Meshtastic?! More like Meshtragic :-(

[admin]

Meshtastic?! More like Meshtragic! -- My Adventures with Meshtastic and the HelTec V4 and LilyGo T-LoRa Pager

The idea of Meshtastic:

Metastatic is an open source community mesh communications system. The idea is to provide communications without traditional infrastructure such as phone lines or mobile phone companies. In some cases, as will be described below, the Meshtastic infrastructure can even be independent of the conventional power grid. In addition to sending and receiving messages (and possibly voice calls), each Meshtastic device also relays communications for other users. In this way, and assuming there is a sufficient concentration of nodes, far longer communications distances are possible than would be with traditional communications systems of similar power. While an amateur radio license allows legal use of more power, it also imposes certain restrictions. Meshtastic is generally operated unlicensed on the global ISM bands.

The Beginnings of my Meshtastic Journey:

My original intent was to purchase a small and very portable Cyberdeck sort of device. I already have a Valve SteamDeck, which can function as a very fast, capable and portable Linux PC. I was looking for something much smaller, and primarily for exploring my RF surroundings. I had certainly heard of the Flipper Zero, but wasn't particularly interested in a tamagotchi with little boards sticking out of the top (and still not having a keyboard).

To this end, I learned of the LilyGo T-LoRa Pager. Here was a device with at least somewhat of a keyboard, a potentially very useful scroll wheel (rotary encoder), a TFT widescreen display, and an IO connector on the top, so that I can still have boards sticking out for "various RF purposes".

LilyGo T-LoRa Pager. Photo Credit: Unknown Vendor Advertisement

Screenshot from 2026-03-06 17-57-51.png (180.86 KiB) Viewed 324533 times

However, it wasn't lost on me that the intended purposes of the LilyGo T-LoRa Pager, is (Duh) LoRa communications, and since multiple firmwares can be installed, I planned to explore Meshtastic.

My first mistake was to place my order from LilyGo on the very first day of Lunar New Year. OK, my bad, no problem... I'll wait.

...But I couldn't wait... The Mesh was calling me. Overnight shipping from "a certain large retailer" and I was in possession of a HelTec V4 --- a postage stamp sized module with a OLED display, and "More Powwwaaaar!" (28 dbm of RF output power). I was sure that I would be dominating the Nationwide Mesh by the next evening.

My HelTec V4 sits by the window during testing. It will eventually live 30ft up a pine tree.

20260305_ed_pub_sm.jpg (149.88 KiB) Viewed 324593 times

It hasn't quite worked out that way. What will follow will be more that just a little bit of a rant. My intent here is not to criticize an Open Source project. My intent is to provide helpful hints for users trying or considering Meshtastic, and to document things that need to be improved in both Meshtastic compatible Hardware, and in the Meshtastic code base. I've contributed code and fixes to other Open Source projects in the past, but at this point, jumping to something as large and complex as the entire Mestastic code base is probably not going to happen. This, with a little humour and sarcasm, is my contribution.

I do encourage those interested to try Meshtastic. Despite some frustrations, Meshtastic is a great idea -- for both community communications, or in the event of an actual emergency, or significant infrastructure failure. Meshtastic is Cool, Fun, an excellent way to get into modern communications electronics, network communication, HAM radio, etc.

I want to see Meshtastic thrive.

I also want to say that once the Lunar New Year vacations completed, LilyGo shipped my order immediately, and it was on my Doorstep a week later.


Installation:

Wanting to stay reasonably close to an Open-Source purist, my intent was to avoid the Google Chrome "web serial" interface. As we will see, I did end up installing Chrome later. However, I was successful at going the purely Ubuntu way of installing ESP32 firmware.

What is described here utilizes the official Espressif Esptool installed from the Ubuntu App Store. This does not use a third party Python based installer, SNAP version, or Web Installer. This is why the command line is different than what is shown elsewhere.

If you are comfortable with the command line, this method is straight forward, safe, and quick.

NOTE: Excepting Physical or Electrical Damage, it is impossible (or at least difficult) to "Brick" an ESP32 device. You should always be able to replace corrupted firmware using the steps below. Experiment away.

To install Meshtastic on the HelTec V4, I did the following:

NOTE: USB "Drivers" are not required on Linux. You may have to grant permissions to use your PC's USB ports in serial mode. This is well covered elsewhere. I am assuming you have a normal USB "A" to "C" cable connected to an available port on your PC.

• Download firmware-esp32s3-2.7.15.567b8ea.zip (Current Released version as of this writing) from https://github.com/meshtastic/firmware/releases/
• Find the correct binary firmware from the zip file for the Heltec V4. In this case it was: firmware-heltec-v4-2.7.15.567b8ea.bin
• Starting with the unit unconnected (un-powered), Hold the Boot button (not Reset) while plugging in the USB cable. (NOTE: Especially the higher-powered Heltec V4 can be permanently degraded or destroyed from high SWR if operated without a proper load connected to the LoRa Antenna Terminal at all times.)
  Do the Following:

Code: Select all

espressif-esptool.esptool erase-flash
...
espressif-esptool.esptool --chip ESP32S3 write-flash 0x0 'Downloads/firmware-esp32s3-2.7.15.567b8ea/firmware-heltec-v4-2.7.15.567b8ea.bin' 
...

(responses not shown)

This took a total of about 45 seconds, and I was greeted with the Mestastic //\ logo upon hitting reset.

NOTE for LilyGo T-LoRa Pager: If you want to use your LilyGo T-LoRa Pager for Meshtastic only, the Firmware can be installed in the same manner. I suggest using a newer "Alpha" firmware since there are several new upgrades for functionality and battery life for the T-LoRa Pager. I am running 2.7.19 (alpha). If you want to install Launcher (Suggested), obtain the Launcher firmware from https://github.com/bmorcelli/Launcher as shown above, and then copy the appropriate Meshtastic Firmware to the SD card, and install Mesthastic from within Launcher.

As this thread continues, I will add sections for other categories of hints and work-arounds, as well as other issues, bugs, and suggestions.

[admin]

User Interface and Configuration:

So once I got the correct release firmware installed on my HelTec V4, I needed to configure it.

I would have thought that it would provide an SSID providing DHCP and a Webserver. Just connect, supply my WiFi information, reconnect, and navigate to the web interface -- Like -- You know -- almost every piece of networking equipment made!(and many IOT devices) Even my NODE MCU Clock works this way, and it runs on a far less powerful ESP8266.


The Web Interface for my NODE MCU Clock provides a simple web interface for configuration -- all running on it's internal ESP8266. The fact that Meshtastic does not work the same way has been the biggest disappointment of my whole Mestastic journey.

Sadly, Meshtastic *is* running a Web server, it's just not usable directly from a browser as with many devices. I understand that the ESP32-S3, while night-and-day more powerful than an ESP8266, still has limited resources. But by keeping the web interface simple, and with a few clever compression techniques, I would think that it is still very doable. I'll also point out the functional and cool-looking web interface in ESP32 Launcher.

At this point, I could still have avoided proprietary software from Mountain View, California, but I decided to capitulate. I installed Google Chrome so that I could use the same USB connection to connect to my HelTec's Meshtastic Serial Port.


Another General UI Rant:

Before I get into specifics, and some workarounds, I have one more general complaint:

NOTE: A new version of the Meshtastic Android Client recently became available from the Google Play Store. This new version significantly improves the user interface in terms of both appearance and usability, and addresses some of the complaints listed below, however, others remain.

There is no consistency between the various user interfaces. This refers to appearance and type of widget for a specific function, nomenclature of a specific function, units, or allowable input parameters for a specific function. Since the functions are inconsistent among the Web Client, the Android Client App (I cannot check the iOS Client App), and the device firmware, the Web documentation can't possibly match all of them. In fact, the documentation often matches none of them. As can be seen in the Hardware Section, I had a totally unnecessary struggle with setting the battery voltage adjustment constant on the HelTec V4.

The Web Client calls the relative setting "ADC Multiplier Override ratio". The documentation calls it "ADC Multiplier Override" (without the un-capitalized "ratio"), and the Android Client calls it "ADC multiplier override" for a switch that is not present in the documentation, nor present in the Web Client), followed by "ADC multiplier override ratio" (In this case, no caps, except the Acronym) for the actual setting. Yes, the capitalization is a nit, and it's mostly consistent, but here's where it gets worse: I attempted to use the "ADC Calculator" in the documentation, but got values that produced useless results for the HelTec V4. Other users on Reddit and elsewhere also reported useless values when using the ADC Calculator. AI (Gemini) actual got the right answer -- Values close to 4.9, but the Web Client would not allow any value near 4. Also, the Web Client arbitrarily invalidates valid values. For example 1.1 or 1.11 is allowed, but 1.10 is not. Validating input is good, but let's at least follow elementary mathematics, and not invalidate the correct multiplier ratio factor parameter setting value thingy number.

Web Client units (time for example) are generally in seconds, and can be entered free-form (any number of seconds) whereas the Android Client has pull downs with e.g. 1 Minute, 2 Minutes, 5 Minutes...

Even worse is "Shutdown on power loss" !? (from the app) What does not shutdown on power loss? Apparently, this same setting is called "Shutdown on battery delay" "Automatically shutdown node after this long when on battery, 0 for indefinite", on the Web Client. This reads totally differently, but at least makes some sense. The documentation has the following heading and first line: "Shutdown after losing power" "Automatically shut down a device after a defined time period if power is lost." -- Again, it does not have any reference to a battery, or clarify internal or external power.

So I can figuratively hear the maintainers and developers saying "OK, Sure... We'll rewrite all of those tonight. Is 09:00 tomorrow OK to have this all fixed?" I'm not asking for that -- Instead, in a reasonable fashion, check the other UI's when related code is touched. Don't make it worse. If you are working on the menus in the firmwares, Look at the relevant settings in Meshtastic-Andriod, and try to be consistent. If you think the other party is wrong, write an Issue. You are building a communications system. Maybe communicate some - Huh?

I also get that the firmwares are attempting to support many types of hardware -- some with extremely minimal user interface hardware. However, at least in the case of the LilyGo T-LoRa Pager, the on-board UI is unusable.

More UI and Client Issues -- No Particular Order.

Many, if not most, settings changes force an immediate and unannounced reboot. Note comment below about experience with using a mobile phone -- apparently the developers are very familiar with Windows. It does not matter if the settings change is done from the Device UI, or from a Client interface.

LilyGo T-LoRa Pager with Firmware 2.7.19 (alpha) or 2.7.17 (release): Pressing any keyboard button wakes the unit from sleep, Changes to the message page, and begins a message. This means that this pocket-pager-sized unit cannot be put in a pocket or purse without significant likelihood of sending random messages. Today, I sent the letter "w" to the LongFast public chat. The other day, while attempting to get the encoder wheel working, I sent "Yes" from the Canned Messages to the LongFast open chat -- Embarrassing, and it could have been worse depending on what other messages were in the chat at the time. Ironically, one of the few buttons on the T-LoRa Pager that does *not* wake the unit from sleep is the power button. I really think that the Dev's must have never seen or used a mobile phone.

To this end -- and exemplary of the nonsensical locations of functions within the Android Client -- Why does enabling and using the encoder wheel require that Canned Messages to be turned on? Granted, there are some devices that have an encoder wheel (or can have an encoder attached), but have no QWERTY keyboard, in this case, it's obvious that the encoder wheel is used for the Canned Reply. However, especially in light of one -- at least relatively popular commercial device with both an encoder wheel and a QWERTY keyboard, the firmware should not arbitrarily connect the 2 features.

Why are the Rotary Encoder settings dependent on the Canned Message feature.

Screenshot_20260305_2_sm_ed_pub.png (41.5 KiB) Viewed 324567 times

NOTE: See Hardware section for more about the Rotary Encoder, and a workaround that allows the the encoder wheel to be at least partially usable.

Firmware Menus (on device) will close even while you are interacting with them. Some seem to time out on their own, but they will also (at least sometimes) close if you have the display set to "Carousel", and the display advances. As I type this, I have made several attempts to turn on Bluetooth from the device itself. Between the flaky encoder wheel, and the menus changing or disappearing, it has taken me several minutes to turn on Bluetooth.

Web Client fails to connect, or is extremely slow over WiFi: Ref Web-Client Issue #1015. Tried with both Firefox and Chrome. The following seems to help: Browse to https://(nodes local IP address)/ in a separate browser tab, and then go back to https://client.meshtastic.org/, and attempt to connect again.

Web Client: Saving settings fails or is very slow for certain settings. Same settings/same device and network address will update normally from the Android Client.

LilyGo T-LoRa Pager with Firmware 2.7.19 (alpha): Nodes shown in the Device Node List page are completely different from those shown in the Client Node List. Why? Do I have something set wrong? Have unintended button presses blocked most Nodes? The problem persists after clearing the Node Database.

LilyGo T-LoRa Pager with Firmware 2.7.19 (alpha): Nodes in the "Bearings" page continue to show a direction (bearing) hours or days after the last heard time, or if GPS Compass is turned off on the observing node. There is no indication of "Staleness". Again, this could be very bad, even if it's just a lost or injured hiker. Data that is known to be invalid, or stale should not be displayed, or should be flagged as such.

HelTec V4 Settings to Reduce Power Consumption: Numerous articles report on high power demand for the HelTec V4. With default Meshtastic settings, the HelTec V4 will drain even a large battery in a matter of hours.

My Setup: I am using a 3400 mAh LiPo battery that I salvaged from something long enough ago that I do not remember where it came from. While it is old, I believe that the original device it came from was pretty much new when the battery was salvaged. The battery is in good literal shape -- in other words, not puffy or damaged. Charging is provided by a 5W Solar Panel, that has it's own 5V converter. This is potentially (no pun intended) inefficient, because the converter may drop off line (no output) when there would otherwise be sufficient voltage to still charge the battery, however, the 5W panel should provide more than adequate charge in most conditions, and I did not want to break open the waterproof solar panel housing to bypass the converter.

Settings: Note: Values provided are as seen in the Android Client App -- As mentioned, Menu structure, Nomenclature, and units are not consistent between the Web Client and the Android Client. Settings not mentioned are left to defaults, or are changed, but not directly or significantly related to power consumption.

Radio Configuration --> LoRa --> Transmit Power -- Currently left at "30" (Omitting units since the app does not show units for this setting)
Device Configurations --> Options --> (Note: Aren't a lot of these "Options"?) Node Info Broadcast Interval 48 Hours (Yay for units!)
Device Configurations --> Hardware --> (There is a Device section under Hardware -- Sorry, there is just too much material here. I can't stop) LED Heartbeat - OFF
Device Configurations --> Device GPS --> GPS Mode (Physical Hardware) -- NOT_PRESENT
Device Configurations --> Power Config --> Enable power saving mode -- Off (Reference note about using the app. For a remotely administered node, will be accessing it from the app, so this must be left Off)
Device Configurations --> Power Config --> Shutdown on Power Loss -- Unset (Note: I still am not sure I fully understand this setting yet (see other comments). Setting it to e.g. 24 hours may help prevent continued drain on a depleted battery, but it may also cause the node to shutdown and require physical access to restart, or to not restart when the battery is charged again.)
Device Configurations --> Power Config --> ADC multiplier override -- On
Device Configurations --> Power Config --> ADC multiplier override ratio -- 4.92 (This is a guessed number that gave me "reasonable" values for my individual module *if* the battery is properly managed by the hardware -- i.e. 4.20 Volts when the battery "seems" to stop charging. It also makes it indicate external power (Plug Icon) at about the right time.) (UPDATE: Also verified with a DVM.)
Device Configurations --> Power Config --> ADC multiplier override --> Wait for Bluetooth duration -- 10 seconds (Note: Nonsensical hierarchy of items copied for consistency.)
Device Configurations --> Power Config --> ADC multiplier override --> Super deep sleep duration -- 1 hour (This seems to have made the most difference. I am not going to pretend that I understand the nomenclature for any of these.)
Device Configurations --> Power Config --> ADC multiplier override -- Minimum wake time -- 10 seconds (Same note as above.)
Device Configurations --> Display --> Advanced -- Screen on for -- 30 seconds (Can set shorter if the display will never be seen.)
Device Configurations --> Bluetooth --> Bluetooth Config (PLEASE -- Make it stop!) --> Bluetooth Enabled -- Off (Since the device will be in a tree outside, it will probably be out of convenient Bluetooth range. I will normally communicate with the node via WiFi.)

Let's just go for it!! Can we get a "Device Configurations --> Hardware --> Device Hardware --> Hardware Config --> Bluetooth Config --> Bluetooth Options --> Bluetooth Settings -->Bluetooth -->" Ahhhhh!!


With these settings, by HelTec V4 -- With the battery of questionable history will usually be at about 70% (used 30%) in test conditions by the time the sun comes up enough to start generating power on a clear morning. I will report back once I have the actually installed the node in a tree.


More Coming Soon

[admin]

Hardware:

My first (of many) Hardware disappointments:

HelTec V4: As mentioned, the HelTec V4 was purchased so that I could learn Meshtastic in the weeks before my LilyGo T-LoRa Pager arrived, and to act as an outdoor repeater or "range extender" for the Pager, which was rumored to have rather poor antennas (more on this later.)

Someone had given me some waterproof equipment boxes, and I found a very old, but still somewhat healthy 3800mah LiPo battery in one of my bins. I was also able to add a small Solar Panel to my order so that it would arrive the same day as the HelTec V4.

As shown in Post #1, I hobbled everything together in the box, and set it out in the sun to charge -- so far - so good.

When I brought it in, the HelTec was quite hot, and wasn't cooling off. Within a very short time, it shut down. I found that the LiPo battery had quickly discharged to about 2 volts -- dangerously low for a LiPo.

I found out several things: First -- the HelTec V4 has no real battery management. It contains a CN3165 charger (charge only controller), which is a linear (not switch mode) device. The result is that it runs quite hot during charging. There is no mention of under voltage protection (LVC) in the CN3165 documentation.

Battery level is separately monitored using one of the ESP32's GPIO Lines (see User Interface and Configuration section for my difficulties in setting the "ADC Multiplier Override". and for my values to get reasonable readings on my HelTec V4). Battery meter performance is "close enough" without altering settings on the LilyGo T-LoRa Pager.


LilyGo T-LoRa Pager, Firmware 2.7.19 (alpha) Encoder Wheel issues (Again, see User Interface and Configuration section) Note: What is here was tried with both the release 2.7.17 release version, and the latest 2.7.19 alpha. While well positioned, the narrow encoder wheel on the T-LoRa Pager does not feel very nice. It works acceptably in both Launcher, and in the Bruce firmware, but is not functional by default even in the latest 2.7.19 (alpha) Meshtastic firmware.

To partially enable scroll wheel functionality: Go to Settings --> Device --> GPIO, and set Button GPIO to 40. This will allow one way scrolling for the icons strip at the bottom, and in menus. It will not falsely send Canned Messages from the message screen without other interaction. Scrolling either way will advance Right or Down. The Back button can be used to go backwards along the horizontal icon list, but not in pop-up menus. It's very awkward, and takes some getting used to, but it makes the unit overall more usable than having no encoder wheel at all.


LilyGo T-LoRa Pager antennas and range performance: Articles and video reviews have complained about poor performance (range) with the included flip up antennas. Another post stated that the Left antenna (WiFi) was fake -- i.e. there is no antenna element or anything connected inside the left antenna (as viewing the unit from the front.) Note that for most of my initial testing, the HelTec V4 has been nearby, however, I have taken the T-LoRa Pager out with me, and found that it still shows many active nodes, including some of which have connected directly. I will post back after I have more time with the T-LoRa Pager. I will also note that many devices (such as most mobile phones) have good WiFi performance without external WiFi antennas.

NOTE: US Region, LR1121 version of the LilyGo T-LoRa Pager.

Bruce Firmware on the LilyGo T-LoRa Pager (not related to Meshtastic): I feel I should also mention that almost nothing works out of the box with Bruce on the LilyGo T-LoRa Pager. Note: LR1121 version of the LilyGo T-LoRa Pager.

WiFi -- Supported WiFi works in Bruce, Launcher and Meshtastic. In Bruce, only 4 Access Points (AP's) show in the small window, and I have not figured out a way to scroll to other ones. Note that in Meshtastic, the AP name must be entered even if the AP is not hidden. Other than that, WiFi performance is good.

Bluetooth/BLE -- Supported WiFi works in Bruce and Meshtastic. In Bruce, only 4 devices show in the small window, and I have not figured out a way to scroll to other ones. Because of this, actually exploring BT or BLE devices in the area is not possible. I was hoping that Bruce would allow me to do more than a BLE App I have on my phone -- this is not the case by a long shot. Other than that, Bluetooth performance is good.

2.4 GHz RF -- Not Supported. LR1121 is not currently supported in the Bruce Firmware. Note that I have purchased the LilyGo nRF24L01-PA board. nRF24L01 is supported by Bruce, but I have not tried it yet. I do not know of any of these small devices that support 5 GHz WiFi.

433 MHz -- Not supported on LR1121 version. A CC1101 433MHz Module (Supported) is on hand, but I need to build a small "hat" or "shield" for convenient installation on top of the T-LoRa Pager. See later posts in this thread for my (again -- unnecessarily difficult experience getting the CC1101 board working.)

NFC -- Not Supported. All versions of the LilyGo T-LoRa Pager implement NFC using the ST25R3916. The ST25R3916 is Not Currently Supported in Bruce. A response to Bruce Firmware Issue #1855 states: (referring to ST25R3916/LilyGo T-LoRa Pager) "We hope to add support soon." If a PN532 "Hat" or "Shield" were to be constructed, it should be supported. I will also note that in the Factory LillyGo T-LoRa Pager Firmware, the unit would buzz when an NFC hotel room key was presented, but it would not read the key. The same key is easily read (and written) with an NFC app on my Android Phone.

IRDA -- Not Present/Not Supported. Again a separate hat with IRDA transmitter and receiver would be required. See later posts in this thread to avoid significant frustration and possible hardware damage due to incorrect documentation for the T-Lora Pager.

GNSS (GPS and others) -- Supported, but Bruce has only Wardriving and one other GNSS function. Bruce will not simply show Lat/Lon, Direction/Speed, etc.

Display -- Supported and looks good, but neither Meshtastic nor Bruce utilize the screen area or colors well. Both firmwares just appear to be spread out versions of the screen on devices with small monochrome OLED displays.

Encoder Wheel and Button -- Partial Support Due to the poor feel, lack of responsiveness, and poor UI's, accurately navigating menus or making selections is hit-or miss at best in both Bruce and Meshtastic. Pressing down to make a selection is nearly impossible without unintentionally making an up-down input at the same time. The click feel, and actually making an up or down input is completely unrelated. See elsewhere in this thread for specific issues and workarounds. Due the the combination of issues, while the encoder wheel does work, I must categorize it as Partial Support.

Keyboard -- Supported.


If you have comments/corrections/workarounds/tips, please email john @ this domain.

[admin]

Adding 433MHz support to the LR1121 Version of the LilyGo T-Lora Pager

NOTE: What is here is for using the Bruce Firmware. This does not apply to use with Meshtastic.


As mentioned, My original intent when shopping for the LilyGo T-Lora Pager was for use as an RF Exportation Tool. To this end, I have added a CC1101 433MHz module to my LilyGo T-Lora Pager so that it works in the Bruce Firmware.

Reference this article on Reddit -- where someone did exactly that. This same person provided far more detail in building a very similar setup for the CardPuter ADV.

Reddit User RJ01988 (I will add YouTube name) did an excellent job constructing the modules ("hats") for both the CardPuter ADV and the LilyGo T-Lora Pager. My result is not as sophisticated or as neat. (Note that I do not need the NRF24 modules, as I have the "Official" LillyGo NRF24 board.)

Unfortunately, RJ01988 does not provide a wiring diagram. Note that in a follow up post, he states that "you can just plug it straight into the top header" (Referring to both of the modules he is using.)

It took quite a bit of research, and nearly the death of a CC1101 Module, but it is now working.

Untitled 1.png (156.43 KiB) Viewed 323401 times

NOTE: I now believe the widely published diagram shown on LilyGo's product pages and may other places is incorrect for the header pin diagram. Note that most pictures that show the header pin functions depict the pager Face Down. This page clearly states ">----------Place the screen facing up---------------<" and shows the same pin diagram. Reference also numerous diagrams for the special NRF24L01 module that is made to attach to the LilyGo T-LoRa Pager. It is clearly shown as pins facing the viewer, and mounting holes on the bottom, and again shows the same pin order (athough specific to the special NRF24 module). BOTH CANNOT BE CORRECT.

If the pager is placed faced down as shown in the commonly shown picture, Pin 1 (GND) is to the Lower Left. For the text above the picture to be correct, Place the pager Face Up.

LilyGo T-LoRa Pager with CC1101 433MHz Module

DSC_0793_ed_pub.JPG (88.75 KiB) Viewed 323409 times

Other than this, a common CC1101 module as described, is plug-and-play when Inserted towards the Left side of the pager as it is normally held.

As seen above, I replaced the header pins with a right angle header, so that the module/antenna is oriented vertically. Not also that I used a 12 pin header, with pins 7 and 8 removed to help make it a little less likely that it is inadvertently inserted incorrectly.

Apparently, not many people are building add-on hardware for the LilyGo T-LoRa Pager.

Please see below for my comments on How Well it works.



If you have comments/corrections/workarounds/tips, please email john @ this domain.

[admin]

UPDATE: Due to the HelTec V4 Battery Management Issues (Lack of Battery Management) as described in the Post #3 of this thread, my HelTec V4, which was installed 30 ft up a pine tree, did not survive it's first night.

It has not reappeared on my WiFi network since then despite several days of good sunlight. When I can, I will attempt to retrieve the node, and replace the battery with two name-brand 2800mah rated 18650 cells. These cells have a battery management board that should prevent over discharge, but testing will be needed prior to re-deployment to insure that it will begin charging again if discharged to the point of LVC (Low Voltage Cutoff).

Even with the "HelTec V4 Settings to Reduce Power Consumption" as posted in the previous post, significant capacity for both storage and charging is needed for an un-attended solar deployment of this board.

Reference: GitHub Meshtastic Firmware Issue 9911 as well as the referenced Reddit discussions.

UPDATE:. Lilygo T-Lora Pager After trying Firmware 2.7.20.6658ec2 Alpha on my LilyGo T-LoRa Pager, it began sending random character messages. (Note that any key presses will automatically take you to the Message Page). The device was otherwise unresponsive via the device itself or Bluetooth.

At this point,. due to issues with both the Lilygo T-Lora Pager and the Heltec V4, I was literally and figuratively wiped off the Meshtastic Map. I was forced to do a complete flash erase, and re-install both Launcher and Meshtastic 2.7.19.

[admin]

Note: This Post is specific to the Bruce Firmaware. This does not apply to Meshtastic.

Note: This is based on the current release version of Bruce 1.14

So now that Bruce is working with the CC1101 Module on my LilyGo T-LoRa Pager, what does it do? Can it really be used to steal cars?

--- Well, I think that at least for now, your Bugatti is safe in your driveway. Those worried that such devices can be used to enter or steal cars, or for similar nefarious activities, are generally (but not completely) off-base.

For obvious reasons, I'll keep this pretty high level, and simply write it as a list of bug fixes or enhancements.

--- Under the "RF" main menu (which in itself is not particularly helpful, since many (most) of the main menu items fall under "RF"), many of the functions are poorly or incorrectly named.

--- The function "Spectrum" does not produce a Spectrum display at all. It produces a time domain plot at a single selected frequency that does not seem to update until the display is left, and returned to again. This will display "stuff" on the screen if you already know the frequency of the device you are trying to "attack".

-- The function "RSSI Spectrum" does, in all but one mode, produce a Frequency Domain plot that is closer to what is generally referred to as a Spectrum display or plot, however, it has only start and stop frequency. Given that the spectrum allowed (not necessarily covered by any given module) is non-linear, determining the frequency of any "blip" is generally impossible . The frequency of peaks is not shown. There is no vertical scale. No matter the choice of the few available frequency ranges, the display is scanned so slowly, that a typical press of a key fob, or similar, is rarely displayed at all. If you want to steal someones car, they will need to be awfully cooperative.

--- "SquareWave Spec" is actually pretty cool, but is not at all a Spectrum display.

--- "Spectrogram" is a waterfall type display. and it does show what seems to be a peak frequency and db level. The start and stop frequency is also adjustable, and a scale of 2 other frequencies are shown. However, again, it is so slow as to miss a key fob press. Narrowing the spectrum does not seem to help the speed. I would suggest that the effort put into the "Spectrogram" function should used to make the "RSSI Spectrum" more usable.

--- How each function is exited is inconstant.

--- Functions will allow you to select frequency ranges that the module in use does not support.

--- With no usable way to determine the frequency of a given "target", those wanting to pursue a life of crime will need either a separate device (not going to be specific here), or simply ask the intended victim if they can borrow their car keys.

Note that there *are* some functions of the Bruce Firmware, and specifically the RF section, that could be used for nefarious purposes, however, unless everything the criminals are trying to break into was made in the 1970's they are not going to have a very lucrative life of crime. I'm not going to loose too much sleep over the possibility that there are gangs of youths roaming my neighborhood wielding LilyGo devices or CYD concoctions with Bruce Firmware.

Another Hint: I have some small pre-made 433MHz dipoles from my previous attempts to build an OpenLRS R/C system. Those dipoles increase the sensitivity of the CC1101 significantly. I don't know if it will actually help with any nefarious activities, but you will definitely look b*d*ss walking around with a dipole sticking out of your LilyGo T-LoRa Pager .

[admin]

Not Really Meshtastic Related

Not really Meshtastic related, but this looks like it will be a cool new firmware for the LilyGO T-LoRa Pager:

Melody Machine is a MP3 player and internet radio firmware. It looks to be versitile, support the keyboard and encoder, and includes a cool looking somewhat retro UI.

NOTE: Not currently Launcher Compatible. The developer is working on releasing a merged bin file that should be Launcher Compatible.

Check it here:

https://github.com/wadadawadada/melody_machine

If anyone is aware of other firmwares for the LilyGO T-LoRa Pager, please send links. The Pager is a very capable ESP32 platform, and can do much more than LORA/Meshtastic.

[admin]

Temporary Solution to the HelTec V4 Solar Charging Issue

IMPORTANT NOTE: What is described here seems to be only a partial fix. Please see subsequent post for another possible hardware solution.

Ref Meshtastic firmware - Heltec power management. Sleeping Beauty mode. (Issue #9911)

Problem Summary:

As covered in the referenced Meshtastic Github Issue and elsewhere, The Heltec V4 with any current Meshtastic firmware cannot be used as a solar node due to the fact that it is intolerant of a low voltage situation.

The symptoms include constantly restarting (boot looping) during or after a low-voltage condition, and a factory reset once stable voltage is reestablished. Recovery from this condition is impossible without physical access, which may be difficult if the node is installed in an outdoor elevated location such as a tree, roof top, or tower.

A second symptom is an over-discharged battery, as the HelTec V4 contains no under voltage (LVC - Low Voltage Cut-off) circuitry.

While the Meshtastic developers work on a firmware fix (or at least improvement), it is desired to come up with a simple hardware fix. This fix should utilize inexpensive, and available modules that require only simple wiring. The solution should prevent the Factory Reset issue, and prevent serious under discharge of the battery.


Side Effects:

This solution is imperfect, and should be considered temporary. It suffers from the following:

-- Battery voltage indication is lost. See below for possible workarounds.
-- While battery LVC is provided, the Cut-off voltage of the TP4056 module is not adjustable, and is lower than ideal to preserve battery health.
-- Since any added circuitry must cause additional losses, overall efficiency is lost. More solar charging, and/or battery capacity may be necessary


The Solution:

Heltech V4 Meshtastic Solar Power Fix.png (177.72 KiB) Viewed 34069 times

Circuit Description:

A TP0456 Module is used for Battery charging. The first part of this circuit might seem nonsensical, as it is very similar to the charging circuit already present on the Heltec V4. However, the TP4056 module contains an additional LVC circuit (DW01A) and MOSFET's that isolate the battery from the load when over discharged. Unfortunately, the DW01A cutoff voltage is not adjustable with external components, and it's internally set 2.4 V cut-off represents a significantly over-discharged battery. However, it is likely that numerous consumer products use the DW01A, with few problems.

In addition to mistreatment of the battery, allowing it to discharge to such a low state provides insufficient voltage to the Heltec V4. To correct this, we use a low input voltage boost board, with the the output set to always provide sufficient voltage to the Heltec V4.

The boost circuit will provide a regulated 4.2V or 5V (See Below) from any input voltage down to about 2.0V. It is also over 90% efficient, and is capable of sourcing sufficient current to run the Heltec V4 in almost any configuration (See below). While a boost circuit does not represent an open when in a stalled (e.g. undervoltage) condition, it should function until the TP4056 board isolates the battery at ~2.4V. In other words, in the low voltage cut-off condition, the battery is disconnected at the input before the boost converter stalls. The Heltec V4 experiences a clean power down from a nominal voltage.

NOTE: A paragraph that previously appeared here represented an incorrect understanding of the battery low voltage cutoff functionality of the TP4056/DW01A board. The incorrect paragraph has been deleted.


Testing:

The test setup consisted of the indicated components wired to the "Bat" input connector of the Heltec V4. A somewhat aged 18500 (not 18650) battery was purposely chosen to allow more battery cycles in a shorter time. For initial testing, the power source was a 5VDC USB-C adapter instead of a solar panel. Boost module output was set to approx 4.2V.

The Heltec V4 was loaded with the appropriate current Alpha firmware. Several simulated charging and battery power cycles were done per day, with the batteries allowed to run to depletion and module shutdown. Solar charging was sometimes simulated by connecting and disconnecting the USB-C power source -- simulating periods during charging -- especially early charging -- where there may be insufficient sunlight to continue charging -- including cases where this happens early in the day, causing the minimally charged battery to run down again almost immediately.

After several days of 100% successful restarts, more aggressive "pulsing" of the charging power was performed. At some point this must have resulted in some corruption. The Heltec V4 node continued to function properly, however; the white LED remained on, which I understand to be an indication of corruption.

Ad no point did the Heltec V4 experience an unintentional factory reset, nor fail to communicate on the mesh.


Next Steps:

The solar panel that is installed 30ft up the pine tree provides a regulated 5V, but currently remains in place until I have a solution. I have obtained (for $1) another solar panel of similar dimensions that produces an un-regulated output. I am going to use a buck converter or linear regulator to make this solar panel act more like the one currently in the tree. The steady 5 VDC output will be connected to the input of the circuit shown above, and further testing will be performed. The small battery will continue to be used so that more than one cycle per day can be simulated by simply bringing the solar panel inside.

To regain battery voltage indication, it looks like the "bruit force" method would be to remove Q5 on the Heltec V4 board, and connect battery voltage directly to where the drain was connected (top of R27). The value of R27 could be adjusted so that an "ADC Multiplier Override ratio" value is not needed, or at least one that is acceptable to the the Web client UI, produces an accurate indication of battery voltage.

Reference the Official Heltec Documention for the part Reference Designators.


Notes:

-- Configuration of the Heltec V4 is assumed to be appropriate for unattended solar/battery operation. See previous posts for the settings used to minimize current draw of the Heltec V4. More work is needed to obtain the optimum setting for RF power out vs. draw. Settings above a certain value result only in more current draw without more output power. I need time to experiment with a Heltec V4 connected directly to my RF Explorer to investigate the optimal setting. Once configured properly, the load is well within the margins of the Boost Board -- even with the battery in a low state of charge.

-- Since all regulation takes place downstream of the +5 VCC input or the Bat input, the actual setting of the Boost Board output seems somewhat arbitrary as long as it is greater than the nominal output of the TP4056 board in all conditions, but does not exceed approx 5V. Also, assuming Q1 is on, both connections are essentially tied together, so the connection point probably does not matter.

-- The solution described here does appear to work to prevent firmware corruption and a factory reset of the Heltec V4. However, it does not work with a small solar panel to recover from the case of an over discharged battery. The ($1) panel used for testing lacked sufficient power to recover an over-discharged battery, while simultaneously powering the Heltec V4. This resulted in a condition similar to, but different than boot-looping. While the Heltec V4 did not loose any settings (it functioned normally with all settings, nodes, and messages retained when connected to a USB power source), it did not recover by itself when direct sunlight was available to the solar panel. Given a solar power source with sufficient power and regulation, it does appear that the solution described here is a complete solution given the caveats already noted.


*** Implement at your own risk. Lithium-Ion batteries -- especially when damaged in any way -- including over discharge -- are more likely to catch fire. This solution is intended to improve the over discharge problem, but does not eliminate it. ***

[admin]

Attempt #2 to Create a Hardware Solution for the Problem Described in the Previous Post

The Boost Converter solution described above does seem to eliminate the problem of an undervolt condition causing Firmware corruption during battery depletion of a Heltec V4 Meshtastic node. It may be a complete solution if your solar installation has sufficient power to begin powering the Heltec V4 while simultaneously charging an over-discharged battery.

Problem Description (as it stands now):

During discharge (night), the battery is the only source of power. Thus, as previously described, the Boost board will maintain adequate voltage until the TP4056/DW01A module detects an undervolt condition. At this point, the DW01A will isolate the battery (not the load). The Heltec V4 experiences a sudden power removal shutdown, which it generally seems to tolerate.

The TP4056/DW01A module is intended to charge the battery from a stable source of voltage, such as a USB-C Charger, so it will reconnect the battery as soon as external power is available. This generally makes sense, however in the case of a varying and potentially unstable input voltage, such as a solar panel on a cloudy morning, the Heltec V4 may experience low or intermittent voltage during initial charging. Of course, this depends on the regulation and current capacity of the solar power system. As mentioned, a regulated solar panel that remains off until sufficient power (voltage and current) is available, combined with the previously described circuit is still assumed to be a solution.


Possible Alternate Solution:

In the case of power from a more mediocre or unregulated solar panel -- that while perhaps adequate to charge the batteries during a day of adequate sunlight -- cannot initially provide sufficient voltage and current to simultaneously recover an over-discharged battery. This may result in a voltage being delivered to the boost converter that results in a stalled (unable to start) boost converter. In this case a low and/or unstable voltage will be passed to the Heltec V4. We still needed a way to ensure we allow adequate charge in the battery before attempting to power the Heltec V4. in essence, we want to use the battery as a filter with a very long time constant - perhaps on the order of an hour or more. We need a comparator circuit to monitor the battery voltage, and a MOSFET to isolate the battery and charging circuit from the boost converter until sufficient voltage is available for a clean start under load.

... But the above essentially describes the comparator and MOSFET part of the TP4056/DW01A module. What will be attempted next will be to modify a second TP4056/DW01A board. The first TP4056/DW01A will continue to handle battery charging and protection. Only the DW01A portion of the second module will be used. It will be modified to sense the low voltage condition, and to isolate the Boost module until sufficient power is available to simultaneously run the Heltec V4, and to add charge to the battery.

In other words, the first TP4056/DW01A module will isolate the battery during discharge, and the second (modified) TP4056/DW01A module will isolate the boost module during initial battery charging. The Boost module does not experience a stalled condition during battery charging or discharging, and thus ensures that the Heltec V4 never sees a low voltage condition.

Solar Power Fix_2_ed.png (86.75 KiB) Viewed 33029 times

Details:

-- Pin 5 of the TP4056 chip will be lifted -- disabling and isolating the TP4056 charging circuit. Only the DW01A (with associated circuitry) and MOSFET are used.
-- Power out from the unaltered TP4056 module OUT+ will be applied to the output of the modified module (B+ node). The connection to the Buck module will be connected to OUT+. Note that these 2 connection are the same node. In other words, the (+) side is simply carried through.
-- The OUT- will be connected to the IN- connection of the Boost module.
-- The B- output of the 2nd (modified) TP4056 module will be connected to the OUT- of the unmodified TP4056 module.
-- If the above 2 notes seem backwards (i.e. thinking of the MOSFET switching the lead connected to the load). Think instead in terms of Source --- Load. It can also be thought of as the voltage that changes (B-) -vs- the voltage that should not change (OUT-). The 2 MOSFETs on the TP4056 module do not represent a bidirectional solid state relay/switch. Source and Load from their point of view must be maintained.
-- Removed note about Resistor R6. Leave Resistor R6 as is. I have attempted to delete my edits to the drawing pertaining to R6.


Advantages:

-- Lower cost/lower area solar panels can be used.
-- While resumption of operation of the Meshtastic node may be delayed, the proposed solution increases the odds that the Heltec V4 will initialize correctly without physical access.
-- The better battery protection features of an unaltered TP4056/DW01A module is retained.
-- The same 2 types of modules (TP4056 and Boost modules) == 3 modules total -- are used, and wiring remains mostly simple with only minor SMT work required.
-- Especially if the Solar Charging system terminates in a USB-C plug, or just to avoid confusion, the USB-C connector can be removed from or taped over on the 2nd TP4056/DW01A module.


Current Status:

-- Construction of the prototype board with the (2) TP4056/DW01A modules and Boost converter has been completed.
-- (1) TP4056/DW01A modules was damaged at some point an has been replaced. Another was damaged by messing with R6 (destroyed trace) when I should not have. R6 has been replaced with a old-fashion thru-hole part, so this board needs to be replaced, too.
-- The node is currently "on the air" powered by the 18500 in the 3 module configuration. It is undergoing a battery depletion cycle. Solar charging will be attempted in the morning using the $1 panel, assuming full sunlight as we have been having.
--- The Heltec V4 used for testing has retained all settings and the node database during testing.


*** Implement at your own risk. Lithium-Ion batteries -- especially when damaged in any way -- including over discharge -- are more likely to catch fire. This solution is intended to improve the over discharge problem, but does not eliminate it. ***