@oe6rke (Robert) has been doing some fantastic work on setting up his ground-station lately. The GS already produced some results!
I took the chance to decode some captured ISS payloads so here is the decoding of payload 640 (of observation 192.
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
APRS: OE6MUE-7>TWPS86,RS0ISS:’+3Nl [/>73 via ISS de Mike
In order to get the demodulated data I did the following:
Download the .ogg data recording
Convert it to raw (possibly not needed?) using oggdec --raw=1 input_file.ogg
Decode it with multimon-ng -A -t raw input_file.wav
note the -A for the AFSK1200 demodulator
Moving forward we should be able to automate this process in the network! Thoughts and comments welcome.
I think it would be a really good thing to be able to get the raw IQ data. This would allow to really improve existing decoders and on occasion probably allow to recover a signal that would otherwise be useless to standard decoders.
Issue would obviously be amount of data but if we do a resampling just to the bandwidth that the signal should be within this could probably be in the area of 5-10MB for a 15 minute pass even with a 12 bit ADC.
would be really appreciate such feature.I thought of using modded rtl_sdr instead rtl_fm for this purpose. But i dont know if sdrsharp can read such file and where to but that files for community purpose…
SDR Sharp, GQRX, etc. all are capable of reading IQ files in at least one format. Problem with IQ files is that there is plenty of ways in which they can be serialized. Good thing is that it’s easy to convert them into whichever format as long as one base format is available without any loss. I am thinking of this similar to photography where you would likely want to preserve the RAW image until you have done everything you can in terms of conversion.
I’d be happy to work on a warehousing system for storage of these. With cold storage going for 1 cent/GB/month these days this shouldn’t be a big spend for a long time.
Storing IQ would be a huge advantage for SatNOGS in the long run. @wnagele do you have any idea on how big a single observation would be (given that it is aprox 5-15 mins on average?)
My thinking would be to keep the current setup and add a parallel raw IQ stream. Recording on client, posting on a cold storage system and posting the associated link to the file back to network so we can track this.
Factors are bandwidth and ADC precision (RTL SDRs output 8 bits).
Here is an example for a 2kHz bandwidth using a RTL SDR for a 15 minute pass:
8 bits * 2000 (bandwidth in Hz) * 2 (as we cover I and Q data) * 60 seconds * 15 minutes / 1024 / 1024 / 8 ~= 3.5MBytes
To avoid large startup costs I would probably suggest using something like Google Nearline storage (https://cloud.google.com/storage-nearline/). Pricing is very good but it doesn’t have the retrieval times of 4+ hours of traditional cold storage systems. You can basically store almost 300 recordings for a cent per month.
As for implementation it would probably be best to come up with a lightweight tool that does what rtl_sdr and hackrf_transfer do but using the Osmocom libraries. This way we would support a number of hardware devices directly. Other than that a simple resampler or low pass filter would suffice to decimate the 2Msps input sample rate down to the actual signal.
I’d be happy to work on something for this. I’d need some pointers to make this properly interface with the overall system. Let me know what you guys think.
Had a bit of a look around and there seem to be plenty of transponders out there that have 30-50kHz bandwidths. Uncompressed that would bloat the required storage capacity pretty drastically and also the upload bandwidth required.
I think before going into any of this we would have to get a better idea of bandwidths of the signals out there and compression rations we can achieve.