Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#12 Boot up delay needed

v1.0 (example)
open
nobody
5
2003-09-28
2003-09-28
Anonymous
No

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

Discussion

  • 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).