I've stayed home sick today. My throat seems to be tearing itself apart from the inside out... never fun.

I'm not on top of my mental game, so I wrote some quick code that I intend to throw away now that I've logged its results.

The first thing I decided to to was the look at the latency of a round trip packet. That is, sending it the receiver, and waiting for the receiver to send it back. This is the way the serial emulator is going to work, with this back and forth communication, so I figured that's how I would log the numbers.

Here's a graph of the latency and throughput for all the radio's speed modes

And purely for curiosity's sake, here's the same graph in a stacked format

To be frank these are the results I was expecting, but not the results I was hoping for. It seems after 10k, the throughput of the radio falls largely under the margin of error. Either that, or there's some sort of bottleneck on one of the devices... but these are what I'm going to have to use, so I'll just have to live with it.

Also it's worth noting that the speed if the connections do NOT compensate for the latency in any way. I wanted to keep them as-is, because if I plug in the devices to my computers and send some data, what you see should be what is recorded on these graphs.

So unfortunately it doesn't even look like we could break into the kB/s range... hell we didn't even break 200 B/s... but from the beginning I always knew this was going to be nowhere near fast. Hell I wouldn't even call a data link of this speed "slow" you could use some more exciting words like "glacial".

But I'm not discouraged, I still think that this is a really cool project and I'm certainly going to continue with it, I had considered all this before I even started knowing that these numbers would probably be what I was seeing.

I also logged some data on how the packet size effects the latency and throughput of the devices (no pretty graph, libreoffice crashed -.-) however the conclusion that was drawn was "it doesn't"

The latency of the connection from what I can tell BARELY depends on how much data the radio is actually sending. I'm talking about a difference of ~30ms (which is a drop in the bucket compared to pings of normal operation).

At 58bytes per packet we're seeing a speed of ~170B/s at a latency of ~340ms

and at 2 bytes per packet we're seeing a speed of ~6B/s at a latency of ~311ms

After 58 bytes what I noticed in a previous log proved to be the case, the radio splits the data up into packets of 58 bytes and we see no further performance gain.

Gathering this data did turn out to be a larger pain than I was expecting because I dropped a surprising amount of packets. Sure it was maybe 4 in 100, but to be honest I wasn't expecting any with the radios 2 feet away from each other.

I do not yet have any code to handle a lost packet, that will come later when I flesh out the serial emulator for these devices.

So what have we learned from all this information...

• setting the radio to a data rate of >10k is probably not worth the packet loss you'll see
• 1k, though it will achieve the longest range, has a painfully slow latency and speed on it.
• Some code will have to be implemented to intelligently and QUICKLY deal with lost packets
• The serial connection's speed when we're done won't be blowing anyone's socks off.

And what's next?

If I were doing this professionally the next thing I'd be doing would be grabbing one of the devices, strapping a battery onto it, and heading off outside to see what kind of effective range we get with this solution before deeming it a worthwhile project.

Good news is, I'm not doing this professionally (and I don't have a battery)

The C.H.I.P. device can power the radio from its 3.3v line at maximum power, and the chip itself can be powered off a regular microusb connection. My plan is to order a power pack used to recharge cell phones on the go, and take the whole assembly out with me and get some gps distance readings from the other device and see what kind of communication we can get.

In the meantime, I need to start thinking about the design of the serial emulator itself, and before I can do that there are some rather broad design decision that need to be made.

Should I use some sort of checksum (in addition to what LORA already has) to verify the data?

Should I implement any sort of retry functionality on a lost packet? or leave it up to the point-to-point protocol to handle those sorts of errors.

I'll be sitting back on the couch slamming water into my body hoping it can take care of these bacteria lurking in my throat, all the while thinking about this.

If anyone is reading this and has a good idea/previous experience about what might be a good idea to implement in a simple back and forth data transfer protocol I'd be glad to hear it!