Historic archive of defunct list thumbgps-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
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>

  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