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
| Reply via web post | Reply to sender | Reply to group | Start a New Topic | Messages in this topic (26) |
