Yea a bank of super caps could be the way. The size would mainly depend on the expected transmit duty cycle I guess. A busy mesh would need a pretty sizeable bank.
I could think that the esp8266 could make a good base for a headless device. Paired with a RA-02 module for example it should need less power than a esp32.
Price is nice two. A wemos d1 mini clone goes for $2 shipped, a RA-02 module (sx1278) is less than $4. Combined with a battery or supercap and some energy harvesting device
I have 3 D1 Minis, a D1 Mini Pro (also has a charging circuit), and a couple Pycom LoPy4 sitting around. I need to look into installing on other devices. Are there any guides/reports of folks installing on unsupported devices?
Edit: Reading through this thread Discussion on support for custom build targets (i.e. different radio chips, cpus, one off boards)
I guess esp8266 is one of the easier targets to port meshtastic-device to because it’s the closest to the existing esp32. But I am no programmer so I can’t really tell - for sure it’s still a bunch of work.
Biggest difference hardware wise is the missing bluetooth for the esp8266. As the device can also be completely controlled with USB OTG (works identical with the app and a android phone like when using bluetooth ) their is not really a downside at al. For the use cases as a stationary station/repeater bluetooth is not needed and this can drop cost for building a mesh drastically.
Thinking of $6 (d1 mini + ra-02) and a little bit of soldering for a lora station/repeater is just awesome.
IMO - nowadays it is never worth it to use a esp8266. The ESP32 is almost as cheap and so much better.
Inclined to agree. Not planning on buying more, but I do have a few collecting dust. Minimizing similar drawer clutter in the future is exactly why I started this thread.
Me too. The esp8266 (and it’s child the esp8285) have a few advantages imho. One is for sure the price - it’s still around 50% cheaper than a esp32. Other thing is the lower power consumption which should lead to a greater battery life. And the fact that many people have them in the drawer could also be a benefit
yes - the drawer argument is great. But for most low power applications (unless wifi is a requirement), I think the NRF52 is much better. super low power draw while leaving bluetooth 100% on (< 2mA total - worlds better than the espressive CPUs). So no more of the (painful) sleep/wake dance we have to do on the ESP32.
FWIW, I hope you spend roughly 0% of your time getting ESP8266 to work. Way more important things, and if the rest of us get motivated to make it work, I’m sure it can be figured out without diverting energy.
What about wind turbine for charging and heating up the electronics (just like the enclosures of security cameras do)? There are few designs that could work even in such conditions as you have described.
These turbines are rated to -35c, so may survive even in your temps. You could use a 12v heater element and convert down to 4.2v for LiFeP04 charging maybe?
Personally I’d avoid moving (frozen) parts and go for a massively oversized solar panel with a heating charger on the controller such as this one Then surround the battery system in 40cm of insulating foam.
all really great info in here. I’ll be following closely, I also live in a rural area and would like to strap some nodes up high in a few trees around here to provide for some basic over/around some hills in the area. I’ve been really impressed with the range in dense trees so far.
curious to hear how the CUBECELL works out. looks like a promising platform. but I haven’t pulled the trigger on buying any yet.
luckily I don’t have the temperature issues that @jetatomic has to work with. It’s just cool and rainy in the pacific north west.
This doesn’t have GPS but might be good hardware for a repeater?
£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…
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.
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.
This is a good option, but a terrible assumption.