Re: [time-nuts] any WWV audio recordings available?
Hi there, Some time ago, I "hot rodded" the "tg" program that comes with the open source "ntp" package and cleaned it up, making options for different output formats, including IEEE 1344 extensions on the IRIG, and cleaned up the WWV output for DST shifts, quality coding, etc. When you posted your question, I did a quick look, hacked in libsndfile calls, and made it so it can generate clean IRIG-B or WWV audio WAV files of arbitrary duration, starting at arbitrary times. The generation actually runs much faster than real time, resulting in huge files for long time frames, stored in seconds. As an example, please find at http://www.weiten.com/time_nuts/2010-02-10_07h09Z.zip , a 221k ZIP archive that expands out to a 92M WAV file of simulated WWV audio from 2010-02-10 07h10Z to about 17h29Z. Is this helpful? -- Dean Weiten Phone:(204)-888-1334 (home) (204)-771-4925 (cell) E-mail: d...@weiten.com (home) ___ 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] any WWV audio recordings available? (synthetic WWV output fixed, I think)
Hi Scott et al., I compared the sound output from TG to an AU file provided by NIST, and sure enough, it did sound weird. I had a closer look at the TG customization that I had done, and indeed, the whole u-Law audio compression thing was all messed up in my code. The problem is that the original was written for a Sun workstation, and it (apparently) used u-Law compression, or at least in the original TG program, it was turned on. In order to keep things the same and use the same tables, I thought I had turned on u-Law compression, but apparently I did something incorrectly. Therefore, I've now modified it to be linear, at least when compiled for non-Sun systems. So now the 100 Hz subcarrier should be 6 dB down, as I believe it is supposed to be. There are two sample files, 1 hour long each, in the ZIP archive at http://www.weiten.com/time_nuts/synthetic_wwv-like_audio.zip . Please give them a try/listen and let me know if it sounds more realistic. -- Dean Weiten Phone:(204)-888-1334 (home) (204)-771-4925 (cell) E-mail: dmw-at-weiten.com (home) ___ 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] Yukon Power
Actually, these days, in the widely-connected continental area of US & Canada (with exceptions like Texas), the frequency will be much closer than +/- 0.5 Hz. Power systems will start "islanding" and shedding load if frequency goes outside say +/- 0.1 Hz. It's very important for the power system frequency to stay stable - energy flows and therefore revenue flows depend on it. The power utilities are absolutely anal about tracking frequency and maintaining it precisely. It turns out that an AC power line is almost entirely inductive in nature. This means that the power flow has little to do with the voltage, more or less all about the phase angle difference between the ends. Actually, a voltage difference generally means a reactive power flow, which is counter-productive, so voltage is maintained very constant as well. At the transmission line between cities, you see the bird's eye view aggregate of power consumption - and utilities will put systemic voltage support at various points to ensure that voltage is well matched. In order to keep the system stable, power utilities must maintain strict frequency control. In the case of Whitehorse YT, they are not connected to the continental grid and therefore are not subject to the same controls. The power is probably generated by diesel, coal, or perhaps hydro power. It is much more difficult to maintain frequency control under these conditions - a single big load (like a mill) "dumping" because of some disturbance, can change your load base substantially, throwing the frequency way out of whack. You can't instantaneously change the speed of the motor or turbine shaft, so you have to slowly bring the system back in line. Here in Manitoba where I live, we have hydro-electric generation way up at the north end of the province supplying something like 90% of our power, with most of the load in the south, separated by, hmm, something like 800 km. Plus, we actually export *a lot* of power into the north-central states. In the 1960s, Manitoba Hydro built an AC-to-DC converter up north and a DC-to-AC converter down south, and ran the 800 km with a 500 kV DC line. There are lots of benefits to this, but one of the biggest ones is that the phase & frequency of the output of the DC-to-AC converter can be controlled on a cycle-by-cycle basis - it's done with thyristors (huge SCRs, used to be mercury-arc but now almost all solid state), so there are no rotating shafts. This gives our power system excellent stability. In fact, Manitoba Hydro can modulate the output of the DC-to-AC converter to help stabilize the system from other, external disturbances. The possibilities are limitless. Of course, the downside is that the loss of that DC line to the north leaves us up a creek, and that happened about a decade ago when a cyclone went through and took it down. What an exciting time that was! The frequency of the AC system up north from the generators to the AC-to-DC converter station is not well controlled. If we dump a big load in the south, the DC system changes almost instantly to adjust, but then there's nowhere for the energy to go, so the northern AC system goes way up in frequency. Conversely, if we add a big load in the south, it can go down, but then that's generally planned, and more controlled. They say you don't run your clock on the frequency up north. In fact, nobody does, because it's high voltage transmission, and there isn't enough population to justify putting a distribution substation in there - some folks complain that they can SEE the transmission line, but they are forced to run on diesel generated power. It isn't a conspiracy, it's pure practicality and economics - you can't just drop a wire and plug in your stove! OK, maybe I digress, sorry. What I do find interesting is that the Yukon folks don't have multiple cross-correlated timing systems checking each other. If the frequency were to go very low (say 50 Hz) it will cause significant dissipation in power transformers and the like, perhaps even damaging them. It turns out that flux in the core of said transformers is related to V/f, so if the frequency drops over 10%, you get a substantial increase in flux, and if you are close to the saturation of the core, well, let's say that makes for not-so-happy customers. Heavens, designing such systems is what I (used to) do. I could close my eyes and see the design - it wouldn't be that difficult! Maybe I should give them a call. So when I see derogatory comments directed at the Yukon power folks, be careful - they might be guilty of not having a backup time tracking system, perhaps even of not tracking it automatically. But, it's much more difficult when you are not connected to the continental grid! Regards, Dean Weiten. ___ 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] IRIG B
Date: Tue, 25 May 2010 09:08:18 +0100 From: "Clive Green" Subject: [time-nuts] IRIG B To: Message-ID: <000d01cafbe1$6f6788b0$4e369a...@com> Content-Type: text/plain; charset="iso-8859-2" Can anyone help with a modern IRIG B chipset manufacturer Many thanks Clive Green -- Hi Clive and the group. I can't give you a lead on an ready-made chipset, but I've implemented an IRIG-B decoder in a 68HC11 and in an 68HCS12. I found the difficult part to be the analog section, as it can introduce significant uncertainties in the timing stream, especially in a modulated signal. We got ours down to around 10 uSec which we considered quite good. Of course the 5 volt logic levels of the unmodulated signal makes it easier to get better accuracy. The IRIG-B decoder work I did was implemented on power systems relays & disturbance recorders several years ago, then I left the company and in the meantime, they changed over to an FPGA implementation and skipped the processor altogether. Now I'm back with that same company (although ownership has changed), but I haven't yet had a chat with the new FPGA designer to find out how he did it :-) I've also tweaked and "upgraded" (well in my opinion) the TG program of the NTP package, which generates WWV(H) and IRIG-B audio signals in *NIX operating systems. It was targeted for the Sun Sparc and I moved it to OSS audio which was what I was using on X86 GNU/LINUX at the time. I think I submitted it for inclusion in the NTP package but I don't think it ever got in there; I used to claim that it was rejected, but then again it's also possible that I didn't submit it correctly. I can give this to you if you would like. If you would advise on your application and parametric requirements, perhaps I (or someone else on the mailing list) could make further suggestion or help directly. -- Dean Weiten ___ 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->audio interface
Hi there, It turns out that the NTP package has a built-in utility called "tg" which can generate IRIG-B time code. I'm not familiar with what you are trying to do. If you have a computer that is keeping accurate time (through your GPS clock??), you can generate a nice audio IRIG-B. It was developed to allow testing of the NTP IRIG-B **input** function. NTP has a bunch of front ends for all kinds of code inputs. I played with tg from NTP 4.2.2p3 quite extensively some time ago, and created a version with a bunch more options, including IEEE 1344 extensions, and corrected a couple of bugs etc. Also, I play a bit with the timing to allow "tg" to omit or insert strategic single cycles to correct for the clock error on the audio card. Plus much more, mostly to help me test an IRIG-B decoder. Oh yes, I also did a bunch of adjustments to the WWV(H) output option from "tg". Not many folks care about WWV(H) any more, though :-) I'm not sure if any of you would be interested in this modified "tg". Let me know if you do. I had submitted it to the NTP gurus some time ago, and they didn't seem too terribly interested. Regards, Dean Weiten. ___ 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] PC-104 ISA by Luis Cupido
Luis, As have many others, I've stubbed my toes on ISA interfacing lots of times. The best reference on the subject is "Interfacing to the IBM (r) Personal Computer", by Lewis C. Egeebrecht, from Sams. It's old and may be out of print, but it's an essential resource for anybody dealing with 8 or 16-bit ISA. You will have to ignore the sections in PS/2 Micro Channel architecture of course :-) There are a few typos (e.g chapter 10 - description of SBHE - SBHE should be inverted, and /SBHE=0 A0=1 is odd byte 8 bit transfer not "invalid") but it is an *excellent* reference. Back to your problem. 8 bit I/O should work if you are decoding the lower 16 bits of address (NB **only** 16 bits) qualified by AEN low and using /IOW & /IOR to strobe. One common error that I've made a few times is to ignore the AEN, which typically works but messes up the DMA so that floppy drive access fails. Be sure to leave I/O Channel Ready alone unless you want to extend the I/O cycle time; and then only drive it low when your device is accessed. To enable 16 bit I/O, you drive I/O CS 16 low when you have valid address to your board (address & AEN, no need for strobe), then you must do an 8 bit or a 16 bit cycle in accordance with A0 & /SBHE. This because the X86 instruction set allows for 8 and 16 bit I/O, and you don't know which one you will be seeing when you get selected. That should be all there is to it. All this with the caveat of course that free advice is worth... well, you know :-) Regards, Dean Weiten dmw -at- weiten.com ___ 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] Features of a Precision Clock?
Hi there, Having worked with the folks who operate the power utilities (I designed protective relaying and recorder electronics for several years), I can advise that they do take the long-term accuracy of their power seriously. However, the short-term is not a big concern, and in fact, they cannot control it all that well. It turns out that power flow on an AC line requires a phase difference between end points (as opposed to a DC system where it is resistance that counts). The resistance of the line is not important. This is because power transmission lines are almost pure inductive reactance - in power systems terms, the line angle (impedance angle) is generally near to 90 degrees. Systems are connected at multiple points, like a mesh of rubber bands connecting weights and support points. Some of these points are heavier (down) or pull stronger (up), some have stronger bands, some have very weak bands. When the load changes, or when a line opens or closes, the phase angles of the power through all these interconnected ties will shift to establish a new equilibrium. In so doing, your power will advance or retard somewhat. If you have a clock running on the phase of AC power, your clock will gain or lose a bit of time. It is unclear whether you will ever be corrected - the new equilibrium might just be a fact of life. The prime movers of the systems (generators) are almost all physical moving devices, like hydro-electric (water dams) or thermal (coal, natural gas, or nuclear powered turbines). When they are loaded down, they slow down - and when less loaded, they speed up. This isn't as bad as it sounds - the rest of the system rolls along at the "system frequency", and the generator's slight frequency change actually becomes a phase change, which, as per above, changes its power output. Then the generator gets back into sync, but with a phase angle different than before. As you can imagine, it is a challenge to maintain tight control of the phase, with all the changing conditions on the power grid. In the case of our utility (Manitoba Hydro), they keep power system clocks at the big "24 by 7" staffed power stations and in the main control room, and will, under their rules of operation, tweak things slightly over time. I am not certain of the rules of operation, or of the way they tweak things (generator bias?), but could find out from friends and colleagues, if you wish. Here in Manitoba, we are blessed to have much of our power supplied from the hydro-electric generators in the north, through a DC link. It turns out that this is economical above a certain distance and power level - related partly to the "skin effect" (yes it becomes important, even at 60 Hz). At the south end of the link, we have a DC-to-AC inverter system (huge - pretty impressive), fibre optic fired thyristors (equivalent to triacs? SCRs?). We can change the firing angle on a cycle-by-cycle basis, adjusting the power flow in and out, and exerting extraordinary control of the system phase. We use it to stabilize the system more than for power frequency correction, but I assume that this could be done too, just unsure of the algorithm. Of course, the system is a lot more complex than I describe it here, with phase shifting transformers, tap changers, and more modern back-to-back DC links, wind generation at the distribution (lower voltage) level, etc. More complex than I understand, to be sure. But those are the basics. Regards, Dean Weiten, Elecsys Solutions, Winnipeg, Manitoba. ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Poor Man's IRIG-B Generator?
Hi there, The "standard" source package for the Network Time Protocol package, found either at http://www.ntp.org or through download with/for a LINUX distribution, has a tool in the "utils" directory called "tg", which stands for "tone generator". It can generate simple modulated IRIG-B and WWV(H) time signals on an audio card. Unfortunately, I found that it would not compile for X86 - it was apparently written for the SparcStation, I think. I've modified it to work with Open Sound System (a modern LINUX sound system), and added all kinds of IRIG options, including IEEE 1344 yes/no, daylight savings time, proper second-of-day, 1998 or 2002 format (includes years), etc. I also tweaked the WWV(H) format to make it more correct, e.g. skipping the 440 Hz tone on the 29th second, etc. Unfortunately, I haven't got around to contributing the source back yet. Looking just now, it's not obvious **how** to contribute back. I'll check that out later. In spite of this... should you be running LINUX, and should you wish to download NTP (you have to have NTP source before you can compile "tg" - may even have to have the core software compiled), I can provide a file "tg.c" which will drop right on top of the existing "tg.c" in the "utils" directory, and give you these features. Just drop me a line. As always, your mileage might vary, no warranties, etc. One caveat: with any sound card output, the sample rate is only as good as the time card's clock source. This means that the output frequency is only as good as that clock source. Since the signal is just sine waves output continuously, this means that the IRIG-B output time will drift from the system clock. I was working on monitoring the difference and correcting for this long-term drift. I haven't completed this yet. It would create a small short term variation in the frequency, but IRIG-B clients would not care. As an aside, I've implemented a couple of IRIG-B time decoders as part of my job. One of them automatically handled modulated and unmodulated on the same input, switched and level-compensated automatically, and fed a highly accurate (hmm, "highly" is dubious when you are talking IRIG-B, but let's say "impressively" accurate given the signal characteristics) "on-time" signal to a DSP, which then synchronized its sampling to it. It was part of the framework for a power system relay & recorder product line, http://www.nxtphase.com/sub-products-relays-bpro.htm . For some reason, I find such things exciting and gratifying. I guess this is why I subscribe :-) Regards, Dean Weiten [EMAIL PROTECTED] ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Scopes and 1 PPS signals?
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY Hi there, One option that I've used is to put a flip-flop on the signal, turning the 1 PPS short pulse into a 1/2 Hz square wave. You can always see that on the DSO, and it may even be easier to catch the rising and falling edges on other assorted equipment (depending on the equipment). Regards, Dean Weiten. ___ 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.
