Using LoRa RFM96W modules I succesfully manage to radio transmit data between a Pro Mini set up as transmitter and a Pro Mini set up as receiver. The SPI bus and the modules perform flawlessly.
However, when transposing the RX program to NodeMCU (with ESP8266) the parsing does not perform correctly:
counter values are sent as integers, from 1 up. At the receiver end this data is being parsed from -65.536 upwards,
The SPI bus connections have been correctly assigned: using lora.h from SandeepMistry it is possible to reassign NSS (chip select) and RST to custom input pins. The MOSI, MISO and CLK pin assignments for NodeMCU are standard on 11, 12 and 13 (see attachment).
A screenshot of the serial monitors for both transmitter and receiver is also in attachment.
The code for the transmitter (Pro Mini 328):
#include <SPI.h>
#include <LoRa.h>
#include <math.h>
int counter = 0;
void setup() {
Serial.begin(9600);
while (!Serial);
Serial.println("LoRa Sender");
while (!LoRa.begin(868E6)) {
Serial.print(".");
delay(500);
}
Serial.println("LoRa Initializing OK!");
}
void loop() {
Serial.print("Sending packet with data: ");
Serial.print("counter = ");
Serial.println(counter);
// Write packet header
LoRa.beginPacket();
// Send 4 bytes (sizeof(count)) starting at the location of counter
LoRa.write((const uint8_t*)&counter, sizeof(counter));
// End packet, send it
LoRa.endPacket();
counter++;
delay(5000);
}
The code on the receiver end (ESP8266):
#include <SPI.h>
#include <LoRa.h>
const int csPin = 15; // LoRa radio chip select GPIO15(D8)->SS OF Lora module
const int resetPin = 2; // LoRa radio reset GPIO2(D4)->RESET OF Lora module
void setup() {
LoRa.setPins(csPin, resetPin);
Serial.begin(9600);
while (!Serial);
Serial.println("LoRa Receiver");
while (!LoRa.begin(868E6)) {
Serial.print(".");
delay(500);
}
Serial.println("LoRa Initializing OK!");
// put the radio into receive mode
LoRa.receive();
}
void loop() {
yield();
onReceive(LoRa.parsePacket());
}
void onReceive(int packetSize) {
// Try to parse packet
if (packetSize == 0) {
return;
}
// Read 4 bytes into a
// Read 4 bytes into counter
int counter;
for (int i = 0; i < sizeof(counter); i++) {
*(((uint8_t*)&counter) + i) = (uint8_t)LoRa.read();
}
// Display read values
Serial.print(" counter = ");
Serial.print(counter);
Serial.print(" with RSSI ");
Serial.println(LoRa.packetRssi());
}
When sending LoRa.write((const uint8_t*)&counter, sizeof(counter));
And for parsing.
*(((uint8_t*)&counter) + i) = (uint8_t)LoRa.read();
If you send a 7, 0000 0111, and you are getting a -65529, 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 0000 0000 0000 0111, you might be able to see that the sent info is being received properly but not properly parsed.
Idahowalker:
When sending
LoRa.write((const uint8_t*)&counter, sizeof(counter));
And for parsing.
*(((uint8_t*)&counter) + i) = (uint8_t)LoRa.read();
If you send a 7, 0000 0111, and you are getting a -65529, 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 0000 0000 0000 0111, you might be able to see that the sent info is being received properly but not properly parsed.
That I know; but how do I solve this?
Grts
Erik
Do you know how to write code to AND 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 0000 0000 0000 0111 with FFFF?
Will you be sending negative numbers?
I ask because uint8_t are used as the number sent.
try sender code as per the LoRa example.
LoRa.write((const uint8_t*)&counter);
Have you considered using the example LoRa code to receive data arduino-LoRa/LoRaReceiver.ino at master · sandeepmistry/arduino-LoRa · GitHub?
I figure the Pro Mini is the issue with sending a 4 byte thingy. On a Pro Mini is not an integer 2 bytes? So When you send 4 bytes you'll be sending 2 bytes of a known quantity and 2 bytes of an unknown quantity. Instead you might try declaring your counter as a uint32_t or a int32_t.
an integer on an AVR is 2 bytes, but on an ESP 4 bytes. so using sizeof() to determine packet size is not going to return the same result on both boards. Either send for bytes and receive 4 bytes or send 2 bytes and receive 2 bytes. Using 'int' as a type is the issue. either use int16_t or int32_t as a type (or uint16_t or uint32_t for unsigned data)
Deva_Rishi:
an integer on an AVR is 2 bytes, but on an ESP 4 bytes. so using sizeof() to determine packet size is not going to return the same result on both boards. Either send for bytes and receive 4 bytes or send 2 bytes and receive 2 bytes. Using 'int' as a type is the issue. either use int16_t or int32_t as a type (or uint16_t or uint32_t for unsigned data)
Interesting! I will try that out; I wasn't aware of that.
Idahowalker:
I figure the Pro Mini is the issue with sending a 4 byte thingy. On a Pro Mini is not an integer 2 bytes? So When you send 4 bytes you'll be sending 2 bytes of a known quantity and 2 bytes of an unknown quantity. Instead you might try declaring your counter as a uint32_t or a int32_t.
Good idea! Thanks a lot for that information. Will try that out; same thanks too for Deva.
