Enabling Angle of Arrival Packets on RuuviTags

Hi, I’m currently working on a project that focuses on using BLE 5 standard for incorporating angle of arrival data to enhance location tracking abilities. We’ve decided to use the RuuviTags as our beacons, but our current receiver isn’t able to detect any Angle of Arrival (AoA) packets being sent from the RuuviTags. Any advice on how to remedy this would be wonderful!

I found this great tutorial about AoA:


I have no info yet if sender firmware has to be modified to get this working but tagging here @otso

My understanding is that AoA requires special hardware which is not present on nRF52, https://devzone.nordicsemi.com/f/nordic-q-a/23352/nordic-chipsets-can-support-indoor-location-tracking-feature . However if someone finds a way to implement the AoA on nRF52 I’d be happy to port it to RuuviTag.

Hey there @otso and @lauri.

Just wondering about the same thing…

From https://www.nordicsemi.com/?sc_itemid={4A16EF17-B7DD-4CE6-9B13-5EDD04335CBF}, it seems that the nRF52811 “combines the low cost of Nordic’s baseline nRF52810 SoC with the multiprotocol support of Nordic’s mid-range nRF52832 and advanced nRF52840 SoCs” (nRF52832 being used in RuuviTag). It further goes on to say that, “nRF52811 is also the first product in the Nordic low power wireless range to support Bluetooth 5.1, which adds Direction Finding

Where trilateration needs three receiving signals, my understanding from the source given by @lauri(http://dev.ti.com/tirex/content/simplelink_academy_cc2640r2sdk_2_30_02_00/modules/blestack/ble_aoa/ble_aoa.html) only two receiving signals (by connecting “at least two antennas to the same receiver”) is needed to determine AoA…

  1. Am I correct in saying that AoA cannot be determined by a RuuviTag alone - even if it carried the nRF52811?;
  2. Will the Ruuvi Node, being a receiver and not a ‘tag’, have two antennas to enable sub 1m positioning?
  3. Would Ruuvi Node also support elevation detection? i.e. 3D positioning (https://www.youtube.com/watch?v=c3XqbEKmNcM)

I’d like to contribute to this, but based on @otso comment on the slightest possibility of AoA on a nRF52 makes me feel I’m reading everything upside down…

Your guidance/possibility on this is appreciated.



As you noted, even if RuuviTag had nRF52811 it would not be enough alone, as support by receivers would be required.

We’re definitely interested in the possibility of supporting the direction finding features, but we’ll need to understand what is required from the hardware and software before making any promises.

In meanwhile, RuuviTags support Quuppa positioning which fills the use case of precise tracking of tags.

Thanks @otso!

With some RTLS experience, trilateration algos tend to be a leech on server resources (there’s also a chance I don’t know how to code efficiently :rofl:). So, if there is a chance for AoA, I’d be a serious advocate!

I’m sure Quuppa’s proprietary gateways are extraordinary but I’d much rather stay within the opensource framework of the Ruuvi stack without having the aching burden of volatile license fees…

Let me know. I’d be happy to contribute what I can!


Has there been any update or discussion on updating the hardware to support bluetooth 5.1 specs and direction finding?


Last time I looked into this Nordic didn’t yet have software support for sending direction finding packets on 52811, if there’s an update please link it here and I’ll check it out