Everything nRF52840
-
@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.. :nerd_face: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 :laughing:
-
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.
-
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.
-
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 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 -
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/@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:
https://www.youtube.com/watch?v=YZouRE_Ol8g&index=2&t=0s&list=PLx_tBuQ_KSqGHmzdEL2GWEOeix-S5rgTVIt'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.
-
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)
-
@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??
