nRF5 action!
-
@d00616 said in nRF5 Bluetooth action!:
Yes. Give the event register as parameter.
so, if I have an intterupt atached to pin 1, what shall i put into ISR?
NRF_RESET_EVENT....;
Sorry for dumb questions, this is completely new to me.@Toyman said in nRF5 Bluetooth action!:
@d00616 said in nRF5 Bluetooth action!:
Yes. Give the event register as parameter.
so, if I have an intterupt atached to pin 1, what shall i put into ISR?
With arduino-nrf5, you can't put nothing into the pin interrupt ISR because the ISR is already defined.
Sorry for dumb questions, this is completely new to me.
There are no dumb questions, there are bad answers.
-
@d00616 said in nRF5 Bluetooth action!:
If you need help, please ask.
What is it that I submit? A diff file or something? And I'm guessing I do it through github?
@NeverDie said in nRF5 Bluetooth action!:
@d00616 said in nRF5 Bluetooth action!:
If you need help, please ask.
What is it that I submit? A diff file or something? And I'm guessing I do it through github?
There is and document describing the procedure: https://www.mysensors.org/download/contributing
I think this is a good document to start with. If you have trouble, please ask.
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616 said in nRF5 Bluetooth action!:
If you need help, please ask.
What is it that I submit? A diff file or something? And I'm guessing I do it through github?
There is and document describing the procedure: https://www.mysensors.org/download/contributing
I think this is a good document to start with. If you have trouble, please ask.
@d00616
The solution I'm going with, which serves my present needs, is just to put all serial communications code within "DEBUG" compiler directives. So, if I'm not debugging, the issue just goes away, and there's no added overhead. :) -
@d00616
The solution I'm going with, which serves my present needs, is just to put all serial communications code within "DEBUG" compiler directives. So, if I'm not debugging, the issue just goes away, and there's no added overhead. :)@NeverDie said in nRF5 Bluetooth action!:
@d00616
The solution I'm going with, which serves my present needs, is just to put all serial communications code within "DEBUG" compiler directives. So, if I'm not debugging, the issue just goes away, and there's no added overhead. :)Found a shortcut. Instead of doing all that, which is extra work and looks ugly too, I just disabled the UART0 on the first sleep, and then never re-enabled it. It works.Now my sleep current is just 2.1ua, except for the brief pulses every 100ms where the PPI listens for an incoming packet addressed to it. :) -
Nonetheless, I just now measured the sleep current on the cheap nRF51822 that @NCA78 referenced:
https://www.aliexpress.com/item/NRF51822-04-BLE4-0-Wireless-Bluetooth-Module-TTL-Low-Power-Consumption-3-3V-New/32821044213.html?aff_platform=aaf&cpt=1507850033284&sk=e2Vzr3v&aff_trace_key=fa8ec197f200446fbd58fc8679ffb3bd-1507850033284-07709-e2Vzr3v&terminal_id=29bfb7ff18284b7f96acb3c3884390ce
It measures at 5ua, which is higher than the 2.1ua of the nRF52832, but still not bad in absolute terms. I was afraid after the discussion of how some nrf51's had a 1ma bug in the hardware that they would be counted among them. Fortunately, it seems not. :) -
Nonetheless, I just now measured the sleep current on the cheap nRF51822 that @NCA78 referenced:
https://www.aliexpress.com/item/NRF51822-04-BLE4-0-Wireless-Bluetooth-Module-TTL-Low-Power-Consumption-3-3V-New/32821044213.html?aff_platform=aaf&cpt=1507850033284&sk=e2Vzr3v&aff_trace_key=fa8ec197f200446fbd58fc8679ffb3bd-1507850033284-07709-e2Vzr3v&terminal_id=29bfb7ff18284b7f96acb3c3884390ce
It measures at 5ua, which is higher than the 2.1ua of the nRF52832, but still not bad in absolute terms. I was afraid after the discussion of how some nrf51's had a 1ma bug in the hardware that they would be counted among them. Fortunately, it seems not. :)@NeverDie The nRF51 is done on a different process then then the nRF52. The nRF52 is on average 50% lower power then the nRF51. The picture of the module shows a nRF51822QFAA Hx part which is a 256k flash, 16k Ram part REV 3. You can see all the revision number here: http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf51/dita/nrf51/compatibility_matrix/nRF51822_ic_revision_overview.html?cp=3_0_1
-
I was just checking the nRF51 datasheet, and I don't see much, if any, PPI control available. So, I suppose that's yet another reason for preferring the nRF52....
-
@NeverDie You may wish to check out the nRF51 Reference guide in addition to the datasheet. http://infocenter.nordicsemi.com/pdf/nRF51_RM_v3.0.1.pdf The PPI is located in section 16.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie You may wish to check out the nRF51 Reference guide in addition to the datasheet. http://infocenter.nordicsemi.com/pdf/nRF51_RM_v3.0.1.pdf The PPI is located in section 16.
Thanks! Doesn't look as though the nRF51822's PPI allows for FORK though, whereas the nRF52832 does.
-
@Toyman said in nRF5 Bluetooth action!:
Guys,
Have you seen this?
Note, that our beloved ebyte is not there, but PTR9618PA is
It's useful. But just knowing the module exists is one thing. Finding a source for it is another.
@NeverDie actually, I am suprised that many of these modules are available and at the prices lower than Ali.
For example:
http://www.fanstel.com/buy/bt832xe
They claim "BT832XE is the longest range Bluetooth 5 module, 1350 meters between 2 BT832XE with used with ANT060 antenna."
$23, shipped within US
Not bad, ah? -
One must be aware, that the gain of an antenna doesn't come from a magic amplification, but from direction.
Meaning, the higher the gain of an antenna is, the more directional it is.
For a sensor, let's say a window switch, that may end up in every mounting position you might imagine, this is NOT what you want.Neither do you want that for the gateway, that may be in the middle of the house, and should be able to receive transmissions from all directions.
-
One must be aware, that the gain of an antenna doesn't come from a magic amplification, but from direction.
Meaning, the higher the gain of an antenna is, the more directional it is.
For a sensor, let's say a window switch, that may end up in every mounting position you might imagine, this is NOT what you want.Neither do you want that for the gateway, that may be in the middle of the house, and should be able to receive transmissions from all directions.
@Uhrheber
It does look like they also have a PA on their module: http://www.fanstel.com/bt832x-bluetooth-5-module/It's a good find, as it looks as though they have a lot to choose from: http://www.fanstel.com/buy/
Also, as compared to the chinese vendors, I think it's more likely that they really did pass FCC, since it's based in the US. The fines to US companies for selling non-compliant stuff are pretty severe (enough to bankrupt a small company), whereas (it seems) the chinese vendors can dodge it. Hence, the joke that "CE" stands for "Chinese Exemption".
-
@Uhrheber
It does look like they also have a PA on their module: http://www.fanstel.com/bt832x-bluetooth-5-module/It's a good find, as it looks as though they have a lot to choose from: http://www.fanstel.com/buy/
Also, as compared to the chinese vendors, I think it's more likely that they really did pass FCC, since it's based in the US. The fines to US companies for selling non-compliant stuff are pretty severe (enough to bankrupt a small company), whereas (it seems) the chinese vendors can dodge it. Hence, the joke that "CE" stands for "Chinese Exemption".
-
I just now noticed that fanstel is selling an nRF52840 module: http://www.fanstel.com/buy/bt840f-v1-nrf52840-bluetooth-5-thread-zigbee-module
That's the first I've seen on the open market (aside from the DK that is). [Edit: won't be shipping until January though]
I wonder which, if any, of the Fanstel modules contain the DCDC hardware? Their pinout on the 832's does not appear to be as complete as the Ebyte module, so if DCDC is not already on the module, it might be impossible to add after-the-fact.
-
I just now noticed that fanstel is selling an nRF52840 module: http://www.fanstel.com/buy/bt840f-v1-nrf52840-bluetooth-5-thread-zigbee-module
That's the first I've seen on the open market (aside from the DK that is). [Edit: won't be shipping until January though]
I wonder which, if any, of the Fanstel modules contain the DCDC hardware? Their pinout on the 832's does not appear to be as complete as the Ebyte module, so if DCDC is not already on the module, it might be impossible to add after-the-fact.
@NeverDie said in nRF5 Bluetooth action!:
Their pinout on the 832's does not appear to be as complete as the Ebyte module, so if DCDC is not already on the module, it might be impossible to add after-the-fact.
Page 13,
pin F5 -
@NeverDie said in nRF5 Bluetooth action!:
Their pinout on the 832's does not appear to be as complete as the Ebyte module, so if DCDC is not already on the module, it might be impossible to add after-the-fact.
Page 13,
pin F5@Toyman Thanks! I'm going to order a couple of the Nordic nRF52840 PDK's to audition now that modules are on the horizon. Shall be interesting to see how the range compares in a normal home environment. Also, 256K RAM and 1M of flash sounds like such a luxury!
-
I just now noticed that fanstel is selling an nRF52840 module: http://www.fanstel.com/buy/bt840f-v1-nrf52840-bluetooth-5-thread-zigbee-module
That's the first I've seen on the open market (aside from the DK that is). [Edit: won't be shipping until January though]
I wonder which, if any, of the Fanstel modules contain the DCDC hardware? Their pinout on the 832's does not appear to be as complete as the Ebyte module, so if DCDC is not already on the module, it might be impossible to add after-the-fact.
-
@NeverDie Note that all the nRF52840 based products being showcased now (including the Fanstel modules) are using the engineering silicon. There is Errata on these parts. Production devices will be available Q1-18.
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie Note that all the nRF52840 based products being showcased now (including the Fanstel modules) are using the engineering silicon. There is Errata on these parts. Production devices will be available Q1-18.
Do you advise waiting, or is it sufficiently non-buggy that it's likely to work unless doing something obscure?
-
@d00616 Problem #1 is that there does not yet appear to be an Arduino board definition for the nR5F2840, as there is already for the nRF52832 and nRF51822. Is that correct? Or does one already exist somewhere? It's critical path to testing code on the nRF52840 PDK.
-
@d00616 Problem #1 is that there does not yet appear to be an Arduino board definition for the nR5F2840, as there is already for the nRF52832 and nRF51822. Is that correct? Or does one already exist somewhere? It's critical path to testing code on the nRF52840 PDK.
Hmmm... Looks like there is an nRF52840 "variant": https://github.com/lpercifield/arduino-nRF5/commit/d55d54a1bdc479acc259e131f0f445c5da8e02b3
Would that work? If so, how exactly should it be added so that it will appear in the Arduino IDE board manager list of boards?
