From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from snark.thyrsus.com (static-71-162-243-5.phlapa.fios.verizon.net [71.162.243.5]) by huchra.bufferbloat.net (Postfix) with ESMTP id 4E31B20024C for ; Mon, 12 Mar 2012 14:04:02 -0700 (PDT) Received: by snark.thyrsus.com (Postfix, from userid 1000) id 775BE40617; Mon, 12 Mar 2012 17:03:45 -0400 (EDT) Date: Mon, 12 Mar 2012 17:03:45 -0400 From: "Eric S. Raymond" To: Patrick Maupin Message-ID: <20120312210345.GC17357@thyrsus.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.21 (2010-09-15) Cc: thumbgps-devel@lists.bufferbloat.net Subject: Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway? X-BeenThere: thumbgps-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: esr@thyrsus.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:04:02 -0000 Patrick Maupin : > In this message on esr's blog, I suggested that perhaps we should > acquire and test/modify a really cheap ($23) USB GPS module. Sorry about the belated response - had a busy weekend and a houseguest. I was initially skeptical about this idea but I've come around for reasons I'll explain. > http://esr.ibiblio.org/?p=4171&cpage=1#comment-374779 > > esr correctly wanted to understand the value in this. > > There are several reasons to do this. First, it's dirt cheap for > playing with. We can test the latency through the prolific, hack in a > couple of FTDI chips and test their latency as well, test the wobble > on the PPS pin from that particular module, etc. Reason #1 I'm now persuaded this is a good idea is because it's using a PL2303, which as I've noted before is probably our safest choice for volume production if and when we start rolling our own PCBs. Thus, the PPS-to-USB latency statistics we collect on it are likely to be the *right* ones. > Second, if I understand correctly, this device is EXACTLY what we want > to build, except for the lack of the PPS connection. Reason #2 is that it's probably a single-layer board (can't think of any reason they'd have gone multilayer for a simple interconnect like this). Which in turn means we may very well be able to reverse-engineer a workable PCB design and parts list just by looking at this thing. > Third (and I alluded to this on the blog, but perhaps didn't stress it > enough) electronic parts pricing follows an exponential decay curve > vs. quantity. It is actually unlikely that you could make a PCB and > buy all the parts in that thing for anywhere as low as $23 in > quantities of 100, plus the labor of building the board is significant > compared to the labor of cutting a board trace and adding a wire. So > the first production run (maybe all production runs) could be to buy > those, add a blue wire, and ship them. (FWIW, real actual consumer > products ship with hacked boards all the time.) I'm still skeptical about custom builds for production - means one of us would have to do the soldering, keep inventory, ship the results. I'd rather develop a design and talk SparkFun or Dangerous Prototypes into fabbing it. But an advantage of starting with this $23 module is that we don't have to make that decision yet. Either way we go (selling a modified version of these things, or reverse-engineering to spin up our own design) we get a head start by blue-wiring one of these and testing it. > Fifth, the most important thing for us is probably a testbed that > gives us confidence in the latencies through the system. This is not > a board that will ship in quantity. As with all science, it should be > reproducible, but perhaps you only need two or three in the world. > This test system should probably be FPGA-based and should have at > least these capabilities: > > - High resolution, high stability frequency source (OCXO or TCXO). > - Ability to timestamp PPS signals from multiple attached GPS devices > to look for wobble > - Ability to timestamp start-character information from multiple > attached GPS devices -- maybe we can get lucky and find one that has > consistent message timing > - Ability to compare latency through different USB converters > > In other words, trust but verify. Spec sheets are meaningless, but we > can apply metrics to all the hardware we can find. This sounds like a larger project than just reverse-engineering the dongle, though. Do you have the capability, personally, to design and build such a thing? > So, while our product is made in China, we don't make enough boards to > do that. I know nothing about getting a board made in China, and > frankly have no interest in learning at this point. And you shouldn't have to. That end of the problem is what Sparkfun and Dangerous Prototypes are for. > In short, if this was a work project, I'd be buying a couple of those > $23 units with an eye towards hacking them and figuring out if I > wanted to buy another hundred. In that process, I would develop a > test bench and some skills that would let me analyze the units, and > other similar ones in the future, to evaluate if they really meet the > needs at hand, and to help insulate myself from inevitable future > product unavailability. And this makes complete sense. Seems like a good way to start that doesn't require excessive time commitment up front on your part. -- Eric S. Raymond