Odys Loox - Geräte mit inotifyd automatisch verwalten, einhängen

[fluxflux]

Was gibt dmesg als idVendor und idProduct aus, wenn du den BT-Dongle ansteckst?

Hier wird der Fehler liegen ... nachdem meine beiden BT-Dongles die idVendor 0a12 haben, habe ich die als Standard vorausgesetzt. Hat dein BT-Dongle eine andere ID, dann klappt es natürlich nicht und die rc.devwatch muss hier angepasst oder ergänzt werden.

Kannst du einfach lokal machen, indem du in der /system/etc/rc.d/rc.devwatch die 0a12 mit deiner idVendor überschreibst, mich würde die ID aber interessieren, damit ich sie ins Skript mit aufnehmen kann.

Danke,

Thomas.

Gesendet vom Odys Loox mit der Android-Hilfe.de-App

 

[KDO70]

Hallo Thomas,

Problem gelöst. Ich hab das Script rc.devwatch an meinen BT-Dongle angepasst.
ich hab die erste Zeile im Abschnitt Bluetooth-GPS wie folgt abgeändert:

if dmesg | busybox tail -10 | busybox grep idVendor | busybox grep 050d ; then

Dann hab ich noch die Zeile

hciconfig hci0 up

eingefügt. Die hast du im BTGPS-SCript auch verwendet. Erst nach dem einfügen dieser Zeile klappt es nun.

Klaus

 

[fluxflux]

Die Zeile hciconfig hci0 up braucht es aber nicht, wenn der Stick auch ohne die Zeile blinkt, denn dann ist hci0 schon "up".

Mein Fehler war die falsche idVendor und wahrscheinlich auch die zu geringe Zeilenzahl, wenn da noch ein paar mehr Infos ausgeworfen werden.

Ich erweitere die rc.devwatch und schicke sie PopEi, damit sie jeder ins System kopieren kann.

Danke für den Hinweis!

Thomas.

 

[KDO70]

ohne diese Zeile blinkt der Stick aber leider nicht! Ich lass sie bei mir erstmal drin.

Klaus

 

[fluxflux]

Hm, wann steckst du den Stick an?

Nach dem Booten?

Thomas.

 

[fluxflux]

Die Änderungen in der boot.img setzten den BT-Dongle, wenn er beim Booten angesteckt ist, auf "up", das bootende Android schaltet ihn dann aber wieder ab.

Also läuft das Skript ohne die Zeile "hciconfig hci0 up", wenn der BT-Dongle nach dem Booten eingesteckt wird und nur mit der Zeile "hciconfig hci0 up", wenn der BT-Dongle von Anfang an angesteckt ist.

So ist das hier mit 2 BT-Dongles jederzeit reproduzierbar.

Ändern kann ich das leider nicht, werde dann wohl sicherheitshalber die Zeile mit aufnehmen, dann klappt es in beiden Fällen ...

Thomas.

 

[KDO70]

Den BT-Dongle steck ich erst nach dem Booten an.
Die Anzahl der Zeilen die mit tail ausgelesen werden kann bei mir auch mal bis zu 15 sein!

Klaus

Klaus

 

[KDO70]

Hier die Ergebnisse meines "Feldversuchs" heute morgen.

BT-Stick wird erkannt, Verbindung zum BT_GPS hergestellt.
Nun starte ich UsbGPS. Nach ca. 30 sec. bricht die Verbindung zum BT_GPS ab.
Ein paar Sekunden später bricht UsbGPS ab, da es keine Daten mehr erhält.
Danach startet da Script wieder!
BT-Stick wird erkannt, Verbindung zum BT_GPS hergestellt.... usw.

Das ganze lief 5 oder 6 Mal ab. Den Wert nach tail hatte ich auf 14 gesetzt.
So klappt die Navigation leider noch nicht

Wie gesagt, als ich nur das BTGPS-Script verwendet habe, hat es geklappt, auch nachdem ich das Script nach Übernahme des Streams durch UsbGPS beendet hatte.

Klaus

 

[fluxflux]

Sehr rätselhaft ...

Ich verwende hier zwei BT-Dongles (Hama, Sitecom), mit beiden klappt eine Verbindung und auch die Navigation mit GoogleMaps und Navit oder Osmand.

UsbGPS übernimmt den Stream, der Stream bricht nicht ab, alles wie es soll.

Mir ist noch nicht klar, warum das ganze Prozedere bei dir mehrmals abläuft ... dazu müsste der BT-Dongle ja getrennt werden, damit er wieder neu erkannt wird und das Skript neu startet. Denn wenn es ein zweites Mal klappt, muss ja der "d"-Event abgelaufen sein und /dev/rfcomm0 wieder frei sein, sonst würde es nach meinem Verständnis nicht klappen.

Mal sehen, was mir oder dir noch einfällt ...

Thomas.

 

[KDO70]

Genau das hat mich ja auch gewundert.
Der BT-Dongle steckte die ganze Fahrt im Gerät.
Nach ca. 30sec hat der STick die Verbindung zum BT-Dongle verloren (LED leuchtete nur noch Blau). Nachdem dann UsbGPS dies auch registriert hatte und ebenfalls die Verbindung gestoppt hatte, hat der BT-Dongle wieder angefangen zu blinken...
Ich verwende einen BELKIN FPT017.
Manuell hat die Navigation mit Navit wunderbar funktioniert.
Mal sehn, wo da sich der Fehler versteckt.

Klaus

 

[fluxflux]

Ich bin kurz davor, die ganze Sache in die Tonne zu treten ...

Habe von einem Kollegen einen Sitecom-BT-Dongle bekommen, den er noch in seiner Teilekiste hatte.

Der wird als

New USB device found, idVendor=0df6, idProduct=2200

erkannt und es geht weder das btgps-Skript noch das inotifyd-Skript. Sobald der BT-Dongle aktiv wird, kann /dev/rfcomm0 nicht mehr angesprochen werden ohne dass der BT-Dongle sofort neu initialisiert und /dev/rfcomm0 blockiert ist.

Ein "cat /dev/rfcomm0" ist nicht möglich, man sieht aber, dass der BT-Dongle Daten vom BT-GPS übernimmt, er flackert fleißig vor sich hin.

???????

Thomas.

 

[Oma7144]

Ich bin kurz davor, die ganze Sache in die Tonne zu treten ...

.... nein, nicht aufgeben!


Aber grundsätzlich ist anzumerken, daß der Kernel recht instabil ist, wenn noch andere Module "nebenher" laufen ....


Meine Erfahrung hier ist: mal geht es, mal nicht. Wenn dann noch der Hub dazwischen ist, dann ist alles äußerst instabil.

 

[fluxflux]

Es läuft hier mit den BT-Dongles, die die idVendor=0a12 haben, absolut zuverlässig und ohne Fehler.

Der Sitecom-BT-Dongle läuft auch, aber ich kann den Stream nicht abgreifen, UsbGPS auch nicht, es kommt keine Verbindung zustande, ein "cat /dev/rfcomm0" kann nicht ausgeführt werden: "Connection refused".

Es scheint also so zu sein, dass die Bluetooth-Einbindung, die Bluetooth-Kernelmodule und das UsbGPS nicht immer sauber zusammen arbeiten und es offensichtlich auch BT-Module gibt, die buggy sind.

Da stehen wir nun ...

Thomas.

 

[KDO70]

Wenn ich das BTGPS Script verwende, dann klappt es wunderbar.
Nur bei inotifyd-Skript kommen diese Abbrüche.
Hängt das vielleicht damit zusammen, daß im script 30 sekunden gewartet wird, in denen man UsbGPS starten muß, und dann das script 'abgeschossen' wird (busybox killall cat)

Mein BT-Dongle beinhaltet zudem noch einen Hub mit 3 Ports , wobei er dann zuerst eine Tastatur, dann noch eine Maus einbindet und erst dann den BT-Dongle. Ich schick dir heute abend mal den Auszug aus dmesg, was bei der BT-Dongle Initialisierung alles angezeigt wird, hab im Moment leider kein wlan und kein passendes USB-Kabel dabei.

Klaus

 

[fluxflux]

Im btgps-Skript lässt du wohl das "cat < /dev/rfcomm0" weiterlaufen, solange die Navigation läuft?

Wenn ja, dann müsstest du im rc.devwatch nur das & nach "cat /dev/rfcomm0" rausnehmen und die beiden folgenden Zeilen mit # kommentieren.

Dann sollte es genauso laufen.

Thomas.

 

[fluxflux]

Meine Erfahrung hier ist: mal geht es, mal nicht.

Der Wahnsinn hat einen Namen: LOOX ...

Jetzt geht das inotifyd-Skript auch mit dem Sitecom, der die letzten 2 Stunden nicht gegangen ist!

Ich habe nur die sleep-Time im rc.devwatch auf 45 Sekunden verlängert und schon läuft der BT-Dongle, als wäre nie was gewesen.

Offensichtlich werden dem UsbGPS die Rootrechte zum Switchen auf /dev/rfcomm0 nicht immer schnell genug gegeben.

Das fällt beim btgps-Skript nicht auf, da man ja zuerst UsbGPS startet und danach das "cat" beendet. Da passt es also immer.

Thomas.

 

[KDO70]

Werde ich testen und dann melden ;-)

Klaus

 

[fluxflux]

Um die Sache mit den verschiedenen IDs zu umgehen, denke ich an diese Lösung:

Statt die ID zu prüfen wird einfach auf ein hci0 geprüft, das automatisch da sein muss, wenn die Kernelmodule für den BT-Dongle passen und hci0 wird aktiviert, falls man den BT-Dongle schon beim Booten angesteckt hatte.

Würde in der rc.devwatch dann so aussehen:

if hciconfig | busybox grep hci0 ; then
hciconfig hci0 up
...
fi

Bisher:

if dmesg | busybox tail -5 | busybox grep idVendor | busybox grep 0a12 ; then
...
fi

flux.

 

[KDO70]

2. Feldversuch:

Das Script hab ich abgeändert, wie du es im letzten Post beschrieben hast. Die Wartezeit hab ich auch auf 45 sec hoch gesetzt.
BT-Dongle wird gefunden und startet.
BT-GPS wird erkannt, blaue LEDs blicken ...
Usb-Gps aktiviert.
Nach ca. 45 sec bricht die BT-Verbindung ab! Die LEDs leuchten nur noch blau.
Nach weiteren ca. 30 sec stoppt UsbGPS.
Dann ist erstmal Ruhe (ca. 20-30 sec).
Nun beginnt der BT-Dongle wieder zu blicken!
Er findet den BT-GPS - Verbindung steht.
UsbGps gestartet ...
Abbruch nach ca. 45 sec.
Dann das gleich wieder von vorne.

Ging so die ganze Fahrt nach Hause.

Hier hab ich dann das gleiche nochmals versucht, allerdings mit dem Fortschritt, das die BT-Verbindung nun stabil hergestellt ist.
Nur UsbGps findet das Signal nicht mehr!
Irgendwas läuft hier noch falsch!

Hier mal der Auszug von dmesg, was bei mir beim einstecken des BT-Dongles erzeugt wird:

<6>[ 3681.983907] usb 2-1: new full speed USB device using usb20_host and address 34
<6>[ 3681.988300] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3682.183922] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3682.194461] usb 2-1: New USB device found, idVendor=0a5c, idProduct=4500
<6>[ 3682.198318] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
<6>[ 3682.205469] usb 2-1: Product: BCM2046B1
<6>[ 3682.209227] usb 2-1: Manufacturer: Broadcom
<6>[ 3682.216006] usb 2-1: configuration #1 chosen from 1 choice
<6>[ 3682.225402] hub 2-1:1.0: USB hub found
<6>[ 3682.226485] hub 2-1:1.0: 3 ports detected
<6>[ 3682.443916] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3682.524425] usb 2-1.1: new full speed USB device using usb20_host and address 35
<6>[ 3682.528986] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3682.633895] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3682.641990] usb 2-1.1: New USB device found, idVendor=0a5c, idProduct=4502
<6>[ 3682.646214] usb 2-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
<6>[ 3682.657142] usb 2-1.1: configuration #1 chosen from 1 choice
<6>[ 3682.678115] input: HID 0a5c:4502 as /devices/platform/usb20_host/usb2/2-1/2-1.1/2-1.1:1.0/input/input19
<6>[ 3682.717661] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3682.734299] generic-usb 0003:0A5C:4502.0011: input: USB HID v1.11 Keyboard [HID 0a5c:4502] on usb-usb20_host-1.1/input0
<6>[ 3682.944442] usb 2-1.2: new full speed USB device using usb20_host and address 36
<6>[ 3682.949021] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3683.083970] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3683.097991] usb 2-1.2: New USB device found, idVendor=0a5c, idProduct=4503
<6>[ 3683.102010] usb 2-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
<6>[ 3683.122745] usb 2-1.2: configuration #1 chosen from 1 choice
<6>[ 3683.141821] input: HID 0a5c:4503 as /devices/platform/usb20_host/usb2/2-1/2-1.2/2-1.2:1.0/input/input20
<6>[ 3683.167281] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3683.170165] generic-usb 0003:0A5C:4503.0012: input: USB HID v1.11 Mouse [HID 0a5c:4503] on usb-usb20_host-1.2/input0
<6>[ 3683.264407] usb 2-1.3: new full speed USB device using usb20_host and address 37
<6>[ 3683.268963] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3683.384009] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3683.395556] usb 2-1.3: New USB device found, idVendor=050d, idProduct=0017
<6>[ 3683.399582] usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
<6>[ 3683.420226] usb 2-1.3: Product: BLUETOOTH USB +EDR ADAPTER Class 1 v2.1 UHE
<6>[ 3683.426470] usb 2-1.3: Manufacturer: Broadcom Corp
<6>[ 3683.429108] usb 2-1.3: SerialNumber: 00190E06513A
<6>[ 3683.445428] usb 2-1.3: configuration #1 chosen from 1 choice
<6>[ 3683.484534] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<6>[ 3683.486835] DWC_OTG: dwc_otg_hcd_qh_init tt->hub null!
<4>[ 3683.516351] usb 2-1.1: input irq status -115 received
<4>[ 3683.524348] usb 2-1.1: input irq status -115 received

Hoffe das hilft uns weiter.

Wenn ich das BTGPS script verwende, klappt die Verbindung und Usb GPS behält auch die Verbindung

Ich denke das Problem liegt in der Warteschleife (45 sec) bis das Script wieder beendet wird, damit UsbGPS den Stream weiterverwenden kann.
Kann man eigentlich Apps direkt aus einem Script heraus starten?
Wenn ja, könnten wir doch aus dem Script heraus UsbGPS starten, verbinden und dann das Script beenden.

Klaus

 

[fluxflux]

Das Problem ist der richtige Augenblick zum Starten des UsbGPS. Versäume ich den, dann reagiert mein Sitecom (also der, der erst gar nicht ging) identisch mit deinem Belkin. 5 bis 6 maliger Start, keine Streamübernahme durch UsbGPS.

Starte ich UsbGPS (Voreinstellung der sleep-time auf 30 Sekunden) sobald der BT-Dongle und das BT-GPS verbinden (BT-GPS zeigt Bluetooth-LED dauernd, LED im BT-Dongle flackert ständig), klappt die Verbindung zuverlässig und wird auch nicht mehr beendet. Starte ich etwas zu spät, dann das Prozedere, das du auch hast, Schleife ohne Ergebnis.

Ich kenne keine Möglichkeit aus dem Skript heraus eine App zu starten ...

Zu deiner BT-Dongle-ID finde ich nur Bug-Meldungen von Ubuntu und Probleme mit hciconfig ...

Thomas.