This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Energy Detection Mode for 1Mbit/2Mbit

Dear people of DevZone,

I set up a TDMA-based sensor network using the NRF52840 without the BLE-Softdevice or any API functions (message transmission and reception all by hand with NRF registers).

Everything works fine and now I wanted to extend the network with the capability to measure the RSSI/signal level of each timeslot in my TDMA-superframes (without receiving messages e.g. also interferences ).
The NRF52840 (and 52833) support Energy Detection (ED) that comes with the IEEE 802.15.4 operation modes of the SoC. I start the ED mode every timeslot and the result looks promising.

But now my question:
I do not use the 802.15.4 mode and also not the corresponding bitrate of 250 kbps.
I use the Ble_1Mbit and Ble_2Mbit mode and cannot find anything in the datasheets if these modes  support the ED at all and if the result I get is valid/trustable? I also observed that by going from Ble_1Mbit to Ble_2Mbit the measured ED is varying more and it also shows way more interference (high ED value in timeslots I am not using). Which again raises my question if the ED is supported in the 1Mbit/2Mbit mode at all?

I hope you can help me with my ED questions or suggest me another way to measure the (average/max) RSSI/signal level over a certain time period (~1ms) without receiving messages.

Br
Julian

Parents
  • Hi Julian

    Okay, I will forward this question internally, but I can't guarantee that we have a good answer for you I'm afraid.

    There are quite a few problems with using a feature that is not designed for BLE: 

    • It has not been tested or qualified with this PHY layer.
    • It is prone to change between variants/revision due to the above point.
    • We do not have any data of how it might change as temperature and voltage changes.
    • We have no data on how it might change due to other modulations or signal levels, etc.

    I will come back to you when I hear from the experts on the matter, but I'm afraid the support will be very limited here due to our lack of documentation and testing on this matter. The energy detection might very well work in the BLE physical layer, but there are no guarantees that it will, so you would be using this feature on your own risk. I'm sorry I can't be of more help to you...

    Best regards,

    Simon

Reply
  • Hi Julian

    Okay, I will forward this question internally, but I can't guarantee that we have a good answer for you I'm afraid.

    There are quite a few problems with using a feature that is not designed for BLE: 

    • It has not been tested or qualified with this PHY layer.
    • It is prone to change between variants/revision due to the above point.
    • We do not have any data of how it might change as temperature and voltage changes.
    • We have no data on how it might change due to other modulations or signal levels, etc.

    I will come back to you when I hear from the experts on the matter, but I'm afraid the support will be very limited here due to our lack of documentation and testing on this matter. The energy detection might very well work in the BLE physical layer, but there are no guarantees that it will, so you would be using this feature on your own risk. I'm sorry I can't be of more help to you...

    Best regards,

    Simon

Children
  • Hey Simon,

    thank you for forwarding it, maybe there will be a satisfying answer to my question :-)

    I totally understand that you cannot test and verify all features extensively, especially not the ones that at not officially supported.

    Maybe the ED-mode "just" extends the RSSI-sampling for a longer period and averaging (e.g. 128us instead of the 0.25us). However, I am aware that due to the different modulation schemes of the 802.15.4 mode the internal procedure may vary completely compared to the BLE mode.

    Thank you very much (and be prepared for follow up questions like abusing the direction-finding mode without antenna switching of the 52833 to enable raw I/Q sampling of interfering messages ;-) )

    Best regards,
    Julian

Related