Thanks for sharing! That looks fantastic.
I’m not sure why UDP is not giving you good results, but in some cases it can give problems with lost samples or clipping when converting to int16. Maybe you can try using a named FIFO with the “File sink” block in the SatNOGS side and the --rawinput option in gr-satellites. I’ve never tested reading from a FIFO in gr-satellites, but I guess it should work.
To be clear, UDP audio works really well, just too bad it depends heavily on the demod script chosen. The main goal was the bpsk script and it is working, so I shifted focus to fsk/fm and that audio is quite different, also depends on the baud sent to it. This is why I chose to add another UDP sink that takes the doppler_corrected virtual sink with complex data at 48k or more and send to gr-satellites using the --iq parameter. It is up and running on my station 1864 but I think it has less successful frames than before.
That’s why I decided to capture the raw iq data that can be enabled in satnogs-client, uploading them to a local server for later experiments. Here’s where the problems started. If I run a observation ogg (wav) through gr-satellites I get all or most frames out from it, when I use the --rawin16 xxx.raw I get perhaps 25% of the frames compared to the wav. I then built a grc that replays the xxx.raw to both UDP audio and iq, so I can mess with different settings etc, I get perhaps 50% of the frames decoded compared to the wav.
When running the UDP with --iq I get more of less warnings of dropped frames, --throttle seems to make things worse. Maybe I can upload the files somewhere and the scripts I use to run them so others can test and see whats going on.
One note, the IQ sink in the satnogs flowgraphs uses a very odd scale, probably a typo: 16768.
I have discussed this on the IRC channel and it should either be 2^15-1 or 2^14-1.
Do you have an example of the uploaded KISS files? An observation link or DB entry would be ok.
Thanks,
Patrick
Funcube-1
Nayif-1
jy1sat with ssdv pictures
Innosat-2
That is somewhat surprising. Given that OGG is a lossy format, I would expect you get at least the same amount of decodes with the other output formats, not less. I guess that there is something wrong in the signal processing chain that degrades the signal, so that only the strongest packets can still be decoded. My main suspects would be clipping, aliasing, and too narrow filtering. I think we have the OGGs from the observation links you shared. If you share the other files, we can look at them and check for obvious problems.
I was just wondering on that part - you’re doing it correctly as those files are not the KISS encoded ones! Well done for this at least 
Probably, I have not dug too deep in the IQ file sink that is in the satnogs-flowgraphs, I have assumed this would be working. Assuming I have done the byte massaging correct in the flowgraph, and also running with the correct input source in gr_satellites.
I put one of my tests that showed big differences in the decodes here:
https://drive.google.com/drive/folders/10iAaU8WzrW24zvleyl_3ZeHRI3WnKy-_?usp=sharing
I have tried different settings in the scaling etc but not able to come up to the wav performance.
It’s only using the kiss as a intermediate format between gr_satellites and satnogs-client, using the timestamps for file name and only frame data in the file itself. 
Not able to control how gr-satellites decide to format the data thou, possibly small differences between satnogs demods in the leading/trailing bytes ?
I took a look at your raw file, and the problem is actually with the way that IQ input for FSK signals works in gr-satellites.
When you use IQ input, gr-satellites needs to perform the FM demodulation of FSK, and so it needs to know the deviation of the FSK signal in order to use the correct gain in the quadrature demod. The default deviation is 5000 Hz, because this is sort of standard for Amateur packet radio, and because no-one has made a thorough study of the deviations used by each of the FSK satellites.
It turns out that AAUSAT-4 uses a deviation of around 1000 Hz, so the default is inadequate. Interestingly, the deviation for a 2400 baud GMSK signal would be 600 Hz, but the deviation seems higher than this.
When running with non-IQ input, this is not an issue because since we don’t know the gain of the FM demodulator (which is external and typically uses the wrong gain), there is an AGC to compensate for this.
So you have two options to improve the decodes with the IQ data. Specify the deviation, as:
gr_satellites AAUSAT-4 --rawint16 3250192_2020-12-05T13-16-58_AAUSAT_4.raw --samp_rate 48e3 --iq --hexdump --deviation 1000
or enable the same AGC that is used with the non-IQ input:
gr_satellites AAUSAT-4 --rawint16 3250192_2020-12-05T13-16-58_AAUSAT_4.raw --samp_rate 48e3 --iq --hexdump --use_agc
Both of these will give me 14 decodes, while the wav file gives 18 out of 20 visible packets (and 2 of them are too weak to expect to be able to decode them).
How to improve this further and get back our 18 packets? I’ve reviewed the FSK demodulator for the IQ case (which sees much less use than the non-IQ case, so it might have some rough spots), and the issue is that all the input goes directly to the quadrature demod. So here you’re needlessly feeding in 48kHz of noise into the demod. The appropriate thing to do is to put a lowpass filter before, that cuts off a bandwidth according to Carson’s rule.
I’ve just done this (and will now push the commit to master) and now I get 18 decodes with both of the command lines indicated above. Carson’s rule depends on the deviation, so the correct thing to do would be to specify the --deviation even if using --agc_on, but even so I still get 18 decodes if I don’t do it.
Very impressive change 
From the work I’ve done on the grsat-wrapper.sh script in audio mode I had to treat bpsk differently (offset). Then added a bit of guesswork (find_samp_rate.py) for the sample rate when switching to --iq and I’m seeing a small calculation/guesstimate on the deviation required in the near future 
For the flowgraph producing the UDP IQ frames I have placed a AGC 2 block to minimize the limitations on int16, pondering on how to properly scale these to avoid clipping. The first suggestion was a reference of 0.5 and scaling on 32767. Perhaps lowering the scaling to 16383, while loosing one bit of resolution it should still be fine for the SDR’s commonly used. This could also be done with a complex to ishort as well, not tried it yet.
In the wild, used on many different birds using more or less correct deviation, drifting and frequency calibration on the receivers; how much would one need to increase the deviation to give decent results ? given the limited info one gets in the post-op-script parameters, baudrate / 2 ?
Actually it makes sense to list the deviation of each satellite in the SatYAML files in gr-satellites. However, that requires the effort and tools to measure the deviation for each satellite, which is the main reason why this parameter is currently missing.
For GMSK (or MSK), which seems quite popular lately, the deviation would be baudrate/4. Other transmitters use higher deviations.
Regarding clipping, in an int16 you have plenty of bits, so it’s not an issue if you leave a couple bits of headroom. The important thing is not to get confused with the scaling in the conversion blocks (I always get confused), so it’s good to look at the amplitude of the output and check if it’s as expected.
I’ve messed around with the AGC and scale and found a setting that seems to work ok for IQ data.
It’s actually the same as the audio path (15m) and it decoded all the frames in the previously mentioned raw-file.
The method I used - probably not optimal - was a QT time sink with abs in front of it, to visualize the noise floor and how large signal bursts looked.
On another topic, I am running the higher sample rates on the doppler corrected iq stream and getting dropped frames, for example obs 3269442 wich was a 19k2 using the fsk demod. My calculations shows 76k8 and the flowgraph tells the same, still getting a bunch of:
gr::log :WARN: udp_source0 - Too much data; dropping packet.
Althou this obs 3271242 running at 9k6 fsk, with a samp rate of 57k6 is just running fine, no dropped udp packets. My first thought was a problem with samp rate > 48k.
(Dupe frames from running two decoders, one in the fsk flowgraph and one from gr-satellites. Not sure how to solve this)
Hello,
I would like to try some of your IQ files on gnuradio-companion, are they raw files produced by satnogs-client?, how do I find out their sampling rate?
thanks for sharing!!..
Cheers…Abraham - xe3adc
Great!
They were produced by Satnogs. A description is available at Understanding satnogs-flowgraphs - SatNOGS Wiki
I found the tool soxi useful when I don’t now the sample rate.
When there is no meta information in the file, then soxi will also fail to produce information.
Example:
soxi example.wav
Input File : 'example.wav'
Channels : 2
Sample Rate : 500000
Precision : 16-bit
Duration : 00:06:52.76 = 206382500 samples ~ 30957.4 CDDA sectors
File Size : 826M
Bit Rate : 16.0M
Sample Encoding: 16-bit Signed Integer PCM
Hi,
tried to know witch version of gr-satellites i have on my station.
$ gr_satellites --version doesn’t show me the version…
VE2DSK
(I know v3.x.y is version compatible with my GNU version 3.8.2.0-14)
built from source ? then it should have some git tag perhaps.
if binary then 3.16 or 3.18 iirc.
please paste the output here.
@Acinonyx or someone else needs to sync the package versions between satnogs-unstable and satnogs repo at OBS.
In any case, gr_satellites --version should print something (unless it is a really old version of gr-satellites or something is wrong with the installation). What is the output you get?