LilacSat-2 KISS transport locks up

[kng]

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]

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

[kng]

iq_9873340_48000_cut.zip

[daniestevez]

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]

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]

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]

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]

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.