[Bug]: T114 can't send messages longer than 47 chars #4723
Comments
|
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. |
|
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 |
|
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? |
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. |
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
<#4723 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIMTLW7DOBYX6PGAGO2P5TZXA2VHAVCNFSM6AAAAABOIBAVMGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJVHE3TOMZSHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
neil*martin*
|
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: |
|
@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 :) |
Couldn't get your method to work for me unfortunately although it did perform a little better than it has been. |
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. |
|
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 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 |
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? |
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 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? |
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? 🤷🏻♂️ |
You are using LongModerate and not LongFast where the error occurs. |
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. |
I have tried this, and can confirm it works. I can now send the full amount of characters on full power. |
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 Or Heltec flashed an old or custom version of the firmware, clear main flash then reupload latest version |
Serial takes time to print, the issue may happen after that debug line |
Exactly what I mean |
|
Hello everyone. We will continue to follow up on this situation and look forward to more feedback from you. |
|
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. |
I think they lowered the dBm to 11. |
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
The text was updated successfully, but these errors were encountered: