Anaren Air Boosterpack on Stellaris

[CorB 64]

SOLVED !!! See my last post #5

 

 

Hi all,

 

Ive always wanted to try the Stellaris with the Anaren Air Boosterpack. I have a network of MSP430s with the same boosterpacks working for a long time now and adding the Stellaris into this network adds new potential. Luckily Energia now has a default library we can use for this purpose.

 

Ive started by setting all the RFregisters in the config file to make sure that the module will be sending/receiving data using the same RFsettings. Then I started codeing using the WirelessMonitorHub sketch, within a few minutes I had the Stellaris up and running and it was clearly receiving messages. Fantastic !!

 

But ... the messages did not exactly contain the data as expected. The original sketch contains a packetdefinition:

/*struct sPacket

{

  uint8_t from;           // Local node address that message originated from

  uint8_t message[59];    // Local node message [MAX. 59 bytes]

}; */

 

 

My network sends a bit more complex messages around see the definition below the ***** line.  

When I read the incoming data at the Stellaris the data looks shifted a byte or so. Incoming data is stable (I can recognize the individual sensors) and comparable between received transmissions. 

 

Does anybody have an idea where this shift could come from and/or what a good solution might be (without changing everything on the MSP430 side of the network) ?

 

regards

Cor

 

 

****************************************************************************************************************

//status substructure

struct StatusStruct{

  enum TxACKMessageType {                                                       //!< Flags to ACK transfer

    REQUEST_NO_ACK                       = 0,

    REQUEST_ACK                          = 1

  } TxACKMessageType;

 

   enum RxACKMessageType {                                                       //!< Flags to ACK transfer

    RECEIVED_NO_ACK                   = 0,

    RECEIVED_ACK                      = 1

  } RxACKMessageType;

  char channel;

  char power;

  char RSSI;

  int msgNodeId;

}; 

 

// main packetstructure

struct sPacket {    

  char addr; // payloads need to start with char addr as the receiver can check this !

  char msg; // messagetype 0x00 - 0xFF options

  char msgdata0; // var1 that belongs to the message // sensortype

  char msgdata1; // var2 that belongs to the message //secondary data

  StatusStruct Status;

  // USER DESIGNED PAYLOAD SECTION

  unsigned int data1; // maindata

  //unsigned int data2;

  char DataUnit;

        

}; 

 

****************************************************************************************************************

[jkabat 0]

@@CorB

 

The enums may be generating 16-bit variables.  I believe there is a gcc option to limit to 8 bits. Alternatively define them as uint8_t.

Of course I may be totally wrong!

 

Regards

JohnK

[CorB 64]

Hi John,

 

Ive even removed the whole Status structure and replaced it by all uint8_t vars. When I adjusted the structure to this:

 

struct sPacket {    

  uint8_t addr; // payloads need to start with char addr as the receiver can check this !

  uint8_t msg; // messagetype 0x00 - 0xFF options

  uint8_t msgdata0; // var1 that belongs to the message // sensortype

  uint8_t msgdata1; // var2 that belongs to the message //secondary data

 

// these 3 replace the STATUS structure Enums  

  uint8_t ACK1;

  uint8_t ACK2;

  uint8_t ACK3;

  

  uint8_t channel;

  uint8_t power;

  uint8_t RSSI;

  uint8_t msgNodeId1;

  uint8_t msgNodeId2;

 

 

  uint16_t data1; // maindata

  uint8_t DataUnit;

        

}; 

 

The readouts for channel and power are always correct, but everything else doesnt bring anything usefull yet.

 

Cor

[CorB 64]

Hi all,

 

A followup. Ive changed the structure on the stellaris into something simple that represents the same size of my normal structure (18 bytes).

 

struct sPacket {    

  uint8_t buffer[18];

};

 

Using this I can easier inspect if the datapackages arrive intact or not. The result of this test is that the packet arrives as expected, the bytes in the buffer[] array are the same as the bytes that were originally send by the MSP430 RF routines. 

 

So the problem is now easier, its the typecasting of the original structure that seems to give a problem. I will try to see if I can find out what needs to be changed to get it right. Otherwise I will decode the bytes in the buffer[] into the variables I am using.

 

cheers

 

Cor

 

EDIT: one of my vars in the structure is defined as an unsigned INT in the msp430 code, when I try to receive that with a uint16_t on the stellaris the MSB and LSB are swapped when I use serial.print ... 

[CorB 64]

SOLVED  !:

 

The new structure:

 

struct sPacket {    

  uint8_t addr; // payloads need to start with char addr as the receiver can check this !

  uint8_t msg; // messagetype 0x00 - 0xFF options

  uint8_t msgdata0; // var1 that belongs to the message // sensortype

  uint8_t msgdata1; // var2 that belongs to the message //secondary data

  

// ENUM Structure

  uint8_t ACK1;

  uint8_t ACK2;

  uint8_t ACK3;

  uint8_t ACK4;

  

  uint8_t channel;

  uint8_t power;

  uint8_t RSSI;

  uint8_t msgNodeId1;

  uint8_t msgNodeId2;

  

  // USER DESIGNED PAYLOAD SECTION

  uint8_t data1a; // maindata

  uint8_t data1b; // maindata

  uint8_t DataUnit;

        

}; 

 

To construct the original unsigned integer variables msgNodeId and Data1

        msgNodeId = msgNodeId1+ msgNodeId2*256 

        Data1 = data1a + data1b*256;

 

Its a bit unfortunate that the transfer of integers gets mixed up between the two platforms but its not difficult to change that. I havent found a format in the structure to read an integer properly.

 

cheers

 

Cor

Edited November 15, 2013 by CorB

[jkabat 0]

@@CorB,

Here is a useful function;

 

uint16_t swap16(uint16_t val) {
return ((val & 0xFF) << 8)
| ((val >> 8) & 0xFF);
}

 

data2=swap(data1);

 

I make my own include files that conditionally compile based on the endian type of the host. All external items should be little endian. 

 

#ifdef  WE_ARE_BIGENDIAN

#define swap16_external(val)  (((val & 0xFF) << 8) | ((val >> 8) & 0xFF)))
#else

#define swap16_external(val)  (val)

#endif

[CorB 64]

Hi John,

 

Thanks for those defines, but the problem is more fundamental. If I use uint16_t vars instead of 2 uint8_t vars I get garbage. Looks as if the declaration of a uint16_t in a structure doesnt go very well when doing a typecast from a buffer.

 

In the original sketch the typecast looks like this:

if (Radio.receiverOn((unsigned char*)&rxPacket, sizeof(rxPacket), 1000) > 0)

 

cheers

Cor

[jkabat 0]

@@CorB

 

That actually should be OK.

 

You might want to try:

#pragma pack(1)

 ... define your structure here

 

#pragma pack()

 

 

You might be having problems with word alignment. The compiler may force uint16_t to be aligned on a word boundry. 

The pack(1) forces aligment to 1 byte. the pack() restores it to whatever the compiler is using.

 

I have to do this all the time on my x86 stuff.

 

regards

John

[CorB 64]

Hello John,

 

Thats a real good solution, works completely as planned. Ive now changed my vars back to normal. Never had this kind of issue on MSP430. Also havent seen the use of pack() before, gotta study that !

 

Thanks for adding quality to the initial solution,

 

regards

Cor

 

EDIT: found a nice explanation here http://stackoverflow.com/questions/3318410/pragma-pack-effect