Share built in GPS

[Brofalad]

Hi
Hi all

I need to share the PDA build in GPS between two applications, ArcPad
(a commercial GIS program) and my own C# application. The ArcPad
application seems to be able to use the program port configured with
setting/GPS/program port. But not my own application. My application
can only use the hardware port. I have used the
System.IO.Ports.SerialPort and the target platform Pocket PC 2003.

What is the simplest way to make the two application to both share the
data from the built in GPS. ArcPad I can't modify of course. Is it
possible to use the SerialPort component and still share. My fist
thought was to just change the target platform to Windows Mobile 5.0
Pocket PC SDK (which support GPS intermediate driver) and use the
Settings/GPS/ to set the hardware port to the real hardware port and
than the two applications could both use the program port. But it
doesn't work only ArcPad seems to be able to use the program port.
What modifications do I have to make to my application?

Regards

Brofalad

 

[Paul G. Tobey [eMVP]]

Can another program, other than yours, successfully share the port with
ArcPad? If so, we know where the problem is: your code. You'd have to show
the code you're using, if you want any real suggestions about it. Perhaps
you're trying to open the "program port" with GENERIC_WRITE?

Paul T.

 

[Brofalad]

Thanks for your reply!

Yes, other program can share the port with ArcPad.

I'm using System.IO.Ports.SerialPort and just use Open() to open the
port.

I used the Terminal sample in the "Microsoft Mobile Development
Handbook" as a model.

Which means the Terminal sample has the same problem as my program.
How can the simple Teminal sample be modified to share comports with
other programs?

I can send you the Terminal sample code if you want.

/Brofalad

 

[Alberto Silva, MVP]

Hi,
Try GPSGate from www.franson.biz to share the COM port to check if it sutis
you better than the GPS share built-in feature of WM 5 and later.

--

Alberto Silva
http://www.moving2u.pt - R&D Manager
http://msmvps.com/AlbertoSilva - Blog
Microsoft MVP - Device Application Development

 

[Broeden]

Hi,

I am considering GPSGate, but it's commercial and yet some more steps for
the user to configure and probably will require support in many cases.

I would like to know if the SerialPort component is supported by the GPS
share built-in feature of WM 5 and later or I have to rewrite my application.

/Brofalad

 

[Alberto Silva, MVP]

Intead of using the SerialPort object and parse yourself the NMEA sentences,
have you considered trying the GPS sample from the Windows Mobile 6 SDK,
which 'natively' uses the built-in GPS share I told you about?

--

Alberto Silva
http://www.moving2u.pt - R&D Manager
http://msmvps.com/AlbertoSilva - Blog
Microsoft MVP - Device Application Development

 

[Broeden]

Thanks for your hints!

To 'natively' use the GPS Intermediete Driver was the rewrite option, which
I was hoping to avoid. But if the SerialPort component can't use the GPS
Intermediete Driver then I have to rethink.
I was hoping for the answer. "Yes, the SerialPort can be used if you..." or
"No, the SerialPort can't be used because..."

/Brofalad

 

[Paul G. Tobey [eMVP]]

Good.

The most-likely cause is that the SerialPort object is opening the device
for both read and write access, which, it should be obvious, can't really be
supported for multiple clients of a serial port. Since you want to try to
keep your code unchanged, my best suggestion would be to build your own
SerialPortShared class which either a) inherits from SerialPort but has an
Open method which tells the class to open the port only for reading, not for
both reading and writing (pass GENERIC_READ, not GENERIC_READ |
GENERIC_WRITE, as I'm sure the default SerialPort class does, or b) replaces
entirely the SerialPort class with GPSSerialPort or something. In the second
case, you'd have to step in and do all of the reads and writes, and also open
the device for read only, but you'd have complete control for getting data as
"GPS data", not just serial data.

A quick test to see if I'm right should be pretty easy just P/Invoking
CreateFileW() with the right parameters and seeing if, when you do that, you
can share the port with ArcPad successfully...

Paul T.

 

[DickGrier]

Hi,

There may be another alternative. Franson (www.franson.com) has their
GPSTools, which provides serial port sharing for GPS devices, between
multiple applications. I've use it with success, so you may want to give it
a try. That way, you wouldn't have to rewrite any code. The cost is
reasonable, IMO.

You can download a demo version from Franson. If it works for you, I can
provide you with the licensed version at a discount. You can contact me via
email if you want to pursue this avenue.

Dick

--
Richard Grier, Consultant, Hard & Software 12962 West Louisiana Avenue
Lakewood, CO 80228 303-986-2179 (voice) Homepage: www.hardandsoftware.net
Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004, Revised July
2006.

 

[Broeden]

Hi,

I have made some tests now. There is no problem to open the port with
CECreateFileW when using the programport configured by the GUI for GPS
Intermediate Driver. If I could change from R/W to just R that would be the
easiest sulotion. But how do I do override the Open method? I don't know all
what has to be done except for the CECreateFileW statement.

/Brofalad

 

[Paul G. Tobey [eMVP]]

I don't have Visual Studio in front of me. You know that you need to
override it; try it and see what happens. My guess is that you can't (class
might be sealed, etc.) As mentioned, at worst, you can use your own class.
The other options are a subclass, one or more extension methods...

Paul T.

 

[Paul G. Tobey [eMVP]]

After briefly looking at the SerialPort class, I don't think that you can do
what you need to do via a subclass or an extension method. You'd need to be
able to set the handle to the device used internally to the class and I don't
see any way for you to access it. That means that you need a class of your
own. You could start with the 1.x version of OpenNETCF's Smart Device
Framework, which had a SerialPort class.

Paul T.

 

[Broeden]

Thanks!

I have started to make my own class and at first it seems to work OK. But
then the the communication goes slower and slower until it stops and the
program is completely locked. Not even stop under running programs can kill
the program completely. HW reset is required. And it's quite hard to debug
this kind of realtime applications when youre not used to it.
Why isn't there a working solution out there ;-)
/Brofalad

 

[Paul G. Tobey [eMVP]]

It's definitely something you're doing. There are many pre-.NET CF 2.0
serial classes that didn't suffer from this. You've already been directed to
several working ways to do this. If your requirements are: 1) free, 2) can't
require any changes to my code, 3) doesn't require me to write my own class,
you're going to limit your choices!

Paul T.

 

[Broeden]

Yesterday I worked with alt 3, but it hangs, and I don't know how to find
the problem. Today I have started to work with alt 2. and i seems promesing
even tough my boss don't like big late changes...

/Brofalad