search

daniestevez / gr-satellites

GNU Radio decoder for Amateur satellites
GNU General Public License v3.0
790 stars 164 forks source link

LilacSat-2 KISS transport locks up #614

Open kng opened 4 months ago

kng commented 4 months ago

While measuring deviation on observation 9873340 I noticed that the gr_satellites app did not exit after running through the file. gr_satellites lilacsat-2 --iq --rawint16 iq_9873340_48000.raw --samp_rate 48000 seems to work fine. I did cut out a piece of a seemingly strong frame dd bs=$((4*48000)) if=iq_9873340_48000.raw of=cut.raw skip=314 count=2 and ran with a satyaml that only contains the 4k8 transmitter because I wanted to look at the waveform. gr_satellites LilacSat-2_48.yml --iq --rawint16 cut.raw --samp_rate 48000 --dump_path dump --disable_dc_block It prints one pdu and does not exit, the dump files does not get bigger and on cpu hogging going on. When I add --hexdump it prints two frames and exits cleanly. The last one contains a bunch of C0 which is KISS FEND character.

***** VERBOSE PDU DEBUG PRINT ******
((transmitter . 4k8 FSK downlink) (rs_errors . 0))
pdu length =        114 bytes
pdu vector contents =
0000: c0 a2 54 3c 00 bb a1 01 04 0b 1c 00 02 2f 5f 00
0010: 01 00 00 00 09 00 00 00 00 00 02 0a 00 0b f9 02
0020: 1f 21 7f 36 02 0a 1a 02 0a a2 19 40 08 00 00 00
0030: 00 00 00 db dc 01 34 0b 02 46 0d 08 05 d1 d2 d1
0040: 83 00 55 01 64 0f b8 0f aa 0f ac 02 1e 1b 4a 02
0050: 0c 00 0c 00 0c 00 0c 00 ff f8 8f f4 ff 13 de ff
0060: b5 ff 45 00 9d 00 e3 18 00 01 00 00 00 00 81 6f
0070: 3f de
************************************
***** VERBOSE PDU DEBUG PRINT ******
((transmitter . 4k8 FSK downlink) (rs_errors . 0))
pdu length =        114 bytes
pdu vector contents =
0000: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
0010: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
0020: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
0030: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
0040: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
0050: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
0060: c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0 c0
0070: c0 c0
************************************
daniestevez commented 4 months ago

Can you share a link to the raw IQ file (or cut.raw) so that I can replicate this locally?

kng commented 4 months ago

iq_9873340_48000_cut.zip

daniestevez commented 4 months ago

I have seen that if I modify the SatYAML to remove everything except the 4k8 transmitter, then gr_satellites doesn't terminate. To get it to terminate I need to remove the KISS transports kiss and kiss3. Maybe this is what happens in your case?

kng commented 4 months ago

I think it is the kiss_to_pdu that locks up, using hexdump disables it, right ? Same as removing the kiss/kiss3 in the yaml.

daniestevez commented 4 months ago

using hexdump disables it, right ?

I think so, but I'd have to check the code.

If the kiss_to_pdu doesn't have anything connected at its input, then I guess it makes sense that it doesn't terminate.

daniestevez commented 3 months ago

What should we do with this issue? My reading was that if the SatYAML is such that it leaves some kiss_to_pdu blocks with disconnected input, then the flowgraph will not terminate. This doesn't happen with the gr-satellites SatYAML, but it happens if some transmitters are removed and their corresponding transports are not. So I think this is expected behaviour and this can be closed. Agreed?

kng commented 3 months ago

I initially thought it was the kiss block that behaved erratically when fed with for example only the escape characters, the other details was more of selecting which blocks that was active. Probably easier to make a simpler flowgraph and isolate it even more. It becomes an issue when processing a bunch of file in a batch, because it just locks up forever. I have been thinking of adding a --silent option or similar, to disable all the frame output in the console. To use when running in a automated environment where only the kiss output or zmq is used, then this becomes less of an issue.

daniestevez commented 1 month ago

Trying to figure out what's the state of the issue and action to take. My last comment in https://github.com/daniestevez/gr-satellites/issues/614#issuecomment-2295213011 suggested that this is expected behaviour and a non-issue (a particular case of a modified SatYAML that causes the flowgraph to run forever because it leaves some blocks in the flowgraph with a disconnected PDU input). It might be that I missed something.