Hello,
I am prototyping a solution for a client which will use about 100-1000 of the CSR101 in a meshed sensor network. We are comparing the CSR101 to LT / Dust networks Smartmesh solution and comparing which can get the current consumption the lowest, as we need this to run a year on a battery before replacement.
All I know right now is the module can use up to 20mA when transmitting/receiving. It uses <5uA when sleeping, but it's not clear what percentage of nodes on the network need to be awake at any one point to make for reliable transmission. To know that would help me calculate the average current consumption.
I believe I can set it to sleep until the watchdog timer (WDT) expires, and then wake and transmit its sensor readings (datasheet says this can be done in 3ms), then go back to sleep. The max WDT period appears to be 65,536 ms, or about a minute. So I'm calculating (haven't ordered the microenergy sensor dev kit yet, that's next on the list) an average current consumption of (65,533 ms * 5uA + 3ms * 20mA) / 65,533ms = 6uA average.
6uA average draw would be very good, but we're not sure that network transmissions would be reliable. Because you need to have some percentage of other devices on the network awake at any time for the messages to be relayed. But now if you're on for only 3ms at a time, you would need more than 21,845 other nodes on the system (65,536 / 3) to guarantee that another one is on (assuming uniform probability distribution, which it probably isn't perfectly random, etc.) but this will be a problem with 100-1000 nodes in the system.
Are there any theoretical numbers to use that given a network size of n nodes, and an acceptable probability of transmission success p, will tell me how often they need to turn on (and hence, the actual power consumption)? We are OK with not all messages getting through, since they'll be trying again a minute later and the time constant of our sensor data is very low.
These datasheet numbers are no good to me and neither is a sample kit of 3 sensors not a large enough population to get real data.
I'm hoping that someone from CSR / Qualcomm here can comment on how I should figure this. We obviously can't buy 1000 sensors to try it out if it might not work.
Thanks,
Joel
I would be interested in some best practices too.
We tested the scan rate of 0.1%
scan_param.scan_duty_param.scan_duty_cycle = 101;
scan_param.scan_duty_param.min_scan_slot = 4;
This is literally unusable. The time the mesh listens on the air is so short that other devices can not hit that window.
Even after 30 packets, with various automatic density adjustments (maybe a 2.0 feature) it still takes forever to get a reception.
We are running at 1% (=110). This takes about 5 seconds when we use the standard advertising rate of iOS9.
But even running the ads 10 seconds long on iOS, the likelihood to miss the package is about 50%.
The user has to click on the "trigger" button in our app about twice to get a response. Not a good user experience.
What is your best practice to get a better reception, but maintain low power consumption?
Increase the scan slot? To what?
Thanks
Can someone from CSR / Qualcomm please reply to this? I was told when I emailed support with my question that this is the venue for support, and that CSR employees lurk on the forums.
I feel like this would be a common question that people will want an answer to before considering your product for Mesh applications.
If I am dependent on the help of community and no employees are going to go out of the way to help me use your products, that is not acceptable at a professional level. We are not playing with Arduinos here. I am happy to go with alternative companies with greater support.
Thx,
Joel
You've asked a very good question, but the answer is unfortunately not as easy as a simple formula (or even a complex one). The variables include the number of devices, their orientation and placement, duty cycle, number of times the advertisement is sent by each node, etc. The impacts of reducing duty cycle is that the latency can increase, and reliability of the delivered message.
We have done some testing with various node configurations, and with a 2% duty cycle, reasonable density (i.e. not just one node in RF range of another, but several in range of each other), reducing the advertising interval from the default of 90msec to 40 msec, and increasing the number of times a device transmits the device, the behavior was reasonable (i.e. message delivery at good reliablity with acceptable latency).
Longer term, there are plans for a simulator that would be made available to customers to simulate their own configurations.
Hope this helps.
Thank you for the reply.
I agree it's a complex problem, just looking for some real world numbers and expectations. You have provided some, and it sounds like anything close to an average current consumption < 70uA with this model (to reach my >1year battery life) is highly unlikely.
Would be interested in a simulator if/when that is available. Thanks again.
Joel
Yes, we also changed the timing. Here is what we do:
#define DEFAULT_ADV_INTERVAL ( 30 * MILLISECOND ) // was 90ms
#define DEFAULT_ADV_TIME ( 210 * MILLISECOND ) // was 600ms
#define ONE_SHOT_ADV_TIME ( 5 * MILLISECOND )
The transmit timing change does indeed improve the performance a bit. But acceptable? We added a density variable that sends multiple packages, same data, with different sequence number. That does improve a bit more.
Our scan cycle is at 1%
#define MIN_SCAN_DUTY_CYCLE (110) and the scan slots at 4
#define DEFAULT_MIN_SCAN_SLOT ( 4 )
And you are perfectly right, not even our CR123 with 2000mAh will last a year. The duty cycle must be much lower.
I was thinking that scheme of a longer listening time (scan slots) but not as often, would be better to improve
the customer experience. It is easier to send out packets for like 30 seconds at a low rate, but be certain that when
the device comes online within those 30 seconds it will guarantee receive it.
These short intervals on both ends, transmit and receive are not working well.
Ideas?
After full experimentation with the scan slots and duty cycle I must say, the implementation is weirdly limited.
This means, if you want a longer window of more than 1.25s and longer listening times of more than 125ms, you need to implement that yourself with CSRSchedEnableListening().
Using CSRSchedEnableListening() to start and stop the receiver actually works much better because when it is off, the transmitter for mesh packets does not schedule the receiver. You end up with much less power consumption during transmit. Mesh packets don't need the receiver anyway since there is no need to answer an ad packet within the around 3-5ms. Remember, it is not BLE and BLE timing restrictions do not apply.
Right now we are running at 35ms with 5000ms window, manually controlled.
Works much better.
Aircable,
Thanks for posting all your results. I wish I could help more but I don't have any hardware yet.
What kinds of average supply currents are you seeing in that last setup you posted that you said you were getting good results with?