My current queue (just FYI for anyone curious, I always work from a list like this) - with guesses on dates. As always, if anyone is looking for a fun project to code on, send me a note and you can work on as much or as little as you want ;-). It is pretty fun actually.
Approximately the next week: (by 5/3)
(DONE - will put out a build on the 3rd or 4th) Fixed the new dropped packet bug (partially by making a python driven multi-node stress test / qualification test - which will also provide an open python API for other uses)
(DONE - I tested with a semtech devboard, once I receive a ârealâ board with this chip Iâll probably need to tune a bit) sx1262 support
(DONE) Some relatively minor android bug reports on github
(DONE - Next release will be the 4thish, if it is solid Iâll call it beta 1) Declare android app âbetaâ quality
Approximately the next two weeks: (by 5/10)
(DONE - will push an update later this week) publish the python library on PyPi (for âpipâ installs). This should make a nice easy âzero configâ just plug it in and you have mesh networking support for other projects.
(DONE) turn encryption on for channels (AES256 - hardware assisted)
make mesh routing work for unicast messages (more efficient than the current ânaive floodingâ broadcast and provides acks (might slip a little - TBD). This will also automatic resends for lost messages.
Turn âover bluetoothâ updates of the device firmware back on in the android app.
Declare ESP32 device load beta quality
Approximately the next month: (by 6/15ish)
Have android app show message delivery status (queued, in mesh, delivered) via a small icon per message.
Get the existing codebase (and related needed changes for nrf52 and new radio, display and GPS) running nicely on @Syedâs board/product.
Allow nodes that have internet connectivity to gateway for any other node in the mesh. Initially support will be limited to MQTT and APRS (must have ham license for this second option).
Use the new MQTT gateway feature and a small webserver allow users to optionally share their position and signal strength data. This will allow building a real corpus showing âreal worldâ ranges people are getting and comparisons of radio hardware. This sharing will be default off but at least Iâll use it on my nodes/hikes as it is easier than painfully using spreadsheets. as the saying goes âwhat gets measured, gets done.â
re: hams and APRS
I should have been a bit more verbose. Since the mesh is already sharing position data I was going to have the gateway service (running in the phone) directly connect (via IP) to one of those APRS IP gateways. So not really âAPRSâ at all for anything flying over the mesh. The last time I futzed with APRS (a long time ago) the people that ran those servers said âwe only want hams using this gatewayâ. I donât know if it is still true.
Iâll look more carefully once this idea gets a little more real. Mostly I was thinking APRS and MQTT because they are both super easy to add to the gateway (because the IP protocols are so simple and easy to plop in a lib). And they would provide a good initial (but still useful) test of âautomagically let any node that can reach the internetâ gateway for all the other mesh members - with zero configuration required.
@syed oh yes, that was the other reason I wanted some sort of APRSish gateway - because I thought some sort of âoptional but automatically functionalâ global map visualizer of node positions would be cool.
We are waiting for it!
In the meanwhile, being very bed on the hardware side of things, how can I get a ready-to-go couple of devices for development / testing?
The API probably wonât change too much, and there are still a few TODO.md listed but it is basically usable now.
re: which hardware
For now Iâd recommend buying a few TTGO TBEAMs from aliexpress/banggood. Sometimes there are sellers that sell them on Amazon, but make sure to get a 915MHz version if you are in the US and get a version that includes a screen. Also buy one 18650 battery per board.
The TBEAMs are quite nice, but soonish (a couple of months?) there will hopefully be a purpose built even nicer boards.
If you donât need a GPS I think that would probably be fine. Iâm not sure if their little 3d printed case has enough space for a battery, but from the pict it looks like if you donât install the pin connectors (unneeded) I bet a 700mAh lipo battery would fit in there.
I think there is a small socket for battery power and they give you the corresponding plug to wire on to your battery of choice - either a pouch type lipo, or an 18650 cylinder which will need a holder. Like @geeksville says you can power it via usb if you want, computer or powerbank,
The webserver/MQTT idea sounds great. Its not that easy to test and log currently. I go out cycling and stop periodically and push the button or send a message then wait for the " ago" to update, if it does I know it worked, then I look at the time, ride a bit more, compare time, repeat etc. Then when I get home I plot in google maps the two points and have it work out the distance for those distant ones that were good. One idea I had was for a testing was a code word to be used in the android app that would trigger your gps coordinates to be pinged back to you in the app and/or to the remote node, then you could have a log of sorts to look at when you got home in the chat session.
Regarding range, I bought some whip antennas to replace the stock ones and range improved quite a lot. I will do some further testing and put it in a new topic. Setting Bandwidth to 62.5K instead of 125K and it works reliably too and improves range at the expense of speed.
ok an update: Iâve fixed the âlost messagesâ problem - I think, but I want to run an X hour stress test before declaring victory. Also, I switched from my old âoriginally Radiohead but highly customizedâ RF95 driver to the very nice driver in the Radiolab project. Radiolab is super nice because it allows supporting a super wide set of network interface chips with only minor code changes. This new branch now uses Radiolab for the RF95 and the new SX1262 driver and OMG it is so much cleaner internally than Radiohead.
But this change was âbigâ so I wonât be putting a build out with these changes until Iâve used it a few days.
(btw - just a general note on progress - Iâm hacking away, but since the current set of builds seems super stable and getting more usership, Iâm trying to group up a bunch of changes for the next release. Iâll probably release it this week and hopefully it will be the last âprotocol changingâ release for a while)
Also some great contributions from others have been merged into main - Iâll say more about them when I make the release.
Doesnât the TCXO have stability of about 2PPM (initial and temperature offsets combined)?
So at 900 (MHz) * 2 (part per million) = 1800 Hz/1.8 kHz offset. I know that is theoretical, but I would assume that it could do better than a 62 kHz channel.
Just going based off of memory - I think there is a temperature calibration/correction software step in the SX1262 datasheet (unless Iâm mixing up with another chip). I wonder if some drivers just arenât doing that process.