nRF5 action!

[NeverDie]

I was able to reduce the active listen period to about 100us:

Now listening every 100ms yields a 10F supercap voltage measured decline of just 9mv per hour. i.e. a decline of 0.108v by the end of 12 hours.

[d00616]

@Mike_Lemo said in nRF5 Bluetooth action!:

Also about the NFC I'm planning to use it with the arduino IDE so just wanted to ask if there is a library for it because the SDK is quite useless in this case as well as the Central peripheral connection.

Now there is a second port of arduino to nRF52. This includes some libraries, like NFC, but they using the SDK. MySensors is currently not ready for this arduino-port.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Now listening every 100ms yields a 10F supercap voltage measured decline of just 9mv per hour. i.e. a decline of 0.108v by the end of 12 hours.

Great job. If I'm not wrong the method allows nearly 1 year of listening time with a CR2032.

[Toyman]

@Mike_Lemo your best bet is to "convert" the module to Arduino Primo and use the NFC libraries developed for it.
d00616 gave you the link to the arduino org github. Pls. note that Primo core generates a merged softdevice+sketch hex so you should locate it in the Temp folder and upload.

[NeverDie]

Here's a very simple OPEN/CLOSE remote control I was able to quickly throw together using my small prototyping board:

It required only two buttons, a diode, a resistor, and (obviously) some wire. When not in use, everything is powered 100% OFF to save the most energy possible. So, pushing either button powers it ON, at which point it rapidly determines which button was pushed and then sends the corresponding packet to the receiver. From the standpoint of human perception, it all appears to happen instantly.

[NeverDie]

This is how the next version of the protoboard will look:

[NeverDie]

Interestingly, it looks as though Arduino is suggesting/recommending users to use the regular Arduino Primo to program the Arduino Primo Core (i.e. the wearable).

[Toyman]

@NeverDie is this SWD?

[NeverDie]

@Toyman said in nRF5 Bluetooth action!:

@NeverDie is this SWD?

I don't have either the Primo or the Primo Core, so I can't say for sure. However, I presume so.

[Uhrheber]

@Mike_Lemo
This sounds more like an EMC issue.
The connected ST Link filters some disturbance at the i2c lines, and when it's not connected, the disturbance corrupts the signals.
Try connecting capacitors from the i2c lines to ground. I'd start with 100pF each.
May also be a power supply issue. Did you connect the st-link's 3.3V line to the board?

[NeverDie]

Here's the small budget nRF51 soldered to the breakout board that I had linked earlier above:

[NeverDie]

I have the RTC running off the low frequency internal RC, because I don't see a crystal oscillator on the module. I have it blinking an LED now and sending text to the serial port, which I'm able to read on the serial console.

At least so far, all is good.

[Nca78]

@NeverDie said in nRF5 Bluetooth action!:

Here's a very simple OPEN/CLOSE remote control I was able to quickly throw together using my small prototyping board:

It required only two buttons, a diode, a resistor, and (obviously) some wire. When not in use, everything is powered 100% OFF to save the most energy possible. So, pushing either button powers it ON, at which point it rapidly determines which button was pushed and then sends the corresponding packet to the receiver. From the standpoint of human perception, it all appears to happen instantly.

Hello @NeverDie, could you please share the code for this ?
I'd like to adapt and test it on a reprogrammed nrf51822 beacon that I just received.

[NeverDie]

@Nca78
I can, but it wouldn't be proper "mysensors" code, because mysensors code has a 5-10 second power-up delay. So, for that reason, it's using radiohead instead. Do you still want it anyway?

[Nca78]

@NeverDie said in nRF5 Bluetooth action!:

@Nca78
I can, but it wouldn't be proper "mysensors" code, because mysensors code has a 5-10 second power-up delay. So, for that reason, it's using radiohead instead. Do you still want it anyway?

Ah I see, probably still interesting to see, please share anyway

[Toyman]

I am trying to reprogram a commercial nrf51 module. Under "commerical" I mean "not from aliexpress", but installed in "smart" bluetooth socket.
I can connect to it with Black Magic Probe just fine, but after mass_erase, BMP reports 0xfffffffe instead of usual 0xffffffff, meaning something is lef behind. That prohibits reflashing of softdevice BUT I can load "plain" skethes that do not require softdevice
I ASSUME the module has some kind of write protection and/or UICR registers set that are not erased with BMP mass+erase command.
I've tried to load d0016 uuicr clearing sketch, It loads fine, but I've still got 0xfffffffe after masserase.
So what's the proper way to really completely erase the module?
I have nrf52 dk that I tried to use as a programmer but it didn't worked.

[NeverDie]

@Nca78 said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

@Nca78
I can, but it wouldn't be proper "mysensors" code, because mysensors code has a 5-10 second power-up delay. So, for that reason, it's using radiohead instead. Do you still want it anyway?

Ah I see, probably still interesting to see, please share anyway

Here it is, warts and all:
0_1506603795796_remote_control_v031.zip
It works, but it's just hastily improvised throw-away code, so I made no attempt to polish it. i.e. For anyone reading this: It is very definitely not demo code.

[Jokgi]

@NeverDie This may be old news but I will throw it out anyway. The Reset pin on the nRF52 series is both a GPIO and RESET line (one or the other) . This is not a dedicated Reset however and the application must define that pin as RESET. This is the only pin that can be defined as reset. The Datasheet describes this as well.

[Jokgi]

@Toyman What is the make and model of the module. You can use the nRF52-DK to erase the device. P20 is a ease access to the programming pins on that board. You need to power up the module, run the VDD from the module back to the dev kit , P20, Pin2. Hook up the SWDIO lines to Pin3 and the SWDCLK to Pin4. and Ground, Pin8. As reset is not hardwired you don't have to hook that up unless you want to (Pin7. .  You can use nRFJPROG to exersise the J-Link (Segger). This is found in the downloadable tools on the Nordic site. BTW - I have no problem using J-Link Commander version 6.20c with the nRF52-DK with the nRF52832 mounted. I hope this helped.

[NeverDie]

@Jokgi said in nRF5 Bluetooth action!:

@NeverDie This may be old news but I will throw it out anyway. The Reset pin on the nRF52 series is both a GPIO and RESET line (one or the other) . This is not a dedicated Reset however and the application must define that pin as RESET. This is the only pin that can be defined as reset. The Datasheet describes this as well.

Yes, and thanks to @d00616's work, RESET can also be enabled/disabled from the Tools menu of the arduino IDE if using myNRF5Board as the board definition.

[NeverDie]

I just now compared the transmission range and packet loss of the cheap nRF51822 to the Ebyte nRF52832. I expected that the Ebyte, with its bigger and fancier antenna, to mop the floor with the nRF51822, but I was surprised to find that they actually seem fairly comparable (at least in my informal, off-the-cuff testing). So, if you have a sensor that's mostly transmission oriented, like, say, a TH sensor, the smaller and cheaper nRF51822 is maybe worth considering.

[Terrence]

@NeverDie said in nRF5 Bluetooth action!:

the smaller and cheaper nRF51822 is maybe worth considering.

That is interesting. What sort of range where you getting?

Do you have the 840 dev kit? If so, can you measure range on that guy? Should be 10x I would think.

[NeverDie]

@Terrence

Around 30 feet, through some walls, but at 2mbps. I realize that's not very far, but even so the measured packet loss (informal testing) is pretty high at that speed. I can see why most people default to 250kbps instead.

I don't have the 840 dev kit yet, mostly because I don't see anyother 840 modules on the market right now.

[NeverDie]

What's a good initial value to use for DATAWHITEIV, if doing data whitening?

[Toyman]

@Jokgi Thanks. That's exactly what I did. Flashed successfully but ideally I'd like to find a way to power the module from the DK (I had to use the external power)
Unfortunately, this was the first time when BMP let me down. It just failed to load either softdevice or the sketch hex while Jlink@DK handled it without any problem.

[NeverDie]

@d00616
Which settings are key for ensuring that packets sent by the nRF24 are correctly received by the nRF5? It would be nice to leverage the versions of the nRF24 that have amplified Tx. For sending wake-up packets, I shoudln't need shockburst, and so maybe this will work fairly easily.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Which settings are key for ensuring that packets sent by the nRF24 are correctly received by the nRF5? It would be nice to leverage the versions of the nRF24 that have amplified Tx.

These are more than settings. You have to set the Radio configuration like in Radio_ESB.cpp, reverse the addresses and handle sending ACK packages by software.

This is a good resource to understand the OTA protocol: https://hackaday.io/project/11942-antenna-diversity-receive-and-transmit/log/39510-shockburst-vs-enhanced-shockburst-nrf24-vs-nrf5x

I can provide a simple example how to use the MySensors transport code without Radio Head. This works for nRF5 and nRF24 modules, but its outside of that what the MY_CORE_ONLY mode is designed for.

#define MY_CORE_ONLY

#ifndef ARDUINO_ARCH_NRF5
#define MY_NODE_ID (1)
#define SND_TO (2)
#else
#define MY_NODE_ID (2)
#define SND_TO (1)
#endif

// Enable debug
#define MY_DEBUG
//#define MY_DEBUG_VERBOSE_RF24
//#define MY_DEBUG_VERBOSE_NRF5_ESB


// RF24_250KBPS RF24_1MBPS RF24_2MBPS
#define MY_RF24_DATARATE (RF24_1MBPS)
// NRF5_250KBPS NRF5_1MBPS NRF5_2MBPS
#define MY_NRF5_ESB_MODE (NRF5_1MBPS)


// Enable and select radio type attached
#ifndef NRF5
#define MY_RADIO_NRF24
#else
#define MY_RADIO_NRF5_ESB
#endif

#include <MySensors.h>

void setup() {
  Serial.begin(115200);
  
  hwInit();
  transportInit();
  transportSetAddress(MY_NODE_ID);
}

void loop() {
  // Check for packages
  while (transportAvailable()) {
    uint8_t buffer[256];
    uint8_t num = transportReceive(&buffer);
    Serial.print("Data=");
    for (int i=0;i<num;i++) {
      if (buffer[i]<0x10) Serial.print("0");
      Serial.print(buffer[i], HEX);
      Serial.print(" ");
    }
    Serial.println();
  }

  wait(1000);

  // Send data
  transportSend(SND_TO, "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",32, false);
}

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Yes, and thanks to @d00616's work, RESET can also be enabled/disabled from the Tools menu of the arduino IDE if using myNRF5Board as the board definition.

The reset support isn't complete at the moment. The menu is active, but it has no effect at the moment. I fix this with release 0.2.0.

[Uhrheber]

I just received 2 of those little boards.
Ideal for small sensor nodes, I'd say, but not very breadboard friendly.
So I dug out the verowire, and did a little soldering.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

Which settings are key for ensuring that packets sent by the nRF24 are correctly received by the nRF5? It would be nice to leverage the versions of the nRF24 that have amplified Tx.

These are more than settings. You have to set the Radio configuration like in Radio_ESB.cpp, reverse the addresses and handle sending ACK packages by software.

This is a good resource to understand the OTA protocol: https://hackaday.io/project/11942-antenna-diversity-receive-and-transmit/log/39510-shockburst-vs-enhanced-shockburst-nrf24-vs-nrf5x

I can provide a simple example how to use the MySensors transport code without Radio Head. This works for nRF5 and nRF24 modules, but its outside of that what the MY_CORE_ONLY mode is designed for.

#define MY_CORE_ONLY

#ifndef ARDUINO_ARCH_NRF5
#define MY_NODE_ID (1)
#define SND_TO (2)
#else
#define MY_NODE_ID (2)
#define SND_TO (1)
#endif

// Enable debug
#define MY_DEBUG
//#define MY_DEBUG_VERBOSE_RF24
//#define MY_DEBUG_VERBOSE_NRF5_ESB


// RF24_250KBPS RF24_1MBPS RF24_2MBPS
#define MY_RF24_DATARATE (RF24_1MBPS)
// NRF5_250KBPS NRF5_1MBPS NRF5_2MBPS
#define MY_NRF5_ESB_MODE (NRF5_1MBPS)


// Enable and select radio type attached
#ifndef NRF5
#define MY_RADIO_NRF24
#else
#define MY_RADIO_NRF5_ESB
#endif

#include <MySensors.h>

void setup() {
  Serial.begin(115200);
  
  hwInit();
  transportInit();
  transportSetAddress(MY_NODE_ID);
}

void loop() {
  // Check for packages
  while (transportAvailable()) {
    uint8_t buffer[256];
    uint8_t num = transportReceive(&buffer);
    Serial.print("Data=");
    for (int i=0;i<num;i++) {
      if (buffer[i]<0x10) Serial.print("0");
      Serial.print(buffer[i], HEX);
      Serial.print(" ");
    }
    Serial.println();
  }

  wait(1000);

  // Send data
  transportSend(SND_TO, "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",32, false);
}

I tried compiling it using the Arduino Windows IDE, but for some reason it complains about not finding a whole litany of .h files: socket.h, w5100.h, netdb.h.... Does mysensors.h really need to drag in all of those .h files, even if only indirectly? Or, if there's an easy way to make it find them, what is it?

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

I tried compiling it using the Arduino Windows IDE, but for some reason it complains about not finding a whole litany of .h files: socket.h, w5100.h, netdb.h.... Does mysensors.h really need to drag in all of those .h files, even if only indirectly? Or, if there's an easy way to make it find them, what is it?

I can compile it with Linux. What are missing is part of the Ethernet library. I don't know why it's included in you build.

[NeverDie]

I just now upgraded to the current release of the mysensors development library, and the compile problem went away. So, if anyone else encounters the same problem, I recommend doing that.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

I just now upgraded to the current release of the mysensors development library, and the compile problem went away. So, if anyone else encounters the same problem, I recommend doing that.

Sorry. I have forgotten my uncommited changes. At the moment, you have to start the HFCLK in the CORE_ONLY mode. This is done in hwInit() later.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

I just now upgraded to the current release of the mysensors development library, and the compile problem went away. So, if anyone else encounters the same problem, I recommend doing that.

... At the moment, you have to start the HFCLK in the CORE_ONLY mode. ...

Do you have a revised sketch which does that? I tried running the sketch you gave above on an nRF52 DK, but it immediately goes into a boot-loop, wherein in keeps rebooting itself, over and over and over again.

[NeverDie]

@NeverDie said in nRF5 Bluetooth action!:

I tried running the sketch you gave above on an nRF52 DK, but it immediately goes into a boot-loop, wherein in keeps rebooting itself, over and over and over again.

I just now tried running it on a pro-mini using a nRF24, and it also gets into a boot-loop.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

I just now tried running it on a pro-mini using a nRF24, and it also gets into a boot-loop.

Please replace wait() with delay(). This is an issue in the transport code, which is triggered while sleep() or wait() is executed.

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

I just now tried running it on a pro-mini using a nRF24, and it also gets into a boot-loop.

Please replace wait() with delay(). This is an issue in the transport code, which is triggered while sleep() or wait() is executed.

OK, made that change, and it no longer boot-loops.

However, neither node appears to be receiving anything from the other.

Please advise.

[NeverDie]

@d00616
Since the original code didn't work, I upgraded it somewhat to give a larger Rx window. However, it still doesn't work:

#define MY_CORE_ONLY

#ifndef ARDUINO_ARCH_NRF5
#define MY_NODE_ID (1)
#define SND_TO (2)
#else
#define MY_NODE_ID (2)
#define SND_TO (1)
#endif

// Enable debug
#define MY_DEBUG
//#define MY_DEBUG_VERBOSE_RF24
//#define MY_DEBUG_VERBOSE_NRF5_ESB


// RF24_250KBPS RF24_1MBPS RF24_2MBPS
#define MY_RF24_DATARATE (RF24_1MBPS)
// NRF5_250KBPS NRF5_1MBPS NRF5_2MBPS
#define MY_NRF5_ESB_MODE (NRF5_1MBPS)


// Enable and select radio type attached
#ifndef NRF5
#define MY_RADIO_NRF24
#else
#define MY_RADIO_NRF5_ESB
#endif

#include <MySensors.h>

void setup() {
  Serial.begin(115200);
  Serial.println("Starting....");
  Serial.print("MY_NODE_ID=");
  Serial.println(MY_NODE_ID);
  Serial.print("SND_TO=");
  Serial.println(SND_TO);
  
  hwInit();
  transportInit();
  transportSetAddress(MY_NODE_ID);
}

uint32_t theTime=0;
uint32_t loopCounter=0;
void loop() {
  // Check for packages
  while ((millis()-theTime)<1000) {
    while (transportAvailable()) {
      uint8_t buffer[256];
      uint8_t num = transportReceive(&buffer);
      Serial.print("Data=");
      for (int i=0;i<num;i++) {
        if (buffer[i]<0x10) Serial.print("0");
        Serial.print(buffer[i], HEX);
        Serial.print(" ");
      }
      Serial.println();
    }
  }
  theTime=millis();

  //delay(1000);
  Serial.print(loopCounter++);
  Serial.println(", SENDING:  abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz");

  // Send data
  transportSend(SND_TO, "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",32, false);
}

One node is an nRF24 on a pro mini, and the other is an nRF52832.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Since the original code didn't work, I upgraded it somewhat to give a larger Rx window. However, it still doesn't work:

Please add this to your setup() function (https://forum.mysensors.org/topic/6961/nrf5-bluetooth-action/985

	// Clock is manged by sleep modes. Radio depends on HFCLK.
	// Force to start HFCLK
	NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;
	NRF_CLOCK->TASKS_HFCLKSTART = 1;
	while (NRF_CLOCK->EVENTS_HFCLKSTARTED == 0)
		;

	// Enable low latency sleep mode
	NRF_POWER->TASKS_CONSTLAT = 1;

	// Enable cache on >= NRF52
#ifndef NRF51
	NRF_NVMC->ICACHECNF = NVMC_ICACHECNF_CACHEEN_Msk;
#endif

At the moment I prepare a new Pull Request fixing this including some small fixes and improvements for nRF5 MCUs. When it's integrated the HFCLK is startet in hwInit().

[Toyman]

@d00616 is this universal recommendation?

[d00616]

@Toyman said in nRF5 Bluetooth action!:

@d00616 is this universal recommendation?

I think you mean to start the HFCLK. This isn't a universal recommendation. At the moment the HFCLK is started in MyMainNRF5.cpp. This file is ignored in CORE_ONLY mode. I moved any initialization code into hwInit().

[d00616]

@d00616 said in nRF5 Bluetooth action!:

At the moment I prepare a new Pull Request fixing this including some small fixes and improvements for nRF5 MCUs. When it's integrated the HFCLK is startet in hwInit().

The Pull Request is available: https://github.com/mysensors/MySensors/pull/938

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

@d00616 said in nRF5 Bluetooth action!:

At the moment I prepare a new Pull Request fixing this including some small fixes and improvements for nRF5 MCUs. When it's integrated the HFCLK is startet in hwInit().

The Pull Request is available: https://github.com/mysensors/MySensors/pull/938

That link lists changes to the files, but it doesn't seem to provide the new files. Or else I'm overlooking where it does?

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

That link lists changes to the files, but it doesn't seem to provide the new files. Or else I'm overlooking where it does?

You have to checkout this pull request: https://help.github.com/articles/checking-out-pull-requests-locally/

[NeverDie]

@d00616 said in nRF5 Bluetooth action!:

@NeverDie said in nRF5 Bluetooth action!:

That link lists changes to the files, but it doesn't seem to provide the new files. Or else I'm overlooking where it does?

You have to checkout this pull request: https://help.github.com/articles/checking-out-pull-requests-locally/

Maybe I need write-access or something? Those instructions refer to a command line, and I just don't see one anywhere.

[NeverDie]

Well, anyway, I added code to start the high frequency clock, and now it seems to work:

#define MY_CORE_ONLY

#ifndef ARDUINO_ARCH_NRF5
#define MY_NODE_ID (1)
#define SND_TO (2)
#else
#define MY_NODE_ID (2)
#define SND_TO (1)
#endif

// Enable debug
#define MY_DEBUG
//#define MY_DEBUG_VERBOSE_RF24
//#define MY_DEBUG_VERBOSE_NRF5_ESB


// RF24_250KBPS RF24_1MBPS RF24_2MBPS
#define MY_RF24_DATARATE (RF24_1MBPS)
// NRF5_250KBPS NRF5_1MBPS NRF5_2MBPS
#define MY_NRF5_ESB_MODE (NRF5_1MBPS)


// Enable and select radio type attached
#ifndef NRF5
#define MY_RADIO_NRF24
#else
#define MY_RADIO_NRF5_ESB
#endif

#include <MySensors.h>
#include <nrf.h>

void setup() {
  Serial.begin(115200);
  Serial.println("Starting....");
  Serial.print("MY_NODE_ID=");
  Serial.println(MY_NODE_ID);
  Serial.print("SND_TO=");
  Serial.println(SND_TO);

  if (MY_NODE_ID==2) {
    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
  }


  hwInit();
  transportInit();
  transportSetAddress(MY_NODE_ID);
}

uint32_t theTime=0;
uint32_t loopCounter=0;
void loop() {
  // Check for packages
  while ((millis()-theTime)<1000) {
    while (transportAvailable()) {
      uint8_t buffer[256];
      uint8_t num = transportReceive(&buffer);
      Serial.print("Data=");
      for (int i=0;i<num;i++) {
        if (buffer[i]<0x10) Serial.print("0");
        Serial.print(buffer[i], HEX);
        Serial.print(" ");
      }
      Serial.println();
    }
  }
  theTime=millis();

  //delay(1000);
  Serial.print(loopCounter++);
  Serial.println(", SENDING:  abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz");

  // Send data
  transportSend(SND_TO, "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz",32, false);
}

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Maybe I need write-access or something? Those instructions refer to a command line, and I just don't see one anywhere.

You can do this with git on your local machine:

git clone https://github.com/mysensors/MySensors.git
cd MySensors
git fetch origin pull/938/head:pr938
git checkout pr938

[NeverDie]

@d00616
Thanks for trying. That would probably work with a linux machine, but mine is running Windows. I'm surprised there's no easy way to do this from Windows.

I guess I'll just wait for the next developers release of mysensors.

[NeverDie]

For anyone else caught in the same limbo as me, here's a more proper update of the earlier example:

#define MY_CORE_ONLY

#ifndef ARDUINO_ARCH_NRF5
#define MY_NODE_ID (1)
#define SND_TO (2)
#else
#define MY_NODE_ID (2)
#define SND_TO (1)
#endif

// Enable debug
#define MY_DEBUG
//#define MY_DEBUG_VERBOSE_RF24
//#define MY_DEBUG_VERBOSE_NRF5_ESB


// RF24_250KBPS RF24_1MBPS RF24_2MBPS
#define MY_RF24_DATARATE (RF24_1MBPS)
// NRF5_250KBPS NRF5_1MBPS NRF5_2MBPS
#define MY_NRF5_ESB_MODE (NRF5_1MBPS)


// Enable and select radio type attached
#ifndef NRF5
#define MY_RADIO_NRF24
#else
#define MY_RADIO_NRF5_ESB
#include <nrf.h>
#endif

#include <MySensors.h>

void setup() {
  Serial.begin(115200);
  Serial.println("Starting....");
  Serial.print("MY_NODE_ID=");
  Serial.println(MY_NODE_ID);
  Serial.print("SND_TO=");
  Serial.println(SND_TO);
  Serial.flush();

  #ifdef ARDUINO_ARCH_NRF5
    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
  #endif


  hwInit();
  transportInit();
  transportSetAddress(MY_NODE_ID);
}

uint32_t theTime=0;
uint32_t loopCounter=0;
void loop() {
  // Check for packages
  while ((millis()-theTime)<1000) {
    while (transportAvailable()) {
      uint8_t buffer[256];
      uint8_t num = transportReceive(&buffer);
      Serial.print(loopCounter);
      Serial.print(", RECEIVED=");
      for (int i=0;i<num;i++) {
        if (buffer[i]<0x10) Serial.print("0");
        Serial.print(buffer[i], HEX);
        Serial.print(" ");
      }
      Serial.println();
      Serial.flush();
    }
  }
  theTime=millis();

  //delay(1000);
  Serial.print(loopCounter++);
  Serial.println(", SENDING:  abcdefghijklmnopqrstuvwxyz01234");
  Serial.println();
  Serial.flush();

  // Send data
  transportSend(SND_TO, "abcdefghijklmnopqrstuvwxyz01234",32, false);
}

The serial output shown by the nRF52 is what you would expect:

Starting....
MY_NODE_ID=2
SND_TO=1
0, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
0, SENDING:  abcdefghijklmnopqrstuvwxyz01234

1, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
1, SENDING:  abcdefghijklmnopqrstuvwxyz01234

2, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
2, SENDING:  abcdefghijklmnopqrstuvwxyz01234

3, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
3, SENDING:  abcdefghijklmnopqrstuvwxyz01234

However, the serial output of the pro mini often seems to include a 1-byte packet:

Starting....
MY_NODE_ID=1
SND_TO=2
0, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
0, SENDING:  abcdefghijklmnopqrstuvwxyz01234

1, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
1, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
1, SENDING:  abcdefghijklmnopqrstuvwxyz01234

2, RECEIVED=41 
2, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
2, SENDING:  abcdefghijklmnopqrstuvwxyz01234

3, RECEIVED=41 
3, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
3, SENDING:  abcdefghijklmnopqrstuvwxyz01234

4, RECEIVED=47 
4, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
4, SENDING:  abcdefghijklmnopqrstuvwxyz01234

5, RECEIVED=46 
5, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
5, SENDING:  abcdefghijklmnopqrstuvwxyz01234

6, RECEIVED=47 
6, RECEIVED=61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 00 
6, SENDING:  abcdefghijklmnopqrstuvwxyz01234

Is that a bug?

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Thanks for trying. That would probably work with a linux machine, but mine is running Windows. I'm surprised there's no easy way to do this from Windows.
I guess I'll just wait for the next developers release of mysensors.

This depends on Git installed not on Linux. The Pull Request is now into the developer branch.

@NeverDie said in nRF5 Bluetooth action!:

However, the serial output of the pro mini often seems to include a 1-byte packet:
...
Is that a bug?

This is the RSSI value, which is send back as ACK payload. I check what's the best way to deal with.

[NeverDie]

Good news. Thanks to the work of @d00616 on making the ESB transport available, I'm getting very good range using the nRF52832 as a receiver and a pro mini with an inexpensive power amplified nRF24 as the sender, all at 2mbps. Not sure if there are yet power amplified nRF52832 available (?), but if not, this does the business.

[NeverDie]

One thing I do notice though is that the amount of time it takes to send a packet from an nRF24L01 using this ESB transport is pretty long: about 27ms passes between sending one packet and the next packet, and that's running on an ESP8266, which is pretty fast.

[NeverDie]

Looking at the nRF24L01 datasheet (file:///C:/Users/CoolerMaster/Downloads/nRF24L01_Product_Specification_v2_0%20(3).pdf), it appears that one simply needs to keep the TX FIFO full, and the radio will then send things as fast as it can (which should be a lot faster than 27ms). So, I'll give that a try.

[NeverDie]

Oddly enough, in the current mysensors-development release, it takes even longer: 97ms between packets.

[Nca78]

@NeverDie isn't it because quality of the radio link is bad, and it needs to send each packet many times while waiting for the ACK between each sending ?
I'm not sure what/how you measure but if you have many packets in your TX FIFO the next packet is processed only when first packet is acknowledged and removed from FIFO, so if radio link is bad the delays of retransmission will add up while processing the TX FIFO and last packet will be sent only after a "long" delay.

When an ACK is successfully received from a PRX, it implies that the payload was successfully received and added to the PRX's RX FIFO, the successfully transmitted packet will be removed from the TX FIFO so that the next packet in the FIFO can be transmitted.

[Jokgi]

@NeverDie check out a Colorado company "Notwired". They have a 832 with a PA however I believe the PA is controlled by the softdevice. Check it out as there may be another way to contol it.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

Looking at the nRF24L01 datasheet (file:///C:/Users/CoolerMaster/Downloads/nRF24L01_Product_Specification_v2_0%20(3).pdf), it appears that one simply needs to keep the TX FIFO full, and the radio will then send things as fast as it can (which should be a lot faster than 27ms). So, I'll give that a try.

If "noACK" is enabled, each packet is send 15 times, which consumes ~27ms. Both NRF24 and NRF5 do the same here.

[NeverDie]

Well, there are these:
https://www.aliexpress.com/item/PTR5618PA-Nordic-nRF52832-Module-PA-module-BLE-4-0-Module-Free-shipping/32761051086.html?spm=2114.search0104.3.8.MXhqTf&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_10130_5560016_10068_10344_10342_10343_10340_10341_10307_10060_10155_10154_10056_10055_10054_5370016_10059_10534_10533_10532_100031_10099_10338_10339_5580016_10103_10102_10052_10053_10107_10050_10142_10051_10324_10325_9947_10084_513_10083_10080_10082_10081_5590016_10178_10110_10111_10112_10113_10114_143_10312_10314_10078_10079_5570016_10073-9947,searchweb201603_1,ppcSwitch_4&btsid=40a5015f-dcf6-44e1-aba0-2ebedd393fb8&algo_expid=122380a9-0e93-4cf0-b147-38cdf7c5df53-1&algo_pvid=122380a9-0e93-4cf0-b147-38cdf7c5df53
but who knows how well they work. Have to buy 5 just to find out.

In time, I'm sure there will be more available with PA's on them.

[NeverDie]

I need to be able to send back-to-back packets from an nRF24L01 in order to guarantee waking up an nRF52832 receiver that's in a "listen mode" but otherwise asleep.

[Toyman]

@NeverDie have you tried adding ipx antennae to Ebyte module?
Does it help?

[Nca78]

@Toyman said in nRF5 Bluetooth action!:

@NeverDie have you tried adding ipx antennae to Ebyte module?
Does it help?

You need to move the tiny cap for that, not easy

[NeverDie]

@Toyman said in nRF5 Bluetooth action!:

@NeverDie have you tried adding ipx antennae to Ebyte module?
Does it help?

Yes, but it made no difference. NCA78's post explains why. So, I guess that connector, which looks so promising, amounts to just marketing bait? i.e. in terms of practicality, it's little more than a decoration? And if so, then which would be a good module to buy if intending to hook up using an ipx? Presumably a module that has only an ipx connector and no other antenna already on it? Which module exactly? I'd like to try it with an eye for use on a gateway.

[NeverDie]

By the way, with the latest library, time between packets is now down to around 1ms. I guess there was a favorable change in the library? I'm now not sure if it's that, or something I may have inadvertantly done while mucking around with it.

[NeverDie]

@Uhrheber said in nRF5 Bluetooth action!:

I just received 2 of those little boards.
Ideal for small sensor nodes, I'd say, but not very breadboard friendly.
So I dug out the verowire, and did a little soldering.

Looks as though the module itself is missing the SW pinouts. Is that what the two wires you soldered near the chip are for?

[Nca78]

@NeverDie said in nRF5 Bluetooth action!:

Yes, but it made no difference. NCA78's post explains why. So, I guess that connector, which looks so promising, amounts to just marketing bait? i.e. in terms of practicality, it's little more than a decoration?

I did the change on a PA LNA nrf24 from CDEByte, it was a real pain especially when the module was already soldered and surrounded by connectors. In the end I lost the cap somewhere on my desk and so I replaced it with a 0603 of the same capacity. Not looking great but much easier and it works better with the ipx antenna than with PCB.

[NeverDie]

From the nRF24L01 datasheet:

The nRF24L01+ transmitter PLL operates in open loop when in TX
mode. It is important never to keep the nRF24L01+ in TX mode for more than 4ms at a time.

So, I guess I won't be able to use the nRF24L01+ for continuous transmits after all.

[NeverDie]

Looks as though maybe this nRF52832 module would not require modification in order to use the IPX?
https://www.aliexpress.com/item-img/1pcs-NRF52832-Bluetooth-module-M4-kernel-Bluetooth-4-1BLE-module/32821473149.html?spm=2114.10010108.1000017.2.2d1f5eccJxyODh

[NeverDie]

So, I just did what NCA78 inspired me to do: resoldered the capacitor to enable the IPX connector. The results? It is an improvement, and I can see the difference at the margin, but still nothing like the 20dbi of the amplified modules. Not surprising. So, I guess I'll try to find one of those as either an nRF52832 or an nRF51822, and give that a try.

[Jokgi]

@Toyman there are both 5v and 3vdc available on the DK. You can use that to power the board. But that is not VTG line. That line just lets the DK know it has a target board out there and that the voltage is about 3vdc. (There are no voltage levelers on the board)

[NeverDie]

Didn't find much. So, I ordered this:
https://www.aliexpress.com/item/NRF51822-PA-LNA-remote-Bluetooth-4-module-transparent-serial-UART-sphygmomanometer-program/32818019202.html?spm=2114.search0104.3.16.FI9Dyt&ws_ab_test=searchweb0_0,searchweb201602_5_10152_10065_10151_10130_10068_10344_10342_10343_10340_10341_5560012_10307_10060_10155_10154_10056_5370012_10055_10054_10059_10534_10533_10532_100031_10099_10338_10339_10103_10102_5580012_10052_10053_10107_10050_10142_10051_10324_10325_10084_513_10083_10080_10082_10081_10178_10110_10111_10112_10113_5590012_10114_143_10312_10314_5570012_10078_10079_10073,searchweb201603_25,ppcSwitch_5&btsid=85a7f5aa-077c-4499-8f02-1a3a17ca6e74&algo_expid=347478fd-3b90-441e-9a58-e5018c973274-2&algo_pvid=347478fd-3b90-441e-9a58-e5018c973274

[Jokgi]

@NeverDie Hi, Do you know how they are pulling in the PA on these nRF52832 modules? I see many people using the device in Proprietary mode. There is no hardware line like with the nRF24L & the nRF518xx devices.. (VDD_PA) The nRF52832 uses the Softdevice to control a external PA using GPIOs.. You can see them on this block diagram from the Notwired module . There will be a PA out soon from a new company called OctoTech that has a internal RF sense switch included in the part. This will make a straight PA design much easier.

[Toyman]

@Nca78 it's like on Pi zero where you need to relocate an ultra tiny resistor. Definitely, beyond my smd skills.

[NeverDie]

@Jokgi said in nRF5 Bluetooth action!:

Do you know how they are pulling in the PA on these nRF52832 modules?

Good question! I'm assuming that it's simply active 100% of the time. Maybe that's why it's advertised as a PA module rather than a PA + LNA module. Even the silkscreen just says PA, with no mention of LNA. Or, since it's just PA, maybe it's controlled by the CE pin to turn it on/off(?).

I feel a bit sheepish buying it with a ceramic antenna, but, well, there's just not much in the way of alternatives right now. There was this though:
https://www.aliexpress.com/item/Free-shipping-NRF51822-pa-Bluetooth-module-external-pillars-antenna-CC2540-undertaking-Bluetooth-Project/32458170451.html?spm=2114.search0204.3.2.8gtlmf&ws_ab_test=searchweb0_0,searchweb201602_4_10152_10065_10151_10130_5560016_10068_10344_10342_10343_10340_10341_10307_10060_10155_10154_10056_10055_10054_5370016_10059_10534_10533_10532_100031_10099_10338_10339_5580016_10103_10102_10052_10053_10107_10050_10142_10051_10324_10325_10084_513_10083_10080_10082_10081_5590016_10178_10110_10111_10112_10113_10114_143_10312_10314_10078_10079_5570016_10073,searchweb201603_17,ppcSwitch_4_ppcChannel&btsid=bb691308-6a6f-4156-b00c-1ead48bef348&algo_expid=f9b3f79a-0b94-4799-9c7d-f9f55f552603-0&algo_pvid=f9b3f79a-0b94-4799-9c7d-f9f55f552603
which is maybe better in that regard.

I think for a gateway, it would indeed be preferable to have a PA+LNA module. I see the PA-only module as being possibly useful in a handheld remote controller that's basically Tx only.

[NeverDie]

That NotWired device does sound very nice, but at $89 each, I guess it really needs to be!
https://www.notwired.co/ProductDetail/CNRF52SKY66112-NotWired-CO/605602/
If the price were lower, I'd definitely get one. Nice to know it exists though.

@Nca78 How much is the OctoTech module supposed to be priced at? Any indications?

[NeverDie]

This module looks quite interesting: it appears to have two sets of antennas! It claims to offer some kind of antenna diversity:
https://www.aliexpress.com/item/nRF52832-LNA-PA-Range-Extension-EV-Board-best-sol-for-the-coming-Bluetooth-5-0-and/32778491443.html?ws_ab_test=searchweb0_0,searchweb201602_5_10152_10065_10151_10130_10068_10344_10342_10343_10340_10341_5560012_10307_10060_10155_10154_10056_5370012_10055_10054_10059_10534_10533_10532_100031_10099_10338_10339_10103_10102_5580012_10052_10053_10107_10050_10142_10051_10324_10325_10084_513_10083_10080_10082_10081_10178_10110_10111_10112_10113_5590012_10114_143_10312_10314_5570012_10078_10079_10073,searchweb201603_25,ppcSwitch_5&btsid=893e31a3-e668-41b9-862b-ec85db388059&algo_expid=439c9797-3287-4608-b652-5bcf1936fbb5-0&algo_pvid=439c9797-3287-4608-b652-5bcf1936fbb5

If it performed up to its advertised specs, it would make for one heck of a great gateway!

[NeverDie]

@Toyman said in nRF5 Bluetooth action!:

Definitely, beyond my smd skills.

I had the same concern, but it turns out that even a clumsy solder job seems to work just fine:

I was most concerned that I might create a short, so the tombstone bridge proved to me that wouldn't happen.

[NeverDie]

Not sure if this thing would work, but maybe?
https://www.amazon.com/gp/product/B01B94U438/ref=od_aui_detailpages00?ie=UTF8&psc=1

[Jokgi]

@NeverDie This module is based on the nRF52832 and a RF AXIS PA (now purchased by Skyworks) . I happen to have one of the first prototypes. This design worked great! . Note the blue wires attached to the 32khz crystal which was later mounted on the board.. Laughing a bit here. .

[Jokgi]

@NeverDie I believe that the Notwired price you mentioned was for the full dev kit board with RF module.
The Octotech device is not out in the market yet. I don't think they will be making production modules. Probably will have dev kits and then looking for module manufactures to produce modules with their part. 0_1507066567924_8TR8210 Product Brief RevA3.2.pdf

[NeverDie]

@Jokgi said in nRF5 Bluetooth action!:

This module is based on the nRF52832 and a RF AXIS PA (now purchased by Skyworks) .

Cool! Anyone selling it now besides Aliexpress?

[NeverDie]

@Jokgi said in nRF5 Bluetooth action!:

I believe that the Notwired price you mentioned was for the full dev kit board with RF module.

I wish that were so, but it just doesn't look that way to me. It seems that the dev board that could go with it is sold separately, and is another $95:
https://www.notwired.co/ProductDetail/CWSEPARD-notWired-co/606027/

[NeverDie]

Dang, I just noticed that this board has a FEMALE ipx connector on it:
https://www.aliexpress.com/store/product/1pcs-NRF52832-Bluetooth-module-M4-kernel-Bluetooth-4-1BLE-module/2629039_32821473149.html
At least the Ebyte module has a male ipx on it, which seems much more common.

[Jokgi]

@NeverDie If that is the case then I kind of limits their clientele a bit.

[Uhrheber]

@NeverDie
Exactly. There are two pads labelled SWD and SWC, originally meant for pogo pins.
I patched them with wires to the pin header.
Programming with a Chinese STLink V2 clone works flawlessly.

[Uhrheber]

@NeverDie
What antenna did you use?
It doesn't make so much sense to replace the internal 1-2dBi Antenna with an external 2-3dBi one.
Most small WiFi antennas are simply crap.
Also, 2.4GHz is a frequency so useless, that not even the radio amateurs wanted it. They have 2.3GHz.
At 2.4GHz, you may achieve a range of kilometers if you have a free sight, but not even penetrate a single wall with the same setup.

[NeverDie]

@Uhrheber said in nRF5 Bluetooth action!:

@NeverDie
What antenna did you use?
It doesn't make so much sense to replace the internal 1-2dBi Antenna with an external 2-3dBi one.
Most small WiFi antennas are simply crap.
Also, 2.4GHz is a frequency so useless, that not even the radio amateurs wanted it. They have 2.3GHz.
At 2.4GHz, you may achieve a range of kilometers if you have a free sight, but not even penetrate a single wall with the same setup.

I used an antenna that I temorarily removed from an ASUS router. I don't know what it's gain is supposed to be. However, I had similar thoughts, so yesterday I ordered this from amazon:
https://www.amazon.com/gp/product/B073SWWMRG/ref=od_aui_detailpages00?ie=UTF8&psc=1
which claims a 9db gain. It should arrive tomorrow. It's not really ideal, because it has to go through three connections (first the IPX connection and then an SMA connection and then finally the antenna connection), whereas it would be preferable to just have one connection so as to have less insertion loss. I'd be interested if you have any suggestions for something even better.

[NeverDie]

@Uhrheber said in nRF5 Bluetooth action!:

What antenna did you use?

Here's a photo of it:

[NeverDie]

@d00616

I want to transmit the shortest frame possible for my remote control packet, because that means the listen window on the receiver can be as short as possible, and that equals energy savings. To that end, looking at Figure 30: On-air packet layout in the datasheet (http://infocenter.nordicsemi.com/pdf/nRF52832_PS_v1.3.pdf), that would mean eliminating CRC, SO, LENGTH, S1, and the payload. What's left? Just an address. I could use one logical address to mean "ON", and a different logical address to mean "OFF".

I had already eliminated CRC from the radiohead code, and it all worked fine. Now I'm converting over to the MySensors transport code, and I'm wondering: how should I approach getting rid of those extra bytes using the MySensors transport code as the starting point?

[NeverDie]

I've had success in changing from sending one byte of payload to no payload at all by changing from

NRF_RADIO->PCNF0=0x80108

to

NRF_RADIO->PCNF0=0x80008

However, so far I haven't been able to shed S0 and/or S1 and still get the packet received, even if there's no payload.

Interestingly enough, the smaller frame works better than the more bloated frame. I guess less chances for it to get corrupted over the air.

[d00616]

@NeverDie said in nRF5 Bluetooth action!:

@d00616
I want to transmit the shortest frame possible for my remote control packet, because that means the listen window on the receiver can be as short as possible, and that equals energy savings.

I think the best way to do this is using the Bit counter. Set a timer to stop the radio and with the bitcounter, you can stop this timer. With the BC, you don't loose the CRC or length information. The Bit counter counts the S0/S1 and Length information and all data bits.

I use the bitcounter in the ESB-TX mode.

[NeverDie]

@d00616

Since it appears now that there's no way to avoid sending S0, LENGTH, and S1 over-the-air in the course of a full packet transmission cycle (even if their values are zero), I'm having success using EVENTS_ADDRESS to remove them from the equation anyway by cutting short the full packet sending/receiving process just after the address is either sent or received.

[maniron]

@NeverDie said in nRF5 Bluetooth action!:

I received the following message from the Ebyte seller:

Sorry that the two files are incorrect, please just ignore or delete them.
We will send correct files later.

Thank you!

Hi, they sent you the right files? Can you share them?

Thank you very much, great discussion

[NeverDie]

@maniron
They never sent them. Would you be willing to try asking them too? Maybe if enough people do, they'll finally take some action.

Unrelated, but I notice they've raised their prices.

[NeverDie]

OK, so I've reduced the over-the-air transmission to one preamble byte and 5 address bytes, for a total of six bytes. The transmitter sends a packet to a different logical address depending on which button is pressed, and the receiver can determine which button was pressed depending on which logical address matches.

So far, so good. The question now will be how many of those bytes I can eliminate before I start to get garbage packets.

The other factor is the granularity of the RTC. The receive window will either be about 30us or 60us, and I believe (but haven't yet confirmed) that I'm already at around 60us. So, I may already be at the practical limit.

[Jokgi]

@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.

[Jokgi]

@d00616 You may wish to count your retries as well. It is no use keeping the window narrow if you need to keep transmitting and receiving to get the same packet across. It may show that having a little wider window reduces the average current required by increasing the chance of picking up the packet first time. If you are using a timer to synchronize the RX and TX (TDMA) then you may be just fine.

[NeverDie]

@Jokgi said in nRF5 Bluetooth action!:

@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.

@Jokgi said in nRF5 Bluetooth action!:

@NeverDie I would not go less then 3 address bytes or random noise may look like valid addresses. The more address Bytes the less chance of that happening.

According to the datasheet, it appears to force a minimum of 3 address bytes anyway: 2 base address bytes plus 1 prefix address byte. With no prefix byte, it would appear that's as low as the hardware will allow.

[Jokgi]

@NeverDie I would not use a 2byte address for the reason I gave above. I was not including the preamble which is not really part of the address. 3 byte minimum is what I would recommend, not 2.

[NeverDie]

I can't make sense of the Packet configuration register 1 (PCNF1). Upon powering up, its value reads 0x262164, which doesn't really make any sense. I then try changing it to 0x22164. When i re-read it though, its value is then 0x139620, which is completely different. And this is 100% repeatable.

I can't make sense of this. What's going on with PCNF1? Why doesn't it keep the value that I set it to? why does it rapidly change over to the other number, and why that number in particular? I've tried setting it to other numbers also, but each time it doesn't stick and instead produces a puzzling number in its place. I've even confirmed that the radio is in a DISABLED state prior to making the change, but that doesn't seem to help either.

[Edit: mystery solved. I was accidently printing it as decimal instead of HEX. So, it works perfectly after all. :)].
.

[NeverDie]

Setting aside that mystery for the moment, the remote control presently is working very well, and the current draw during listen mode is now down to this:

which is certainly less than previously. Scale: 1mv=1ma.

It turns out that there's a minimum of 1 preamble byte. So, all told, there is a minimum of 4 bytes total that have to be transmitted: 1 preamble, 2 base address, 1 address prefix.

Eyeballing it, it does look as though the actual window of active listening is already around 30us, and unfortunately the granularity of the RTC prevents me from making it smaller than that. So, I suspect that, regarding power draw, this is already as good as it's possible to get.