Re: [time-nuts] Small time server for mobile use.
Thanks for this. This (and the other responses) were the type of answers I was hoping for. The budget is probably up to several thousand for a robust COTS product that won't add significant operational hassles. (Kludging a laptop to run as an NTP server would be an example of a solution that would add operational hassles.) Equipment designed for rack mounting is a bit less than ideal (the equipment bay in the vehicle is not really set up for rack mounted gear) but we could probably work out a way to mount a one u device, and mounting a laptop adds it's own set of challenges, although a laptop can be mounted outside of the equipment bay. The ideal form factor would be something the size of a small paper back book (or smaller) that could be surface mounted or secured via clamps to a piece of tubing that is already in the equipment bay. Sent from my iPad On 2015-05-12, at 3:03 PM, Bob Darlington rdarling...@gmail.com wrote: What's your budget? I've done this with 1U sized NTP servers from Symmetricom (S300 and S350 systems) for mobile military use. These are a few thousand bucks a pop. They're rugged, and held up just fine in places the military goes.Compared to the rest of the system I was working on, this was quite small in comparison and we used more than one at each location. My personal one died recently so I'm working on developing a cape for the BeagleBone Black. The prototype is working just fine so far so I'm moving forward with a board layout and eventual sale to the list members if there is any interest (I'm not asking for interest yet). -Bob On Tue, May 12, 2015 at 11:11 AM, Mark Spencer m...@alignedsolutions.com wrote: Hi sorry for a possibly OT post. Has anyone had practical experience with small commercially available time servers / ntp servers suitable for mobile use in a vehicle. The use case is I am in need of an accurate (ie. within 100 ms) time source for several pc's in moving vehicle.Being able to run directly off a 13.8 or 28 VDC source would be a major plus but AC power is also available. Hold over if there are gaps in GPS coverage is also a major plus. We already have a GPS with a 1 pps output, but an integrated box with it's own GPS would be best. Yes I am aware I could feed a 1 pps signal into a laptop and use that as a time server and I may end up going that route. There is a small Ethernet LAN in the vehicle. The pc's currently get their time via a wireless connection to various NTP servers. I need to be able to ensure accurate time on the PC's if there is no wireless coverage. This is for a one off project so piecing together various parts is an option but a single box COTS solution would be nice. I've found a few candidates via web searches but would welcome any feed back. Thanks in advance Mark Spencer ___ 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] Small time server for mobile use.
The quickest no-cost way to get decent hold over if all you need is about 100 ms is to configure all you NTP users to be part of an orphan network. When the outside NTP server is lost the island will look at the set of local NTP systems that agree with each other. So you in effect use the most stable internal clocks for hold over. It is just a matter if setting up all the ntp.conf files on all the computers to do this. On Tue, May 12, 2015 at 3:03 PM, Bob Darlington rdarling...@gmail.com wrote: What's your budget? I've done this with 1U sized NTP servers from Symmetricom (S300 and S350 systems) for mobile military use. These are a few thousand bucks a pop. They're rugged, and held up just fine in places the military goes.Compared to the rest of the system I was working on, this was quite small in comparison and we used more than one at each location. My personal one died recently so I'm working on developing a cape for the BeagleBone Black. The prototype is working just fine so far so I'm moving forward with a board layout and eventual sale to the list members if there is any interest (I'm not asking for interest yet). -Bob On Tue, May 12, 2015 at 11:11 AM, Mark Spencer m...@alignedsolutions.com wrote: Hi sorry for a possibly OT post. Has anyone had practical experience with small commercially available time servers / ntp servers suitable for mobile use in a vehicle. The use case is I am in need of an accurate (ie. within 100 ms) time source for several pc's in moving vehicle.Being able to run directly off a 13.8 or 28 VDC source would be a major plus but AC power is also available. Hold over if there are gaps in GPS coverage is also a major plus. We already have a GPS with a 1 pps output, but an integrated box with it's own GPS would be best. Yes I am aware I could feed a 1 pps signal into a laptop and use that as a time server and I may end up going that route. There is a small Ethernet LAN in the vehicle. The pc's currently get their time via a wireless connection to various NTP servers. I need to be able to ensure accurate time on the PC's if there is no wireless coverage. This is for a one off project so piecing together various parts is an option but a single box COTS solution would be nice. I've found a few candidates via web searches but would welcome any feed back. Thanks in advance Mark Spencer ___ 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. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Small time server for mobile use.
Thanks. Yep running an extra Dc to Dc converter is an option but we already have access to clean 28 and 13.8 VDC supplies with some extra capacity. We could likely provide up to a 100 watts of power for this system (I doubt it would need that much.) The hold over requirement is in the range of several hours. The temperature swings could be fairly large (ie. cold soak outside at minus 35C, then inside a heated garage, plus what ever temperature the equipment bay rises to when the vehicle has been operating for some time probably less than 85 deg C.) mounting the equipment in locations other than the equipment bay would likely result in lower max temperatures. I'm not sure about the cooling capacity of the equipment bay, but there are other areas with climate control systems where this device could be installed if needed. I'm fairly comfortable that a device that generated up to 100 watts of heat could be accommodated (ie, I would assume all of the electrical power going into the device gets turned into heat) but would need to double check this. The size is somewhat flexible. To a certain extent the requirements could be adjusted to fit an existing COTS product that was perceived as generally suited to the application. As this is a one off requirement, that will be in use for a limited time some limitations can be worked around or lived with. The budget could be several thousand dollars. I thought about a Raspberry Pi type of solution, but need to factor in the cost of my time or that of someone else, plus there is a strong desire to either drop in a COTS black box or use a laptop. Thanks for the comments. Sent from my iPad On 2015-05-12, at 3:54 PM, Pete Stephenson p...@heypete.com wrote: On Tue, May 12, 2015 at 7:11 PM, Mark Spencer m...@alignedsolutions.com wrote: Hi sorry for a possibly OT post. Has anyone had practical experience with small commercially available time servers / ntp servers suitable for mobile use in a vehicle. I don't know about any commercially-available products, but it sounds like it'd be pretty straightforward to do with a Raspberry Pi or something similar if you don't mind a little bit of DIY. What constraints do you have on budget, size, power requirements, and cooling? The use case is I am in need of an accurate (ie. within 100 ms) time source for several pc's in moving vehicle.Being able to run directly off a 13.8 or 28 VDC source would be a major plus but AC power is also available. The Pi runs on 5V DC. DC-DC buck converters that can convert 7-35V to 5V DC are cheap, efficient, and widely available. Shouldn't be a problem. Hold over if there are gaps in GPS coverage is also a major plus. How long would you need holdover? Seconds or minutes (e.g. driving through a tunnel)? Hours? Days? Would the computers in the vehicle be subject to large temperature shifts? A Pi should be able to handle +/- 100ms of holdover in the minutes-to-hours range using NTP. We already have a GPS with a 1 pps output, but an integrated box with it's own GPS would be best. A tiny integrated module like the Adafruit Ultimate GPS breakout[1] is cheap, handy, and emits a 1PPS signal. It's also extremely small and can be purchased in hat form[2] that mounts directly to the Pi. Cheers! -Pete [1] https://www.adafruit.com/products/746 [2] https://www.adafruit.com/products/2324 -- Pete Stephenson On Tue, May 12, 2015 at 7:11 PM, Mark Spencer m...@alignedsolutions.com wrote: Hi sorry for a possibly OT post. Has anyone had practical experience with small commercially available time servers / ntp servers suitable for mobile use in a vehicle. The use case is I am in need of an accurate (ie. within 100 ms) time source for several pc's in moving vehicle.Being able to run directly off a 13.8 or 28 VDC source would be a major plus but AC power is also available. Hold over if there are gaps in GPS coverage is also a major plus. We already have a GPS with a 1 pps output, but an integrated box with it's own GPS would be best. Yes I am aware I could feed a 1 pps signal into a laptop and use that as a time server and I may end up going that route. There is a small Ethernet LAN in the vehicle. The pc's currently get their time via a wireless connection to various NTP servers. I need to be able to ensure accurate time on the PC's if there is no wireless coverage. This is for a one off project so piecing together various parts is an option but a single box COTS solution would be nice. I've found a few candidates via web searches but would welcome any feed back. Thanks in advance Mark Spencer ___ 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. -- Pete Stephenson
Re: [time-nuts] Small time server for mobile use.
m...@alignedsolutions.com said: Has anyone had practical experience with small commercially available time servers / ntp servers suitable for mobile use in a vehicle. The use case is I am in need of an accurate (ie. within 100 ms) time source for several pc's in moving vehicle.Being able to run directly off a 13.8 or 28 VDC source would be a major plus but AC power is also available. Hold over if there are gaps in GPS coverage is also a major plus. I don't have any experience with commercial units. (except looking at a few price tags) My straw man would be a Raspberry Pi. Adafruit sells a GPS card. (and all the other Raspberry Pi stuff you would need) http://www.adafruit.com/product/2324 Total parts cost would be under $200. The GPS card comes with a patch antenna which works inside my house. If that's not good enough, it has a connector so you can attach an external antenna. The Raspberry Pi needs 5V. The power connector is a micro-USB. If you have PCs, you can probably steal power from one of them. It's not ready-to-go. You would need somebody familiar with Linux and ntp, or willing to learn. That's both to set it up and for maintenance. If David Taylor's web pages aren't good enough, I'll be glad to help. -- 100 ms is pretty easy for ntp. How long do you want it to run? Is this for a ship which will be out for weeks, or a truck that goes out collecting data for an afternoon? For a short trip, it might make sense to run in holdover for the whole trip. An important thing that ntpd does is correct for the drift of the local clock. At 1 PPM error, it takes a whole day to drift 100 ms. It's easy for ntpd to get better than 1 PPM, but the target moves if the temperature changes. m...@alignedsolutions.com said: Yes I am aware I could feed a 1 pps signal into a laptop and use that as a time server and I may end up going that route. Is there any serial data to go with the PPS? There is a small Ethernet LAN in the vehicle. The pc's currently get their time via a wireless connection to various NTP servers. I need to be able to ensure accurate time on the PC's if there is no wireless coverage. Why not run ntpd on one of the PCs and set the others up to get time from it? Do you need time to agree with UTC or the PCs to agree with each other? -- These are my opinions. I hate spam. ___ 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] Time in a cave
If you don't require an accurate external sync (GPS), one options is to use solarflare 10GB NIC's with the high resolution clock on board, using this clock to govern the PC clock.Running PTP through this can yield +-250ns synchronisation between the nodes due to the hardware implementation for the PTP stack and does support external sync to a GPS PTP signal if available. I have no association with the company, but I like the product. http://www.solarflare.com/Precision-Time-Synchronization-PTP J. On Wed, May 13, 2015 at 9:00 AM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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. -- -- Teach your kids Science, or somebody else will :/ ja...@ball.net vk2...@google.com vk2f...@google.com callsign: vk2vjb ___ 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] Time in a cave
On 5/12/2015 6:00 PM, Tucek, Joseph wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe LTE and WCDMA both provide time, but it's a function of how carefully the operators actually maintain it. That's less of a problem today, but there are no absolute /guarantees/, even with IS-95 CDMA. The only guarantee is that the basestations in the system will track within a few microseconds of each other. What you don't say is how much accuracy you need. Is a hundred milliseconds enough, or do you need sub-microsecond absolute accuracy? How much holdover accuracy do you need? These are considerably different probelms. You indicate that you need to provide PTP to a 'cluster.' Is relative accuracy within the cluster all that's important, or do you need to coordinate with the outside? If so, there are a host of other considerations. Too many applications grossly over specify some requirements in the name of safety and miss critical performance needs. More information might let the group a more complete answer. -- mailto:o...@ozindfw.net Oz POB 93167 Southlake, TX 76092 (Near DFW Airport) ___ 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] Time in a cave
Can you use a cell phone as a time source? For instance I see: http://time-server.android.informer.com/ as an android app that is an ntp server. I know this depends on the accuracy of the cell phone network. On Tue, May 12, 2015 at 7:00 PM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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] Time in a cave
sync to UTC is a secondary concern so long as the cluster agrees with itself. If this is really true then you cancun off the PC's internal clock and set the PC's clock now and then with your wrist watch. OK so maybe you need to track UTC a little more closely. The question is (1) What is your accuracy requirement. Do you need Few tens of milliseconds or do you need nanoseconds. You say you are in a cave but then talk about CDMA. Which is it? What connectivity do you really have? Is this a tall building with a south facing window or a mine shaft. Can you access the Internet? If you can get any Internet connection and need only to be a few tens of mSec from UTC then us a set of NTP pool servers -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Time in a cave
HI Ok, some basics: GNSS = GPS, they are the same thing with the same issues, GNSS lets you hit the Russian system as well as the US. CDMA = your cell phone guy sets the clock. Many people have put *big* dollars into these systems only to find that the local cell phone guy(s) really don’t care what time it is. You can argue about that being right or wrong, we get to buy lots of stuff on eBay because it’s often wrong. Time synch at the user level is a manual (!) setting on the basestation equipment. It’s independent of the CDMA. You would have to check the setup at your local tower to know what they have done. You are also dependent on them not changing that setting as soon as you leave. Good luck getting any real information along those lines. Probably your best bet is an atomic clock of some sort (cheap Rb through Hydrogen maser). The only question is the budget being $200 or $200,000 (or something in-between). Bob On May 12, 2015, at 7:00 PM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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] Time in a cave
On 5/12/15 4:00 PM, Tucek, Joseph wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. But the entire cluster is interconnected? Or do you need some sort of wireless distribution. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). What about an off the shelf Rb that puts out 1pps or NTP or PTP. SRS (http://www.thinksrs.com/products/fs725.htm) does 1pps MicroSemi (aka Symmetricom,HP,Datum, etc.) has all manner of equipment that has quartz or Rb references and probably any interface you care to name (for a price). If you need sync to outside sources periodically, most of these could be carried to somewhere you have sky visibility to get a GPS 1pps, wait long enough to synchronize it up, then carry it back down and go on holdover. My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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] Time in a cave
On 5/13/2015 1:01 PM, Tucek, Joseph wrote: In reply to everyone (but mostly Mark Spencer): Does your cave have any connectivity to the outside world ? The cave has network connectivity, and is network close (but not physically close) to a high-quality surveyed GPS disciplined stratum 1 NTP server which we have permission to run off of. The cave is actually partially underground, and the bit that isn't has building on top of it. CDMA comes in enough to make your phone ring or receive a text, but phone calls are all I'm amazed it didn't drop ye[call dropped]. Antenna runs for GPS are not an option (I asked); it's too expensive/hard to get permission/too long, depending on which route to sky you want to take. Are there any places your cave has connectivity to that might have enough of a sky view to provide periodic gps coverage ? See above, but yes. Do you need a COTS (commercial off the shelf) solution or can you accept something that has been kludged together ? I can accept semi-kludge. Custom firmware on a model xyz phone sourced from ebay with a mere 5 wires soldered is great for fun time (and for fun I'd love to try it), but not so much for this. Single COTS would be great (yeah, and I want a side of fries with my flying unicorn), but here's two (or 3, or n) COTS things you usually won't plug together, but... is fine. Maybe 1 soldered wire Do you need a Peng or other professional to sign off on the solution ? Thank goodness no. We also don't need traceability to NIST either. A bit more information that people requested. We only need to be 1ms to UTC (100us would make some people happier, but then so would a GPS antenna run). The PTP sync inside the cluster, however, needs to be tight (sub 1 us if possible). PTP will do this if proper implemented, so it sounds like you're good there. Holdover isn't critical (24 hour OK, weekend better, month is overkill) so long as sync within the cluster remains tight. This is where a lot of smart people get into trouble. Don't thing of holdover as meeting all worst case specs. Figure out what you /really/ need. What will allow everything to work without catching fire? Given your description here, I'm guessing a millisecond or ten will do that as long as local cluster relative accuracy is maintained. It's really easy to over-specify this and get into exotic clock (for an industrial application) territory. 100 usec in 72 hours is 3.86 e-10 which is still in the range of a */really/***good quartz oscillator. There's a nice chart on slide 13 here: http://freqelec.com/oscillators/understnding_osc_specs.pdf I had a telecom customer that needed 5 us relative accuracy between all nodes synced over GigE. The specified 72 hour holdover at 1 us (3.86E-12) and were surprised (and offended) when when we said it would require a Rhubidium standard. After saner heads prevailed we were able to ship standard product. The cluster itself has proper hardware PTP support (NICs and switches) throughout, and is low radius -- 2 switch traversals from the grandmaster to each node tops. As for everyone's comments so far, it seems that there is an assumption that any PTP master worth its salt will keep its slaves tightly synced to one-another even if it has lousy sync to UTC. Am I reading between the lines correctly? Yes, the master will have a fairly low phase noise local oscillator as it's internal reference. Everything will synch to that. If all you are doing is syncing the local cluster you don't even care about time outside. This is true for most industrial applications that are just syncing machinery. -- mailto:o...@ozindfw.net Oz POB 93167 Southlake, TX 76092 (Near DFW Airport) ___ 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] TTi TF930/960 linux programming
I have the TI 930 and did run it from a computer - I did it under Windows but had quite a lot of trouble. It worked fine if I used the Windows own command line shell (I forget what it is called and I'm on a Linux machine at the moment) but when I tried communicating directly via the USB port (as COM3) using a c program I found it difficult to get responses. But this may well be my lack of knowledge of USB/RS232 under Windows. It might well be easier under Linux. Basically the instrument responds to command strings and you can set it to just return values continually which is what I did. I've since got the Tek FS3100 (Pendulum CNT91 I think) which is much more sophisticated and I started working on programming that. Unfortunately I've since got a job away from home so I have no time for electronics and won't have until I eventually manage to move house. If I were you I'd use a terminal emulator, at least at first, and get it going interactively and then just save the output to a file. Once you've got used to how it all works (and there isn't much to it) you can set up a more robust software system. James -Original Message- From: Florian Teply use...@teply.info To: Discussion of precise time and frequency measurement time-nuts@febo.com Sent: Tue, 12 May 2015 22:59 Subject: [time-nuts] TTi TF930/960 linux programming Hi guys, I seem to recall that someone on this list mentioned that he's using a Thurlby-Tandar TF930 or 960 Frequency counter. As I'm considering to buy such a unit for some experiments at my workplace, I figured I'd better ask around here for some suggestions. Has someone already used one of these gadgets in a computer-controlled fashion, with some luck using some Linux environment? Judging from the manual, I probably ccould hack some shell script to repeatedly perform frequency readings and write that to a file, but if someone already has done that I'd be much too lazy to reinvent the wheel... The actual setting I'd plan to use it in is to monitor some ring oscillators (frequency drift) and/or delay lines (output pulse length) sort-of-continuously over extended periods of time. I'd be interested in frequency drifts due to device aging and/or radiation effects, and as especially device aging tests can take quite some time (a few months each...), some sort of stability would be needed. This is not strictly a time-nuts application where one might chase the 10th digit, and I figure I probably could tolerate (and wouldn't even notice without cross-checking) an constant offset in frequency readings even of a few percent, but it would bite me quite a bit if the readings wander around too much when the input frequency doesn't... Any suggestions? best regards, Florian ___ 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] Time in a cave
In reply to everyone (but mostly Mark Spencer): Does your cave have any connectivity to the outside world ? The cave has network connectivity, and is network close (but not physically close) to a high-quality surveyed GPS disciplined stratum 1 NTP server which we have permission to run off of. The cave is actually partially underground, and the bit that isn't has building on top of it. CDMA comes in enough to make your phone ring or receive a text, but phone calls are all I'm amazed it didn't drop ye[call dropped]. Antenna runs for GPS are not an option (I asked); it's too expensive/hard to get permission/too long, depending on which route to sky you want to take. Are there any places your cave has connectivity to that might have enough of a sky view to provide periodic gps coverage ? See above, but yes. Do you need a COTS (commercial off the shelf) solution or can you accept something that has been kludged together ? I can accept semi-kludge. Custom firmware on a model xyz phone sourced from ebay with a mere 5 wires soldered is great for fun time (and for fun I'd love to try it), but not so much for this. Single COTS would be great (yeah, and I want a side of fries with my flying unicorn), but here's two (or 3, or n) COTS things you usually won't plug together, but... is fine. Maybe 1 soldered wire Do you need a Peng or other professional to sign off on the solution ? Thank goodness no. We also don't need traceability to NIST either. A bit more information that people requested. We only need to be 1ms to UTC (100us would make some people happier, but then so would a GPS antenna run). The PTP sync inside the cluster, however, needs to be tight (sub 1 us if possible). Holdover isn't critical (24 hour OK, weekend better, month is overkill) so long as sync within the cluster remains tight. The cluster itself has proper hardware PTP support (NICs and switches) throughout, and is low radius -- 2 switch traversals from the grandmaster to each node tops. As for everyone's comments so far, it seems that there is an assumption that any PTP master worth its salt will keep its slaves tightly synced to one-another even if it has lousy sync to UTC. Am I reading between the lines correctly? Thanks for the help so far. -Joe ___ 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] HP-117A and MSF ?
Iain The 117 would have worked for msf at 60 KHz and lucky you to have operational loran still. MSF as far as I know is not using any bpsk signals and i think at the top of the minute there was a carrier drop. Not off but a reduction. So that can cause the 117 an issue in tracking. But yes I used to use the 117 on msf and wwvb. On the east coast of the US at night funny things would happen between the 2 signals. The 30 V you reference was intended for a nuvistor preamp at the antenna. This is easily replaced with 2n3904 transistors as an example. Or the real loop antenna if you actually have it. Now the fact that you have LORAN timing receivers perhaps is a real benefit as the phase changes you see from the 117 will represent the propagation behaviors. That used to be fun to watch. But we messed all that up in the US. Regards Paul WB8TSL On Wed, May 13, 2015 at 2:40 PM, Iain Young i...@g7iii.net wrote: 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. ___ 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] Time in a cave
In response to Oz-in-DFW Given your description here, I'm guessing a millisecond or ten will do that as long as local cluster relative accuracy is maintained. Spot on; I hope I'd made it clear earlier, but perhaps I've been communicating poorly. My goals w.r.t. to sync to UTC and w.r.t. holdover are very loose. I do need time sync intra-cluster to be tight (sub millisecond, 100 nano as a stretch goal). UTC sync can comparatively be terrible; 10-1 ms is fine, and I can live with bad NTP, 100 ms if I must. From specs, */really/* good quartz is my limit and /good/ quartz is acceptable, so long as it doesn't mess with the intra-node PTP tightness. I'm mostly looking at TCXO options. OCXO isn't out of the question, but rubidium doesn't seem to give $/value. Yes, the master will have a fairly low phase noise local oscillator as it's internal reference. Everything will synch to that. If all you are doing is syncing the local cluster you don't even care about time outside. This is true for most industrial applications that are just syncing machinery. Thanks for the info. PTP isn't as well understood/documented as NTP, so I've not been as certain about my decisions. Of course, that is fair for a relatively new standard. Currently, I think my two best options are: 1) CDMA enabled PTP appliance (set and forget), or 2) PTP appliance running as stratum 2 from good NTP. Thanks to everybody for the feedback. -joe ___ 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] Time in a cave
Hi a few questions, Does your cave have any connectivity to the outside world ? Are there any places your cave has connectivity to that might have enough of a sky view to provide periodic gps coverage ? Do you need a COTS (commercial off the shelf) solution or can you accept something that has been kludged together ? Do you need a Peng or other professional to sign off on the solution ? (In my experience PTP may on occasion be found in industrial settings where a Peng may be required to sign off on the solution.) Mark Spencer On 2015-05-12, at 4:00 PM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP to a cluster where we don't have line of sight to the sky, and are unlikely to get roof-rights without a fight. There are CDMA solutions that would work (e.g. Endrun Technologies), but I was wondering if there were any other options. I either need an indoor capable PTP, or an indoor capable PPS. Microsemi claims to have an indoor capable GNSS system, but I've yet to find a sales rep to talk about it; if anyone has a link to one who can, I'd love to find out the problems^W^W^W^W talk to them about it. For an example of something that almost but doesn't quite work, Beagle Software has a CDMA NTP server, but they do neither PTP nor PPS in the CDMA version. Similarly, Meinberg will sell a PTP unit that freeruns (if you override the config), but they have no solution to discipline via CDMA. I'm also curious if anyone has any idea about non-GPS time sync after CDMA gets turned off (can I get time from 4G?). My endgame worst case is to just do PPS from a stratum 2 NTP (or even a freerunning oscillator) and lie to my PTP server; hard sync to UTC is a secondary concern so long as the cluster agrees with itself. Endrun is looking pretty good, but I'd really like to have a second option to compare against. -Joe ___ 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] Time in a cave
Hi Any CDMA device is a *really bad* idea. It’s perfectly legal to run CDMA several seconds out of sync with UTC. There are a number of networks that do exactly this. PTP is fine as long as *all* your network infrastructure (switches / hubs / routers) is PTP enabled. If any of your links are not fully PTP stamping devices you will get into time issues as your network load varies. Bob On May 13, 2015, at 5:44 PM, Tucek, Joseph joseph.tu...@hp.com wrote: In response to Oz-in-DFW Given your description here, I'm guessing a millisecond or ten will do that as long as local cluster relative accuracy is maintained. Spot on; I hope I'd made it clear earlier, but perhaps I've been communicating poorly. My goals w.r.t. to sync to UTC and w.r.t. holdover are very loose. I do need time sync intra-cluster to be tight (sub millisecond, 100 nano as a stretch goal). UTC sync can comparatively be terrible; 10-1 ms is fine, and I can live with bad NTP, 100 ms if I must. From specs, */really/* good quartz is my limit and /good/ quartz is acceptable, so long as it doesn't mess with the intra-node PTP tightness. I'm mostly looking at TCXO options. OCXO isn't out of the question, but rubidium doesn't seem to give $/value. Yes, the master will have a fairly low phase noise local oscillator as it's internal reference. Everything will synch to that. If all you are doing is syncing the local cluster you don't even care about time outside. This is true for most industrial applications that are just syncing machinery. Thanks for the info. PTP isn't as well understood/documented as NTP, so I've not been as certain about my decisions. Of course, that is fair for a relatively new standard. Currently, I think my two best options are: 1) CDMA enabled PTP appliance (set and forget), or 2) PTP appliance running as stratum 2 from good NTP. Thanks to everybody for the feedback. -joe ___ 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] Time in a cave
On Tue, May 12, 2015 at 7:00 PM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP I believe this was recently discussed on ntp:questions. People often forget dial-up (ACTS) which is supported by the PTP capable Microsemi SyncServer 3NN models which also have OCXO/TCXO/Rb hold-over options. EndRun used to make ACTS capable units as well but I believe the current products are RF only. If your UTC requirements are sufficiently loose you can use VoIP as opposed to a tradition land-line. ___ 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] Time in a cave
Tucek, Joseph writes: I do need time sync intra-cluster to be tight (sub millisecond, 100 nano as a stretch goal). UTC sync can comparatively be terrible; 10-1 ms is fine, and I can live with bad NTP, 100 ms if I must. From specs, */really/* good quartz is my limit and /good/ quartz is acceptable, so long as it doesn't mess with the intra-node PTP tightness. I'm mostly looking at TCXO options. OCXO isn't out of the question, but rubidium doesn't seem to give $/value. If you want intra-cluster at sub-millisecond, NTP is possible, and that should be trivial with PTP. I've been attending the ISPCS plugfests for the past few years' time and I've been making sure that we can take time from upstream NTP or PTP, and distribute that time via NTP or PTP. Yes, the master will have a fairly low phase noise local oscillator as it's internal reference. Everything will synch to that. If all you are doing is syncing the local cluster you don't even care about time outside. This is true for most industrial applications that are just syncing machinery. Thanks for the info. PTP isn't as well understood/documented as NTP, so I've not been as certain about my decisions. Of course, that is fair for a relatively new standard. Network Time Foundation includes the NTP Project, Ntimed (and PHK plans to at least look at PTP support sometime), and 2 PTP projects - PTPd, which is designed to be portable and generally useful, and Linux PTP, which is designed to be optimized for the latest Linux kernels. Currently, I think my two best options are: 1) CDMA enabled PTP appliance (set and forget), or 2) PTP appliance running as stratum 2 from good NTP. Either should be fine. I saw you can't run an antenna wire from where you'll be, but perhaps a lan cable? That might go to either a GPS device or to a small NTP or PTP device. NTF is working to improve the products under its umbrella all the time, and we're seriously resource-constrained. OK, we're disturbingly resource-constrained. While the PTPd folks seem to have enough developer resources and Richard Cochran has not complained about the developer resources for Linux PTP, none of the projects have adequate documentation writers. Guess what I think would be a Swell Idea? -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ 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] Time in a cave
Paul writes: On Tue, May 12, 2015 at 7:00 PM, Tucek, Joseph joseph.tu...@hp.com wrote: I'm looking for information on non-GPS time sources. For background, I need to provide PTP I believe this was recently discussed on ntp:questions. People often forget dial-up (ACTS) which is supported by the PTP capable Microsemi SyncServer 3NN models which also have OCXO/TCXO/Rb hold-over options. One problem is that while ACTS used to be a very good way to keep time, now that modems no longer have constant processing time and phone lines are no longer end-to-end copper and the signal likely goes thru a number of domain changes (Audio/Digital, Frame Relay, ATM, ...), I'm told that ACTS is nowhere near as good as it used to be. H ___ 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] New 5370A
I got a new 5370A, so of course I've been running a bunch of tests on it. In the image linked below, the start channel is my PRS-45A, the stop channel is my GPSDOe (e is for engine) and the ARM channel is fed by the PPS from my SSR-6Tru. As you can see in the notes, the test parameters are all the same, except for the clock source for the 5370A. As you might guess, my question is about the blue line, which is where the 5370A uses its internal 10811 as its clock reference. Is it normal for tests run like this to have the left side of the ADEV be such a wiggle on the internal reference? I had noticed the same thing with the 5335A I've been using up till now and had just assumed there was a problem with its 10811. The OCXO in my GSPDO is a surplus Trimble 34310-T. It's been running for several weeks, but is still in retrace. http://evoria.net/AE6RV/5370A/Test1.png And kudos to John for Timelab. It doesn't play well with Wine in Linux, but that's not terribly surprising, all things considered. Bob ___ 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.
