Weirdest thing I've ever experienced in my life

So, my colleague and I have been working quite extensively with this sample:

developer.nordicsemi.com/.../README.html

Our problem is that we have modified this sample, and for some reason, we are receiving packets in some bizarre manner. These packets seem to appear out of nowhere. When we run this sample, it opens a shell that can be used to set the radio to receive mode. Now with a specific address, size of the preamble, base length in the packet configuration, and setting ENDIAN to little, we receive a tremendous amount of packets. Our first thought was that it might be something in the air interfering and sending out packets to this address precisely. The packets are random bytes that we see when using the print command in the shell.

So what we did to cancel out this communication was that we used a screened room available to us at the company where we are working; this room cancels out almost any signal in the air, not 100% but almost everything. I sat in this room with my computer and the nrf52840 running this modded sample, and I still received packets. I've ensured with the test engineer responsible for this room that there is nothing in this room running on electricity that could transmit some kind of communication. So to ensure that my computer is not sending out something weird (even if I've turned off Bluetooth and wifi) I used a hole in this room that is covered with copper and made the cable from the computer to my nrf52840 go through it, and then covered up the hole as much as I could with copper again so only the cable could fit in the hole, now the board is in the room alone, and the door is shut. I'm outside with my laptop running the sample, and STILL, it receives some kind of packets. How is this possible? Is there something that we are doing that makes the board act out this weird behavior? Or are we making some idiotic mistake?

If someone has an nrf52840 board, please run radio_test sample with these changes made in the method radio_config and radio_test.h.

----radio_test.c changes----

case TRANSMIT_PATTERN_11110000:
nrf_radio_prefix0_set(NRF_RADIO, 0x9A);
nrf_radio_base0_set(NRF_RADIO, 0x297C); // Address that we are using
break:

memset(&packet_conf, 0, sizeof(packet_conf));
packet_conf.lflen = RADIO_LENGTH_LENGTH_FIELD;
packet_conf.maxlen = (sizeof(tx_packet) - 1);
packet_conf.statlen = 0;
packet_conf.balen = 2; // Changed base lenght to 2 bytes
packet_conf.big_endian = false; // put to false to get little endian
packet_conf.whiteen = true;

default:
/* Packet configuration:
* S1 size = 0 bits,
* S0 size = 0 bytes,
* 8-bit preamble.
*/
packet_conf.plen = NRF_RADIO_PREAMBLE_LENGTH_16BIT; // changed to 16 bit
break;

----radio_test.h changes-----

#define RADIO_MAX_PAYLOAD_LEN 52


When runninig, write in the shell:

start_channel 1
transmit_pattern pattern_1111000
start_rx
print_rx

Sry for the long post; any help is appreciated.

  • Hi,

    So sorry misunderstanding, I originally though the hex files you shared where the same ones you used. 

    To keep it short, the reason for the "ghost" packages you are seeing is due to coincidence. When you have a short address the chance of random noise being picked up as a bit.

    So to steer clear of the random noise being picked up as a package you have to increase the length, suing base length = 2 is not the best idea. 

    So the DK it self may be the source of the noise, onboard de-bugger and UART communication seems to be enough to provide enough noise that there is a good chance that something is picked up. Even though there are no other radio signals in the environment.

    packet_conf.balen = 2; is the culprit here. Stick to 4, and you should be OK, set balen = 1; and you will see a much quicker increase in ghost packages.

    With just the balen = 2 changed from the original radio_test sample there would be something like a chance that every 16 second there is match. With just the noise from the device it self. There are 16 million address combinations and at 1M it is sampling 1 million bit's every second

    CRC can help mitigate the issue to some degree. 


    32-bit address should be minimum. 

    Regards,
    Jonathan

Related