It is horribly impractical, but works with enough glue.

No idea what motivated this, but once you get obsessed with a communication problem, nothing can stop you.  It might be the hope of getting very long range or the desire of unemployed programmers to remember they can still write programs.

Wifi isn't really wireless because the range is useless. The phone company is worthless because it's extremely expensive.  Everyone dreams of running PPP on a private, long range serial port radio that can reach for miles.

A serial port radio like the XBee, 3DRRadio, or CC1101 can potentially give real wireless range, but has issues. IP requires full duplex asynchronous communication. Hook up your PPP connection directly to a 3DRRadio & it won't go anywhere.  Without constant rebroadcasting & just relying on TDM for full duplex, it goes nowhere.  The packet loss is too high & TDM gets completely jammed.

The best results from serial port radios have come from filling the entire bandwidth at the highest bitrate with repeated packets & hoping some data makes it through.  The fastest full duplex has come from constantly broadcasting beacons & waiting for replies, regardless of data usage.  To improve matters, the download packet size is 5x bigger than the upload packet size.

It's not an efficient algorithm & it doesn't reach the theoretical maximum bandwidth, but it's practical.  The algorithm would ideally be on the radio module instead of the host computer, but having it on the host allows the radio modules to be interchanged.

The idea is to have a sliding window of packets constantly rebroadcasting until they all get ACKs.  Ideally, the error checking is done on the radio module, so the entire packet doesn't need to be sent over the serial port before sending an ACK.

The bandwidth is too low to have the ideal header.  A 1 byte sequence number needs to make due instead of the 4 byte sequence number in TCP.  Having only 1 byte for the sequence number makes it ugly.  A single error will throw off the sequence numbers & lock it up.  The windowing algorithm is horrible & kludgy, but works.

The CRC checking on the stock 3DRRadio firmware was not effective.  Even with forward error correction,  a lot of errors got through.  So you had to wait for the entire packet to transfer over the serial port before doing your own CRC calculation & sending the ACK.  The xbee had effective error checking on the module, which made it faster.

Without ECC, at 230400 baud, the 3DRRadio downloaded 2kbytes/sec. With ECC, it was under 1000 bytes/sec.  The TDM algorithm & the frequency hopping slowed it way down.

The xbee at 115200 did 3.5kbytes/sec.  It was a series 1 XBee with 100mW power but only 115200 bits/sec.

Both modules seemed to have the same range.  They were well beyond wifi range, even with crummy wire antennas.  The 3DRRadio seemed to gradually lower in bandwidth with increasing distance, while the XBee was all or nothing.

If the 3DRRadio had a way to replicate the XBee without any frequency hopping or TDM, it would scream.  It would probably hit 7kbytes/sec.  Thus began the SiK firmware hacking.

Comment out most of tdm.c, most of packet.c, disable the broken script & you can get the fastest 2 way communication out of it.  A bit more hacking & it did effective CRC rejection before sending on the serial port. The CRC encoding was still done on the host. It also properly framed the full duplex packets.  The firmware CRC rejection got it another 300 bytes/sec on the upload speed.

That got 6700bytes/sec download speed & 1400 bytes/sec upload speed, 3x faster than the stock firmware.  It could actually load some web pages, with enough patience.

Would say even in its intended application as a telemetry radio, it could do better by saturating the bandwidth with repeats.

Some testing after all that development was pretty disappointing.  The urban apartment complex range was 150ft.  It was much farther than wifi, but so slow using it to load any web pages was barely survivable.  It would be useful with the ancient email client Pine or a phone app, but the modern web based gmail was hopelessly slow.

The better option is still a waveguide antenna on a standard wifi router.  The wifi standards have just been optimized to get the most TCP/IP performance out of the available power.

Views: 2714

Comment by Joshua Johnson on November 18, 2013 at 12:49am

Great post Jack!  You amaze me with your intelligence on Drones and Tech related issues!!!!  Keep up the good work pal and keep sharing your projects with us please.  I miss seeing your amazing blogs as frequent as you used to post them.  

Wish I still had Admin or Moderator privileges so I could fix your blog for you so the photo or video shows first.  I am a perfection Nazi and notice spelling errors and such on official pages and documents all the time but can't fix em anymore! :(

Have a great night/morning Jack!,

Joshua Johnson

Comment by Joshua Johnson on November 18, 2013 at 12:52am

I'll scan through the Diy Drones Universe and see if I can find anyone with high enough Jedi ranking to fix the blog for you!  My Jedi mindtricks are of no use here anymore. LOL

Comment by Meez on November 18, 2013 at 3:35am

really awesome and you really know what you're doing. Keep it up and sure i want to see more.

Comment by Roberto Navoni on November 18, 2013 at 4:28am

Hi Jack , that's good application , on NuttX is possible to do that using SLIP protocol . I work a lot on PPP protocol in the past. I also does some study about M-PPP , it's a special protocol that you can use with multi radio module so you can have batter bandwith .



Comment by Andrew Tridgell on November 18, 2013 at 2:31pm

Hi Jack,

I'd be interested in discussing your results in a bit more detail if you have the time. I've also been using 3DR radios for internet style streaming (specifically, downloading images) and I've got quite different results from you. I run the radios at the default air rate of 64kbps and get better than 70% of the theoretical efficiency.

For transferring images I use a protocol called Using block_xmit copes with packet loss a lot better than any of the congestion control algorithms that I've tried with TCP. If you look at you'll see the default transport is UDP, but I also use it to transmit packets over MAVLink via the cuav camera code.

My aim was for reliable mixed image+telemetry transfer over telemetry radios over long distances (10s of kilometers), so I wasn't specifically aiming for maximum speed, but I'm a bit surprised that our results don't match up better.

Did you modify the register tables in radio.c at all? You mentioned you were running at 230400, but that isn't one of the supported rates in the register tables in SiK. It does support 250, but I've found transfers to be very unreliable at that speed. It does much better at 192. If you want good range then you really need to run it at 64kbps or below. For really long range I use 19kbps. The receive sensitivity of the radios varies greatly with data rate (as it does for all radios of this type).

It would also be great if you could expand a bit in some of your other comments. What sort of breakage did you find in (that script just aims to work around the lack of pointer type checking in sdcc). When you say that TDM and frequency hopping "slowed it down" are you referring to CPU cycles, or impact on the modulation and radio mode changes?

Perhaps you'd like to do a G+ hangout together sometime to chat about ways to improve SiK?

Cheers, Tridge

Comment by davidbuzz on November 18, 2013 at 11:00pm

Jack, I'd like to see your hacked SiK code.  :-)

Comment by Jack Crossfire on November 19, 2013 at 4:52pm

The 3drradios & Xbees are limited by the need to buffer a complete packet before sending or receiving on the UART. If they could directly connect the UART to the modulation, they could pack in a lot more data.


You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service