Guten Tag Ich möchte eine selbstgebaute Hardware (mit PIC Controller) mit einer Universal Windows App über Bluetooth ansteuern. Ich habe viele Beispiele und NuGets für C# unter Visual Studio ausprobiert. Leider bisher ohne Erfolg. Unter anderem fehlt mir wahrscheinlich die Erfahrung. Das vielversprechendste scheint mir die RFCOMM library zu sein, hat damit schon jemand Erfahrungen gemacht? Auch habe ich es beispielsweise mit dem NuGet BluetoothManager von Rob Miles probiert. Ebenfalls ohne Erfolg. Die Hardware funktioniert. Denn die Kommunikation über ein PuTTy-Terminal klappt ohne Probleme. Schlussendlich soll ich mich verbinden und einzelne Characters oder Strings schicken können. Vielen Dank bereits im Voraus für eure Hilfe! Ich bin für jeden Tipp dankbar :)
Gut ich arbeite viel mit C++ unter Qt und würde es dann dort mit dem Bluetooth Modul probieren. http://doc.qt.io/qt-5/bluetooth-examples.html
Bluetooth unter Windos ist, schlicht gesagt, zum kotzen. Kleines Beispiel: Qt hat ein Beispielprojekt (Heartrate Service) , mit dem man sich den Herzschlag von einem Brustgurt holen und anzeigen lassen kann. Das funktioniert unter Linux total super, nur unter Windows nicht. Zum Glueck bietet Visual Studio auch viele Beispiele. Wenn man da sucht, gibt es auch unter VS ein Beispielprojekt fuer einen Heartrate Service (in C#, C++, JavaScript, etc). Der Unterschied zwischen Linux und Windows an dieser stelle: Linux: Anwendung starten, die Anwendung pairt sich mit dem Brustgurt und alles ist schoen. Windows: Man muss erst in die Systemsteuerung, um Windows mit dem Brustgurt zu pairen, und erst dann kann das VS-Beispiel sich mit dem Brustgurt verbinden. Das Qt-Beispiel funktioniert nicht! Das liegt aber nicht an Qt sondern an M$. Unter Windows kann man sich nicht direkt aus dem Programm mit dem Device verbinden, man muss immer den manuellen weg ueber die Systemsteuerung gehen.
Kaj schrieb: > Unter Windows kann man sich nicht direkt aus dem Programm mit dem > Device verbinden, man muss immer den manuellen weg ueber die > Systemsteuerung gehen. Das hängt vom Bluetooth-Stack ab. Mit dem Microsoft Stack geht das über die BluetoothAuthenticateDevice*()-Funktionen. Mit anderen Stacks geht es meist auch, da könnte man schauen wie es hier gelöst wurde: https://32feet.codeplex.com/wikipage?title=Bluetooth%20Security&referringTitle=Documentation Für UWP-Apps gibt es hier Beispielcode: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/DeviceEnumerationAndPairing
bluppdidupp schrieb: > Das hängt vom Bluetooth-Stack ab. > Mit dem Microsoft Stack geht das über die > BluetoothAuthenticateDevice*()-Funktionen. Interessant... und warum nutzt Microsoft dass dann (offenbar) nicht in seinen eigenen Beispiel-Anwendungen?
Kaj schrieb: > Unter Windows kann man sich nicht direkt aus dem Programm mit dem > Device verbinden, man muss immer den manuellen weg ueber die > Systemsteuerung gehen. man könnte das auch als Sicherheitsfeature bezeichnen.
Kaj schrieb: > Interessant... und warum nutzt Microsoft dass dann (offenbar) nicht in > seinen eigenen Beispiel-Anwendungen? Weil das nur für Bluetooth Classic funktioniert und das o.g. Beispiel für Low Energy war?
> Weil das nur für Bluetooth Classic funktioniert und das o.g. Beispiel > für Low Energy war? Richtig. Ihr muesst das unterscheiden! Beides hat nichts miteinander zutun. Bei BLE liefert die QT Klasse zum scannen der Devices unter Windows eine Fehlermeldung zurueck die besagt das diese Funktion bei Windows8.1 nicht implementiert ist. (und bei 7 sowieso nicht) Olaf
Die Native-API (die die meisten Libs verwenden) kann BLE glaube ich überhaupt nicht, dazu muss vermutlich UWP verwendet werden. Ich hab weder ein BLE-Device noch BLE-fähigen PC-Adapter zur Hand und kanns nicht testen, aber zumindest Geräte mit 2.x-er BT-Version laufen bei mir auch noch in UWP.
Also zunächst mal wäre es natürlich interessant was du PIC seitig tust und wie du dir da sicher bist, dass es klappt. Du schreibst es funktioniert mit PuTTY, meinst du da zufällig USART? Es ist so: Bluetooth ist immer ein bisschen knifflig, ich hatte selbst unter Debian (Gut, das war ein Raspi mit USB-Bluetooth Dongle und dann auch noch Python) ein paar Problemchen, aber das lag zunächst auch an meinem Verständnis von Bluetooth. RFCOMM z.B. ist eigentlich keine Library (es sei denn, es gibt auch eine Library diesen namens), sondern eine Art Protokoll, mit dem zugehörigen Serial Port Profile. Bluetooth spezifiziert genaue Gerätetypen und Funktionalitäten, d.h. meistens sendest du nicht einfach Daten auf Low-Level Ebene sondern nutzt ein passendes Profile. Da gäbe es jetzt natürlich diese ganzen Freisprecheinrichtung-Dinger, aber da du ja keinen Sound möchtest, nutzt du das Serial Port Profile. Was auch noch wichtig ist: Bluetooth funktioniert "in etwa" wie TCP/IP: Du hast eine MAC Adresse (TCP: IP-Adresse) und einen Channel (TCP: Port). Wichtig ist, dass du zunächst die Device Services scannst um herauszufinden auf welchem Channel denn überhaupt RFCOMM angeboten wird. Um in der Analogie weiter zu machen: Am Port muss natürlich ein Server laufen, d.h. du musst deinen PIC in den "RFCOMM-Server-Modus" schicken, denn nur dann akzeptiert er die Verbindung vom PC. Da gibt es natürlich auch die Möglichkeit den PC als RFCOMM Server laufen zu lassen und dein PIC scannt ständig nach verfügbaren PCs und verbindet sich (So kannst du z.B. verhindern, dass ein fremder sich zum PIC verbindet). Der Nachteil hierbei ist, dass es auf Android schier unmöglich ist, einen RFCOMM Server hinzubekommen. Ich habe es versucht, und wenn es mal klappte, dann brach die Verbindung recht schnell zusammen. Damit wären wir auch beim Ultimativen Tipp: Es gibt zig Bluetooth Serial Consoles für Android, mit denen du dich zu deinem PIC verbinden kannst, um ihn als Fehlerquelle auszuschließen. Ein paar die ich für meine Tests hatte: "BlueTerm, Bluetooth Console, BlueTooth Serial Conne(..), Bluetooth Terminal". Ich weiß aber nicht mehr, welches gut war :P Für's iPhone mags das auch geben aber ich meine mal gelesen zu haben, dass die RFComm irgendwie erschweren bzw. eben nur den Headset Modus möchten. RFCOMM funktioniert dann wie eine Serielle Konsole, also USART. Ich bin jetzt hier nicht auf das Pairing eingegangen, aber das macht Windows ja offenbar via System schon, also liegt es außerhalb deiner Software. PS: Du schreibst du hattest kein Erfolg, sagst aber nicht genau WO das Problem lag, das ist natürlich schlecht^^ Konntest du pairen und lediglich nicht connecten?
Hallo erstmal Danke für die Antworten und Tipps! Inzwischen konnte ich das Problem lösen. Stimmt, ich habs vielleicht etwas ungenau beschrieben. Also ich steuere mit meinem PIC ein RN42 Bluetooth Module an. Ich konnte das Modul mit meinem PC koppeln und dann mit PuTTY über den entsprechenden COMx (siehe Gerätemanager rechtsklick aufs verbundene Bluetooth Module) den PIC ansteuern. Noch zu meiner Lösung: Ich benutze nun bei meiner Universal Windows App das NuGet "BluetoothManager" ( http://www.robmiles.com/bluetooth-manager/ ). Das Beispiel auf dieser Internetseite funktioniert gut. Jedoch muss man zusätzlich im File "Package.appmanifest" das Bluetooth freischalten mit folgenden Zeilen: <Capabilities> <DeviceCapability Name="bluetooth.rfcomm"> <Device Id="any"> <Function Type="serviceId:00001101-0000-1000-8000-00805F9B34FB"/> </Device> </DeviceCapability> </Capabilities> Dabei war mein Fehler am Anfang, dass ich die falsche serviceId benutzt habe. Die einfachen Fehler sucht man doch immer am längsten ;-) Nun funktioniert alles einwandfrei. Ich kann mich direkt in der App mit meinem Device koppeln und Commands senden. Das Empfangen muss ich jedoch noch testen. :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.