[Thumbgps-devel] Shotgunning the Shenzhen scene

[Thumbgps-devel] Shotgunning the Shenzhen scene

[Eric S. Raymond]

I spent several hours last night mining alibaba.com for contacts at
mainland Chinese electronics manufacturers. They don't publish email
contact addresses, so you have to use their real-time chat facility to
scare up a trade rep and talk him or her into disgorging an email
contact address for your RFP.

Here's who I ended up sending the spec to:

info@mightygps.com (MightyGPS.com), 
service@sja.com.tw (Sheng Jay Automation Technologies Co.), 
sales@navisys.com.tw (NaviSys Technology Corp.),
taylor.he8@gmail.com (Shenzhen Shanhai Technology),
michael@chinaonwin.com (Shenzhen Onwin Enterprise Limited),  
dawn@unitraq.com (UniTraq)

According to alibaba there are about a dozen Shenzhen and Taiwanese
companies shipping USB GPS dongles, but many of the product
descriptions and enclosures are so similar that I think these are
shells around no more than 2 or 3 distinct manufacturing and
engineering groups.  I'm pretty sure the list above covers all of
them.

Here's what I sent.  More comments below.

---------------------------------------------------------------------
I have a requirement for more than 100 USB GPS dongles.  I am
considering your company as a potential supplier.  I need a basic,
no-frills USB GPS in a thumb-drive-sized enclosure. Data logging and
other functions are not required, just location and time with 1PPS.

To evaluate the suitability of your product for my deployment, here
are some questions for which I need answers:

1. Please identify your eligible product by name and model number.

2. What GPS chipset does it use? (e.g. SiRF-III, Skytraq 6, etc.)

3. What USB-to-serial adapter does it use?  (e.g. PL23203, FTDI SIO, etc.)

4. Does your product carry the 1PPS timing signal from the GPS chip to
   to the DCD or RI input pin of the USB interface?

5. If the answer to question 4 is "no", would you be able to produce a variant
   that carries the 1PPS signal to the USB interface?

I am part of a group of engineers troubleshooting some wide-area
Internet performance problems. The deployment is for network delay
tomography, providing time service to monitoring routers running
Linux.  If you know of any specific feature of your product that might
impact this use, please specify.

If you are not familiar with "1PPS", it is a timing signal emitted
at the top of every GPS second to within 50 nanoseconds.  Almost all
GPS chipsets emit it to an output pin.  Many serial GPSes connect it
to the DCD or RI pin of an RS-232 interfaces.  I need a USB GPS that 
passes 1PPS state changes to the host as USB events.  If your dongle 
does not already do this, it is likely that adding a single trace to
your PCB (possibly with a level shifter) would add this capability.

If you did not find the above explanations understandable, please
forward this email to your product engineers.
---------------------------------------------------------------------

I see the following possible outcomes from this.  

1. One of these outfits is already manufacturing what we want and
   will tell us so.  Game over, we win.  I think this is unlikely,
   but it's possible.

2. None of these outfits are manufacturing what we want, but will 
   offer to OEM what we want once they figure out it's a single
   trace and a level shifter.  Probable win, depending on price.

3. Nobody will OEM what we want, but the information I elicit will
   identify plausible targets for devices to be blue-wired or 
   reverse-engineered.

Interesting note: The *only* trade rep who understood my query about
1PPS was at an outfit called Xucai Technologies that seems to be the 
actual manufacturer of the Chinavision dongle with the 8-pin PL2303
clone in it.  She told me they don't carry out the handshake signals, 
confirming our suspicions.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

You [should] not examine legislation in the light of the benefits it will
convey if properly administered, but in the light of the wrongs it
would do and the harm it would cause if improperly administered
	-- Lyndon Johnson, former President of the U.S.

[Thumbgps-devel] Effect of baud rate USB GPS / NMEA wandering effect / GPGGA

[Ron Frazier (NTP)]

Hi guys,

I thought I'd pass along some random info from my testing of my 
GlobalSat BU-353 USB only GPS.  Some of this has been discussed on the 
NTP questions list, and I thought it might be useful to you.

A) I have a nice example of (apparently) NMEA wandering here:

http://dl.dropbox.com/u/9879631/drifting01-peerstats.20120312.jpg

This graph shows my pc locked to the GPS, which is the jaggy dark line 
centered around zero vertically.  The band of colored lines is a group 
of internet servers I'm watching.  You can clearly see them wandering 
away from zero.  Then, in the middle, my GPS has a heart attack, and the 
offset of the colored lines dramatically shifts.  Then it starts 
wandering again.

So, one of three things is happening:

    1) all the internet servers are wandering
    2) my gps is wandering
    3) neither is happening, and this is a reporting error in the 
peerstats file

#2 seems the most likely.

B) The graph above was taken with the GPS set to 57600 baud.  I don't 
really even know what that means in the context of a USB connection.  I 
did that to reduce latency and perhaps jitter.  However, it may also 
reduce the stability of the GPS.  I've had two instances where my system 
clock suddenly jumped to about 52 seconds off.  Cause unknown.  I 
reduced the baud rate to 9600 as a test.  Results are preliminary, but 
it looks like the unit may be more stable and may wander less.  It 
didn't seem to affect the jitter much.  Regardless of how the data gets 
through the USB, once the baud rate was reduced, I had to adjust my 
offset fudge factor by about 90 ms to get the reported GPS time to agree 
with the internet servers I'm monitoring.

C) I believe I have recommended using the GPZDA sentence here before, 
and indeed, the manual for the Trimble Resolution T also recommends it 
for timekeeping.  However, David Taylor and I got into a discussion on 
this on the NTP Questions list.  He pointed out that the GPZDA doesn't 
have any validity check field where as GPGGA does.  We looked in the C 
code for NTPD's refclock implementation, and found out that it does 
check said validity field.  I don't know what it does with the data.  In 
any case, I decided to revert my system back to using GPGGA.  
Theoretically, this should allow a more graceful recovery in case the 
GPS fails.  In my experience, GPGGA does produce slightly more jitter 
than GPZDA.

Sincerely,

Ron


-- 

(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