Skip to content

Releases: meshtastic/firmware

1.2.4 alpha

05 Mar 05:51
c5b67d8
Compare
Choose a tag to compare
1.2.4 alpha Pre-release
Pre-release

NOTE: THIS RELEASE WAS NOT GOOD - DO NOT USE.

First public alpha of this major release chain.

Caveats:

  • Unless you truly want to be an ALPHA tester, you should stay with the 1.1.x device and app releases for now
  • Some security features are not yet turned on in this 1.2 release, that will take another couple of weeks
  • firmware builds are now region independent. You must use the android (in the settings tab) or python (with --set region X) tools to set the region for your radio and location. However, we try to preserve old region info, so if you are updating it will try to keep your region correctly. If we don't know your region we guess and use USA frequencies.

Major changes:

  • Settings & channels can now be changed remotely via messages inside the mesh (not yet ready for testing by ya'll yet - first I want to make a python testharness)
  • We now 'piggyback' acks on application layer replies, this substantially reduces airtime consumed
  • Multiple channels are simultaneously supported (not yet ready for testing though - please wait until I write a full wiki on the topic)
  • Lots of internal cleanup which will result in smaller/faster packets

1.2.1 VERY alpha

04 Mar 03:43
249390a
Compare
Choose a tag to compare
1.2.1 VERY alpha Pre-release
Pre-release

Unless you are developing you probably don't want this yet

1.1.50 beta

01 Mar 01:23
43673c0
Compare
Choose a tag to compare

This is recommended stable tree for users

1.1.48 beta

14 Feb 07:26
2b10a03
Compare
Choose a tag to compare

Some good (but not urgent) fixes in here:

  • @mc-hamster added support for the ttgo lora32 1.3 board
  • @mc-hamster exposed radio frequency through his json web api
  • @sachaw fixed a bit of malformatted JSON
  • Position broadcasts are now sent even if we don't have a GPS lock, this should dramatically cut the time required for new nodes to learn the mesh.
  • We were not properly broadcasting the positions of nodes that were marked as "fixed_position"
  • Firmware updates now disable the lora radio during the update, we also show an "updating" screen on the screen.
  • (Related to the very brief 1.1.47 alpha release) make failures due to hitting MAX_THREADS fatal (rather than silently ignoring), and bump max_threads to 32

Any feedback appreciated.

(btw - note on my work queue: I spent the last week fixing github bugs and the reliability is looking pretty good. I'm now going to spend twoish weeks finishing some support for new boards and (hopefully) get the first release of the internet messaging/mqtt feature out there)

1.1.46...1.1.48

1.1.47 alpha

14 Feb 05:50
c0fbfcc
Compare
Choose a tag to compare
1.1.47 alpha Pre-release
Pre-release

(this release had problems - you don't want it)

1.1.46 beta

12 Feb 02:05
7ff1f3a
Compare
Choose a tag to compare

Hi ya'll,

This release includes a really good protocol improvement. While investigating/fixing:

#681

I noticed a funny side effect of lora being so slow: Usually when making a protocol there isn't much need to use message priority to change the order of transmission (because interfaces are fairly fast). But for lora where packets can take a few seconds each, it is very important to make sure that critical packets are sent ASAP. In the case of meshtastic that means we want to send protocol acks as soon as possible (to prevent unneeded retransmissions), we want routing messages to be sent next, then messages marked as reliable and finally 'background' packets like periodic position updates.

So I bit the bullet and implemented a new (internal - not sent over the air) field in MeshPacket called 'priority'. And the transmission queue in the router object is now a priority queue.

I also updated the position and node info plugins to never have more than one transmission queued.

The combined effect of these changes is a dramatic increase in speed and reliability for 'busy' networks. Also the networks will become much less busy, because we can prevent unneeded flood routing events sooner.

1.1.42 alpha

07 Feb 03:01
f7beec4
Compare
Choose a tag to compare
1.1.42 alpha Pre-release
Pre-release

A minor alpha release to pull in some recent fixes.

  • @android606 stepped up and fixed an old bug, of 'if the radio has a broken irq wire. report that as a critical fault in the diagnostics'
  • @mc-hamster fixed #664 - blink the LED when the BLE pin is disabled
  • @mc-hamster added beginning support for beepers/speakers and added documentation for this
  • @mc-hamster fixed problems with remote GPIO control
  • fix bug #677: don't reboot board if someone tries to send a packet but no radio chip was found, instead just report a fault
  • Fix charging indication for boards that have 'dumb' battery sensors
  • Use the new logo

1.1.33 beta

26 Jan 04:48
ea40bd9
Compare
Choose a tag to compare

... a whole lot more little bugs!

1.1.32 beta

03 Jan 13:27
bce2c93
Compare
Choose a tag to compare

A beta release with minimum changes vs the 1.1.31 alpha. Just:

  • Fix #622. "Device without GPS asserts on node->has_position"
  • @mc-hamster removed a warning about this being still experimental

1.1.31 alpha

02 Jan 08:53
8e8257a
Compare
Choose a tag to compare
1.1.31 alpha Pre-release
Pre-release

1.1.31 of the device code is out! Hopefully (if ya'lls testing goes okay), it will be blessed as a beta and become the new "not prerelease build".

This release is almost primarily bug fixes by @mc-hamster and @wfang2002 (and a couple of them related to GPS most users will definitely want).

  • @wfang2002 fixed a couple of really ugly gps bugs (see changelogs for details)
  • @mc-hamster continued improvements in the WEB API