I'm slowly, a bit too slowly for the paper deadline, assembling a timing transfer system for redundant distribution of network time using IEEE1588-2008, PTP. Today, I achieved a minor milestone, in that I actually can speak to the GNSS receiver that's built into some of my routers. Required an upgrade and a number of as usual cryptic commands. Tomorrow I'm bodging an antenna mount using a piece of galvanised 3/4" pipe with taper thread in one end, and actually vill try to connect the antenna to the receiver module.
Not much, then, so far, but I'm hoping for some actual achievement reasonably soon. Will post.
Time nuttery in distributed application.
Forum rules
Use tags for the type of equipment your topic is about. Include the "repairs" tag, too, when appropriate. If a new tag is needed, request one in the TEAdministration forum.
Use tags for the type of equipment your topic is about. Include the "repairs" tag, too, when appropriate. If a new tag is needed, request one in the TEAdministration forum.
Re: Time nuttery in distributed application.
Today I managed to get the GNSS board an antenna, and have it see the sky. Found enough satellites, and locked on, and started steering the oscillator in the switch. It became a GM in the PTP collective, and all the others obeyed properly. I did tweak Priority1 in the PTP config enough so as to guarantee it becoming a GM in absentio better clocks. Then I hung the 10MHz o/p onto my 2465, and put the 10MHz of our Anritsu GNSS steered Rb on the other channel. Aaaand LOCK. The Anritsu is quite wildly chasing back and forth before its GNSS thinks the Rb is steady and OK, but when the light goes on, it is rock solid.
I promptly connected our central infrastructure clock on to this as well, after some deliberations on "How to not break TV production on a Friday afternoon", and they immediately took over the show and relegated the local GNSS steered clock to backup.
So far gone, I realised that I'd had so much luck that I would likely soon run out. Packed the instruments away, and went home early so as to not jinx it.
Next week, I'll make some PTP quality measurements using the Anritsu, and record the results of them. Then write up the findings like crazy.
I promptly connected our central infrastructure clock on to this as well, after some deliberations on "How to not break TV production on a Friday afternoon", and they immediately took over the show and relegated the local GNSS steered clock to backup.
So far gone, I realised that I'd had so much luck that I would likely soon run out. Packed the instruments away, and went home early so as to not jinx it.
Next week, I'll make some PTP quality measurements using the Anritsu, and record the results of them. Then write up the findings like crazy.
Re: Time nuttery in distributed application.
A 2465CTS and the frequency is measured to 1% (10.0MHz). What a waste 
Re: Time nuttery in distributed application.
The frequency counter in the scope is there just to make sure one does not look at mains hum. 
1% accuracy mightabeen impressive to someone not familiar with what a good reciprocal counter can do, but in context of reference oscillator checking, it is obviously just a toy.
No, the interesting part, which a bit awkwardly requires video to prove, is of course that regardless which input the scope is triggered from, both inputs are rock solid on the display. That's a resolution in comparative frequency counting going further than most counters.
I have a 5316B to check things over with if needed, but, I don't think (thinking about it for just a short moment) it'll be any better in resolution than the two waves not moving visibly against each other; and I've not got video of it, but I watched the scope on and off for 30 minutes with the markers set at origo, one on each wave, and they stand absolutely still. With a somewhat large margin for error, that is moving less than ~10° relative over 1800 seconds. To my broken brain, that would be something like:
(1/(36 * 10000000)) / 1800 = .00000000000154320987
(please roast that bit of 6th grade math and tell me where I'm stupidly wrong. I need it)
The cornerstone of the system here of course is the MT1000A, which, with a Rb oscillator locked to GNSS, and being in-cal, is the house portable reference. I've run it against the fixed house references, two Meinberg M3000 GNSS clocks, and they're all bang-on in agreement to the last digit of what I can measure. Everywhere.
1% accuracy mightabeen impressive to someone not familiar with what a good reciprocal counter can do, but in context of reference oscillator checking, it is obviously just a toy.No, the interesting part, which a bit awkwardly requires video to prove, is of course that regardless which input the scope is triggered from, both inputs are rock solid on the display. That's a resolution in comparative frequency counting going further than most counters.
I have a 5316B to check things over with if needed, but, I don't think (thinking about it for just a short moment) it'll be any better in resolution than the two waves not moving visibly against each other; and I've not got video of it, but I watched the scope on and off for 30 minutes with the markers set at origo, one on each wave, and they stand absolutely still. With a somewhat large margin for error, that is moving less than ~10° relative over 1800 seconds. To my broken brain, that would be something like:
(1/(36 * 10000000)) / 1800 = .00000000000154320987
(please roast that bit of 6th grade math and tell me where I'm stupidly wrong. I need it)
The cornerstone of the system here of course is the MT1000A, which, with a Rb oscillator locked to GNSS, and being in-cal, is the house portable reference. I've run it against the fixed house references, two Meinberg M3000 GNSS clocks, and they're all bang-on in agreement to the last digit of what I can measure. Everywhere.
Re: Time nuttery in distributed application.
My presumption was that you didn't want to confuse observers by displaying the 2465CTS's inaccuracy.mansaxel wrote: ↑Sat Apr 29, 2023 9:08 am The frequency counter in the scope is there just to make sure one does not look at mains hum.
It is easy to (accidentally) have rock solid traces: just have "alt" mode and "vert" triggering. Never done that by mistake, oh no, never ever.No, the interesting part, which a bit awkwardly requires video to prove, is of course that regardless which input the scope is triggered from, both inputs are rock solid on the display. That's a resolution in comparative frequency counting going further than most counters.
Please stop right there. Such statements require me use up my limited willpower to exercise self-restraint. (I'm pleased I managed to avoid bidding on a second QuartzLock off air standard yesterday)I have a 5316B to check things over with if needed, but, I don't think (thinking about it for just a short moment) it'll be any better in resolution than the two waves not moving visibly against each other; and I've not got video of it, but I watched the scope on and off for 30 minutes with the markers set at origo, one on each wave, and they stand absolutely still. With a somewhat large margin for error, that is moving less than ~10° relative over 1800 seconds. To my broken brain, that would be something like:
(1/(36 * 10000000)) / 1800 = .00000000000154320987
(please roast that bit of 6th grade math and tell me where I'm stupidly wrong. I need it)
The cornerstone of the system here of course is the MT1000A, which, with a Rb oscillator locked to GNSS, and being in-cal, is the house portable reference. I've run it against the fixed house references, two Meinberg M3000 GNSS clocks, and they're all bang-on in agreement to the last digit of what I can measure. Everywhere.
Re: Time nuttery in distributed application.
Oh, the counter fsvo counter, is just the horizontal distance between the markers plus some math, not anything trigged at all. So, in all fairness, the 1% accuracy is probably reasonable given that one has to hit origo twice with the markers manually to measure.
I don't think I did that, for during the warm-up phase there was a definitive difference displayed, which was oscillating around 10MHz in typical narrowing-in / dampening deviations style with less and less overshoot, and then finally it just stuck on "stable".tggzzz wrote: ↑Sat Apr 29, 2023 10:18 amIt is easy to (accidentally) have rock solid traces: just have "alt" mode and "vert" triggering. Never done that by mistake, oh no, never ever.No, the interesting part, which a bit awkwardly requires video to prove, is of course that regardless which input the scope is triggered from, both inputs are rock solid on the display. That's a resolution in comparative frequency counting going further than most counters.
Happy to help!tggzzz wrote: ↑Sat Apr 29, 2023 10:18 amPlease stop right there. Such statements require me use up my limited willpower to exercise self-restraint. (I'm pleased I managed to avoid bidding on a second QuartzLock off air standard yesterday)I've run it against the fixed house references, two Meinberg M3000 GNSS clocks, and they're all bang-on in agreement to the last digit of what I can measure. Everywhere.
Re: Time nuttery in distributed application.
Always nice to see a wandering trace snap into sync as a Rb locks 
Just be careful about lighning protection. I know of one case where a GPSDO was connected to a rack of expensive equipment and it took the lot out when the antenna took a direct attachment.
Just be careful about lighning protection. I know of one case where a GPSDO was connected to a rack of expensive equipment and it took the lot out when the antenna took a direct attachment.
Re: Time nuttery in distributed application.
This is very good advice. The antenna right now is inside; I took it in from its Heath Robinson antenna mount after the trials. Our Antenna Responsible, who mostly concerns himself with all the myriad up- and downlink dishes we slowly are phasing out in favour of Internet links for programme delivery has been on the subject and we've discussed the various needs of the protection. This install, though, is more of a transient thing. In actual operation, we'll put it at another location.
Re: Time nuttery in distributed application.
There's a microcosm of all things "life" in that statement...
mnem
"Time is an illusion; timebase doubly so." ~TinkerDwagon
Re: Time nuttery in distributed application.
On my long list of "things to do" is get a pole up on the roof that is suitably placed to put the GPS antenna I have sitting in the currently disorganised mess of electronics bits, and figure out what would be adequate lightning protection for it as it is certainly going to be higher than anything in its immediate vicinity.
Re: Time nuttery in distributed application.
Oh, this is actually a must, so much that it will either get properly installed, or not at all.
- First, The Keeper Of Antennas will see to the proper install, no exceptions.
- Second, the entire point of the install is to get the receiver into another city, creating a distributed, redundant system of usable clocks.
Re: Time nuttery in distributed application.
Mine here at home is on top of a 3m piece of 1 1/2" plumbing pipe fastened to the wall just below the roof. It is very high up, compared to the rest of my antenna park. It's also got the supplied OVP installed in-line, and with a suitable ground connection.Cerebus wrote: ↑Sat Apr 29, 2023 5:21 pmOn my long list of "things to do" is get a pole up on the roof that is suitably placed to put the GPS antenna I have sitting in the currently disorganised mess of electronics bits, and figure out what would be adequate lightning protection for it as it is certainly going to be higher than anything in its immediate vicinity.
An earlier attempt looked like this:
The new one is in the same place, just 3m further up.
I do know I've got a pic of it somewhere. But where?
Re: Time nuttery in distributed application.
Huh? I have a 2465DMS with the counter and I'm damn sure it's way more accurate than 1%. 10.0000MHz displays 10.0000MHz. And I don't need to futz with the markers nor even have the trace properly triggered.
Perhaps yours needs to be calibrated.....although it would flag a boot up error if it was way off.
An old gray beard with an attitude. I don't bite.....sometimes 
Re: Time nuttery in distributed application.
No, it's simply not being used to its potential, because I did not read the manual beforeMED6753 wrote: ↑Sat Apr 29, 2023 11:57 pm
Huh? I have a 2465DMS with the counter and I'm damn sure it's way more accurate than 1%. 10.0000MHz displays 10.0000MHz. And I don't need to futz with the markers nor even have the trace properly triggered.
Perhaps yours needs to be calibrated.....although it would flag a boot up error if it was way off.
. Manual states that Option No. 6, counter/timer, has 1Hz resolution up to 10MHz (but it changes to 10Hz resolution at just 10MHz), so it's even higher than that. I just need to engage it properly. Scope is at work now, so can't check it out. And, I haven't got the DMS option, but the combination of Options 6,9,10 sold as "2465CTS".Manual: https://w140.com/tekwiki/images/7/71/070-4631-00.pdf See Page 1-4 for the specification table.
Re: Time nuttery in distributed application.
The only difference between the DMS and CTS is the addition of the DMM option on the DMS. The other options are identical.mansaxel wrote: ↑Sun Apr 30, 2023 1:00 amNo, it's simply not being used to its potential, because I did not read the manual beforeMED6753 wrote: ↑Sat Apr 29, 2023 11:57 pm
Huh? I have a 2465DMS with the counter and I'm damn sure it's way more accurate than 1%. 10.0000MHz displays 10.0000MHz. And I don't need to futz with the markers nor even have the trace properly triggered.
Perhaps yours needs to be calibrated.....although it would flag a boot up error if it was way off.
Manual: https://w140.com/tekwiki/images/7/71/070-4631-00.pdf See Page 1-4 for the specification table.
An old gray beard with an attitude. I don't bite.....sometimes
Re: Time nuttery in distributed application.
Ok, a lot of usual work and some issues with "which controls what" in the network equipment have delayed the work with my project. It's been put a bit on the backburner, but not as much so as to grind to a halt. I hope. More is coming.
Re: Time nuttery in distributed application.
Heh... All my projects seem to do that... pesky real life getting in the way and all that.
viewtopic.php?t=167
But as you can see here, I do eventually finish them... it's the half-dozen other projects that got started while that was in the works that I have to worry aboot now.
mnem
tzzzzzzt.
viewtopic.php?t=167
But as you can see here, I do eventually finish them... it's the half-dozen other projects that got started while that was in the works that I have to worry aboot now.
mnem
tzzzzzzt.
-
Specmaster
- Posts: 1121
- Joined: Sat Oct 22, 2022 8:13 pm
- Location: Chelmsford, UK
Re: Time nuttery in distributed application.
Hmm oh my, I must have missed the bulk of that build, very impressive, but like you said, real life gets in the way, it did with me on this build. Why did you mention the cored Cat 5 cable, all of my Cat 5 cables are cored, is that unusual then?mnementh wrote: ↑Sun May 14, 2023 1:46 pm Heh... All my projects seem to do that... pesky real life getting in the way and all that.
viewtopic.php?t=167
But as you can see here, I do eventually finish them... it's the half-dozen other projects that got started while that was in the works that I have to worry aboot now.
mnem
tzzzzzzt.
Who let Murphy in?
Brymen-Fluke-HP-Thurlby-Thander-Tek-Extech-Black Star-GW-Advance-Avo-Kyoritsu-Amprobe-ITT-Robin-TTi-Heathkit-Duratool
Brymen-Fluke-HP-Thurlby-Thander-Tek-Extech-Black Star-GW-Advance-Avo-Kyoritsu-Amprobe-ITT-Robin-TTi-Heathkit-Duratool
Re: Time nuttery in distributed application.
Oh, there's lots of Cat5, etc cable that's solid-core conductors. Completely unsuitable for use on things that move.Specmaster wrote: ↑Sun May 14, 2023 2:49 pmHmm oh my, I must have missed the bulk of that build, very impressive, but like you said, real life gets in the way, it did with me on this build. Why did you mention the cored Cat 5 cable, all of my Cat 5 cables are cored, is that unusual then?mnementh wrote: ↑Sun May 14, 2023 1:46 pm Heh... All my projects seem to do that... pesky real life getting in the way and all that.
viewtopic.php?t=167
But as you can see here, I do eventually finish them... it's the half-dozen other projects that got started while that was in the works that I have to worry aboot now.
mnem
tzzzzzzt.
Yes, most of my updates while I was working on the fatBike battery upgrade were posted to the Discord and occasionally to the 3DP threads. It wasn't until it was all done that I made the project thread.
mnem
*connected*