Haicom HI-302CF and Cacko ROM

GPS units
  • I am trying to run a Haicom HI-302CF (LP) with an external antenna on a Zaurus SL-C860. At first, I had the original Sharp-ROM installed but I have now changed to Cacko-ROM 1.22. I know that the card is functioning because I can use it on my Power Book G4. I also know qpeGPS is working because I can use it with a Garmin receiver.
    Under Sharp-ROM, getting the HI-302CF to work with qpeGPS or zGPS was highly erratic: I finally figured out it would work if I ran it at 9600 bauds after "cardctl resume" on ttyS3. Under Cacko-ROM, the card is detected and powered as soon as it is inserted (identified as a Bluetooth card, however, which shouldn't matter). The card gets a fix very quickly, and on the PowerBook I can see that the fix is correct and that it sends regular NMEA data.
    But so far, neither qpeGPS nor zGPS have established any contact with the HI-302. A "cat /dev/ttyS3" on the Konsole only returns endless rows of illegibile signs. I have tried all that has been recommended before -- reboot, kill gpsd, change baud rates. I am at my wit's end. Could it be that Cacko's handling of bluetooth cards is somehow interfering? But I know there are people around who have the card running under Cacko. But how?

    • > Under Sharp-ROM, getting the HI-302CF to work with qpeGPS or zGPS was highly
      > erratic: I finally figured out it would work if I ran it at 9600 bauds after
      > "cardctl resume" on ttyS3.

      According to the manual at  http://www.normap.no/Haicom/side_10.htm , the baud rate for HI-302CF is 4800 bauds.
      Have you tried that one?

      > A "cat /dev/ttyS3" on the Konsole only returns endless rows of illegibile signs.

      This is typical when you specify wrong baud rate.
      I guess bluetooth has nothing to do with it.


    • I know the baud rate is 4800 bauds, but so far it only works at 9600 bauds ...
      It seems that bluetooth has actually a lot to do with it.
      I finally got it to run the card under qpeGPS at 9600 bps for a short time after ejecting the card and running qpeGPS BEFORE reinserting the CF. The output was correct, but I could not reproduce this after reboot.
      Cacko automatically handles non-identified cards (card id string "CF CARD", "GENERIC", manfid "0x0279, 0x950b") as Bluetooth cards and sets the baud rate at 1000000 instead of suspending cardctl. That's how it is defined in etc/bluetooth/serial. In any case, serial_cs is bound but cardctl is resumed.
      That leads to the CF being powered-up upon insertion (which shouldn't be bad in itself). In most cases, I cannot get any signals after "cat /dev/ttyS3", and qpeGPS won't even finish booting -- because (that's my guess) ttyS3 is already busy. "cardctl suspend/resume" won't help because everything just repeats.
      I tried to outcomment all those definitions in the etc/pcmcia config files concerning unidentifiable CFs but without success. The baud rate still seems way to high. 
      So the important step should indeed be to prevent Cacko from misidentifying the Haicom as a Bluetooth CF. I just can't see how because its manfid is identical with many other cards (including Bluetooths).
      Or is this related to serical_cs itself?

    • Okay, I found a workaround.

      (1) Replace the serial_cs.o in /lib/modules/2.4.18-rmk7-pxa3-embedix/pcmcia/ with the one you can get at http://www.iral.com:88/~albertr/zaurus/misc/serial_cs.o.gz and activate it as described at http://qpegps.sourceforge.net/assets/gps_units/rikaline_gps_6021_x6.html.

      (2) Edit and save /home/etc/pcmcia/serials.opts as follows:
      (a) Uncomment (delete the leading #):
             SERIAL_OPTS="baud_base 4800"
      (b) Outcomment (add a leading #):
            #SERIAL_OPTS='grep "$ID" SERIAL_CONF | cut -f2 -d":"

      (3) Start qpeGPS. Ignore the "Cannot connect to gpsd" alert. In the Configuration menu, change the gpsd args to:
            -p /dev/ttyS3 -s 9600

      (4) Insert the GPS CF. The led will burn  continuously.

      (5) In qpeGPS, confirm the gpsd args (hit ENTER).
      Now the Data Status should display:
      gpsd: OK (green) GPS: ??? (green)
      As soon as the GPS CF gets a fix, you should see the usual position data and be able to display the according maps.

      (6) When you are done with qpeGPS, quit the program and eject the CF. For using it again repeat steps (3) to (5).

      ALWAYS insert the CF AFTER qpeGPS is running; ALWAYS run it at 9600 bauds.

      It turns out, then, that Cacko's way of setting up the base baud rate was at the core of the problem. The nice thing is you won't need to "cardctl resume" after inserting the card; this is done automatically. Very likely, however, this workaround will prevent you from using both bluetooth and GPS. For using bluetooth again, you'd have to reverse the settings in step (2). But as I don't use bluetooth, I have no way of confirming this.

    • Just for reference, I quote from a Japanese explanation about BlueZ (http://homepage.mac.com/mokjpn/Zaurus/BT.html):

      When using CF type GPS cards such as CFGPS2, it seems better not introduce the Bluetooth-related package. The CF type GPS card is visible as a serial port card from Zaurus, but as BlueZ camouflages the Bluetooth dial up terminal compulsorily in the serial port and dials up, there is interference. When a GPS card is used, it is probably better not to introduce this package, or move /etc/rc.d/init.d/bluetooth and /etc/rc.d/init.d/btstart to another place and switch Bluetooth functionality ON/OFF manually.

      (My translation.)

    • I found a simple workarround:

      Open the file /etc/bluetooth/serial with an editor, locate the line that starts with "CF CARD", "GENERIC". Append spd_cust divisor 24 at the end of this line.

      Now you have to use 38400 baud for the gpsd. The "spd_cust divisor 24" parameter forces the serial port to 4800 baud whenever a software switches the baudrate to 38400.

      The only side effect is that you can not use any GENERIC card with 38400 baud.