Bluetooth?!?!

[Corelgott]

Hi @ all,

ich habe mal ne Frage: Ist irgendwer von euch schon mal auf ein bisschen Bluetooth-Programmiereung gestoßen?
Ich habe jetzt seit kurzen nen USB-Bluetooth-Dongle und dachte mir: "Da gibt's doch bestimmt schicke Software für!"

Pustekuchen!

Google selbst findet echt nur Schrott dazu... (Oder ich bin zu doof richtig zu suchen! :cyclops: )

Naja dann dachte ich mir: "Du it jur self" (Oder wie das auch heist... :gruebel:)

Aber leichter gesagt als getan! Irgendwie gibts dazu auch keinerlei Code! Weder in DElphi noch in Java! VB kann man da vermutlich eh knicken und C bzw. C++; Ja da bin ich zu doof zu...

Hat da wer ne helfende Idee?

thx Corelgott

PS.: Frohes Neues!
:party:
|
|
V
:kotz:

[Corelgott]

Hat keiner ne Idee?
Niemand ne Ahnung?

thx
Corelgott

[Luckie]

Warte mal auf Hagen, der könnte helfen.

[Corelgott]

Tja denn warte ich mal.....
wart...
wart.....
wart......
:|

[thomasdrewermann]

Also,
um dich endgültig zu enttäuschen antworte ich mal. Die meisten Blutooth-Dongles bz. von Acer, Tecom usw. werden mit einer Software Namens Widcomm betrieben. Je nachdem mit welchen Gerät diese ausgeliefert wird werden durch einen Lizenz-File die nutzbaren Profile beschränkt. Eigene Programme im Punkto Bluetooth beschränken siche meistens auf eine Serielle Schnittstelle. Sogar führende Handy-Suites arbeiten damit. Nokia beispielsweise. Hier wird per Hand ein Serieller Port auf das Handy gemappt. Am Handy ist dann der virtuelle COM1 mit einem virtuellen COM5 am PC verbunden. Über diesen COM-Port wird dann die Kommunikation abgewickelt.

Da Bluetooth nicht einfach ein Netzwerk ist kann man da wenig selbst programmieren. Bluetooth funktioniert halt über die verschiedenen Profile. Zum Beispiel den seriellen Bluetooth Port Dienst, Headset-Dienst, DFÜ-Dienst usw. diese sind einzeln nutzbar. Wie gesagt, die meisten Programme arbeiten mit der gemappt seriellen Schnittstelle.


MFG
thomas

[Corelgott]

Das heißt aber auch... (wenn ich das richtig verstehe)

dass, einen dann eher arbeit abegenommen wird...
(mehr oder weniger)
man nimmt sich dann einfach den gemappten Post und schickt dann über den Befehle...
Wenn mann jetzt Client-Seitig auch noch ein Programm hat, das diese Commandos versteht...

Oder mache ich da nen Denkfehler? Oder kann man den Port bzw. den "Kanal" dann nicht nach belieben nutzen?

thx für die Antwort..

Corelgott

[thomasdrewermann]

Ja genau richtig.
Im Prinzip kann man dann so verfahren, als ob man die COM-Ports zweier PCs direkt mit einem Kabel verbunden hätte.

Mit der Ausnahme, dass die Verbindung auf einem Virtuellen COM-Port also einem COM-Port ohne Hardware-Adresse und über den Bluetooth Adapter hergestellt wird.

MFG
Thomas

[Corelgott]

Gibt's dafür so ne art "do's and dont's" was die Port angeht? Alos angenommen, ich nehme den gleichen Port, den schon der OBEX benutzt...
Das solle man doch wohl eher lassen, da mein PDA mir das doch übel nehmen könnte? oder? Welchen Service "missbraucht" man für so was?
:roll: :gruebel:

Irgendwie ist mir das noch nicht so 100%ig geheuer...

Ach übrigens... Ein Com-Port ohne Hardware-Adresse? Schon klar versteh' ich auch warum aber...

Wie steuert man denn so was an? Ich kann mich bei so was nur immer an einen kleinen Fetzen Assambler-Code erinnern, der mir die Arbeit für so was abnahm (indem ich ihm einfach ein Byte gab...); Aber der Code brauchte eigentlich ne Adresse, an die er das Byte hinschieben sollte...
so was in der art wie $378 (obwohl das war wohl erher LPT1 oder?)

Also kurz und knapp Virtuelle-Com-Port? :gruebel:
:kotz:

Wie geht man denn damit um? :freak:

thx @ all
&
thomasdrewermann

Corelgott

[thomasdrewermann]

Hi,
also zuerst wollte ich nochmal klarstellen, dass alle innerhalb des Bluetooth ferfügbaren Betribsmodie also Headset OBEX-Filetransfare usw. jeder für sich eine Dienstart ist. Eine unter diesen Dienstarten ist halt der virtuelle COM-Port. Das schwierige daran ist, dass man diesem unter Windows nicht einfach mit diesem von dir schon angesprochenen simplen Assambler Code Befehle erteilen kann. Dieser Virutelle COM-Port ist nur über die Windows-API anzusprechen, was dir vieles auch noch viel einfacher machen wird. Dazu gibt es aber bei Torry massig Komponenten. Da musst du einfach mal suchen.

Mit diesen Kompnenten die auf der Windows-API basieren lassen sich bereits sehr einfach ganze Zeichenfoglen über die Serielle Schnittstelle übetragen. Schau einfach mal bei Google nach :-)

MFG
Thomas

[fkerber]

Hi!

Also ich habe mal ein Progrämmchen geschrieben, dass die Kommunikation mit von uns gebauten Robotern abwickelt.
Ich habe dabei normale Com-Port Komponenten verwdendet, da wir sowohl Bluetotth als auch Kabel verwenden und das funktioniuert wunderbar, ich kann den BLuetooth-Com-Port wie einen normalen Nutzen und Zeichenfolgen hinschicken bzw. empfangen.

Ciao fkerber

[negaH]

Am flexibelsten ist es wenn beide Bluetooth Geräte ein LAN Profil unterstützen. Hat man die Kontrolle zur freien Programmierung beider Geräte, also z.B. PocketPC an PC dann ist es nur eine Frage der Konfiguration der Geräte auf beiden Seiten. D.h. man entwickelt z.B. auf dem PC mit Delphi/INDY seinen TCP/IP Server. Auf dem PocketPC/Palm Handheld codiert man seinen TCP/IP Clienten. Nun müssen nur beide Geräte so konfiguriert werden das sie über Bluetooth ihre Verbindungen aufbauen. Es ist also von großem Vorteil sich nur einfach auf die TCP/IP Sockets zu stützen, und den ganzen Verbindungsaufbau über die im Gerät mitgelieferten Treiber machen zu lassen.

Als Beispiel hier mal ein derzeitig fertiggestelltes Projekt von mir.
Es ging dabei um die live Datensynchronisation zwichen PC-Server Datenbanken und PalmOS Handhelds. Auf PC Seite habe ich einen TCP/IP Server programmiert, mit Delphi und INDY. Effektiv hat das für den kleinen Testserver einen Tag gedauert. Auf PalmOS Seite wurde mit PocketStudio der TCP/IP Client programmiert. Das verwendetete Protokoll ist ein eigenes.

Zur Verbindung eines Palm Tungsten zum PC gegeben sich NUR durch umkonfiguration der Geräte folgende Übertragungswege:
1.) Palm an Ladeschale über Serielle Schnittstelle an PC mit SoftTick PPP Software ins LAN des Recheners zum eigenen TCP/IP Server.
2.) Palm an Ladeschale über USB Cardle an PC mit SoftTick PPP Software ins LAN zum Server.
3.) Palm über Infrarot IrDA an Laptop IrDA Port mit virtuellen COM Port Treiber an SoftTick PPP Softare ins LAN zum Server
4.) Palm über Bluetooth an PC Bluetooth Dongle mit WIDCOMM Software Treiber über Bluetooth LAN Access Treiber ins LAN an Server
5.) Palm über Bluetooth an PC Bluetooth Dongle mit WIDCOMM Software Treiber über virtuellen Bluetooth Seriellen Port an Softwick PP Sowftare ins LAN an Server
6.) Palm über Bluetooth an PC Bluetooth Dongle mit WIDCOMM Software Treiber über virtuellen Bluetooth Seriellen Port an Windows RAS ins LAN an Server
7.) Palm über Bluetooth an Siemens S55 Handy per GPRS/GSM Netz in Internet, über DynDNS.org dynamisch Namensauflösung der IP des PC über T-DSL Modem ins LAN zum Server. Sprich PC ist ein Server aus dem WEB erreichbar, und Palm verbindet wireless über Bluetooth an Handy ins Internet.
8.) Palm über serielles Kabel an Siemens S55 Handy per GPRS/GSM Netz in Internet und dann zum Server.

Alternativ zu den obigen LAN Zugriffen per IrDA/COM/Bluetooth ist es nun auch möglich das über dieses LAN eine Verbindung ins Internet/Intranet besteht über die auf Remote Server zugegriffen werden kann.

D.h. nutzt man von vornherein die TCP/IP Sockets der entsprechenden Geräte kann man über jeden erdenklichen Übertragungsweg eine Verbindung aufbauen. Dies wird vereinfacht wenn man auf beiden Geräten seinen eigenen TCP/IP Server und Clienten programmieren kann. Man muß dann nur noch die Übertragungswege auf den Geräten konfigurieren OHNE das man an der eigentlichen Software was umcodieren muß.

Alle obigen Möglichkeiten wurden von mir in meinem Projekt intensiv getestet und funktionierten einwandfrei.

Gruß Hagen

[Robert Marquardt]

Wahrscheinlich gibt es nur wenig Bluetooth API ueberhaupt.
Wenn erst mal ein Profil aktiv ist, dann laeuft es ueber das API das vom zugehoerigen Treiber geliefert wird.
Das ist bestimmt wie bei USB auch, nu ein bischen Verwaltungs-API.

[Corelgott]

Das ganze per LAN zu lösen ist ne echt gute idee!!

Ist auf alle fälle wesentlich einfacher, als das ganze per hand zu bauen!!!
Ich werde da mal ein wenig tumprobieren!!!

thx @ all!
Corelgott

[kaiser1401]

@negaH: Du hast geschrieben das du mit PocketStudio einen TCP client geschrieben hast. ich habe mir mal die Trial von PS 2 runtergeladen und würde soetwas auch gerne machen (ich will mit einem alten palm os 3.3 mein winamp bedienen und da es dazu leider keine gute fertige software gibt würd ich sie gern selber schreiben). Nur leider kann ich bis jetzt nirgendwo finden wie man eine solche verbindung mit PS basteln kann... :-(

[Robert Marquardt]

Das Windows Bluetooth API ist beim Modul win32api von http://jedi-apilib.sf.net mit dabei.

[negaH]

@kaiser1401:

PalmOS 3.3 ist ziemlich ungünstig ! Besser OS 4.2 oder 5.0 oder sogar 6.0.
Es geht mit PalmOS 3.3 aber die NetLib im PalmOS, gerade der älteren Versionen, hat gravierende Macken. Das ist zwar alles softwaretechnisch auszubügeln, mit vielen Tricks, und läuft dann auch aber es kostet ne Menge Schweiß. Ich habe dabei eine eigene Unit gecodet die mir die doch relativ simplen berkely Sockets des PalmOS komfortabler und auch lauffähig machen. Diese Unit umfasst so circa 400 Zeilen an Source und ist eine kommerzielle Entwicklung von mir. Ich kann sie also verkaufen und werde sie nicht verschenken, dazu steckt viel zu viel Arbeit drinnen.
Auf diese Basis Unit aufbauend habe ich dann noch einen FTP Clienten für den Palm gecodet, auch dieser wäre erhältlich. Allerdings kann ich nur empfehlen, wenn machbar, einen eigenen Clienten mit eigenem binärem TCP/IP Protokoll zu bauen. In diesem Moment hast du absolute Kontrolle über den Datenstrom, dessen zeitliches Auftreten, dessen Größe und strukturellem Aufbau. Als vergleich: um den FTP Client sauber zum laufen zu bekommen habe ich 8 Wochen dran gearbeitet. Danach traten aber immer noch Schwierigkeiten auf Serverseite auf um per FTP ein passables "Protokoll" hinzubekommen. Danach haben wir uns umentschieden (das was ich von Anfang an prophezeit hatte ;) ) und ein eigenes TCP/IP Protokoll mit Verschlüsselung, Autentifikation, Client und Server TCp/IP Software, TCP/IP Server als Dienst, in 3 Wochen fertig programmiert.

Besonders wenn du über die Anbindung von Handies, sprich GSM/GPRS nachdenkst, ist das Datenaufkommen und dessen zeitliches versenden enorm wichtig. GSM/GPRS ist ein dynamisches Protokoll und untersützt die dynamische Aufteilung der verfügbaren Bandbreite im Funktnetz auf alle Teilnehmer in der gleichem Funkzelle. D.h. alle Teilnehmer in der Zelle teilen sich die verfügbare Bandbreite. Also auch wenn behauptet wird das mit GSM/GPRS die 64KBit möglich wären so ist dies tatsächlich eher ein Werbeversprechen und nicht Realität. Das Problem ? GSM/GPRS arbeitet immer dann schnell wenn man größere Datenmengen in einem Rutsch hin&her sendet und dabei nur sehr wenig das "Hin&Her". Dh. am besten ist es mit wenigen Protokollschritten auszukommen, statt mit vielen kleinen Packeten die öfters zwischen Client&Server ausgetauscht werden. Das kann bei zb. 16Kb an Daten die zb. in 4 Packeten hin&her gesendet werden im Vergleich zur selben Datenmenge die aber in 16 Packeten hin&her gesendet wird, einen Unterschied von Minuten in der Gesamtzeit ausmachen !!!

Aus Erfahrung kann ich dir versichern das aber ab OS 3.3 eine Kommunikation über Sockets stabil machbar ist. Besser ist es aber wirklich erst mit PalmOS 4.3 (gepatchte inoffizielle Version) anzufangen.

DEMOs für PS 2.0 sollten eigentlich dabei sein. Zb.

\programm\winsoft\pocketstudio2\demos\HTTP\ oder ..\net\ oder ..\ping\ oder ...\SendMail\ oder ...\SendSMS\.
Am besten ist das ...\net\ Example.

Diese sind zwar recht "primitiv" gehalten und berücksichtigen bei weitem nicht alle Features, funktioneren aber.
Als DEV Plattform lädst du dir den Simulator oder den Emulator. Der Emulator sollte für OS3.3 die bessere Wahl sein. Aber Vorsicht! beide Windows-Sim/Emulatoren simmulieren die NetLib Funktionalität des PalmOS nicht, sondern nutzen reines Windows API. Du musst also auch auf deinem Palm testen.

Gruß Hagen

PS: auf Windows-Server-Seite kann ich dir nur die INDY Komponenten empfehlen, damit hast du nach par Stunden schon deinen Server fertig. Mit ein bischen, wirklich nur ein bischen, mehr Aufwand kannst du diesen dann zu einem Service umbauen.

PPS: das Bluetooth API, egal ob Palm oder Windows oder PocketPC (.NET) ist im Gegensatz dazu echt komplizierter ! Wenn du es über die TCP/IP Sockets vermeiden kannst das zu benutzen dann tue es auch. Davon abgesehen, jetzt wo ZigBee an der Tür klopft würde ich keinen Cent in Bluetooth investieren.


PPPS: und ich meine das es schon eine fertige PalmOS Anwendung im Netz gibt die exakt das macht was du vorhast. Ansonsten gibts sogar einen VNC Client für PalmOS mit dem du deinen Windows Rechner bedienen kannst.

[kaiser1401]

Danke, werd mir das mal anschauen.

Mit Bluetooth hatte ich eigentlich nciths vor. ist nur in diesem Topic gelandet weil ich sonst fast ncihts zu PocketStudio gefunden habe und auch nciht direkt wusste wo ich einen neuen topic dazu hätte aufmachen sollen....

Der Grund warum ich das mit OS 3.3 mache ist vor allem der, das ich 2 palms damit rumfliegen habe und ich mir nciht noch einen anschaffen möchte. zumindest nicht um diesen dann zu zerstückeln und umzubauen.

Die fertigen Palm fernbedienungen für Winamp haben irgendwie alle nicht das was ich möchte beziehungsweise benötigen OS 3.5 oder höher. VNC hab ich auch schon mal versucht, ist aber sehr langsam und für diesen zweck nicht wirklich geeignet finde ich.

Ich werd gleich mal schauen ob ich die Beispiele finde und vor allem daraus schlau werde. Windows seite hatte ich auch mit Indy vor, da hab ich sonst auch schon was mit gemacht, sollte also klappen. *hoff*

Ansonsten schon mal vielen Dank für deine Erläuterungen.

Gruß Kaiser

[negaH]

Stop!! alles zurück, PalmOS 3.5 is required ! Vergiß PalmOS 3.3. das ist ja noch älter als uralt. Ich bin mir jetzt garnicht sicher ob das überhaupt schon eine NetLib besitzt. In meinem obigen Posting bezog ich mich nämlich auch auf PalmOS 3.5 statt 3.3 sorry. Alle meine Palm Anwendungen mit TCP/IP Anbindung laufen erst ab 3.5.

Am besten du stellt die beiden Teile, schön gereinigt mit ansprechendnen Bildern und dem Titel "sehr seltene und alte Palms für Sammler" in die größte deutsche Erfindung der Nachkriegszeit als Auktion rein. Meistens haben solche Uralt Teile einen höheren Wert als derzeitige Auslaufmodelle ;) Das ist auch der Grund warum ich meinen PalmPilot mit OS 1.2 und meinen PalmIIIc der erste Farbdisplay Palm niemals nicht weggeben werde ;)

Aber zum Programmieren sind die ungeeignet, bzw. würd ich mir das nicht nochmal antuen wollen ! Wenn du also zwei davon hast könntest du unter Umständen mit ihrem Verkauf ein gutes und aktuelles Auslaufmodell ersteigern.

Gruß Hagen

PS: welche Modell sind es denn ? Treo vielleicht ?

[kaiser1401]

Also für 3.3 gibt es auch eine NetLib oder zumindest so etwas ähnliches zum Nachinstallieren (kann grad nicht nachschauen ob es wirklich netlib ist). Damit kann man dann auch über tcp/ip kommunizieren. hat zumindest mit anderen anwendungen dann geklappt. Der eine ist ein IBM Workpad (quasi palm III) und das andere ist noch älter, hab es leider gerade nicht zur hand, aber da ist dieses 2MB "Upgrade"-Kit reingekommen mit dem man dan auch IR hat. Dürfte in der Grundkonfiguratiion schon ziemlich alt sein denk ich. (Auch weil der noch so richtig schön eckig ist)