Linuxslate.com Forums

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



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 or RF output power). I was sure that I would be dominating the Nationwide Mesh by the next evening.



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 was 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. This method doesn't seem to be described any place else, but if you are comfortable with the command line, it is straight forward, safe, and quick.

I already had the official Espressif esptool installed from the Ubuntu App Store.

NOTE: Excepting Physical or Electrical Damage, it is impossible (or at least difficult) to "Brick" an ESP32 device. You should always be able to return the device to DFU mode and 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:

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

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

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 MacOS 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.
(See next Post for a partial workaround to enable partial functionality of the scroll wheel in Meshtastic without enabling Canned Replies.


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 not about using the app. For a remotely administered node, will be accessing it from the app
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.)
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 (Don't say "Display Config" -- I can't stop!) --> 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

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

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

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. I will build either a separate hat with IRDA transmitter and receiver, as part of the CC1101 hat or separately.

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.

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


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.


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.

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 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: After trying Firmware 2.7.20.6658ec2 Alpha on my LilyGo T-LoRa Pager, it began sending random character messages. (Not 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, 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.

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, 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 look b*d*ss walking around with a dipole sticking out of your LilyGo T-LoRa Pager .