Re: [time-nuts] Designing an embedded precision GPS time server
On 26/10/17 22:11, Chris Caudle wrote: The processor you mentioned has a Cortex-M7 at 300MHz. has a Cortex-A8 running at 1GHz plus a Cortex-M processor available as a coprocessor. Peripheral set is pretty comparable, and you can buy BBB at retail for $50 which gets you the faster higher class processor, 512MB of DRAM and 4GB of flash. It runs linux right out of the box so you basically power it on and have NTP running. The BB Green is even better value for money, and why would we need HDMI for timing apps ? (It also simplifies doing my Poor man's TIC!) On my list of projects to work on is a cape for BeagleBone Black that takes 10MHz and 1PPS inputs along with a couple of RS232 converters for the UARTs so you can connect a GPSDO to a BBB to make a time server. In my estimation that seemed like the best return on effort. Wheen you get around to it, *Please* consider: 1) multiplying that 10MHz up to 24 MHz as an option 2) RS422 option instead of RS232 (for the Lucent/HP GPS/Rb boxes) 3) PPS routed to TIMER4/5/6/7 rather than any old GPIO 4) Cover _all_ UARTS, even if serial headers are needed, rather than 9-pin D connectors 5) Some method of dropping a 5V PPS down to 3.3V (2N comes to mind, as does a /2 voltage divider [2.5V is sufficient to trigger the GPIO pins], I have done both - and yes measured the delay through the 2N!) (Sorry Chris, I was looking at the serial cape options earlier today to try an santise my lash-ups, and was most disappointed!) Iain ___ 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] inexpensive, black box, GPS or NTP based TTL time capture?
Hi Michael, You Wrote: We are using BeagleBone Black + GPS 1 pps etc in our time-transfer system You can see the overlays in https://github.com/openttp/openttp/tree/develop/software/system/device-tree-overlays Very interesting, I will have to clone the git repo, and have a closer look. I have my own 'fleet' of Beaglebone Blacks and Greens monitoring LORAN and GPS. Working to add my small rubidiums and some LF and HF Clocks as well. One day I will get the time to document the entire thing! I am using the PRUSS to do Time Interval Measurements (details can be found in the list archive), and feeding a PPS via TIMER4, and the highly accurate timer that the Beaglebones have onboard. Is there a particular reason you used the GPIO rather than TIMER4 ? (If your google for Dan Drown DMTIMER, you will find the Linux Driver) He also has coded up the TCLKIN pin, so that you can clock the Beaglebone from an external reference, which also may be of interest. (That bit I still need to do - I have the code enabled, just need to plug a reference in to the Beaglebones!) FreeBSD also has a driver for the TIMER4 input Iain ___ 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] Surplus Lucent RFTG-m-II units in rack shelf
On 12/05/17 07:23, Gregory Beat wrote: As noted by Bob Camp, this Lucent pair has a rubidium standard and OCXO. Since I posted (15 hours ago), he has sold 18 units. Think I just grabbed the last one. Note, judging by the pictures, the 10MHz reference from the Rb is fed to the GPS receiver, and that outputs 15MHz (presumably disciplined). The output on the right hand side of the Rb unit looks to be 15MHz. Also interesting, the splitter appears to have two inputs. I'm guessing that's two splitters, or more likely for this gear, for fail over, and only one output is active. Should be fun to find out. I'm betting more than just me acquired one on this list. Like Gregory, I'd love to see the good/bad/ugly, both in Frequency and Time (It's likely to be two weeks before it arrives here, and I'll not get chance to play until at least the second half of June, so I bet others will get there ahead of me) Iain ___ 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] Anthorn eLoran
On 09/05/17 20:28, moGandalfG8--- via time-nuts wrote: Iain Young wrote: I now have all four with green tracking lights, so looks good to go Thanks Iain, Also looking good here now so seems like I cried wolf after all, although very happy it wasn't anything more permanent:-) I noted this morning, mine were all "Red" again. This very much suggests antenna maintenance (Off while they work on it during the day, and on once they've finished the day's work before starting work on it again the next morning, rather like they do with MSF next door) Iain ___ 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] Anthorn eLoran
On 09/05/17 10:20, Iain Young wrote: Just checked my four Austrons (2 on the "Master", 2 on the "Slave" signal. All four had lost tracking, all four sat at acquire at present, and have been for long enough to suggest they can't lock on. Hopefully it is a fault, or antenna work, I'll give the Austrons another prod later if they don't wake up. Last I heard, eLoran was good until at least the end of 2017 from Anthorn. I now have all four with green tracking lights, so looks good to go Iain ___ 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] Anthorn eLoran
On 09/05/17 07:49, GandalfG8--- via time-nuts wrote: Is anybody monitoring eLoran from Anthorn? Yes It might that there's a fault or the system is down for antenna maintenance, there's no alerts on either these days as there is for MSF, or perhaps it's something longer term. Anyone know what the score is? Just checked my four Austrons (2 on the "Master", 2 on the "Slave" signal. All four had lost tracking, all four sat at acquire at present, and have been for long enough to suggest they can't lock on. Hopefully it is a fault, or antenna work, I'll give the Austrons another prod later if they don't wake up. Last I heard, eLoran was good until at least the end of 2017 from Anthorn. Iain ___ 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] TDF (Was Re: RFDO - Experience and questions)
Hey Paul, My apologies, false alarm, it returned about mid-day French time. I guess they had some extended maintenance work to do, or something that needed daylight Iain On 07/03/17 14:10, paul swed wrote: Thanks I have a sense Tdf is a big question But it's pretty strong here On Tuesday, March 7, 2017, Iain Young <i...@g7iii.net> wrote: On 07/03/17 03:35, paul swed wrote: Actually as I think about it from the earlier part of the thread. Locking to the carrier with a 2-4 second time constant removes the phase modulation since its only in the first 200 ms. The 0 Phase is 800 ms in length or more for all bits. Now to find some nice coils for 162 KHz. You might want to hold off on those coils. I got up this morning to find TDF off air. Hopefully it is just the Tuesday maintenance that is over-running, or just extended maintenance Iain ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/m ailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] TDF (Was Re: RFDO - Experience and questions)
On 07/03/17 03:35, paul swed wrote: Actually as I think about it from the earlier part of the thread. Locking to the carrier with a 2-4 second time constant removes the phase modulation since its only in the first 200 ms. The 0 Phase is 800 ms in length or more for all bits. Now to find some nice coils for 162 KHz. You might want to hold off on those coils. I got up this morning to find TDF off air. Hopefully it is just the Tuesday maintenance that is over-running, or just extended maintenance Iain ___ 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] RFDO - Experience and questions
Hi Gilles, You Wrote: Indeed, the station is located in central France with a very powerful transmitter (up to 2MW). It covers all Europe and it was a real pain for me when they stopped broadcasting the France Inter Station. I understand the French government have a consultation out about what to use the AM carrier for, so maybe another commercial AM station will pick it up. The longwave signal can be received anywhere, even in the basements (ground effect propagation). No need for an external full sky antenna etc… Hopefully they are still operating and sending the time code. They are. I've written an SDR decoder for it, and with it being Phase Modulated, it doesn't suffer from the varying signal strengths of both MSF and DCF. And actually the signal is much clearer today in 2017 than when it was also amplitude modulated. Good news, but how long will it last ... ? Agreed, it's a nice clean carrier now :) I think it will last a good time, Certainly with some of the things that use it in France, I suspect it will be there for some time to come Best Regards Iain ___ 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] RFDO - Experience and questions
On 05/03/17 20:23, paul swed wrote: Gilles what signal is that at 162KHz. A European station? Nice thats its C controlled. That's TDF from France. Their equivalent of WWV/MSF/DCF. Used to carry the AM Station France Inter as well, but that went when France turned off all LW, MW, and LORAN stations at the end of 2016. The Time Signal is Phase Modulated (I have a gnuradio decoder which works very well if anyone is interested) See https://en.wikipedia.org/wiki/TDF_time_signal and https://en.wikipedia.org/wiki/Allouis_longwave_transmitter With no AM modulation, there are obvious benefits with regards to using it as a frequency reference. Average phase and frequency deviation is zero over 200msec (see link above for details) Iain PS, The signal is used by the French railways SNCF, the electricity distributor ENEDIS, airports, hospitals according to the Allouis link above ___ 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] Clock Block Unavaliable - Alternative Solutions ?
Hi All, I noticed that the TAPR site now lists the Clock-Block as unavaliable. This is a shame as I was going to experiment with driving some beaglebones with a 24MHz clock from one, multiplied up from a Rb/GPS/LORAN source this summer Does anyone know of a similiar device avaliable elsewhere (built) ? Or are there plans for a clock block v2 ? I guess I can drive them at 10MHz directly, but it would have been great to push them at 24MHz, however using a HP Signal Generator locked to one of my references seems...overkill :) Iain ___ 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] MSF 60KHz Problems?
Hi Nigel On 03/05/16 15:15, GandalfG8--- via time-nuts wrote: Is anyone else seeing anthing unusual with the MSF 60KHz signal from Anthorn? Can't check from here at the moment, but sounds normal from the WebSDR at UTwente... Iain ___ 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] Best Rubidium Frequency Standard
Hi, OK, so I'm about to show the limitations of my knowledge :) Bob Wrote: On 11/03/16 22:51, Bob Camp wrote: If your target is something like a microwave radio, many Rb’s are > “challenged” in terms of phase noise and/or spurs. Some sort of > cleanup will be needed for almost all of them. Are some models particularly better than others at either phase noise or spurs ? If so, do we know which ones ? Or is it more a case by case basis (damage/maltreatment not with standing...) ? Also, are we "simply" talking LPF/HPF/BPF precautions here ? Or would folks advise doing other things as well ? The microwave radio isn't going to care about delay through any filter [assuming that delay stays constant of course] (Different on the timing side of course) (I looked at the 10MHz output from the KS24361 boxes that Bob posted on here, with all the multiples, and brain simply screamed LPF. Saw the sub harmonic, and it shouted HPF at me!) Iain ___ 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] Loran Europe Lessay seems to be back on air?
Hi All, On 05/01/16 20:03, paul swed wrote: The norm right now is 1 year. Enjoy while you can. On Tue, Jan 5, 2016 at 1:50 PM, GandalfG8--- via time-nuts < time-nuts@febo.com> wrote: Yes, they've been switching back and forth between one or two channels all day, with the one channel state always being just the usual Anthorn Y channel and the two channels always being Master plus the Y channel. Sometimes the overall signal levels have been fluctuating quite a bit at 100 Miles from Anthorn, more so than usual, and when in the two channel state both channels have always been at the same signal level, although on a few occasions the signal has shut down altogether for several minutes at a time. As it's now nearly 1850, and still transmitting Master and slave rather than reverting to just the slave as it did at the end of the day yesterday, I'm even more encouraged to hope this might become the norm for some time at least. I happen to receive the "GNSS Edition of Chronos Times" from chronos.co.uk. While a "newsletter" (read advertisement) style email, the like of which I'm sure we all get from various sources, the following paragraph contained a sentence about the recent European LORAN shutdown. I won't quote the entire "newsletter", but the paragraph in question reads: ---BEGIN QUOTE--- We wish you a happy and prosperous 2016 and welcome to the first GNSS edition of the Chronos Times. Apart from a number of new exciting products shown below, the best news we had just before Christmas was that eLoran transmissions for timing and data services will be maintained going forward. Whilst the rest of Europe has decided to close down its old Loran-C transmitters, the UK has confirmed that eLoran transmissions from Anthorn will continue. This is early days for this new service ---END QUOTE--- So, that's some good news at least. How long for, as Paul says is to be determined, but at least it's positive news Best Regards Iain ___ 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] End of Loran-C in Europe confirmed.
On 17/12/15 10:50, Poul-Henning Kamp wrote: I've spent some time tracking this down, but it looks like all Loran-C in Europe shuts down on new-years eve. The only station I have not found official confirmation for is Sylt, but France, Norway, Denmark and UK have all officially announced shut-down of their stations. Do you have the UK announcement ? I got notification of Lessay, Soustons, and the control station at Brest, but not for Sylt or Anthorn. The UK is (supposedly) supportive of eLORAN, and I thought Anthorn (along with some extra stations on the south coast) were indeed transmitting eLORAN. With eLORAN being backwardly compatible, I was assuming/hoping at lease Anthorn would keep my Austron's busy :) Iain ___ 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] End of Loran-C in Europe confirmed.
On 17/12/15 15:21, Wojciech Owczarek wrote:
I have a memo / stakeholder briefing document from the General
Lighthouse Authorities UK/Ireland (can't see any confidentiality notes
on it), that states:
""
4. Effect if France Terminates eLoran
It is hoped that the RNTF [http://rntfnd.org] commercial initiative
can maintain the continuity of eLoran transmissions from France beyond
the end of 2015. However, in the event that the French and Norwegian
transmissions were to cease, all maritime eLoran Navigation capability
in UK waters would be lost immediately. In addition, the UTC basis of
precise Timing of the Anthorn eLoran transmissions would also be lost,
unless an alternative link to a source of UTC in the UK could be
provided. The Loran transmissions from Anthorn could be continued to
provide precise Timing (with intervention to synchronise transmissions
to UTC) for the benefit of UK and Irish CNI, but the maritime mandate
of the GLA does not cover this intervention. Without French
transmissions and hence with no maritime benefit, the GLA have no
mandate to maintain any eLoran capability in the UK and would plan to
close the service down.
""
Chronos in the UK have partnered with UrsaNAV to form this:
http://taviga.com . The various UK government bodies support eLORAN
and the people involved say they have the capacity to make Anthorn a
master station. They need a UTC reference, but given that the NPL are
transmitting MSF from Anthorn, I would assume that traceable UTC is
already there. All that's left to do is wait to see what actually
comes out of this, but things are looking bleak for now; for
positioning you can't do much with Anthorn alone.
Well quite, MSF is next door (or more likely the next field, but
close enough!)
I found the last words of the UK announcement to provide just the
hint of a little hope ("until further notice")
http://www.rin.org.uk/newsitem/4273/eLoran-to-become-commercial?
also provides at least a little hope for the future even if, as you
say, the immediate future looks bleak.
I suspect Chronos are not going to want to lose their eLORAN revenue
stream - they have what look like some very nice devices.
With the various UK Government bodies supporing eLORAN, and the amount
invested already, I hope that a solution can be found before too long.
Iain
___
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] Phase noise from Allan Deviation ?
Hi Tom, On 14/12/15 03:15, You wrote: I've constructed a homebrew setup to measure time intervals using a software defined radio. Basically a single-channel downconversion to about one hertz, then count samples from the SDR clock to time stamp the zero crossings. This is done in gnuradio and saved to a file for post processing. The resolution is theoretically good, but the accuracy is unknown. Very interesting. Would you consider making your flowgraph available ? I have done similar things with just thresholding and looking for the start of second (or minute) marker of various distant radio clocks, and then graphing how far apart they were, as well as feeding NTP. 73s Iain ___ 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] Lessay and Soutons French LORAN Stations Shutting Down
On 11/12/15 15:50, Bob Camp wrote: Hi Yes, the Austron (at least the one I ran back in the 80’s) really does not care if it has a master or not. If you want traceability of the signal, it needs the master. Ah great. Navigation wise, the slaves become useless once the master for that chain goes off the air. Unless there is a new master set up, the slaves will be shutting down fairly soon. Anthorn is eLORAN anyway and thus backwards compatible time wise, so won't be going away any time soon - In fact the UK Government is strongly pro eLORAN, so all is not quite lost. Maybe Anthorn will just become a master. Sylt is joint funded by the UK, Germany, and France, so hopefully that will continue, or even switch to master on 6371 as well as 7499 Iain ___ 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] Lessay and Soutons French LORAN Stations Shutting Down
Hi Folks Received this sad message re Lessay and Soustons LORAN stations. Would guess that France-Inter/TDF won't be far behind, as IIRC France had decided to cease all LW transmissions, but I still hope :) > CONTROL CENTER BREST AND THE TWO FRENCH LORAN STATIONS (LESSAY 6731M/7499X AND > SOUSTONS 7499X) > WILL CLOSE DEFINITIVELY THE 31st OF DECEMBER 2015 AT 1100 UTC* A real shame, as for me Lessay is stronger than Anthorn for me With the 6731 Master off air, anyone know if The Austron 2100's will be able to lock onto the remaining slaves at Anthorn and Sylt on the 6731 chain ? (I guess I could lock onto the Sylt master on 7499, but Anthorn would be more reliable from here...) Anyone receivbed purely a slave station with the Austrons w/o being in range of the master station ? Iain ___ 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] measuring os latency for pps
On 25/08/15 18:53, Andrew Symington wrote: Hi Folkert If you have a board with a hardware timer that supports load/match/compare then you can schedule an external interrupt to be generated at a predetermined point in the hardware count. Thus, if you know the transform between your disciplined clock and the hardware counter of the timer that drives it, then you should be able to do this. I have spent some time working with the (pretty neat) timers on board a beaglebone black, and I've written some code to setup input capture and compare on up to 4 timers: https://bitbucket.org/rose-line/roseline/src/35d551bf29e4bfec80f8ba667b199c8aa333b87f/core/modules/roseline.c?at=master Wait...You mean with your driver I essentially have a A-B-C-D TIC ? _THAT_ I have a use or three for... Since there is also code out there to drive a BBB from an external reference via TCLKIN, this gets very interesting. I might just have to compare your code against my own TIC code using the PRUSS (Although that's only a traditional A-B or A-A TIC at the moment, extending to 3 or 4 inputs would decrease the precision and accuracy...) On Tue, Aug 25, 2015 at 8:24 AM, folkert folk...@vanheusden.com wrote: Hi, Not sure if it is interesting for you guys but I wrote a simple program for e.g. Linux (or any other system with the pps api implemented) that listens on a pps source waiting for a pulse and then toggles a gpio pin. That way you can measure the latency introduced by the the kernel when listening from userspace. Note that there's a little extra latency due to the gpio-pin handling. Oh this might be very interesting, esp with something like the BBB, which has the excellent counters that Andrew discusses above. Presumably it is a five minute job to modify your code to do something other than twiddle a GPIO pin. It would be very useful to try and characterise that kernel delay. I will add it to the list of things to try, once I finish moving the time lab around! Iain ___ 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] wtd: WWVB info
On 07/08/15 07:18, Charles Steinmetz wrote: Bob wrote: Well, at least *some* of the chips out there do not make it to 96 KHz when sampling at 192 KHz. Its been a few years since I dug into them. Back then a chip that had an internal filter that went to 96K was very much the exception rather than the rule. If the only point of 192K is getting to a 96K bandwidth, a lot of the chip guys missed out on it . 192k *audio* ADCs often have input anti-aliasing filters that are only 20-50kHz wide. In that case, the point of sampling at 192ks/S is so the anti-aliasing filter does not need to have a brick wall response (as it would need to have if you sampled at 48 or even 96ks/S), so it can have a flatter group delay over the range of human hearing. I guess I got lucky. The machine I brought specifically for SDR work ended up with an (on board) 192kHz sample card, that appears not to have such filters in. http://hal.g7iii.net/vlf/vlf1.png and http://hal.g7iii.net/vlf/vlf2.png You should be able to spot MSF and DCF booming in amongst the low data LF stations (and odd sprog). This is off my LF antenna, but a long wire may be sufficient (In fact a 2M long feed wire to the mic socket was picking up both time signals by itself for me, but that's another story!) While not decoding the phase, my gnuradio MSF and DCF receivers are here: http://hal.g7iii.net/GRC/Radio_Clocks/ I do have a gnuradio TDF decoder as well if anyone is interested. TDF twiddles the phase on a AM carrier to transmit the time. Originally I simply used an LPF, but then switched to using the Quadrature Demod block which was available in gnuradio Iain ___ 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] Loran and SRS FS700 in the UK
On 10/07/15 22:39, GandalfG8--- via time-nuts wrote: This is a reply to the topic Loran-C reception in the UK with specific emphasis on the Stanford Research FS700. Apologies for starting a fresh topic but I'm still not able to take emails from the list due to incompatibility problems with AOL and I don't see how to reply to an existing subject directly from the archive, if anyone knows how to do this please let me know. There is an excellent reference to eLoran in the UK, including downloadable publications, starting here.. http://www.gla-rrnav.org/radionavigation/eloran/index.html As far as I can tell, the Lessay chain, which includes the UK station at Anthorn, is currently transmitting eLoran, with the extra data channel, rather than Loran-C but this is totally backwards compatible and the FS700 runs fine here, as does the Austron 2100 series. This is why it's difficult to find specific GRIs quoted for eLoran as opposed to Loran-C, it's effectively the same network, using the same transmitters and GRIs. Right, so GRI 63710. I had heard a while back that there were some extra transmitters on the south coast specifically for eLORAN, but finding the ED's or if they are on the same GRI has proved fruitless so far. Iain ___ 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] LORAN-C reception in the UK
On 10/07/15 21:46, ken hartman wrote: from: http://gpsworld.com/eloran-progresses-toward-gps-back-up-role-in-u-s-europe/ “Both Norway and France have declared an intention to cease Loran transmissions at the end of 2015. Moreover, France intends to dismantle its Loran infrastructure in 2016. Arrangements for the commercial operation of the infrastructure are being investigated, but this depends on some form of regional agreement. The European Union appears to have no policy for resilient PNT, the European Radio Navigation Plan having twice been drafted but never published. The view seems to bee that the introduction of Galileo will achieve resilient PNT, which it will not.” Hmm.I knew about Norway (to be honest, the Noreweigan stations being so far away that I can't hear them anyway), but France ceasing transmissions is new. That might be interesting with Anthorn currently a slave to Lessay. I suspec the Arrangements for the commercial operation of the infrastructure are being investigated means France wants to privatise the operations. Anthorn is already privately operated. Hopefully a deal can be done Iain ___ 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] LORAN-C reception in the UK
Hi David On 10/07/15 13:14, Dr. David Kirkby (Kirkby Microwave Ltd) wrote: How good/bad would a LORAN-C frequency reference such as the Stanford Research FS700 work in the UK? I live about 60 km to the east of central London. My Austron 2100's lock on to Anthorn, Lessay, and Sylt. I'm in Coventry, about ~330km away from both Anthorn and Lessay Is there any future for LORAN-C in the UK? Don't think it's going away. The UK is rolling out eLORAN, which I thought is backwards compatible with LORAN-C (I believe it uses the 9th pulse for data) What I'm having trouble finding is any references to GRI's for eLORAN - and I'm sure I saw one reference say that it didn't need them, so I'm not sure on it's timing use, or the ability to sync with UTC due to ToC Others, better versed than I might have more info. Iain ___ 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] HP-117A and MSF ?
Hi All, Has anyone considered using (or even used) a HP 117A for receiving and/ or measuring MSF ? I had one of those mad idea evenings last night after comparing MSF to the Greenwich Time Signal for a few days (More info on my next post...) But back to the mad idea, I thought I might use a 117A to: o compare MSF against my three LORAN boxes (Yes the 1Meg would need to be divided down...) o Use the Signal Level 1/4 stereo phone jack and a resistor to feed a time decoder, for yet another clock, just to help justify having the 117 [and to compare my SDR decoders to of course...] :) The potential issues I thought of (so far) are: o 50Hz vs 60Hz power. Not really a big issue, I can get converters to solve this one. o Being a TRF receiver, and with me only having an LF whip with pre-amp, I'd need to add filtering, but again not the end of the world. o 30V on the antenna line. Seems that I may be able to use the test connector. Alternatively, a Bias Tee, or just cutting the DC supply to the antenna connector should suffice, I can't believe it would be that hard o MSF off time. Now this might be a bit more of a problem for phase measurements, MSF doesn't just reduce the carrier like WWVB and DCF, but drops it entirely. Anyone know if this would just give me interruptions to the comparisons, during the 100-300 msec off times, or would it entirely mess up the comparison with the house standard ? I'm guessing it would depend on if MSF just cuts the carrier from the output stages or if they stop the actual carrier generation... Any other issues I might run into other than the usual aging issues and so forth ? Iain ___ 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] FYI: Galileo satellite recovered and transmitting navigation signals
On 05/12/14 22:40, Bob Camp wrote: Typically they let you selectively enable each of the major systems. As you enable more systems, you get more sat’s in each of the messages. For most users, there is not a lot of reason to enable multiple systems. If you want UTC sync’d to USNO you enable one system. If you want to set your watch to time from Moscow, you enable another system …. Setting your watch to both is impractical. Time-nuts will buy multiple, enable one major system on each, and compare, and draw ADEV plots! Iain ___ 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] Beaglebone Black driver for hardware timer capture
Hey Dan, You Wrote: I wrote a kernel driver for the BBB timer hardware. It produces pps events for things like ntpd to consume. The source for it is at https://github.com/ddrown/pps-gmtimer A side effect of this driver is it measures the interrupt latency and jitter on the BBB hardware. The attached file interrupt-latency.png contains an interrupt latency histogram and cumulative distribution function. This interrupt latency should be similar to what the pps-gpio driver experiences on this hardware. The difference is the timer hardware driver can remove the effects of the interrupt latency. The graphs of offset over 7 days worth of samples don't show a huge difference. The *-timer.png file is from pps-gmtimer and the *-gpio.png file is from pps-gpio. The stddev of the offsets are 244ns from the gpio run and 143ns from the timer run. Great work. I will have to try this driver, I've been using the FreeBSD equivalent, it's good to see someone has actually done the Linux version as well now. That will be anoŧher Christmas/New Year project! The BBB hardware supports hardware IEEE1588/PTP timestamps, so people might be interested in that as well. The driver for it is already in Linux, but not enabled in the default BBB kernel config. Indeed, this support is still missing in FreeBSD, and the PRU support is much more mature on linux (although it does work on FreeBSD, I had some issues with working out what was going on at times, but that might well have been operator error without time to debug) Let me know if you have any questions. Is your code able to support multiple inputs simultaneously ? FreeBSD's doesn't due to some architecture issue with the timing subsystem as I understand it. Or is it like the FreeBSD code, and I have to select exactly one of TIMER4-TIMER7 input pins to drive the PPS ? The Beaglebone also has the facility for an external clock input. Are you planning on doing any work in order to get the Linux kernel to select the TCLKIN as the clock ? Best Regards Iain ___ 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] BeagleBone Black DDMTD update
Hi Simon, On 29/10/14 20:15, Simon Marsh wrote: This is a fairly long post, at the top is a bit of description of of changes since my last posts and then around the middle is some description of the data thats attached. The data raises a few questions, and I'll put those in a separate post. Do you have any code to share ? Or did I miss it ? All the Best Iain ___ 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] GPS for ntp
It's been done on FreeBSD. See: http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html Patch is now in recent FreeBSD releases/snapshots And yes, it's far superior to than using the GPIOs, or UARTS There was some work done on Linux, but I'm not sure it was ever finished or published. All of my Timing Beaglebones run FreeBSD, with the exception of the TIC stufff I wrote for the PRUSS's. As soon as the userspace bits of that work on FreeBSD, I'll probably switch that to FreeBSD as well. All the Best Iain On 21/10/14 13:33, Neil Schroeder wrote: Andrew- I'm actually referring to using either the eCAP function or one of the integrated dmtimer triggers - which are, from some accounts, more accurate than a gpio. Google beaglebone dmtimer pps. NS On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland and...@cleverdomain.org wrote: On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPS for ntp
It just turns up as /dev/pps0 like any other PPS source, so you configure ntp in the same way you would for any other PPS source, or build ppsapitest to test it manually (Although be aware you -may get a Invalid argument error from ppsapitest after running it more than once. Reboot solves it, and since the BBB's don't do anything else, and I don't restart ntp too often, its not a big deal for me.) Iain On 21/10/14 14:58, Simon Marsh wrote: Iain, How do you map the timer counter value in to a PPS timestamp ? (that is, how do you turn the HW counter value in to what the OS thought the time was when the event occured ?) Cheers Simon On 21/10/2014 13:54, Iain Young wrote: It's been done on FreeBSD. See: http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html Patch is now in recent FreeBSD releases/snapshots And yes, it's far superior to than using the GPIOs, or UARTS There was some work done on Linux, but I'm not sure it was ever finished or published. All of my Timing Beaglebones run FreeBSD, with the exception of the TIC stufff I wrote for the PRUSS's. As soon as the userspace bits of that work on FreeBSD, I'll probably switch that to FreeBSD as well. All the Best Iain On 21/10/14 13:33, Neil Schroeder wrote: Andrew- I'm actually referring to using either the eCAP function or one of the integrated dmtimer triggers - which are, from some accounts, more accurate than a gpio. Google beaglebone dmtimer pps. NS On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland and...@cleverdomain.org wrote: On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPS for ntp
Hi Simon, Ah, slightly different question :) I'm afraid I didn't write the code, so I can't really answer that question. What I can say is that it does appear to be as good as Ian (Lepore's) ntpq output shows. To be honest, I just use the code :) Iain On 21/10/14 15:39, Simon Marsh wrote: Sorry, I wasn't clear. The /dev/pps0 devices output a timestamp corresponding to when the event happened. The GPIO driver does this very simply by waiting for an interrupt event and then asking what (current) time it is. This leads to the problem that there is a non-deterministic time between the event and when the code gets to ask 'what time is it ?' With HW capture, you can get an accurate view of when the event took place but only relative to the counter in the particular timer/capture unit that is being used. You have to synchronise between the counter value and what the OS understands is 'system time' in order to create a retrospective timestamp for when the event occured. Whilst you've solved the problem with the interrupt approach, you've created a different one of needing to synchronise counters. My question is how do you convert between the timer value and system time to get the timestamp ? Cheers Simon On 21/10/2014 15:14, Iain Young wrote: It just turns up as /dev/pps0 like any other PPS source, so you configure ntp in the same way you would for any other PPS source, or build ppsapitest to test it manually (Although be aware you -may get a Invalid argument error from ppsapitest after running it more than once. Reboot solves it, and since the BBB's don't do anything else, and I don't restart ntp too often, its not a big deal for me.) Iain On 21/10/14 14:58, Simon Marsh wrote: Iain, How do you map the timer counter value in to a PPS timestamp ? (that is, how do you turn the HW counter value in to what the OS thought the time was when the event occured ?) Cheers Simon On 21/10/2014 13:54, Iain Young wrote: It's been done on FreeBSD. See: http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html Patch is now in recent FreeBSD releases/snapshots And yes, it's far superior to than using the GPIOs, or UARTS There was some work done on Linux, but I'm not sure it was ever finished or published. All of my Timing Beaglebones run FreeBSD, with the exception of the TIC stufff I wrote for the PRUSS's. As soon as the userspace bits of that work on FreeBSD, I'll probably switch that to FreeBSD as well. All the Best Iain On 21/10/14 13:33, Neil Schroeder wrote: Andrew- I'm actually referring to using either the eCAP function or one of the integrated dmtimer triggers - which are, from some accounts, more accurate than a gpio. Google beaglebone dmtimer pps. NS On Mon, Oct 20, 2014 at 11:56 PM, Andrew Rodland and...@cleverdomain.org wrote: On Mon, Oct 20, 2014 at 10:50 PM, Neil Schroeder gign...@gmail.com wrote: The one thing that hasn't yet happened is making the beaglebone timestamp on the linux side in a way that works for ntp. Custom code no problem. Freebsd PPSAPI no problem. Linux, nothing there yet. I have been working on it but if anyone has some insight its appreciated. It appears to support gpio class devices, with interrupts, so the pps-gpio driver (in-tree since 3.2) should work just fine. The only thing that's needed (other than building the driver) is a bit of code in the board support file to register the device. Various folks have done it for the rpi (http://ntpi.openchaos.org/pps_pi/ for example), and I've done it for the UDOO Dual (https://gist.github.com/arodland/518f037e4f24b1984286). The BBB is probably about as easy. I'm not sure if there's other hardware that lets you do better than grabbing an interrupt, but that will get you in the microsecond range or a bit better, anyhow. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin
Re: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
Hey Paul, Grab the tarball, it contains each of the other files in that directory. And yes, the README tells you what you need to do. Note you will need the PRUSS compiler end probably the AM335x PRU Package to compile. Google for it, or grab this one via git: https://github.com/rjw245/am335x_pru_package/ [Not mine, but used the inputtest example as a base]. Dump the files in the inputtest directory (or create a new one at the same level), then do the pasm and make stuff. To get started quickly, tic_ab_dualpru, tic_ab_pru0.bin, and tic_ab_pru1.bin, and just run tic_ab_dualpru. This will work on a BBW. I am currently playing with it on the BBB, and have discovered I can go to 10ns resolution, but the code needs adjusting (seems the PRUs might be running at a different speed to the BBW, I need to investigate!) I also still have the 10-11uS issue mentioned below, but I am unconvinced I have the pin-mux settings quite right yet (I think they are being passed back through the SOC-fabric, thus slowing things down!) I'll probably post an update over the weekend (not had chance to play all week due to work commitments) Iain On 05/09/14 20:09, paul swed wrote: Ian what files are needed? Forgive me if its in the read me. Thanks On Fri, Sep 5, 2014 at 2:56 PM, paul swed paulsw...@gmail.com wrote: Ian Have not downloaded the info yet. But I was surprised by the fact you were using LORAN sooo you must be in Europe. Lucky you to have such a fine signal. Great job on the tic. Now to go download the bits. Thanks again. Regards Paul. On Sun, Aug 31, 2014 at 10:26 PM, Tom Van Baak t...@leapsecond.com wrote: Hi Iain, Thanks very much for posting, and for sharing the code. I know many of us are interested in how well modern CPU's or SBC's can be used as time interval, time stamping, and frequency counting instruments. I know the BB PRU's have been mentioned before on the list but it's really nice to see actual code and test results. About the hp 5370 -- realize that these are still 1000x more precise (on the order of tens of ps) than what a BB/PRU is capable of (on the order of tens of ns). But as you observe, they key point is -- for mid- to long-term measurement of free-running time/frequency standards you do not necessarily need ps-level measurement capability. Nanosecond, or even microsecond time resolution is more than enough to create comprehensive plots of time and frequency drift over the long-term. Again, thanks. /tvb - Original Message - From: Iain Young i...@g7iii.net To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Sunday, August 31, 2014 1:24 PM Subject: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU) Hi Folks, As much as we all love our HP 5370B's, they are a tad expensive if you want to monitor several PPS sources long term to ensure they are all closely syncronised. In my case, I have three Austron 2100 LORAN receivers and a HP Z3816A GPS receiver. I wanted to be able to compare each of their PPS outputs with the PPS output of the Z3816A, as well as each other. Clearly, multiple 5370's would have been too expensive, not just for initial outlay, but also ongoing electrical costs would not be helped! However, the Beaglebone (Both White and Black variants) have two PRUs. These are real-time units, with clocks that run at 200 MHz, and most instructions complete in 1 clock cycle (5ns) So, I decided to write a TIC in the PRU Assembler to scratch my particular itch. The current code waits for the A clock to go high, and then counts until B goes high, resets it's counters, and waits for A to go high again. It also keeps track of a sequence number for sanity's sake, and onward processing. Since the Beaglebone's have two PRUs, I have written the code to run on both at the same time, and use different GPIO pins, so you can compare up two sets of two clocks, or two clocks with a common reference. Pins are documented in README.txt Now, it's resolution is 20ns. However, it gets confused if the two pulses are less than around 10-11uS apart. I -think- this is when it sends the data back to the host processor via shared RAM. In my case, this is not an issue, as I can just slew the PPS from the Austron's (or even use the Fixed PPS), but if you wanted to compare two GPS receivers, then that would be an issue. I'll have to look if there's a better way to do the shared memory stuff (interrupts, signaling etc), or store multiple intervals and send them all at once, although the current code seems pretty tight. I'd like to have tried it with 1MHz, 5MHz, and even 10 MHz clocks, as 20nS resolution will handle that, but I think I need to fix the 11uS separation issue first. Then again, it was written to compare PPS's from different Austron 2100's and GPS. It also took less than 24 hours from concept to running :) If anyone wants it, the code is here here: http://hal.g7iii.net/bb_tic/ You will need the pasm compiler, and probably
[time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
Hi Folks, As much as we all love our HP 5370B's, they are a tad expensive if you want to monitor several PPS sources long term to ensure they are all closely syncronised. In my case, I have three Austron 2100 LORAN receivers and a HP Z3816A GPS receiver. I wanted to be able to compare each of their PPS outputs with the PPS output of the Z3816A, as well as each other. Clearly, multiple 5370's would have been too expensive, not just for initial outlay, but also ongoing electrical costs would not be helped! However, the Beaglebone (Both White and Black variants) have two PRUs. These are real-time units, with clocks that run at 200 MHz, and most instructions complete in 1 clock cycle (5ns) So, I decided to write a TIC in the PRU Assembler to scratch my particular itch. The current code waits for the A clock to go high, and then counts until B goes high, resets it's counters, and waits for A to go high again. It also keeps track of a sequence number for sanity's sake, and onward processing. Since the Beaglebone's have two PRUs, I have written the code to run on both at the same time, and use different GPIO pins, so you can compare up two sets of two clocks, or two clocks with a common reference. Pins are documented in README.txt Now, it's resolution is 20ns. However, it gets confused if the two pulses are less than around 10-11uS apart. I -think- this is when it sends the data back to the host processor via shared RAM. In my case, this is not an issue, as I can just slew the PPS from the Austron's (or even use the Fixed PPS), but if you wanted to compare two GPS receivers, then that would be an issue. I'll have to look if there's a better way to do the shared memory stuff (interrupts, signaling etc), or store multiple intervals and send them all at once, although the current code seems pretty tight. I'd like to have tried it with 1MHz, 5MHz, and even 10 MHz clocks, as 20nS resolution will handle that, but I think I need to fix the 11uS separation issue first. Then again, it was written to compare PPS's from different Austron 2100's and GPS. It also took less than 24 hours from concept to running :) If anyone wants it, the code is here here: http://hal.g7iii.net/bb_tic/ You will need the pasm compiler, and probably the am335x PRU package, although there are (tiny) binaries there as well Setup, Compile, and Running instructions are included in README.txt Oh, Sample output: PRU0: Seq No:848 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:849 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:850 Interval:11700 ns or 0.11700 seconds PRU0: Seq No:851 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:852 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:853 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:854 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:855 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:856 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:857 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:858 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:859 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:860 Interval:11660 ns or 0.11660 seconds PRU0: Seq No:861 Interval:11660 ns or 0.11660 seconds You can plainly see the Austron has a jitter of around +/-20 ns from the GPS PPS (figures confirmed with the 5370). Slew was around 11.5us. I must wire up the other two Austron's but will need to build a new BB image first :) Hope someone else finds the code useful. Iain ___ 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] FYI: NPLTime® - a new service providing a precise time signal directly traceable to Coordinated Universal Time (UTC) and independent of GPS.
On 14/08/14 17:24, David J Taylor wrote: The National Physical Laboratory (NPL) has signed a distribution agreement with trading technology company Intergence to deliver NPLTime® - a new service providing a precise time signal directly traceable to Coordinated Universal Time (UTC) and independent of GPS. More: http://www.npl.co.uk/news/intergence-invests-in-npltime?utm_source=measurementnewsutm_medium=emailutm_campaign=august2014 Heh. I saw this, and in fact remember it being mentioned at NPL when I was there in May for their openday. I'd love it, but I dread to think what the cost is, and I suspect I might get a few odd looks when they realised they were delivering to domestic premises! Best Regards Iain ___ 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] Software Defined MSF and DCF Receiver
Hi Folks, While not exactly nanosecond class, I thought at least some of you might be interested in my latest experiments with writing a MSF and DCF decoder in SDR (gnuradio in this case) The gnuradio flowgraph is shown here: http://hal.g7iii.net/GRC/Radio_Clocks/Multi_Radio_Clock_Receiver.png (The GRC file itself is also there for those who wish to play with it in the gnuradio companion, along with some prototypes) This tunes to 250Hz off the carrier, and uses a Goertzel filter at 250Hz to detect it. We then do a Complex to Mag^2 to effectively get rid of any negative values, before a threshold block essentially converts the signal to a square wave (via a moving average to help with interference and noise, as well as general signal level changes throughout the day] The eventual output is a 1 kHz stream of 1s and 0's, sent via UDP (You will notice the significance of the port numbers selected - 12360 and 12377 in the flowgraph :)]. A separate application (currently using nc and stdin/stdout) looks for the Start of Minute marker, then grabs the rest of the second's data. Once completed it decodes[1] it, and sends it on to NTP via the SHM driver. This code is currently running on the same machine, but could be run on any capable UDP host. I intend to try it on a beaglebone[2], and see what the difference is. Now, I was expecting some pretty awful jitter etc, but have been rather surprised. Here are a few random ntpq outputs taken over a few hours (nothing scientific): ntpq pe remote refid st t when poll reach delay offset jitter == SHM(0) .MSF.0 l7 64 3770.0006.622 0.859 SHM(1) .DCF.0 l6 64 3770.000 -3.321 0.900 *cerberus.local 192.36.143.153 2 u 15 64 3770.061 -0.265 0.347 ntpq pe remote refid st t when poll reach delay offset jitter == SHM(0) .MSF.0 l 13 64 3770.0006.932 0.193 SHM(1) .DCF.0 l 12 64 2770.000 -2.913 0.107 *cerberus.local 192.36.143.153 2 u 255 256 3770.0990.606 2.365 ntpq pe remote refid st t when poll reach delay offset jitter == SHM(0) .MSF.0 l 10 64 3770.0007.062 0.146 SHM(1) .DCF.0 l9 64 3250.0007.193 3.888 *cerberus.local 192.36.143.153 2 u 174 256 3770.0990.606 4.162 Both radio clocks were set to noselect. cerberus was serving as a reference, and was talking to a cesium over the internet, but for this experiment was more than sufficient. The jitter and offset figures are far better than I had been expecting, and more than sufficient for numbering the seconds and Time-Of-Day, before a PPS source takes over (See [2]). They are also far better than I had been getting from one of the available modules For anyone wanting to try this, the hardware was simply my LF Antenna/Preamp [which primarily does LORAN duty, but has a 4 way splitter on the end], plugged into my 192k soundcard. Those in UK/Europe may get by with a long wire (I haven't tried it yet - my own has other duties right now), but I could audibly still detect MSF with it when I did a quick check] If HF ever recovers here, I shall have a go at detecting and decoding the MIKES IRIG station in Finland on 25 MHz. I'm also trying to write a flowgraph for RBU, but that it proving a challenge (it uses 100Hz and 312.5 Hz tones to indicate 0 and 1 in the time code, but even with SDR techniques it's difficult to separate the two, not to mention it's far less powerful and further away than both MSF and DCF from me. Iain [1] At present, this code is a lash up. It doesn't check for leap seconds, will break come the 3rd weekend in October here in Europe, and doesn't check Parity. That said, the decoding is so solid for me, that even when (usually the DCF side) decodes things incorrectly it's so far out, NTP just laughs at it. I'm lazy. The RF code was far more interesting to write than is this bit set, is that bit set ? :) [2] Said beaglebone currently has a PPS input from an Austron 2100 locked to Anthorn, but needs an internet host to set the time-of-day ___ 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] BeagleBone Black NTP server
On 10/05/14 03:32, Brian Lloyd wrote: That may be the case for the Angstrom distro but it is not the case for the Debian distro, which seems to be the future direction of BBB. It's an aptitude install away, although you may want to build from source to ensure all ref clocks are enabled (esp the ATOM PPS driver, may not be enabled in the default build. ___ 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] BeagleBone Black NTP server
On 10/05/14 04:49, Paul wrote: I use stacking headers (the wrong way) to lift the cape. I'd rather have the console port than be able to close a case. Add a getty on one of the other serial ports :) Or manage via ssh over the LAN :) [Yes, okay, you don't get access to early boot, but to be honest you shouldn't be needing that very often] Best Regards Iain ___ 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] BeagleBone Black NTP server
On 10/05/14 04:38, nuts wrote: Note a bug on the BBB is if you use a cape, it blocks the connector to the serial port. The serial port ? I assume you mean the UART0, aka the console ? There are 5 others to choose from (UART3 doesn't have all the pins brought out from the but makes a great PPS or MSF/DCF input) Those 5 are brought out to P8 and/or P9. You may have to twiddle some pinmux, and lose access to the HDMI and onboard MMC, depending on which port you choose, but you can stilll use the SD card slot. Why would you want HDMI on an NTP server anyway ? These days, you just load the appropriate Cape firmware (Yes, even if you don't actually haver a serial cape, the firmware essentially twiddles those pinmux's for you. Now, the BBB has a better PPS input. The TIMER4-TIMER7 inputs can be used, *IF* you are willing to run FreeBSD rather than Linux. See: http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html (Note, no need for patches now, just grab the snapshots from ftp.freebsd.org. the patch is in there) I _think_ it's also in the latest releases, I'd need to check to be sure though. I know there was some work done on a similiar facitility for Linux, but not sure if the Author has had the time to finish the work. I have my BBBs fed from my Austrons via a 5V-3.3V voltage divider. One thing I'd like to try is feeding the BBB the 10MHz clock from the Austrons, as it also has an External Clock Input Pin (TCLKIN), but that will need some kernel work to select the external clock. It may also need further work in uboot. Treat the BBB and Pi just like any other Linux box :) Iain ___ 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] Beaglebone NTP server
On 26/03/14 23:18, Brian Lloyd wrote: Well, yeah. I figured that I would run the 1pps from my T-bolt to a GPIO line with appropriate clamping to 3.3V. But if anyone has done this before and run into anything of note, that would be nice to know ahead of time. Can I suggest you consider FreeBSD ? You can use the TIMER4-7 input pins as PPS input for a better PPS. See the following URL for details: http://lists.freebsd.org/pipermail/freebsd-arm/2013-February/004769.html If I recall correctly, the patch is in the FreeBSD 10 snapshots for the Beaglebone, so you don't need to apply it, but you will need to enable PPS and ensure one of the four TIMER pins is set to input in the DTS and recompile. Iain ___ 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] nortel trible NTBW50AA boards SCPI command access
Hi Mark On 13/09/13 13:26, Mark C. Stephens wrote: One obvious use for the SCPI port could be for NTPD. The NTBW50AA is lacking 1PPS but has a very accurate 2 Hz pulse ideal for NTPD. 2Hz ? I thought it they were a pulse on the even second, thus actually 0.5 Hz ? I wonder how the PPS Driver in NTP would react to that (either 2Hz, or 0.5Hz pulses). I guess if it really is 2Hz, then one of Tom's PICs could be used to drop it to 1 Hz But if it's 0.5 Hz, I wonder if a modification to the ATOM driver or underlying PPS code would be needed Or is the 2Hz signal coming off the SCPI port ? Iain (and yes, like others, I am interested) ___ 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] eLoran announcement in the UK
On 17/07/13 17:27, David wrote: Not the first time this has been mentioned but another confirmation of the GPS alternative and eLoran stations to be rolled out across UK http://eandt.theiet.org/news/2013/jul/eloran-rollout.cfm?utm_source=Adestrautm_campaign=E%26T%20News%20fortinightly%20-AUTOMATION%20VERSION-%20membersutm_medium=Newsletters-E%26T%20Newsutm_content=E%26T%20News%20-%20Membersutm_term=http%3A%2F%2Feandt.theiet.org%2Fnews%2F2013%2Fjul%2Feloran-rollout.cfmutm_contact=17085095 Now this will be interesting. My -understanding- is that eLORAN is backwards compatible with LORAN-C, (So an old LORAN receiver will still receive the eLORAN signals, you just wont get the extra features [low rate data transmissions, timing built in, rather than relying on TOC etc]) Now if only they'd stop playing with Anthorn during the day at the moment, I could do some more tests. Ah well, I'll get to it later, it'll be cooler then anyway! Iain ___ 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] eLoran announcement in the UK
On 17/07/13 17:55, Bob Camp wrote: There are multiple European chains running that can be picked up from the US. They all are in the skywave zone distance wise. Checkout http://www.loran-europe.eu for details. Iain ___ 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] looking for low-power system for gps ntp timekeeping
On 02/07/13 06:43, NeonJohn wrote: Before anyone wastes his money on a BeagleBone, I suggest you join the mailing list and read the hundreds of messages each day that pass through, most of them citing problems, mostly with the Linux implementation. Basically, the ancient implementation of Angstrom Linux is a POS. Just barely enough code to be able to say, for example, that SPI works. It does - sorta - but not well enough for any application where clock timing or jitter matters. You are not restricted to just Angstrom. My fleet run Debian. FreeBSD is also available. First thing I do is blow away Angstrom from any SD card. I had intended to embed the BB white in my next revision induction heater. After several months of frustration and a considerable amount of money to a kernel programmer to write drivers that actually worked, I gave up. I could easily had a man-year in the application that I can do bare metal in a few months. Hmm, is this a case of Angstrom being beind the kernel curve, or is it still an issue when running things like Debian ? I've not had the need to use SPI on the BB yet, only the Pi. The thing that finally canned the BB for me was the short SD card life. Even though the implementation uses a virtualized root file system, it still writes to the SD card about once a second. The result is that even industrial grade SD cards rarely live over a year. With the Black they tried to address the problem by putting some NAND memory on board but that only prolongs the problem and with components that are not easily changed. I've only ever had one SD card go dead on me on my entire fleet, and I suspect that was actually my fault, not Debian's :) A final negative is the support. The team member, a guy named Gerald, who provides official support on the mailing lists is one of the most hateful persons I've encountered on the net. No, I never personally had an encounter with him but I daily shook my head in amazement that TI would let such a person rep them. I've heard he can be somewhat robust to deal with. That said, he is very knowledgeable from what I've seen/understand. Never actually had to mail the mailing list itself though - found all the answers I needed in the archive - often from him! PS: Before you go to buy the Black, take a careful look at what all they left off in an effort to compete with the Pi. Hmm. I checked a lot of the things I'd need on the black for this type of application, and found they were all still there (Serial Ports, PRUSS, Timers etc). Yes you may need to twiddle the pinmux as by default it goes to he HDMI stuff etc, but they are still there Is there something specific here you are thinking of ? Maybe I just don't need what they left off. I do remember looking and going Meh, not important for what I'm doing Best Regards Iain ___ 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] Austron 2100 HPIB/GPIB/IEE-488 cards
Hi Folks, Having recently acquired two Austron 2100 Timing Receivers which did not have the GPIB/HPIB/IEEE-488/whatever you wish to call it cards in, I was wondering if any time-nuts had any hanging around that they wanted to dispose of ? If so, let me know off list, I'm certainly interested in two (esp as I'm currently hoping cleaning the switch contacts with isopropyl alcohol will make them function properly again) Having HPIB would get around the problem if the cleansing fails and remote command and control would be very useful anyway All the Best Iain ___ 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] Distribution amps for Thub=nderbolt and David partridges divider box?
On 19/05/13 19:12, Dave M wrote: Yes... .Jump on it! Seems to be a good price for it. If I needed a DA, I'd buy it in an instant. I just grabbed a pair! (After missing out on the Soekris boxes!) They should go well with the A2100 Timing Receivers that are currently sat in customs, and the Z3816A of mine, as well as the HP 5328B with a 10811, and the 8657B :) Hopefully I can convince a friend of mine to do the 75 ohm to 50 ohm surface mount conversion! Gotta love ebay when you (or someone else) knows what they are buying! Iain ___ 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] Italian Time Station on 10 MHz ?
Hi Folks, A friend of mine sent me a You Tube recording of an unidentified Time Station on 10MHz, possibly from Italy or Brazil. Further work seems to suggest it is indeed an experimental time station from Italy. Below is a (modified for context) version of the email I sent him: --BEGIN INCLUDE MESSAGE--- At first look, I tend to agree with others that it's a new experimental Italian Time Signal. It is also shown on this You Tube link: http://www.youtube.com/watch?v=VSQyKh694RU Video claims to be: Experimental Time Signal from the italian private socitey Italcable transmitting at 1KHz Three observations from this recording: a) The pips are about ~1k up from the main carrier on 10MHz. Probably a little higher, maybe 1.1k b) Right at the beginning, there is a burst of digital comms, that to my ear sounded similar to 300 baud packet. Checking the Frequency vs Amplitude display in the bottom left again, it appears that that burst is up at ~2k+ from the 10MHz centre Now...a PK232 running 300 baud uses the following frequencies: 2110 Mark, and 2310 space tones as a PK-232, with the center of the tones being 2210 Hz, and going fullscreen on the video suggests that the spikes during that burst are smack where we would see them for 300 baud packet when using a PK-232. (With the resolution of the youtube video and the screen, thats as accurate as I can get) c) The burst does appear to repeat later in the recording, which suggests it may be part of the time code, rather than some Italian APRS station being a tad off frequency I would suggest that the next step would be to put a 300 baud PK232 MODEM on 10 MHz, and record anything that gets decoded. If its ASCII (highly unlikely to be KISS Frames unless it is someone way off frequency, and c) above would seem to suggest that's less likely, then it may well be the time of day. In that case, in order to use it, we need to work out the reference point. There seems to be six pips 1 second apart, a gap of a two seconds, followed by a final seventh pip. While different to Radio 4's longer final pip, this is similar to DCF where the final second of the minute is not modulated (MSF does something similar with a 500mS carrier off at the beginning of the minute. My guess is the seventh pip identifies the start of the minute, with the 6 pips beforehand being used for receivers to lock on, and identify the 2 second gap, with the 300 baud packet being used to carry the time information itself for the next minute. Now, do you have the ability to listen on 10MHz with a PK232 tones sound MODEM ? :) ---END INCLUDE MESSAGE--- I am hoping to get a recording or two of it (I don't have HF RF capability right now, but do have replay and 300 baud decode capability), to see if it really is 300 baud packet, but have any (Probably European) time-nuts hear this signal ? Anyone have any details on the time code ? I'm going to hope it might be possible to decode the time from the packet burst, but if anyone has any prior knowledge, then a head start is never a bad thing when trying to decode these things :) (BTW, the station seems to play music most of the minute, which quietens during the packet burst and pips) All the Best Iain ___ 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] Remote GPS Oscillator Steering
Hi Everyone, Recently, I have acquired a HP Frequency Counter and Signal Genny, and have set up a small lab in the house. This is great, but I'd like to hook it into my 3816A, which is 70 ft away in an outhouse, along with all my radio gear, to at least compare it to the 10811 in the Frequency Counter. I'd rather not drill a hole and run a cable (There are other issues with that as well as the hole, the outhouse is the other side of the garden path from the lab!) I do have fibre to the house for N/W connectivity, and (unshielded) CAT6 from the patch panel to the lab. Two problems here. One the patch panel is the other side of the house from the lab (so running a dedicated piece of coax is out without taking up the floors..), and Two, 10MHz over unshielded CAT6 is not good practice, to say the least, and simply not going to happen. So I started looking at other possibilities. It seems a lot of GPSDOs steer the Oscillator by using the PPS. Is that right ? 1 Hz over UTP is a bit more reasonable than 10 MHz, but I did not find many 10MHz oscillators with a PPS input. I thought of using a Z3801 instead of the Z3816, but patching out from the EFC SBM connector, then (optionally) converting that to fibre, sending it up the garden to the house, converting back to copper, then the CAT 6 to the Lab where a second Z3801 would sit I would rather fibre between the house and outhouse for EMC and grounding reasons. My hope is that thee 10MHz Osc would then be steered from the remote Z3801, although the lab Z3801 itself would complain bitterly about no lock no doubt. Does anyone have any comments on this madhat scheme ? Or have other suggestions of how I might go about getting that 10MHz signal converted to fibre, and back again to send into the lab equipment ? What are other people's experience with similar issues ? What do the big boys like NIST and NPL do to manage this ? I know they transfer time over large distances, and I know NPL transfer frequency as well to certain customers, so I guess other similar institutions do as well [Note, for me, plug and play is better. Soldering irons do not like me, and I wouldn't trust myself with one anywhere near anything like a precision instrument :), although putting pre-built modules in a metal box I'm okay with, but plug-and play preferred.] (Googling for fibre converters or similar these days brings up such a noise floor of Ethernet, Any suggestions on the best terms or part numbers to use to find raw (assembled) fibre transmitter / receiver modules that might be suitable would be gratefully received) Best Regards Iain ___ 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] Remote GPS Oscillator Steering
On 18/04/13 11:50, Hal Murray wrote: 10MHz over unshielded CAT6 is not good practice, to say the least, and simply not going to happen. What do you mean by not good practice? Gigabit Ethernet works over CAT5. I think it's 125 megabaud, 5 level, 2 bits per baud. Whatever, it's way over 10 MHz. Oh I know it can handle it, I was trying to avoid a nice 10MHz signal on an unshielded conductor smack on the Amateur Radio 30m band :) It's more RF here than Time/Frequency, and if I can avoid clashes, so much the better... (I detest these ethernet over powerlines things, and it seemed hypercritical to complain about them, then smack a nice signal right on our 30m band. Maybe I worry too much about such things) [SNIP] I would rather fibre between the house and outhouse for EMC and grounding reasons. My hope is that thee 10MHz Osc would then be steered from the remote Z3801, although the lab Z3801 itself would complain bitterly about no lock no doubt. I can't figure out what you are trying to do. The lab Z3801 isn't setup to be steered by an external PPS or 10 MHz signal. Does anyone have any comments on this madhat scheme ? Or have other suggestions of how I might go about getting that 10MHz signal converted to fibre, and back again to send into the lab equipment ? I think you want to send 10 MHz from your outhouse to your house/lab. You may need a distribution amplifier if you want to send it to more than one device. Indeed, Sorry I wasn't clear, I guess I was trying to avoid sending the actual 10 MHz signal over that unshielded copper conductor, so was thinking about sending the data needed to steer the Oscillator instead With it ending up as a -5V to +5V signal to the 10811 in the end, The idea of sending the EFC came from reading http://www.realhamradio.com/joe-geller.htm and noting said EFC was available on a SMB connector. Fiber transmitters and receivers are reasonably common. You can get modules targeted at Ethernet with both transmit and receive in the same package. There is a blizzard of variations depending on distance and bit rate and type of fiber. The trick is that the receiver includes AGC so you get logic level signals out. Noted, thanks, I'll keep hunting :) All the Best Iain ___ 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] Z3805A OCXO p/n 3505A09422?
On 18/04/13 22:41, Brooke Clarke wrote: Hi: I'm trying to learn more about the HP Z3805A GPSDO. http://www.prc68.com/I/Z3805A.html It has an OCXO that I haven't seen before with a paper sticker with it's p/n: 3505A09422 The A normally means made in America. Does anyone know more about it? As others have said, it's a 18011, and you are looking at the serial number. IIRC, It was made in late 1995 (1960+35). The 05 is the 5th week of HP's Fiscal year that begins Nov 1 (still today), which I think puts the date of manufacture between Nov 29th and Dec 6th 1995. It's also a darned fine bit of kit :) (Sorry, I know I'm sad and bad, I just couldn't resist :)] Iain (who can probably still remember what he was doing that Nov 1 at HP!) ___ 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] LORAN in Europe
For any European Time Nutters, I came across this today: http://www.loran-europe.eu/news.php Iain ___ 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] DCF77 phase modulation receiver
On 18/01/13 10:59, francesco messineo wrote: has anyone tried to duplicate the following project: http://www.marvellconsultants.com/DCF No, not yet. Any comment? Yes, you've caused me to add another thing to try and build, and another clock to compare against once I finish the MSF, DCF, and TDF receivers. That's going to mean more graphs, and possibly another TARDIS... (And before anyone asks, I found a schematic for a TDF RX at http://www.rvq.fr/tech/fi.php google translate url below, but watch wrapping) http://translate.googleusercontent.com/translate_c?depth=1ei=qZTtUJDWCqan0AXa-4DACQhl=enprev=/search%3Fq%3DRecepteur%2Bhoraire%2Bsur%2BFrance-Inter%2BG-O%26hl%3Den%26tbo%3Dd%26biw%3D1920%26bih%3D973rurl=translate.google.co.uksl=fru=http://www.rvq.fr/tech/fi.phpusg=ALkJrhiQMp7sEaaWBJ_BwCZQwebN5_gq-Q Best Regards Iain ___ 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] SLIP vs Ethernet for NTP
Hi Guys, I have often heard it said that since RS-232 is more deterministic, and suffers from less jitter, and uncertainties, than ethernet, that it makes a better medium for time distribution (no CDMA for a start). (Especially if you know how many bits you need to squirt over the RS-232 link at what baud rate) Since I am shortly going to have quite a few Srata 1 time sources, my first thought of just plugging them all into a switch, and then having an S2 box sat on the LAN, and distribute from there. And remembering the rules about RS-232 etc, the (possibly mad) thought of running SLIP or PPP over dedicated serial lines to link the Strata 1 boxes to the Strata 2 machine. (I can't connect all the Strata 0 devices to the same Strata 1 box, as there will be other processing being done on the GPS data using RTKLIB on a couple of them) To be honest, this is for nothing more than fun, and nothing critical (this is time *nuts* after all), although it may well mean I have less copper Ethernet hanging around working like tuned antennas, *and* wouldn't need to go fibre on quite so many machines! What are people's opinion and experience of doing such a thing ? Best Regards Iain ___ 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] Z3816A Serial Port Parameters
Hi Guys, Having finally got the time to get my Z3816A connected up to both a power supply and antenna, I find myself with a minor issue. It powers up just fine (minus the silly Antenna alarm, really must add that resistor sometime...) gets GPS Lock, and I can *tell* it's squirting stuff down the RS-232 line [correct led blinks now I have a Null MODEM cable] But can I figure out the baud rate ? Can I heck...Think I've tried most of them, at 8N1. Anyone know what it should be set as ? Maybe even just by default ? Iain ___ 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] OT - GPS and North
Gary Chatters wrote: I have no idea of how the math works for computing heading. Checkout FORWARD and INVERSE (and their 3d equivalents) at http://www.ngs.noaa.gov/TOOLS/Inv_Fwd/Inv_Fwd.html While these are hosted on a NOAA site, I'm sure I've seen it on a NASA site as well. IIRC, there is also a C port somewhere. Iain ___ 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] Z3805 vs Z3816/Z3801
Hi All, I'm thinking about adding a Z3805 to my existing Z3816 (once I get the 3816 up and running once the sparky has finished putting electricity in the garage!) However, I have a few questions that I need to answer before I actually make that decision, and as I'm sure those of you who have a Z3805 know, finding the manual is...a challenge... Anyway, does anyone know: a) The Power requirements. The 3801 and 3816 differ in Voltage requirements as I understand it, anyone able to tell me what the 3805 needs/wants/likes to be fed ? b) Pictures I've seen appear to show BNC rather than SMA connectors, can someone with 3805 confirm ? (Not that it's such a massive issue, but extra cables or converters required...) c) 16 channel GPS RX is great. But anyone know if it wants to feed 3.3V or 5V up to the antenna ? d) Anyone know if it works with the Type 26 NTP reference clock driver ? Anyone actually have it running this way ? Finally, a generic question about all 3 of these HP/Agilent/Symmetricon devices: I know the PPS spec -isn't- at RS-232 levels, however nor is the Garmin GPS-18, and that worked raw for me. Has anyone tried just feeding the PPS signal from a 3801/05/16 into the DCD pin of a serial port ? Iain ___ 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.
