[Thumbgps-devel] the serial alternative/radio noise

[Dave Taht]

So in addition to the crypto + gps idea floated earlier

I direct you at the 'smile plug', which is also an ideal device for
deployment in places without reliable power.

http://www.youtube.com/watch?v=r74rKmz-9Qk

I have to drop in at stanford soon to check out their progress.

Earlier versions of this hardware (see the open-rd) had some
interesting connectors available in addition to usb. I don't know if
the dreamplug does - the guruplug had such lousy thermals as to rule
it out for any usage....

I'm not wedded to the the wndr3800 as the 'reference time ticker
beyond the internet edge' for this project, it merely seemed at the
time that just plugging in a good gps signal into the deployment via
the router I was already using (and bismark uses, as well as what
several other network measurement projects are using), which has
increasingly well characterized behavior, was the right thing.

we certainly seem to have identified a market and price gap between
shipped devices with bad time, and devices with good time, but we
haven't established that usb with PPS on 'dcd emulation' can be made
'more right', as yet.

So I'm kind of looking for ways to get the right parts and evaluate
the following without having to do much soldiering, to try and isolate
where each of the latency problems are.

PPS serial
PPS usb
kernel pps
gpsd w/wo r/t privs under load

Stuff like that. I'd like to be able to duplicate hal's weird traces,
find a reciever that works even halfway decently indoors, etc, etc.

The venus really does look like a nice device.

http://www.sparkfun.com/products/11058


On Mon, Mar 12, 2012 at 3:59 PM, Dave Taht <dave.taht at gmail.com> wrote:
> On Mon, Mar 12, 2012 at 3:06 PM, Eric S. Raymond <esr at thyrsus.com> wrote:
>> Dave Taht <dave.taht at gmail.com>:
>>> I AM curious if there is one of the gps boards we've looked at than
>>> can 'just fit' on this header. Or, for that matter, a RTC.
>>
>> How often do I have to sing the "this kind of customization won't scale"
>> song?
>
> Cats, herding.
>
> I note that in the early stages of any project, I tend to appreciate
> all sorts of blue-sky thinking, rather than tie down to any one goal,
> and try to encourage such in others. I guess in part what drives me in
> suggesting alternatives (and please note my alternative above was
> intended as a lead-in into the noise question more than an actual
> suggestion), is that I would like to find markets for a 'new device',
> that 'does new stuff', that justifies the manufacturing run, more than
> a 'usb gps with hyper-accurate pps and time output' may, as a
> differentiator.
>
> To give an example I've long had an interest in climate change, in
> particular, in the lack of good data from equatorial zones. I had
> intended while I was still working on my mesh project in Nicaragua to
> co-locate weather stations with at least some nodes, (multiple open
> source and open hardware alternatives are available, google for them),
> and in that case - given that the network might be down or
> non-existent, having good time for the samples also seemed good (as
> well as a good location indicator! See
> http://www.teklibre.com/~d/b4barrios10.kml for an interactive map of
> the sites I'd surveyed with my handheld gps below san juan del sur,
> Nicaragua).
>
> http://oscirrus.see-do.org/schematics/schematics.html for one weather
> station (this isn't the one I was thinking of at the time, tho)
>
> Anyway, this is a potential market use-case for the hardware as
> discussed thus far. There are no doubt others.
>
>>
>>> Now, I actually brought this up because in looking at this I realized
>>> anew what a huge radiator of various forms of electronic noise this
>>> is. - 2.4ghz and 5.x ghz radios, and a variety of possible waveforms
>>> from the cpu - and I'm curious as to what extent gps is affected by
>>> these frequencies.
>>
>> You and I have observational evidence that it's not an issue even for
>> low-end, poorly-shielded hardware,
>
> I have observational evidence that we have problems with many kinds of
> hardware and the cause is undefined, and varies by manufacturer.
>
>
>> --
>>                <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



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