Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: T114 can't send messages longer than 47 chars #4723

Closed
adingbatponder opened this issue Sep 15, 2024 · 208 comments
Closed

[Bug]: T114 can't send messages longer than 47 chars #4723

adingbatponder opened this issue Sep 15, 2024 · 208 comments
Labels
hardware cantfix Hardware problem, can't be fixed

Comments

@adingbatponder
Copy link

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

@adingbatponder adingbatponder added the bug Something isn't working label Sep 15, 2024
@adingbatponder
Copy link
Author

@adingbatponder
Copy link
Author

Does it forward packets normally or are certain length messages not forwarded?

@meshtastic-bot
Copy link

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

@GUVWAF
Copy link
Member

GUVWAF commented Sep 15, 2024

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.

@fifieldt fifieldt changed the title [Bug]: [Bug]: T114 can't send messages longer than 47 chars Sep 16, 2024
@lupusworax
Copy link

lupusworax commented Sep 16, 2024

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.

@willfootwill
Copy link

exact same behaviour here - ok below 8db

@willfootwill
Copy link

I tried going back to earlier firmware 2.4.xxx, no improvement

@lupusworax
Copy link

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.

@NeilMartin
Copy link

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).

@lupusworax
Copy link

lupusworax commented Sep 16, 2024

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

@DTopp
Copy link

DTopp commented Sep 17, 2024

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.

@aljaxus
Copy link

aljaxus commented Sep 17, 2024

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.

@thebentern
Copy link
Contributor

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.

@lupusworax
Copy link

Would a big enough capacitor at the LDO be able to buffer that?

@thebentern
Copy link
Contributor

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. 😅

@fifieldt
Copy link
Contributor

fifieldt commented Sep 17, 2024

Q) Does everyone above have the version with a screen? GPS?

@lupusworax
Copy link

lupusworax commented Sep 17, 2024

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.

@DTopp
Copy link

DTopp commented Sep 17, 2024

Q) Does everyone above have the version with a screen? GPS?

Screen and GPS.

@NeilMartin
Copy link

NeilMartin commented Sep 17, 2024 via email

@todd-herbert
Copy link
Contributor

todd-herbert commented Sep 17, 2024

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)

@fifieldt
Copy link
Contributor

fifieldt commented Sep 18, 2024

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 (

@skylerwshaw
Copy link

@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!

@fifieldt
Copy link
Contributor

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.

@x81Reaper
Copy link

x81Reaper commented Sep 19, 2024

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%

@DTopp
Copy link

DTopp commented Sep 19, 2024

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.
Screenshot 2024-09-19 133723

@lupusworax
Copy link

lupusworax commented Sep 19, 2024

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??

@s56oa
Copy link

s56oa commented Sep 19, 2024

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.

@lupusworax
Copy link

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)

@jsnyder
Copy link

jsnyder commented Oct 17, 2024

contact them directly over the messenger on ali express that includes your order , so did I and had a answer the next day.

Just looked. Instead of replying to the email they responded on AliExpress for me.

@DTopp
Copy link

DTopp commented Oct 18, 2024

I received my reply via AliExpress chat too.

@meshtastic-bot
Copy link

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/meshtastic-scotland/11479/248

@joan7770
Copy link

Since the hardware is being fixed with a new revision, will the board be added back to the web flasher and OTA update on the app?

@fifieldt
Copy link
Contributor

@joan7770 yes indeed - developers are just waiting to receive a board to do some final testing before that happens.

@hank
Copy link

hank commented Oct 24, 2024

Replacement going well on AliExpress chat. Thanks Heltec for not sucking!

@hayschan
Copy link

I've also bought their new T114 v2. Hope everything goes well.

@jangrewe
Copy link

I can confirm that they replied to an email via AliExpress message, ~14 hours after the email.
But since that is now 2 weeks ago, i was wondering if anybody has already received their Rev 2.0 board?

@daniel4999
Copy link

The response I received was that they would send it out in sequential order at the end of the month

@gpi-ct
Copy link

gpi-ct commented Oct 28, 2024

I contacted them through Aliexpress messaging and they replied same day with "Your order has been registered. We will ship it to you after the new version is put on the shelves. Please wait patiently"
Nice.

@guryonblaze
Copy link

IMG_3859

Ordered 3 recieved 4, the store packed in my replacement for the v1 I had ordered previously

IMG_3858

@guryonblaze
Copy link

Quick update, Bluetooth is a lot more solid, and long messages are passing through

@skylerwshaw
Copy link

@guryonblaze, who was replacing your boards? Here's to hoping Muzi and other vendors receive them soon as well! Thanks for the update.

@guryonblaze
Copy link

@guryonblaze, who was replacing your boards? Here's to hoping Muzi and other vendors receive them soon as well! Thanks for the update.

A store on Aliexpress (Moonmall Store), was really impressed they packed the replacement with my order, but guess it makes sense as it saves shipping.

@hayschan
Copy link

Just got the T114 v2. Really impressive stuff.

@lupusworax
Copy link

lupusworax commented Oct 31, 2024

Just got the T114 v2. Really impressive stuff.

You mean because it works now? Or what exactly is impressive? Where you able to do some testing? How about the results?

@lyusupov
Copy link

lyusupov commented Nov 18, 2024

@jangrewe

But since that is now 2 weeks ago, i was wondering if anybody has already received their Rev 2.0 board?

1 month and 1 week have passed since I've received a confirmation from Heltec Store on AliExpress that my replacement request is accepted and being queued.

Every 7-10 I days I request a status update and the Heltec Sales representative always says that the shipment of replacement orders is going on but my particular order is not shipped out yet - "please, wait patiently..."
This is not funny anymore...

@lupusworax
Copy link

they send them out in the same order they received the orders, I got confirmation and a tracking code 4 days ago. They do the best they can, you will get your replacement dont worry. yeah it takes some time but at least you get it fully replaced. Its gonna be alright.

@NexGen-3D-Printing
Copy link

I got my tracking details a few days ago as well.

@tfindley
Copy link

I had mine delivered a few days ago.
Already in a case with a battery and in the car as a mobile node.

Battery life is crazy good!

@lupusworax
Copy link

I had mine delivered a few days ago. Already in a case with a battery and in the car as a mobile node.

Battery life is crazy good!

Once you go NRF52 its almost impossible to go back to esp32 when it comes to mobile or solar nodes ;)

@Doom4535
Copy link

Has anyone had any luck with the RMA process for these through Amazon? I have a board that is outside of the normal return window apparently, but I would like to replace it (and have a low confidence in Amazon for these sorts of things). If this doesn't work, will Heltec allow contacting them directly (the posted directions say they will only directly service those purchased through their normal storefront and aliexpress (which is unfortunate when so many items are purchased through 3rd party sellers)).

@lupusworax
Copy link

lupusworax commented Nov 21, 2024

Has anyone had any luck with the RMA process for these through Amazon? I have a board that is outside of the normal return window apparently, but I would like to replace it (and have a low confidence in Amazon for these sorts of things). If this doesn't work, will Heltec allow contacting them directly (the posted directions say they will only directly service those purchased through their normal storefront and aliexpress (which is unfortunate when so many items are purchased through 3rd party sellers)).

Get in direct contact with the seller on amazon, or was it directly sold by amazon?

@Doom4535
Copy link

Doom4535 commented Nov 22, 2024

Has anyone had any luck with the RMA process for these through Amazon? I have a board that is outside of the normal return window apparently, but I would like to replace it (and have a low confidence in Amazon for these sorts of things). If this doesn't work, will Heltec allow contacting them directly (the posted directions say they will only directly service those purchased through their normal storefront and aliexpress (which is unfortunate when so many items are purchased through 3rd party sellers)).

Get in direct contact with the seller on amazon, or was it directly sold by amazon?

Not sold directly by Amazon sadly, the two different sellers have both now said they would send me new boards (hopefully they do, but I may not be getting the 20% coupon code unfortunately (I mostly want the board replacements as I need them working to make proper repeaters)).

Has anyone identified a way to fix the v1 models? As they currently are, they would likely degrade the mesh network and probably shouldn't be used, but I'd hate to turn them into e-waste.

@lupusworax
Copy link

lupusworax commented Nov 22, 2024

Sadly there is no 100% working solution, I was having some success by adding capacitors to the SX chip and the 3.3volt rail but it never really solved the issue completely, with some of the boards I was able to send a lot more characters, others stayed exactly the same its just.....meh........you can use them as long you dont send to long messages, and to prevent them from degrading the mesh network, you can set it to "client_mute" that way they wont repeat incoming messages. as the V1 boards receive just fine there surely is some sort of use to them. Maybe make yourself some canned message node just sending out those short messages, they will work no problem.

@gpi-ct
Copy link

gpi-ct commented Nov 22, 2024

I'm probably going to take my two v1's and set them as CLIENT_MUTE, use them inside the house at low power because they will only need to reach the attic node with the strong antenna. Or if there is some other Lora non-meshtastic use I could throw at them. I'm with you though, I don't want to just toss them if there's something they could be used for.

@aljaxus
Copy link

aljaxus commented Nov 22, 2024

I can confirm that I received the replacement sceen-less modules. I assume I will receive the replacement ones with screens later on. So far so good.

Will edit this reply as things change.

@blackgis
Copy link

blackgis commented Dec 25, 2024

V1 is dead? Any updates? Amazon Germany is still selling these...

@garthvh
Copy link
Member

garthvh commented Dec 25, 2024

V1 is dead? Any updates? Amazon Germany is still selling these...

V1 is dead

@efm-7
Copy link

efm-7 commented Dec 25, 2024

V1 can be used with an external transceiver module if you're willing to rework it a little and run wires from the SPI lines 😅

image

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hardware cantfix Hardware problem, can't be fixed
Projects
None yet
Development

No branches or pull requests