Everything nRF52840
-
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:
-
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.
-
I did an nRF52840 drop-in upgrade to the BT840F module and was able to program it to transmit. It works!
-
Here's a size comparison of the nRF52840 BT840F to the BT832X (an amplified nRF52832).
I'm not aware of any amplified nRF52840 modules, but I would, of course, be interested if there are any.
-
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?
-
@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.
-
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 } } }
-
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.50784c4dZJ6WSYI 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=0This 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
I have also odered 3 nRF52840 dev boards from holyiot for 6us$ (which is quite ok).
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.
-
@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.
-
@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
-
@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.
-
@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 ? @_@
-
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).
-
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 payloadThen 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
-
@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.
-
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.
-
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.
-
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.
-
@neverdie What speaks against platform.io with Visual Studio Code?
https://platformio.org/platforms/nordicnrf52
http://docs.platformio.org/en/latest/platforms/nordicnrf52.html (includes nRF52840 DK)
and what about that:
https://os.mbed.com/platforms/Nordic-nRF52-DK/
and that:
https://github.com/lpercifield/arduino-nRF5/tree/nrf52840
-
@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=RelevancePlatforms: 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
-
@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-embeddedSo what MCU's and radio/transmission are you using then ... ?
-
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=docsI 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/nrf52840this 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/70Softdevice 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
-
@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.
-
@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
-
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.
-
@NeverDie
exactly.
with infos below, you have everything for estimating the range (maybe that can interest others people too):- https://forum.mysensors.org/post/93384 simple but so true.
- an excellent excel sheet made by.. TI! where you can pick absorption materials, set height of antenna, indoor/outdoor calc etc
http://www.ti.com/tool/RF-RANGE-ESTIMATOR
The doc for the sheet http://www.ti.com/lit/an/swra479a/swra479a.pdf , very interesting too with comparison about selectivity/blocking etc
or the forum thread in case https://e2e.ti.com/support/wireless_connectivity/proprietary_sub_1_ghz_simpliciti/f/156/t/375556
works ok, here, with excel 2010 viewer (else you can't use choice lists)
As it targets TI mcu, it's explained in docs that you can try by using an "equivalent" TI mcu, then check datasheet values for your mcu and change what's needed in the excel sheet. Maybe cc2640r2f and nrf52840 has "same" rf perf at 125kbps, no idea about blocking level.
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
-
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..
-
Unfortunately, I don't see the module on their website, nor does the listing show a pinout. Of course, the antenna won't be good. Regardless, I'd like to see a pinout.
-
@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 ...)
-
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.
-
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.
-
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/
-
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.
-
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
-
@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.
-
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 SemiconductorIt'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.
-
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.
-
@monte I don't know what to think about this, but just in case, to avoid confusion for newcomers, you can't really use MySensors AND 802.15.4 stacks. it would be redundant. these are two different projects with same goals: providing a RF stack with their own logic (state machine). I mean it's a choice to make : using MySensors or a standard like 15.4 (zigbee etc)
-
@scalz , If it's an either/or choice, why would anyone not pick 802.15.4? It's a rock solid IEEE standard that has been thoroughly vetted because it has been used for a long time already. Especially if the hardware itself directly supports it... it has intrinsic efficiencies.
The only reason I can see for not picking it would be the difference in transmit rate. At least on this chip, 802.15.4 won't be doing 1mbps or 2mbps, but only 250kbps. So, there is an argument for using mysensors at those higher transmit rates, and perhaps switching to 802.15.4 at the lower rate. Also, there would still be a need for something to manage that.
-
@NeverDie
of course I'm not saying to not use 15.4. I just meant it's redundant with MySensors.
It's just like if you were on a controller forum, says openhab, and were doing ads/howtos about another controller e.g. domoticz. It's free to talk about this, but still a bit off MySensors topic.
MySensors is an arduino library. That's the big difference with using others more "technical" frameworks/ide..So it's more than just a bitrate question (a bit overhead to switch bitrates the way you said, especially with 2.4g, maybe you would gain some range but not that much indoor, depends on the wall absorption which can be huge for this band, see excel sheet..)
Choices so far are simple:
- MySensors + Arduino : easier to get started for educational, non-programmers etc. Not IP based. Suppport (not complete) for different mcus. Connectors with controllers (openhab, domoticz etc).
- BLE + Arduino (not complete cores for all mcus).
- others stack (15.4 etc) + Arduino. Not complete core for all mcus. Not as complete as MySensors with all connectors. Often code are old. More technical framework than MySensors. Less easy for non-programmer/noob
- others stacks + others non-Arduino toolchains. The most technical from a newbie point of view for coding (you need to know C in a better way than using Arduino + examples). But in this case, you get better mcu support for using features.
Maybe I'm mising a case??
-
The code size generated by SES for a "hello world" is 11KB, versus more like 430KB for mbed, so, I suppose, yet another reason to switchover to SES. And that's 11KB non-optimized. If I turn on the optimized settings, it should be smaller.
-
I think it's because there is also mbedOS included, and with SES there isn't any (rtos) for simple hello world.
-
still 430KB is a lot I agree. compared to MySensors stack! (not comparable, mysensors isn't an OS
)
-
@scalz haven't you noticed that mysensors' community which is represented mostly by this forum has become more than just an arduino library? People share on this forum many projects that has only mediate connection to mysensors, if any. And many of users of the library in it's current form have outgrowing some of it's limitations, so naturally they will try to find a solution to overcome them and then share with others on this forum. I don't see nothing wrong for mysensors platform to evolve and adopt modern standards and/or protocols. And even if 15.4 is not suitable or just a replacement of mysensors protocol I think there are people here that will find it useful to read about it. Correct me if I'm wrong but there is no rule against discussing other protocols than mysensors on this forum.
-
Anyone here tried Tag-Connect? It looks like a convenient way to interface to your modules for uploading:
http://www.microchip.com/Developmenttools/ProductDetails/TC2030-MCP-NL#additional-summaryAccono is using it to program their nrf52 modules: http://aconno.de/acn52832/
It's not clear to me whether you need to hold it against the module while doing the programming, or whether some of the pins somehow grab on to the pcb so that you don't have manually hold it up against the board while doing the programming.
-
@neverdie it was discussed in https://forum.mysensors.org/post/80266
-
@NeverDie I think you need to hold it, but it looks there is "coded" holes/slots for helping and correct positioning.
@monte
@monte said in Everything nRF52840:haven't you noticed that mysensors' community which is represented mostly by this forum has become more than just an arduino library?
Hmm, I haven't.. so what's more? Has MySensors been forked to another platform?
@monte said in Everything nRF52840:
People share on this forum many projects that has only mediate connection to mysensors, if any. And many of users of the library in it's current form have outgrowing some of it's limitations, so naturally they will try to find a solution to overcome them and then share with others on this forum.
I'm not the last on bleeding edge, but I didn't notice many mediate connections..Which limitations have been hacked? maybe on the forum, not same on git I think. Thx to PR contributors. But apart from mysensors team, especially one very active contributor that we can thx
it's rather rare.@monte said in Everything nRF52840:
I don't see nothing wrong for mysensors platform to evolve and adopt modern standards and/or protocols. And even if 15.4 is not suitable or just a replacement of mysensors protocol
Not in scope and not supported by mysensors team to switch to a standard, as mysensors is still about its own stack. It's like if you wanted to mix zigbee&mysensors logics (doesn't make sense). So 15.4 is a replacement. Maybe read about it. I'm telling this because I played and playing with 15.4+another mcu, and comparing stacks.. whether switching stack or not. If not, what could be improved, logics to add to mysensors etc.
@monte said in Everything nRF52840:
I think there are people here that will find it useful to read about it. Correct me if I'm wrong but there is no rule against discussing other protocols than mysensors on this forum.
you're right. no rule on this, free to talk. But I preferred to be precise for newcomers who may get confused when reading about nrf52840 in mysensors, that there is no support from team for others stacks, and non-arduino.
Lot of "noobs" don't know what means a rf stack exactly, what logics inside etc, they simply want to use MySensors because it's easy to use, especially when non former dev. That's what would expect someone discovering nrf52840 is supported in MySensors. So this gets completely confusing, external toolchains and using others rf stacks etc.. might end in hundreds of posts with just a few mysensors relevant infos (good luck for newcomers)wasting my time, I won't disturbe your experiments anymore
Good luck and feel free to improve MySensors of course!
-
@scalz I think you're right to some extent if the full Zigbee stack is used.
On the othe hand, my understanding was, that mysensors provides more than an RF protocol and it supports already more than one protocol (nRF24, RFM60, RFM95/LoRa) and also partially other MCU's not just the default Arduino's e.g. ESP32 - but not for battery powered nodes. It also support a couple of sensors, voltage etc.
For battery powered sensors, I have only seen only full support for the Atmega 328p and that is for me a big limitation, as it has a couple of HW limitations such as Flash/RAM etc. and I got stuck as I want to use battery powered sensors with a low power display like ePaper.
Looking for alternatives brought up the discussion on MCU alternatives which are very engergy efficient and dont have that limitations. The nRF5 is in my eyes a good alternative with either the bluetooth, ZigBee protocoll or even if both do not provide the required range, I would just use them with a RFM95 LoRa module (why not?) it will then just replace the MCU and not the radio.
The mainy question is still open: Will there be a "full" mySensors project support for another MCU like the nRF5 or will it become another project (ZigBee, Bluetooth etc.).@NeverDie In any case, I appreciate the work done by you, because I see the nRF5 currentyl as the most promising platform for low engergy sensor nodes. I also like the ESP32 and will continue using them, but they are complementary.
BTW: I have ordered 5 dongles via Mouser.at at (10€) with no shipping cost (above 50€, thus the 5 x 10€ order).
I'll also get my nrf52832 min Breakout-PCB's soon (https://www.openhardware.io/view/586/E73-2G4M04S-Breakout)
-
@heinzv
what do you mean by full zigbee vs incomplete zigbee then ?
a rf transceiver+some PHY settings VS an rf stack/framework. not the same. MySensors, zigbee, ble etc are stacks (software logics with different layers) that can run on different mcus/socs
MySensors used in non-arduino platform? which one? (esp32 idf is included in arduino, and you can add arduino module in esp-idf but that's all.. still arduino)
For the moment there are still conflicts in nrf5 hw resources for ble+mysensors.
d00616 started some work for nrf5 support, but it's not finished yet, and as usual team members do this in their very limited spare time. It's not in plan of MySensors (others members can correct me) to switch to a different stack
Sorry to not have a better answer, but it's hard to say
-
@scalz "Full Zigbee Stack": Maybe my phrasing was not ideal, I wanted to say: if we use not only the IEEE802.15.4 Standard but also the complete stack with ZigBee.
I know that mySensors is done by (most likely a few) people in their spare time and adding a new HW stack is extra work which is not just initial work but also remaining maintenance effort. On the other hand, isn't that also the intention of a community project to discussing new possibilities and significant improvement potentials and having experts and enganged people providing pros, cons, inpust (thus also your inputs are important
-
@heinzv
oki
that's what I meant. your pic shows it. Mysensors is already "full" stack with different layers, and afaik it's not in plan to replace its PHY+MAC layers by 15.4 . This would imply lot of work too and most of features are already present except slotted time rf which needs quite some work..
And changing these layers won't solve nrf5 resources, softdevice accessibility in arduino.
The others solutions- d00616 work for mysensors : help to fix issues and finish the code
- fork mysensors to another non arduino platform supporting these stacks -> lot of work non supported by mysensors team (and still redundant, worth the effort? as you could directly use your favorite stack)
Like you I tried a lot of different roads too (I'm not new on the bleeding edge like I said)..full of dilemmas, no perfect solution, still working on it!
-
@scalz just let me/us know or please share your findings.
I'm also exploring different roads for different cases. Not just MCU, radios, sensors, displays (TFT, LCD, ePaper) etc.
So far I've got some overview on the possibilities and limitations.
I'm quite satsified with the ESP family (8266/8285 and ESP32), but I see also the limitations of the Atmega families as well as the old STM32 families.
I like the LoRa radio as best option for long range and energy efficiency use cases, but see the potential of BLE 5.0 and ZigBee but have not yet experience with it and I'm at the beginning of the nRF5x learning, but it looks at least promising.
Any other option on the radar? ... I'll follow your inputs/discussions and of course observe the market as well by myself ...
-
Although it's hard to predict the future, I'd wager that Bluetooth 5 will greatly overshadow 802.15.4 when it comes to wireless sensors. Why do I say that? Because Bluetooth 5 is already included in some of the leading phones: https://www.gizbot.com/mobile/features/10-latest-smartphones-which-come-with-bluetooth-5-0-to-buy-in-inida-2018-047304.html
For instance, I have a Samsung Galaxy S8 phone, and up until just now I wasn't even aware that it actually contains Bluetooth 5. Does that mean my phone can communicate with a Nordic nRF52840 using the 125kbps long range settings? I don't know, but I'm now curious to find out. Anyone know?
According to Nordic, the 500kbps mode will have twice the range of the 1mbps datarate, and the 125kbps datarate will have 4x the range of the 1mbps datarate:
I guess they're comparing it to the 1mbps proprietary mode of the same radio? Part of the reason for the 2x or 4x range increase can be attributed to the coding gain, which, AFAIK, the 250kbps 802.15.4 mode doesn't have. Unfortunately, the article doesn't say what kind of range increase to expect from the 802.15.4 mode, but I'm guessing (?) it will not be a lot. Maybe, what, 10% or 20% better? Any guesses?But range of the 125kbps mode should be even more impressive if comparing against the nRF24L01, which has a link budget of 86dbm:
https://www.eetimes.com/document.asp?doc_id=1276396&page_number=2
as compared to 111dbm for the 125kbps mode of the nRF52840 (as quoted by the same Nordic blog as above). Part of that is from the greater Tx power and receive sensitivity of the nRF52840. In the end, all those details get reduced to a single link budget number, which is apparently how a proper comparison is made.[Edit: https://devzone.nordicsemi.com/b/blog/posts/taking-a-deeper-dive-into-bluetooth-5]
-
@NeverDie I also own a Galaxy S8 and interested in that study.
I especially like the idea to have a very energy efficient MCU which contains already a very energy efficient radio. That saves a lot of energy in total, soldering, wiring, complexity of multi chip handling (sleep, wake, sync) and saves also space (makes PCB's and devices smaller).
If the range is sufficent and we get the development environment satisfying established, what else are we missing?
Price and MCU performance is also ok, Flash and RAM is ok. Availability of internal peripheral and sleep/wakeup behaviour is ok. The only small drawback I've seen is that there is no internal EEPROM.
Once I have my dongles and or breakout PCB's (for the "inconvinient" 1.1mm pinouts and soldering pads below the module), I'll start with the sensor communication, radio transmission and ePaper display. If the range is satisfying with BLE then I also need to decide how I integrate with my controller OpenHAB (a mySensors binding if we get that added, ZigBee, MQTT which a MQTT gateway ...). Would be interested what your plans for integration are (which is also releated to the comment from @scalz)
-
about indoor range, if you didn't try the TI range estimator excel sheet link, I extracted list of absorption material, if it interests anyone
about using multi protocols in same band, a while ago I modified a graph I found on internet, for comparing wifi less crowded channels VS nrf24/52 channels in MySensors.
Note: zigbee also uses same channels, some implementation can do frequency hopping too, making harder to predict PER packet error rate etc. If I remember Zigbee channel 1 = nrf24/52 channel5. Last zigbee channel being nrf24/52 channel 80.
maybe I'll try to make an article about all this rf stuff (missing time atm).
Still good to know, what possible issues with coexistence of multiple protocols used in same band without good device placement or "time slots" for switching protocols and avoiding "potential collisions". But this would need same synced software for all devices.
I would say, I can be wrong, it's not a great idea to use too many protocols in same band without these precautions, can get messy in air. (not mentioned neigboors playing with different endproducts in same band, antenna detuning, efficiency due to hw designs, ->shifting center freq, bandwitdth etc..).
-
Sadly, at least as of June 2018, none of the smartphones supported the long range capabilities of Bluetooth 5, only just the 2mbps Bluetooth 5 capability.
Bluetooth 5 features in smartphones
Bluetooth 5 includes capabilities for faster speed and longer range. It’s fairer to say, however, that developers must choose between speed or range.
Read more: The Bluetooth 5 trade-off
In smartphones, however, you don’t even have that choice. To date none of the smartphones support the Coded PHY that extends the range of Bluetooth 5. Instead you can have the 2mbps speed. For most applications this is likely to be fine. Most consumers are looking for ways to connect to devices that are within a few feet of them. The longer-range features are more useful for lower bandwidth applications such as sensor networks.
https://blog.nordicsemi.com/getconnected/bluetooth-5-in-smartphonesI don't know if that's an android limitation which might improve, or whether the radio chips in the phones are missing the required hardware to do coded 125kbps Bluetooth 5 long range. I can understand that there's a chicken and egg dilemma holding things back, and that right now there's probably not any reason for phone manufacturers to give long range priority in their phones, since at present there's very few, if any, devices for the phones to connect with using Bluetooth 5 long range.
Nonetheless, this post has links to demo code for long-range bluetooth on the Nordic: https://devzone.nordicsemi.com/f/nordic-q-a/38267/long-range/148485#148485
-
@neverdie I read an article regarding BLE 5.0, ANdroid and the Samsung Galaxy S8 HW (the used SoC from Qualcom/Snapdragon or from Samsung varying on the model/region).
The article is in German but it says: BLE 5.0 was introduced with Android 8.0 but the S8 HW does only support the 2x data rate (2MBps) but not the 4x range. So it seem that it is a HW limitation similar to the nRF52832 in comparison to the nRF52840. Only the 840 support both, the 832 only the higher data rate. Strange, that this is so bound to the HW and thus so limiting and unflexible.
-
It's worth noting that Texas Instruments has a $29 launchpad which demonstrates its flavor of Bluetooth Long Range: http://www.ti.com/tool/launchxl-cc2640r2
It uses a Cortex M3 rather than an M4.
I think it might be worth looking into to see whether it's any easier to use than SES.Cypress Semiconductor has its version, with kits starting at $49.
http://www.cypress.com/products/ble-bluetoothLikewise, silicon labs has its version, but the starter kit is $99: https://www.silabs.com/support/getting-started/bluetooth/bluetooth-low-energy
https://www.silabs.com/products/wireless/learning-center/bluetooth/bluetooth-5?gclid=EAIaIQobChMIodewu8PR3QIVXrXACh2IZwE5EAAYASAAEgI3OfD_BwEAre there other manufacturers worth noting?
I wish at least one of them had an official video course. That would speed up the learning process. I think Nordic has made the mistake of not making it easier to learn how to develop for their product. It wouldn't be hard for them to do a high quality video tutorial, and yet it appears they've done just the bare minimum. I have some hope that TI may be better in this regard, but I haven't yet looked more closely to say for sure.
-
@scalz said in Everything nRF52840:
Hmm, I haven't.. so what's more? Has MySensors been forked to another platform?
I mean people discuss all things here on forum that are in common interest including 3d printers, CNC's and work place arrangement. No wonder they will discuss other wireless protocols and platforms as well.
@scalz said in Everything nRF52840:
Lot of "noobs" don't know what means a rf stack exactly, what logics inside etc, they simply want to use MySensors because it's easy to use, especially when non former dev. That's what would expect someone discovering nrf52840 is supported in MySensors. So this gets completely confusing, external toolchains and using others rf stacks etc.. might end in hundreds of posts with just a few mysensors relevant infos (good luck for newcomers)
Those newcomers will just pass by these threads and find the answer on their topic. And then when they will learn (as many of us did thanks to this forum) they will come back to threads like this and get useful information for their further education. And those noobs, you mentioned who just wants to make "smart socket" or humidity sensor probably won't even come to the forum section as they have plenty information in tutorials on the main page. Why do you consider newcomers so dumb?
-
Guys, let's move on from this tempest in a teapot. The way I see it: at this point in history what we individually want or don't want won't make any difference to the ultimate outcome in the big picture, because there are now much larger forces at work. Our best bet is to help each other identify the best trend to ride. If that's mysensors, then great, but if not, let's try to figure out just exactly what else might reasonably win so that we can avoid dead-ends and hopefully ride the trends with the wind at our backs.
To my mind, the following have traction (in no particular order)
- LoRa (because it's simple and it just plain works)
- Bluetooth 5 Long Range (because smart phones, eventually, will make it so) with an integrated ARM MCU. That said, bluetooth per se has always seemed cumbersome to me, and I never really liked it. I'd probably be happier using a barebones version of it.
- MQTT
Maybe Thread will happen or maybe it won't. I'm not sure what will catalyze it, so I'd have to see meaningful uptake before I bet on Thread.
-
@neverdie I have no problem with this discussion (actually I like it :-). We're just lookig for an alternative to the "aged" and "limited" Atmega 328p platform. And at the end, I can/should also benefit for the MySesnors project/community.
At least, I'll do it anyway but having some other experts opinins is always helpful.I have taken a look at the TI CC1352P which supports multiprotocols UHF (868) and BLE 5 (ZigBee, Threads etc.). It has similar features as the nRF52.
Has less Flash/RAM but still sufficient.So still to investigate BLE 5/ZigBee long range or LoRa + MQTT and Nordic nRF52 or TI CCxxx
-
@heinzv said in Everything nRF52840:
I have taken a look at the TI CC1352P which supports multiprotocols UHF (868) and BLE 5 (ZigBee, Threads etc.). It has similar features as the nRF52.
Wow, almost everything but the kitchen sink!
The CC1352P device is a multiprotocol Sub-1 and 2.4-GHz wireless MCU targeting Wireless M-Bus, IEEE 802.15.4g, IPv6-enabled smart objects (6LoWPAN), Thread, Zigbee
, KNX RF, Wi-SUN, Bluetooth 5 low energy, and proprietary systems. The device contains a +20-dBm integrated high-power amplifier with best-in-class efficiency for long-range applications.
http://www.ti.com/product/CC1352P/descriptionImpressive. What will TI make next? A software defined radio?
-
@NeverDie that's what I'm going to use for my ha. I have TI launchpad and sensortag for testing, already played a bit with previous cc1350 and their framework. I have designed a few different cc1352x rf modules (shielded), childboard for sensors, pcb or ceramic antennas footprints for nodes etc..I'm just waiting to receive pcbs, vna and I'll tune. when enclosed too. for compliance. Lot of fun coming
-
Interesting! I watched this video and learned that it lets you do both Bluetooth and sub-gigahertz simultaneously.
Connect: Dynamic Multi-Protocol Demo – 05:48
— Texas InstrumentsI like it.
-
@scalz So that was a good hint
It would be nice if you would share your PCB's and and where you ordered it and I hope also your code! I have not yet seen many boards (good layout and price) with the CC1352P/R but maybe you can help us here?
Of course I mean beside the TI Lunchpad for develoment.@NeverDie what do you think? Finally we might come closer
-
@heinzv said in Everything nRF52840:
what do you think?
I've pretty much said what's on my mind. I just want to make sure I'm taking the easiest/fastest path possible for getting projects done. IMHO, Nordic would benefit from a more friendly API (more like Arduino or MBED). Nordic's code is largely undocumented in-line. Instead, virtually all the documentation is in Wiki's or the datasheet. It's just not geared toward quick learning, although once you learn something it does seem easy in retrospect.
Therefore, I think TI is worth a closer look. If TI is easier than SES/Nordic, or at least has better learning materials, then I'd probably switch to TI, even though I would sorely miss Nordic's Programmable Peripheral Interface (PPI). As far as I know, PPI is not a part of ARM, and only Nordic has a it (?).
Also, having a wireless bootloader that works and is easy to use would be a real bonus. I'd much prefer to wirelessly upload sketches. Does TI have that? Anyone know?
-
@NeverDie got it. I'll also try both and decide then. Maybe scalz can help us to come to a decison as he tried both and might share some sketches/code or give us some hints.
-
@neverdie said in Everything nRF52840:
Also, having a wireless bootloader that works and is easy to use would be a real bonus. I'd much prefer to wirelessly upload sketches. Does TI have that?
Answering my own question, it would appear the answer is yes:
Supports Over-the-Air Upgrade (OTA)
http://www.ti.com/product/CC1352P/descriptionand it appears to be true for the CC2642R2 launchpad also:
http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_1_30_00_25/docs/blestack/ble_sw_dev_guide/html/oad/oad.html
-
@neverdie I have ordered the Launchpad LAUNCHXL-CC1352P1 from Mouser.at and registered at TI and downloaded all SDK's and the IDE(s).
Now I need plenty of time to test my nRF52832, nRF52840 (breakout/USB dongles) as well as the TI CC1352P ...
-
@heinzv That's great. Maybe we can learn together.
I like Mouser, although here it may in this instance be less expensive to order from TI directly.
The main downside at the moment is that both the CC1352P and the CC2640 are so new that there are not as yet any inexpensive modules to use on projects, and I doubt I would be good at DIY reflowing these chips onto PCBs. So, I'm not sure what to do about that. Anyone have any ideas?
-
@heinzv said in Everything nRF52840:
@neverdie I have ordered the Launchpad LAUNCHXL-CC1352P1 from Mouser.at and registered at TI and downloaded all SDK's and the IDE(s).
Now I need plenty of time to test my nRF52832, nRF52840 (breakout/USB dongles) as well as the TI CC1352P ...To kick start your development, we offer two LaunchPads with optimized external RF components, one for Sub-1GHz PA and another for 2.4GHz PA wireless operations:
LAUNCHXL-CC1352P1:
Sub-1 GHz operation at 868 MHz / 915 MHz up to 20 dBm
2.4 GHz operation up to 5 dBm
Get started with the out of box experience > (dev.ti.com/launchxl-cc1352p1)
LAUNCHXL-CC1352P-2:
Sub-1 GHz operation at 868 MHz / 915 MHz up to +14 dBm
2.4 GHz operation up to +18 dBm*
Argh. Why, oh why, didn't TI make a launchpad with a PA on both the sub-1ghz and the 2.4ghz?
I wonder which radio gets used for the OTA firmware upload?
-
@neverdie I have seen that only the P1 version was "unavailable" directly @TI. And yes they have different signal strength on 1GHz and >2,4GHz. I found that also strange.
I wanted to order @TI directly but it looks like you have to be a company or a school and they enforce you to provide a valid URL (you could fake that but I'm not sure if they would ship then).
However buying it at Mouser in Austria is faster and you don't pay shipping cost (above 50€) and don't have to take cate about tax as Mouser has an Austrian order address . The Launchpad cost about 50€.Regarding the non dev modules: That is what I mentioned to @scalz that I have not yet seen cheap modules, but he said that he made some PCB's for the MCU as well as sensor add-ons and they are on the way, so I hope he will share the PCB files with us or we can order them via his page.
I have a SMD hot air soldering station and solder paste. So I have no fear to solder the MCU But of course having ready soldered bare modules which work out of the box and less or around than 10€/US$ would be preferred.
-
@neverdie said in Everything nRF52840:
Argh. Why, oh why, didn't TI make a launchpad with a PA on both the sub-1ghz and the 2.4ghz?
because it's a very new mcu, and they have some work in progress regarding PA paths. (from what I read). So I think they wanted to quickly provide a few usable&different launchpad designs for customers.
Like I said above (but it's in nrf52840 thread arghh), I designed my own shielded modules that I'll tune regarding an ideal gnd plane. I'll test a few antennas (still have a few favorites, but there are some nice chip antennas I would like to test too). And I'll also tune it regarding a sensor daughter board I made, and again check once it's enclosed too. Once that's done I'll provide some comparison, infos, with tuning results (smith charts, vswr etc), tips and help if I can for assembly or to get my modules (PM, or tindie etc, I have a reflow oven to help me, and at my job we're talking about pick&place in shortterm future, not for iot, but handy for extra projects) but 1st step 1st
Still for the moment, as some others new mcus (with erratas), it's not arduino.. but TI mcus are close as it's possible to use, with some limitations, Energia/Arduino project (and sketches are import-able to TI ide).
Our plan (another team member might be interested, he played with cc135x too) is to use MySensors lib (or a part). The main reason : MySensors API is compatible with lot of controllers.
-
@scalz said in Everything nRF52840:
Our plan (another team member might be interested, he played with cc135x too) is to use MySensors lib (or a part). The main reason : MySensors API is compatible with lot of controllers.
Yes that's the big advantage of MySensors, having something you can use on many controllers. So even if the RF stack/network is completely different it's still nice to have a gateway that pretends to be a MySensors gateway to the controller.
-
@heinzv (or anybody) Do you happen to know what the Tx power and Rx sensitivity is on the bluetooth that's in the Samsung Galaxy S8? I'm guessing that it's relatively weak, in which case I suppose launchpad P1 might make more sense than P2.
-
It seems that Nordic just hasn't developed easy to use abstraction layer for Bluetooth 5. The question is: has TI? I guess maybe before ordering the launchpad, I should download TI's software and have a look.
Also, is it better to have a single awesome radio that does everything at 2.4Ghz or two humdrum radios, one with great range at sub 1ghz and the other with limited range at 2.4ghz? The two radio solution will always have a higher hardware cost and a bigger footprint, so getting cheap modules might (?) be difficult even down the road. I just don't know.
Thoughts?
-
@neverdie I have not found any hint on BLE Rx Tx sensitivity (Rx) or signal strength (Tx), but I assume that it's not that high as after a few meters the device connections are lost (SmatGear S3), Headphone etc. I would say less than 10m.
My TI CC1352P1 is ordered and I guess it will arrive by end of the week. Meanwhile the Nordic USB dongles are also on the way, so I'll start with the nRF52840 latest at the next weekend and I assume I will have the first experience with the Nordic MCU's.
Regarding the TI MCU: Although in the advertisment video it was explained why you would have two radios at the same time on the same chip, but I rather see it as a possibility to use one or the other best fitting the usage it is built for without attaching another modul. But I'll wait for the first set of real live tests under different conditions (for both nRF52 and TI CC1352). And also how convinient the IDE's and libraries can be used.
Looking at the TI homepage, the CC1352(p) is not even yet available but announved for Q3/2018 which should be now or soon. Thene I hope we can get first modules. I wonder where @scalz will get the MCU's (even the raw chip's)?
-
I've thought it through.
Presently the nRF52840 and all the TI Bluetooth 5 launchpads have a receive sensitivity of -103 at 2.4Ghz. None of them are using an LNA at this time.
I think my interest in these chips is mostly tied to doing very power efficient remote control wakeups, which I previously proved I could do using the PPI on an nRF52832. I used the PPI to wake up every 100ms and check for received packets without waking up the mcu, thereby saving power. I could do the same thing with the nRF52840, but with the advantage of its greater receive sensitivity. I'm not sure that TI has anything equivalent to PPI, but even if it did, it would have no advantages for this use case.
For everything else, I'm happy using LoRa modules, because their range/coverage are just fantastic, and at around $3 the Ra-01 LoRa modules are very inexpensive.
Meanwhile, I'll track developments at TI and see what becomes available. It looks like TI is doing good work.
-
@NeverDie they have sort of equivalent for processing IOs, sensors, i2c etc without waking up the mcu. it's called Sensor Controller (accessible by code or they also provide a small ide for it).
about LORA I've never been really interested in it, I prefer to have my own "micro" network than being a part of a larger network. I would also prefer narrowband.
Sure if you use LORA nodes, maybe narrowband is maybe not the best bet for you. in some cases, widespectrum LORA can have range issues, not heard, when narrowband is used (they made a video+appnote about coexistence)
My need is subghz for long range reliable delivery + BLE for shorter range stuff.., using one broadband antenna or two differents of any kind, to be able to use a module or a bare ic (sometimes a module doesn't fit well in design regarding placement of the module or the antenna orientation&keepout area, so with two modules it's "worse"), and I've been very disappointed to see Nordic changed its mcu footprint (needs premium pcb, and more soldering care). That's why TI picked my curiosity (it ticked all my checkboxes, all in one).
But you're right if you feel more confortable with nrf, it's nice mcus too. Both needs some work anyway (one mcu needs BLE/MySensors, the other needs to get its dualmode compatible with MySensors messages&serial api)
-
@scalz I found this: https://training.ti.com/simplelink-academy-introduction-sensor-controller , which says:
Also, the sensor controller has not any direct interface to the radio or system flash.
-
@NeverDie yes. SC is also accessible from app, it can be independant. If goal would be for sort of lowpower listenmode, there are code examples too, not the goal of SC, sure (no link with rf). I don't think I tried it, but will take a look once I've other stuff ok.
I guess, even if PPI doesn't wake up mcu, the task function with a timer still uses somes power.Maybe you should keep on nrf if you feel more familiar with these. Truth is I have played too with it, but I stopped on my side, a while ago..and started to take a look at TI (so I could say I'm as familiar or maybe "more" with TI now,..). And perhaps, I already said it, but I'm not interested to pay 12$ for bt840f (limited accessible IOs), or less money but with 840 ceramic antenna. When for the same price I can assemble myself a dualband mcu and pick antennas I need. Like people says, pick what fits best your needs (and the application)
-
@scalz regarding LoRA (RFM95), I think you might confuse LoRa with LoRaWAN. LoRa is a protocol and you can have your own "mico network" (so do I). It is the most efficient and easy to use 868MHz radio (in my opinion) and has long range and high energy efficiency and cost is low (a little bit more than RFM69).
The nRF52840 has a good amount of Flash/RAM (1MB/256kB) and good sleep current even keeping RTC and RAM up or even using radio Rx.But the TI MCU's like the CC1352P is certainly a very interesting new candidate and it look very very promising with it's BLE 5.0, ZigBee AND 868MHz radio. And I like the SC coprocessor. No doubt that look very attractive. Thus I ordered the CC1352P1 Lunchpad. But that seem to be the only available option to get this MCU and this is for learning purposes only.
When I look at the TI product page it says Status: PREVIEW, no stock: http://www.ti.com/product/CC1352P/samplebuy
I have also seen anounced prices with 10 US$ for the chip itself.
Not sure when it will be really available, get a reasonable price and modules offered (such as for any other MCU's like nRF52).
Same story for the CC2652R, also in PREVIEW.
If you have sources or even PCB's (designed by you) for this MCU's, I would be eager to order and test it.
-
@heinzv
yes you're right about lora, and that they're using some juice too (they can even be compatible with a rfm69 when you take a look at the datasheet. TI's too though).
I know about nrf52840 power modes, I just replied about PPI feature (depending what you implement, it can't be completely free).
About Ti mcus, they are new and available at their store only. about sharing my work.. when I'll get time. for the moment I'm very busy (with my job too). In the meantime, you still can play with their devboard and try their courses, or energia.
-
@scalz and @NeverDie today I got my nRF52840 dongles (6 pieces) as well as the TI CC1352P1 launchpad. Now the fun will begin (latest at the weekend)
See the picture below (the dongle in blue and the launchpad in red).
If you have already some more code to share for testing (send/receive, I2C sensor read etc.) please post it (some code was postetd by NeverDie) other wise I'm looking at the Nordic pages, they provide a lot of examples (I will probably use/try Segger).
For the TI part, I only have one launchpad, so I have to verify, if I can use BLE 5.0 to communicate with my mobile or between TI CC1352 and nRF52 ...
Not sure if the TI can also communicate with the CC1101 at 868MHz (using the Sub 1GHz capabilities) using the same modem settings. So a lot to find out.
-
@heinzv Please do keep us posted with your impressions as you develop them.
I found out that Nordic does have OTA firmware updates, though it looks rather laborioius to set up: https://devzone.nordicsemi.com/b/blog/posts/getting-started-with-nordics-secure-dfu-bootloader
Maybe it's easier with TI (?).
-
@NeverDie okay, a very first testing yesterday late-night when setting up the Segger / nRF52(840) tool chain and a very quick dongle testing
I used the nRFconnect and uploaded all 5 demo/test applications which worked. No big achievement but just a very basic testing (maybe not even worth to mention)
Here is the result of the BLE app test: I did the BLE scan with the dongle and it found some devices around such as the BLE WiT power plug with the energy meter. Thene I did the oposite and installed the nRF connect on the Android Galaxy S8 phone and scanned for the nRF dongle.
Attached the two results (one from the dongle and one from the mobile phone)
As you see the Galaxy S8 finds all BLE WiT smart plugs in the flat (also the ones which are in other rooms) while the nRF dongle sees only the one which is close in the same room.
I would assume, that the Galaxy S8 has a much better BLE antenna than the dongle (which has almost no antenna), but what I interpret the RSSI, the dongle reports a better signal strength of the WiT powermeter in the room?!
Today I received also the breakout PCB's for the nRF52832, thus I'll probably try to do a sender/receiver test with them using one as mySensors Gateway and one as mySensors Node (both in nRF24 mode). Not sure if the compile/build will work, because I have to also provide the proper pin-map (as the E73 module is not mapped in the Arduino IDE).
-
@heinzv Regarding, the dongle, its antenna seems to be highly directional, so that may play a factor in what you are observing.
-
Found these relatively inexpensive TI modules:
https://www.ebay.com/itm/REYAX-RYB080I-BT-4-2-5-0-Bluetooth-module-BLE-TI-CC2640R2F-Antenna-AT-Command/183413364598?hash=item2ab449d776:g:dOEAAOSwOZtbRu7Athat presumably are compatible, at some level, with ti's cc2640R2F launchpad
Also, I found the info on how to do the OAD (over the air download): http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_1_30_00_25/docs/blestack/ble_sw_dev_guide/html/oad/oad.html
Regarding the Nordic gear, I'm hoping that micropython, if installed, might prove to be easiest for OTA updates, since, in theory, a micropython app should be able to update itself through its inherent REPL process. It turns out that maybe because of the BBC micro bit, micropython runs on the nRF51. In general, though, it seems like the ESP8266 has a lot more micropython support.
-
@NeverDie I'm still at the basics (where you have been probably one year ago). I have now soldered my nRF52832 modules (the E73...B from EBYTE) to the breakout boards and tried to find the best way to program and flash them.
I started with Segger Studio and with ST-Link upgraded to Black Magic Probe but as far as I have understood it supports only their own J-Link HW for flashing (at least the J-Link EDU is required). I also converted a ST-Link Dongle to a J-Link dongle but that can only flash STM MCU's (license restrictions).I have then tried to use Aruino Studio with all 3 dongle types (Black Magic, J-Link and ST-Link). I was only successful by using ST-Link. It does flashes the sketches and it runs (just used a simple blink example for flash testing).
But using the ST-Link (V2), there is no serial devices and thus no Serial Windows for log output (Serial.println()).
I've also tried to use the Black Magics with the GDB but it did not work either and I found it also not convinient with the commandline.So what are you using for flashing with Arduino Studio (with it's limited nRF52 support) and flashing with Segger Studio an what are you using for debugging and logging (print lines to output/serial ...)?
-
@heinzv For the NRF52832, try using the MySensors MyBoardNRF5 board type. In MyBoardNRF5.h, there is a section for the serial interface. Set PIN_SERIAL_TX to the pin you want to get serial output from. Set PIN_Serial_RX to some unused pin. It isn't used anyway. (A tip I got from @NeverDie).
I like the Black Magic Probe because it has both the SWD and Serial in one device, but you could program with the ST-Link and listen to Serial with an FTDI. I hear J-Link is the best, but have not used it. Might try it now that I know there is an educational version.
