Fix overflow / underflow stats

[zsoerenm]

Overflow and underflow stats are not included within flags, but are thrown in SoapySDR.jl: https://github.com/JuliaTelecom/SoapySDR.jl/blob/0f2ea919a99c5acd0278de1042a00aecf8d6cdd1/src/highlevel.jl#L814

[sjkelly]

I am not sure Throwing is the correct behavior here. In general it is problematic since Timeout overflow are sometimes expected behaviors and not "exceptional". Maybe we are not propagating the out_flags from https://github.com/JuliaTelecom/SoapySDR.jl/blob/0bc8cd7b743bd6a1468769a42332663b1924c918/src/highlevel.jl#L907 correctly?

[zsoerenm]

No, all flags are defined here: https://github.com/pothosware/SoapySDR/blob/795661c9f31577160885502ea6edda3c535eea61/include/SoapySDR/Constants.h and all errors are defined here: https://github.com/pothosware/SoapySDR/blob/795661c9f31577160885502ea6edda3c535eea61/include/SoapySDR/Errors.h The error is encoded in the number of samples nread (Error is a "negative number of samples"). Flags are given in out_flags. I wouldn't call an overflow an expected behavior. In the context of GPS this means you loose track of all satellites.

[zsoerenm]

@sjkelly Could this be merged? I happen to copy this code quite often into my current workspace to have more debugging information.

[sjkelly]

I'd say so. Unfortunately I don't think there is one correct way to do the under/over flow and timeout handling. This approach ostensibly make things slower, therefore inducing more overflows. A bit like Heisenberg's uncertainty principle unfortunately.

[sjkelly]

We can also put this behavior behind flags, as I tried in SoapySDR.

[zsoerenm]

Is that because of the thrown and catched error? Printing Os and Us is quite usual though. GnuRadio also does it.