KerberosSDR Developments in 2020

Discuss KerberosSDR - 4x Coherent RTL-SDR
Post Reply
rtlsdrblog
Site Admin
Posts: 2375
Joined: Mon Nov 19, 2012 11:54 pm

KerberosSDR Developments in 2020

Post by rtlsdrblog » Thu Oct 03, 2019 8:33 am

Thanks for your support with KerberosSDR! The people who've purchased units are helping make this open source code happen.

Posted here is a rough road map of what we're planning for the next stage of KerberosSDR development. Please feel free to post any suggestions for features. We won't be giving a timeframe for these developments, but we are expecting most of them to be completed by the end of 2020.

[*] DAQ Double buffering - We are currently working on revised DAQ code that will allow for arbitrary buffer sizes to be set. The buffer size defines the number of samples the code first collects, then gives to the DSP code to work on. Different buffer sizes may be optimal for different signal types. This is necessary for future developments.

[*] Networked DFing - With several networked KerberosSDR units spread out around a city it will be possible to instantly direction find any signal.

[*] Intermittent Signal DFing Improvements - Right now it is difficult to use DFing with very short intermittent signals. Adjustments to the code will allow us to work on sample chunks that consist of mostly noise.

[*]Passive Radar Blips On a Map (PR + DF) - This will be a combination of the passive radar and direction finding techniques. The idea is that it should be possible to direction find the passive radar blips if we use all 4 on board RTL-SDRs and 4 directional antennas. This would allow us to plot the estimated location (via the distance + bearing) of an object being tracked by passive radar on something like Google Maps. Several improvements to the PR code such as target tracking are required for this to be completed.

[*] DAQ Unit Separation - Processing performance could be significantly improved if the DAQ subsystem and DSP processing code is separated onto two different pieces of computing hardware. Presently if the DSP code is set to run too fast, the DAQ code will lose sample sync due to the CPU + OS on a single device not being able to keep up with the task switching requirements. In the long run it would be better to dedicate a Pi3/4 or other cheap SBC to the DAQ and another computing unit to the DSP. This will allow people to easily read the coherent data stream in other programs too like GNU Radio via an Ethernet network stream. For mobile DFing we will keep the option to use just one SBC.

[*] Android DFing App Bug Fixes + Optimizations - There are a few bugs related to entering out of bounds settings in the app. The app also has room for speed optimization.

[*] Proper confidence values for DFing - Currently confidence is roughly calculated. There exists a potential method for calculating if probabilisticly and this will be tested.

[*] Beamforming - Once the DAQ system upgrades are completed, beamforming and listening to actual signals should be possible. Beamforming will allow you to electrically optimize an antenna array for receiving in one particular direction.

[*] Direct support for two combined KerberosSDR units - Combining two KerberosSDR's gives you 8 antenna inputs. This can improve DFing accuracy, and improve passive radar coverage.

[*] DSP Performance Improvements - There is room for DSP code speed improvements. Ideally we'd like to get passive radar updating significantly faster.

[*] Notching - Calibrating with the antennas connected results in better results, UNLESS there are signals in the spectrum. So calibrating with the antennas can be difficult/impossible in the real world. Adding notches in the DSP may help with this.

[*] Hardware: Switches and an improved calibration PCB - It should be investigated if switches degrade the phase calibration or not. With switches we could eliminate the need to disconnect the antennas when recalibrating.

[*] Improved clutter filters for passive radar - The clutter filter removes passive radar blips from stationary objects. Improved algorithms are faster and result in a cleaner PR display.

[*] A more user friendly UI - Wizards and calculators should be added to make setting up the KerberosSDR settings easier.

ckoval7
Posts: 11
Joined: Fri Sep 27, 2019 8:54 pm

Re: KerberosSDR Developments in 2020

Post by ckoval7 » Wed Oct 09, 2019 7:35 pm

[*] Networked DFing - With several networked KerberosSDR units spread out around a city it will be possible to instantly direction find any signal.
I'm actively working on my own implementation of this. I would love to work together if you're interested.

[*] Hardware: Switches and an improved calibration PCB - It should be investigated if switches degrade the phase calibration or not. With switches we could eliminate the need to disconnect the antennas when recalibrating.

I am presently experimenting with the HSWA2-30DR+ from Mini-Circuits. The PCBs just arrived in the mail today and I will have results by Sunday night. This chip allows selecting between 2 antennas and an internal 50 ohm load.

rtlsdrblog
Site Admin
Posts: 2375
Joined: Mon Nov 19, 2012 11:54 pm

Re: KerberosSDR Developments in 2020

Post by rtlsdrblog » Thu Oct 10, 2019 4:31 am

ckoval7 wrote:
Wed Oct 09, 2019 7:35 pm
[*] Networked DFing - With several networked KerberosSDR units spread out around a city it will be possible to instantly direction find any signal.
I'm actively working on my own implementation of this. I would love to work together if you're interested.

[*] Hardware: Switches and an improved calibration PCB - It should be investigated if switches degrade the phase calibration or not. With switches we could eliminate the need to disconnect the antennas when recalibrating.

I am presently experimenting with the HSWA2-30DR+ from Mini-Circuits. The PCBs just arrived in the mail today and I will have results by Sunday night. This chip allows selecting between 2 antennas and an internal 50 ohm load.
Excellent, happy to see contributions! This has been the goal from day one.

For networked operation the stop-gap idea was to get this program compatible with the KerberosSDR http://www.musther.net/RDFMapper/.

But if you're happy to open source and throw your code up on GitHub i'll help test it too.

Will be definitely keen to hear about your switch experiments too. Keep in contact either here on the forums or [email protected].

ckoval7
Posts: 11
Joined: Fri Sep 27, 2019 8:54 pm

Re: KerberosSDR Developments in 2020

Post by ckoval7 » Sun Oct 13, 2019 11:54 pm

rtlsdrblog wrote:
Thu Oct 10, 2019 4:31 am
For networked operation the stop-gap idea was to get this program compatible with the KerberosSDR http://www.musther.net/RDFMapper/.

But if you're happy to open source and throw your code up on GitHub i'll help test it too.

Will be definitely keen to hear about your switch experiments too. Keep in contact either here on the forums or [email protected].
Right now, the networking code is in bits and pieces for testing of various concepts. I'll open up the repo later this year.


I've very pleased with the results from the antenna switch! I've set up the software to run an auto-calibration routine upon changing frequency. Nothing got mangled in the VHF range. I'm not sure how it will translate to the upper UHF range that people seem to use in the demo videos. There's nothing I've cared to DF in the 800MHz range.
Here are some photos: https://photos.app.goo.gl/K1PndvpgotPKdeBU9

Streets814
Posts: 4
Joined: Tue Oct 15, 2019 12:44 am

Re: KerberosSDR Developments in 2020

Post by Streets814 » Tue Oct 15, 2019 12:52 am

rtlsdrblog wrote:
Thu Oct 10, 2019 4:31 am
ckoval7 wrote:
Wed Oct 09, 2019 7:35 pm
[*] Networked DFing - With several networked KerberosSDR units spread out around a city it will be possible to instantly direction find any signal.
I'm actively working on my own implementation of this. I would love to work together if you're interested.

[*] Hardware: Switches and an improved calibration PCB - It should be investigated if switches degrade the phase calibration or not. With switches we could eliminate the need to disconnect the antennas when recalibrating.

I am presently experimenting with the HSWA2-30DR+ from Mini-Circuits. The PCBs just arrived in the mail today and I will have results by Sunday night. This chip allows selecting between 2 antennas and an internal 50 ohm load.
Excellent, happy to see contributions! This has been the goal from day one.

For networked operation the stop-gap idea was to get this program compatible with the KerberosSDR http://www.musther.net/RDFMapper/.

But if you're happy to open source and throw your code up on GitHub i'll help test it too.

Will be definitely keen to hear about your switch experiments too. Keep in contact either here on the forums or [email protected].
I like this! I purchased a PA8W doppler RDF from wil. Just haven't got around to putting it together as it seams a bit complex. The http://www.musther.net/RDFMapper/ was one of the reasons that sold me on the direction finder.

I am following the KerberosSDR project and will be purchasing some once it evolves a bit more. The rdf mapper, combining 2 devices for accuracy and the ability to network link are big for me.

Keep up the great work!

WA4OSH
Posts: 1
Joined: Thu Nov 07, 2019 5:07 pm

Re: KerberosSDR Developments in 2020

Post by WA4OSH » Thu Nov 07, 2019 9:42 pm

Is it possible to use a GPSDO with the KerberosSDR so that all four (or eight) RTL-SDR DAQs are all sync'ed to the same source?

Eg. the Leo Bodnar Mini Precision GPS Reference Clock
http://www.leobodnar.com/shop/index.php ... &cPath=107

rtlsdrblog
Site Admin
Posts: 2375
Joined: Mon Nov 19, 2012 11:54 pm

Re: KerberosSDR Developments in 2020

Post by rtlsdrblog » Fri Nov 08, 2019 3:45 am

WA4OSH wrote:
Thu Nov 07, 2019 9:42 pm
Is it possible to use a GPSDO with the KerberosSDR so that all four (or eight) RTL-SDR DAQs are all sync'ed to the same source?

Eg. the Leo Bodnar Mini Precision GPS Reference Clock
http://www.leobodnar.com/shop/index.php ... &cPath=107
Actually if you can set it to output a 28.8 MHz signal, you could use the clock input on the board and set the MASTER/SLAVE jumper to SLAVE. But i'm not sure what application you have that would require such a precise clock?

Post Reply