Sending struct from Arduino to Raspberry Pi - wrong types

Question

I'm using Raspberry Pi and Arduinos for my home automation project where Raspberry Pi is the controler of Arduino nodes. I use nRF24 wireless transceivers to communicate.

My problem is that when I was sending a structure like following

struct TempSensorData

{ uint32_t result; uint32_t temperature; uint32_t humidity; };

From Raspberry to Raspberry everything went fine but now when I use Arduino as sender I get very strange results:

received: status: 335544320, temperature: 754974720 degrees, humidity: 0%

While on Raspberry it was

received: status: 0, temperature: 22 degrees, humidity: 44%

Can this be a problem with types? Or with different type of architecture (like different sizes on 3-2bit and 64-bit arch)?

EDIT:

Code on Raspberry:

if (radio.available())

{ // dump the payloads until we've got everything Message receivedData = {0}; radio.read(&receivedData, sizeof(Message)); TempSensorData data = receivedData.msgData.tempSensorData; std::cout << "received: status: " << data.result << ", temperature: " << data.temperature << " degrees, humidity: " << data.humidity << "%" << std::endl; //TODO here we have some strange numbers - check if we have proper types }

Before that I have:

radio.begin();
radio.setPALevel(RF24_PA_LOW);
radio.setChannel(0x4c);
radio.openReadingPipe(1, RASPI_READ_ADDR);
radio.openWritingPipe(RASPI_WRITE_ADDR);

radio.enableDynamicPayloads();
radio.setAutoAck(true);
radio.powerUp();
radio.startListening();

And on Arduino:

Header header = {thisNodeId, thisNodeType, 0, static_cast<uint8_t>(MsgType::TEMP_SENSOR_DATA), 12345, Status::ok};
TempSensorData dhtData;
dhtData.result = DHT.read11(DHT11_PIN);
dhtData.humidity = (int)DHT.humidity;
dhtData.temperature = (int)DHT.temperature;
Message message = {0};
message.header = header;
message.msgData.tempSensorData = (dhtData);
radio.stopListening();
radio.write(&message, sizeof(message));
radio.startListening();

I also use a common header with defined structures for both Arduino and Raspberry, which contains:

#define RASPI_WRITE_ADDR 0xF0F0F0F0F0LL
#define RASPI_READ_ADDR 0xF0F0F0F0E1LL

struct TempSensorData {   
  uint32_t result;
  uint32_t temperature;
  uint32_t humidity;
};  

enum class Status : uint8_t

{
ok, error, fail };

enum class MsgType : uint8_t {
    INITIALIZATION,
    RESET_REQUEST,
    ACK_NACK,
    TEMP_SENSOR_DATA,
};

struct Header {
  uint8_t nodeId;
  uint8_t nodeType;
  uint8_t location;
  uint8_t msgType;
  uint16_t checksum;
  Status status;
};

union MsgData {
  InitMsgData initMsgData;
  AckNack ackNack;
  TempSensorData tempSensorData;
};

struct Message {
    Header header;
    MsgData msgData;
};

radio is an item of RF24 class from https://github.com/TMRh20/RF24/

Unfortunately the RF24 repo is 64 commits ahead of what I use.

EDIT2:

Maybe the problem lays in that

enum class Status {};

which I use in both files.

I must add that I use g++-4.7 when compiling on Raspberry and when compiling on Arduino I use avr-g++-4.8.2

Answer 1

It is not a size problem: uint32_t is always 32 bits. Converting the numbers to hex gives:

• Raspberry to Raspberry: 0x00000000, 0x00000016, 0x0000002c
• Arduino to Raspberry: 0x14000000, 0x2d000000, 0x00000000

There seems to be an offset between the two. You may just have lost one byte when the Arduino is the sender. There may be also a byte order issue, but your test is not sufficient to say. You can, e.g., send a series of 0x12345678 to know for sure.

You need to devise a way of synchronizing the communication, i.e. to identify, in the byte stream, which is the first byte of the packet.

Edit: Let me illustrate how this can happen both with and without and endianness issue. I'll assume you are transmitting {status: 0, temperature: 20, humidity: 45} and the first byte(s) of the first packet are lost. On the receiving side, you combine the remaining bytes of the first packet with the first byte(s) of the second packet, and interpret the whole as a single packet. You get: {status: 335544320, temperature: 754974720, humidity: 0}.

In a little endian to little endian scenario, you only need to loose one byte:

original data:     0x00000000, 0x00000014, 0x0000002d
transmitted bytes: 00 00 00 00 14 00 00 00 2d 00 00 00
received bytes:    00 00 00 14 00 00 00 2d 00 00 00 00
received data:     0x14000000, 0x2d000000, 0x00000000

In a big endian to little endian scenario, you get the exact same result if you loose 4 bytes:

original data:     0x00000000, 0x00000014, 0x0000002d
transmitted bytes: 00 00 00 00 00 00 00 14 00 00 00 2d
received bytes:    00 00 00 14 00 00 00 2d 00 00 00 00
interpreted data:  0x14000000, 0x2d000000, 0x00000000

Answer 2

I believe this could be because the Raspberry pi is big endian and the arduino is little endian.

Learn about Endianness here!

Answer 3

You may have multiple problem. First of all the structure get align to be efficient on the specific architecture, to avoid those filling you have to tell the compiler to pack the structure. There are different way to pack depending on compiler used.

Then endianess is different, so the byte composing the value has to be swapped.

Finally there may be a desincronization or a bus error. In those case a sync message (normally 2 byte before each transmission) and a CRC are used to fix the issue.