Re: [time-nuts] Lucent KS-24361/Thunderbolt antenna advice sought.
I am using hp58516a distribution amplifier. Trimble active antenna, Trimble TB and BC637PCI constantly connected to that unit. And time to time I connecting some DUT and GPS modules to it. It works for me. Regards, V.P. On 2015-05-04 08:18, Oghma wrote: Hi, all I've only recently joined time-nuts, having recently become interested in having a stable, accurate frequency reference available - mainly for amateur radio applications in the 1-24GHz region. Anyway, I have a Trimble Thunderbolt GPSDO, and a Lucent KS-24361 (REF 0 REF 1 units), and would like to have them both connected to the same antenna. I know that the KS-24361 puts out a dc feed on the TNC to power an active antenna, but am not sure whether the Thunderbolt does the same... So, can anyone who knows a little more about these two units recommend an antenna that will be suitable for both? Sorry if this is too basic a question for this list - I have had a look though a lot of the archive, but I can't seem to find the answer, and there doesn't appear to be a decent search facility :( Many thanks, in advance for any advice/ recommendations John Sent tomorrow, from my time machine. ___ 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] DDS, OCXO and ADEV
The counter is in TIME MODE. And simple calculation could transform it to frequency as necessary. For example: 1/(350.50824*10^-9) 2852999.97512184021693755330 OR 1/0.00350508240900 2852999.96779619226350692058 Which is pretty close to my DDS VFO freq. value [2853000] I switch counter to TIME MODE, because ADEV1 utility using times, not frequency: Here is from documentation: Adev1 works on everything from pendulum clocks to hydrogen masers. The only restrictions are that the data must be phase (time interval) rather than frequency; the data must be sequential (no gaps); and the data should be free from glitches or outliers. I am using 10 second intervals for the measurement. DDS VFO clocked by Trimble TB and its using AD9852 chip. Regards, V.P. On 2015-05-03 10:01, Bob Camp wrote: Hi Either the output data is with the counter set to time mode (and it’s in 100’s of ns) or you have it set to frequency mode and have a very stable system. Bob On May 2, 2015, at 9:53 PM, d0ct0r t...@patoka.org wrote: Hello, I would like to create some charts for ADEV for following setup: HP5386A counter connected to External REF. (OCXO). The input of counter connected to my DDS VFO. The frequency on VFO is 2853000 Hz. Here is what I got from counter via GPIB: S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082409E-7 S +3.505082408E-7 S +3.505082409E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 I converted it to following form: 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240800 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 Then I tried to use ADEV by tvb (long life to Tom!). See attached file 1b.bmp And I tried to create the charts for the collected data. See attached file 1a.bmp. But it seems I am doing something wrong. Any advises will be greatly appreciated. Thanks ! -- WBW, V.P.1a.png1b.png___ 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] DDS, OCXO and ADEV
Hello, I would like to create some charts for ADEV for following setup: HP5386A counter connected to External REF. (OCXO). The input of counter connected to my DDS VFO. The frequency on VFO is 2853000 Hz. Here is what I got from counter via GPIB: S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082409E-7 S +3.505082408E-7 S +3.505082409E-7 S +3.505082408E-7 S +3.505082408E-7 S +3.505082408E-7 I converted it to following form: 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240800 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 0.00350508240900 Then I tried to use ADEV by tvb (long life to Tom!). See attached file 1b.bmp And I tried to create the charts for the collected data. See attached file 1a.bmp. But it seems I am doing something wrong. Any advises will be greatly appreciated. Thanks ! -- 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] Once again about counter calibration
I tried to use 1PPS as Ext. trigger for the oscilloscope. I was able to stabilize signal movement. Then I tried to calibrate OCXO. However its appeared out of range (I reach end of potentiometer limit but counter still shows that OCXO is out of 10Mhz). Which kind of suspicious. Then I decide to disassemble my project to take pure 10Mhz directly from GPSDO to measure OCXO signal. Its read totally different frequency value now. So, using 1PPS didn't work for me. I tried using that GPSDO 10 Mhz as Ext. Trigger. And now I got much better result. I was able to calibrate 5386A to some extent. But my 5386 has TCXO. So, after few minutes its moving out of perfect value. May be I need to wait much longer to stabilize oscillator. I am not sure what to expect here. Using GPSDO 10 Mhz as REF signal, I was able to calibrate OCXO. And now its potentiometer position was nether at its both extremes. The reading on 5386a (using 10 sec gate) fluctuate from 9.3M to 10.7M. Again, may be I need to wait much longer when OCXO will be stable. So, I think the best approach will be using 10Mhz GPSDO as ref. signal for this counter. In another case, I'll need to wait to warm it up (the manual advised only 30 minutes. But I am not sure). And then re-calibrate it. Its time consuming. I am curious, if its practical to calibrate something like Morion MV89A and use it as signal reference for this counter ? Or OCXO still will drift out of desired frequency relatively soon ? Regards, V.P. On , Scott McGrath wrote: Or feed both oscillators into a mixer and extract the difference which will be the offset of your DUT from your standard Content by Scott Typos by Siri On Apr 24, 2015, at 10:36 PM, Brent Gordon time-n...@adobe-labs.com wrote: Just feed the PPS into the scope trigger on step 2. The low repetition rate on the PPS would make this difficult on an analog scope; on a digital scope it is easy. You can use any sub-harmonic that is less than or equal the counter reference frequency (10 MHz). Brent On 4/24/2015 3:45 PM, d0ct0r wrote: Hello, The input: HP 5386A which I would like to calibrate, Well warmed Tremble Thunderbolt (1PPS only), 10 Mhz Datum OCXO (unknown accuracy), Rigol 1101E Oscilloscope. The goal is to calibrate counter to read the Datum OCXO. === Reading the manual for 5386A, there is simple schema for calibration: 1. Connect HP 5386A 10Mhz OUTPUT to Oscilloscope 2. Connect Frequency Standard to Ext. Trigger on Oscilloscope 3. Adjust the frequency on 5386A TCXO for minimum sideways movement of 10 Mhz signal However, my Trimble TB 10Mhz output is currently in use. I have only 1PPS signal available. The HP manual do not mention what exactly frequency needs to be on Frequency Standard connected to Ext. Trigger. Is there any method/option I could apply to calibrate HP counter ? Thanks ! ___ 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] Once again about counter calibration
Hello, The input: HP 5386A which I would like to calibrate, Well warmed Tremble Thunderbolt (1PPS only), 10 Mhz Datum OCXO (unknown accuracy), Rigol 1101E Oscilloscope. The goal is to calibrate counter to read the Datum OCXO. === Reading the manual for 5386A, there is simple schema for calibration: 1. Connect HP 5386A 10Mhz OUTPUT to Oscilloscope 2. Connect Frequency Standard to Ext. Trigger on Oscilloscope 3. Adjust the frequency on 5386A TCXO for minimum sideways movement of 10 Mhz signal However, my Trimble TB 10Mhz output is currently in use. I have only 1PPS signal available. The HP manual do not mention what exactly frequency needs to be on Frequency Standard connected to Ext. Trigger. Is there any method/option I could apply to calibrate HP counter ? Thanks ! -- 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] Once again about counter calibration
Currently, 10 Mhz output connected to Linear LTC6957-3 to feed DDS and MCU for another purpose. Of course I am able to reconfigure (physically disconnect) it. But I am just curious if its an option to use only 1PPS for calibration. Regards, V.P. On , Bob Albert wrote: Why not use a T connector to patch the 10 MHz to two places at once? Bob On Friday, April 24, 2015 5:06 PM, d0ct0r t...@patoka.org wrote: Hello, The input: HP 5386A which I would like to calibrate, Well warmed Tremble Thunderbolt (1PPS only), 10 Mhz Datum OCXO (unknown accuracy), Rigol 1101E Oscilloscope. The goal is to calibrate counter to read the Datum OCXO. === Reading the manual for 5386A, there is simple schema for calibration: 1. Connect HP 5386A 10Mhz OUTPUT to Oscilloscope 2. Connect Frequency Standard to Ext. Trigger on Oscilloscope 3. Adjust the frequency on 5386A TCXO for minimum sideways movement of 10 Mhz signal However, my Trimble TB 10Mhz output is currently in use. I have only 1PPS signal available. The HP manual do not mention what exactly frequency needs to be on Frequency Standard connected to Ext. Trigger. Is there any method/option I could apply to calibrate HP counter ? Thanks ! -- 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 [1] and follow the instructions there. Links: -- [1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts -- 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] Once again about counter calibration
Following my request, I am curious about modding of HP 5386A. My unit has TCXO. Is it possible to replace that existed TCXO by third part OCXO ? Like Morion MV89A, for example ? -- 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] Visual clock comparison
Hello, Netizens ! I am wandering what is the average human ability to visually compare two clocks ? Let say I have XClock application running on one machine (stratum 1 NTP) and I have my project clock close by. And I would like to match the reading. If I'll see the difference, which range it will be ? 100ms or so ? I also tried to use my ears (CHU radio signals and clock display, NRC phone line). However NRC Talking Clock could be routed via Satelite which will compromise the reading a little bit. Thanks ! -- 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] Trimble Thunderbolt question, splitting its output.
In my project, I was using LT6957 to share 10Mhz from my TBolt. It was perfectly fine for my setup. I split 10Mhz to feed the clock of MCU and second output was connected to DDS block (AD 9852). Regards, Vlad On , Chris Wilson wrote: 27/03/2015 17:14 My T/Thunderbolt has operated flawlessly for some years feeding a David Partridge frequency divider board. The board gives 10Mhz and lower divisions of 10MHz down to the KHz level out, as square waves. What I need to know is, can I T off the T/Thunderbolt 10MHz feed to this board and take a second sine wave output direct from the Thunderbolt, to drive a transceiver GPS disciplined 10 MHz frequency standard input as well as having it feed the divider baord, which has a square wave output? Thanks. The .pdf for David's board is at: http://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=4ved=0CDMQFjADurl=http%3A%2F%2Fwww.perdrix.co.uk%2FFrequencyDivider%2FFrequency%2520Divider%25202.1.pdfei=g5AVVbDXGcSy7QbLioCAAQusg=AFQjCNHiXeXt-NZksvMBKYHfkJPf5mn_Fwsig2=kXB0iLgZhoDuB8shplLFqAbvm=bv.89381419,d.ZGU? -- 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] DDS on AD9852
Hello, That Q1 is MAV1-0104 made by Mini-Circuits. This part is exact replacement for the MSA-0104, which was in TenTec kits early. The schematic of that pre-amp is pretty simple: +12 V | [ ] (470 Ohm) | L1 (100uH) | 50ohm input ---||-- Q1 -||-50 Ohm output 0.01 0.01 You are overdriving the amplifier. What is the part number of Q1? It looks like a MAR-xx something. The Tentek page does not have any good technical details on the amp that I could find. What info do you have? Regards -- 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] June 30 2015 leap second
Today, I did the check the settings for my BC637 card. I was surprised that its overwrite my manual setting for the Leap Event by following information: Time Settings: Mode : GPS Time Format: Binary Year : 1995 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 876614400 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable Sun, 12 Oct 1997 00:00:00 GMT. Its weird. I am going to re-insert it and will check it again later. New Time Settings are: Mode : GPS Time Format: Binary Year : 2015 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 1435708799 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable Also, my NTP, which rely on that card, didn't get the value for leap second event yet: # ntpq -c rv associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, version=ntpd 4.2.6p5@1.2349 Mon Sep 22 20:41:39 UTC 2014 (14), processor=x86_64, system=Linux/3.2.0-74-generic, leap=00, stratum=1, precision=-23, rootdelay=0.000, rootdisp=8248.907, refid=BTFP, reftime=d85e7526.957a1b17 Mon, Jan 12 2015 11:30:30.583, clock=d85ec544.e1effe31 Mon, Jan 12 2015 17:12:20.882, peer=0, tc=4, mintc=3, offset=3.757, frequency=-243.698, sys_jitter=0.000, clk_jitter=1.328, clk_wander=15.616 Regards, Vlad It's fragile enough that there have been accidental false leap-second events. Yes, for example if there have been GPS receivers which decoded the UTC parameters incorrectly, and started to announce a leap second when there wasn't one (end of September). That's why, for example, ntpd's leap second handling code has been changed in v4.2.6 to accept a leap second warning only if the warning is received from a majority of the configured servers. If you want to be sure you can also provide ntpd with a leap second file which is then (in current versions) considered as authentic source for leap second information. Martin ___ 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] June 30 2015 leap second
Reading about leap seconds for the past two days, I found that common solution for it - just encode leap second event proactively and wait for it. Of course that possible only if device has that option. For example, BC637PCI has a menu item 7. Program Leap Event Seconds. Which I did. Now, if I do the request for time settings, its shows me following: Time Settings: Mode : GPS Time Format: Binary Year : 2015 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 1435708799 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable Scheduled Leap Event Time - is so-called UNIX time. However, I am not sure where its take number 16 (Current Leap Seconds). Its definitely was not programmed there by me. Concerning of my clock project, I am thinking about best approach how to set up leap second procedure. I mean which time exactly I'll need to do correction for my clock (set time on RTC module). There is two options, I think. One: to reset RTC at July 1, 00:00:00 and set it back to June 30, 23:59:00. Or, at July 1, 00:00:01, set RTC back to July 1 00:00:00 and then at July 1 00:00:01 reset RTC with occurrance of raising edge of 1PPS. I would prefer to play with July 1, because in this case I don't need to do much calculations to transfer RTC time to number of seconds, decrement it by 1 second, transfer it back to BCD format and write it back to RTC. Instead, I'll need just read/write RTC register which keeps number of seconds inside. Regards, Vlad Just because you observe one tz update from Debian does not imply that all Linux systems on planet earth (or in space) magically know about leap seconds. There must be millions (billions?) of embedded or isolated systems -- from web servers to desktops to military systems to gadgets to Raspberry Pi's to mobile phones, that have not, and will not ever receive this update. -- 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] June 30 2015 leap second
This is an issue indeed. Here is what I get from MySQL Data Base support site: Before MySQL 5.0.74, if the operating system is configured to return leap seconds from OS time calls or if the MySQL server uses a time zone definition that has leap seconds, functions such as NOW() could return a value having a time part that ends with :59:60 or :59:61. If such values are inserted into a table, they would be dumped as is by mysqldump but considered invalid when reloaded, leading to backup/restore problems. As of MySQL 5.0.74, leap second values are returned with a time part that ends with :59:59. This means that a function such as NOW() can return the same value for two or three consecutive seconds during the leap second. It remains true that literal temporal values having a time part that ends with :59:60 or :59:61 are considered invalid. Last time it was quite a pain: Machines running the mighty Amadeus Altea system were brought down soon after an extra second was added to Coordinated Universal Time (UTC) at midnight on Saturday, 30 June. The bonus second was inserted at the direction of time boffins to keep UTC synchronised with Earth's slowing rotation. The Altea system was taken offline for an hour, and staff at Qantas and Virgin Australia had to check in passengers manually, disrupting flight plans. Google's solution looks pretty amazing. The slowing down the clock by milliseconds as the event approach. May be that an option to play with Oscillator Aging register. In accordance with data sheet, the Aging Offset register takes a user-provided value to add to or subtract from the factory-trimmed value that adjusts the accuracy of the time base. The Aging Offset code is encoded in two’s complement, with bit 7 representing the SIGN bit and a valid range of ±127. One LSB typically represents a 0.12ppm change in frequency. The change in ppm per LSB is the same over the operating temperature range. Positive offsets slow the time base and negative offsets quicken the time base. So, using that I could achieve 127x0.12 = 15ppm change. 1s/24h = 1/86400 which is approximately 12ppm. That means that Aging Offset could slow down my clock for 1 second if I'll apply the maximum value one day ahead (roughly). I need to do some experiments first. ;-) Its looks too unreliable for me. On , Martin Burnicki wrote: Gregory Maxwell wrote: On Fri, Jan 9, 2015 at 3:21 PM, Martin Burnicki martin.burni...@burnicki.net wrote: Systems which are simply time clients can receive the leap second warning via the usual protocols like NTP or PTP/IEEE1588. Indeed, they can. Even when there hasn't been a leap-second. Practically all internet (and otherwise?) time distribution is unauthenticated, the leap second itself is unauthenticated. ... and even the time you get via NTP or PTP is usually not authenticated. So you can trust the time and leap second warning, or you shouldn't trust either. It's fragile enough that there have been accidental false leap-second events. Yes, for example if there have been GPS receivers which decoded the UTC parameters incorrectly, and started to announce a leap second when there wasn't one (end of September). That's why, for example, ntpd's leap second handling code has been changed in v4.2.6 to accept a leap second warning only if the warning is received from a majority of the configured servers. If you want to be sure you can also provide ntpd with a leap second file which is then (in current versions) considered as authentic source for leap second information. Martin ___ 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] June 30 2015 leap second
Tom, Thanks for the comments ! In my design I am using NMEA as an option to set initial time on the clock. Its just faster and more convenient than doing it manually. And in the other (rare) occasions when clock logic could decide to sync. RTC module time with time received from GPS module. Basically I decide not to relay on GPS NMEA too much. My clock using 1PPS signal coming from internal GPS module or from external source connected to the device. That 1PPS and 32kHz signal from RTC module, connected to the MCU timers. So, I know for sure if RTC module generate its 32k signal slower/faster than it should be. If the difference between of those two signals become too big, clock will do autocorrection for the RTC oscillator to trim the value for Aging Register. RTC module has accuracy 2ppm. I think it suppose to keep the time well. Initially I was thinking that GPS will receive hh:59:60 NMEA message and I could use it as it is. But now I think I'll add some more code to handle such wonderful thing as a leap second event. I am going to create subroutines which will allow me to enter and keep leaps second event in battery backed SRAM and apply it as that even occurred. Unfortunately it will need the human interaction to set up leap second events. But if I'll leave the clock logic as it is now, I'll need to correct time on the clock any way. Since 1PPS just keep RTC oscillator in tact. But time on the clock will be 1 second ahead. -- 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] June 30 2015 leap second
Tim, I was using perl as a tool to calculate UNIX time. As my project based on STM32 MCU, I have no option to use time libraries. And I dont' think its applcable for my project. I am thinking what exactly of that UNIX time is. Looks like its using simple constants, like we have 86400 seconds per day, we have 365/366 days per year. And we have certain leap years with strict rule to identify it. For the clock to use on a desk, its should be sufficient to avoid confusion with rest of the world. ;-) In the other words, looking to current UNIX time we could identify the current date/time as most people see it. But its give us zero info about actual number of seconds passed since Thursday, 1 January 1970, 00:00:00. Regards, V.P. V.P., since you mention Perl and leap seconds, I'd like to point out that there's a very useful Perl library for computing delta times around leapsecond jumps: http://search.cpan.org/~drolsky/DateTime-1.12/lib/DateTime/LeapSecond.pm [6] This particular library is useful if you need to know the correct delta time between UTC timestamps but have chosen to ignore the ambiguity problem of correctly marking the leapsecond itself. ___ 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] June 30 2015 leap second
Hello,
As I am in the process of creation of my own Nixie clocks. And it
probably good time frame to clarify one thing about leap seconds. In my
project I am using GPS module as an option to have current UTC time and
also to have 1PPS signal to do auto-adjustment for external RTC module.
The question is how usually GPS modules handle leap seconds ? Is it
satelates who send UTC time to GPS module or GPS module has firmware
with leap second information hard-coded ?
The same question is for UNIX epoch time. How computers knows if it is
necessary to add leap seconds ? Lets say I am using very simple script
to calculate UNIX time for specified date:
#!/usr/bin/perl
use Time::Local;
my ($d, $m, $y);
my $time;
@myYears = ('01/06/2000', '01/06/2015', '01/06/2038', '01/06/3000');
foreach (@myYears) {
($d, $m, $y) = split '/', $_;
$time = timelocal(0,0,0,$d,$m-1,$y);
printf %ld\n\r, $time;
}
==
It will produce the following output:
959832000
1433131200
2158977600
32516740800
I am not sure if its take leap second consideration. Most likely not.
And that means its only accurate for the present and pas time. Right ?
For my clock I already implement the function for the leap second and I
am able to add/remove number of seconds from the time I receiving from
GPS or any other source. But it will be more inetersting if clock could
do it automagically and shows me that famous 60 number without human
interaction. Any advise for this ? Thanks !
Regards,
V.P.
On , Tom Van Baak wrote:
Just announced: there will be a positive leap second at the end of
June 30 2015 UTC (that's Wednesday July 1st for most of the world).
As usual we time nuts will have a leap second party -- where we
capture and share the magic hh:59:60 display on as many different
clocks and instruments as possible.
/tvb
More info:
ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
http://hpiers.obspm.fr/eop-pc/
And for those of you who want to know how long each day really is:
ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.dat
___
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] CMOS level difference for LTC6957-3 and AD9852
To whom it may concern, here is the note regarding of CMOS level difference for two product AD9852 from AD and LT6957 from Linear. My attempts to feed AD9852 directly from LTC6857-3 has failed. AD9852 just ignored the REFCLOCK signal coming from LTC6957-3. So, I'll need to think about some solution how to match the levels and do not impact the source signal too much. (Received from tech. department of AD): ... the logic levels for the AD9852 and LTC6957 don't line up. From page 5 of the AD9852 datasheet, VIH minimum is 2.3V whereas the LTC6957 says it's VOH could be as low as 2.08V. This means the LTC6957 could output 2.08V for a logic high, but our part won't recognize it as it needs at least 2.3V to be a logic high. It's the same problem for low logic voltages. The AD9852 datasheet says VIL max is 1V whereas the LTC6957 says it's VOL max is 1.63V or 1.67V depending on the temperature range of your part. So the LTC6957 could output 1.63V for a logic low, but our part won't recognize it as it needs a voltage below 1V to be a logic low. = --- 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] CMOS level difference for LTC6957-3 and AD9852
AD was comparing apples and oranges. The LTC6957-3 has CMOS outputs, which go from 0.2V to Vdd-0.3V (with a 3mA load). Perhaps they were looking at the LTC6957-1 which is LVPECL and would have a rather small swing. The LTC6957-3 should drive the AD9852 if its requirements are as noted below. That was my first impression. However its not working for some reason. AD9832 do not oscillate. Normally, as REFCLOCK is presented on its input (pin69), it should start to generate IO UPDATE signal by default. Its not happens in my case. But if I apply another source (the direct output from OCXO) to the same pin AD9852, its accept that. The chip to heat up and generate IO UPDATE. On the AD9852 evaluation board, AD is using MC100LVEL16 as a level converter. I would like to try that and see how it will be. From: d0ct0r t...@patoka.org To: time-nuts@febo.com Sent: Friday, April 25, 2014 1:33 PM Subject: [time-nuts] CMOS level difference for LTC6957-3 and AD9852 To whom it may concern, here is the note regarding of CMOS level difference for two product AD9852 from AD and LT6957 from Linear. My attempts to feed AD9852 directly from LTC6857-3 has failed. AD9852 just ignored the REFCLOCK signal coming from LTC6957-3. So, I'll need to think about some solution how to match the levels and do not impact the source signal too much. (Received from tech. department of AD): ... the logic levels for the AD9852 and LTC6957 don't line up. From page 5 of the AD9852 datasheet, VIH minimum is 2.3V whereas the LTC6957 says it's VOH could be as low as 2.08V. This means the LTC6957 could output 2.08V for a logic high, but our part won't recognize it as it needs at least 2.3V to be a logic high. It's the same problem for low logic voltages. The AD9852 datasheet says VIL max is 1V whereas the LTC6957 says it's VOL max is 1.63V or 1.67V depending on the temperature range of your part. So the LTC6957 could output 1.63V for a logic low, but our part won't recognize it as it needs a voltage below 1V to be a logic low. = --- 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] CMOS level difference for LTC6957-3 and AD9852
Just to confirm: MC100LVEL16 solved the issue with signal levels. On 2014-04-25 14:54, d0ct0r wrote: AD was comparing apples and oranges. The LTC6957-3 has CMOS outputs, which go from 0.2V to Vdd-0.3V (with a 3mA load). Perhaps they were looking at the LTC6957-1 which is LVPECL and would have a rather small swing. The LTC6957-3 should drive the AD9852 if its requirements are as noted below. That was my first impression. However its not working for some reason. AD9832 do not oscillate. Normally, as REFCLOCK is presented on its input (pin69), it should start to generate IO UPDATE signal by default. Its not happens in my case. But if I apply another source (the direct output from OCXO) to the same pin AD9852, its accept that. The chip to heat up and generate IO UPDATE. On the AD9852 evaluation board, AD is using MC100LVEL16 as a level converter. I would like to try that and see how it will be. From: d0ct0r t...@patoka.org To: time-nuts@febo.com Sent: Friday, April 25, 2014 1:33 PM Subject: [time-nuts] CMOS level difference for LTC6957-3 and AD9852 To whom it may concern, here is the note regarding of CMOS level difference for two product AD9852 from AD and LT6957 from Linear. My attempts to feed AD9852 directly from LTC6857-3 has failed. AD9852 just ignored the REFCLOCK signal coming from LTC6957-3. So, I'll need to think about some solution how to match the levels and do not impact the source signal too much. (Received from tech. department of AD): ... the logic levels for the AD9852 and LTC6957 don't line up. From page 5 of the AD9852 datasheet, VIH minimum is 2.3V whereas the LTC6957 says it's VOH could be as low as 2.08V. This means the LTC6957 could output 2.08V for a logic high, but our part won't recognize it as it needs at least 2.3V to be a logic high. It's the same problem for low logic voltages. The AD9852 datasheet says VIL max is 1V whereas the LTC6957 says it's VOL max is 1.63V or 1.67V depending on the temperature range of your part. So the LTC6957 could output 1.63V for a logic low, but our part won't recognize it as it needs a voltage below 1V to be a logic low. = --- 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] First success with very simple, very low cost GPSDO, under $8
Actually GCC supporting Cortex. So, I am using Raisonance IDE plus GCC Toolchain as a development environment. My current project functional diagram is following: +--- STM32 -- (Pulse Counter, TTL Generator, DDS driver, GPSDO monitor) GPSDO--LTC6957-3--| || | +--- AD9852 -- VFO - | | v +--- TADD3 -- (1PPS, TTL) -- As I'll finish it more or less, I'd like to compare the 1PPS which comes directly from GPSDO with 1PPS which I could create on MCU (and probably on DDS). As I mention before, each STM MCU comes with very useful Peripheral Library. That Library has tonnes of different examples. Regards, V.P. On 2014-04-21 16:29, paul swed wrote: Good afternoon very interested in the work you are doing with the STM board. As I mentioned far earlier in this thread I am attempting to use it to correct the BPSK WWVB signal here. Initial thoughts were using FORTH to program the STM board. Very curious what you are using as examples. My experience in FORTH is from many years ago and have done very poorly at C. But this may be the case to have something of interest to actually do. In either language. Regards Paul WB8TSL On Mon, Apr 14, 2014 at 12:27 PM, d0ct0r t...@patoka.org wrote: I was experimenting with the same setup for STM32 MCU. This microprocessor has accept the sine wave from external OCXO or GPSDO. No problem with this. The only thing: I was need to start MCU from slow watch crystal first. And then switch it to work to external one. In another case I got incorrect timing settings for MCU. Later, I decide to implement LTC6957-3 chip to share REFCLOCK source, since that chip has two equal CMOS-level outputs. Unfortunately I have no tool to measure the phase noise and jitters on each setup. It turns out all of this is built into the AVR chip. There is a counter and logic to copy the current counter value to a register on a PPS pulse raising edge. The counter keeps running and every second its value is trapped. I can connect the OCXO and the PPS directly to the AVR pin. The AVR has hardware (a fast comparator) to square a low amplitude sine wave and trap the counter on a zero crossing. So it looks like I can get rid of ALL of the external chips. The built in DAC is working well also but it needs some external resisters and caps. No need for '74 FFs or '373' or counter chips. I do get precision timing with no time critical software, no 74xxx chips. -- 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 [1] and follow the instructions there. Links: -- [1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts -- 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] First success with very simple, very low cost GPSDO, under $8
I was experimenting with the same setup for STM32 MCU. This microprocessor has accept the sine wave from external OCXO or GPSDO. No problem with this. The only thing: I was need to start MCU from slow watch crystal first. And then switch it to work to external one. In another case I got incorrect timing settings for MCU. Later, I decide to implement LTC6957-3 chip to share REFCLOCK source, since that chip has two equal CMOS-level outputs. Unfortunately I have no tool to measure the phase noise and jitters on each setup. It turns out all of this is built into the AVR chip. There is a counter and logic to copy the current counter value to a register on a PPS pulse raising edge.The counter keeps running and every second its value is trapped. I can connect the OCXO and the PPS directly to the AVR pin. The AVR has hardware (a fast comparator) to square a low amplitude sine wave and trap the counter on a zero crossing. So it looks like I can get rid of ALL of the external chips. The built in DAC is working well also but it needs some external resisters and caps. No need for '74 FFs or '373' or counter chips.I do get precision timing with no time critical software, no 74xxx chips. -- 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] First success with very simple, very low cost GPSDO, under $8
I am not sure about Arduino, but probably it too has so-called timer
overflow interrupt. If so, then its possible to use that other
interrupt and some long (lets say 32-bit) RAM variable to accumulate
real value of counter.
In one of my project I was using timer overflow and Besier method to
make good 1 minutes intervals.
volatile signed long t_besier = 1200L;
interrupt void TPM2OV_ISR(void)
{
TPM2SC = TPM2SC;
if (TPM2SC_TOF)
TPM2SC_TOF=0;
t_besier -= 65536L;
if(t_besier 0) {
t_besier += 1200L;
t_time++;
}
}
On 2014-04-09 23:10, Chris Albertson wrote:
Bob,
Yes, that is kind of how it works. The timer is only read once per
second. After reading it we subtract whatever was the count in the
previous sample to get the number of cycles in this last second.
There is no accurate way to reset the timer at the start of the
second. So we let it run forever. The 16-bit timer actually over
flows many times per second. The maximum value it ever gets to is
about 65,536. (actually 2^16 - 1)The counter will never reach
10,000,000. (but actually we count after a divide by 2 so 5,000,000
is the target number)
As it turns out even in a perfect world the counter value every second
is some random value between zero and 65535. Because when the
overflows happen depend in the exact microsecond I applied power to
the system., that is my arbitrary zero and I count up from there
overflowing back to zero about 76.6 times per second Every second we
capture whatever the timer value is and compute delts cycles
You are right in the I don't even need data cycles. All I want is the
error which is 5,000,000 minus the count. this is hopefully zero.
This would be easier if we have a 32 bit counter that could be reset
to zero each second. In the past I think people have built counters
like this but now I can buy a $3.80 Arduino that does the counting,
ADC and DAC and computer USB interface. So I put up with a harder to
use 16-bit nonresetable counter
On Wed, Apr 9, 2014 at 6:33 PM, Bob Stewart b...@evoria.net wrote:
Have you considered reading the timer only at PPS? You don't need to
keep track of the actual count. You just need to keep track of the
difference between counts at each PPS. Resolution isn't a problem
since the difference in the lower 16 bits is a fixed number for your
purpose. IOW, 10,000,000 is 0x989680. You're only interested in the
0x9680. If there's a difference in two successive timer counts of
0x9680, then you know you counted 10,000,000, unless your oscillator
is capable of running at one of the other values that gives 0x9680 as
the lower two bytes.
Bob
From: Chris Albertson albertson.ch...@gmail.com
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Sent: Wednesday, April 9, 2014 6:35 PM
Subject: Re: [time-nuts] First success with very simple, very low
cost GPSDO, under $8
On Wed, Apr 9, 2014 at 1:04 PM, Tom Harris celephi...@gmail.com
wrote:
Another point with the software is that your handler for the PPS
just reads
the counter. This gives an offset between the PPS edge and the value
read,
as your software takes time to respond to the interrupt and read the
counter. In your code, it doesn't matter as you only have one
interrupt.
Actually there are two interrupts. One is for PPS and the other is
for overflow of the 16-bit counter. This over flow happens about 76
times per seconds.
However, if you have another interrupt enabled, this could run after
the
PPS pulse but before the handler runs, giving you a very rare
jitter.
A better way would be to use the input capture feature to read the
timer
into a capture register. Then the interrupt handler has until the
next edge
to read the capture register.
Do you know how to do this. I don't see any way to capture the timer
value other then reading it with software. The timer capture
register
is 16 bits and is set atomically after each timer increment but I
don't see a way to make an external interrupt pin capture a timer.
The two interrupts do bump into each other about roughly every 100
seconds but I can detect that. I think I'll just ignore that second.
--
Chris Albertson
Redondo Beach, California
___
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
Re: [time-nuts] First success with very simple, very low cost GPSDO, under $8
Correct, your code example is the traditional way to keep track of
elapsed time without long-term rounding error, although it's usually
not attributed to Bézier.
My bad ! I messed up Bezier and Bresenham line algorithm, which I was
using for generating one average timed period from any other timed
period (like the PIC timer0 overflow period, for example).
Not sure if you've been following the whole thread, though -- the
problem with timer interrupt code is that it can, and will on rare
occasion, conflict with 1PPS rising edge pin interrupts. On a
microcontroller, for best precision, the solution is to get rid of the
timer interrupts, or get rid of the 1PPS interrupts, or both.
Secondly, you cannot share multi-byte variables between interrupt
level and main level without synchronization or arbitration.
I am not familiar with Arduino. STM32, for sure, has interrupt priority.
But than it will not be 8$ project. ;-) The best results I achieve
using DMA. Timer updating the buffer variable(s) in background and its
not using interrupts for it. So, I could read the current value of
counter any time. At least I got good results for this approach when I
connect MCU clock to GPSDO and tried to measure the signal from external
OCXO. I got perfect 10 Mhz at that time.
Your code snippet is a good example of what is subtle and dangerous,
and dare I say, wrong. You are updating long t_besier in an interrupt
handler. Any main level code using t_besier faces byte carry
corruption in the multi-byte value of t_besier. True, this works fine
on a 32- or 64-bit cpu, but not on an 8- or 16-bit cpu.
Hmm...
- Original Message -
From: d0ct0r t...@patoka.org
To: time-nuts@febo.com
Sent: Thursday, April 10, 2014 10:12 AM
Subject: Re: [time-nuts] First success with very simple, very low cost
GPSDO, under $8
I am not sure about Arduino, but probably it too has so-called timer
overflow interrupt. If so, then its possible to use that other
interrupt and some long (lets say 32-bit) RAM variable to accumulate
real value of counter.
In one of my project I was using timer overflow and Besier method to
make good 1 minutes intervals.
volatile signed long t_besier = 1200L;
interrupt void TPM2OV_ISR(void)
{
TPM2SC = TPM2SC;
if (TPM2SC_TOF)
TPM2SC_TOF=0;
t_besier -= 65536L;
if(t_besier 0) {
t_besier += 1200L;
t_time++;
}
}
___
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] ARM boards for low-cost GPSDOs
The timers are 16-bit but I extend it to 64 bits in software. When the timer rolls over I add 65536 to the software variable mono_epoch. At BTW, its possible to extend timer to 64 bit using special feature of ST32. Its when one timer (master), controlling the other timer(s) (slaves). See following app. note, for example: http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/CD00165509.pdf Also, the examples which coming with peripheral library helps a lot ! I was using PIC and Freescale before. All my recent project is on ST32. But instead of Discovery board I would prefer bare board with MCU from auction site. JUst because its gives me more control. ;-) -- 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] TSIP protocol for T-Bolt
Thanks ! As soon as I figured out about double DLE bytes - everything is back to right track. Regards, V.P. On 2014-03-26 04:46, Götz Romahn wrote: Am 25.03.2014 22:43, : Today I spent good part of my time to figure out that my version of Thunderbolt has some issue with the TSIP protocol definition. I am using following document: ThunderBolt GPS Disciplined Clock User Guide, Version 5.0, Part Number: 35326-30, November 2003 but beware, no single document related to Thunderbolt from Trimbles website is complete nor fully correct. As a reference you may use my code of a simple Tbolt-Monitor you will here: http://www.romahn.info/tbolt2lcd/ regards Götz ___ 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] TSIP protocol for T-Bolt
Speaking about legacy T-Bolt devices and modern development: Here is
paragraph from Trimble Thunderbolt User guide:
Week Number: This field represents the current GPS week number. GPS week
number 0
started on January 6, 1980. Unfortunately, the GPS system has allotted
only 10-bits of
information to carry the GPS week number and therefore it rolls-over to
0 in just 1024
weeks (19.6 years,) and there is no mechanism built into GPS to tell the
user to which
1024 week epoch the week number refers. The first week number roll-over
will occur as
August 21, 1999 (GPS) transitions to August 22, 1999 (GPS). The
ThunderBolt adjusts for
this week rollover by adding 1024 to any week number reported by GPS
which is less that
week number 936 which began on December 14, 1997. With this technique,
the
ThunderBolt will provide an accurate translation of GPS week number and
TOW to time
and date until July 30, 2017.
How that week number will affect the functionality of whole device ?
Its probably time to think to put some workaround to the code or even
eliminate to use that time information received from T-Bolt. I already
met that challenge when I was working with BC637PCI card. The work
around was quite simple then - just to add 619315200 seconds to the
current value [1024*7*24*60*60]. I would like to be little proactive
here. ;-)
Also, does anybody knows if new Trimble Thunderbolt E is backward
compatible with legacy HW ? I mean the replacement will still works on
most of existed setups. For example, I did compare the packet definition
for 8F-AC and looks like Thunderbolt E has some extensions, but its
backward compatible.
Regards,
V.P.
On 2014-03-26 08:38, Didier Juges wrote:
You can play with my Thunderbolt Simulator:
http://www.ko4bb.com/Timing/GPSMonitor/TBoltSim.php [2]
(Windows only, sorry...)
It lets you create arbitrary packets (including setting fault
conditions and arbitrary GPS time or coordinates) and properly escapes
the embedded DLEs. The actual string that is sent is displayed in Hex
at the bottom of the screen.
(Warning: It is work in progress, so not all menu selections actually
work)
On Tue, Mar 25, 2014 at 7:11 PM, d0ct0r t...@patoka.org wrote:
Much thanks Tom and Mike ! I missed that point. In another word,
T-Bolt sending DLE data wrapped by another byte ! Now I know !
On 2014-03-25 19:55, mike cook wrote:
Le 25 mars 2014 à 22:43, d0ct0r a écrit :
Today I spent good part of my time to figure out that my version of
Thunderbolt has some issue with the TSIP protocol definition. I am
using following document: ThunderBolt GPS Disciplined Clock User
Guide, Version 5.0, Part Number: 35326-30, November 2003
In that particular PDF file, there is definition for 0x8F-AB TSIP
packet [section A.10.30 Report Packet 0x8F-AB Primary Timing
Packet].
Here is the structure of 8F-AB, translated to plain C-code:
typedef struct tb_8f_ab {
uint8_t sub; //0 : 1
uint32_t tow; //1-4 : 4
uint16_t wn; //5-6 : 2
int16_t ls; //7-8 : 2
uint8_t tflag; //9 : 1
uint8_t sec; //10 : 1
uint8_t min; //11 : 1
uint8_t hr; //12 : 1
uint8_t day; //13 : 1
uint8_t month; //14 : 1
uint16_t year; //15-16 : 2
} mytb_8f_ab;
Here is the dump I get from my MCU:
//0x10 0x8F 0xAB 0x0 0x3 0x92 0x88 0x6 0xF9 0x0 0x10 0x10 0x3 0x2C
0x1 0x11 0x19 0x3 0x7 0xDE 0x10 0x3
//0x10 0x8F 0xAB 0x0 0x3 0xCC 0x16 0x6 0xF9 0x0 0x10 0x10 0x3 0x12
0x7 0x15 0x19 0x3 0x7 0xDE 0x10 0x3
how are you dumping this?
you have an imbedded (stuffed)DLE, which is sent as DLE/DLE but the
second is to be ignored.
Which is conform to TSIP standard packet definition:
TSIP packet structure is the same for both commands and reports.
The
packet format is:
DLE id data string bytes DLE ETX
Where:
* DLE is the byte 0x10
* ETX is the byte 0x03
* id is a packet identifier byte, which can have any value
excepting
ETX and DLE.
Ex: In the tsip developer tool kit , from TsipParser.c
case TSIP_IN_PARTIAL:
// The parser is in this state if a previous character was
// a part of the TSIP data. As noted above, a DLE character
// can be a part of the TSIP data in which case another DLE
// character is present in the data stream. So, here we look
// at the next character in the stream (currently loaded in
// ucByte). If it is a DLE character, we just encountered
// a stuffed DLE byte. In that case, we ignore this byte
// and go back to the TSIP_DLE state. That way, we will log
// only one DLE byte which was a part of the TSIP data.
//
// All other non-DLE characters are placed in the TSIP packet
// buffere.
if (ucByte == DLE)
{
nParseState = TSIP_DLE;
}
else
{
ucPkt[nPktLen++] = ucByte;
}
break;
However, its appeared that my T-Bolt throwing one extra byte for
the so-called Timing Flags.
There is 19 bytes coming from my T-Bolt, instead of expected 18. I
found that actual length of TFLAG is 16 bit - not 8. Interesting
enough, that Lady Heather works perfectly fine with that T-Bolt !
Can somebody confirm that there is different version
[time-nuts] TSIP protocol for T-Bolt
Today I spent good part of my time to figure out that my version of
Thunderbolt has some issue with the TSIP protocol definition. I am using
following document: ThunderBolt GPS Disciplined Clock User Guide,
Version 5.0, Part Number: 35326-30, November 2003
In that particular PDF file, there is definition for 0x8F-AB TSIP packet
[section A.10.30 Report Packet 0x8F-AB Primary Timing Packet].
Here is the structure of 8F-AB, translated to plain C-code:
typedef struct tb_8f_ab {
uint8_t sub;//0: 1
uint32_t tow; //1-4 : 4
uint16_t wn;//5-6 : 2
int16_t ls; //7-8 : 2
uint8_t tflag; //9: 1
uint8_t sec;//10 : 1
uint8_t min;//11 : 1
uint8_t hr; //12 : 1
uint8_t day;//13 : 1
uint8_t month; //14 : 1
uint16_t year; //15-16 : 2
} mytb_8f_ab;
Here is the dump I get from my MCU:
//0x10 0x8F 0xAB 0x0 0x3 0x92 0x88 0x6 0xF9 0x0 0x10 0x10 0x3 0x2C 0x1
0x11 0x19 0x3 0x7 0xDE 0x10 0x3
//0x10 0x8F 0xAB 0x0 0x3 0xCC 0x16 0x6 0xF9 0x0 0x10 0x10 0x3 0x12 0x7
0x15 0x19 0x3 0x7 0xDE 0x10 0x3
Which is conform to TSIP standard packet definition:
TSIP packet structure is the same for both commands and reports. The
packet format is:
DLE id data string bytes DLE ETX
Where:
• DLE is the byte 0x10
• ETX is the byte 0x03
• id is a packet identifier byte, which can have any value excepting
ETX and DLE.
However, its appeared that my T-Bolt throwing one extra byte for the
so-called Timing Flags.
There is 19 bytes coming from my T-Bolt, instead of expected 18. I found
that actual length of TFLAG is 16 bit - not 8. Interesting enough, that
Lady Heather works perfectly fine with that T-Bolt !
Can somebody confirm that there is different version of T-Bolt on the
market ? If so, where I need to look for the documentation for my
version ?
--
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] TSIP protocol for T-Bolt
Much thanks Tom and Mike ! I missed that point. In another word, T-Bolt
sending DLE data wrapped by another byte ! Now I know !
On 2014-03-25 19:55, mike cook wrote:
Le 25 mars 2014 à 22:43, d0ct0r a écrit :
Today I spent good part of my time to figure out that my version of
Thunderbolt has some issue with the TSIP protocol definition. I am
using following document: ThunderBolt GPS Disciplined Clock User
Guide, Version 5.0, Part Number: 35326-30, November 2003
In that particular PDF file, there is definition for 0x8F-AB TSIP
packet [section A.10.30 Report Packet 0x8F-AB Primary Timing
Packet].
Here is the structure of 8F-AB, translated to plain C-code:
typedef struct tb_8f_ab {
uint8_t sub; //0 : 1
uint32_t tow; //1-4 : 4
uint16_t wn; //5-6 : 2
int16_t ls; //7-8 : 2
uint8_t tflag; //9 : 1
uint8_t sec; //10 : 1
uint8_t min; //11 : 1
uint8_t hr; //12 : 1
uint8_t day; //13 : 1
uint8_t month; //14 : 1
uint16_t year; //15-16 : 2
} mytb_8f_ab;
Here is the dump I get from my MCU:
//0x10 0x8F 0xAB 0x0 0x3 0x92 0x88 0x6 0xF9 0x0 0x10 0x10 0x3 0x2C
0x1 0x11 0x19 0x3 0x7 0xDE 0x10 0x3
//0x10 0x8F 0xAB 0x0 0x3 0xCC 0x16 0x6 0xF9 0x0 0x10 0x10 0x3 0x12
0x7 0x15 0x19 0x3 0x7 0xDE 0x10 0x3
how are you dumping this?
you have an imbedded (stuffed)DLE, which is sent as DLE/DLE but the
second is to be ignored.
Which is conform to TSIP standard packet definition:
TSIP packet structure is the same for both commands and reports. The
packet format is:
DLE id data string bytes DLE ETX
Where:
• DLE is the byte 0x10
• ETX is the byte 0x03
• id is a packet identifier byte, which can have any value
excepting
ETX and DLE.
Ex: In the tsip developer tool kit , from TsipParser.c
case TSIP_IN_PARTIAL:
// The parser is in this state if a previous character was
// a part of the TSIP data. As noted above, a DLE character
// can be a part of the TSIP data in which case another DLE
// character is present in the data stream. So, here we look
// at the next character in the stream (currently loaded in
// ucByte). If it is a DLE character, we just encountered
// a stuffed DLE byte. In that case, we ignore this byte
// and go back to the TSIP_DLE state. That way, we will log
// only one DLE byte which was a part of the TSIP data.
//
// All other non-DLE characters are placed in the TSIP packet
// buffere.
if (ucByte == DLE)
{
nParseState = TSIP_DLE;
}
else
{
ucPkt[nPktLen++] = ucByte;
}
break;
However, its appeared that my T-Bolt throwing one extra byte for
the so-called Timing Flags.
There is 19 bytes coming from my T-Bolt, instead of expected 18. I
found that actual length of TFLAG is 16 bit - not 8. Interesting
enough, that Lady Heather works perfectly fine with that T-Bolt !
Can somebody confirm that there is different version of T-Bolt on
the market ? If so, where I need to look for the documentation for
my version ?
--
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 [1]
and follow the instructions there.
Links:
--
[1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
--
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] Power Supply for AD9852 / AD9854
I would assume that using two voltage regulators will spread the load. For the AD9851 I'am planning to put external radiator glued on top of it. Regards, V.P. those parts dissipate a fair amount of heat, and they're not very big. If you turn on everything in the 9854 AND run it at 300 MHz clock, it draws about 1.2 Amps (@ 3.3V) which is about 4 Watts.. that's a lot of power to get out of the part and keep Tj reasonable. Board layout to get the heat out is very important. If they get too hot, they start to act flaky. You get extra spurs and more importantly, they don't respond to the programming properly (e.g. you send the serial stream to program frequency X, and instead it programs some different frequency). The heat sink of the AD9854ASVZ 80-lead TQFP package must be soldered to the PCB. Adequate dissipation of heat from the AD9854 relies on all power and ground pins of the device being soldered directly to a copper plane on a PCB. In addition, the thermally enhanced package of the AD9854ASVZ has an exposed paddle on the bottom of the package that must be soldered to a large copper plane, which, for convenience, can be the ground plane. -- 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] Power Supply for AD9852 / AD9854
Hello, By design, DDS stones like AD9852 from Analog Devices, required separated power lines for AVDD, DVDD and VCC. What will is simple solution for that ? I am planing to use following approach: +5V from linear PS, then three LC filters, then three 3.3V voltage regulators (Ex.: MC33269T) connected to each filter. Is it good enough ? May be its better solution for this ? Or may be that could be simplified to join AVDD and VCC (AVDD will be connected to VCC via 100 Ohm). Thanks in advance ! -- WBW, V.P.attachment: pf.png___ 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] Power Supply for AD9852 / AD9854
Many thanks indeed for detailed answer ! Yes, I will using Evaluation Board for my project. Regards, V.P. On 2014-03-16 00:06, Charles Steinmetz wrote: By design, DDS stones like AD9852 from Analog Devices, required separated power lines for AVDD, DVDD and VCC. What will is simple solution for that ? I am planing to use following approach: +5V from linear PS, then three LC filters, then three 3.3V voltage regulators (Ex.: MC33269T) connected to each filter. Is it good enough ? May be its better solution for this ? Or may be that could be simplified to join AVDD and VCC (AVDD will be connected to VCC via 100 Ohm). Do you have the AD evaluation board, or are you starting with the bare chip? If you really want to know how simple you can make it, why not try it yourself, and see what you need? You will learn a lot more that way than by asking first every time a question occurs to you. Follow the evaluation board plan and put a 0.1uF (100nF) monolithic ceramic capacitor right at each power input pin of the IC itself (something like 10 capacitors per supply). First, use one 3.3v regulator and feed its output straight to all three circuits, with simply a local bypass cap for each one (plus the per-pin capacitors as noted above). Run the DDS and see how it performs. Then, see how three separate LC filters perform (each LC fed by the regulated 3.3v supply). Finally, feed the unregulated supply to the upstream side of each of the three LC filters, and use a separate 3.3v regulator on the downstream side for each supply. In each case, note carefully (at a lot of different output frequencies) the general output noise level and the presence of any spurs and birdies in the output, as well as any logic faults you find (wrong frequency, system hangs up, bus errors, etc.). It might be more instructive to run those steps backwards -- first, see how it works with the most complex (and presumably best) supply, then try the simpler circuits and see what problems crop up. Of course, with either test protocol it is difficult to know whether you have tried every operating state that could cause a problem, so play with it quite a while with each setup and try to use every function and combination. As Chris said, you need to be very careful with your grounds. These chips are intended to be put on boards with four or more layers. The AD evaluation board has four layers with a common ground plane for the analog and digital circuitry -- it is possible you could do better with more careful attention to grounding. Best regards, Charles ___ 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] Frequency Counter using OCXO and MCU
I am using old Wavetek 180 signal generator for the tests. I just hooked
its TTL output directly to the pin of MCU. The STM32F4xx has core clock
168 mHz and its inputs capable to handle pretty wide range of frequency.
I don't think 1-2 mHz connected to the pin should be a problem. At least
in my setup it shows me adequate result for that frequency. But its
slows done the main loop a lot because its interrupting million time
per second. For 2 mHz input, I'll need to wait several seconds to see
the result. Of course I could remove averaging or decrease number of
samples to improve that time.
I am still thinking why I have incorrect results for low frequency. May
be counter overflows could impact the result.
The counter for my timer is 16 bit. That means it will generate overflow
after 65535 counts. The timer frequency is 168 mHz. Then it will
overflows around every 400 uS (or 2563.5 Hz). Probably any frequency
which is lower than 2.5 kHz will shows me incorrect results. Probably
I'll need to think how to handle that.
Regards,
V.P.
On 2014-03-12 10:18, Chris Albertson wrote:
Are you putting the unknown signal to be measured on an interrupt
pin? that will work for low enough frequencies but most uPs have a
built-in counter. It is a hardware register on the uP chip that
will increment for each pulse on a pin. then you read that number
and divide by the gate time. At some point the frequency will be to
high for the counter pin so then you switch in a hardware frequency
diver as a pre-scaler.
On Tue, Mar 11, 2014 at 8:24 PM, d0ct0r t...@patoka.org wrote:
Hello,
I am experimenting to build frequency counter using external OCXO
and ST32 MCU. The OCXO is external DATUM 2750013-1 device which
produce 10Mhz sine wave. I connected its output to OC_IN on MCU. I
have few challenges now.
First, looks like I need to create some delay to turn on MCU
_after_ OCXO. If I try to start both devices simultaneously, I got
following result for 10 kHz TTL measurement:
System Core Clock: 16800 Hz
SYSCLK_Frequency PCLK1_Frequency PCLK2_Frequency
1600 1600 1600
# Starting SuperLoop...
FREQ: 105197
FREQ: 105263
FREQ: 105263
FREQ: 105263
As soon as I push reset button on MCU, I got correct results for
its clocks and correct value for the counter:
System Core Clock: 16800 Hz
SYSCLK_Frequency PCLK1_Frequency PCLK2_Frequency
16800 4200 8400
# Starting SuperLoop...
FREQ: 10019
FREQ: 10019
FREQ: 10019
FREQ: 10019
FREQ: 10018
FREQ: 10019
Another challenge is the fact, that if I increase the input signal
frequency, then performance of the MCU decreased. In the other word,
I need to wait much more time to have a result. Probably MCU is
super busy to handle the interrupt. Say for 10 kHz range its pretty
fast. Then for 1 mHz its much slower.
Here is main loop:
while (1) {
if(j++ 0xF0) {
accum += deltaREF; // Moving Average
accum = (accum 1);
} else {
uwTIM1Freq = (uint32_t) SystemCoreClock / accum;
printf(FREQ: %ulnr, uwTIM1Freq);
accum = j = 0;
}
}
The counter is based on timer in input capture mode and driven by
interrupt:
[ See STM32F4xx_StdPeriph_ExamplesTIMTIM_InputCapture ]
Also this counter shows incorrect results for low frequency. For
example, for 100 Hz:
FREQ: 4968
FREQ: 5030
FREQ: 5056
FREQ: 4916
I would be interesting to hear any advise how to improve it.
And another question is: what will be pros and cons to
transform 10Mhz sine to square to feed MCU ? I tried it, but didn't
catch any difference.
Here is schema
http://www.qsl.net/va3iul/Homebrew_RF_Circuit_Design_Ideas/Sine-to-Square_Wave_BJT_Converter_Wenzel.gif
[1]
--
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 [2]
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
Links:
--
[1]
http://www.qsl.net/va3iul/Homebrew_RF_Circuit_Design_Ideas/Sine-to-Square_Wave_BJT_Converter_Wenzel.gif
[2] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
--
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] Frequency Counter using OCXO and MCU
LCD connected to the same MCU. And it has relation to the core clock
too. So, nothing on LCD before I reset entire MCU. I think initial
incorrect core clock reading cause a lot of issues. Probably my only
option will be to implement some external relay and timer to turn on MCU
few seconds after OCXO. Or may be to put 10Mhz oscillator to PCB and
connect OCXO output in parallel to it (not sure if its good idea or it
will works).
Regards,
V.P.
On 2014-03-12 10:21, Chris Albertson wrote:
Sorry forgot to add this.
As for delayed turn on. That can work but why not simply have the
software go into a 5 or 10 second wait before it does anything else.
Display warming up or please wait on the LCD.
On Wed, Mar 12, 2014 at 7:18 AM, Chris Albertson
albertson.ch...@gmail.com wrote:
Are you putting the unknown signal to be measured on an interrupt
pin? that will work for low enough frequencies but most uPs have a
built-in counter. It is a hardware register on the uP chip that
will increment for each pulse on a pin. then you read that number
and divide by the gate time. At some point the frequency will be
to high for the counter pin so then you switch in a hardware
frequency diver as a pre-scaler.
On Tue, Mar 11, 2014 at 8:24 PM, d0ct0r t...@patoka.org wrote:
Hello,
I am experimenting to build frequency counter using external OCXO
and ST32 MCU. The OCXO is external DATUM 2750013-1 device which
produce 10Mhz sine wave. I connected its output to OC_IN on MCU. I
have few challenges now.
First, looks like I need to create some delay to turn on MCU
_after_ OCXO. If I try to start both devices simultaneously, I got
following result for 10 kHz TTL measurement:
System Core Clock: 16800 Hz
SYSCLK_Frequency PCLK1_Frequency PCLK2_Frequency
1600 1600 1600
# Starting SuperLoop...
FREQ: 105197
FREQ: 105263
FREQ: 105263
FREQ: 105263
As soon as I push reset button on MCU, I got correct results for
its clocks and correct value for the counter:
System Core Clock: 16800 Hz
SYSCLK_Frequency PCLK1_Frequency PCLK2_Frequency
16800 4200 8400
# Starting SuperLoop...
FREQ: 10019
FREQ: 10019
FREQ: 10019
FREQ: 10019
FREQ: 10018
FREQ: 10019
Another challenge is the fact, that if I increase the input
signal frequency, then performance of the MCU decreased. In the
other word, I need to wait much more time to have a result.
Probably MCU is super busy to handle the interrupt. Say for 10 kHz
range its pretty fast. Then for 1 mHz its much slower.
Here is main loop:
while (1) {
if(j++ 0xF0) {
accum += deltaREF; // Moving Average
accum = (accum 1);
} else {
uwTIM1Freq = (uint32_t) SystemCoreClock /
accum;
printf(FREQ: %ulnr, uwTIM1Freq);
accum = j = 0;
}
}
The counter is based on timer in input capture mode and driven
by interrupt:
[ See STM32F4xx_StdPeriph_ExamplesTIMTIM_InputCapture ]
Also this counter shows incorrect results for low frequency. For
example, for 100 Hz:
FREQ: 4968
FREQ: 5030
FREQ: 5056
FREQ: 4916
I would be interesting to hear any advise how to improve it.
And another question is: what will be pros and cons to
transform 10Mhz sine to square to feed MCU ? I tried it, but
didn't catch any difference.
Here is schema
http://www.qsl.net/va3iul/Homebrew_RF_Circuit_Design_Ideas/Sine-to-Square_Wave_BJT_Converter_Wenzel.gif
[1]
--
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 [2]
and follow the instructions there.
--
Chris Albertson
Redondo Beach, California
--
Chris Albertson
Redondo Beach, California
Links:
--
[1]
http://www.qsl.net/va3iul/Homebrew_RF_Circuit_Design_Ideas/Sine-to-Square_Wave_BJT_Converter_Wenzel.gif
[2] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
--
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] Frequency Counter using OCXO and MCU
Hello,
I am experimenting to build frequency counter using external OCXO and
ST32 MCU. The OCXO is external DATUM 2750013-1 device which produce
10Mhz sine wave. I connected its output to OC_IN on MCU. I have few
challenges now.
First, looks like I need to create some delay to turn on MCU _after_
OCXO. If I try to start both devices simultaneously, I got following
result for 10 kHz TTL measurement:
System Core Clock: 16800 Hz
SYSCLK_Frequency PCLK1_Frequency PCLK2_Frequency
1600 16001600
# Starting SuperLoop...
FREQ: 105197
FREQ: 105263
FREQ: 105263
FREQ: 105263
As soon as I push reset button on MCU, I got correct results for its
clocks and correct value for the counter:
System Core Clock: 16800 Hz
SYSCLK_Frequency PCLK1_Frequency PCLK2_Frequency
1680042008400
# Starting SuperLoop...
FREQ: 10019
FREQ: 10019
FREQ: 10019
FREQ: 10019
FREQ: 10018
FREQ: 10019
Another challenge is the fact, that if I increase the input signal
frequency, then performance of the MCU decreased. In the other word, I
need to wait much more time to have a result. Probably MCU is super busy
to handle the interrupt. Say for 10 kHz range its pretty fast. Then for
1 mHz its much slower.
Here is main loop:
while (1) {
if(j++ 0xF0) {
accum += deltaREF; // Moving Average
accum = (accum 1);
} else {
uwTIM1Freq = (uint32_t) SystemCoreClock / accum;
printf(FREQ: %ul\n\r, uwTIM1Freq);
accum = j = 0;
}
}
The counter is based on timer in input capture mode and driven by
interrupt:
[ See STM32F4xx_StdPeriph_Examples\TIM\TIM_InputCapture ]
Also this counter shows incorrect results for low frequency. For
example, for 100 Hz:
FREQ: 4968
FREQ: 5030
FREQ: 5056
FREQ: 4916
I would be interesting to hear any advise how to improve it.
And another question is: what will be pros and cons to transform
10Mhz sine to square to feed MCU ? I tried it, but didn't catch any
difference.
Here is schema
http://www.qsl.net/va3iul/Homebrew_RF_Circuit_Design_Ideas/Sine-to-Square_Wave_BJT_Converter_Wenzel.gif
--
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] GPSDO module connections
Hello, I am looking for the advise: what will be the better method to connect GPSDO module by short extension cable to put its antenna input on front or back panel ? Lets say, GPSDO module has female “F” connector. And I would like to have BNC connector on back panel of my project. Manufacturer of GPSDO recommend to use RG-59 cable for antenna connection. Is it OK if I'll take some RG-59 from CCTV, cut 6 or 12 of it, connect one end to GPSDO (let say this cable has compression type connector) and solder other end to BNC on the panel ? Or its better to use adapters and no soldering ? Like F connector-to-BNC adapter , then short BNC-to-BNC cable connected to BNC panel connector ? And other question: is it worth to use RF cable to connect 1PPS output from GPSDO to distribution amplifier ? Or regular AWG-22 could do that job ? Thanks ! -- 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] FSCM 38243 Power Distribution Module
Thanks All for the information ! I'll try to contact PG Electronics for the specifications. For now, I have no access to precision instruments to measure certain parameters of that module. The whole idea is to have couple of extra sine outputs from my Trimble T-bolt. I am thinking to hook 10Mhz to MCU and use it as main clock source for it. The same MCU will be using as monitoring tool for T-Bolt and probably provide some extra functionality for my project. And at the same time to have isolated sine outputs which I could use for some other projects or experiments. For 1PPS I'll going to use TADD-3. I think its fun to have MCU which using GPSDO as main clock source. For example, I think I could use as frequency counter or signal generator. Regards, V.P. On 2014-03-02 03:06, Robert Atkinson wrote: From the construction and components used it isn't UHF ;-) It appears to be 7 two way splittters in series and the transformers look to have plenty of turns. As you have a 10MHz source why not just try it out? You should get about 9dB attenuation input to output with the other ports terminated in 50R. This could be checked by reference to a 10dB attenuator with a 50R load, diode and multimeter as indication if you don't have an accurate power meter. Or if you ship it to me I can stick it on a VNA and give you exact specs. HTH Robert G8RPI. - FROM: d0ct0r t...@patoka.org TO: time-nuts@febo.com SENT: Sunday, 2 March 2014, 5:54 SUBJECT: [time-nuts] FSCM 38243 Power Distribution Module Does anybody knows if FSCM 38243 8-way P/D module is suitable for 10MHZ frequency ? The module I have, has no other information on it except Serial No.: 171-0100-048. Looks like its old Minicircuits product. But I am not sure. I am planing to connect 10Mhz GPSDO output to it. -- 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 [1] and follow the instructions there. Links: -- [1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts -- 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] DS3231m 1HZ output stability
Do you have a scope? Any overshoot/bounce crap? (Not likely with low power CMOS.) Attached is screenshot from USB-based scope. I'll going to switch wires to see any difference. -- WBW, V.P.attachment: gps2rtc.PNG___ 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] DS3231m 1HZ output stability
To answering myself: I think nothing wrong with DS32XX. I hooked up GPS 1PPS output to the same timer (different channel) where I have 1PPS from RTC. Now I see something like this. # Delta GPS: 7330, Delta RTC: 7330 # Delta GPS: 7330, Delta RTC: 7329 # Delta GPS: 7330, Delta RTC: 7329 # Delta GPS: 7330, Delta RTC: 7330 # Delta GPS: 7330, Delta RTC: 7330 # Delta GPS: 405, Delta RTC: 705 # Delta GPS: 405, Delta RTC: 705 # Delta GPS: 7330, Delta RTC: 7330 Definitely something wrong with my code or the way how MCU handle different events (interrupts). Reggards, V.P. On 2014-02-25 17:32, Tom Van Baak wrote: I would like to ask if somebody did measurement for that Dallas DS32XX series chips. Is that 1PPS (1HZ square wave) stable there or it has some issues ? I am thinking that burp in my tests could be because of my poor code or may be because of DS32XX doing temperature conversion every second, which cause an impact to the 1HZ output. I would be interested to hear any information about. From the datasheet of DS3231m , that 1HZ from DS32XX should be stable. Both the GPS and DS32XX 1PPS should be fine. Are your free-run counters really free? It looks like a simple bug in your code. All this is very easy to debug if you have even the most basic frequency or time interval counter available to independently validate the GPS or the DS32XX 1PPS interval. /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. -- 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] Serial port splitter s/w
Here is interesting topic about NTP on Raspberry PI (typical usage of ARM and Linux bread on top of it) http://www.synclab.org/?tag=testing Basically, TCP stack on ARM usually come from one source - its a Adam Dunken TCP stack. Then its is MII part and the hardware which doing Ethernet. In my opinion, MCU (ARM) could provide excellent Ethernet functions. However its far from serious dedicated ethernet controllers we could see in enterprise servers. Regards, V.P. On 2014-02-26 12:32, Chris Albertson wrote: It's not going to work. If the purpose of running the Thunderbolt is only to drive NTP then you don't need LH. NTP's only tags the pulses to the nearest microsecond, nano sec on accuracy is lost on NTP. I'd even say the TB is the wrong GPS for NTP. It costs to much and uses to much power. But if you are also, or mainly, using the Thunderbolt for it's 10Mhz and NTP is a secondary function then a TB makes sense. Yes you NEED the PPS on the serial cable. Thunderbolts do not send NMEA. Thunderbolts send their own data format that is unique to Trimble. Don't modify the GPS receiver. Make a special cable adapter. When you do this pay attention to polarity of the PPS signal. It is easy to get it backwards. You want the raising edge of the TB pulse to interrupt the computer. It you invert the signal the wrong number of times the time will be off by the ouse length and I don't know if the pulse length is controlled to the level the leading edge is.Remember RS232 uses negative and positive voltage, data lines use negative logic, control lines positive. The TB's PPS is TTL level. Many rs232 ports do accept t/l level if you get the polariy correct. Again don't even bother to run an NTP server without PPS. You may as well just get time from some internet time servers. You can NOT control a GPS from two ports. Both NTP and LH will try to send commands to the GPS. Likely, almost certainly you need to build a small circuit board the has two connectors that face the TB (PPS and serial) and one that faces the computer. The little perfboard makes a neat way to or connect cables but you could solder up a y--cable The best thing to do is get a cheaper GPS, and one that uses less power to drive the NTP server. The old Motorola Oncore series are cheap and the new breed of very small GPSes are good too. DOn't spend more than $40 or $50 on a GPS to drive NTP as ,again NTP record microseconds. You could free up that Windows PC too. It is not the best platform for NTP. Asmall ARM based system (even the Rasbery Pi) will outperform a Windows based NTP server. and use a LOT less power (Power cost for a NTP server is more than you think, it came to about $300 a year for me if I used a standard PC and a thunderbolt. Switching to a very tiny ARM based system and a smaller GPS gave as good performance and power savings paid for the hardware in 1/2 a year. $.21/KWH about 170W and 8760 hours per year comes to a $300 power bill. My current system is powered by a 1000 mw plug-in power cube and does not need a cooling fan. On Wed, Feb 26, 2014 at 7:53 AM, David C. Partridge david.partri...@perdrix.co.uk wrote: I'm running Meinberg NTP on the Windows 7 x64 machine to which my Thunderbolt is attached. I'd like to be able to share the serial port between LH and NTP so that I can run the machine as an NTP Stratum 1 server locked to the TB, and also be able to use LH to check things. I looked around the with Google, and saw *numerous serial port splitters. Which is recommended? Also what's the best way how to configure NTP to lock the the TB on a serial port? Do I need to modify the TB to deliver the PPS down one of the serial data lines or will NTP work well by parsing the NMEA time messages? Many thanks David Partridge ___ 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] DS3231m 1HZ output stability
Hello, I am experimenting to compare 1PPS outputs from Dallas/Maxim DS3231m chip and 1PPS output from generic GPS module. I attached both signal to MCU timers with free run counters and measure the interval between of raising edges. Here is the typical results: # Delta GPS: 3659, Delta RTC: 3660 # Delta GPS: 3659, Delta RTC: 3659 # Delta GPS: 3658, Delta RTC: 1984 # Delta GPS: 3658, Delta RTC: 1984 # Delta GPS: 3659, Delta RTC: 3659 # Delta GPS: 3659, Delta RTC: 3660 In my tests, Delta is the number of MCU tics (counter value) and its depends of MCU clock settings. Usually Delta pretty much close for RTC and GPS. But sometimes, DS3231m shows some big difference. Meantime, 1PPS from GPS module is much more consistence. I would like to ask if somebody did measurement for that Dallas DS32XX series chips. Is that 1PPS (1HZ square wave) stable there or it has some issues ? I am thinking that burp in my tests could be because of my poor code or may be because of DS32XX doing temperature conversion every second, which cause an impact to the 1HZ output. I would be interested to hear any information about. From the datasheet of DS3231m , that 1HZ from DS32XX should be stable. Regards, 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] WWVB antennas
I am impressed by Casio engineers who created tiny antenna for my wrist watch. I don't know how, but that Pathfinder able to catch and decode 60 khz wwvb in noisy city environment. And it did even better when i was 500 km north ! :40, Alexander Pummer wrote: here are the other 60kHz transmitters: http://www.ka7oei.com/wwvb_antenna.html U.S. based WWVB transmitter. As described, it could also be used for theUK-based 60 kHz MSF http://en.wikipedia.org/wiki/Time_from_NPLMSF signal formerly the Rugby clock**and the Japanese 60 kHz JJY http://en.wikipedia.org/wiki/JJY_ _our fiend in Australia most likely*_ _*receive the JapaneseWWVB 73 KJ6HUN Alex _*//*_ On 2/21/2014 12:21 PM, Robert Roehrig wrote: John Forster said: WWVB is hard to detect w/ a 3-foot diameter HP shielded loop w/ integral preamp 2 stages of mechanical filters. (HP 117A). The other half of the time it was undetectable. Paul S uses a loop that is much larger. I am near Chicago and I have 2 60 kHz antennas. One is a ferrite rod type and the other a 5 foot diameter loop. Both are tuned and feed identical 2 transistor preamp. The loop does work better. ___ 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] New WWVB modulation format receivers
Its still interesting to read an article from Radio-Electronics Magazine with date stamp back to August 1973. In that article Don Lancaster explain few classical techniques how to handle WWVB band. Regards, V.P. On 2014-02-20 20:42, Clint Turner wrote: Several years ago I spotted a clever PIC-based software (DSP-ish) approach to WWVB modulation - but it has thusfar defied my attempts to find it via Google. It was from the late 90's, early 2000's - and I may have it in an archive somewhere. The exact details escape me, but I believe that it sampled at 8 kHz and was fed a crystal-filtered WWVB signal at 60 kHz, putting this bandwidth-limited, AGC-leveled signal directly into the PIC's A/D. If I've done my math correctly, that would yield a frequency-inverted alias at 4 kHz. The A/D was then mixed and/or decimated significantly and a simple software-based carrier recovery scheme (a Costas loop, maybe?) was implemented in this rather low-end PIC. Because the TRF bandwidth was on the order of just a few Hertz, it took a fairly trivial amount of horsepower to implement. Presumably, at just one baud it should be practical to do this on more modern PICs and AVRs using the same scheme. The trick to homebrewing this is to find a 60.003 kHz crystal - but one of these could be swiped from a WWVB receiver module, or, perhaps, a source-follower could be used to recover the phase component of the received carrier, tapping off the signal from the BPF itself and making it available to the processor. * * * Another scheme - one that I believe was poo-poohed a while back on this list - is to simply take a bandpass filtered sample of around 60 kHz and throw it into a four-quadrant multiplier to yield a 120 kHz signal sans phase shift. I believe that the initial critique of this was that this was not a particularly good way to recover a weak signal, but I found it to be quite useful on a project some (15) years ago. On this project, I had a 100 kHz pilot carrier modulated with NRZ BPSK telemetry data and this same carrier was used to convey the reference frequency to multiple, simulcast transmitters via a 33cm microwave link. At 100 kHz, I simply had an L/C bandpass filter that was roughly 3-5 kHz wide on the transmit (to control the occupied bandwidth when XOR-gate modulated) and a similar filter on the receive end. Listening to this 100 kHz center frequency, 3-5 kHz bandwidth was a 1496 configured as a multiplier, the output of which was passed through a simple filter constructed using 200 kHz crystals. The 200 kHz from the doubler output was then divided-by-two and used to synchronously demodulate the BPSK data (after being filtered with either a Bessel or Gaussian LPF) and this same recovered 100 kHz signal was then made available to the master 10 MHz frequency reference for locking. What impressed me was the fact that my input signal S/N could go about 40 dB below the detection bandwidth of the BPSK signal and still maintain perfect lock on the 100 kHz carrier, despite the fact that the 1496 - which really doesn't make all that great of a doubler compared with other available (but more expensive!) devices was being pelted with 3-5 kHz of garbage when the S/N was purposely compromised. IIRC, the detection bandwidth of the crystal-based carrier recover filter was on the order of a few 10ths of Hz. Yes, the phase did vary with temperature, but the rate-of-change was fairly slow and this fact was inconsequential in our application. * * * The upshot of this is that it should be quite easy to do a simple doubler-based carrier recovery system at 120 kHz (or something else, if it's frequency-converted) and, since it may be a bit tricky to find a cheap 120.006 kHz crystal, use an SCF clocked from a VCXO (or a simple fractional divider/DDS implemented in software) to provide a very narrow detection bandwidth that would satisfy the dynamics associated with the usable signal range over which the WWVB carrier could be reconstructed and the phase data could likely be recovered. The AM output of a standard WWVB clock module could then be used to aid in the windowing of a synchronous demodulator integrate-and-dump filter to recover the phase information and make these two pieces available to something like a PIC or an AVR/Arduino for crunching. In the (likely!) event of a signal that was too weak to recover the amplitude information from the broader-bandwidth WWVB receiver module it should be practical to oversample (say, by 8x) the output of the synchronous demodulator and then infer the timing of the phase change over a period of time since the minimum period of this is well known (1 second!) and such timing could be (initially) autonomously applied with very good stability until the timing of the phase change resolved itself - something that could be correlated with a statistical analysis of the output of the amplitude detector, as well. To a large degree, this sounds like a candidate for a front end
[time-nuts] Maxim DS3232 and I2C
I would like to ask an advise for following: Lets say I have a DS3232 RTC connected by I2C to some MCU. The maximum allowed I2C bus speed is 400KHZ. And I need to read time (HH:MM:SS) from it. It will be THREE SEPARATE REQUESTS for each part (hours, minutes and seconds). My concern: what if I start to read time at the edge, when it will change itself inside of DS3232 ? Potentially, I could get weird results, like hours and minutes stay the same, but seconds has changed. Or even worth - hours is the same, but seconds and minutes has changed. Is there any method to read all three values (HH:MM:SS) by one single requests ? Or is there any other workaround for this issue ? Or it is not issue at all ? Thanks ! -- 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] Maxim DS3232 and I2C
I think I found the information in the datasheet: The read operation can be used to read multiple bytes with a single transfer. When reading bytes from the slave, the master simply ACKs the data byte if it desires to read another byte before terminating the transaction. After the master reads the last byte it must NACK to indicate the end of the transfer and then it generates a STOP condition On an I2C START or address pointer incrementing to location 00h, the current time is transferred to a second set of registers. The time information is read from these secondary registers, while the clock may continue to run. This eliminates the need to reread the registers in case the main registers update during a read As far as I understood, I could specify the address and number of bytes to read. Then I could obtain all necessary fields using one transaction. I tried it - it seems it works. Thanks ! On 2014-02-15 14:19, Chris Albertson wrote: Even on the primitive chips that don't have mutlipbyte reads and buffers. Just read it twice and see it the two reads are the same. On the one in the thousand case where they differ, read a third time. Problems only happen if you are so unlucky to read the time just before the seconds flip over and as I said, you detect a second flip by reading twice. But it appearts this chip is more sophisticated and has buffers On Fri, Feb 14, 2014 at 2:20 PM, d0ct0r t...@patoka.org wrote: I would like to ask an advise for following: Lets say I have a DS3232 RTC connected by I2C to some MCU. The maximum allowed I2C bus speed is 400KHZ. And I need to read time (HH:MM:SS) from it. It will be THREE SEPARATE REQUESTS for each part (hours, minutes and seconds). My concern: what if I start to read time at the edge, when it will change itself inside of DS3232 ? Potentially, I could get weird results, like hours and minutes stay the same, but seconds has changed. Or even worth - hours is the same, but seconds and minutes has changed. Is there any method to read all three values (HH:MM:SS) by one single requests ? Or is there any other workaround for this issue ? Or it is not issue at all ? Thanks ! -- 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 [1] and follow the instructions there. -- Chris Albertson Redondo Beach, California Links: -- [1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts -- 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 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
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
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
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.
[time-nuts] TARP TADD-3 and T-BOLT
Hello, I have a quick question about TADD-3 Pulse-per-Second Distribution Amplifier. Does anybody tried to use TADD-3 with Trimble T-Bolt in the configuration, when its using 1PPS and 10MHZ as TADD-3 inputs. The idea is to use TADD-3 to share BOTH t-bolt frequency outputs. Thanks ! -- 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 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
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
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.
