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

nRF52811 for AoA on Receiver Side and nRF52832 On Transmitter Side

Hi,

Is possible for the nRF52811 to measure AoA on the receiver side with nRF52832 on the transmitter side?

Thank You,

David

Parents
  • I'm interested in this also. If the only requirement at the Tx end is to switch on the extended CW burst at the end of the packet, why can't this be done on the nRF52840? Obviously it would require a modification to the softdevice or SDK but I don't understand why it can't be done using the existing radio hardware (?)

  • Hi Pete

    While there is some flexibility in the nRF52840 radio with regards to packet configuration and similar it's not a true soft radio implementation where you can do pretty much anything. 

    The main limitation is that the CTE data has to be added after the CRC field is transmitted, and there is no support in the nRF52840 or earlier devices to add data after the CRC. The CRC will always be the very last thing that is transmitted or received. 

    Best regards
    Torbjørn

  • As I understand it, the CTE is an (unwhitened) all-ones pattern, transmitted after the CRC.

    It seems to me that, if the radio hardware can be commanded to send a long enough cell, then even if it insists on adding the CRC and doing whitening, the soft device could (at some CPU cost) do this:

    • Once the cell to be transmitted is formed...
    • Compute and append the soft device's own CRC, then
    • Having computed its own copy of the whitening pattern, append a bunch of anti-whitened all-ones bytes.
    • Then hand the result to the radio...
    • Which dewhitens the all-ones pattern and adds its own CRC to the end.

    So if the soft device could be hacked to do this, say to advertising packets (which are constant and have a long time to be pre-processed), you'd have a software upgrade that could let chips like the nRF52832 or nRF52840 act as AoA senders with no hardware changes; and not a lot of extra crunch.

    The last byte of the transmitted packet would be garbage (thus violating the standard).  But if the AoA receiver is programmed to ignore it, this should just work.

  • Oops.  The transmitter might include the extra bytes in the byte count, which would break this if it can't be overridden.

  • Hi Michael

    It should be possible to use the STATLEN field in the PCNF1 register to add some additional bytes to the payload, independent of what is configured through the length register. 

    That said you also need to control the antenna selection pins which needs to be controlled very accurately, and do a lot more processing in software. 

    While it might be possible in the TX only case (AoD) I can more or less guarantee it won't work in receive (AoA). 

    Since this case was originally opened we officially unveiled the nRF52833, which is essentially a mix of the nRF52832 and the nRF52840 with support for Bluetooth 5.1 added. I would strongly suggest this device for anyone interested in AoA/AoD. 

    Best regards
    Torbjørn

Reply
  • Hi Michael

    It should be possible to use the STATLEN field in the PCNF1 register to add some additional bytes to the payload, independent of what is configured through the length register. 

    That said you also need to control the antenna selection pins which needs to be controlled very accurately, and do a lot more processing in software. 

    While it might be possible in the TX only case (AoD) I can more or less guarantee it won't work in receive (AoA). 

    Since this case was originally opened we officially unveiled the nRF52833, which is essentially a mix of the nRF52832 and the nRF52840 with support for Bluetooth 5.1 added. I would strongly suggest this device for anyone interested in AoA/AoD. 

    Best regards
    Torbjørn

Children
No Data
Related