[time-nuts] BC637PCI 1024 week rollover
GandalfG8 at aol.com
GandalfG8 at aol.com
Tue Feb 11 14:06:19 EST 2014
Ah, now I understand:-)
All I'm using at the moment though is a small Trimble patch mounted indoors
and although it does drop out occasionally most of the time it's ok, have
you checked your satellite signal levels as reported by the BC637 software?
Although my own interest is really only in using these to condition
external oscillators I would still like to get the time sorted if possible.
However, as well as GPS there is also an option to reference the card to an
external 1PPS so rather than tie up another GPSDO it might be possible
just to remove the Ace3 from the BC637 and run that as a stand alone 1PPS
source, although it's possible of course that once configured in firmware to
accept the onboard GPS module the BC637 may not like running without it.
Regards
Nigel
GM8PZR
In a message dated 11/02/2014 17:38:48 GMT Standard Time, time at patoka.org
writes:
Sorry for confusing information. I have some small Trimble antenna which
currently connected to BC637PCI. However I never get it "locked" with
that antenna:
GPS PACKET 46 - GPS HEALTH PACKET
Status: No usable satellites
Error: 63
Binary Time: 02/11/2014 17:28:40.0572284 Status: 7
Binary Time: 02/11/2014 17:28:40.0672927 Status: 7
Binary Time: 02/11/2014 17:28:40.0773571 Status: 7
Notice "Status: 7". Ideally it should be "Status: 0". As far as I
understood from the documentation, if GPS is not locked then BC637PCI
will using its "freerun mode".
My board FW even older. Its DT10041V11.
Since I am using this card for my "home-brewed" Startum 1 NTP server, I
am thinking to connect to BC637PCI some external 10MHZ GPSDO to keep it
in sync and not using the GPS part at all. The card itself doing well if
its in "free run" mode.
Regards,
V.P.
On 2014-02-11 12:09, GandalfG8 at aol.com wrote:
> Ah, sorry, when you commented before about modifying the demo software
> it
> obviously didn't register with me quite what you were trying to do.
> In the BC637PCI Demo software, I'm using version 7.0.0, under the
> "Help"
> menu, one item is Receiver Firmware Version and this returns the Packet
> 45
> data.
>
> If it's any consolation, mine is the same as yours, except for the date
> showing as 4/1/1900:-)
>
> 2000 doesn't seem unreasonable for the Ace3 firmware date, my BC637
> itself, another drop down on that same Help menu, shows as Version
> DT10041V12,
> Number 2.21, Date 2/10/2003, which ties in pretty well with
> Symmetricom
> completing their takeover of Datum in late 2002 and introducing their
> BC637PCI-U
> own brand replacement in 2004.
>
> What I do find intriguing though is that your Packet 41 data is
> returning
> the correct GPS week number and Leap Second offset when there's no
> antenna
> connected, how the heck does it do that?:-)
>
> Regards
>
> Nigel
> GM8PZR
>
>
>
> In a message dated 11/02/2014 16:36:21 GMT Standard Time,
> time at patoka.org
> writes:
>
>
> I figured out why GPS FW information was not available by request. To
> do
> such requests BC637PCI needs to be in "GPS MODE". If I run the request
> in "Free Run", it return the error code. Here is FW infomation from my
> GPS module:
>
> GPS Packet Menu
>
> 1. Request Packet 41 - Gps Time Packet
> 2. Request Packet 42 - Gps Position Packet
> 3. Request Packet 46 - Gps Health Packet
> 4. Request Packet 45 - Gps FW
> 0. Back to main menu
>
> Select: 1
>
> GPS PACKET 41 - GPS TIME PACKET
>
> Seconds of Week: 232505.89
> GPS Week Number: 1779
> GPS/UCT Offset: 16.00
>
> Select: 4
>
> GPS PACKET 45 - GPS FW
>
> FW: 08-08, 04/01/2000 : 10-16, 04/01/2000
>
> If its correct, than I have pretty old GPS module. I got my GPS
> antenna,
> however it has N-type connector on it. Now I need to find the way to
> connect it to SMA.
>
> Regards,
>
> V.P.
>
> On 2014-02-10 18:51, GandalfG8 at aol.com wrote:
>> In a message dated 10/02/2014 21:56:25 GMT Standard Time,
>> magnus at rubidium.dyndns.org writes:
>>
>> On 10/02/14 11:15, GandalfG8 at aol.com wrote:
>>> Ah, I took 1999 as I thought that was the only relevant date for
>>> another
>>> 1024 weeks, I'm not familiar with the shifted 1024 week period so
>>> will
>> take a
>>> look at that.
>>>
>>> Does "shifted" imply a shift at the whim of the manufacturer, ie
>>> could
>> it
>>> explain why these boards might have been ok a few years ago but
>>> not
>>> now?
>>
>> Yes. We have seen week 500 and week 512 occuring.
>>
>> Considering this simple code:
>>
>> if (gpsweek < 500)
>> gpsweek += 1024;
>>
>> This means that GPS week 500 to 1023 maps straight and truncated
>> GPS
>> week 0 to 499 is mapped to GPS week 1024 to 1523.
>>
>> However, when GPS week 1524 occurs, GPS week 500 is transmitted, so
>> receivers jump from GPS week 1523 to GPS week 500 and the NMEA
>> readout
>> date jumps 19.3 years. Woops.
>>
>> The interesting thing is that the GPS otherwise operate properly, as
>> it
>> is only the read-out date which goes wrong, not the internal gears
>> of
>> the GPS, so the leap second applied will be the current and not the
>> one
>> from 19 years ago.
>> -------------------------------------
>> Yes, that's what I was seeing, anything received by the GPS module
>> was
>> passed through correctly, week number, leap seconds, etc, it was what
>> the BC637
>> did with it after that wasn't quite so helpful.
>> -------------------------------------
>>
>>
>>
>>> Oh dear, I think a wee light bulb has just exploded:-)
>>
>> Good. :)
>>
>>> I haven't checked this yet, but if shifting means to start a 1024
>>> week
>>> period that's approximately from or not too far before the date
>>> of
>>> manufacture, either for individual units or just as a ballpark for
>>> a
>> given production
>>> run, that would buy them nearly twenty years from then, which
>>> would
>> mean
>>> these boards should still be ok.
>>
>> It's arbitrary. It could be from writing the code to just before a
>> certain batch. Who knows. Adjusting it is trivial.
>>
>>> If shifting means to do this say at the design stage or starting
>>> with
>>> the
>>> first production run then they might buy twenty years from then but
>>> regardless of individual manufacturing date.
>>
>> It's arbitrary. Considering that GPS week 500 and GPS week 512 have
>> been
>> found in equipment, and these are not "random numbers", it seems
>> like
>> a
>> random pick early in the design.
>>
>>> I'm not too sure that even the earliest of these boards should be
>>> twenty
>>> years old yet, but if plan Z was to stick with some previously
>>> picked
>>> arbitrary date, such as company formation or granny's birthday,
>>> then
>> that might
>>> well be the answer:-)
>>>
>>> Thank you, will definitely look more closely at this, perhaps it's
>>> not
>> time
>>> yet to put the boards back into hibernation after all:-)
>>
>> Good, now you learned something. :)
>> ------------------------
>> Certainly seems that way, perhaps the old brain cell does still fire
>> up
>> now and again after all:-)
>>
>> I was quite surprised though just how little a Google search threw up
>> on
>> 1024 week offsets, however I worded it I got plenty of hits regarding
>> the
>> 1024 week rollover itself, plus its implications, but virtually
>> nothing
>> regarding the use of offsets and any consequences of that.
>> -----------------------
>>
>>
>>
>>
>>
>>> I agree re the TMS29F010, and I'm sure I could read it, but would
>>> definitely need an adapter for that.
>>
>> Ah. Yes.
>>
>> I don't know what FW my boards have, if it has the GPS FW latent or
>> not.
>> ----------------------------
>> I bought a set of PLCC adapters on Ebay this afternoon, probably
>> about
>> time
>> my programmers joined the 19th century, so with a bit of luck, a
>> following
>> wind, and a good head of steam, I might even have a dump of the
>> firmware
>> by the weekend:-)
>>
>> Regards
>>
>> Nigel
>> GM8PZR
>> _______________________________________________
>> 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.
>
> --
> WBW,
>
> V.P.
> _______________________________________________
> 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.
>
> _______________________________________________
> 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.
--
WBW,
V.P.
_______________________________________________
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.
More information about the time-nuts
mailing list