Everything nRF52840

[Nca78]

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/

[NeverDie]

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. :)

[NeverDie]

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

[NeverDie]

@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.

[NeverDie]

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-S5rgTV

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

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

[NeverDie]

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.

[monte]

@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.

[scalz]

@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)

[NeverDie]

@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.

[scalz]

@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??

[NeverDie]

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.

[scalz]

I think it's because there is also mbedOS included, and with SES there isn't any (rtos) for simple hello world.

[scalz]

still 430KB is a lot I agree. compared to MySensors stack! (not comparable, mysensors isn't an OS :) )

[monte]

@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.

[NeverDie]

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-summary

Accono 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.

[mfalkvidd]

@neverdie it was discussed in https://forum.mysensors.org/post/80266

[scalz]

@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!

[heinzv]

@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)

[scalz]

@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

[heinzv]

@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 :-)