gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] PPS over USB


From: Gary E. Miller
Subject: Re: [gpsd-dev] PPS over USB
Date: Mon, 7 May 2012 12:01:39 -0700

Yo Ed!

On Mon, 07 May 2012 12:31:59 +0100
Ed W <address@hidden> wrote:

> ...Very hostile answer Gary? What did I say to tick you off?

Sorry, not intentional, just trying to be very clear, and trying to stay
on topic for gpsd.  

> >> Just to be clear - the above is a waaay more powerful board than
> >> most routers, it's i586 compatible (rather than ARM).  However, it
> >> is probably more expensive than an old Linksys router, and it's
> >> switching capacity is almost certainly lower than a cutting edge
> >> Linksys job.
> > And that is exactly the problem.  They want a common dumb consumer
> > platform becasue they are looking to develop teaks for dumb consumer
> > platorms.
> 
> Still not quite clear what you are saying here?  First you say you
> can't do diy, then you say that you want to tweak off the shelf
> stuff?

You are confusing three cases.  One case is what the thumbgps project
wants/can do.  A second case is what I want/can do.  Third case is the
gpsd project focuses on.

Case 1: thumbgps needs cheap, off the shelf, totally standard.  No DIY,
and they need it now.

Case 2: I am comfortable building things from scratch.

Case 3: gpsd is software only, but some gpsd people fall in case 1 and
some in case 2.

> At least some interpretations of that are incompatible?

Correct.  Case 1 is very different from case 2.  Case 3 is a mixture of
both.

> Are you saying that you cannot narrow the platform hardware choices?

Case 1: I am saying the thumbgps project has long ago been fixed their
platform in stone.  You need to discuss the reasons for that with them.

Case 2: For myself I'll try anything.

Case 3: gpsd has some of both.

> The front page of the thumbgps platform suggests you are building
> your own 'wrt clone?

Case 1: Not me!  You have to ask them, but that is also my understanding.

Case 2: out of scope.

Case 3: out of scope.

> Note although you are ticking me off for *asking* if DIY is an
> option, your mailing list is full of technical chatter - I think you
> are quite harsh to an outside simply trying to offer some ideas when
> it's really not obvious what the parameters are.  I will stand
> corrected though...

Case 1: If you are interested in the thumbgps and bufferbloat projects
then you really need to direct your questions to them.  All the gpsd
project is doing is helping them with the time needs of their project.
They have explicitely stated DIY is off the table.

Case 2: I have no immediate need, but am curious what you come up with.

Case 3: they few DIY'ers in gpsd are doing their own DIY already.

> >> The bit I was trying to square was that the GPIOs don't currently
> >> have a linux driver which is interrupt triggered.
> >
> > Yup, and the bufferbloat project noted that and explictly decided
> > that to go down that road was to go Yak Shearing.  If such a driver
> > should appear that might be usefull in a future project.
> 
> Don't understand?  Isn't software on the table?  I thought it was
> only diy hardware which was out of contention?

Case 1: Once again you really need to ask the thumbgps project.  Don't
shoot the messenger.  They have explicitly taken kernel driver changes
off the table.

Case 2: I have no bandwidth left to think about kernel drivers.

Case 3: Kernel driver changes are also out of scope of the gpsd project.

If you feel you can get driver improvements in the kernel we would love
to see it happen.

> I already managed to get the basic GPIO changes into kernel 3.2 to 
> support this.  Either I or someone else needs to beat me to take the 
> code from the OLPC modules and turn it into a generic module.  For
> sure it's systems programming, but probably around 100 lines of code
> or so.

Case 1: Unless you get it in the kernel yesterday, too late for this round.
Otherwise out of scope for them.

Case 2: I have no bandwidth left to think about kernel drivers.

Case 3: And out of scope of the gpsd project.

> I do agree it's not perfect hardware though - hence my questions on
> what your requirements were.  Had this been a useful solution I might
> have been inclined to try and help get such a module developed sooner

Case 1: A day late and a dollar short.  The engineering samples meet all
objections and production orders are imminent.  If you wish to explore
this further with them you know where to find them.

Case 2: I have all the hardware I need.

Case 3: gpsd is mostly software hobbyists running on commodity hardware.

OTOH, if you think you have a product, then have at it.  Let us know how
it works out.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]