#30 After reverting from broken 0.9.3 to 0.9.2 older gpsd fails

closed
nobody
None
5
2007-05-29
2007-03-04
No

An attempt to uprade qpegps from 0.9.2.3.3 triggered a problem with gpsd. I do not quite understand how could it happen, but here are the facts:

My system is a Zaurus C1000, Cacko 1.23, Socket CF bluetooth card and Globalsat BT-338 (on /dev/rfcomm0)

I did:
- backed up my old working config
- ipkg remove qpegps (0.9.2.3.3)
- ipkg install gpsd
- ipkg install qpegps (0.9.3)
- tried to fix it with no success by editing configs and the qpegps binary several times. (see bug 1669793 at http://sourceforge.net/tracker/index.php?func=detail&aid=1669793&group_id=55933&atid=478750\)
- ipkg remove gpsd
- ipkg remove qpegps (0.9.3)
- ipkg install qpegps (0.9.2.3.3)

The old gpsd which comes inside old qpegps package and to the best of my memory did work for more than a year in the same environment, with the same configs and with the same hardware cannot connect to qpegps. The "gpsd" box does not stay constanly green. Instead it flashes red irregularly as if trying to reconnect all the time. Other boxes are red.

The GPS device itself is OK and connected
#rfcomm show tells me that it is connected and tty-attached.

cat /dev/rfcomm0 shows garbage though the parameters are OK without doubt.

New gpsd works well, but working qpegps does not connect to it. What can I do?

Discussion

  • Logged In: YES
    user_id=889173
    Originator: YES

    Is there a trick to make gpsd 1.x decode messages properly that could be undone by installing the new gpsd?

    I always ran it with "-p /dev/rfcomm0 -s 38400". The baudrate and port setting are correct (BT-338 uses 38400). What else can be the reason of garbage output?

     
  • Logged In: NO

    I had the same problem...
    The deinstallation is not deleting the config files. So I deleted the files qpegps.conf and qpe_default_profile.conf (etc.) in /home/zaurus/Settings after deinstallation by hand and installed the software again afterwards - then it worked. There seems to be a problem with the config file of the different versions.

     
  • Logged In: YES
    user_id=889173
    Originator: YES

    I remembered that and restored the gpsd related stuff in qpegps.conf and qpe_default_profile.conf. The arguments supplied to the older gpsd and qpegps/gpsd binaries are correct. The /etc/bluetooth stuff remained unchanged. Only the gpsd output changed from normal to junk.

    I have a theory that installation of gpsd 2.34 did something to the system's default tty settings. Gpsd 2.34 does not have the -s option and autoprobes different modes. Eventually it finds the right one and works. Could it screw up something?

     
  • ztep
    ztep
    2007-03-13

    Logged In: YES
    user_id=1578573
    Originator: NO

    The problem is that the new gpsd turns on binary mode on sirf based gps.
    You can use gpsctl included in gpsd ipk to back your gps to nmea text mode.

     
  • Ondrej_Kuda
    Ondrej_Kuda
    2007-03-25

    Logged In: YES
    user_id=1730745
    Originator: NO

    I have the same problem with gpsd. Upgrade from 0.9.2.3.3 to 0.9.3 and back.
    With gpsd 2.34 I was not able to get GPS signal - autoprobing all modes failed. I have CF i-TEC (20 channels), 4800 baud + Cacko 1.23 (+ the "hack" with baud rate divisor to 38400).
    I let gpsd scan all modes (gpsd -nND4 /dev/ttyS3) (4800,9600,...8/7...) in the first terminal, in the second I had opened telnet connection to see output and in the third I had gpsctl and had tried to change binary/NMEA modes... I could see only garbage.
    I can not use sirfmod and others, because I have not vt100 installed.

    So I uninstall qpegps 0.9.3 and install back 0.9.2.3.3: The GPSD status flashes red/green irregularly (OK/ERROR). Previous configuration gpsd -p /dev/ttyS3 -s 38400 doesn't work - only garbage.

    Also LED on the GPS module doesn't light as bright as before changes of gpsd (?).

    So I asked a friend with notebook and Windows to test GPS module with original software. The module was not recognized as GPS device any more (only Device on COM4), but it still sent garbage data (bursts of characters).
    I suppose there is a HW problem and I am going to claim the module :-(
    I didn't do anything except starting gpsd with different parameters.

     
  • ztep
    ztep
    2007-03-26

    Logged In: YES
    user_id=1578573
    Originator: NO

    My test said that in order to use gpsctl you cannot have another client conected to gpsd. You have wrote that you tried gpsctl while having a telnet to gpsd in other terminal.

    Have you tried to use it alone?

    Anyway I think that this is a problem related with gpsd, not with qpegps. Have you asked on gpsd forums?

     
  • Ondrej_Kuda
    Ondrej_Kuda
    2007-05-25

    Logged In: YES
    user_id=1730745
    Originator: NO

    I find out the problem (I guess). Cacko 1.23 recognizes my Compact Flash i-TEC GPS module Sirf III BC 337 as Dell Truemobile.... Bluetooth card. I have to change port baud rate setting to 38400 etc. (previously reported). This works with older gpsd (qpegps 0.9.2.3.3).

    The last version of gpsd (2.34) probes the module for baudrate speed. Unfortunately there seems to be a bug in the firmware of my module. The first probing cycle finished succesfully - module was identified and signal harvested, but there were no available satellites, so no fix.

    Then I tried gpsd again and I stopped gpsd with CTRL+C during the probing of senseless configuration (9600 bps). And here is the problem. Now the module is internally set to 9600 bps(?) and confused (fix/no fix?), and gpsd/cat/gpsctl/... are not able to connect succesfully or gain only garbage data.

    The same problem happened to MSI bluetooth GPS module I used.

    This is reported bug of certain firmwares (http://gpsd.berlios.de/upstream-bugs.html#bluetooth). I can confirm that module become working after several days out of power. There should be a condensor/battery which energizes the "internal memory" of the chip and setting of the interface. After energy depletion module forgets the setting and can be used again.

    So my recommendation would be to use gpsd with "-b" parameter:

    "Bluetooth-safety, otherwise known as read-only mode. Some popular bluetooth receivers lock up or become totally inaccessible when probed or reconfigured. This switch prevents gpsd from writing to a receiver. This means that gpsd cannot configure the receiver for optimal performance, but it also means that gpsd cannot break the receiver. A better solution would be for bluetooth to not be so fragile. A platform independent method to identify serial-over-bluetooth devices would also be nice." (see gpsd web).

    /opt/Qtopia/bin/gpsd -b /dev/ttyS3 for safety reasons could be good default configuration.

     
  • Logged In: YES
    user_id=889173
    Originator: YES

    I managed to solve this problem thanks to this post:

    > The problem is that the new gpsd turns on binary mode on sirf based gps.
    > You can use gpsctl included in gpsd ipk to back your gps to nmea text
    > mode.

    It worked, so I consider this bug a false alarm caused by lack of README information. Please, mention it in the readme file or add some other kind of a notice.

     
    • status: open --> closed