Keine Verbindung mit BT747 - i.Blue747Pro und Opensuse 11.3

Hallo zusammen,

ich habe mif den i.Blue 747 Pro angeschafft und will ihn mit Bt747 unter Suse 11.3 (Linux 2.6.34.8-0.2-default x86_64) verwenden. Leider bekomme ich keine verbindung von Bt747 weder über USB noch Blauzahn. Blauzahn erkennt das Gerät korrekt als 747 Pro GPS mit der Meldung, dass kein nterstützter Dienst vorhanden ist.
Mit lsusb bzw. lsusb -v bekomme ich die Ausgabe:

Bus 007 Device 004: ID 0e8d:3329 MediaTek Inc.

dmesg gibt

[ 1255.848089] usb 7-1: new full speed USB device using uhci_hcd and address 4
[ 1256.018069] usb 7-1: New USB device found, idVendor=0e8d, idProduct=3329
[ 1256.018073] usb 7-1: New USB device strings: Mfr=3, Product=4, SerialNumber=0
[ 1256.018077] usb 7-1: Product: GPS Receiver
[ 1256.018079] usb 7-1: Manufacturer: MTK
[ 1256.026400] cdc_acm 7-1:1.1: ttyACM0: USB ACM device

aus.

Ich probiere schon seit 5 Tagen a 5-6 Stunden rum. Keine Ahnung wieviele Seiten ich schon Gegooglet habe.
Ha t jemand einen Tip??

Gruss

Allgaeuer Bigfoot

sieht doch ganz gut aus: das system erkennt den logger schon mal.

schau dich HIER mal um: http://www.bt747.org/

wenn die dir nicht helfen können, wer sonst?

unter ubuntu rennt das teil schon seit 18 monaten bei mir. (per usb - ist eh schneller)

gruss
walter

Danke für die schnelle Antwort Walter,

ich denke die Problematik liegt in der 64 bit Architektur?? Der Pro mit 64 bit verwendet, glaube ich, /dev/ttyACM0 und die 32bit Version /dev/ttyUSB0.

Es bringt mir nichts, wenn USB und Blauzahn und BT747 jeder für sich läuft. Ich habe auch auf der Projektseite von BT747 schon jeden Buchstaben 2 mal umgedreht aber ohne Erfolg.

Die Datei run_j2se.sh von BT747 wurde von mir auch schon um eine Zeile (RXTXLIBPATH=${RXTXPATH}/Linux/x86_64-unknown-linux-gnu erweitert.

Ich habe auch schon diverse andere Sachen ausprobiert - mit dem Problem, dass das Dateisystem von 11.3 zu älteren Versionen eine komplett anderen Aufbau hat.
Das heisst , das manche Tips wegen fehlender /geänderter Dateipfade nicht klappen können. Beispiel: z.B. der USB Treiber ist nicht unter /proc sondern unter /sys oder /var abgelegt oder fstab - udev.

WINE will ich eigentlich nicht. Sonst könnte ich wieder Windows benutzen :-))
Linux hat bei Exotischen Anwendungen / Treibern noch Probleme - speziell mit den Human Device Treibern.

Vielen Dank nochmal

Andi

nöö, glaub ich nicht. meine kiste ist 64-bit und ich geh auch über /dev/ttyUSB0

das verstehe ich nicht - mach erst das eine (USB). warum beides zur selben Zeit am selben Rechner???

wende dich mal an deren FORUM

BT747 ist Pure Java. da ist nichts mit wine, da nicht notwendig. und driverprobleme hat es auch nicht zu geben. ist alles im jar-file drin.
daher mag ich java ja auch so gerne.

gruss
walter

Ich habe auch ein 64bit openSUSE 11.3 und das funzt prächtig mit meinen Datenlogger.

Deine Probleme könnten auf rxtx zurückzuführen sein, welches nicht alle Schnittstellen-Namen ohne Weiteres akzeptiert. (Früher hat bt747 diese Library verwendet, könnte heute auch noch so sein.) Wenn es daran liegt, und wenn bt747 dieses Namens-Problem nicht umgeht (was möglich ist) hilft es, das Problem auf Betriebssystemebene zu lösen.

Man kann dafür sorgen, daß der Logger sich zusätzlich zu oder statt /dev/ttyACMx als /dev/ttyUSBx anmeldet. Stichwort udev-Regeln → google. Ich habe dazu die Datei


/etc/udev/rules.d/99-usb-mtk.rules

mit folgendem Inhalt angelegt:


#Rename MTK-Logger from /dev/ttyACM* to /dev/ttyUSB*
SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0e8d", ATTRS{idProduct}=="3329", GROUP="dialout", NAME="/ttyUSB%n"

Neustart von udev nicht vergessen…

Vielleicht kannst du noch ein anderes Programm testen, um zu probieren, ob die Kommunikationsprobleme an BT747 liegen. Ich habe noch so dunkel im Hinterkopf, dass sich das Programm bei mir früher auch manchmal verschluckt hat und keinen Kontakt zum iblue 747 A+ herstellen konnte.

Hast du gpsbabel ausprobiert? Meine Tracks übertrage ich mit diesem gpsbabel-Befehl:

gpsbabel -t -w -i mtk -o gpx -f /dev/ttyACM0 -F iblue.gpx

Das ist bei mir ein Ubuntu-System, aber ebenfalls 64 Bit.

Das geht auch viel einfacher. Falls der Logger sich als

/dev/ttyACM0

angemeldet hat, sollte ein


cat /dev/ttyACM0

im Sekundentakt NMEA-Sätze auf der Console produzieren. Falls das geht, liegt es an der Anwendung.

Eine andere Fehlerquelle könnte die Rechtevergabe sein: rxtx versucht, eine Sperre im Verzeichnis


/var/lock

zu setzen. Hierauf muß der Nutzer entsprechende Schreibrechte haben. Bei mir gehört dieses Verzeichnis zur Gruppe


dialout

Evtl. muß diese Gruppe dem Nutzer hinzugefügt werden.

Habe hier ein 64bit-Fedora mit dem gleichen GPS-Logger, den ich per USB anspreche. Und dazu musste ich meinen Benutzer zu folgenden Gruppen zufügen:
dialout um auf /dev/tty* zugreifen zu können
lock um das Recht zu haben, irgendwas zu „locken" (= blockieren)
Manuell kannste Deinen Benutzer in der Datei /etc/group zu den Gruppen hinzufügen. Es geht aber auch grafisch (Benutzerverwaltung).

Im Programm bt747 habe ich im Feld neben „Verbinden" /dev/ttyACM0 eingetragen. Und im Feld neben „Übertragungsrate" steht 115200.

Vielleicht haste Dich schon zu viel damit beschäftigt und bist betriebsblind? Naja, dass mit der Zugehörigkeit zu den Gruppen (und der damit erworbenen Rechte) muss man auch erst mal wissen.