Baffling pcFullDuplexSerial4FC problem

Jay Kickliter

I've been using pcFullDuplexSerial4FC exclusively in all my projects requiring serial. I ran across a problem, but I can figure out if it is my code or a serial problem.

There's the code:

pub receiveLoop | char
  uarts.str(DEBUG_PORT, string("Entering XBee receive loop", 13))
  repeat
    uarts.tx(DEBUG_PORT, uarts.rx(XBEE_PORT))  

Simple enough, just a test to see if the XBee is sending serial to the Prop. The XBee is sending the data to the Prop at 115 kbps, but only about 18 bytes a second.

I verified that the send and receive XBee's are set up correctly by taking the receive module off the proto board and plugging directly to the computer's serial port, and every packet came in as it should:

7e 00 7d 31 90 00 7d 33 a2 00 40 4b 22 77 ff fe 01 48 65 6c 6c 6f a4
7e 00 7d 31 90 00 7d 33 a2 00 40 4b 22 77 ff fe 01 48 65 6c 6c 6f a4
7e 00 7d 31 90 00 7d 33 a2 00 40 4b 22 77 ff fe 01 48 65 6c 6c 6f a4
7e 00 7d 31 90 00 7d 33 a2 00 40 4b 22 77 ff fe 01 48 65 6c 6c 6f a4

But, when I ran the above code, and echoed the data that the Prop received, it had a lot if irregularities, but obviuosly some repeating characters:

7e 00 fc b8 c8 80 be 26 34 10 b0 94 d2 d7 fe 01 48 65 e4 a6 a7 96
7e 00 fc b8 c8 80 be 99 d1 80 90 29 a4 d7 fe 01 48 65 6c 34 af 96
7e 00 fe 98 c8 80 be 26 34 20 b8 94 f2 d7 fe 01 48 65 6c 76 bf 96

If I was getting complete garbage, I wouldn't be suprised, since I mess up like than all the time, but this time some byes repeat and some don't.

Any suggestions?

tellurian

Hmmm, that's not a lot of info to go on. It seems that the Prop cannot keep up to 115kbps. Is it running at 80Mhz? What else is that cog doing (how many ports ... speeds)? 18 bytes at 115 kbps will all come in at ~ 1.56 mS it may be that you are overflowing the receive buffer which is 16 bytes. There are quite a few instructions involved with RXing and TXing, TXing in particular was identified as a bit slower. Can you insert some small delays between bytes at the source of the data? What happens if you slow down to say 19200 baud? Do you have to run at 115kbps?

... no help at all, but it looks like the Prop just can't keep up. I almost never us 115 kbps as I find it can be flaky on many embedded platforms, especially if bit banging the serial ports.

tellurian

Jay Kickliter

Are you saying that the receive routine can receive individual bytes at 115 k, but not continuously? I could see the buffer overflowing if I didn't empty it fast enough. But for testing purposes I'm sending very little data, and it is messing up after just the seconds byte.

Yes, running at 80 MHz. I really need to keep if as fast as possible to reduce latency. Throughput is going to be small, but end to end byte times must be low as possible.

Come to think about, I've send data faster than this before with a hard-wired serial line, and didn't have any problem. Puzzling.

Mike Green

It may be a timing discrepancy. If either the transmitter's clock or the receiver's clock is off too much, you can get bit errors, particularly in the high order bits of the data which come just before the stop bit. I haven't had problems with pcFullDuplexSerial4FC, but I haven't used it at the higher speeds. Have you tried a PM to the author?

Leon

It's counter-intuitive, but baud rate differences are more critical with slow baud rates.

Leon

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle

tellurian

Jay Kickliter said...
Are you saying that the receive routine can receive individual bytes at 115 k, but not continuously? I could see the buffer overflowing if I didn't empty it fast enough. But for testing purposes I'm sending very little data, and it is messing up after just the seconds byte.

Yes, running at 80 MHz. I really need to keep if as fast as possible to reduce latency. Throughput is going to be small, but end to end byte times must be low as possible.

Come to think about, I've send data faster than this before with a hard-wired serial line, and didn't have any problem. Puzzling.

Mike G. could be right about the timing. I was wondering about a delay between bytes to encourage sync-up, not because the prop can't receive a stream of bytes at 115k (i.e. a delay in lieu of 2 stop bits). But the XBee docs say that it will not output data serially until the input rf stream is idle ... dunno how big its buffer is but it will blast it all out in one go ... therefore a 16 byte buffer may be too small of the rf packet payload is more that 16 bytes , and an inter-byte delay would be of no use. But given your simple test program and the results I would go with Mike's view. Do you have any equipment (a scope?) that could let you look at the serial stream and determine if the clock rates are off? Have you tried slowing down the baud rate to 56700 or 38400 (or even 19200) just to see if it works at a slower speed?

Jay Kickliter

You guys were right, slowing down to 56k fixed it. If I can get ahold of an oscope I'll check if it is a timing problem.

CannibalRobotics

Jay,
If you need the speed you could try to expand the 16 byte I/O buffers to 32 bytes? Your data packages are 23 bytes long so you might be blowing out the buffer. As I remember, it's a circular buffer and if your not clearing new data out fast enough it can overwrite. I don't see that pattern in your data though.
Jim-

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When your problem seems insurmountable, read the forum for a while.
Solve someone else's problems and yours won't seem so bad.