Totally right, with ogg and mp3 there will be some data loss and there will be problems to further work with the signal, making them unusable for something else than voice
We should be using iq or baseband uncompressed wav files (bzipping them to save bandwith).
We have looked into posting raw audio or raw IQ. Unfortunately their size makes it prohibitable for posting back to the network via a plain internet connection.
We should investigate that possibility as an option for stations that have really good upload bandwidth.
Also compressing them with lossless algorithms makes almost zero change (due to random rf noise being the majority of the data).
Possible. However with one of the reference architectures being a raspberry pi your space is limited (typical SD card of 16GB, 32GB…)
This means that retention of captures is going to be very low, making the torrent short lived. To draw a connection, my ground station has done 33 captures in the last 24 hours (thanks @BOCTOK-1!). That would exceed a 32GB SD card easily.
(for comparison, since we don’t yet have data rotation setup quite yet, I have 348 captures of data currently taking 9.5G of space through ogg)
There is definitely value in the IQ data, especially as we try to fine-tune frequencies and look for new or missing satellites… or even deal with compression loss. I will say that I have decoded 19k2 packets just fine given our current setup, however I think some tweaking can be done in our demod process to improve the signal.
Either or both, yes. An ogg source block for gnuradio was just added this week, which ideally could be used in place of wav source in the gr-satellites flows, eliminating at least one possible point of loss:
I’ve created cloud based service https://r2cloud.ru which could decode aausat-4. Is it possible to stream gzipped raw IQ data from stations? If we have it somewhere in the cloud, then we could decode it on a very performant servers. + if current gnu radio blocks cannot decode raw data, then we could improve them and re-run against already existing data.
The bandwidth issue that @pierros mentioned is still a problem for raw IQ. Currently, I’m on a metered connection and the rate at which I am capturing observations I would eat through my monthly plan in 1 day if I were uploading IQ.
It is definitely worth pursuing further though, there is in fact a lot more we could do with it if we solve the network and storage issues.
Awesome! How are you tuning to the data stream? We could use your help in the gr-satnogs and decoder side of db.satnogs.org
What do you mean by “tuning”? Doppler effect? I do not perform any doppler corrections and expect client to perform it before sending any data. I’ve created this project specifically for satnogs, because currently networks.satnogs.org contains a lot of “Waiting for demoded data”