I went over the documentation multiple times and nowhere did I see that a null byte wasn't allowed but apparently, that is the case. My initial code design was to encode joy inputs along with multiple buttons, etc, that gets converted directly in to the unit8_t array holding the data to send. I haven't been able to figure out of the problem is on the sending or receiving end but doing it like this resulted in 1 or more continuous bytes that were 0x0. And even though the last few bytes of the 24 total I am sending always ends with more byte and the final null byte. Forcing the length on the send/receive does not resolve this. On the receiving end, it READS the first 0x0 byte in from the data but the remaining uint8_t bytes in the array are garbage.
Anyhow, it's easy to duplicate without all the wacky bit-shifting (which I confirmed was not my problem):
Example Transmit:
// -------------------------------
// Example Trasmit code to send "Hello World" using a null byte for the space
// -------------------------------
#include <Arduino.h>
#include <TFT_eSPI.h> // LCD Driver
#ifdef RH_HAVE_HARDWARE_SPI
#include <SPI.h> // Not actually used but needed to compile
#endif
RH_ASK driver(2000, 16, 17, 5);
void setup() {
Serial.begin(115200);
if (!driver.init())
Serial.println("init failed");
Serial.println("Setup Done.");
}
void loop() {
transdata[0] = 72; // H
transdata[1] = 101 // e
transData[2] = 108; // l
transData[3] = 108; // l
transData[4] = 111; // o
transData[5] = 0; // null!
transdata[6] = 87; // W
transdata[7] = 111; // o
transdata[8] = 114; // r
transdata[9] = 108; // l
transdata[10] = 100; // d
driver.send((uint8_t *)transData, strlen(transData));
driver.waitPacketSent();
delay(50);
}
Example Receive:
// -------------------------------
// Example Receive code to receive "Hello World" using a null byte for the space, but it will fail.
// -------------------------------
#include <Arduino.h>
#include <TFT_eSPI.h> // LCD Driver
#ifdef RH_HAVE_HARDWARE_SPI
#include <SPI.h> // Not actually used but needed to compile
#endif
RH_ASK driver(2000, 16, 17, 5);
char transData[12];
void setup() {
Serial.begin(115200) ;
if (!driver.init())
Serial.println("init failed");
Serial.println("Setup Done.");
}
void loop() {
uint8_t buf[12];
uint8_t buflen = sizeof(buf);
if (driver.recv(buf, &buflen)) // Non-blocking
{
if (sizeof(buf) < dataLen) {
Serial.println("Invalid data count!");
return;
}
Serial.print("Byte Values: ");
for (int i = 0; i < sizeof(buf); i++;) {
Serial.printf("%i ", buf[i]);
}
Serial.println();
}
What you would expect to see here when running these two is the following output on the receiver:
The readout here breaks after the 0. Oddly, even though is receive code is doing a sizeof to confirm the packet size matches the 12 expected, the data being handed over is actually NOT the full array.
My workaround for now was to ensure the first byte of every array member was set to one regardless. This makes the sending packet larger by 3 bytes (I need 18), but then none of them every equal 0. I then just read the upper most 7 bytes of the incoming buffer items, chucking the least significant bit and reassemble the data that way. I'd prefer not to is this is fixable.
I went over the documentation multiple times and nowhere did I see that a null byte wasn't allowed but apparently, that is the case. My initial code design was to encode joy inputs along with multiple buttons, etc, that gets converted directly in to the unit8_t array holding the data to send. I haven't been able to figure out of the problem is on the sending or receiving end but doing it like this resulted in 1 or more continuous bytes that were 0x0. And even though the last few bytes of the 24 total I am sending always ends with more byte and the final null byte. Forcing the length on the send/receive does not resolve this. On the receiving end, it READS the first 0x0 byte in from the data but the remaining uint8_t bytes in the array are garbage.
Anyhow, it's easy to duplicate without all the wacky bit-shifting (which I confirmed was not my problem):
Example Receive:
What you would expect to see here when running these two is the following output on the receiver:
However, what actually prints is something like the following:
The readout here breaks after the 0. Oddly, even though is receive code is doing a sizeof to confirm the packet size matches the 12 expected, the data being handed over is actually NOT the full array.
My workaround for now was to ensure the first byte of every array member was set to one regardless. This makes the sending packet larger by 3 bytes (I need 18), but then none of them every equal 0. I then just read the upper most 7 bytes of the incoming buffer items, chucking the least significant bit and reassemble the data that way. I'd prefer not to is this is fixable.