Skip to content

Receiving garbage data #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sasi143 opened this issue Mar 6, 2019 · 27 comments
Closed

Receiving garbage data #17

sasi143 opened this issue Mar 6, 2019 · 27 comments
Labels
bug Something isn't working

Comments

@sasi143
Copy link

sasi143 commented Mar 6, 2019

Actual data:
bytearray(b'{waterLevel:71,name:TAOF0201,solenoidState:0,valid:1,ultrasonicState:1,waterLevelDistance:43,freeMemory:38,compareStatus:0}')

"Received data:"
Received (raw bytes): bytearray(b"+w4\xb4irL\xa9v\xa5l:7\x11.Lame:TAOF5b51,solenoidState:0,valid:1Lulr\xfa\xf9wonicState:1,waterLevelDistance:43,freeMemory:38,coe\xf8a'`\x06tatus:0}")

I am receiving the above data instead of actual data, some times data was printing correct and some times it behaving strangely. please help me with this.

I am using Arduino uno for client and Raspberry pi for the server with RFM9x

Thankyou

@ladyada
Copy link
Member

ladyada commented Mar 6, 2019

try sending shorter chunks until you can figure out where the issue is

@sasi143
Copy link
Author

sasi143 commented Mar 6, 2019

My Arduino can able to receive the data perfectly, but Raspberry pi receiving data in garbage format

@jerryneedell
Copy link
Contributor

@sasi143 -- What library are you using on the Arduino? can you post the code you are running on both ends? What pins are you using on the Raspberry Pi?

@sasi143
Copy link
Author

sasi143 commented Mar 6, 2019

Here is my client code (Arduino uno)
`#include <SPI.h>
#include <RH_RF95.h>

#define RFM95_CS 10
#define RFM95_RST 9
#define RFM95_INT 2

#define RF95_FREQ 868.0

const unsigned int TRIG_PIN = 8;
const unsigned int ECHO_PIN = 9;
const unsigned int SOLE_PIN = 5;

char TankName[] = "TAOF0201";

const unsigned int MaxTankHeight = 110;
const unsigned int MinTankHeight = 15;

unsigned int Samples = 10;
char ValveCuttOff = 90;
char ValveOpen = 75;
const unsigned int ErrCheck = 120;

unsigned long duration = 0;
bool verify = true;
bool compareState = false;
bool solenoidValveState = false;
bool storeDurationValue = false;
bool ultraBeat = false;
unsigned long previousDurationValue = 0;
unsigned long previousMillis = 0;
const long interval = 1000;

// Singleton instance of the radio driver
RH_RF95 rf95(RFM95_CS, RFM95_INT);

void setup()
{
pinMode(RFM95_RST, OUTPUT);
digitalWrite(RFM95_RST, HIGH);

while (!Serial);
Serial.begin(9600);
delay(100);

Serial.println(F("Arduino LoRa TX Node!"));

pinMode(TRIG_PIN, OUTPUT);
pinMode(ECHO_PIN, INPUT);
pinMode(SOLE_PIN, OUTPUT);
// manual reset
digitalWrite(RFM95_RST, LOW);
delay(10);
digitalWrite(RFM95_RST, HIGH);
delay(10);

while (!rf95.init()) {
Serial.println("LoRa radio init failed");
while (1);
}
Serial.println(F("LoRa radio init OK!"));

// Defaults after init are 434.0MHz, modulation GFSK_Rb250Fd250, +13dbM
if (!rf95.setFrequency(RF95_FREQ)) {
Serial.println(F("setFrequency failed"));
while (1);
}
Serial.print(F("Set Freq to: ")); Serial.println(RF95_FREQ);

// you can set transmitter powers from 5 to 23 dBm:
rf95.setTxPower(23, false);

}

void loop()
{
mainFunction();
loraSubFunction();
}

int freeRam ()
{
extern int __heap_start, *__brkval;
int v;
return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}

void mainFunction() {
unsigned long currentMillis = millis();

if ((currentMillis - previousMillis) >= interval) {
// save the last time you blinked the LED
previousMillis = currentMillis;
long errDuration = 0;
int temp = 0;
int percentage = 0;
int durationDifference = 0;
int distance = 0 ;
int AvgSamples = Samples;
int distanceCaliculate = 0;

for (int i = 0; i < AvgSamples; i++)
{
  digitalWrite(TRIG_PIN, LOW);
  delayMicroseconds(2);
  digitalWrite(TRIG_PIN, HIGH);
  delayMicroseconds(10);
  digitalWrite(TRIG_PIN, LOW);
  duration = pulseIn(ECHO_PIN, HIGH);
  distanceCaliculate = (duration / 29 ) / 2;
  if ((duration <= 58 * MaxTankHeight) && (duration >= 58 * MinTankHeight))
  {


    if (storeDurationValue == false)
    {
      previousDurationValue = duration;
      storeDurationValue = true;
    }
    durationDifference = duration - previousDurationValue;

    durationDifference = abs(durationDifference);
    if (durationDifference <= ErrCheck)
    {
      previousDurationValue = duration;
      errDuration += duration;
      temp++;
      if (temp == 10) {
        AvgSamples = 0;
        distance = ((errDuration / temp) / 29 ) / 2;
      }


    }
  }

  delay(500);
}

if ((duration > 0) && (distance == 0)) {

  Serial.println(F("-----------------------------Sensor values are not accurate---------------------------------------"));
  percentage = 0;
  verify = false;
  ultraBeat = true;

}

if (duration <= 0) {
  Serial.println(F("Warning: no pulse from sensor"));
  percentage = 0;
  verify = false;
  ultraBeat = false;
}
else {
  Serial.print(F("distance to nearest object:"));
  Serial.println(distance);
  Serial.println(" cm");
  ultraBeat = true;
  if ((distance <= MaxTankHeight) && (distance >= MinTankHeight))
  {

    percentage = map(distance, MinTankHeight, MaxTankHeight, 100, 0);
    verify = true;
    if ((percentage > ValveCuttOff) && (compareState == false))
    {
      digitalWrite(SOLE_PIN, HIGH);
      solenoidValveState = true;
      compareState = true;
      Serial.println(F("----Solenoid Valve turned ON------"));
    }
    else if ((percentage < ValveOpen) && (compareState == true))
    {
      digitalWrite(SOLE_PIN, LOW);
      solenoidValveState = false;
      compareState = false;
      Serial.println(F("----Solenoid Valve turned OFF------"));
    }
  }
  else {
    verify = false;
    percentage = 0;
  }


}

Serial.println(F("Sending to rf95_server"));
int availableRam = map(freeRam(), 0, 3000, 0, 100);
String jsonChar = "{waterLevel:" + (String)percentage + ",name:" + (String)TankName + ",solenoidState:" + (String)solenoidValveState + ",valid:" + (String)verify + ",ultrasonicState:" + (String)ultraBeat + ",waterLevelDistance:" + (String)distanceCaliculate + ",freeMemory:" + (String)availableRam + ",compareStatus:"+(String)compareState+"}";

rf95.send(jsonChar.c_str (), jsonChar.length());

Serial.println(F("Waiting for packet to complete...")); delay(10);
rf95.waitPacketSent();

}

}

void loraSubFunction() {
if (rf95.available())
{
// Should be a message for us now
uint8_t buf[RH_RF95_MAX_MESSAGE_LEN];
uint8_t len = sizeof(buf);

if (rf95.recv(buf, &len))
{
  Serial.println(F("------------------Got reply------------------------"));
  String output = (char*)buf;

  Serial.println(output.substring(0, len));
  if (output.substring(0, len).substring(5, 13) == TankName) {
    if (output.substring(0, len).substring(20, len) == "ON" || output.substring(0, len).substring(20, len) == "OFF")
    {
      if (output.substring(0, len).substring(20, len) == "ON") {
        solenoidValveState = true;
        digitalWrite(SOLE_PIN, HIGH);
      }
      if (output.substring(0, len).substring(20, len) == "OFF") {
        solenoidValveState = false;
        digitalWrite(SOLE_PIN, LOW);
      }



      rf95.send("{Tank:TAOF0301,state:success}", 29);
    }
    Serial.println();
  }
}

}
}`
connected pins on arduino uno from rfm9x:
cs - 10
mosi - 11
miso - 12
sck- 13
g0 - 2
gnd - gnd
vin - 3.3
Rst - None(Not connected)

My Raspberry pi code :
`import board
import busio
import digitalio
import time
import adafruit_rfm9x

Define radio parameters.

RADIO_FREQ_MHZ = 868.0 # Frequency of the radio in Mhz. Must match your
# module! Can be a value like 915.0, 433.0, etc.

Define pins connected to the chip, use these if wiring up the breakout according to the guide:

CS = digitalio.DigitalInOut(board.D5)
RESET = digitalio.DigitalInOut(board.D6)

Initialize SPI bus.

spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)

Initialze RFM radio

rfm9x = adafruit_rfm9x.RFM9x(spi, CS, RESET, RADIO_FREQ_MHZ,baudrate=1000000)

rfm9x.tx_power = 23

while True:
# Optionally change the receive timeout from its default of 0.5 seconds:
packet = rfm9x.receive(timeout=2.0)
# If no packet was received during the timeout then None is returned.
if packet is None:
#print('Received nothing! Listening again...')
None
else:
#packet_text = str(packet, "utf-8")
print('Received (raw bytes): {0}\n'.format(packet))
rssi = rfm9x.rssi
print('Received signal strength: {0} dB'.format(rssi))`

connected pins from rfm9x to raspberry pi3:

cs - 29
mosi - 20
miso - 21
sck- 23
g0 - None(not conneted)
gnd - 25
vin - 17
Rst - 31

@jerryneedell
Copy link
Contributor

A few suggestions:

  1. try removing the baud rate setting here:
rfm9x = adafruit_rfm9x.RFM9x(spi, CS, RESET, RADIO_FREQ_MHZ,baudrate=1000000)

use
rfm9x = adafruit_rfm9x.RFM9x(spi, CS, RESET, RADIO_FREQ_MHZ)

It is not clear why you are lowering the baud rate to 1Mhz from the default 5Mhz

If that does not help then as @ladyada suggested, try sending shorter packets just to see if they work reliably and if they do increase the size to see if there is a threshold where it fails.

also - how often are you sending these packets. ti looks like the interval s 1 second. - If so, that may be an issue with the receive timeout of 2 seconds. Try slowing down the transit rate to see if that helps.
Good luck!

@sasi143
Copy link
Author

sasi143 commented Mar 7, 2019

@jerryneedell , @ladyada I did below the things that you suggested.

  1. Reduced transmitting data size from 128 bytes to 18 bytes.
  2. Increased transmitting time from 1 second to 3 minutes
  3. Changed baud rate to 5Mhz as default
  4. Received timeout parameter changed to default(0.2 seconds) in python code(Gateway)

Now I am getting data like this:

bytearray(b'| \xea\x81q\x9e\x86\x02\xffZ\xe0uQ\xd0\xf6\nV3\x1c>\xb7\x9b\x90\x86\xed\x05*\xe5\xe1\xee\xf4$\xf1\xb0\x1f\xb1\x86\xc3\xf5\t?\x80syr\xac\xa7\x0b\x1f\xb01(5\xf0\x0e4\x8eB\xbb\x1a~\x1c\x9c\x0b\x9a\x11`\xd2\xd2-\x16\xe0Le\x9b@t\xc4\xd3~\x18Eol\xfdM#k\xf2\xde\x9e\xca\xa5\xa2\xa7#5l\x98\x0c&M\xd2\x8a\xa6\x0f\x0e\xba\x95\xb0b;"\xe8\x94A\xa5Q\xbf\xc7Q\xa5\x04\xf2H"\xf1\xe3m\\x1d6C\x80\x19=\xfa\xbf\x12\xd0\xa0\x95\xed\xc2K\xfae')

Actuall data is :

bytearray(b'121,0,0,0,0,0,43,0')

Sometimes I can able to receive the data correct and sometimes it behaves strangely. Please suggest on the same

@sasi143
Copy link
Author

sasi143 commented Mar 8, 2019

can someone please respond?

@jerryneedell
Copy link
Contributor

I have no idea what is going on. When you say it works sometimes, does to run for awhile then start giving the bad data? Are you sure you don't have something else transmitting? I know I often see bursts of data that I don't recognize if I just listen.
But I have not seen problems similar to what you are describing. Have you tried just using the basic test programs on both units just to verify basic function?

When you say the Arduino receives data OK, what data is that? Is it being sent from the Raspberry Pi?

For your tests, are the radios near each other and are you just using simple wire antennas?

@sasi143
Copy link
Author

sasi143 commented Mar 8, 2019

@jerryneedell Thanks for responding quickly. I am sure it was not sending any bad data because at the same time I can able to receive the data perfectly in Arduino uno. The basic functionality is failing some times.

I am sending plain string data from Arduino uno(client) to raspberry pi(gateway)

I am using this type of Antena : https://www.adafruit.com/product/3340

If possible can you please help me to run this code : https://github.com/hallard/RadioHead/blob/master/examples/raspi/rf95/rf95_server.cpp

when I run the code it saying :

RF95 module init failed, Please verify wiring/module
RF95 CS=GPIO25, IRQ=GPIO4, RST=GPIO17, LED=GPIO255

I didn't find IRQ and LED pin on LoRA module.

can you please help me on this.
Thank you

@jerryneedell
Copy link
Contributor

@sasi143 I have not used the RadioHead library on my RaspBerry Pi at all. I have only used the CircuitPython RFM9X library for LoRa.

The LED pin is , Think just for an external LED if you want to use one -- you don't need it.
The IRQ pin on the LoRa Module is the pin labeled G0 if you are using one of these boards
https://www.adafruit.com/product/3072

On the Arduino are you using the adafruit fork of the Radiohead library? https://github.com/adafruit/RadioHead
That is what I have used.

When you say the Arduino is receiving data, where is the data coming from?

Have you ever been able to communicate with the Raspberry Pi system?

@sasi143
Copy link
Author

sasi143 commented Mar 8, 2019

I am using the same product and the same library that you asked.

one arduino uno-1 (client) sending the data. I am running receiving the code in both Raspberry pi(Python) and arduino uno -2.

I can able to communicate raspberry pi with the only python, but still failing to run Radio head c++ files in the raspberry pi

@jerryneedell
Copy link
Contributor

OK -- so when you use the adafruit-circuitpython-rfm9x library on the Raspberry PI, you can receive data reliably? It is just the c++ library that is not working? Is that correct?

@sasi143
Copy link
Author

sasi143 commented Mar 8, 2019

No, I can able to receive the data in Raspberry pi but it was not consistent manner. sometimes I am receiving data good and some times it was behaving strangely.

Good data : bytearray(b'121,56,0,1,1,57,43,0')
Strange data :
bytearray(b"\xd3\xd1\xe6\x0f\xbey\x08\x1b\x90\x1a\x97\x10\xff- Z\x85r\xa8K\xcbJ\xe2\x11\x96\x06\xc06\xd2\x81\xc6\xdf\xd0\x1d\x95\xe1?\x97_-\xb6^ncl\'V\x11\xe4\xbaU\x9eF)\x94\xac\x1c\x9ci(\xa6\x1a+\xb2d\xd6 \xa5u>\xfb\xb8zwZ\xa5\xb9\x12\xfa\x81\xce\xc1*o\xe9A\xb3\x95\x1a\xc7\xf0G2\xb7\xa0\x90\xf0$|\xcfG;,\xbdo\xc1\xe0\x8a{\x96[\xcf\x7f\x08\xc3x.RM6\xdc\x1c|\xb8\xc8\xb7\x8e\x84\xbb\x96")

so, python library was not consistently printing the right data. so, I am thinking to move to c++ program on raspberry pi which was build in RadioHead library
Link : https://github.com/adafruit/RadioHead/tree/master/examples/raspi

But, when I try to run "RasPiRH.cpp" file in Raspberry pi it saying "RF95 module init failed, Please verify wiring/module"

@jerryneedell
Copy link
Contributor

ah -- how often do you get the bad packets? -- as I mentioned I do see something similar -- very infrequently -- many minutes apart -- I will get a packet like this

Received (raw bytes): bytearray(b'Zr\xee\x1b&\xb3\x14\x0c\xa4 \xd1\xd8No\xe7\x16\xf0\x12\x04\x06\x11\xb6\x9a\x89\r\x82\x0b0\xbf99\x0e\xabb\xf7\x0e,v\xfa J\x80\xc3x\xf2I\xb0g\nO\xf4\xf4\x9cc\xea\x0b\xb2\xaf8\x8b\x9a\xce\xda\xfe\xfba\x8a\x99\xd3\x08\xe3w37\xa9\xc3\x963\x8f\xa1\x00\x8b\xdc\xcb\x81\x1e)g.\xf3\xbaa\xaaC\xe8\xb0\x10\xd9\xb2\x11H\xdbO\xf2\r\xf5D\xc1+\xbd\x8d\xd1\xf2\x7f\x8e\xe1\xb5\xc9\x13\x87X\xd4\x941e\x81DQ-$\x98\x0c2\x9b\x12s\xc8\xe1\xbf\x88\xceu/`\xe1A\r\xc5-\x8b\x8f\xd8\x12\xc1)\xf6\xe0E&\xce\xb2\xad\x8b\xfe\xdd\xb9\x92\xcd\x15r\xa6')
Received signal strength: -86 dB

I get these if I just listen without anything transmitting.
I have not been able to determine the source. I just ignore them - I use the packet headers to filter them out.

Is this what you are seeing or do the bad packets correspond to the times of your actual transmissions? I think that is what you stated in your first message, so I was not thinking it was comparable, but it may be.
Since the bad packets you report are not even close in length to your transmitted packet, I am confused how they can be related.

If I have time, I can take a look at the c++ library this weekend,

@sasi143
Copy link
Author

sasi143 commented Mar 8, 2019

once again thanks for the quick response,

sometimes my transmitting data can be manipulated like below

bytearray(b'121,56,0,1,1,5>,4\xa3\xb59')

some values are correct in that data and some index values are filled up garbage values

I am really appreciate your kind response

@sasi143
Copy link
Author

sasi143 commented Mar 8, 2019

The disturbance of data is not frequent, but I can able to see after every 3 to 4 correct messages in raspberry pi. whereas Arduino can able to receive the data perfectly.

@jerryneedell
Copy link
Contributor

That is good information - I wish I had better suggestions - Other than the infrequent noise packets, I have not had problems with receiving data on the Raspberry Pi. I usually am sending them from a board running CircuitPython, though, not Arduino. I'll try to run some tests this weekend to see if I can replicate your problems.

@sasi143
Copy link
Author

sasi143 commented Mar 8, 2019

Thanks alot @jerryneedell , will wait for your response. Thanks for your work.

@jerryneedell
Copy link
Contributor

jerryneedell commented Mar 9, 2019

@sasi143 I cannot reproduce your setup exactly, but I have been running tests sending data from Arduino library code to Python code on a Raspberry Pi

I have not had any issues other than some missed packets if I left the default .5 second timeout.
In that case, I suspect it is just missing some packets because the listening duty cycle is lower. This is one major issue with the Python code since it does not use interrupts to detect if a packet has arrived in the background.

I have not seen any corrupted packets.

Can you try these examples? You will have to adjust the Pin assignments.

Note, only the first 2 digits of the packet counter are shown in the last two bytes. This was just a quick example...

Arduino sketch -- feather M0 with rfm9x featherwing

// Feather9x_TX
// -*- mode: C++ -*-
// Example sketch showing how to create a simple messaging client (transmitter)
// with the RH_RF95 class. RH_RF95 class does not provide for addressing or
// reliability, so you should only use RH_RF95 if you do not need the higher
// level messaging abilities.
// It is designed to work with the other example Feather9x_RX

#include <SPI.h>
#include <RH_RF95.h>
/*for feather32u4

#define RFM95_CS 8
#define RFM95_RST 4
#define RFM95_INT 7
*/
/* for feather m0  
#define RFM95_CS 8
#define RFM95_RST 4
#define RFM95_INT 3
*/

/* for shield 
#define RFM95_CS 10
#define RFM95_RST 9
#define RFM95_INT 7
*/

/* for ESP w/featherwing 
#define RFM95_CS  2    // "E"
#define RFM95_RST 16   // "D"
#define RFM95_INT 15   // "B"
*/

/* Feather 32u4 w/wing
#define RFM95_RST     11   // "A"
#define RFM95_CS      10   // "B"
#define RFM95_INT     2    // "SDA" (only SDA/SCL/RX/TX have IRQ!)
*/

#define RFM95_RST     11   // "A"
#define RFM95_CS      10   // "B"
#define RFM95_INT     6    // "D"

/* Teensy 3.x w/wing 
#define RFM95_RST     9   // "A"
#define RFM95_CS      10   // "B"
#define RFM95_INT     4    // "C"
*/


#if defined(ESP32)    // ESP32 feather w/wing
  #define RFM95_RST     27   // "A"
  #define RFM95_CS      33   // "B"
  #define RFM95_INT     12   //  next to A
#endif

// Change to 434.0 or other frequency, must match RX's freq!
#define RF95_FREQ 915.0

// Singleton instance of the radio driver
RH_RF95 rf95(RFM95_CS, RFM95_INT);

void setup() 
{
  pinMode(RFM95_RST, OUTPUT);
  digitalWrite(RFM95_RST, HIGH);

  Serial.begin(115200);
  while (!Serial) {
    delay(1);
  }

  delay(100);

  Serial.println("Feather LoRa TX Test!");

  // manual reset
  digitalWrite(RFM95_RST, LOW);
  delay(10);
  digitalWrite(RFM95_RST, HIGH);
  delay(10);

  while (!rf95.init()) {
    Serial.println("LoRa radio init failed");
    while (1);
  }
  Serial.println("LoRa radio init OK!");

  // Defaults after init are 434.0MHz, modulation GFSK_Rb250Fd250, +13dbM
  if (!rf95.setFrequency(RF95_FREQ)) {
    Serial.println("setFrequency failed");
    while (1);
  }
  Serial.print("Set Freq to: "); Serial.println(RF95_FREQ);
  
  // Defaults after init are 434.0MHz, 13dBm, Bw = 125 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC on

  // The default transmitter power is 13dBm, using PA_BOOST.
  // If you are using RFM95/96/97/98 modules which uses the PA_BOOST transmitter pin, then 
  // you can set transmitter powers from 5 to 23 dBm:
  rf95.setTxPower(23, false);
  //rf95.setPromiscuous(true);
}

int16_t packetnum = 0;  // packet counter, we increment per xmission
char radiopacket[103] = "0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789";
void loop()
{
  delay(5000); // Wait 5 seconds between transmits, could also 'sleep' here!
  Serial.println("Transmitting..."); // Send a message to rf95_server
  
  itoa(packetnum++, radiopacket+100, 10);
  Serial.print("Sending "); Serial.println(radiopacket);
  radiopacket[102] = 0;
  
  Serial.println("Sending...");
  delay(10);
  rf95.send((uint8_t *)radiopacket, 103);

  Serial.println("Waiting for packet to complete..."); 
  delay(10);
  rf95.waitPacketSent();
  // Now wait for a reply
  uint8_t buf[RH_RF95_MAX_MESSAGE_LEN];
  uint8_t len = sizeof(buf);

  Serial.println("Waiting for reply...");
  if (rf95.waitAvailableTimeout(1000))
  { 
    // Should be a reply message for us now   
    if (rf95.recv(buf, &len))
   {
      Serial.print("Got reply: ");
      Serial.println((char*)buf);
      Serial.print("RSSI: ");
      Serial.println(rf95.lastRssi(), DEC);    
    }
    else
    {
      Serial.println("Receive failed");
    }
  }
  else
  {
    Serial.println("No reply, is there a listener around?");
  }

}

Python script on Raspberry Pi

# Simple demo of sending and recieving data with the RFM95 LoRa radio.
# Author: Tony DiCola
import board
import busio
import digitalio
import time

import adafruit_rfm9x


# Define radio parameters.
RADIO_FREQ_MHZ = 915.0  # Frequency of the radio in Mhz. Must match your
                        # module! Can be a value like 915.0, 433.0, etc.

# Define pins connected to the chip, use these if wiring up the breakout according to the guide:
CS = digitalio.DigitalInOut(board.CE1)
RESET = digitalio.DigitalInOut(board.D17)
# Or uncomment and instead use these if using a Feather M0 RFM9x board and the appropriate
# CircuitPython build:
# CS = digitalio.DigitalInOut(board.RFM9X_CS)
# RESET = digitalio.DigitalInOut(board.RFM9X_RST)

# Initialize SPI bus.
spi = busio.SPI(board.SCK, MOSI=board.MOSI, MISO=board.MISO)

# Initialze RFM radio
rfm9x = adafruit_rfm9x.RFM9x(spi, CS, RESET, RADIO_FREQ_MHZ)

# Note that the radio is configured in LoRa mode so you can't control sync
# word, encryption, frequency deviation, or other settings!

# You can however adjust the transmit power (in dB).  The default is 13 dB but
# high power radios like the RFM95 can go up to 23 dB:
rfm9x.tx_power = 23

# Send a packet.  Note you can only send a packet up to 60 bytes in length.
# This is a limitation of the radio packet size, so if you need to send larger
# amounts of data you will need to break it into smaller send calls.  Each send
# call will wait for the previous one to finish before continuing.
rfm9x.send(bytes('Hello world!\r\n',"utf-8"))
print('Sent hello world message!')

# Wait to receive packets.  Note that this library can't receive data at a fast
# rate, in fact it can only receive and process one 60 byte packet at a time.
# This means you should only use this for low bandwidth scenarios, like sending
# and receiving a single message at a time.
print('Waiting for packets...')
while True:
    packet = rfm9x.receive( timeout =5.0)
    # Optionally change the receive timeout from its default of 0.5 seconds:
    #packet = rfm9x.receive(timeout=5.0)
    # If no packet was received during the timeout then None is returned.
    if packet is None:
        continue
    else:
        # Received a packet!
        # Print out the raw bytes of the packet:
        print(time.ctime())
        print('Received (raw bytes): {0}'.format(packet))
        print([hex(x) for x in packet])
        # Also read the RSSI (signal strength) of the last received message and
        # print it.
        rssi = rfm9x.rssi
        print('Received signal strength: {0} dB'.format(rssi))
        rfm9x.send(bytes('Hello world!\r\n',"utf-8"))

received by Raspberry Pi

Sat Mar  9 09:20:52 2019
Received (raw bytes): bytearray(b'012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678974\x00')
['0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x37', '0x34', '0x0']
Received signal strength: -27 dB
Sat Mar  9 09:20:58 2019
Received (raw bytes): bytearray(b'012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678975\x00')
['0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x37', '0x35', '0x0']
Received signal strength: -27 dB
Sat Mar  9 09:21:03 2019
Received (raw bytes): bytearray(b'012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678976\x00')
['0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x30', '0x31', '0x32', '0x33', '0x34', '0x35', '0x36', '0x37', '0x38', '0x39', '0x37', '0x36', '0x0']
Received signal strength: -27 dB

@sasi143
Copy link
Author

sasi143 commented Mar 11, 2019

@jerryneedell Can I please let us know the Raspberry pi pin configuration with RFM 95?

@jerryneedell
Copy link
Contributor

For the RFM95 breakout board on a Raspberry Pi 3B+ I use:

signal  physical RPi Pin
3.3V         17
Ground    25 
MOSI        19      ==     board.MOSI
MISO        21      ==     board.MISO
SCK          23     ==     board.SCK
CS (CE1)  26     ==     board.CE1
RESET      11      ==     board.D17

@jgresl
Copy link

jgresl commented Aug 28, 2019

No, I can able to receive the data in Raspberry pi but it was not consistent manner. sometimes I am receiving data good and some times it was behaving strangely.

Good data : bytearray(b'121,56,0,1,1,57,43,0')
Strange data :
bytearray(b"\xd3\xd1\xe6\x0f\xbey\x08\x1b\x90\x1a\x97\x10\xff- Z\x85r\xa8K\xcbJ\xe2\x11\x96\x06\xc06\xd2\x81\xc6\xdf\xd0\x1d\x95\xe1?\x97_-\xb6^ncl\'V\x11\xe4\xbaU\x9eF)\x94\xac\x1c\x9ci(\xa6\x1a+\xb2d\xd6 \xa5u>\xfb\xb8zwZ\xa5\xb9\x12\xfa\x81\xce\xc1*o\xe9A\xb3\x95\x1a\xc7\xf0G2\xb7\xa0\x90\xf0$|\xcfG;,\xbdo\xc1\xe0\x8a{\x96[\xcf\x7f\x08\xc3x.RM6\xdc\x1c|\xb8\xc8\xb7\x8e\x84\xbb\x96")

so, python library was not consistently printing the right data. so, I am thinking to move to c++ program on raspberry pi which was build in RadioHead library
Link : https://github.com/adafruit/RadioHead/tree/master/examples/raspi

But, when I try to run "RasPiRH.cpp" file in Raspberry pi it saying "RF95 module init failed, Please verify wiring/module"

When using the C++ version of the RadioHead library, you have to edit the code to specify which LoRa hardware is being used. Directions are posted in the comments.

example with Dragino LoRa hat hardware on /RadioHead/examples/raspi/rf95/rf95_server.cpp :

Comment out #define BOARD_LORASPI
Uncomment // #define BOARD_DRAGINO_PIHAT

or specify the wiring configurations...

/* Raspberry Pi wiring configurations for Dragino LoRa Hat */
#define RF95_CHIP_SELECT_PIN RPI_V2_GPIO_P1_22 // Slave Select on GPIO25 so P1 connector pin 22
#define RF95_INTERRUPT_PIN RPI_V2_GPIO_P1_07 // IRQ on GPIO4 so P1 connector pin 7
#define RF95_RESET_PIN RPI_V2_GPIO_P1_11 // Reset on GPIO17 so P1 connector pin 11

https://github.com/hallard/RadioHead

@jerryneedell
Copy link
Contributor

started looking at this a bit more -- I am running a simple listening program on both an RPi 4 and on a feather_m0_adalogger with rfm9x both see the occasional "garbage" packets but interestingly, they don't see them at the same time!

For this test, I have both systems listening for packets with a third system sending a packet every 10 seconds. Bot see the transmitted packets and each has seen one "garbage" packet in the past 15 minutes, but they did not see the same "garbage" packet. They were minutes abaort and had very different content.

I will try to get some additional captures.

@kattni
Copy link
Contributor

kattni commented May 4, 2020

@sasi143 @jerryneedell Are you still experiencing this issue?

@kattni kattni added the bug Something isn't working label May 4, 2020
@kevin192291
Copy link

I am having this very same issue, I am getting a at the end of my data, but only sometimes.
It is not reliable. Sometimes my message sends just fine, others, it will have between 1 and 5 strange characters at the end. I am not sure if it has something to do with the power to the ESP8266.

@maholli
Copy link

maholli commented Oct 31, 2020

@sasi143 @kevin192291 See my recent issue: #51. Depending on your LoRa configuration, implementing the improvements and errata described in my first post may remedy your problems.

@jerryneedell
Copy link
Contributor

There were some changes made to address this in #57 -- I still see occasional noise packets, butI'm not sure there is anything we can do about them. If there are no objections I will close this for now and we can re-open it or start a new issue if necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

7 participants