nRF5 action!
-
More good news. As far as the PPI is concerned, an event such as OVRFLW is still just as active as if it had been cleared, even if it hasn't. Here's the proof:
NRF_RTC0->TASKS_TRIGOVRFLW=1; NRF_PPI->CH[0].EEP = (uint32_t)&NRF_RTC0->EVENTS_OVRFLW; //when RTC overflow occurs. NRF_PPI->CH[0].TEP = (uint32_t)&NRF_RTC0->TASKS_TRIGOVRFLW; //set COUNTER to be near another overflow. NRF_PPI->CHENSET=1; //enable Channel 0. NRF_RTC0->EVTENSET=B10; //enable routing of RTC OVRFLW events to PPI.functions as follows:
https://pastebin.com/Z09e7tMK -
Anyhow, I don't see a way to do an RFM69 style "listen mode" using just the PPI on the nRF52832. I think this may be a dead end.@NeverDie said in nRF5 Bluetooth action!:
Anyhow, I don't see a way to do an RFM69 style "listen mode" using just the PPI on the nRF52832. I think this may be a dead end.It looks like you are implementing a new radio protocol and you are coming forward.
What do you think about forking the MY_RADIO_NRF5_ESB into a new one? The nRF5 code is designed to implement additional protocols for nRF5.
If you remove the address reverse code, there are no OTA conflicts with the ESB protocol. The address width can be enhanced by 2 bits to allow better AES encryption and lager packages.
-
@NeverDie said in nRF5 Bluetooth action!:
Anyhow, I don't see a way to do an RFM69 style "listen mode" using just the PPI on the nRF52832. I think this may be a dead end.It looks like you are implementing a new radio protocol and you are coming forward.
What do you think about forking the MY_RADIO_NRF5_ESB into a new one? The nRF5 code is designed to implement additional protocols for nRF5.
If you remove the address reverse code, there are no OTA conflicts with the ESB protocol. The address width can be enhanced by 2 bits to allow better AES encryption and lager packages.
@d00616 said in nRF5 Bluetooth action!:
It looks like you are implementing a new radio protocol and you are coming forward.
Yes, I'm presently focused on trying to reduce the amount of energy consumed by probably the hardest case of all: a battery/solar/supercap receiver that needs to be both highly responsive (within 100ms) and listening 24/7 without running out of juice. Of course, one can always throw bigger batteries or bigger solar panels at the problem, but I'm first trying to be as ultra efficient as possible so that won't be necessary. The benefit will be smaller size, not to mention lower cost.
I am posting my findings as I go because there is precious little in the way of working examples, so I may yet still be of help to others in that way. From the view count, it does seem that people are reading this thread, even if not many are posting.
-
@d00616 said in nRF5 Bluetooth action!:
It looks like you are implementing a new radio protocol and you are coming forward.
Yes, I'm presently focused on trying to reduce the amount of energy consumed by probably the hardest case of all: a battery/solar/supercap receiver that needs to be both highly responsive (within 100ms) and listening 24/7 without running out of juice. Of course, one can always throw bigger batteries or bigger solar panels at the problem, but I'm first trying to be as ultra efficient as possible so that won't be necessary. The benefit will be smaller size, not to mention lower cost.
I am posting my findings as I go because there is precious little in the way of working examples, so I may yet still be of help to others in that way. From the view count, it does seem that people are reading this thread, even if not many are posting.
@NeverDie said in nRF5 Bluetooth action!:
I am posting my findings as I go because there is precious little in the way of working examples, so I may yet still be of help to others in that way. From the view count, it does seem that people are reading this thread, even if not many are posting.
btw. Thank you for sharing you knowledge here. In my option this is very helpful for me.
-
@NeverDie said in nRF5 Bluetooth action!:
I am posting my findings as I go because there is precious little in the way of working examples, so I may yet still be of help to others in that way. From the view count, it does seem that people are reading this thread, even if not many are posting.
btw. Thank you for sharing you knowledge here. In my option this is very helpful for me.
I think you'll find this interesting:
NRF_RADIO->TASKS_DISABLE=1; //sleep the radio while (NRF_RADIO->STATE) {}; //wait until radio is DISABLED (i.e. STATE=0); NRF_RTC0->TASKS_TRIGOVRFLW=1; //set COUNTER to trigger an overflow after 16 TICKS. NRF_PPI->CH[0].EEP = (uint32_t)&NRF_RTC0->EVENTS_OVRFLW; //when RTC overflow occurs. NRF_PPI->CH[0].TEP = (uint32_t)&NRF_RTC0->TASKS_TRIGOVRFLW; //set COUNTER to be near another overflow. NRF_PPI->FORK[0].TEP = (uint32_t)&NRF_RADIO->TASKS_RXEN; //turn on the radio receiver NRF_RTC0->EVTENSET=B10; //enable routing of RTC OVRFLW events to PPI. //When Radio state TXIDLE is reached, perform an RSSI sample. There is no shortcut for this, so we must use PPI. NRF_PPI->CH[1].EEP = (uint32_t)&NRF_RADIO->EVENTS_READY; //After event READY, radio shall be in state TXIDLE. NRF_PPI->CH[1].TEP = (uint32_t)&NRF_RADIO->TASKS_RSSISTART; //Take the RSSI sample NRF_PPI->CH[2].EEP = (uint32_t)&NRF_RADIO->EVENTS_RSSIEND; //After event RSSIEND, RSSI measurement is finished and radio will be in state TXIDLE. NRF_PPI->CH[2].TEP = (uint32_t)&NRF_RADIO->TASKS_DISABLE; //Sleep the radio NRF_PPI->CHENSET=B111; //enable Channel 2, Channel 1 and Channel 0. sleep(1000000000); //sleep a million seconds so as not to interfere with current measurements.It sleeps the MCU, and using just PPI, it wakes up the radio every 16 TICKS (each tick is 100ms) and measures the RSSI. Then it puts the radio back to sleep.
So, looking at the current consumption from a macro viewpoint, it's this:
The taller peaks are when the RSSI measurements happen. Zooming in on one of the RSSI measurements, the current consumption is this:
As you can see, very little, and only for a very short time!
-
So all I need now is a way for the PPI to compare the RSSI measurement it obtained above with a threshold benchmark to decide whether or not to wake the MCU, which can take it from there. From that point onward, the regular ESB code could be used. :)
-
Nordic could have taken this a lot farther if they had included some comparison tasks, so that the PPI could make decisions about what to do next. However, I don't see that there are any that can be used for comparing an RSSI measurement against a benchmark. Too bad. :(
-
Great that it works.
But I'm not so convinced about the usefulness of this method, anyways.
I know that a lot of receivers use simple RSSI measurement to implement a low power listening mode, but when you are in a noisy environment, the system will wake up quite often, draining the battery fast. And unless you live in a very remote area, 2.4 GHz IS a noisy environment. -
Great that it works.
But I'm not so convinced about the usefulness of this method, anyways.
I know that a lot of receivers use simple RSSI measurement to implement a low power listening mode, but when you are in a noisy environment, the system will wake up quite often, draining the battery fast. And unless you live in a very remote area, 2.4 GHz IS a noisy environment.@Uhrheber said in nRF5 Bluetooth action!:
Great that it works.
But I'm not so convinced about the usefulness of this method, anyways.
I know that a lot of receivers use simple RSSI measurement to implement a low power listening mode, but when you are in a noisy environment, the system will wake up quite often, draining the battery fast. And unless you live in a very remote area, 2.4 GHz IS a noisy environment.And your better alternative is....?
-
@d00616 said in nRF5 Bluetooth action!:
It looks like you are implementing a new radio protocol and you are coming forward.
Yes, I'm presently focused on trying to reduce the amount of energy consumed by probably the hardest case of all: a battery/solar/supercap receiver that needs to be both highly responsive (within 100ms) and listening 24/7 without running out of juice. Of course, one can always throw bigger batteries or bigger solar panels at the problem, but I'm first trying to be as ultra efficient as possible so that won't be necessary. The benefit will be smaller size, not to mention lower cost.
I am posting my findings as I go because there is precious little in the way of working examples, so I may yet still be of help to others in that way. From the view count, it does seem that people are reading this thread, even if not many are posting.
@NeverDie said in nRF5 Bluetooth action!:
From the view count, it does seem that people are reading this thread, even if not many are posting.
I'm following your work with interest of course ;) On my side i'm pretty busy on other stuff (rpi and my HA) so i'm missing time for try..I'll be back soon on this!
@NeverDie said in nRF5 Bluetooth action!:
t what to do next. However, I don't see
I thought too, about implementing this kind of listenmode for rfm69 in my HA. What i don't like so much, is I think i would need a dedicated node for the scheduling and it complicates a bit thing. I'm not fond of using gw resources for the wakeup broadcast.
I think, maybe I'm wrong, that, ideally, the best would be "time slots" so everything would be in sync, no flooding broadcast, lost msg, collisions etc.. but that implies some work regarding the lib, and some hw issues (with simple 8bits without precise rtc).Keep the good work!
-
@Uhrheber said in nRF5 Bluetooth action!:
Great that it works.
But I'm not so convinced about the usefulness of this method, anyways.
I know that a lot of receivers use simple RSSI measurement to implement a low power listening mode, but when you are in a noisy environment, the system will wake up quite often, draining the battery fast. And unless you live in a very remote area, 2.4 GHz IS a noisy environment.And your better alternative is....?
@NeverDie None, unfortunately. The manufacturer would have to take care of that, by implementing a low power mode in the receiver (maybe with reduced sensitivity), and an additional low power wakeup pattern detector.
There are transceiver that can do that, but the nRF52 can't.Some of the simple 433MHz OOK receivers have a low current consumption, but they're pretty insensitive, high bandwidth and low speed, so of not much use except switching some battery powered lamp, or such.
Some time ago I searched for a transceiver with low current receive mode, to use it in a battery powered node, that could be woken up by rf, but found nothing.
All of the standard data transceivers are pretty power hungry. -
Interesting study regarding nrf51/nrf52 power consumption:
-
Interesting study regarding nrf51/nrf52 power consumption:
@Toyman Indeed:
Nonetheless, larger AA or AAA type
batteries are still required to reliably achieve operation times
of a year or longer with high advertising rates.As I thought.
And for more advanced modulations, like LoRa, the power consumption is even higher. -
@NeverDie None, unfortunately. The manufacturer would have to take care of that, by implementing a low power mode in the receiver (maybe with reduced sensitivity), and an additional low power wakeup pattern detector.
There are transceiver that can do that, but the nRF52 can't.Some of the simple 433MHz OOK receivers have a low current consumption, but they're pretty insensitive, high bandwidth and low speed, so of not much use except switching some battery powered lamp, or such.
Some time ago I searched for a transceiver with low current receive mode, to use it in a battery powered node, that could be woken up by rf, but found nothing.
All of the standard data transceivers are pretty power hungry.@Uhrheber said in nRF5 Bluetooth action!:
Some time ago I searched for a transceiver with low current receive mode, to use it in a battery powered node, that could be woken up by rf, but found nothing.
TI and Silicon Labs have both had chips with "wake on radio". e.g. http://www.ti.com/lit/an/swra126b/swra126b.pdf
The Rx current consumption of the nRF52832 seems pretty good, especially with DCDC regulator enabled. Seems to me that the RSSI detection implemented in PPI is a big improvement, even in noisy environments for the following reasons: the RSSI measurement takes only 0.25us, according to the DS. That's very little overhead. If the Radio gets switched on due to a false positive on the RSSI, well, it would have had to be switched on anyway even without the RSSI. I don't see the downside to this. The more noisy the environment, the less effective the technique is, but I don't see that you'd ever really be worse off for using it.
-
@d00616
If I'm usingsleep(1000000000);to sleep the CPU while keeping the PPI active, is there a way for the PPI to subsequently wake the CPU so that the CPU can resume where it left off? I'm not seeing any TASKS which look suitable for doing that. Or do I need an altogether different configuration for sleeping the CPU?
Back on August 5, @RMTUCKER had suggested using:sleep(digitalPinToInterrupt(10), FALLING,0);If I were to go that route, I could probably have the PPI toggle PIN 10 to do a wake-up, but I found that, for whatever reason, that method of sleeping had a much higher current draw.[Edit: scratch that. I just tried "sleep(digitalPinToInterrupt(10), FALLING,0);", and it appears to turn-off PPI. Oddly enough, it appears to leave the RTC running, which is actually just fine by me. However, I need the PPI running too. ]
-
@Toyman Indeed:
Nonetheless, larger AA or AAA type
batteries are still required to reliably achieve operation times
of a year or longer with high advertising rates.As I thought.
And for more advanced modulations, like LoRa, the power consumption is even higher. -
It turns out the cost in current consumption of waking the MCU merely to check the RSSISAMPLE result is relatively high:
The first hump is the current drawn by the PPI and RSSI sample. The second hump is the current drawn by MCU.
Measurement Scale: 1mv=1ma.
Anyhow, the RSSISAMPLE measurement, as reported by the MCU, is abnormally high. It may be that I need to put the radio into RX state, instead of just RXIDLE, before taking the RSSI measurement.
-
@NeverDie said in nRF5 Bluetooth action!:
Is there any example code which illustrates the use of interrupts on the nRF52832?
Yes. In a sketch, you have to put the interrupt routine into one line. You can define the interrupt only once. If you want to use the radio ISR, you can't enable the radio in MySensors.
https://github.com/sandeepmistry/arduino-nRF5/issues/52
https://github.com/mysensors/MySensors/blob/development/drivers/NRF5/Radio_ESB.cpp#L500
This post is deleted! -
@d00616
If I'm usingsleep(1000000000);to sleep the CPU while keeping the PPI active, is there a way for the PPI to subsequently wake the CPU so that the CPU can resume where it left off? I'm not seeing any TASKS which look suitable for doing that. Or do I need an altogether different configuration for sleeping the CPU?
Back on August 5, @RMTUCKER had suggested using:sleep(digitalPinToInterrupt(10), FALLING,0);If I were to go that route, I could probably have the PPI toggle PIN 10 to do a wake-up, but I found that, for whatever reason, that method of sleeping had a much higher current draw.[Edit: scratch that. I just tried "sleep(digitalPinToInterrupt(10), FALLING,0);", and it appears to turn-off PPI. Oddly enough, it appears to leave the RTC running, which is actually just fine by me. However, I need the PPI running too. ]
@NeverDie said in nRF5 Bluetooth action!:
to sleep the CPU while keeping the PPI active, is there a way for the PPI to subsequently wake the CPU so that the CPU can resume where it left off? I'm not seeing any TASKS which look suitable for doing that. Or do I need an altogether different configuration for sleeping the CPU?
The PPI cannot wake up the CPU. You can try to trigger events to a timer which resumes the CPU.
@NeverDie said in nRF5 Bluetooth action!:
Are there special reserved names to always use for the IRQ handlers? e.g. GPIOTE_IRQHandler(void), and so on?
The names are defined there:
