This doesn’t have GPS but might be good hardware for a repeater?
https://doc.rakwireless.com/rak4600-lora-evaluation-board
£28 but should only need a cheap solar/battery set up. Appears from the silkscreen to have inbuilt solar controller too.
Yeah, but I’m not sure you want to trust the user with this setting – RF conditions may change, the antenna may fall off, etc. Or a hiker may randomly perch on a splendid vista and have better coverage than any repeater. Actual nodes-in-view coverage may have nothing to do with a user-input setting.
IMHO, available battery power would be a better determining factor. We’d assume repeater nodes have plenty of power and can thus always run in “who cares about the watts” no-sleep mode, but we don’t want to drain a hiker’s last 10%. On the other hand, if that hiker’s node is plugged into a solar panel at camp, it’s an ideal router/repeater again.
(Side note, this is how the Prius uses battery power. When the traction battery is in the middle of its state-of-charge range, the car will blend battery power with engine power. But if the battery is above 90%, say after a long downhill where regenerative braking filled it to the brim, the car will prefer electric-only propulsion, until such time as the battery returns to normal range. Thus, prior to the release of an official PHEV version, there was an aftermarket plugin conversion kit which threw a bunch more batteries in the trunk and used a DC-DC converter to dump power into the traction battery, keeping it right at its 99% voltage, which persuaded the powertrain to run electric-only a lot of the time, until such time as the extra batteries were depleted, and the system reverted to its normal blended strategy. You’d go home, plug the extra batteries into the wall, and charge for tomorrow’s drive.
I mention this because it’s exactly how I picture Meshtastic working. A node automatically acts in “spend all the power!” mode when its battery is fully charged, because it has some external source, which might actually be a larger USB pack or something. When that goes away, it reverts to normal operation to make the most of the power that remains.)
EDIT: I think there’s a two-birds-with-one-stone approach: The user config bit should be “Act as repeater above this battery level”. So if you want the node to always act as a repeater, set that low and it’ll always be above it. If you want to never act as a repeater, set the threshold as 101%.
I think this is a good idea going forward anyway, for reasons mentioned in this Reddit thread. If two nodes (be they phones, or hardware nodes) can see each other directly over bluetooth, send the message that way! It’ll only occupy a few ms of the plentiful 2.4GHz spectrum, instead of spending many seconds stomping on the scarce sub-GHz spectrum.
It would be nice to be able to disable this for testers who want to make sure their messages go via Lora even if their testing phones are inches apart on the same bench, though…
3 Likes
I really like your suggested approach about having functional statuses according to the battery percentage, from full activity to periodic beeps in deep sleep. It shouldn’t be difficult to apply as it is a mere state machine connected to the power gauge.
Going to the frequency escalation, having nodes always pinging around on WiFi and BLE to see nearby nodes is an enormous waste of power. GPS isn’t reliable as we can’t assume all nodes will have a GPS receiver onboard. Maybe RSSI?
I don’t think BLE pings cost that much power, and anyway, I think you could just do it when a packet comes in. Wake up the BLE for a moment and see if there are nodes within Bluetooth range, before deciding what interface to forward the packet to.
2 Likes
True - but software developer time is precious (especially given the small number of devs who are not me who are currently working on the project). So I think the idea of also bridging over BLE where “two users are in BLE range (which is really not that large anyways) of each other” is a complicated edge case I don’t think I’ll be tackling soon.
But as always, if someone is really excited about this feature and is interested in making a set of PRs to support it we can totally discuss that and it might make sense in that context.
5 Likes
This is a good option, but a terrible assumption.
2 Likes
Would the original LoPy be any good as a repeaters? lopy docs/datasheet. I’ve a couple with expansion boards that I would love to be able to use as repeaters.
You might want to look into Lithium Titanate batteries. They have crazy low temperature operation. I’ve seen some quoted as -50 to 65 C. Very fast 10C charge current (for brief sunrise/sunset days). You can get used packs for not a whole lot of money. They also have a very long cycle life (upwards of 7000 cycles) making used packs viable options.
3 Likes
I’ve seen them before, but haven’t come across any rated below -30C. And those still needed to be charged at close to 0C. The charging temperature tends to be the rub with lithium even if they maintain usable discharge capacity in colder ranges. But if some manufacturers have figured out some voodoo, I’d be happy to find them.
1 Like
Too bad you can’t get some RHUs.
I’ve seen small prototypes built off scraped Americium cores from flame sensors
A more practical option may be a simple circuit that connects the output of the solar cells to a restive heating element if the temperature is less than zero degrees. Then keep the setup in a well insulated enclosure.
2 Likes
I made some rough calculations and with a 5watt solar panel you can warm a 0.1Kg battery using something like 444watt/s or roughly 5watt panel can warm up a battery in about 1 minute with a delta-T of 10C. So basicallty the panel can heat/charge/heat/charge at 1 minute intervals. Good insulation is paramount.
1 Like
In lower latitudes, warming batteries via solar probably pencils out. I’m at 65°N, and there’s almost zero sun exactly when it’s the coldest. Even when there aren’t clouds, direct sunlight doesn’t clear the trees. There’s diffuse light for 3-4 hours.
I currently have 4x 100W nominal panels, and the highest efficiency I get is 80% in June. Even direct sunlight in winter has significantly less usable energy due to increased cross-section of atmospheric traversal (I’m making up terms to describe a phenomenon that’s real, but I am not a scientist) at these latitudes.
Apples to oranges, but my phone battery freezes in an insulated bag at -20°F while being heated by a resistive element powered by [effectively unlimited] juice from my snowmobile — while it is self-heating by turning on the flashlight, screen and processor intensive apps.
None of this is to say it’s not possible, but having messed around with a few battery chemistries in the boreal forest for years, I’m skeptical of their use in remote repeaters.
Different latitude or different climate or higher budget and the question gets easier.
2 Likes
Good point. Also heating invites a lot of condensation… So what is the solution for battery + solar in such conditions? SuperCaps? None? SLA?
1 Like
I think a combination of tiny wind + solar + supercapacitors has potential to smooth the bumps out. I’m not in a high wind area, but the average wind speeds are highest during the months solar energy is the lowest.
If whatever is holding the charge can opportunistically harvest a high percentage of solar in short durations, I really only need to get through 7-8 weeks of non-useful solar. 2nd week of November and 1st week of February tend to have decent solar energy for an hour or two (when it’s not cloudy).
Another idea I’ve been tossing around is just dropping off higher capacity (e.g., golf car) lead acid batteries in the fall, and picking them up in the spring to charge. Lead acid doesn’t really freeze unless they’re discharged pretty far, and they’ll still output power when it’s very cold (cars still start at -30F). I haven’t run the numbers, but it might be possible to just run a low-power repeater all winter without drawing the battery below ~12.0V.
Maybe building on one of these for a headless repeater would be ok as consumes ~8uA in deep sleep with RFM95 radio? No bluetooth or GPS, so I’m too much of a rookie so far (waiting for my kit to arrive) to know how location could be set, but as a fixed repeater GPS/bluetooth not so important?
Not sure there is enough memory though as the M0 has 32k SRAM and I think the meshtastic code requires 20k+?
For simple REST API or MQTT interaction there might be in future need to connect off-grid groups via some simple (extensible) server solution.
LILYGO TTGO introduced add-ons to their TTGO T-SIM7000G (which is NB-IoT).
Product link: https://www.aliexpress.com/item/4000542688096.html
with LoRa 868MHz and 915MHz shields.
Few other GSM 2G/4G boards are available as well.
modular - https://github.com/Xinyuan-LilyGO/LilyGo-T-PCIE
2G - https://www.aliexpress.com/item/33045221960.html
And they added interesting option for “detached display”/ HID 
https://www.aliexpress.com/item/4000971508364.html
5 Likes
This Clock integration for show the current information and messages … or warnings … etc. will be nice. put the t-beam in backpack and have fun!
@sam_uk and @jtbutcher ,
Interesting stuff, Platformio doesn’t necessarily have to be used, it does have some nice features like vs studio code (intelli sense) has as well and Arduino CC , The basics starts by the manufacturer Tensilica they produce a wide variety of microprocessor cores and companies like Pycom or Lillygo TTgo are vendors bringing these chips into market with their specific needs manufactured by Espressif a company that focuses on low-power IoT solutions , the basic way to flash these chips is by using the ESP-IDF from Espressif and the Xtensa compiler, doing so it is vital to get certain settings correct in terms of flashing etc ie: Upload Speed, CPU Frequency,Flash Frequency,Flash Mode,Flash Size and a Partition Scheme and Bootloader, on top of that you want to build the libaries as well, they contain important information making the Hardware and OS work properly allowing you to connect an oled screen or lora radio chip etc some platforms have these parts integrated in 1 chip like the Lopy4 from Pycom has Lorawan,Sigfox,BLeutooth/Ble and Wifi embedded,Pycom’s original firmware runs under micropython and therefore there are some limitations on the Bleutooth/Ble side unfortunately specifically security management needed for pairing and bonding, in theory it is possible to Re-Flash the Lopy4 with new Firmware that contains the correct libraries to run Meshtastic in a environment without Micropython and instead use Freertos working fully under C, the trick is to configure the Xtensa compiler correct so that the libaries needed and components are rated during the build, there are a few files that are important doing this, like sdkconfig, a Json index file and Json CPP file and all the correct Paths, I believe Arduino CC uses preferences.txt, library.properties and package_index.json and package_esp32_index.json, anyway that is from what I have try to gather over time but maybe others on this forum can explain this better or correct me if I am wrong, I would like to make Meshtastic run on a Pycom Lopy4 but not certainly sure if my understanding of how things work is correct, any help would be much appreciated to point me in the right direction
Regards
Mark