nRF5 action!
-
@Jokgi said in nRF5 Bluetooth action!:
@NeverDie Hello, If you are referring to that Prototype Board with the Nordic logo on it then it was being controlled by GPIO and by the Bluetooth Low Energy stack (Softdevice) You can read more about it here.. https://devzone.nordicsemi.com/blogs/831/palna-support-in-s132/.
As I mentioned before. there is no good way to control the PA in a proprietary mode, only when using BLE. Regardless, I have asked if it is ok to share the schematic that relates to that PA board and I will let you all know. And about the question about antenna switching. This was never implemented in the Softdevice. Any antenna switching would need to be done in the application.
See if this chart helps.
The only definition I've found for PDET is "Analog Voltage Proportional to the PA Power Output ." I'm not sure what that means. So, I set P0.02 to HIGH, which in this instance is 3.3v. However, I'm only getting relatively weak Tx power emitted. Is there anything else I should be doing? For instance, should I be supplying external voltage to the PDET pin directly?
Here's the code I'm currently using to setup for transmission:
myNrf5_pinMode(2,OUTPUT_H0H1); //PDET myNrf5_pinMode(20,OUTPUT_H0H1); //SWANT myNrf5_pinMode(24,OUTPUT_H0H1); //TXEN myNrf5_pinMode(23,OUTPUT_H0H1); //RXEN myNrf5_pinMode(22,OUTPUT_H0H1); //MODE digitalWrite(20,HIGH); //select one of the antenna's. digitalWrite(23,LOW); //disable RXEN digitalWrite(24,HIGH); //enable TXEN digitalWrite(22,LOW); //disable MODE digitalWrite(2,HIGH); //set the analog voltage for PDET as high as possible@NeverDie said in nRF5 Bluetooth action!:
For instance, should I be supplying external voltage to the PDET pin directly?
I tried that just now, and it made no difference.
I also tried powering the PA_VDD pin externally at 3.3v, and that didn't help either. Does that pin expect higher voltages?
-
@NeverDie 0_1508367805179_RD-nRF52-RFX2411N-REV2.zip Hello All -- For your viewing enjoyment. The Schematic and layout files for that nRF52840 and RFX2411n board you have. (If it is version 2 which did have the big Nordic logo on it. )
I think you may know this already but this bears repeating. This is not a Nordic board. Nordic Semiconductor's tech support will probably not know anything about this board. Also there is a difference between the RFX2411 and the nRF2411N. (N for Nordic) It is not the same device.@Jokgi said in nRF5 Bluetooth action!:
@NeverDie 0_1508367805179_RD-nRF52-RFX2411N-REV2.zip Hello All -- For your viewing enjoyment. The Schematic and layout files for that nRF52840 and RFX2411n board you have. (If it is version 2 which did have the big Nordic logo on it. )
I think you may know this already but this bears repeating. This is not a Nordic board. Nordic Semiconductor's tech support will probably not know anything about this board. Also there is a difference between the RFX2411 and the nRF2411N. (N for Nordic) It is not the same device.Just now noticed that the schematic explains PDET. It's "Optional Antenna Power Monitoring." So, I take that to mean that it's output from the board, not input to it.
Also, the schematic indicates that the board has the DCDC inductors built into it, so that's good.
-
Aha! Apparently the RFaxis defaults not to the trace antenna on the board, but rather to the external, connected antenna. So, I hooked that up, and now it's working like a champ. I can now safely say that it definitely has a much better range than a non-PA nRF52832 module. And, of course, I'm running it at 2mbps. :)
The other nice thing is that even if I transmit continuously (i.e. 100% duty Tx cycle), the chips don't get hot. I'm impressed. I tried doing that with a LoRa module once, and it got too hot to even touch.
It will be fun to check the range when there's a PA+LNA nRF52832 on both ends of the link.
-
And here it is:

-
Of course, I couldn't stop until I tried hooking it up to the 4w boost amplifier:

Wow! That really kicks tail. I don't think there's a nook or cranny anywhere that I don't get a great signal now, and all from a single gateway. :) -
I just now ordered a number of Fanstel modules to go with the breakout boards I recently posted. It's worth noting that Fanstel's lowest cost nRF52832 module is only $3.75, which is lower than the Ebyte module: http://www.fanstel.com/buy/bt832-ble42-hardware-ready-for-bluetooth-5-module-2fhya
I ordered one, and I'll see how it compares in actual use. -
I just now ordered a number of Fanstel modules to go with the breakout boards I recently posted. It's worth noting that Fanstel's lowest cost nRF52832 module is only $3.75, which is lower than the Ebyte module: http://www.fanstel.com/buy/bt832-ble42-hardware-ready-for-bluetooth-5-module-2fhya
I ordered one, and I'll see how it compares in actual use.@NeverDie said in nRF5 Bluetooth action!:
It's worth noting that Fanstel's lowest cost nRF52832 module is only $3.75, which is lower than the Ebyte module: http://www.fanstel.com/buy/bt832-ble42-hardware-ready-for-bluetooth-5-module-2fhya
interesting for US customers only I think. Because last time I looked, shipping were too expensive (plus add extra shipping fee like customs etc.).
-
I just now ordered a number of Fanstel modules to go with the breakout boards I recently posted. It's worth noting that Fanstel's lowest cost nRF52832 module is only $3.75, which is lower than the Ebyte module: http://www.fanstel.com/buy/bt832-ble42-hardware-ready-for-bluetooth-5-module-2fhya
I ordered one, and I'll see how it compares in actual use.@NeverDie said in nRF5 Bluetooth action!:
It's worth noting that Fanstel's lowest cost nRF52832 module is only $3.75, which is lower than the Ebyte module: http://www.fanstel.com/buy/bt832-ble42-hardware-ready-for-bluetooth-5-module-2fhya
I ordered one, and I'll see how it compares in actual use.
It's woth noting that despite it's "832" name it's in fact an nrf52810 :P@scalz said in nRF5 Bluetooth action!:
interesting for US customers only I think. Because last time I looked, shipping were too expensive (plus add extra shipping fee like customs etc.).
43$ shipping if you're not in the US. And with DHL meaning (at least for me) 10 extra dollars of DHL fee for custom processing + highest tax possible. -
What are the pin assignments when you have one linear list of pin names next to a double row of pins? In this case: https://www.aliexpress.com/item-img/NRF51822-pa-Bluetooth-module-external-antenna-module-column-industrial-self-timer-heart-rate-meter/32815682890.html?spm=2114.10010108.1000017.2.35e823afSFYACg
-
@NeverDie said in nRF5 Bluetooth action!:
It's worth noting that Fanstel's lowest cost nRF52832 module is only $3.75, which is lower than the Ebyte module: http://www.fanstel.com/buy/bt832-ble42-hardware-ready-for-bluetooth-5-module-2fhya
I ordered one, and I'll see how it compares in actual use.
It's woth noting that despite it's "832" name it's in fact an nrf52810 :P@scalz said in nRF5 Bluetooth action!:
interesting for US customers only I think. Because last time I looked, shipping were too expensive (plus add extra shipping fee like customs etc.).
43$ shipping if you're not in the US. And with DHL meaning (at least for me) 10 extra dollars of DHL fee for custom processing + highest tax possible.It's too bad Fanstel's shipping rates outside the US are high. I received the modules I ordered from Fanstel in just a couple of days. I'll try them out after I receive the PCB's from OSH PARK, which should happen in about another 1-2 weeks. The pinout for Fanstel's "micro" version (BC832) is different, and obviously the land pattern is much smaller, so I just now did a separate breakout board for it and sent it to the fab.
I'm trying to think now as to whether I'll have any future need for nRF24L01's. The very small and cheap nRF51822 seems to supplant it now with its 4dbm higher Tx power, and the nRF52 affords lower current consumption while in Tx or Rx, because of its DCDC option.
-
@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. This is just a simple example to explain what I mean by the question.
-
It's too bad Fanstel's shipping rates outside the US are high. I received the modules I ordered from Fanstel in just a couple of days. I'll try them out after I receive the PCB's from OSH PARK, which should happen in about another 1-2 weeks. The pinout for Fanstel's "micro" version (BC832) is different, and obviously the land pattern is much smaller, so I just now did a separate breakout board for it and sent it to the fab.
I'm trying to think now as to whether I'll have any future need for nRF24L01's. The very small and cheap nRF51822 seems to supplant it now with its 4dbm higher Tx power, and the nRF52 affords lower current consumption while in Tx or Rx, because of its DCDC option.
@NeverDie said in nRF5 Bluetooth action!:
It's too bad Fanstel's shipping rates outside the US are high
No issue for me as I am a using a mail forwarder(s) and I can highly recommend them to others. Bringing nrf52Dk from Arrow to Russia costed me $10 (inter-US shipping is free at Arrow).
I am considering switching to Fanstel modules completely, especially to their PA+LNA ones -
@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. This is just a simple example to explain what I mean by the question.
@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.
-
@NeverDie said in nRF5 Bluetooth action!:
It's too bad Fanstel's shipping rates outside the US are high
No issue for me as I am a using a mail forwarder(s) and I can highly recommend them to others. Bringing nrf52Dk from Arrow to Russia costed me $10 (inter-US shipping is free at Arrow).
I am considering switching to Fanstel modules completely, especially to their PA+LNA ones@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.
-
@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. -
-
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. 😏
-
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. -
@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.
@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; }} -
@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?