Blogs

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 check_code.py 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.