Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LilacSat-2 KISS transport locks up #614

Open
kng opened this issue Jul 17, 2024 · 8 comments
Open

LilacSat-2 KISS transport locks up #614

kng opened this issue Jul 17, 2024 · 8 comments

Comments

@kng
Copy link
Contributor

kng commented Jul 17, 2024

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
Copy link
Owner

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

@kng
Copy link
Contributor Author

kng commented Jul 22, 2024

iq_9873340_48000_cut.zip

@daniestevez
Copy link
Owner

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
Copy link
Contributor Author

kng commented Jul 22, 2024

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
Copy link
Owner

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
Copy link
Owner

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
Copy link
Contributor Author

kng commented Aug 18, 2024

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
Copy link
Owner

Trying to figure out what's the state of the issue and action to take. My last comment in #614 (comment) 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants