nRF5 action!
-
@rmtucker said in nRF5 Bluetooth action!:
@NeverDie
I connected a new amplified nrf24 to the gateway with the tin foil as mentioned and it is reading -60dB compared to -89dB with the non amplified version.Did the tin foil make a difference? Hackaday seemed to think it made a big difference. I haven't tried it yet.
-
@NeverDie said in nRF5 Bluetooth action!:
@rmtucker said in nRF5 Bluetooth action!:
@NeverDie
I connected a new amplified nrf24 to the gateway with the tin foil as mentioned and it is reading -60dB compared to -89dB with the non amplified version.Did the tin foil make a difference? Hackaday seemed to think it made a big difference. I haven't tried it yet.
I think it did but what do you have to lose
-
Here's the Hackaday article: http://hackaday.com/2016/05/31/fixing-the-terrible-range-of-your-cheap-nrf24l01-palna-module/
-
@NeverDie said in nRF5 Bluetooth action!:
@Nca78
Did you ever figure out how to reset the MCU on the Ebyte module?Sorry didn't touch my NRF5 in the last weeks. A bit busy on other things...
-
What's the best way to make a "receive only" gateway? i.e. one that cannot transmit? Then I wouldn't need to worry about whether the gateway is turned on before powering up a MY_PASSIVE_NODE sensor mote. Is there a way to do it simply in hardware, or do I have to sabotage the gateway library code?
-
It's getting too baroque. What I'd really like to have is a short nRF5 library of just the bare essentials (like the MIRF library is for the RF24).
-
Hmmm... it looks like radiohead may be such a library: http://www.airspayce.com/mikem/arduino/RadioHead/classRH__NRF52.html
-
@NeverDie said in nRF5 Bluetooth action!:
It's getting too baroque. What I'd really like to have is a short nRF5 library of just the bare essentials (like the MIRF library is for the RF24).
You can take a look into the actual Nordic NRF SDK. There are the ESB library for nRF24 compatible communication.
-
@d00616 said in nRF5 Bluetooth action!:
@NeverDie said in nRF5 Bluetooth action!:
It's getting too baroque. What I'd really like to have is a short nRF5 library of just the bare essentials (like the MIRF library is for the RF24).
You can take a look into the actual Nordic NRF SDK. There are the ESB library for nRF24 compatible communication.
The RadioHead library seems very easy to pickup and start using. Maybe it's me, but I can't say the same for the Nordic SDK.
Interestingly, it looks as though @Yveaux may (?) have written the nRF51 part of the RadioHead library.
-
I was able to program the tiny nRF51822 (earlier photograph above) by programming it as an xxaa Generic nRF51 with an RC oscillator.
Nice!
-
Here's a close-up photo:
-
FWIW, range on the tiny nRF51822 does seem compromised when compared against larger sized nRF52832 modules. Not really surprising, but I had hoped it might be a little better than it is.
-
@NeverDie said in nRF5 Bluetooth action!:
FWIW, range on the tiny nRF51822 does seem compromised when compared against larger sized nRF52832 modules. Not really surprising, but I had hoped it might be a little better than it is.
This is an idea, I don't know if this helps. The two pins near the antenna are GND. Try to solder an 3cm isolated wire to the pin near your PCB and route it parallel of your pcb away from the nRF51 board. The extends the GND pane size.
-
Just in case anyone uses the waveshare ble400 board.
The board was consuming 150uA when fed with 3.3v bypassing the regulator.
I have cut through one of the tracks and now it is only consuming 4-5uA and it can still be used normally with the usb lead 5v as long as i place a dupont link across 2 pins.
If anyone needs photo's let me know.
-
@d00616 said in nRF5 Bluetooth action!:
@NeverDie said in nRF5 Bluetooth action!:
FWIW, range on the tiny nRF51822 does seem compromised when compared against larger sized nRF52832 modules. Not really surprising, but I had hoped it might be a little better than it is.
This is an idea, I don't know if this helps. The two pins near the antenna are GND. Try to solder an 3cm isolated wire to the pin near your PCB and route it parallel of your pcb away from the nRF51 board. The extends the GND pane size.
I'll give it a try. Is your idea to make it like a dipole antenna?
-
@d00616
Is this what you had in mind?
-
Also, there are a couple of what look like large solder pads on the back of the PCB. I have no idea what they're for. Anyone know or care to guess?
-
@scalz said in nRF5 Bluetooth action!:
I don't think sendSignalStrength function is implemented yet, but you should be able to get this info with:
int16_t transportGetSendingRSSI(void) int16_t transportGetReceivingRSSI(void)Just wondering what both of these mean?
I assumed the transportGetReceivingRSSI(void) was the strength of signal from my Gateway ?
But what is the transportGetSendingRSSI(void)?
-
@rmtucker said in nRF5 Bluetooth action!:
But what is the transportGetSendingRSSI(void)?
This is the RSSI of the receiver. With nRF5 it's part of the ACK payload.
-
Out of curiosity i stuck a cake tin over the top of the node and it just carried on transmitting,so i put it behind 4 walls and 1 floor down then behind the fuse box and consumer unit and eventually got it to drop to -68dB for received rssi but send rssi stayed at -45dB so it seems to be booming out and in.
-
Results: I don't think it made the link worse, but it's not obvious that it made the link better either. Range seems about the same.
Even more surprising: prior to adding this piece of wire, I didn't notice much improvement when I went from 2Mbps at Tx 0db to 250kbps at Tx 4db either. I had really thought it would be a tangible improvement in range, but if there was any improvement (and I'm not sure that there was), it seemed like only a modest amount.
Conclusions/recommendations/suggestions/comments?
-
@NeverDie I don't know how much work is needed to make this work with nrf5, but @Yveaux has created a range tester that might be useful. https://github.com/Yveaux/MySensorsRangeTest
It does use MySensors though, so it might provide more overhead than the bare-bone functionality you are looking for.
-
@NeverDie is your wire soldered to gnd?? if so, i would have soldered it to the antenna transmission line, as a monopole, with taking care of disabling the pcb antenna. i guess you're trying sort of dipole, but one branch is meandered/"coiled" so not sure if that would improve a lot like you noticed..
-
@scalz said in nRF5 Bluetooth action!:
@NeverDie is your wire soldered to gnd?? if so, i would have soldered it to the antenna transmission line, as a monopole, with taking care of disabling the pcb antenna. i guess you're trying sort of dipole, but one branch is meandered/"coiled" so not sure if that would improve a lot like you noticed..
In this instance, I don't see a way to attach to the actual antenna. On some boards I see a little hole where a wire can be attached. On this one, I guess maybe it could be done by carefully scraping off the solder mask and then soldering to the trace.... Its a gamble though: t would be all too easy to scrape off the trace in the process.
Anyhow, enlarging the footprint of the board kinda defeats the purpose of its small size. I think maybe it just is what it is, and the relatively poor performance explains its relatively low price.
Maybe what would rescue it is an adequate ground plane on whatever PCB it attaches to. For instance, I'm thinking it might be a nice match for a "Chirp" soil moisture sensor, which maybe (I'd have to look) has a long--though narrow--ground plane. Making the Chirp wireless would be a nice upgrade.
It has an attiny MCU, which (unless someone knows differently) isn't enough to control, say, an SMD nRF24l01. I suppose it could be redesigned to use an atmega328p (which would be preferable), but you can already buy cheap pre-made attiny Chirps from China, so there's an argument for leveraging that instead by attaching maybe this cheap wireless module to it.
-
Interesting discovery! Despite what you would think from the look of them (especially the one on the left), the two large solder pads both have continuity to ground.
So, I'm hypothesizing that both are meant to be soldered to a larger ground plane on whatever PCB the module is soldered to.
-
@NeverDie
i would have unsoldered the last pad of the passive before the antenna feed point to disable it, and would have soldered the wire antenna to passive, so without scratching anything but i have no idea about nrf51 range, i'm not using this mcu :simple_smile:
I have my own design for soil moisture..not really interested by "chirp" like sensors, but i agree nrf52 are nice mcu.
-
@scalz said in nRF5 Bluetooth action!:
@NeverDie
i would have unsoldered the last pad of the passive before the antenna feed point to disable it, and would have soldered the wire antenna to passive, so without scratching anything but i have no idea about nrf51 range, i'm not using this mcu :simple_smile:
I have my own design for soil moisture..not really interested by "chirp" like sensors, but i agree nrf52 are nice mcu.If you feel like posting it, I'd certainly be interested in a good soil moisture sensor.
This is the only nRF51 I've tried, but @rmtucker seems to be getting good range (beyond his garden) with his nRF51. I previously drank the Kool-aid and thought the nRF52 generally performs better, but I'm not I'm not really sure anymore.
-
@NeverDie
What are you using at the other end,just a standard nrf24 or the amplified version.
I switched to rfm69 some time ago because of poor range/coverage.
But i am astounded with the nrf51 and wemos/nrf24 pa setup.
Maybe it is the tin foil wrapping Lol.
-
@rmtucker
I did eventually manage to stop it by putting it in the fridge.
My other half has never laughed so much.
-
@rmtucker said in nRF5 Bluetooth action!:
@rmtucker
I did eventually manage to stop it by putting it in the fridge.
My other half has never laughed so much.If you switch to Lithium batteries (I'm partial to the Energizer AA's because they have good datasheets), your node should still work even in the freezer.
-
@rmtucker said in nRF5 Bluetooth action!:
@NeverDie
What are you using at the other end,just a standard nrf24 or the amplified version.
I switched to rfm69 some time ago because of poor range/coverage.
But i am astounded with the nrf51 and wemos/nrf24 pa setup.
Maybe it is the tin foil wrapping Lol.I did it both ways when with datarates of 250kbps and 1Mbps, but when I upgraded the nRF52832 to 2Mbps, the connection stopped working. For expediency, I switched to an nRF52 DK as the gateway, rather than debug the nRF24 just then. Eventually I'll circle back and try to figure out what the problem is/was with the 2Mbps on the nRF24's. So, the nRF52 DK is what I'm presently using.
-
@rmtucker
On the supercapacitor subject.
Nick Gammon used a 0.47uf 5.5v capacitor and you have been trying a 10uf 2.7v.
So i was going to try a 4uf 5.5v super cap and an mcp1700-33 to power the nrf at 3.3v.
I was going to charge the supercap initially with an adjustable dc-dc converter set to 5v while experimenting,anyone see a problem?
-
@rmtucker said in nRF5 Bluetooth action!:
@rmtucker
On the supercapacitor subject.
Nick Gammon used a 0.47uf 5.5v capacitor and you have been trying a 10uf 2.7v.
So i was going to try a 4uf 5.5v super cap and an mcp1700-33 to power the nrf at 3.3v.
I was going to charge the supercap initially with an adjustable dc-dc converter set to 5v while experimenting,anyone see a problem?I'm assuming Nick Gammon was using not an Nordic radio but just an atmega chip? I don't think you'll get much runtime on a 0.47uF supercap, nor a 4uF supercap, because of the radio.
On the plus side, it should charge up almost instantly.
On the other hand, 100uF should be enough to send at least one packet. I haven't tried that low an amount on the nrf52, but I have done it with a 100uF (charged to 2.7v) powering an atmega328p+RFM69 combo.
-
@NeverDie
I think he was using an nrf24 just the same as us.
He was getting 32hours without re-charging and transmitting every 5mins.
-
@rmtucker said in nRF5 Bluetooth action!:
mcp1700-33
It appears to be just an LDO. So, you won't get any advantage to charging your capacitor to greater than 3.3v.
-
@rmtucker said in nRF5 Bluetooth action!:
@NeverDie
I think he was using an nrf24 just the same as us.
He was getting 32hours without re-charging and transmitting every 5mins.Really? Wow. That I'd like to see. I don't see how it's even possible. Do you have a link?
-
-
@rmtucker said in nRF5 Bluetooth action!:
Nick Gammon used a 0.47uf 5.5v capacitor
Re-read your link. He used a 0.47F capacitor, not a 0.47uF capacitor. That's a million times difference.
0.47F works. I arrived at 10F because it seems to be a sweet spot in the way that supercaps are priced. You can get a lot of Farads for just $2.
-
@NeverDie
My Mistake but his results were impressive don't you think?
Anyway i was just going to use 4f because i can get one.
How are you charging your Cap?
-
@rmtucker said in nRF5 Bluetooth action!:
How are you charging your Cap?
6v mini solar panel run through diode and a 2.7v ldo. That works for me indoors even 15-20 feet away from a window.
-
@NeverDie
Hmm the only 2.7v ldo i can see are surface mount in the uk.
Thats a no no for me.
-
@rmtucker said in nRF5 Bluetooth action!:
@NeverDie
Hmm the only 2.7v ldo i can see are surface mount in the uk.
Thats a no no for me.Yeah, I'm using surface mount, but I solder it on manually the old fashioned way. Not all surface mount are difficult just because they're SMD. Simply avoid the ones with too small a pitch.
-
@NeverDie
Part number?
-
@rmtucker said in nRF5 Bluetooth action!:
@NeverDie
Part number?http://datasheet.sii-ic.com/en/voltage_regulator/S1313_E.pdf
-
Where is the sleep(...) function defined for the nrf5? I've looked, but I can't seem to find which library it is in. Anyone know?
-
@NeverDie said in nRF5 Bluetooth action!:
Where is the sleep(...) function defined for the nrf5? I've looked, but I can't seem to find which library it is in. Anyone know?
It's defined in "hal/architecture/MyHwNRF5.cpp"
-
If anybody need cheap NRF52 DK, Arrow has them for ca. $30 with free courier shipping!
-
@Toyman said in nRF5 Bluetooth action!:
If anybody need cheap NRF52 DK, Arrow has them for ca. $30 with free courier shipping!
10% discount at the moment so 29.48$. Given the price per unit of a nrf52 if you buy in small numbers, it's worth buying it just for the extra chips provided
-
Speaking as a noob myself, I think the DK's are great for noobs, especially when first getting started. I don't have as big a need for them now, but they definitely helped in the beginning. They pretty much "just work" without a lot of fuss.
-
I'm presently playing around with the radioHead library. I can:
- Send and receive backets between two nRF5 modules.
or - Send and receive packets between two nRF24L01 modules.
However, at present, I can't send or receive packets successfully between an nRF24 and an nRF5 module, even though it appears they share the same network ID, the same datarate, and the same channel.
I'm guessing there exists some kind of compatability mode (?) that would bridge this gap, but I haven't found it.
- Send and receive backets between two nRF5 modules.
-
@NeverDie
d00616 added the support of NRF5 + ESB to MySensors.
Radiohead lib doesn't handle this mode (explained in the description of his NRF51class).
-
Yeah, MySensors can definitely do it. Nice work @d00616 !
It turns out that with RadioHead, I am almost able to send packets from an nRF24L01 to an nRF5 module: it's just that the packets arrive as garbage. So, the packet and/or frame formatting must be different, but indeed the network ID's are matching or else I wouldn't be receiving anything at all.
-
I found the smoking gun in the radiohead documentation. Turns out RadioHead does indeed use a different packet format for the nRF5 that is "NOT compatible with the one used by RH_NRF24 and the nRF24L01 product specification, mainly because the nRF24 only supports 6 bits of message length."
Well, that stinks.
-
@NeverDie Ya, that really sucks. It would have been great to mix and match.
-
@NeverDie said in nRF5 Bluetooth action!:
Yeah, MySensors can definitely do it. Nice work @d00616 !
Thanks.It turns out that with RadioHead, I am almost able to send packets from an nRF24L01 to an nRF5 module: it's just that the packets arrive as garbage. So, the packet and/or frame formatting must be different, but indeed the network ID's are matching or else I wouldn't be receiving anything at all.
The ID's are reversed between nRF5 and nRF24. Look into the code how to reverse the ID's.
@NeverDie said in nRF5 Bluetooth action!:
I found the smoking gun in the radiohead documentation. Turns out RadioHead does indeed use a different packet format for the nRF5 that is "NOT compatible with the one used by RH_NRF24 and the nRF24L01 product specification, mainly because the nRF24 only supports 6 bits of message length."
You have to choose the correct number of bits for length, S0 and S1. I have played a while to find out the correct configuration. When ACK is enabled you have to do a lot of timing work.
@Terrence said in nRF5 Bluetooth action!:
@NeverDie Ya, that really sucks. It would have been great to mix and match.
At the moment I have no opinion to the "GPL or commercial" license of Readiohead. So I have no plans to port my Code .
The Nordic SDK has an ESB library supporting the nRF24 mode. IMHO Starting with SDK 13 the license is more Open Source friendly.
-
I'm realizing I can live with it. It just means I need to add a separate nRF24 gateway if I want to use nRF24's. I'm already adding separate gateways to support RFM69's and LoRa's, so, actually, it's no big deal.
Meanwhile, I've found that the RadioHead and the MySensors libraries are at least minimally compatible. So, presently I'm using RadioHead for my low power transmissions, but I'm using the sleep(...) function from MySensors to sleep the nRF52 and wake it up.
The only weirdness I'm noticing is that immediately after sending the very first packet in this configuration, there's a mysterious several second delay that occurs before the code continues. However, after the initial hiccup, everything appears to run exactly as fast as it should. I have no clue as to what is causing that initial delay though. It doesn't happen if I don't #include the MySensors.h file.
-
I was playing with sleep tonight and found the following problem.
when using sleep as below it always returns a figure 252 ms bigger than the sleep figure.
ie sleep 10000 always returns 10251
ie sleep 3000 always returns 3251.
I know the nrf51822 has a 32khz rtc so why is this?oldmillis = hwMillis(); hwSleep(10000); newmillis = hwMillis(); Serial.println(newmillis - oldmillis);
-
Seems it may have something to do with this in the code.
// Calculate sleep time // 8 Hz -> max 582.542 hours sleep. MY_HW_RTC->PRESCALER = 4095; // Set compare register to 1/125ms + 2 to garantee event triggering MY_HW_RTC->CC[0] = (ms / 125) + 2;```
-
MY_HW_RTC->CC[0] = (ms / 125) + 2;
It seems the +2 above is adding 250ms.
Why is it done like this???
-
What more can be done to reduce current consumption on an nRF52832 when the MySensors "sleep" function is being used with RTC wakeup. I've measured a 300mv drop on a 10F capacitor over a 12 hour time period. Of that 300mv, perhaps 20mv was lost due to self-discharge of the supercap. So, that still leaves 280mv of loss due to the nRF52832 . That is too high a rate of loss.
-
@NeverDie
Seeing Your sketch would help?
-
@rmtucker said in nRF5 Bluetooth action!:
MY_HW_RTC->CC[0] = (ms / 125) + 2;
It seems the +2 above is adding 250ms.
Why is it done like this???A minimum of two ticks are required to be sure the CC[0] is triggered.
What accuracy is your requirement? I can add more code here to dynamical change the pre scaler plus a check if ms/125>=2
-
@d00616
My initial thoughts were how the nrf51822 could be used for energy meters (counting pulses and the gap between them),But unlike the arduino's which can not run timers when in sleep mode,The nrf5 can of course do this.
So the nrf5 would be able to report watts and usage while still using sleep mode.
But seeing the inaccuracy of the timer has put the brakes on that.
Yes being able to change the prescaler dynamically would help a great deal as 125ms / 582.542 hours is not really useful for most applications with a 250ms overrun.
-
Just wondering what the prescaler etc would have to be set to for ms accuracy and how long before overflow.(aint got my maths head on today)
-
@NeverDie said in nRF5 Bluetooth action!:
What more can be done to reduce current consumption on an nRF52832 when the MySensors "sleep" function is being used with RTC wakeup. I've measured a 300mv drop on a 10F capacitor over a 12 hour time period. Of that 300mv, perhaps 20mv was lost due to self-discharge of the supercap. So, that still leaves 280mv of loss due to the nRF52832 . That is too high a rate of loss.
Wh = 0.5 * 10F * 280mV = 0.392 Wh = 0.0326667 W
I=0.0326667/2.56V = 12.76mALooks like the node is most time fully active.
-
@rmtucker said in nRF5 Bluetooth action!:
@d00616
My initial thoughts were how the nrf51822 could be used for energy meters (counting pulses and the gap between them),But unlike the arduino's which can not run timers when in sleep mode,The nrf5 can of course do this.
So the nrf5 would be able to report watts and usage while still using sleep mode.If you have the idea to store the results into the EEPROM like storage the nRF5, then read the hints about this: https://github.com/d00616/arduino-NVM/#nvramh
The virtual EEPROM, the radio or debugging output are adding latency to the main loop. You will see more timing errors in long term run when you trust the sleep() time.
The nRF5 can help you to count without adding latency by the cpu. You can use a timer in counter mode which TASK_COUNT and TASKS_CAPTURE[0] are triggered by PPI. Then you can compare the hwMillis() with the last seen CC[0] content and do precise calculation of events.
With nRF52 there is an unused RTC wich can trigger TASKS_CAPTURE[0] at a specific time. One RTC is used for millis() in arduino-nrf5 and one RTC is used for sleep.
But seeing the inaccuracy of the timer has put the brakes on that.
Yes being able to change the prescaler dynamically would help a great deal as 125ms / 582.542 hours is not really useful for most applications with a 250ms overrun.I will change this.
-
@rmtucker
Here it is, though it's rather messy. Nonetheless, all it does is measure the supercap and solar panel voltages, send them, then sleep for 12 hours. Then repeats:// nrf51_client.pde // -*- mode: C++ -*- // Example sketch showing how to create a simple messageing client // with the RH_NRF51 class. RH_NRF51 class does not provide for addressing or // reliability, so you should only use RH_NRF51 if you do not need the higher // level messaging abilities. // It is designed to work with the other example nrf51_server. // Tested on RedBearLabs nRF51822 and BLE Nano kit, built with Arduino 1.6.4. // See http://redbearlab.com/getting-started-nrf51822/ // for how to set up your Arduino build environment // Also tested with Sparkfun nRF52832 breakout board, witth Arduino 1.6.13 and // Sparkfun nRF52 boards manager 0.2.3 #include <RH_NRF51.h> #include <MySensors.h> unsigned long SLEEP_TIME = 43200000; // 12 hour sleep time between measurements (in milliseconds) //unsigned long SLEEP_TIME = 3600000; // 1 hour sleep time between measurements (in milliseconds) //unsigned long SLEEP_TIME = 300000; // 5 minute sleep time between measurements (in milliseconds) //unsigned long SLEEP_TIME = 1000; // 1 second sleep time between measurements (in milliseconds) #define SUPERCAP_PIN A2 //input pin for reading the supercap's voltage #define SOLAR_PANEL_PIN A4 //input pin for reading the solar panel's voltage #define LDO_ENABLE_PIN 8 //D8 (P0.19) is output pin for enabling (HIGH) or disabling (LOW) the LDO #define NUM_MEASUREMENTS_TO_AVERAGE 3 //number of measurements to collect and then average #define MAX_MEASUREMENTS 10 //Maximum number of voltage measurements before returning a result. // Singleton instance of the radio driver RH_NRF51 nrf51; uint8_t data[10]; uint16_t batteryVoltage() { uint16_t lastRawVoltage, newRawVoltage; //uint16_t counter=0; //lastRawVoltage = hwCPUVoltage(); //throw away the first voltage measurement newRawVoltage = hwCPUVoltage(); return newRawVoltage; } uint16_t readRawVoltageOnPin(uint8_t thePin) { uint16_t lastRawVoltage, newRawVoltage; uint16_t counter=0; lastRawVoltage = analogRead(thePin); newRawVoltage = analogRead(thePin); while (((newRawVoltage != lastRawVoltage)) && (counter<MAX_MEASUREMENTS)) { //measure until two consecutive measurements match lastRawVoltage=newRawVoltage; newRawVoltage=analogRead(thePin); counter++; } uint32_t sumOfMeasurements=0; for (int i=0;i<NUM_MEASUREMENTS_TO_AVERAGE;i++) { sumOfMeasurements=sumOfMeasurements+analogRead(thePin); } return (sumOfMeasurements/NUM_MEASUREMENTS_TO_AVERAGE); } void myBaro() { uint32_t superCapVoltage=0; uint32_t solarPanelVoltage=0; uint32_t superCapRawVoltage=0; uint32_t solarPanelRawVoltage=0; digitalWrite(LDO_ENABLE_PIN, LOW); //disconnect solar panel superCapRawVoltage = readRawVoltageOnPin(SUPERCAP_PIN); superCapVoltage = (3048*(((superCapRawVoltage)*3127)/4095))/1591; //Serial.print("SuperCap voltage="); //Serial.println(superCapVoltage); //send(msg1_S_BARO_P.set(superCapVoltage)); //superCap's raw voltage // wait(500); // wait(500); //delayMicroseconds(1000); //wait for voltage to adjust after LDO disabled. Necessary??? solarPanelRawVoltage=readRawVoltageOnPin(SOLAR_PANEL_PIN); digitalWrite(LDO_ENABLE_PIN, HIGH); //re-connect solar panel solarPanelVoltage=(5500*(((solarPanelRawVoltage)*3181)/4095))/1289; //Serial.print("Solar Panel Voltage="); //Serial.println(solarPanelVoltage); //superCapVoltage=1234; data[0]= (superCapVoltage/1000)+'0'; data[1]= ((superCapVoltage%1000)/100)+'0'; data[2]= ((superCapVoltage%100)/10)+'0'; data[3]= (superCapVoltage%10)+'0'; data[4]=','; data[5]= (solarPanelVoltage/1000)+'0'; data[6]= ((solarPanelVoltage%1000)/100)+'0'; data[7]= ((solarPanelVoltage%100)/10)+'0'; data[8]= (solarPanelVoltage%10)+'0'; data[9]='\0'; nrf51.send(data, sizeof(data)); nrf51.waitPacketSent(); } void setup() { pinMode(LDO_ENABLE_PIN, OUTPUT); // Enable/Disable pin for the LDO digitalWrite(LDO_ENABLE_PIN, HIGH); //enable the LDO. analogReadResolution(12); //use 12-bit ADC resolution pinMode(SUPERCAP_PIN,INPUT); //Supercap voltage measurement pin pinMode(SOLAR_PANEL_PIN,INPUT); //Solar panel voltage measurement pin //delay(1000); // Wait for serial port etc to be ready Serial.begin(250000); //while (!Serial) ; // wait for serial port to connect. if (!nrf51.init()) Serial.println("init failed"); // Defaults after init are 2.402 GHz (channel 123), 2Mbps, 0dBm if (!nrf51.setChannel(123)) Serial.println("setChannel failed"); if (!nrf51.setRF(RH_NRF51::DataRate2Mbps, RH_NRF51::TransmitPower4dBm)) Serial.println("setRF failed"); // AES encryption can be enabled by setting the same key in the sender and receiver // uint8_t key[] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, // 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08}; // nrf51.setEncryptionKey(key); // nrf51.printRegisters(); Serial.println("Setup of nr51 client completed."); Serial.println("Sending to nrf51_server..."); Serial.flush(); } uint32_t sentCounter=0; uint32_t replyCounter=0; void loop() { //uint16_t theBatteryVoltage; //theBatteryVoltage=batteryVoltage(); //theBatteryVoltage=batteryVoltage(); // Serial.print("Battery voltage = "); //Serial.print(theBatteryVoltage); //Serial.println(" millivolts."); // Send a message to nrf51_server //uint8_t data[] = "Hello World!"; /* data[0]= (theBatteryVoltage/1000)+'0'; data[1]= ((theBatteryVoltage%1000)/100)+'0'; data[2]= ((theBatteryVoltage%100)/10)+'0'; data[3]= (theBatteryVoltage%10)+'0'; data[4]='\0'; nrf51.send(data, sizeof(data)); sentCounter++; nrf51.waitPacketSent(); */ myBaro(); /* // Now wait for a reply uint8_t buf[RH_NRF51_MAX_MESSAGE_LEN]; uint8_t len = sizeof(buf); if (nrf51.waitAvailableTimeout(500)) { // Should be a reply message for us now if (nrf51.recv(buf, &len)) { Serial.print("got reply: "); Serial.println((char*)buf); replyCounter++; } else { Serial.println("recv failed"); } } else { Serial.println("No reply, is nrf51_server running?"); } Serial.print("sentCounter="); Serial.print(sentCounter); Serial.print(", replyCounter="); Serial.println(replyCounter); Serial.flush(); */ sleep(SLEEP_TIME); // Sleeps for 12 hours in deep sleep }Using Termite to timestamp the output received, what I got was:
2017/08/25 17:04:13: got request: 2684,0085 2017/08/26 05:04:12: got request: 2396,0076You can ignore the solar panel measurements, because I disconnected it so as to not interfere.
On the bright side, it woke up and reported within 1 second of when it was supposed to, after a 12 hour sleep.
-
@NeverDie said in nRF5 Bluetooth action!:
Here it is, though it's rather messy. Nonetheless, all it does is measure the supercap and solar panel voltages, send them, then sleep for 12 hours. Then repeats:
RadioHead sets the radio into the Idle state. The radio isn't powered off. There is no call in RadioHead to power off the radio.
-
@NeverDie
So your sketch only wakes up every 12hours.
What current is it drawing using the radiohead library vs mysensors for an equivalent 12 hour sleep because in past discussions with you i remember you saying 5-6uA while sleeping,is this still correct?
I dont see much advantage to the radiohead library if only sending at 12hour intervals.
-
@rmtucker said in nRF5 Bluetooth action!:
@NeverDie
So your sketch only wakes up every 12hours.
What current is it drawing using the radiohead library vs mysensors for an equivalent 12 hour sleep because in past discussions with you i remember you saying 5-6uA while sleeping,is this still correct?
I dont see much advantage to the radiohead library if only sending at 12hour intervals.The 6ua was measured with it in deep sleep, where it relied on an external interrupt to wakeup. This measurement was intended to see what it would be if it woke-up using the RTC. So, the 12 hour interval is artificial, for measurement purposes.
@d00616
I had wrongly assumed that the "sleep(...)" command would sleep the radio. Thanks for pointing out my error. How/when is it that Mysensors puts the radio to sleep? Does it just happen automatically at the end of every sending/receiving?
-
@NeverDie said in nRF5 Bluetooth action!:
I had wrongly assumed that the "sleep(...)" command would sleep the radio. Thanks for pointing out my error. How/when is it that Mysensors puts the radio to sleep? Does it just happen automatically at the end of every sending/receiving?
We are both not 100% correct
The hwSleep() function doesn't disable the radio, but the sleep() function does it, when MY_SENSOR_NETWORK is defined.After Sleep transportReInitialise() is called. Then you have to initialize RadioHead again.
-
@d00616 said in nRF5 Bluetooth action!:
After Sleep transportReInitialise() is called. Then you have to initialize RadioHead again.
So, even with RAM retention active while sleeping, each time the radio is awoken, it needs to be re-initialized?
-
@NeverDie said in nRF5 Bluetooth action!:
So, even with RAM retention active while sleeping, each time the radio is awoken, it needs to be re-initialized?
The Radio has to be initialized after power down. This doesn't depend on RAM retention.
-
According to Table 39 of the mRF52832 datasheet, there is only one radio state resembling sleep, and that is the DISABLED radio state where "No operations are going on inside the radio and the power consumption is at a minimum."
Apparently the radio is disabled through register TASKS_DISABLE, offset 0x010, Disable RADIO, as indicated by Table 41 register overview.
-
But how exactly does one read or write to these registers? It looks like a quite different arrangement than writing to registers for an nRF24 or an RFM69 or a LoRa chip.
-
@NeverDie said in nRF5 Bluetooth action!:
But how exactly does one read or write to these registers? It looks like a quite different arrangement than writing to registers for an nRF24 or an RFM69 or a LoRa chip.
You have to include nrf.h. To disable the radio, you can do this:
https://github.com/mysensors/MySensors/blob/development/drivers/NRF5/Radio_ESB.cpp#L264
If your transmitting power is 0dbm, then "TX only run current PRF = 0dBm" with 11.6 mA is near the calculated current, when the radio stays in TX mode after sending the data.
-
@d00616
Will this block of code guarantee that the radio is disabled?Serial.println("Testing whether radio is disabled..."); Serial.print("NRF_RADIO->EVENTS_DISABLED="); Serial.println(NRF_RADIO->EVENTS_DISABLED); while (!(NRF_RADIO->EVENTS_DISABLED)) { Serial.print("NRF_RADIO->EVENTS_DISABLED="); Serial.println(NRF_RADIO->EVENTS_DISABLED); NRF_RADIO->TASKS_DISABLE = 1; //sleep the radio } Serial.println("Radio disabled.");
-
@NeverDie said in nRF5 Bluetooth action!:
Will this block of code guarantee that the radio is disabled?
This one is better:
if (NRF_RADIO->STATE != RADIO_STATE_STATE_Disabled) { NRF_RADIO->TASKS_DISABLE = 1; }
-
@rmtucker said in nRF5 Bluetooth action!:
Yes being able to change the prescaler dynamically would help a great deal as 125ms / 582.542 hours is not really useful for most applications with a 250ms overrun.
The sleep() function is now more precise for sleeping <512s:
https://github.com/mysensors/MySensors/pull/909
The PR is waiting for merge.
-
@d00616
That works. Thanks!What's the best way to awaken the radio after sleeping it though? I've tried:
NRF_RADIO->TASKS_START = 1; //awaken the radioand
NRF_RADIO->TASKS_TXEN = 1; //awaken the radioand neither seems to have an effect. The radio stays disabled.
-
@NeverDie said in nRF5 Bluetooth action!:
What's the best way to awaken the radio after sleeping it though? I've tried:
This depends on the implementation. Sorry, at the moment I have not time to look into the RadioHead code in that detail. You can try to initialize the library again.
-
@NeverDie Here is a snippet to dump all registers, hope it's help to analyze whats going wrong with RadioHead:
Serial.print("NRF_RADIO->EVENTS_READY "); Serial.println(NRF_RADIO->EVENTS_READY, HEX); Serial.print("NRF_RADIO->EVENTS_ADDRESS "); Serial.println(NRF_RADIO->EVENTS_ADDRESS, HEX); Serial.print("NRF_RADIO->EVENTS_PAYLOAD "); Serial.println(NRF_RADIO->EVENTS_PAYLOAD, HEX); Serial.print("NRF_RADIO->EVENTS_END "); Serial.println(NRF_RADIO->EVENTS_END, HEX); Serial.print("NRF_RADIO->EVENTS_DISABLED "); Serial.println(NRF_RADIO->EVENTS_DISABLED, HEX); Serial.print("NRF_RADIO->EVENTS_DEVMATCH "); Serial.println(NRF_RADIO->EVENTS_DEVMATCH, HEX); Serial.print("NRF_RADIO->EVENTS_DEVMISS "); Serial.println(NRF_RADIO->EVENTS_DEVMISS, HEX); Serial.print("NRF_RADIO->EVENTS_RSSIEND "); Serial.println(NRF_RADIO->EVENTS_RSSIEND, HEX); Serial.print("NRF_RADIO->EVENTS_BCMATCH "); Serial.println(NRF_RADIO->EVENTS_BCMATCH, HEX); Serial.print("NRF_RADIO->CRCSTATUS "); Serial.println(NRF_RADIO->CRCSTATUS, HEX); Serial.print("NRF_RADIO->RXMATCH "); Serial.println(NRF_RADIO->RXMATCH, HEX); Serial.print("NRF_RADIO->RXCRC "); Serial.println(NRF_RADIO->RXCRC, HEX); Serial.print("NRF_RADIO->DAI "); Serial.println(NRF_RADIO->DAI, HEX); Serial.print("NRF_RADIO->PACKETPTR "); Serial.println(NRF_RADIO->PACKETPTR, HEX); Serial.print("NRF_RADIO->FREQUENCY "); Serial.println(NRF_RADIO->FREQUENCY, HEX); Serial.print("NRF_RADIO->TXPOWER "); Serial.println(NRF_RADIO->TXPOWER, HEX); Serial.print("NRF_RADIO->MODE "); Serial.println(NRF_RADIO->MODE, HEX); Serial.print("NRF_RADIO->PCNF0 "); Serial.println(NRF_RADIO->PCNF0, HEX); Serial.print("NRF_RADIO->PCNF1 "); Serial.println(NRF_RADIO->PCNF1, HEX); Serial.print("NRF_RADIO->BASE0 "); Serial.println(NRF_RADIO->BASE0, HEX); Serial.print("NRF_RADIO->BASE1 "); Serial.println(NRF_RADIO->BASE1, HEX); Serial.print("NRF_RADIO->PREFIX0 "); Serial.println(NRF_RADIO->PREFIX0, HEX); Serial.print("NRF_RADIO->PREFIX1 "); Serial.println(NRF_RADIO->PREFIX1, HEX); Serial.print("NRF_RADIO->TXADDRESS "); Serial.println(NRF_RADIO->TXADDRESS, HEX); Serial.print("NRF_RADIO->RXADDRESSES "); Serial.println(NRF_RADIO->RXADDRESSES, HEX); Serial.print("NRF_RADIO->CRCCNF "); Serial.println(NRF_RADIO->CRCCNF, HEX); Serial.print("NRF_RADIO->SHORTS "); Serial.println(NRF_RADIO->SHORTS, HEX);
-
@d00616
I did a bit more poking around, and I've confirmed that there's no need to re-enable the radio before transmitting. Apparently doing the transmission and returning to disabled mode happens automatically. In fact, I think this is the expected behavior, as indicated by Figure 35 of the datasheet.
-
So, under this theory, the only time when the radio is not disabled is when it is actively transmitting or receiving. There's no need to manually disable it, because that appears to happen automatically anyway.
-
So, to move forward with this, I took a super-stripped down nRF52832, and loaded it with a super stripped down sketch that never initializes the radio and pretty much just jumps directly into a long RTC 12 hour slumber using the MySensors sleep routine. Measuring the current drawn while in that slumber using a uCurrent Gold, I'm reading about 9.3ua. So, to confirm that, I'm running the same stripped down setup from a 10F supercap, and I'll see at what rate the supercap voltage drops with time, and whether that appears to agree or not with these initial measurements.
Hopefully the current draw will remain low, and there will be no surprises. In that case, I'll add stuff back in until I find the culprit that was previously causing the higher current draw.
-
@NeverDie
I can not understand why you are drawing 9.4uA in the first place?.
My nrf51822 seems to consistently only draw 4-5uA with no strip down of software when in mysensors sleep mode.
Fair enough i have not got your measurement equipment but i don,t see it being that far away.
The data sheets seem to point to under 5uA.
-
@rmtucker said in nRF5 Bluetooth action!:
I can not understand why you are drawing 9.4uA in the first place?.
Yes, it is puzzling. I don't have a good answer as to why it measures so high. Maybe the crystal oscillator? What else is there that might be causing it?
-
After this initial run completes, I'll try reprogramming it to use the internal resonnator instead and see if that makes any difference.
-
Indeed, reprogramming the Ebyte nRF52832 to use the internal oscillator dropped the sleep current consumption down to 5.4ua.
I wonder whether physically removing the crystal oscillator would result in additional savings, or if that's as low as it goes?
I also wonder whether the datasheet cheats a bit by not counting the current consumed by the external crystal oscillator when that's being used? Otherwise, I don't see how Nordic can claim a <2ua sleep current for the nRF52832.
-
Stranger still my 4-5uA is using the external crystal??.
-
I have to amend what I just said, because I took a measurement short-cut that in retrospect I shouldn't have: namely, I did the measurements on two different modules.
I went back and changed the 5.4ua module using the RC internal oscillator to use the external crystal oscillator, and it measures about the same.
So... The difference I was reading was a difference in the way the two modules measure. I'm not sure why one reads higher than the other, except perhaps that I didn't clean the solder flux off the higher reading module, and I did clean off the solder flux on the lower reading module.
I'll try cleaning the solder flux off the higher reading module and see if that drops the current consumed.
-
I cleaned off the solder flux and... no real difference. Go figure. Maybe it's just random variation among the Ebyte Modules? I guess I'll have to wire up more of them and see how they all compare.
-
@NeverDie did you select the option with internal crystal ? 1s accuracy after 12h like you said before sounds more like a precise external crystal than an internal one.
-
@Nca78 said in nRF5 Bluetooth action!:
@NeverDie did you select the option with internal crystal ? 1s accuracy after 12h like you said before sounds more like a precise external crystal than an internal one.
Up until today I was using just the external crystal on the Ebyte nRF52832's. It was only for comparison purposes of current consumption that today I switched to the internal resonator. It's about the same current consumption. Maybe if I now remove the external crystal, it will save some current? I just don't know.
-
@rmtucker said in nRF5 Bluetooth action!:
I can not understand why you are drawing 9.4uA in the first place?.
My nrf51822 seems to consistently only draw 4-5uA with no strip down of software when in mysensors sleep mode.While developing the nRF5 port, I had no chance to measure the current of the nRF52 accurate. With my original nRF51 dev kit I I have a sleeping current matching the data sheet.
Now I can measure currents in the µA range. With all nRF52 I have, I measured sleeping currents around 10µA. This is to much. We have to see 2-3µA. I have no original nRF52832 dev kit to compare. The reason of this sleeping current can be either an error in the layout or there is a component which is not required in active state while sleeping.
At the moment I have no time to analyse this. There is a bug in the radio code, which I have to fix. When transport debug is disabled no packages are received. In my opinion this has more priority.
-
@NeverDie Just my two cents. Leakage current through non ideal capacitors can be 1-10uA.
-
@NeverDie said in nRF5 Bluetooth action!:
So, to move forward with this, I took a super-stripped down nRF52832, and loaded it with a super stripped down sketch that never initializes the radio and pretty much just jumps directly into a long RTC 12 hour slumber using the MySensors sleep routine. Measuring the current drawn while in that slumber using a uCurrent Gold, I'm reading about 9.3ua. So, to confirm that, I'm running the same stripped down setup from a 10F supercap, and I'll see at what rate the supercap voltage drops with time, and whether that appears to agree or not with these initial measurements.
Hopefully the current draw will remain low, and there will be no surprises. In that case, I'll add stuff back in until I find the culprit that was previously causing the higher current draw.
It turns out that the culprit was the mere act of using pinmode to designate a pin as an input pin, even if it's not connected to anything. Then, during sleep, the current consumption is an order of magnitude higher. This is quite different behavior than on, say, an Arduino pro mini, where the input pins are high impedance and there's neglible current draw.
Not sure what to do about it though. Any ideas?
-
The same sort of thing happens if pinmode is used to designate a pin as an output pin--again, even if nothing is connected to it.
This is a potential show stopper. This module is useless to me if I can't connect it to anything.
As a workaround, is there some way to designate a pin as undefined again after having used pinmode to define it as either an input pin or an output pin?
-
Well, setting the pinmode to OUTPUT and then digitalwriting it to LOW seems to help considerably--at least when it's not connected to anything.
[Edit: Setting it to HIGH also helps similarly.]
-
Anyhow, I'm relieved that the radio isn't the source of these power drain problems. This pinmode stuff is a bummer, but it looks like I can at least partially work around it.
Suggested Topics
-
Welcome
Announcements • • hek
