Most reliable "best" radio

[Larson]

@NeverDie You are building a library. I don’t have the time to consume/enjoy it now as I’m deep in eldercare. But for sure, I’m coming back to your wonderful library to learn more – just later. Don’t interpret my silence as… indifference.

[NeverDie]

@Larson No worries. It works better with feedback from a knowledgeable audience, but... that entire audience has seemingly evaporated. Nonetheless, this rubber ducking may still have some value even under the current "everyone long gone" circumstances.

[NeverDie]

Aha! Apparently there is some kind of undocumented difference in the way addresses are represented in an nRF24L01P vs. an nRF5x. I found this address conversion function in Nordic's "micro-esb" library (https://github.com/NordicPlayground/nrf51-micro-esb/blob/master/common/micro_esb.c ) which holds promise for illuminating what that difference is:

and

Just from eyeballing it, nRF24L01P apparently transmits in the order of most significant bits first (which is undocumeneted), as compared to nRF5x, which transmits in order of least significant bits first (which is documented). Well, that would explain why xE7 (=B11100111), worked in my earlier addressing attempt, since it is the same either way.

Well, yes, though the algorithm is a two-step process. The bytewise_bit_swap function apparently reverses the ordering of bits in each byte, but leaves the bytes in the same order:

1111111111111111111111110100 -> 11110000111111111111111100101111
1111111111111111111111110011 -> 11110000111111111111111111001111
1111111111111111111111110010 -> 11110000111111111111111101001111
1111111111111111111111110001 -> 11110000111111111111111110001111
1111111111111111111111110000 -> 11110000111111111111111100001111

The radio address config section then reorders the sequence of the bytes. The net effect is the same as what I had guessed.
Well, this does explain why on the nRF5x, the "prefix" comes after the address section in the above diagram. My original impression had been that it was a poor choice of nomenclature.

Next I need to test this new theory on the hardware and see if it works.

[Larson]

@NeverDie said in Most reliable "best" radio:

I suppose an alternate, non-elegant way to solve the problem would be to have an array of different nRF24L01 modules, each optimized for a different power level.

Does the optimization mean different HW components with different RF_PWR settings? If the HW remains the same then one could incrementally change the RF_PWR level in the loop, right? Perhaps even by using two input pins one could control the RF_PWR level settings manually. The pins determine 00, 01, 10, or 11 and that gets fed to RF_PWR. That might be easier.

[NeverDie]

@Larson said in Most reliable "best" radio:

@NeverDie said in Most reliable "best" radio:

I suppose an alternate, non-elegant way to solve the problem would be to have an array of different nRF24L01 modules, each optimized for a different power level.

Does the optimization mean different HW components with different RF_PWR settings? If the HW remains the same then one could incrementally change the RF_PWR level in the loop, right? Perhaps even by using two input pins one could control the RF_PWR level settings manually. The pins determine 00, 01, 10, or 11 and that gets fed to RF_PWR. That might be easier.

Is your two pin solution referring to picking different modules, or to somehow adjusting the Tx power on one module? Not really following what you mean there. Since all the nRF24L01 modules use SPI, what I imagined was a separate chip enable line for each one, which would make it very easy to select among them. Indeed, that's the very definition of how SPI works. Straightforward.

[Larson]

@NeverDie said in Most reliable "best" radio:

two pin solution

Sorry, sometimes when I reread what I wrote, I don't understand it either.

My suggestion was to use only one radio and rotate different RF_PWR settings into the radio from the Atmega328p chip. That could be done by different means: 1. in the loop every 10 seconds or so for testing, or 2. by using GPIO pins defined as inputs, or 3. since we are talking radios, the power level could be transmitted to subject radio, read in code, and changed on the fly, or 4. any variety of other means (sensed light, temperature, vibration...)

For example, I'm looking at your barebones board right now. The radio module I'm using (RFM69HCW) is mounted on the first 8 pins of the headers that include SPI connections. Neighboring pins A0 and A1 on the barebones header are open and could be jumpered to GND (logic 0) or VCC (logic 1). The program on the 328 could sense those pins and select one of 4 power levels in the RF_PWR setting per the table you show above.

Hope that helps!

[NeverDie]

Reporting back regarding how to successfully transmit a packet from an nRF24L01P to an nRF5x, here's what I've confirmed (using the actual hardware) regarding the differences in how addressing is handled between the two different platforms:

Suppose the receiver address on a particular nRF52 (let us call it nRF52#1) is this:
prefix: 0x01
base-address: 0xACC01ADE
However, despite the name "prefix", we know from the datasheet that, from a temporal standpoint, when the over-the-air bits get sent, the prefix actually gets sent after the base-address. That means that if another nRF52 (let us call it nRF52#2) were transmitting an address meant to match nRF52#1, then the over-the-air bits, which are sent least-significant bit first on an nRF5x, would be sent as follows if you were writing them down left to right in temporal transmission order:
(reverse 0xACC01ADE) followed by (reverse 0x01)
Hence, from a certain twisted perspective it does make sense to call 0x01 a "prefix", because this is the same as:
(reverse 0x01ACC01ADE)

So, given that, the target Tx address, from the standpoint of an nRF24L01P, concatenated together, is the very same:
(reverse 0x01ACC01ADE)
because an nRF24L01P transmits in the order of most-significant-bit first.
As it turns out, this is equivalent to:
(reverse 0xDE) (reverse 0x1A) (reverse 0xC0) (reverse 0xAC) (reverse 0x01)
concatenated together.

That number turns out to be:
0x7B 58 03 35 80

QED.

HOWEVER, worthy of note: when you send that address over SPI from an atmega328P to an nRF24L01, the order of the bytes (but not the bits in the bytes) is again reversed. Confused yet? That means the temporal order of the bytes sent over SPI to the nRF24L01P is actually:
0x 80 35 03 58 7B
from left to right. i.e. 0x80 gets sent over SPI first, then 0x35, and so on. "Why is that?" you may ask. It's because, as per the nRF24L01 datasheet, the target address is sent LSByte first over SPI:

Regarding how to configure the S0, LENGTH, and S1 fields on the nRF52, it makes sense to do the following:
S0 = 0
LENGTH = 6
S1=3

because then the LENGTH field is properly alligned with the LENGTH bits transmitted by the nRF24L01.

[NeverDie]

To memorialize all that detail in easy to understand c-language code, here is a simple program which converts an nRF52 address into an equivalent nRF24L01P address that you can compile and run on any linux machine using gcc:

#include <stdint.h>
#include <stdio.h>

// This program defines a nRF5x address and converts it into an equivalent nRF24L01P address 
// so that a nRF24L01P radio can send packets to the nRF5x device.

// Define prefix and base-address for an nRF5x:
uint8_t this_Node_Nrf5x_Address[] = {0x01, 0xAC, 0xC0, 0x1A, 0xDE};

//Note: Node_Nrf5x_Address[0] is the prefix address, and the remaining bytes are the base-address.

// Define an equivalent address used by an nRF24L01 which, when transmitted, will correspond to the this_Node_Nrf5x_Address
uint8_t nRF24L01P_Tx_Address[5];


// Function that, given a byte, returns a byte with the bits reversed. 
// This function is derived from the function originally provided by Nordic Semiconductor (https://github.com/NordicPlayground/nrf51-micro-esb/blob/master/common/micro_esb.c)
uint8_t bytewise_bit_swap(uint32_t inp)
{
    inp = (inp & 0xF0) >> 4 | (inp & 0x0F) << 4;
    inp = (inp & 0xCC) >> 2 | (inp & 0x33) << 2;
    return (inp & 0xAA) >> 1 | (inp & 0x55) << 1;
}


//Convert from the given_Nrf5x_Address to the equivalent nRF24L01P_Tx_Address
void convertAddress() {
  nRF24L01P_Tx_Address[0] = bytewise_bit_swap(this_Node_Nrf5x_Address[4]);
  nRF24L01P_Tx_Address[1] = bytewise_bit_swap(this_Node_Nrf5x_Address[3]);
  nRF24L01P_Tx_Address[2] = bytewise_bit_swap(this_Node_Nrf5x_Address[2]);
  nRF24L01P_Tx_Address[3] = bytewise_bit_swap(this_Node_Nrf5x_Address[1]);
  nRF24L01P_Tx_Address[4] = bytewise_bit_swap(this_Node_Nrf5x_Address[0]);
}

//Given a pointer to an address array of 5 elements, print the address in hexadecimal
void printAddress(uint8_t *theAddress) {
  for (int i=0;i<5;i++) {
    printf("%02X",theAddress[i]);
  }
  printf("\r\n");
}

void main() {
	printf("nRF5x address:  0x");
	printAddress(this_Node_Nrf5x_Address);
	convertAddress();
	printf("equivalent nRF24L01 address:  0x");
        printAddress(nRF24L01P_Tx_Address);	
}

In this example, the output is:

nRF5x address:  0x01ACC01ADE
equivalent nRF24L01 address:  0x7B58033580

:grin:

[NeverDie]

That's probably it for this thread. Proof of concept is working, and time to move on. Thank you to the few who had anything to say. Hopefully there will be more of a community again after the chip shortage is over. If not, I hope what has already been posted is at least preserved in some retrievable way so as not to be completely lost in the sands of time.

[Larson]

@NeverDie said in Most reliable "best" radio:

not to be completely lost in the sands of time.

Wish I could do more from my end. As long as this forum and the web exists... your library of knowledge will be of great value to me, and I presume, to others. I thank you!

[NeverDie]

Epilogue: It turns out that although I'm now able to receive packets on an nRF52 that are sent by an nRF24L01, the payload appears to be gibberish. Argh! So close, and yet no cigar. I thought it worth mentioning for anyone who happens to be following along. I'm fairly sure it must involve those mysterious S0, S1, and LENGTH bit blocks, but as there's virtually no documentation on this aspect of things, a solution will either involve extensive troubleshooting or else locating some relevant code and figuring it out from that. In the end, I'm not sure it's worth the effort. I may just stick with plain vanilla nRF52-to-nRF52 communication, as that much is working fine and without further hassles.

[Larson]

@NeverDie A young Scott Harden taught me, via Youtube how to use a soundcard and Audacity recording SW as an o'scope. He would transmit a known preamble followed by a known pattern. I think this can be done in OSK, FSK, OOK. When the data is in Audacity, or an o'scope, then you can take your time to learn the timing of the transmitted and received signal. Seeing is believing, for me.

[NeverDie]

@Larson Although I haven't tried it myself, I have my doubts that a soundcard would work for recording signals sent at 2mbps, if only because that is way outside the spec for normal sound recordings. However, for slow signals, yes, I can believe it would work.

There are also software defined radio receivers that would probably do a good job of receiving and, with the right software, displaying signals. Certainly HackRF One would be one such device that could do it. I haven't tried that either, but it was designed for the purpose. IIRC, Andreis Speiss did a video on using a cheap ($10-$20) SDR to receive and decode some fairly basic radio packets. Maybe it would display them as well.

[Larson]

@NeverDie If I remember correctly, I was working on 433 MHz radios at the time - so a little slower rate. The sampling rate available though Audacity was way more than I needed to see the digital signal. At the time it was my first introduction to digital radio. And, in life so often, the first experience is the best. And it helped me realize that more advanced SW/HW like the PPKII depend on the same sampling of a signal. Pretty danged cool.

[NeverDie]

@Larson About 10 years ago I did it using the A2D on an Arduino Due once for a simple 433Mhz OOK receiver. It worked well enough. Like you, it was my first experience doing such things. The hardware was so basic that it was a software-only radio from the mac layer up. The Due was fast enough that I could detect both the original signal (shortest path) and subsequent bounced signals (multipath) as separate entities. I still think it's pretty cool. :sunglasses:

[Larson]

@NeverDie Sorry for the slow response/question. Elder care still demands the day(s).

Is the bounced signal physical? Or is it electronic reflection? I suppose it would be difficult to decipher.

[Larson]

@NeverDie Here is a view of what the Power Profiler Kit II sampler (100,000 samples/second) could see. This is my 433 MHz radio/motion-detector rig picking up motion and sending a HT12E 12-bit address/data byte. Really fun to see that the ones and the zeros can be clearly seen in the FSK profile of the measured current of the device.

[NeverDie]

@Larson That's pretty cool. I suppose if it were OOK, you wouldn't even need a receiver to see the contents of a transmitted packet. You could maybe check your garage door opener or one of the cheaper TH sensors. Or check an IR transmitter to see what pattern it's sending.

[Larson]

@NeverDie Excellent thinking on the signal detection. I think I'm going to build a garage door repeater. While the signal probably has some kind of encryption, maybe all I need to do is to repeat the same signal. But before I do that, I’ve got to return to the radio project you inspired. Elder-care has all of my time for now.
My description above was a bit cryptic. What I marvel at is that I was only measuring the device power and didn’t know the transmitted code would be revealed in the power profile. But that makes sense now for most any battery powered transmitter including OOK, ASK protocols. As such your thought about detecting codes from TV remotes to garage doors would apply just by measuring the power battery power to the device. Effectively the PPKII becomes an O’scope.

[NeverDie]

@Larson Unless you have a really ancient garage door remote, your garage remote most likely uses some kind of rolling code that's intended to prevent a simple playback attack. Unless you happen to know the packet/frame layout, and probably the algorithm as well, then reverse engineering it can be quite time consuming. I once did it for a consumer soil moisture sensor, and it was damn hard. Reading the bits wasn't hard, but figuring out the semantics represented by those bits took quite a bit of effort--way more than it was worth, as I subsequently discovered the sensor didn't have good accuracy in the first place. A bit ironic, as there was no way to discover that until after I had the detailed data that had previously been inaccessible.