A bug or a feature? When the program first boots up,
the GPS may not be sending information. There needs
to be some sort of initial delay before it throws up an
error.
As a feature request, why not have it scan
each /dev/ttySx in order to automatically look for a
GPS?? It could also check the data coming out in order
to verify that it is of the correct type.
You can contact me at: rthawkcom@yahoo.com
Logged In: NO
Also, I have noticed that if you come out of a suspended
state, its necessary to click in the "Args:" box (on the GPS
tab) and hit "enter" in order to get it to start working
properly. I've also noticed the program hanging when the CF-
GPS card is removed. I believe all of these symptoms to be
related.
Logged In: NO
Also, I have noticed that if you come out of a suspended
state, its necessary to click in the "Args:" box (on the GPS
tab) and hit "enter" in order to get it to start working
properly. I've also noticed the program hanging when the CF-
GPS card is removed. I believe all of these symptoms to be
related.
Logged In: YES
user_id=564402
Yes, gpsd is not running at the first start of qpegps.
After the first start gpsd stays in the background
(daemon). => I'll set this on my ToDo-list.
Scanning on all tty ports is difficult => I did a small
test, and the Z locked up, when I was trying to read from
some wrong ports...it may be better, to check if I can
read this information from the CF mechanism
suspend:
Sometimes I have the same problem => ToDo-list
Please look at the note for the transplant gps unit on our
web-site => I'll check if I can use this to check if a gps
is connected (and on which port).