Next work items in my queue

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.”
1 Like

@geeksville Why is APRS limited to hams, if the usage is in the 900 MHz unlicensed band?

For a bit of inspiration of how others are doing the location and signal strength mapping, WSPRnet might be interesting.

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?

as it turns out it was easier than expected. Early version here: Python API release notes

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.

what about this one?


however I dont understand if they have a battery or not

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.

1 Like

also - battery probably doesn’t matter if you are using these things as dongles attached to your windows machine - they will get power from USB.

1 Like

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.

2 Likes

ooh that’s great feedback. I look forward to your post. I’m a big fan of trading speed for range (considering the current initial usecase).

yeah - we need some better way to map/log performance ranges across types of radios and settings.

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.

3 Likes

That sounds awesome and great for the project going forward as more and more devices can be supported with relative ease.

(updated work queue in the original post)

@scott Have you tried going down to 7.8 kHz channel bandwidth?

(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.

62.5KHz minimal stable frequency for TCXO in modules. It won’t work on 7.8 kHz bandwidth.

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.

In theory- yes. But just try it and you’ ll see instability.

1 Like

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.