nRF5 action!

scalz

@Toyman yep, this confirms what i said, not difficult to access.
I didn't read the description..just looking at the pcb layout was enough to tell me poor rf range + no basic usb spec design rules (latter point is maybe not the most critical for most of people, but it just shows 1) designer wasn't aware ?? 2) this is what you get for cheap money, whereas missing parts would have cost few cents..).
Just saying, because maybe this dongle can work well enough for some people.

Toyman

@scalz actually, it might be ideal as a REPEATER given the form-factor. You just insertt it into any cheap USB charger and voila.

scalz

@Toyman that's a valid point, sure. Here, I prefer to not have repeater as much as i can, else i switch to subghz ;)

Jokgi

This post is deleted!

NeverDie

@jokgi said in nRF5 action!:

@neverdie I would suggest holding off on purchasing a new nRF52840-PDK until the final silicon is released.

Oh! It's still not?

Jokgi

@scalz
I would be interested in any range testing in regard to this dongle. For ground it has whatever it is that it is plugged into. (PC, SBC, USB extention cable, etc) There will be a nRF52840 based dongle out soon. See picture above. This dongle will need to be programed over the SWD lines. No Segger on board this one..!

scalz

@Jokgi i'm not using usb dongle but it looks nice. (too bad 52840 is AQFN..)

Omemanti

@Nca78
Getting rid of the ground plains around the entire module hugely improved the range. Had to stap back to AAA batteries to fit on the board. But I'm happy with the way it's going (AA is still possible but not soldered on it just doesn't fit enough in the wall socket)

NeverDie

Very nice. Looks professional!

Toyman

Very nice indeed. I thought ground plains improve the range

Nca78

@toyman said in nRF5 action!:

Very nice indeed. I thought ground plains improve the range

He's talking about the ground plane around the nrf5 module, not on the full board ;)

gohan

@toyman they do, but not too close to the antenna 😀

Nca78

What about moving the PID-related discussion to a dedicated thread as this one is already excessively long and useful information will get lost soon ?

@neverdie said in nRF5 action!:

It was very hard to extrude it, so I always seemed to either underextrude or overstrude. I found it very hard to get the right amount exactly where it should go by just manually pressing the plunger on the solder paste syringe that the material came in.

Yes I had the same problem too... added with too old solder paste from my local shop :(
I just ordered a stencil together with my test PCB, I guess it's the way to go given the now very low prices of stencils (mini-stencils at 9.9$ at Seeed and I just paid 7$ + 2$ PCB at JLCPCB, same company than EasyEDA).

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?

nRF5 action!

13

11.7k

11.2k

113.0k