This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/op25-dev@lists.osmocom.org/.
ikj1234i at yahoo.com ikj1234i at yahoo.com---In op25-dev at yahoogroups.com, <verymetl at ...> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/op25-dev/attachments/20140126/a4ff51ba/attachment.htm>