New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Random Tuning Error #6
Comments
@thetoivonen What RTL-SDR are you using? |
It's the Nooelec NESDR SMArt SDR. Supposed to have 0.5ppm stability. It makes sense that it could be thermal drift, but I don't understand why simply restarting the command, with no pause for it to cool off and without changing the -q correction would fix it. Any ideas on how to trace this problem down? |
Mmm that's even weirder because the NESDR SMArt have TCXO so they shouldn't thermal drift.. I'm not sure but its the same with the cheaper ones.. You restart the prog and off it goes again.. If you use -v 5 which will do verbose logging or maybe use -l http:0.0.0.0:80 which will allow you to browse to http://ipaddresss:80 which will show the frequency error.. That's all I can think of right now.. |
Is there way to record frequency log that active and recording active voice ?? |
1 similar comment
Is there way to record frequency log that active and recording active voice ?? |
What hardware are you running on? I've see RPi3 have issues when the power supply hasn't been able to keep up with demand. I've also experienced RTL dongles going bad and intermittently failing due to heat. Either way, I don't think this is an op25 bug or more people would be experiencing it. |
It is indeed on a Raspberry Pi. I'll give it a try on something else and see if I can reproduce it, but you are probably right. FYI here is a workaround that has been working for several days now:
It runs 'rx.py' in an infinite loop that times out and restarts every 5 minutes. Kludgy, but might be useful to people who have stability issues with their SDR. |
I've been seeing this issue on a pi. Tried a different power supply to no avail, but haven't had a chance to try a different RTL. I also don't think it's an op25 bug but not sure how to squash it. Since OP25 knows when there is a tuning error because it logs it, could we have a command line option to quit upon a tuning error, maybe after so many of them, and then the service could restart it? |
@thetoivonen looking at your work around, wouldn't it cut my feed every 5 minutes for the few seconds as op25 starts again? |
Yes. You can change the amount of time between resets to something longer, but it definitely is not an elegant solution.
null
|
I too am observing this issue. I find it hard to believe it's a hardware issue since restarting the op25-rx applications causes it to recover. I've also noticed that when it's "stuck" the WEB interface reports frequency error of +1200hz. If this was a hardware drift issue, why would restarting the app fix it? Any ideas |
Once op25's demodulator locks the signal at +/-1200hz or 2400hz it will
stay there forever because the costas loop is locked 90 or 180 degrees out
of phase. Restarting (or manually adjusting fine tune) resets the internal
demod phase tracker and allows it to seek the correct phase lock again.
The solution to this problem is to correctly adjust ppm and fine tune so
that it is never far enough off frequency that it inadvertently gets locked
at the wrong point.
Graham
…On Wed, Aug 14, 2019, 8:51 AM mkmer ***@***.***> wrote:
I too am observing this issue. I find it hard to believe it's a hardware
issue since restarting the op25-rx applications causes it to recover. I've
also noticed that when it's "stuck" the WEB interface reports frequency
error of +1200hz. If this was a hardware drift issue, why would restarting
the app fix it? Any ideas
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#6?email_source=notifications&email_token=AHS3SNS74OUVAS76MOUUXILQEP5VNA5CNFSM4GS5DS5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4IWCPQ#issuecomment-521232702>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHS3SNU7FRLBJBUSRZI5EADQEP5VNANCNFSM4GS5DS5A>
.
|
Strange... I'm running with 2-5hz freq error and mixer balance of 0 to 1...
don't think I can get much closer. It takes several hours of run time - is
it possible there is a time related bug with the costas?
…On Wed, Aug 14, 2019 at 10:22 AM boatbod ***@***.***> wrote:
Once op25's demodulator locks the signal at +/-1200hz or 2400hz it will
stay there forever because the costas loop is locked 90 or 180 degrees out
of phase. Restarting (or manually adjusting fine tune) resets the internal
demod phase tracker and allows it to seek the correct phase lock again.
The solution to this problem is to correctly adjust ppm and fine tune so
that it is never far enough off frequency that it inadvertently gets locked
at the wrong point.
Graham
On Wed, Aug 14, 2019, 8:51 AM mkmer ***@***.***> wrote:
> I too am observing this issue. I find it hard to believe it's a hardware
> issue since restarting the op25-rx applications causes it to recover.
I've
> also noticed that when it's "stuck" the WEB interface reports frequency
> error of +1200hz. If this was a hardware drift issue, why would
restarting
> the app fix it? Any ideas
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
> <
#6?email_source=notifications&email_token=AHS3SNS74OUVAS76MOUUXILQEP5VNA5CNFSM4GS5DS5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4IWCPQ#issuecomment-521232702
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AHS3SNU7FRLBJBUSRZI5EADQEP5VNANCNFSM4GS5DS5A
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#6?email_source=notifications&email_token=AB3GVBGC4KFFL5CGVMHCQ7DQEQIK3A5CNFSM4GS5DS5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4I6OWY#issuecomment-521267035>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB3GVBBSC3FXS7VMYVJEZ5LQEQIK3ANCNFSM4GS5DS5A>
.
|
I've never seen this with my 3 feeds or my desktop listening station,
all of which run for weeks/months without problem.
The only time I've reliably seen the issue you describe is where the
initial PPM is incorrect and has been compensated with excessive
fine-tune. Freq of control channel may appear to be exactly tuned (and
TSBKs are being decoded) but after tuning to a more distant (several mhz
away) voice channel things can go out of whack on the return to the
control channel.
Graham
…On 8/14/19 3:21 PM, mkmer wrote:
Strange... I'm running with 2-5hz freq error and mixer balance of 0 to
1...
don't think I can get much closer. It takes several hours of run time - is
it possible there is a time related bug with the costas?
On Wed, Aug 14, 2019 at 10:22 AM boatbod ***@***.***> wrote:
> Once op25's demodulator locks the signal at +/-1200hz or 2400hz it will
> stay there forever because the costas loop is locked 90 or 180
degrees out
> of phase. Restarting (or manually adjusting fine tune) resets the
internal
> demod phase tracker and allows it to seek the correct phase lock again.
>
> The solution to this problem is to correctly adjust ppm and fine tune so
> that it is never far enough off frequency that it inadvertently gets
locked
> at the wrong point.
>
> Graham
>
> On Wed, Aug 14, 2019, 8:51 AM mkmer ***@***.***> wrote:
>
> > I too am observing this issue. I find it hard to believe it's a
hardware
> > issue since restarting the op25-rx applications causes it to recover.
> I've
> > also noticed that when it's "stuck" the WEB interface reports
frequency
> > error of +1200hz. If this was a hardware drift issue, why would
> restarting
> > the app fix it? Any ideas
> >
> > —
> > You are receiving this because you modified the open/close state.
> > Reply to this email directly, view it on GitHub
> > <
>
#6?email_source=notifications&email_token=AHS3SNS74OUVAS76MOUUXILQEP5VNA5CNFSM4GS5DS5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4IWCPQ#issuecomment-521232702
> >,
> > or mute the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/AHS3SNU7FRLBJBUSRZI5EADQEP5VNANCNFSM4GS5DS5A
> >
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
>
<#6?email_source=notifications&email_token=AB3GVBGC4KFFL5CGVMHCQ7DQEQIK3A5CNFSM4GS5DS5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4I6OWY#issuecomment-521267035>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AB3GVBBSC3FXS7VMYVJEZ5LQEQIK3ANCNFSM4GS5DS5A>
> .
>
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#6?email_source=notifications&email_token=AHS3SNXDEUAX6CFCLWKQGRDQERLMNA5CNFSM4GS5DS5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4J2WMA#issuecomment-521382704>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHS3SNVBQ37MR27PG3JHE73QERLMNANCNFSM4GS5DS5A>.
|
Graham,
Thanks for the feedback - interestingly enough, I don't have any fine
tuning adjustments - completed the alignment with only a little PPM
adjustment. (-q 1). Could a possibility be that the voice channel is too
far off (aka non linear PPM error on the RTL device?) throwing the
alignment off? I also noticed some one complaining about a "USB
disconnect" causing similar problems. Maybe my USB stick is resetting... I
do have a 2.5A power supply connected, but who knows?
Thanks again for the feedback
-Mike
…On Wed, Aug 14, 2019 at 4:57 PM boatbod ***@***.***> wrote:
I've never seen this with my 3 feeds or my desktop listening station,
all of which run for weeks/months without problem.
The only time I've reliably seen the issue you describe is where the
initial PPM is incorrect and has been compensated with excessive
fine-tune. Freq of control channel may appear to be exactly tuned (and
TSBKs are being decoded) but after tuning to a more distant (several mhz
away) voice channel things can go out of whack on the return to the
control channel.
Graham
On 8/14/19 3:21 PM, mkmer wrote:
> Strange... I'm running with 2-5hz freq error and mixer balance of 0 to
> 1...
> don't think I can get much closer. It takes several hours of run time -
is
> it possible there is a time related bug with the costas?
>
>
> On Wed, Aug 14, 2019 at 10:22 AM boatbod ***@***.***>
wrote:
>
> > Once op25's demodulator locks the signal at +/-1200hz or 2400hz it will
> > stay there forever because the costas loop is locked 90 or 180
> degrees out
> > of phase. Restarting (or manually adjusting fine tune) resets the
> internal
> > demod phase tracker and allows it to seek the correct phase lock again.
> >
> > The solution to this problem is to correctly adjust ppm and fine tune
so
> > that it is never far enough off frequency that it inadvertently gets
> locked
> > at the wrong point.
> >
> > Graham
> >
> > On Wed, Aug 14, 2019, 8:51 AM mkmer ***@***.***> wrote:
> >
> > > I too am observing this issue. I find it hard to believe it's a
> hardware
> > > issue since restarting the op25-rx applications causes it to recover.
> > I've
> > > also noticed that when it's "stuck" the WEB interface reports
> frequency
> > > error of +1200hz. If this was a hardware drift issue, why would
> > restarting
> > > the app fix it? Any ideas
> > >
> > > —
> > > You are receiving this because you modified the open/close state.
> > > Reply to this email directly, view it on GitHub
> > > <
> >
>
#6?email_source=notifications&email_token=AHS3SNS74OUVAS76MOUUXILQEP5VNA5CNFSM4GS5DS5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4IWCPQ#issuecomment-521232702
> > >,
> > > or mute the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/AHS3SNU7FRLBJBUSRZI5EADQEP5VNANCNFSM4GS5DS5A
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> >
> <
#6?email_source=notifications&email_token=AB3GVBGC4KFFL5CGVMHCQ7DQEQIK3A5CNFSM4GS5DS5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4I6OWY#issuecomment-521267035
>,
> > or mute the thread
> >
> <
https://github.com/notifications/unsubscribe-auth/AB3GVBBSC3FXS7VMYVJEZ5LQEQIK3ANCNFSM4GS5DS5A
>
> > .
> >
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub
> <
#6?email_source=notifications&email_token=AHS3SNXDEUAX6CFCLWKQGRDQERLMNA5CNFSM4GS5DS5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4J2WMA#issuecomment-521382704
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AHS3SNVBQ37MR27PG3JHE73QERLMNANCNFSM4GS5DS5A
>.
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#6?email_source=notifications&email_token=AB3GVBCXG45DW7224QHEV43QERWTNA5CNFSM4GS5DS5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4KCYBQ#issuecomment-521415686>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB3GVBFQQIGMZWMGSGSY6MLQERWTNANCNFSM4GS5DS5A>
.
|
The issue occurs for me with a single voice frequency tuned, no trunking.
|
Little more detail on this: I'm getting the error when it tunes out to a voice channel - it never makes it to the voice channel it tries to tune to and start throwing the p25_framer::rx_sym() tuning error -1200 error. Then it finally voice channel time out and tries to go back to the control channel but continues to be stuck. Shouldn't the costas reset every time we change channels? Maybe I'm confused by the implementation of the tracking system. As boatbod stated, adjusting the fine tuning via web page did result in a recovery. |
OK... had some more time to try to debug this issue. I'm using one of the RTL-SDR usb sticks. I think part of the issue is that the system I'm listening to is a split 700/800Mhz system - thus always moving 30Mhz from control to voice. As described above, when the system is locked up I can adjust fine tuning +/- 1 click (net 0 offset) and get the system to start receiving again. I made a small modification to rx.py - set_freq(self, target_freq): Since the change, I have not seen a lockup, nor have I notice any adverse affects - but still testing. |
I started seeing this out of the blue with 2 of my SDRs as well. They no longer work w/ previously functional configurations. My third works just fine with all configurations... which leads to me to think something changed on the two other SDRs. Not sure if they cooked, or what. I can get them to work by tweaking the fine-tune by 1000-1200, but that's hardly ideal when the original issue isn't clear. Mine are also the Nooelec NESDR SMArt SDR. |
As soon as start rx.py and it initializes, I get this error continuously - with or without the self.demod.reset(). xxxxxxxxxxxx:~/Projects/SDR/op25/op25/gr-op25_repeater/apps$ ./rx.py --args 'rtl' -N 'LNA:47' -S 2500000 -f 858.7375e6 -o 17e3 -q 0 -T trunk.tsv -V -2 -U -w -l http:127.0.0.1:8080 gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.13.4 |
- P25 trunking (port of existing rx.py trunking capabilities) - Motorola ASTRO25 (Smartnet/Smartzone) analog and p25cai digital trunking - New 'tuner' gnuplot type (plot #6) - Support for built-in audio player - Support for interactive terminal types (curses and http) - Support for narrowband fm analog demodulator (can be used stand-alone) - Support for metadata updates for icecast streaming - Numerous minor bugfixes and tweaks
I'm getting the same error as @AndrewBarfield I run the command
And the stderr log shows this:
and repeats |
First observation is your control channel has very poor signal quality -
the constellation plot is widely smeared and not tightly defined in the
four corners of a box. That said, sufficient symbols are being decoded
for the framer to detect the frame check sequence, but like the error in
the log says, your tuning is off by 2400hz.
Switch to plot #5 and adjust ppm correction until the signal hump is
centered, then switch to plot #6 and tweak the fine tune for minimal bar
graph size.
Graham
…On Fri, Jul 31, 2020, 9:09 PM scott.center ***@***.***> wrote:
I'm getting the same error as @AndrewBarfield
<https://github.com/AndrewBarfield>
I'm running Raspbian Desktop in VMware (tl;dr I want to develop a
graphical interface for op25) with a Nooelec RTL2832U R820T RTL-SDR Tuner.
I run the command ./rx.py --args 'rtl' -N 'LNA:39' --nocrypt -V -q 76 -d
0 -v 5 -S 1000000 -U -T trunk.tsv 2>stderr.2 and the trunk file looks like
Sysname Control Channel List Offset NAC Modulation TGID Tags File Whitelist Blacklist Center Frequency
P25 SYSTEM 460.4375,460.6125,460.0875 0 0 cqpsk
My screen looks like this
[image: Raspbian-2020-07-31-19-54-40]
<https://user-images.githubusercontent.com/14814308/89090384-348df700-d368-11ea-8d60-38584f482bc0.png>
And the stderr log shows this:
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
Using device #0 Realtek RTL2838UHIDIR SN: 00000000
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
gain: name: LNA range: start 0 stop 0 step 0
setting gain LNA to 39
supported sample rates 250000-2560000 step 24000
Exact sample rate is: 274000.001470 Hz
[R82XX] PLL not locked!
Unable to use two-stage decimator for speed=274000
Project 25 IMBE Encoder/Decoder Fixed-Point implementation
Developed by Pavel Yazev E-mail: ***@***.***
Version 1.0 (c) Copyright 2009
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see the file "LICENSE" for details.
op25_audio::open_socket(): enabled udp host(127.0.0.1), wireshark(23456), audio(23456)
p25_frame_assembler_impl: do_imbe[1], do_output[0], do_audio_output[1], do_phase2_tdma[0], do_nocrypt[1]
07/31/20 19:54:17.354168 set control channel=460.612500
metadata update not enabled
using ALSA sound system
audio device: default
Listening on 127.0.0.1:23456
Allocating 15 zero-copy buffers
07/31/20 19:54:18.435480 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.436305 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.440269 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.440291 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.440303 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.441260 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.441277 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.441288 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.441299 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.441311 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.441322 [0] p25_framer::rx_sym() tuning error +/- 2400
07/31/20 19:54:18.441559 [0] p25_framer::rx_sym() tuning error +/- 2400
and repeats p25_framer::rx_sym() tuning error +/- 2400 indefinitely
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#6 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHS3SNQYDWWN4BEGXLPU23LR6NTNFANCNFSM4GS5DS5A>
.
|
Not sure if it matters I have the Official RTL-SDR.com v3 from there official channel on Aliexpress and i get it too . I even run sdr-trunk to fine tune in my frequency to see if that made a difference getting it eyeballed as dead centered as possible. but seems to make no difference. I run a fan on mine because it runs hot. I originally thought thats why it did it. but its barely luke warm with a fan on it non-stop. I can get it to run for many hours. it seems to randomly freezeup. Sometimes 10 hours no issues sometimes all it takes is a few hours. Note I get alot of these errors before it freezes. I am runing the latest build as of today. ordered a cheaper SDR that also has a TCXO (hopefully) as a second.
|
If the app is completely going to sleep it's quite likely your RTL
dongle is either having connection stability issues. Does "dmesg" show
the device disconnecting/reconnecting?
Graham
…On 2/19/21 11:32 PM, frankmasio wrote:
Not sure if it matters I have the Official RTL-SDR.com v3 from there
official channel on Aliexpress and i get it too . I even run sdr-trunk
to fine tune in my frequency to see if that made a difference getting
it eyeballed as dead centered as possible. but seems to make no
difference. I run a fan on mine because it runs hot. I originally
thought thats why it did it. but its barely luke warm with a fan on it
non-stop. I can get it to run for many hours. it seems to randomly
freezeup. Sometimes 10 hours no issues sometimes all it takes is a few
hours.
Note I get alot of these errors before it freezes.
ordered a cheaper SDR that also has a TCXO (hopefully) as a second.
|op25/gr-op25_repeater/apps$ ./rx.py --args 'rtl' -N 'LNA:49' -s
2000000 -o 25000 -U -T trunk2.tsv -w -2 -l http:0.0.0.0:8080 Using
Python /usr/bin/python2 linux; GNU C++ version 7.3.0; Boost_106501;
UHD_003.010.003.000-0-unknown gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf
bladerf rfspace airspy airspyhf soapy redpitaya freesrp Using device
#0 Realtek RTL2838UHIDIR SN: 00000001 Found Rafael Micro R820T tuner
[R82XX] PLL not locked! gain: name: LNA range: start 0 stop 0 step 0
setting gain LNA to 49 supported sample rates 250000-2560000 step
24000 [R82XX] PLL not locked! Using two-stage decimator for
speed=960000, decim=10/4 if1=96000 if2=24000
op25_audio::open_socket(): enabled udp host(127.0.0.1),
wireshark(23456), audio(23456) p25_frame_assembler_impl: do_imbe[1],
do_output[0], do_audio_output[1], do_phase2_tdma[1], do_nocrypt[1]
02/19/21 19:44:16.770297 Reading blacklist file metadata update not
enabled using ALSA sound system audio device: default Listening on
127.0.0.1:23456 python version detected: 2.7.17 (default, Sep 30 2020,
13:38:04) [GCC 7.5.0] ^Cmain: exception occurred main: exception:
Traceback (most recent call last): File "./rx.py", line 991, in run
time.sleep(1) KeyboardInterrupt |
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#6 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHS3SNRKNNH7XQDI56A7V23S743PNANCNFSM4GS5DS5A>.
|
When running rx.py the system will work for some time (typically hours) and then suddenly begin throwing the error: "p25_framer::rx_sym() tuning error +1200" repeatedly. This happens with no change to the tuning, antenna, or rx temperature. Stopping rx.py and restarting instantly fixes the issue, but the software will not recover without stopping and restarting. When working properly the constellation plot shows 4 tight groups where they belong. When malfunctioning, the constellation plot will show either a ring or ellipse.
The text was updated successfully, but these errors were encountered: