[Thumbgps-devel] the serial alternative/radio noise

[Thumbgps-devel] the serial alternative/radio noise

[Dave Taht]

While this has already been discussed and discarded, and then sort of
brought up again,
there is a picture here of the on-board serial connector on these
classes of devices.

http://wiki.openwrt.org/toh/netgear/wndr3800

As noted there is no dcd pin to play with. There are plenty of other
GPIOs on the box however.

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.

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.

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

Re: [Thumbgps-devel] the serial alternative/radio noise

[tz]

The sparkfun venus is a pin-match for it (gnd- tx-rx-3.3v on 0.1
centers - tx to rx, rx to tx), so as long as it wasn't a console or
otherwise used it could work.  http://www.sparkfun.com/products/11058

The GPS antenna is at the end of a short or long wire, the mag mount
is about 10 feet or more so wouldn't be near the wifi.  I have had
problems with wifi interfering with GPS if it was "right on the case".

On Mon, Mar 12, 2012 at 5:54 PM, Dave Taht <dave.taht@gmail.com> wrote:
> While this has already been discussed and discarded, and then sort of
> brought up again,
> there is a picture here of the on-board serial connector on these
> classes of devices.
>
> http://wiki.openwrt.org/toh/netgear/wndr3800
>
> As noted there is no dcd pin to play with. There are plenty of other
> GPIOs on the box however.
>
> 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.
>
> 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.
>
> --
> 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

Re: [Thumbgps-devel] the serial alternative/radio noise

[Eric S. Raymond]

Dave Taht <dave.taht@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?  

> 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,
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] the serial alternative/radio noise

[Dave Taht]

On Mon, Mar 12, 2012 at 3:06 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Dave Taht <dave.taht@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

Re: [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@gmail.com> wrote:
> On Mon, Mar 12, 2012 at 3:06 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
>> Dave Taht <dave.taht@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

Re: [Thumbgps-devel] the serial alternative/radio noise

[Dave Taht]

On Mon, Mar 12, 2012 at 4:22 PM, Dave Taht <dave.taht@gmail.com> wrote:

>> I have observational evidence that we have problems with many kinds of
>> hardware and the cause is undefined, and varies by manufacturer.

A better way to put my question is: what evidence do we have that a
PPS signal over usb can provide better time?




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

Re: [Thumbgps-devel] the serial alternative/radio noise

[Eric S. Raymond]

Dave Taht <dave.taht@gmail.com>:
> On Mon, Mar 12, 2012 at 4:22 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> >> I have observational evidence that we have problems with many kinds of
> >> hardware and the cause is undefined, and varies by manufacturer.
> 
> A better way to put my question is: what evidence do we have that a
> PPS signal over usb can provide better time?

You pointed me at it yourself.  The guy who measured 50us jitter on a Windows
machine.  You should re-post that link here for the record and so others
can use it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: [Thumbgps-devel] the serial alternative/radio noise

[Patrick Maupin]

On Mon, Mar 12, 2012 at 6:22 PM, Dave Taht <dave.taht@gmail.com> wrote:

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

Is checking for good network connectivity where there isn't power that useful?

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

Agreed.  I thought about that and then discarded it.

> I'm not wedded to the the wndr3800 as the 'reference time ticker
> beyond the internet edge' for this project.

Well, I kind of like the idea of a braindead ethernet thing, too.  That
would require a router ethernet port, but a lot of routers don't have USB,
so that could be OK.

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

Right, which is why the first thing we need to build is precise
measurement capability for what we want.  (You can buy precise
measurement capability for tens of thousands of dollars, but you still
have to wire up your own stuff over to it, so I don't really see the
point.)

> 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

We're definitely on the same page.  I'd like to be able to do this in
hardware rather than software.  Or rather, do the lowest level stuff
in hardware, and collect data for the software to analyze.

The two major pieces of this are an FPGA and a really stable frequency
reference.  For example, you can get a 5ppb OCXO that will drift less
than 4 ms in a day, and a lot less than that for short term
disturbances.  Without such a thing, you can't say for sure that what
Hal saw wasn't times when his computer got so loaded down that tick
interrupts didn't happen.

Even though the Linux drivers and firmware aren't open source, my
favorite FPGA board at the moment is the 1.2M gate version of the
Digilent Nexys2.  I've probably bought around 40 of the Nexys and then
the Nexys2 for the lab at work.  You can easily build a big board that
plugs right into it, and a few little boards that plug into it too.
If there are no objections, this is what I plan on using for the base
of the timing tool:

http://digilentinc.com/Products/Detail.cfm?NavPath=2,400,789&Prod=NEXYS2

The big FPGA version is $189.

I can easily build a board to attach that has the following:

1) Provision for modules for a few different FTDI chips (FT232H, FT232R, FT232x)
2) Provision for modules for a few different GPS devices from different vendors
3) Provision for connectors for a few different GPS devices (e.g. Garmin 18x)
4) Provision for an OCXO
5) Provision for input from a timing reference such as a rubidium clock

I can fab 4 identical boards for ca. $200.  Probably another
$200-300/board for modules depending on how crazy we get.  The
question comes with the OCXO.  Do we want to get used ones off EBAY or
buy really expensive new ones?  I'm contemplating that perhaps we
should make it where we can use multiple ones and then check them
against each other.

> The venus really does look like a nice device.

Agreed.  Nice but expensive.

> A better way to put my question is: what evidence do we have that a PPS signal over usb can provide better time?

That's evidence we need to collect.

Re: [Thumbgps-devel] the serial alternative/radio noise

[Ron Frazier (NTP)]

I expect to have a Sure Electronics GPS board shortly.  Assuming I can 
solder it without killing it, I will be adding PPS to the DCD pin 
according to these instructions.

http://www.satsignal.eu/ntp/Sure-GPS.htm

Before I even do that, I'm going to test it with the serial output going 
into a Prolific based serial - USB converter.  I want to see if it 
exhibits the "drifting" behavior that I've been seeing on my Globalsat 
BU-353.  Once that's done, I hope to add PPS.  I've been told by David 
Taylor that I should be able to get 400 us offsets through the serial - 
USB converter with PPS but haven't had a chance to test anything yet.

Sincerely,

Ron


On 3/12/2012 7:22 PM, Dave Taht wrote:
> 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.
>
>    

-- 

(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] the serial alternative/radio noise

[Eric S. Raymond]

Dave Taht <dave.taht@gmail.com>:
> 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.

Fair enough.  But, as the person who has sort of dropped into the role
of project manager, it'a my job to ensure that (a) we have a coherent
and achievable set of objectives, and (b) the engineers keep their eye 
on that ball.  (For completeness, I consider the third major challenge of my 
job to be (c) negotiating with vendors and fabricators.)

For me, this is an amazing adventure, really. Me, a defrocked
mathematician, cat-herding a...*hardware* project.  Riiiight.  Good
thing I'm a naturally arrogant person or I'd probably be curled up in
fetal position in a corner somewhere.

Note, I also want to try this as a kind of experiment in just how far
down the post-industrial road we actually are.  I've been reading and
thinking for years about the demassification of production, silicon
foundries, 3D fabbing and other technologies that are supposedly
making semi-custom and individualized products more viable then ever.
The economist in me wants to grok these changes from ground level.

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

I understand that urge, but the increment in complexity required for
us to do "new stuff" would be all too likely to complexify the project
out of the zone of feasibility.  Let's do a design for which we *know*
that we have established need and a clear specification first.  If the
team gels and we develop good relationships with our vendors and
fabricators, we can then use that to go back around to things like
randomness sources and environmental sensors.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>