Meshtastic Firmware beta

This version was focused on bug fixes. If there are no major problems, it’ll be promoted to Beta.

What’s Changed

New Contributors


The old CPU speed on the oled display has been replaced with “ChUtil” or channel utilization. This will show how much traffic there is on your channel, both from your mesh and any other lora traffic that may interfere (other meshes, helium, lorawan, etc).


I made a post yesterday about Tbeam FW 1.2.50 not found in Android 7 mestastic APP from 1.2.45 to 1.2.50 / 51. Remove the post hour later because it solved. This morning upgrade to latest FW and APK Tbeam FW 1.2.50 + meshtastic 1.2.52 trouble is back and not fantastic
Android 7.0 pair BT Tbeam and APP meshtastic APP 1.2.52 also see device, but not give access to Tbeam device some reason not clear
Same as yesterday after upgrade to mestastic APP from 1.2.45 to 1.2.50 / 51.
I solve it yesterday to roll back FW Tbeam to early versions and upgrade every version from start but i think not the way.
How do i ADD pictures to post?

Strange, the latest FW firmware-t-echo- changed my device name from Meshtastic_1cf2 to Meshtastic_c773

Seems like it pulls the name from the beginning instead of the end of the MAC address: 73:c7 … 1c:f2 and also in reverse!

1.2.50 has been promoted from Alpha to Beta.

It’s stable!

With the 2 T-echo that i have, same result : Critical fault #8

An idea ??

After updating to 1.2.50 all 3 of my t-beam boards will not get a gps lock. Anyone else seeing this?

Ever since updating to 1.2.50 when using the python cli, most commands return the below posted output. Checking Version or such work, however it reports 1.2.48 instead of 1.2.50.

$ meshtastic --port COM5 --nodes
Traceback (most recent call last):
File “C:\Users\Mark\AppData\Local\Programs\Python\Python310\Scripts\”, line 33, in
sys.exit(load_entry_point(‘meshtastic==1.2.48’, ‘console_scripts’, ‘meshtastic’)())
File “C:\Users\Mark\AppData\Local\Programs\Python\Python310\lib\site-packages\”, line 833, in main
File “C:\Users\Mark\AppData\Local\Programs\Python\Python310\lib\site-packages\”, line 635, in common
client = meshtastic.serial_interface.SerialInterface(
File “C:\Users\Mark\AppData\Local\Programs\Python\Python310\lib\site-packages\meshtastic\”, line 52, in init = serial.Serial(devPath, 921600, exclusive=True, timeout=0.5, write_timeout=0)
File “C:\Users\Mark\AppData\Local\Programs\Python\Python310\lib\site-packages\serial\”, line 33, in init
super(Serial, self).init(*args, **kwargs)
File “C:\Users\Mark\AppData\Local\Programs\Python\Python310\lib\site-packages\serial\”, line 244, in init
File “C:\Users\Mark\AppData\Local\Programs\Python\Python310\lib\site-packages\serial\”, line 64, in open
raise SerialException(“could not open port {!r}: {!r}”.format(self.portstr, ctypes.WinError()))
serial.serialutil.SerialException: could not open port ‘COM5’: FileNotFoundError(2, ‘The system cannot find the file specified.’, None, 2)

Also it seems now the AP web interface is not working, all I get is a blank page. It was working in the earlier version.

Blank page means the web content wasn’t loaded. Did you use the install script in the firmware zip file?

It can take 15-20 minutes, outdoors on a clear day, to get a gps lock.

I found some ‘bugs’ in firmware-1.2.50 when I activate the node as WiFiAP.

The node is a LilyGo T3-1.6.
Sometimes the webserverIP is but mostly it is
(Maybe because I have a ESP8266 device that also use for configuration?)

Sometimes, just after activating the WiFi AP, the node get very slow and even can reset itself, the node will then come back as IP and needs a push-reset-button.
Getting in WiFi mode on a Android(8.0) phone or on a Win10 tablet is slow and difficult (maybe browser issues)
On a linux laptop in Chromium it works best for me, the connection stays stable.

On the UI:
When I choose the ‘nodes’ button nothing happens, blank screen, need to go to previus page.
In the message screen the time stamp always is the same 01:00 AM.

I see that the ChUtil is varying a lot even after some power on time ( from 0…22%). Is it calculated only for the last minute or so? If yes, wouldn’t it be better to have a longer time average?
Just a thought…

Next version smooths it a little bit, but the 1 minute window remains. This is intended to be “what is going on now”.

If longer averages are needed, the airtime data can be reviewed. That has 24 hours of data.

There’s nothing in the code that would make it listen to

We picked 42 because that’s to the answer to life the universe and everything.

In AP mode, try going to on your device. That’s an internal page served by the web server. If you can get to that, then you know the device is functioning normally.

How could I have missed that, it’s so obvious :innocent:

I have to learn a lot of stuff, I just started 2 weeks ago with this awesome project.