OpenNETCF GPS watchdog

  • Thread starter Thread starter Hilton
  • Start date Start date
H

Hilton

Hi,

If the GPS is turned off (or is never turned on), the GPS class is unable to
recover; i.e. it does not find the GPS and stops. Does anyone have watchdog
code (that is verified to work) to ensure that you can turn on/off the GPS
several times without the app no longer getting GPS data.

I know this sounds simple, but I have been trying numerous things, but I
cannot get GPS after a turn off/on.

Thanks,

Hilton
 
Hi Hilton,

I'm actually trying to do the same thing with my GPS stuff - ie recover from
a power off. As you know I'm not using OpenNetCF so I can't help you there,
but I would suspect that you may have to go the same route that I am
attempting.

The approach I'm using is a PowerNotifications class which uses
RequestPowerNotifications (I think that should work for any CE device from
4.1 onwards) so I can create a PowerOnNotification event. (there is an
example in the SDK pmsample.sln) When I get that event, I end the thread
that my GPSReceiver class is using and at that point I instantiate another
instance of that class, which in theory should fire up the GPS again.

Can't say I've got it all working correctly yet (not the easiest thing to
debug when the power goes off), but I am getting the event, however ending
the GPSReceiver thread is a little unreliable at the moment as I appear
sometimes to having trouble calling SerialPort.Close, something I referred
to in an earlier thread a few weeks back.

Using PocketPC Console is helpful in these situations. Most of the time, it
works and I can successfully close down the GPSReceiver class using Join on
its thread and then close down the Notification thread also using Join.

Then a couple of days ago I noticed I couldn't deploy again, because VS
reported that the app was already running and sure enough when I checked
with the Remote Process viewer my app is still running even though it
appears to have exited cleanly.

I'm working on that part now, trying to figure out why these 2 threads never
seem to end. I presuming its got to do with these 2 threads. Actually its
more likely the Notification thread, because the GPSReceiver thread has been
there for ever. Join is new in CF2.0 so maybe I've introduced another
problem there.

I hope this gives you a few ideas - I'll let you know how it goes if you
like. Please let me know if you come up with a solution.

Graham
 
Graham said:
I'm actually trying to do the same thing with my GPS stuff - ie recover
from a power off. As you know I'm not using OpenNetCF so I can't help you
there, but I would suspect that you may have to go the same route that I
am attempting.
Click to expand...

Well, I'm trying to recover from a 'stop in GPS data' (more general than
powering down the PDA). For example, let's say that the GPS's battery does,
you plug in the AC adapter, but OpenNETCF's GPS's object has stopped, never
to be restarted. Since there are events created in its run(), you can't
just fire up another thread. I don't want to change any OpenNETCF code so
that I can drop in new releases, so I'm stuck at trying to monitor and
restart (i.e. watchdog). It seems easy enough, but nothing I try allows me
to power-off the GPS for a minute or so, then power it back up.

Any OpenNETCF guru's out there that can help?

I'm kinda getting desperate, so I may have to resort to rewriting the
OpenNETCF GPS class (something I've tried to avoid up till now).

Thanks,

Hilton
 
Don't fear a code modification. It probably a better solution that to try
to hack around the limitation anyway. We've released the Serial and GPS
pieces as a stand-alone, CF 2.0/Studio 2005 supported component, so adding
it in is pretty simple.

http://www.opennetcf.org/serial

-Chris
 
Chris,
Don't fear a code modification. It probably a better solution that to try
to hack around the limitation anyway. We've released the Serial and GPS
pieces as a stand-alone, CF 2.0/Studio 2005 supported component, so
adding it in is pretty simple.

http://www.opennetcf.org/serial
Click to expand...

Very nice, thank you. Before I dive into the GPS code rewrite (although I'm
still hoping someone can come to the rescue with a quick work-around), I was
wondering: Wouldn't it be more efficient to 'auto discover' from high COM
port to low COM port, and high baud rate down to low baud rate? The first
will/should/may give you faster auto discover time, and the latter will give
you faster transfers.

Also, I'm running WM 5.0 and I can only connect to the GPS using COM8 (set
in the Settings|System GPS gizmo) with the GPS setting turned on (on the
Settings|System GPS). When I turn the GPS gizmo off, shouldn't I still be
able to connect without that intermediate step? I connected just fine
before WM 5.0, so I was wondering why I can now only connect when the
Settings|System|GPS is on and playing middleman.

Thanks,

Hilton
 
Very nice, thank you. Before I dive into the GPS code rewrite (although
I'm still hoping someone can come to the rescue with a quick work-around),
I was wondering: Wouldn't it be more efficient to 'auto discover' from
high COM port to low COM port, and high baud rate down to low baud rate?
The first will/should/may give you faster auto discover time, and the
latter will give you faster transfers.
Click to expand...

I'm not a fan of auto detect at all. There are occasions (like some BT
serial on devices) when opening a port will casue a dialog to appear. I
believe there's also a standard for GPS speed , so running through a set is
probably not realy ideal. If I were to have to try some auto detection, I'd
read the registry to semi-intelligently determine what COM ports even exist.
Then I'd open at the standard rate (I think it's 9600, but not certain) and
look for data there.
Also, I'm running WM 5.0 and I can only connect to the GPS using COM8 (set
in the Settings|System GPS gizmo) with the GPS setting turned on (on the
Settings|System GPS). When I turn the GPS gizmo off, shouldn't I still be
able to connect without that intermediate step? I connected just fine
before WM 5.0, so I was wondering why I can now only connect when the
Settings|System|GPS is on and playing middleman.
Click to expand...

The hardware may be turning on and off the GPS receiver when you go through
the settings to save power. If that's the case opening the port won't do
it, you'd have to do the added step of powering it, and that's probably not
a standardized thing.

-Chris
 
Back
Top