Wifly Hex Commands?

I m sending integers over a wifly module where the integers are split into individual bytes. So if you are using the match command 0xd to flush the buffer i wouldnt recommended to send ints as bytes because eventually one of your bytes will undesirably issue a flush command. So i have disabled this feature of flushing on 0xd command (set comm match 0)

However are there other wifly hex commands that I should be aware of when sending ints as bytes? Sometimes the data I send over wifly gets fragmented and I m trying to narrow down the problem. I actually have the wifly at a baud rate of 115200. For a 16Mhz crystal there appears to be an error rate of 3.7% so maybe this is the cause of my problem. I have experimented with flow control eg changing flush size and flush timer but still getting fragmented data. I still have to experiment with the baud though.

So are there any hex commands that can cause issues if your sending ints as bytes other than 0xd?

romarshmallow:
I m sending integers over a wifly module where the integers are split into individual bytes. So if you are using the match command 0xd to flush the buffer i wouldnt recommended to send ints as bytes because eventually one of your bytes will undesirably issue a flush command. So i have disabled this feature of flushing on 0xd command (set comm match 0)

If you are sending binary data over a comm link that expects imbedded control characters (0x00..0x1F,0x80..0xFF) you need to 'escape' all control codes. Have you ever seen a HTML address with %20 imbedded in the link? Those three character (%20) represent a 'space' character (0x20). Both sides of the link should have the logic to replace control characters with their escaped equivalent. And convert the escaped equivalent back to the control characters.

If you do this escaped route, remember to handle the case of a your 'escape' character used as a normal character. Example:
"Women make up 54% of the US population." would need to be 'escaped' to
"Women make up 54%% of the US population."

in the Sending code, the single '%' is converted to the double '%%', which is converted back to a single '%' inside the receiver code.

romarshmallow:
Sometimes the data I send over wifly gets fragmented and I m trying to narrow down the problem. I actually have the wifly at a baud rate of 115200. For a 16Mhz crystal there appears to be an error rate of 3.7% so maybe this is the cause of my problem. I have experimented with flow control eg changing flush size and flush timer but still getting fragmented data. I still have to experiment with the baud though.

So are there any hex commands that can cause issues if your sending ints as bytes other than 0xd?

This sounds like a data overrun problem. You probably need to implement some sort of handshaking. Does your WIFI module have a buzy/Ready pin?

Depending on which Arduino you use, the Serial RX/TX buffers can be from 16 bytes to 64 bytes. if your 'blocks' of data are bigger and you cannot process them fast enough you will loose bytes.

Chuck.


Check out my Kickstarter Project Memory Panes an expansion RAM Shield for Mega2560's. It adds 1MB of RAM for those projects where 8KB is not enough.

I m hoping that control characters/codes are only registered once the wifly is in command mode. The problem only came about when i configured the wifly to detect 0xd for flushing (eg set comm match 0xd). So I m hoping that I dont have to go into the level of detail that you talked about.

Depending on which Arduino you use, the Serial RX/TX buffers can be from 16 bytes to 64 bytes. if your 'blocks' of data are bigger and you cannot process them fast enough you will loose bytes.

Do you know if I can keep writing to the serial line going beyound buffer size without having to flush so long as my baud rate is low enough? ie I assume arduino auto flushes once buffer is filled.

romarshmallow:
Do you know if I can keep writing to the serial line going beyound buffer size without having to flush so long as my baud rate is low enough? ie I assume arduino auto flushes once buffer is filled.

When you Serial.print("xx"); the Serial Library adds the data to the output buffer. If the buffer does not have enough space for all of the data, the call waits for the hardware to send out enough data to clear space in the buffer. It then adds the new data to the TX buffer and returns. Serial.print() will not loose any data. It will transmit everything you send it.
BUT, if the receiver cannot accept it at full speed, the receiver will loose data by ignoring it. If you are loosing TX data then the culprit is Receiver(WIFI). If this is the case, then you need to either implement a flow control (CTS/RTS) or space out your TX data to slow the average through put to something the WIFI can handle.

Serial.flush(); just hangs until all of the TX data has been sent out by the hardware. When Serial.flush() returns, all data has been transmitted. You do not normally need to call Serial.flush(), I only use it during RS485 operations on a simplex bus. RS485 is a serial protocol that shares a two wire bus between up to 32 transceivers.
A standard transmission sequence for RS485 is:

  • Is the RS485 bus clear(no one transmitting)
  • Switch to TX mode
  • Start sending data thru Serial.print()
  • call Serial.flush(), wait for all data to be sent out
  • Switch back to RX mode, listen for new cmds

Chuck.


Check out my Kickstarter Project Memory Panes an expansion RAM Shield for Mega2560's. It adds 1MB of RAM for those projects where 8KB is not enough.

So after spending a bit of time at this I think i v got it sorted. Firstly, sending integers as bytes shouldnt cause any problems with bytes clashing with wifly commands. Most commands on the wifly will only work once the device is in command mode. So configuring the wifly to recognise 0xd (set comm match 0xd) seems to be the only exception. Which can be switched off anyway(set comm match 0).

So I was playing around with varying the flush timer and flush size. When flush timer is off or 0, because the wifly buffer has to fill before it can be flushed its likely that the data you are adding to the buffer will overflow. the overflow data or data that exceeds the size of the buffer ends up getting put into the refreshed/empty buffer. So you have to wait again until the buffer fills up. So without having a flush timer that gets rid of overflow its difficult to manage efficient data flow.

So the problem I dont think had to do with the serial communication but I lowered the baud anyway from 115200 to 38400. The data seems to be quite reliable now.

My settings are

• Baud - 38400, (115200 baud has error rate @3.7% for 16Mhz crystal, 38400 baud has error rate of 0.2% for 16Mhz crystal)
• flush size - 1446, (max >1460 may cause data loss)
• flush time - 1000, (reduces buffer overflow if buffer doesnt get flushed.)