Serial comm not as reliable as PC port.

sccoupe

I am having trouble trying to get reliable serial reception with the propeller but having problems. I have a box sending out about 20 bytes at 9600 baud after it received a "D". I am at this point just printing this using TV term. It works, but only 80 90 percent of the time. I send out a "D" and get the data back at about 10 times a second. Its likely noise or timing, but I cannot nail it down and need advice. If I attach the receive line from the breadboard to a PC at the same time, the PC gets the right info every time, nice and consistant without the need to retry if certain characters are not received. The prop(and basic stamp, and pic processor) only seem to work about 80-90% of the time. What are the likely things to check. 9600 baud is pretty slow and should be easy to deal with.

Thanks

Jason

Mike Green

The things to check are the ones you've mentioned, the timing and the presence of noise spikes. Both are things you should see on an oscilloscope. You may get some hints if you look at the data sent (and seen by the PC) and compare that to the individual bit strings seen by the Prop or Stamp or PIC.

I think TV-Term uses FullDuplexSerial for its serial I/O. This uses a fairly simple algorithm for start bit detection, so it could be easily thrown off by noise spikes.

sccoupe

Thanks Mike. So, if I look at this from a noise spike perspective, the PC likely handles noise much better than the Prop? Also, is there a better object to use then the Fullduplexserial based on reliability? Can pullup or pulldown resistors on the rx line help or is the signal supposed to keep this in line? I'll put this on the o'scope tonight and take a look for noise.

Jason

Mike Green

It depends on the kind of serial port you're using. Some UARTs (Universal Asynchronous Receiver Transmitter) sample the serial line several times and require that they get a low level each time before they call it a Start bit. FullDuplexSerial and most serial I/O software just looks for the first high to low transition and times everything from that edge. I'm not aware of any Prop object that does anything different.

Clock Loop

While doing serial output from the prop, I had trouble with getting good signals, and high speeds, due to no pull down resistors on both tx/rx. I used 10k. (my blackbox schematic shows the serial connections between props, and they show one set of 10k pull down resistors per communication channel.)

http://forums.parallax.com/showthread.php?115258-TheBlackBox-Release-v2.0-Propeller-HSS-FX-Sequencer-with-Digital-Audio-SPDIF

Ariba

I think the problem is that your box sends 20 bytes, but the FullDuplexSerial has only a 16 byte receive buffer, so depending on the time it needs to display the data, sometimes it works , sometimes not.
If the TV_Terminal object is meant with "TV_Term" then replace it with TV_Text, which should be faster.
Then I would also use another Serial object with a bigger buffer, for example the attached Serial_Conf.

Andy

localroger

I second Ariba. When receiving a packet you need a buffer at least as large as the packet. There is a version of fds in the obex which allows you to specify the size of the buffers in a CON statement. I have used fds (manually modified for buffer size) for stuff like this for months at a time with great reliability. I seriously doubt it is either the timing or the hardware. It's just that, if you don't poll the buffer quickly enough, it gets overrun and you miss part of the packet.

Cluso99

sccoupe: I would like to see a schematic or photo in case we can recognise something.

In case you are losing characters in the fifo, try my FullDuplexSerial_RRxxx in the OBEX and change the buffer size to say 32 (must be power of 2 and 256 is the max). This is compatible with FullDuplexSerial.

sccoupe

Ill give one of these other objects a shot this evening and see what happens. I did try some things with the BS2 last night. Just grabbing the string and sending it to debug. The data looks something like this, " xxxx xxxx xxxx xxxx". There is more on the end of that but I just ognore the rest. I was waiting to see the first 3 spaces and then grabbing 20 bytes. I changed it to wait for only one space and it works more often, but skews the debug output, though it all still looks correct. If I just grab it all without waiting for a space, when it messes up, I get a wierd character, and its always the same. So it either looks right when it works correctly or messes up the first couple of bytes in the string the same way every time it messes up. I checked for noise on the scope and didnt see any. I also tried pullup and pulldown resistors with no success. This seems more like timing of the first byte?