Re: [App_rpt-users] RTCM voter problem - SOLVED
Well, after many of you offered your time and thoughts on my voter problem, Jim WB6NIL graciously donated a couple of hours of his time to remotely help me and he uncovered the problem. All 5 of my RTCMs were purchased within the last 6 months, and I suspect all 5 have the same problem (will verify that today) The problem is that the microprocessor crystal is running too fast! There is 9.6Mhz crystal that drives the MPU, on the particular unit that Jim helped me diagnose, it's running 2.5 khz too fast. There is a sanity check in the firmware that makes sure the correct number of samples were taken in the last second (it's supposed to be 8000) and fails if the sample is incorrectly sized (mine is taking 8003 samples). Jim helped adjust the code to be more tolerant of the sampling error and my whole system instantly worked. I have since tested it with ALL my GPSs (they all work great!) So I now have everything working, including the voting. I haven't contact Micro-Node about it yet. Jim told me that voting should work fine but this clock error would probably not be acceptable for Simulcast (something we have no plans on doing as of now). Since mine are deployed at mountain top sites, I'll probably pursue a crystal that is running at the correct frequency and use "standard" firmware so that if the decision is ever made to play with simulcast, I won't be right back in this same boat. Thanks to all that helped out, and a HUGE thanks to Jim for taking the time to troubleshoot this. BTW- This clock error will NOT effect the RTCM in mix client mode, it only affects it in voting or simulcast mode! Thanks all, have a good weekend. 73 James KI0KN On Tue, Apr 5, 2016 at 12:56 PM, James Cizek <james.m.cizek@gmail.com> wrote:
Hi all,
I posted this problem many months ago and I came to the conclusion at that time that it was my 1PPS signal from the GPS into the RTCM that was the problem. I have changed hardware now to fix that and I still have the problem so I am suspecting a config issue and hope someone will have an idea. This is on a stock DIAL box.
RTCM is setup and working great as a standard node. Everything is working great on the repeater as long as RTCM is in non-voter mode.
I have the chan_voter module loading in modules.conf.
Here is my voter.conf:
[general] port = 667 buflen = 200 password = blah
[1115] Horsetooth = blah,transmit plfilter = y txtoctype = none
I am happy to share any other config if requested.
In the RTCM menus, I have a static IP, I have the voter server IP, all the approriate IP fields filled out. As mentioned, the RTCM works fine with the asterisk server when it's in non-voter mode.
Here's the way I am testing: Verify RTCM menu item 10 is set to (2) None.
Boot server, then boot RTCM. RTCM console says:
GPS Receiver Active, waiting for aquisition GPS signal acquired, number of satellites in view = 9 04/05/2016 17:58:17.560 Time now syncronized to GPS 04/05/2016 18:13:18.580 Host Connection established (Pri) (10.16.1.240)
I have a very nice, clean, 5Volt 1PPS signal going to pin 7 on the DB15. Verfied with o-scope.
as soon as I change menu item 10 on the RTCM to either a (1) or a (0) instead of (2), I *instantly* get this on the RTCM console:
04/05/2016 18:44:13.660 Lost GPS Time synchronization 04/05/2016 18:44:13.660 Host Connection Lost (Pri) (10.16.1.240)
and it sits there forever and never re-establishes connection to the host.
Here is a snippet of the GPS output:
$PFEC,GPtps,160405181603,1,0,1,150701000000,00,17,160405165607,1891,238580 $GPGGA,181603,4020.9810,N,10506.4515,W,0,07,00.00,001566.7,M,-020.0,M,, $GPGSV,2,1,08,03,53,215,46,07,09,253,37,09,28,305,39,16,63,126,43 $GPGSV,2,2,08,22,26,178,44,23,60,316,43,26,52,066,41,31,17,061,34 $GPRMC,181603,V,4020.9810,N,10506.4515,W,,,050416,008.9,E,N*1A $PFEC,GPtps,160405181603,3,0,1,150701000000,00,17,160405165607,1891,238580 $GPGGA,181604,4020.9810,N,10506.4515,W,0,03,00.00,001566.7,M,-020.0,M,, $GPRMC,181604,V,4020.9810,N,10506.4515,W,,,050416,008.9,E,N*1D $PFEC,GPtps,160405181604,3,0,1,150701000000,00,17,160405165607,1891,238581 $GPGGA,181605,4020.9812,N,10506.4495,W,1,07,01.73,001573.3,M,-020.0,M,, $GPRMC,181605,A,4020.9812,N,10506.4495,W,,,050416,008.9,E,A*0F $PFEC,GPtps,160405181605,3,0,1,150701000000,00,17,160405165607,1891,238582 $GPGGA,181606,4020.9812,N,10506.4494,W,1,07,01.73,001573.2,M,-020.0,M,, $GPRMC,181606,A,4020.9812,N,10506.4494,W,000.0,283.2,050416,008.9,E,A*06
I am just not sure where to go from here. I can't seem to find anyone that's had any problem like this or what might be causing it.
I have tried 5 different RTCMs and 5 different GPSs from 3 different manufacturers.
Any suggestions on what I might be missing?
Many thanks for any help anyone can offer!
James KI0KN
On Sat, 9 Apr 2016, James Cizek wrote:
Jim helped adjust the code to be more tolerant of the sampling error and my whole system instantly worked.
Could you please share the code adjustment for future reference. ================================================================ Dr. Willem A. Schreuder, President, Principia Mathematica Address: 445 Union Blvd, Suite 230, Lakewood, CO 80228, USA Tel: (303) 716-3573 Fax: (303) 716-3575 WWW: www.prinmath.com Email: Willem.Schreuder@prinmath.com
Sure Willem, in voter.c, the stock line is: if ((samplecnt >= 7999) && (samplecnt <= 8001)) it needs to be changed to something like: if ((samplecnt >= 7999) && (samplecnt <= 8003 )) That was just enough to make my first RTCM work. I've had a chance now to check a few more of my RTCMs on the bench this morning and the crystal frequencies are kind of all over. The next one I had on the bench was 5.2Khz fast. The above code was still not enough to fix it (as would be expected) so it looks like the quality control on whatever manufacturer that crystal is, isn't very good (or a low tolerance crystal is being used). I am going to pursue crystal replacement to get a highly accurate, stable, on-frequency crystal in there as my first choice. Changing the firmware 5 different times doesn't seem like the right answer. Jim put that sanity check in there for a reason. Working around it *may* allow the device to work, but to me, it seems getting the hardware operating the way it was supposed to originally is the better answer. I will follow up with Micro-node and let you all know how it goes. Thanks. James KI0KN On Sat, Apr 9, 2016 at 9:05 AM, Willem Schreuder <willem@prinmath.com> wrote:
On Sat, 9 Apr 2016, James Cizek wrote:
Jim helped adjust the code to be more tolerant of the sampling error and
my whole system instantly worked.
Could you please share the code adjustment for future reference.
================================================================ Dr. Willem A. Schreuder, President, Principia Mathematica Address: 445 Union Blvd, Suite 230, Lakewood, CO 80228, USA Tel: (303) 716-3573 Fax: (303) 716-3575 WWW: www.prinmath.com Email: Willem.Schreuder@prinmath.com
According to the original documentation for the first generation X1 is a SER3418-ND 9.60MHz 18pf 30ppm. So 9.6 x (+/-) 30 = +/- 288 Hz. My question is If the same processor is doing the A/D conversion AND checking the number of samples/second why would there be a discrepancy regardless of the timing offset? Or is the error at the receiving end?? On 4/9/2016 2:16 PM, James Cizek wrote:
Sure Willem, in voter.c, the stock line is:
if ((samplecnt >= 7999) && (samplecnt <= 8001))
it needs to be changed to something like:
if ((samplecnt >= 7999) && (samplecnt <= 8003 ))
That was just enough to make my first RTCM work. I've had a chance now to check a few more of my RTCMs on the bench this morning and the crystal frequencies are kind of all over. The next one I had on the bench was 5.2Khz fast. The above code was still not enough to fix it (as would be expected) so it looks like the quality control on whatever manufacturer that crystal is, isn't very good (or a low tolerance crystal is being used). I am going to pursue crystal replacement to get a highly accurate, stable, on-frequency crystal in there as my first choice. Changing the firmware 5 different times doesn't seem like the right answer.
Jim put that sanity check in there for a reason. Working around it *may* allow the device to work, but to me, it seems getting the hardware operating the way it was supposed to originally is the better answer. I will follow up with Micro-node and let you all know how it goes.
Thanks.
James KI0KN
On Sat, Apr 9, 2016 at 9:05 AM, Willem Schreuder <willem@prinmath.com <mailto:willem@prinmath.com>> wrote:
On Sat, 9 Apr 2016, James Cizek wrote:
Jim helped adjust the code to be more tolerant of the sampling error and my whole system instantly worked.
Could you please share the code adjustment for future reference.
================================================================ Dr. Willem A. Schreuder, President, Principia Mathematica Address: 445 Union Blvd, Suite 230, Lakewood, CO 80228, USA Tel: (303) 716-3573 <tel:%28303%29%20716-3573> Fax: (303) 716-3575 <tel:%28303%29%20716-3575> WWW: www.prinmath.com <http://www.prinmath.com> Email: Willem.Schreuder@prinmath.com <mailto:Willem.Schreuder@prinmath.com>
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
-- Joe Leikhim Leikhim and Associates Communications Consultants Oviedo, Florida JLeikhim@Leikhim.com 407-982-0446 WWW.LEIKHIM.COM
The timing of one second comes from the GPS satellites and is accurate. Chuck On Sat, Apr 9, 2016 at 7:03 PM, Joe Leikhim <rhyolite@leikhim.com> wrote:
According to the original documentation for the first generation X1 is a SER3418-ND 9.60MHz 18pf 30ppm.
So 9.6 x (+/-) 30 = +/- 288 Hz.
My question is If the same processor is doing the A/D conversion AND checking the number of samples/second why would there be a discrepancy regardless of the timing offset? Or is the error at the receiving end??
On 4/9/2016 2:16 PM, James Cizek wrote:
Sure Willem, in voter.c, the stock line is:
if ((samplecnt >= 7999) && (samplecnt <= 8001))
it needs to be changed to something like:
if ((samplecnt >= 7999) && (samplecnt <= 8003 ))
That was just enough to make my first RTCM work. I've had a chance now to check a few more of my RTCMs on the bench this morning and the crystal frequencies are kind of all over. The next one I had on the bench was 5.2Khz fast. The above code was still not enough to fix it (as would be expected) so it looks like the quality control on whatever manufacturer that crystal is, isn't very good (or a low tolerance crystal is being used). I am going to pursue crystal replacement to get a highly accurate, stable, on-frequency crystal in there as my first choice. Changing the firmware 5 different times doesn't seem like the right answer.
Jim put that sanity check in there for a reason. Working around it *may* allow the device to work, but to me, it seems getting the hardware operating the way it was supposed to originally is the better answer. I will follow up with Micro-node and let you all know how it goes.
Thanks.
James KI0KN
On Sat, Apr 9, 2016 at 9:05 AM, Willem Schreuder <willem@prinmath.com> wrote:
On Sat, 9 Apr 2016, James Cizek wrote:
Jim helped adjust the code to be more tolerant of the sampling error and
my whole system instantly worked.
Could you please share the code adjustment for future reference.
================================================================ Dr. Willem A. Schreuder, President, Principia Mathematica Address: 445 Union Blvd, Suite 230, Lakewood, CO 80228, USA Tel: (303) 716-3573 Fax: (303) 716-3575 WWW: www.prinmath.com Email: <Willem.Schreuder@prinmath.com> Willem.Schreuder@prinmath.com
_______________________________________________ App_rpt-users mailing listApp_rpt-users@ohnosec.orghttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
-- Joe Leikhim
Leikhim and Associates
Communications Consultants
Oviedo, Florida JLeikhim@Leikhim.com 407-982-0446 WWW.LEIKHIM.COM
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
oh, wow! I just went into my source and see that apparently long ago I had made a similar change to my RTCM code that I had forgot about, but there it is. I must have run into this issue previously. hmmm. By the way, I also added smart ID code to the RTCM for when it is offline so I don't have to hear it ID every 10 minutes or on top of people when it is offline. I see I didn't make it run time adjustable so maybe I should do that and then share it. Chuck WB9UUS On Sun, Apr 10, 2016 at 4:36 AM, Chuck Henderson < rpt2@chuck.midlandsnetworking.com> wrote:
The timing of one second comes from the GPS satellites and is accurate. Chuck
On Sat, Apr 9, 2016 at 7:03 PM, Joe Leikhim <rhyolite@leikhim.com> wrote:
According to the original documentation for the first generation X1 is a SER3418-ND 9.60MHz 18pf 30ppm.
So 9.6 x (+/-) 30 = +/- 288 Hz.
My question is If the same processor is doing the A/D conversion AND checking the number of samples/second why would there be a discrepancy regardless of the timing offset? Or is the error at the receiving end??
On 4/9/2016 2:16 PM, James Cizek wrote:
Sure Willem, in voter.c, the stock line is:
if ((samplecnt >= 7999) && (samplecnt <= 8001))
it needs to be changed to something like:
if ((samplecnt >= 7999) && (samplecnt <= 8003 ))
That was just enough to make my first RTCM work. I've had a chance now to check a few more of my RTCMs on the bench this morning and the crystal frequencies are kind of all over. The next one I had on the bench was 5.2Khz fast. The above code was still not enough to fix it (as would be expected) so it looks like the quality control on whatever manufacturer that crystal is, isn't very good (or a low tolerance crystal is being used). I am going to pursue crystal replacement to get a highly accurate, stable, on-frequency crystal in there as my first choice. Changing the firmware 5 different times doesn't seem like the right answer.
Jim put that sanity check in there for a reason. Working around it *may* allow the device to work, but to me, it seems getting the hardware operating the way it was supposed to originally is the better answer. I will follow up with Micro-node and let you all know how it goes.
Thanks.
James KI0KN
On Sat, Apr 9, 2016 at 9:05 AM, Willem Schreuder <willem@prinmath.com> wrote:
On Sat, 9 Apr 2016, James Cizek wrote:
Jim helped adjust the code to be more tolerant of the sampling error and
my whole system instantly worked.
Could you please share the code adjustment for future reference.
================================================================ Dr. Willem A. Schreuder, President, Principia Mathematica Address: 445 Union Blvd, Suite 230, Lakewood, CO 80228, USA Tel: (303) 716-3573 Fax: (303) 716-3575 WWW: www.prinmath.com Email: <Willem.Schreuder@prinmath.com> Willem.Schreuder@prinmath.com
_______________________________________________ App_rpt-users mailing listApp_rpt-users@ohnosec.orghttp://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
-- Joe Leikhim
Leikhim and Associates
Communications Consultants
Oviedo, Florida JLeikhim@Leikhim.com 407-982-0446 WWW.LEIKHIM.COM
_______________________________________________ App_rpt-users mailing list App_rpt-users@ohnosec.org http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
To unsubscribe from this list please visit http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users and scroll down to the bottom of the page. Enter your email address and press the "Unsubscribe or edit options button" You do not need a password to unsubscribe, you can do it via email confirmation. If you have trouble unsubscribing, please send a message to the list detailing the problem.
I thought you had to use an external, GPS-synced 9.6MHz clock reference in order to negate clock jitter for simulcasting to work properly (that's been thrown around on this mailing list before). Either way, how is a customer supposed to know if they are getting an RTCM with an in-spec crystal? Has the plans for the PCGM module been tossed? Are there plans for provisioning interfacing for injecting an external 9.6MHz into the RTCM in lieu of it's internal crystal? These are questions I have heard others ask before, and would love an answer to. Thanks! On Saturday, April 9, 2016, James Cizek <james.m.cizek@gmail.com> wrote:
Well, after many of you offered your time and thoughts on my voter problem, Jim WB6NIL graciously donated a couple of hours of his time to remotely help me and he uncovered the problem.
All 5 of my RTCMs were purchased within the last 6 months, and I suspect all 5 have the same problem (will verify that today) The problem is that the microprocessor crystal is running too fast! There is 9.6Mhz crystal that drives the MPU, on the particular unit that Jim helped me diagnose, it's running 2.5 khz too fast. There is a sanity check in the firmware that makes sure the correct number of samples were taken in the last second (it's supposed to be 8000) and fails if the sample is incorrectly sized (mine is taking 8003 samples). Jim helped adjust the code to be more tolerant of the sampling error and my whole system instantly worked.
I have since tested it with ALL my GPSs (they all work great!) So I now have everything working, including the voting.
I haven't contact Micro-Node about it yet. Jim told me that voting should work fine but this clock error would probably not be acceptable for Simulcast (something we have no plans on doing as of now). Since mine are deployed at mountain top sites, I'll probably pursue a crystal that is running at the correct frequency and use "standard" firmware so that if the decision is ever made to play with simulcast, I won't be right back in this same boat.
Thanks to all that helped out, and a HUGE thanks to Jim for taking the time to troubleshoot this.
BTW- This clock error will NOT effect the RTCM in mix client mode, it only affects it in voting or simulcast mode!
Thanks all, have a good weekend.
73 James KI0KN
On Tue, Apr 5, 2016 at 12:56 PM, James Cizek <james.m.cizek@gmail.com <javascript:_e(%7B%7D,'cvml','james.m.cizek@gmail.com');>> wrote:
Hi all,
I posted this problem many months ago and I came to the conclusion at that time that it was my 1PPS signal from the GPS into the RTCM that was the problem. I have changed hardware now to fix that and I still have the problem so I am suspecting a config issue and hope someone will have an idea. This is on a stock DIAL box.
RTCM is setup and working great as a standard node. Everything is working great on the repeater as long as RTCM is in non-voter mode.
I have the chan_voter module loading in modules.conf.
Here is my voter.conf:
[general] port = 667 buflen = 200 password = blah
[1115] Horsetooth = blah,transmit plfilter = y txtoctype = none
I am happy to share any other config if requested.
In the RTCM menus, I have a static IP, I have the voter server IP, all the approriate IP fields filled out. As mentioned, the RTCM works fine with the asterisk server when it's in non-voter mode.
Here's the way I am testing: Verify RTCM menu item 10 is set to (2) None.
Boot server, then boot RTCM. RTCM console says:
GPS Receiver Active, waiting for aquisition GPS signal acquired, number of satellites in view = 9 04/05/2016 17:58:17.560 Time now syncronized to GPS 04/05/2016 18:13:18.580 Host Connection established (Pri) (10.16.1.240)
I have a very nice, clean, 5Volt 1PPS signal going to pin 7 on the DB15. Verfied with o-scope.
as soon as I change menu item 10 on the RTCM to either a (1) or a (0) instead of (2), I *instantly* get this on the RTCM console:
04/05/2016 18:44:13.660 Lost GPS Time synchronization 04/05/2016 18:44:13.660 Host Connection Lost (Pri) (10.16.1.240)
and it sits there forever and never re-establishes connection to the host.
Here is a snippet of the GPS output:
$PFEC,GPtps,160405181603,1,0,1,150701000000,00,17,160405165607,1891,238580 $GPGGA,181603,4020.9810,N,10506.4515,W,0,07,00.00,001566.7,M,-020.0,M,, $GPGSV,2,1,08,03,53,215,46,07,09,253,37,09,28,305,39,16,63,126,43 $GPGSV,2,2,08,22,26,178,44,23,60,316,43,26,52,066,41,31,17,061,34 $GPRMC,181603,V,4020.9810,N,10506.4515,W,,,050416,008.9,E,N*1A $PFEC,GPtps,160405181603,3,0,1,150701000000,00,17,160405165607,1891,238580 $GPGGA,181604,4020.9810,N,10506.4515,W,0,03,00.00,001566.7,M,-020.0,M,, $GPRMC,181604,V,4020.9810,N,10506.4515,W,,,050416,008.9,E,N*1D $PFEC,GPtps,160405181604,3,0,1,150701000000,00,17,160405165607,1891,238581 $GPGGA,181605,4020.9812,N,10506.4495,W,1,07,01.73,001573.3,M,-020.0,M,, $GPRMC,181605,A,4020.9812,N,10506.4495,W,,,050416,008.9,E,A*0F $PFEC,GPtps,160405181605,3,0,1,150701000000,00,17,160405165607,1891,238582 $GPGGA,181606,4020.9812,N,10506.4494,W,1,07,01.73,001573.2,M,-020.0,M,, $GPRMC,181606,A,4020.9812,N,10506.4494,W,000.0,283.2,050416,008.9,E,A*06
I am just not sure where to go from here. I can't seem to find anyone that's had any problem like this or what might be causing it.
I have tried 5 different RTCMs and 5 different GPSs from 3 different manufacturers.
Any suggestions on what I might be missing?
Many thanks for any help anyone can offer!
James KI0KN
-- KJ6QFS Sam Skolfield
Well, if you dont break the built-in sanity check by modifying the firmware, it will just not work, and like with any other device shipped from a manufacturer that does not work, you should probably have it swapped for one that does, unless you prefer broken hardware. ________________________________ From: app_rpt-users-bounces@ohnosec.org <app_rpt-users-bounces@ohnosec.org> on behalf of Sam Skolfield <kj6qfs@gmail.com> Sent: Saturday, April 9, 2016 10:36 AM To: James Cizek Cc: app_rpt mailing list Subject: Re: [App_rpt-users] RTCM voter problem - SOLVED I thought you had to use an external, GPS-synced 9.6MHz clock reference in order to negate clock jitter for simulcasting to work properly (that's been thrown around on this mailing list before). Either way, how is a customer supposed to know if they are getting an RTCM with an in-spec crystal? Has the plans for the PCGM module been tossed? Are there plans for provisioning interfacing for injecting an external 9.6MHz into the RTCM in lieu of it's internal crystal? These are questions I have heard others ask before, and would love an answer to. Thanks! On Saturday, April 9, 2016, James Cizek <james.m.cizek@gmail.com<mailto:james.m.cizek@gmail.com>> wrote: Well, after many of you offered your time and thoughts on my voter problem, Jim WB6NIL graciously donated a couple of hours of his time to remotely help me and he uncovered the problem. All 5 of my RTCMs were purchased within the last 6 months, and I suspect all 5 have the same problem (will verify that today) The problem is that the microprocessor crystal is running too fast! There is 9.6Mhz crystal that drives the MPU, on the particular unit that Jim helped me diagnose, it's running 2.5 khz too fast. There is a sanity check in the firmware that makes sure the correct number of samples were taken in the last second (it's supposed to be 8000) and fails if the sample is incorrectly sized (mine is taking 8003 samples). Jim helped adjust the code to be more tolerant of the sampling error and my whole system instantly worked. I have since tested it with ALL my GPSs (they all work great!) So I now have everything working, including the voting. I haven't contact Micro-Node about it yet. Jim told me that voting should work fine but this clock error would probably not be acceptable for Simulcast (something we have no plans on doing as of now). Since mine are deployed at mountain top sites, I'll probably pursue a crystal that is running at the correct frequency and use "standard" firmware so that if the decision is ever made to play with simulcast, I won't be right back in this same boat. Thanks to all that helped out, and a HUGE thanks to Jim for taking the time to troubleshoot this. BTW- This clock error will NOT effect the RTCM in mix client mode, it only affects it in voting or simulcast mode! Thanks all, have a good weekend. 73 James KI0KN On Tue, Apr 5, 2016 at 12:56 PM, James Cizek <james.m.cizek@gmail.com> wrote: Hi all, I posted this problem many months ago and I came to the conclusion at that time that it was my 1PPS signal from the GPS into the RTCM that was the problem. I have changed hardware now to fix that and I still have the problem so I am suspecting a config issue and hope someone will have an idea. This is on a stock DIAL box. RTCM is setup and working great as a standard node. Everything is working great on the repeater as long as RTCM is in non-voter mode. I have the chan_voter module loading in modules.conf. Here is my voter.conf: [general] port = 667 buflen = 200 password = blah [1115] Horsetooth = blah,transmit plfilter = y txtoctype = none I am happy to share any other config if requested. In the RTCM menus, I have a static IP, I have the voter server IP, all the approriate IP fields filled out. As mentioned, the RTCM works fine with the asterisk server when it's in non-voter mode. Here's the way I am testing: Verify RTCM menu item 10 is set to (2) None. Boot server, then boot RTCM. RTCM console says: GPS Receiver Active, waiting for aquisition GPS signal acquired, number of satellites in view = 9 04/05/2016 17:58:17.560 Time now syncronized to GPS 04/05/2016 18:13:18.580 Host Connection established (Pri) (10.16.1.240) I have a very nice, clean, 5Volt 1PPS signal going to pin 7 on the DB15. Verfied with o-scope. as soon as I change menu item 10 on the RTCM to either a (1) or a (0) instead of (2), I *instantly* get this on the RTCM console: 04/05/2016 18:44:13.660 Lost GPS Time synchronization 04/05/2016 18:44:13.660 Host Connection Lost (Pri) (10.16.1.240) and it sits there forever and never re-establishes connection to the host. Here is a snippet of the GPS output: $PFEC,GPtps,160405181603,1,0,1,150701000000,00,17,160405165607,1891,238580 $GPGGA,181603,4020.9810,N,10506.4515,W,0,07,00.00,001566.7,M,-020.0,M,, $GPGSV,2,1,08,03,53,215,46,07,09,253,37,09,28,305,39,16,63,126,43 $GPGSV,2,2,08,22,26,178,44,23,60,316,43,26,52,066,41,31,17,061,34 $GPRMC,181603,V,4020.9810,N,10506.4515,W,,,050416,008.9,E,N*1A $PFEC,GPtps,160405181603,3,0,1,150701000000,00,17,160405165607,1891,238580 $GPGGA,181604,4020.9810,N,10506.4515,W,0,03,00.00,001566.7,M,-020.0,M,, $GPRMC,181604,V,4020.9810,N,10506.4515,W,,,050416,008.9,E,N*1D $PFEC,GPtps,160405181604,3,0,1,150701000000,00,17,160405165607,1891,238581 $GPGGA,181605,4020.9812,N,10506.4495,W,1,07,01.73,001573.3,M,-020.0,M,, $GPRMC,181605,A,4020.9812,N,10506.4495,W,,,050416,008.9,E,A*0F $PFEC,GPtps,160405181605,3,0,1,150701000000,00,17,160405165607,1891,238582 $GPGGA,181606,4020.9812,N,10506.4494,W,1,07,01.73,001573.2,M,-020.0,M,, $GPRMC,181606,A,4020.9812,N,10506.4494,W,000.0,283.2,050416,008.9,E,A*06 I am just not sure where to go from here. I can't seem to find anyone that's had any problem like this or what might be causing it. I have tried 5 different RTCMs and 5 different GPSs from 3 different manufacturers. Any suggestions on what I might be missing? Many thanks for any help anyone can offer! James KI0KN -- KJ6QFS Sam Skolfield
Wanted to offer a quick update on this. I contact Mark at Micronode. He mentioned 25 units made it out the door with un-approved crystals. He offered to fix my RTCM's or offered to send new crystals. Since I have SMD reflow equipment, I had him send them to me. The crystals arrived a few days later (I was traveling) along with a pouch of SMD capacitors. My 5 RTCMs had the wrong crystal and were missing the crystal buffer capacitors. I was able to solder the new parts in on all 5. I loaded the stock code back to the units Jim Dixson and I were troubleshooting, and had several others that still had stock firmware. All 5 units are working flawlessly now. They are all showing *exactly* 8000 samples/sec and they GPS lock immediately as well as login to the DIAL host and join the voting network. I have been contacted privately by others on the list that are having this problem. I suggest you send the units in to Mark if you don't have the necessary equipment to solder/unsolder surface mount. The caps are some of the smallest of all SMD parts and you will likely have poor luck replacing those and not damaging your RTCM board without a reflow setup. Just my $0.02 there.... Thanks to all on the list that offered help and guidance, to Jim for finding the ultimate root cause, and to Mark for helping rectify it quickly. 73 James KI0KN On Sat, Apr 9, 2016 at 8:09 AM, James Cizek <james.m.cizek@gmail.com> wrote:
Well, after many of you offered your time and thoughts on my voter problem, Jim WB6NIL graciously donated a couple of hours of his time to remotely help me and he uncovered the problem.
All 5 of my RTCMs were purchased within the last 6 months, and I suspect all 5 have the same problem (will verify that today) The problem is that the microprocessor crystal is running too fast! There is 9.6Mhz crystal that drives the MPU, on the particular unit that Jim helped me diagnose, it's running 2.5 khz too fast. There is a sanity check in the firmware that makes sure the correct number of samples were taken in the last second (it's supposed to be 8000) and fails if the sample is incorrectly sized (mine is taking 8003 samples). Jim helped adjust the code to be more tolerant of the sampling error and my whole system instantly worked.
I have since tested it with ALL my GPSs (they all work great!) So I now have everything working, including the voting.
I haven't contact Micro-Node about it yet. Jim told me that voting should work fine but this clock error would probably not be acceptable for Simulcast (something we have no plans on doing as of now). Since mine are deployed at mountain top sites, I'll probably pursue a crystal that is running at the correct frequency and use "standard" firmware so that if the decision is ever made to play with simulcast, I won't be right back in this same boat.
Thanks to all that helped out, and a HUGE thanks to Jim for taking the time to troubleshoot this.
BTW- This clock error will NOT effect the RTCM in mix client mode, it only affects it in voting or simulcast mode!
Thanks all, have a good weekend.
73 James KI0KN
On Tue, Apr 5, 2016 at 12:56 PM, James Cizek <james.m.cizek@gmail.com> wrote:
Hi all,
I posted this problem many months ago and I came to the conclusion at that time that it was my 1PPS signal from the GPS into the RTCM that was the problem. I have changed hardware now to fix that and I still have the problem so I am suspecting a config issue and hope someone will have an idea. This is on a stock DIAL box.
RTCM is setup and working great as a standard node. Everything is working great on the repeater as long as RTCM is in non-voter mode.
I have the chan_voter module loading in modules.conf.
Here is my voter.conf:
[general] port = 667 buflen = 200 password = blah
[1115] Horsetooth = blah,transmit plfilter = y txtoctype = none
I am happy to share any other config if requested.
In the RTCM menus, I have a static IP, I have the voter server IP, all the approriate IP fields filled out. As mentioned, the RTCM works fine with the asterisk server when it's in non-voter mode.
Here's the way I am testing: Verify RTCM menu item 10 is set to (2) None.
Boot server, then boot RTCM. RTCM console says:
GPS Receiver Active, waiting for aquisition GPS signal acquired, number of satellites in view = 9 04/05/2016 17:58:17.560 Time now syncronized to GPS 04/05/2016 18:13:18.580 Host Connection established (Pri) (10.16.1.240)
I have a very nice, clean, 5Volt 1PPS signal going to pin 7 on the DB15. Verfied with o-scope.
as soon as I change menu item 10 on the RTCM to either a (1) or a (0) instead of (2), I *instantly* get this on the RTCM console:
04/05/2016 18:44:13.660 Lost GPS Time synchronization 04/05/2016 18:44:13.660 Host Connection Lost (Pri) (10.16.1.240)
and it sits there forever and never re-establishes connection to the host.
Here is a snippet of the GPS output:
$PFEC,GPtps,160405181603,1,0,1,150701000000,00,17,160405165607,1891,238580 $GPGGA,181603,4020.9810,N,10506.4515,W,0,07,00.00,001566.7,M,-020.0,M,, $GPGSV,2,1,08,03,53,215,46,07,09,253,37,09,28,305,39,16,63,126,43 $GPGSV,2,2,08,22,26,178,44,23,60,316,43,26,52,066,41,31,17,061,34 $GPRMC,181603,V,4020.9810,N,10506.4515,W,,,050416,008.9,E,N*1A $PFEC,GPtps,160405181603,3,0,1,150701000000,00,17,160405165607,1891,238580 $GPGGA,181604,4020.9810,N,10506.4515,W,0,03,00.00,001566.7,M,-020.0,M,, $GPRMC,181604,V,4020.9810,N,10506.4515,W,,,050416,008.9,E,N*1D $PFEC,GPtps,160405181604,3,0,1,150701000000,00,17,160405165607,1891,238581 $GPGGA,181605,4020.9812,N,10506.4495,W,1,07,01.73,001573.3,M,-020.0,M,, $GPRMC,181605,A,4020.9812,N,10506.4495,W,,,050416,008.9,E,A*0F $PFEC,GPtps,160405181605,3,0,1,150701000000,00,17,160405165607,1891,238582 $GPGGA,181606,4020.9812,N,10506.4494,W,1,07,01.73,001573.2,M,-020.0,M,, $GPRMC,181606,A,4020.9812,N,10506.4494,W,000.0,283.2,050416,008.9,E,A*06
I am just not sure where to go from here. I can't seem to find anyone that's had any problem like this or what might be causing it.
I have tried 5 different RTCMs and 5 different GPSs from 3 different manufacturers.
Any suggestions on what I might be missing?
Many thanks for any help anyone can offer!
James KI0KN
participants (6)
-
Chuck Henderson -
James Cizek -
Jim Duuuude -
Joe Leikhim -
Sam Skolfield -
Willem Schreuder