nRF5 action!

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.

nRF5 action!

17

11.7k

11.2k

113.1k