nRF5 action!

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