New device alpha 1.2.44 lots of good fixes (particularly for nrf52)

This release (for alpha testers only for now) has a bunch of good bug fixes - especially for the new nrf52 boards. Please post here with how it goes for you!

  • @audunf made packet routing smarter when the transmit queue is full. In that case, try to drop only low priority packets.
  • @dmitryelj fixed support for boards that use the (less common) SH1106 display
  • @flux242 fixed an invalid heap reference when using MQTT
  • @claesg fixed battery sensing and sleep on nrf52
  • Fix higher odds of dropping packets if a board was in light sleep (bug #801)
  • Don’t leak wifi passwords back to hosts (hosts can still set them, but can’t read them) reported by @vodkin
  • Don’t enter light-sleep state while talking to MQTT servers
  • Show a max of four most recent nodes in the scrolling screen display
  • Update to latest nrf52 arduino libs
  • Fix #838 serial could hang when talking to nrf52 boards

hi, iam new on this project and i really like it. Previous versions throwed some backtraces with is_router enabled. Now seems to work flawlesly., thanks to the devs


Running nicely on 5 RAK nrf52 boards over here

1 Like

btw - RAK power consumption could be much lower. I haven’t had a chance to get to it yet, but if anyone wants to poke at it I can give some pointers (in short: we are leaving a very expensive power rail on all the time when we really should only turn it on when the GPS is needed)

I would be happy to take a look, just got the repo building locally.

1 Like

I have installed 1.2.44 on two T-Echo’s. I reported that these units have an issue but I wonder now if they are just faulty. 1.2.44 shows the same issues seen in 1.2.42 and 43. Both units get a good gps fix as judged by distances reported for each other and two other T-beams. However neither updates the positions and one says no gps lock while the other gives a lat/lon but says 0 satellites.
Meshtastic --info gives the following for the two units. I have not set the region but doing makes the unit reporting the correct lat/lon then report an incorrect lat/lon. Any clues in this to help? Anything else I could do to understand the problem? Apologies for the long post. Thanks.
T-Echo No gps lock:

My info: { “myNodeNum”: 1304503830, “hasGps”: true, “numBands”: 13, “firmwareVersion”: “1.2.44.f2c9c55”, “messageTimeoutMsec”: 300000, “minAppVersion”: 20200, “maxChannels”: 8 }

Nodes in mesh:
{‘num’: 1304503830, ‘user’: {‘id’: ‘!4dc12616’, ‘longName’: ‘Unknown 2616’, ‘shortName’: ‘?16’, ‘macaddr’: ‘6PlNwSYW’, ‘hwModel’: ‘T_ECHO’, ‘raw’: id: “!4dc12616”
long_name: “Unknown 2616” short_name: “?16” macaddr: “\350\371M\301&\026” hw_model: T_ECHO }, ‘position’: {‘latitudeI’: 520808590, ‘longitudeI’: 142431, ‘altitude’: 9,
‘batteryLevel’: 100, ‘raw’: latitude_i: 520808590 longitude_i: 142431 altitude: 9 battery_level: 100 , ‘latitude’: 52.080859, ‘longitude’: 0.0142431}, ‘lastHeard’: 1629103323,
‘lastReceived’: {‘from’: 1304503830, ‘to’: 4294967295, ‘decoded’: {‘portnum’: ‘NODEINFO_APP’, ‘payload’: b’\n\t!4dc12616\x12\x0cUnknown 2616\x1a\x03?16"\x06\xe8\xf9M\xc1&\x160\x07’, ‘user’: {‘id’: ‘!4dc12616’, ‘longName’: ‘Unknown 2616’, ‘shortName’: ‘?16’, ‘macaddr’: ‘6PlNwSYW’, ‘hwModel’: ‘T_ECHO’, ‘raw’: id: “!4dc12616” long_name: “Unknown 2616” short_name: “?16” macaddr: “\350\371M\301&\026” hw_model: T_ECHO }}, ‘id’: 1481765944, ‘rxTime’: 1629103323, ‘hopLimit’: 3, ‘priority’: ‘BACKGROUND’, ‘raw’: from: 1304503830 to: 4294967295 decoded { portnum: NODEINFO_APP payload: “\n\t!4dc12616\022\014Unknown 2616\032\003?16”\006\350\371M\301&\0260\007" } id: 1481765944 rx_time: 1629103323 hop_limit: 3 priority: BACKGROUND , ‘fromId’: ‘!4dc12616’, ‘toId’: ‘^all’}, ‘snr’: None, ‘hopLimit’: 3}
{‘num’: 3912074273, ‘user’: {‘id’: ‘!e92d8421’, ‘longName’: ‘Unknown 8421’, ‘shortName’: ‘?21’, ‘macaddr’: ‘7s7pLYQh’, ‘hwModel’: ‘T_ECHO’, ‘raw’: id: “!e92d8421”
long_name: “Unknown 8421” short_name: “?21” macaddr: “\356\316\351-\204!” hw_model: T_ECHO }, ‘position’: {‘latitudeI’: 520808160, ‘longitudeI’: 141265, ‘altitude’: 31,
‘batteryLevel’: 100, ‘time’: 1629103291, ‘raw’: latitude_i: 520808160 longitude_i: 141265 altitude: 31 battery_level: 100 time: 1629103291 , ‘latitude’: 52.080816, ‘longitude’: 0.0141265}, ‘lastHeard’: 1629103265, ‘snr’: 4.75, ‘lastReceived’: {‘from’: 3912074273, ‘to’: 4294967295, ‘decoded’: {‘portnum’: ‘NODEINFO_APP’, ‘payload’: b’\n\t!e92d8421\x12\x0cUnknown 8421\x1a\x03?21"\x06\xee\xce\xe9-\x84!0\x07’, ‘user’: {‘id’: ‘!e92d8421’, ‘longName’: ‘Unknown 8421’, ‘shortName’: ‘?21’, ‘macaddr’: ‘7s7pLYQh’, ‘hwModel’: ‘T_ECHO’, ‘raw’: id: “!e92d8421” long_name: “Unknown 8421” short_name: “?21” macaddr: “\356\316\351-\204!” hw_model: T_ECHO }}, ‘id’: 1481766596, ‘rxTime’: 1629103265, ‘rxSnr’: 4.75, ‘hopLimit’: 3, ‘rxRssi’: -32, ‘raw’: from: 3912074273 to: 4294967295 decoded { portnum: NODEINFO_APP payload: “\n\t!e92d8421\022\014Unknown 8421\032\003?21”\006\356\316\351-\204!0\007" } id: 1481766596 rx_time: 1629103265 rx_snr: 4.75 hop_limit: 3 rx_rssi: -32 , ‘fromId’: ‘!e92d8421’, ‘toId’: ‘^all’}, ‘hopLimit’: 3}
{‘num’: 2885177024, ‘user’: {‘id’: ‘!abf84ec0’, ‘longName’: ‘Unknown 4ec0’, ‘shortName’: ‘?C0’, ‘macaddr’: ‘JGKr+E7A’}, ‘position’: {‘latitudeI’: 520809327, ‘longitudeI’: 140953,
‘batteryLevel’: 100, ‘time’: 1627646007, ‘latitude’: 52.0809327, ‘longitude’: 0.0140953}, ‘lastHeard’: 1627646150, ‘snr’: 7.0}
{‘num’: 2885175640, ‘user’: {‘id’: ‘!abf84958’, ‘longName’: ‘Unknown 4958’, ‘shortName’: ‘?58’, ‘macaddr’: ‘JGKr+ElY’}, ‘position’: {‘latitudeI’: 520803603, ‘longitudeI’: 148102, ‘batteryLevel’: 100, ‘time’: 1627830026, ‘latitude’: 52.080360299999995, ‘longitude’: 0.014810199999999999}, ‘lastHeard’: 1628099676, ‘snr’: 3.75}

Preferences: { “positionBroadcastSecs”: 15, “phoneTimeoutSecs”: 900, “lsSecs”: 300 }

T-Echo gps lock but no satellites:

My info: { “myNodeNum”: 3912074273, “hasGps”: true, “numBands”: 13, “firmwareVersion”: “1.2.44.f2c9c55”, “messageTimeoutMsec”: 300000, “minAppVersion”: 20200, “maxChannels”: 8 }

Nodes in mesh:
{‘num’: 3912074273, ‘user’: {‘id’: ‘!e92d8421’, ‘longName’: ‘Unknown 8421’, ‘shortName’: ‘?21’, ‘macaddr’: ‘7s7pLYQh’, ‘hwModel’: ‘T_ECHO’, ‘raw’: id: “!e92d8421”
long_name: “Unknown 8421” short_name: “?21” macaddr: “\356\316\351-\204!” hw_model: T_ECHO }, ‘position’: {‘latitudeI’: 520808160, ‘longitudeI’: 141265, ‘altitude’: 31,
‘batteryLevel’: 100, ‘time’: 1629103826, ‘raw’: latitude_i: 520808160 longitude_i: 141265 altitude: 31 battery_level: 100 time: 1629103826 , ‘latitude’: 52.080816, ‘longitude’: 0.0141265}, ‘lastHeard’: 1629103821,
‘lastReceived’: {‘from’: 3912074273, ‘to’: 4294967295, ‘decoded’: {‘portnum’: ‘NODEINFO_APP’, ‘payload’: b’\n\t!e92d8421\x12\x0cUnknown 8421\x1a\x03?21"\x06\xee\xce\xe9-\x84!0\x07’, ‘user’: {‘id’: ‘!e92d8421’, ‘longName’: ‘Unknown 8421’, ‘shortName’: ‘?21’, ‘macaddr’: ‘7s7pLYQh’, ‘hwModel’: ‘T_ECHO’, ‘raw’: id: “!e92d8421” long_name: “Unknown 8421” short_name: “?21” macaddr: “\356\316\351-\204!” hw_model: T_ECHO }}, ‘id’: 1481766677, ‘rxTime’: 1629103821, ‘hopLimit’: 3, ‘priority’: ‘BACKGROUND’, ‘raw’: from: 3912074273 to: 4294967295 decoded { portnum: NODEINFO_APP payload: “\n\t!e92d8421\022\014Unknown 8421\032\003?21”\006\356\316\351-\204!0\007" } id: 1481766677 rx_time: 1629103821 hop_limit: 3 priority: BACKGROUND , ‘fromId’: ‘!e92d8421’, ‘toId’: ‘^all’}, ‘snr’: None, ‘hopLimit’: 3}
{‘num’: 2885175640, ‘user’: {‘id’: ‘!abf84958’, ’
longName’: ‘Unknown 4958’, ‘shortName’: ‘?58’, ‘macaddr’: ‘JGKr+ElY’}, ‘position’: {‘latitudeI’: 520803440, ‘longitudeI’: 148156,
‘batteryLevel’: 100, ‘time’: 1628607607, ‘latitude’: 52.080344, ‘longitude’: 0.0148156}, ‘lastHeard’: 1628607673, ‘snr’: 4.5}
{‘num’: 1304503830, ‘user’: {‘id’: ‘!4dc12616’, ‘longName’: ‘Unknown 2616’, ‘shortName’: ‘?16’, ‘macaddr’: ‘6PlNwSYW’, ‘hwModel’: ‘T_ECHO’}, ‘position’: {‘latitudeI’: 520808590, ‘longitudeI’: 142431, ‘altitude’: 9, ‘batteryLevel’: 100, ‘time’: 1628416666, ‘latitude’: 52.080859, ‘longitude’: 0.0142431}, ‘lastHeard’: 1629103565, ‘snr’: 7.0}
{‘num’: 2885177024, ‘user’: {‘id’: ‘!abf84ec0’, ‘longName’: ‘Unknown 4ec0’, ‘shortName’: ‘?C0’, ‘macaddr’: ‘JGKr+E7A’}, ‘position’: {‘latitudeI’: 520809327, ‘longitudeI’: 140953,
‘batteryLevel’: 100, ‘time’: 1627646007, ‘latitude’: 52.0809327, ‘longitude’: 0.0140953}, ‘lastHeard’: 1627646149, ‘snr’: 7.25}

Preferences: { “positionBroadcastSecs”: 15, “phoneTimeoutSecs”: 900, “lsSecs”: 300 }

1 Like

If you have some pointers as far as where to look in the firmware for the code related to the RAK GPS power rail I have some time this week to take a look.

How did you manage to get this far with the t-echo’s? I have one which I have tried installing every version since 1.2.39 and the screen only once updated to the meshtastic splash screen on first install, but didn’t cycle through the screens and so I reinstalled SOFTRF and tried with a never version of meshtastic afterwards, no success. SoftRF seems to work OK
I can see the removable drive, drop the firmware-t-echo-1.2.44.f2c9c55.uf2 on there, it autoejects, but the firmware doesn’t seem to run. No communication via the serial port either (works fine with RAKs boards and t-beams).

Any suggestions?

1 Like

hmm - my techo’s seem fine. Can you try the following:

  • Tap the reset button twice (to force it to stay in the bootloader)
  • The red led should ‘breathe’ slowly getting dimmer/brighter
  • Drag drop the latest uf2 into that drive
  • Press the reset button (I don’t remember if this is required)
  • The blue led should blink briefly once every 500ms. Does it?
  • The eink screen should update. Does it?
  • If you run “meshtastic --info” on your desktop PC it should talk to the device over USB and print out device settings. Does it?

Hi @Nanovitruvius I did nothing special - just followed the instructions to drag and drop the uf2 file into the new drive seen on double clicking button 1.
On my PC I see the message telling me the file is being copied and then the unit resets. I get an initial message re no gps but then the units mesh and I see several pages with distance and direction to the other units on the screen. The uf2 file from LilyGO-T-Echo/examples/Meshtastic_firmware at 1e0ce8dfb7be0ab5eba2e6807f54d29e2f49c785 · Xinyuan-Lily also worked for me.

Hi @geeksville, thanks for taking the time to reply! This is the step by step results from your instructions above:

  • Bootloader mounts the drive on double click

  • I get a red, solid (not blinking) LED

  • Drag & drop firmware-t-echo-1.2.44.f2c9c55.uf2 across, it copies onto the mounted drive, which then unmounts automatically, LED is now purple. Screen still shows “SoftRF & LilyGO”

  • Pressing reset button or the other button does nothing, I still have the same solid purple button - the device seems stuck

  • Screen still shows “SoftRF & LilyGO”

  • Running the meshtastic --info command in terminal on OS X times out with:

meshtastic --info
Traceback (most recent call last):
File “/usr/local/bin/meshtastic”, line 8, in
File “/usr/local/lib/python3.9/site-packages/meshtastic/”, line 663, in main
File “/usr/local/lib/python3.9/site-packages/meshtastic/”, line 508, in common
client = SerialInterface(
File “/usr/local/lib/python3.9/site-packages/meshtastic/”, line 936, in init
File “/usr/local/lib/python3.9/site-packages/meshtastic/”, line 773, in init
File “/usr/local/lib/python3.9/site-packages/meshtastic/”, line 795, in connect
File “/usr/local/lib/python3.9/site-packages/meshtastic/”, line 424, in _waitConnected
raise Exception(“Timed out waiting for connection completion”)
Exception: Timed out waiting for connection completion

The same command works for the t-beams and my RAK modules, I have read somewhere on the forum that the t-echos mount differently on OSX but cannot find that post just now.

I also tried with the code again that @feh123 suggests above (from LilyGO-T-Echo/examples at main · Xinyuan-LilyGO/LilyGO-T-Echo · GitHub) but all the .uf2 files give this exact result.
The very first time I tried this was when I received the t-echo, at that time I think the firmware was on 1.2.39 or .41, the screen updated to the meshtastic splash screen but never got past the splash screen, in fact the SoftRF screen was kind of still visible behind the meshtastic screen. I tried several times re-uploading the meshtastic firmware but never got the splash screen again - this is why I have been going back to SoftRF to check if the hardware is still ok.
Edit: Only the SoftRF version from LilyGOs link works on my device, downloading the Mass storage firmware from here [Releases · lyusupov/SoftRF · GitHub] does not, it shows the same problems as the meshtastic firmware (and the screen is upside down).

I would think I have an early dud, but the strange thing is that it always works with LilyGOs SoftRF when I go back to uploading that (all but the capacitative button at the top, which I am not sure is even in use in SoftRF).

Edit2: It seems my T-Echo doesn’t have the Bosch barometer installed, could this be the reason it hangs up?

Hi @Nanovitruvius I think like you that I have two duds. Both boot up correctly with 1.2.44 and meshtastic --info works. The best one finds satellites and seems to be working but within a few minutes all the satellites are lost. The second never gets that far. It boots but always shows gps lock = 0 (using Arduino serial monitor). I can see no obvious wiring errors if look inside either one. I am going to try to get them replaced.

1 Like

I’ve had the most success running on my T-Echos. The latest version seems to bring back the issue where the reboot button doesn’t work unless the device is plugged in.

Hi thanks for the info. No improvement with 1.2.42 on my T-Echos sadly. I am asking Lilygo for replacements. However part of me would like to reset the devices completely and re-install from scratch to see if that is the problem. Because it does seem odd that they are faulty. But I am not sure how to do that!

You could try the SoftRF software from LilyGo that I linked above - if that works then in principle Meshtastic should work to and its a software issue - I seem to remember that @geeksville may have mentioned somewhere else that LilyGo might have made some slightly different hardware versions, could it be related to that?

It seems strange that the LilyGo versions have different behaviour from the versions from the actual developer (screen upside down, etc)

Thanks for the idea. I tried it and SoftRF does work - I just installed the uf2 180 file using the double click method to copy it.
It confirms one problem - the device with the no gps lock error now gives a No Fix on the position screen. This looks definitely faulty.
The second device with the working gps does show the gps data in monitor mode via XCSoar. From the gngga sequence it sees a stable 12 satellites. So this device should work, if I am reading the NMEA correctly!

1 Like

I’ve been experimenting a bit more and the SoftRF180 .uf2 file works on mine, but none of the meshtastic uf2’s do, as detailed in my post further up.

However after loading a variety of uf2s, including installing micropython, and then returning to SoftRF, I note that the settings that I changed using the SoftRF app ( I changed the default protocol in SoftRF to “FAN” and switched transmission to “OFF”), they stick, even after uploading several uf2s. Every time I reinstall SoftRF, it remembers these settings.

On LilyGo T-Echo readme I see that there are two different Flash versions that seem to be used in the devices:

  1. Flash will choose MX25R1635FZUIL0 or ZD25WQ16B according to the availability.Pay attention to the difference when using.

@geeksville Could SoftRF be set up to program either whilst meshtastic flashes just one of the versions so that those of us who have “the wrong one” cannot program the device?

I’ve opened mine up to see which flash chip is installed but my eyesight isn’t good enough to make out the markings without a microscope.

PS I know this is in the 1.2.44 thread but I have also tried 1.2.45.

Could you install via Git Bash? I have not tried that.

I do not know if it directly relates, but there is a persistent gps config…