Meshtastic <--> Secure Scuttlebutt

Any interesting idea. There was a talk a long time a go on integrating various forms of compression for the text part of the payload, possibilities for optimizing location updates, etc.

@LoRaLiker Did you get RAK3172 hardware ? If so what software library are you going to use with it?

For low power applications this module looks very attractive if there is easy software solution.


I ordered 10 with IPEX and 10 without on June 10th, but they still haven’t arrived yet. I reached out to RAK yesterday and they said they’d ship it out, so cross my fingers hopefully they arrive soon.

I have done a lot of work with the RAK4270 in the last couple weeks at my day job. I’ve gotten sleep down to 4uA, and rx duty cycled every 1s down to 70uA average! I think it was SF10, BW125. You have to be awake for a minimum number of preamble symbols, so lower data-rate settings will consume more power. It also means the TX has to send a 1s preamble, but for infrequent use cases, it saves a ton of energy on the RX side.

I justed used the code from semtec’s GitHub. You just have to implement a couple HAL functions. I used STM32cubeide and Cubemx, so it was pretty easy. Semtec’s code doesn’t come with an example application, just low level drivers, so you’ll have to write your own. Honestly the SX1262 is surprisingly simple compared to some other devices with complicated register and command sets.

When my new modules arrive, I’ll probably just modify my existing code. Cubemx can actually do code generation for the STM32WL devices, but I think they overcomplicate it and it has a number of dependencies, like timers. For custom P2P applications I think it’s overkill, but might be necessary if you are planning on doing LoRaWAN.

If you decide to use a RAK4270 or RAK3172 and run into any troubles, let me know and I’ll see if I can help.

1 Like

@LoRaLiker Thank you for your quick but detailed response. I will be following your experiments with it. I am only interested in P2P applications.

It’s been a busy summer but I am finally back to working on LoRa again. My RAK3172 modules showed up after a month of waiting, but unfortunately they were all with IPEX and none without. RAK shipped me the correct modules, and was kind enough to let me keep the ones with IPEX connectors that were sent in error.

I decided to actually use the STM32cubemx generated code base. It’s not terrible to work through, but it is probably more difficult than implementing it yourself depending on what you’re doing.

I’ve been happy with the RAK3172, outside of RAK not posting internal schematics for the module and then finding out it doesn’t contain a txco despite previous documentation indicating it does. Apparently the chip shortage lead to them making the decision to swap out the txco for a regular crystal oscillator last minute without updating the documentation. The poor/incorrect documentation was disappointing, but I will say RAK wireless does seem to have good support on their community forum and they are quick to answer any questions. The RAK3172 might not be the best device for Meshtastic in it’s current form since it doesn’t have bluetooth, but I hope that in the future Meshtastic adds support for lower power IOT devices without bluetooth. Bluetooth is great for the final steps of interfacing with the user, but you really only need one BLE->LoRa bridge, putting BLE on each IOT device seems unnecessary.

I was able to get the power consumption of my demo board down to 3uA sleeping and around 75uA for RX duty cycled receiving. I believe the duty cycle specs were 1 RX period every second for SF10 BW125khz, but I would have to double check my notes. The minimum RX period is at least 8 symbol periods plus 1ms for oscillators to stabilize, so higher spread factors and lower bandwidth settings increase the power consumption by increasing the required length of the RX period.

I am going to finish implementing my custom Motion Sensor → Alarm project. At that point I’d like to look into adapting it to implement a system closer to SSB where each device has a append only feed and surrounding devices sync and propagate that feed. Although latency might be slightly higher, it should in effect essentially be mesh networking with flood routing and store then forward functionality.

1 Like