Module rebooting with Send Message

Support Python API
1

Hi,
I try to send a message with the following command:

meshtastic --device "/dev/tty.SLAB_USBtoUART" --sendtext "HelLoWww 15:25 a " --dest "862621965" --debug

But I see the module restarting at something like 9/10 of the time on the other module, not message received

Modules: T-Beam V1.1 w/ NEO-6M
Firmware: 0.9.5
Python library version: updated today (12/09)

is it the same bug: https://github.com/meshtastic/Meshtastic-device/issues/351 ?

If yes, is there another way (maybe not Python ) to send and receive messages?

Thank you

meshtastic --device "/dev/tty.SLAB_USBtoUART" --sendtext "HelLoWww 15:42 a " --dest "862621965" --debug
DEBUG:root:Connecting to /dev/tty.SLAB_USBtoUART
DEBUG:root:Sending: want_config_id: 42

??????????????????????????????????????????????????Emitting reboot packet for serial shell
DEBUG:root:Received: {'rebooted': True}
DEBUG:root:Sending: want_config_id: 42

booted, wake cause 0 (boot count 1), reset_reason=reset
I2C device found at address 0x3c
ssd1306 display found
done
Meshtastic swver=0.9.5, hwver=1.0-EU865
Setting random seed 688163975
Total heap: 265492
Free heap: 238292
Total PSRAM: 4194252
Free PSRAM: 4194252
NVS: UsedEntries 68, FreeEntries 562, AllEntries 630
AXP192 not found
Turning on screen
Read RTC time as 0 (cur millis 101) valid=0
Connected to UBLOX GPS successfully
RadioConfig reset!
Installing AES128 key!
Initial packet id 2083774665, numPacketId 4294967295
Loading saved preferences
Loaded saved preferences version 11
Installing AES128 key!
NODENUM=0x336a8e95, dbsize=1
Starting meshradio init...
Set radio: name=Default, config=3, ch=0, power=17
RF95 init result 0
[D][esp32-hal-cpu.c:189] setCpuFrequencyMhz(): PLL: 320 / 4 = 80 Mhz, APB: 80000000 Hz
GPS fix type 0
Ignoring invalid GPS month=11, year=-1901, unixtime=-2040326656
New GPS pos lat=0.000000, lon=0.000000, alt=0, pdop=0.000000, heading=0.000000, sats=255
Sending position to mesh
Update DB node 0x336a8e95, rx_time=0
Node status update: 1 online, 1 total
showing standard frames
Providing time to mesh 0
Adding packet record (id=0x7c33e0cc Fr0x95 To0xff, WantAck0, HopLim3 Payload:Position)
enqueuing for send (id=0x7c33e0cc Fr0x95 To0xff, WantAck0, HopLim3 encrypted)
txGood=0,rxGood=0,rxBad=0
Screen: Started...
sending owner !c44f336a8e95/Unknown 8e95/?95
Update DB node 0x336a8e95, rx_time=0
old user !c44f336a8e95/Unknown 8e95/?95
updating changed=0 user !c44f336a8e95/Unknown 8e95/?95
Adding packet record (id=0x7c33e0cd Fr0x95 To0xff, WantAck0, HopLim3 Payload:User)
enqueuing for send (id=0x7c33e0cd Fr0x95 To0xff, WantAck0, HopLim3 encrypted)
txGood=0,rxGood=0,rxBad=0
showing standard frames
Starting low level send (id=0x7c33e0cc Fr0x95 To0xff, WantAck0, HopLim3 encrypted)
Transition powerFSM transition=boot timeout, from=BOOT to=ON
Setting bluetooth enable=1
Pre BT: 222624 heap size
Starting bluetooth
BLE task running
registered service 0x1800 with handle=1
registered service 0x1801 with handle=6
registered service 6ba1b218-15a8-461f-9fa8-5dcae273eafd with handle=10
registered service cb0b9a0b-a84c-4c0d-bdbb-442e3144ee30 with handle=18
BLE advertisting type=0, Private=0, Device Address: 39:c4:4f:33:6a:8e

Completed sending (id=0x7c33e0cc Fr0x95 To0xff, WantAck0, HopLim3 encrypted)
Can not send yet, busyRx
Can not send yet, busyRx
Can not send yet, busyRx
Lora RX (id=0x77ddade1 Fr0x0d To0x95, WantAck0, HopLim3 encrypted rxSNR=11)
Adding packet record (id=0x77ddade1 Fr0x0d To0x95, WantAck0, HopLim3 encrypted rxSNR=11)
FIXME not implementedFIXME-update-db Sniffing packet
Delivering rx packet (id=0x77ddade1 Fr0x0d To0x95, WantAck0, HopLim3 Payload:User rxSNR=11)
Trigger powerFSM 3
Ignoring incoming time, because we have a GPS
Forwarding to phone (id=0x77ddade1 Fr0x0d To0x95, WantAck0, HopLim3 Payload:User rxSNR=11)
Update DB node 0x336a910d, rx_time=0
old user //
updating changed=1 user !c44f336a910d/Unknown 910d/?0D
Trigger powerFSM 8
Transition powerFSM transition=NodeDB update, from=ON to=ON
Node status update: 2 online, 2 total
showing standard frames
Telling client we have new packets 1
Telling client we have new packets 1
No BLE notify
Starting low level send (id=0x7c33e0cd Fr0x95 To0xff, WantAck0, HopLim3 encrypted)
GPS fix type 0
Setting RTC 1599918119 secs
Read RTC time as 1599918119 (cur millis 12246) valid=1
New GPS pos lat=48.842999, lon=2.404238, alt=27, pdop=0.000000, heading=0.000000, sats=255
Update DB node 0x336a8e95, rx_time=1599918119
Node status update: 1 online, 2 total
Completed sending (id=0x7c33e0cd Fr0x95 To0xff, WantAck0, HopLim3 encrypted)
GPS fix type 0
New GPS pos lat=48.842999, lon=2.404238, alt=27, pdop=99.990000, heading=0.000000, sats=0
Update DB node 0x336a8e95, rx_time=1599918129
Node status update: 1 online, 2 total
Lora RX (id=0x7c33e0cd Fr0x95 To0xff, WantAck0, HopLim2 encrypted rxSNR=9.25)
Rx someone rebroadcasting for us (id=0x7c33e0cd Fr0x95 To0xff, WantAck0, HopLim2 encrypted rxSNR=9.25)
Found existing packet record for fr=0x336a8e95,to=0xffffffff,id=2083774669
Ignoring incoming msg, because we've already seen it: fr=0x336a8e95,to=0xffffffff,id=2083774669,hop_limit=2
Trigger powerFSM 9
Trigger powerFSM 11
Transition powerFSM transition=serial API, from=ON to=SERIAL
Shutdown BT: 236552 heap size
DEBUG:root:Received: {'myInfo': {'myNodeNum': 862621333, 'hasGps': True, 'numChannels': 10, 'region': '1.0-EU865', 'hwModel': 'tbeam', 'firmwareVersion': '0.9.5', 'packetIdBits': 32, 'currentPacketId': 2083774671, 'nodeNumBits': 32, 'messageTimeoutMsec': 300000, 'minAppVersion': 172}}
DEBUG:root:Received: {'radio': {'preferences': {'positionBroadcastSecs': 900, 'sendOwnerInterval': 4, 'waitBluetoothSecs': 120, 'screenOnSecs': 300, 'phoneTimeoutSecs': 900, 'phoneSdsTimeoutSec': 7200, 'meshSdsTimeoutSecs': 7200, 'sdsSecs': 31536000, 'lsSecs': 3600}, 'channelSettings': {'modemConfig': 'Bw125Cr48Sf4096', 'psk': '1PG7OiApB1nwvP+rz05pvw==', 'name': 'Default'}}}
DEBUG:root:Received: {'nodeInfo': {'num': 862621333, 'user': {'id': '!c44f336a8e95', 'longName': 'Unknown 8e95', 'shortName': '?95', 'macaddr': 'xE8zao6V'}, 'position': {'altitude': 27, 'latitudeI': 488429988, 'longitudeI': 24042377, 'time': 1599918129}}}
DEBUG:root:Received: {'nodeInfo': {'num': 862621965, 'user': {'id': '!c44f336a910d', 'longName': 'Unknown 910d', 'shortName': '?0D', 'macaddr': 'xE8zapEN'}, 'snr': 11.0}}
DEBUG:root:Node without position
DEBUG:root:Received: {'configCompleteId': 42}
Connected to radio
Sending text message HelLoWww 15:42 a  to 862621965
'862621965'
DEBUG:root:Received: {'packet': {'from': 862621965, 'to': 862621333, 'decoded': {'user': {'id': '!c44f336a910d', 'longName': 'Unknown 910d', 'shortName': '?0D', 'macaddr': 'xE8zapEN'}}, 'id': 2011016673, 'rxSnr': 11.0, 'hopLimit': 3}}
Received: {'from': 862621965, 'to': 862621333, 'decoded': {'user': {'id': '!c44f336a910d', 'longName': 'Unknown 910d', 'shortName': '?0D', 'macaddr': 'xE8zapEN'}}, 'id': 2011016673, 'rxSnr': 11.0, 'hopLimit': 3, 'fromId': '!c44f336a910d', 'toId': '!c44f336a8e95'}
DEBUG:root:Closing serial stream
DEBUG:root:reader is exiting
2

It probably is the same issue. There are a couple of funny clues/ideas related to this:

  • I’ve been unable to reproduce this
  • The only reports of it are both where the host is OS-X (not linux)
  • … though the host shouldn’t matter cause we are just talking serial
  • The reset_reason is reset - so, not an internal failure (probably), but rather the PMU pulsed the reset line to the CPU
  • Theory: The TBEAM is drawing a bit more than the 500mA max it is supposed to from USB when it is transmitting and the Mac is strict on that and then blipping the power when it happens (causing a reboot)
  • Question: Do you have a battery installed in your tbeam?
  • Question: Are you connected directly to the mac or via an external powered hub. If not the latter can you try such a hub and report back? (to help isolate the problem)

cc @mc-hamster because relevant to his original report

3
  • Question: Do you have a battery installed in your tbeam?

Yes

  • Question: Are you connected directly to the mac or via an external powered hub. If not the latter can you try such a hub and report back? (to help isolate the problem)

It was originally plugged into a powered USBC -> 10 Port usb hub.
I just plugged it straight in the back of the MacMini and got the same problem.

4

It may have to do with how the python serial library does flow control or our use of the python serial library.

The ttgo schematic shows that RTS and DTR goes to the reset pins of the ESP32. My theory is DTR is being toggled and causing the uC to restart.

image

3 Likes
5

ooh thats the best theory! smart!

6

I got it to work without restart on my side.

in init.py, add this line:

self.stream.setRTS(False)

Right below:

    self.stream = serial.Serial(
        devPath, 921600, exclusive=True, timeout=0.5)

@geeksville Could you try that out on your side? I don’t know how Linux or Windows would behave with that change, but it should be transparent.

2 Likes
7

works great! I’ll check it in and spit out a new 1.0.4 build in a few minutes!

3 Likes
8

Hi thank you both,
It fixes the reboot issue on my side too

1 Like
9

I am having this same issue on multiple windows computer. Even when I do a meshtastic --port COM10 --info the device will restart after sending the command.

Trying to find where the init.py file ended up so I can test the possible fix.