nRF5 action!

[gohan]

I think we should open a dedicated thread about smd

[Nca78]

@gohan said in nRF5 action!:

I think we should open a dedicated thread about smd

We had the same idea at the same time.
I moved the related posts here => https://forum.mysensors.org/topic/9412/smd-reflow-oven-pid

Not sure the title is the best, feel free to suggest a better one in the other thread

[monte]

Hello guys. Finally I've got some nrf51288 boards, like used here: https://www.openhardware.io/view/510/Button-cell-Temperature-Humidity-sensor I've hooked it up to ST Link, uploaded test sketch and everything worked fine. Then I tried to put it to sleep and measure power consumption. The best number I'm getting is 550uA... And it seems like something is completely wrong with this. Either my readings, or some bug in new version of Mysensors library or nrf5 arduino core.
To be sure it's not particular chip's bug I've checked both I've got, no differences. I've also checked current on stock BLE firmware from manufacturer it was running when they came. It was around 120uA - 200uA while presenting via bluetooth. So I guess it can't be that my readings are completely wrong. But then how can it be that bluetooth presenting consume less current than sleeping?
For now I couldn't find a solution or any hint for this, so I apologize If I am missing something, but I need help.

EDIT: I might just delete this post, but maybe someone will search for the same solution. Long story short 600uA extra is due to the lack of low frequency crystal onboard. It makes HFCLK to not shutdown and draws current during a sleep. I knew, that synth RTC will take more current but I didn't expect it to be that much.
Another question is why sleep that depends on pin change and seems doesn't require RTC consumes 1ma? I'm confused...

[monte]

To summarize, what I have for now.

• Plain mysensors sketch with empty loop consumes - 16.6mA

• The same sketch with sleep(60000); in loop - 95-100uA

• The same sketch with pinMode(10, INPUT_PULLUP); and sleep(10, FALLING, 0); - 1mA

• The sketch based on Nordicsemi example from here https://github.com/NordicPlayground/nrf51-powerdown-examples/blob/master/system_on_wakeup_on_gpio/main.c

void setup() {
  NRF_GPIO->PIN_CNF[10] = ((uint32_t)GPIO_PIN_CNF_DIR_Input        << GPIO_PIN_CNF_DIR_Pos)
                          | ((uint32_t)GPIO_PIN_CNF_INPUT_Connect    << GPIO_PIN_CNF_INPUT_Pos)
                          | ((uint32_t)GPIO_PIN_CNF_PULL_Pullup      << GPIO_PIN_CNF_PULL_Pos)
                          | ((uint32_t)GPIO_PIN_CNF_DRIVE_S0S1       << GPIO_PIN_CNF_DRIVE_Pos)
                          | ((uint32_t)GPIO_PIN_CNF_SENSE_Low   << GPIO_PIN_CNF_SENSE_Pos);
  NRF_GPIOTE->INTENSET = GPIOTE_INTENSET_PORT_Msk;
  NVIC_EnableIRQ(GPIOTE_IRQn);
  delay(2000);
  NRF_RTC1->TASKS_STOP = 1;
}

void loop() {
  NRF_RADIO->TASKS_DISABLE = 1;
  NRF_CLOCK->TASKS_HFCLKSTOP = 1;
  __WFE();
  __SEV();
  __WFE();
}

void GPIOTE_IRQHandler(void)
{
  // This handler will be run after wakeup from system ON (GPIO wakeup)
  if (NRF_GPIOTE->EVENTS_PORT)
  {
    NRF_GPIOTE->EVENTS_PORT = 0;

  }
}

While delay(2000); consumes 4mA, after stopping RTC and HFCLK and going to sleep as expected consumes less than 10uA (my meter can't read less than that so it shows just 0).

• The same code adapted for use with mysensors library:

#define MY_RADIO_NRF5_ESB

#include <MySensors.h>

void setup()
{
  NRF_GPIO->PIN_CNF[10] = ((uint32_t)GPIO_PIN_CNF_DIR_Input        << GPIO_PIN_CNF_DIR_Pos)
                          | ((uint32_t)GPIO_PIN_CNF_INPUT_Connect    << GPIO_PIN_CNF_INPUT_Pos)
                          | ((uint32_t)GPIO_PIN_CNF_PULL_Pullup      << GPIO_PIN_CNF_PULL_Pos)
                          | ((uint32_t)GPIO_PIN_CNF_DRIVE_S0S1       << GPIO_PIN_CNF_DRIVE_Pos)
                          | ((uint32_t)GPIO_PIN_CNF_SENSE_Low   << GPIO_PIN_CNF_SENSE_Pos);
  NRF_GPIOTE->INTENSET = GPIOTE_INTENSET_PORT_Msk;
  NVIC_EnableIRQ(GPIOTE_IRQn);
}

void loop()
{
  transportDisable();
  NRF_POWER->TASKS_LOWPWR = 1;
  NRF_RTC1->TASKS_STOP = 1;
  MY_HW_RTC->POWER = 0;
  MY_HW_RTC->INTENCLR = RTC_INTENSET_COMPARE0_Msk;
  MY_HW_RTC->EVTENCLR = RTC_EVTENSET_COMPARE0_Msk;
  NRF_ADC->TASKS_STOP = 1;
  NRF_ADC->ENABLE = 0;
  NRF_CLOCK->TASKS_HFCLKSTOP = 1;
  NRF_UART0->TASKS_STOPRX = 1;
  NRF_UART0->TASKS_STOPTX = 1;
  NRF_UART0->TASKS_SUSPEND = 1;
  __WFE();
  __SEV();
  __WFE();
}

void GPIOTE_IRQHandler(void)
{
  // This handler will be run after wakeup from system ON (GPIO wakeup)
  if (NRF_GPIOTE->EVENTS_PORT)
  {
    NRF_GPIOTE->EVENTS_PORT = 0;

  }
}

I know that this code is wrong, as it doesn't enable peripherals after wake up, and it I just took chunks of code from different places trying to disable whatever is running by mysensors and consumes that extra current. So in sleep this code consumes 200-230uA.

All is running on WT15822 board like this:
It doesn't have 32KHz crystal, but I program it using "Crystal Oscillator" from board menu of nrf5 arduino core.
As far as I understand some of the periferals and/or interrupts and/or timers is used by Mysensors stack and doesn't shut down when going to sleep, so it tries to use RTC, which is not available, so it wokes HFCLK, so it consumes extra current. A lot more than it should in sleep mode.

I need help with this, as I am planning to build a bucnh of simple window sensors on this board and they doesn't require wake by timer, but will be woken by extrnal pin interrupt. But for now I just can't use Mysensors sleep function to do this, because as I have described it works not as expected. Hope to get some response from you guys.

[mfalkvidd]

Great work @monte, thanks for sharing.

Just to set your expectations correctly: Very few MySensors users have tried nrf5 so far, so the combined experience is quite low. Hopefully someone has an idea on how to help you, but it could very well be that you're the community's most experienced user in this area thanks to your work.

[Nca78]

@monte thé HFCLK is on because of a hardware bug in nrf51822 when you want to wake up using pin interrupt. You have to use PORT interrupt to go really low (around 5uA).

I made some (dirty) test code to validate that with MySensors but there was not much interest in that in the forum so I switched to something else. I will not use nrf51822 but nrf52832/40, they became really cheap now and don't have this hardware bug.

[NeverDie]

@nca78 By the way, were you ever able to get multiple different interrupts working?

Here we are a year later, and I guess there's still no final silicon for the nRF52840?

[Nca78]

@neverdie it works with the code I posted.

There are a few modules available with nrf52840 now so I guess final silicon is out. But it's only available in WCSP format I think so you won't see the chip alone.

[Jokgi]

@nca78 The Rev C (COO) parts are available now and they are the production parts. (Symmetry and Nordic's other distributors have these in stock) There will be a respin of this to a Rev D to fix the REG0 issue. FYI, the current nRF52840 package is not a WCSP. It is a aQFN package. The nRF52840-Dongle is also available now. Go forth and design......

[monte]

@nca78 well, after 2 nights of intense trying and failing I've got code to work as expected. And yes, it works with PORT interrupt, its kinda more code for you to write in compare to simply using attachInterrupt function, but I'm okay with that. For me double the price of 52832 compared to 51822 is significant. And for now, for a simple sensor stuff as we do with mysensors I don't really see any advantages except that interrupt bug fixed.
Also I've found that Mysensors sleep function for nrf5 is missing one very important command, I don't know why, maybe it is nrf51822 specific and thus @d00616 missed it but in current version of Mysensors library it doesn't disable UART before sleep, that's why I was getting 120-200uA current during sleep. I still don't really know how to make pull requests on github, so I guess I will just post it here:
line 290 of MyHwNRF5.cpp should contain: NRF_UART0->ENABLE=0; and line 327: NRF_UART0->ENABLE=1; respectively. That completely disables UART on nrf51822.
I will post my complete sketch later, when I will finish it, maybe someone who strugles as I did will find it useful. Also I think we need to somehow combine all examples that were posted in this thread or at least put a list of them with links, because looking through 1654 posts is not an easy task, especially if you not sure what you are looking for exactly.

[smilvert]

@monte But you solve your issue with the WT15822 board? Can you please share your sketch?

Is the range good of the WT15822 board?

I have started sketching to create a couple of new simple temp / hum sensors (WT15822, si7021 and cr2032) and want to know if I can use WT15822 before I order a pcb

[monte]

@smilvert I think I solved issues I mentioned. But I don't have final code yet as I am waiting for parts to arrive for my board. But I think there is no problem using WT51822 board except that you'll have to manually set PORT interrupt and also set pin SENSE register which is cannot be done with arduino function pinMode().
So I guess you can order PCBs if you want, I'm going to post final sketch with explanations at the end of the month.

[Omemanti]

Hey,

I got an issue with getting my custom board with SI7021 under 450uA.

• Ebyte 52832

I use the Sparkfun library to read data from it

I did some deductions.

• When I insert sensor.begin(); it starts using quite an amount of power when sleeping.

• When I remove this line it shoots down to around the 10ua.

• I tried 2 board, that are identical, with exactly the same results

This happens also when I use this code on a board that doesn't have a SI7021 soldered onto it. So I don't think it is the SI7021.
SDA/SCL are both connected with a 10K pull-up.

My guess is that is has something to do with it being a thing with the NRF.

the readings from the SI7021 seem legit, so it works, but the sleep current wrecks my battery life.

Is there someone that can help me with this?

The same old story, when you finally go looking for help, you find your answer.
It indeed looks like it has something to do with the NRF52.
as mentioned: https://github.com/sandeepmistry/arduino-nRF5/issues/291#issuecomment-407492282

A workaround for the symptoms is known and described at:
http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.Rev1.errata%2Fanomaly_832_89.html&cp=2_2_1_0_1_26

Solution:

you need to add the following lines to shutdown the i2c:

NRF_TWI1->ENABLE=TWI_ENABLE_ENABLE_Disabled << TWI_ENABLE_ENABLE_Pos;
*(volatile uint32_t *)0x40004FFC = 0;
*(volatile uint32_t *)0x40004FFC;
*(volatile uint32_t *)0x40004FFC = 1;

And when you need some readings, just call "sensor.begin(); " to go on your way.

I measure 00.01 mA now, (multimeter doesnt go into the uA ranges )

Maybe @d00616, or someone else can work this into a standard routine (this is way out of my league, i can dump it into my sketch, but dont have a clue what it is doing)

[monte]

@omemanti It seems like some peripherals are not shut down before sleep. As library you've mentioned uses Wire library, it must be TWI (i2c) interface that are active during sleep and consumes extra power. I'm afraid that you will have to manually disable/enable TWI around sleep routine.
EDIT: I see you've found an answer by yourself. Just want to clarify that it isn't nrf5 chip's fault, it just how it intended to work. It doesn't automagically disable all peripherals during sleep. So, someone should write low current sleep library for nrf5 specifically, that will check the state of peripherals before sleep and disable them if needed.

[NeverDie]

Anyone played around with Nordic's nRF52840 dongle? They're $10 each, and a few places have them in stock.
https://www.nordicsemi.com/eng/Products/nRF52840-Dongle

Nordic finally has a v1.0 product specification for the nRF52840, not just the silly v0.5 that they had posted for so long. http://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.0.pdf

It has 256K RAM and 1MB of flash. I'm having difficulty imagining which applications would require that much of either one. If it were free, that would be great, but I'm afraid the large RAM becomes an energy drain. For instance, it consumes 3.16µA with System ON, full 256 kB RAM retention, and wake on RTC.

On the other hand, it consumes 0.4uA of current if System OFF, no RAM retention, and wake on reset

It consumes 16.4ma if transmitting at full power (8dBm) with DC-DC engaged.

If compared to LoRa, it's going to lose on range. However, the question is: will it be good enough in a large or otherwise difficult home environment? The specs say it should be better than either nRF24L01 and nRF52832, which seem better suited to smaller dwellings. Maybe (?) the question can be answered with a couple of dongles.

[Nca78]

@neverdie I want to, but only shop that can send me with free shipping (and not 75$ like the others) is Arrow, and it's not yet in stock there.
CDEByte sells some too now ... but with a small form factor & ceramic antenna, I'm afraid it will waste all the theoretical extra range...

[NeverDie]

I guess maybe in your case the next best alternative would be the Fanstel nRF52840 modules, which should be drop-in upgrades to whatever PCB designs you may have had that used the Fanstel nRF52832 modules. I had previously posted a few:
https://www.openhardware.io/view/499/10-years-wireless-PIR-Sensor-on-just-one-set-of-3-AAs
https://www.openhardware.io/view/491/PA-LNA-nRF52832-ESP-LINK-Shield-for-Wemos-D1-Mini-ESP8266
https://www.openhardware.io/view/489/BT832X-Power-Amplified-nRF52832-Remote-Control-with-LNA
Fortunately, the remote control I posted would still consume zero current when not in use even with the nRF52840.

I guess that PPI is unique to Nordic. I had previously supposed it was a part of the generic ARM chip design, but I didn't see it when I looked into the STM32 chips.

[NeverDie]

Come to think of it: with so much flash and RAM, I bet the nRF52840 could easily run micro Python. Now that would be interesting!

[Uhrheber]

@neverdie
In fact it can.
Adafruit has a build of their Circuitpython (Micropython fork) for the nrf52832, and there's already an early alpha for the nrf52840.
As the 52840 has native USB, they can use Micropython as it was originally intended to be, with a virtual USB drive that contains all the user code files.

[NeverDie]

@uhrheber Can it run as a USB host? Because then (with a sex change) you could maybe plug it into a USB drive and have a nice little computer.

[Uhrheber]

@neverdie No, device only.

But another thought: This thing has USB, NFC, an AES and SHA accelerator, secure storage, secure boot, random number generator, and Bluetooth.

So it would make a nice USB/NFC/Bluetooth FIDO/U2F security key!

[Uhrheber]

@neverdie said in nRF5 action!:

It has 256K RAM and 1MB of flash. I'm having difficulty imagining which applications would require that much of either one.

Bluetooth 5

[Uhrheber]

@jokgi Someone said 800 to 1000m.
https://www.reddit.com/r/electronics/comments/9b3xhv/a_simple_nrf52840_breakout_board/

[NeverDie]

I suppose plugging the Nordic dongle into a Raspberry Pi via USB would potentially make a powerful gateway with a very easy setup.

[NeverDie]

Anyone know if the dongle has a USB bootloader on it so that you can upload a sketch over the USB?

[Edit: apparently, the answer is yes: http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52%2Fdita%2Fnrf52%2Fdevelopment%2Fnrf52840_dongle%2Fgetting_started.html ]

[alowhum]

A plug and play dongle.. now there's something. A controller could theoretically take care of all the work - a user just has to plugin the dongle and it flashes it, installs mysensors..

I read it can also support Zigbee and Bluetooth. Could it support Zigbee, bluetooth and MySensors at the same time?

Wow, plug that into a Pi Zero and you have a capable controller for a smart home.

[alowhum]

This looks like an Arduino-nano/pro-mini style device with an NRF51:

https://www.aliexpress.com/item/Nrf51822-LIS3DH-Bluetooth-Module-CJMCU-8223-Bluetooth-acceleration-module/32821873481.html

[NeverDie]

Maybe this is old news, but it looks like Adafruit put together a nice board and software for the nRF2832. https://www.adafruit.com/product/3406

[NeverDie]

I'd like to take a crack at prograamming the nRF52840. Has anyone here tried it? I'm not sure whether the software support for it is in place yet or not. How best to get started with it? As far as compiling and uploading code goes, do I just treat it the same as an nRF2832?

[heinzv]

@neverdie I have ordered 10x nRF52832 and 2x nRF52840 from EBYTE (E73-xxxB/C). I will join you once I got them (they are on they way since 2 weeks). I'll also work together with ransyer to get new PCB's (the last we maybe together are for the ESP32).
I'm curious what distance I can get indoor with the BLE 4.2/5.0 (no extra radio) and if required, I will combine it with a LoRA RFM95 (that is also what our PCB's is made for RFM69/95 and CC1101).
I'm still working on the sensor with the 1,54" ePaper (where the ATMEGA328p is lost with its 32kB flash and even worse with the 2k RAM)

https://de.aliexpress.com/item/CDEBYTE-E73-2G4M04S-BLE-4-2-5-0-long-distance-100m-2-4GHz-SMD-ARM-Core/32820692238.html?spm=a2g0s.9042311.0.0.60a94c4dZdIUhQ

this one will be tricky to solder (I'm trying to get something better to solder)
https://de.aliexpress.com/item/NRF52840-Bluetooth-5-0-240-mhz-RF-Transceiver-CDSENET-E73-2G4M08S1C-8dbm-Keramik-Antenne-BLE-4/32906661666.html?spm=a2g0s.9042311.0.0.1d174c4dKW9mAo

[NeverDie]

@heinzv Well, great, the more the merrier.

[Nca78]

@heinzv said in nRF5 action!:

this one will be tricky to solder (I'm trying to get something better to solder)
https://de.aliexpress.com/item/NRF52840-Bluetooth-5-0-240-mhz-RF-Transceiver-CDSENET-E73-2G4M08S1C-8dbm-Keramik-Antenne-BLE-4/32906661666.html?spm=a2g0s.9042311.0.0.1d174c4dKW9mAo

Already out of stock it seems, it's not possible to order them any more.
They seem to have both 32K crystal and inductances for DCDC, that's pretty convenient.

[NeverDie]

The answer I got on the Sandeep library made it sound rather iffy as to whether it would work for the nRF52840: https://github.com/sandeepmistry/arduino-nRF5/issues/310
or that the coverage might be rather spotty.

So, I think I may give mbed a try for programming the nRF52840, because mbed claims to support the nRF52840-DK. Also, I found what seems like a nice and simple youtube tutorial series for how to use mbed: https://www.youtube.com/watch?v=kP_zHbC_5eM

If I have success with mbed, I may circle back to the Sandeep library and the mysensors implementation, but I'd like to start with something solid, and it appears that mbed might be.

The other nice thing is that it appears mbed provides an abstraction layer which makes easy to program a whole range of different mcu's, incuding many of the stm32's.

Anyone here familiar with or tried mbed before?

[mfalkvidd]

@neverdie I tried mbed briefly in a workshop on LoRaWAN FOTA. With the workshop instructions it was easy to use, but my impression is that Arduino has a much larger ecosystem with more libraries.

[NeverDie]

Update:
I received some nRF52840 dongles. I confirmed with Nordic that the recommended way to program them over USB is to use nRF Connect v2.5.0 which contains the nRF Programmer v1.0.0-experimental.5 application. I tried that, but I may have somehow bricked my first dongle by not pressing reset first before the upload. Either that, or because my simple program didn't initialize the USB, maybe it can't be found for that reason (I suspect so).

Luckily, I live not too far from Mouser. I should be receiving the nRF52840-DK today, so I figure that way I can unbrick the dongle.

Yesterday I played around with mbed on an nucleo board. Seems to work well (no bricking). Unfortunately, the dongle isn't an mbed device, so the methods above are required unless you program it with a DK or similar. The good news, though, is that the DK is an mbed board, so hopefully that will be smooth sailing. It turns out that USB is built into the nRF52840 chip, so it doesn't require a separate chip like a CP2102 to communicate over USB. I guess that can be good or bad depending on how your write your code.

[NeverDie]

By the way, the nRF52840-DK is even easier to program thant the nRF52832-DK. When you attach it to your PC, it shows as an additional drive in your directory. Any hex file that you copy to that drive gets uploaded and programmed onto the nRF52840. Easy.

[mfalkvidd]

@neverdie that’s how we programmed the device in the workshop as well. Very neat.

[NeverDie]

Luckily, it looks as though I can manually set any GPIO pin I want as the UART TX pin for debugging output from an nRF52840 by setting PSEL.TXD. That means I can probably re-use my PCB's from nRF52832 for the nRF52840 with just a few software adjustments even if I use mbed without the convenient pin mapping afforded by the mysensors code. So, this is starting to look more and more feasible.

[smilvert]

@NeverDie How do I know which nRF52832 board I should use?

Does the CFsunbird-nRF52832 has the DC/DC inductors?
Or can I use nRF51822?

Want a cheap chip, easy to solder (Have a couple of Ebyte e-73 but they take some time to solder and if I understand correctly, the DC / DC inductors are missing?)

[NeverDie]

@smilvert It really depends on what you want to do, but if you want a blanket recommendation, I would recommend the Fanstel modules. For one thing, they're FCC approved, and most of what you'll find on aliexpress isn't and probably wouldn't pass if it tried.

Also, the Fanstel F series has superior range compared to anything I've ever found on Aliexpress.

[NeverDie]

Even better, it turns out mbed solves the problem of handling multiple different interrupts, which no one here could figure out with the sandeep build. With mbed, it looks pretty simple in fact:

InterruptIn button1(P0_11);//(USER_BUTTON nRF52840 DK);
InterruptIn button2(P0_12);
InterruptIn button3(P0_24);
InterruptIn button4(P0_25);

void button1_pressed()
{
  led1 = led2 =led3 =led4 = 1;
  led1 = 0;
  
}

void button1_released()
{
  led1 = led2 =led3 =led4 = 1;
  //led1 = 0;
}

void button2_pressed()
{
  led1 = led2 =led3 =led4 = 1;
  led2 = 0;
  
}

void button2_released()
{
  led1 = led2 =led3 =led4 = 1;
  //led1 = 0;
}

void button3_pressed()
{
  led1 = led2 =led3 =led4 = 1;
  led3 = 0;
 // wait(0.1);
}

void button3_released()
{
  led1 = led2 =led3 =led4 = 1;
  //led1 = 0;
}

void button4_pressed()
{
  led1 = led2 =led3 =led4 = 1;
  led4 = 0;
  
}

void button4_released()
{
  led1 = led2 =led3 =led4 = 1;
  //led1 = 0;
}

int main() {
    led1 = led2 =led3 =led4 = 0;
    
    button1.fall(&button1_pressed);
    button1.rise(&button1_released);
    
    button2.fall(&button2_pressed);
    button2.rise(&button2_released);

    button3.fall(&button3_pressed);
    button3.rise(&button3_released);

    button4.fall(&button4_pressed);
    button4.rise(&button4_released);

   while (true) {}
}

[Nca78]

@neverdie said in nRF5 action!:

By the way, the nRF52840-DK is even easier to program thant the nRF52832-DK. When you attach it to your PC, it shows as an additional drive in your directory. Any hex file that you copy to that drive gets uploaded and programmed onto the nRF52840. Easy.

That's exactly what I'm doing with the NRF52832-DK already. How do you program yours ?

[NeverDie]

@nca78 IIRC, with nRF52832-DK I was using the arduino IDE to program it using the J-link programmer. Anyhow, that's now ancient history.

[smilvert]

@neverdie Im guessing that the BT832 dosen't have the 32.768 khz crystal but the inductors?

The datasheet says

Standby current consumption is important for battery-powered product. We suggest adding a 32.768 kHz crystal 
and 2 capacitors as shown in the upper left corner of the evaluation board schematics. The 32MHz main clock 
won’t be active at idle state to save power.

Two inductors required for DCDC converter are inside BT832 module. You can enable DCDC to lower
power consumption.

[scalz]

@NeverDie
cool. already tried it too. and i agree with you on this, arduino is fun at the beginning, but then you discover its limits. compatible with lot of things but incomplete That said, then you may end up converting some of your arduino libs/stuff to the new toolchain. On my side I like TI toolchain (free, tailored for iot with lot of nice tools, for debugging etc), not using it for nrf of course..
On other side, arduino is maybe "easier" to read for someone discovering coding.

[NeverDie]

@scalz said in nRF5 action!:

@NeverDie
cool. already tried it too. and i agree with you on this, arduino is fun at the beginning, but then you discover its limits. compatible with lot of things but incomplete That said, then you may end up converting some of your arduino libs/stuff to the new toolchain. On my side I like TI toolchain (free, tailored for iot with lot of nice tools, for debugging etc), not using it for nrf of course..
On other side, arduino is maybe "easier" to read for someone discovering coding.

Interesting! Does that mean you're using TI's' MSP430 as your primary mcu now?

[NeverDie]

@smilvert said in nRF5 action!:

@neverdie Im guessing that the BT832 dosen't have the 32.768 khz crystal but the inductors?

The datasheet says

Standby current consumption is important for battery-powered product. We suggest adding a 32.768 kHz crystal 
and 2 capacitors as shown in the upper left corner of the evaluation board schematics. The 32MHz main clock 
won’t be active at idle state to save power.

Two inductors required for DCDC converter are inside BT832 module. You can enable DCDC to lower
power consumption.

yup

[scalz]

@neverdie said in nRF5 action!:

Interesting! Does that mean you're using TI's' MSP430 as your primary mcu now?

nope, as usual I prefer the very best 430 isn't rf.
But I don't want to make OT (nrf, mysensors). just said this to say, you can usually get all power of a mcu by using the right tools like you noticed (pros&cons)

[NeverDie]

Unfortunately, the problemm with mbed is that it provides no real support for using the nRF52 radio in proprietary modes. I would have to code all of that from scratch.

[NeverDie]

Good news. I hadn't bricked the dongle after all. Yesterday I wrote some rather primitive code to send packets using the Nordic proprietary code and this morning I loaded it onto the dongle using its USB connector and USB Bootloader. I'm now receiving the packets on the nRF52840-DK, so that satisfies proof of concept. i.e. it works!

[NeverDie]

Even better news! The range is quite good. Not as awesome as my LoRa modules, but at 1mbps (I haven't yet tried 2mbps) and 8db Tx power, it easily beats the range of the nRF52832 for a comparable setup. So, to be fair, the LoRa's can use quite a bit more Tx power, and the LoRa datarate is far slower, so the nRF52840's seem likely to be quite a bit more energy efficient than LoRa for a home environment.

There is a 250Kbps speed available if using the 802.11.15 mode (which I haven't yet explored), and it should have even better range than the regular Nordic proprietary modes (of which there are only two: 1mbps, and 2mbps). IIRC, 802.11.15 can automatically handle retransmits and the like, and it's a proven standard. It likely handles a lot of the drudgery.

Then there's Thread, which is new to me but which it also supports and which is intended for home automation.

It has built in hardware acceleration for SHA256, which is pretty cool. CRC is handled by hardware too. Also, lots of crypto stuff for those who are into that.

So, although these are just early results, so far I'm liking it. In contrast, I was rather disappointed in the range of the nRF52832's (even though they were better than the range of an unamplified nRF24L01).

[alowhum]

Now if they could put it in a maker friendly package..

[NeverDie]

@alowhum I don't think Nordic ever will, though for the $10 price the dongle comes pretty close, except for the limited castellated pinout, which is inconvenient though nicely small. I'm quite sure Adafruit and Sparkfun and maybe some others will though. I think from a purely hardware point of view it pretty much blows away the Arduinos since it includes an integrated radio and is low power and has the huge flash and memory and all the other goodies.

[NeverDie]

I've started a new thread for everything related to nRF52840: https://forum.mysensors.org/topic/9717/everything-nrf52840

So, going forward, I'll mostly be posting there, unless it's for earlier products like the nRF52832 or the nRF51.

[alowhum]

This company has the cheapest arduino-ish board I've found.

It consists of a dev board..
https://www.aliexpress.com/item/NRF51822-2-4G-Wireless-Module-Wireless-Communication-Module-Bluetooth-module-zigbee-module-DMX512/32726191346.html

...and the little module you place in it:
https://www.aliexpress.com/item/NRF51822-2-4G-Wireless-Module-Wireless-Communication-Module-Bluetooth-module-zigbee-module-DMX512/32726191346.html

Total cost: about 13 euros.

[alowhum]

I just turned the BBC Micro:bit board into a MySensors repeater. No problem, went totally smooth.

The cheapest Micro-bit I've found is $18 on Aliexpress.

Lady Ada has a great PDF tutorial, full of little code snippets, to help you get started with all the onboard sensors it comes with.

[NeverDie]

@alowhum Thanks for your post. I just now looked on ebay, and there's an entire eco-system of little ad-ons for the micro bit! Lots of displays, buttons, sensors, power packs, etc.

I thought there would be a vast supply on ebay of cheap used BBC micro bits, but I didn't see any. Not sure, but maybe on the UK ebay they can be found. After all, I think a lot were given away for free initially by a magazine or something.

[alowhum]

Yes, a million were handed out to school children. And if you buy one now, one is given to a child (theoretically).

The ecosystem of attachment is indeed impressive. Parents who want their children to embrace and succeed in technology, there's quite some money to be made there.

[NeverDie]

Well, this is interesting: you can run micropython on your micro bit: https://www.amazon.com/dp/1260117588/ref=rdr_ext_tmb

[Omemanti]

Not sure if it is allowed, else I remove this post, but the nrf52832's at ebyte are for sale (50% off)the coming 2 days.cdebyte AliExpress I sure grab myself some (max 2 at a time, but last time I ordered multiple times :)) only €2,62 a piece

[NeverDie]

@omemanti said in nRF5 action!:

Not sure if it is allowed, else I remove this post, but the nrf52832's at ebyte are for sale (50% off)the coming 2 days.cdebyte AliExpress I sure grab myself some (max 2 at a time, but last time I ordered multiple times :)) only €2,62 a piece

Your post is perfectly fine, and I would even encourage it. It makes good sense to share tips like that.

The funny thing is that the 50% price is, IIRC, close to what the original price was when it was first introduced. Then the price slowly crept up from there.

[Omemanti]

@neverdie well, July 2017 they were €4,15. So they went up around 1 euro in a year. FYI the last one I bought was about 5 months ago since then they went up from version 1,1 to 1,3.
Also, the item number changed a bit (but the datasheet checks out).
It went from E73-2G4M04S to E73-2G4M04S1B, and the introduced a nrf52810 E73-2G4M04S1A with the same footprint and pinout.

[NeverDie]

@omemanti Ah, yes, you're right. It was on March 7, 2018 that they were on sale for $2.55.

Well, regardless, it's a good price.

[Nca78]

@omemanti the A version is with NRF52810, be careful.

[smilvert]

@neverdie Sorry, im a bit confused.

If im are going to use the BT832 for a battery sensor do I need to connet a 32 khz crystal like you did on the 10+ years wireless PIR Sensor (on just one set of 3 AA's!) project? But you have also written:
@neverdie said in nRF5 action!:

@alowhum IIRC, the crystal oscillator is only required by Bluetooth. For everything else, the internal resonator is sufficient.

How much more current are used if the crystal is not connected?

Can I use P00/P01 as a data pin instead of using the crystal?

[NeverDie]

You don't need the crystal. Not sure difference in current. Yes, to your last question.

[Omemanti]

@nca78 yeah I noticed that, what is the downside of the NRF52810?

[Nca78]

@omemanti said in nRF5 action!:

@nca78 yeah I noticed that, what is the downside of the NRF52810?

At least lower memory (ram and flash) and I don't know for the peripherals. Not sure if the core for nrf52832 will work flawlessly or not. Given the tiny price difference it's better to stick to nrf52832.

Low frequency crystal will make you save energy when you use Bluetooth, because it needs to wake up at precise time frames to send/receive data. Do in that case the internal oscillator is not precise enough and mcu has to wake up regularly to recalibrate it with high frequency clock.
For MySensors, it's not useful.

[Jokgi]

@nca78 There is no downside to using the nRF52810. It depends on your needs. If you can live with 192K Flash and 24K RAM and a stack that supports peripheral only (at this time) then you are good. The device can use the internal 32Khz RC osc for BTLE and there is a slight current consumption hit as the receive window will be longer. (+/- 500ppm) . No different then on the nRF52832. as stated, a 32Khz crystal will give you a tighter clock and lower current consumption.

This is a scaled down version of the nRF52832 so there are some peripherals that have been taken out or reduced. PWM for example, only one. No NFC, 1x SPI Master or Slave, (instead of 3), No I2s...... The full datasheet and product briefs are available on Nordic's website so you can A-B the features.

[Jokgi]

This post is deleted!

[NeverDie]

An amusing video, which nonetheless suggests the power of tapping into existing bluetooth devices:

nRFready Smart Remote 3 for nRF52 Series – 02:08
— Nordic Semiconductor

[Omemanti]

What are the options of getting OTA working? Is it supported? Or is it still work in progress? (If so, ia there an ETA?)

[NeverDie]

@omemanti said in nRF5 action!:

What are the options of getting OTA working? Is it supported? Or is it still work in progress? (If so, ia there an ETA?)

https://devzone.nordicsemi.com/f/nordic-q-a/38936/is-there-an-easier-to-use-ota-firmware-uploader

[NeverDie]

These are a bit cheaper than the Ebyte modules, and the breakout board is already built-in: https://www.aliexpress.com/item/NRF52832-Bluetooth-Module-BLE-4-2-Low-Power-Bluetooth-External-Antenna-IPEX-Support-Multi-Protocol/32904197412.html?spm=2114.search0104.3.102.772c16a3Fm2Lp8&ws_ab_test=searchweb0_0,searchweb201602_2_10065_10068_10130_10547_10546_10059_10884_10548_315_10545_10887_10696_100031_10084_531_10083_10103_10618_10307_449,searchweb201603_60,ppcSwitch_0&algo_expid=f8654a20-dd6e-4042-987f-5bd9eaf3c58d-15&algo_pvid=f8654a20-dd6e-4042-987f-5bd9eaf3c58d&transAbTest=ae803_4&priceBeautifyAB=0

[Jokgi]

@neverdie And it has the 32Khz crystal on it too which will reduce power consumption. And It looks like the DC/DC converter is also included?

[Toyman]

Guys, remind me pls: is CR2450 enough for the nrf52 Ebyte module acting as a Mysensors node?
Is it capable to handle tx current spikes?
Energizer datasheet states 9ma as max curent pulse. Is it sufficient?

[Toyman]

@neverdie I've setup the bootloader for my BT project and I confirm its much easier than it looks.
Can it be used for MySensors? For BT, I create a hex file in Keil and then upload it via nrftoolbox app.
Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

[scalz]

@toyman said in nRF5 action!:

Guys, remind me pls: is CR2450 enough for the nrf52 Ebyte module acting as a Mysensors node?
Is it capable to handle tx current spikes?
Energizer datasheet states 9ma as max curent pulse. Is it sufficient?

yes but you need some power buffer for the spikes. So put 100uF low leakage ceramic capa close to batt holder, and you could also add one more close to your nrf5 module.

Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

You already have your answer I think

[NeverDie]

@toyman said in nRF5 action!:

Can the same procedure be used with MySensors? OTA needs Softdevice and Softdevice is not compatible with MySensors

Ouch. That does seem like a gotcha. Thanks for pointing that out!

Let's enumerate the possible remedies:

1. I guess theoretically the bootloader could use softdevice to handle uploads and then revert to MySensors afterward. After all, with these devices there's so much flash and memory that there's nothing which says the bootloader needs to be tiny. In that case your code would need to force a reboot, and the bootloader would need to wait a period of time to see if an OTA upload is being requested before continuing. But this is all theoretical, and I don't know enough to know whether that would be easy or difficult to make work. Far from elegant to be sure. Maybe there's a better solution than that? Admittedly, this looks like a rabbit hole I'd rather not go down.

2. Maybe (?) micropython is the the easier path out of this train wreck, assuming (?) it can assemble a string that it reads from OTA and then execute it (EVAL it) the way that. say, LISP, can. Then you could bypass softdevice entirely and use whatever radio communications you want. The relative ease of that might make it worth the added baggage of running an interpreter. Well, that might work for me, but for mysensors it would mean a major port to micropython, which, AFAIK, no one has yet done.

3. That leaves writing your own wireless bootloader, like I guess others here have done for mysensors and the atmega328p, but that doesn't sound trivial either.

4. Any other ideas?

I'm just thinking out loud here and above, but I'm admittedly now both stymied and flummoxed. Being wireless without the ability to do wireless updates is not good.

@scalz Does the TI platform have the same sort of issue, or does it handle OTA updates differently?

[NeverDie]

For instance, this buttonless approach stays in DFU mode for 30 seconds after a reset: https://thingtype.com/blog/dfu-ota-updating-an-nrf52-application-over-the-air/

I guess maybe that's the shortest path out of this dilemma.

[monte]

@neverdie but all those bootloaders rely on bluetooth (thus softdevice) for DFU, that means we need to write our custom bootloader which uses different transport.

[NeverDie]

@monte said in nRF5 action!:

@neverdie but all those bootloaders rely on bluetooth (thus softdevice) for DFU, that means we need to write our custom bootloader which uses different transport.

In a perfect world, yes. However, since that doesn't yet exist, the question is: what else, if anything, can be done today?

[Nca78]

@neverdie said in nRF5 action!:

In a perfect world, yes. However, since that doesn't yet exist, the question is: what else, if anything, can be done today?

Today is either use bluetooth/ant/thread (all need softdevice) or write your own OTA bootloader for legacy radio without softdevice.

[NeverDie]

Looks as though micropython does support the bluetooth stack for both nRF52832 and nRF52840: https://github.com/micropython/micropython/tree/master/ports/nrf

Micropython also runs on the nRF51, but apparently (judging from the BBC micro:bit), there's not also enough extra space to also support the bluetooth at the same time on the nr51.

[Uhrheber]

@neverdie Speaking of micropython: Adafruits fork of micropython (called circuitpython) now also supports the nRF52840. The also added the nRF52840 dongle as make target (pca10059). After compiling, you can use nRF Connect to flash the hex file to the dongle, via the stock USB DFU bootloader, so you don't need an extra programmer.

I like that dongle, it's cheap yet powerful, and it may be the smallest micropython-capable board with native USB. Native USB is nice, because in this case it has not only a serial REPL, but also a virtual drive with the code files, like the original pyboard.

[NeverDie]

After running through a gauntlet, I managed to get micropython running on the nRF52832-DK! I posted the firmware here: https://forum.micropython.org/viewtopic.php?f=2&t=5343&p=30756#p30756 to spare anyone else from running the same gauntlet. Just copy the firmware.hex file directly to the nRF52832-DK drive on your PC, and it will upload automatically to the DK and start running micropython. )

[Toyman]

@neverdie what are potential advantages of micropython?

[NeverDie]

@toyman OTA updates.

[Toyman]

@neverdie I am afraid it still relies on Softdevice

[monte]

@toyman no, if your code is in python. So the deal is "just" to port mysensors to python.

[NeverDie]

@toyman Micropython on the BBC micro:bit (which uses the nRF51822) has a Radio library that uses Nordic's proprietary radio modes and doesn't involve Bluetooth. I suppose the question is: what would be involved in getting it to run on the nRF52832 or the nRF52840. Seems like it would be substantially the same.

Faiing that, if I can directly manipulate the radio registers from miropython as I can from C, then it shouldn't be too hard to get at least minimal radio capability up and running from within micropython.

If I can get rudimentary radio communications working in micropython, then from there it should be easy to do OTA updates via REPL. I did some proof of concept to that effect on the micro:bit, but quickly ran out of memory--the micro:bit has only a total of 16K of RAM, so there's very little headroom to begin with. On the nRF52840, lack of RAM shouldn't be an issue.

[NeverDie]

@scalz hinted at it previously, but it looks like MyNewt OS might offer yet another way to do OTA updates. According to their posted information, it offers:

A open-source Bluetooth 5.0 stack (both Host & Controller), NimBLE, that completely replaces the proprietary SoftDevice on Nordic chipsets. (https://github.com/apache/mynewt-core/blob/master/README.md)

Apparentlly it runs on both the nRF52832 and the nRF52840.

[speechsupply]

@neverdie
1737 posts and counting
Spend hours reading this. Amazing journey so far.

[Uhrheber]

@neverdie There are three ways to manipulate registers directly from Micropython:

1. Use machine.mem16

2. Use the decorator @micropython_viper
   The Viper code emitter implements integer types and pointers, allowing to access memory and registers directly.

3. Use the decorator @micropython.asm_thumb
   Write your code in ARM assembler.

Problem: I don't know whether any of this is already implemented and works reliably in Micropython for nRF.

[Toyman]

@speechsupply this thread is golden. I was so empowered that was able to easily switch to nRF SDK and to start producing (semi) commercial BLE-ANT device

[speechsupply]

@toyman
Yea, On monday I'll order a couple of nRF52840 EVAL boards. Any suggestion regarding what to get?
Looked at both the BMD-340-EVAL and ofcourse the NRF52840-DK

[NeverDie]

@uhrheber said in nRF5 action!:

@neverdie There are three ways to manipulate registers directly from Micropython:

1. Use machine.mem16

2. Use the decorator @micropython_viper
   The Viper code emitter implements integer types and pointers, allowing to access memory and registers directly.

3. Use the decorator @micropython.asm_thumb
   Write your code in ARM assembler.

Problem: I don't know whether any of this is already implemented and works reliably in Micropython for nRF.

Thanks! We finally nailed it all the way down on this thread here: https://forum.micropython.org/viewtopic.php?f=12&t=5377

[Omemanti]

I see somewhat strange behaviour when using millis() for intervals.

I'm not sure it's my mistake, but one thing is that it seems that the millis rollover is around; 131.068.570 (36 hours)

When the rollover happens, it looks like it interrupts my sleep. Does that make sense?

sleep(digitalPinToInterrupt(PIR_Pin), CHANGE, LongSleep); 

Debug lines => (Temp / RH - Millis)

21.44 / 61.15 - 130977952
21.43 / 61.16 - 131008158
21.42 / 61.15 - 131038364
21.44 / 61.14 - 131068570
I woke up because I saw movement at: 26576
Sleep Duration : -131042000  Im going back to sleep for 150000       
21.43 / 61.16 - 176822

20-10-2018 => its been ±36 hours laters, and he woke up again at the same moment.

18.57 / 56.88 - 131007553
18.56 / 56.86 - 131037759
18.58 / 56.85 - 131067965
I woke up because I saw movement at: 25971
Sleep duration : -131042000 => Rollover??
18.55 / 56.89 - 206423
18.53 / 56.89 - 236628
18.54 / 56.90 - 266834
18.55 / 56.89 - 297040
18.54 / 56.90 - 327246

[Omemanti]

@maciekczwa said in nRF5 action!:

Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.241270
Info : nrf52.cpu: hardware has 0 breakpoints, 2 watchpoints
Error: timed out while waiting for target halted
TARGET: nrf52.cpu - Not halted
in procedure 'program'
in procedure 'reset' called at file "embedded:startup.tcl", line 478
in procedure 'ocd_bouncer'

**embedded:startup.tcl:454: Error: ** Unable to reset target ****
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 479
at file "embedded:startup.tcl", line 454
wybrany port szeregowy at file "embedded:startup.tcl", line 454

maybe someone else already found the solution, but it took me a while to figure it out for myself.

So for documentation sake:

Just had the exact same things with new Ebyte NRF52832 modules, ST-Link v2 couldn't erase it. (the old once did erase without a single problem )

After some digging, I found the following:
(I'm using my NRF52832-DK for it, maybe other devices work as well, just tested this one)

DK => Ebyte module
GND(detect) => GND
SWDIO => SWDIO
SWDCLK => SWCLK
VTG => 3,3V
3,3V => 3,3V
GND =>GND

you can erase the protection using nRFgo Studio

1. On the left, you can find a header named Segger, click on that.
2. then it shows that it is locked, and you can click recover.
3. after that you can erase it
4. upload a new sketch using an ST-link V2 or the DK while you are still at it.

[alowhum]

@alowhum said in nRF5 action!:

This looks like an Arduino-nano/pro-mini style device with an NRF51:

https://www.aliexpress.com/item/Nrf51822-LIS3DH-Bluetooth-Module-CJMCU-8223-Bluetooth-acceleration-module/32821873481.html

I tried uploading a simple blink sketch today. I found some code on github which suggested pin 23 and 24 are LED pins.

I got an error uploading via STM32 though.

debug_level: 2
0x4000
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 10000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : Unable to match requested speed 10000 kHz, using 4000 kHz
Info : clock speed 4000 kHz
Info : STLINK v2 JTAG v17 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.233552
Warn : UNEXPECTED idcode: 0x0bb11477
Error: expected 1 of 1: 0x2ba01477
in procedure 'program'
in procedure 'init' called at file "embedded:startup.tcl", line 473
in procedure 'ocd_bouncer'
** OpenOCD init failed **
shutdown command invoked