FDS_rr004 and 921600 baud

charleyshf

Hi,

I've been playing around with a sensor hooked up to my prop that can send/receive data at rates up to 2.5Mbps for a few weeks now, until today I was using 115,200 baud for testing which worked great without any problems.

Today I changed the baudrate to 921,600 and even though I can transmit to this sensor, and the sensor does receive valid data, the data or text I should say that I receive back to the prop is all garbage, like the baudrate is off. I first verified that this sensor is working properly and hooked it up to my pc and it is fine at this baudrate.

I have been using FullDuplexSerial_rr004 object which allows you to increase the buffer size along with Extended_FDSerial, the Parallax Serial Terminal object and simple code that just sends a command to my sensor and waits for a responce, which the sensor will respond, well until I changed the baudrate today that is.

I have been reading through the forums that at this baudrate the prop can send, however receiving is a different story.

The tx/rx wires are less than 3 inches apart between the prop and my sensor.

I need to be able to run at least 921,600 baud because the sensor also sends video wirelessly, and you cannot have the sensor run at two different speeds, in order to change the baudrate on this sensor you have to change the baudrate then recompile the software and upload it to the sensor.

I'm trying to find a better hardware solution, something like a MAX3232cpe, but I don't think it would handle this baudrate..

Any ideas??

$WMc%

charleyshf wrote: »

Hi,

I've been playing around with a sensor hooked up to my prop that can send/receive data at rates up to 2.5Mbps for a few weeks now, until today I was using 115,200 baud for testing which worked great without any problems.

Today I changed the baudrate to 921,600 and even though I can transmit to this sensor, and the sensor does receive valid data, the data or text I should say that I receive back to the prop is all garbage, like the baudrate is off. I first verified that this sensor is working properly and hooked it up to my pc and it is fine at this baudrate.

I have been using FullDuplexSerial_rr004 object which allows you to increase the buffer size along with Extended_FDSerial, the Parallax Serial Terminal object and simple code that just sends a command to my sensor and waits for a responce, which the sensor will respond, well until I changed the baudrate today that is.

I have been reading through the forums that at this baudrate the prop can send, however receiving is a different story.

The tx/rx wires are less than 3 inches apart between the prop and my sensor.

I need to be able to run at least 921,600 baud because the sensor also sends video wirelessly, and you cannot have the sensor run at two different speeds, in order to change the baudrate on this sensor you have to change the baudrate then recompile the software and upload it to the sensor.

I'm trying to find a better hardware solution, something like a MAX3232cpe, but I don't think it would handle this baudrate..

Any ideas??

'
Theres a lot of things that cause interference when running these higher Baud rates.And I suspect that its interference that is causing you the problems.Most likely the wireless video from the sensor it self.
'
I know this from wireless video that knocks out my WiFi router and dumps the wife and kid off line from the INTERNET every time I use it around the WiFi router.They let me know in a hurry to stop,quit, shut it off.
'
You can try shielding the serial cable.Just ground the shield on one end or the other, Not both ends.---"Dreaded ground loops"
'
Theres a ton of other things that can be wrong, But I would start here.

Timmoore

Try adjusting the baud rate slightly up and down. I have had similar problems in the past and ended up with a baud rate a few % off to make the system work.

Cluso99

I suspect you will find that the problem is in the way the FDX receives data. You may have to split the receiver into its own cog.

Remember, the FDX routine is doing a ping-pong multithread approach to receiving and transmitting.

I thought FDX had run sucessfully at 230400 baud but I have not tried it.

Depending on the pcb, maybe you can overclock the prop to 100-104MHz.

pjv

Hi;

A possible explanation here based only on the assembler portion of the Full Duplex Comms routine which seems to be the common base among all iterations I have looked at.

The FDX assembler routine uses a ping-pong technique to alternate running small pieces of code for both, the RX and TX routines. The idle loop in the receiver consumes 4 instructions, and the idle loop in the transmitter consumes 8 instructions, two of which are hubops with indeterminate timing, so they can each be as long as 2 to 5 regular instructions. So the minimum loop time is 4 (Rx) plus 8+2 (Tx) for 14, or worst case as long as 4 plus 8 plus 8 for 20 instruction equivalents. That means as long as one uSec using an 80 MHz clock.

At a high data rate such as 921600, one bit is just over 1 uSec, so at those speeds the receiver will not reliably detect a start bit, and hence your problem. And as you indicated, the transmitter at that speed will have less problem, but probably a fair bit of jitter.

If you were to run at half that rate, things will surely run much better...... perhaps well enough. If that is not fast enough, you will need to improve the assembler portion of the FDX for better performance. That might be doable if you can sacrifice an I/O pin for signalling.

Holler if you need some more help.

Cheers,

Peter (pjv)

charleyshf

Hello,

@$WMc% - The wireless module is removed, unfortunately it didn't change the receiving issue I am still having with the prop. I also tried different wires as well as even shorter ones (1.5"). The ground was re-done as well.

@Timmoore - I am going to try this today, I think I had read somewhere else in the forums that this idea was able to resolve a receiving issue.

@Cluso99 - I am not that great at programming in spin, still learning, but that might resolve the issue I am having, and it would make sense to use separate cogs for Tx/Rx, and I have extra cogs anyways.. I also have the 6.5MHz crystals, I'll have to try the prop at 100Mhz and see if that helps(not forgetting to change the settings at the top of the objects of course)

@piv - I wish I could just stay at 115,200 because I had everything running pretty stable, unfortunately the sensor I have been working with is a blackfin camera, which does all its own image processing onboard, so the prop is just asking it for results as well as tracking information. What I am trying to do is have my robot be able to be manually controlled as well as have it run on its own, but in either mode I would like to be able to see what it's seeing (hence the high baudrate) Assembler, I am still learning SPIN, I couldn't even imagine learning assembler at this point....


Thank you everyone for your responces, hopefully I can get something going today....

Sapieha

Hi charleyshf.

You need look in Hanno's ViewPort software.
It can run up to 2 MBit serially with his drivers.

charleyshf wrote: »

Hello,

@$WMc% - The wireless module is removed, unfortunately it didn't change the receiving issue I am still having with the prop. I also tried different wires as well as even shorter ones (1.5"). The ground was re-done as well.

@Timmoore - I am going to try this today, I think I had read somewhere else in the forums that this idea was able to resolve a receiving issue.

@Cluso99 - I am not that great at programming in spin, still learning, but that might resolve the issue I am having, and it would make sense to use separate cogs for Tx/Rx, and I have extra cogs anyways.. I also have the 6.5MHz crystals, I'll have to try the prop at 100Mhz and see if that helps(not forgetting to change the settings at the top of the objects of course)

@piv - I wish I could just stay at 115,200 because I had everything running pretty stable, unfortunately the sensor I have been working with is a blackfin camera, which does all its own image processing onboard, so the prop is just asking it for results as well as tracking information. What I am trying to do is have my robot be able to be manually controlled as well as have it run on its own, but in either mode I would like to be able to see what it's seeing (hence the high baudrate) Assembler, I am still learning SPIN, I couldn't even imagine learning assembler at this point....


Thank you everyone for your responces, hopefully I can get something going today....

Peter Jakacki

There's a problem with FDX as well in the start bit timing in that the it does not compensate for overheads which although minor at low baud rates become a problem at the higher baud rates in that the start bit does not have the same timing as the data bits. This causes the PC's receiver to sample near the edge of the data bit leading to errors.

Also the sample timing on the receive side of FDX has a similar problem although the start bit from the PC is fine the trouble is that by the time the start bit is detected it may well be into the start bit and once again the receive samples end up too close to the edge of a data bit instead of at the center leading to reception errors.

There is also no way that the start bit can be properly synchronized while FDX is doing it's ping-pong multitasking between transmit and receive in the one cog. Either you receive or transmit but not both at the same time or else you dedicate a cog to reception.

I have a fast serial object that can replace FDX and this one uses self-modifying code to set the best mode of operation for the code etc depending upon your requirements. If you ask the object to receive at 2M baud then it will but you can't transmit and receive at the same time. You can force into high-speed full-duplex mode but then it automatically uses 2 cogs instead of one. Timing is accurate and has been tested to just over 2M baud.

This serial object is actually part of my UNICOM object of which I just need to spend some quality time on (or any) to test and release. In the meantime I can see no reason why I can't get this fast serial object out but I will wait until the morning (here) to trim it and document it.

charleyshf

Thanks, I am currently trying to get it to work, unfortunately I am getting the same results, however I haven't used viewport in a long time, so I am probably missing something...

Sapieha wrote: »

Hi charleyshf.

You need look in Hanno's ViewPort software.
It can run up to 2 MBit serially with his drivers.

charleyshf

I understand what you mean with FDX, and that would be great if you could post your fast serial object, i've been stuck on this since yesterday when I changed the baudrate to 921,600 on my sensor and right now I have to set my sensor back down to 115,200 baud so I can continue programming/testing.

Peter Jakacki wrote: »

There's a problem with FDX as well in the start bit timing in that the it does not compensate for overheads which although minor at low baud rates become a problem at the higher baud rates in that the start bit does not have the same timing as the data bits. This causes the PC's receiver to sample near the edge of the data bit leading to errors.

Also the sample timing on the receive side of FDX has a similar problem although the start bit from the PC is fine the trouble is that by the time the start bit is detected it may well be into the start bit and once again the receive samples end up too close to the edge of a data bit instead of at the center leading to reception errors.

There is also no way that the start bit can be properly synchronized while FDX is doing it's ping-pong multitasking between transmit and receive in the one cog. Either you receive or transmit but not both at the same time or else you dedicate a cog to reception.

I have a fast serial object that can replace FDX and this one uses self-modifying code to set the best mode of operation for the code etc depending upon your requirements. If you ask the object to receive at 2M baud then it will but you can't transmit and receive at the same time. You can force into high-speed full-duplex mode but then it automatically uses 2 cogs instead of one. Timing is accurate and has been tested to just over 2M baud.

This serial object is actually part of my UNICOM object of which I just need to spend some quality time on (or any) to test and release. In the meantime I can see no reason why I can't get this fast serial object out but I will wait until the morning (here) to trim it and document it.

Jack Buffington

charleyshf wrote: »

unfortunately the sensor I have been working with is a blackfin camera, which does all its own image processing onboard, so the prop is just asking it for results as well as tracking information.

Are you using the Surveyor SRV-1 camera? How is that to work with? Is the learning curve steep? I'm pretty interested in embedded vision system stuff so a board like that would be useful.

charleyshf

I think it's a really good sensor, other than trying to get it running with a prop that is..

I would say that it's a moderate learning curve..

Jack Buffington wrote: »

Are you using the Surveyor SRV-1 camera? How is that to work with? Is the learning curve steep? I'm pretty interested in embedded vision system stuff so a board like that would be useful.

pjv

Charleyshf;

I don't know what you mean by "I'm trying to get it to work"........ the FDX routines simply will NOT work at 921600.

As I had stated earlier, perhaps they may work at half that speed (460800), and probably will at a quarter speed (230400). The top speed you would like is out.

If you have a spare I/O pin available, the code could be modified to work at that speed.

Cheers,

Peter (pjv)

charleyshf

Just wanted to post an update as this is has me very curious...

I decided to try a baudrate of 230,400, well I started with the same issue. So I put in a 6.25MHz crystal changed my settings, got the same result, I can transmit at this rate, just can't receive anything.

SO....

I started changing the baudrate setting and went from 230_400 to 236_400..

It's working, in fact working very well, I have it in an endless loop with the sensor and it's been over half an hour, and so far, no problems....

I'm wondering if I should go back to the 5MHz crystal and see if it still works???

charleyshf

Actually I talked with Hanno today, the conduit object(which is the one that allows up to 2Mbps speeds) in Viewport is designed to for pc-propeller comms, it doesn't support prop-device comms.

Sapieha wrote: »

Hi charleyshf.

You need look in Hanno's ViewPort software.
It can run up to 2 MBit serially with his drivers.

John Abshier

I communications is half duplex, go to the Object Exchange and search for Dynamixel. These servos use half duplex communications at 1,000,000 baud.

John Abshier