Re: GPS intermediate driver compatible to old software?

the GPS only on the software COM port but not on the hardware COM port...

I'm not sure about the other details of your Java library, though if it's
not working on real hardware COM port and you have an application using
GPSID this may be by design. It's possible the underlying hardware driver
has already locked out your java app from calling into it once GPSID opens
it up, though this is just speculation as serial drivers can handle multiple
apps calling into them however they feel like. Perhaps the takeaway here
then is to try to test in isolation as much as possible and reboot the
device since various drivers may be maintaining state.

As you said there's a lot of variables here, sorry I don't have much insight
beyond GPSID.

--
John Spaith
Development Lead, Windows CE
Microsoft Corporation

Check out the CE Networking Team Blog at http://blogs.msdn.com/cenet/.

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2006 Microsoft Corporation. All rights
reserved.

"Marc" <Marc@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:EB23D139-8077-4FDA-932D-662778F56042@xxxxxxxxxxxxxxxx
Hi John,

thank's for the detailed answer. I think in general the GPS intermediate
driver is a great idea. But the current behavior is a little bit
confusing. I
have a Java based application which uses a serial library. It seems that
the
serial library can sometimes access the software COM port and sometimes
not.
Sometimes the COM port enumerator (which the documentation says queries
the
OS for available COM ports) can see software COM ports and sometimes not.
A
test tool I have used detects the GPS only on the software COM port but
not
on the hardware COM port...

So it is very difficult for me to find out where the problem is: the user,
the Java serial library, my application, the WM5 OS or GPS intermediate
driver. So I tested several GPS tools with totally different results
(equal
to the results of Wolfgang tests). I will read through your comments in
detail. Maybe I can find an answer.

"John Spaith [MS]" wrote:

First of all I'd like to apologize for the bad experience folks have been
having here. Please let me know, either on the group or via email (just
strip "online." out of my mail) which applications you are having
problems
with as far as BC when they use GPSID.

To answer the big questions I can get out of this thread.

UI Ugliness - I'm aware the UI is too hard to configure.
http://blogs.msdn.com/cenet/archive/2006/07/07/659306.aspx. For the
long-term I ultimately believe it was a painful, needed step though.

GPD Ports - this was a bad idea on my part. In theory an application
could
open up say gPD5: to use as the port it gets NMEA from, but in practice
it
won't work because most older apps are hard-coded to only support
COM0-9:.
THe idea is that COM ports are very precious so we wanted some out to
save
them, but obviously it won't work.

Wolfgang's question on the .Net framework group / why his app is having
problems - this I really can't answer, since he indicated that he removed
the intermediate driver and he's still seeing problems. I'd recommend
making sure you don't do anything but the minimal CreateFile/ReadFile and
make sure baud rate, etc. are OK.

Wolfgang on "Virtual Earth Mobile" -- if there's not a newsgroup thread
on
this already, please kick one off.

MS Story on back-compat - We tested a few applications (Pocket Streets,
Ostia, and a Trimble high-end GPS config utility are the ones I remember
off
the top of my head). As I said above, please let me know what's not
working.

Reasons old apps would not work - Unless an application is trusted, we
do
not allow it to do WriteFile() to the GPS device. Let's say that you
have 2
applications running on the device, both using GPSID multiplexer. App1
calls WriteFile() to put the GPS device into some weirdo state. App2 all
of
a sudden is broken, as is any other app running. I decided breaking App1
was better than breaking the App2's of the world.

Additionally, i don't let apps call SetCommState(), SetupComm(), or
SetCommTimeouts() on the underlying GPS driver. Basically I don't want
them
putting underlying driver into a state other simultaneous apps may not
want
it to. In theory GPSID could do some of this logic it its layer to
handle
this per app, but we didn't have the resources available to dev/test
this.
If an app fails on one of those calls failing, it would break compat.

Yes, I know this bordering on trivia since you don't have src code to
apps
and couldn't change them if you could but it is some known problems and
why
there would be problems.

John

--
John Spaith
Development Lead, Windows CE
Microsoft Corporation

Check out the CE Networking Team Blog at http://blogs.msdn.com/cenet/.

This posting is provided "AS IS" with no warranties, and confers no
rights.
You assume all risk for your use. © 2006 Microsoft Corporation. All
rights
reserved.

"Wolfgang Schwarz" <nospam@xxxxxxxxx> wrote in message
news:%23EsQS1IxGHA.2384@xxxxxxxxxxxxxxxxxxxxxxx

"Marc" <Marc@xxxxxxxxxxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:61C0143D-02FD-420B-AC0F-681FB996F32D@xxxxxxxxxxxxxxxx
Thanks's for all the answers so far. I am glad to see that I am not
the
only
one who has problems.

But the key thing I want to know is how this intermediate drive should
work
in theory. Is it possible to run an old software which does not know
anything
about GPS intermediate drivers (like my software) and use the software
COM
port set in the OS GPS Settings like any virtual or hardware COM port
or
can
only special software which has been created using the WM5 SDK and
the
intermediate driver interface use the software COM port set in the
GPS
settings?

Yes I also want to know:
- Why does Software (e.g. "TomTom-Navigator", "VisualGPS" works on both
OS
(PPC2003 AND WM5). I don't thing that they use the new GPS intermediate
drivers.
- Why does my own Software written for PPC2003 and read NMEA data
diectly
from GPS device via SerialPort DIDN'T work ?
- Why does the GPS-Sample from the WM5 SDK hangs after several minutes
on
my device ?
- Why does the Software "Virtual Earth Mobile" not find any GPS device
on
my device.

Questions over Questions. Where is the logic ?


The next question is: what are these GPD ports which I can select in
the
OS
GPS settings dialog?

regards
Wolfgang









.

Relevant Pages

  • Re: GPS intermediate driver compatible to old software?
    ... to use as the port it gets NMEA from, ... won't work because most older apps are hard-coded to only support COM0-9:. ... and a Trimble high-end GPS config utility are the ones I remember off ... calls WriteFileto put the GPS device into some weirdo state. ...
    (microsoft.public.pocketpc.developer)
  • Re: Disabling Serial Ballpoint Mouse when GPS connected
    ... common occurance when this GPS is installed? ... > the 'found new hardware' Wizard requesting the driver for the new mouse. ... > connected to the serial port and to see if it's a mouse. ... > installing devices, but this would mean that the USB to Serial drivers ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Delorme SA2006 vs MS Streets and Trips 2006
    ... >>with other GPS units. ... This was in the first USB ... it had a driver that did the USB to serial ... > port conversion. ...
    (rec.outdoors.rv-travel)
  • Re: USB to Serial converter
    ... You might try some of the driver here if those are not the ones that came with it: ... rate I selected for the port. ... Do you have a GPS receiver? ... Do it after the GPS receiver has a fix because many GPS receivers will not output NMEA data unless they have a fix. ...
    (sci.geo.satellite-nav)
  • Re: GPS intermediate driver compatible to old software?
    ... I think in general the GPS intermediate ... driver is a great idea. ... serial library can sometimes access the software COM port and sometimes not. ... won't work because most older apps are hard-coded to only support COM0-9:. ...
    (microsoft.public.pocketpc.developer)