[Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[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.

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.

Second, if I understand correctly, this device is EXACTLY what we want
to build, except for the lack of the PPS connection.

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.)

Fourth, and I can't stress this enough -- when you're doing things in
small quantities, you're unimportant.  Priorities change.  Nobody
bothers to inform you that the part you settled on as "best" after 30
hours of research is going to be end-of-lifed in 2 months.  But they
DO tell the customers that buy thousands, and those customers put in a
final buy order, and a few more are made and then the thing becomes
completely unavailable.  Then you're spinning a new board, scrapping
the 200 "extras" you had made because board pricing is such that the
first one costs a couple of hundred but the next few are practically
free, and doing a lot of extra work just to ship the next ten units.

(As an aside, the fourth point doesn't apply so much if you're willing
to pay a lot for the more industrial modules, but that probably gets
us above the price point we're aiming for.)

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.

OK, so what should we be doing?

I propose:

1) Such a test-system, thoroughly documented and used by 2 or 3 people
(or more if they want).  Investment might be around $300-400/unit to
achieve excellent accuracy, plus cost of whatever GPS devices you want
to hook to it.

2) A process whereby several different options are presented and the
pros and cons discussed and user chooses the best one for him

3) A dialogue with different vendors, and lots of descriptive links to
different products.

4) A storefront, perhaps with someone like seeedstudio or sparkfun,
where we can contract for them to build and have available a few of
the units du jour.  Minimal investment on our part that is not
designed to make a profit, but rather to facilitate their efforts in
making these things available.  As an example, buying 100 of those
cheap units would cost $2300 and if you had them modified and
minimally tested in seeedstudio in China that would add $2 to $5/unit.
 (seeedstudio is cheaper and probably more amenable to modifying other
devices.)

5) Links to other webpages where people have done the same sorts of
modifications.  I have seen several of these, some quite useful.

I think that the market is actually working well for these devices,
and that our efforts will be best spent categorizing winners and
losers and almost-winners, and facilitating modifying almost-winners
into winners, both on a one-off standpoint and with the manufacturers.
 At the end of the day, if we are successful, lots of manufacturers
will be shipping GPS mice with the desired properties.

Other people's mileage may vary and it may very well be that the right
answer is to, in fact, build a board and source components and build
the thing from scratch.  We all have our own biases, so I will
describe a little about my background here.  I work for a chip
manufacturer.  We ship zillions of chips.  But to design and test
those, we need boards and widgets in the lab.  We make anywhere from a
couple of those to dozens of those.  We also ship development kits
that may ship in the low hundreds.

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.  We have boards
made locally, or we hand make them in the lab.  Making boards in the
lab would be too expensive for 100 boards.  Making them in a local
board shop would probably be to expensive unless your minimum
production run was at least 50 boards --  then you could probably get
the assembly cost down to $10-$15 per board.

But making small modifications is a piece of cake.  I could probably
give our best technician $300 to take home 100 of those dongles that
just need a blue wire added, and take them home and add the wire, and
then we'd all be extremely happy.

You can see these economics in action all over the place.  Go look at
sparkfun or seeedstudio or any similar sites, and take a good look at
the products they actually make.  In a lot of cases, you will see "out
of stock" notices.  This is because the economies of the entire
process, from purchasing to board fabrication to board assembly, are
heavily weighted towards batch building.

The only economies that aren't significantly improved by batch
building involve hand labor (but even those are improved to the extent
that it's easier to outsource modifications to a batch than to a
single board).  This is why I strongly suggest that we find someone
who (1) has good economies of scale because they are making thousands,
(2) actually passes on a significant value of those economies of scale
to their customers, and (3) has a product that is easily adaptable to
what we need.

This is what I do all the time at work.  I make boards that have a
header to accept power from an ATX supply.  I build projects that fit
inside aluminum external drive cases (which you can buy for less than
you could buy the power supply inside!)  I work really hard to
leverage existing stuff I can find for cheap and turn into what I
need.  Sometimes.  If you're just building one board, banana jacks for
a lab supply are fine.  If you're building 15, it's nice for it to
have its own power supply.

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.

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

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>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[tz]

On Mon, Mar 12, 2012 at 5:03 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> 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.

The board is probably minimum 4 layer.

Every USB chip and every GPS chip I've seen in dongles are fine-pitch
surface mount.

You CANNOT do this with anything less than 2 layers with lots of vias,
and if the pitch is fine enough you will need at least 4.

Also the RF section for the GPS - antenna to the input - is critical.
You aren't just going to put some copper out there and have it work
well.

http://www.prolific.com.tw/eng/downloads.asp?ID=23

The prolific is 28 pin ssop with scattered power and ground pins.

GPS chips (except for highly integrated modules) are worse as far as
the pins you need to get to the right places.

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Patrick Maupin]

On Mon, Mar 12, 2012 at 4:03 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> 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 if you work with somebody like this or like seedstudio, they will
order parts for you and assemble according to your instructions.  If
you simply view the dongle as a part to be ordered and the assembly to
be "take it apart, add this blue wire, put it back together" you will
realize that the same process could apply, at least for a company that
does more than basic board assembly.

> But an advantage of starting with this $23 module is that we don't have
> to make that decision yet.

Exactamundo!

> [Test system] 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?

This is more what I do on a daily basis.  Use a bunch of readily
available off-the-shelf thingies to make a few units.  In this case, I
would buy a third party FPGA board, make a couple of smaller PCBs to
talk to it with a socket for an OCXO, maybe a connector to accept a
clock from a rubidium time source, headers for some USB modules and
some GPS modules and do some FPGA coding to allow reliable high
resolution timestamps.  There are a couple of levels of this.  The
first is just to do some one-off futzing around looking at various
devices.  The second is to get serious.  You could probably build 3
identical units with really good resolution and stability (expensive
OCXO) for under $2K total.  Maybe a lot less if you can find some good
surplus stuff on ebay.

> And this makes complete sense.  Seems like a good way to start that doesn't
> require excessive time commitment up front on your part.

In that case I'll start ordering and plotting out what I'm going to
do, and will sign up for the project to start putting out information
on the test setup for people to throw rocks at.

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

tz <thomas@mich.com>:
> On Mon, Mar 12, 2012 at 5:03 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> 
> > 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.
> 
> The board is probably minimum 4 layer.

Crap.  Well, there goes that idea then.  Or are there procedures for
reverse-engineering a multilayer board?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Patrick Maupin]

On Mon, Mar 12, 2012 at 4:18 PM, tz <thomas@mich.com> wrote:

> The board is probably minimum 4 layer.

The main board could easily be 2 layers, because the GPS is done in a
surface mount module that mounts on the main board.  Pictures here:

http://www.geekzone.co.nz/forums.asp?forumid=80&topicid=60005

> The prolific is 28 pin ssop with scattered power and ground pins.

There's apparently an 8 pin variant -- check the picture...

> GPS chips (except for highly integrated modules) are worse as far as
> the pins you need to get to the right places.

Right -- you ought to be able to use modules for this quantity.

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Patrick Maupin]

On Mon, Mar 12, 2012 at 4:26 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Crap.  Well, there goes that idea then.  Or are there procedures for
> reverse-engineering a multilayer board?

There's nothing to reverse engineer on that board.  It speaks for
itself.  Take a look at the picture :-)

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

Patrick Maupin <pmaupin@gmail.com>:
> On Mon, Mar 12, 2012 at 4:03 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> 
> > 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 if you work with somebody like this or like seedstudio, they will
> order parts for you and assemble according to your instructions.  If
> you simply view the dongle as a part to be ordered and the assembly to
> be "take it apart, add this blue wire, put it back together" you will
> realize that the same process could apply, at least for a company that
> does more than basic board assembly.

Good point.  Then, though, we're dealing with the risk that our supplier 
will EOL the product we're blue-wiring.  I can tell you from experience
that consumer-grade GPSes like these have ridiculously short lifetimes.

A friend (who may join this list shortly) once explained to me that
this is a result of patent lawsuit risk. The big Taiwanese electronics
companies spin up small shell companies to own the product designs, rent time
on their fab lines, sell a shitload of units from a couple of big-batch
runs, then fold before the lawsuits can land leaving the parent company
legally in the clear.
 
> > [Test system] 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?
> 
> This is more what I do on a daily basis.  Use a bunch of readily
> available off-the-shelf thingies to make a few units.  In this case, I
> would buy a third party FPGA board, make a couple of smaller PCBs to
> talk to it with a socket for an OCXO, maybe a connector to accept a
> clock from a rubidium time source, headers for some USB modules and
> some GPS modules and do some FPGA coding to allow reliable high
> resolution timestamps.  There are a couple of levels of this.  The
> first is just to do some one-off futzing around looking at various
> devices.  The second is to get serious.  You could probably build 3
> identical units with really good resolution and stability (expensive
> OCXO) for under $2K total.  Maybe a lot less if you can find some good
> surplus stuff on ebay.

OK.  Hal Murray will probably want one of these.
 
> > And this makes complete sense.  Seems like a good way to start that doesn't
> > require excessive time commitment up front on your part.
> 
> In that case I'll start ordering and plotting out what I'm going to
> do, and will sign up for the project to start putting out information
> on the test setup for people to throw rocks at.

OK.  I'll keep working the net looking for products we can mod or
reverse-engineer.  Also trying to cultivate interest in building 
product for us at Sparkfun and similar outfits.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

Patrick Maupin <pmaupin@gmail.com>:
> On Mon, Mar 12, 2012 at 4:26 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> > Crap.  Well, there goes that idea then.  Or are there procedures for
> > reverse-engineering a multilayer board?
> 
> There's nothing to reverse engineer on that board.  It speaks for
> itself.  Take a look at the picture :-)

Sorry, my eyes aren't educated enough. (I'm an ex-mathematician; what
relatively little I know about electronics design I've picked up by
osmosis doing software). What does it say?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[tz]

I can't find a datasheet with the pinout for the 8 pin PL2303.

You would need 4 lines for the USB, plus TX and RX.  It would depend
what the other two pins are.

On Mon, Mar 12, 2012 at 5:28 PM, Patrick Maupin <pmaupin@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 4:26 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>> Crap.  Well, there goes that idea then.  Or are there procedures for
>> reverse-engineering a multilayer board?
>
> There's nothing to reverse engineer on that board.  It speaks for
> itself.  Take a look at the picture :-)

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Patrick Maupin]

On Mon, Mar 12, 2012 at 4:37 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Good point.  Then, though, we're dealing with the risk that our supplier
> will EOL the product we're blue-wiring.  I can tell you from experience
> that consumer-grade GPSes like these have ridiculously short lifetimes.

Which is why the most important thing is to get the process down of
identifying what works and be able to vet a new device quickly.  As I
explained in my original posting, even high-dollar modules can get
EOLed, and then you're out money on your PCB blanks.   The only other
alternative is to pick a reasonable build size and always build that
many at a time.  But the problem with that batch mode is that you're
either carrying a lot of (more expensive than $23/unit) inventory, or
you're always out of stock when somebody wants one, or (more likely)
you oscillate between those two states.

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

Patrick Maupin <pmaupin@gmail.com>:
> On Mon, Mar 12, 2012 at 4:37 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> > Good point.  Then, though, we're dealing with the risk that our supplier
> > will EOL the product we're blue-wiring.  I can tell you from experience
> > that consumer-grade GPSes like these have ridiculously short lifetimes.
> 
> Which is why the most important thing is to get the process down of
> identifying what works and be able to vet a new device quickly.  As I
> explained in my original posting, even high-dollar modules can get
> EOLed, and then you're out money on your PCB blanks. 

I believe that.  But I also know some things about this corner of the
market that tend to reassure me on thast score.

1. The NRE on GPS modules (like the SparkFun GP2106) is a lot higher
than it is on the PCBs and enclosures for the consimer products.

2. Accordingly, they have longer product lifetimes. 

So by dropping down a level we'd trade higher up-front costs for a
substantial reduction in supply-chain volatility.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Patrick Maupin]

On Mon, Mar 12, 2012 at 4:39 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Sorry, my eyes aren't educated enough. (I'm an ex-mathematician; what
> relatively little I know about electronics design I've picked up by
> osmosis doing software). What does it say?

It says:

I am a very simple board.  My major components are:

- USB module
- USB patch antenna
- Small PL2303 clone (fitting in with your lawsuit theory)
- Simple 5v -> 3.3v voltage regulator
- Coin cell battery
- Diode so as not to drain battery during operation
- USB connector

There is nothing there that would require 4 layers, and all the
traces seem to "go somewhere".

There doesn't seem to be a real 8 pin SOIC PL2303.

It almost certainly isn't illegal to clone one of these chips
(although there might be an infringed patent or two there, that isn't
necessarily true either).  It probably is illegal to exhort people to
download the copyrighted Windows PL2303 driver and use it with this.
Probably not a problem with Linux :-)

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[tz]

OK, it is a 2 sided board, but you would have to find the 1PPS pin
(and it looks hard to solder to), attach a wire and and route it
somewhere - it is a SiRF III so has the larger jitter.

Since the GPS patch antenna is on the board, the board would have to
be in the sky view so you would have to run the PPS all the way to the
router if one of the pins isn't DCD, CTS or some other line.

On Mon, Mar 12, 2012 at 6:10 PM, Patrick Maupin <pmaupin@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 4:39 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>> Sorry, my eyes aren't educated enough. (I'm an ex-mathematician; what
>> relatively little I know about electronics design I've picked up by
>> osmosis doing software). What does it say?
>
> It says:
>
> I am a very simple board.  My major components are:
>
> - USB module
> - USB patch antenna
> - Small PL2303 clone (fitting in with your lawsuit theory)
> - Simple 5v -> 3.3v voltage regulator
> - Coin cell battery
> - Diode so as not to drain battery during operation
> - USB connector
>
> There is nothing there that would require 4 layers, and all the
> traces seem to "go somewhere".

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Patrick Maupin]

On Mon, Mar 12, 2012 at 5:23 PM, tz <thomas@mich.com> wrote:
> OK, it is a 2 sided board, but you would have to find the 1PPS pin
> (and it looks hard to solder to),

The module is documented, the pin doesn't look in that difficult a
place.  Seriously, my tech could probably do at least 50 of these an
hour.

> Since the GPS patch antenna is on the board, the board would have to
> be in the sky view so you would have to run the PPS all the way to the
> router if one of the pins isn't DCD, CTS or some other line.

This is what I'm less sanguine about.  When I thought it was a "real"
Prolific chip, I assumed that there would be at least a CTS.  And
maybe there is, but I'm concerned about the handling of it.  I've gone
off the idea of this module a bit simply because the chip is not
documented, but if it really is just a single blue wire from the
module to the USB converter, it would make a great solution.

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

Patrick Maupin <pmaupin@gmail.com>:
> On Mon, Mar 12, 2012 at 4:39 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> > Sorry, my eyes aren't educated enough. (I'm an ex-mathematician; what
> > relatively little I know about electronics design I've picked up by
> > osmosis doing software). What does it say?
> 
> It says:
> 
> I am a very simple board.  My major components are:
> 
> - USB module
> - USB patch antenna
> - Small PL2303 clone (fitting in with your lawsuit theory)
> - Simple 5v -> 3.3v voltage regulator
> - Coin cell battery
> - Diode so as not to drain battery during operation
> - USB connector

Yes, I identified most of these myself.

> There is nothing there that would require 4 layers, and all the
> traces seem to "go somewhere".

That is *exactly* what I thought when I looked at it.  Perhaps I am
less clueless than I feared. :-)

So, this is probably cloneable with relatively little effort, then?

> There doesn't seem to be a real 8 pin SOIC PL2303.
> 
> It almost certainly isn't illegal to clone one of these chips
> (although there might be an infringed patent or two there, that isn't
> necessarily true either).  It probably is illegal to exhort people to
> download the copyrighted Windows PL2303 driver and use it with this.
> Probably not a problem with Linux :-)

At that, PL2303s are cheap.  This page

http://www.ebay.com/sch/i.html?_nkw=pl2303+usb

clues us that they're probably less than $2 a unit.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Dave Taht]

On Mon, Mar 12, 2012 at 3:45 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Patrick Maupin <pmaupin@gmail.com>:
>> On Mon, Mar 12, 2012 at 4:39 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>> > Sorry, my eyes aren't educated enough. (I'm an ex-mathematician; what
>> > relatively little I know about electronics design I've picked up by
>> > osmosis doing software). What does it say?
>>
>> It says:
>>
>> I am a very simple board.  My major components are:
>>
>> - USB module
>> - USB patch antenna
>> - Small PL2303 clone (fitting in with your lawsuit theory)

As noted elsewhere it might be cool to get away from serial emulation entirely.

>> - Simple 5v -> 3.3v voltage regulator
>> - Coin cell battery

I like the supercap idea more than the battery idea. I imagine (and I
may be wrong) - that that will have a longer field lifetime than a
battery could.

>> - Diode so as not to drain battery during operation
>> - USB connector
>
> Yes, I identified most of these myself.
>
>> There is nothing there that would require 4 layers, and all the
>> traces seem to "go somewhere".
>
> That is *exactly* what I thought when I looked at it.  Perhaps I am
> less clueless than I feared. :-)
>
> So, this is probably cloneable with relatively little effort, then?
>
>> There doesn't seem to be a real 8 pin SOIC PL2303.
>>
>> It almost certainly isn't illegal to clone one of these chips
>> (although there might be an infringed patent or two there, that isn't
>> necessarily true either).  It probably is illegal to exhort people to
>> download the copyrighted Windows PL2303 driver and use it with this.
>> Probably not a problem with Linux :-)
>
> At that, PL2303s are cheap.  This page
>
> http://www.ebay.com/sch/i.html?_nkw=pl2303+usb
>
> clues us that they're probably less than $2 a unit.
> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> _______________________________________________
> Thumbgps-devel mailing list
> Thumbgps-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/thumbgps-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

Dave Taht <dave.taht@gmail.com>:
> As noted elsewhere it might be cool to get away from serial
> emulation entirely.

I agree.  For years I've thought it was silly that SiRF or somebody
else hasn't designed a direct-to-USB GPS chip.  Such an obvious next
step considering how obsolete RS232 is becoming - they could reduce
parts count drastically *and* claim a larger share of end-product BOM
for a double win.

Unfortunately, exactly *because* it's so obvious, the fact that it
hasn't been done sends an unpleasant message about the front-loaded
costs of this plan. They must be pretty high. If SiRF can't hack them,
they're sure as hell out of our reach.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Chris Kuethe]

On Mon, Mar 12, 2012 at 18:43, Eric S. Raymond <esr@thyrsus.com> wrote:
> I agree.  For years I've thought it was silly that SiRF or somebody
> else hasn't designed a direct-to-USB GPS chip.  Such an obvious next
> step considering how obsolete RS232 is becoming - they could reduce
> parts count drastically *and* claim a larger share of end-product BOM
> for a double win.

ublox antaris4 (and probably everything newer) has on-die usb and
implements the abstract modem class. but 1PPS isn't transmitted over
usb.

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

Chris Kuethe <chris.kuethe@gmail.com>:
> ublox antaris4 (and probably everything newer) has on-die usb and
> implements the abstract modem class. but 1PPS isn't transmitted over
> usb.

Annoyingly, it probably could be.  That modem model pretty much has to have 
DCD and RI events.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Ron Frazier (NTP)]

Hi all,

Regarding the sky view.  Maybe you can route the RF from an external 
antenna, or even an amplified antenna, after disconnecting the patch 
antenna.  I have a Globalsat BU-353 USB GPS, which is a Sirf III 
product.  It happily runs inside in a residential wood framed home.  
It's 10 feet away from the nearest window.  Except, it goes phycho every 
few days with large offsets for a few hours, then resumes normal 
operation.  The point being, the chipset is very sensitive and the patch 
antenna can do a pretty good job.  It would probably not work in a data 
closet in a commercial building.  The other point being, if you set up 
an external antenna, you can put your logic board where ever you want.

Sincerely,

Ron


On 3/12/2012 6:23 PM, tz wrote:
> OK, it is a 2 sided board, but you would have to find the 1PPS pin
> (and it looks hard to solder to), attach a wire and and route it
> somewhere - it is a SiRF III so has the larger jitter.
>
> Since the GPS patch antenna is on the board, the board would have to
> be in the sky view so you would have to run the PPS all the way to the
> router if one of the pins isn't DCD, CTS or some other line.
>
> On Mon, Mar 12, 2012 at 6:10 PM, Patrick Maupin<pmaupin@gmail.com>  wrote:
>    
>> On Mon, Mar 12, 2012 at 4:39 PM, Eric S. Raymond<esr@thyrsus.com>  wrote:
>>      
>>> Sorry, my eyes aren't educated enough. (I'm an ex-mathematician; what
>>> relatively little I know about electronics design I've picked up by
>>> osmosis doing software). What does it say?
>>>        
>> It says:
>>
>> I am a very simple board.  My major components are:
>>
>> - USB module
>> - USB patch antenna
>> - Small PL2303 clone (fitting in with your lawsuit theory)
>> - Simple 5v ->  3.3v voltage regulator
>> - Coin cell battery
>> - Diode so as not to drain battery during operation
>> - USB connector
>>
>> There is nothing there that would require 4 layers, and all the
>> traces seem to "go somewhere".
>>      


-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Ron Frazier (NTP)]

I think configuration data should be stored in flash.  That way extended 
power off periods are not a problem.

My BU-353 has a supercap.  That's better than a battery that I might 
have to replace, or possibly couldn't replace.  But I don't like knowing 
that, if I unplug it for a week, I'm going to have to reprogram it.

Sincerely,

Ron

On 3/12/2012 7:01 PM, Dave Taht wrote:
> I like the supercap idea more than the battery idea. I imagine (and I
> may be wrong) - that that will have a longer field lifetime than a
> battery could.
>
>    

-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Chris Kuethe]

On Mon, Mar 12, 2012 at 19:29, Ron Frazier (NTP)
<timekeepingntplist@c3energy.com> wrote:
> Regarding the sky view.  Maybe you can route the RF from an external
> antenna, or even an amplified antenna, after disconnecting the patch
> antenna.

Commercial re-radiators exist and work great for this, if you control
the building or can somehow get a cable through the wall... :)

You're right about the sirf3 freaking out. Somewhere I have logs of me
going for a walk in an urban canyon with a few different receivers.
The sirf3 did attempt to work with much weaker signals than the sirf2,
at the cost of solution stability. I know I walk fast, but I didn't
think I could walk at the speed of sound.

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Dave Taht]

On Mon, Mar 12, 2012 at 7:13 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Chris Kuethe <chris.kuethe@gmail.com>:
>> ublox antaris4 (and probably everything newer) has on-die usb and
>> implements the abstract modem class. but 1PPS isn't transmitted over
>> usb.
>
> Annoyingly, it probably could be.  That modem model pretty much has to have
> DCD and RI events.

Perhaps simply a real usb microcontroller with spi or i2c then driving
usb-2.0 for real...

http://www.linux-usb.org/ezusb/ - 16 bucks and WAY too  many pins...
but it should be possible to do much better than that after looking
harder.

I've also always got a kick out of the propeller chip...

http://www.parallax.com/Store/Microcontrollers/PropellerChips/tabid/142/CategoryID/18/List/0/Level/a/ProductID/411/Default.aspx?SortField=ProductName%2cProductName

Atmel's AVRs are also of interest...

http://www.olimex.com/dev/avr-usb-162.html

http://www.atmel.com/devices/at90usb162.aspx

> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Chris Kuethe]

On Mon, Mar 12, 2012 at 19:38, Ron Frazier (NTP)
<timekeepingntplist@c3energy.com> wrote:
> I think configuration data should be stored in flash.  That way extended
> power off periods are not a problem.
>
> My BU-353 has a supercap.  That's better than a battery that I might have to
> replace, or possibly couldn't replace.  But I don't like knowing that, if I
> unplug it for a week, I'm going to have to reprogram it.

See, I wouldn't mind losing the config after a few hours without
power. At least that way you have a way to reset the serial port when
it gets hopelessly confused - a situation known to gpsd as the
bluetooth problem.

>
> Sincerely,
>
> Ron
>
>
> On 3/12/2012 7:01 PM, Dave Taht wrote:
>>
>> I like the supercap idea more than the battery idea. I imagine (and I
>> may be wrong) - that that will have a longer field lifetime than a
>> battery could.
>>
>>
>
>
> --
>
> (PS - If you email me and don't get a quick response, don't be concerned.
> I get about 300 emails per day from alternate energy mailing lists and
> such.  I don't always see new messages very quickly.  If you need a
> reply and have not heard from me in 1 - 2 weeks, send your message again.)
>
> Ron Frazier
> timekeepingdude AT c3energy.com
>
> _______________________________________________
> Thumbgps-devel mailing list
> Thumbgps-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/thumbgps-devel



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Chris Kuethe]

On Mon, Mar 12, 2012 at 19:40, Dave Taht <dave.taht@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 7:13 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>> Chris Kuethe <chris.kuethe@gmail.com>:
>>> ublox antaris4 (and probably everything newer) has on-die usb and
>>> implements the abstract modem class. but 1PPS isn't transmitted over
>>> usb.
>>
>> Annoyingly, it probably could be.  That modem model pretty much has to have
>> DCD and RI events.

Well, serial is great for implementing in small/uncomplicated/cheap
hardware... I guess if you're TSMC or Atmel you can cram in a hardware
controller. And Atmel did joint work with ublox to produce the
antaris.

As for tiny USB stacks, at least LUFA and V-USB come to mind.  I think
you can fit a software implementation into 4K.

I don't know of any I2C/SPI GPS. If you can point me at some good ones
I'd appreciate it, because I was thinking I'd have to build some glue
logic to do that for another project of mine.

AT90USB162 are $3.71 for single pieces from digikey. Or about $20 if
you want a nicely fabricated board like the "teensy".

> Perhaps simply a real usb microcontroller with spi or i2c then driving
> usb-2.0 for real...
>
> http://www.linux-usb.org/ezusb/ - 16 bucks and WAY too  many pins...
> but it should be possible to do much better than that after looking
> harder.
>
> I've also always got a kick out of the propeller chip...
>
> http://www.parallax.com/Store/Microcontrollers/PropellerChips/tabid/142/CategoryID/18/List/0/Level/a/ProductID/411/Default.aspx?SortField=ProductName%2cProductName
>
> Atmel's AVRs are also of interest...
>
> http://www.olimex.com/dev/avr-usb-162.html
>
> http://www.atmel.com/devices/at90usb162.aspx
>
>> --
>>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
>
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Ron Frazier (NTP)]

Add a "bios reset" button like many modern PC motherboards have.

By the way, if anything on this design uses firmware programmable 
components, it should be field upgradable / flashable, preferably from a 
memory stick or sd card.

Sincerely,

Ron

On 3/12/2012 10:42 PM, Chris Kuethe wrote:
> On Mon, Mar 12, 2012 at 19:38, Ron Frazier (NTP)
> <timekeepingntplist@c3energy.com>  wrote:
>    
>> I think configuration data should be stored in flash.  That way extended
>> power off periods are not a problem.
>>
>> My BU-353 has a supercap.  That's better than a battery that I might have to
>> replace, or possibly couldn't replace.  But I don't like knowing that, if I
>> unplug it for a week, I'm going to have to reprogram it.
>>      
> See, I wouldn't mind losing the config after a few hours without
> power. At least that way you have a way to reset the serial port when
> it gets hopelessly confused - a situation known to gpsd as the
> bluetooth problem.
>
>    
>> Sincerely,
>>
>> Ron
>>
>>
>> On 3/12/2012 7:01 PM, Dave Taht wrote:
>>      
>>> I like the supercap idea more than the battery idea. I imagine (and I
>>> may be wrong) - that that will have a longer field lifetime than a
>>> battery could.
>>>
>>>
>>>        

-- 

(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such.  I don't always see new messages very quickly.  If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)

Ron Frazier
timekeepingdude AT c3energy.com

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Dave Taht]

On Mon, Mar 12, 2012 at 8:00 PM, Ron Frazier (NTP)
<timekeepingntplist@c3energy.com> wrote:
> Add a "bios reset" button like many modern PC motherboards have.
>
> By the way, if anything on this design uses firmware programmable
> components, it should be field upgradable / flashable, preferably from a
> memory stick or sd card.

hmm.. Anyone know anything about this puppy?

http://www.u-blox.com/en/gps-chips/timing-a-raw-data-chip/ubx-g6010-st-tm.html

>
> Sincerely,
>
> Ron
>
>
> On 3/12/2012 10:42 PM, Chris Kuethe wrote:
>>
>> On Mon, Mar 12, 2012 at 19:38, Ron Frazier (NTP)
>> <timekeepingntplist@c3energy.com>  wrote:
>>
>>>
>>> I think configuration data should be stored in flash.  That way extended
>>> power off periods are not a problem.
>>>
>>> My BU-353 has a supercap.  That's better than a battery that I might have
>>> to
>>> replace, or possibly couldn't replace.  But I don't like knowing that, if
>>> I
>>> unplug it for a week, I'm going to have to reprogram it.
>>>
>>
>> See, I wouldn't mind losing the config after a few hours without
>> power. At least that way you have a way to reset the serial port when
>> it gets hopelessly confused - a situation known to gpsd as the
>> bluetooth problem.
>>
>>
>>>
>>> Sincerely,
>>>
>>> Ron
>>>
>>>
>>> On 3/12/2012 7:01 PM, Dave Taht wrote:
>>>
>>>>
>>>> I like the supercap idea more than the battery idea. I imagine (and I
>>>> may be wrong) - that that will have a longer field lifetime than a
>>>> battery could.
>>>>
>>>>
>>>>
>
>
> --
>
> (PS - If you email me and don't get a quick response, don't be concerned.
> I get about 300 emails per day from alternate energy mailing lists and
> such.  I don't always see new messages very quickly.  If you need a
> reply and have not heard from me in 1 - 2 weeks, send your message again.)
>
> Ron Frazier
> timekeepingdude AT c3energy.com
>
> _______________________________________________
> Thumbgps-devel mailing list
> Thumbgps-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/thumbgps-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Chris Kuethe]

On Mon, Mar 12, 2012 at 20:04, Dave Taht <dave.taht@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 8:00 PM, Ron Frazier (NTP)
> <timekeepingntplist@c3energy.com> wrote:
>> Add a "bios reset" button like many modern PC motherboards have.
>>
>> By the way, if anything on this design uses firmware programmable
>> components, it should be field upgradable / flashable, preferably from a
>> memory stick or sd card.
>
> hmm.. Anyone know anything about this puppy?
>
> http://www.u-blox.com/en/gps-chips/timing-a-raw-data-chip/ubx-g6010-st-tm.html

Well, if it's anything like other ublox receivers it'll be pretty good
for timing.

I'm glad we still have docs for earlier devices: "The UBX-G6010-ST
Data Sheet, Hardware Integration Manual, and Receiver Description
Including Protocol Specification require an NDA and can be obtained by
contacting u-blox"

>> Sincerely,
>>
>> Ron
>>
>>
>> On 3/12/2012 10:42 PM, Chris Kuethe wrote:
>>>
>>> On Mon, Mar 12, 2012 at 19:38, Ron Frazier (NTP)
>>> <timekeepingntplist@c3energy.com>  wrote:
>>>
>>>>
>>>> I think configuration data should be stored in flash.  That way extended
>>>> power off periods are not a problem.
>>>>
>>>> My BU-353 has a supercap.  That's better than a battery that I might have
>>>> to
>>>> replace, or possibly couldn't replace.  But I don't like knowing that, if
>>>> I
>>>> unplug it for a week, I'm going to have to reprogram it.
>>>>
>>>
>>> See, I wouldn't mind losing the config after a few hours without
>>> power. At least that way you have a way to reset the serial port when
>>> it gets hopelessly confused - a situation known to gpsd as the
>>> bluetooth problem.
>>>
>>>
>>>>
>>>> Sincerely,
>>>>
>>>> Ron
>>>>
>>>>
>>>> On 3/12/2012 7:01 PM, Dave Taht wrote:
>>>>
>>>>>
>>>>> I like the supercap idea more than the battery idea. I imagine (and I
>>>>> may be wrong) - that that will have a longer field lifetime than a
>>>>> battery could.
>>>>>
>>>>>
>>>>>
>>
>>
>> --
>>
>> (PS - If you email me and don't get a quick response, don't be concerned.
>> I get about 300 emails per day from alternate energy mailing lists and
>> such.  I don't always see new messages very quickly.  If you need a
>> reply and have not heard from me in 1 - 2 weeks, send your message again.)
>>
>> Ron Frazier
>> timekeepingdude AT c3energy.com
>>
>> _______________________________________________
>> Thumbgps-devel mailing list
>> Thumbgps-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/thumbgps-devel
>
>
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net
> _______________________________________________
> Thumbgps-devel mailing list
> Thumbgps-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/thumbgps-devel



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Dave Taht]

On Mon, Mar 12, 2012 at 8:06 PM, Chris Kuethe <chris.kuethe@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 20:04, Dave Taht <dave.taht@gmail.com> wrote:
>> On Mon, Mar 12, 2012 at 8:00 PM, Ron Frazier (NTP)

>> hmm.. Anyone know anything about this puppy?
>>
>> http://www.u-blox.com/en/gps-chips/timing-a-raw-data-chip/ubx-g6010-st-tm.html
>
> Well, if it's anything like other ublox receivers it'll be pretty good
> for timing.
>
> I'm glad we still have docs for earlier devices: "The UBX-G6010-ST
> Data Sheet, Hardware Integration Manual, and Receiver Description
> Including Protocol Specification require an NDA and can be obtained by
> contacting u-blox"

I've read up a lot of this chips features, it has 12Mbit usb onboard,
also spi, this was some info on the timing stuff....

https://www.u-blox.com/images/downloads/Product_Docs/Timing_AppNote_%28GPS.G6-X-11007%29.pdf

wish I knew how much it was...

not clear to me just how much usb there is to the usb - is additional
glue/firmware/cpu neeeded?

>>> On 3/12/2012 10:42 PM, Chris Kuethe wrote:
>>>>
>>>> On Mon, Mar 12, 2012 at 19:38, Ron Frazier (NTP)
>>>> <timekeepingntplist@c3energy.com>  wrote:
>>>>
>>>>>
>>>>> I think configuration data should be stored in flash.  That way extended
>>>>> power off periods are not a problem.
>>>>>
>>>>> My BU-353 has a supercap.  That's better than a battery that I might have
>>>>> to
>>>>> replace, or possibly couldn't replace.  But I don't like knowing that, if
>>>>> I
>>>>> unplug it for a week, I'm going to have to reprogram it.
>>>>>
>>>>
>>>> See, I wouldn't mind losing the config after a few hours without
>>>> power. At least that way you have a way to reset the serial port when
>>>> it gets hopelessly confused - a situation known to gpsd as the
>>>> bluetooth problem.

I like the idea of onboard flash, which is why I went looking for the
atmel. Although sparkfun lists it as obsolete, I don't see an obvious
replacement from atmel....

And a supercap to stay alive as long as possible.

I think I've done enough damage to the potential pricepoint for one day...



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Chris Kuethe]

On Mon, Mar 12, 2012 at 20:16, Dave Taht <dave.taht@gmail.com> wrote:
> wish I knew how much it was...

Look at the cost of the timing eval kit. In large quantities you could
probably get oem modules for about 1/10th of that.

> not clear to me just how much usb there is to the usb - is additional
> glue/firmware/cpu neeeded?

My AEK-4T has a usb port on board. Done.

The hardware integration manual for the ublox5 says you need a few
resistors, a couple of decoupling caps, a couple of protection diodes
and a 3.3v power supply.

Both of them probably have all the code in the firmware already. Never
noticed any ill effect on timing quality even with verbose usb output.

>>>> On 3/12/2012 10:42 PM, Chris Kuethe wrote:
>>>>>
>>>>> On Mon, Mar 12, 2012 at 19:38, Ron Frazier (NTP)
>>>>> <timekeepingntplist@c3energy.com>  wrote:
>>>>>
>>>>>>
>>>>>> I think configuration data should be stored in flash.  That way extended
>>>>>> power off periods are not a problem.
>>>>>>
>>>>>> My BU-353 has a supercap.  That's better than a battery that I might have
>>>>>> to
>>>>>> replace, or possibly couldn't replace.  But I don't like knowing that, if
>>>>>> I
>>>>>> unplug it for a week, I'm going to have to reprogram it.
>>>>>>
>>>>>
>>>>> See, I wouldn't mind losing the config after a few hours without
>>>>> power. At least that way you have a way to reset the serial port when
>>>>> it gets hopelessly confused - a situation known to gpsd as the
>>>>> bluetooth problem.
>
> I like the idea of onboard flash, which is why I went looking for the
> atmel. Although sparkfun lists it as obsolete, I don't see an obvious
> replacement from atmel....
>
> And a supercap to stay alive as long as possible.
>
> I think I've done enough damage to the potential pricepoint for one day...
>
>
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net



-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

Chris Kuethe <chris.kuethe@gmail.com>:
> On Mon, Mar 12, 2012 at 19:38, Ron Frazier (NTP)
> <timekeepingntplist@c3energy.com> wrote:
> > I think configuration data should be stored in flash.  That way extended
> > power off periods are not a problem.
> >
> > My BU-353 has a supercap.  That's better than a battery that I might have to
> > replace, or possibly couldn't replace.  But I don't like knowing that, if I
> > unplug it for a week, I'm going to have to reprogram it.
> 
> See, I wouldn't mind losing the config after a few hours without
> power. At least that way you have a way to reset the serial port when
> it gets hopelessly confused - a situation known to gpsd as the
> bluetooth problem.

I agree with this argument.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Dave Taht]

On Tue, Mar 13, 2012 at 3:31 AM, Chris Kuethe <chris.kuethe@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 20:16, Dave Taht <dave.taht@gmail.com> wrote:
>> wish I knew how much it was...
>
> Look at the cost of the timing eval kit. In large quantities you could
> probably get oem modules for about 1/10th of that.
>
>> not clear to me just how much usb there is to the usb - is additional
>> glue/firmware/cpu neeeded?
>
> My AEK-4T has a usb port on board. Done.
>
> The hardware integration manual for the ublox5 says you need a few
> resistors, a couple of decoupling caps, a couple of protection diodes
> and a 3.3v power supply.
>
> Both of them probably have all the code in the firmware already. Never
> noticed any ill effect on timing quality even with verbose usb output.

http://www.u-blox.com/images/downloads/Product_Docs/LEA-6_NEO-6_MAX-6_HardwareIntegrationManual_%28GPS.G6-HW-09007%29.pdf

was nice. The speedo, temp sensor and spi support just cries out for the
weather station app I mentioned earlier.

but back to time...


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

Dave Taht <dave.taht@gmail.com>:
> On Mon, Mar 12, 2012 at 7:13 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> > Chris Kuethe <chris.kuethe@gmail.com>:
> >> ublox antaris4 (and probably everything newer) has on-die usb and
> >> implements the abstract modem class. but 1PPS isn't transmitted over
> >> usb.
> >
> > Annoyingly, it probably could be.  That modem model pretty much has to have
> > DCD and RI events.
> 
> Perhaps simply a real usb microcontroller with spi or i2c then driving
> usb-2.0 for real...

So, how would we get the data off the GPS chip if not through the TTL-level 
serial interface?  Are you proposing building our own serial-to-USB adaptor
with a microcontroller?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

Chris Kuethe <chris.kuethe@gmail.com>:
> On Mon, Mar 12, 2012 at 20:16, Dave Taht <dave.taht@gmail.com> wrote:
> > wish I knew how much it was...
> 
> Look at the cost of the timing eval kit. In large quantities you could
> probably get oem modules for about 1/10th of that.
> 
> > not clear to me just how much usb there is to the usb - is additional
> > glue/firmware/cpu neeeded?
> 
> My AEK-4T has a usb port on board. Done.

But does it pass 1PPS out?  I'm guessing not.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Dave Taht]

On Tue, Mar 13, 2012 at 4:54 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Dave Taht <dave.taht@gmail.com>:
>> On Mon, Mar 12, 2012 at 7:13 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>> > Chris Kuethe <chris.kuethe@gmail.com>:
>> >> ublox antaris4 (and probably everything newer) has on-die usb and
>> >> implements the abstract modem class. but 1PPS isn't transmitted over
>> >> usb.
>> >
>> > Annoyingly, it probably could be.  That modem model pretty much has to have
>> > DCD and RI events.
>>
>> Perhaps simply a real usb microcontroller with spi or i2c then driving
>> usb-2.0 for real...
>
> So, how would we get the data off the GPS chip if not through the TTL-level
> serial interface?  Are you proposing building our own serial-to-USB adaptor
> with a microcontroller?

Proposing, not as yet. Researching the idea, yes.

1) It would be my hope that the blox UBX-G6010-ST-TM actually did
supply the PPS over it's existing USB interface. The specs are
otherwise quite ideal - single satellite operation, fixed location
operation, 15ns pulse, etc., as you'll see from the links provided
earlier. eval board here:

http://www.abacuscity.ch/abashop?s=142&p=productdetail&sku=114

But I figure an email or conversation with u-blox is in order
regarding the level of their pps support and
firmware. If portions of their firmware were hackable, that would be excellent.

2) If it didn't, interfacing the time pulse pin of nearly any hardware
with a microcontroller that that had a full usb stack (eg the AVR
mentioned earlier) offers the opportunity to offer gps over a
non-serial, saner-for-gps new usb interface, no need to emulate
rs-232...

This latter idea has some good points (not all that much more
expensive than a usb-serial chip!), and
bad (whole other cpu, when there's a perfectly good arm7 inside most
of these gps chips)

> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[tz]

A re-radiator is possible, I had one for my car but this adds to the
complexity and expense.

You can do SPI or I2C - I have the EVK so can do some firmware
customization for the SkyTraq 628 - I can only do 10Hz but I can put
data out over SPI or I2C, but that is not the problem.

The newest Arduinos use a second Atmel chip (reprogrammable!) to
translate USB to serial - it replaces the FTDI, but we would have all
the source and it should be common enough to have drivers everywhere.
I don't remember if it has an ICP.  I have a different sparkfun USB
breakout Atmel chip that can be a serial adapter but has a high
resolution timer input capture the PPS could be run into.

http://arduino.cc/forum/index.php?topic=111.15

www.atmel.com/Images/7799S.pdf

The 32u2 would have space for extra things if we wanted to do things
like maintain a synchronized internal clock.   We could theoretically
add I2C sensors (gyro, baro/temp, accel, magnetic compass).  I had
something like this on a breadboard already 2 years ago (logged data
from a skytraq plus all these).

Note: The Skytraq chips have options to save configurations into FLASH
and SRAM or just SRAM.  It also has a "ROM" option if you screw things
up but I don't know if the right pins are on the breakout.

Most other chipsets have an option save to FLASH or EEPROM
(Non-Volatile storage).  We could add an EEPROM if we do our own USB
micro and do a soft reset and upload the configuration if needed.

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[Eric S. Raymond]

Dave Taht <dave.taht@gmail.com>:
> 1) It would be my hope that the blox UBX-G6010-ST-TM actually did
> supply the PPS over it's existing USB interface.

North American contact addresses:

Support: support_us@u-blox.com
General information: info_us@u-blox.com

Ask them.  We'd also need to know what USB model the interface uses.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] Build vs. modify vs. what should we be doing anyway?

[tz]

SkyTraq has a similar high-accuracy timing version of the 638:

http://www.skytraq.com.tw/products/Venus638LPx-T_PB_v2.pdf

On Tue, Mar 13, 2012 at 12:04 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Dave Taht <dave.taht@gmail.com>:
>> 1) It would be my hope that the blox UBX-G6010-ST-TM actually did
>> supply the PPS over it's existing USB interface.
>
> North American contact addresses:
>
> Support: support_us@u-blox.com
> General information: info_us@u-blox.com
>
> Ask them.  We'd also need to know what USB model the interface uses.
> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
> _______________________________________________
> Thumbgps-devel mailing list
> Thumbgps-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/thumbgps-devel