Home/Support/Support Forum/payload changes when sending uint8_t of value 17 or 19

payload changes when sending uint8_t of value 17 or 19

0 votes
Below is a snippet of code. I'm using a simple uint8_t to hold a 'counter', so I can visualize every frame on the receiving end (Coordinator). I increment a 'counter' value from 0 to 100, then back to 0 to send as part of my payload for reading on the far end. Everything works as expected until I send a value of '17' or '19', all other values between 0-99 generate expected results. I've pasted the received frames below the sample code. My issue is, as you might guess, what's going on when I send '17' or '19' in this packet and why does it cause the change in payload characteristics?

Thanks for any help! Here's the details...


--- variable declarations ---

uint8_t counter; //this holds int values 0-100 and is initialized to '0' during setup

--- next snippet of code is executed repeatedly in main loop ---

case DHT_ERROR_NONE:

Serial.print("Heres temp as an Int: ");
Serial.println(myDHT22.getTemperatureCInt());

byte hiBite;
hiBite = highByte(myDHT22.getTemperatureCInt());
// Serial.println(hiBite);
byte loBite;
// loBite = lowByte(myDHT22.getTemperatureCInt());
Serial.println(loBite);

payload[0] = hiBite;
payload[1] = loBite;
payload[2] = counter;

zbTx = ZBTxRequest(addr64, payload, sizeof(payload));

xmt();

counter = counter + 1;
if (counter > 99) counter = 0;

Serial.println(payload[2]);

break;

--- outside of 'case' I call the send function of the xbee object

void xmt(void)
{
xbee.send(zbTx);
}

// sample of GOOD frame received by API coordinator (when receiving a an integer 0-16, 18, and 20-99)
payload [0] is 126
payload [1] is 0
payload [2] is 125
payload [3] is 49
payload [4] is 16
payload [5] is 1
payload [6] is 0
payload [7] is 0
payload [8] is 0
payload [9] is 0
payload [10] is 0
payload [11] is 0
payload [12] is 0
payload [13] is 0
payload [14] is 255
payload [15] is 254
payload [16] is 0
payload [17] is 0
payload [18] is 0 <-- payload[0] = hiBite;
payload [19] is 237 <-- payload[1] = loBite;
payload [20] is 18 <-- payload[2] = counter;
payload [21] is 242

// sample of Weird frame received by API coordinator (when receiving an integer 17 or 19)
payload [0] is 126
payload [1] is 0
payload [2] is 125
payload [3] is 49
payload [4] is 16
payload [5] is 1
payload [6] is 0
payload [7] is 0
payload [8] is 0
payload [9] is 0
payload [10] is 0
payload [11] is 0
payload [12] is 0
payload [13] is 0
payload [14] is 255
payload [15] is 254
payload [16] is 0
payload [17] is 0
payload [18] is 0 <-- payload[0] = hiBite;
payload [19] is 237 <-- payload[1] = loBite;
payload [20] is 125 <-- payload[2] = counter; //this should be a value of '17',
payload [21] is 51 <-- this 21st element shouldn't exist, and the frame grows from 21 members to 22 whenever the value 17 or 19 is sent as the "payload[2] = counter;"
payload [22] is 241
asked Mar 17, 2014 in RF Solutions and XBee by concyse New to the Community (0 points)

Please log in or register to answer this question.

1 Answer

0 votes
The obvious first thought is a issue with Xon and Xoff as those two values are used for Xon and Xoff. API mode two is seldom really needed, probably less than 1% of all situation need API mode 2. Just remember that if you do use API mode 2 that you must escape your characters properly. Simpler to just use API mode 1....
answered Mar 24, 2014 by MikeN Community Contributor (87 points)
Your support is awesome!  Thanks - I appreciate the help, and it was spot-on.
...