UtraLowPower PlugIn or Task for a dedicated processor?

I don’t know if any existing meshtastic hardware can be powered down so much that it draws less than about 0,1 mA. Seems that an ESP does a restart/bootup when waking up from hibernation or deep-sleep, which is not good for ULP.

I think about a plugin that forces a node into hibernation, turn of all LED’s, BT/WiFi CPU and the LoRa chip. And only leaves the RC clock in the ESP running until a specified time is past or until a dedicated pin changes. Then it must do a small task and transmit a prepared message. After that go into hibernation again.

The task could be to transmit some sensordata or transmit a fixed-location + name for a beacon.

Sensordata should be sent in a dedicated channel to only one node where data may be coupled into a home automation system by MQTT. Number of hops should be set as needed by user.

Beacon-data should be sent with zero hops on the normal channel. I know there is already a beacon PlugIn, but that is not optimized for ULP.

The node must be very low power. No display needed, no receiving at all or only receive for a short period after a message waiting for acknowledge. The power must be so low that a node can work for several months on a single li-on battery. Assumed that only a few messages are sent every hour.

Maybe it is more feasable to use a ULP processor (like: Arduino Pro-Mini 8MHz 3.3V) with a LoRa module. Probably the software can be minimized by deleting RX and mesh stuff so that it fits into 32kB. At least it should be able to send a small message as a string that other meshtastic nodes can understand and handle.
My programming skills are limited and porting a mini meshtastic to an ATMega328 is not a very simple task.

Does anyone have thoughts about this or has done this already?

2 Likes

The port of mesthastic on the nrf52 uses 230kb of ram. No way this will fit on an atmega of any kind.

Way to do what you’re suggesting is to improve the sleep behavior and then to use the lora radio to wake the device when a packet is received.

If you wanna give it a shot, we’ll be happy to give you a few pointers :slight_smile:

2 Likes

Probably the only way how, with my fairly limited programming skills, I succesfully can do what I want is to use a 8MHz 3.3V arduino-pro-mini with a LoRa module, and generate a string which mimics a real meshtastic_node and inject it in the mesh. Receiving acknowledge is not a necessity.

I only want to sent some sensor_data over the mesh to my PC because this sensor is out of reach for my usual P2P_LoRa_receiver. These sensor-transmitters can work for many months on a single LiFePo4 battery.

I have a few board here like this (GitHub - hallard/Mini-LoRa: Arduino Mini Lora Battery/Sensors Board) which I used for the TTN-network up until december last year, then they moved to TTN-V3 which made my nodes worthless.

1 Like

If sending frequency is low, you can just use a regular ESP32/NRF52 unit with meshtastic, and have a separate circuit to shut off the whole unit for an hour (or for the period of time you want), then switch it on temporarily.
You will only need to hook in a sensor reading and message sending at bootup, and you are done.

This is a hack of course, and I would much prefer to see improvements in power management for ESP32 units if feasible.

2 Likes

Meshtastic is not the right project for your needs. Look for something similar to zigbee, etc.

tnx for your suggestion.

Zigbee is definitly not the solution.
The sensor i’m talking about is a few kilometers away from my home and out of reach for direct point2point LoRa which would have been the preferred solution.
It is also out of reach from any local TTN gateway.

Yes, you need LoRa but not MESH network.

вт, 19 апр. 2022 г. в 11:38, Costo via Meshtastic <notifications@meshtastic.discoursemail.com>:

1 Like

Now that I think of this further, there’s a new role that we’re introducing in 1.3. It’s still not fully fleshed out but the comment is:

/*

  • ClientMute device role
  • This is like the client but packets will not hop over this node. Would be
  • useful if you want to save power by not contributing to the mesh.
    */
    ClientMute = 1;

That could be made to be a super low power device because it’s not intended to contribute much to the mesh – it can sleep more than other devices.

Thinking about this even more, maybe this suggests another role for a device that only transmits. That would save even more power and support your use case.

1 Like

Also, as a broad idea, an option to operate the mesh clock-synced, with dynamic wake-up frequency, could dramatically increase battery life.
More about that here Who is interested in a solar light relay node? - #27 by Eagle

I think he wants a range extender/repeater. If he has two nodes with a router node in between, then it isn’t a real mesh but a line topology. I think meshtastic works fine in this case.

Maybe you can use the serial interface with your microcontroller of choice, you are comfortable with. But the best option would be to extend the existing meshtastic-device code.