[time-nuts] BC637PCI Flash Memory Dump
I've downloaded the flash memory contents from a BC637PCI card, it's a 128K file but also had to save it as 64K to please the disassemblers I found online. That didn't look to be an issue, as far as I can tell only 64K is used anyway. The memory chip is a CAT28F010, as opposed to a 29F010 shown in the schematics, and the processor is an MC68HC11F1CFN4. If anyone wants to talk a look my files are here https://www.mediafire.com/?kavvrm2cow2365c There's the two binary files there plus some of my efforts at disassembly but I have to admit the disassembled files do even less for me than the binaries:-) Other than some messages at the beginning of the data area that seem to relate to file update processes, perhaps for the GPS and oscillator options, the only other obvious text string I found just said BC635IRIG. I know that may not be too significant in itself but there's 512 bytes of EEPROM inside the CPU and I'm wondering if that's handling the personalised data such as serial number and configuration etc. None of which helps with the 1024 week offset of course:-) Regards Nigel GM8PZR ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
You've lost me, what code are you modifying at the moment, is it the
actual Datum demo software?
Regards
Nigel
GM8PZR
In a message dated 12/02/2014 03:48:12 GMT Standard Time, t...@patoka.org
writes:
You are right ! Now I am going to modify the code a lit bit.
Each time as we call bcReadBinTimeEx or bcReadBinTime, we need to add
magic number to unsigned long pointer which store major time. Example:
if (bcReadBinTime(stfp_handle, btm[1], btm[0], stat ) == 0) {
msyslog(LOG_ERR, get_datumtime error:
%m);
return(NULL);
}
btm[1] + 619315200;
At least its working for demo:
Binary Time: 02/12/2014 03:45:09.6158902 Status: 7
Binary Time: 02/12/2014 03:45:09.6259547 Status: 7
Binary Time: 02/12/2014 03:45:09.6360200 Status: 7
On 2014-02-10 18:51, gandal...@aol.com wrote:
In a message dated 10/02/2014 21:56:25 GMT Standard Time,
mag...@rubidium.dyndns.org writes:
On 10/02/14 11:15, gandal...@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@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
WBW,
V.P.
--
WBW,
V.P.
___
time-nuts mailing list --
Re: [time-nuts] BC637PCI 1024 week rollover
I modified two things for now. Its a demo software (Linux edition).
And refclock_banncom driver for NTP. Personally, I would prefer to
modify microcode or library. But that is proprietary with no source code
around.
Regards,
V.P.
On 2014-02-13 10:46, gandal...@aol.com wrote:
You've lost me, what code are you modifying at the moment, is it the
actual Datum demo software?
Regards
Nigel
GM8PZR
In a message dated 12/02/2014 03:48:12 GMT Standard Time,
t...@patoka.org
writes:
You are right ! Now I am going to modify the code a lit bit.
Each time as we call bcReadBinTimeEx or bcReadBinTime, we need to add
magic number to unsigned long pointer which store major time.
Example:
if (bcReadBinTime(stfp_handle, btm[1], btm[0], stat ) == 0) {
msyslog(LOG_ERR, get_datumtime error:
%m);
return(NULL);
}
btm[1] + 619315200;
At least its working for demo:
Binary Time: 02/12/2014 03:45:09.6158902 Status: 7
Binary Time: 02/12/2014 03:45:09.6259547 Status: 7
Binary Time: 02/12/2014 03:45:09.6360200 Status: 7
On 2014-02-10 18:51, gandal...@aol.com wrote:
In a message dated 10/02/2014 21:56:25 GMT Standard Time,
mag...@rubidium.dyndns.org writes:
On 10/02/14 11:15, gandal...@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@febo.com
To unsubscribe, go to
Re: [time-nuts] BC637PCI 1024 week rollover
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, gandal...@aol.com wrote: In a message dated 10/02/2014 21:56:25 GMT Standard Time, mag...@rubidium.dyndns.org writes: On 10/02/14 11:15, gandal...@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
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, t...@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, gandal...@aol.com wrote: In a message dated 10/02/2014 21:56:25 GMT Standard Time, mag...@rubidium.dyndns.org writes: On 10/02/14 11:15, gandal...@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
Re: [time-nuts] BC637PCI 1024 week rollover
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, gandal...@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, t...@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, gandal...@aol.com wrote: In a message dated 10/02/2014 21:56:25 GMT Standard Time, mag...@rubidium.dyndns.org writes: On 10/02/14 11:15, gandal...@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.
Re: [time-nuts] BC637PCI 1024 week rollover
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, t...@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, gandal...@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, t...@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, gandal...@aol.com wrote: In a message dated 10/02/2014 21:56:25 GMT Standard Time, mag...@rubidium.dyndns.org writes: On 10/02/14 11:15, gandal...@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
Re: [time-nuts] BC637PCI 1024 week rollover
You are right ! Now I am going to modify the code a lit bit.
Each time as we call bcReadBinTimeEx or bcReadBinTime, we need to add
magic number to unsigned long pointer which store major time. Example:
if (bcReadBinTime(stfp_handle, btm[1], btm[0], stat ) == 0) {
msyslog(LOG_ERR, get_datumtime error:
%m);
return(NULL);
}
btm[1] + 619315200;
At least its working for demo:
Binary Time: 02/12/2014 03:45:09.6158902 Status: 7
Binary Time: 02/12/2014 03:45:09.6259547 Status: 7
Binary Time: 02/12/2014 03:45:09.6360200 Status: 7
On 2014-02-10 18:51, gandal...@aol.com wrote:
In a message dated 10/02/2014 21:56:25 GMT Standard Time,
mag...@rubidium.dyndns.org writes:
On 10/02/14 11:15, gandal...@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@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
WBW,
V.P.
--
WBW,
V.P.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
That's the document I was refering to when I said earlier that I'd seen written confirmation from Trimble that they weren't expecting any rollover problems with the Ace3, I didn't mention the through the year 2015 comment as we haven't actually got there yet:-) That may indeed be an issue in the not too distant future but for now I have no concerns over the Ace3, as per previous comments I've tested both the Ace3 and Ace2 and demonstrated they handle the date correctly. The problem, as I'm seeing it here anyway, seems to lie with the BC637 itself. The BC637 demo software menu item Time/Receiver Time returns, by way of example, the following, Time of Week -- 119761.64, Week Number -- 1779, GPS/UTC -- 16.0 Note that the week number is correct, and this is one of the reasons I've assumed the BC637 is taking raw data from the Ace3 and doing its own processing, the fact that the Ace3 iteslf knows the right date is perhaps another hint:-) All I'm still hoping for at the moment is just that another BC637 user can confirm whether or not they're seeing the same thing or whether their date display from the demo software is correct. It does appear that the BC637 is in error but this still doesn't seem to me to be logical, given its date of manufacture plus my doubts over what it was doing a few years ago. So, at this stage, I still feel I haven't fully eliminated the possibility that it's me doing something stupid, and that's all I'm trying to establish before pursuing it any further. Regards Nigel GM8PZR In a message dated 10/02/2014 00:23:34 GMT Standard Time, t...@patoka.org writes: I found the document about Trimble ACE3 module: http://www.symres.com/files/ACE3.pdf Here is the paragraph about WNRO: Effect of GPS Week Number Roll-over (WNRO) The ACE III GPS module has been designed to handle WNRO, and there are no problems with either dates or first fix after WNRO through the year 2015. [* Note – GPS Week Numbers system, as defined by the ICD200 GPS Specification, occupy a range from zero to 1023. The Week Number Roll Over (WNRO) occurs every 1024 weeks, or approximately every 19 years 8 months. August 1999 was the first roll-over for the GPS system since the beginning of GPS time on 06 January 1980.] [ 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] I tried to modify the demo code to obtain FW of my GPS module. But I had no luck with it, since bcGPSMan subroutine always return ERROR state in response to packet ID 0x1F. Regards, V.P. On 2014-02-09 16:05, gandal...@aol.com wrote: In a message dated 09/02/2014 15:31:47 GMT Standard Time, mag...@rubidium.dyndns.org writes: On 09/02/14 12:56, gandal...@aol.com wrote: Oh well, full credit to Mr Trimble for getting it right, he does bake exceedingly nice GPS modules and the Ace3 doesn't have a rollover issue and it does report the date correctly. Unfortunately, as far as I can tell anyway, the BC637PCI takes the raw GPS time data from the Ace3 and performs its own calculation which is where the problem seems to occur, certainly it's a 1024 week issue with the date from the BC637 being displayed as June 26 1994 in all versions of the associated demo software. It is possible to set the date correctly but the next packet from the GPS module promptly overwrites it again. I still don't recall seeing this before, although with two boards behaving in the same fashion I'm having doubts about that, but more to the point these boards indicate a firmware date of 2003 which implies they were put into the field like this, and that doesn't make much sense either. Any ideas anyone?, and again has anyone else seen this and/or am I missing something glaringly obvious? If the ACE3 gives correct date, but the BC637 FW does not, then it is obvious that the FW does the unwrapping itself just like a problematic GPS receiver would. Most probably would the ACE3 have issues if it looses it's CMOS backup. I haven't looked at those details, but you should be able to disable the date from being set by the GPS. Maybe play around there. Might be that the FW needs an update, which naturally may not be in existence. Can you read-out the EPROM? Only proves to show that my comment that NTPD needs to do the 1024 week correction for other GPS dependent drivers than the NMEA (NTP bug
Re: [time-nuts] BC637PCI 1024 week rollover
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? Oh dear, I think a wee light bulb has just exploded:-) 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. 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. 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:-) I agree re the TMS29F010, and I'm sure I could read it, but would definitely need an adapter for that. Regards Nigel GM8PZR In a message dated 10/02/2014 01:40:44 GMT Standard Time, mag...@rubidium.dyndns.org writes: It probably operates on a shifted 1024 week period and that was probably not changed after the original code was written. Obviously the shifted wrapping has now occurred. 1999 is only relevant for the non-shifted 1024 period. It is possible to set the board for other than GPS, (Timecode, Freerunning, or 1PPS) but I suspect I might then loose the conditioning, something I'd need to check. Either way, I'd like to have the correct GPS date too if possible, but it's the conditioning that's of more interest so I'd do without the correct date if needs be. I've identified two programmable devices, the version H manual with schematics is very useful:-), the first being a OTP configuration PROM for the Spartan FPGA and the other a TMS29F010 flash mamory IC which I suspect holds the firmware. That is socketed but I don't think I have the necessary 32 pin quad adapter to be able to read it. It would be the TMS29F010 flash which would be of interest. This was only intended to be a quick test, funny how quick tests soon become major projects:-), so these might have to go back into hibernation again shortly, for the time being at least. Fair enough! Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
On 10/02/14 11:15, gandal...@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. 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. :) 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. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
In a message dated 10/02/2014 21:56:25 GMT Standard Time, mag...@rubidium.dyndns.org writes: On 10/02/14 11:15, gandal...@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] BC637PCI 1024 week rollover
Oh well, full credit to Mr Trimble for getting it right, he does bake exceedingly nice GPS modules and the Ace3 doesn't have a rollover issue and it does report the date correctly. Unfortunately, as far as I can tell anyway, the BC637PCI takes the raw GPS time data from the Ace3 and performs its own calculation which is where the problem seems to occur, certainly it's a 1024 week issue with the date from the BC637 being displayed as June 26 1994 in all versions of the associated demo software. It is possible to set the date correctly but the next packet from the GPS module promptly overwrites it again. I still don't recall seeing this before, although with two boards behaving in the same fashion I'm having doubts about that, but more to the point these boards indicate a firmware date of 2003 which implies they were put into the field like this, and that doesn't make much sense either. Any ideas anyone?, and again has anyone else seen this and/or am I missing something glaringly obvious? Regards Nigel GM8PZR ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
On 09/02/14 12:56, gandal...@aol.com wrote: Oh well, full credit to Mr Trimble for getting it right, he does bake exceedingly nice GPS modules and the Ace3 doesn't have a rollover issue and it does report the date correctly. Unfortunately, as far as I can tell anyway, the BC637PCI takes the raw GPS time data from the Ace3 and performs its own calculation which is where the problem seems to occur, certainly it's a 1024 week issue with the date from the BC637 being displayed as June 26 1994 in all versions of the associated demo software. It is possible to set the date correctly but the next packet from the GPS module promptly overwrites it again. I still don't recall seeing this before, although with two boards behaving in the same fashion I'm having doubts about that, but more to the point these boards indicate a firmware date of 2003 which implies they were put into the field like this, and that doesn't make much sense either. Any ideas anyone?, and again has anyone else seen this and/or am I missing something glaringly obvious? If the ACE3 gives correct date, but the BC637 FW does not, then it is obvious that the FW does the unwrapping itself just like a problematic GPS receiver would. Most probably would the ACE3 have issues if it looses it's CMOS backup. I haven't looked at those details, but you should be able to disable the date from being set by the GPS. Maybe play around there. Might be that the FW needs an update, which naturally may not be in existence. Can you read-out the EPROM? Only proves to show that my comment that NTPD needs to do the 1024 week correction for other GPS dependent drivers than the NMEA (NTP bug 2466) is a correct assumption. See the posting I forwarded yesterday. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
Hello, I'll be glad to check my GPS module to see what is going on there, however I am still waiting for the GPS antenna to be delivered. I tried to use some small form factor Trimple GPS antenna with BC637, but on-board GPS module couldn't lock with it. So, my BC637 is working in freerun mode now: Time Settings: Mode : Free Run Time Format: Binary Year : 2014 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 0 Scheduled Leap Event Time : 1391731200 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable I have no issues with date stamp in that mode: Binary Time: 02/09/2014 14:36:19.7005289 Status: 0 Binary Time: 02/09/2014 14:36:19.7105941 Status: 0 Binary Time: 02/09/2014 14:36:19.7206589 Status: 0 Even if I switch BC637 to GPS mode, it still using correct date. Which is expected, because in accordance with documents, if GPS is not locked, BC637 will behave in the same way as free run. The difference is the Status. Its shows, four bits. And one of them indicates that GPS is not locked: Binary Time: 02/09/2014 14:37:43.0045326 Status: 7 Binary Time: 02/09/2014 14:37:43.0146051 Status: 7 Binary Time: 02/09/2014 14:37:43.0246776 Status: 7 As soon as I'll get my bullet GPS antena attached, I'll see what is going on there for the date stamp. Also, in the documents, I saw some sections, which explain how to use data registers to send some command to Trimble GPS. Probably its is possible to do some corrections through that procedure. May be it is possible to attach another GPS module to the BC637 card. Its using 9 pin connector. This connector is used primarily for connecting the ACE III GPS. Data communications between the board and the GPS receiver are via serial signals. Additionally, the GPS receiver provides a 1 PPS signal to the board. Regards, V.P. On 2014-02-09 06:56, gandal...@aol.com wrote: Oh well, full credit to Mr Trimble for getting it right, he does bake exceedingly nice GPS modules and the Ace3 doesn't have a rollover issue and it does report the date correctly. Unfortunately, as far as I can tell anyway, the BC637PCI takes the raw GPS time data from the Ace3 and performs its own calculation which is where the problem seems to occur, certainly it's a 1024 week issue with the date from the BC637 being displayed as June 26 1994 in all versions of the associated demo software. It is possible to set the date correctly but the next packet from the GPS module promptly overwrites it again. I still don't recall seeing this before, although with two boards behaving in the same fashion I'm having doubts about that, but more to the point these boards indicate a firmware date of 2003 which implies they were put into the field like this, and that doesn't make much sense either. Any ideas anyone?, and again has anyone else seen this and/or am I missing something glaringly obvious? Regards Nigel GM8PZR ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
In a message dated 09/02/2014 15:31:47 GMT Standard Time, mag...@rubidium.dyndns.org writes: On 09/02/14 12:56, gandal...@aol.com wrote: Oh well, full credit to Mr Trimble for getting it right, he does bake exceedingly nice GPS modules and the Ace3 doesn't have a rollover issue and it does report the date correctly. Unfortunately, as far as I can tell anyway, the BC637PCI takes the raw GPS time data from the Ace3 and performs its own calculation which is where the problem seems to occur, certainly it's a 1024 week issue with the date from the BC637 being displayed as June 26 1994 in all versions of the associated demo software. It is possible to set the date correctly but the next packet from the GPS module promptly overwrites it again. I still don't recall seeing this before, although with two boards behaving in the same fashion I'm having doubts about that, but more to the point these boards indicate a firmware date of 2003 which implies they were put into the field like this, and that doesn't make much sense either. Any ideas anyone?, and again has anyone else seen this and/or am I missing something glaringly obvious? If the ACE3 gives correct date, but the BC637 FW does not, then it is obvious that the FW does the unwrapping itself just like a problematic GPS receiver would. Most probably would the ACE3 have issues if it looses it's CMOS backup. I haven't looked at those details, but you should be able to disable the date from being set by the GPS. Maybe play around there. Might be that the FW needs an update, which naturally may not be in existence. Can you read-out the EPROM? Only proves to show that my comment that NTPD needs to do the 1024 week correction for other GPS dependent drivers than the NMEA (NTP bug 2466) is a correct assumption. See the posting I forwarded yesterday. Cheers, Magnus Hi Magnus, and thanks for your comments. I arrived at the same conclusion regarding the BC637 firmware and that's the issue I'd like to resolve, but I'm a bit cautious given that these were produced after 1999 as I can't understand why the firmware wouldn't already have been updated. It is possible to set the board for other than GPS, (Timecode, Freerunning, or 1PPS) but I suspect I might then loose the conditioning, something I'd need to check. Either way, I'd like to have the correct GPS date too if possible, but it's the conditioning that's of more interest so I'd do without the correct date if needs be. I've identified two programmable devices, the version H manual with schematics is very useful:-), the first being a OTP configuration PROM for the Spartan FPGA and the other a TMS29F010 flash mamory IC which I suspect holds the firmware. That is socketed but I don't think I have the necessary 32 pin quad adapter to be able to read it. This was only intended to be a quick test, funny how quick tests soon become major projects:-), so these might have to go back into hibernation again shortly, for the time being at least. Regards Nigel ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
It may be that your onboard batteries are in better health than mine are, although mine might have been disabled using the software, as I tried booting up without an antenna this evening and got the right year this time but twith he date as 1st January:-) What I found when running in GPS mode was that I could correct the date but it would get overwritten again. As I commented in my previous reply to Magnus' comments, I still don't understand why units produced after 1999 should have this problem anyway. Thanks for the data, I'll keep that and compare later, and I'll be very interested to hear how yours performs once the antennna is connected. Running off 1PPS is an option but I'd much prefer to use actual GPS time if possible, unfortunately, as commented earlier, the problem lies with the BC637 itself, not the GPS module. Your mention of other GPS modules reminds me that the appropriate set of schematics for these BC637s shows that a header swap would allow the board to use a Motorola Oncore in place of the Trimble ACE2 or ACE3. Not sure that I'll ever try that but it might help explain why they take the raw GPS data rather than what's already been processed by the module. Regards Nigel In a message dated 09/02/2014 15:34:22 GMT Standard Time, t...@patoka.org writes: Hello, I'll be glad to check my GPS module to see what is going on there, however I am still waiting for the GPS antenna to be delivered. I tried to use some small form factor Trimple GPS antenna with BC637, but on-board GPS module couldn't lock with it. So, my BC637 is working in freerun mode now: Time Settings: Mode : Free Run Time Format : Binary Year : 2014 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 0 Scheduled Leap Event Time : 1391731200 Scheduled Leap Event Flag : Insertion GPS Time Format : UTC Format IEEE Daylight Savings Flag : Enable I have no issues with date stamp in that mode: Binary Time: 02/09/2014 14:36:19.7005289 Status: 0 Binary Time: 02/09/2014 14:36:19.7105941 Status: 0 Binary Time: 02/09/2014 14:36:19.7206589 Status: 0 Even if I switch BC637 to GPS mode, it still using correct date. Which is expected, because in accordance with documents, if GPS is not locked, BC637 will behave in the same way as free run. The difference is the Status. Its shows, four bits. And one of them indicates that GPS is not locked: Binary Time: 02/09/2014 14:37:43.0045326 Status: 7 Binary Time: 02/09/2014 14:37:43.0146051 Status: 7 Binary Time: 02/09/2014 14:37:43.0246776 Status: 7 As soon as I'll get my bullet GPS antena attached, I'll see what is going on there for the date stamp. Also, in the documents, I saw some sections, which explain how to use data registers to send some command to Trimble GPS. Probably its is possible to do some corrections through that procedure. May be it is possible to attach another GPS module to the BC637 card. Its using 9 pin connector. This connector is used primarily for connecting the ACE III GPS. Data communications between the board and the GPS receiver are via serial signals. Additionally, the GPS receiver provides a 1 PPS signal to the board. Regards, V.P. On 2014-02-09 06:56, gandal...@aol.com wrote: Oh well, full credit to Mr Trimble for getting it right, he does bake exceedingly nice GPS modules and the Ace3 doesn't have a rollover issue and it does report the date correctly. Unfortunately, as far as I can tell anyway, the BC637PCI takes the raw GPS time data from the Ace3 and performs its own calculation which is where the problem seems to occur, certainly it's a 1024 week issue with the date from the BC637 being displayed as June 26 1994 in all versions of the associated demo software. It is possible to set the date correctly but the next packet from the GPS module promptly overwrites it again. I still don't recall seeing this before, although with two boards behaving in the same fashion I'm having doubts about that, but more to the point these boards indicate a firmware date of 2003 which implies they were put into the field like this, and that doesn't make much sense either. Any ideas anyone?, and again has anyone else seen this and/or am I missing something glaringly obvious? Regards Nigel GM8PZR ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___
Re: [time-nuts] BC637PCI 1024 week rollover
I found the document about Trimble ACE3 module: http://www.symres.com/files/ACE3.pdf Here is the paragraph about WNRO: Effect of GPS Week Number Roll-over (WNRO) The ACE III GPS module has been designed to handle WNRO, and there are no problems with either dates or first fix after WNRO through the year 2015. [* Note – GPS Week Numbers system, as defined by the ICD200 GPS Specification, occupy a range from zero to 1023. The Week Number Roll Over (WNRO) occurs every 1024 weeks, or approximately every 19 years 8 months. August 1999 was the first roll-over for the GPS system since the beginning of GPS time on 06 January 1980.] [ 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] I tried to modify the demo code to obtain FW of my GPS module. But I had no luck with it, since bcGPSMan subroutine always return ERROR state in response to packet ID 0x1F. Regards, V.P. On 2014-02-09 16:05, gandal...@aol.com wrote: In a message dated 09/02/2014 15:31:47 GMT Standard Time, mag...@rubidium.dyndns.org writes: On 09/02/14 12:56, gandal...@aol.com wrote: Oh well, full credit to Mr Trimble for getting it right, he does bake exceedingly nice GPS modules and the Ace3 doesn't have a rollover issue and it does report the date correctly. Unfortunately, as far as I can tell anyway, the BC637PCI takes the raw GPS time data from the Ace3 and performs its own calculation which is where the problem seems to occur, certainly it's a 1024 week issue with the date from the BC637 being displayed as June 26 1994 in all versions of the associated demo software. It is possible to set the date correctly but the next packet from the GPS module promptly overwrites it again. I still don't recall seeing this before, although with two boards behaving in the same fashion I'm having doubts about that, but more to the point these boards indicate a firmware date of 2003 which implies they were put into the field like this, and that doesn't make much sense either. Any ideas anyone?, and again has anyone else seen this and/or am I missing something glaringly obvious? If the ACE3 gives correct date, but the BC637 FW does not, then it is obvious that the FW does the unwrapping itself just like a problematic GPS receiver would. Most probably would the ACE3 have issues if it looses it's CMOS backup. I haven't looked at those details, but you should be able to disable the date from being set by the GPS. Maybe play around there. Might be that the FW needs an update, which naturally may not be in existence. Can you read-out the EPROM? Only proves to show that my comment that NTPD needs to do the 1024 week correction for other GPS dependent drivers than the NMEA (NTP bug 2466) is a correct assumption. See the posting I forwarded yesterday. Cheers, Magnus Hi Magnus, and thanks for your comments. I arrived at the same conclusion regarding the BC637 firmware and that's the issue I'd like to resolve, but I'm a bit cautious given that these were produced after 1999 as I can't understand why the firmware wouldn't already have been updated. It is possible to set the board for other than GPS, (Timecode, Freerunning, or 1PPS) but I suspect I might then loose the conditioning, something I'd need to check. Either way, I'd like to have the correct GPS date too if possible, but it's the conditioning that's of more interest so I'd do without the correct date if needs be. I've identified two programmable devices, the version H manual with schematics is very useful:-), the first being a OTP configuration PROM for the Spartan FPGA and the other a TMS29F010 flash mamory IC which I suspect holds the firmware. That is socketed but I don't think I have the necessary 32 pin quad adapter to be able to read it. This was only intended to be a quick test, funny how quick tests soon become major projects:-), so these might have to go back into hibernation again shortly, for the time being at least. Regards Nigel ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
On 09/02/14 22:05, gandal...@aol.com wrote: In a message dated 09/02/2014 15:31:47 GMT Standard Time, mag...@rubidium.dyndns.org writes: On 09/02/14 12:56, gandal...@aol.com wrote: Oh well, full credit to Mr Trimble for getting it right, he does bake exceedingly nice GPS modules and the Ace3 doesn't have a rollover issue and it does report the date correctly. Unfortunately, as far as I can tell anyway, the BC637PCI takes the raw GPS time data from the Ace3 and performs its own calculation which is where the problem seems to occur, certainly it's a 1024 week issue with the date from the BC637 being displayed as June 26 1994 in all versions of the associated demo software. It is possible to set the date correctly but the next packet from the GPS module promptly overwrites it again. I still don't recall seeing this before, although with two boards behaving in the same fashion I'm having doubts about that, but more to the point these boards indicate a firmware date of 2003 which implies they were put into the field like this, and that doesn't make much sense either. Any ideas anyone?, and again has anyone else seen this and/or am I missing something glaringly obvious? If the ACE3 gives correct date, but the BC637 FW does not, then it is obvious that the FW does the unwrapping itself just like a problematic GPS receiver would. Most probably would the ACE3 have issues if it looses it's CMOS backup. I haven't looked at those details, but you should be able to disable the date from being set by the GPS. Maybe play around there. Might be that the FW needs an update, which naturally may not be in existence. Can you read-out the EPROM? Only proves to show that my comment that NTPD needs to do the 1024 week correction for other GPS dependent drivers than the NMEA (NTP bug 2466) is a correct assumption. See the posting I forwarded yesterday. Cheers, Magnus Hi Magnus, and thanks for your comments. I arrived at the same conclusion regarding the BC637 firmware and that's the issue I'd like to resolve, but I'm a bit cautious given that these were produced after 1999 as I can't understand why the firmware wouldn't already have been updated.' It probably operates on a shifted 1024 week period and that was probably not changed after the original code was written. Obviously the shifted wrapping has now occurred. 1999 is only relevant for the non-shifted 1024 period. It is possible to set the board for other than GPS, (Timecode, Freerunning, or 1PPS) but I suspect I might then loose the conditioning, something I'd need to check. Either way, I'd like to have the correct GPS date too if possible, but it's the conditioning that's of more interest so I'd do without the correct date if needs be. I've identified two programmable devices, the version H manual with schematics is very useful:-), the first being a OTP configuration PROM for the Spartan FPGA and the other a TMS29F010 flash mamory IC which I suspect holds the firmware. That is socketed but I don't think I have the necessary 32 pin quad adapter to be able to read it. It would be the TMS29F010 flash which would be of interest. This was only intended to be a quick test, funny how quick tests soon become major projects:-), so these might have to go back into hibernation again shortly, for the time being at least. Fair enough! Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI 1024 week rollover
On 09/02/14 23:24, d0ct0r wrote: I found the document about Trimble ACE3 module: http://www.symres.com/files/ACE3.pdf Here is the paragraph about WNRO: Effect of GPS Week Number Roll-over (WNRO) The ACE III GPS module has been designed to handle WNRO, and there are no problems with either dates or first fix after WNRO through the year 2015. [* Note – GPS Week Numbers system, as defined by the ICD200 GPS Specification, occupy a range from zero to 1023. The Week Number Roll Over (WNRO) occurs every 1024 weeks, or approximately every 19 years 8 months. August 1999 was the first roll-over for the GPS system since the beginning of GPS time on 06 January 1980.] First GPS week of 2016 is GPS week of 1878. Which gives indication wrap-around and also means it has been valid since mid 1996. [ 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] If you don't listen to the Extended GPS Week Number, you are toast, but as there is an end to the Ace III extension capability, there isn't far away and you are toast anyway. I tried to modify the demo code to obtain FW of my GPS module. But I had no luck with it, since bcGPSMan subroutine always return ERROR state in response to packet ID 0x1F. I think this is another case where the developers didn't forsee this situation. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
On 07/02/14 09:09, Robert Watzlavick wrote: Magnus, What kind of problems did you have with it? I have a couple of BC635PCI boards that I've been using for a while with my own LabVIEW-based register driver. I've noticed some interesting behavior after board reset (loses lock for 8 sec to 3.5 min), and after changing the mode (disrupts lock/phase bits for ~5 sec and freq bit between 4-60 min). Rev H of the user's guide has the schematics if anybody needs them. I did not see the full board. I was unable to use the off the shelf software, so I wrote my own but was not able to get full access to the board, it behaved as if the CPU side did not work or something. I can't recall seeing schematics, and if worse comes to worse I might need a copy of the EPROM. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
On 07/02/14 18:45, d0ct0r wrote: Great ! Super ! Thanks a LOT ! Also, Symmetricom shared the resource for the latest version of that driver [BCPCI-V830 build 120]. http://www.symmetricom.com/bus-level-timing-sdk-and-driver-downloads/ I tried that on Ubuntu 12.04.3 LTS x86_64, kernel 3.2.0-58-generic. And its works for me. To whom it may interested, previously I tried to use WinDriver I take directly from Xilinx site [basically Jungo's WinDriver v11.5.0] and Legacy version of BC635PCI driver [BCPCI-V700 build 111], and it was working perfectly fine too. On the same 64bit Linux machine. Thanks! I did not know there where modern drivers available! Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
Following my earlier post with download links for the Symmetricom software and documentation CD TVB was kind enough to send me this Symmetricom link.. http://www.symmetricom.com/bus-level-timing-sdk-and-driver-downloads/ I've verified that the two Windows archives there for the BC635/637 match what's in the CD ISO and have no reason to assume the rest won't match either, so this might be a more straightforward link to individual files. I've had a BC637PCI running continuously since yesterday and can confirm that both modules here seem to have a week 1024 rollover problem, via the Datum/Symmetricom demo software both are happily reporting dates in June 1994. I'm not sure yet whether the board takes the date from the GPS module or just the week number, so I'm not sure either if this is an issue with the Datum boards or with the Trimble Ace3 GPS modules, but I do have an earlier comment from Trimble that they were happy the Ace3 wouldn't have a problem after 1999 and I don't recall seeing this anyway when I last ran a BC637 a few years ago, nor with some more recent tests on other Ace3 modules. I'll run up an Ace3 standalone tomorrow but was just wondering if anyone else has seen this behaviour with the BC637? Regards Nigel GM8PZR In a message dated 07/02/2014 17:13:35 GMT Standard Time, gandal...@aol.com writes: Whilst sorting through my BC637PCI files earlier I realised for the first time that an ISO file I'd downloaded in 2010, described by Symmetricom as BC635/637 driver, is actually a full software and documentation CD, presumably what was then being supplied with new hardware. Ether that or I had been aware and it's something else that's slipped through the sieve:-) As well as the Windows SDK and more recent versions of the BC635 and BC637 demo software this file also contains later versions of the legacy demo software than I'd used previously, perhaps making most, if not all, of the earlier software obsolete, although the pre Symmetricom manuals, especially the one with the schematics, are certainly worth having. Now it's quite possible I'm the only one who wasn't aware of this, but in case it's not just me, and as I can't locate the original again to quote a URL, I've uploaded a file that contains this ISO, the extracted files from the same, plus my original collection of earlier software and documentation. This is quite a large file, approx 235MB, so for anyone who might only be interested in the earlier files I've also uploaded those as a smaller file of approx 52MB. BC637PCI_Full.rar 234.5 MB https://mega.co.nz/#!6dgVzBQI!A8y-qffQo4X5OYViTz97ZyiFn05zaPPfxCwoGLDu0Kg BC637PCI_Reduced.rar 50.2 MB https://mega.co.nz/#!iUQiwK7R!wyRPeBnkS4o1iADZGp7c-ZS6hHNbNqEEb8p1KKbr-ZU Any problems with the downloads or files please let me know and, as always, please feel free to upload elsewhere. Regards Nigel GM8PZR In a message dated 07/02/2014 03:36:46 GMT Standard Time, t...@patoka.org writes: Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
Le 7 févr. 2014 à 00:18, d0ct0r a écrit : Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? check the Symmetricom datasheets. You don't mention the version you are needing info for , IRIG/GPS.. Anyway, all that I glanced at show an Exr. 10MHz ref input on pin 1 of the sub-D 15 connector. Digital, 40% to 60% or sine, 0.5V to 8V p-p, 10kOhm. ex. http://www.symmetricom.com/resources/download-library/documents/datasheets/bc637pci-v2 -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
Magnus, What kind of problems did you have with it? I have a couple of BC635PCI boards that I've been using for a while with my own LabVIEW-based register driver. I've noticed some interesting behavior after board reset (loses lock for 8 sec to 3.5 min), and after changing the mode (disrupts lock/phase bits for ~5 sec and freq bit between 4-60 min). Rev H of the user's guide has the schematics if anybody needs them. -Bob On 02/06/2014 11:03 PM, Magnus Danielson wrote: The BC637PCI already have a VCXO onboard, but you add a OCXO on the outside to get much better results. It was the original poster that needed help. My problems with the BC637PCI was that one of my boards didn't respond completely as documented. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
I played with this around five or six years ago but unfortunately my notes from that time are likely to be buried somewhere still waiting to be scanned or indexed. All the necessary information though is in the user and SDK manuals, connections for the 10MHz external input and EFC output are on the 15 way I/O connector and there's even demo software which I'm pretty sure was all I used to make the necessary adjustments. One manual, pre Symmetricom, even has what looks to be a full set of schematics. I've just run the software again to check but it won't do much if it can't find the card so would need to fire up another PC with a spare slot to check further. I wasn't really happy at the time with my attempts to condition an external Vectron OCXO, it was certainly better than using the internal oscillator but there were some odd jumps and drifts using either which suggested these might be artifacts of the board itself rather than the Vectron OCXO. I've since acquired another BC637PCI, and want to try both again with other oscillators, but that's quite some way down a very long to do list, now reminded though I might take a quick look later:-) In the meantime, I have got copies of manuals and software etc and will get those zipped up today and make them available for download. Regards Nigel GM8PZR In a message dated 07/02/2014 03:36:46 GMT Standard Time, t...@patoka.org writes: Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
Whilst sorting through my BC637PCI files earlier I realised for the first time that an ISO file I'd downloaded in 2010, described by Symmetricom as BC635/637 driver, is actually a full software and documentation CD, presumably what was then being supplied with new hardware. Ether that or I had been aware and it's something else that's slipped through the sieve:-) As well as the Windows SDK and more recent versions of the BC635 and BC637 demo software this file also contains later versions of the legacy demo software than I'd used previously, perhaps making most, if not all, of the earlier software obsolete, although the pre Symmetricom manuals, especially the one with the schematics, are certainly worth having. Now it's quite possible I'm the only one who wasn't aware of this, but in case it's not just me, and as I can't locate the original again to quote a URL, I've uploaded a file that contains this ISO, the extracted files from the same, plus my original collection of earlier software and documentation. This is quite a large file, approx 235MB, so for anyone who might only be interested in the earlier files I've also uploaded those as a smaller file of approx 52MB. BC637PCI_Full.rar 234.5 MB https://mega.co.nz/#!6dgVzBQI!A8y-qffQo4X5OYViTz97ZyiFn05zaPPfxCwoGLDu0Kg BC637PCI_Reduced.rar 50.2 MB https://mega.co.nz/#!iUQiwK7R!wyRPeBnkS4o1iADZGp7c-ZS6hHNbNqEEb8p1KKbr-ZU Any problems with the downloads or files please let me know and, as always, please feel free to upload elsewhere. Regards Nigel GM8PZR In a message dated 07/02/2014 03:36:46 GMT Standard Time, t...@patoka.org writes: Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
It seems I have first generation of that card. And I was thinking to use that card as a source of 1PPS and 10MHZ - not to feed it from another reference. I though it is possible to do some modding to replace VCXO by OCXO. PCI Board Revision ID : 18 (0x12), Firmware Version : DT10041V11 On 2014-02-07 03:00, mike cook wrote: Le 7 févr. 2014 à 00:18, d0ct0r a écrit : Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? check the Symmetricom datasheets. You don't mention the version you are needing info for , IRIG/GPS.. Anyway, all that I glanced at show an Exr. 10MHz ref input on pin 1 of the sub-D 15 connector. Digital, 40% to 60% or sine, 0.5V to 8V p-p, 10kOhm. ex. http://www.symmetricom.com/resources/download-library/documents/datasheets/bc637pci-v2 -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
The information you need is more in the description of the software commands, this will tell you how to switch between the internal and external oscillators and how to vary the conditioning parameters and I'm pretty sure, although it's been a while so might be wrong, that some of the software contains menus to make this more straightforward. As long as what you have has already been configured as a BC637, ie existing firmware is aware that the GPS module is fitted, then there's no further change required to attach an external oscillator, as per above all the commands to do this are already available. In manual version K see page 6-4 and 6-15 for info on command 0x25, set disciplining gain. See page 3-6 section 3-5 on Hardware Menu option in the software keep on reading the manuals:-) Regards Nigel GM8PZR In a message dated 07/02/2014 18:06:55 GMT Standard Time, t...@patoka.org writes: Thanks everybody for the bit of information ! I have a Revsion C and Revision K manuals. In Revison K its only one note about OCXO: An internal 10 MHz VCXO (Voltage Controlled Crystal Oscillator) is disciplined to the reference source. The VCXO output drives all timing functions on the card. The VCXO output and a 1pps signal are provided as outputs. The TFP is also capable of disciplining an external voltage controlled oscillator. As an option, the TFP board can be ordered with an OCXO (Oven Controlled Crystal Oscillator) installed. As far as I understood, if I'll implement external OCXO to my BC637, I'll need to change FW on the card to make it work. If so, its not an option for me, since I just bought that card from auction and there is no way to obtain new microcode for it. Off-topic: Aside of that OCXO implementation, I would like to ask some direction from time-nuts community about the relatively simple way to compare two 1PPS signals using some MCU. Lets say I have T-Bolt and BC637. Each has 1PPS and I would like to see the phase difference between of that two. Of course it is some instruments already available for that, but I have not own that one (yet). I am thinking to connect both 1PPS to Timers input in capture mode on MCU. Then register first raising edge, start counting of ticks until second timer will not catch another signal raise. Then number of ticks will indicate the difference. But may be it is more elegant way to do that comparison ? Thanks ! Regards, V.P. On 2014-02-07 03:38, gandal...@aol.com wrote: I played with this around five or six years ago but unfortunately my notes from that time are likely to be buried somewhere still waiting to be scanned or indexed. All the necessary information though is in the user and SDK manuals, connections for the 10MHz external input and EFC output are on the 15 way I/O connector and there's even demo software which I'm pretty sure was all I used to make the necessary adjustments. One manual, pre Symmetricom, even has what looks to be a full set of schematics. I've just run the software again to check but it won't do much if it can't find the card so would need to fire up another PC with a spare slot to check further. I wasn't really happy at the time with my attempts to condition an external Vectron OCXO, it was certainly better than using the internal oscillator but there were some odd jumps and drifts using either which suggested these might be artifacts of the board itself rather than the Vectron OCXO. I've since acquired another BC637PCI, and want to try both again with other oscillators, but that's quite some way down a very long to do list, now reminded though I might take a quick look later:-) In the meantime, I have got copies of manuals and software etc and will get those zipped up today and make them available for download. Regards Nigel GM8PZR In a message dated 07/02/2014 03:36:46 GMT Standard Time, t...@patoka.org writes: Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@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@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@febo.com To unsubscribe, go to
Re: [time-nuts] BC637PCI and OCXO
My first card at least is a Datum card so quite old now, and that was fine doing what you want to do.. You really will need to read the manuals in some detail and I do suggest downloading the larger of the two files I uploaded, that will give you the latest versions of the Demo programs that allow adjustment of the card, as well as the earlier versions of the same and all the manuals For some things, with earlier versions anyway, it's better to use the BC635 version of the Demo software, as that comes with a built in help section which the BC637 version lacks. I'll try and get a card installed so I can run the software properly again and if so will come back with more information later. Regards Nigel GM8PZR In a message dated 07/02/2014 18:25:22 GMT Standard Time, t...@patoka.org writes: It seems I have first generation of that card. And I was thinking to use that card as a source of 1PPS and 10MHZ - not to feed it from another reference. I though it is possible to do some modding to replace VCXO by OCXO. PCI Board Revision ID : 18 (0x12), Firmware Version : DT10041V11 On 2014-02-07 03:00, mike cook wrote: Le 7 févr. 2014 à 00:18, d0ct0r a écrit : Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? check the Symmetricom datasheets. You don't mention the version you are needing info for , IRIG/GPS.. Anyway, all that I glanced at show an Exr. 10MHz ref input on pin 1 of the sub-D 15 connector. Digital, 40% to 60% or sine, 0.5V to 8V p-p, 10kOhm. ex. http://www.symmetricom.com/resources/download-library/documents/datasheets/bc637pci-v2 -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
Great ! Super ! Thanks a LOT ! Also, Symmetricom shared the resource for the latest version of that driver [BCPCI-V830 build 120]. http://www.symmetricom.com/bus-level-timing-sdk-and-driver-downloads/ I tried that on Ubuntu 12.04.3 LTS x86_64, kernel 3.2.0-58-generic. And its works for me. To whom it may interested, previously I tried to use WinDriver I take directly from Xilinx site [basically Jungo's WinDriver v11.5.0] and Legacy version of BC635PCI driver [BCPCI-V700 build 111], and it was working perfectly fine too. On the same 64bit Linux machine. Regards, V.P. On 2014-02-07 12:07, gandal...@aol.com wrote: Whilst sorting through my BC637PCI files earlier I realised for the first time that an ISO file I'd downloaded in 2010, described by Symmetricom as BC635/637 driver, is actually a full software and documentation CD, presumably what was then being supplied with new hardware. Ether that or I had been aware and it's something else that's slipped through the sieve:-) As well as the Windows SDK and more recent versions of the BC635 and BC637 demo software this file also contains later versions of the legacy demo software than I'd used previously, perhaps making most, if not all, of the earlier software obsolete, although the pre Symmetricom manuals, especially the one with the schematics, are certainly worth having. Now it's quite possible I'm the only one who wasn't aware of this, but in case it's not just me, and as I can't locate the original again to quote a URL, I've uploaded a file that contains this ISO, the extracted files from the same, plus my original collection of earlier software and documentation. This is quite a large file, approx 235MB, so for anyone who might only be interested in the earlier files I've also uploaded those as a smaller file of approx 52MB. BC637PCI_Full.rar 234.5 MB https://mega.co.nz/#!6dgVzBQI!A8y-qffQo4X5OYViTz97ZyiFn05zaPPfxCwoGLDu0Kg BC637PCI_Reduced.rar 50.2 MB https://mega.co.nz/#!iUQiwK7R!wyRPeBnkS4o1iADZGp7c-ZS6hHNbNqEEb8p1KKbr-ZU Any problems with the downloads or files please let me know and, as always, please feel free to upload elsewhere. Regards Nigel GM8PZR In a message dated 07/02/2014 03:36:46 GMT Standard Time, t...@patoka.org writes: Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
Now I have the plan. Thanks ! I'll try to connect external OCXO to that 15-pin connector, then using provided utility, I could switch to external oscillator. I think here is settings for externally connected source of 10Mhz: 12. Select Clock Source - 0. Internal 1. External Probably I'll need to do some adjustment using so-called Advanced settings: Advanced Menu: 1. Control Jam-Sync 2. Force Jam-Sync 3. Set Clock Value 4. Load D/A Converter 5. Set Disciplining Gain 6. Disconnect Battery to RTC Chip 0. Back to main menu Regards, V.P. On 2014-02-07 13:39, gandal...@aol.com wrote: My first card at least is a Datum card so quite old now, and that was fine doing what you want to do.. You really will need to read the manuals in some detail and I do suggest downloading the larger of the two files I uploaded, that will give you the latest versions of the Demo programs that allow adjustment of the card, as well as the earlier versions of the same and all the manuals For some things, with earlier versions anyway, it's better to use the BC635 version of the Demo software, as that comes with a built in help section which the BC637 version lacks. I'll try and get a card installed so I can run the software properly again and if so will come back with more information later. Regards Nigel GM8PZR In a message dated 07/02/2014 18:25:22 GMT Standard Time, t...@patoka.org writes: It seems I have first generation of that card. And I was thinking to use that card as a source of 1PPS and 10MHZ - not to feed it from another reference. I though it is possible to do some modding to replace VCXO by OCXO. PCI Board Revision ID : 18 (0x12), Firmware Version : DT10041V11 On 2014-02-07 03:00, mike cook wrote: Le 7 févr. 2014 à 00:18, d0ct0r a écrit : Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? check the Symmetricom datasheets. You don't mention the version you are needing info for , IRIG/GPS.. Anyway, all that I glanced at show an Exr. 10MHz ref input on pin 1 of the sub-D 15 connector. Digital, 40% to 60% or sine, 0.5V to 8V p-p, 10kOhm. ex. http://www.symmetricom.com/resources/download-library/documents/datasheets/bc637pci-v2 -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
Aside of that OCXO implementation, I would like to ask some direction from time-nuts community about the relatively simple way to compare two 1PPS signals using some MCU. Lets say I have T-Bolt and BC637. Each has 1PPS and I would like to see the phase difference between of that two. Of course it is some instruments already available for that, but I have not own that one (yet). I am thinking to connect both 1PPS to Timers input in capture mode on MCU. Then register first raising edge, start counting of ticks until second timer will not catch another signal raise. Then number of ticks will indicate the difference. But may be it is more elegant way to do that comparison ? Thanks ! Regards, V.P. Yes, that's very simple and works well, up to the period of the MCU clock driving the timer, e.g., a 200 MHz MCU gives you 5 ns resolution on the capture register. If you need under 5 or 10 ns, the next level is adding analog interpolation to the signal. There have been many discussions about this on the list. Search for Richard's PICTIC, for example. Depending on the complexity you want and the amount of calibration or re-calibration you employ, you can get down to hundreds or even tens of ps this way. Most of us just buy surplus time interval counters on eBay. You can get 1 or 2 ns counters for $50 to $200 on a good day. Or for casual time interval work, a two channel digital oscilloscope. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
Sounds like you cracked it, and beat me to it:-) I just dug out a PCI expansion chassis, the quickest option for now, and have one card up and running but have discovered, as a left over from my playing earlier, that installing the later software, what Symmetricom calls its BC635/637 configurator program, causes earlier versions of the software to fail at startup, even with the latest one uninstalled, so that's something to watch out for:-( The later stuff does seem to offer all the options of the earlier software though, and as you've no doubt discovered the oscillator parameters you mention are accessed through the BC635 software rather than the BC637 version. On the version I'm running at least, verion 10 of the configurator at the moment, there is a menu option to switch between internal and external oscillators on the Hardware menu in standard configuration and the other options as you say are available in advanced with the oscillator switching no longer showing. Interesting to see the rolling time displayed down to microseconds, although my eyes do struggle a bit to keep up with that, but rather a shame that for now I seem to be stuck in June 1994! I am getting the impression though that this particular software is expecting a later version of the card, this card is showing in Device Manager as a BC635/7PCI-eV2, which it certainly isn't, and the software is offering to adjust the DDS frequency for me, which would be nice but I don't remember it having DDS either. Time to have a software clearout methinks and to start over. Have fun:-) Nigel GM8PZR In a message dated 07/02/2014 19:12:34 GMT Standard Time, t...@patoka.org writes: Now I have the plan. Thanks ! I'll try to connect external OCXO to that 15-pin connector, then using provided utility, I could switch to external oscillator. I think here is settings for externally connected source of 10Mhz: 12. Select Clock Source - 0. Internal 1. External Probably I'll need to do some adjustment using so-called Advanced settings: Advanced Menu: 1. Control Jam-Sync 2. Force Jam-Sync 3. Set Clock Value 4. Load D/A Converter 5. Set Disciplining Gain 6. Disconnect Battery to RTC Chip 0. Back to main menu Regards, V.P. On 2014-02-07 13:39, gandal...@aol.com wrote: My first card at least is a Datum card so quite old now, and that was fine doing what you want to do.. You really will need to read the manuals in some detail and I do suggest downloading the larger of the two files I uploaded, that will give you the latest versions of the Demo programs that allow adjustment of the card, as well as the earlier versions of the same and all the manuals For some things, with earlier versions anyway, it's better to use the BC635 version of the Demo software, as that comes with a built in help section which the BC637 version lacks. I'll try and get a card installed so I can run the software properly again and if so will come back with more information later. Regards Nigel GM8PZR In a message dated 07/02/2014 18:25:22 GMT Standard Time, t...@patoka.org writes: It seems I have first generation of that card. And I was thinking to use that card as a source of 1PPS and 10MHZ - not to feed it from another reference. I though it is possible to do some modding to replace VCXO by OCXO. PCI Board Revision ID : 18 (0x12), Firmware Version : DT10041V11 On 2014-02-07 03:00, mike cook wrote: Le 7 févr. 2014 à 00:18, d0ct0r a écrit : Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? check the Symmetricom datasheets. You don't mention the version you are needing info for , IRIG/GPS.. Anyway, all that I glanced at show an Exr. 10MHz ref input on pin 1 of the sub-D 15 connector. Digital, 40% to 60% or sine, 0.5V to 8V p-p, 10kOhm. ex. http://www.symmetricom.com/resources/download-library/documents/datasheets/bc637pci-v2 -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow
Re: [time-nuts] BC637PCI and OCXO
Thanks everybody for the bit of information ! I have a Revsion C and Revision K manuals. In Revison K its only one note about OCXO: An internal 10 MHz VCXO (Voltage Controlled Crystal Oscillator) is disciplined to the reference source. The VCXO output drives all timing functions on the card. The VCXO output and a 1pps signal are provided as outputs. The TFP is also capable of disciplining an external voltage controlled oscillator. As an option, the TFP board can be ordered with an OCXO (Oven Controlled Crystal Oscillator) installed. As far as I understood, if I'll implement external OCXO to my BC637, I'll need to change FW on the card to make it work. If so, its not an option for me, since I just bought that card from auction and there is no way to obtain new microcode for it. Off-topic: Aside of that OCXO implementation, I would like to ask some direction from time-nuts community about the relatively simple way to compare two 1PPS signals using some MCU. Lets say I have T-Bolt and BC637. Each has 1PPS and I would like to see the phase difference between of that two. Of course it is some instruments already available for that, but I have not own that one (yet). I am thinking to connect both 1PPS to Timers input in capture mode on MCU. Then register first raising edge, start counting of ticks until second timer will not catch another signal raise. Then number of ticks will indicate the difference. But may be it is more elegant way to do that comparison ? Thanks ! Regards, V.P. On 2014-02-07 03:38, gandal...@aol.com wrote: I played with this around five or six years ago but unfortunately my notes from that time are likely to be buried somewhere still waiting to be scanned or indexed. All the necessary information though is in the user and SDK manuals, connections for the 10MHz external input and EFC output are on the 15 way I/O connector and there's even demo software which I'm pretty sure was all I used to make the necessary adjustments. One manual, pre Symmetricom, even has what looks to be a full set of schematics. I've just run the software again to check but it won't do much if it can't find the card so would need to fire up another PC with a spare slot to check further. I wasn't really happy at the time with my attempts to condition an external Vectron OCXO, it was certainly better than using the internal oscillator but there were some odd jumps and drifts using either which suggested these might be artifacts of the board itself rather than the Vectron OCXO. I've since acquired another BC637PCI, and want to try both again with other oscillators, but that's quite some way down a very long to do list, now reminded though I might take a quick look later:-) In the meantime, I have got copies of manuals and software etc and will get those zipped up today and make them available for download. Regards Nigel GM8PZR In a message dated 07/02/2014 03:36:46 GMT Standard Time, t...@patoka.org writes: Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
As far as I understood, in many modes (except GPS mode), we need to set date/time manually. Also, I found the link for the direct oscillator replacement part: http://www.mti-milliren.com/pdfs/210.pdf I think in the documentation, Symmitricom mentioned this particular model. Now I know how it looks like. But unfortunately its not straight process just to use my Hakko to exchange the crystals. Its required to change the microcode as well. So, that is not an option. The only way is to use external OCXO connected to pin 1 of the 15-pin connector. And I'll try it. Thank you all for all the information ! Regards, V.P. On 2014-02-07 14:55, gandal...@aol.com wrote: Sounds like you cracked it, and beat me to it:-) I just dug out a PCI expansion chassis, the quickest option for now, and have one card up and running but have discovered, as a left over from my playing earlier, that installing the later software, what Symmetricom calls its BC635/637 configurator program, causes earlier versions of the software to fail at startup, even with the latest one uninstalled, so that's something to watch out for:-( The later stuff does seem to offer all the options of the earlier software though, and as you've no doubt discovered the oscillator parameters you mention are accessed through the BC635 software rather than the BC637 version. On the version I'm running at least, verion 10 of the configurator at the moment, there is a menu option to switch between internal and external oscillators on the Hardware menu in standard configuration and the other options as you say are available in advanced with the oscillator switching no longer showing. Interesting to see the rolling time displayed down to microseconds, although my eyes do struggle a bit to keep up with that, but rather a shame that for now I seem to be stuck in June 1994! I am getting the impression though that this particular software is expecting a later version of the card, this card is showing in Device Manager as a BC635/7PCI-eV2, which it certainly isn't, and the software is offering to adjust the DDS frequency for me, which would be nice but I don't remember it having DDS either. Time to have a software clearout methinks and to start over. Have fun:-) Nigel GM8PZR In a message dated 07/02/2014 19:12:34 GMT Standard Time, t...@patoka.org writes: Now I have the plan. Thanks ! I'll try to connect external OCXO to that 15-pin connector, then using provided utility, I could switch to external oscillator. I think here is settings for externally connected source of 10Mhz: 12. Select Clock Source - 0. Internal 1. External Probably I'll need to do some adjustment using so-called Advanced settings: Advanced Menu: 1. Control Jam-Sync 2. Force Jam-Sync 3. Set Clock Value 4. Load D/A Converter 5. Set Disciplining Gain 6. Disconnect Battery to RTC Chip 0. Back to main menu Regards, V.P. On 2014-02-07 13:39, gandal...@aol.com wrote: My first card at least is a Datum card so quite old now, and that was fine doing what you want to do.. You really will need to read the manuals in some detail and I do suggest downloading the larger of the two files I uploaded, that will give you the latest versions of the Demo programs that allow adjustment of the card, as well as the earlier versions of the same and all the manuals For some things, with earlier versions anyway, it's better to use the BC635 version of the Demo software, as that comes with a built in help section which the BC637 version lacks. I'll try and get a card installed so I can run the software properly again and if so will come back with more information later. Regards Nigel GM8PZR In a message dated 07/02/2014 18:25:22 GMT Standard Time, t...@patoka.org writes: It seems I have first generation of that card. And I was thinking to use that card as a source of 1PPS and 10MHZ - not to feed it from another reference. I though it is possible to do some modding to replace VCXO by OCXO. PCI Board Revision ID : 18 (0x12), Firmware Version : DT10041V11 On 2014-02-07 03:00, mike cook wrote: Le 7 févr. 2014 à 00:18, d0ct0r a écrit : Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? check the Symmetricom datasheets. You don't mention the version you are needing info for , IRIG/GPS.. Anyway, all that I glanced at show an Exr. 10MHz ref input on pin 1 of the sub-D 15 connector. Digital, 40% to 60% or sine, 0.5V to 8V p-p, 10kOhm. ex. http://www.symmetricom.com/resources/download-library/documents/datasheets/bc637pci-v2 -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@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] BC637PCI and OCXO
Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
On 07/02/14 00:18, d0ct0r wrote: Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? As I recall it, it's fairly straigh-forward to output the EFC and input the clock frequency. I also recall that there is a API for changing the PI-filtering parameters. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
Hi Vlad, There was discussion about that board on the list some years ago. Google for: site:febo.com BC637PCI See, for example, http://www.febo.com/pipermail/time-nuts/2008-October/033730.html /tvb - Original Message - From: d0ct0r t...@patoka.org To: time-nuts@febo.com Sent: Thursday, February 06, 2014 3:18 PM Subject: [time-nuts] BC637PCI and OCXO Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
Hi Magnus, I could help you with that, I also looking for a GPS module which has a 10kHz output, To lock to the 1pps is a bit complicated, one would need a crystal oscillator with very good short-time stability, with a 10kHz is just an analog PLL, for what would you use the output -- what frequency do you need? Regards Alex 73 KJ6UHN On 2/6/2014 8:05 PM, Magnus Danielson wrote: On 07/02/14 00:18, d0ct0r wrote: Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? As I recall it, it's fairly straigh-forward to output the EFC and input the clock frequency. I also recall that there is a API for changing the PI-filtering parameters. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI and OCXO
The BC637PCI already have a VCXO onboard, but you add a OCXO on the outside to get much better results. It was the original poster that needed help. My problems with the BC637PCI was that one of my boards didn't respond completely as documented. Cheers, Magnus On 07/02/14 05:37, Alex Pummer wrote: Hi Magnus, I could help you with that, I also looking for a GPS module which has a 10kHz output, To lock to the 1pps is a bit complicated, one would need a crystal oscillator with very good short-time stability, with a 10kHz is just an analog PLL, for what would you use the output -- what frequency do you need? Regards Alex 73 KJ6UHN On 2/6/2014 8:05 PM, Magnus Danielson wrote: On 07/02/14 00:18, d0ct0r wrote: Hello, Does anybody seen any links to the information how to implement external OCXO to Symmetricom PCI TFP BC635/BC637 ? As I recall it, it's fairly straigh-forward to output the EFC and input the clock frequency. I also recall that there is a API for changing the PI-filtering parameters. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI
In a message dated 11/10/2008 05:12:11 GMT Daylight Time, [EMAIL PROTECTED] writes: Has anyone upgraded the oscillator on an older Datum BC637PCI card to the MTI crystal? Is it as simple as changing the crystal and adjusting the osc gain? - Hi Scott I've not changed the oscillator, but I did look into the possibility and also ran a BC637PCI for a while with an external Vectron ovened 10MHz oscillator. I assume you have the BC637PCI manual? Appendix A refers to field upgrades, both converting a 635 to 637 by adding the GPS module and upgrading to the ovened oscillator. In both instances a firmware upgrade was activated by entering a device specific password provided by Datum/Symmetricom. I doubt that option is still longer available even though the necessary firmware changes are obviously already there waiting to be activated. I suspect, in the case of the oscillator upgrade anyway, some default settings including oscillator gain will be all that's changed. When running with an external oscillator I found that loss of power would default any settings I had changed so no doubt that's what would happen if you upgraded the oscillator without the firmware change. Page 6-15, in the rev K manual anyway, gives details of the oscillator gain adjustment, I found approx 70 seemed reasonable with my Vectron oscillator but my BC637PCI, and perhaps others, has some conditioning issues anyway. The basic onboard oscillator was not very good, apologies for such an imprecise statement but I can't find the fairly extensive notes made several months ago, both accuracy and stability were relatively poor measured on an HP53132A using a known good Thunderbolt as a reference. In particular I noticed quite frequent, but seemingly random, jumps in output frequency that would then take a little while to recover, a bit like a fast acting automatic gain control with slow recovery time. These jumps were significantly greater than the normal variations I observed and fell outside of the unit specification. Using the Vectron oscillator greatly improved things, it was a much better oscillator anyway and I was able to observe the significant improvement in the Vectron performance when being conditioned by the BC637PCI. However, the frequency jumps still occured albeit with overall performance much improved and frequency stability much better and the jumps less than before, ie frequency jumps were seemingly reduced in proportion to the better accuracy. Without the jumps I would have been happy with the Vectron performance but didn't feel able to trust the combination without permanent computer monitoring, and still don't know if this was a function of my BC637PCI or something common to all of them. It was interesting to play with, and I'll probably go back to it at some time, but I was more concerned then to set up something I could rely on and eventually put it to one side. Whilst working with the BC637PCI I did find that I needed both the BC635PCI and BC637PCI software, both offer options the other lacks, and I have late copies of both if you need them. I also have two manuals, version H from Datum that includes schematics, and the fairly similar version K from Symmetricom but without schematics. regards Nigel GM8PZR ** ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI
In a message dated 11/10/2008 05:12:11 GMT Daylight Time, [EMAIL PROTECTED] writes: Has anyone upgraded the oscillator on an older Datum BC637PCI card to the MTI crystal? Is it as simple as changing the crystal and adjusting the osc gain? - PS Should have added to my previous waffle, I think the answer to this is yes:-) given the need to reset any changed values every time you power down and up again. regards Nigel GM8PZR ** ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] BC637PCI
Nigel, thanks for the detailed response. I noticed the password option in the advanced menu as well. I ran it overnight locked to a 1-PPS feed and it seemed to stay witin +-200ns. Not spectacular, but within spec according to the older datasheets. I am mainly interested in the card as a timecode generator. However it looks like it might be more convenient to just feed the card an external 10mhz and not use the internal oscillator. Also, the RTC battery is toast, so it looks like I'll be replacing that at some point. Scott [EMAIL PROTECTED] wrote: In a message dated 11/10/2008 05:12:11 GMT Daylight Time, [EMAIL PROTECTED] writes: Has anyone upgraded the oscillator on an older Datum BC637PCI card to the MTI crystal? Is it as simple as changing the crystal and adjusting the osc gain? - PS Should have added to my previous waffle, I think the answer to this is yes:-) given the need to reset any changed values every time you power down and up again. regards Nigel GM8PZR ** ___ time-nuts mailing list -- time-nuts@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
