search

erikkaashoek / tinySA

tiny Spectrum Analyzer
227 stars 52 forks source link

BUG: No possibility to interrupt long running serial commands, e.g. scanraw #72

Closed Ho-Ro closed 4 months ago

Ho-Ro commented 1 year ago

I encountered this problem while hacking Ian's (@g4ixt) QtTinySA program: Scanning, for example, the FM radio range 87.5..108 MHz with RBW = 3 kHz takes about 80 seconds. (These are the times for tinySA Basic, the times for the Ultra may be different.) The serial command, e.g. scanraw 87500000 1080000 400 returns the data in small blocks of 20 points and cannot be stopped - only by disconnecting or switching off the tinySA. Unfortunately, the shell_stream (shell_stream = (BaseSequentialStream *)&SDU1;) only has a blocking get() or read(). So it is not possible to check for sent characters without stopping the measurement. As an experiment, I changed cmd_scanraw() in sa_cmd.c to read one character before each call to perform() (depending on the additional fourth command parameter), so that the values can be "polled" point by point unless I send e.g. '.' which breaks the loop. The original function of the command is preserved, only if the additional parameter is given, "unbuffered" output and / or "polled" output can be chosen. Both additional modes combined are most useful for very slow scans, the "unbuffered" mode gives a smooth trace update and the "polled" mode allows to stop a scan immediately. This works well with my hacked QtTinySA.

@erikkaashoek What is your opinion, should I follow this approach and extend my PR #71 for "unbuffered" output to that effect?

erikkaashoek commented 1 year ago

The current code of scanraw is supposed to abort when a new USB command is received. IF this does not happen this is a bug and should be solved,

Ho-Ro commented 1 year ago

IF this does not happen this is a bug and should be solved,

It does NOT happen (at least not on the tinySA3), it sends everything until the closing '}'. I changed the title of this issue accordingly. Thank you for taking care.

Could it also be a topic for the NanoVNAs of @DiSlord, @hugen79 and @edy555?

Ho-Ro commented 4 months ago

@erikkaashoek your recent cb33f64c51ca4685755c1763d51c786be5b59edf has fixed this issue - I close right now. Thank you for you effort!