After some testing and reorganizing, the E32-TTL-100 lora module driver implemented in rust is now complete!

You can find the source here: https://github.com/ddemarco5/lora_driver

It's configured as a crate, so if you want to include it in your own RUST project, all you have to do is add this to your Cargo.toml (assuming you're using cargo)

[dependencies]
lora_driver = { git = 'https://github.com/ddemarco5/lora_driver.git' }

extern crate lora_driver;
use lora_driver::RadioConfig;
use lora_driver::Driver;
use lora_driver::RadioMode;

I plan on updating it as I require/see fit as the project continues, so a word of warning to anyone who wants to jump on the bus immediately. Though based on how much attention this project is getting I'm assuming that won't be many of you :P

Besides that news, I'm going to be starting the actual full-duplex serial emulator soon.

Before that though, I think I'm going to run a few tests to see what sort of speeds/power consumption I can expect out of these things. The packet transmit rate is anywhere from an advertised 1k to 25k, so I'll actually need to test those.

Based on preliminary results though, I can attest to the fact that the 1k mode is SLOW. I'm talking somewhere around 2-3 seconds to transfer 256 bytes of data.

Though there's a somewhat undocumented reason for that... I'll explain below.

What first tipped me off to it was the power drain I was seeing on my power supply. I sent the documented 256 bytes to the device for transmit, and I could see the power drain hop up to 100mA immediately, it was drawing current as was specified in the doc, but something was odd. Every second or so the power consumption would drop down to 70mA for a short while and then back up to 100mA.

I could actually hear very slightly the noise made from the radio in speakers I had close by, so that also tipped me off to the radio's activities.

When the power draw dropped to 70mA, the radio would stop transmitting... odd.

I went to a serial monitor program on my C.H.I.P. device to see what was up, since I wasn't receiving the full data I was expecting in my rust program, and there I saw the culprit.

The radio was actually sending FIVE data packets of 58 bytes each. When the power draw of the radio was dropping, that was the internal circuitry moving 58 bytes from its internal buffer into the LORA chip for transmittal.

The max packet size is NOT 256 bytes as the original documentation suggested, but 58 bytes instead.

The chip has a UART buffer that can be filled with up to 256 bytes, and the gpio outputs from the chip indicate whether or not THAT buffer is full, not the max packet size of the LORA radio.

This is interesting functionality, but unfortunately I'll be unable to make use of it in the serial emulation portion of my project, because the radio is already introducing overhead per packet, it will be of no value to me to send data any larger than 58 bytes to the radio. If I don't split the data in to 58 bytes per packet, the radio will instead.

The only impact that would have on the final project of this project would most likely be an increase in latency, unfortunate...

HOWEVER, since I'd like the driver software I wrote to be general purpose enough to be used by other people, I've left the ability to read an entire 256 byte packet in as well. The code makes use of a timeout function on a serial read to ensure there is no more data left in the serial buffer to be read.

I will, however, have to expose the ability to customize that timeout value, because based on the transmit rate the radios are set to, you may have to end up waiting for around 2 SECONDS for another data packet to come through. Yes... it can be that slow.

Progress is promising though! I'll post some updates after I've done some benchmarking of these devices to see what kind of data rates I might be able to expect when all is said and done.