Direction Finding Usage Documentation

[flatflyfish]

Got it running with ./run.sh, but how do we use your inter_df and music_df Python files? Trying to set up something similar to what you have in your video.

[andyn]

Use the phase comparison interferometer, forget about the MUSIC one. It would require more receiver channels and extra calibration to work reliably.

The main binary writes the channel correlation matrix into a POSIX pipe named fifo. The direction finder programs consume the data from there and do the actual angle of arrival estimation.

First fire up the consumer program, like inter_df.py. Opening the pipe will block until it gets data. Then, in another terminal run the main binary, and everything should work.

I can't emphasize enough that this is a proof-of-concept demo that requires rtl-sdr hacker skills and proper antenna switch hardware, not just three dongles with the stock antennas. That's also why the written documentation isn't that good – it's expected that you actually know what you're doing.

[flatflyfish]

Thanks, yep I understand it's all proof of concept and the HW requirements. I want to learn about DF and this seems like a good start. A little more documentation wouldn't hurt though! :)

Hmm I had to go back to an earlier version to get inter_df.py to work though. The latest version causes a crash and makes ./main disconnect from the dongles.

[andyn]

I'll borrow the original hardware from @tejeez tomorrow and try to find out why the interferometer crashes. I probably won't add any features on the program, though.

[tejeez]

The reason is the format and contents of the data moved in the pipe were completely changed when direction finding was implemented in C code. When the inter_df script was used, the C program printed covariance matrix of the strongest signal (frequency bin with most power) in text format in pipe and the python script calculated the DOA from that. Now, the C program calculates DOA for all frequencies and sends them in binary format for the waterfall program to draw. This means inter_df doesn't currently work at all without some changes to code.

Sending the matrix in text format is still left in the code inside #if 0 and might work if you change it to # if 1:
https://github.com/tejeez/rtl_coherent/blob/master/correlate.c#L136
You also have to enable "calibration mode" where waterfall is not calculated.

[andyn]

Yup, seems like inter_df.py has been written for the earlier data format. Try the SDL waterfall program instead. You can launch it via run.sh.

• It's looks much nicer than a Numpy polar plot
• You're able to DF a whole 2 MHz wide block of spectrum instead of a narrow band frequency
• You'll instantly see if the calibration works and if there are strong interfering signals that prevent synchronization.

If you need a more accurate direction-of-arrival indication, you can hack the waterfall program to e.g. show the (Frequency, DoA) coordinates of the mouse cursor.

[flatflyfish]

Thanks I'll take a look at the code for both.

One thing I didn't quite get. What is the bottom pane in sdl_waterfall showing?

Is it the spectrum of the current block, including the noise sync block? I guess it's meant to show a short burst of noise near the bottom, and then the signals further up?

I'm going to try and use the GPIO to switch in and out the noise source with timing done in software instead of via the RC circuit.

[andyn]

The frequency is on the X axis and the angle of arrival is on the Y axis. The amplitude shows the strength of the correlation, so you should usually see greenish blob near the most probable direction of arrival. Wideband local QRM usually has multiple DoA results that point in the same direction, so the lower half of the display should also help you visually eliminate noninteresting results.

…

On 11 Aug 2017 12.20 AM, "flatflyfish" ***@***.***> wrote: Thanks I'll take a look at the code for both. One thing I didn't quite get. What is the bottom pane in sdl_waterfall showing? Is it the spectrum of the current block, including the noise sync block? I guess it's meant to show a short burst of noise near the bottom, and then the signals further up? I'm going to try and use the GPIO to switch in and out the noise source with timing done in software instead of via the RC circuit. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABAaf1FZcIwnK8ARgOoeczmWeTz66fS-ks5sW3QCgaJpZM4OwTX1> .