-
-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add skip option #72
Comments
This is a bit of a difficult one to implement, and kind of goes against how auto_rx currently operates (which is to lock on to a sonde and track it until signal is list). It would also result in gaps in the flight paths. To track multiple sondes with the current codebase, you can add more RTLSDRs. |
We have multiple probes at the same time on air here. a friend did a quick hack to skip to the next probe, so i can now catch all. but the "hack" is very dirty :) https://pastebin.com/raw/YGBhAvMX For logging i use https://radiosondy.info/ |
I can see the value in this option. It would be a lot cleaner doing this with 2 RTLSDRs - in that case one can be constantly scanning, and then the other RTLSDR can round-robin through the currently detected radiosondes. Doing it with a single RTLSDR will add long gaps while scanning and detection takes place. |
Ideas on this (so I don't forget):
The loop would:
The same options that are currently disabled in multi-SDR mode (OziMux output, Rotator control, any uploaders with fixed sonde IDs) would need to be disabled in this mode. |
Have raised #77 to deal with the APRS uploader hackyness, which is probably why it doesn't work with radiosondy.info at the moment. |
Halloha, I have written a simple bash script to receive multiple sondes in parallel using only 1 rtl-sdr. No, this is not frequency hopping, decoders really work at the same time with different frequencies. Then I patched auto_rx so that it receives the decoded info as json strings over UDP. Here's an example of receiving 3 sondes in parallel https://imgur.com/d7uGjuj |
Would you be able to share your script? |
I'm writing an article about it and I let you know when it's ready. I patched a version that didn't have UPD sensor type. So basically I made sure that auto-rx doesn't touch my rtl-sdr dongle but would still run and added a new UDP sonde type like you did but my cmd was just 'nc -luk 5678'. Then set rx_timeout = 18000000000000 so that it wouldn't exit |
Probably better to try it with the latest version of auto_rx then? It would be useful if this could be done without major modifications to auto_rx. |
the change that is needed is to start auto_rx without any radio hardware, so that it would simply sit and listen on a UDP port for decoders json strings. The newest trunk code would still access/stop my dongle if I start it with -m UDP. If I define sdr_quantity = 0 then it wouldn't start at all. Second thing which could be useful is that beside desoders json string I could provide power measurements in some form. It could also be a json string. For my sonde hunting app I'm adding a 'response_type' tag to every json that is sent back to the client. So each decoder json string is preprocessed with jq --unbuffered -rcM '. + {"response_type":"sonde"}'. In case of the power scanner output I'm adding "response_type":"log_power" into a json string with power measurements. So if the auto-rx is in the UDP state and simply listens it can also show the spectrum |
do you know btw how multiple receiving is implemented in dxlAPRS? Are they using frequency hopping? |
Solving the first problem (Allowing auto_rx to run without SDRs) is probably fixable with some kind of override when in UDP mode. I believe dxlAPRS has some kind of channeliser system, but it seems to have fairly fixed frequency steps. Of course there's always the limitation of the SDRs bandwidth too. I'd still prefer some kind of network-based server (think: spyserver, but not closed source), that allows a client to connect in and request an IQ stream at a particular frequency. This would allow the greatest flexiblity. |
not sure what channaliser is, but if it what I think then my script works similarly. Tuner is always on the fixed frequency but the IQ stream is multiplexed into number of decoding threads and into the power scanner. Power scanner then tells decoder threads to shift the IQ signal to specific frequency or to stop if no activity detected anymore. |
http://flux242.blogspot.com/2020/08/how-to-receive-and-decode-multiple.html |
Does this duplicate the baseband rtl_sdr stream for each signal? Similar to |
looks interesting. This would allow dynamic creation/disposing of decoding processes unlike my current solution where it is statically preallocated |
Dynamic creation/disposal of channels via connections via a network interface is exactly what I'm looking for to move auto_rx to a parallel decoding system :-) |
I could try the following design:
will this work for you? |
or client connects to the control block using TCP and receives JSONs over UDP broadcasts. |
@darksidelemm @flux242 |
@rs1729 well, auto_rx can of course handle clients itself. The power scans should not be stored in a file then but be sent over TCP the same way like IF is sent |
If auto_rx runs the server, it could read the power scan file as it would when created by rtl_power (it is not the same format right now). For more than one sdr device the filenames should be different. Probably it could also be send over TCP. You could separate server and client, but then more information about the scan results etc has to be communicated. EDIT: |
here is a new script version that uses iq_server/iq_client concept https://flux242.blogspot.com/2020/08/how-to-receive-and-decode-multiple_10.html |
here I've created a pastebin with the changes I've made to the auto-rx latest trunk to run it without any hardware in the UDP mode https://pastebin.com/CqWvNunc basically the trick is to let the device_idx start with TCP in the station.cfg (no changes in the code required) |
I'm really running low on time to work on these kind of changes. If you can work the changes into a pull request (targeted at the testing branch) that doesn't result in degradation of functionality to other aspects of the software, i'd be happy to merge them in. The changes look fairly benign. |
Some more notes on the IQ server/client concept, from a recently email I sent: So auto_rx needs two things:- It needs to be able to get a snapshot of spectrum of the entire band of interest. At the moment this is done using rtl_power, which handles things like stepping the receiver in steps to cover a frequency range wider than the receivers bandwidth, and it also does averaging. I get the output from this in CSV format and run it through a peak detection algorithm in Python. That peak detection alg works fine. Next, I need to be able to get a narrow-band IQ channel (48 or 96 kHz sample rate & bandwidth, signed 16-bit samples). This is what drives pretty much all the decoder, and the dft_detect utility accept nowadays. The first step auto_rx does is to pipe the IQ into dft_detect, which does the signal classification. Once we know the sonde type, I then start up the decoder. All of this is done using python subprocesses, and piping signals around via stdout/stdin. Run auto_rx with the -v option and you'll see all the commands used. There are still a few decoders that require FM demodulated audio as input. At the moment i'm using rtl_fm's FM mode for this, but it's also fairly easy to take some IQ and pass it through CSDR to do FM demodulation - so realistically the source only needs to provide IQ. So, the sources of data at the moment are rtl_power (FFT data over a wide bandwidth), and rtl_fm (FM audio and narrowband IQ). Each of these take up an entire RTLSDR while running, which is obviously a waste of resources. The first requirement could be realistically just be done by requesting the full SDR bandwidth, and just taking a FFT, so I wouldn't say it's a hard requirement that the server does the FFTing. This software here is essentially doing the server part of the above: https://github.com/dernasherbrezon/sdr-server .. however it's RTLSDR only. As you mention, something like SoapySDR would allow use of a wider range of SDRs. So the above works for a single SDR - but we also have the issue that quite often the frequency ranges we are interested in exceed the bandwidth of a single SDR (e.g. a RTLSDR - max 2.4 MHz reliable bandwidth, but the radiosonde band in europe is 6 MHz wide). So what do we do here?
The client part of this could be implemented as some binary which we can use in a similar way to rtl_power and rtl_fm right now - but instead of connecting to a SDR directly, it connects to a server which is started up separately.
|
RTL-Airband can receive many AM voice channels from multiple rtlsdr's simultaneously, and FM in a limited way (runs out of cycles) the fft is done on the GPU (at least for raspberries) |
The idea to retune hardware to be able to receive wider than the baseband can be implemented even using iq_server. There's a problem though- if 2 sondes are 2.5mhz apart and baseband is only 2.4mhz , to which one should it be tuned? Should there be a time window to jump from one to another? Is it really a viable solution ? How well does it scale? No, it isn't a solution. If you need wider tuning range than there are 2 options: use proper hardware that covers you frequency range or start multiple iq servers. The receivemultisonde.sh can be adjusted a bit to run in Multihardware mode. |
The |
If the software detects a probe, the decoder remains attached to this probe.
But as there are many probes in the air it would be good if the decoder could jump to the next probe after a few seconds.
The text was updated successfully, but these errors were encountered: