---In op25-dev(a)yahoogroups.com, <verymetl@...> wrote:
Running the app with an offset cc frequency
doesn't seem to apply to the voice channels.
Same as if I specify an offset to the tsv file for this system. If I don't use offset
tuning,
it isn't tracking very well. So there is some tweaking I need to figure out for
proper
trunking functionality.
-Scott
My RTL sticks finally arrived from the East. Here are a few random comments... First
the "Offset" that appears in the per-system trunking config file is in Hz, not
in PPM. This is something that would be nice to get rid of entirely, and fold the
functionality into the global PPM which only changes when the USB stick is changed to a
different one. However there are still issues. The QPSK PLL in OP25 doesn't have a
separate frequency-correction loop (yet), it only has a phase detection capability right
now, which means that the tuning has to be closer than 1,200 Hz to the nominal carrier
frequency. One PPM error at 850 Mhz would be 850 Hz of error, which means that for best
results we'd need to use a fractional PPM. Accordingly the "Offset" Hz
value provides a much finer method of tuning than the PPM. All this would be a non-issue
if GPSDO clocks were used, then there would be neither PPM error nor offset error...
A separate issue with the RTL sticks is there is a very long latency for the device to
change frequencies, approx. 1.6 seconds after the frequency-change is commanded by the
trunking receiver controller logic. This means that if we're switching from the trunk
CC to a voice channel there's an excellent chance by the time we finally arrive on the
voice channel that the transmission has already ended, followed by another 1.6 sec. delay
before the control channel can be re-acquired. The cause of this extreme delay is not
clear at this time.
This delay does NOT occur when using the USRP; trunking following is very fast. Also the
problem doesn't bite when Hamlib-tuned receiver is used. This is interesting re: the
RTL USB stick because there is a hack to add support for the direct sampling mode (you
have to do some soldering). So, the Hamlib controlled receiver is tapped at the final IF
(455 K.C. or 10.7 M.C) and that would be fed directly to pin 1 or 2 of the RTL2832 using
suitable matching circuitry (the hamitup converter is another option, but not as cool as
this direct-input hack)...
OTOH, the HackRF unit DOES seem to suffer from this or a similar timing problem...
Max