Radio Test modulation not working

[Federico]

Hi,

We're working on a development project using nRF52832, SDK 15.2 and s132_nrf52_6.1.0_softdevice. I'm trying to use the radio test example from the SDK to certify the device, but since our hardware is physically closed, there's no way to flash a different application or command it via UART. We do have an SPI connection from a different microcontroller, so I took radio_test.c and implemented SPI commands to call each of the functions found there. However, the rest of our application must remain there. My current strategy is to call sd_softdevice_disable when a specific SPI command to begin the radio test is received and then call the radio test function when the matching SPI command is received. When the radio test is completed, the nRF is reset and regular BLE operation resumes.

This works for the TX carrier and TX Sweep. I can see it on the RSSI viewer from another board when the command is received. However TX modulated data and RX data don't work. If I transmit from our device, the dev kit will not receive  anything. If I transmit from the dev kit, our device receives something but it seems to be completely incorrect.  For the transmission pattern 1111000, y expect to receive a packet filled with 0xF0 (which I do when using 2 devkits, one for TX and one for RX). Here I get: 0x04, 0x00, 0x20, 0xE9, 0x08, 0x00, 0x00, 0x7D, 0x05.... The contents seem fairly random, but they're always the same. Even if I listen on another channel where I'm not transmitting.

When transmitting, the received data on the dev kit is all 0.

Is it enough to call sd_softdevice_disable before calling the functions exported in radio_test.h or do I need to do something else? Is it possible at all to unload and disable the BLE stack to run the radio test or should I restart and run a different initialization?

I tend to think that it must be related to the unloading of the soft device because it's the most obvious difference, but perhaps it's something else. What else could be the issue? I'm not sure how to debug this, BLE works ok out of test mode.

[Håkon Alseth]

Hi,

 

This works for the TX carrier and TX Sweep. I can see it on the RSSI viewer from another board when the command is received. However TX modulated data and RX data don't work. If I transmit from our device, the dev kit will not receive  anything. If I transmit from the dev kit, our device receives something but it seems to be completely incorrect.  For the transmission pattern 1111000, y expect to receive a packet filled with 0xF0 (which I do when using 2 devkits, one for TX and one for RX). Here I get: 0x04, 0x00, 0x20, 0xE9, 0x08, 0x00, 0x00, 0x7D, 0x05.... The contents seem fairly random, but they're always the same. Even if I listen on another channel where I'm not transmitting.

In SDK v15.x, the radio_test will fully transmit random patterns, including randomizing the RF address on both ends.

If you use radio_test from nRF5 SDK v17.1, you should be able to setup two kits with randomized data and receive this correctly, as the RF address is statically set.

 

Transmit patterns 11110000 and 11001100 are for RF PHY testing only, and not really meant for a receiver to look at the data.

Is it enough to call sd_softdevice_disable before calling the functions exported in radio_test.h or do I need to do something else? Is it possible at all to unload and disable the BLE stack to run the radio test or should I restart and run a different initialization?

I tend to think that it must be related to the unloading of the soft device because it's the most obvious difference, but perhaps it's something else. What else could be the issue? I'm not sure how to debug this, BLE works ok out of test mode.

This depends on how you want this setup. Ideally, you do not want the RF test firmware inside the shipped application firmware, unless there's specific reasons for doing this (ie. routine self-check of the hardware/firmware or similar). If this is purely for initial testing of the device, I would recommend that you first flash the radio_test, and then afterwards flash your full application (softdevice + app).

 

Kind regards,

Håkon

[Federico]

Hi Håkon,

Thanks for the quick answer. I have a few questions:

1. Can I use the SDK 17 radio test with the SDK 15? Is it too hard to backport it?

2. If transmit patterns are meant for RF PHY TX testing only, in what cases does one use "start_rx" and "print_rx" commands?

3. How does one use radio_test.c to perform an RF PHY test of the RX?

4. Regarding the setup, I understand that ideally you'd flash the device with a test fw and then back to the regular fw again. However, our devices are fully encolsed with a metal cover and cannot be physically accesed without destroying the device enclosure, which would affect the validity of the test. We could puncture a hole to pass a few cables on a single unit, but there isn't even a JTAG or SWD port on the board once it's fully assembled.

So the RF test firmware will not be in the final application firmware becuase, as you said, there's no reason to do that, but for the purposes of the test unit, the special test fw must be a blend of the radio test code into our application code. After posting this I thought that maybe I could use a GPIO pin to signal the nRF in which mode it has to initialize after a reset, that way I don't have to "unload" anything, I just reset it and choose what to load. Still, unloading seems easier if just calling "sd_softdevice_disable" is enough, which is still not clear to me 

Thanks!

[Håkon Alseth]

Hi,

Federico said:

Can I use the SDK 17 radio test with the SDK 15? Is it too hard to backport it?

Yes, you can backport to your current SDK version. Just copy the radio_test.c/.h files into your project (you might also have some includes that needs to be handled).

 

Federico said:

2. If transmit patterns are meant for RF PHY TX testing only, in what cases does one use "start_rx" and "print_rx" commands?

Patterns that are bitwise 01010101/11110000 etc, will confuse any radio, as it resembles preamble too much.

print_rx was added, but does not work reliable in SDK 15. You should use radio_test.* files from SDK 17 to send/receive data.

 

Federico said:

3. How does one use radio_test.c to perform an RF PHY test of the RX?

In general, you use radio_test in combination with a spectrum analyzer to perform verification of for instance output power, harmonics, and other spurious. For RX specific tests, you normally look at the spurious when in RX mode.

Here's a white paper that can be of interest: https://infocenter.nordicsemi.com/pdf/nwp_006.pdf?cp=17_20

 

For evaluation, like packet error rate (bit error rate), you use a piece of firmware and send either a known amount of packets, or packets in a given interval, and count the amount of successful received packets on the receiver end.

 

In bluetooth applications, you use a dedicated tester (for instance a Anritsu MT8852B) and on the DUT you use direct_test_mode.

https://infocenter.nordicsemi.com/pdf/nan_34.pdf

 

Federico said:

4. Regarding the setup, I understand that ideally you'd flash the device with a test fw and then back to the regular fw again. However, our devices are fully encolsed with a metal cover and cannot be physically accesed without destroying the device enclosure, which would affect the validity of the test. We could puncture a hole to pass a few cables on a single unit, but there isn't even a JTAG or SWD port on the board once it's fully assembled.

So the RF test firmware will not be in the final application firmware becuase, as you said, there's no reason to do that, but for the purposes of the test unit, the special test fw must be a blend of the radio test code into our application code. After posting this I thought that maybe I could use a GPIO pin to signal the nRF in which mode it has to initialize after a reset, that way I don't have to "unload" anything, I just reset it and choose what to load. Still, unloading seems easier if just calling "sd_softdevice_disable" is enough, which is still not clear to me 

Yes, you can use a specific pin to enter test mode before softdevice_init() in such a scenario.

  

Kind regards,

Håkon

[Federico]

Thanks, backporting the radio test from SDK 17 worked great! That seems to have solved the issue.

[Håkon Alseth]

Great to hear!

Hope you have a wonderful weekend!

 

Kind regards,

Håkon