John
Mon Aug 28 12:59:47 CDT 2006
> 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@discussions.microsoft.com> wrote in message
news:EB23D139-8077-4FDA-932D-662778F56042@microsoft.com...
> 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@nospam.de> wrote in message
>> news:%23EsQS1IxGHA.2384@TK2MSFTNGP02.phx.gbl...
>> >
>> > "Marc" <Marc@discussions.microsoft.com> schrieb im Newsbeitrag
>> > news:61C0143D-02FD-420B-AC0F-681FB996F32D@microsoft.com...
>> >> 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
>> >
>> >
>> >
>> >
>>
>>
>>