nRF5 action!
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616 Is it still the case that we're limited to a single interrupt? For instance, I'd like to put the nRF52832 to wake-up periodically as a heartbeat where it reports its battery level, and I also want it to wake-up if a particular pin goes HIGH (e.g. if a PIR sensor is triggered). Presently I'm using the RTC to provide the one interrupt, and I use the PPI to create an RTC interrupt if it detects that the PIR sensor pin has gone HIGH. Then the interrupt code must determine the true cause of the interrupt. It would be cleaner if I could separate them into separate interrupts.
You can wake up the MCU via:
- GPIO pin sense; used for sleep()
- GPIOTE; consumes less engergy but pin must be dedected in software (0.1µA-0.5µA)
- LPCOMP (0.5µA)
- QDEC (5µA)
The interrupts for LPCOMP and QDEC are not allocated by the arduino-port. I think the LPCOMP is a good point to start with.
-
@Toyman said in nRF5 Bluetooth action!:
Bringing nrf52Dk from Arrow to Russia costed me $10 (inter-US shipping is free at Arrow).
Do they ask you for shipment fee directly to Russia ?
I'm in Vietnam and bringing nrf52DK from Arrow was free, like everything I order from them, and over US$20 it's even express shipment (By the way they have a 25% flash sale right now !)I'm interested on info on your mail forwarder if it's not only for Russia.
-
@Nca78 Arrow ships free to Russia, but only to companies, not to direct consumers this is linked to the fact they use couriers (DHL/Fedex) and not vanilla USPS.
Have a look at www.shipito.com, it's not the one I am currently using, but Shipito works with the whole world. Pricing might be a bit steep, but I haven't looked at it for a long time.
-
http://blog.nordicsemi.com/getconnected/power-consumption-explained?utm_campaign=Blog update notifications&utm_source=hs_email&utm_medium=email&utm_content=57717514&hsenc=p2ANqtz-9HxcPCGqL9z_8UZBj38TZu8vg-vE-JmEgmzOlt-uiiGj32PO4Vm0brgVaCxtEly5tGV5aioj1vJezIbGK-xZVXV6zxQ&_hsmi=57717514
-
Had the nrf52dk shipped from arrow to the Netherlands. Because it was above 22 euro( something like that) DHL had to let it apply tax and some administration cost.
The board costed 28 euro(inc shipping). The tax office estimate was that is was around 120 euro??? so they charged me a little to much. I filled in some forms to get some of the taxes back.
When the board arrived I had to pay DHL 43 euro . So getting it though customes cost more than the board itself.
-
@Omemanti said in nRF5 Bluetooth action!:
When the board arrived I had to pay DHL 43 euro .
DHL is selling it's shipment service cheaper to shops so the cost seems interesting for buyer. But their trick is to force you to pay some "service fee" when you receive your parcel in addition to custom taxes. This is borderline scam IMHO as this fee is mandatory and has a fixed value for each destination country, so DHL should include it upfront when customer orders.
No more DHL shipment for me.
-
@d00616 said in nRF5 Bluetooth action!:
@NeverDie said in nRF5 Bluetooth action!:
@d00616 Is it still the case that we're limited to a single interrupt? For instance, I'd like to put the nRF52832 to wake-up periodically as a heartbeat where it reports its battery level, and I also want it to wake-up if a particular pin goes HIGH (e.g. if a PIR sensor is triggered). Presently I'm using the RTC to provide the one interrupt, and I use the PPI to create an RTC interrupt if it detects that the PIR sensor pin has gone HIGH. Then the interrupt code must determine the true cause of the interrupt. It would be cleaner if I could separate them into separate interrupts.You can wake up the MCU via:
- GPIO pin sense; used for sleep()
- GPIOTE; consumes less engergy but pin must be dedected in software (0.1µA-0.5µA)
- LPCOMP (0.5µA)
- QDEC (5µA)
The interrupts for LPCOMP and QDEC are not allocated by the arduino-port. I think the LPCOMP is a good point to start with.
I have it now where LPCOMP does detect pin AIN1 (i.e. pin P0.03) going HIGH, but it still doesn't wake-up the MCU,
and the interrupt code never runs. I could use the PPI to trigger an RTC interrupt when it detects the NRF_LPCOMP->EVENTS_UP event, which would wake up the MCU, but then I'm back to square one. Is that the best that can be done given the current state of the software?#define MY_CORE_ONLY #include <nrf.h> #include <MySensors.h> uint32_t blinkCounter=0; uint32_t interruptCounter=0; bool button_pressed=false; void setup() { Serial.begin(9600); Serial.println(); Serial.println("Starting..."); // Enable interrupt NVIC_SetPriority(LPCOMP_IRQn, 15); NVIC_ClearPendingIRQ(LPCOMP_IRQn); NVIC_EnableIRQ(LPCOMP_IRQn); hwPinMode(LED_BUILTIN,OUTPUT_H0H1); //hwPinMode(PIN_BUTTON1,INPUT); NRF_LPCOMP->PSEL=1; // monitor AIN1 (pin P0.03). while (!(NRF_LPCOMP->PSEL==1)) {} //wait until confirmed NRF_LPCOMP->REFSEL=3; // choose 1/2 VDD as the reference voltage while (!(NRF_LPCOMP->REFSEL==3)) {} //wait until confirmed NRF_LPCOMP->INTENSET=B0100; //Enable interrupt for UP event while (!(NRF_LPCOMP->INTENSET==B0100)) {} //wait until confirmed NRF_LPCOMP->ENABLE=1; //Enable LPCOMP while (!(NRF_LPCOMP->ENABLE==1)) {} //wait until confirmed NRF_LPCOMP->TASKS_START=1; //start the LPCOMP while (!(NRF_LPCOMP->EVENTS_READY)) {} //wait until ready } void loop() { Serial.print(blinkCounter++); Serial.println("HIGH"); digitalWrite(LED_BUILTIN,HIGH); delay(20); /* if (NRF_LPCOMP->EVENTS_UP) { digitalWrite(LED_BUILTIN,HIGH); delay(2000); NRF_LPCOMP->EVENTS_UP=0; //Clear the semaphore } */ if (button_pressed) { digitalWrite(LED_BUILTIN,HIGH); delay(2000); button_pressed=false; //Clear the semaphore NRF_LPCOMP->EVENTS_UP=0; //Clear the semaphore } digitalWrite(LED_BUILTIN,LOW); hwSleep(5000); } // * Reset events and read back on nRF52 //* http://infocenter.nordicsemi.com/pdf/nRF52_Series_Migration_v1.0.pdf #if __CORTEX_M == 0x04 #define NRF5_RESET_EVENT(event) \ event = 0; \ (void)event #else #define NRF5_RESET_EVENT(event) event = 0 #endif // This must be in one line //extern "C" { void GPIO_IRQHandler(void) {interruptCounter++; NRF5_RESET_EVENT(NRF_RTC0->EVENTS_OVRFLW); NRF_RTC0->EVENTS_OVRFLW=0; }} extern "C" { void LPCOMP_IRQHandler(void) {button_pressed=true; interruptCounter++; NRF5_RESET_EVENT(NRF_LPCOMP->EVENTS_UP); NRF_LPCOMP->EVENTS_UP=0; }}
-
Getting closer... The LPCOMP interrupt code does run, but the main loop doesn't resume until the RTC timer makes it resume because the programmed time interval has expired.
I know this is true because if, during sleep, I make AIN1 go HIGH, and then LOW, then when the MCU later wakes up because of the RTC, it so indicates by making the LED go HIGH for 2 seconds. However, even though there's now solid proof that the LPCOMP interrupt hardware does execute, the main loop doesn't immediately resume, as it does when the RTC times out.
So.... How to make the main loop immediately resume whenever LPCOMP goes UP?
-
Well, I have to re-build the timer part of this, and clean up the code, but at least now a PIR sensor trigger will immediately wake-up the MCU. That's progress! Unfortunately, current drawn during sleep is now 456ua, which is much higher than it should be.
#define MY_CORE_ONLY #include <nrf.h> #include <MySensors.h> uint32_t rtcInterruptCounter=0; uint32_t buttonPressInterruptCounter=0; bool button_pressed=false; void myHwSleepPrepare(unsigned long ms) { // Idle serial device NRF_UART0->TASKS_STOPRX = 1; NRF_UART0->TASKS_STOPTX = 1; NRF_UART0->TASKS_SUSPEND = 1; //NRF_UART0->ENABLE=0; //disable UART0 //NRF_CLOCK->TASKS_HFCLKSTOP = 1; // Enable low power sleep mode NRF_POWER->TASKS_LOWPWR = 1; } // Sleep in System ON mode inline void doTheSleep() { __WFE(); __SEV(); __WFE(); } void myHwSleepEnd(unsigned long ms) { // Start HFCLK //if (nrf5_pwr_hfclk) { if (false) { NRF_CLOCK->EVENTS_HFCLKSTARTED = 0; NRF_CLOCK->TASKS_HFCLKSTART = 1; while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0) ; // Enable low latency sleep mode //NRF_POWER->TASKS_CONSTLAT = 1; } } void myHwSleep(unsigned long ms) { myHwSleepPrepare(ms); doTheSleep(); //now sleeping myHwSleepEnd(ms); } void setup() { //Serial.begin(9600); //Serial.println(); //Serial.println("Starting..."); // Enable interrupt NVIC_SetPriority(LPCOMP_IRQn, 15); NVIC_ClearPendingIRQ(LPCOMP_IRQn); NVIC_EnableIRQ(LPCOMP_IRQn); hwPinMode(LED_BUILTIN,OUTPUT_H0H1); //hwPinMode(PIN_BUTTON1,INPUT); NRF_LPCOMP->PSEL=1; // monitor AIN1 (pin P0.03). while (!(NRF_LPCOMP->PSEL==1)) {} //wait until confirmed NRF_LPCOMP->REFSEL=3; // choose 1/2 VDD as the reference voltage while (!(NRF_LPCOMP->REFSEL==3)) {} //wait until confirmed NRF_LPCOMP->INTENSET=B0100; //Enable interrupt for UP event while (!(NRF_LPCOMP->INTENSET==B0100)) {} //wait until confirmed NRF_LPCOMP->ENABLE=1; //Enable LPCOMP while (!(NRF_LPCOMP->ENABLE==1)) {} //wait until confirmed NRF_LPCOMP->TASKS_START=1; //start the LPCOMP while (!(NRF_LPCOMP->EVENTS_READY)) {} //wait until ready //NRF_PPI->CH[0].EEP = (uint32_t)&NRF_LPCOMP->EVENTS_UP; //If PIR sensor is triggered //NRF_PPI->CH[0].TEP = (uint32_t)&NRF_RTC0->TASKS_TRIGOVRFLW; //make the RTC wake-up the MCU //NRF_PPI->CHENSET=B00000001; //enable Channel 0. NRF_RTC0->INTENSET = B10; //interrupt MCU if an OVRFLW is detected. while (NRF_RTC0->INTENSET != B10) {} //wait until confirmed } void loop() { //Serial.print(blinkCounter++); //Serial.println("HIGH"); digitalWrite(LED_BUILTIN,HIGH); delay(20); /* if (NRF_LPCOMP->EVENTS_UP) { digitalWrite(LED_BUILTIN,HIGH); delay(2000); NRF_LPCOMP->EVENTS_UP=0; //Clear the semaphore } */ if (button_pressed) { digitalWrite(LED_BUILTIN,HIGH); delay(2000); button_pressed=false; //Clear the semaphore NRF_LPCOMP->EVENTS_UP=0; //Clear the semaphore } digitalWrite(LED_BUILTIN,LOW); myHwSleep(5000); } // * Reset events and read back on nRF52 //* http://infocenter.nordicsemi.com/pdf/nRF52_Series_Migration_v1.0.pdf #if __CORTEX_M == 0x04 #define NRF5_RESET_EVENT(event) \ event = 0; \ (void)event #else #define NRF5_RESET_EVENT(event) event = 0 #endif // This must be in one line extern "C" { void RTC0_IRQHandler(void) {rtcInterruptCounter++; NRF5_RESET_EVENT(NRF_RTC0->EVENTS_OVRFLW); NRF_RTC0->EVENTS_OVRFLW=0; }} extern "C" { void LPCOMP_IRQHandler(void) {button_pressed=true; buttonPressInterruptCounter++; NRF5_RESET_EVENT(NRF_LPCOMP->EVENTS_UP); NRF_LPCOMP->EVENTS_UP=0; }}
-
Aha! Most likely the high current draw is from the high frequency clock, which I need to turn off prior to sleep but haven't done yet.
-
Anyhow, the basic question remains and boils down to this: Can I have both
// Enable interrupt NVIC_SetPriority(LPCOMP_IRQn, 15); NVIC_ClearPendingIRQ(LPCOMP_IRQn); NVIC_EnableIRQ(LPCOMP_IRQn);AND an equivalent incantation for the RTC both active at the same time? Or am I forced into having it be just one or the other?
-
@NeverDie Did you manage to get more than 10m ? maybe by another modules.
I thought the nrf52 will have better range !
-
@Uhrheber I am a bit confused. To program the nRF52 from eByte I need a special programmer but they are expensive. So you mean you used a clone StLink V2 and it worked fine ?
I found this.
-
@ahmedadelhosni
Sure, I'm using a similar one.
Why wouldn't it work? The nrf52 is an ARM Mx, like the ST chips. The programming interface is the same. You could also use one of the many other ARM programmers, like J-Link, or nearly any JTAG programmer supported by OpenOCD.Just follow this guide: https://www.openhardware.io/view/376/MySensors-NRF5-Platform
And: https://github.com/sandeepmistry/arduino-nRF5/#installing
-
@Uhrheber Great. Thanks for the help.
So if I understand well. If I have a TIVA board like TM4C123G Launchpad and it is ARM Mx also, then I can use it to program my nRF ?
This is the datasheet for the board : http://www.ti.com/lit/ug/spmu296/spmu296.pdf
I searched and found those links describing how to use the Launchad but I am not sure whether this will work for nRF also or not.
http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To
http://ucsolutions.blogspot.com.eg/2014/08/ti-launchpad-as-external-debugger-with.htmlThanks.
-
@ahmedadelhosni said in nRF5 Bluetooth action!:
@Uhrheber Great. Thanks for the help.
So if I understand well. If I have a TIVA board like TM4C123G Launchpad and it is ARM Mx also, then I can use it to program my nRF ?
This is the datasheet for the board : http://www.ti.com/lit/ug/spmu296/spmu296.pdf
I searched and found those links describing how to use the Launchad but I am not sure whether this will work for nRF also or not.
http://processors.wiki.ti.com/index.php/Stellaris_LM4F120_LaunchPad_Debug_How_To
http://ucsolutions.blogspot.com.eg/2014/08/ti-launchpad-as-external-debugger-with.htmlThanks.
I think it's a question of the licence of the programmer that is on your board.
For example the J-Link version on the NRF52 DK is only allowed to program NRF52 and NRF51 chips. It's logic because the NRF52DK is just over 30$ while a J-Link programmer is x00$.
You have pins SWDIO and SWDCLK on pins PC0 and PC1 of your board so just try it and you will know
-
@Nca78 Yeah actually this makes sense. I forgot about the licence thing. Actually I didn't bug the boards and I want to get everything at once without missing anything. I am in a hurry
it is strange that this clone can do the work as @Uhrheber mentioned.
-
Guys, your best bet is to reflash STM32 Bluepill into BlackMagicProbe.
It's awesome!
https://medium.com/@paramaggarwal/converting-an-stm32f103-board-to-a-black-magic-probe-c013cf2cc38c
-
@NeverDie said in nRF5 Bluetooth action!:
Anyhow, the basic question remains and boils down to this: Can I have both
// Enable interrupt NVIC_SetPriority(LPCOMP_IRQn, 15); NVIC_ClearPendingIRQ(LPCOMP_IRQn); NVIC_EnableIRQ(LPCOMP_IRQn);AND an equivalent incantation for the RTC both active at the same time? Or am I forced into having it be just one or the other?
@d00616 Any thoughts or comments regarding this?
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616 Any thoughts or comments regarding this?
Sorry, I can't help here. Maybe, the interrupt priority can be used only once and you have to use another priority for RTC or LPCOMP.
-
I tried out the Fanstel BT832X (i.e. nRF52832 with PA and LNA) today:
Good news:
- Even without the PA turned on, the range seems a lot better than if transmitting from an Ebyte module.
- Also, I've confirmed that it comes with DCDC built-in.
- With the PA turned on, the range is comparable to, and perhaps even better than, the RFaxis I reviewed earlier in this thread.
With the PA turned on, it consumes about 250ma.
-
@d00616 I hooked up the Fanstel BT832A. Although it appeared to flash and verify correctly, I couldn't get it to do anything--not even blink. Is there any chance that it's downsized flash/memory has something to do with it? "Flash/RAM memories in BT832 are 512KB/64KB. They are 192KB/24KB in BT832A." So, as an experiment, I hooked up a BT832 in its place on the same board, and it's able to transmit and blink just fine. In total, the only differences between the two are:
- Cortex M4F in BT832 has hardware DSP and floating point instructions. Cortex M4 in BT832A has hardware DSP instructions but it does not have floating point unit to support hardware instruction.
- Flash/RAM memories in BT832 are 512KB/64KB. They are 192KB/24KB in BT832A.
- BT832 has NFC tag interface. BT832A does not have NFC tag
interface.
I think we can rule out #3. So, if it isn't #2, then is perhaps #1 a factor? I wouldn't think so.
The solder connections seemed correct. I suppose it's possible I simply got a bad module, but I'm doubtful that's it.
Here's a photo of it installed on a BT832X board, which is pin-for-pin compatible:
-
@NeverDie said in nRF5 Bluetooth action!:
I think we can rule out #3. So, if it isn't #2, then is perhaps #1 a factor? I wouldn't think so.
I think, you have to do more things:
- Change compiler attributes to disable FPU support
- Change the memory layout in linker scripts. Look into boards definition. Linker scripts are placed under ./cores/nRF5/SDK/components/toolchain/gcc/ The SDK14 has scripts supporting the nrf52810
- The SDK14 has an dedicated startup code (gcc_startup_nrf52810.S), I don't know if this relevant for arduino-nrf5
I think there is more to do than compile the code. I think the SDK code for arduino-nrf5 must be updated to SDK 14, then a nre MCU must be defined.
I have compared the startup code. The difference is in the interrupt vector. It should work with the NRF52832 startup code, but the linker script must be changed.
-
@d00616 Also, at least so far, I haven't been able to get the Fanstel modules to receive anything. At first I thought it must be an LNA thing, but I tried it just now on a Fanstel module without LNA, and although it can transmit and blink just fine, the regular receive code isn't working. Any theories on that?
-
@NeverDie said in nRF5 Bluetooth action!:
@d00616 Also, at least so far, I haven't been able to get the Fanstel modules to receive anything. At first I thought it must be an LNA thing, but I tried it just now on a Fanstel module without LNA, and although it can transmit and blink just fine, the regular receive code isn't working. Any theories on that?
I think this could be the memory layout -> linker script. My try to port Arduino to nrf51 in 2014 is failed at the same state. Blink was ok. Using something with memory are failed. The reason was a wrong linker script. At this time Nordic hasen't released (L)GPG compatible scripts.
Edit: I think it's possible to add the 82810 to https://github.com/mysensors/ArduinoHwNRF5 by changing the board definition and add the missing linker script into the variant folder.
-
@d00616 I'm puzzled then. The module that you are using (https://www.aliexpress.com/item/NRF52832-Mini-Development-Board-Gold-Core-board-Wireless-Bluetooth-Transceiver-Module/32798618219.html?spm=2114.search0204.3.1.BEAy98&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_5700015_5620015_10130_10068_10344_10345_10547_10342_10546_10343_10340_10341_10548_10545_10541_10307_5640015_10060_10155_10154_10056_10055_10539_10538_5370015_10537_10536_10059_10534_10533_100031_10103_10102_10142_10107_10324_10325_5760015_10084_10083_10178_5750015_10312_10313_10314_10073_5630015,searchweb201603_30,ppcSwitch_4_ppcChannel&btsid=011daf01-f75a-4448-9202-405ef9dcacd9&algo_expid=acb605b8-ed11-4497-8757-d77cd4b3550b-0&algo_pvid=acb605b8-ed11-4497-8757-d77cd4b3550b) allegedly comes with 512k flash and 64k ram. So, what, if any, difference is there between that and the Fanstel module with the same amount of flash and ram?
-
OK, I need to confirm it, but I have a theory now that the Fanstel modules don't have 32K clock crystals in them. That would explain why that have pinouts for XTAL1 and XTAL2. It might also be hanging my code, which assumes there is a clock crystal and tries to turn it on.
My using pin P0.02 to control the LED might be a deadly brew that causes the hang. I'll post a follow-up if that's what turns out to be the actual root of what superficially seemed like an "Rx problem."
-
It's confirmed. Son of a gun, they don't have the 32K clock crystal on the module. On the datasheet, it says that for battery operation, "We suggest adding a 32.768 kHz crystal and 2 capacitors as shown in the upper left corner of the evaluation board schematics."
I'll add pads for it on the breakout board.
-
@NeverDie said in nRF5 Bluetooth action!:
My using pin P0.02 to control the LED might be a deadly brew that causes the hang.
Correction: Use of P0.02 to control the LED shouldn't be a problem, as it corresponds to AIN0 and isn't involved in XTAL. Therefore, I edited the original post to strike-through this sentence.
-
Good news! Switching over to the RC oscillator totally fixed the problem. Both the Fanstel BT832 and BT832X now receive just fine.
-
In fact, both the Fanstel BT832 and the BT832X (with no LNA turned on) have much better receive range than an Ebyte module. They are head and shoulders better. In turn the BT832X (again, even with no LNA turned on) has a noticeably better receive range than the BT832.
So, at this point, I'm sold on the Fanstel modules for the most common uses. The Fanstel modules also have a smaller footprint than the Ebyte modules. The Ebyte modules might be better for those cases where you need a lot of easily accessible pins to do something, but that's about it I think.
-
@NeverDie said in nRF5 Bluetooth action!:
In fact, both the Fanstel BT832 and the BT832X (with no LNA turned on) have much better receive range than an Ebyte module. They are head and shoulders better. In turn the BT832X (again, even with no LNA turned on) has a noticeably better receive range than the BT832.
So, at this point, I'm sold on the Fanstel modules for the most common uses. The Fanstel modules also have a smaller footprint than the Ebyte modules. The Ebyte modules might be better for those cases where you need a lot of easily accessible pins to do something, but that's about it I think.
Now we need to convince Fanstel to find another shipping method outside the US
-
@NeverDie it looks like we found an ideal gateway.
What about the code they provide to activate PA+LNA?
Can it be used in mysensors?
-
I tried out the sub-dime sized BC832 on a quick port of the BC832X breakout board:
What I'm finding is that the Rx range for the BC832 is about the same as for the Ebyte nRF52832 module: I'm hard pressed to tell which is better than the other. The BC832 is nonetheless impressive, given how small its antenna is relative to the Ebyte antenna.
-
@Toyman said in nRF5 Bluetooth action!:
it looks like we found an ideal gateway.
Agreed.
@Toyman said in nRF5 Bluetooth action!:
What about the code they provide to activate PA+LNA?
I only extracted the needed info from their code to make it work. It works just fine with mysensors. For instance, here's mysensors code to activate the PA:
#define PA_PIN 17 #define CPS_PIN 6 #define LNA_PIN 19 myNrf5_pinMode(CPS_PIN,OUTPUT_H0H1); digitalWrite(CPS_PIN,HIGH); //disable. Active LOW //while (!(digitalRead(CPS_PIN)==HIGH)) {} //wait until confirmed myNrf5_pinMode(LNA_PIN,OUTPUT_H0H1); digitalWrite(PA_PIN,LOW); //disable. active HIGH //while (!(digitalRead(LNA_PIN)==LOW)) {} //wait until confirmed myNrf5_pinMode(PA_PIN,OUTPUT_H0H1); digitalWrite(PA_PIN,HIGH); //enable. active HIGH //while (!(digitalRead(PA_PIN)==HIGH)) {} //wait until confirmed //myNrf5_pinMode(CPS_PIN,OUTPUT_H0H1); digitalWrite(CPS_PIN,LOW); //enable. active LOW //while (!(digitalRead(CPS_PIN)==LOW)) {} //wait until confirmedI've tested it, and it works. From my testing it appears that the pins are write-only (which is why the while loops are now commented out).
-
@Nca78 How about sending a email to the company and ask if there is a distributor / Rep in your area?
Dr. Yuan Fan
Fanstel Corp.
Trusted Name Since 1990
7466 E. Monte Cristo Ave., Scottsdale AZ 85260 USA
Tel. 1480-948-4928 x101;
email: yfan@fanstel.com http://www.fanstel.com
-
@Toyman said in nRF5 Bluetooth action!:
it looks like we found an ideal gateway.
Yup, here's my gateway:
https://www.openhardware.io/view/491/PA-LNA-nRF52832-ESP-LINK-Shield-for-Wemos-D1-Mini-ESP8266
-
@Toyman Have you received your Fanstels yet? I'd like to compare notes with someone on the LNA part of it.
-
@NeverDie I haven't ordered yet. Waiting for my paycheck.
-
When you combine my BT832XE gateway with the LNA on this external "booster," the result is really great reception range, even at 2Mbps:
I think this combo will be hard to beat. In fact, I can receive even from nRF24L01's that are far away (further away than a nRF24L01 with PA+LNA can receive).
-
Well my NRF51822 has been running 25days approx sending every 60secs on a cr2032.
No signs of problems yet.
-
@rmtucker I don't recall whether you already have, but would you mind posting a photo of your node?
-
@NeverDie
Its just the waveshare ble400 board but i have cut one of the tracks to prevent the residual drain from the on board regulator.
And i have an external cr2032 battery holder feeding it.
I would love to make a small pcb for the NRF core to plug in to instead of the big motherboard as below, but i failed dismally at the design side of things.
-
@rmtucker said in nRF5 Bluetooth action!:
I would love to make a small pcb for the NRF core to plug in to instead of the big motherboard as below
Here you go: https://www.openhardware.io/view/510/Button-cell-Temperature-Humidity-sensor#tabs-bom
This should be even smaller and less expensive than what you wished for. I made it for the Si7021 because I had some extras laying around. The BME280 would also be a good choice.
-
@NeverDie
That would be perfect but i would have to order everything from china.
Well maybe not the led and resistor.
I also prefer the si7021 also it has far less consumption and quite accurate.
-
@rmtucker said in nRF5 Bluetooth action!:
I also prefer the si7021 also it has far less consumption and quite accurate
As long as the humidity is less than 80%. Otherwise, you need to turn on its "heater" to avoid permanently ruining its humidity accuracy.
-
@NeverDie it's not that quick, it happened only to the one I put in bathroom with very high humidity for a long time.
Other sensors reached over 90% humidity sometimes and spent many days in the 75-85 range but just a nightly use of aircon seems to have maintained their hability to measure humidity.
So my feeling is unless you are in a very humid environment you should have no problem with the si7021.I'm in a tropical country and problem happened during rainy season, >80% humidity at 30°C makes a lot of humity in the air, I don't think you get close to that level in European countries or most of the US.
-
@Nca78 I'm just taking what the datasheet says at face value. In practical terms, I think it's fairly rare to see >80% humidity in an indoor "conditioned space" (well, maybe a bathroom is an exception to that sweeping generality) but outdoors it happens by definition anytime the air temperature approaches the dew point. That certainly does occur in quite a lot of geographies.
So, for that reason, I think of the si7021 as more of an indoor TH sensor. From what I can tell, the BME280 doesn't have this issue, so it would therefore seem to be a good choice for outdoors.
Of course, the si7021 sensor modules are made in Asia, and if it's tropical asia (Thailand for instance?), it may have already been exposed to high humidity. So, that's a bit of an unknown factor hanging in the background.
Anyhow, thanks for the additional insight that maybe the si7021 really needs to soak in high humidity for a long time before it gets ruined. Otherwise, it can spring back from brief exposures. I certainly hope that's the case. Running its heater does consume a significant amount of current.
-
It turns out that on the nRF52832, pins 9 and 10 are assigned to NFC by default. The following code allows them to behave "almost" like regular GPIO pins:
//Make pins 9 and 10 usable as GPIO pins. NRF_NFCT->TASKS_DISABLE=1; //disable NFC NRF_NVMC->CONFIG=1; // Write enable the UICR NRF_UICR->NFCPINS=0; //Make pins 9 and 10 usable as GPIO pins. NRF_NVMC->CONFIG=0; // Put the UICR back into read-only mode.Well, good enough for a blink demo anyway.
-
Is there some particular trick to reading the built-in temperature sensor? I've tried it a number of ways, but after doingNRF_TEMP->TASKS_STARTI can never get NRF_TEMP->DATARDY to return true, no matter how long I wait. If I just try reading NRF_TEMP->TEMP anyway, it always returns zero.[Edit: Nevermind. The answer was right in front of me. It obviously should have been:
NRF_TEMP->TASKS_START=1;Because the PPI uses the former syntax, and the regular code uses the later syntax for the same thing, I sometimes interchange the syntax by mistake.
Anyhow, problem solved.
-
-
@NeverDie said in nRF5 Bluetooth action!:
@rmtucker said in nRF5 Bluetooth action!:
I would love to make a small pcb for the NRF core to plug in to instead of the big motherboard as below
Here you go: https://www.openhardware.io/view/510/Button-cell-Temperature-Humidity-sensor#tabs-bom
This should be even smaller and less expensive than what you wished for. I made it for the Si7021 because I had some extras laying around. The BME280 would also be a good choice.
I'm realizing now that I can get a decent temperature reading from just the nRF5x chip itself. With calibration it should get even better.
-
Today I finally received the PTR9618PA that I ordered a while back:
Like the Fanstel modules, it lacks a 32.768Khz crystal oscillator. Also, as you can see from the second photo, the PA/LNA chip is the 2401C: http://www.skyworksinc.com/Product/3213/RFX2401C
-
@NeverDie said in nRF5 Bluetooth action!:
@NeverDie said in nRF5 Bluetooth action!:
I'm realizing now that I can get a decent temperature reading from just the nRF5x chip itself. With calibration it should get even better.
I used the internal temperature in the past but i can not remember how i did it?
Do you have some example code to remind me?
-
@rmtucker said in nRF5 Bluetooth action!:
Do you have some example code to remind me?
/* * This example sketch shows how you can manage the nRF5 pin mapping as part of your code. * You can use the method for any nRF51822 or nRF52832 board or module. * * Most components, like UART, SPI, Wire Bus, of the nRF5 series chips don't * have a fixed pin mapping. There are some pins with restrictions like analog * inputs, NFC or pins near the radio module. Please refer the latest * documentation about pin restrictions at http://infocenter.nordicsemi.com * * To use the custom pin mapping you have to do following steps: * * 1. Install "arduino-nrf5" like described at * https://github.com/sandeepmistry/arduino-nRF5/ * 2. Install the "My Sensors nRF5 Boards" with the board manager like * explained at https://github.com/mysensors/ArduinoBoards * 3. Copy the files "MyNRF5Board.cpp" and "MyNRF5Board.h" from * "MyNRF5Board" example into your sketch. * 4. Modify pin mappings in "MyNRF5Board.cpp" and "MyNRF5Board.h" to fit * your requirements. * 5. Select "MyNRF5Board nrf52832" or "MyNRF5Board nrf52822" as your board. * Choose the correct parameters and programmer in the Tools menu. */ // Many thanks to d00616 for this framework! //------------------------------------------------------------------------------------------------------------------------------------------------------------------------ //Simple program to demonstrate that both the LED and Serial and Temperature are working correctly on the breakout board: // https://www.openhardware.io/view/471/Ebyte-nRF52832-Small-Breakout-Board //Note: Compile and upload from Arduino IDE using "MyNRF5Board nRF51822" as the board and with 16K RAM, RC Oscillator, and no bootloader as the options. // #define MY_CORE_ONLY #include <nrf.h> #include <MySensors.h> void setup() { hwPinMode(LED_BUILTIN,OUTPUT_D0H1); digitalWrite(LED_BUILTIN,HIGH); NRF_CLOCK->INTENSET=B11; //enable interrupts for EVENTS_HFCLKSTARTED and EVENTS_LFCLKSTARTED Serial.begin(9600); Serial.println(); Serial.println("Starting..."); NRF_CLOCK->TASKS_HFCLKSTART=1; //start the high frequency crystal oscillator clock while (!(NRF_CLOCK->EVENTS_HFCLKSTARTED)) {} //wait until high frequency crystal oscillator clock is up to speed and working NRF_TEMP->TASKS_STOP; NRF_TEMP->EVENTS_DATARDY=0; NRF_TEMP->INTENSET=1; //enable EVENTS_DATARDY temperature interrupt while (!(NRF_TEMP->INTENSET==1)) {} //wait until completed } uint32_t blinkCounter=0; uint32_t rawTemperature=0; float celsius=0.0; //rawTemperature converted to Celsius void loop() { NRF_TEMP->TASKS_START=1; while (!(NRF_TEMP->EVENTS_DATARDY)) {} //wait until temperature measurement is complete rawTemperature=NRF_TEMP->TEMP; celsius=((float)rawTemperature)/4.0; Serial.print(celsius); Serial.println(" degrees Celsius"); Serial.print(blinkCounter++); Serial.println(", HIGH"); digitalWrite(LED_BUILTIN,HIGH); delay(500); Serial.print(blinkCounter++); Serial.println(", LOW"); digitalWrite(LED_BUILTIN,LOW); delay(500); }
-
I made a prototype of my CR2032 buttoncell project using the earlier small nRF51822-4 beakout board. I have it running the MySensors passive sensor code. It reports to the serial gatewaqy once every minute.
-
cool.
you could add some clearance for the antenna, better I think for antenna radiation.
-
@scalz said in nRF5 Bluetooth action!:
you could add some clearance for the antenna, better I think for antenna radiation.
OK, I adjusted it. How about now?
-
I dont have access to the source code now. Can someone please tell which pins are configured as Tx and Rx for serial communication ?
-
@ahmedadelhosni Do you mean in general? In the general case, you can select which pins are meant for Rx and Tx using your software.
-
Yes I read this from the datasheet but I thought maybe MySensors defines some Pins for debugging.
How can I set them ? Any ApI refrences ?
-
@ahmedadelhosni said in nRF5 Bluetooth action!:
Yes I read this from the datasheet but I thought maybe MySensors defines some Pins for debugging.
How can I set them ? Any ApI refrences ?
Look at the source code posted at https://www.openhardware.io/view/510/CR2032-Small-Wireless-Temperature-Humidity-Sensor#tabs-source
It will be obvious from that.
-
@ahmedadelhosni said in nRF5 Bluetooth action!:
Yes I read this from the datasheet but I thought maybe MySensors defines some Pins for debugging.
How can I set them ? Any ApI refrences ?Most NRF5 pins are freely configurable. MySensors only uses the definition of the Arduino variant. If you are not lucky with the pins defined with the Arduino board variants, you can use the ArduinoHwNRF5 board. There are examples to redefine pins.
This repository has the release 0.1.0 its usable and stable, but I have plans to rename the files to MyBoardNRF5 and change the g_ADigitalPinMap to the more flexible Arduino primo format in the near future. I think this is required to support NRF52840 MCUs in the future.
-
Thanks both for the guiding. I will look through them.
-
@NeverDie how is the battery voltage doing on your existing test node ?
I think you should include a strong capacitor to help the battery during TX/RX sequences. It's probably less necessary on NRF5 boards, but on atmega+nrf24 a board without a 100-200µF (meaning only around half of that available with a 3V bias) capacitor has a very poor battery life.
-
@Nca78 said in nRF5 Bluetooth action!:
@NeverDie how is the battery voltage doing on your existing test node ?
I think you should include a strong capacitor to help the battery during TX/RX sequences. It's probably less necessary on NRF5 boards, but on atmega+nrf24 a board without a 100-200µF (meaning only around half of that available with a 3V bias) capacitor has a very poor battery life.No real data as of yet, though I haven't noticed any problems per se. What size capacitor do you recommend?
Here's why I was hoping I could maybe sidestep the issue:
http://data.energizer.com/pdfs/cr2032.pdf
i.e. very short pulses might have stable voltage. I'm not sure what amount of current is assumed by that Energizer graph though.
-
@d00616 said in nRF5 Bluetooth action!:
I think this is required to support NRF52840 MCUs in the future.Again, you've done a nice a work on ESB driver
At least we can confirm that nrf52840 works with regular variant boards, and basic MySensors features, as it was a part of an intense traffic setup yesterday.That's the proof MySensors is getting better week after week
-
@NeverDie
I would use 100 to 200uf like said above. That's what i'm doing with all my coincell nodes too.
This is regarding the internal resistance of coincells which is not great >5mA, especially when coincell will be more aged. So it is recommanded to increase lifetime.But not too strong capacitor value, else that won't be better (you don't want to waste energy, and increase internal coincell res, by charging caps, else you would need a current limiting resistor lol).
I would not be too cheap by omitting decoupling and buffering capa, on my boards I prefer to have footprints (optional or not) because sure it can work well at the beginning but as soon as lifetime goes, it can change..
-
Thank you @nca78 and @scalz . Per your suggestions, I added a 100uF ceramic cap to version 8 of the multi-sensor board:
https://www.openhardware.io/view/510/Multi-Sensor-TempHumidity-LeakMagnetLightAccel
-
Anyone tried building a bluetooth stack on the nRF5x from within the Arduino IDE? I can see how running it simultaneously with the mySensors code would be tricky, but maybe one could switch back and forth between the two? e.g. if you want to output debug text to a terminal window on your smart phone via bluetooth If so, anyone have any demo code for doing that?
For that matter, has anyone here tried the Arduino Primo? And if so, how did it go?
-
@NeverDie said in nRF5 Bluetooth action!:
Anyone tried building a bluetooth stack on the nRF5x from within the Arduino IDE? I can see how running it simultaneously with the mySensors code would be tricky, but maybe one could switch back and forth between the two?
From what I understand this is not possible, the NRF5 Core used by @d00616 is not using the soft device to have better access to the hardware, while the Arduino IDE version is using soft device to run bluetooth stack. So you have to flash one or the other, not the two at the same time.
-
@NeverDie said in nRF5 Bluetooth action!:
Anyone tried building a bluetooth stack on the nRF5x from within the Arduino IDE? I can see how running it simultaneously with the mySensors code would be tricky, but maybe one could switch back and forth between the two? e.g. if you want to output debug text to a terminal window on your smart phone via bluetooth If so, anyone have any demo code for doing that?
The parts of the SDK to disable and enable the SoftDevice are not included into the arduino-nrf5 port, but on the Primo port.
For that matter, has anyone here tried the Arduino Primo? And if so, how did it go?
The Arduino-NVM library is not compatible. This results in a crash. My first try to use the SoftDevice API was not successful.
-
@d00616 have you looked at https://mynewt.apache.org/?
-
@Toyman said in nRF5 Bluetooth action!:
@d00616 have you looked at https://mynewt.apache.org/?
Does it have any worthwhile demo apps running on it?
-
@Toyman said in nRF5 Bluetooth action!:
@d00616 have you looked at https://mynewt.apache.org/
Yes, I have seen the documentation and some parts of the source code. It's a good project. I like the concepts.
-
@Toyman said in nRF5 Bluetooth action!:
@d00616 have you looked at https://mynewt.apache.org/?
on my side, i tested it. agree with d00616, it's interesting.
yes there are examples.
-
How would you all rate the mynewt's stage of development? Pre-alpha? Or, is it already fairly well tested and production ready?
-
latest release is 1.2.0, it's not prealpha. for production I think, easiest is to read docs and try
Note it's an OS (which means shared resources etc..), not arduino integrated, nor mysensors compatible actually. If you want to use MySensors, you would need to port the code and check what's in use by the OS etc..
If I would like to use a RTOS+BLE with NRF5, I would use this one.
For other mcus, not sure, there are others nice OS.
Hard to find one fits for all, and not very handy to have x toolchains&libraries to handle (I already have arduino, espressif, apache, TI.. OS&frameworks installed and this can be too much!). And i don't mention rpi/linux stuff..That depends on the project.
But for my HA project, as MySensors targets arduino actually, and I prefer the NRF5 ESB driver than BLE for multiple reasons (security etc), it's easier to stick to arduino environment and I can use all mcus for that in Visual Studio.
-
How are people here preferring to connect to their nRF5x node for programming/debugging? I had been using a 10-pin IDE boxed connector on the PCB's I was making, but I just recently tried a micro-USB OTG connector (just as a 5-pin connector, not for anything truly USB protocol related), and I find that I like it a lot. For one thing, it's a lot more compact:
It does require making an adapter, but once you've made it (once and done), it's easy.
Any thoughts on this? I'm tentatively leaning toward switching over to it for everything.
-
The other cool thing is that the side access allows me to make a very compact PIR motion sensor that's still re-programmable:
-
@NeverDie I think it's ok only if you keep those only for yourself, and/or make an enclosure hiding this plug.
Because if you give to someone like a friend and an USB plug is visible one day or another they'll plug it and fry the board with 5V
-
Good point. To avoid that as a potential problem then, can anyone suggest a better connector to use?
-
I suppose if/when OTA updates are developed for the nRF5x's, then the issue would go away. Then you'd only need the connector when first setting it up, and then later work could be uploaded OTA. After the initial setup, one could simply sabotage the USB connector (fill it with epoxy maybe, or perhaps just cut the traces) to prevent the friend from plugging the node into an actual USB charger or the like.
-
I'd say to make something with pogo pins if you really need it once
-
@NeverDie check out a product called "TAG-CONNECT". It is perfect for programming. It is used on the Nordic Semiconductor Beacon Reference Design.
-
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie check out a product called "TAG-CONNECT". It is perfect for programming. It is used on the Nordic Semiconductor Beacon Reference Design.
Thank you. Here is an programmer with this connector: http://aconno.de/acnprog/
I don't know if this is compatible to the Beacon Reference Design, but its compatible with the nRF52 boards provided by aconno.
-
@d00616 not familiar with the USB interface / tag connect. The ones I have used have the connector type that plugs onto the nRF5x-DK, uLinks, jlink lite, etc. a ten pin Micro Cortex connector to six or ten pin "pogo pin" tag-connect connector. There is also a clip that allows the connector to stay attached for debugging purposes.
-
A bit off-topic perhaps, but does anyone here happen to know what kind of switch Enocean uses to transduce a button press into the electrical energy needed to send a packet? I'm guessing it's some kind of piezo switch. Can just that transducer part be purchased by itself? I'm wondering whether the same trick can be done using an nRF5...
-
I would stick with cortex 10-pin connector. Mostly because it's (a) standard (b) a cable can be made without soldering by using IDC connectors and a ribbon cable.
The only downside is height.
Using USB connector for sometging that's not USB is generally a bad idea as it's not foolproof
-
Is signing soft supported or not yet ?
The personalizer sketch do not have hash define for the NRF52.
-
@ahmedadelhosni pull requests are always welcome.
-
@ahmedadelhosni said in nRF5 Bluetooth action!:
Is signing soft supported or not yet ?
The personalizer sketch do not have hash define for the NRF52.The security personalizer is working with the NRF5X. Random numbers for the Soft Signing are generated with the internal AES hardware, seeded with the hardware number generator. This allows a fast and secure nonce generation.
At the Moment the NRF5 with Soft Signing is not at the same level like the ATSHA204, because the read back protection is not enabled. If you want to do this, you have to add some code.
-
What else should I turn-off to save power during sleep?
Presently, I turn-off these things: the radio, NFC, the high frequency clock, and uarte, Meanwhile, the low frequency clock is working.
Presently getting a sleep current drain of apprxoimately 2.8 microamps.
-
@NeverDie said in nRF5 Bluetooth action!:
What else should I turn-off to save power during sleep?
Presently, I turn-off these things: the radio, NFC, the high frequency clock, and uarte, Meanwhile, the low frequency clock is working.
Presently getting a sleep current drain of apprxoimately 2.8 microamps.
Which chip are you talking about ?
-
nRF52832. I'm guessing the same will apply to the nRF51822, except for the NFC (which the nRF51822 doesn't have).
-
I should probably add that the 2.8ua is with the RTC and LPCOMP running. So, maybe it's already as low as it can go, I don't know. Just wondering if there are any other obvious suspects I should try turning off. I'll try i2C and SPI to see if it makes a difference... Not sure, but maybe SPI gets initialized through the header file without my even being aware of it.
-
Well, it could be within the bounds of measurement error, but it appears that dropping I2c and SPI has reduced the drain to 2.6ua.
-
@NeverDie said in nRF5 Bluetooth action!:
Well, it could be within the bounds of measurement error, but it appears that dropping I2c and SPI has reduced the drain to 2.6ua.
Is I2C or SPI used somewhere in your code?
-
@d00616 said in nRF5 Bluetooth action!:
@NeverDie said in nRF5 Bluetooth action!:
Well, it could be within the bounds of measurement error, but it appears that dropping I2c and SPI has reduced the drain to 2.6ua.
Is I2C or SPI used somewhere in your code?
Not in the current test code that I'm running.
-
@NeverDie said in nRF5 Bluetooth action!:
Not in the current test code that I'm running.
Interesting. The SPI is rated with <1µA idle current. TWI has no idle current in the datasheet.
