Yeah, the way that offset errors are handled is in need of a revisit, I'll be making
those decisions after reviewing the RTL (they must be on a slow boat from the East).
Basically the "-c" (calibration) was the old way that scope.py took care of
offsets, and when the new trunking support was grafted on that was supposed to be replaced
by a per-system offset in the TSV file. Ideally it would work the same way as other osmo
apps - specify the offset in a single parameter. BTW it won't work if you specify the
offset twice, once on the command line and then again in the 'offset' parameter of
the TSV file; one or the other is enough. One reason I'm skeptical of the command
line offset is it seems to be a non-linear function of frequency...
It's possible with your "frequency correction" patch to scope.py that's
taken care of all issues, and you can just set "-c" to zero and
"offset" in the TSV files likewise to zero...... Not sure until I've had a
chance to play with the hardware...
Nonetheless your reports are very encouraging! It's possible also that you're on
an encrypted channel. You can adjust the value of the "-v" parameter upwards
(try -v 15) - that will print out a running log of frame activity to the console - should
be able quickly to separate whether you're seeing voice or packet data or what...
Max