Closed adingbatponder closed 22 hours ago
Does it forward packets normally or are certain length messages not forwarded?
This issue has been mentioned on Meshtastic. There might be relevant details there:
https://meshtastic.discourse.group/t/t114-fails-to-send-messages-above-certain-length/14719/1
Can you try setting a lower transmit power (e.g. 3 dBm) and see if the issue persists?
I'm trying to figure out if it's a hardware issue (e.g. unstable power supply or EMC issues) or something else.
Lowering the transmit power to 3 dbm did the trick! it transmitted for me from one T114 to another (DM), longfast. 3dbm --> success 5dbm-->success 7dbm--> success but slight delay 8dbm--> failure 10dbm-->failure But even with the 3db setting I was not able to successfully send a max length/characters message.
exact same behaviour here - ok below 8db
I tried going back to earlier firmware 2.4.xxx, no improvement
I am on 2.5 most recent release. If this issue is hardware based its bad, really bad!! because how I see it now every T114 so far is affected.
My T114 is running 2.4.2 and I just sent a 71 character message to LongFast. Received successfully on my T-Deck (2.4.2).
Also tested to send from my T114 ( stock 27dbm) to my Heltec V3 a much longer message then 71 (150) successfully 3 times out of 4. #longfast DM
Today at 27dBm I can send around 60 character messages, up to 30 characters no problem after that I had to resend a couple of messages.
At 3dBm I'm managing to send 200 character messages (stopped there as I wasn't sure what the limit is) and they've been getting through no problem.
can send 144-char (base64 encoded, and 107-char decoded) messages with tx_power
set to 5. (more info in reddit reply)
Same message was not reliably sent when having tx_power set to 27. Will test further and update this reply as I go.
Thinking out loud... Given this symptom combined with some of the sporadic BLE issues, I wonder if we're looking at some hardware level issues with the LDO converter not being able to supply enough current to the MCU + peripherals under certain loads.
Would a big enough capacitor at the LDO be able to buffer that?
Would a big enough capacitor at the LDO be able to buffer that?
Potentially. If someone is willing to sacrifice hardware modifications in the name of science, we can find out. 😅
Q) Does everyone above have the version with a screen? GPS?
Screen+ GPS and Screen no GPS but lots of other added stuff like vibra, buzzer ( both fired by a mosfet feeded directly from the 3.3volt rail) and a smd LED but that barely falls into weight as that stuff only fires up when receiving a message. I have to retry with a unmodified T114 as well when I get home but I am pretty sure it will be the same outcome pretty much. One thing I also noticed is that the screen dims slightly whenever a message is sent.
Q) Does everyone above have the version with a screen? GPS?
Screen and GPS.
Screen and GPS for me too.
On Tue, 17 Sept 2024 at 07:16, DTopp @.***> wrote:
Q) Does everyone above have the version with a screen? GPS?
Screen and GPS.
— Reply to this email directly, view it on GitHub https://github.com/meshtastic/firmware/issues/4723#issuecomment-2355977328, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIMTLW7DOBYX6PGAGO2P5TZXA2VHAVCNFSM6AAAAABOIBAVMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJVHE3TOMZSHA . You are receiving this because you commented.Message ID: @.***>
--
neilmartin
Thinking out loud... Given this symptom combined with some of the sporadic BLE issues, I wonder if we're looking at some hardware level issues with the LDO converter not being able to supply enough current to the MCU + peripherals under certain loads.
I would have suspected the same thing, but I've got it on the scope right now though and I can't measure any significant dip in voltage when transmitting. This was with screen only, powered by USB. I'll connect the GPS and see if it changes.
Update: no change with GPS. Drawing ~150mA from 5V supply when transmitting. To my untrained eye, the 3.3V looks pretty solid, at least on my device.
Update 2: I'm actually having trouble replicating the issue at all, so my report might not be that helpful. Long DM's seem to be going through fine for me right now. Could be good to get some observations instead from devices which are struggling.
This is with tonight's master (a967dd5)
I've managed to reproduce on a T114 no GPS and no screen. So it looks like those are not factors.
Current master (2024-09-18).
logs:
DEBUG | 02:07:24 465 [Router] Module 'routing' considered
INFO | 02:07:24 465 Telling client we have new packets 45
INFO | 02:07:24 465 BLE notify fromNum
INFO | 02:07:24 465 getFromRadio=STATE_SEND_PACKETS
DEBUG | 02:07:24 465 phone downloaded packet (id=0xff6785a8 fr=0x3f to=0x3f, WantAck=0, HopLim=4 Ch=0x0 Portnum=5 requestId=216334ae rxtime=1726625244 priority=120)
DEBUG | 02:07:24 465 [Power] Battery: usbPower=0, isCharging=0, batMv=3973, batPct=78
DEBUG | 02:07:25 466 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=52, time 624 ms
DEBUG | 02:07:25 466 [RadioIf] Lora RX (id=0x3067a0f4 fr=0x48 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=3 rxRSSI=-92 hopStart=7)
DEBUG | 02:07:25 466 [RadioIf] AirTime - Packet received : 624ms
DEBUG | 02:07:25 466 [Router] Found existing packet record for fr=0x335c2d48,to=0xffffffff,id=0x3067a0f4
DEBUG | 02:07:25 466 [Router] Found existing packet record for fr=0x335c2d48,to=0xffffffff,id=0x3067a0f4
DEBUG | 02:07:25 466 [Router] Add packet record (id=0x3067a0f4 fr=0x48 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=3 rxRSSI=-92 hopStart=7)
DEBUG | 02:07:25 466 [Router] Ignoring incoming msg we've already seen (id=0x3067a0f4 fr=0x48 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=3 rxRSSI=-92 hopStart=7)
DEBUG | 02:07:25 466 [Router] cancelSending id=0x3067a0f4, removed=0
DEBUG | 02:07:25 466 [Router] Incoming message was filtered from 0x335c2d48
DEBUG | 02:07:27 468 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=52, time 624 ms
DEBUG | 02:07:27 468 [RadioIf] Lora RX (id=0x3067a0f4 fr=0x48 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=7 rxRSSI=-32 hopStart=7)
DEBUG | 02:07:27 468 [RadioIf] AirTime - Packet received : 624ms
DEBUG | 02:07:27 468 [Router] Found existing packet record for fr=0x335c2d48,to=0xffffffff,id=0x3067a0f4
DEBUG | 02:07:27 468 [Router] Found existing packet record for fr=0x335c2d48,to=0xffffffff,id=0x3067a0f4
DEBUG | 02:07:27 468 [Router] Add packet record (id=0x3067a0f4 fr=0x48 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=7 rxRSSI=-32 hopStart=7)
DEBUG | 02:07:27 468 [Router] Ignoring incoming msg we've already seen (id=0x3067a0f4 fr=0x48 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=7 rxRSSI=-32 hopStart=7)
DEBUG | 02:07:27 468 [Router] cancelSending id=0x3067a0f4, removed=0
DEBUG | 02:07:27 468 [Router] Incoming message was filtered from 0x335c2d48
DEBUG | 02:07:28 469 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=98, time 968 ms
DEBUG | 02:07:28 469 [RadioIf] Lora RX (id=0x3feb7e38 fr=0x0c to=0x48, WantAck=0, HopLim=4 Ch=0x8 encrypted rxSNR=7 rxRSSI=-31 hopStart=4)
DEBUG | 02:07:28 469 [RadioIf] AirTime - Packet received : 968ms
DEBUG | 02:07:28 469 [Router] Add packet record (id=0x3feb7e38 fr=0x0c to=0x48, WantAck=0, HopLim=4 Ch=0x8 encrypted rxSNR=7 rxRSSI=-31 hopStart=4)
DEBUG | 02:07:28 469 [Router] Using channel 0 (hash 0x8)
DEBUG | 02:07:28 469 [Router] Expanding short PSK #1
DEBUG | 02:07:28 469 [Router] Using AES128 key!
DEBUG | 02:07:28 469 [Router] decoded message (id=0x3feb7e38 fr=0x0c to=0x48, WantAck=0, HopLim=4 Ch=0x0 Portnum=4 WANTRESP rxtime=1726625248 rxSNR=7 rxRSSI=-31 hopStart=4)
DEBUG | 02:07:28 469 [Router] handleReceived(REMOTE) (id=0x3feb7e38 fr=0x0c to=0x48, WantAck=0, HopLim=4 Ch=0x0 Portnum=4 WANTRESP rxtime=1726625248 rxSNR=7 rxRSSI=-31 hopStart=4)
DEBUG | 02:07:28 469 [Router] Module 'nodeinfo' wantsPacket=1
INFO | 02:07:28 469 [Router] Received nodeinfo from=0x433b830c, id=0x3feb7e38, portnum=4, payloadlen=74
DEBUG | 02:07:28 469 [Router] old user TWMesh 830c/TW83, channel=0
DEBUG | 02:07:28 469 [Router] Incoming Pubkey: : 50 11 a3 bc 3a 5a dd 04 e9 65 d1 d3 cd 83 c7 03 bd b9 f9 35 7f 73 9b 80 ad 79 0f 9d d3 3e 51 2c
INFO | 02:07:28 469 [Router] Public Key set for node, not updating!
DEBUG | 02:07:28 469 [Router] Saved Pubkey: : 50 11 a3 bc 3a 5a dd 04 e9 65 d1 d3 cd 83 c7 03 bd b9 f9 35 7f 73 9b 80 ad 79 0f 9d d3 3e 51 2c
DEBUG | 02:07:28 469 [Router] updating changed=0 user TWMesh 830c/TW83, channel=0
DEBUG | 02:07:28 469 [Router] Module 'nodeinfo' considered
DEBUG | 02:07:28 469 [Router] Module 'routing' wantsPacket=1
INFO | 02:07:28 469 [Router] Received routing from=0x433b830c, id=0x3feb7e38, portnum=4, payloadlen=74
DEBUG | 02:07:28 469 [Router] Routing sniffing (id=0x3feb7e38 fr=0x0c to=0x48, WantAck=0, HopLim=4 Ch=0x0 Portnum=4 WANTRESP rxtime=1726625248 rxSNR=7 rxRSSI=-31 hopStart=4)
DEBUG | 02:07:28 469 [Router] Not rebroadcasting. Role = Role_ClientMute
DEBUG | 02:07:28 469 [Router] Module 'routing' considered
INFO | 02:07:29 470 [DeviceTelemetryModule] (Sending): air_util_tx=0.159861, channel_utilization=17.653332, battery_level=78, voltage=3.973000, uptime=470
DEBUG | 02:07:29 470 [DeviceTelemetryModule] Partially randomized packet id 2912681385
DEBUG | 02:07:29 470 [DeviceTelemetryModule] updateTelemetry LOCAL
DEBUG | 02:07:29 470 [DeviceTelemetryModule] Node status update: 8 online, 42 total
INFO | 02:07:29 470 [DeviceTelemetryModule] Sending packet to phone
INFO | 02:07:29 470 Telling client we have new packets 46
INFO | 02:07:29 470 BLE notify fromNum
INFO | 02:07:29 470 getFromRadio=STATE_SEND_PACKETS
DEBUG | 02:07:29 470 phone downloaded packet (id=0xad9bfda9 fr=0x3f to=0xff, WantAck=0, HopLim=4 Ch=0x0 Portnum=67 rxtime=1726625249 priority=10)
DEBUG | 02:07:31 472 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=96, time 952 ms
DEBUG | 02:07:31 472 [RadioIf] Lora RX (id=0x3feb7e38 fr=0x0c to=0x48, WantAck=0, HopLim=3 Ch=0x8 encrypted rxSNR=2.25 rxRSSI=-93 hopStart=4)
DEBUG | 02:07:31 472 [RadioIf] AirTime - Packet received : 952ms
DEBUG | 02:07:31 472 [Router] Found existing packet record for fr=0x433b830c,to=0x335c2d48,id=0x3feb7e38
DEBUG | 02:07:31 472 [Router] Found existing packet record for fr=0x433b830c,to=0x335c2d48,id=0x3feb7e38
DEBUG | 02:07:31 472 [Router] Add packet record (id=0x3feb7e38 fr=0x0c to=0x48, WantAck=0, HopLim=3 Ch=0x8 encrypted rxSNR=2.25 rxRSSI=-93 hopStart=4)
DEBUG | 02:07:31 472 [Router] Ignoring incoming msg we've already seen (id=0x3feb7e38 fr=0x0c to=0x48, WantAck=0, HopLim=3 Ch=0x8 encrypted rxSNR=2.25 rxRSSI=-93 hopStart=4)
DEBUG | 02:07:31 472 [Router] cancelSending id=0x3feb7e38, removed=0
DEBUG | 02:07:31 472 [Router] Incoming message was filtered from 0x433b830c
DEBUG | 02:07:37 478 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=54, time 641 ms
DEBUG | 02:07:37 478 [RadioIf] Lora RX (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x8 encrypted rxSNR=-19.75 rxRSSI=-116 hopStart=3)
DEBUG | 02:07:37 478 [RadioIf] AirTime - Packet received : 641ms
DEBUG | 02:07:37 478 [Router] Add packet record (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x8 encrypted rxSNR=-19.75 rxRSSI=-116 hopStart=3)
DEBUG | 02:07:37 478 [Router] Using channel 0 (hash 0x8)
DEBUG | 02:07:37 478 [Router] Expanding short PSK #1
DEBUG | 02:07:37 478 [Router] Using AES128 key!
DEBUG | 02:07:37 478 [Router] decoded message (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625257 rxSNR=-19.75 rxRSSI=-116 hopStart=3)
DEBUG | 02:07:37 478 [Router] handleReceived(REMOTE) (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625257 rxSNR=-19.75 rxRSSI=-116 hopStart=3)
DEBUG | 02:07:37 478 [Router] Module 'position' wantsPacket=1
INFO | 02:07:37 478 [Router] Received position from=0x33686c24, id=0x5d17b792, portnum=3, payloadlen=34
DEBUG | 02:07:37 478 [Router] POSITION node=33686c24 l=34 lat=250125571 lon=1214676538 msl=52 hae=0 geo=0 pdop=179 hdop=0 vdop=0 siv=10 fxq=0 fxt=0 pts=1726625257 time=1726625255
DEBUG | 02:07:37 478 [Router] Ignoring time from mesh because we have a GPS, RTC, or Phone/NTP time source in the past day
INFO | 02:07:37 478 [Router] updatePosition REMOTE node=0x33686c24 time=1726625255 lat=250125571 lon=1214676538
DEBUG | 02:07:37 478 [Router] Node status update: 8 online, 42 total
DEBUG | 02:07:37 478 [Router] Module 'position' considered
DEBUG | 02:07:37 478 [Router] Module 'routing' wantsPacket=1
INFO | 02:07:37 478 [Router] Received routing from=0x33686c24, id=0x5d17b792, portnum=3, payloadlen=34
DEBUG | 02:07:37 478 [Router] Routing sniffing (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625257 rxSNR=-19.75 rxRSSI=-116 hopStart=3)
DEBUG | 02:07:37 478 [Router] Not rebroadcasting. Role = Role_ClientMute
DEBUG | 02:07:37 478 [Router] Delivering rx packet (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625257 rxSNR=-19.75 rxRSSI=-116 hopStart=3)
DEBUG | 02:07:37 478 [Router] Update DB node 0x33686c24, rx_time=1726625257
INFO | 02:07:37 478 [Router] Heard a node on channel 0 we don't know, sending NodeInfo and asking for a response.
DEBUG | 02:07:37 478 [Router] cancelSending id=0xd1b0f1a4, removed=0
DEBUG | 02:07:37 478 [Router] Skip sending NodeInfo since we just sent it less than 5 minutes ago.
DEBUG | 02:07:37 478 [Router] Forwarding to phone (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625257 rxSNR=-19.75 rxRSSI=-116 hopStart=3)
DEBUG | 02:07:37 478 [Router] Module 'routing' considered
INFO | 02:07:37 478 Telling client we have new packets 47
INFO | 02:07:37 478 BLE notify fromNum
INFO | 02:07:37 478 getFromRadio=STATE_SEND_PACKETS
DEBUG | 02:07:37 478 phone downloaded packet (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625257 rxSNR=-19.75 rxRSSI=-116 hopStart=3)
DEBUG | 02:07:39 479 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=54, time 641 ms
DEBUG | 02:07:39 479 [RadioIf] Lora RX (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=3 rxRSSI=-91 hopStart=3)
DEBUG | 02:07:39 479 [RadioIf] AirTime - Packet received : 641ms
DEBUG | 02:07:39 479 [Router] Found existing packet record for fr=0x33686c24,to=0xffffffff,id=0x5d17b792
DEBUG | 02:07:39 479 [Router] Found existing packet record for fr=0x33686c24,to=0xffffffff,id=0x5d17b792
DEBUG | 02:07:39 479 [Router] Add packet record (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=3 rxRSSI=-91 hopStart=3)
DEBUG | 02:07:39 479 [Router] Ignoring incoming msg we've already seen (id=0x5d17b792 fr=0x24 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=3 rxRSSI=-91 hopStart=3)
DEBUG | 02:07:39 479 [Router] cancelSending id=0x5d17b792, removed=0
DEBUG | 02:07:39 479 [Router] Incoming message was filtered from 0x33686c24
WARN | 02:07:39 480 [GPS] Couldn't publish a valid location: didn't get a GPS lock in time.
DEBUG | 02:07:39 480 [GPS] Took 60s to get lock
DEBUG | 02:07:39 480 [GPS] Predicting 60s to get next lock
DEBUG | 02:07:39 480 [GPS] 0s until next search
INFO | 02:07:39 480 [GPS] GPS power state moving from ACTIVE to IDLE
DEBUG | 02:07:39 480 [GPS] publishing pos@0:2, hasVal=0, Sats=0, GPSlock=0
DEBUG | 02:07:39 480 [GPS] onGPSChanged() pos@0 time=1726625259 lat=0 lon=0 alt=0
INFO | 02:07:39 480 [GPS] updatePosition LOCAL pos@0 time=1726625259 lat=0 lon=0 alt=0
DEBUG | 02:07:39 480 [GPS] Setting local position: lat=0 lon=0 time=1726625259 timestamp=0
DEBUG | 02:07:39 480 [GPS] Node status update: 9 online, 42 total
INFO | 02:07:43 484 toRadioWriteCb data 0x20016b0a, len 68
DEBUG | 02:07:43 484 PACKET FROM PHONE (id=0x216334b0 fr=0x00 to=0x87, WantAck=1, HopLim=0 Ch=0x0 Portnum=1)
DEBUG | 02:07:43 484 localSend to channel 0
DEBUG | 02:07:43 484 (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=68, time 739 ms
DEBUG | 02:07:43 484 Setting next retransmission in 8596 msecs: (id=0x216334b0 fr=0x00 to=0x87, WantAck=1, HopLim=4 Ch=0x0 Portnum=1 rxtime=1726625263)
DEBUG | 02:07:43 484 Add packet record (id=0x216334b0 fr=0x00 to=0x87, WantAck=1, HopLim=4 Ch=0x0 Portnum=1 rxtime=1726625263)
DEBUG | 02:07:43 484 Expanding short PSK #1
DEBUG | 02:07:43 484 Using AES128 key!
DEBUG | 02:07:43 484 enqueuing for send (id=0x216334b0 fr=0x3f to=0x87, WantAck=1, HopLim=4 Ch=0x8 encrypted rxtime=1726625263 hopStart=4 priority=100)
DEBUG | 02:07:43 484 txGood=7,rxGood=78,rxBad=3
INFO | 02:07:43 484 Telling client we have new packets 48
INFO | 02:07:43 484 BLE notify fromNum
INFO | 02:07:43 484 getFromRadio=STATE_SEND_PACKETS
DEBUG | 02:07:43 484 [RadioIf] Starting low level send (id=0x216334b0 fr=0x3f to=0x87, WantAck=1, HopLim=4 Ch=0x8 encrypted rxtime=1726625263 hopStart=4 priority=100)
DEBUG | 02:07:43 484 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=70, time 755 ms
DEBUG | 02:07:43 484 [RadioIf] AirTime - Packet transmitted : 755ms
DEBUG | 02:07:44 485 [RadioIf] Completed sending (id=0x216334b0 fr=0x3f to=0x87, WantAck=1, HopLim=4 Ch=0x8 encrypted rxtime=1726625263 hopStart=4 priority=100)
INFO | 02:07:44 485 [GPS] GPS power state moving from IDLE to ACTIVE
DEBUG | 02:07:44 485 [Power] Battery: usbPower=0, isCharging=0, batMv=3949, batPct=75
DEBUG | 02:07:45 486 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=27, time 436 ms
DEBUG | 02:07:45 486 [RadioIf] Lora RX (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=2 Ch=0x8 encrypted rxSNR=3 rxRSSI=-91 hopStart=2)
DEBUG | 02:07:45 486 [RadioIf] AirTime - Packet received : 436ms
DEBUG | 02:07:45 486 [Router] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=27, time 436 ms
DEBUG | 02:07:45 486 [Router] Add packet record (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=2 Ch=0x8 encrypted rxSNR=3 rxRSSI=-91 hopStart=2)
DEBUG | 02:07:45 486 [Router] Using channel 0 (hash 0x8)
DEBUG | 02:07:45 486 [Router] Expanding short PSK #1
DEBUG | 02:07:45 486 [Router] Using AES128 key!
DEBUG | 02:07:45 486 [Router] decoded message (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=2 Ch=0x0 Portnum=5 requestId=216334b0 rxtime=1726625265 rxSNR=3 rxRSSI=-91 hopStart=2)
DEBUG | 02:07:45 486 [Router] handleReceived(REMOTE) (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=2 Ch=0x0 Portnum=5 requestId=216334b0 rxtime=1726625265 rxSNR=3 rxRSSI=-91 hopStart=2
DEBUG | 02:07:45 486 [Router] Module 'routing' wantsPacket=1
INFO | 02:07:45 486 [Router] Received routing from=0x1499a87, id=0xe56aa9b4, portnum=5, payloadlen=2
DEBUG | 02:07:45 486 [Router] Routing sniffing (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=2 Ch=0x0 Portnum=5 requestId=216334b0 rxtime=1726625265 rxSNR=3 rxRSSI=-91 hopStart=2)
DEBUG | 02:07:45 486 [Router] Received an ack for 0x216334b0, stopping retransmissions
DEBUG | 02:07:45 486 [Router] Delivering rx packet (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=2 Ch=0x0 Portnum=5 requestId=216334b0 rxtime=1726625265 rxSNR=3 rxRSSI=-91 hopStart=2)
DEBUG | 02:07:45 486 [Router] Update DB node 0x1499a87, rx_time=1726625265
DEBUG | 02:07:45 486 [Router] Forwarding to phone (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=2 Ch=0x0 Portnum=5 requestId=216334b0 rxtime=1726625265 rxSNR=3 rxRSSI=-91 hopStart=2)
DEBUG | 02:07:45 486 [Router] Module 'routing' considered
INFO | 02:07:45 486 Telling client we have new packets 49
INFO | 02:07:45 486 BLE notify fromNum
INFO | 02:07:45 486 getFromRadio=STATE_SEND_PACKETS
DEBUG | 02:07:45 486 phone downloaded packet (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=2 Ch=0x0 Portnum=5 requestId=216334b0 rxtime=1726625265 rxSNR=3 rxRSSI=-91 hopStart=
DEBUG | 02:07:46 486 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=27, time 436 ms
DEBUG | 02:07:46 486 [RadioIf] Lora RX (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=5.75 rxRSSI=-33 hopStart=2)
DEBUG | 02:07:46 486 [RadioIf] AirTime - Packet received : 436ms
DEBUG | 02:07:46 486 [Router] Found existing packet record for fr=0x1499a87,to=0x59e4f83f,id=0xe56aa9b4
DEBUG | 02:07:46 486 [Router] Found existing packet record for fr=0x1499a87,to=0x59e4f83f,id=0xe56aa9b4
DEBUG | 02:07:46 486 [Router] Add packet record (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=5.75 rxRSSI=-33 hopStart=2)
DEBUG | 02:07:46 486 [Router] Ignoring incoming msg we've already seen (id=0xe56aa9b4 fr=0x87 to=0x3f, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=5.75 rxRSSI=-33 hopStart=2)
DEBUG | 02:07:46 486 [Router] cancelSending id=0xe56aa9b4, removed=0
DEBUG | 02:07:46 486 [Router] Incoming message was filtered from 0x1499a87
DEBUG | 02:07:52 493 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=54, time 641 ms
DEBUG | 02:07:52 493 [RadioIf] Lora RX (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x8 encrypted rxSNR=-20 rxRSSI=-115 hopStart=3)
DEBUG | 02:07:52 493 [RadioIf] AirTime - Packet received : 641ms
DEBUG | 02:07:52 493 [Router] Add packet record (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x8 encrypted rxSNR=-20 rxRSSI=-115 hopStart=3)
DEBUG | 02:07:52 493 [Router] Using channel 0 (hash 0x8)
DEBUG | 02:07:52 493 [Router] Expanding short PSK #1
DEBUG | 02:07:52 493 [Router] Using AES128 key!
DEBUG | 02:07:53 493 [Router] decoded message (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625272 rxSNR=-20 rxRSSI=-115 hopStart=3)
DEBUG | 02:07:53 493 [Router] handleReceived(REMOTE) (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625272 rxSNR=-20 rxRSSI=-115 hopStart=3)
DEBUG | 02:07:53 493 [Router] Module 'position' wantsPacket=1
INFO | 02:07:53 493 [Router] Received position from=0x33686c24, id=0x5d17b793, portnum=3, payloadlen=34
DEBUG | 02:07:53 493 [Router] POSITION node=33686c24 l=34 lat=250125158 lon=1214674883 msl=84 hae=0 geo=0 pdop=217 hdop=0 vdop=0 siv=12 fxq=0 fxt=0 pts=1726625273 time=1726625271
DEBUG | 02:07:53 493 [Router] Ignoring time from mesh because we have a GPS, RTC, or Phone/NTP time source in the past day
INFO | 02:07:53 493 [Router] updatePosition REMOTE node=0x33686c24 time=1726625271 lat=250125158 lon=1214674883
DEBUG | 02:07:53 493 [Router] Node status update: 9 online, 42 total
DEBUG | 02:07:53 493 [Router] Module 'position' considered
DEBUG | 02:07:53 493 [Router] Module 'routing' wantsPacket=1
INFO | 02:07:53 493 [Router] Received routing from=0x33686c24, id=0x5d17b793, portnum=3, payloadlen=34
DEBUG | 02:07:53 493 [Router] Routing sniffing (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625272 rxSNR=-20 rxRSSI=-115 hopStart=3)
DEBUG | 02:07:53 493 [Router] Not rebroadcasting. Role = Role_ClientMute
DEBUG | 02:07:53 493 [Router] Delivering rx packet (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625272 rxSNR=-20 rxRSSI=-115 hopStart=3)
DEBUG | 02:07:53 493 [Router] Update DB node 0x33686c24, rx_time=1726625272
INFO | 02:07:53 493 [Router] Heard a node on channel 0 we don't know, sending NodeInfo and asking for a response.
DEBUG | 02:07:53 493 [Router] cancelSending id=0xd1b0f1a4, removed=0
DEBUG | 02:07:53 493 [Router] Skip sending NodeInfo since we just sent it less than 5 minutes ago.
DEBUG | 02:07:53 493 [Router] Forwarding to phone (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625272 rxSNR=-20 rxRSSI=-115 hopStart=3)
DEBUG | 02:07:53 493 [Router] Module 'routing' considered
INFO | 02:07:53 493 Telling client we have new packets 50
INFO | 02:07:53 493 BLE notify fromNum
INFO | 02:07:53 493 getFromRadio=STATE_SEND_PACKETS
DEBUG | 02:07:53 493 phone downloaded packet (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=2 Ch=0x0 Portnum=3 rxtime=1726625272 rxSNR=-20 rxRSSI=-115 hopStart=3)
DEBUG | 02:07:54 495 [RadioIf] (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=54, time 641 ms
DEBUG | 02:07:54 495 [RadioIf] Lora RX (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=3.25 rxRSSI=-91 hopStart=3)
DEBUG | 02:07:54 495 [RadioIf] AirTime - Packet received : 641ms
DEBUG | 02:07:54 495 [Router] Found existing packet record for fr=0x33686c24,to=0xffffffff,id=0x5d17b793
DEBUG | 02:07:54 495 [Router] Found existing packet record for fr=0x33686c24,to=0xffffffff,id=0x5d17b793
DEBUG | 02:07:54 495 [Router] Add packet record (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=3.25 rxRSSI=-91 hopStart=3)
DEBUG | 02:07:54 495 [Router] Ignoring incoming msg we've already seen (id=0x5d17b793 fr=0x24 to=0xff, WantAck=0, HopLim=1 Ch=0x8 encrypted rxSNR=3.25 rxRSSI=-91 hopStart=3)
DEBUG | 02:07:54 495 [Router] cancelSending id=0x5d17b793, removed=0
DEBUG | 02:07:54 495 [Router] Incoming message was filtered from 0x33686c24
DEBUG | 02:08:04 505 [Power] Battery: usbPower=0, isCharging=0, batMv=3975, batPct=78
INFO | 02:08:14 515 toRadioWriteCb data 0x200236e8, len 257
DEBUG | 02:08:14 515 PACKET FROM PHONE (id=0x216334b1 fr=0x00 to=0x87, WantAck=1, HopLim=0 Ch=0x0 Portnum=1)
DEBUG | 02:08:14 515 localSend to channel 0
DEBUG | 02:08:14 515 (bw=250, sf=11, cr=4/5) packet symLen=8 ms, payloadSize=255, time 2131 ms
DEBUG | 02:08:14 515 Setting next retransmission in 11380 msecs: (id=0x216334b1 fr=0x00 to=0x87, WantAck=1, HopLim=4 Ch=0x0 Portnum=1 rxtime=1726625294)
DEBUG | 02:08:14 515 Add packet record (
@fifieldt Can you help break down what your debug logs here demonstrate? I'm a software dev, though new to Meshtastic as of a week. Aiming to run some tests at various dBm levels between a t114 and a control Wisblock node. Would love insight into what logs are indicating that could benefit my analysis outside of just looking at whether the message was received by the control node. Thanks!
Hi @skylerwshaw , the only real interesting messages are the last 5.
We got a packet from the phone, plan to send it to lora channel 0, sent a 255 byte payload, then died after cleaning up and adding it to our list of sent packets. The half-printed line where it dies is from code that hasn't been changed in >6 months, so that's probably not the root of the problem.
Hello dear community, it is definitely not a hardware issue. I have fixed it on 3 devices. How? nrf erase multiple times, firmware 2.5, then back to 2.4.2 then back to 2.5, deleted again and back to 2.4.2 and now I can send the full number of characters :) Battery level over 90%
Hello dear community, it is definitely not a hardware issue. I have fixed it on 3 devices. How? nrf erase multiple times, firmware 2.5, then back to 2.4.2 then back to 2.5, deleted again and back to 2.4.2 and now I can send the full number of characters :) Battery level over 90%
Couldn't get your method to work for me unfortunately although it did perform a little better than it has been.
Hello dear community, it is definitely not a hardware issue. I have fixed it on 3 devices. How? nrf erase multiple times, firmware 2.5, then back to 2.4.2 then back to 2.5, deleted again and back to 2.4.2 and now I can send the full number of characters :) Battery level over 90%
That sounds wild, there must be a better solution, thats like rolling some dice and hoping to get a pair at some point??
Hello dear community, it is definitely not a hardware issue. I have fixed it on 3 devices. How? nrf erase multiple times, firmware 2.5, then back to 2.4.2 then back to 2.5, deleted again and back to 2.4.2 and now I can send the full number of characters :) Battery level over 90%
That sounds wild, there must be a better solution, thats like rolling some dice and hoping to get a pair at some point??
Sounds like some sort of timing issue?
My Heltec T114 has the same problem. Tested with full length (228 bytes) messages. Super and dandy up to 10 dBm. Above this it gets into trouble.
Seems to be all over the place, I was not able to send larger messages above 7dBm with both of my T114s. Lowering dBm was in direct relation of being able to send bigger messages. The lower the dBm the more successful I was with bigger messages. Once I upped the dBm again step by step, message length decreased ( for a successful delivery)
Sure seems like a hardware problem still.
Hi Everyone, I was analyzing the schematic and and comparing it to the Wisblock etc...
I don't think there is enough isolation between the nRF and SX chips on the T114
One thing that could be tried is to pick off L4 inductor and on the and tie the nRF side to the auxiliary Ve_3.3v which has its own regulator
I am willing to risk my own T114 to give this a shot once i'm feeling brave enough to work at such small levels
but why could I then fix the error? If it was a hardware error, it would be wrong on all devices because it would then be a design error
but why could I then fix the error? If it was a hardware error, it would be wrong on all devices because it would then be a design error
nobody can replicate your solution, it working at reduced power indicates this is hardware related.
If it were a hardware defect, several hundred devices would be affected and I think you would read more about it on the Internet (not just meshtastic). I have my solution to share, which worked for me.
Thanks @lupusworax
PS. I realized the enable pin for that regulator is pulled down by default and controlled by the nRF, i'm sure the heltec folks can figure it out though.
Another idea - Could perhaps an idle-state dump and comparison/diff of the hardware config registers across other, known to be reliable, nRF devices such as the RAK4630, T-echo, etc..., be done?
If it were a hardware defect, several hundred devices would be affected and I think you would read more about it on the Internet (not just meshtastic). I have my solution to share, which worked for me.
Personally, I don't doubt you, but it's not really a solution or fix unless the mechanisms are well-understood, otherwise it's just a "YMMV" remedy.
Your successful outcomes may rely on some sort of edge case that we don't know of, but are still valuable anecdotes! we need these clues :)
I had this problem! and then tried everything to fix it, as I described, I was previously unable to send more than a maximum of 45 characters, now I can send the full number of characters normally at full transmission power (22) if it was a hardware problem I couldn't fix it by simply deleting the software.
I had this problem! and then tried everything to fix it, as I described, I was previously unable to send more than a maximum of 45 characters, now I can send the full number of characters normally at full transmission power (22) if it was a hardware problem I couldn't fix it by simply deleting the software.
I am wondering, every single device I built and configured, for 868_EU the dBm setting was 27 (stock) I never touched that value, Richard from heltec told me that it should not be more then 21 +/- 1 just like you said yours is on 22. How comes that 868_EU has a stock value of 27?
I had this problem! and then tried everything to fix it, as I described, I was previously unable to send more than a maximum of 45 characters, now I can send the full number of characters normally at full transmission power (22) if it was a hardware problem I couldn't fix it by simply deleting the software.
Hence why I think it's worthwhile looking at what the config registers are doing... my hunch is that there may be something new/novel in the "offending" firmware that, once set, is out of reach in other versions of the firmware, and a firmware reload dance like you describe can sometimes get it to unstick? 🤷🏻♂️
but why could I then fix the error? If it was a hardware error, it would be wrong on all devices because it would then be a design error
You are using LongModerate and not LongFast where the error occurs.
I had this problem! and then tried everything to fix it, as I described, I was previously unable to send more than a maximum of 45 characters, now I can send the full number of characters normally at full transmission power (22) if it was a hardware problem I couldn't fix it by simply deleting the software.
I am wondering, every single device I built and configured, for 868_EU the dBm setting was 27 (stock) I never touched that value, Richard from heltec told me that it should not be more then 21 +/- 1 just like you said yours is on 22. How comes that 868_EU has a stock value of 27?
27 is the maximum value allowed for EU_868. When the power is configured to the hw driver it is limited to what the chipset is capable of, i.e. 22. But this value is not shown on the UI.
Hello dear community, it is definitely not a hardware issue. I have fixed it on 3 devices. How? nrf erase multiple times, firmware 2.5, then back to 2.4.2 then back to 2.5, deleted again and back to 2.4.2 and now I can send the full number of characters :) Battery level over 90%
I have tried this, and can confirm it works. I can now send the full amount of characters on full power.
but why could I then fix the error? If it was a hardware error, it would be wrong on all devices because it would then be a design error
You are using LongModerate and not LongFast where the error occurs.
not only it works on every mode !
Someone who has a tantalum capacitor (10+ uF) can try if it helps to put it across VDD_3V3 and GND. It can't do any harm, as long as you put it the right way round.
Maybe add #define LORA_DIO1 SX126X_DIO1
if it is something to do with sleep interrupts.
Or Heltec flashed an old or custom version of the firmware, clear main flash then reupload latest version
Hi @skylerwshaw , the only real interesting messages are the last 5.
We got a packet from the phone, plan to send it to lora channel 0, sent a 255 byte payload, then died after cleaning up and adding it to our list of sent packets. The half-printed line where it dies is from code that hasn't been changed in >6 months, so that's probably not the root of the problem.
Serial takes time to print, the issue may happen after that debug line
Someone who has a tantalum capacitor (10+ uF) can try if it helps to put it across VDD_3V3 and GND. It can't do any harm, as long as you put it the right way round.
Maybe add
#define LORA_DIO1 SX126X_DIO1
if it is something to do with sleep interrupts.Or Heltec flashed an old or custom version of the firmware, clear main flash then reupload latest version
Exactly what I mean Delete everything on this "Drive" and make an clean install
Hello everyone. We made a version of the firmware to alleviate this issue temporarily: Download link
We will continue to follow up on this situation and look forward to more feedback from you. If you have any ideas that you would like to be verified, or need any help or consultation, you can contact us at: support@heltec.cn
To add, how I made it work using official mesthastic firmware from flasher.mesthastic.org:
Now my Heltec T-114 is able to send 227 bytes of text with default 27 dBm power setting using Long Range - Fast preset for EU 868 MHz.
Haven't tried the RichardHeltec Download link firmware file.
@RichardHeltec Maybe if you can explain to the dev team what was changed in your firmware so it can be pushed to official release.
exactly what I have said...delete everything.and flash new
This issue has been mentioned on Meshtastic. There might be relevant details there:
https://meshtastic.discourse.group/t/problems-with-heltec-t114/14489/22
I tried this with 2.5.0.9 Alpha and it did not work for me.
Category
Other
Hardware
Heltec Mesh Node T114
Firmware Version
2.4.3.91d6612
Description
Messages above 47 characters cannot be sent. Other are reporting that the message length that causes failure to send is variable https://www.reddit.com/r/meshtastic/comments/1fhc47k/heltec_t114_message_sending_bugfault
Relevant log output
No response