Meshtastic 1.3 -- Development Starts Next Week

Oh hey!

We had an absolute blast on little Meshtastic 1.3 Kickoff party two weeks ago. That was originally planned to get together for just an hour but we ended up going for nearly 4 hours!

Next week, we’re going to pause regular releases of Meshtastic 1.2 so we can focus on Meshtastic 1.3. While 1.2 is paused, we may put out a release of 1.2 but only fix any major issues that come up.

What are we planning on for 1.3? Here’s the short list (In no particular order):

  • Support for more regions
  • Support for dynamic scaling of the band plan based on bandwidth (Example: >200 channels on the US region, vs 13 today)
  • Revised radio configuration to be more resilient to errors and better support for forward error correction
  • Use wear leveling on the filesystem (LittleFS) to extend the life of the on board flash.
  • Support for group chats (eg: #FoodFreaks) like in IRC, Slack, Discord, etc.
  • Packet refactoring to reduce redundant information and reduce transmission requirements.
  • Transparent packet level compression – we expect a 25% reduction in packet size
  • Fixes for TEcho
  • Remove all backward compatibility code and data structures
  • Replace the bluetooth initialization routines to fix the bluetooth pairing issues on Android / iOS
  • Support for multiple clients connecting to the same device (eg: Multiple phones at once)
  • Improve how packets are handled for MQTT
  • Improvements to NodeDB
  • Plumbing to support Dynamic Frequency Switching (switch channel every few minutes to avoid noise)

While this list is being shared, this is not a promise. We’re 100% volunteer supported and while we have a volunteer for each one of those items, something might fall out.

The changes here will impact not only the device firmware, but everything from the Python API to Web / iOS / Android client, our MQTT server, documentation and I’m sure I’m missing something. This is a huge effort, please expect the first few version of 1.3 to be buggy.

This is not going to be backward compatible with previous firmware and that is by design. We will work with our hardware partners to have them ship 1.3 when the time comes.

That said, we’re all very excited to do this and hope to have 1.3 in your hands in around 4 months.

Yaaaaaaay!

23 Likes

Looking forward to this.

What about jumping to a 2.0 version? With this many backwards compatibility braking changes I think there are documentation and support advantages and little to no reason to stick to a middle (x.y.z) version increase.

4 Likes

The idea has merit. Let’s noodle on it.

2 Likes

We’ll use 1.3 during development and then the first public will be 2.0.0. :slight_smile:
Good idea.

6 Likes