Product Advice for Prototype

[ghowe]

I am building a prototype sensor and am looking for some advice on which of your products (if any) would fit my needs.

I have a sensor mounted a few inches underground and need to send data back to a gateway with constant power and upload to the web via a cellular shield.  The sensor must operate on battery power (likely a 800mAH LiPo) for 6 months or more and transmit over 200m away and through a large building.  Another option could be to wrap the antennas around a buried control/power wire connecting valves to a controller where the gateway will be installed.  The sensor module repeatedly samples a turbine style flow sensor with builtin hall effect sensor, counting the number of pulses over a set time frame 10 milsec, and time stamps the reading.

The location of the sensors preclude the use of solar chargers or constant power.  Only cellular web connection is available for data upload.

[Felix]

If your sensor has a high duty cycle (ie it's more often ON than OFF) then that will drain your battery. This sounds similar to my water meter where a pulse can happen at any time and that sensor has to be ON to capture the moment, so permanent power is provided because it was conveninent. In your case you only have a battery. Not really sure how that's going to work, it really depends how much power your sensor needs and the power duty cycle required.
In terms of transmission I think Moteino/RFM69 should work between your sensor node and your cellular node, even if you tweak the settings/lower the bitrate to get more range, several examples here in the forum. However your antenna being elevated rather than on the ground will make a bigger difference.
Without actually trying this it's hard to guesstimate what will happen. Your bigger problem to solve is powering the sensor node rather than communicating.

[ghowe]

Thanks for the advice.  I ordered two test units to try hopefully I can make something work!

Regarding the sensor, nose is sleeping until flow is detected then samples at a periodic rate.  For that I suspect the sensor has to be powered all the time.  Accuracy of flow start isn't critical above say plus or minus 10 seconds of actual.  Subsequent samples are.  What's a good way to handle this situation for conserving battery power related to the sensor in your opinion?

Second question: Do your nodes have RTC's integrated or do I need to add a separate module?  The sole purpose of the RTC is provide a date stamp in Epoch format when each sample is complete and before storing/sending.  If I need to add an RTC circuit is there a recommendation that works of 3.3v?  Ones I have seen and used are 5v which requires an inefficient converter.

[Felix]

The nodes do not include an RTC.
An RTC can be implemented at the receiver/accumulator node rather than at the end points.
That is unless you have an imperative need to timestamp all packets coming in. I doubt that's a necessity.
What kind of metric do you need to report to your central node?

You need to sleep your node (everything in the node, including sensors or anything that draws power) as much as possible. Only wake up at deterministic intervals to detect flow, then back to sleep. If flow is detected then setup the sensor to sample at higher duty cycle, and sleep the MCU in between. Depending what sensor you use it could generate interrupts that accumulate a pulse count, which you then transmit when the flow session is complete (no more flow) or at certain intervals during the flow. The central node would then accumulate all those and timestamp them as they come in etc.

Any RTC that works on 3.3v levels should work.

[ghowe]

My reasoning for time stamping the flow when the sample is collected is to ensure consistent time interval for the sampling.  If the time stamp is done at the receiver instead of the node, how accurate are the stamps likely to be?  Plus or minus several millisecs could be acceptable but anything more than .5 sec could affect the data analysis.

[Felix]

My reasoning for time stamping the flow when the sample is collected is to ensure consistent time interval for the sampling.  If the time stamp is done at the receiver instead of the node, how accurate are the stamps likely to be?  Plus or minus several millisecs could be acceptable but anything more than .5 sec could affect the data analysis.

I don't know, that's why i asked what is the nature of the collected data? What does the receiver get?
I understand the data is pulses? How do you quantize and report those pulses?
Or if that's not the case, please explain how the data is measured, and how it is aggregated and reported.

[ghowe]

I'm content pulses for a specific amount of time to get a rate (pulse/sec).  I use this value to compare to other values to look at changes in rate over time.

[Felix]

So are you calculating a pulse/sec and transmit that or transmit all pulses and your gateway calculates the pulses/sec?

[ghowe]

The data is a count of pulses.  No calculations are done before storage.

The sampling duration is hard coded and fixed.

Currently I time stamp at the start of the sampling, then count pulses for 1000milsec.  Code will run again exactly 3 secs after the time stamp.

[Felix]

We're spinning wheels. Looking at code would be much better. Possible?

Either way since you know when you start sampling, or at least the 3s offset, you can still keep timestamping at the central node. The time difference intoduced by the transmission itself can be negligible, or added as an additional offset.

It feels the conversation is drifting away from your initial questions. Do you still have any questions left regarding your hardware setup?