28 replies to this topic

[Pip]

Yes the modem I've done does have RTS/CTS lines for letting connected hardware know when the data bufferes fill up, but the op main board does not have these hardware handshaking lines - unless you give up a couple of the spare ADC lines on the OP main board and use them as RTS/CTS lines.

[osnwt]

Worse is that CTS is used as receiver input (unless you use Spektrum satellite), and RTS is used for Power sensor.

[Dr. Baldrick]

Hi Pip (and others),

I am new here and planning on getting involved, I just getting up to speed so sorry if I am repeating something that has been said in other threads that I have not fully read yet..

I have been doing a fair bit of mucking around with the Digi (formally MaxStream) 9XTend Modems. I have been using these up to now on my UAV projects mainly due to their stated range. However one frustrating thing that I have found with these is that it is near impossible to get the stated data rates out of the modems in a duplex scenario. This is due to the fact that the 9600 baud or 115200 baud is the RF SIMPLEX transmission rate. What this means is that if you would like to do duplex transmission, then you have to run at a much lower rate to avoid RF collisions. From my testing I was only able to get a reliable (95% transmission successful) data link when backed off to about 10kbps in each direction. Any higher than that then you end up having RF collisions and dropped packets resulting is a much lower actual throughput.

Have you had any experience with this and does your radio address this issue?

On another note, I have spent a bit of time developing a telemetry protocol between a ground station and a UAV. There are two features that I have found nice to have and if implemented correctly it would make sense for these to be implemented in the radio rather than the ground station software.

1 - Priority queues to allow critical data such as controls and last known GPS coordinate to be prioritized over general telemetry and large uploads such as a new flight plan.

2 - High speed queues with the ability to discard old data. Say you have an telemetry frame that contains some generic vehicle information such as the temperature of all the batteries, ESCs and Motors (for example). If your telemetry link is running slow and you have one of these update packets on the queue to send and then another temperature update packet is ready to send, you really want to discard the first rather than having them both queued. This is a strategy I use to deal with link fade and recovery more gracefully. You can still have the full history transmitted if you need it by keeping it queued on a low priority telemetry queue but the high priority real time data needs a update and discard last capability.

Anyway, that is my initial thoughts.. If there is anyway I can get involved with the development of RF modem I would be very interested and I have some experience in this area.

Cheers,

Paul

[peabody124]

I'm sure Pip will answer this too, but this is one thing we've discussed regarding making the modem UAVTalk aware. I was leaning towards making the modem inform the main board when the buffer was backing up so it can throttle and only send critical. Sounds like you're a vote in favor of it being done on the modem (I think how Pip is leaning).

But the short answer is this will be a feature, but it will only benefit UAV's using UAVtalk and or OpenPilot (depending where throttling occurs), although since the firmware will be open you can modify it

[dankers]

peabody124, on 04 October 2010 - 05:41 AM, said:

I'm sure Pip will answer this too, but this is one thing we've discussed regarding making the modem UAVTalk aware. I was leaning towards making the modem inform the main board when the buffer was backing up so it can throttle and only send critical. Sounds like you're a vote in favor of it being done on the modem (I think how Pip is leaning).

Kinda but not exactly like BECN from frame relay...

[Pip]

Yes Paul, everything you mentioned is being worked on.

Dankers has been in charge of who gets the dev boards to work on, he's bought & paid for them all by himself so it's in his hands really (rightly so) who gets what development boards really.

The RF chips have limited feedback as to the channel being in use but I am implementing anti-collision as best as possible (listen before transmit and random transmit delay periods).

I have the modems transfering packets between each other now and replying, it's not finished yet as I need to process retry handling, comms with the main board/PC, frequency hopping (the awkard one), modem configuration setting etc. We'll get there though in time.

[Dr. Baldrick]

Hi Pip,

Thanks for the prompt reply, if there is anything I can do to assist then please let me know. I am keen to try something apart from the 9XTend and it will be good to have a radio out there that has the possibility for the firmware to be tweaked.

If you don't mind me asking, what is the general architecture of the design? Are you using a CPU coupled directly to an off the shelf RF chip? If so which RF chip is this based on? If not, then are you using FPGA to drive a DAC/ADC etc?

I love playing with this stuff, good to see some open source development going on with it.

Cheers,

Paul

[Bani Greyling]

Dr. Baldrick, on 04 October 2010 - 04:04 AM, said:

... This is due to the fact that the 9600 baud or 115200 baud is the RF SIMPLEX transmission rate. ...

If I can chip in here, I know WiMAX use a timeslice/scheduling methodology to prevent/minimise collisions.... to quote from wikipedia "WiMAX uses a QoS mechanism based on connections between the base station and the user device. Each connection is based on specific scheduling algorithms."

So maybe if you do scheduling, you can still run at 115200 baud...? (or do asymmetric time-slice allocation to have more download bandwidth)

...but you guys know more about this than I do....

[Dr. Baldrick]

Yeah, I tried to implement a time slice method in the protocol layer on the 9XTend, but it turned out that there was a variable latency between the packets entering the serial port and the actual transmission. This meant that it was near impossible to have them time synchronized at RF unless you leave a very large guard band which makes performance terrible.

So I am suggesting that for duplex transmission, that the new modem should take care of the duplex issue closer to the RF layer. This could be done with time slicing, or different hopping codes depending on the capabilities of the RF chipset.