Difference between DOA value from Web GUI and Android App

Hi,

I’m using kraken with a custom application and to get data results i use a HTTP Get to read the DOA_value.html file. (http://192.168.229.87:8081/DOA_value.html)
In that file, the DOA value is the same as the Web GUI


DOA value

I try the same setup but in stand of using my custom app, I use the Android app.
I also connect the Web GUI to my rapsberry and i read the same DOA value as my custom app (195°)…
But on the android app it’s not the same value like if their is a (360 - DOA value) applied. (165°). And I extracted the result file from the android application and the DOA value in the file is 165°.
App values

The good value is 165° (from Android app) so can you tell me if a make something wrong and why i don’t have the same result betwenn Web GUI and Android App?

I hope i’m clear (Sorry I’m french) :slight_smile:

Thanks for catching this, I believe this is a bug and I just pushed a fix to the GitHub. The Max DOA value on local data recording should have been 360-doa_value as you correctly determined.

This does not affect the heatmap generation as that relies on the full doa output which is correct. The max DOA value is not used for anything in the map, other than the blue max doa log lines plot.

Thank you for the quick response.

If I understand correctly, the Android app doesn’t use the DOA_value.html file saved locally on the rapsberry. How does it get the results?

Congratulations on your work, it works really well.

Romain

The Android app does use the DOA_value.html page. It polls that page and reads data from it over WiFi.

I’m not sure that this issue is completely resolved or see you can find where I am going wrong with my thinking?

The Max Doa Value should align with the center point of a nice tight 360 DoA lobe, correct? Using the fix outline above (360-doa_value) this puts the Max DoA Value in the opposite (correct?) quadrant but the 360 lobe does not move quadrants when using the Android App or Cloud Mapper. What am I missing here? I included an image that hopefully illustrates what I am describing.

The fix hasn’t made it’s way to the ready to use image file yet, if that’s what you’re using. You can try a git pull in the krakensdrdoa/krakensdrdoa folder if you want to update.

The code that I am using has the relevant update (line 759 inkraken_sdr_signal_processor.py). The result of this fix puts the Max Doa Value in compass convention, correct?

What I am suggesting that the Adroid App or Cloud Mapper may not be plotting the 360 DoA lobe in a useful perspective for the user (still in unit circle convection). If I understand things correctly this wouldn’t affect the heatmap once it arrived an estimated location of the transmitter but if you wanted to look at instantaneous DoAs, the 360 DoA wouldn’t be helpful to the user.Or am I misunderstanding things?

The output of the 360 doa values in the html file remains in the unit circle convention. It’s up to the app to rotate the vector in a way that’s useful for the app.