How would you like to help fix the Internet?
One of the efforts I’ve been contributing to during the last year is the Bufferbloat project, a group of experienced Internet engineers who believe that excessive buffering and poor queue-management strategies may be the real villains behind a lot of network problems commonly attributed to undercapacity.
Before we can solve the problem, we need to measure and map it by collecting a lot of packet-propagation-time statistics. Awkwardly, we suspect that one of the services being screwed up by bufferbloat-induced latency spikes is the Network Time Protocol. So…Dave Täht (aka Dave from my basement) is trying to build a device he calls the Cosmic Background Bufferbloat Detector. The CBBD would be a flock of routers scattered all over the world, watching NTP packet timings using a common timebase independent of NTP, and sending data back to a collection server for analysis and visualization.
That’s where I, as the lead of the GPSD project, come in. GPSes are an obvious candidate for a high-precision NTP-independent time service. But there’s a problem with that…
With rare and extremely expensive exeptions, GPSes only report time to a hundredth of a second, at most, in their data stream. And we’ve found by experiment that SiRFs, the chip used in 80% of consumer-grade GPSes, has about a long-period wobble of up to 170 milliseconds in its time-reporting latency. This is no good; NTP time is supposed to be accurate to 10 milliseconds, so for diagnostic purposes we therefore want a timebase about an order of magnitude better than that or at about 1ms accuracy.
There is a way to get this from GPS. GPS chips have an output called 1PPS, a pulse that’s emitted at the start of each GPS-clock second with accuracy to 50 nanoseconds. So, in theory, simple: you use the 1PPS to trigger an interrupt on your host machine, latch that as top of the second, and use it to condition your clock. Even with the expected amount of interrupt-processing overhead you can expect this to keep your local clock accurate to the common timebase to about 10 microseconds – two orders of magnitude finer than our 1-millisecond accuracy goal.
GPSes, or at any rate the sort of inexpensive GPSes you’re limited to when you’re contemplating deploying a hundred or more attached to CBBD routers, are simple beasts. They’re built around a module like the SiRFStar II or III that’s basically a single chip with RF and signal-processing stage for the GPS. That module ships TTL-level serial data, with two lines for TX/RX, a ground, RTS, and a fifth wire carrying the PPS strobe (usually mapped as the DCD or Data Carrier Detect line).
Typically these wires are carried to a serial-to-USB converter such as a PL2303 which provides the data path off the device. Yes, some GPSes go to RS232, but that’s increasingly uncommon and we couldn’t use those anyway because the inexpensive routers we can afford to deploy by the hundred only have USB ports. Yes, serial-to-USB adaptors do ship an event corresponding to a change in DCD line state; turns out USB latency costs you about 50 microseconds of slop, which is well within our maximum error budget.
This is where it gets messy.
You see, in order to cut costs (or something) most GPS manufacturers drop the 1PPS strobe line on the way out. They could connect it to the DCD input on the serial-to-USB converter, but they don’t.
Now let me introduce you to two devices. Exhibit A is the Globalsat BR355. I have one on my desk. This is an extremely typical consumer-grade GPS mouse based on the SiRFStar III. It doesn’t ship 1PPS, though older versions sold under the same name apparently did – removed to cut costs.
Exhibit B is the ZTI Z050, advertised as a USB navigation and timing dongle. It fits a GPS chip and serial-to-USB converter in a thumb-drive case. It uses a different, non-SiRF chip called a Trimble, but that’s a detail; it ships to the converter over TTL just like the SiRFStar. But the ZI050 does carry the 1PPS trace to the serial-to-USB converter, and you can see PPS events on the USB bus. ZTI advertises 1ms accuracy,
Essentially, the logical differences between these devices come down to the presence or absence of one trace on the circuit board.
The BR-355 costs $36. The Z050 says “call for quote” and I was told $950. Yes, that’s right; that one PPS trace costs $914.
Now, part of this is the North American distributors marking the device up insanely. A European friend caled ZTI direct and was quoted €175 or about $225. That’s not the highway robbery the distributor was attempting (they’re called “Omnicor” – try not to give them your business) but it’s still bloody ridiculous.
So I’m trying to think up a solution, and it occurred to me that building your own USB GPS from parts and a custom circuit board isn’t that complicated. One of my GPSD devs has actually done it. We can’t use a homebrew GPS for this deployment, that wouldn’t scale to a hundred units, but …
…isn’t there an opportunity here? It ought to be possible to manufacture a timing dongle like the ZI050 really cheaply; remember, the PCB-level difference is between it and that $36 BR-355 is basically one trace. One design engineer with connections to a Taiwanese job shop ought to be able to get a thousand of these cranked out at barely $10 a pop.
That’s what I’m looking for. These clowns should have competition. So, calling all open-source hardware engineers – can we do this thing? Spec a parts list, design a PCB to fit in a thumb drive, publish it as an open design, and then actually get the little sucker manufactured?
There might even be money in this. The Bufferbloat project wants at least a hundred of these for the CDDB, and the thumb-drive form factor could make it really popular with laptop users.
Anybody feeling entrepreneurial?
While I’m certainly willing to believe that dubious buffer management in low-level internet code is a problem (because it’s software, and most software is badly broken, for a lot of good sound economic reasons), my gut feel is that root cause of any given slowdown that anyone is seeing comes down to “fuk’n youtube”. Optimizing protocol stacks is gods work, but isn’t going to do a huge amount of good handling a flood of video through sort-of-but-not-really-video-friendly pipes.
I’ve looked at the specs for 32 Channel San Jose Navigation GPS 5Hz (99 USD on sparkfun) and in the specs pin7 is iPPS.
Not sure if it would be quick enough, but an Arduino with an ethernet shield & small custom board for the GPS? A GPS shield exists, not sure it it conflicts with the ethernet shield.
Could run standalone? or hook upto a PC via USB.
Re Sparkfun and Arduino: the dev I mentioned earlier (Chris Kuethe) built his own rig from Arduino parts after discovering that none of the Sparkfun boards bring out 1PPS. (He rechecked this while I was on the phone with him a couple of days ago.) But a hand-build approach won’t scale to the required number of units.
I haven’t studied the various boards and chips, but Sparkfun carries lots of GPS modules:
http://www.sparkfun.com/categories/4
If you can identify one of those that meets your needs, we could fairly easily hack something together, test it, and then either recommend that (probably < $150) or do as you suggest and lay out a new board.
Sparkfun also has a GPS buyer’s guide — haven’t read it yet.
http://www.sparkfun.com/tutorials/127
I see Mouser sells the Maestro A1035-H for about $20, and it has a 1PPS pin (pin 15): http://www.mouser.com/ProductDetail/Maestro-Wireless-Solutions/A1035-H/?qs=sGAEpiMZZMsa9w4dmI1JYEv5hDt7Ew5Y
A carrier board with an FTDI chip would be all that’s needed, plus some sort of (GPS-transparent) enclosure to make it pretty.
It looks like regular Mouser links are not made for human use. This one will work though: http://www.mouser.com/_/?Keyword=927-A1035-H&FS=True
If it is just a missing trace, would it be feasible to simply solder a wire on it in 100 units?
And Adafruit has one for $40 they claim offers precision time:
http://adafruit.com/products/272
But that one and some of the ones at sparkfun use a Sirf chipset. Does its wobble extend to the pulse pin you’re interested in?
>And Adafruit has one for $40 they claim offers precision time:
The Adafruit looks possible.
>But that one and some of the ones at sparkfun use a Sirf chipset. Does its wobble extend to the pulse pin you’re interested in?
No. The wobble is in the latency of time delivery off-chip via the TTL-pins-to-RS232 or -USB path.
I believe one can obtain both a GPS “shield” and a USB interface for an Arduino at a reasonable cost. Its all open-source too.
Actually, there are now several industrial modules available. For example, at mouser:
http://www.mouser.com/Embedded-Solutions/RF-Wireless-Modules/_/N-6f8ws?Keyword=gps&FS=True&Ns=Pricing|0
Is there anything wrong with the Garmin 18x LVC or Garmin 18x-5Hz?
Those appear to be in nice packages for around $60 and claim 1 us accuracy for the timing pulse.
>Is there anything wrong with the Garmin 18x LVC or Garmin 18x-5Hz?
The Garmin 18 is really frustrating. It comes in three variants. The PC and USB ones don’t bring out 1PPS. The LVC does – but the data cable ends in bare wires! You’re intended to crimp your own connector and interface to them.
BTW, electronic parts pricing is extremely volume sensitive.
Often, you can buy something like this much cheaper than you could possibly make it, or even have a Taiwanese job shop make it, unless you’re prepared to make at least several thousand.
If you’re fortunate, the price break for a part comes at small quantities. For example, one balun I use costs $16. Or $4 if I buy 10. That’s right — I can buy 10 of them cheaper than I can buy 3 of them. And the price break for buying 1K or 10K of something is often 90% or more.
Huh. Didn’t see Andrew Filer’s comments before I mentioned mouser. Moderation queue stuff?
Here’s a tutorial using the garmin device and gpsd:
http://www.lammertbies.nl/comm/info/GPS-time.html
A couple of jobs ago, I got involved with commercial GPS hardware; you’re right that the manufacturer’s markup in small quantities is insane, but that’s why scaling up is so important.
Where are you planning on deploying these USB-GPS widgets? If you’re going to be using them indoors, you’d better plan on having an external antenna port.
>Where are you planning on deploying these USB-GPS widgets? If you’re going to be using them indoors, you’d better plan on having an external antenna port.
Indoors near windows. We think this is enough skyview for time with modern RF stages, but that’s an assumption that will require careful testing with prototypes.
This can be done with these two, an enclosure and mounting hardware, a passive antenna, and some bits of wire:
http://www.sparkfun.com/products/718
http://www.sparkfun.com/products/11058
It can be bus-powered if the GPS is jumpered for low-power startup. Active antennas would need an extra 3.3V regulator to power the GPS.
Unfortunately, the device at Adafruit has no PPS signal at all.
>This can be done with these two, an enclosure and mounting hardware, a passive antenna, and some bits of wire:
Hackers. You tell them hand-build approaches won’t scale, and they respond with – hand-build recipes.
I know that the better the clocks, the better you measurement, which needs very good leads (witness the neutrino speed problems). So I understand your drive to get very precise GPS clocks.
But your problem seems to one that could be solved by Network Tomography.
https://en.wikipedia.org/wiki/Network_tomography
With tomography you can work with timing differences, eg, return trafic times and route difference times that hit specific nodes. Then you might be able to do away with global time precision and do with only very precise timing differences.
I am sure I am missing something here. But from your post I do not understand why you need high global (absolute) time precision instead of relative time difference precision.
>But your problem seems to one that could be solved by Network Tomography.
The CDDB approach is a variant of delay tomography. But if you read the description of that technique carefully you’ll see that it requires a common timebase, otherwise the delay timings might be corrupted by clock skew.
>I do not understand why you need high global (absolute) time precision instead of relative time difference precision.
We don’t in fact need absolute time. What we do need is a common timebase – the ability to match timestamps across the net. The valuable thing about GPS is that it’s a low-cost way to refer to a common timebase at global scale.
@esr
I would love to see a “useful*” link to an overview of the CDDB approach. Could you post one?
I once discussed whether it would be possible to use network tomography to determine the physical (cable) distances between an unknown networked computer and routers and servers with known geographical positions. I still think that must be possible.
*Useful: I can stand quite a lot technical and mathematical content. But not the level to reproduce a tomography imaging program.
> Hackers. You tell them hand-build approaches won’t scale, and they respond with – hand-build recipes.
Oh, I know it won’t scale, but that gives someone a good idea what the circuit needs to contain.
Eric,
Make a real proposal, take it to Kickstarter. If you get N backers/customers, have it built.
Otherwise, the idea probably sucks.
No idea if this is useful but my go to place for little devices like that is a Canadian company called Phidgets (needless to say I am a major stockholder who will personally benefit massively from this endorsement. :-)
They have a GPS device that claims a timing accuracy of 300ns, and is about $80 in quantity.
http://www.phidgets.com/products.php?product_id=1040
I’m not knowledgeable enough to judge the merits but I thought I’d mention it to you. I am sure also that I don’t have to tell you that at that level of precision you are going to have to know physically where the device is located, along with the ephemeris data on the satellite, and adjust according to the propagation delay. But I am sure you already thought of that.
Sparkfun.com has modules for $50 or less. Many routers have internal serial and run at 3.3v
Adafruit.com is another source, as well as some of thebuild-a-drone places.
You don’t really have a spec but I’ve built something like that. Sparkfun’s boards are opensource.
And there is a variant of the skytraq that can do 10nS from gps – it does only timing from gps.
http://www.sparkfun.com/products/11058 – schematic and Eagle (circuit board) files available.
You would need an antenna and then connect the RxD and the PPS.
20Hz – this is what I use on my harley.
They also have a devkit and I can do my own firmware (only 10Hz) for the SkyTraq itself.
I am not sure why you would use routers for this project. If you intending to deploy routers for traffic analysis then OK, but I would still use a TS7200 rather than an actual router. Or, if you are going to use a router, use one that has open code. If that is what you’re doing then I would suggest that you consider using the PTP protocol instead of trying to build something around GPS. And, if you rewrite PTP to include the use of RDTSC then you will have your extremely accurate time base.
The Phidgets link Jessica mentioned looks interesting.
If you really want someone to build a few hundred, you should work with seeedstudio.com or one of the guys who already works with them, like dangerousprototypes.com
They have several business models available already, and I’m pretty sure you’ve influenced them :-)
http://www.weirdstuff.com/cgi-bin/item/20164#
http://www.correctivephrenology.com/blog/?p=14
http://eshop1.chem.buffalo.edu/600M-GPS.html
Using a $3 chip (ATtiny2313), maybe $5-10 system cost not counting the GPS, I can send out a non-NMEA character, e,g @ or # at the PPS (1 char time jitter if the GPS is already sending), 100uS at 115200 baud), and then pass through the rest of the NMEA stream. So it would be GPS -> AT2313 -> USB serial. Of course you can use two USB UARTs
Note the antenna is important – either an active antenna you can place near a window, or at least a larger, maybe amplified one, or the USB cable will have to be long. If it is one of those modules you will need to keep it away from a router doing wifi.
Sparkfun has a $50 module with PPS http://www.sparkfun.com/products/10702 – 3.3v.
The Phidget is basically a SkyTraq (I can’t see if it is the 624 or 628) with a USB connection and does NOT have a PPS output broken out.
Take the SparkFun SkyTraq Venus 628 module, and add an ATtiny4313 (baud rate friendly crystal, with ISP header for programming and jumper block to select how to connect the serial ports and for initial GPS setup and general breakout so the board will be useful elsewhere). Add a USB to serial chip and connector, PL2303 or FTDI and 5v to 3.3v regulator and backup battery/cap. Include the SMA magnetic antenna and you have the system.
@tz:
Disclaimer: I haven’t looked at the Phidget and don’t know how it does what it claims to.
I could be wrong, but I thought the PPS output was an example of an enabling technology rather than a requirement.
The requirement was stated to be met with least 50us of precision at the computer. If the Phidget really somehow lets you get within 300 ns, that more than meets the requirement.
What chance is there that there is an Android phone that brings out the 1PPS signal from its internal GPS. Or, if such a thing doesn’t exist, that you can convince Google to make such a thing happen for the next-gen Nexus platform?
Then your future cast-off Google Nexus could be a nice USB-based GPS clock.
Google must be concerned about buffer bloat.
I dont understand your comments on scale. What exactly do you want? Do you want ~100 devices for your project, or do you want someone to start selling a cheap USB/GPS timer?
If its the former then ~100 devices could be hacked together in about a week. And if the hack only needed basic soldering skills then some members of your project will be able to hack their own anyway.
Whats your target unit cost?
If all you need to do is solder on a wire expose the 1PPS signal in the GPS shield, flash the Arduino, drill a couple of holes in a project box & plug it all together then I don’t see why you need a custom design.
And sparkfun (or others) might be open to revising their design of GPS shield to expose the 1PPS line making the build easy for anyone on your project.
Its not an optimal solution, but gets the job done.
Eric,
Perhaps the one-off would scale. What if a few of your GPSd folks taught a free “design and build” lesson at their local hacker spaces.
10 spaces, 10-12 students per class, you create 100-120 devices, which can then be used with your project.
Let the hackers work, man, let ’em work.
The ZTI is expensive because it is accurate to +/-25 nS and that goes over USB with corresponding driver. The SkyTraq should be accurate to +/-30 (and SkyTraq has a variation that can go to +/-10 with correction – it says the pulse is that early or late).
@Patrick – I went to the Phidgets site and got the docs and pics available. To do 1PPS you need that pin broken out or attached somewhere and it isn’t and there aren’t any apparent connections.
@Larry – zero chance on android, I don’t think OpenMoko does either. Cast off cell phones (used, refurb) are also expensive, at least those with GPS. Even the cheap chinese android devices won’t have this.
@alanuk – Good Point – I forgot to ask. What is the quantity? 100? 1000? More? Most of this is the tooling charge so it should be a lot cheaper per-unit in quantity. Perhaps a kickstarter project is in order.
>What is the quantity? 100? 1000? More? […] Perhaps a kickstarter project is in order.
We’re looking at 100 firm, two or three times that if the project really takes off.
Kickstarter is an interesting idea for gathering funds for a fabrication run. I’ll investigate it.
@tz:
But they claim 300 ns timing accuracy. If they actually provide that at the computer, that solves the problem without requiring the 1PPS pin. If it’s a marketing lie, that’s a different story.
>But they claim 300 ns timing accuracy. If they actually provide that at the computer, that solves the problem without requiring the 1PPS pin. If it’s a marketing lie, that’s a different story.
A problem with the Phidget is that there’s not enough structure in its datastream, as described, to make it self-identifying the way a GPS is. That really, really complicates things – enough to disqualify it, actually.
If you can characterize the average of that wobble to within X ms, and the clock on your computer was accurate enough, wouldn’t it be possible to derive the time to within about X ms eventually by sampling?
You’ld presumably need to do it for each GPS (sub-)model, though, so I’m not sure if that actually is much of a win…
>If you can characterize the average of that wobble to within X ms, and the clock on your computer was accurate enough, wouldn’t it be possible to derive the time to within about X ms eventually by sampling?
Yes, but X would be significantly larger than our target accuracy. The wobble is very noisy.
@esr:
One thought about why they didn’t hook up that pin. It might upset/annoy drivers and/or software (perhaps even more on that other operating system) to think that the modem status keeps arbitrarily changing like that.
Eric,
I have an Sure Electronics MG1613S here that provides PPS after the soldering one additional wire. See these two links:
http://www.leapsecond.com/pages/MG1613S/
http://www.satsignal.eu/ntp/Sure-GPS.htm
The chip is a MTK-3301 and it works fine.
Winter said: I once discussed whether it would be possible to use network tomography to determine the physical (cable) distances between an unknown networked computer and routers and servers with known geographical positions. I still think that must be possible.
If one Knew (to a sufficient, read very high, level of accuracy) the delay characteristics of the routers and network hardware that were Unknown – and if they were consistent enough [or the outliers obvious enough to filter out] in that delay, yes, it seems like it ought to be possible.
The problem is that one doesn’t know their delay characteristics very accurately, does one? Realistically I’m not sure someone outside the network can determine them at all, let alone sufficiently accurately to do cable length determination.
Determining the length of a piece of wire via timing is … tricky*, shall we say. The speed of light is very fast and thus the delays from wire are ver’ ver’ small (about a microsecond per mile!). At that level I’m not sure I trust my local network hardware to process the packets in such a way as to not destroy the timing…
I’d expect “everyday” network hardware to have jitter far exceeding wire-length delay – or at least close enough to it to throw off all the math.
(Alternatively, is there some Deeply Very Subtle analysis that somehow makes all that go away and makes it plausible to do sub-microsecond timing analysis of remote network traffic?
That would be awesome. Literally.)
(* I recall my mother talking shop about that, related to writing and debugging software for cable/fiber testers that did Very Complicated Analysis And Math not only find out that there were faults in a very long run of fiber, but where they were along it.
Trying to do that sort of thing by analysing what would sort of have to boil down to ICMP reply time jitter or something like that?
I’m dubious about the information being present, literally.)
@Sigivald: What I assume ESR is after is placing a “router” right on the port where the internet is connected with a GPS to compare network time protocol (NTP). Every such timerouter would know the precise second, so the NTP latency from near and far could be measured.
Note: if the various NTP sites go through different numbers of switches, that might suffice.
What might be more interesting is to use the GPS 1PPS interrupt (and I have two with perfectly synced pps outputs on my scope right now) to send a packet (or packets) out so you could determine the exact latency between any two nodes with such devices. You could do so to a centralized location but the geodesic would be more interesting, sort of a real-time map of internet latency.
Dunno if it’ll help, but I posted this to the Arduino forum. Lots of folks over there who have experience that could help.
http://arduino.cc/forum/index.php/topic,94755.0.html
I wonder if crowdsourcing this could be effective. Or perhaps contact Limor Fried? She’s enthusiastic about open source, and surely knows something about getting stuff built.
A naive question from someone unfamiliar with the dirty details:
Assuming you get the time references built and working, so that you now have accurate delay measurements, how can you tell the difference between delays caused by buffer bloat and delays caused by simple bad routing?
Eric,
although you’re justifiably partial to GPS, have you also researched radio-controlled clocks as a time reference for your project? Wikipedia, admittedly without citing a reference, says that they, too, can give you your desired precision of 1ms, limited by the margin of error for the delay in radio transmission.
Advantages:
(1) It’s long-wave radio, so it’ll naturally work everywhere in the building, even with no skyview at all. You won’t need “careful testing with prototypes” to check for adequate reception.
(2) There’s a dude with a website by the name of Jonathan, who appears to have built something similar to what you want, parts list and all, for about $50. His heart seems to be in the right place for an open-hardware project, since he released his source code for the Linux client that listens to his device. Perhaps the two of you could talk about massaging what he already has into the mass-producible, thumb-drive-sized solution you need?
Disadvantages:
(1) Because each receiver will sit at a different distance from the atomic clock whose transmitter it listens to, each will need individual calibration before delivering the precision you need. And Jonathan’s default mode of calibration involves—you guessed it—GPS and NTP.
(2) The atomic-clock radio transmitters across the world don’t all broadcast at the same frequency. Hence, your PCBs would probably need to accommodate some variety of receivers, in smaller quantities of each. If so, this will keep the price higher than with the GPS approach.
But hey, maybe the disadvantages can be worked around, so what’s the harm in putting this idea out there? Whichever way you end up doing it, good luck!
>have you also researched radio-controlled clocks as a time reference for your project?
I have. In addition to the precision and signal-availability issues noted by a previous commenter, we’d be looking at a complicated deployment problem because we’re looking to set up monitoring routers all over the world – multiple radio clocks for different regional time services. GPS is plain simpler.
Eric. Want a low cost high precision GPS. You can buy any number of Motorola Oncore UT+ receivers for under $20 each on eBay. These have a 1PPS with 50 nanosecond (1 sigma) error. That is better than you need and cost is under $20.
The telecom industry has been dumping thousands of very high end GPSes for dirt cheap and some how they end up in China and then on eBay. Even with shipping prices are low and most of these Chinese sellers are good and honest.
The current, introduction version of this use is an MT+ that sells for $60 and they have the error down to 2 (yes two) nanoseconds. $60 is not a bad price for that.
http://www.synergy-gps.com/images/stories/pdf/m12mt_brochure.pdf
If it mist be USB you’d need a converter cable. And of course any GPS needs a good clear view of the sky
>You can buy any number of Motorola Oncore UT+ receivers for under $20 each on eBay.
These all seem to be uncased boards. That means we’d have to find cases for them and assemble cased units, whivch is exactly the sort of thing that doesn’t scale well up to a hundred-unit deployment.
The comment above about radio clocks sounds good until you actually try. First off reception is not a sure thing. and you are not likely to get anything at all in the day time. While until around mid night. next the time code that is transmitted is only good to whole seconds.
If you need software to decode the bits, look at the NTP source code, there is a reference clock driver in there
If you want a hardware solution coax makes t and digikey sells it. Not expensive. the little units comes with an antenna
http://www.google.com/url?sa=t&rct=j&q=cmax%2060khz%20radio&source=web&cd=3&ved=0CDMQFjAC&url=http%3A%2F%2Fwww.c-max-time.com%2Fdownloads%2FgetFile.php%3Fid%3D542&ei=4KRRT_-8HYGziQLjt9C0Bg&usg=AFQjCNGvpf6XhCdN-dA_3rH922i45o5ccg
http://www.sparkfun.com/products/10060
But these are, like I said only good for about 1 second resolution and only at night. You could do better but you’d need a big loop antenna and to place it outdoors for from a house or electronics
For best bet will be to buy up some timing GPSes that are being surplussed by the telecom industry
Not that this would be cheap, but this has to be the best GPS hacker dude out there:
http://www.holmea.demon.co.uk/GPS/Main.htm
This electronic parts search engine might help someone find something useful.
http://octopart.com/
Octopart
It is a Y Combinator-backed startup company based in New York City.
Good luck.
Cases would likely be the easy part. If PacTec doesn’t have a case style in stock that would work, at 100qty or more, they would no doubt be more than willing to customize one of their designs, or even create something from scratch.
Have you considered doing all this in hardware?
There are many microcontrollers that have simple TCP-IP interfaces. I’ve even found a number that have libraries for getting NTP data. It should be pretty easy to hack something that does *everything* together. Just plug it in, connect ethernet, make sure it can see the sky, and you’re good.
As an added bonus, you could know the cycle-accurate timing required for every operation, so you’d get much better precision.
I’d love to try to design something, if you’d like. It sounds like an interesting project.
> whivch is exactly the sort of thing that doesn’t scale well up to a hundred-unit deployment.
You’re wrong.
A 100 unit deployment is easily hand-buildable. You’ll need an order of magnitude more (maybe 2 orders of magnitude) before you can justifiably make the claim.
Certain of the SkyTraq modules have a “sync to UTC second” option that will insure the start bit of the first character in the NMEA stream. I’m not sure about the one from Sparkfun but their GLONASS/GPS module implements this feature and has a standard USB to serial chip (silicon labs). They have an off-the-shelf EVK board which was $100 a year ago. The module name is S4554GNS-LP-EVK It includes a reasonable magnetic mount antenna but I use the one from sparkfun as it is more sensitive but probably not necessary. I don’t know if they have them in quantity or if there is a quantity discount.
If a zero-jitter UART startbit is adequate, perhaps these can be used. There is no enclosure, but the hardware is “off the shelf”.
http://www.skytraq.com.tw/contact/contact.html
The SkyTraq Venus628 apparently will sync to the UTC second IF that mode is set AND IF the update rate is 1Hz, so that might be a cheaper alternative, though the EVKs are the same price as the GLONASS modules from SkyTraq. The Sparkfun module would need something like the FTDI 3.3v TTL (arduino pro) adapter and a few wires run or the board layouts merged – the FTDI has a built-in 3.3v regulator which provides 50mA, and the 628 in low power acquisition uses 50mA. And an antenna. You can get immediately three off the shelf parts plus 4 jumper wires, then add some kind of enclosure, do some setup and be up in a few minutes.
It is also possible that other chipsets – I would almost bet Garmin – do sync to UTC or have it as an option.
Two other things haven’t been clarified.
1. Cost. $50? $200? More? Less?
2. Do you really need true and separate PPS or would a “start-bit edge at UTC” suffice?
If you can deal with start-bits…
I don’t know of a consumer GPS that uses the SkyTraq chipsets, but google shows http://www.xaiox.com/skytraq.htm which is bluetooth but they may also go out USB. Most do.
http://www.beboxx.com/coen/usb-gps-dongle-with-car-adapter.html?currency=USD&track=feedgCrS – at $40 it might pay to get one, if it is SkyTraq it should be configurable to enable the sync to UTC.
If the Garmin, MTK or uBlox based GPS “mice” happen to sync, you could just use those “off the shelf”.
You need to open them up or otherwise be able to see the serial stream to see where it is in relation to the PPS. Any PPS will do as they should all sync, but if you have a number of different chipset GPS mice it may pay to test them to see which ones do what.
>1. Cost. $50? $200? More? Less?
It has to be low enough that more than a hundred volunteers will be willing to buy a $99 router plus the GPS and install it. I think that means $99 more at absolute maximum. Realistically I think we have to come in under $75.
>2. Do you really need true and separate PPS or would a “start-bit edge at UTC” suffice?
We could probably live with the accuracy limit of a start-bit edge, but that kind of reporting stream has other implications that are a deal-killer. To work with GPSD a device has to emit data in a self-describing packet format (header, length, checksum, trailer) that the packet-sniffer can recognize and sort out from all the other sorts of packets that might come in over USB. Devices like the Phidget don’t do that.
Please no “Just drop GPSD” suggestions” in response to that objection. Writing a custom USB-port monitoring daemon is exactly the kind of time-consuming rathole we don’t want to go down, the software equivalent of all the well-meant but fundamentally wrongheaded suggestions that we should assemble a hundred custom devices from parts.
Think whole-systems engineering at scale, people – we need a solution with low complexity and downstream-maintainance overhead, not fiddly assemblies of custom hardware and software parts. Off-the-shelf hardware and software as well-tested and bulletproof as GPSD might get us there; getting diverted into clever hand-building will not.
@tz:
Three things about FTDI:
1) They actually make cables where the guts are in the USB connector. Several companies (including Sparkfun) sell these.
2) The FTDI chips will send status change information (e.g. DSR or DCD changing) on the next poll from the host, so if you use one of those signals for the 1PPS, it’s probably as good as you get with USB (the rest is all software, and the Linux FTDI driver is open source).
3) Although they cost a bit more, you might want to use one of the high speed FTDI chips (e.g. FT232H) because the host can poll more often and the latency will be reduced.
I actually thought about using the Garmin 18x LVC with one of the cables, but Garmin seems to be doing some sort of pseudo-RS232 level signalling, so you’d probably need couple of inverters between them at a minimum. But maybe one of the other available modules would work.
I forgot that the FT232R has programmable pin polarities.
Latency wouldn’t be as good as a faster part, but you should still be able to have it down in the sub 3ms range.
So you could take an FTDI cable (TTL-232R-5V-WE) and connect it to the Garmin 18x LVC. Just need basic soldering skills and not to be color-blind.
The Garmin pulls a bit more than the cable is rated for (75mA vs 90mA) but that’s just to meet USB spec at power-up — the assembly would violate USB by pulling more than 100 mA at the start, but 99% of the computers out there won’t care.
Total cost: < $85 + 20 minutes of entry-level soldering skills.
> That means we’d have to find cases for them and assemble cased units,
Here is what you need in addition to the boards and cables:
1. A bunch of little plastic boxes from the grocery store
2. Several hot glue guns
3. A few utility knifes
4. A few cases of beer
5. Quite a few pizzas
6. A group of fun, moderately competent people
7. One basement.
Mix these together and you should get your 100 finished units, in one evening of frolicking fun. If I lived closer (and if you bought vegetarian pizza), I’d be down in the basement joining the party.
Or to put it another way, 100 units isn’t really all that many.
>Or to put it another way, 100 units isn’t really all that many.
You’re still not thinking this through. What happens when we start getting bug reports from the field about the devices? What happens if the CDDB is wildly successful and we have more than a hundred volunteers clamoring to install monitoring nodes? How many assembly parties would we have to hold? What about the shipping costs to get all these units deployed?
We need a recipe for a CDDB node that doesn’t require hardware assembly and can be replicated cheaply by anyone willing to plug together off-the-shelf hardware they can order off the net. I’ve suggested designing a Z050-equivalent only because if we can do that once and then off-load the manufacturing onto a Taiwanese job-shop it will become off-the-shelf hardware.
We can’t afford to be diverted from the actual mission – which is operating the CDDB and performing data analysis – into the kind of complications that come with hand-built hardware.
@Jessica Boxer: I wouldn’t want to be the guy with the job of testing 100 units put together at a frolicking fun pizza party. Hand-building electronics takes more attention than partygoers are willing to give. Those workers at Foxconn aren’t having much fun, and for good reason.
@sigvald
In coaxial cabels the speed of light is 200 million meters per second. That is only 200 meter per microsecond.
However, in the situation we have here the return time would be dominated by repeater delays. Effectively, you would be counting hops. With à lot of statstics you would determine the timing characteristics of the paths to the last router. From then on you try to do statistics on the timing of the last arm.
You might try running this product idea past B&B Electronics. Having millisecond-accurate timing over distance is a general need that may appeal to industrial control system users.
Which is why I suggested seeedstudio or dangerousprototypes. seeedstudio will do all that stuff for you (and even pay royalties if you want them). Between them, those guys are set up for lots of different business models, and will probably be more than happy to handle the engineering.
But don’t discount the engineering. If you start with integrated circuits rather than pre-built modules, 100 units is barely enough at the kind of price point you’re talking about to take the risk of building a prototype and then selling units. But that’s dangerousprototype’s business, so you should certainly talk to them:
http://dangerousprototypes.com/about
@Jamie Fenton:
> You might try running this product idea past B&B Electronics.
Sure, but the nice thing about dangerousprototypes is that everything is open source.
@esr
>We need a recipe for a CDDB node that doesn’t require hardware assembly and can be replicated cheaply by anyone willing to plug together off-the-shelf hardware they can order off the net.
I get that. Which is why I think an existing unit is a better plan. There was no soldering iron on my party plan list, just gluing existing, pretested electronics into a plastic box. So here is what I was responding to:
> > You can buy any number of Motorola Oncore UT+ receivers for under $20 each on eBay.
> These all seem to be uncased boards.
Uncased doesn’t matter if it doesn’t need to look pretty, I guess was my point. Tell your users to buy this device and tell them to glue it onto anti static foam in the bottom of a plastic box. Really that pretty much seems to be all you need here. A five minute youtube video and a short BoM seem to be all you need here.
Custom hardware is a huge undertaking, and a royal pain in the ass, in my experience, especially all these persnickety radio thingies. More to the point using a job shop and sell them as a finished product has a million legal traps just waiting for you. If you do, then you are going to have to think about getting FCC part 15 RF Certs and equivalents for every other country they go to. This is not only difficult and time consuming, it is also extremely expensive. From memory you don’t absolutely have to do it in the US (though you open liability if you don’t) but you do have to have the equivalent in Europe to even ship it there.
@Jessica Boxer:
And RoHS and WEEE. In the EU you have to have provisions to recycle stuff you build…
http://ec.europa.eu/environment/waste/weee/index_en.htm
Not only the EU. California has similar requirements.
Eric is making a HUGE mistake by insisting on a “$99 router” (so he can make gpsd part of the solution).
What is needed here (*) is a box that can plug into Ethernet and run NTP, not a box that can run gpsd. The goal was to build a parallel NTP infrastructure, right?
(* if, indeed, it is needed at all. I don’t hear Jim Gettys (who knows more about bufferbloat than anyone) or Dave Mills (who knows more about NTP than anyone) worrying about the effects of bufferbloat on NTP.
>Eric is making a HUGE mistake by insisting on a “$99 router” (so he can make gpsd part of the solution).
Not my constraint. Dave Täht chose the WND3700 router for its low cost and wide availability, and then recruited me specifically because he thought GPSD was the likeliest time source to connect to it. After brief but fruitless detours into radio clocks (scuppered by poor signal availability) and GPS-conditioned high-precision oscillators (waaaay too expensive), we’ve come back to the original design.
>I don’t hear Jim Gettys (who knows more about bufferbloat than anyone) […] worrying about the effects of bufferbloat on NTP.
Then you’re not paying attention, haterboy. Or maybe it’s just hard to hear anything through that 60-cycle hum.
ESR: To work with GPSD a device has to emit data in a self-describing packet format (header, length, checksum, trailer) that the packet-sniffer can recognize and sort out from all the other sorts of packets that might come in over USB. Devices like the Phidget don’t do that.
The Phidget emits straight NMEA – if it is a Venus624 as pictured it probably has the sync mode. If GPSD cannot decode vanilla NMEA it has far greater problems. The 628 does have sync to PPS mode.
“All the other sorts of packets that might come in over USB” – this is a router and likely has only one USB port, or if two the other is likely to be for storage. It will appear as a vanilla serial COM port. And the “other sorts of packets” will all be NMEA sentences.
In the Sync mode, the start bit of the “$” of the first sentence is at the PPS. You don’t even really have to packet sniff more than the “$” at higher baud rates, only wait for a .5 second gap as all the sentences will complete in 300mS, so the first $ after such a gap will be the one corresponding to the PPS. Or look for “$GPRMC,” but insure that the previous one indicated (current one indicates?) a lock (with an A instead of a V).
For an OpenHardware solution to work, you either need some assembly yourself, or allow for double the cost. You won’t get them under $100 in 100-300 quantity. The tooling charges for the cases would likely be more. Quantity 10,000 makes prices drop in range, but at 100, even the components (GPS chip, antenna, USB to serial, aux chip) are already around $65 and that is without a board, assembly, or packaging.
>The Phidget emits straight NMEA
Really? That doesn’t fit the previous description, but if so, great. GPSD can handle NMEA just fine.
/me checks.
It it the 1040 you’re talking about? I just read the product manual, and it claims 300ns accuracy but says nothing about the sync-bit feature. Where is that documented?
Just noticed the FTDI part is available on a nice board without a cable attached, suitable for cable attachment:
http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_USB_RS232_PCB.pdf
It would be trivial to solder the Garmin 18x OEM LVC wires to such a board. and heat-shrink the wire to the USB connector/board. Wouldn’t look half bad when finished, and you wouldn’t have an odd bump in the middle of the cable.
You can buy 1 of these for $18 at mouser, or 100 for $15.30 each. You could build 5 units at a time for around $400, and you’ll get something with a 15 foot cable and nice plastics on the part near (or outside) the window.
Honestly, this is the way I would do it. Every hacker has a friend with a soldering iron and a heat gun, right?
>It would be trivial to solder the Garmin 18x OEM LVC wires to such a board. and heat-shrink the wire to the USB connector/board. Wouldn’t look half bad when finished, and you wouldn’t have an odd bump in the middle of the cable.
How would you enclose it?
>Every hacker has a friend with a soldering iron and a heat gun, right?
Probably. Can’t think of any friends who’d take on making a hundred of these, though.
@esr:
> How would you enclose it?
Just to make sure we’re on the same page, the garmin comes in a nice enclosure, so you’re talking about the end that plugs into the computer, right?
That’s what the heat-shrink is for. You’d probably use some smallish stuff on the wire, then some bigger stuff on the whole connector end assembly. Hard to describe. But here’s a picture. Imagine that, instead of the light, there’s a cable coming out, with a little bit more heatshrink around the first half-inch or so of cable.
http://www.instructables.com/id/Heat-Shrink-USB-Mod/
Alternatively, I believe the FTDI board would fit fine inside this enclosure. Might need to glue it down because it wasn’t designed for it, but it’s no big deal, and would give you a professional look for another buck-fifty.
> Probably. Can’t think of any friends who’d take on making a hundred of these, though.
The making’s not the real problem. As somebody else mentioned, you could have a party. Three people could drink a lot of beer and get 100 of these together in a couple of hours, with only one guy soldering. One guy going slow could probably still do over 10 an hour.
The problem is more logistics, accounting, etc. If I built these things and then sold one to someone in my state, I have to collect sales tax. If I have one break, then I have to worry about warranty. Sure, garmin will replace it, but there is shipping cost, etc.
To the extent I want to donate and make the world a better place, I’m happy to build one or two as a proof of concept. I’m even happy to solder a few dozen together every now and again if somebody wants it. But I’m not interested in making a business out of it, taking care of inventory, being responsible for refunds, etc.
In addition to seeedstudio, you might check out sparkfun. They’re domestic, and ship all over the world, and are happy to do new designs:
http://www.sparkfun.com/tutorials/315
Since they already have GPS modules, and already have designs with the FTDI, why not point them at this blog post?
>The problem is more logistics, accounting, etc. If I built these things and then sold one to someone in my state, I have to collect sales tax. If I have one break, then I have to worry about warranty. Sure, garmin will replace it, but there is shipping cost, etc.
I know. This is why I keep saying I want off-the-shelf hardware. not a hand-build.
>In addition to seeedstudio, you might check out sparkfun.
How is Sparkfun going to help? Looks like they’re all about parts and subassemblies, not finished products in a case.
> I know. This is why I keep saying I want off-the-shelf hardware. not a hand-build.
Yeah, but you also say you have a target maybe around $75 and a number of units maybe around 100. If we assume that the $35 going price of a USB mouse is about right, then there’s $4000 “extra” for somebody willing to do all the engineering, stocking, warranty, etc. That’s not enough to warrant starting a business, but it might be enough for somebody already in the business…
> How is Sparkfun going to help? Looks like they’re all about parts and subassemblies, not finished products in a case.
You’d be surprised what kind of stuff sparkfun will put in a case. If it’s weird enough and appeals enough to their geekly audience, why not?
Perhaps a business might be more interested in producing a device that has both the “router” and GPS in a single box. This would allow them to claim the entire $175 per system deployed, making it easier to amortize the costs of design.
Putting a computer into the thing would be beyond an amateur with a soldering iron, but you are already discounting such people. For serious prototyping firms, “embedded Linux computer such as in a router” is likely a macro in their circuit design software.
You’d also get the best latency possible, as the PPS could be given a dedicated interrupt line.
The device would sell outside your own projects, as it would at once be both a “router with good time” and a “standalone Stratum 1 server with an extra Ethernet port”.
@Patrick Maupin
> And RoHS and WEEE. In the EU you have to have provisions to recycle stuff you build…
I think the job shop should be able to handle RoHS, after all this isn’t the space shuttle we are talking about here. And I suppose WEEE can be handled with a notice saying “When you are done mail it back to Eric’s house. But I’m not an expert.
For sure a pre built part that users can order and put in a box avoids the whole bureaucratic nightmare that is consumer product engineering, especially in low quantities where the NRE per unit is gigantic.
@Jessica Boxer:
> I think the job shop should be able to handle RoHS, after all this isn’t the space shuttle we are talking about here
Technically, you’re right. Legally, the paperwork might actually be worse. You have to track everything, and there is even a provision for liability for people who aren’t the principal offender. There’s apparently a potential for up to 3 years jail time, and we know that doesn’t happen for the space shuttle even when people die (but espionage is another issue).
According to this:
http://www.goodbyechain.com/pdf/weeerohsfines.pdf
in Greece, if the relevant violations weren’t intentional, you only face up to 1 year of jail time. What a relief!
@Michael Deutschmann:
Yes, I think that’s an excellent product idea. But I also think that if someone built it, they might be able to maximize revenue by selling it for a lot more than $175, given that GPS time servers without routers go for more than that.
http://www.amazon.com/TM1000A-GPS-Network-Time-Server/dp/B002RC3Q4Q/ref=pd_sim_sbs_e_1
OTOH, if you had the balls to build a few thousand routers with GPS built-in, you could probably create a new product category and make a lot of money at a price-point under $200. Especially if it had WiFi and ran Linux and one or more of the Linux router distros.
@Michael Deutschmann:
That product idea (replace a Cisco SOHO-type router, with as much functionality as you can) might actually be worthy of a kickstarter project. Especially if it had a quadband cellular modem for backup.
>That product idea (replace a Cisco SOHO-type router, with as much functionality as you can) might actually be worthy of a kickstarter project. Especially if it had a quadband cellular modem for backup.
I agree. However, not this time. We all know what tends to happen to engineering projects that develop mission creep…
>>Every hacker has a friend with a soldering iron and a heat gun, right?
>Probably. Can’t think of any friends who’d take on making a hundred of these, though.
Bah! If you (or somebody else) is willing to come by and be entertaining for a while, I can crank these out. It’d even give me a reason to buy a new soldering station I’ve been looking at for a while.
100 units isn’t that big of a deal – maybe a solid afternoon.
>100 units isn’t that big of a deal – maybe a solid afternoon.
Much appreciated, Garrett. If I can’t find any other way than hand-building these, you’ll get a call.
> Not my constraint. Dave Täht chose the WND3700 router
Yeah, so he can run Cerowrt. Next question? Oh wait, right. It’s still a stupid idea.
Dave got his butt handed to him on the ntp list when he proposed this last year.
Reason: in steady state, ntp sends a smallish packet every 1024 seconds, and has a built-in mechanism to throw away packets with excessive delay. What are the chances he’s going to see an event?
If you want to work on bufferbloat, why not fix Linux, which will open-up the receive window beyond the needs of the bandwidth delay product? And if the other side is also Linux, it will have taken advantage of this.
(Linux will allow the socket buffers/windows grow to 4MB by default. And doesn’t implement TCP Vegas.)
See: http://www.bufferbloat.net/projects/bloat/wiki/Linux_Tips
Or just gaze at your navel whilst running experiment 1d:
http://gettys.wordpress.com/2010/11/29/home-router-puzzle-piece-one-fun-with-your-switch/
>Reason: in steady state, ntp sends a smallish packet every 1024 seconds, and has a built-in mechanism to throw away packets with excessive delay. What are the chances he’s going to see an event?
And that’s exactly why Dave’s monitoring software will use rawstats – the unfiltered propagation data.
>If you want to work on bufferbloat, why not fix Linux
If you had been paying attention upthread, you would know that Dave already did this.
If you don’t have to run the the WND3700 router, you could use a Raspberry Pi. Cases will be available by Summer.
I wonder if these are the same problem that creator of ColorHug had…
@esr
> We all know what tends to happen to engineering projects that develop mission creep…
Perhaps it could have a feature that, if it kicks over the the cellular modem, that it sends you an email?
:-)
@esr
> We all know what tends to happen to engineering projects that develop mission creep…
Shoot, I got that wrong. What I MEANT to say was: perhaps it could add a feature to allow it to be configured simply by sending it an email, adding a module to read a POP3 box.
But it isn’t funny if you screw it up. Ah well, back to the drawing board.
Here’s a USB mouse with its own vegetable patch:
http://computerdevices.org/computer-hardware/custom-usb-sejat-sj-5210-usb-mouse-gps-receiver-w-sirf-star-iii/
@esr: Hey, what about the Gumstix GPSstix boards? They’re a bit expensive ($130 for the board + $169 for the Verdex Pro board you need to go with it), but after a quick glance around the related sites, they are based on the NEO 5Q GPS receiver which I think has the 1PPS line. The plus side is you can build the NTP server right into the device which runs an embedded Linux.
>[Gumstix] are based on the NEO 5Q GPS receiver which I think has the 1PPS line.
Proves nothing. All GPS chipsets have 1PPS on an output pin. The board-level integrator chooses whether to make that accessible. Googling on “Gumstix 1PPS” suggests they have not.
I agree Maupin’s extension of my idea would be a distraction full of mission creep. Probably the only creep that might be reasonable is bringing out any spare GPIO pins the CPU may have, alongside a replica of the PPS signal, into some sort of spare “geek port” on the box.
But my original idea: a box with just GPS, reprogrammable computer, two Ethernet ports and whatever else ESR and Dave need – is still reasonable. Those components alone are enough to make the thing useful to at least some people outside the project, a few of whom are currently paying an order of magnitude more for inferior solutions.
Also, have you tried negotiating with ZTI (or any other supplier of “good” USB GPS) for a better unit price considering you will commit to buying 100 of them?
>Also, have you tried negotiating with ZTI (or any other supplier of “good” USB GPS) for a better unit price considering you will commit to buying 100 of them?
One of our European devs is chasing a quantity-100 quote from ZTI.
> If you had been paying attention upthread, you would know that Dave already did this.
Dave did what, exactly?
> Proves nothing. All GPS chipsets have 1PPS on an output pin. The board-level integrator chooses whether to make that accessible. Googling on “Gumstix 1PPS” suggests they have not.
Looking at the top link generated by asking Google for “Gunstix 1PPS” shows:
“The 1pps from the ublox gps on the gpsstix board maps to gpio9.”
(and in-fact many links contain the same phrase)
>Dave did what, exactly?
Shepherded some Linux changes that will radically reduce TCP/IP packet latency.
>“The 1pps from the ublox gps on the gpsstix board maps to gpio9.”
Useless for anything but LEDs. In order for PPS to be visible for time service it needs to be carried to the serial-to-USB adaptor. This is what, in general, GPS vendors fail to do.
Since you’re not rational, be sure to point Dave to
http://www.leapsecond.com/pages/MG1613S/
or
http://www.synergy-gps.com/images/stories/pdf/synpaq%20product%20data%20sheet%20040110.pdf
or even
http://www.febo.com/pages/soekris/
(The clock stretcher isn’t required with an M12M or M12+T as its PPS pulse width is 200ms.)
To be perfectly clear, I don’t think your approach of “cheap USB GPS receiver” doing 1PPS is going to be all that accurate. Read the links above for ‘why’.
As for your 60Hz hum nonsense:
http://www.LeapSecond.com/pages/mains/
> Useless for anything but LEDs. In order for PPS to be visible for time service it needs to be carried to the serial-to-USB adaptor.
LOL
You do know you can take an interrupt of the GPIO signals, right?
Seriously, Eric. What you *DON’T WANT* is the additional latency of the DCD (or DTR, or whatever) line going high, **AND** the latency of the USB protocol moving your 1PPS signal way over to the right.
>You do know you can take an interrupt of the GPIO signals, right?
If I’m willing to do custom hardware that wires the board to a gpio pin on the router, yes. For reasons I have patiently explained several times, this is not a feasible option.
> Shepherded some Linux changes that will radically reduce TCP/IP packet latency.
Not in the mainline kernel, (so far, they’re cerowt only!)
which was my request.
>Not in the mainline kernel, (so far, they’re cerowt only!)
Wrong.
http://esr.ibiblio.org/?p=4162&cpage=1#comment-373354
> You do know you can take an interrupt of the GPIO signals, right?
Further on this, ARM (and ARM linux) supports a ‘fast irq’, which means the kernel can get to it quite a bit faster, and thus keep a (vastly) superior reference clock updated and chiming in-sync.
> Wrong
Let’s quote the first line together, ready?
A note: “I” did NOT get the new stuff related to bufferbloat pushed up into the upcoming Linux 3.3 kernel.
(emphasis mine)
Go back and read his comment again,. And the followup.
And consider yourself under a ban warning. Your trolling and your vicious, petty, carping attitude is wasting my time. You will be more polite in the future, or I will kick your ass off this blog.
> If I’m willing to do custom hardware that wires the board to a gpio pin on the router, yes. For reasons I have patiently explained several times, this is not a feasible option.
You’re either dense, or being silly.
The GPSstix, when attached to the proper gumstix board, the 1PPS signal on the GPStix is already connected to gpio9 on the gumstix. Through the 60-pin connector.
“No wires needed”, it’s snap-together, like LEGO. Cases are even available.
>The GPSstix, when attached to the proper gumstix board, the 1PPS signal on the GPStix is already connected to gpio9 on the gumstix. Through the 60-pin connector.
That’s useless unless we’re ready to abandon the WND3700 and port a routing distribution to the gumstix, which is presently out of scope as a solution. If I can’t see 1PPS on USB, the WNDR3700 can’t use it.
>You’re either dense, or being silly.
That is the last remark of that kind you are allowed before being banned. If you had a history of constructive behavior I would allow you great freedom to insult me (though much less to insult any one else). You don’t, so you have to earn that liberty one polite and thoughtful comment at a time.
@Larry Yelnick:
This is a concern. Which is why I think, if USB is required, it would probably be much better to use a high speed device. Additional variable latency can be reduced to 125 us, maybe lower depending on USB scheduling. You could probably send 3 interrupt packets/microframe to the GPS (if that was your main focus) to get it down to 42 us.
Obviously, you don’t really care about fixed latency, as long as you have an idea of how long it is.
But the gumstix looks considerably more expensive than the garmin, which is itself quite expensive. Given that all the other USB mouse vendors seem to mimic the Garmin, it’s surprising that none of them have an analogue to the 18x OEM LVC.
Or maybe they do. I’m curious if the typical cable with attached mini-DIN has any wires that don’t actually connect to the mini-DIN, or that connect to one of the pins marked unused on some versions of the mini-DIN.
In any case, the 18X OEM LVC (perhaps unlike the 18 OEM LVC it replaced) apparently doesn’t actually terminate in bare wires. It has a connector. According to Garmin, you can cut off the connector without voiding the warranty, because a lot of people aren’t going to use the connector, but it is there, and they tell you the mating connector, and you can use it. The connector is not designed for extreme use, so you’d want to put it on a board inside an enclosure with a strain relief on the cable.
Assuming the existence of the connector on the 18x, it would be trivial to create a small design (either USB or 9 pin serial, whichever seems most appropriate) that could be used in conjunction with the Garmin with no soldering on the part of the end-user. This design would be cheap enough to build a lot and stock, and, in the case of USB, actually a little bit more general purpose than just a serial connector for a GPS mouse.
>Additional variable latency can be reduced to 125 us, maybe lower depending on USB scheduling.
Yes, this is one of the optimization possibilities I’ve been keeping in my pocket – it should be possible to jack the USB polling rate up to 8MHz.
>I’m curious if the typical cable with attached mini-DIN has any wires that don’t actually connect to the mini-DIN, or that connect to one of the pins marked unused on some versions of the mini-DIN.
The BR355 has this exact problem. There’s an unconnected yellow pin 3 in the pinout at http://www.usglobalsat.com/p-57-br-355-gps.aspx#images/product/large/57.jpg and there’s some reason to believe that this brought out 1PPS on older versions of the hardware.
>In any case, the 18X OEM LVC (perhaps unlike the 18 OEM LVC it replaced) apparently doesn’t actually terminate in bare wires.
I wondered what the X suffix meant. I think you may have explained it.
>Assuming the existence of the connector on the 18x, it would be trivial to create a small design (either USB or 9 pin serial, whichever seems most appropriate) that could be used in conjunction with the Garmin with no soldering on the part of the end-user. This design would be cheap enough to build a lot and stock, and, in the case of USB, actually a little bit more general purpose than just a serial connector for a GPS mouse.
I looked at the 18x technical spec at http://www8.garmin.com/manuals/GPS18x_TechnicalSpecifications.pdf and it is very clear they bring PPS out on pin 1 (yellow). It also says “The factory-installed connector will mate with JST right-angle PCB-mount connector (model BM06B-SRSS-TBT) or side-entry PCB-mount connector (model SM06B-SRSS-TB).” And that connector looks real familiar.
So, yes, I think you’re right. Mating a male JST connector to a PL2303 or some other bog-standard serial-to-USB converter and protecting that with shrink-wrap might very well do the trick. This is probably the most feasible custom-build suggestion anyone has made yet.
@ESR – Talking about a 1 microsecond clock is nice and all. But how will you marry this accurate clock to the packets that you’re trying to timestamp? OK, so you build your GPS 1PPS interrupt circuit but then exactly how are you going to get your OS to respond at 1 microsecond accuracy? There is so much “stuff” between the packet physically hitting the interface and the OS network stack and the application that hooks up to your 1PPS clock that I think it extremely unlikely that your time stamps are going to be anywhere near 1 microsecond accuracy. I say this based upon my experience in developing low latency networks which I have examined in lab conditions prior to deployment of products in the low latency financial trading world </Appeal to Authority). To come to grips with 1 microsecond network analysis you need to look at products from Corvil and TS Associates and others. Those chaps sell products that do the kind of analysis that the bufferbloat projects seems to be wanting to perform. To do the job at 1 microsecond and down into the nanosecond territory you need to have PTP (which is far more accurate than NTP). And then you need highly optimised software that is dedicated to the analysis. Both Corvil and TS make appliances that analyse traffic using either span ports but usually and more accurately using network taps. TS Associates even makes a PCI-X card that goes with their appliance. The card allows insertion of special "time stamp" calls into your production code on your production application servers and thus allows analysis of both network component timing and also application and OS software timing. This stuff is expensive and complex. I think throwing a GPS 1PPS time stamp at your WND3700 is fine except that you need to come to grips with all of the other "stuff" that's going on inside the WND3700 before you could ever expect to get analysis working at 1 microsecond. If WND3700 is to do what bufferbloat seems to be asking, then WND3700 would have to be dedicated to the job of analyzing "passing" traffic and would not be doing any firewalling, NATing, AAA, connection table populating, or pretty much anything else. If WND3700 is required to support all of the standard WND3700 network capabilities and functions then those processes are going to turn your 1 microsecond target into a bad joke. Unless I am somehow missing the point.
@esr:
I think you mean kHz…
BTW, the variable latency introduced by the USB is exacerbated and made hard to calibrate out because the 1 second PPS occurs in an even number of USB frames. So the clock drift of the computer’s (router’s) internal USB frame counter vs. UTC time will cause the latency to gradually change over a long period of time, and then snap back.
The effect of this will be perceived as a one frame (or perhaps one microframe on highspeed) slip every ‘n’ seconds, where ‘n’ depends on how far off the computer’s clock is. The closer the clock is to being correct, the less often the slip happens, and the worse it looks. For example, a clock that’s only off 1 ppm would gain or lose one second every 1M seconds, or gain or lose one
frame every 1000 seconds, which might interfere with your analysis.
One way to compensate for this would be to have an external CPLD or FPGA running a local clock and interpolating time samples before feeding to the USB. So, for example, if you interpolated 30 samples between the PPS, the 1K frame rate or 8K microframe rate is not divisible by 31 (one per second plus 30 in between), so you could force jitter associated with the clock drift to happen much faster. Essentially, this approach would let you calibrate your internal system’s RTC much more quickly for the same level of accuracy.
You could easily play tricks to distinguish the 1 pps pulse from the others. For example, the 1pps pulse could be on DSR, and the others could be on DCD or CTS.
>For example, a clock that’s only off 1 ppm would gain or lose one second every 1M seconds, or gain or lose one frame every 1000 seconds, which might interfere with your analysis.
I don’t understand the failure mode you’re trying to describe. Let me lay out how I think the clock will be conditioned in each second, then you can explain how you think this drift will affect it.
1. PPS interrupt comes in. We record it as ppstime = clock_gettime(CLOCK_REALTIME). ppstime is actual top of second plus an unknown latency which does not exceed 50 microseconds.
2. UTC time arrives as data over USB; we record this as utctime. Time of arrival is recorded as timetime = clock_gettime(CLOCK_REALTIME)
3. timetime-ppstime is the imputed latency of the time report with respect to PPS top of second, and will always be less than a second. We call adjtime(3) to slew the clock towards utc-time + (timetime – ppstime).
@patrioticduo:
Unless I misunderstood, the goal of using GPS was to keep the router’s RTC accurate within 1ms. I think this goal is eminently achievable.
@ Patrick Maupin – ah yes, you’re right. So I would suggest using RDTSC and rewrite PTP to dumb it down for WAN devices to achieve somewhere between 1mS and 100uS accuracy. But even at 1mS accuracy, it can be very challenging to get any OS to receive frames and time stamp them accurately when there is so much stuff in between the PHY and the clock. Getting into the PHY device driver is a specialized area. Does the WND3700 publish the source for the NIC device driver? Are the NIC’s sharing an interrupt (bad) or using an interrupt per NIC (good)? Are the NIC’s running on special ASIC’s with the CPU sitting on top? If yes, then those ASIC’s probably have built in queuing which is going to make it virtually impossible to time stamp traffic within the OS. These low cost home routers often use a four port switch ASIC with the OS sitting on top to handle all of the stuff from layer 4 to layer 7. The RDTSC is standard in all Intel CPU’s from the Pentium up http://www.ccsl.carleton.ca/~jamuir/rdtscpm1.pdf and I have found it to be most useful for time stamping network traffic in my own endeavors at 100Mbps rates. So for 1mS accuracy RDTSC would be my choice along with code similar to PTP but dumbed down to 1mS. http://www.endruntechnologies.com/pdf/PTP-1588.pdf . NTP just isn’t good enough anymore but PTP is intended for LAN’s. So there is a sweet spot to be found for WAN synchronization that would sit right somewhere in the 1mS to 100uS range.
@patrioticduo:
Sure, but routers don’t use those. I don’t know about the uncertainty inherent in the router software and hardware, but I take it on faith that those who are using the equipment to their own satisfaction do.
@esr:
If you are certain that in your setup the variable latency is below 50 us, then the issue I described is probably not a problem.
What I was considering was a USB scenario with one interrupt per 1 ms frame. I guess you are scheduling more than one interrupt per frame if your latency is 50 us.
>If you are certain that in your setup the variable latency is below 50 us, then the issue I described is probably not a problem.
Dave Täht forwarded me measurements from a guy who has real-time-profiled PPS over USB under Windows. That’s what the measurements say.
I would think we would want to build using whatever serial -> USB converter part this guy used. I’m sure they aren’t all created equal…
>I would think we would want to build using whatever serial -> USB converter part this guy used. I’m sure they aren’t all created equal…
Good point.
That Sure electronics board mentioned by Beat Bolli definitely looks interesting. I wonder if you could convince them to update it? They only want $32 for the thing.
It uses the SiLabs USB -> serial converter, which may or may not be good enough from a latency standpoint.
Still, it has all the pieces your final solution would require except a case for the board, and comes in at an excellent price point.
Have you tried any GPS devices based on the u-blox chips? The modules themselves have USB out. Maybe it jitters less than the SiRF-based devices?
You can get a very simple test board with the u-blox device on it (full kit, connects via USB or RS232) from Mouser for sixty bucks.
Alternatively, it might be useful to contact them directly. They should know who you are — they describe using gpsd to connect to the device. They might be able to tell you about the latency in receiving messages over USB, and might be happy to send Dave a board to test with himself. Finally, I would expect their English to be pretty good — they’re in Switzerland…
http://www.u-blox.ch/en/gps-modules/pvt-modules/lea-6-family.html
Several other companies also seem to sell modules based on their chips (Antenova for one).
>You can get a very simple test board with the u-blox device on it (full kit, connects via USB or RS232) from Mouser for sixty bucks.
Link?
>Alternatively, it might be useful to contact them directly.
I’ll try it, but I need to know what board I’m talking about first.
The board I found at mouser is different (and cheaper — made by a third-party) than the one direct from u-blox:
http://www.mikroe.com/eng/products/view/122/smartgps-board/
That board’s manufacturer also makes a nice little board (but with PPS only going to an LED — blue wire required if we need it):
http://www.mikroe.com/eng/products/view/123/gps-click/
The chip/module manufacturer has a more expensive evaluation board:
http://www.abacuscity.ch/abashop?s=142&p=productdetail&sku=113
If the USB out has sufficiently low jitter, you could probably use any mouse with this module. Otherwise, the module (or a small board like the gps-click for $50) might be the basis of a system we build with a lower latency USB interface (assuming we figure out the best USB chip for that).
Actually, I was wrong about needing a bluewire on the click — the schematic wasn’t drawn very well, but it appears that the 1pps also goes to the connector.
So, if the jitter on the u-blox part is low enough through USB, just find the right mouse using the right part and we’re done. If it’s not low enough, this looks like a good module to put down on a little board with a better USB to serial converter we can attach the PPS signal to.
I take off for the weekend and this happens…
I am encouraged by many of the comments on this thread, but I do feel the need to correct a few things that have gone by…
‘CBBD’ = Cosmic Background Bufferbloat Detector. I don’t know what CDDB is. What I started off calling the idea is a reference to this:
http://en.wikipedia.org/wiki/Discovery_of_cosmic_microwave_background_radiation
I’m certainly open to a better name…
I did not ‘get my butt handed to me on the ntp list’, in the end nobody was able to poke enough holes in the idea to dissuade me from trying it, and as eric noted, the intent was to analyze the noise that ntp’s various filters currently discards (e.g – the rawstat data), to see if there were any recognisable patterns across a large enough data sample.
I have had plenty of feedback from time geeks pointing to anomalies detected even within gigE switched networks.
That’s on the client side. On the server side, I’d hoped to also break down incoming ntp data when it was natted or not.
However to get a good baseline and error bars, (measuring the
inherent drift of the router’s own clock as another example) I really wanted reference sources on and beyond the edge of the network that had a chimer we could trust, which is how the concept of using gps to cross check the data came to be, and became the rathole of trying to find a gps that actually did do PPS in this so-called modern era.
Lets see, other stuff – as esr also noted there are some really nice debloating enhancements for ethernet to the upcoming linux 3.3 kernel – which I helped shepard by testing them in cerowrt. I gave full credit to the actual developers on the previous thread.
Despite my own desire to do this on the router testbed, having trustable edge time sources using any technology, with known performance characteristics and error bars, is an overall goal, so that other sorts of test data – not just ntp, but file transfers and the like, can be more directly compared. Imagine if you will, if you had 100 routers deployed on the edges of the internet, doing tests between each other….
So, perhaps long term something useful will come out of the rawstat data with or without a more accurate reference clock, I look forward to collecting more data, and if there was a way to get some solid chimers out ‘beyond the edge’ of the internet, it would be darn helpful.
Perhaps I’ll get to a ‘proof of concept’ or a ‘disproof of concept’ in the next month or two.
>‘CBBD’ = Cosmic Background Bufferbloat Detector. I don’t know what CDDB
My typo, probably.
“This ain’t no Mud Club. No CeeBeeGeeBee’s. I ain’t got time for that now!”
@esr and Dave Taht:
One thing that has been bugging me.
If the router has a reasonably stable hardware RTC, why do you need a non-jittered connection to the GPS?
Why can’t you assume that the temperature and voltage are relatively stable and the RTC won’t change too much over the course of a minute or an hour? Within some time period, you can determine a straight line correction based on two recent data points that are (a) far enough apart to minimize quantization error and (b) “appear” to be earlier (compared to the internal RTC) than any other nearby points.
So, my strategy would be:
1) Develop a straight line correction factor from the RTC to UTC for the internal RTC based on the perceived earliest two of recent multiple GPS measurements.
2) When an NTP packet comes in, don’t attempt to directly correlate it to the most recent GPS measurement. Instead, correlate it to the internal RTC, using the linear correction factor.
A more sophisticated version of this could use some filtering to allow for some RTC stability drift and to get a bit more accuracy, but the key is to either throw out all the GPS measurements that have been jittered way late, or to take the opposite approach, and just average all the samples (knowing that will give you more reported latency).
Now, having said all that, I think this technique would work better the more samples you had in a recent time period, which is why I was suggesting using hardware to report more than one PPS.
But to the extent that the data reported from the GPS consists of fixed + variable latency and to the extent that the internal RTC is stable, do you really need the PPS signal? And to the extent the PPS signal would be useful and you have to transport it over jittery USB, wouldn’t it likewise be useful to have a faster signal?
Oh, and one last question:
Can you recommend this router? What firmware should I use? Anything to be wary of, like manufacturer ships two versions and this one doesn’t have enough flash? (I try to follow similar “ask slashdot” discussions, but am never happy with all the answers :-)
@tz: “What might be more interesting is to use the GPS 1PPS interrupt (and I have two with perfectly synced pps outputs on my scope right now) to send a packet (or packets) out so you could determine the exact latency between any two nodes with such devices. You could do so to a centralized location but the geodesic would be more interesting, sort of a real-time map of internet latency.”
Exactly. Being able to effectively measure the edge is something that hasn’t been done yet. The more nodes participating the better the edge can be mapped.
Various projects are trying – notably the samknows people and the bismark folk, ICSI, and CAIDA.
In my own case I’m rather interested in the ledbat (bittorrent) work particularly inside a given providers network, across provider networks, and in the presence or absence of various queue management technolgies.
There are/were a lot of people in the IETF that held high hopes for an effective E2E ‘scavenging’ protocol in ledbat. The irony is that ledbat (v9) at least, does scavenge in drop tail, non-aqm, non-shaped networks, but is only marginally effective in RED managed ones. The newer AQM technologies we’re fiddling with are unknowns in this regard, but seem very effective for managing other sorts of traffic, so seem to be a net win… but I’d really like to get a grip on what uTP and ledbat do in a debufferbloated universe sometime soon.
http://perso.telecom-paristech.fr/~drossi/index.php?n=Software.LEDBAT
Anyway, to get back to the ntp + gpsd issue, I’ve read through the backlog of postings here, and it appears that nothing of the shelf is going to work, and that a basement build party might be required…
and frankly I’d like to get to processing my backlog of data, and
maybe getting others to start collecting it, to see if any trends can
indeed be determined with or without a decent reference chimer.
Collecting rawstats is easy for a daily period. Merely add the
following lines to your /etc/ntp.conf
statsdir /tmp/ntpstats/ # or some other place you can save to
statistics loopstats peerstats clockstats rawstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
filegen rawstats file rawstats type day enable
@Patrick Maupin: I can recomend routers that use the chipset in the netgear wndr3700v2 and wndr3800 – there are something like 36+ products from various vendors that use that chipset (atheros ag71xx (wired chips) and ath9k (wireless)), all of which are supported by openwrt.
I can recomend the nanostation M5 for long distance links. I’ve heard some good things about the buffalo BZR-300 series.
So far as I know this chipset has the only 100% open source drivers chipset out there at present (although broadcom has been getting better of late), and even the native firmware is generally pretty good. (the buffalo router actually ships with dd-wrt, btw)
That leaves 30+ routers based on this chipset that I have not had a chance to play with directly, and to keep my life simple, the 3800 is the way the cerowrt project is going to stay for a while longer.
As to your RTC question – there is no RTC, battery backed up or otherwise, in most consumer routers. This leads to lovely chicken-egg problems with ntp and dnssec, as one example. As to evaluating the stability of the onboard crystal and OS’s timekeeping ability, the latter is dependent on the OS version somewhat, and the workload somewhat, the former dependent on environmental conditions and build quality – and in either case, how do you effectively measure that stuff without a reference time source?
I’d LOVE to get down to where we merely had known error bars.
>‘CBBD’ = Cosmic Background Bufferbloat Detector.
You don’t want to confuse this with the Blufferboat – it sails into international waters with high-stakes poker players aboard.
….OUCH!…OK,OK! I’ll stop!…..
@Dave Taht:
Understood. Really just need a solid timing source. For example, the USB chip has to output at 1KHz frame rate — is that available internally? (And BTW, the USB chip damn well better be pretty close to correct frequency or it just plain Won’t Work. USB spec is +/- 500 ppm.) So one would assume, if frame info can be read from USB, it will be pretty accurate. This can probably even be done by seeing where its DMA pointers are if it doesn’t have a special register for that.
BTW, I think I found the absolute easiest build for an uncased product that will connect the Mediatek GPS chip (if that works OK) to the high-speed FTDI chip (if that works OK) and connect 1PPS to a modem control signal:
http://www.fastraxgps.com/showfile.cfm?guid=af07f121-2c43-4317-bd5b-90eef430b505
http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_C232HD_UART_CABLE.pdf
You’d need to solder a 1×6 0.1″ header strip to the Fastrax and then plug the right connectors from the cable on to it.
Total cost for a single would be $57 plus the header plus the plastic case to put the Fastrax in and a cable-tie to provide some strain relief so the cat doesn’t destroy the Fastrax when it knocks it off the windowsill.
>Really just need a solid timing source. For example, the USB chip has to output at 1KHz frame rate — is that available internally?
Wouldn’t solve the problem. We don’t need just a reliable ticktock, we need a common timebase for all the detector nodes. That’s the real utility of GPS here, not the absolute precision.
Wasn’t CDDB a service that you could use to try to figure out the author, cd name and track name of your music cds based on track number and length?
@esr:
But you’re claiming that the problem with the available GPS mouses is latency. There are two kinds of latency — fixed latency can be measured and easily compensated for (for a given chip). Variable latency can be compensated for with a reliable ticktock. In other words, I am not questioning the decision to use GPS, but I am challenging the conclusion that 1 PPS must be available for it to be useful for your scenario.
For example, in this comment you describe a method of, essentially, measuring the most recent GPS tick against the most recent NTP packet.
But if you have a stable local clock with high enough resolution, if that’s all you’re doing, you’re throwing away most of the data that’s available to you, and it’s no wonder that jitter on incoming GPS data gives you fits. I’m suggesting you use lots of samples of GPS data to give you an equation that will convert whatever the local stable ticktock says into UTC. Then when the NTP packet comes in, you do the math and know how far out it is.
It’s certainly possible I’m missing something and this won’t work. But I haven’t seen it discussed in depth, and, in fact, your example of use says that the history of GPS samples isn’t being used.
>I am challenging the conclusion that 1 PPS must be available for it to be useful for your scenario.
I see. I’ll look into this.
CD Database. It’s what allows iTunes to automatically recognize your CD when you rip it, filling in a title, cover art and a tracklist. :)
I hooked up and configured one of my Venus 628s to just generate GPRMC, synced to UTC, 115200 Baud – the same family as the Phidget and the $30-$40 off the shelf devices.
With this the DTR line flips 2-3.5 mS after the PPS as visible on my scope. I didn’t try root nice -20. C would also be faster. The start bit of the $ is 1 millisecond after the pulse edge. I was doing an update in the background so the system wasn’t idle.
#!/usr/bin/python
import sys
import os
import time
import fcntl
import termios
import struct
if len(sys.argv) > 1 :
try:
ser = open( sys.argv[1], “rw”)
except:
print “Usage: dtrpps.py [/dev/serdev]”
exit(1)
else:
exit(1)
ios = fcntl.ioctl( ser.fileno(), termios.TIOCMGET, “\x00\x00\x00\x00” )
ios = struct.unpack(“i”, ios)
ios = ios[0]
ios = ios ^ termios.TIOCM_DTR
fcntl.ioctl(ser.fileno(), termios.TIOCMSET, struct.pack(“i”,ios))
while(1):
dat = ser.read(1)
if dat[0] != “$”:
continue
ios = ios ^ termios.TIOCM_DTR
fcntl.ioctl(ser.fileno(), termios.TIOCMSET, struct.pack(“i”,ios))
tabs to 4 spaces:
#!/usr/bin/python
import sys
import os
import time
import fcntl
import termios
import struct
if len(sys.argv) > 1 :
try:
ser = open( sys.argv[1], “rw”)
except:
print “Usage: devgpsrc.py [/dev/if/not/stdin]”
exit(1)
nodeid = sys.argv[1][-4]
ms = str(int(time.time()*1000%100000))
else:
ser = sys.stdin
nodeid = str(os.getpid())
ms = str(int(time.time()*1000%100000))
print ser, ser.fileno(), termios.TIOCMGET
ios = fcntl.ioctl( ser.fileno(), termios.TIOCMGET, “\x00\x00\x00\x00” )
ios = struct.unpack(“i”, ios)
ios = ios[0]
ios = ios ^ termios.TIOCM_DTR
fcntl.ioctl(ser.fileno(), termios.TIOCMSET, struct.pack(“i”,ios))
while(1):
dat = ser.read(1)
if dat[0] != “$”:
continue
print dat
ms = str(int(time.time()*1000%100000))
ios = ios ^ termios.TIOCM_DTR
fcntl.ioctl(ser.fileno(), termios.TIOCMSET, struct.pack(“i”,ios))
sigh. Try underscores for spaces
#!/usr/bin/python
import sys
import os
import time
import fcntl
import termios
import struct
if len(sys.argv) > 1 :
____try:
________ser = open( sys.argv[1], “rw”)
____except:
________print “Usage: dtrtest.py [/dev/serdev]”
________exit(1)
else:
____exit(1)
ios = fcntl.ioctl( ser.fileno(), termios.TIOCMGET, “\x00\x00\x00\x00” )
ios = struct.unpack(“i”, ios)
ios = ios[0]
ios = ios ^ termios.TIOCM_DTR
fcntl.ioctl(ser.fileno(), termios.TIOCMSET, struct.pack(“i”,ios))
while(1):
________dat = ser.read(1)
____if dat[0] != “$”:
________continue
____ios = ios ^ termios.TIOCM_DTR
____fcntl.ioctl(ser.fileno(), termios.TIOCMSET, struct.pack(“i”,ios))
@esr: A while back, I ran into the same problem as tz did when I tried to send some primitive ASCII graphics. Doesn’t WordPress have some setting that will preserve spaces? How many bytes does the damn thing think it is saving on the hard drive, anyway?
>Doesn’t WordPress have some setting that will preserve spaces?
I did this with <pre lang=”C”>
It works with most other major programming languages as well, preserving spaces and doing language-apprpriate syntax highlighting.
Thank you, thank you, thank you.GPSD alone with NO MODIFICATIONS (at least under Fedora 16 with all the updates) will sync using just the NMEA stream from a SkyTraq 624 or 628 in PPS sync mode (I’ve verified both can be put into sync to UTC mode) running with the full set of sentences at 115.2 kBaud consistently 14 milliseconds late. That is my DTR switcher will show the PPS $ at XX.9836 seconds, +/- one millisecond itself 3 milliseconds late per my oscilloscope.
I found it due to an annoyance where the generic FTDI USB ID is used for one of the GPS units in udev – so I didn’t intend to start it, but gpsd started, grabbed the serial port and the clock synced. Strangely, ntp (via ntpd or ntpdate) sets this so the PPS occurs at xx.540. I fixed the udev, but then ran it manually, and it synced right to the same microsecond offset again.
Maybe this could be of interest to you: http://shackspace.de/wiki/doku.php?id=project:hgg:timing_and_synchronization#gps
The EM-406A GPS Module is used as a time base in this project. It has a 1PPS output (Pin 6) and is available for 40$ to 60$.
Datasheet: http://www.sparkfun.com/datasheets/GPS/EM-406A_User_Manual.PDF
The aim of the project is to build a distributed satellite ground station network. Projects members have given a talk at 28C3:
* Presentation: http://events.ccc.de/congress/2011/Fahrplan/events/4699.en.html
* Video: http://media.ccc.de/browse/congress/2011/28c3-4699-en-building_a_distributed_satellite_ground_station_network.html
And they made a call to arms :-)
>the EM-406A GPS Module is used as a time base in this project.
Clever idea but it looks like it needs the West German time radio service to work :-)
If ever you really thought you knew what time it was, let me refer you to this posting of hal murray’s
http://www.febo.com/pipermail/time-nuts/2012-February/064267.html
I have some additional graphs from hal showing time as reported from four different breeds of gps varying by 100s-1000s of ms over roughly – but not quite – a 24 hour pattern.
@Dave Taht:
Well, that’s just… silly.
With a TCXO, you should be able to do a good job of figuring out which of those are wobbling and which are steady. Then it’s a matter of trying to figure out which of the steady ones are accurate.
Even though the Motorola OnCore might not be the right thing for the build of a hundred units, they might be the very thing for setting up a test lab. Anything that is used in cell stations in real life with no complaints is probably pretty good, because the cells absolutely depend on having the right time to keep from interfering with each other.
Adafruit has introduced a new GPS module / breakout board:
http://www.adafruit.com/blog/2012/03/09/new-product-adafruit-5v-friendly-gps-breakout-66-channel-w10-hz-updates-mtk3329-chipset/
GPS chip spec sheet: http://www.adafruit.com/datasheets/PA6B-Datasheet-A07.pdf
Price: $39 (http://www.adafruit.com/products/746)
The adafruit one looks sweet. Intelligently designed. Obviously not their first effort.
But maybe not for timing. Where’s the PPS pin?
It says that it has 10Hz updates. Maybe it does a better job of not wobbling the RS232 data.
At least for initial development, if we find a cheap enough device, maybe we just add a wire. That will tell us whether the latency through the USB is good enough.
This dongle is 23 bucks:
http://www.chinavasion.com/product_info.php/pName/gps-receiver-usb-adapter-for-computers-netbook-laptop-umpc/
Here’s a guy who used it with gpsd (not for timing, though):
http://theadventuresofsuperdoc.blogspot.com/2009/09/gps-with-cvgi-b07-on-eeebuntu.html
Here’s a guy who took it apart because it was the cheapest way to get a GPS module:
http://www.geekzone.co.nz/forums.asp?forumid=80&topicid=60005
Looking at his pictures, it doesn’t look like it would be hard to add a wire. The name of the GPS module is fairly clearly visible as a GlobalSat EB-3531. A quick check shows that that module does in fact support PPS and that the module vendor actually appears to have customer support:
http://www.usglobalsat.com/forum/index.php?topic=3953.0
Here’s the module datasheet:
http://www.usglobalsat.com/store/download/581/eb3531_ug.pdf
THe module shows as discontinued in their module comparison, which may be why devices using it are so cheap:
http://www.usglobalsat.com/store/engineboard_comparison/engineboard_comp.html
If you want, I’d certainly be willing to buy a couple and modify them for testing.
USGLobalSat also makes their own USB dongle which looks to be pretty decent build quality for not much more. Should probably be easy to add a wire to that, too.
>If you want, I’d certainly be willing to buy a couple and modify them for testing.
You’re the hardware designer. My job is the to keep the requirements in view of both of us and do the software integration. So, you get to choose the hardware path. But I don’t see that this gets us much of anywhere, since we can’t guaranteed that our production version will use the same USB adapter with the same latency.
We have now passed the point at which I can track all the branches in the decision tree through blog comments. Please get set up on gitorious so we can whiteboard some design possibilities on the thumbgps project wiki. I’ll bring in Hal Murray and some other interested parties.
Comment stuck in moderation queue.
The decision tree passed comprehensibility for me as well about 100 messages back.
I like ‘thumbgps’ as a name, too.
If anyone wants a specialized mailing list for this, I can set one up fast.
I HAD started a repo for the cbbd stuff a while back, and got stuck on representing ntp’s time format before I stopped. While software does intersect with hardware, and I’m rather interested in how the firmware is programmed on these puppies, I somehow doubt that that firmware is readily available?
>The decision tree passed comprehensibility for me as well about 100 messages back.
Please register on gitorious. That will allow you to erite on the thumbgps project wiki, and I’ll give you commit privs on the main repo.
Mailing list – That’s probably a good idea. You, I, Patrick Maupin and Hal Murray should be on it to start with.
thumbgps-devel created. I am generally reluctant to arbitrarily sign people up for a given mailing list without their express consent, so those interested in pursuing this idea in a format easier to deal with (e.g: email) please sign up at:
https://lists.bufferbloat.net/listinfo/thumbgps-devel
(apologies for the currently obsolete ssl key)
A full uart emulation chip for usb is just slightly
more expensive than a 4 wire one.
http://www.ftdichip.com/Products/ICs/FT231X.html
http://www.ftdichip.com/Products/ICs/FT230X.html
Which I think sort of begins to explain why the PPS devices have been vanishing from the planet.
It does strike me as kind of odd to go on emulating an obsolete standard (rs-232) for so long. USB2 has several modes of ‘native’ operation that seem more suitable… interrupts, and isochronous mode. ‘Interrupts’ are interesting in that they aren’t actually interrupts, but are polled for.
isochronous mode supports data streams of up to 480Mbit, and individual ‘packets’ of up to 1024 bytes.
Heh. It would be nice to get a real usb id for gps…
I replied to esr and Dave on new mailing list.
You can do it (assuming you compile GPSD with PPS on CTS – this should be a command line or config file option) with the following three main parts:
http://www.sparkfun.com/products/464 (Magnetic Mount active antenna with long cable)
http://www.sparkfun.com/products/11058 (SkyTraq breakout)
http://www.sparkfun.com/products/9873 (FTDI 3.3v Basic)
$13, 50, and 15 respectively for $78, Quantity 1. 100+ drops 20%. You would need a simple single-sided board with some headers to attach – all at 0.1″ centering, very easy to do, e.g. http://www.sparkfun.com/products/553 and http://www.sparkfun.com/products/116 – the PPS goes to CTS, the FTDI provides 3.3v @ 50mA – just enough for the GPS, and then just do TX – RXI and RX to TXO. Then some kind of packaging, the big problem is the hole for the mini-USB. You might have to configure the SkyTraq the first time, and AGPS helps (I have code for that – ftp download, then serial packetized upload with acks).
Even if you get a $30 GPS unit you would have to break it open and do some soldering under a stereo microscope, assuming you can attach the PPS to DCD or CTS or another pin easily.
For a highly accurate and inexpensive GPS time server solution, consider the Garmin 18X LVC OEM device which provides RS-232 NMEA and Proprietary messages plus a PPS output for 60 to 70 dollars US. The device comes with pigtail wiring that has Power+, Power-, Signal Gnd, RS-232 Rx, RS-232 Tx, and PPS. The device readily integrates with Linux 2.6+ kernels and I have set up many time servers using linux utilities gpsd, ntpd, and ptpd on commodity hardware machines. ntpq reports that the clock jitter is well under 20 microseconds and is usually within +/- 3 or 4 microseconds. A decent time server can be constructed for less than $200 US.
>For a highly accurate and inexpensive GPS time server solution, consider the Garmin 18X LVC OEM device
A couple of my senior devs use this GPS for time service; we know it well. It is indeed a good PPS source, but it has three serious drawbacks for the deployment I have in mind.
1. Low sensitivity – very poor indoor performance. The 18 has the design heritage of Garmin’s marine-GPS line; it’s good enough on the water, with an unobstructed skyview, but performance degrades rapidly in weak-signal environments.
2. Won’t talk to the USB port on a modern commodity router. Not even a conventional serial-to-USB adapter would do the trick; we’d need one of those, plus a hand-bodged cable adapter for Garmin’s OEM connector.
3. High cost per unit. What we’re going to deploy, the Navisys Macx-1, is less than half as expensive as the bare Garmin 18, let alone what the custom adapter hardware would cost.
Ooh, here’s another very interesting use this could enable!:
http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/spanner-osdi2012.pdf
Google is apparently using a combination of GPS high-resolution timing and locally installed atomic clocks (!) as part of a novel approach to a distributed, consistent database called “Spanner”.
I designed a board that has the Trimble Copernicus II on it. Used the dual-uart from ftdi to connect the two serial outputs from the GPS chip (one for raw trimble, the other for NMEA) — usb. Has an RF in and RF out (the second is for a follow-on GPS device in our system, and has a dc-block on it to allow the second device to receive the RF signal for it’s own use). I use my board on an embedded linux board as the system ntp server. I have gpsd and chrony working together. Cost of the boards, with parts, is about $75. And that’s just for 2 boards. Works like a charm.
A little late and still somewhat hand built, but see links on http://radiopc.vanbuer.net/~darrel/stratum1.html for complete Raspbery pi time server:
off the shelf parts: Adafruit GPS board $40, Raspberry Pi $35, 4GB SD card with software,
custom adapter board (I had 10 made for $60), micro usb power supply, case.
Ethernet built in, whole thing size of a pack of cigarettes. Do have to solder at least 10 pins, but no wires at all.
Darrel AK6I
This electronic parts search engine might help someone find something useful.
http://componentsearch.com/
Component Search
It is a startup company based in Orange County.
Good luck.
I do not believe that Midaged Computers are dying. still, now, laptop is one of the leading Laptop variety and nothing stands in its way. Macbook is doing a great business everywhere and people still want to own it.
The most interesting featurer that might be added would be 4K support, I just don’t know if the plumbing will support it.