From: "Eric S. Raymond" <esr@thyrsus.com>
To: Patrick Maupin <pmaupin@gmail.com>
Cc: thumbgps-devel@lists.bufferbloat.net
Subject: Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?
Date: Mon, 12 Mar 2012 17:03:45 -0400 [thread overview]
Message-ID: <20120312210345.GC17357@thyrsus.com> (raw)
In-Reply-To: <CAPz3yKdBJZzhSVMrT514aPehJGXMHVnGNKgt5rYNM6EuQ7=MTg@mail.gmail.com>
Patrick Maupin <pmaupin@gmail.com>:
> 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.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
next prev parent reply other threads:[~2012-03-12 21:04 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-10 18:02 Patrick Maupin
2012-03-12 21:03 ` Eric S. Raymond [this message]
2012-03-12 21:18 ` tz
2012-03-12 21:26 ` Eric S. Raymond
2012-03-12 21:28 ` Patrick Maupin
2012-03-12 21:39 ` Eric S. Raymond
2012-03-12 22:10 ` Patrick Maupin
2012-03-12 22:23 ` tz
2012-03-12 22:33 ` Patrick Maupin
2012-03-13 2:29 ` Ron Frazier (NTP)
2012-03-13 2:39 ` Chris Kuethe
2012-03-12 22:45 ` Eric S. Raymond
2012-03-12 23:01 ` Dave Taht
2012-03-13 1:43 ` Eric S. Raymond
2012-03-13 2:04 ` Chris Kuethe
2012-03-13 2:13 ` Eric S. Raymond
2012-03-13 2:40 ` Dave Taht
2012-03-13 2:53 ` Chris Kuethe
2012-03-13 4:54 ` Eric S. Raymond
2012-03-13 13:23 ` Dave Taht
2012-03-13 14:35 ` tz
2012-03-13 16:04 ` Eric S. Raymond
2012-03-13 16:22 ` tz
2012-03-13 2:38 ` Ron Frazier (NTP)
2012-03-13 2:42 ` Chris Kuethe
2012-03-13 3:00 ` Ron Frazier (NTP)
2012-03-13 3:04 ` Dave Taht
2012-03-13 3:06 ` Chris Kuethe
2012-03-13 3:16 ` Dave Taht
2012-03-13 3:31 ` Chris Kuethe
2012-03-13 4:49 ` Dave Taht
2012-03-13 4:55 ` Eric S. Raymond
2012-03-13 4:16 ` Eric S. Raymond
2012-03-12 21:40 ` tz
2012-03-12 21:27 ` Patrick Maupin
2012-03-12 21:22 ` Patrick Maupin
2012-03-12 21:37 ` Eric S. Raymond
2012-03-12 21:45 ` Patrick Maupin
2012-03-12 22:02 ` Eric S. Raymond
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120312210345.GC17357@thyrsus.com \
--to=esr@thyrsus.com \
--cc=pmaupin@gmail.com \
--cc=thumbgps-devel@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox