Closed janvgils closed 3 months ago
I agree that the --deviation
and --use_agc
parameters of the FSK demodulator could be described in more detail in the documentation. These are slightly complicated due to the fact that there is support for both an IQ input and an FM-demodulated real input (probably with unknown volts/Hz gain), as well as the fact that some satellites use rather different deviations and this is usually not documented by the satellite owners, so there is no attempt made at comprehensively setting the deviation for each satellite in the SatYAML file.
Since your questions are only about IQ input, I won't speak in detail about FM-demodulated real-input in this answer. By default, the FSK demodulator assumes a deviation of 5 kHz unless there is a deviation specified either in the SatYAML file or with the --deviation
command line parameter. The default of 5 kHz comes from the fact that it's the value most typically used in amateur packet radio, although IARU R1 recommends a deviation of 3 kHz, which fits better a 12.5 kHz narrowband FM channel spacing. The deviation is used by the FSK demodulator for two things:
To compute a lowpass filter bandwidth using Carson's rule. Here using the correct deviation is not too important, unless the deviation is wrong by a lot. If the deviation used is much smaller than the true one, then the lowpass filter will be too narrow, cutting away part of the FSK signal, and the decoder won't really work. If the deviation used is much larger than the true one, then the lowpass filter will be too wide, letting additional noise through and hurting low SNR decoder performance (although the decoder will work just fine at high SNR).
For the gain of the quadrature demodulator. Here using the correct deviation is more important, since the Symbol Sync block requires a signal of amplitude one and will work badly if the amplitude is somewhat different from one. Moreover, if the satellite in question has a FEC decoder that uses soft symbols such as a Viterbi decoder, the symbols will also have a wrong amplitude, which might give problems with the FEC decoder. As a rule of thumb, I'd say that the deviation should be set with a 20% error or better with respect to the true deviation for this to work fine.
There is also the --use_agc
parameter. By default, with an IQ input an AGC is not used. If --use_agc
is specified, then an AGC is inserted immediately before the Symbol Sync block. This AGC is used to normalize the signal to unit amplitude even if the deviation is set quite wrongly. Informally, --use_agc
is the same as saying "I don't know and don't care about what is the true deviation of the signal" (although --use_agc
doesn't protect one from specifying a deviation that is too wrong, which will make the Carson's rule lowpass filter bad). Specifying the correct deviation (or using the default of 5 kHz if it's close enough) is better than using --use_agc
, because the AGC needs some time to converge, can be upset by noise or interference, etc. It doesn't make much sense to use both --use_agc
and --deviation
.
The main reason why there is an optional AGC in the first place is because of the FM-demodulated real input mode, where the AGC is absolutely necessary (and always enabled) due to the unknown gain of the FM demodulator, which is external to gr-satellites. I don't know why grsat-wrapper.sh
is defaulting to --use_agc
, given that it also uses --iq
(maybe @kng knows). The --use_agc
option might have some value with IQ input usage to do quick experimentation for a satellite that has unknown deviation that is quite different from 5 kHz (so the default of 5 kHz is giving bad results) to get some results quickly without having to measure and specify the deviation manually. But for normal usage I'd refrain from using --use_agc
with IQ input. If a satellite has a deviation that is too different from 5 kHz to make the FSK demodulator work well, then its deviation should preferably go in the SatYAML file.
Hi Daniel,
Thanks for the quick reply, but due to the lack of knowledge on my side, your response is creating even more questions.
For now I try to implement your suggestion by leaving the --use_agc
and try to find a working --deviation
value.
The strange thing is, that although removing the --use_agc
and trying multiple --deviation
values the output is different every time. (pdu_length is different also)
Some examples that I tried (and lets not forget, this is GNURadio 3.8 with the tnc_nx OOT):
name: TUBIN
norad: 48900
data:
&tlm Telemetry:
unknown
transmitters:
4k8 FSK downlink:
frequency: 435.950e+6
modulation: FSK
baudrate: 4800
framing: Mobitex-NX
data:
- *tlm
gr_satellites TUBIN.yml --rawint16 iq_48000_9628118.wav --samp_rate 48e3 --iq
no frames despite that 5000 should be the default
gr_satellites TUBIN.yml --rawint16 iq_48000_9628118.wav --samp_rate 48e3 --iq --deviation 5000
frames are present
And to make things even more confusing, when I repeat the same command multiple times sometimes the outcome isn't the same. Adding deviation to the yaml file also gave different results.
For now, I guess we need some help from the team so we know the expected pdu_length and then try to figure out the optimal deviation value.
And in the future we need to work towards yaml files with the right deviation value and remove the --use_agc
option.
I don't know why
grsat-wrapper.sh
is defaulting to--use_agc
, given that it also uses--iq
Hmm, I don't recall why, but it might just have been a relic from the beginning when I tried using signed integer as output. I removed it from both the old repo and the newer implementation
And to make things even more confusing, when I repeat the same command multiple times sometimes the outcome isn't the same. Adding deviation to the yaml file also gave different results.
Yeah, I also have mixed results with trying different parameters to see what works best. You also need to run it several times to get some average. This is ofc a pretty empiric method, probably better to do it the proper way, but I don't have any experience on that so will probably get nowhere :D
From one of the TUBIN team members are received the following reply:
Can you help in getting the FM deviation used by TUBIN and maybe also other TU Berlin satellites? Further I was wondering if the frames always have the same length and if you could provide it (them) This gr-satellites issue https://github.com/daniestevez/gr-satellites/issues/545 is related to these questions.
As far as I understand the FM deviation should be 1200 Hz (My collogue said "In MSK the difference between the higher and lower frequency is identical to half the bit rate. I.e. die frequency derivation should be ±1200 Hz (~ differce 2400 Hz)"
With this value the output is the same every time I run the command, this gives me the idea we are on the right path.
gr_satellites 48900 --rawint16 iq_48000_9621861.wav --samp_rate 48e3 --iq --deviation 1200
* MESSAGE DEBUG PRINT PDU VERBOSE *
((transmitter . 4k8 FSK downlink) . 1)
pdu_length = 592
contents =
0000: 3f 0e 44 50 30 54 42 4e 15 c0 05 11 1e cc 00 1c
0010: 01 2d ed 45 5c 05 15 dc 0c 00 00 00 00 00 00 00
0020: 00 00 00 ff 02 02 03 00 00 00 00 00 00 00 00 00
0030: 00 ff 40 ab a4 00 10 01 2d ed 45 5c 00 10 46 00
0040: 00 10 0d 00 00 1e 00 10 1a 72 00 06 a6 a7 34 25
0050: 00 07 01 2d ed 45 5c 02 29 54 01 27 58 5b 06 34
0060: a8 40 00 03 01 2d ed 45 5c 0a f9 00 00 03 89 1f
0070: 00 11 08 2d ed 45 5b 06 3c 5c 17 00 10 5c 00 c4
0080: fd 1e 23 58 00 01 00 2b 00 35 a2 eb 00 41 08 2d
0090: ed 45 5b 06 83 00 06 64 39 00 00 4c 9f ff fe df
00a0: a0 00 0d ce 7a ff fd 01 15 ff ec 00 02 00 03 00
00b0: 05 02 53 ff 24 fe 32 01 de fc b3 00 ed ff 29 02
00c0: 9d fe 9a 01 45 03 63 01 78 05 1c ef fe 14 d2 ff
00d0: fd 00 05 00 04 00 b1 fb 00 1d 18 2d ec f8 36 00
00e0: b2 00 40 00 1f 00 20 3f bc 00 13 0d 38 04 fa 3f
00f0: b2 3f c4 00 0b 0d 4c 05 03 3f cc 10 10 00 2f 7f
0100: 00 2a 18 2d ec f8 36 00 a9 00 40 00 1f 00 20 27
0110: 00 00 00 00 00 00 00 1a 26 18 11 0e 10 1a 1d 39
0120: e0 2e 1c 00 00 00 00 00 0b 1d 28 2a 24 1d 17 14
0130: 14 3b 77 ff 74 00 2a 18 2d ec f8 ae 00 a9 00 42
0140: 00 20 00 25 00 00 00 00 00 27 00 00 25 21 15 10
0150: 0f 17 19 1c 3b 2a 1e 00 00 00 00 00 00 28 27 2d
0160: 24 1d 18 14 13 1a 3b 66 97 f1 00 2a 18 2d ec f9
0170: 26 00 a9 00 42 00 1f 00 22 00 00 00 00 2a 47 00
0180: 00 2c 1a 12 10 14 22 19 1a 3b 4c 00 00 00 00 00
0190: 00 0a 00 2e 29 1d 18 15 13 16 24 3b 09 e1 01 00
01a0: 04 13 2d ec f9 62 06 81 04 89 24 c0 f5 e7 00 41
01b0: 13 2d ec f9 62 06 83 00 07 bf ce ff fa e3 76 ff
01c0: f9 f4 3b 00 0a 7e 27 ff 04 00 36 00 ad ff fe ff
01d0: fb ff ff 01 f6 02 7d ff 2d 02 c6 fd 7a fe eb ff
01e0: 14 01 97 fd 66 01 48 03 62 01 77 ff 80 08 7d e6
01f0: 93 00 03 ff fa ff fe 00 e7 0b 00 24 13 2d ec f9
0200: 62 06 b5 01 04 01 63 01 29 00 f7 01 42 01 27 01
0210: 15 01 74 01 2e 00 f7 01 33 01 29 01 4f 01 4a 01
0220: 22 01 1d 01 1d 01 1d ad b0 00 11 17 2d ec f9 62
0230: 05 66 00 22 20 23 23 26 25 22 1f 24 26 21 27 26
0240: 28 24 21 84 90 ff ff ff ff ff aa 00 00 00 00 bb
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
((transmitter . 4k8 FSK downlink) . 1)
pdu_length = 592
contents =
0000: 3f 0e 44 50 30 54 42 4e 15 c0 05 11 1e cf 00 1c
0010: 03 2d ed 45 63 05 15 dc 0c 00 00 00 00 00 00 00
0020: 00 00 00 ff 02 02 03 00 00 00 00 00 00 00 00 00
0030: 00 ff 40 6a 16 00 10 03 2d ed 45 63 00 10 46 00
0040: 00 10 0d 00 00 1e 00 10 1a 73 00 07 a6 a7 99 94
0050: 00 07 03 2d ed 45 63 02 29 54 01 22 57 59 06 34
0060: 3c 71 00 11 08 2d ed 45 62 06 3c 5c 17 00 10 63
0070: 00 35 fd 7f 23 5e 00 01 00 2a 00 35 02 f8 00 41
0080: 08 2d ed 45 62 06 83 00 06 66 bd 00 00 15 16 ff
0090: ff 05 92 00 0d d0 f8 ff f2 01 24 ff c0 ff fe 00
00a0: 06 ff f7 02 5d ff 21 fe 3d 01 d4 fc b4 01 02 ff
00b0: 2c 02 9b fe 8f 01 45 03 63 01 78 05 05 f0 22 14
00c0: f2 ff fd 00 05 00 04 00 67 a1 00 03 03 2d ed 45
00d0: 63 0a f9 00 00 03 bd 1a 00 2a 18 2d ec fb 7e 00
00e0: a9 00 42 00 22 00 22 00 00 00 00 00 00 00 00 1c
00f0: 11 11 13 1b 20 13 0f 02 6a 00 00 00 00 00 00 00
0100: 00 1a 11 0d 0d 0d 11 1a 1f 02 7b 8e ea 00 24 13
0110: 2d ec fb ba 06 b5 01 40 01 09 00 de 01 01 01 60
0120: 01 13 01 47 01 1f 00 e3 00 ed 01 56 01 1f 01 2c
0130: 01 31 01 36 01 31 01 31 01 31 46 2d 00 04 13 2d
0140: ec fb ba 06 81 08 89 44 c1 fc bb 00 41 13 2d ec
0150: fb ba 06 83 00 02 35 29 00 0b 2c ad 00 09 e6 b1
0160: ff fd c0 79 ff af 00 75 ff 9e ff fe 00 01 ff fd
0170: 00 8e 01 2d 03 9b 7f ff 7f ff 7f ff 00 93 fe ab
0180: fc 77 01 48 03 62 01 77 07 60 f8 e1 e7 38 00 02
0190: ff fa 00 02 64 fe 20 00 11 17 2d ec fb ba 05 66
01a0: 00 29 24 23 25 28 1f 1d 24 26 21 24 21 1b 1d 1b
01b0: 24 53 1d 00 1d 18 2d ec fb ba 00 b2 00 42 00 20
01c0: 00 25 3f 8c ff 01 0d 3a 04 ff 3f 66 3f 80 ff 66
01d0: 0d 4e 05 07 3f 80 15 15 f0 e4 5d 00 2a 18 2d ec
01e0: fb f6 00 a9 00 42 00 20 00 22 00 00 00 00 00 00
01f0: 00 00 18 11 10 12 17 19 11 0e 01 da 00 00 00 00
0200: 00 00 00 00 15 0f 0c 0b 0c 0f 15 18 01 da d1 d1
0210: 00 2a 18 2d ec fc 6e 00 a9 00 42 00 23 00 25 00
0220: 00 00 00 00 00 00 00 15 10 0f 11 14 16 0f 0c 01
0230: c9 00 00 00 00 00 00 00 00 12 0d 0b 0a 0a 0d 12
0240: 14 01 c9 ad 41 ff ff ff ff ff aa 00 00 00 00 bb
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
((transmitter . 4k8 FSK downlink) . 1)
pdu_length = 574
contents =
0000: 3e 0e 44 72 34 74 42 4e 15 c0 05 11 1e d2 00 1c
0010: 07 2d ed 45 6a 05 15 dc 0c 00 00 00 00 00 00 00
0020: 00 00 00 ff 02 02 03 00 00 00 00 00 00 00 00 00
0030: 00 ff 40 59 06 00 10 07 2d ed 45 6a 00 10 46 00
0040: 00 10 0d 00 00 1d 00 0f 1a 75 00 07 a6 a7 0e eb
0050: 00 07 07 2d ed 45 6a 02 29 54 01 22 59 58 06 34
0060: 71 b0 00 11 03 2d ed 45 6a 06 3c 5c 17 00 10 6d
0070: ff 98 fd e2 23 5f 00 01 00 2a ff 35 f6 0f 00 41
0080: 03 2d ed 45 6a 06 83 00 06 6a e3 ff ff d7 51 ff
0090: ff 2c 1e 00 0d d1 65 ff fa 01 1d ff cf 00 07 ff
00a0: fe 00 02 02 67 ff 1c fe 4a 01 c8 fc b4 01 16 ff
00b0: 2e 02 98 fe 83 01 45 03 63 01 78 04 ec f0 48 15
00c0: 15 ff fd 00 05 00 04 00 e4 c3 00 03 07 2d ed 45
00d0: 6a 0a f9 00 00 03 58 cd 00 1d 18 2d ec fe 12 00
00e0: b2 00 42 00 23 00 25 3f 44 ff 19 0d 3a 04 ff 3f
00f0: 22 3f 7c ff 4d 0d 4e 05 07 3f 66 17 16 f0 fc 3e
0100: 00 2a 18 2d ec fe 4e 00 a9 00 42 00 20 00 25 00
0110: 00 00 00 00 00 00 00 0f 0b 0a 0d 10 10 0b 09 01
0120: b8 00 00 00 00 00 00 00 00 0a 07 05 05 06 09 0d
0130: 0d 01 b8 48 b5 00 2a 18 2d ec fe c6 00 a9 00 42
0140: 00 1f 00 20 00 00 00 00 00 00 00 00 0d 0a 0a 0c
0150: 0f 0e 0b 09 01 b8 00 00 00 00 00 00 00 00 08 06
0160: 04 04 06 09 0c 0b 01 af 35 14 00 24 13 2d ec ff
0170: 3e 06 b5 00 e1 00 b4 00 98 00 be 00 ca 00 a5 00
0180: ed 00 b6 00 9d 00 b1 00 c5 00 a7 00 d2 00 d7 01
0190: 36 01 31 01 31 01 2c 4c 8d 00 04 13 2d ec ff 3e
01a0: 06 81 08 89 44 c1 99 e9 00 41 13 2d ec ff 3e 06
01b0: 83 00 04 02 75 ff f4 36 e4 ff f8 a3 8e ff fb 22
01c0: 95 ff 1e 00 41 ff d8 00 00 ff fc ff fe 01 50 00
01d0: 34 fd 6f 7f ff 7f ff 7f ff 00 e1 fd f5 01 b3 01
01e0: 48 03 62 01 77 0c 97 e8 f2 fa a5 00 00 ff ff 00
01f0: 07 64 37 e2 00 11 17 2d ec ff 3e 05 66 00 1a 18
0200: 18 18 17 17 14 18 24 1a 1b 10 0f 0f 0f 24 49 44
0210: 00 16 17 2d ec ff 3e 00 b1 01 b8 01 af 3f 2b 00
0220: 2d 3f 66 01 90 3f 01 3f 4d 20 21 00 00 00 00 80
0230: 37 ff ff ff ff ff ff ff aa 00 00 00 00 bb
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
((transmitter . 4k8 FSK downlink) . 1)
pdu_length = 592
contents =
0000: 3f 0e 44 50 30 54 42 4e 15 c0 05 11 1e d3 00 1c
0010: 01 2d ed 45 6d 05 15 dc 0c 00 00 00 00 00 00 00
0020: 00 00 00 ff 02 02 03 00 00 00 00 00 00 00 00 00
0030: 00 ff 40 81 25 00 10 01 2d ed 45 6d 00 10 46 00
0040: 00 10 0d 00 00 1f 00 0f 1a 75 00 07 a6 a7 bc 88
0050: 00 07 01 2d ed 45 6d 02 29 54 01 22 5a 5c 06 34
0060: 21 31 00 11 08 2d ed 45 6c 06 3c 5c 17 00 10 6b
0070: ff 68 fe 06 23 62 00 01 00 2a ff 36 ee 99 00 41
0080: 08 2d ed 45 6c 06 83 00 06 6a 04 ff ff c4 7f ff
0090: ff 3a 05 00 0d d2 56 ff f1 01 0b ff de ff ff ff
00a0: fc 00 04 02 6a ff 1a fe 4e 01 c4 fc b4 01 1d ff
00b0: 2f 02 97 fe 80 01 45 03 63 01 78 04 e3 f0 55 15
00c0: 20 ff fd 00 05 00 04 00 aa b9 00 03 01 2d ed 45
00d0: 6d 0a f9 00 00 03 e3 33 00 6e 17 2d ec ff 3e 00
00e0: b3 00 00 00 00 dd 00 00 00 00 00 00 00 00 dd dd
00f0: 00 dd 00 00 00 00 00 ee 00 00 00 00 00 00 00 00
0100: f0 ee 00 ef 00 00 00 00 00 da 00 00 00 00 00 00
0110: 00 00 db da 00 db 00 00 00 00 00 00 00 00 00 00
0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 00
0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 38
0140: 00 00 00 00 00 00 00 00 12 15 00 17 00 00 00 bf
0150: c3 00 10 17 2d ec ff 3e 00 b0 dd dc ef f0 db db
0160: 00 00 00 00 10 03 28 28 00 00 cb 1b 00 1d 18 2d
0170: ec ff 3e 00 b2 00 42 00 22 00 24 3f 08 ff 1c 0d
0180: 2d 04 f9 3f 01 3f 64 ff 4a 0d 4e 05 07 3f 4d 17
0190: 16 f0 e8 09 00 2a 18 2d ec ff 3e 00 a9 00 42 00
01a0: 22 00 24 00 00 00 00 00 00 00 00 0b 09 0a 0c 0d
01b0: 0c 0a 08 01 b8 00 00 00 00 00 00 00 00 06 04 04
01c0: 04 05 08 0a 09 01 af c7 c2 00 2a 18 2d ec ff b6
01d0: 00 a9 00 42 00 22 00 23 00 00 00 00 00 00 00 00
01e0: 09 08 0a 0b 0c 0a 08 07 01 af 00 00 00 00 00 00
01f0: 00 00 05 03 03 03 05 08 09 07 01 a7 12 51 00 2a
0200: 18 2d ed 00 2e 00 a9 00 42 00 20 00 24 00 00 00
0210: 00 00 00 00 00 08 07 09 0b 0b 08 06 05 01 af 00
0220: 00 00 00 00 00 00 00 03 02 02 03 05 07 08 05 01
0230: a7 57 9b 00 04 13 2d ed 00 6a 06 81 08 89 44 c1
0240: cd d4 ff ff ff ff ff ff ff ff aa 00 00 00 00 bb
***********************************
* MESSAGE DEBUG PRINT PDU VERBOSE *
((transmitter . 4k8 FSK downlink) . 1)
pdu_length = 592
contents =
0000: 3f 0e c4 58 30 5c 42 4e 15 c0 05 11 1e dc 00 1c
0010: 07 2d ed 45 85 05 15 dc 0c 00 00 00 00 00 00 00
0020: 00 00 00 ff 02 02 03 00 00 00 00 00 00 00 00 00
0030: 00 ff 40 87 a4 00 10 07 2d ed 45 85 00 10 46 00
0040: 00 10 0d 00 00 1f 00 0f 1a 79 00 07 a6 a7 da 81
0050: 00 07 07 2d ed 45 85 02 29 54 01 22 58 ff 06 34
0060: c6 9a 00 11 03 2d ed 45 85 06 3c 5c 17 00 0f fb
0070: fd 75 ff 4c 23 8b 00 01 00 28 ff 37 82 2c 00 41
0080: 03 2d ed 45 85 06 83 00 06 3e 39 ff ff 01 51 ff
0090: ff b9 5d 00 0d e2 85 ff fe 01 0b 00 8e 00 04 ff
00a0: fe ff e8 02 8a ff 0f fe 78 01 98 fc b5 01 5c ff
00b0: 37 02 8d fe 5b 01 45 03 63 01 78 04 91 f0 d4 15
00c0: 8e ff fd 00 05 00 04 00 40 26 00 03 07 2d ed 45
00d0: 85 0a f9 00 00 03 16 f6 00 24 18 2d ed 05 0e 06
00e0: b5 00 af 00 73 00 75 01 01 00 b6 00 aa 00 c0 00
00f0: 70 00 73 00 ed 00 ca 00 c5 00 b9 00 b9 01 04 00
0100: fa 00 f5 00 f5 0b 7e 00 0e 13 2d ed 05 0f 0a 01
0110: 02 f1 0e 00 00 00 00 1c 00 2e 81 2b 1c 30 cb f2
0120: 00 11 12 2d ed 07 67 05 66 00 28 26 26 29 11 18
0130: 1b 18 1e 17 18 0f 16 0f 17 1d b3 54 00 24 18 2d
0140: ed 07 66 06 b5 01 31 00 8c 00 e3 00 f2 00 93 00
0150: a5 01 33 00 84 00 d2 00 f7 00 9d 00 ac 00 aa 00
0160: af 00 ff 00 f5 00 f5 00 f0 87 36 00 04 18 2d ed
0170: 07 66 06 81 04 89 24 c0 d6 ea 00 41 18 2d ed 07
0180: 66 06 83 00 02 52 a2 00 08 dd b5 00 08 10 f1 ff
0190: f6 d9 02 00 81 00 4e 00 f3 00 09 ff fa 00 00 01
01a0: 13 03 53 01 2b ff e0 ff 18 fc 34 01 96 fe 18 fd
01b0: 64 01 47 03 62 01 77 f6 ec 0b 18 16 91 ff fe 00
01c0: 06 ff fd 00 60 28 00 6e 13 2d ed 07 67 00 b3 00
01d0: 00 00 00 dd 00 00 00 00 00 00 00 00 dd dd 00 dd
01e0: 00 00 00 00 00 ee 00 00 00 00 00 00 00 00 f0 ee
01f0: 00 ef 00 00 00 00 00 da 00 00 00 00 00 00 00 00
0200: db da 00 db 00 00 00 00 00 00 00 00 00 00 00 00
0210: 00 00 00 00 00 00 00 00 00 00 00 09 00 00 00 00
0220: 00 00 00 00 00 00 00 00 00 00 00 00 00 38 00 00
0230: 00 00 00 00 00 00 12 15 00 18 00 00 00 eb 00 ff
0240: ff ff ff ff ff ff ff ff ff ff aa 00 00 00 00 bb
As far as I understand the FM deviation should be 1200 Hz (My collogue said "In MSK the difference between the higher and lower frequency is identical to half the bit rate. I.e. die frequency derivation should be ±1200 Hz (~ differce 2400 Hz)"
That makes sense. If TUBIN uses (G)MSK, the the deviation for 4800 baud is indeed 1200 Hz. It explain why the default of 5000 Hz is giving quite bad results.
I've pushed commits to set the deviation of TUBIN to 1200 Hz in the SatYAML file.
By removing the --use_agc
that was part of the grsat-wrapper.sh
script and tuning the yaml or sat.cfg options I get the impression more real time satnogs/gr-satellites obs are successful.
At the moment I am mainly modifying sat.cfg but in the future it would be better to modify the yaml files.
For now:
35933 --clk_bw 0.3
37855 --clk_bw 0.1
46276 --clk_bw 0.1
46493 --deviation 1200
47960 --deviation 2400
48900 --deviation 1200
58472 --input_gain -1
58755 --deviation 1200
58810 --deviation 1200
A short update,
We are a couple of weeks after this issue/question and my impression seems to be valid, the removal of --use_agc
in grsat-wrapper.sh
leads to the need of configuring deviation
to all the yaml files or add it in the ${HOME}/.gr_satellites/sat.cfg
that have FSK or similar as modulation.
At the moment I have already the following in the sat.cfg
35933 --clk_bw 0.3
37855 --use_agc --clk_bw 0.1
46276 --deviation 300
46493 --deviation 1200
47960 --deviation 2400
58470 --deviation 600
58472 --input_gain -1
58755 --deviation 1200
58810 --deviation 1200
The satellites using USP framing need some extra care, not always does the deviation
option has the desired outcome.
If you see that FSK modulations no longer produce frames, or far less keep this in mind, and please share the information.
Sorry for the late reply. I've classified the --deviation
's in your list into the following to try to come up with something that is actionable as a pull request.
UPMSat-2, DEKART. For these your list indicates MSK. Do we have documentation or measurements that show that these use MSK? In the case of TUBIN this information came from the team directly.
Orbicraft-Zorkiy, NANOFF-A NANOFF-B. These include multiple baudrates in the SatYAML file, so a single deviation cannot typically be valid for all of them.
EIRSAT-1. You're using --input_gain -1
, but the SatYAML file already has a negative deviation (-2400
) that is supposed to flip the high and low tones. It is assumed that the high FSK tone encodes the bit 1 and the low tone encodes the bit 0. If the transmitter uses the opposite convention, a negative gain is required. Looking at https://github.com/daniestevez/gr-satellites/discussions/307 I see that there was some discussion about this. However, --input-gain -1
doesn't really do anything with an IQ input (well, it does what it promises, which is to multiply the complex signal by -1, but that's a 180 degree phase shift that doesn't have any practical effects or implications). But if you use --input-gain -1
with a real signal, since there is a negative deviation already in the SatYAML that would be flipping the signal twice, which is probably not correct (I assume the SatYAML file is right, which must be the case if you get decodes with IQ data).
As we're not measuring this for regulatory reasons and don't have access to the satellite and doing the measurements directly with 50dB SNR, lets assume we're in the domain of good results for the demodulation (:
For the gain of the quadrature demodulator. Here using the correct deviation is more important, since the Symbol Sync block requires a signal of amplitude one and will work badly if the amplitude is somewhat different from one.
With this --dump_path method, is it possible to plot this for any given deviation value and evaluate if this is close to 1 or not ? like a go/no-go test. If this is possible, then it would be easier to find appropriate deviation values with observations. Somehow automating this would be even cooler :P
Looking at the collection of satyaml I see that the baud/deviation ratio is one of 2, 2.4 or 4, with a few exceptions of 2.1 (Russian) and 3.2 (erminaz).
Also, would it be a good idea to add a new argument to guesstimate the deviation where it is not specified ? Not entirely sure what the algorithm should be at the moment thou... In @janvgils list they are all baud/deviation=4
With an --iq
input and without the --use_agc
option you can plot the waveform.f32
file, which contains the quadrature demodulator output normalized in such a way that the deviation being used corresponds to an amplitude of 1.
baud/deviation=4 corresponds to MSK, which relatively common. However, traditionally, amateur packet radio has used a deviation of 5 kHz or 3 kHz, so or 9k6 this correponds to baud/deviation equal to 1.92 and 3.2 respectively.
In my opinion there is not much point in estimating the deviation. This should be known and declared in the SatYAML, in the same way that other parameters such as the baudrate are. The historical problem is that the deviation has rarely been given in the specifications for a satellite (e.g., SatNOGS DB doesn't have anything like this, AFAIK), and that people have most often shared recordings of FSK satellites as FM demodulated audio instead of IQ, so the whole discussion about deviation cannot be applied because the FM demodulator has unknown gain (e.g., SatNOGS Network is still recording FSK satellites to FM demodulated OGG).
Correct me if I'm wrong here, I might be barking up the wrong tree.
(assuming --iq
and no agc)
In an automated setup it becomes important to have most of the details in the respective satyaml so it works well "out of the box", as the sat.cfg will not be able to set it for several different transmitters on the same satellite. In the example of satnogs-client the info available at the observation start is frequency, norad and baud. Despite baud being present, it isn't always running with the correct transmitter specified. For example the observation can be running for the CW transmitter, but there is both CW and FSK transmitted from the satellite.
In my opinion there is not much point in estimating the deviation.
So the question becomes, is it worth having improved decode rate in an automated setup and as a consequence also in manual running without specifying the deviation ? (with the limitation of sat.cfg)
The problem in that case, what to settle on, err on the side of caution and run with too high deviation as in the default ?
What satyaml deserves this attention and which don't?
How to mark estimations ? deviation: 1200 # estimated
In an automated setup it becomes important to have most of the details in the respective satyaml so it works well "out of the box"
Agreed.
So the question becomes, is it worth having improved decode rate in an automated setup and as a consequence also in manual running without specifying the deviation ?
Ideally the deviation should be in the SatYAML for each satellite. It should come from specifications or be measured accurately in orbit. However few satellites publish their deviation in their specifications and measuring the deviation for all the rest "by hand" is a very time consuming task. There doesn't seem to be enough interest in the community for this to happen.
This being said, I'll happily merge any pull requests for gr-satellites that add deviation in SatYAML files if they come accompanied either with a link to some specifications where the deviation is mentioned, or by a measurement of the deviation (say, a plot of waveform.f32
on a clean signal, as I mentioned, or a plot of the output of the Quadrature Demod block with a gain of 1 in that block, which is another way to do it). What I won't merge is cases of "it seems I get more decodes with this deviation", because that might be misleading. The correct approach is to measure.
What satyaml deserves this attention and which don't?
That's for the community to decide. This is from the current satyaml
directory of gr-satellites.
$ grep "modulation: FSK" *.yml | wc -l
453
I wouldn't expect anyone to go systematically measuring hundreds of satellites (and a significant fraction of these have deorbited or are no longer functional). If someone wants to focus attention on a particular satellite or group of satellites, for any reason, that's more than welcome. Ideally satellite owners would pay more attention to their own satellites, but that isn't happening.
Wondering what should we do with this issue. The situation now is that @kng has systematically gone through many satellites and added deviations for those. Can this issue be closed? I don't remember if there were remaining questions or enhancements to identify (there is already #612 identified).
Good afternoon,
Yes we can close this issue.
I was unable to do real time satnogs/gr-satellites TUBIN Mobitex NX demodulation and tried to find a solution.
Looking at the https://network.satnogs.org/observations/9628118/ observation there should be enough SNR to decode one or more of the frames received, in reality it doesn't.
By using the
--deviation
option I was finally able to demodulate some frames, the strange observation is, that multiple values produce frames.On the gr-satellites documentation site I couldn't find any details on the deviation option in combination with IQ input. Is the
--deviation
option valid and properly used to produce frames?Final remark, it seem that more satellites from TU Berlin (https://www.tu.berlin/raumfahrttechnik/fachgebiet/amateurfunk) produce more frames when adding the
--deviation
option.Jan - PE0SAT
Below details about the configuration, commands and used replay options.
TUBIN.yml
sat.cfg
gr-satellites command line used (/usr/local/bin/grsat-wrapper.sh)
This observation was also creating IQ files, so we can use these to do some replay of the file and see if we can adapt the options so the obs will produce decodes in future passes. The saved IQ file was converted from SatNOGS raw to PCM wav with the help of the following script:
The iq_48000_9628118.wav IQ file can be found at https://www.pe0sat.vgnet.nl/download/TUBIN/
First we tried the default command line options to see what happens:
gr_satellites 48900 --rawint16 iq_48000_9628118.wav --samp_rate 48e3 --iq --use_agc --disable_dc_block
This is producing only the following:
Changing the command line to:
gr_satellites 48900 --rawint16 iq_48000_9628118.wav --samp_rate 48e3 --iq --use_agc
This is producing one decoded frame:
Changing the command line to:
gr_satellites 48900 --rawint16 iq_48000_9628118.wav --samp_rate 48e3 --iq --use_agc --deviation 4500
This is producing three decoded frames: