Everything nRF52840


  • Hero Member

    This thread is intended to be a collecting point for all information related to nRF52840.

    It turns out the nRF52840 dongle is very easy to solder with pin headers, and the format is breadboard friendly as well:
    0_1536863999498_nrf52840_dongle.jpg


  • Hardware Contributor

    This is looking really nice, both for breadboard and for sensors, you just need pads to solder the castellated pin on. I hope it will have more availability soon to play a bit with it.


  • Hero Member

    I did an nRF52840 drop-in upgrade to the BT840F module and was able to program it to transmit. It works!
    0_1536933335150_bt840F_upgrade.jpg


  • Hero Member

    Here's a size comparison of the nRF52840 BT840F to the BT832X (an amplified nRF52832).

    0_1536938575908_size_comparison.jpg

    I'm not aware of any amplified nRF52840 modules, but I would, of course, be interested if there are any.


  • Hero Member

    It appears that at present the mbed compiler doesn't yet recognize the P1.xx pins of the nRF52840, but only the P0.xx pins. Not good! I'll try to find out whether mbed intends to fix that or not.



  • Could you explain a bit what's so cool about this new chip?

    Does it work as a USB stick that you just place a .hex file on to program it? Like the Micro:bit?
    Can you run it, as well as some connected sensors, just by plugging it into a usb charger? Like a Arduino Nano?


  • Hero Member

    @alowhum yes to all the questions.

    You don't have to use usb, but it's built into the nRF52840 chip if you want to use it.

    As far as what's cool about it, well, that's a long list. Read the 1 page summary on page 1 of the datasheet. It packs a lot of punch into a small space and yet it's relatively low power.


  • Hero Member

    Here's some simple code for transmitting a 1 byte payload at 2mbps once every second:

    //This program sends a one byte payload in a packet once every second.
    #include "mbed.h"
    
    
    uint8_t txBuffer[200];  //buffer required for transmitting a payload.  
    uint8_t targetAddress[] = {0xAA, 0xDE, 0xAD, 0xBE, 0xEF};
    
    Serial pc(USBTX, USBRX); // tx, rx
    
    void initializeSerialOutput() {
    
      pc.baud (9600);
      pc.printf("Starting...\n");
    }
    
    void initializeHardware () { 
      NRF_POWER->DCDCEN=1;  //enable the DCDC voltage regulator 
    }
    
    void initializeClocks () {
        
      NRF_CLOCK->TASKS_HFCLKSTART=1;  //activate the high frequency crystal oscillator
      while (NRF_CLOCK->EVENTS_HFCLKSTARTED==0) {};  //wait until high frequency clock start is confirmed
    }
    
    void initializeRadio () {
      //No need to set the preamble.  For Nordic's proprietary radio modes, the preamble (either 0xAA or 0x55) is 1 byte long and is chosen by the hardware.  
      
      uint32_t theTargetBaseAddress;
      theTargetBaseAddress=(((uint32_t)targetAddress[1])<<24)|(((uint32_t)targetAddress[2])<<16)|(((uint32_t)targetAddress[3])<<8)|((uint32_t)targetAddress[4]);  //target base address
      pc.printf("The target address is 0x%X%lX\n",targetAddress[0],theTargetBaseAddress);
      NRF_RADIO->BASE0=theTargetBaseAddress;  //target base address
      NRF_RADIO->PREFIX0=targetAddress[0];   //target prefix address 
      
      NRF_RADIO->FREQUENCY=98; //2498Mhz.  value must be between 0 and 100
      NRF_RADIO->PCNF1 = 0x40101;  //Means: base address is 4 bytes long (possible range is 2 to 4) and max size of payload is 1,and 1 bytes of static length payload
      NRF_RADIO->PCNF0=0;  //S0,LENGTH, and S1 are all zero bits long.
      NRF_RADIO->MODE=1;  //set 2Mbps datarate.  
      NRF_RADIO->MODECNF0=1;  //enable fast ramp-up of radio from DISABLED state.
      NRF_RADIO->CRCCNF=3;  // CRC will be 3 bytes and is computed including the address field
      NRF_RADIO->PACKETPTR=(uint32_t)txBuffer;  //pointer to the payload in txBuffer
      NRF_RADIO->RXADDRESSES=1;  //receive on logical address 0.  Not important for transmitting.
      NRF_RADIO->TXPOWER=8;  //set to 8db transmit power, which is the maximum.
    
      NRF_RADIO->TASKS_DISABLE=1;  //DISABLE the radio to establish a known state.
      while (NRF_RADIO->STATE) {}; //wait until radio is DISABLED (i.e. STATE=0);
    
      NRF_RADIO->TASKS_TXEN=1;  //turn on the radio transmitter and shift into TXIDLE.
      while (!(NRF_RADIO->EVENTS_READY)) {}  //Busy-wait.  After event READY, radio shall be in state TXIDLE.
      
      NRF_RADIO->TASKS_START=1;  //Move from TXIDLE mode into TX mode.
    }
        
    
    int main() {
      initializeSerialOutput();
      initializeHardware();
      initializeClocks();
      initializeRadio();
    
      while (true) {
       
       if (NRF_RADIO->STATE!=11) { //if radio no longer in TX state, then it must have sent a packet
          wait_ms(1000);  //wait one second before sending next packet
       
          txBuffer[0]++;  //increment the payload value to send something different
          NRF_RADIO->TASKS_START=1;  //Move from TXIDLE mode into TX mode to transmit another packet
        }
      }
    }
    

  • Hero Member

    Here is the corresponding simple code for receiving each packet from the transmitter code above:

    //This program receives packets with a one byte payload.
    #include "mbed.h"
    
    uint8_t rxBuffer[200];  //required buffer for receiving packet
    uint8_t myAddress[] = {0xAA, 0xDE, 0xAD, 0xBE, 0xEF};
    
    Serial pc(USBTX, USBRX); // tx, rx
    
    void initializeSerialOutput() {
    
      pc.baud (9600);
      pc.printf("\n\nStarting...\n");
    }
    
    void initializeHardware () { 
      NRF_POWER->DCDCEN=1;  //enable the DCDC voltage regulator as the default. 
    }
    
    void initializeClocks () {
      NRF_CLOCK->TASKS_HFCLKSTART=1;  //activate the high frequency crystal oscillator
      while (NRF_CLOCK->EVENTS_HFCLKSTARTED==0) {};  //wait until high frequency clock start is confirmed
    }
    
    void initializeRadio () {
     //No need to set the preamble.  For Nordic's proprietary radio modes, the preamble (either 0xAA or 0x55) is 1 byte long and is chosen by the hardware.  
       
      uint32_t myBaseAddress;
      myBaseAddress=(((uint32_t)myAddress[1])<<24)|(((uint32_t)myAddress[2])<<16)|(((uint32_t)myAddress[3])<<8)|((uint32_t)myAddress[4]);  //target base address
      pc.printf("My address is 0x%X%lX\n",myAddress[0],myBaseAddress);
      NRF_RADIO->BASE0=myBaseAddress;  //target base address
      NRF_RADIO->PREFIX0=myAddress[0];   //target prefix address 
        
      NRF_RADIO->FREQUENCY=98; //2498Mhz.  value must be between 0 and 100
      NRF_RADIO->PCNF1 = 0x40101;  //Means: base address is 4 bytes long (possible range is 2 to 4) and max size of payload is 1,and 1 bytes of static length payload
      NRF_RADIO->PCNF0=0;  //S0,LENGTH, and S1 are all zero bits long.
      NRF_RADIO->MODE=1;  //set 2Mbps datarate.  
      NRF_RADIO->MODECNF0=1;  //enable fast ramp-up of radio from DISABLED state.
      NRF_RADIO->CRCCNF=3;  // CRC is is 3 bytes and is computed including the address field
      NRF_RADIO->PACKETPTR=(uint32_t)rxBuffer;  //put the received payload in rxBuffer
      NRF_RADIO->RXADDRESSES=1;  //receive on logical address 0
    
      NRF_RADIO->TASKS_DISABLE=1;  //sleep the radio
      while (NRF_RADIO->STATE) {}; //wait until radio is DISABLED (i.e. STATE=0);
     
      NRF_RADIO->TASKS_RXEN=1;  //turn on the radio receiver and enter into state RXIDLE
      while (!(NRF_RADIO->EVENTS_READY)) {}  //Busy-wait.  After event READY, radio shall be in state RXIDLE.
      
      NRF_RADIO->TASKS_START=1;  //Move from RXIDLE mode into RX mode.
    }
        
    
    int main() {
      initializeSerialOutput();
      initializeHardware();
      initializeClocks();
      initializeRadio();
    
      while (true) {  
        if (NRF_RADIO->STATE!=3) {// if radio no longer in RX state, it must have received a packet.
          pc.printf("Payload Received!  Payload=%d\n",rxBuffer[0]); 
    
          NRF_RADIO->TASKS_START=1;  //Move from RXIDLE mode into RX mode so as to receive the next packet
        }
      }
    }
    

    These two example demo codes should be enough to get anyone started on using the nRF52840. 🙂

    Indeed, it relies very little on mbed (just the printf's and the wait function), so you could easily move it to a different tool chain if you wanted to.



  • @neverdie I have ordered 10x nRF52832 and also 5x nRF52840. Two of theme are in the E73... modul which is not really easy to solder with it's additional pads in inner rows under the modul and the company has no plans to change it for private makers.

    I have ordered 2 but it looks like they have discontinued that or working on an upgrade?
    https://www.aliexpress.com/item/nRF52840-Bluetooth-5-0-240MHz-RF-Transceiver-CDSENET-E73-2G4M08S1C-8dbm-Ceramic-Antenna-BLE-4-2/32906661666.html?spm=a2g0s.9042311.0.0.50784c4dZJ6WSY

    I have seen the dongles but they are still quite expensive:
    https://www.aliexpress.com/item/NRF52840-Dongle-Original/32890524949.html?spm=2114.search0104.3.1.dfe53098heRtmA&ws_ab_test=searchweb0_0,searchweb201602_5_10065_10068_10547_10059_10548_10696_100031_5017615_10084_10083_10103_5017516_451_10618_452_10304_10307_5017416_10820_10821_10302_5017715,searchweb201603_60,ppcSwitch_4&algo_expid=c3e31797-40ab-4a13-b99e-df32e618cf5c-0&algo_pvid=c3e31797-40ab-4a13-b99e-df32e618cf5c&transAbTest=ae803_2&priceBeautifyAB=0

    This modul is also makers friendly and around 10-11us$ (4 pieces for around 40us$)
    https://www.aliexpress.com/item/New-product-NRF52840-Bluetooth-5-MESH-Bluetooth-low-power-module-ZIGBEE-GT840A01/32909273516.html?spm=2114.search0104.3.43.bf083dad4DLBft&ws_ab_test=searchweb0_0,searchweb201602_5_10065_10068_10547_10059_10548_10696_100031_5017615_10084_10083_10103_5017516_451_10618_452_10304_10307_5017416_10820_10821_10302_5017715,searchweb201603_60,ppcSwitch_4&algo_expid=2fb40cd9-604f-47a8-b9f1-61d13e35e3cd-6&algo_pvid=2fb40cd9-604f-47a8-b9f1-61d13e35e3cd&transAbTest=ae803_2&priceBeautifyAB=0
    0_1537102327744_77645b3c-f65e-48c8-ab21-9ade454a65d1-grafik.png

    I have also odered 3 nRF52840 dev boards from holyiot for 6us$ (which is quite ok).
    0_1537102018397_1f1e5b94-952b-4587-bc17-4fdce7ea3908-grafik.png
    0_1537102093205_e95dcd83-dcb1-46ad-8581-564e43181f21-grafik.png

    The question is, how far would be a reliable indoor distance which of course includes 3+ standard walls and how much difference is it compared to the nRF52832 (is the 840 really required)?
    And is/will there be a full protocoll support for BLE5.0 (or at least 4.2) or any other protocol which is good enoght to not require an additonal radio like LoRa?
    That would be great and very energy efficient for battery usage.

    At least it would solve my Flash/RAM problem for E-Paper (in comparison to the 328p) 🙂
    Looking forward to the progress of this device/thread.


  • Hero Member

    @heinzv Dongles cost just $10 each if you buy them through a regular Nordic retailer. I don't know where you live (I'm guessing Germany?), but if it's in Europe it should be easier to find a retailer who has them in stock. If you go to the Nordic dongle page and click buy, it will link you to a page with all the official online sellers. Easy.

    If you are concerned about range, then I would give #1 priority to picking a module which has a good antenna. Period. Full Stop. Read that again if you have to. Chip antennas are nicely compact, but they kill your range. The Nordic dongles seem to have pretty good range, so I think they are a good deal for $10.

    Nordic's answer to people who ask "what is the indoor range?" is basically, "buy it and try it yourself," because there are just too many variables to consider. So, $20 for two dongles, and you have your answer.

    It's my subjective impression that the indoor range on the nRF52840 at 1mbps or 2mbps may be roughly equal to an amplified nRF52832, such as the Fanstel BT832X. However, the nRF52840 can do a slower speed at 250kbps (using 802.11.15) that the nRF52832 can't do, and that should be able to have very noticeably longer range. I'm not at all sure about the 125Kbps long range that's only available through Bluetooth. I'm sure it's longer range, but Bluetooth seems not easy to program. Maybe a solution to that will be when someone does the inevitable module that can be controlled with simple AT commands. Better yet would be a highly simplified API to bluetooth.


  • Hardware Contributor

    @heinzv yes, for the moment sandeep nrf5 core is not using latest softdevice (still s132). I don't remember about mbed (I imagine they use latest) but mysensors is not on mbed.
    Sure, subghz is not comparable with 2.4ghz. Like NeverDie said, there are many variables. The dongle have nice range when plugged in computer, it can be different if soldered on a different custom pcb, or using different software etc. Another point, is 2.4ghz can be crowded, depends where you live (no problem I live in rural area) but living in appartment in big cities I can imagine it's less quiet (coexistence&placement of wifi routers, phones, range extender, ble, zigbee, proprietary modes, more&more devices, not synced, channels overlap->selectivity&blocking etc..). Lot of variables for the real range.

    That said I'm not surprised that NeverDie has fun playing with this dongle. it looks sexy (although I decided to stop using nrf5).
    cool! keep the good work @NeverDie 👍


  • Hero Member

    @scalz Which radio do you prefer?

    I'm still a big fan of LoRa. If @heinzv wants guaranteed range today, he should go with LoRa. Once we better understand how to do 802.11.15 on the nRF52840, maybe that will also be compelling. I just can't say for sure, as I haven't yet tried it.


  • Hardware Contributor

    @scalz said in Everything nRF52840:

    That said I'm not surprised that NeverDie has fun playing with this dongle. it looks sexy (although I decided to stop using nrf5).
    So, what do you use now ? @_@


  • Hardware Contributor

    I don't want to pollute this topic with another brand, or making people think it's a bad choice. Nrf5 is a nice arduino "compatible" mcu.
    That just depends (in my case especially) on the application you want to build, the features available in frameworks, BOM etc.
    @NeverDie I gave you hint in another thread 😉
    it's not arduino compatible (and imho not a loss 🙂 , except that needs to port some C sensors libs ). Same for mysensors, not compatible (at least not yet, but still some hope).


  • Hero Member

    You can also improve range with data whitening, though I'm not sure by how much. To enable it, substitute this line into the above code examples:

      NRF_RADIO->PCNF1 = 0x2040101;  //Means: data whitening enbled, base address is 4 bytes long (possible range is 2 to 4) and max size of payload is 1,and 1 bytes of static length payload
    
    

    Then the hardware handles it automatically.



  • @heinzv
    ST electronics has the dongle for 17 euros including shipping in the Netherlands/Europe.

    It's slowly getting cheaper on Aliexpress too. $25 here:
    https://www.aliexpress.com/item/nRF52840-Dongle-original-genuine/32922402227.html


  • Hero Member

    @heinzv said in Everything nRF52840:

    The question is, how far would be a reliable indoor distance which of course includes 3+ standard walls and how much difference is it compared to the nRF52832 (is the 840 really required)?

    I think the short answer is that yes, it should be able to get through 3+ standard walls. There is some directionality to these antennas, so that can be a factor. You may not succeed if you aim the trace antennas in opposite directions, for instance. Using an external omni antenna might make the setup easier.

    I think some of the claimed range for the nRF52840 is from coding gains added to the 125Kbps datarate. Without doing a lot of work, you might have to use bluetooth long-range to get those ranges. Not sure though.



  • @scalz you stopped because of what reason? And you did not want to tell why and what you're now using? It might be worth for us to know!
    So far I plan to use ESP32 for most projects and trying to use the ultra low power nRF52 for battery powered devices. For the RF ranges I need to find out what is best. BLE or LoRa with RFM95 are my favorites now.
    In a pure ESP environment ESPnow is also very good (we have tested it sucssfully within a 120m2 flat).
    I have no better ideas so other HW devices far, but I'm always open for better ideas.

    @NeverDie I'm not from Germany but from Austria 🙂 I'll do testing with the 15 modules I will get in the next 2 weeks. Regarding the indorr range: Of yourse I read all the statements also from Nordic. I thought you have already some practical experience.

    In the battery wall sensors, I can only use a small sizes antenna and the gateway will have a better antenna.
    So the typical distance in a flat is around 15m but through at least up to 3+ walls
    Of course most todays flats/houses have many bluetooth and WLAN devices around.
    But we need an appropriate mysensors radio/protocol library for the nRF52's. Any yes we can play around with lower data rates to extend the range based on the signal range and transmissison stability.

    Looking forward to your experience and inputs.


  • Hero Member

    Here's a simple sketch I wrote for the nRF52840-DONGLE that turns on, one at a time, each of the 4 programmable LED's on the dongle:

    #include "mbed.h"
    
    #define BITMASK_LED1 64 //pin P0.06
    #define BITMASK_LED2R  256 //PIN P0.08
    #define BITMASK_LED2G  512 //PIN P1.09
    #define BITMASK_LED2B  4096 //PIN P0.12
    
    
    int main() {
        NRF_P0->PIN_CNF[6]=0x701;  //Configure pin P0.6 as an output pin with high-drive '0' and disconnect '1'
        NRF_P0->PIN_CNF[8]=0x701;  //Configure pin P0.8 as an output pin with high-drive '0' and disconnect '1'
        NRF_P0->PIN_CNF[12]=0x701;  //Configure pin P0.12 as an output pin with high-drive '0' and disconnect '1'
        NRF_P1->PIN_CNF[9]=0x701;  //Configure pin P1.09 as an output pin with high-drive '0' and disconnect '1'         
        NRF_P0->DIR=BITMASK_LED1|BITMASK_LED2R|BITMASK_LED2B;  //Set LED's as output pins
        NRF_P1->DIR=BITMASK_LED2G;  //set LED2G as an output pin.
        
        while (true) {
          NRF_P0->OUT=BITMASK_LED2R|BITMASK_LED2B;  //turn-on LED1.  Turn-ff LED2R and LED2B.
          NRF_P1->OUT=BITMASK_LED2G;  //Turn off LED2G
          wait(0.5);  //wait 500ms
          NRF_P0->OUT=BITMASK_LED1|BITMASK_LED2B; //turn on LED2R and turn off LED1 and LED2B
          wait(0.5);  //wait 500ms            
          NRF_P0->OUT=BITMASK_LED1|BITMASK_LED2R;  //Turn on LED2B and turn off LED1 and LED2R.
          wait(0.5);  //wait 500ms
          NRF_P0->OUT=BITMASK_LED1|BITMASK_LED2R|BITMASK_LED2B;  //turn off LED1 and LED2R and LED2B.
          NRF_P1->OUT=0;  //Turn on LED2G
          wait(0.5);  //wait 500ms
        }
    }
    

    The dongle per se isn't supported by mbed, which is why I'm doing it purely as register manipulations. Therefore, the code is completely portable and would transfer to whatever toolchain that you're using. I guess I'll write some support functions to make doing this easier in the future.


  • Hero Member

    Good news. I just noticed that Fanstel will have a couple of amplified nRF52840, called the nRF52840X or nRF52840XE. They just aren't yet in production with them. At least to me, this will likely make a big difference in my level of satisfaction. Judging from the datasheet, it will have both a PA and an LNA, so even just having it on the gateway would be a worthwhile improvement.



  • @neverdie said in Everything nRF52840:

    nRF52840XE

    If BLE5 alone works sufficient, that would be great. Worst case, I will use the nRF52 with RFM95 for the battery devices and an ESP32 + RFM95 for the gateway.
    The new PCB's we plan with ranseyer will cover all possible combination and provides the mySX connector.


  • Hero Member

    Maybe by the time nRF52840X comes out (in 6 months to a year I'm guessing), maybe by then mbed will be fully supporting the nRF52840-DK. Or, maybe mbed never will. I need to find a tool chain different from mbed to adopt. I'm not sure whether mbed is nearly dead, slowly dying, or just slow, but I don't see a lot of activity on their forum given the vast scope of their projects. If they aren't on top of new developments,... it's just not a good sign. Also, I'm noticing that mbed comes with a large amount of code overhead (around 400Kbytes from what I've seen in my compilations on it), and although the nRF52840 can handle that and more...it seems strange given the small size of my test programs.

    So, I'm open to suggestions on an alternate toolchain, provided that it's up to date with respect to nRF52840.




  • Hero Member

    @heinzv said in Everything nRF52840:

    and what about that:
    https://os.mbed.com/platforms/Nordic-nRF52-DK/

    The mbed compiler doesn't seem to even recognize that there are new GPIO pins on the nRF52840 that don't exist on the nRF52832. For instance, P1.00, which is one of the pins on the Fanstel nRF52840 module. Plus, I'm not sure that printf works with anything other than USB. I've tried setting it to other pins, and it just hangs. I've written some custom code to do my own sserial communications over P1_00 (to handle a PCB backward compatability issue with the nRF52840 Fanstel modules), but if mbed is only half baked, it's not helping me like it should.

    Not sure about platform.io. Thanks for the lead. I'll look into it.



  • @neverdie take a look at platform.io, it supports al known SOC's. INstall it then from the Visual Studio Code IDE. Both together are a very professional IoT dev environment (also Web and other development).
    I was doing very complex development like ESPurna project build you would not like to do in the Arduino IDE.
    Let me know if you need further hints.
    VSC and Platform.IO includes not only all SOC HW families but also all kind of libraries you know from Arduino and it can also import Arduino project (*.INO Files).
    Give it a try and you will be suprrised once you get familar.
    It does also the flashing (upload), includes GIT nativly, has a command window, debugging etc etc.

    https://code.visualstudio.com/
    https://marketplace.visualstudio.com/items?itemName=platformio.platformio-ide
    https://marketplace.visualstudio.com/search?term=platform.io&target=VSCode&category=All categories&sortBy=Relevance

    Platforms: Atmel AVR, Atmel SAM, Espressif 32, Espressif 8266, Freescale Kinetis, Infineon XMC, Intel ARC32, Intel MCS-51 (8051), Lattice iCE40, Maxim 32, Microchip PIC32, Nordic nRF51, Nordic nRF52, NXP LPC, RISC-V, Samsung ARTIK, Silicon Labs EFM32, ST STM32, Teensy, TI MSP430, TI Tiva, WIZNet W7500

    Frameworks: Arduino, ARTIK SDK, CMSIS, Energia, ESP-IDF, libOpenCM3, mbed, Pumbaa, Simba, SPL, STM32Cube, WiringPi


  • Hardware Contributor

    @heinzv platformio is nice for supporting lot of SOCs. But I think it still rely on sandeep arduino or mbed for nrf5, so, not sure if it adds stuff to the frameworks.. (regarding boards mapping, softdevices, etc). that's what NeverDie is searching I think.. an environment which allows to use all features of the SOC that he buy, ideally with myensors but we still can wait 🙂
    regarding what you asked me previously, this is one of my reason. As missing core features is not what I'm calling fast/easy to market/production for smarter features!
    That, and nrf is 2.4ghz only (area here is 9000m², few outbuildings with thick walls too), so increase of BOM&layout when using multiple modules (not a big problem for a gw, less nice for nodes). I don't want to use lora too..



  • @scalz
    That is what I found at the nordic docu for development
    http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.gs%2Fdita%2Fgs%2Fgs.html&cp=1
    https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF52-DK
    They mention two dev environments

    • nRF5 Series: Developing with SEGGER Embedded Studio
    • nRF5 Series: Developing on Windows with ARM Keil MDK

    Platform.IO support description for nRF52
    framework-arduinonordicnrf5 Arduino Wiring-based Framework (Nordic NRF5 Core)
    framework-mbed mbed Framework
    tool-jlink SEGGER J-Link Software and Documentation Pack
    tool-nrfjprog nRF5x command line tool
    tool-openocd OpenOCD
    tool-sreccat Merging tool
    toolchain-gccarmnoneeabi gcc-arm-embedded

    So what MCU's and radio/transmission are you using then ... ?


  • Hero Member

    I don't see specific support in platformio for nRF52840. Also, it's support for nRF52 generally seems to rely on mbed:
    https://github.com/platformio/platform-nordicnrf52/tree/master/examples?utm_source=platformio&utm_medium=docs

    I suspect the only way to do this is to use Nordic's SDK and one of the tool chains that Nordic recognizes as working with it. I hope I can find one without a heavy learning curve. Either that or limp along with mbed, which is half baked but (so far) at least allows me to do direct registry manipulations. With mbed maybe it will turn out that the total amount of remedial code I have to write isn't huge. Not sure. I don't have much confidence in mbed's future though. I'm noticing that a lot of the posts on their forum go completely unanswered.

    Nordic, on the other hand, seems much better about answering posted questions (well, 5 days a week anyway. Forget about weekends).

    @heinzv We've come full circle on this. I previously posted a question on the Sandeep github as to whether it supported the nRF52840, and the answer was no, its SDK was too new, but that maybe I would have some success in programming it if I treated it like an nRF52832. https://github.com/sandeepmistry/arduino-nRF5/issues/310 Well, that's really no better than the current situation with mbed.

    The only other thing on the horizon might be miropython. Not sure if micropython is fully deterministic enough for microcontroller work (e.g. might it garbage collect in the middle of a critical loop?), but maybe it's worth a shot. "Blinka & her new pal the nRF52840" https://learn.adafruit.com/circuitpython-on-the-nrf52



  • @NeverDie have you also checked this from my previous 3 posts agao
    https://github.com/lpercifield/arduino-nRF5/tree/nrf52840

    this is a fork from sandeeps Arduino-NRF5 project which explicitly adds nRF52840 (that was the reason for the fork) where people have been waiting for (and probably sandeep has not announced a support soon).
    See also sandeeps respons to lpercifield's work
    https://github.com/sandeepmistry/arduino-nRF5/issues/70

    Softdevice in this project is at S132 and Nordic newest is S140 (full BLE5 stack). Don't know why is was not yet worked into and why there is not realy a big progress since 2 years.

    At least there is a project with nRF52 and LoRa (SX1276/RFM95) 🙂
    https://github.com/gluedig/nrf52-lora


  • Hero Member

    @heinzv Thanks for pointing that out. It sounds like lpercifield encountered the exact same problems as me, except two years earlier. But, then he hasn't touched his code in the 2 years afterward. Nordic's SDK has changed since then. I'm just not sure.

    I guess it's a question of whether these one person, piecemeal attempts are enough, or whether joining with a toolchain that has a lot more oomph behind it is preferable. I suspect the total amount of work involved is just too much for one person, in their spare time, to accomplish more than partial coverage. Again, not sure, but I can see what @scalz means.

    I don't think Nordic has any interest in Arduino IDE support per se. If anything, it probably means a costly support burden to them without revenues to support it. Instead, Nordic is clearly targeting big commercial buyers , like phone manufacturers or the like, who will buy millions of chips just to have the latest features/capabilities. So, with nothing to pay for it on the Arduino front, except maybe a tiny bit by Adafruit or Sparkfun, it's necessarily just a bunch of individual, ad hoc efforts, or so it seems to me. Those individuals will solve whatever matters to them personally, but leaving spotty coverage on everything else. It' is admittedly better than nothing. Maybe for what I'm doing it's good enough. More than a little frustrating though.


  • Hardware Contributor

    @NeverDie dilemma.
    maybe try: apache mynewt + plugin for visual studio code. that might pick your curiosity. I liked it when I tried. but you know.. 🤓

    or zephyr but I don't know much about it.
    of course, these advanced toolchains are less easy to get started than arduino (setup or coding details). needs to port some arduino libs when you need it (makes sense). You won't get proprietary rf stack like MySensors out of the box too. It'll be BLE based in this case.
    But you'll be able to use your mcu as you wish.

    I hope you'll like it, else do like me 😆


  • Hero Member

    You can also increase range by increasing the number of preamble bytes. Today I upgraded to using 4 preamble bytes. Beyond that it's likely diminishing returns.

    To do the same on the nRF52840, use:

      NRF_RADIO->PCNF0=0x02000000;  //4 pre-amble bytes.  S0,LENGTH, and S1 are all zero bits long.
    

    @heinzv Another factor in range is how high off the ground your radio nodes are. This can have a huge effect, due to multipath fading from the ground. According to the Fanstel datasheet, for instance, even going from half a meter off the ground to 1.5 meters off the ground can almost triple your range. So, at the very least, try to put your gateway up as high as you can.


  • Hardware Contributor

    @NeverDie
    exactly.
    with infos below, you have everything for estimating the range (maybe that can interest others people too):

    Lot of variables, which also make a FCC module to become non-FCC when soldered on a custom board; all certified modules pass tests regarding a specific manufacturer design&usecase, they cannot certify that people won't degrade RF and emit bad stuff, thus that become non-FCC. Applicable to all RF devices though, rf laws rules (even when changing antenna for better gain, or different shape, on wifi router, it breaks certif in theory).
    Like you said, better pick a good antenna sure! There are antenna which are resistant to detuning, but most of antennas like "coiled" wire, meandered pcb trace (cdebyte 52832 type), or ceramic antennas are easily detuned by pcb layout, or once it's enclosed, or close to objects (stacked boards, metals, hands etc). Then, they need to be rematched to get best range.
    Good to know and interesting stuff 😉


  • Hero Member

    Well, interestingly, I just now tried the BLE Long Range preamble, which is 10 reptetitions of 0x3C, and it really does seem to make a noticeable improvement in coverage/range/reliability. Obviously the extra repetitions help, but I think maybe (?) it's also partly because the 4 byte preamble is the one specified by 802.11.15, which is 4 bytes of all zeros (which is pretty weird. Never seen that as the preferred choice before. Usually preambles are alternating high low signals instead).

    To set the preamble to BLE Long Range, use:

     NRF_RADIO->PCNF0=0x03000000;  //10 preamble bytes.  S0,LENGTH, and S1 are all zero bits long.
    

    .


  • Hero Member



  • @neverdie why won't you use Nordic's native SDK with Eclipse? I found some tutorials how to set it up, so I guess it's an option.



  • @neverdie thanks for the info, I appreciate your effort and investigations. I'll use my gateway and the sensor nodes at least in 1,5m height from the ground.
    Today I got my nrF52832 and also the nRF52840. The E73..C modules are tiny (around 11x16mm). I can't use it without a breakout board. CDBYTE promised me to send me at least reference PCB design which I can then order from any PCB company.

    The Skylab moduls are promising, but I see some deficiencies: No pinout, less pins (don't know what was skiped), no 32kHz low power quart for sleep timer ... I have ordered some other modules ... lets see, so far I can't test a lot without the carrier PCB's.
    Then I join you with testing (range/transmisson test, sensor readout, battery measurement, ePaper ...)


  • Hero Member

    I seem to be getting noticeably better coverage when receiving with a BT840F than with an nRF52840-DK. That's a bit surprising, as the ground plane is smaller. The are several possible explanations, but I'm guessing the metal can around the radio, which the BT840F has but the nRF52840-DK lacks, probably helps reduce the effective noise floor and thereby improve the S/N ratio. So, if you're picking a module, you may want to pick a module which has that. 🙂 Most of them don't, but there are a few that do.


  • Hero Member

    It turns out mbed does support the p1 pins. It just uses a different notation. Instead of P1_00, it's P1_0. Here's a link to all of the pin names: https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_NRF52/TARGET_MCU_NRF52840/TARGET_NRF52840_DK/PinNames.h

    So, because of ease of use and that I'm already started with it, I'm going to stick with mbed a bit longer. I have run across one inconvenient bug relating to send serial communications, but I've reported it, and I've devised a workaround to it until it gets fixed.

    Meanwhile, with all the above tweaks, I'm getting pretty good home coverage with just a single gateway mounted centrally on the second floor. It's not yet at LoRa's near perfect transmission/reception for a every conceivable nook and cranny in a home environment, but I suspect it may approach that once the amplified modules becomes available. And that's all transmitting at 1mbps, without the benefit of BLE Long Range which it is capable of doing.


  • Hardware Contributor

    And what about Segger Embedded Studio ? It's now free to use with Nordic SDK for NRF5 MCUs
    https://www.segger.com/news/segger-embedded-studio-ide-now-free-for-nordic-sdk-users/


  • Hero Member

    I resurrected @d00616 's code for reading the supply voltage to the nRF52, and it seems to work reasonably accurately on the nRF52840-DONGLE. Here it is again to spare people from searching for it:

    uint16_t hwCPUVoltage()
    {
      // VDD is prescaled 1/3 and compared with the internal 1.2V reference
    
      int32_t sample;
      NRF_SAADC->ENABLE = SAADC_ENABLE_ENABLE_Enabled << SAADC_ENABLE_ENABLE_Pos;
      NRF_SAADC->RESOLUTION = SAADC_RESOLUTION_VAL_8bit << SAADC_RESOLUTION_VAL_Pos;
      NRF_SAADC->CH[0].PSELP = SAADC_CH_PSELP_PSELP_VDD << SAADC_CH_PSELP_PSELP_Pos;
      NRF_SAADC->CH[0].CONFIG = (SAADC_CH_CONFIG_BURST_Disabled << SAADC_CH_CONFIG_BURST_Pos) |
                                (SAADC_CH_CONFIG_MODE_SE << SAADC_CH_CONFIG_MODE_Pos) |
                                (SAADC_CH_CONFIG_TACQ_3us << SAADC_CH_CONFIG_TACQ_Pos) |
                                (SAADC_CH_CONFIG_REFSEL_Internal << SAADC_CH_CONFIG_REFSEL_Pos) |
                                (SAADC_CH_CONFIG_GAIN_Gain1_6 << SAADC_CH_CONFIG_GAIN_Pos) |
                                (SAADC_CH_CONFIG_RESN_Bypass << SAADC_CH_CONFIG_RESN_Pos) |
                                (SAADC_CH_CONFIG_RESP_Bypass << SAADC_CH_CONFIG_RESP_Pos);
      NRF_SAADC->OVERSAMPLE = SAADC_OVERSAMPLE_OVERSAMPLE_Bypass << SAADC_OVERSAMPLE_OVERSAMPLE_Pos;
      NRF_SAADC->SAMPLERATE = SAADC_SAMPLERATE_MODE_Task << SAADC_SAMPLERATE_MODE_Pos;
      NRF_SAADC->RESULT.MAXCNT = 1;
      NRF_SAADC->RESULT.PTR = (uint32_t)&sample;
    
      NRF_SAADC->EVENTS_STARTED = 0;
      NRF_SAADC->TASKS_START = 1;
      while (!NRF_SAADC->EVENTS_STARTED);
      NRF_SAADC->EVENTS_STARTED = 0;
    
      NRF_SAADC->EVENTS_END = 0;
      NRF_SAADC->TASKS_SAMPLE = 1;
      while (!NRF_SAADC->EVENTS_END);
      NRF_SAADC->EVENTS_END = 0;
    
      NRF_SAADC->EVENTS_STOPPED = 0;
      NRF_SAADC->TASKS_STOP = 1;
      while (!NRF_SAADC->EVENTS_STOPPED);
      NRF_SAADC->EVENTS_STOPPED = 1;
    
      NRF_SAADC->ENABLE = (SAADC_ENABLE_ENABLE_Disabled << SAADC_ENABLE_ENABLE_Pos);
    
      return (sample*3600)/255;
    }
    

    With that as a voltage reference point, I plan to next try reading and wireless reporting the voltage on a solar panel, the one charging the supercap that will be powering the dongle.

    It's nice that the previous work done on the nRF52832 is easily and quickly ported to the nRF52840. 🙂


  • Hero Member

    I found a driver for doing 802.15.4 on the nRF52840 that looks rather interesting: https://github.com/NordicSemiconductor/nRF-IEEE-802.15.4-radio-driver
    The sample application its Wiki makes it look rather easy to use:
    https://github.com/NordicSemiconductor/nRF-IEEE-802.15.4-radio-driver/wiki/Sample-application


  • Hero Member

    @nca78 said in Everything nRF52840:

    And what about Segger Embedded Studio ? It's now free to use with Nordic SDK for NRF5 MCUs
    https://www.segger.com/news/segger-embedded-studio-ide-now-free-for-nordic-sdk-users/

    Looks quite promising, and probably easier to setup than eclipse. Actually seems quite sophisticated with tight debugger integration.

    I tried to get started with eclipse, and I immediately got lost. I just couldn't find a good tutorial for its C++ IDE. Segger looks as though it may be simpler.

    In order to be able to run the 802.15.4 demo code, which I refer to above, I need to be able to use an IDE that can utilize the Nordic SDK. I'm not sure that mbed can do that. So, unless someone knows of anything simpler, maybe segger embedded studio is it.


  • Hero Member

    I have Segger Embedded Studio (SES) up and running now. I built and ran the Nordic SDK's "hello world" over serial example. It works. Following this video made it easy:
    SEGGER Embedded studio – Getting started – [00:00..07:34] 07:34
    — Nordic Semiconductor

    It's clear from this that all the Nordic SDK examples directly support SES, because there are preconfigured files within the Nordic SDK for building each example on Segger Embedded Studio. 🙂 I don't see the same for mbed. 😞

    Also, as an aside, it's worth noting that the SDK's after 12.3 no longer support the nRF51. The current nordic SDK is version 15.2. Make of that what you will.


  • Hero Member

    I have the wireless uart over 802.15.4 example working. The description on how to set it up and run it is here: http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v13.0.0%2Fnrf_log.html&cp=4_0_0_3_20

    I'll try modifying the github example though to get a better idea as to what kind range improvement is achievable with 802.15.4 at the slower 250kbps.

    I'm not sure if this type of info is of interest to others, though, so for now I'll put a pause on further posting.



  • @neverdie I've read about this standard after reading nrf52 page on nordic's site. Please keep posting if it is not difficult for you. I think some time in the future many of current members of mysensors community will look at nrf51/52 MCU's as a replacement and further development of the platform. Seeing someone like you digging deep into the cause will encourage others.


 

323
Online

7.7k
Users

8.6k
Topics

92.4k
Posts