nRF5 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?
@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"
-
@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 :D
-
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.
-
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.
-
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.
@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); -
-
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.
-
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.
-
MY_HW_RTC->CC[0] = (ms / 125) + 2;
It seems the +2 above is adding 250ms.
Why is it done like this???@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
-
@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.
