[time-nuts] BC637PCI 1024 week rollover
d0ct0r
time at patoka.org
Wed Feb 12 02:49:01 UTC 2014
Just to confirm: As I was able to connect my new antenna to BC637PCI
card, its starts to produce "incorrect" date stamp:
Binary Time: 06/29/1994 02:32:46.7585224 Status: 7
Binary Time: 06/29/1994 02:32:46.7685866 Status: 7
So, it is June 29, 1994. The time is accurate though.
GPS PACKET 46 - GPS HEALTH PACKET
Status: Doing position fixes
GPS PACKET 41 - GPS TIME PACKET
Seconds of Week: 268765.28
GPS Week Number: 1779
GPS/UCT Offset: 16.00
I'll review the code for NTP. Likely I'l be able to do workaround for
this issue.
Meantime, when I run Lady Heather in parallel with time monitor for
BC637PCI I often see the difference in number of seconds. May be its
because my T-Bolt is not disciplined yet. But its strange any way. I
attached screen shot to this message.
Regards,
V.P.
On 2014-02-11 14:06, GandalfG8 at aol.com wrote:
> 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.
>
> _______________________________________________
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bc637pci-time.PNG
Type: image/png
Size: 62823 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20140211/25451ae0/attachment.png>
More information about the Time-nuts_lists.febo.com
mailing list