As usual, there's a tonne of stuff to try to cram into this update. Maybe a bullet point summary to kick things off:
New TRACE packets
ESP32 OTA firmware updates (repeater and room server)
A nasty memory corruption bug fixed
Experimental: MeshCore running over ESP-NOW (2.4GHz)
From firmware versions 1.4.0 onward, a new TRACE packet type is now supported. Liam's app now has a fantastic UI for kicking off trace tests, where you manually trace a path through various repeaters (the path can even ping-pong back and forth if you really want) and if the trace gets though, you get a report of all the SNR's for each hop!
This is a really powerful diagnostic tool for those wanting to plan out their mesh, or diagnose bad links. It also has a lot of potential in the future for various smarts to be enabled by client nodes, to 'probe' known paths, and automate picking the best.
ESP32 OTA updates
The v1.4.1 repeater and room server releases now include the ability to update the firmware OTA. Just login to your repeater or room server, and in the CLI enter "start ota". It will then reply with a URL for connecting your web browser to:
The ESP32 will create a WiFi SSID of 'MeshCore-OTA" which you connect your laptop or phone to. Then just nav to the URL provided. You should see the web page above-right. Take note that the bottom-left has the node name and the board type displayed, eg. "MC Prime (Xiao C3)". Just double-check this is correct, then use the 'Choose file" to select the new firmware .bin file. (NOTE: this must be the 'update' bin, not the -merged.bin!)
If all goes well, the node will then reboot, and you should see it advert. If you want to cancel the OTA update, just enter "reboot" in the CLI.
Bug fixes
A very nasty bug was found in a library function the project uses. (ed25519_verify() for the nerds out there). This affected all devices, and was related to when advert packets are received and checked for integrity. A simple swap-out of this function to another one has cleared this up. But, it was causing some really significant memory corruptions, so could have been causing all sort of other problems.
Ver 1.4.1 firmwares now also use unique filenames per firmware type for the persisted config. Some people try one firmware type, eg. repeater, on a board, then reflash the same board with say companion firmware, and was causing a lot of problems, as the expected formats are different.
ESP-NOW
I go an experimental version of the Terminal Chat firmware working over ESP-NOW (instead of LoRa), and the results have been quite amazing. This is a peer-to-peer WiFi packet standard supported by Espressif boards. Is incredibly fast, but has much less range than LoRa (but better than std WiFi). Round-trip times for a zero hop message <-> Ack are a zippy 4-10 milliseconds! Andy has done a video already:
https://www.youtube.com/watch?v=GufCSJfld0c
It's still going to be more work to get the code into some respectable state, and have it in the Github repo. But, the proof-of-concept is done and is good to know this now a viable type of sub-mesh that can exist in the MeshCore world.
What I foresee as the use-case for this, is for on properties, or even within a building, with all sorts of (new) node types, like sensors or switches/actuators which each have their own native MeshCore identity (ie. public key) and can be contacted directly, either from within the building or from outside via a gateway repeater node (which bridges ESP-NOW and LoRa). The gateway node will make this completely seamless, ie. a path can be established from an in-building node to, say, a TDeck or companion radio, and both endpoints don't even know there are multiple physical mediums involved.
That will be the primary use-case, but there could be support for, say, companion radio nodes that connect over ESP-NOW. This could be for some short-range scenarios, like a conference or concert.
Managing Complexity
A lot of other stuff is happening, but probably not-exactly interesting. Managing the codebase is getting harder. Keeping stuff maintainable is a big challenge. Pull requests are getting merged/accepted more often now, and I've managed to get some pretty meaty refactors done to stave off the spaghetti-code demons.
There are still known bugs lurking around, yet to be found. These can be incredibly hard to corner, and fix. The 'ed25519_verify()' one took a lot of debugging by Liam and I to hunt down. Weird artefacts from it were noticed many weeks ago, so there were some clues, but was a hard one to nail.
Future Stuff
There are quite a lot of independent efforts extending the board support (like Faketec/promicro), and @fdlamotte's custom firmwares for T1000 and Python/command-line integrations. There are still a number of 'wild west' aspects that will take some time to settle, including the ESP-NOW stuff. So, some things will require some patience, and need to be considered unofficial/experimental.
But, I'm hoping to get the core messaging more solid, and the most popular boards (eg RAK, Heltec) to be the most solid. And, if I can get the time, the sensors aspect of MeshCore should be the next big push, feature-wise.