[time-nuts] The GPS 1995 problem and the Heol Design solution.

Sat May 16 03:46:58 EDT 2015

> Le 15 mai 2015 à 22:16, Sean Gallagher <sean at wetstonetech.com> a écrit :
> 
> Good afternoon everyone,

Thanks for sharing this with us Sean.

> 
>    So as most (all) of you are aware at this point what seems to be like all of the Trimble Ace III GPS receivers have looped around their entire lifespan and are setting the date back to 1995. This is affecting many people with the Datum/Symmetricom TymServe 2100 units. My company had two such units (we had purchased a second one when the +1 second UTC thing happened not realizing it was a firmware v3 and 4 problem) and also a slew of Datum 635/637 PCI cards which use the Trimble Ace III as well.
> 
>    After some scrounging around on the web I found that a company in France, Heol Design (http://www.heoldesign.com/), had created an Ace III clone. I contacted them for some information and a quote on what sounded the most promising. These were the N014 and N024 units which were quoted to me as 85 euro for the 014 and 90 euro for the 024. I also asked them if they thought their units would correct the date problem and they reached out to Trimble who apparently was not able (or willing?) to provide an answer. Olivier Descoubès with Heol Designs however was willing to work with me for testing purposes and sent me 2 of the N024 units so that I could test and see if they would work as true drop in replacements. I have attached the data sheets that I received on the units as well for your viewing.  I'm not as technical as most of you so maybe you'll see something that I don't get that you can work with.
> 
>    The units came in yesterday after COB and so this morning was the moment of truth. Short answer to everything is they don't seem to work. I hooked it in to both of my 2100's first the older Datum branded one then the newer Symmetricom brand (although they look physically to be the exact same underlying board) really just to try and cover all my bases. I let the first one go for about an hour and the second for only half an hour since I was already thinking this was a bust. While it was hooked up though I telnetted in and went into the GPS menu. It gave me my Lat/Long position and the satellites command was able to show me that I had plenty of coverage, but it was unable to give me the time.
> 
>    After that I hooked it on to one of my 635PCI cards and got one of my backup servers going. I started up the Datum application and it did go into GPS mode which was at first promising. Typically with these cards if there is a problem between the GPS receiver and the Datum card then it will automatically come up in Time Code mode and won't even recognize the GPS. I let it run for about an hour while I ran to lunch and when I came back it had still not put out time.
> 
>    My guess is that these new receivers use the "Extended date" format or whatever it's called that adds more bits on (3? - sorry I can't remember specifics) to correct the rollover and changes it from 15 years to like 157 or something like that. And it seems like this older equipment that a lot of timing solutions use cannot handle this new output and thus can't decode it. Again I'm just a Junior in college so this is all just theory but it's what my gut feeling is.

From the data sheet, the boards use a Trimble Copernicus  II chip and I took a look at the manual. They do indeed use an extended week number field in setting and reporting the week number (packets 0x21 and 0x41). But so does that Ace III. I expect that as stand alone units, they will not be subject the roll over issue as it is just a symptom of inadequate engineering or , dare I say it, programmed obsolescence . The problem with having a supervising firmware is that they can ignore any  bits they want.  

The ACEIII System Designer Reference Manual says:

 Caution – Trimble OEM GPS receivers have reported the true GPS Week Number in TSIP
messages 0x41 and 0x8F-20 as a number between 0 and 1023. The ACE III GPS outputs
the Extended GPS Week Number as the absolute number of weeks since the beginning of
GPS time or 06 January 1980. If the true GPS Week Number is desired, the system
developer should ignore the extra MSBs of the Extended GPS Week Number and use only
the 10 LSBs.

Unfortunately I don’t have an Ace III to check if that is correct. 

> 
>    I've also attached pictures of these new units. They are the same size and have the 8 pin stack. There is additionally a 10 pin stack that I had to trim down to get it to fit. Also the antenna connector is an SMB, same as the Ace III, however it is on the other plane of the board. So if you were looking at putting it in a 635PCI card like me I had to use tin snips and cut out a notch on the front plate of it to make it fit.
> 
>    So it looks like I had to take a page from Mr. Andrew Cooper's book and have set up a rig like his using the two 2100's in unison. I have GPS going into the older one which I have reverted back to it's oldest firmware (2.84 I think) and thus avoided the 1 second problem. This older unit is putting out a 1PPS into the newer one set mode for 1PPS that is on V3.1 of firmware with the time and date manually being set through telnet. Trying to do it at the unit face is not feasible don't try it and I couldn't do this on the 2.84 firmware version for some reason it wouldn't recognize the commands. A colleague of mine seems to think for some reason that I might start getting drift again with this setup. He said that the 1PPS may not be enough to discipline the other 2100 do you guys have any thoughts on that? It doesn't make a lot of sense to me as it's just a pulse
> 
>    I had kind of a crazy thought earlier based on a project that I had considered doing. I've seen on the internet that some people have taken a Raspberry Pi and made a timing solution out of it. At least one using what looked like the same type of Trimble III card.
> 
> http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
> http://musingsfromthe8thfloor.com/2015/02/08/stratum-1-ntp-server-on-raspberry-pi/comment-page-1/
> https://digitalnigel.com/wordpress/?p=1781

  Not the same receivers. Anyway as Bob said, it would probably not be cost effective to go down that path. 

> 
> Does anyone think it would be possible to do this with these new receivers and get it to work? Even if it was only used to discipline some larger clock unit like the 2100? Or maybe even using the older receivers but making the RPi correct the rollover problem somehow? It looked like without me putting a lot of work into it I wouldn't be able to get it going because of having to learn the pin programming and electrical theory etc. And I unfortunately do not have the resources at work currently to follow this line of thinking.
> 
> **** I have just received an email from Olivier and they are aware of the TS2100 issue from a customer of theirs in France. That customer is shipping them the unit so that Heol can investigate it in action with a 2100 and can maybe come up with a solution.****

  Please update here with any news you get. 

> 
> -- 
> Respectfully,
> 
> 
> Sean Gallagher
> Malware Analyst
> 571-340-3475
> 
> <Heol Design.zip>_______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

"Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité."
Benjimin Franklin