I stand corrected. I was trying to make the distinction (badly) between the frequencies used below the LW broadcast band and the LW broadcast band itself.
The frequency band range nomenclature doesn't fit too well with the broadcast wavelength based assignments. The LW broadcast band fits nicely into the middle of the LF range, 30 to 300 KHz but the MW broadcast band only occupies a relatively small segment of the MF range, 300 to 3000 KHz. However, the HF range, covering 3 to 30MHz nicely encompasses all the SW broadcast bands allowing the HF and SW nominators to be used interchangeably in this case.
JOOI, were you saying that the Anthorn signal also uses 60KHz or just reminding me that 60KHz is in the LF rather than the VLF band?
Ah! It's so easy to overlook what in hindsight becomes the bleedin' obvious. :-) BTDTAGTBTS. Mind you, I earned my T-shirt nearly a decade ago when I realised that the radio controlled clock built into the I.T. Works weather station was only syncing up overnight when I was able to shut down the laptop I was using for late night/wee small hours PVR duty (I very rarely left the desktop PC on overnight to complete any PVR tasks
- the laptop was a better use of the electricity for that purpose).
The Wx station is less than 2 foot away from the laptop (and ditto the desktop monitor which *does* get switched off overnight regardless). The desktop sits about 4 foot away which is still too close to allow reliable reception by the Wx station imo.
Since the computer clocks are synced to ntp servers, I just learned to accept the creeping discrepancy in the Wx station's displayed time. My venerable Casio DB360 wristwatch has settled down to drifting by less than a second over the past 4 months so I use it as a "sanity check" that the PC clock is staying synced to an ntp server.
However, one oddity I've just experienced with the computer clock is the inability to trigger a manual resync. I've just tried to resync to reduce the 3 second discrepancy with my watch back to the leap second induced 1 second behind error and it just claims an inability to connect to any ntp server and slows the clock by half a second each attempt. I'm pretty certain it's always behaved like this, yet it must manage to automatically sync up since day to day (and this machine is rarely powered off) it's usually just showing the 1 second lag with respect to my watch due to my not being arsed to adjust for that leap second just over 4 months ago. I'm running Linux Mint 17.1 KDE 64 for anyone wondering what might be behind this peculiarity.
I'll check it tomorrow and see whether that 3 second discrepancy has returned or not before considering the problem any further. However, curiosity got the better of me and after wasting precious minutes googling ntp servers, I eventually hit upon using "what is the correct time now" which gave me this link: " which is 3 seconds behind my watch strongly suggesting that my watch, after more than 3 months of being ahead by a second has now suddenly gained an extra two seconds during the last week or three.
If it's my watch suddenly gaining an extra couple of seconds, I expect to see the computer clock time go adrift by 3 seconds WRT the watch when I check it tomorrow (I've currently got the PC clock set to one second behind the watch). The Wx station, btw, is 7 seconds slow compared to time.is (making it 9 seconds behind the computer clock).
It is as it always was - transmitting on 60Khz. The SF in MSF stands for Standard Frequency. It not only transmits an accurate time, it is also an extremely accurate frequency reference.
The digital (LCD display) type may keep up with the time signal but analogue display types only synchronise once a day usually 1-2am which means in october they miss the DST change because they check too soon.
Looking at this aerial photo view (which seems to have been snapped when the surveying craft was almost directly over the most easterly mast during mid to late afternoon) I noticed that the name showing just to the south west of the transmitter hall complex is an actual construct on the ground rather than an act of photoshopping by google.
formatting link
Interestingly the transmitter frequency is shown as 19.6KHz with the callsign of GBZ
The initial aerial photo I saw at the following link which had led me to the above aerial view:
must have been the south eastern edge of a much larger image taken an hour or so before noon on a winter's day which creates a very disconcerting view indeed (rotating the image 180 degrees would have remedied this effect but there doesn't appear to be an option to do this on the web page). What at first glance appear to be shadows of masts are, on closer inspection, the towers themselves with 'the tall towers' proving to be nothing more substantial than mere shadows.
It looks like my 'super accurate' Casio had decided to jump a couple of seconds further ahead during the past week or so. A rather peculiar error since a a sudden loss of a second or three after months of rock steady time keeping seemed a more likely glitch to me. Ah well, a good excuse to 'apply' that long overdue leap-second correction I suppose.
The computer clock is obviously being kept in sync with NTP despite there being no apparent way to force a re-sync manually like I could when I was using win2k. Claiming it can't see any of the ntp servers is a damned peculiar way of stopping the end user from over-riding the automated updates though, especially if the attempt to re-sync results in the PC clock losing a few hundred ms each time.
The computer clock display seems to be lagging the
formatting link
display by a couple of tenths of a second. I suspect the
formatting link
GMT web server might be trying to compensate for browser/OS lag by being a fraction of a second ahead. A couple of tenths of a second 'error' on a clock displaying only to the nearest second is neither here no there and being a fraction of a second ahead in this case is no bad thing, all things considered.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.