nRF5 action!
-
FWIW, I noticed on the oscilliscope that turning on-and-off the HFCLK ten times a second produces a fair amount of ringing. If I simply leave HFCLK turned on, most of the ringing is eliminated.
[Edit: So, if doing this as part of an aggressive energy saving approach (for instance, turning OFF HFCLK after RX mode and later turning it on again before initiating a new RX), what sort of extra circuitry beyond the two inductors for the DCDC might be needed? I don't know that the ringing is causing any actual problems, but it doesn't look proper on a scope. For now, I'm just flagging it so that folks are aware of it as a possible issue. ]
-
FWIW, I noticed on the oscilliscope that turning on-and-off the HFCLK ten times a second produces a fair amount of ringing. If I simply leave HFCLK turned on, most of the ringing is eliminated.
[Edit: So, if doing this as part of an aggressive energy saving approach (for instance, turning OFF HFCLK after RX mode and later turning it on again before initiating a new RX), what sort of extra circuitry beyond the two inductors for the DCDC might be needed? I don't know that the ringing is causing any actual problems, but it doesn't look proper on a scope. For now, I'm just flagging it so that folks are aware of it as a possible issue. ]
To better quantify the issue, I measured sleep currents (now using sleep routines that are a fork from what's in mysensors.h), and with the High Frequency clock turned OFF, the sleep current is measured at 2.2ua using a uCurrent Gold. However, the same setup, but with the High Frequency clock left ON, the sleep current is measured at 596ua using the same a uCurrent Gold.
So, clearly, for a battery/supercap application, leaving the High Frequency clock running all the time is not an especially good option.
-
To better quantify the issue, I measured sleep currents (now using sleep routines that are a fork from what's in mysensors.h), and with the High Frequency clock turned OFF, the sleep current is measured at 2.2ua using a uCurrent Gold. However, the same setup, but with the High Frequency clock left ON, the sleep current is measured at 596ua using the same a uCurrent Gold.
So, clearly, for a battery/supercap application, leaving the High Frequency clock running all the time is not an especially good option.
-
However, there's one fly in the ointment remaining. It turns out that some other timer is sometimes waking up the CPU:
time=15798, Radio STATE=0, COUNTER=0x49, packetCounter=22 time=15900, Radio STATE=0, COUNTER=0x49, packetCounter=23 time=16001, Radio STATE=0, COUNTER=0x49, packetCounter=24 time=16103, Radio STATE=0, COUNTER=0x49, packetCounter=25 time=16204, Radio STATE=0, COUNTER=0x49, packetCounter=26 time=16306, Radio STATE=0, COUNTER=0x49, packetCounter=27 time=512000, Radio STATE=0, COUNTER=0x2035, packetCounter=27 time=1024000, Radio STATE=0, COUNTER=0x269, packetCounter=27 time=1536000, Radio STATE=0, COUNTER=0x1803, packetCounter=27 time=2048000, Radio STATE=3, COUNTER=0x36, packetCounter=27 time=2560000, Radio STATE=0, COUNTER=0x1570, packetCounter=27 time=3072000, Radio STATE=0, COUNTER=0x3104, packetCounter=27 time=3584000, Radio STATE=0, COUNTER=0x1337, packetCounter=27 time=4096000, Radio STATE=0, COUNTER=0x2871, packetCounter=27 time=4608000, Radio STATE=0, COUNTER=0x1104, packetCounter=27 time=5120000, Radio STATE=0, COUNTER=0x2638, packetCounter=27All the lines labelled packetCounter=27 (after the first one that is) are a result of this. Looking at the time, they appear to happen on the rollover of some other timer (?)--apparently the one that is responsible for keeping track of millis(). I can filter them out after-the-fact, but I'd rather they not be waking up the CPU for no reason, as that is just a waste of energy.
This post is deleted! -
@NeverDie
I am puzzled with your 596ua?
I thought you were under 10ua with the mysensors sleep some time ago?
Mine only measures 4-5ua when in sleep?@rmtucker said in nRF5 Bluetooth action!:
I am puzzled with your 596ua?
I thought you were under 10ua with the mysensors sleep some time ago?There's no contradiction. It's a different scenario. The MySensors hwSleep function turns off the High Frequency oscillator when sleeping and turns it back on when it wakes up. So, it's perfectly fine for sleeping your device, having it wake up to send something, and then go back to sleep.
The present scenario that I'm working on though is where the MCU sleeps and the PPI manages a "listen mode" where the PPI wakes up the radio once every 100ms for a roughly 200us window of time to listen for an incoming packet. Then it goes back to sleep if nothing is received. On the other hand, if a packet is received, it wakes up the MCU so that the packet can be read and dealt with. Presently I have the PPI turn off the high-frequency oscillator each time after it has finished RX in the listen-mode cycle. Before entering RX again to listen for a new packet, it first ramps up the high frequency oscillator. According to the datasheet, the high frequency crystal oscillator must be operating in order for the radio to either transmit or receive. i.e. it can't simply run off the high frequency RC oscillator the way the MCU can.
My measurements show that while the High Frequency oscillator is running, it consumes about 596ua.
-
Did anyone managed to get two NRF52832 to connect to each other with the arduino IDE and communicate?
Also why does I2C initializes only after an SWD programmed gets connected?
Wierd phenomenon when I use an I2C oled display with that chip and program it with an st link V2 after it displays alright when it's booted if the SWD programmer is connected but as soon as you disconnect it everything else works but the I2C display...
-
Did anyone managed to get two NRF52832 to connect to each other with the arduino IDE and communicate?
Also why does I2C initializes only after an SWD programmed gets connected?
Wierd phenomenon when I use an I2C oled display with that chip and program it with an st link V2 after it displays alright when it's booted if the SWD programmer is connected but as soon as you disconnect it everything else works but the I2C display...
@Mike_Lemo said in nRF5 Bluetooth action!:
Did anyone managed to get two NRF52832 to connect to each other with the arduino IDE and communicate?
Yes. @d00616's demo code will do this.
I don't know the answers to the rest of your questions, because I don't use the ST.
-
Here's a scopeshot of how the revised current draw looks:
As you can see, there is now about a 370us warm-up time at the beginning for the High Frequency oscillator to come up to speed before the RX cycle can be started. Then it takes about 100us for the receiver to warm-up to RXIDLE. From there it finally achieves about 200us of actual productive RX time. Then everything powers down until the end of the 100ms cycle, after which it all repeats again. To conserve energy, all this is managed by the PPI while the MCU sleeps.
Scale: 1mv=1maI think this is about as energy efficient as it's ever going to get, short of chipping away at the number of bits in the frame/packet size, as I indicated earlier.
-
@Mike_Lemo said in nRF5 Bluetooth action!:
Did anyone managed to get two NRF52832 to connect to each other with the arduino IDE and communicate?
Yes. @d00616's demo code will do this.
I don't know the answers to the rest of your questions, because I don't use the ST.
@NeverDie said in nRF5 Bluetooth action!:
@Mike_Lemo said in nRF5 Bluetooth action!:
Did anyone managed to get two NRF52832 to connect to each other with the arduino IDE and communicate?Yes. @d00616's demo code will do this.
I don't know the answers to the rest of your questions, because I don't use the ST.
Any idea how I reach to this code?
Also you say you don't experience any issues with I2C like that?
-
@NeverDie said in nRF5 Bluetooth action!:
@Mike_Lemo said in nRF5 Bluetooth action!:
Did anyone managed to get two NRF52832 to connect to each other with the arduino IDE and communicate?Yes. @d00616's demo code will do this.
I don't know the answers to the rest of your questions, because I don't use the ST.
Any idea how I reach to this code?
Also you say you don't experience any issues with I2C like that?
@Mike_Lemo said in nRF5 Bluetooth action!:
Any idea how I reach to this code?
Yes, it's all explained in detail by @d00616 here: https://www.openhardware.io/view/376/MySensors-NRF5-Platform
Also you say you don't experience any issues with I2C like that?
Haven't tried I2C on this platform yet. I'd be very surprised if it didn't work though, as that's ARM Cortex M4 stuff, which is well vetted. i.e. no real dependency on anything Nordic per se.
-
@Mike_Lemo said in nRF5 Bluetooth action!:
Any idea how I reach to this code?
Yes, it's all explained in detail by @d00616 here: https://www.openhardware.io/view/376/MySensors-NRF5-Platform
Also you say you don't experience any issues with I2C like that?
Haven't tried I2C on this platform yet. I'd be very surprised if it didn't work though, as that's ARM Cortex M4 stuff, which is well vetted. i.e. no real dependency on anything Nordic per se.
@NeverDie said in nRF5 Bluetooth action!:
@Mike_Lemo said in nRF5 Bluetooth action!:
Any idea how I reach to this code?
Yes, it's all explained in detail by @d00616 here: https://www.openhardware.io/view/376/MySensors-NRF5-Platform
Also you say you don't experience any issues with I2C like that?
Haven't tried I2C on this platform yet. I'd be very surprised if it didn't work though, as that's ARM Cortex M4 stuff, which is well vetted. i.e. no real dependency on anything Nordic per se.
The link you attached links me to a getting started page not wireing two nrf's together
-
@NeverDie said in nRF5 Bluetooth action!:
@Mike_Lemo said in nRF5 Bluetooth action!:
Any idea how I reach to this code?
Yes, it's all explained in detail by @d00616 here: https://www.openhardware.io/view/376/MySensors-NRF5-Platform
Also you say you don't experience any issues with I2C like that?
Haven't tried I2C on this platform yet. I'd be very surprised if it didn't work though, as that's ARM Cortex M4 stuff, which is well vetted. i.e. no real dependency on anything Nordic per se.
The link you attached links me to a getting started page not wireing two nrf's together
@Mike_Lemo said in nRF5 Bluetooth action!:
The link you attached links me to a getting started page not wireing two nrf's together
Your question was ambiguous. When you said "connect" I just assumed you meant wirelessly connect.
Sorry, I can't help you. Seems like @scalz has gotten I2C to work with it though, but more likely for reading a TH sensor than for the purpose of wiring two nRF52832's. Still, that would prove that it works. If you know the I2C protocol, it shouldn't be hard to go from that to wiring two nRF52832's together.
-
Here's a scopeshot of how the revised current draw looks:
As you can see, there is now about a 370us warm-up time at the beginning for the High Frequency oscillator to come up to speed before the RX cycle can be started. Then it takes about 100us for the receiver to warm-up to RXIDLE. From there it finally achieves about 200us of actual productive RX time. Then everything powers down until the end of the 100ms cycle, after which it all repeats again. To conserve energy, all this is managed by the PPI while the MCU sleeps.
Scale: 1mv=1maI think this is about as energy efficient as it's ever going to get, short of chipping away at the number of bits in the frame/packet size, as I indicated earlier.
@NeverDie said in nRF5 Bluetooth action!:
I think this is about as energy efficient as it's ever going to get, short of chipping away at the number of bits in the frame/packet size, as I indicated earlier.
I also measured the current between the peaks shown in the scopeshot. By increasing the period between listens, I was able to do the measurement using a uCurrent Gold. Doing so, I found that the current drawn was 10.7ua using the Low Frequency crystal oscillator, and 11.2ua using the Low Frequency RC oscillator. I'm now sure how to square that with some of the earlier measurements I had taken with the nRF52832 sleeping using the MySensors sleep routine, as those measurements came out to about 6ua. Perhaps the difference is the extra current required to run the PPI in this configuration? With neither oscillator configured, and no PPI, it measures, as I said earlier, at 2.2ua, which is close to what the datasheet predicts.
-
@NeverDie said in nRF5 Bluetooth action!:
@Mike_Lemo said in nRF5 Bluetooth action!:
Any idea how I reach to this code?
Yes, it's all explained in detail by @d00616 here: https://www.openhardware.io/view/376/MySensors-NRF5-Platform
Also you say you don't experience any issues with I2C like that?
Haven't tried I2C on this platform yet. I'd be very surprised if it didn't work though, as that's ARM Cortex M4 stuff, which is well vetted. i.e. no real dependency on anything Nordic per se.
The link you attached links me to a getting started page not wireing two nrf's together
@Mike_Lemo said in nRF5 Bluetooth action!:
@NeverDie said in nRF5 Bluetooth action!:
@Mike_Lemo said in nRF5 Bluetooth action!:
Any idea how I reach to this code?
Yes, it's all explained in detail by @d00616 here: https://www.openhardware.io/view/376/MySensors-NRF5-Platform
Also you say you don't experience any issues with I2C like that?
Haven't tried I2C on this platform yet. I'd be very surprised if it didn't work though, as that's ARM Cortex M4 stuff, which is well vetted. i.e. no real dependency on anything Nordic per se.
The link you attached links me to a getting started page not wireing two nrf's together
Yes I did mean wirelessly like central and peripherial connection... Is that supported?
-
I'm sorry, but I can't help you any more than I already have.
-
Here's a scopeshot of how the revised current draw looks:
As you can see, there is now about a 370us warm-up time at the beginning for the High Frequency oscillator to come up to speed before the RX cycle can be started. Then it takes about 100us for the receiver to warm-up to RXIDLE. From there it finally achieves about 200us of actual productive RX time. Then everything powers down until the end of the 100ms cycle, after which it all repeats again. To conserve energy, all this is managed by the PPI while the MCU sleeps.
Scale: 1mv=1maI think this is about as energy efficient as it's ever going to get, short of chipping away at the number of bits in the frame/packet size, as I indicated earlier.
@NeverDie said in nRF5 Bluetooth action!:
I think this is about as energy efficient as it's ever going to get
Epilog: I ran it overnight on a 10F capacitor, and it dropped only 0.011v per hour. I'm very happy with that, considering it's listening every 100ms as to whether or not it has received a packet. :)
-
@d00616 Your posting says,
At the moment on Arduino, there is no definition of various OUTPUT modes. If you want to access all nRF5 output modes, you have to use hwPinMode and the OUTPUT_... macro.
Exactly which macro would that be? It looks to me as though what most users will want is the function nrf5_pinmode(..,..), which appears to do all the actual work. Is that right? It is defined in the file nrf5_wiring_digital.c.
Meanwhile, hwPinMode appears to be merely a straight pass-through for pinMode:
void hwPinMode(uint8_t pin, uint8_t mode) { pinMode(pin, mode); } -
Where is it possible to find a reference schematic for using the NTF52832 E73-2G4M04S module with NFC?
not much is being given in the datasheet not even where the NFC pins go.
@Mike_Lemo said in nRF5 Bluetooth action!:
Where is it possible to find a reference schematic for using the NTF52832 E73-2G4M04S module with NFC?
not much is being given in the datasheet not even where the NFC pins go.Please look into the product documentation:
http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/nfc.html?cp=2_1_0_41_8#concept_ryw_4hk_1s@NeverDie said in nRF5 Bluetooth action!:
At the moment on Arduino, there is no definition of various OUTPUT modes. If you want to access all nRF5 output modes, you have to use hwPinMode and the OUTPUT_... macro.
Exactly which macro would that be? It looks to me as though what most users will want is the function nrf5_pinmode(..,..), which appears to do all the actual work. Is that right? It is defined in the file nrf5_wiring_digital.c.
hwPinMode allows to define platform specific PinMode replacements. Code may be portable. This is the reason pointing to nrf5_pinmode().
nrf5_pinmode() has a little bit more functionality than the original pinmode function.
Meanwhile, hwPinMode appears to be merely a straight pass-through for pinMode:
void hwPinMode(uint8_t pin, uint8_t mode)
{
pinMode(pin, mode);
}This disables the capability using nRF5 specific pin modes with the MySensors API.
-
@Mike_Lemo said in nRF5 Bluetooth action!:
Where is it possible to find a reference schematic for using the NTF52832 E73-2G4M04S module with NFC?
not much is being given in the datasheet not even where the NFC pins go.Please look into the product documentation:
http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/nfc.html?cp=2_1_0_41_8#concept_ryw_4hk_1s@NeverDie said in nRF5 Bluetooth action!:
At the moment on Arduino, there is no definition of various OUTPUT modes. If you want to access all nRF5 output modes, you have to use hwPinMode and the OUTPUT_... macro.
Exactly which macro would that be? It looks to me as though what most users will want is the function nrf5_pinmode(..,..), which appears to do all the actual work. Is that right? It is defined in the file nrf5_wiring_digital.c.
hwPinMode allows to define platform specific PinMode replacements. Code may be portable. This is the reason pointing to nrf5_pinmode().
nrf5_pinmode() has a little bit more functionality than the original pinmode function.
Meanwhile, hwPinMode appears to be merely a straight pass-through for pinMode:
void hwPinMode(uint8_t pin, uint8_t mode)
{
pinMode(pin, mode);
}This disables the capability using nRF5 specific pin modes with the MySensors API.
@d00616 said in nRF5 Bluetooth action!:
@Mike_Lemo said in nRF5 Bluetooth action!:
Where is it possible to find a reference schematic for using the NTF52832 E73-2G4M04S module with NFC?
not much is being given in the datasheet not even where the NFC pins go.Please look into the product documentation:
http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/nfc.html?cp=2_1_0_41_8#concept_ryw_4hk_1s@NeverDie said in nRF5 Bluetooth action!:
At the moment on Arduino, there is no definition of various OUTPUT modes. If you want to access all nRF5 output modes, you have to use hwPinMode and the OUTPUT_... macro.
Exactly which macro would that be? It looks to me as though what most users will want is the function nrf5_pinmode(..,..), which appears to do all the actual work. Is that right? It is defined in the file nrf5_wiring_digital.c.
hwPinMode allows to define platform specific PinMode replacements. Code may be portable. This is the reason pointing to nrf5_pinmode().
nrf5_pinmode() has a little bit more functionality than the original pinmode function.
Meanwhile, hwPinMode appears to be merely a straight pass-through for pinMode:
void hwPinMode(uint8_t pin, uint8_t mode)
{
pinMode(pin, mode);
}This disables the capability using nRF5 specific pin modes with the MySensors API.
I'm talking about the module it's self isn't there a reference schematic for that? I see there are some component in there but else do I have to add to make this work?
