lupusworax
commented
1 week ago Maybe if you can explain to the dev team what was changed in your firmware so it can be pushed to official release.
I think they lowered the dBm to 11.
Closed adingbatponder closed 1 day ago
lupusworax
commented
1 week ago Maybe if you can explain to the dev team what was changed in your firmware so it can be pushed to official release.
I think they lowered the dBm to 11.
aljaxus
commented
1 week ago To add, how I made it work using official mesthastic firmware from flasher.mesthastic.org:
1. Went to Official Flasher https://flasher.meshtastic.org/ 2. Selected Heltec Mesh Node T114 3. Near the green Flash button there is a trashcan icon, I click on this trashcan icon (erase Flash of Heltec Mesh Node T114) 4. I did the erasing of the flash by downloading Flash Erase UF2 file to the unit 5. After erasing was completed I just download and flashed latest official beta firmware (I used official latest beta firmware-heltec-mesh-node-t114-2.4.2.5b45303.uf2 file)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.
Can confirm this worked for me too on multiple nodes.
garthvh
commented
1 week ago Hello everyone.
We made a version of the firmware to alleviate this issue temporarily:
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
Where is the code for this fork located at?
DTopp
commented
1 week ago exactly what I have said...delete everything.and flash new
Gave it another try and it still didn't work for me. All seems a bit weird.
DTopp
commented
1 week ago 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
This firmware does work although I'm a little suspicious as to why it works. Is it true that it's just the dBm that has been lowered and what effect will that have on range if so?
lupusworax
commented
1 week ago I am confused in general when it comes to the NRF52 chipset, its my first of its kind and the whole "flashing" stuff is causing me headaches. When I was trying the posted solution by deleting a few times, flashing older firmware back and forth, erasing again, on my device the possibility to turn gps on and off with 3 button presses stopped working,
no matter what I did, while double pressing sending adhoc worked, gps was not reactive to 3 button presses. I then went on wild erasing, flashing one after another firmware back and forth, erasing again 4 times at once as it suddenly at some point started working again......... This is wild.
With the ESP32 devices I never had anything similar, when I flashed a new firmware I was assured that all the old hardware was gone and no issues remained........but with the NRF52 ( or maybe just with the heltec t114) this is just a hot mess as it seems it never really overwrites the old firmware reliable, is this also the same with RAK based nodes??
lupusworax
commented
1 week ago 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
This firmware does work although I'm a little suspicious as to why it works. Is it true that it's just the dBm that has been lowered and what effect will that have on range if so?
The info about lowering dBm to something around 11 was the last info I got from heltec before I told them it would be best if they directly post their findings on here other then writing messages to me ( I was the one contacting heltec about the problem in the first place)
Well if the max possible output is 21 +/- 1 you can be sure that its a lot less with 11 then it would be capable off and so range is therefor limited of course.
When you check with an SDR you can see that it comes in a lot quieter then with max power.
s56oa
commented
1 week ago @lupusworax I had issues with some ESP32 devices before erasing fash, too. So this is nothing new.
My T114 was shipped with some non-Meshtastic firmware from the factory and this might be the original offender. Erasing the flash seems to clean and tidy up the "house" before the new furniture (official Meshtastic firmware) is brought in.
garthvh
commented
1 week ago @RichardHeltec where is the code? Heltec needs to stop releasing binaries of unreleased code.
s56oa
commented
1 week ago Having the code change would be beneficial. But as evidenced in the field, that erasing the flash makes even the official Meshtastic firmware work, it would be of interest to find the offending culprit. It seems it can be found in the contents of flash memory from the factory.
garthvh
commented
1 week ago Being that the power seems to be substantially reduced it seems really likely that this is a hardware problem @RichardHeltec @Heltec-Aaron-Lee where is this fork at? We need you guys to stop releasing binaries without the code.
dahanc
commented
1 week ago When you check with an SDR you can see that it comes in a lot quieter then with max power.
I wonder if it'd be useful to get a raw IQ recording of a problem transmission. One might be able to get more info on why the transmission is bad.
lupusworax
commented
1 week ago I am using this software "meshsense" that was posted a while ago on Reddit its really not bad at all. there you can see a nice log of pretty much any transmission, no matter if message, telemetry, position update etc. when I send out a message over longfast with my T114 my homebase node receives it no problem and can decode it, when I try to send a DM to my homebase it actually realizes that there would be a message but it lists it as encrypted. I guess because the signal is fucked up in a way?
and here are the packet details: { "from": 2967681682, "to": 3663886660, "channel": 0, "encrypted": "a2BlYbLFvc79PQpf4JHYihHfVDLJGu/tHvV4oBv7KaaYmBowC9WqPKOfRw==", "id": 2574706432, "rxTime": 1727029881, "rxSnr": 4.5, "hopLimit": 3, "wantAck": true, "priority": "UNSET", "rxRssi": -64, "delayed": "NO_DELAY", "viaMqtt": false, "hopStart": 3, "publicKey": "", "pkiEncrypted": false }
fifieldt
commented
1 week ago Potentially related: https://github.com/meshtastic/firmware/pull/4827
lupusworax
commented
1 week ago Yeah I can do whatever I want, going crazy with all the firmwares back and forth erase etc., in my case 2 Devices it just wont stick, I feel like its getting worse honestly. Only solution that works is lowering dBm below 11. ( I am on 2.5.1 now the most recent). I really was excited for the T114 but by now it really starts to become one big frustrating Odyssey, such a pain!
Was anyone able to make it work with 21dBm on firmware 2.5. 0/1 as well or is it just working with 2.4?
The tiny fonts on 2.4 really are terrible on the T114s high resolution screen and so much better with 2.5.
QUESTION: For those where the wild Erase, flash, erase, flash marathon worked, are you guys running 868 or 915MHZ? I am on EU_868.
s56oa
commented
1 week ago Yeah I can do whatever I want, going crazy with all the firmwares back and forth erase etc., in my case 2 Devices it just wont stick, I feel like its getting worse honestly. Only solution that works is lowering dBm below 11. ( I am on 2.5.1 now the most recent). I really was excited for the T114 but by now it really starts to become one big frustrating Odyssey, such a pain! Was anyone able to make it work with 21dBm on firmware 2.5. 0/1 as well or is it just working with 2.4? The tiny fonts on 2.4 really are terrible on the T114s high resolution screen and so much better with 2.5.
QUESTION: For those where the wild Erase, flash, erase, flash marathon worked, are you guys running 868 or 915MHZ? I am on EU_868.
We are on 868 MHz Long Fast Setting for Europe. And there was no marathon. Just download and copy to the device the firmware for erasing the flash and then do the same with official Meshtastic 2.4.2.5b45303 firmware.
As always there is also a possibility of multiple overlapping bugs. Both hardware, software and settings related. What worked for us might not work for you.
Heltec-Aaron-Lee
commented
6 days ago Hi there, sorry for the delay, indeed we noticed this issue last Monday, These days, our engineers have been continuously working on this matter. We hope to provide a formal explanation when the root cause can be identified. Unfortunately, our progress has been slow. Here are all the testing processes details we had done, share them here, maybe it will help us all solve the problem together
When T114 works as a Meshtastic device and tries to send long strings (>50 chars) ONLY in Long-Fast mode (SF11, 250K BW), sometimes sending messages may fail. Yes, not every time will fail, and not every device has this issue. This explains why some people do not encounter this problem.
1. The power supply of LoRa 32M TCXO has been increased from 1.8V to 3.3V
The LoRa chip uses a 32M TCXO, which is powered by the DIO3 pin of the SX1262 chip. In the current firmware, it uses 1.8V. When we configure it to be powered by 3.3V by modifying the code, the situation changes and communication seems to become more stable. Now LoRa PingPong in SF11, 250K BW, 200 bytes packet length became very stable.
When back to Meshtastic communication, There still has long packets that can not be sent issue. Compared to LoRa PingPong, Meshtastic communication enables Bluetooth on the device, which is the only difference. But it's also quite strange. Here are my views:
2. Add SAW filter
We added these SAW filters to the SMA socket, but the situation seems to have not improved significantly.
3. Use MCU or LoRa from other boards (WiFi LoRa 32 V3)
4. Enable Low Data Rate Optimization
SX1262 has a
Low Data Rate Optimization function, which makes communication very stable and there is no problem sending long packets after enabling this function. However, it cannot communicate with devices that have not enabled Low Data Rate Optimization.
5. Some other strange phenomena
6. Replace the XTAL source
Both nRF52840 and SX1262 use a 32M crystal. The difference is that nRF52840 uses Crystal (no power required), while SX1262 uses TCXO (power required).
This point seems to be the most useful information we have found so far, and we are still trying to prove something from this point. Once we have definite results, we will provide explanations.
At present, for users who require long packet transmission, we have compiled this temporary version of firmware, which controls the power output of LoRa. When it is needed to send information with a length>50 chars in Long-Fast mode, the output power is reduced to 14dB. Because this is a temporary firmware that does not conform to the framework of Meshtastic firmware, so we did not submit this version of the code.
We deeply apologize for this issue... Before mass production, we conducted detailed testing, but the testing for sending long strings was not sufficient, which is why the current problem occurred. Thank you to the first person who discovered this issue, and also to everyone who has been doing various tests and attempts here. I think this is the charm of open source.
If there are any new discoveries in the future, I will update them here. Based on my feedback above, if you have found any patterns, please feel free to reply here.
Finally, we guarantee we will not evade this issue. Once we identify the root cause of the problem, we will release a detailed report and provide a final solution. If new hardware is needed to completely resolve the issue, we will send you a replacement, whether you purchased it directly from Heltec or from our agents.
devzwf
commented
6 days ago 
thebentern
commented
6 days ago @Heltec-Aaron-Lee thanks for detailed explanation! I'm planning on trying the experimental TXCO voltage increase build on one of my T1114 in #4836 and I'll report back with my findings.
thebentern
commented
6 days ago After some tests on the experimental build, I was able to get a few messages through at around 120 bytes but reliability steeply declined with any payloads large than that. I was not able to get a single 200 byte message though.
enema-combatant
commented
6 days ago Without question, in my 4 decades following technology, this is the most emotionally mature response from a vendor that I've ever seen. Literally, it started with "Here are all the testing processes details we had done, share them here, maybe it will help us all solve the problem together." <- Gold. Openness and a willingness to ask for help - isn't a bad thing. In my related field, OPENNESS is key, and hiding information leads to bad things happening. Good luck on the troubleshooting. If it were my guess, it's RF-emission related, somehow. But I know so little about 80% of the technical aspects of the landscape here, as I'm just getting started. Used to do radios in the military, but my learning curve seems WAY higher with what this community is about. And that - folks - is a challenge I like.
Technologyman00
commented
6 days ago @Heltec-Aaron-Lee Have you looked into raising the max current of the SX1262? I can only guesstimate as I haven't yet tried it myself. But according to the spec sheet of the SX1262 it requires a current of 120mA to broadcast at 22dB
From the picture on the product page:
The current it draws (for an unknown message length) is 136mA which is very close to the firmware imposed limit of 140mA
The referenced chapter of the SX1262 data sheet also gives the warning:
So I wonder if the randomness of the messages being sent or not is because the SX1262 is bumping up against the current limit preventing the message from being transmitted properly. And for the some devices that don't have the issue is because of the silicon lottery so some chips are more efficient and what not.
Appendix: I am not an electrical engineer so take all my points with a grain of salt.
Looking at the testing of increasing the voltage to the crystal it kinda goes against the point of hitting the voltage limit as for a datasheet of a 32M TCXO: the current goes up with a higher voltage.
but then again, changing the crystal to use the crystal of the nRF52840 it does reduce the current consumption and improve the response of the SX1262.
meshtastic-bot
commented
6 days ago This issue has been mentioned on Meshtastic. There might be relevant details there:
https://meshtastic.discourse.group/t/problems-with-heltec-t114/14489/25
912097713
commented
6 days ago @Heltec-Aaron-Lee have you see the Semtech SX1262 Recommendations for Best Performance_V1.1, from the Table 1: LoRaWAN Packet Durations,
The Maximum Packet Duration is small, for example, SF11, Maximum PHYPayload Length 64 Bytes. Is this a chip feature, have you connect with the Semtech?
And the LDRO feature can help from this documents,
Can you add the Meshtastic to improve the longer Packet?
Hope the document helps you.
lupusworax
commented
6 days ago I think the low data rate optimization was already mentioned but for it to work all the devices have to have that feature to be turned on or they cant communicate with each other.
912097713
commented
6 days ago I think the low data rate optimization was already mentioned but for it to work all the devices have to have that feature to be turned on or they cant communicate with each other.
yes, so i think can heltec add the LDRO feature to the meshtastic
lupusworax
commented
6 days ago Heltec does not provide meshtastic firmware, and if the Meshtastic Team adds the feature ALL current active nodes running without that feature wont be able to communicate with new ones, makes it hard for hard to reach nodes/ repeaters on mountains etc. that wont be updated for a long time, pretty much renders them useless, suddenly splitting the Meshtastic network into two.
dahanc
commented
6 days ago Besides, the docs say that LDRO is advised when the symbol time exceeds 16.38 ms. LongFast uses an 8.19 ms symbol time (SF 11, 250 kHz bandwidth: 211 / 250000 = 8.192E-3). While it's interesting that enabling LDRO fixes the problem, it shouldn't be necessary. Edit: by default, RadioLib automatically enables LDRO if the symbol time is over 16 ms. As far as I can tell, Meshtastic doesn't change the default behavior.
And keep in mind that Meshtastic works on other nRF52/SX1262 boards (e.g., RAK4631), so nothing new should be needed for the T114.
It's interesting that running the ESP32 firmware connected to the T114's RF section works. Makes it seem like there's a firmware setting in the T114 variant file that's not quite right. But then some other symptoms make it seem like a hardware issue.
Would it be useful for someone with an SDR to record a transmission from the T114? Perhaps someone could see what's wrong with it... e.g., starts out fine, but output power drops toward the end; or starts out fine, but frequency drifts towards the end, etc.
kfigiela
commented
6 days ago Hello everyone! It looks like there can be multiple issues here.
I have built a version from https://github.com/meshtastic/firmware/pull/4836 a couple of hours ago (with all master changes merged as of time I was building it). It improves things. However, there is some firmware issue out there. It looks like the real max message length limit is lower than what client app thinks (and restricts the input).
When I use Android app and input the longest possible message (to the limit), send will fail immediatelly (no RF happens, message is marked as not delivered in an instant). Note the Error=7, returning NAK and dropping packet. message.
When I remove 14 characters (from the max input limit) message is transmitted to the other client.
I can reproduce this either on T114 and V3 boards running the firmware from main. This works as expected (can type as many characters input will accept) with board running 2.4.2 firmware, so that would indicate regression. This is somehow weird. The number of characters I need to remove from the message is not consistent, sometimes I need to only remove 2 characters from the message, sometimes this needs to be 14, but seems to be consistent within the single chat channel. Definitely needs more investigation, but at least some log messages are out there.
Would it be useful for someone with an SDR to record a transmission from the T114? Perhaps someone could see what's wrong with it... e.g., starts out fine, but output power drops toward the end; or starts out fine, but frequency drifts towards the end, etc.
@dahanc, did that yesterday. There was nothing visually obvious there. RF is transmitted, power and frequency seems to be right. The receiving node gets the transmission – and reports the same duration (measured in milliseconds) in logs, but reports CRC error. Since TXCO voltage change seems to help, perhaps this could be symbol clock issue? This needs more investigation.
Heltec-Aaron-Lee
commented
6 days ago So I wonder if the randomness of the messages being sent or not is because the SX1262 is bumping up against the current limit preventing the message from being transmitted properly. And for the some devices that don't have the issue is because of the silicon lottery so some chips are more efficient and what not.
Appendix: I am not an electrical engineer so take all my points with a grain of salt.
Looking at the testing of increasing the voltage to the crystal it kinda goes against the point of hitting the voltage limit as for a datasheet of a 32M TCXO: the current goes up with a higher voltage.
but then again, changing the crystal to use the crystal of the nRF52840 it does reduce the current consumption and improve the response of the SX1262.
Hi @Technologyman00, Thank you for your effort.
I don't think this is the reason, For the entire system, the crystal oscillator consumes very little current, and we have also recorded the voltage curve of the entire system during operation, which is very stable with minimal ripple in various states. We have tried using an external power supply to power the TCXO crystal oscillator, but the situation has not improved.
Heltec-Aaron-Lee
commented
6 days ago @Heltec-Aaron-Lee have you see the Semtech SX1262 Recommendations for Best Performance_V1.1, from the Table 1: LoRaWAN Packet Durations,
The Maximum Packet Duration is small, for example, SF11, Maximum PHYPayload Length 64 Bytes. Is this a chip feature, have you connect with the Semtech?
Regarding this document, it's for LoRaWAN communication. LoRaWAN use 125K bandwidth by default (Long-Fast use 250K BW), so the payload length is shorter. Moreover, in LoRaWAN mode, when the spreading factor in SF11 and SF12 and a single byte sending time longer than 16ms, it will automatically turn on LDRO (there is a mechanism in the LoRaWAN source code to handle this aspect). So I don't think we need to look for a solution from this perspective.
meshtastic-bot
commented
6 days ago This issue has been mentioned on Meshtastic. There might be relevant details there:
https://meshtastic.discourse.group/t/problems-with-heltec-t114/14489/27
Heltec-Aaron-Lee
commented
6 days ago Would it be useful for someone with an SDR to record a transmission from the T114? Perhaps someone could see what's wrong with it... e.g., starts out fine, but output power drops toward the end; or starts out fine, but frequency drifts towards the end, etc.
@dahanc, did that yesterday. There was nothing visually obvious there. RF is transmitted, power and frequency seems to be right. The receiving node gets the transmission – and reports the same duration (measured in milliseconds) in logs, but reports CRC error. Since TXCO voltage change seems to help, perhaps this could be symbol clock issue? This needs more investigation.
Hi @dahanc @kfigiela We also tried the same thing. When sending long packets in Long-Fast mode, the SDR shows that the received content is the same as the transmitted content. However, when receiving 40 to 50 characters, the content starts to be inconsistent. The receiver shows CRC Bad.
Heltec-Aaron-Lee
commented
6 days ago I don't think LDRO should be turned ON, because in this mode it will not be able to communicate with other devices that do not have LDRO turned on. This is not friendly to a large number of existing devices. It feels like when I am taking an exam, I find that I don't know how to answer the questions, and I can't ask the teacher to modify the test paper! 🤣
From recent experiments, all problems now point to the crystal oscillator. Although both nRF52840 and SX1262 use 32M XTAL, there is still a slight deviation in their frequencies. In addition, the board is relatively small and there is not enough space for decoupling. Therefore, resonance occurs between them.
Based on this conjecture, we have made a new hardware sample, which will be received soon for verification.
fifieldt
commented
6 days ago Really appreciate the work of you and your team on this @Heltec-Aaron-Lee
JetJunkie
commented
5 days ago With support for the T114 being removed now from the Meshtastic flasher. What is the best method for completely erasing the device and starting over from scratch. I now have two completely non-working units that were working yesterday. I am sure it is of my own doing, but now, I have no erase file to wipe them and start over.
Technologyman00
commented
5 days ago @JetJunkie You can go to the github actions to download the firmware. The erase file is in the zip for the T114 https://github.com/meshtastic/firmware/actions/runs/11017426778
resunltd
commented
5 days ago Any chance Heltec engineering can address the Solar input not charging the battery?
I have three T114 with this issue. I believe others have seen it as well.
Thank you.
Technologyman00
commented
5 days ago Any chance Heltec engineering can address the Solar input not charging the battery?
I have three T114 with this issue. I believe others have seen it as well.
Thank you.
I have 2. Their response to me was to wire the solar panel to the 5V and GND pins. I know Muzi Works is also looking into it.
S5NC
commented
5 days ago I don't think LDRO should be turned ON, because in this mode it will not be able to communicate with other devices that do not have LDRO turned on. This is not friendly to a large number of existing devices. It feels like when I am taking an exam, I find that I don't know how to answer the questions, and I can't ask the teacher to modify the test paper! 🤣
From recent experiments, all problems now point to the crystal oscillator. Although both nRF52840 and SX1262 use 32M XTAL, there is still a slight deviation in their frequencies. In addition, the board is relatively small and there is not enough space for decoupling. Therefore, resonance occurs between them.
Based on this conjecture, we have made a new hardware sample, which will be received soon for verification.
LDRO is just another way of increasing the link budget at the expense of data rate, meaning messages will be sent over a longer period of time. This isn't stated straight up in the SX126x datasheet, however if you look at the symbol duration calculation for Low Data Rate Optimization in comparison to without it, you can see the effect.
Heltec-Aaron-Lee
commented
5 days ago Any chance Heltec engineering can address the Solar input not charging the battery?
I have three T114 with this issue. I believe others have seen it as well.
Thank you.
Connect your solar panel to this socket, or connect to 5V directly.
912097713
commented
5 days ago @Heltec-Aaron-Lee hi, i use the continuous wave to test the Crystal, it seems stable, only 0.5 ppm.
So, i think you should check other things.
resunltd
commented
5 days ago Any chance Heltec engineering can address the Solar input not charging the battery? I have three T114 with this issue. I believe others have seen it as well. Thank you.
Connect your solar panel to this socket, or connect to 5V directly.
Yes, I have tried using the "Solar" port for the panel, however I see no charging when measuring across the battery. I have just reconfigured one with the panel wired direct to 5V & Gnd on P1
adingbatponder
commented
5 days ago In case it helps - I thought I saw a correlation with Bluetooth (BLE) power dropping when LoRa messages are sent. I saw this with T114 in the H2T case that was having BLE issues. The BLE connection to phone / iPad would cut off when pressing to send a message or even get a traceroute. Could be a red herring but thought I would point out my impression.
lupusworax
commented
5 days ago In case it helps - I thought I saw a correlation with Bluetooth (BLE) power dropping when LoRa messages are sent. I saw this with T114 in the H2T case that was having BLE issues. The BLE connection to phone / iPad would cut off when pressing to send a message or even get a traceroute. Could be a red herring but thought I would point out my impression.
So far I built 4 T114 devices ( two different cases I remixed myself but not from Muzi) never had BLE issues a single time, using android( Xiaomi 12 with Hyper OS)
kfigiela
commented
5 days ago @adingbatponder I also experience this while T114 is powered by a small (~200 mAh) cell which has probably degraded. That was the only one I had laying around that would fit into the heltec's case. The symptoms are, BLE disconnects, but message is sent and after phone reconnects, confirmation mark appears. This happens all the time with the "small" battery. When I switch to a larger battery BLE connection is rock-solid.
Unfortuanetly, I don't have osciloscope to measure what's going on with battery voltage during TX. My guess is, the voltage drops and there is short brown-out, so BLE part of MCU "crashes". It'd be a good idea to monitor logs while this happens. That would require to connect UART adapter to RX/TX pins – I guess console is also dumped there, so this could give more insight. I have tried to connect via USB with +5V pin disabled, but USB device is not detected. Probably USB is only enabled by MCU when +5V is detected on VBUS.
I wonder if this is an user-error, i.e. battery can't give enough current, or a hardware design issue. I have connected the same cell to V3 board and it works just fine. This would probably require more investigation from Heltec team.
barbecued
commented
3 days ago After some testing, I believe the same issue occurs with medium/fast too, but the limit is 230 characters in can send. Any more than that fails to send
It is possibly unrelated though as dropping transmit power didn't help
brolly759
commented
3 days ago @Heltec-Aaron-Lee @resunltd I reviewed the solar issue you are having. Seems to be a hardware bug in the board. If you supply 5v on the SOLAR input pin, the diode D3 prevents the SOLAR input from back powering the VDD_5V rail. The CE pin on the charger IC is connected to VDD_5V and will never go HIGH when solar is used, only when USB is supplied will the CE pin be enabled through VDD_5V and charging will work.
The easiest solution to make it work right away is change D3 for a 0 ohm resistor and that will connect Solar input to VDD_5V. That does come with a problem though. When VDD_5V has power, there is a mosfet (Q2) that disconnects the battery from powering the 3V3 LDO. If you use a 0 ohm resistor and power off of solar, if there are any fluctuations or voltage drops there is a high possibility of your node rebooting when failing back over to battery.
2 ways around this issue will be to either provide a boost cap to the 3v3 rail to handle power fluctuations when the power source switches over or to change your charging IC to a smarter one that handles multiple input sources and dynamically switch from input / battery with no downtime.
Heltec-Aaron-Lee
commented
3 days ago @Heltec-Aaron-Lee @resunltd I reviewed the solar issue you are having. Seems to be a hardware bug in the board. If you supply 5v on the SOLAR input pin, the diode D3 prevents the SOLAR input from back powering the VDD_5V rail. The CE pin on the charger IC is connected to VDD_5V and will never go HIGH when solar is used, only when USB is supplied will the CE pin be enabled through VDD_5V and charging will work.
The easiest solution to make it work right away is change D3 for a 0 ohm resistor and that will connect Solar input to VDD_5V. That does come with a problem though. When VDD_5V has power, there is a mosfet (Q2) that disconnects the battery from powering the 3V3 LDO. If you use a 0 ohm resistor and power off of solar, if there are any fluctuations or voltage drops there is a high possibility of your node rebooting when failing back over to battery.
2 ways around this issue will be to either provide a boost cap to the 3v3 rail to handle power fluctuations when the power source switches over or to change your charging IC to a smarter one that handles multiple input sources and dynamically switch from input / battery with no downtime.
Indeed the D5 is 0R in the earlier versions, in later versions, the CE pin of 4056 is actually connected to the Solar network. The schematic diagram in the resource has not been updated yet. I asked my colleagues to prepare the latest schematic diagram.
brolly759
commented
3 days ago @Heltec-Aaron-Lee @resunltd I reviewed the solar issue you are having. Seems to be a hardware bug in the board. If you supply 5v on the SOLAR input pin, the diode D3 prevents the SOLAR input from back powering the VDD_5V rail. The CE pin on the charger IC is connected to VDD_5V and will never go HIGH when solar is used, only when USB is supplied will the CE pin be enabled through VDD_5V and charging will work. The easiest solution to make it work right away is change D3 for a 0 ohm resistor and that will connect Solar input to VDD_5V. That does come with a problem though. When VDD_5V has power, there is a mosfet (Q2) that disconnects the battery from powering the 3V3 LDO. If you use a 0 ohm resistor and power off of solar, if there are any fluctuations or voltage drops there is a high possibility of your node rebooting when failing back over to battery. 2 ways around this issue will be to either provide a boost cap to the 3v3 rail to handle power fluctuations when the power source switches over or to change your charging IC to a smarter one that handles multiple input sources and dynamically switch from input / battery with no downtime.
Indeed the D5 is 0R in the earlier versions, in later versions, the CE pin of 4056 is actually connected to the Solar network. The schematic diagram in the resource has not been updated yet. I asked my colleagues to prepare the latest schematic diagram.
That is awesome, though my last point still stands, the mosfet switch over from VBAT to SOLAR (VCC_5V) can cause a brief moment of power failure when trying to power the LDOs.
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