I have a project forming that will require firmware changes to a RAK4631/SX1276 device to achieve much longer battery life via power management and some protocol timing tricks.
I’m expecting at least 3 months to experiment, prototype and test the code.
Best,
Kurt
801.699.6143
Sensor device or router with power timer switch …
Could you describe more about the project? Are the mesh nodes also supposed to last 3 months on batteries? Can you use solar cells …
For maximum battery life, a module could be implemented that synchronizes all nodes immediately after waking up from deep sleep. I currently wait 15 minutes for the time of a node with GPS or NTP.
With 5,000mAh for 3 months means 55mAh per day or 120 minutes for data transfer per day or 5 minutes per hour.
Thank you very much for your input:
The application is to provide sensors for multi-dwelling apartments with multiple floors and scores of apartments per floor.
There will be one centrally located node on each floor with AC power, and these nodes need to mesh across floors and then provide data to a gateway. With no power constraint, these nodes will always be awake. This node can have an accurate clock running for its own timing purposes, but potentially sending a polling packet that includes day/time to the sensor nodes.
There will also be one node per apartment on each floor with a sensor. These nodes only need to wake up approximately once per hour, receive a packet with day/time from the central node, and if one hour has passed, read the sensor, then pass that data to the central node on that floor, then go back to sleep for another hour. This doesn’t necessarily require the full mesh protocol IMO, because these nodes only need to transmit a packet with the sensor data to the central node.
The RAK4631/SX1262 module is considerably lower power than the ESP32 based devices. I have run the numbers using the above ideas, and getting shelf life of a 5200mAh battery should be possible (they client wants 5 years).
So, I think it’s possible to do this, and I’m looking for a software expert that knows the mesh protocol and can help with the software development and testing which can be fully remote.
Robert,
Forgot to mention this project should have funding shortly. We’re hoping we find an expert and we’ll be happy to provide funding for the work.
Kurt
Sounds like what LoRaWAN is for?
This should be possible with Meshtastic. You can configure a device as a sensor and have the values sent every hour. ESP32 also consumes almost nothing in deep sleep.
You then operate several routers or repeaters on a permanent basis. Only one of them needs a WiFi or hotspot to send the sensor values to the Internet via MQTT. You can then process the sensor values from the MQTT server.
You probably don’t need a repeater on every floor, maybe one in the basement and one in the roof is enough.
What kind of sensors are these?
Have you tested this at all? You have to manually intervene to get out of deep sleep, this is what lorawan is for, no need to square peg in a round hole for everything.
Yes, run several deep sleep devices
Robert,
The sensor is a high accuracy water flow sensor designed by the client. I should get the schematics and pictures in the next day or two so we can figure out how to interface with it. Going forward, it may also make sense to interface to other sensor types, but that’s not a requirement at this time.
My day job is with Northrop Grumman Space Systems at Hill AFB, and I do algorithm development for guidance, navigation and tracking for space vehicles. I’m a subject matter expert in signal processing, software, AI and quantum sensing, and my schedule is flexible.
For me this would be a side-gig and your expertise would be most valuable. I just started looking at the meshtastic gear about 6 months ago because about 20 years ago I was GM of a wireless semiconductor company in San Jose and developed one of the first 802.11a chipsets using CMOS for baseband and Silicon Germanium for a single-chip low noise transceiver. This technology and the integration has finally trickled down to the IoT market with low cost and superb receiver performance.
I think the timing on this will be about a month to get the business side done, and the client is hoping to get the initial development done in 90 days with NRE. I’m not sure that’s possible, but we’ll need to figure it out by the time the project starts.
If you have time for something like this, it might be some fun and they’re happy to pay.
Best,
Kurt
Water flow sensors often have a very high current consumption of 10-15mA, regardless of whether they are mechanical or HAL sensors or sonic. I think it will be difficult to operate water sensors purely on batteries for several months. The sensor would have to trigger pulses for a controller and then act as a secondary controller for a Lora-enabled chip.
As I understand it, this is a new and unique sensor with no moving parts, based on some kind of differential thermal technique, patented. The guy that designed it is a pretty sharp Harvard guy.
The control board uses an ESP32 and runs for 5 years on 2 AA batteries. They’ve spent significant $ developing it. This is what drives the requirement on the wireless side.
I’ve signed an NDA and will get full disclosure on the sensor, gateway and their overall system soon.
I’m interested in the RAK4631/SX1262 primarily because I understand the capability of remote software upgrades is complete and works.
Software revs are frequent for Meshtastic, and in a scenario where there are hundreds or thousands of nodes, and without remote updates the logistics would be impossible…
Best, Kurt
I may have misunderstood your requirements. I would install water sensors for consumption as centrally as possible, e.g. at the entrance in the basement and with a fixed power connection.
As soon as you can send sensor values to an MQTT server, for example, I would see little need for updates here. I would rather see this in the software, which then uses the MQTT server as a data source. Can you describe where you see subsequent adjustments in the installation or are you looking for bug fixes?
Robert,
I like the way you think…
Let’s take the case of an apartment construction site. The problem that’s being solved is that water leaks are a major problem that often damages more than just the unit where the leak occurs (particularly for floors below).
So the system needs to detect water leaks for each unit, so they know what area the leak occurs in, and where to look. Therefore, a sensor is connected in series with the water supply to each apartment at the time of construction. And of course in modern construction, WiFi is generally provided, however, the building owners do not want to have any sensor data traveling over their WiFi network, thus the separate system and gateway.
On the business side, it turns out that insurance companies will provide a big discount (typically 10’s of thousands of $'s per year) for a buildout that incorporates this technology. Knowing who’s going to invest in this kind of solution and that there’s a monetary reason to do it is key. If you look across America you’ll see thousands of large apartments and multiple-dwelling units under construction.
I should have more information from the client in the next few business days. If you have any interest in helping with the software pieces, that would be great, and it probably makes sense to get a mutual NDA together so I can share the specifics.
I can tell you I don’t waste my time on things that don’t make money. I have plenty of other hobbies for entertainment. The guys behind this are serious folks and they have projects and investors behind them.
Best,
Kurt
Oh, and to answer your questions on updates… you might be right, but I think it depends on the final solution.
As a hedge, I’d rather have the ability to fix bugs, or to add sensors going forward without having to visit each node and flash new software.
Kurt
Just wondering, do you use VSCode for Meshtastic development? I’m having a devil of a problem building code for a HeltecV3…
Kurt
I have no problem with Heltec V3 and the new version of VS Code and PlatformIO.
Thanks, I’ll make sure I have the latest versions and watch a tutorial…
If I understand you correctly, your use case is monitoring during the construction phase and not recording the consumption of the individual residential units later on.
In Germany, you can only use state-calibrated water meters to record consumption. They also have to be replaced regularly every 5 years, which is great business for the companies commissioned to do this. In my opinion, a LoraWAN solution would also be an option here.
In your case, would you remove the sensors later after the building work is finished? There are also non-contact sensors such as the flow sensor type 8098 FLOWave from Bürkert. You would probably need a sensor that can also detect very small amounts of water when it comes to structural damage.
I find your idea very exciting and wish you every success in implementing it. Unfortunately, I don’t have the time to support you. You will find many developers from the IoT and Lora environment on Discord Meshtastic. You might want to ask for supporters there.
Robert,
I appreciate all your knowledge and input.
The 8098 sensor you mentioned is $US5490.00.
The new sensor my client developed is a tiny fraction of that and they plan to install it permanently on every main waterline going to each apartment to collect data over many years.
I’ve got niece that lived in Germany, beautiful country.
I agree there should be several SW engineers doing Meshtastic work.
My best wishes to you.
Kurt