I'm developing a CSRMesh network to be used in group of about 100-1000 sensors per customer. The client I'm developing this for wants a battery life of nearly a year. To do this, it would be helpful if I could have the entire sensor network "go to sleep" around when the factory shop floor closes, say at 8pm, and around 6am the sensors would exit deep sleep mode and go back to normal mode of periodically sleeping, then watchdog wakes them, send data, sleep, etc. Having a real-time clock (RTC) would give me the ability to tell them what time to go to sleep. This would almost double my battery life for free.
The datasheet for the CSR101 makes no mention of a RTC in hardware.
However, it does mention using a 32.768kHz crystal as a clock source, which typically is used in RTC applications. But I don't see how I can use this to do what I want to do. Is it possible? Note I can't roll my own RTC in software, as it needs to be in hardware for accuracy/drift.
We haven't selected CSRMesh yet as our solution (also baking off LT / Dust network smartmesh). The winner will be whoever can help extend battery life the greatest.
Thanks,
Joel
There is the ability to set a timer using the API's, but that may not be accurate enough for you, as you point out. What you may be able to do is utlize the PIO controller (which is an 8051) and utlize that for more accurate timing.
Joel
CSRMesh Bridges network 2.0 can't support more than 45 nodes. You have to check it.
See Quotes from CS-337999-RN-5- CSRmesh 2.0 Mobile
"SMTF-591 Bridges disconnect in an environment of over 45 nodes. Using the auto connect method circumvents this issue."
CSR1010 has a 48 bit hardware timer that runs also on sleep. That is good for most projects . And on our test it is accurate.
Hi Joel,
There is a "hibernate" mode which does what you require. Effectively it switches off the chip for a set period and then reboots when the period elapses. The software state will be reset but you are informed that you booted from hibernate rather than "power on".
See SleepRequest() in the API documentation.
Chris
I also want some type of real-time clock on a CSR1010 project. I assumed that because the chip has a 32kHz crystal then there would be an accurate time register that I could read, but I don't see any documentation on this. A timestamp facility is assumed by several BLE profiles (e.g. Glucose sensor). Can the CSR1010 support this, accurately?
I would be quite happy with a "ticks since last reset" counter and manage the time arithmetic myself.
The documentation for the time.h talks about "the current vaue of the system's 1MHz clock" which suggests calls like TimeGet48() relies on the 16MHz crystal rather than the 32kHz crystal. (I guess that the 16Mhz crystal shuts down when the processor sleeps, but the 32kHz crystal runs always? Though it would be possible for "the system's 1MHz clock" to be updated from a 32kHz timer register when the chip wakes...)
Nissim writes "CSR1010 has a 48 bit hardware timer that runs also on sleep. That is good for most projects . And on our test it is accurate." Could you provide more details please Nissim?
A different approach to the same question is to ask how CSR devices supports "org.bluetooth.characteristic.date_time" UUID: 0x2A08
Thanks - Charles
In hibernation mode, the CSR1010 has a 48-bit hardware timer that runs on that deep sleep mode.
We give it a command to sleep for 24:00:00 houses and it week up as expected