Something that crossed my mind, when doing DF, it would be nice to know if its same TX. There was many years ago a DOS software, that did a fingerprint of the transmitter. Maybe possible to do with krakenSDR also?
2 Likes
RF fingerprinting is something we have in the pipeline to investigate, it should be possible.
6 Likes
I remember that software from the days of DOS. Was FM only. Many days before SDR was common. Had to tap discriminator output of your FM receiver. Took some time to ‘print’ a transmitter as well. Was very effective!
2 Likes
Something that maybe would be great to have is different decoders, for example, if turn off DF or keep on…anyway, able to have FM, AM, DMR, TETRA, Pocsag, P25 etc…i found online that there is for SDR different plugin for this, but would be nice to have in krakensdr. Any plans for this?
3 Likes
Adding a suite of decoders would be a massive task, and one that is already solved by other RTL-SDR software that the KrakenSDR is compatible with.
Did you mean that you want to decode those modes while DFing at the same time?
Maybe a discriminator output that can be fed to another program?
Hello, just a thinking, most because sometimes you want to know that signal(voice,data etc) is still there. And also if its a pirate, if say something useful when try to find the pirate. But of course having a separate RX works. Just more equipment to bring.
It wouldn’t be like a traditional audio discriminator output, but there is probably a way to get a raw TCP stream of the data out. Main problem is that the Pi 4 might not have enough processing power left over to do this, so it would be something for an Orange Pi 5 or higher end computing device.
2 Likes
I am not sure about what would be feasible and useful.
Perhaps a rtl_tcp-like server would be enough for most people. It could serve just the raw input from the first RTL, or from the selected RTL, I suppose.
It would need no DSP in the Pi. The Android app could implement a few decoders, just FM to start with.
If you use two phones, or a phone and a tablet, on one of then you can run Kraken app, and on the other any general purpose SDR app, such as MagicSDR.
I would like to note that you can implement another variation: you can multiply each RTL signal by a custom complex weight, add all of them and serve the sum as a single beam steered signal.
If you can do it using integer arithmetic, as I was told rtl_fm does, I suppose it will run on the Raspberry Pi.
As I recall that early radio fingerprint system just looked at the (usually unique) start of the rf as the transmitter initially keyed up and took some time to lock on the carrier frequency (undershoot, overshoot, pl drift if present?). No need for codecs, etc.
It disappeared shortly after publication, I assume due to patent/ legal issues. It would be a terrific feature in KSDR if feasible.
For those of us that don’t have the hotspot available while mobile, provide better Map download capability. The interface asks which map to download but from what list? Could the interface provide some indication of what area is already loaded and how much room is available for more. Currently, only 6000 grid squares can be downloaded. You find out the limit when you hit it.
Thanks,
N9SCD
The map downloads based on the current map view area and zoom.
But yeah we’ve looked into ways to try and show the number of tiles that will be downloaded, but it seems that it’s currently not possible with the current MapBox API.
Eventually we might add an alterative mapping service like open street map which you can manually add your own tiles into, but there will be no satellite maps for that.
I think they meant having the capability to DF RadioIDs within those different protocols if it was possible. DFing rogue RadioIDs can be challenging in the DMR space. But as you stated before Decoders are massive undertaking. Is there a possibility to merge DSP+/FMA with the KrakenSDR to DF specific RadioIDs? Huge fan of what KrakenRF has already achieved.
We’ll look at a way to make the raw radio data streamable over TCP, then any software should be able to connect to that for decoding purposes. But the challenge will be finding a way to synchronize the DOA detections with whatever third party software is used.