New device release 1.2.30 ready for alpha testing!

Development Alpha Testers
1

We’ve gone the last couple of weeks without a new alpha (sorry about that - was dealing with life things and MC, Sasha and the other devs also been busy :wink: ).

If you use the python tool you should “pip install --upgrade meshtastic” to get some important fixes there.

For the next few days I need to work on the pine64 board so I can send some patches upstream. This weekend I’ll push out an android build with misc minor fixes.

Major changes in this new alpha:

  • Fix a nasty problem where sometimes messages that need to be resent were not getting resent
  • A plugin was sometimes stopping packet processing (also nasty)
  • We were somtimes sending NO-RESPONSE NAKs for packets we should not
  • Doc link fixes for the new repo the documentation devs have been making (thank @sachaw @apt105, Foster Irwin and @kylegordon and I hope I didn’t miss anyone)
  • Fixes for battery sensing on heltecs/tlora (please see other thread - I don’t have these boards to test on currently)
  • Fix usb access for nrf52840 boards
  • This is the first release with official binaries for the RAK4631 and TTGO T-Echo (eink) nrf52 boards!
  • Improved support for the pine64 lora board (not yet ready for usage by others though)
  • Use our new github continuous-integration based build system to generate this release (guarantees full repeatability for builds)
14 Likes
2

I’ll give it a spin.
Also, does this address the issue of messages not being pushed from the radio to the app?

3

Seems to be fixed for me. I sent a message from a 1.2.28 radio to a 1.2.30 radio after allowing the 1.2.30 radio to sit for over an hour. The message was received just fine. I haven’t upgraded all my radios to 1.2.30 since the firmware hasn’t been pushed to the app update yet and i don’t want to take apart all my cases.

2 Likes
4

I’m noticing a lot of timeouts using the python CLI. Using 1.2.30.80 on devices and latest 1.2.33 CLI.

meshtastic --nodes
Connected to radio
Aborting due to: Write timeout
ERROR:root:Error while handling message from radio Write timeout
Traceback (most recent call last):
File “C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\meshtastic_init_.py”, line 871, in __reader
self._handleFromRadio(self.rxBuf[HEADER_LEN:])
File "C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\meshtastic_init.py", line 552, in _handleFromRadio
self.handlePacketFromRadio(fromRadio.packet)
File "C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\meshtastic_init.py", line 690, in _handlePacketFromRadio
handler.callback(asDict)
File “C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\meshtastic\node.py”, line 381, in onResponse
self.iface.connected() # Tell everone else we are ready to go
File "C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\meshtastic_init.py", line 465, in _connected
self.startHeartbeat()
File "C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\meshtastic_init.py", line 455, in startHeartbeat
callback() # run our periodic callback now, it will make another timer if necessary
File "C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\meshtastic_init.py", line 453, in callback
self.sendToRadio(p)
File "C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\meshtastic_init.py", line 493, in _sendToRadio
self.sendToRadioImpl(toRadio)
File "C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\meshtastic_init.py", line 821, in _sendToRadioImpl
self.writeBytes(header + b)
File "C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\meshtastic_init.py", line 807, in _writeBytes
self.stream.write(b)
File “C:\Users\avron\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.9_qbz5n2kfra8p0\LocalCache\local-packages\Python39\site-packages\serial\serialwin32.py”, line 325, in write
raise SerialTimeoutException(‘Write timeout’)
serial.serialutil.SerialTimeoutException: Write timeout

1 Like
5

Hmm. Someone else mentioned a change in serial behavior. I haven’t checked yet but possibly pyserial (which we use), pushed out a bad update? I’ll check soon.

It seems like rtscts behavior changed on windows pyserial. I’ll investigate

6

Avron would you mind posting the output for “meshtastic --debug --info” on your machine?

7

I upgraded two t-beams v1, one with the ublox 6 and the other ublox 8, with 1.2.30.
One was flashed as an update from the terminal, the other is a fresh install using espHome Flasher.

Both devices seem to reset themselves randomly. I haven’t tested this in detail yet but after 5-6 min, after no interaction with the device, the startup screen with the meshtastic logo shows.
I’ve tested it several times now and it happens without a fail, but I am not sure what causes it. This is on battery, in a solid case so I am not suspecting a bad contact. Waiting a bit longer i observed the same with the other device. I had noted before that the last message received had reverted to an earlier message for some reason.

2 Likes
8

Here you go:

meshtastic --debug --info
DEBUG:root:Not logging serial output
DEBUG:root:Connecting to COM11
DEBUG:root:Sending: want_config_id: 1028296544
DEBUG:root:Received myinfo: my_node_num: 2988735988 has_gps: true num_bands: 20 firmware_version: “1.2.30.80e4bc6” reboot_count: 8 message_timeout_msec: 300000 min_app_version: 20200 max_channels: 8
DEBUG:root:Received nodeinfo: {‘num’: 2988735988, ‘user’: {‘id’: ‘!b2247df4’, ‘longName’: ‘A W 7df4’, ‘shortName’: ‘AW7’, ‘macaddr’: ‘rGeyJH30’, ‘hwModel’: ‘TBEAM’}, ‘position’: {‘latitudeI’: -337131854, ‘longitudeI’: 1510676976, ‘altitude’: 182, ‘batteryLevel’: 100, ‘time’: 1620166864, ‘latitude’: -33.7131854, ‘longitude’: 151.0676976}, ‘lastHeard’: 1620166864}
DEBUG:root:Received nodeinfo: {‘num’: 84685580, ‘user’: {‘id’: ‘!050c330c’, ‘longName’: ‘Node Red 330c’, ‘shortName’: ‘NR3’, ‘macaddr’: ‘PGEFDDMM’, ‘hwModel’: ‘TBEAM’}, ‘position’: {‘batteryLevel’: 100, ‘time’: 1620087150}, ‘lastHeard’: 1620166856, ‘snr’: 8.75}
DEBUG:root:Config complete ID 1028296544
DEBUG:root:Serializing protobuf as data: get_radio_request: true
DEBUG:root:Sending: packet { to: 2988735988 decoded { portnum: ADMIN_APP payload: " \001" want_response: true } id: 1923491386 hop_limit: 3 want_ack: true }
DEBUG:root:Received radio config, now fetching channels…
DEBUG:root:Requesting channel 0
DEBUG:root:Serializing protobuf as data: get_channel_request: 1
DEBUG:root:Sending: packet { to: 2988735988 decoded { portnum: ADMIN_APP payload: “0\001” want_response: true } id: 1923491387 hop_limit: 3 want_ack: true }
DEBUG:root:Publishing meshtastic.receive.admin: packet={‘from’: 2988735988, ‘to’: 2988735988, ‘decoded’: {‘portnum’: ‘ADMIN_APP’, ‘payload’: b’\x17\n\x15\x08\xac\x02 \x140\x84\x07P\xac\x02x\x06\x90\x02\xac\x02\xa0\x02\xd8\x04’, ‘requestId’: 1923491386, ‘admin’: {‘getRadioResponse’: {‘preferences’: {‘positionBroadcastSecs’: 300, ‘waitBluetoothSecs’: 20, ‘phoneTimeoutSecs’: 900, ‘lsSecs’: 300, ‘region’: ‘ANZ’, ‘gpsUpdateInterval’: 300, ‘gpsAttemptTime’: 600}}, ‘raw’: get_radio_response { preferences { position_broadcast_secs: 300 wait_bluetooth_secs: 20 phone_timeout_secs: 900 ls_secs: 300 region: ANZ gps_update_interval: 300 gps_attempt_time: 600 } } }}, ‘id’: 756703530, ‘rxTime’: 1620166865, ‘hopLimit’: 3, ‘priority’: ‘RELIABLE’, ‘raw’: from: 2988735988 to: 2988735988 decoded { portnum: ADMIN_APP payload: "\027\n\025\010\254\002 \0240\204\007P\254\002x\006\220\002\254\002\240\002\330\004" request_id: 1923491386 } id: 756703530 rx_time: 1620166865 hop_limit: 3 priority: RELIABLE , ‘fromId’: ‘!b2247df4’, ‘toId’: ‘!b2247df4’}
DEBUG:root:Received channel settings { modem_config: Bw125Cr48Sf4096 psk: “\001” bandwidth: 125 spread_factor: 10 coding_rate: 8 } role: PRIMARY
DEBUG:root:Requesting channel 1
DEBUG:root:Serializing protobuf as data: get_channel_request: 2
DEBUG:root:Sending: packet { to: 2988735988 decoded { portnum: ADMIN_APP payload: “0\002” want_response: true } id: 1923491388 hop_limit: 3 want_ack: true }
DEBUG:root:Publishing meshtastic.receive.admin: packet={‘from’: 2988735988, ‘to’: 2988735988, ‘decoded’: {‘portnum’: ‘ADMIN_APP’, ‘payload’: b’:\x0f\x12\x0b\x18\x03"\x01\x010}8\n@\x08\x18\x01’, ‘requestId’: 1923491387, ‘admin’: {‘getChannelResponse’: {‘settings’: {‘modemConfig’: ‘Bw125Cr48Sf4096’, ‘psk’: ‘AQ==’, ‘bandwidth’: 125, ‘spreadFactor’: 10, ‘codingRate’: 8}, ‘role’: ‘PRIMARY’}, ‘raw’: get_channel_response { settings { modem_config: Bw125Cr48Sf4096 psk: “\001” bandwidth: 125 spread_factor: 10 coding_rate: 8 } role: PRIMARY } }}, ‘id’: 756703531, ‘rxTime’: 1620166865, ‘hopLimit’: 3, ‘priority’: ‘RELIABLE’, ‘raw’: from: 2988735988 to: 2988735988 decoded { portnum: ADMIN_APP payload: “:\017\022\013\030\003"\001\0010}8\n@\010\030\001” request_id: 1923491387 } id: 756703531 rx_time: 1620166865 hop_limit: 3 priority: RELIABLE , ‘fromId’: ‘!b2247df4’, ‘toId’: ‘!b2247df4’}
DEBUG:root:Received channel index: 1 settings { psk: “N3\0142ayCW\215w\0336\335w\271\033\212\312e\254\214A"q\027<\006V\310\014\323\301” name: “admin” } role: SECONDARY
DEBUG:root:Requesting channel 2
DEBUG:root:Serializing protobuf as data: get_channel_request: 3
DEBUG:root:Sending: packet { to: 2988735988 decoded { portnum: ADMIN_APP payload: “0\003” want_response: true } id: 1923491389 hop_limit: 3 want_ack: true }
DEBUG:root:Publishing meshtastic.receive.admin: packet={‘from’: 2988735988, ‘to’: 2988735988, ‘decoded’: {‘portnum’: ‘ADMIN_APP’, ‘payload’: b’:/\x08\x01\x12)" N3\x0c2ayCW\x8dw\x1b6\xddw\xb9\x1b\x8a\xcae\xac\x8cA"q\x17<\x06V\xc8\x0c\xd3\xc1*\x05admin\x18\x02’, ‘requestId’: 1923491388, ‘admin’: {‘getChannelResponse’: {‘index’: 1, ‘settings’: {‘psk’: ‘TjMMMmF5Q1eNdxs23Xe5G4rKZayMQSJxFzwGVsgM08E=’, ‘name’: ‘admin’}, ‘role’: ‘SECONDARY’}, ‘raw’: get_channel_response { index: 1 settings { psk: “N3\0142ayCW\215w\0336\335w\271\033\212\312e\254\214A"q\027<\006V\310\014\323\301” name: “admin” } role: SECONDARY } }}, ‘id’: 756703532, ‘rxTime’: 1620166865, ‘hopLimit’: 3, ‘priority’: ‘RELIABLE’, ‘raw’: from: 2988735988 to: 2988735988 decoded { portnum: ADMIN_APP payload: “:/\010\001\022)" N3\0142ayCW\215w\0336\335w\271\033\212\312e\254\214A"q\027<\006V\310\014\323\301*\005admin\030\002” request_id: 1923491388 } id: 756703532 rx_time: 1620166865 hop_limit: 3 priority: RELIABLE , ‘fromId’: ‘!b2247df4’, ‘toId’: ‘!b2247df4’}
DEBUG:root:Received channel index: 2 settings { }
DEBUG:root:Finished downloading channels
DEBUG:root:Sending heartbeat, interval 450.0
Connected to radio
DEBUG:root:Serializing protobuf as data: time: 1620166864
DEBUG:root:Sending:
DEBUG:root:Sending: packet { to: 4294967295 decoded { portnum: POSITION_APP payload: “M\320\310\221`” } id: 1923491390 hop_limit: 3 }
DEBUG:root:Publishing meshtastic.receive.admin: packet={‘from’: 2988735988, ‘to’: 2988735988, ‘decoded’: {‘portnum’: ‘ADMIN_APP’, ‘payload’: b’:\x04\x08\x02\x12\x00’, ‘requestId’: 1923491389, ‘admin’: {‘getChannelResponse’: {‘index’: 2, ‘settings’: {}}, ‘raw’: get_channel_response { index: 2 settings { } } }}, ‘id’: 756703533, ‘rxTime’: 1620166865, ‘hopLimit’: 3, ‘priority’: ‘RELIABLE’, ‘raw’: from: 2988735988 to: 2988735988 decoded { portnum: ADMIN_APP payload: “:\004\010\002\022\000” request_id: 1923491389 } id: 756703533 rx_time: 1620166865 hop_limit: 3 priority: RELIABLE , ‘fromId’: ‘!b2247df4’, ‘toId’: ‘!b2247df4’}

Owner: Avron W 7df4 (AW7)

My info: { “myNodeNum”: 2988735988, “hasGps”: true, “numBands”: 20, “firmwareVersion”: “1.2.30.80e4bc6”, “rebootCount”: 8, “messageTimeoutMsec”: 300000, “minAppVersion”: 20200, “maxChannels”: 8 }

Nodes in mesh:
{‘num’: 2988735988, ‘user’: {‘id’: ‘!b2247df4’, ‘longName’: ‘Avron W 7df4’, ‘shortName’: ‘AW7’, ‘macaddr’: ‘rGeyJH30’, ‘hwModel’: ‘TBEAM’}, ‘position’: {‘latitudeI’: -337131854, ‘longitudeI’: 1510676976, ‘altitude’: 182, ‘batteryLevel’: 100, ‘time’: 1620166864, ‘latitude’: -33.7131854, ‘longitude’: 151.0676976}, ‘lastHeard’: 1620166864}
{‘num’: 84685580, ‘user’: {‘id’: ‘!050c330c’, ‘longName’: ‘Node Red 330c’, ‘shortName’: ‘NR3’, ‘macaddr’: ‘PGEFDDMM’, ‘hwModel’: ‘TBEAM’}, ‘position’: {‘batteryLevel’: 100, ‘time’: 1620087150}, ‘lastHeard’: 1620166856, ‘snr’: 8.75}

Preferences: { “positionBroadcastSecs”: 300, “waitBluetoothSecs”: 20, “phoneTimeoutSecs”: 900, “lsSecs”: 300, “region”: “ANZ”, “gpsUpdateInterval”: 300, “gpsAttemptTime”: 600 }

Channels:
PRIMARY psk=default { “modemConfig”: “Bw125Cr48Sf4096”, “psk”: “AQ==”, “bandwidth”: 125, “spreadFactor”: 10, “codingRate”: 8 }
SECONDARY psk=secret { “psk”: “TjMMMmF5Q1eNdxs23Xe5G4rKZayMQSJxFzwGVsgM08E=”, “name”: “admin” }

Primary channel URL: Meshtastic URL | Meshtastic
Complete URL (includes all channels): Meshtastic URL | Meshtastic

DEBUG:root:Closing stream
DEBUG:root:Sending: disconnect: true
DEBUG:root:reader is exiting
DEBUG:root:Closing our port

1 Like
9

Ooh. It would be super useful if you could leave a serial port attached and when it reboots capture the “crash report” it prints. If you could send that report to me (with your device model) I could quickly see the cause.

(Btw last message received will revert if the board unexpectedly resets, because we only save that info to flash on clean reboots)

10

I noticed this on one of my modules. It only happened once to one of my radios as it
randomly rebooted in the night.

I’ve also sometimes noticed that the little thing that tells you when a radio has last responded sometimes shows up as a absurdly high hour count. Usually when recently rebooted.

1 Like
11

I am still experimenting with capturing a crash report now and it seems that whatever device is connected to usb with serial logging enabled is

  • not able to connect via bluetooth in addition (I assume this is normal)

  • does not crash
    whereas the device unattached to serial via usb crashes as prior (but possibly only after it has seen and connected to a router node running an older version of the firmware, I think 1.2.20).
    The usb serial connected device now does not crash despite seeing the router node.
    Could this mean that the crash is related to the bluetooth connection?
    Or that it is related to waking from sleep and therefore not reproducible when hooked up to usb power?

I’ve just filed a bug report from the app running on a Huawei Honor for the device not connected to serial after it reset itself (named 3PK, a tbeam T22_V1.0 with ublox NEO-M8N. The red LED next to the GPS module stays permanently lit on this one, it does not on the Neo-6M). Its in a network with three other devices, 1PK, 4PK and RPK (this is running as a router).

1 Like
12

Also sent a bug report from a Sony Experia Z3 linked to 1PK afer this reset (although not sure when exactly the reset happened

1 Like
13

I occasionally will see “Device Sleeping” on the app for one of the radios now, but this is not correct. Disconnecting and reconnecting addresses this. Any messages attempted to be sent just results in a cloud with an arrow. Reconnecting will make the message send.
It seems more likely to happen if I walk out of bluetooth range and back again.

2 Likes
14

I’ve noticed the same behaviour. SmugHatLoli’s description is spot on.

The other main bugs seem to have been squashed. B8b8 and I have done quite a bit of testing across our mesh and it is performing much better! Thanks Geeksville!

2 Likes
15

@geeksville could you include Rak4630 in releases? Or some documentation on what to edit?

16

I’ve tested admin channel and gpio channel. Both are working well. I’ve noticed the following…

Anytime you do a --ch-add, both nodes need a reboot or you’ll get timeouts when trying to do --dest commands. Maybe not

--ch-add

but

meshtastic --dest \!12345678 --seturl https://www.meshtastic.org/d/#completeurl

It’s hard to say which requires the reboot because both need to happen.

--dest \!12345678 --nodes

Returns the node list of the local node, not the remote.

1 Like
17

Re: rak4630
It is included. I’ll make a doc soon. But in short:

Power cycle the board so it stays in bootloader. A special “USB drive” will appear on your computer. Drag and drop the uf2 file from our zip onto that drive. The bootloader will magically install the app and run it.

2 Likes
18

Thanks for that description.

19

I am having identical problem since updating to 1.2.30.

I’m too inexperienced in Python to know how to fix it or if there is a fix? Can the timeout parameter be changed in Python? If so, could you give me the appropriate command to do so?

If it helps, my timeouts became increasingly frequent until the radios don’t respond at all now.

20

Coming back to this again after quite a bit of testing, I have now managed to identify a somewhat more reproducible way of causing resets on T-beams v1.0 over the air.

A single node running 1.2.30 with one encrypted channel can sit without resets permanently (I tested 23+h without a single reset)

With four nodes on the mesh, all flashed with 1.2.30, I see a reset every ~24 min or so (based on about 25 resets in 10h). These occur even if no messages are actively sent. On the two nodes that have a screen I can see that they often reset almost simultaneously.
I’ve tested this with the nodes nodes connected via bluetooth and not, with and without admin channels enabled.
The most reproducible way has been to have a remote node with an admin channel enabled. A reset is triggered in the remote node when meshtastic —debug is sent to a USB connected node. (one might have to wait a couple of minutes if the remote device is sleeping).
I am unable to reproducibly induce this behaviour if the remote node does not have an admin channel enabled.

I therefore thought the resets occur only if the admin channel is enabled on the remote node, but after reflashing and only activating the primary channel in all nodes, two nodes nevertheless still reset after a few minutes (even without meshtastic —debug) just as I was writing this (both without USB connection, externally powered nodes don’t seem to reset).

It seems whatever is sent periodically in the mesh without user interaction might also be sent when running meshtastic —debug, and that this can cause the resets.

Can anybody else reproduce this? As mentioned previously, I cannot seem reproduce this if the nodes are powered.

2 Likes