Forum: Mikrocontroller und Digitale Elektronik Bluetoothmodul BTM-222

Hallo Thomas,

AT-Befehle sendest du über den UART. Wenn das Modul eine 
Bluetooth-Verbindung aufgebaut hat, kannst du keine Befehle mehr an das 
Modul schicken, alle Zeichen werden per Bluetooth versendet.

Ich arbeite momentan an einer Library, die ich aber noch nicht ganz 
fertig habe. Kommt aber in Kürze.

Zum Anfang solltest du das Modul am einfachsten an den PC anschließen 
und mit Hyper-Terminal Zeichen versenden. Zunächst solltest du ein 
"ATD0" senden, um dem Modul zu sagen, dass alle PCs eine Verbindung mit 
ihm aufbauen dürfen. Standardmäßig ist irgendeine komische ID 
eingestellt. Wenn du jetzt nach dem Bluetooth-Modul suchst, den 
Hauptschlüssel austauscht (Standard ist "0000" oder "1234", ich weiß es 
nicht mehr.) und die Verbindung aufbaust, sendet das Modul noch ein 
"CONNECT" und reicht dann alle Daten transparent durch. Beendest du die 
Verbindung, kommt ein "DISCONNECT" und du kannst wieder AT-Befehle 
senden.

Gruß
Christoph

Nein. Ich habe zunächst auch alles außer den Versorgungspins, der 
Antenne sowie RX und TX freigelassen.

Einfach ein Stück Draht oder Litze dranlöten, Länge Lamda/4 (also etwa 
31mm für Bluetooth (2,45GHz)).

Kurzer Nachtrag: Sehr schöne Chip-Antennen gibt es bei Farnell, sind nur 
2x3mm² groß, aber leider auch 3€ teuer.

Ja, einfach den UART anschließen. Flußkontrolle brauchst du nicht.

Allerdings solltest du beim Senden von AT-Befehlen nach jedem Zeichen 
warten, bis dieses vom Modul zurückgesendet wurde.

Ansonsten, einfach mal probieren, kaputt machen kann man eigentlich 
nichts.

Du brauchst kein Programm. Einfach einmal ein ATD0 per Hyperterminal, 
etc. senden um Verbindungen von allen PCs zuzulassen, 
Bluetooth-Verbindung am PC, PDA, was weiß ich, einrichten mit dem Modul 
und du kannst senden.

Die AT-Zeile muß mit 0x0D (CR) abgeschlossen werden. Außerdem muß 
hintereinander weg geschrieben werden, ohne auf ein Echo zu warten.
Also ATI1<CR> zum Beispiel.

Versuche mal, einfach AT<CR> zu geben, es müßte dann OK<CR><LF> 
zurückkommen. Oder ob ATI1 (aaa tee iii eins) funktioniert, da sollte 
das Modul seine Einstellungen ausspuken. Warten auf jedes Echo führt zu 
ERROR<CR><LF> im Termianalfenster.

PS: Die spitzen Klammern bitte nicht mitsenden, die sind nur zur 
Trennung von Text und Steuerzeichen.

Im Moment hast du eher schlechte Karten:

Deine Probleme:
Du weist nicht ob das BM Modul funktioniert
Du weist nicht ob die UART am Mega16 funktioniert
Du weist nich ob dein Programm funktioniert
Du weist nicht ob dein Kabel richtig ist

Das sind zuviele Unbekannte.
Ich würde mal mit allem Nachdruck versuchen einen
Rechner aufzutreiben, der noch eine Serielle Schnittstelle
hat. Damit kannst du das Kabel testen, das BM Modul mit
Hyperterminal testen, die UART vom Mega16 testen.
Also so ziemlich jede Einzelkomponente, die dir ein
Problem bescheren könnte.
Erst wenn jede Komponente für sich einzeln begutachtet,
bzw. korrigiert wurde, müsste dann ein Zusammenschluß
von Mega16 und BM Modul auf Anhieb funktionieren.

Hab damit keine Erfahrung, aber ein USB nach RS232 Umsetzter
müsste da eigentlich schon eine enorme Erleichterung sein.

Boris wrote:
> So schlimm isses garnicht!
>
> Das das BM Modul funktioniert wei- ich, weil ich es mit meinem PDA
> finde, pairen kann und auch dessen Services auflisten kann. Nur bei der
> Seriellen Kommunikation sperrt sich das Modul dann, vermutlich aufgrund
> der noch fehlenden Initialisierung.

Wenn ich die Vorgängerpostings durchlese: Das Ding braucht
keine Initialisierung. Die UART funktioniert sofort nach dem
Einschalten.

>
> Das das USART funktioniert sehe ich ja an den LEDs, die ich
> angeschlossen hab. Wenn ich zeichen sende, blinkt diese ja. Scheint also
> auch OK zu sein.

Aber du siehst nicht ob die Baudrate stimmt. Ob sie grundsätzlich
falsch ist, oder ob du nur knapp daneben liegst. Ein PC mit
Hyperterminal könnte dir das sofort sagen.

> Dem ents[prechend gehe ich auch mal davon aus, dass mein Programm
> funktioniert...

Na ja. Wenn doch alles funktioniert, woran hapert es dann :-)
(Hinweis: Die UART des BM Moduls ist es sicherlich nicht)

Systematisch vorgehen. Mit wildem Herumprobieren löst man
Probleme höchstens zufällig. Eine Komponente nach der anderen
als Fehlerquelle ausschliessen führt mit 100% Sicherheit
zum Erfolg. Stelle grundsätzlich alles solange in Frage, bis
du nachweisen kannst, dass es funktioniert.

Boris wrote:
> "Stelle grundsätzlich alles solange in Frage, bis
> du nachweisen kannst, dass es funktioniert."
>
> Hehe, das werd ich dann wohl tun ;-)
>
>
> "Wenn ich die Vorgängerpostings durchlese: Das Ding braucht
> keine Initialisierung. Die UART funktioniert sofort nach dem
> Einschalten."
>
> In einem anderen Thread hatte man mir erklärt, man müsse zunächst ein
> ATD0 senden,

Wie sendest du denn ein ATD0 wenn die UART im Modul nicht
funktioniert?

Du musst unterscheiden zwischen:
'Die UART funktioniert grundsätzlich und das Teil nimmt
Kommandos an und führt sie aus'
und
'Das Modul ist so konfiguriert, dass es tatsächlich sendet'

Die UART wird schon funktionieren, daher wäre es auch so wichtig
das Teil mal an eine nachweislich funktionierende Serielle
zu hängen um zu sehen, was alles gemacht werden muss, damit
das Teil aus dem Idle Zustand in den Übertragungszustand geht.

Aber im Moment weist du ja noch nicht, ob das BM-Modul überhaupt
irgendetwas versteht. Das wird nicht am BM-Modul liegen sondern
an deiner Sendeeinheit.

Mal ´ne ganz dumme Frage an Boris: Mit welcher Spannung läuft Dein BTM 
und mit welcher der Controller?

Hmm.
Ist das eigentlich eine TTL UART?

In einer der ersten Postings wird gesagt, das Modul an den
PC anzuschliessen. Da hier kein Umsetzer erwähnt ist, gehe
ich mal davon aus, dass es sich um keine TTL-Uart handelt.

Daher die Frage: Du hast doch auf dem Controller einen MAX232
drauf, oder nicht? Die Tx/Rx Leitungen vom Controller direkt
mit dem Modul zu verbinden wird nicht funktionieren, weil die
Pegel genau falsch herum sind.

Kann allerdings auch sein, dass ich hier falsch liege. Allerdings
ist im Datenblatt nicht explizite von einer TTL UART die Rede.

Wenn Dein BTM jetzt noch nicht kaputt ist, haste Glück gehabt. Das BTM 
liefert und erwartet Pegel auf 3.0-3.7V, entsprechend seiner 
Speisespannung. Es müssen also Pegelwandler her, sonst wird über die 
UART die gesamte Betriebsspannung des Moduls hochgezogen. Für Modul RX 
reicht ein Spannungsteiler, für Modul TX nach Controller RX muß ein 
echter Pegelwandler aus pnp-npn Transistorpaar oder mittels passendem IC 
realisiert werden. Deshalb bekommt Dein Controller auch nichts zurück, 
der Pegel für logisch High reicht nicht.

Das kannst Du auch machen, allerdings hast Du vom Controller her dann 
eine Geschwindigkeitsbegrenzung auf 8Mhz - wenn Dir das für Dein Projekt 
reicht, dann ist´s okay. Bei meiner Anwendung in einem komplexeren Gerät 
bin ich auf volle 5V am Controller angewiesen.

Das ist jetzt aber ausgesprochen blöd...

Hast du bei dem Modul mindestens einmal ein ATD0 gesendet? Das Modul 
akzeptiert sonst nur Verbindungen von einem ganz bestimmten Rechner. 
Ansonsten kann das Modul keine wirkliche Verbindung aufbauen, was sich 
darin äußert, dass du den COM-Port am PC oder PDA zwar siehst, ihn aber 
nicht öffnen kannst.

Ansonsten wenn du dem Modul irgendeinen Mist sendest, muss es mit ERROR 
antworten. Wenn das nicht klappt, stimmt irgendwas mit deinem Aufbau 
noch nicht.

Mein Modul zum Beispiel akzeptiert ATD0 gar nicht. Trotzdem kann ich mit 
jedem Rechner darauf zugreifen. Bin aber in Verbindung mit dem 
Hersteller, um die letzten Fragen zu klären.

Meine drei Module schon... Komisch. Ohne den Befehl funktionieren sie 
auch nciht. Aber der Hersteller ist eigentlich recht hilfsbereit.

Stimmt. Ich arbeite derzeit mit dem BTM112, was absolut wunderbar sendet 
und empfängt, sich aber nicht konfigurieren läßt. Die Verbindung zum 
UART steht aber - hmm...

1

  UBRRH = (unsigned char)(baud>>8);

2

  UBRRL = (unsigned char)baud;

Ne, das ist jetzt wirklich nicht dein Ernst?

Und das hier erst:

1

  USART_Transmit('0x0D');

Boris wrote:
> Hö? Was ist denn das Problem mit den beiden Zeilen? Die habe ich 1 zu 1
> aus dem Datenblatt des ATMega16 übernommen....

guckstu, eh?
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#UART_initialisieren

Sehr schön! ;)

Pegelwandler! Ich sach nur Pegelwandler. Dann geht auch das LCD wieder. 
Toll, daß das BTM jetzt antwortet.

Funktioniert bei euch das ATH? Kommando ? Ich habe das BTM-112 Modul und 
im Slave Modus ohne bestehende Verbindung zieht das Teil 44mA. Besteht 
dann eine Verbindung man sendet aber nichts so reduziert sich der 
Stromverbrauch auf 3mA. Nun dachte ich das ich über ATH0 den 
Discovery-Modus des Moduls beeinflussen kann. Ansonsten funktioniert 
alles, also Master/Slave, Verbindungsaufbau etc.pp. Nur eben der 
Stromverbrauch stört noch.

Gruß Hagen

Boris, nix für ungut, aber ich habe Dir ein Stück weiter oben schon 
gesagt, wie es geht. Nochmal zum Mitschreiben: RX am Modul bekommt einen 
Widerstand 3.3k nach Masse. Mit 1.8k schließt Du RX Modul an TX 
Controller an. Modul TX geht über einen Widerstand 3.3k auf einen BC557 
(BC857) dessen Emitter an 3.3V von der Modulversorgung angeschlossen 
wird. Der Kollektor geht dann auf einen weiteren Widerstand 3.3k auf die 
Basis eines BC547 (BC847), dessen Emitter auf Masse liegt. Der Kollektor 
geht an RX vom Controller und an einen Widerstand 3.3k nach +5V der 
Versorgung des Controllers. Zwischen Emitter und Basis beider 
Transistoren kommen noch einmal je 1k, die die Transistoren schneller 
schalten lassen.

Ein 7805 ist kein Pegelwandler, sondern ein Festspannungsregler.

Für das Modul brauchst Du noch einen Festspannungsregler 3.3V und für 
den Controller dann halt einen für 5V.

Bei mir gehen keine AT-commands außer ATI0 und ATI1 und AT, ansonsten 
bekomme ich immer ein ERROR zurück. Die Stromaufnahme ist um 35mA ohne 
bestehende Verbindung und etwa 5mA bei bestehender Verbindung ohne 
Datenaustausch.

Boris wrote:
> ^^ Immer dieser Pegelwandler! Hast du mal einen konkreten Namen für
> mich?
> Meinst du vielleicht sowas wie einen 7805? Die scheint es aber leider
> nur für 5 und 8V zu geben (zumindest auf den ersten Reichelt-Blick), und
> sind relativ klobig...

Nein, die Signalpegel müssen angepasst werden. Entweder du betreibst 
deinen Atmega und das LCD mit 5V und wandelst die Signale zum BT-Modul 
oder du baust einen Pegelwandler zwischen Atmega (der dann mit 3,3V 
läuft) und dem LCD ein.

Beispiele zur Realisierung gibt es unter "Pegelwandler" in der 
Codesammlung.

ATI0 und ATI1, diese Kommandos sind garnicht im Datenblatt beschrieben ? 
Wie kommst du auf diese Kommandos ?

Übrigens ATX0,ATX1,ATC0,ATC1 sind ebenfalls nicht im datenblatt. Mit ATC 
schaltet man das Hardwareflowcontrol ein/aus.

Gruß Hagen

Ich habe die Kommandos vom Service zugeschickt bekommen.

Hi TravelRec,

könntest du mir diese Kommandos bitte mailen ?

Gruß Hagen

Yep. Das ist die Beschreibung für ein Dongle, soll aber auch für die 
einzelnen Module zutreffen.

So, ich bin´s nochmal. Mein Problem hat sich gerade erledigt. Es bestand 
darin, daß ich die Daten als String an das Modul versendet hatte. Nun 
verhält es sich tatsächlich aber so, daß das Teil jedes Zeichen erst 
einmal als Echo zurücksenden will, bevor ein neues Zeichen akzeptiert 
wird. Man muß also, wie weiter oben schon einmal bemerkt wurde, erst im 
UART-Receive-Register des Controllers nachschauen, ob das gerade 
versendete Byte wieder angekommen ist, dann darf man weitersenden. Das 
komplette Commando muß mit dem Steuerzeichen 0x0D (ENTER) abgeschlossen 
werden. Ist alles vom Modul verstanden worden, sendet es 0x0D 0x0A 'O' 
'K' 0x0D 0x0A zurück. Bei einer Anfrage an das Modul werden zwischen die 
Steuerzeichen 0x0D 0x0A noch Datenbytes eingeschoben. Also dann mal viel 
Glück beim Proggen :-)

Auf alle Fälle: Her damit ;-) ! Geht Dein Modul jetzt so richtig?

@Travel Rec.

danke für das Datenblatt, das klärt so einige Punkte dir mir unklar 
waren. Bisher habe ich so fast jede Funktion mal durchgetestet und dabei 
sind so par Fallstricke aufgekommen, ich rede über das BTM-112

1.) Erst nach langer Suche fand ich ein Terminalprogram das richtig 
arbeitet. Für den Anfang sollte man mit HyperTerminal das Modul per PC 
ansprechen. Dann dort sofort ATE0, also Echos aus, ausführen. Danach 
kann man auch mit normalen Programmen arbeiten die per Buffer asynchron 
den RS232 Sende/Empfangsroutinen arbeiten.

2.) Im Datenblatt des BTM-112 an PIO(7) eine LED nach Masse schalten, 
Vorwiderstand. Das ist die Link-Status-LED die anzeigt wann das Modul 
einen Discovery, Pairing, Inquiry Status hat. Im Discovery Modus zieht 
das Modul den meisten Strom. Ist man einmal verbunden so sinkt der Strom 
auf 3mA wenn keine Daten übertragen werden.

3.) Im Datenblatt an PIO(6) ist falsch. Der korrekte Pin ist PIO(5) 
ebenfalls LED nach Masse. Diese LED leuchtet auf wenn Daten übertragen 
werden, also nach einem Verbindungsaufbau.

4.) mit ATX1 die +++ Sequenz zum Wechseln aus dem DATA ind den COMAND 
Mode aktivieren.

5.) Geht man mit ATR0 in den Master Modus sollte man erstmal ATO1 
ausführen. Danach ein ATF? um die in Reichweite befindlichen Module zu 
finden. Man muß aber einige Zewit warten bis dieser Suchvorgang fertig 
ist. Danach kann man mit ATA1 bis ATA8 eines der Module verbinden. Mit 
+++ kommt man aus der bestehenden Daten-Verbindung wieder in den 
Kommandomodus. Man kann nun mit ATH die aktuelle verbindung trennen.
Gibt man jetzt mit ATD=xxxxxxxxxxx eine feste Geräte ID vor und wechselt 
mit ATO0 in den automatischen Verbindungsmodus so connected das Modul 
nun immer automatisch mit der Gegenstelle. Das kann man testen indem man 
auf dem PC den Bluetooth Serial Port trennt, das Modul baut sofort 
wieder die Verbindung auf.

6.) mit ATZ kann man 2 Konfigurationen laden. ATZ0 offiziell und ATZ1 
gibts eine zweite Konfiguration. Die ist im Grunde identisch mit der 
Ausnahme das die Baudrate auf 9600 Baud eingestellt ist. Darauf bin ich 
beim Testen herein gefallen und dachte schon das mein Modul kaput 
konfiguriert ist. Musste aber nur die Baudrate auf 9600 Baud einstellen 
;)

Getestet habe ich das Teil im Master/Slave Modus mit meinem PC, Palm 
Thungsten T und Siemens Handy. Beim Handy konnte ich mit den Siemens AT 
Befehlen das Handy steueren ;)

Gruß Hagen

Danke für die Infos Hagen, ich denke mal, das BTM112 haben wir jetzt im 
Griff :-) Gute Nacht dann mal. Heute ist wieder Arbeit.

Nö, keine anderen Pins. Aber Heißkleber? Naja. Ich habe das Modul für 
Tests auf ein Stück Lochrasterplatine gelötet, mittels Fädeldraht an 
Stiftleisten. Auf der Platine sind dann auch die Pegelwandler und 2 
LEDs, damit ich sehe, was das Teil macht. So kann ich es jederzeit mit 
einem anderen Controller verheiraten ;-)

GND,V3.3,RX,TX,Antenne reichen, eventuell noch die Link-LED per 330Ohm 
nach Masse anschließen. Beim BTM112 ist das PIO(7). Im Attachment von 
TravelRec. findest du die Bedeutung der Leuchtphasen dieser LED.

Wie kann man das Modul in die Energiesparmodis versetzen ? 44mA 
Stromverbrauch im nicht verbundenen Suchmodus sind mir zuviel, das Modul 
versucht ja dann ständig verfügbar zu sein. Besser wäre es aber wenn das 
Inquiry nur für par Sekunden alle par Minuten steuerbar wäre.

Gruß Hagen

Nochwas ist mir aufgefallen. Das Modul scheint wohl nur einen 2 Bytes 
großen Empfangspuffer zu haben und benötigt dann einige Zeit diese 2 
Bytes per Commandinterpreter abzuarbeiten. Das bedeutet das man nicht 
wie üblich mal eben einen Befehl wie ATI1<CR> am Stück raussenden kann. 
Das Modul verschluckt sich dann, bzw. bekommt einen UART Receive 
Overflow. Die Software die das AT Protokoll im Modul erledigt scheint 
also ziemlich schlecht zu sein, sie arbeitet die empfangenen Bytes 
direkt per Statemaschine ab und produziert somit Verzögerungen im 
Kommunikationsfluß. Normalerweise würde man per Interrupts arbeiten, und 
im Hintergrund einen Empfangsbuffer befüllen. Also wenn man 
programmieren kann. Nun das erklärt warum alle meine besseren 
Terminalprogramme auf dem PC das Modul eben nicht sauber ansprechen 
können. Windows Hyperterminal wiederum sendet sofort das eingegebene 
Zeichen über den UART, und das Modul hat somit ausreichend Zeit die 
empfangenen Bytes live abzuarbeiten. Ich möchte nicht über die Chinesen 
herziehen, aber ein bischen angegrätzt kann man bei einer solch 
schlechten Implementierung schon sein.
Bezieht sich auf das BTM112, dürfte aber auch das BTM222 betreffen da 
diese ja nur im exteren HF-Booster unterschiedlich ist. Schade ist es 
schon, da ein super Bluethootchip von CSR verbaut ist, mit immensen 
Support für Programmierer seitens CSR und was am Ende im fertigen 
Produkt wieder kastriert herauskommt ist Mist.

Fazit: nach jedem gesendeten Byte den RX Buffer des AVRs auslesen und 
eventuell noch mal µs Wartezeit einlegen.

Gruß Hagen

Das meinte ich weiter oben, weswegen mein Modul erst gar nicht ging. Es 
reicht aber, das Echobyte zu empfangen, danach muß man dann nicht mehr 
warten. Da dies nur die Kommandoebene betrifft und der Datenverkehr mit 
voller Geschwindigkeit laufen kann (ohne Handshake nicht zu emfehlen!) 
ist es nicht so schlimm - find ich.

Hm, ok das würde gehen ist aber nicht so dolle. Eine gute Software würde 
asynchron arbeiten können. Nun wird nämlich auch klar warum man zu 
bestimmten Zeitpunkten bestimmte Kommandos nicht verfrüht absenden darf. 
Macht man das denoch so habe ich den Eindruck das die FSM im Modul aus 
dem Tritt kommt und sich sogar aufhängen kann (mir 2 mal passiert). Es 
gibt einige solcher Befehle, zb. ATR0/1, ATO0/1, ATD die länger an Zeit 
benötigen, und wir eben nicht wissen wie lange das dauert. Es gibt dann 
also nur eine Möglichkeit zu erkennen ob das Modul den nächsten Befehl 
akzeptiert, indem man diesen Befehl ständig sendet, quasi pollt. Aber 
exakt dann scheint sich das Modul wieder zu verschlucken und kann sich 
aufhängen. Ein Teufelskreis ;)

Ergo: jedes Byte was rausgeht gleich im ECHO Modus wieder empfangen und 
auch gleich auf Fehler prüfen.

Fazit: nur gut das ich beim Kauf der Module nicht gierig war ;) Bin mal 
gespannt auf die Erfahrungen mit den Modulen wenn sie im Langzeitbetrieb 
eingesetzt werden. Mal sehen wie stabil die Verbindungen sind.

Bleibt noch das Problem das im Slave Modus bei fehlender Verbindung der 
Stromverbrauch zu hoch ist. Bisher versuche ich dann in den Mastermodus 
zu wechseln und mit ATO1 den automatischen Verbindungsmodus zu 
deaktivieren. Das Modul geht dann in den Standby wie es scheint. 
Allerdings mert sich das Scheißteil nicht den eingestellten 
Automatik-modus wenn man wieder zurück in den Slav-Modus wechselt. Also 
jedesmal wenn man in den Mastermodus wechselt ist der autom. 
Verbindgunsaufbau wieder aktiviert. Das fürht dann dazu das dasw modul 
versucht mit einer Gegenstelle Verbindung aufzunehmen.

Gruß Hagen

Wir werden die Module ausgiebig testen, weil wir sie auf Arbeit in eine 
kundengebundene Applikation einbauen wollen. Da müssen sie dann schon 
laufen! Der Support meinte auf meine Anfrage hin, daß wenn das Modul 
nicht arbeiten soll, das Halten im RESET-Zustand eine Maßnahme wäre, 
auch um Strom zu sparen. Ich werde das morgen mal austesten, vor allem 
auch, was an Einstellungen gespeichert bleibt und was verloren geht / 
rückgesetzt wird.

Hallo zusammen,

habe mir gerade mal die Beschreibung angeschaut. Hat schon jemand ne 
Idee wozu der USB-anteil ist und ob und wie man den benutzen kann?

cu,
olly...

Für USB-Anbindung vielleicht? Soweit ich weiß, sogar 2.0 . 
Anschlußschemata habe ich aber noch keine gesehen, insofern muß ich mal 
den Support bemühen.

Gibt es vom Support bezüglich USB schon Neuigkeiten?

ATN=Mein_Modul

würde funktionieren. Bei Verwendung von nicht erlaubten Zeichen gibt´s 
´ne wunderschöne Fehlermeldung: invalid character.

>Gibt es vom Support bezüglich USB schon Neuigkeiten?

Nein. Laut einer gefundenen Beschreibung für ein anderes Modul müssen 
Vorwiderstände 27Ohm für DP und DN verwendet und das Modul mit 3.3V 
versorgt werden. Der FullSpeed-PullUp ist schon drin. Ob die Firmware 
USB unterstützt, kann ich (noch) nicht sagen.

Das BTM330 ist ein Modul ohne eigenen Stack und somit auf einen voll in 
Software implementierten Stack (wie z.B. als Dongle am USB-Port) 
angewiesen. Es läßt sich auch über USB ansprechen.

ÜBRIGENS: bei www.csd-electronics.de gibt es jetzt auch die BTM112, ohne 
umständliche Bestellung in Polen.

Nee, ich auch nicht ;-)

Das bleibt alles erhalten.

Hallo zusammen,

ich habe jetzt auch mal ein wenig mit dem BTM-112 rumgespielt und bin 
auf zwei Probleme gestoßen:

1.
ich habe jeweils 2 Master und 2 Slaves konfiguriert und offenbar haben 
sich da jeweils 1 Master und 1 Slave verheiratet und jetzt habe ich zwei 
Pärchen, und der eine Master findet immer nur noch einen bestimmten 
Slave, der zweite Master den anderen Slave. Gegeneinander ausgetauscht 
kommt es zu keiner Verbindung. Ich habe ATD0 geschickt, Slaves sind im 
discoverable mode und auto-connecting ist aktiviert. Ich weiß nicht was 
da los ist. Hat jemand eine Idee?

2. Mein fünftes Modul hat eine Zeit lang wunderbar funktioniert, jetzt 
reagiert es nur noch auf die Kommandos ATI0 und ATI1, alle anderen 
Kommandos werden mit ERROR quittiert. Was ist da los? Kann man das Modul 
irgendwie totkonfigurieren oder versehentlich sperren? Wenn ja, wie 
kriegt man das wieder hin?

Wäre für Tips und Anregungen dankbar

Gruß,
Markus

50mA wären normal. Nein, GND und Antenne sollten keinen Schluß 
aufweisen. Da passt irgendetwas mit Deiner Löterei nicht oder das Modul 
ist halt defekt.

Nein, ich denke mal nicht. Wieviel Ohm zwischen Antenne und GND mißt Du? 
Hast Du alle GND und Vcc Anschlüsse belegt? Dir ist auch klar, daß die 
Module nur 3.3V Betriebs- und Steuerspannung haben dürfen?

6.2V?? Das klingt gar nicht gut! Hast Du den Regler ordentlich mit 
Kondensatoren abgeblockt und das Modul mit Keramikkondensatoren an Vcc 
und Masse beschaltet?

>Durchgang zwischen Antenne und GND ist zwar nachwievor vorhanden, aber
>sowohl PocketPC als auch Handy finden den "Serial Adaptor".

Das könnte der Balun auf dem Modul sein. Schön daß es jetzt läuft. 
Welchen Regler für die 3.3V benutzt Du denn?

> Gibt's beim BTM-222
>auch Pins für Status-LEDs (Typ?)?

Ja, GPIO 5...7 . Schließe einfach mal eine LED mit 1k Vorwiderstand nach 
Masse und gucke, was passiert ;-) Noch dazu sind die eingehenden 
Handshake-Leitungen auch mir LEDs ganz anschaulich.

>Kann mir keiner was zu meiner o. g. Frage sagen, wie/ob man die Baudrate
>per BT umstellen kann?

Nicht per Bluetooth, nur mit UART. Ist das Modul erst mal im BT-Mode, 
akzeptiert es keine Commands mehr.

Das Problem hatte ich auch schon, allerdings habe ich es noch nicht 
geschafft, Rayson mal eine eMail zu schreiben. Die sind eigentlich recht 
offen für Fragen. Es wäre allerdings nicht die erste Sache, die im 
Datenblatt falsch ist oder einfach fehlt. Ich hätte einfach mal gerne 
konkrete Aussagen zum Timing des Moduls, zum Beispiel wie lange die 
Start-Up-Zeit ist.

Nein, habe ich nicht. Allerdings habe ich da auch schon länger nicht 
mehr daran gearbeitet, ich brauchte auch nur den Slave-Modus.

Moin,
ich habe mein modul soweit am laufen jedoch bekomme ich es nicht hin 
über meinen smartphone (windows mobile 2003) mit dem modul zu 
kommunizieren. ich würde mich freuen wenn boris sein programm hochladen 
würde.
mfg max

Hallo,

hier ein Terminal für den PDA zum testen:

http://www.appliedpda.com/Products_PocketDAQ.html

mfg

gibt es eine einfache Lösung eine Bluetooth-Verbindung vom Modul aus zu 
kappen, um z.B. wieder AT befehle zu senden?
Einfach resetten?

Gruß
Manuel

+++ senden, danach eine Pause von mindestens 1 sek. lassen

Das BTM333 kommt ohne eigenen Stack und ist daher nur in Verbindung mit 
einem Gerät mit (Software) BlueTooth Stack geeignet (Verwendung in 
USB-Sticks oder als interne BT-Schnittstelle im PC oder PDA).

>Bluetooth Stack heist damit: Man kann damit keine einfache serielle
>Verbindung wie mit dem BTM 112 aufbauen? Also kein SPP-Profil?

Korrekt, lediglich eine Hardware-Anbindung mit HCI-Protokoll (oder 
RFCOMM) zur Beeinflussung der Register im BlueCore4.

Also wenn ich Dir ´was empfehlen soll, dann nimm die BTM222, die sind 
sende- und empfangsstark und unkompliziert über AT-Commands und UART 
steuerbar. Die 112er verlieren den Kontakt tatsächlich nach etwa 10m 
oder hinter einer Betonwand von 20cm Stärke.

Ach ähem, der BT-Chip vom BTMxxx ist ein BlueCore4 von CSR, und somit 
leistungsfähiger, als der von National.

Ist man bei den Modulen mit integrierten SPP-Profil eigentlich auf 
dieses festgelegt, oder hat man alternativ auch das HCI-Interface?

>Als Vorteil der geringen Sendeleistung würde ich sehen, dass sich viele
>gleichzeitig betriebene Module nicht so sehr stören.

Das stimmt wohl. Wenn Dir die kleine Leistung reicht. Die BTMxxx kommen 
ohne Antenne, die kann man aber leicht auf der Trägerplatine als 1/4 
Lambda Drahtstück mit 0,8mm Breite ausführen.

>Ist man bei den Modulen mit integrierten SPP-Profil eigentlich auf
>dieses festgelegt, oder hat man alternativ auch das HCI-Interface?

Entweder ein SPP-Modul mit Stack oder ein HCI ohne.

Also von den BT112-Modulen habe ich noch zwei, die ich nicht benötige. 
Die würde ich gegen Erstattung des Kaufpreises und dem Porto auch 
abgeben wollen.

Allerdings benötige ich dringend BTM222-Module - davon hat zufällig 
keiner mehr welche?

xing wrote:
> Hey, die BTM112 hätte ich gerne. Wie kann ich Dich kontaktieren?

Am besten einloggen und mir eine Nachricht schicken. Preis für die zwei 
Module  inklusive Porto wären 30€.

Gibt es eine Moeglichkeit wieder in den DATA Mode zu gelangen, nachdem 
ich mit '+++' vom DATA in den COMAND Mode gewechselt habe?
Konnte noch nichts finden...

Ich habe mir in Eagle einen einfachen DIL-Adapter fuer das BTM-112 
erstellt (siehe Foto), falls jemand Interesse hat einfach melden. Die 
Antenne ist nur ein Stueck Kupferlackdraht und Lambda/4 lang, 
funktioniert problemlos (das Modul funkt erstaunlicherweise auch ohne 
die Drahtantenne ;) )

Gruesse

>Gibt es eine Moeglichkeit wieder in den DATA Mode zu gelangen, nachdem
>ich mit '+++' vom DATA in den COMAND Mode gewechselt habe?
>Konnte noch nichts finden...

ATO0

siehe hier: 
http://www.mikrocontroller.net/attachment/27771/BTD43X_user_manual.pdf

Travel Rec. wrote:
>>Gibt es eine Moeglichkeit wieder in den DATA Mode zu gelangen, nachdem
>>ich mit '+++' vom DATA in den COMAND Mode gewechselt habe?
>>Konnte noch nichts finden...
>
> ATO0
>
> siehe hier:
> http://www.mikrocontroller.net/attachment/27771/BTD43X_user_manual.pdf


ATO0 ist in der BTD43X_user_manual.pdf leider nicht aufgefuehrt, aber im 
Datenblatt zum BTM-112. Zu ATO: 'When it＇s in master mode .The command 
is used to enable/disable auto-connection feature. When it＇s in slave 
mode, the command will be rejected.'
Ich arbeite im Slave Mode, da funktioniert es nicht...

Das Modul ist uebrigens auch nach der '+++'-Sequenz laut Status-LED noch 
verbunden, eine neue Verbindung waere theoretisch also gar nicht 
notwendig.

Hat noch jemand eine Idee?

Gruesse

PS: Das Englisch aus dem Datenblatt ist ja grauenvoll ;)

>ATO0 ist in der BTD43X_user_manual.pdf leider nicht aufgefuehrt, aber im
>Datenblatt zum BTM-112.

Ist Deine Brille kaputt?!

Was macht denn das Modul, wenn Du nur ATO eingibst (also ohne Null 
danach)?

Travel Rec. wrote:
>>ATO0 ist in der BTD43X_user_manual.pdf leider nicht aufgefuehrt, aber im
>>Datenblatt zum BTM-112.
>
> Ist Deine Brille kaputt?!
>
> Was macht denn das Modul, wenn Du nur ATO eingibst (also ohne Null
> danach)?

Oh, mein Fehler, hatte das 'O' zwischen 'N' und 'P' erwartet ;)
Danke, funktioniert mit ATO wunderbar, bei ATO0 (ATO_NULL) bringt mir 
das Modul nur die Meldung 'ERROR' (egal ob verbunden oder nicht), da ich 
das Modul ja im Slave Mode betreibe.

Gruesse

Na super!

Was genau tust Du denn und was passiert, wenn Du es getan hast?

Schließt Du die Kommandos mit 0x0C ab (ASCII CR) ?

Gut, 0x0D ist richtig. 0x0A ist überflüssig und könnte den Fehler 
provozieren.

:-)

unterstützt dein Handy das SPP ? wahrscheinlich nicht. Mit meinem 
Siemens CX75 und SmartPhone HTC Touch geht es problemlos, sie 
unterstützen aber auch das SPP =Serial Port Profile.

Sobald ich zb. mit dem Siemens verbunden bin und in den Datenmodus 
wechsle kann ich das Siemens per AT Befehle fernsteuern, also so als ob 
ich ein PC-RS232 Kabel am Siemens hätte.

Hast du schonmal versucht von deinem PC aus per BT das Handy 
anzusprechen ?
Wa für'n Handy überhaupt ?

Gruß Hagen

Hm, bei mir hat das funktioniert. Du könntest jetzt versuchen die 
Verbindung vom BTM aus aufzubauen. Auch das hat bei mir funktioniert.

Gruß Hagen

Hallo,

wg. SPP und mobile Verbindung mittels "Mobile Processing"
(s. mobile.processing.org ) auf ein SE w810i

Ich habe ein 112 und ein 222 jeweils über einen sogenannten shield mit 
einem Arduinoboard verbunden. Hat von Anfang an wunderbar funktioniert.
Kann es auch vom Handy aus sehen und in "Meine Geräte" einfügen, 
gleichfalls auf PC und Mac.
Bin gerade dabei eine Steuereinheit für eine Fotokamera zu entwickeln 
und dachte mir, bevor ich die ganze Materie über einen zweiten 
Controller steuere, was für später trotzdem vorgesehen ist, wäre es doch 
supercool wenn man das ganze einfach auch über das Handy steuern könnte.
Da ich eher aus der grafischen Ecke komme, bin ich bei mobile processing 
fündig geworden.
Aber das ganze will nicht so wie ich will. Das SE will einfach das spp 
vom BTM nicht als solches erkennen. Beim Logilinkadapter am PC gibt es 
überhaupt keine Zicken.
Die original Bluetooth Library v. mobProc habe ich im Laufe der Tests 
durch eine gepatchte ersetzt. - s. 
http://todbot.com/blog/2006/09/12/roombactrl-drive-your-roomba-with-your-cell-phone/

http://roombahacking.com/software/midlet/mobileprocessing-bluetooth-patched.zip

Da ich hier von einem ähnlichen Problem gelesen habe, denke ich das 
könnte durchaus ein SonyErichssohn Problem sein?

Ich habe auch einige andere UUIDs durchprobiert, nur das BTM-modul 
wollte nicht, andere kein Problem.
s. 
http://www.avetana-gmbh.de/avetana-gmbh/produkte/doc/javax/bluetooth/UUID.html

Weiss hier irgendjemand welche UUID das spp Profil vom BTM Modul hat? 
Über die BlueSoleil Oberfläche bekomme ich das leider nicht raus und 
sonst habe ich auch nichts gefunden.

Würde mich sehr freuen,
Vielen Dank!

Such doch einfach direkt nach der SPP-UUID 0x1101 anstatt nach einer 
Service-spezifischen UUID. Alternativ kannst du auch ganz ohne UUID 
direkt per Bluetooth-Adresse verbinden, wenn du die Channel-Nummer 
kennst (vermutlich 1)! Das sollte immer klappen.

Ich habe zwar noch nicht mit den BTM Modulen gearbeitet, aber schon 
einige Dinge mit J2ME und Bluetooth zusammen mit SonyEricsson Handys 
gemacht und hatte noch nie Probleme mit SPP Verbindungen.

@Florian

vielen Dank für Deine Antwort.

Folgendes habe ich unter anderem ausprobiert:

1.)    bt = new Bluetooth(this, Bluetooth.UUID_SERIALPORT);

2.)    bt = new Bluetooth(this, 0x1101 );

3.)-xx.)   bt = new Bluetooth(this, 0xYYYY );

Beides funktioniert, den LogiLink Adapter bekomme ich einfwandfrei zur 
Auswahl, sogar zweimal wenn beide Ports frei sind. Das einzige mal in 
der Auswahl erschien das SE bei folgender UUID:
BNEP  0x000F, beim Versuch zu verbinden andererseits warf es eine 
Fehlermeldung auf. Vielleicht sendet das BTM Modul nicht 100proz den 
richtigen Identifizierungscode?
Im Moment weiss ich jedenfallsnicht weiter,... leider (

 Ich versuche jetzt mal in der SE devWorld was rauszukriegen...

@ Florian

konnte den Code gerade 1:1 auf einem Nokia 5300 ausprobieren, hat  ohne 
Probleme sofort geklappt.

D. Frank wrote:
>
> Folgendes habe ich unter anderem ausprobiert:
>
> 1.)    bt = new Bluetooth(this, Bluetooth.UUID_SERIALPORT);
>
> 2.)    bt = new Bluetooth(this, 0x1101 );
>
> 3.)-xx.)   bt = new Bluetooth(this, 0xYYYY );

Was für ein WTK bzw. was für eine Bluetooth-API etc. verwendest du denn? 
Ich benutze die "Standard" JSR-82 API, da gibts so ein Bluetooth-Objekt 
überhaupt nicht?

Für den Verbindungsaufbau benötigst du da einen "Connection-String", der 
die Bluetooth-Adresse (nicht die UUID) und den Channel benötigt. Wenn 
eins davon nicht stimmt, kriegst du keine Verbindung.

Guck am besten mal in die JSR82-Doku:
http://www.jcp.org/en/jsr/detail?id=82

Ein Connection-String könnte so ähnlich aussehen:
"btspp://0123456789AF:1;master=false;encrypt=false;authenticate=false"

0123456789AF wäre dann die Bluetooth-Adresse deines Moduls und der Kanal 
ist 1.

Okay, ich hätte deinen Post genauer lesen sollen ... dass du Java gar 
nicht direkt benutzt, hab ich jetzt erst verstanden. ;-)

Wenn dieses Bluetooth-"Objekt" nur lange UUIDs nimmt, bist du mit meinem 
Tipp natürlich aufgeschmissen. Hast du mit Mobile Processing denn schon 
eine Gerätesuche durchgeführt und dir die Ergebnisse mal ausgeben 
lassen?

Ich persönlich würde die Schuld erst mal auf Mobile Processing schieben, 
wenn das SE keine Verbindung aufbauen will.

Ich könnte auch von Mobile Processing aus direkt auf Java zugreifen. 
Allerdings bin ich da nicht so firm. Ich müsste die entsprechenden 
Libraries/Module/Klassen oder was auch immer importieren und dann 
einfach(?) Java-like verwenden. Habe mich in letzter Zeit eher mit C 
beschäftigt, wg. Arduino. Die Dokumentation von MobProc ist leider noch 
nicht so gut wie die von Processing selbst, wobei die Syntax für die 
grafische Ausgabe eigentlich genau diesselbe ist.
Es ärgert mich, daß ich mal wieder in so einen Sonderfall getappt bin, 
für den es kaum Doku gibt.

ABER wie gesagt: auf dem nokia hat es sofort funktioniert.

Das Gerät wird vom SE gefunden, der Service aber nicht als spp erkannt. 
Habe es mir auflisten lassen. Dieses roombactl.pde kann man übrigens 
direkt verwenden, geht ganz einfach zu compilieren mit der GUI. Die GUI 
ist sehr leicht zu installieren.
Bei einer Verbindung schickt es halt einfach ein paar Bytes ans Target, 
die einfach nichts bewirken, da keine Auswertung erfolgt. Habe das so 
wie es ist, d.h. das midlet, z.B. auf das Nokia geschickt und 
selbstverständlich vorher auch auf das SE. Das SE erkennt alle anderen 
Geräte mit spp, auch hier in der Arbeit wo ich gerade bin, nur das f.. 
BTM nicht. Mit dem BTM-112 übrigens exakt das gleiche Problem. Ach und 
auf dem Mac heisst der Dienstname "Dev B". Da bin ich auch noch nicht 
dahinter gekommen woher das kommt.

Du könntest mal versuchen, dich manuell zu verbinden - ganz ohne 
Discovery etc.

Einfach ein Streamconnection-Objekt holen, so ähnlich:

1

StreamConnection con = null;

2

OutputStream out = null;

3

InputStream in = null;

4

5

String url = 

6

    "btspp://0123456789AF:1;master=false;encrypt=false;authenticate=false"

7

try {

8

    con =

9

        (StreamConnection)Connector.open(url,Connector.READ_WRITE);

10

    out = 

11

        connection.openOutputStream();

12

    in = 

13

        connection.openInputStream();

14

} catch (Exception e) {

15

   //Hier bspw. e.getMessage() ausgeben

16

   return;

17

}

Wenn das klappt (also keine Exception kommt), kannst du fröhlich mit 
in/out Daten senden. Anstatt 0123.. musst du natürlich die 
Bluetooth-Adresse des BTM-Moduls angeben (wird unter Linux bspw. per 
'hcitool scan' angezeigt) und anstatt des Kanals 1 evtl. noch andere 
Kanäle probieren.

Sollte das funktionieren, kannst du im nächsten Schritt ja die 
Gerätesuche von Mobile Processing hinzufügen und dir aus dem gefundenen 
Gerätenamen die Verbindungs-URL zusammenstricken.

Gruß,
Florian

P.S.: Ich hoffe der Code da oben ist einigermaßen fehlerfrei ... 
natürlich ohne Gewähr ;-) Du wirst auf jeden Fall noch folgende Imports 
benötigen:

import java.io.InputStream;
import java.io.OutputStream;
import javax.microedition.io.Connector;
import javax.microedition.io.StreamConnection;

@Florian

Super! Funktioniert! Bekomme keine Fehlermeldung und das BT Symbol oben 
geht auf Connection (der blaue Pfeil) und das Modul zeigt auch eine 
Verbindung an, d.h. die LED leuchtet konstant!
Wow, ich habe mich schon wieder Tage am grübeln mit Kopfweh gesehen...
Zwei kleine Sachen in deinem Code im try block:

1

try {

2

    con =

3

        (StreamConnection)Connector.open(url,Connector.READ_WRITE);

4

    out = 

5

        connection.openOutputStream();

6

    in = 

7

        connection.openInputStream();

muss heissen:

1

try {

2

    con =

3

        (StreamConnection)Connector.open(url,Connector.READ_WRITE);

4

    out = 

5

        con.openOutputStream();

6

    in = 

7

        con.openInputStream();

Das obere habe ich in den setup block eingebettet, zum beenden habe ich 
dann noch MobProc mäßig

1

void destroy() {

2

  //// 

3

  try {

4

    con.close();

5

  } 

6

  catch (Exception e) {

7

    text(e.getMessage(), 2, 60, width-4, height-4);

8

    return;

9

  }

10

}

hinzugefügt, damit die Verbindung dann auch wieder geschlossen wird wenn 
man das midlet killt. Die Textausgabe hier macht glaube ich doch keinen 
Sinn, man hat ohnehin keine Chance diesen zu sehen, da das midlet dann 
ja schon gestorben ist?


Das mit der Gerätesuche und Adresse ist sicher kein Problem, mit Namen 
hakt es manchmal. Würde dann lieber Adresse nehmen. Für ein universelles 
kleines Programm wären Namen natürlich schöner.
Für mich würde es reichen die Adressen meiner Bluetoothmodule hart zu 
kodieren, da die ja bekannt sind/sein müssen, da es ja eine limitierte 
Auflage an Hardware ist mit eigenem Protokoll.

Das ganze eröffnet ja auf einmal ganz neue Möglichkeiten! Sowohl für 
Input als auch für Output. Das schöne an Processing/ Mobile Processing 
ist auch, daß man relativ simpel anständige Grafik ausgeben kann. D.h. 
ich kann Sensorwerte als Kurven odere mehrere Werte schick grafisch auf 
dem handy anzeigen. So kann man sich dann auch für manche Objekte eine 
LCD zumindest für den Prototyp sparen und sich die Debugginggeschichte 
aufs Handy holen. Macht auch für viele Betriebsmodelle mit Sicherheit 
Sinn. Bluetooth ist denke ich doch relativ stabil, v.a. die Class 1 
Module haben genug Power um damit in einem brauchbaren Radius auch 
professionell zu hantieren. Und man muss sich um den restlichen 
Datentransport-Hardwareschnickschnack keine Gedanken mehr machen.

Was dann natürlich auch noch schick wäre, wenn man das Arduinomodul, wie 
beim ArduinoBT per Bluetooth programmieren könnte.

Die Verbindungsprozedur ist übrigens äusserst flott! Geht ZackZack!
D.h. man muss eine Verbindung nicht immer stehen lassen, sondern kann 
sie wahrscheinlich beruhigt beenden wenn man weiss, daß sie gleich 
wieder steht wenn sie gebraucht wird.
So. Und jetzt heisst es ein paar Testdaten hin und herschieben, 
visualisieren, lachen oder lächeln!

Vielen Dank soweit! Du hast mir sehr geholfen!

Für Nokias müsste das ja genauso funktionieren, d.h. das wäre alles auch 
sehr universell einsetzbar.
Noch eine Frage: Weisst Du zufällig auch wie man dasselbe mit normalem 
Java macht? Wenn das ähnlich einfach ginge, wäre der code für mobile 
processing ganz simpel für das normale Processing zu adaptieren, d.h. 
man könnte ein ähnlich gestricktes Programm ganz schnell auf den PC/Mac 
adaptieren oder diesen mit integrieren.

Schön, dass es geklappt hat.

Für JSR82 auf dem Desktop gibts mehrere Erweiterungen (frei und 
kostenpflichtig).

Die bekannteste sollte wohl BlueCove sein:
http://code.google.com/p/bluecove/

In kostenpflichtig gibts bspw. die Implementation der Firma avetana:
http://www.avetana-gmbh.de/avetana-gmbh/produkte/jsr82.xml

Praktisch habe ich allerdings noch mit keiner gearbeitet und immer C++ 
mit der nativen API genutzt  .. ;)

@ Florian: Danke, das werde ich mir bei Gelegenheit mal ansehen.


@ all

Ein Update, ich hoffe daß das jemanden interessiert. In Zukunft werde 
ich nur weiter hier posten falls Interesse besteht. Den "Mobile 
Processing" Code kann ich auch gerne soweit zur Ansicht stellen, wenn 
keiner nörgelt, weil er einfach ein bisserl quick&dirty ist und ich 
beileibe kein Javagenie bin. Der Arduino Code ist nicht spektakulär.

Im Moment ist das Setup folgendermassen:

- Arduino & BTM222 senden bei Verbindung laufend eine Schleife mit 
Werten von 0 bis 255

- Handy empfängt den Stream(!) und versucht eine zeigerähnliche 
Darstellung zu bieten + einige Debugmeldungen.


Soweit so gut funktioniert im Prinzip einwandfrei. Aber...
Um eine saubere Anzeige zu bekommen muss man ein bisschen tricksen. Das 
Problem ist der Stream. Es werden einfach wesentlich mehr Daten 
übertragen als die Framerate verarbeiten kann. Ausserdem sendet das 
Modul auch pulsweise einen Bulk Daten, da hat man auf einen Schlag 
wieder weit über 2000 Bytes im Buffer. Das heisst man muss ein gutes 
Mittel finden zwischen Frames droppen und flüssiger Anzeige. Im Moment 
passt es bei mir ganz gut wenn ich zw. 1000 und 1500 Bytes im Buffer 
habe. Bei weniger stockt die Anzeige zu oft. (Habe mir an der Seite v. 
Display eine Balkenanzeige für die Buffergrösse gemacht und blende unten 
die aktuelle Größe ein) Über die Up und Down Taste kann ich den Skipwert 
erhöhen der sich im Moment nach folgender Formel berechnet:

1

int inlen = in.available(); // check buffer size

2

      int skipper=0;

3

      // The Buffer has sometimes to be shortened

4

      // to get a "smooth" reading. The BT sends 

5

      // bulks of data. Otherwise we may get 

6

      // an overflow sometimes?

7

      if (inlen > 2000) {

8

         // skipbytes is an adjustment you can change with UP or DOWN key

9

        skipper += inlen/100 + skipbytes;

10

      }

11

      in.skip(skipper);

Das ist generell wichtig wenn ich so etwas wie einen Liveauswertung 
vornehmen will. Man sollte im Kopf haben, daß da noch ein ganzer Schlag 
an Daten auf Dich warten kann.
Wenn ich nicht diese absolut gleichmässige Datenübertragung zum Test 
gemacht hätte, wäre mir das nie aufgefallen oder ich hätte mir 
irgendwann gedacht was das Ding für Nonsens überträgt.

Schön ist das natürlich wenn ich das dann einfach abspeicher. Dann habe 
ich einfach alle Werte.

Eine andere Möglichkeit und ev. eleganter wäre einfach nur auf Request 
zu senden.

Anbei noch eine Bildmontage, auf die Schnelle mit der Hand 
abfotografiert und mit Bemerkungen versehen.

Also bei Interesse bitte posten, ansonsten werden ich für die Geschichte 
demnächst nur im Arduinoforum oder -Playground einen Post einrichten.

Vielleicht solltest du doch direkt auf "normales" Java umsteigen ... ;-)

Am einfachsten gehts vermutlich mit einem GameCanvas.

Ein Thread kümmert sich um die Bluetooth-Verbindung und empfängt ständig 
die Daten, sichert sie in eine thread-sichere Variable und ruft dann 
repaint() auf.

Die paint() Methode wird dann von der JVM aufgerufen, wenn mal wieder 
Zeit für ein Update der Anzeige ist. In paint() holst du dir den Wert 
aus der thread-sicheren Variable und malst darauf basierend deinen 
Zeiger.

Dadurch musst du nicht manuell Daten wegwerfen - paint() wird nur dann 
und wann aufgerufen (aber oft genug...) und zeichnet immer den 
aktuellsten Wert.

Für professionelle Entwicklung ist ein solider Java Background sicher 
nicht ohne. Es ist auch die Frage wo man hin will. Im Moment ist für 
mich wichtig mal abzuchecken was prinzipiell möglich ist. Falls man auf 
einmal eine Anfrage hat die so etwas fordert, müsste man einfach auf 
einen Fachmann zurückgreifen der sich um so etwas kümmert. Man kann 
nicht alles können. Na ja, wie dem auch sei :)
Wo man hier aber auch noch anpacken müsste: es werden einfach zuviele 
Daten übertragen. Wenn man das reduziert, ev. nur auf Request macht. 
Aber das mit dem Thread hat schon was für sich… . Vor allem stockt die 
Ausführung immer bis die Daten wieder da sind. sprich wenn sich 
in.read() wieder etwas geholt hat.


Habe die andere Richtung auch mal getestet, funktioniert auch 
einwandfrei. Ich sende mit UP oder DOWN Taste einfach einen Wert, der 
sich durch drücken erhöht oder eben erniedrigt hat. Das Modul empfängt 
und schickt den Wert an eine PWM Ausgabe die einfach eine LED ansteuert 
- heller od. dunkler. Schwieriger wirds jetzt wieder wenn man anstatt 
einem BYTE ein INT schickt. … Da wollte ich mich als nächstes drüber 
machen.

Das Nokia reagiert übrigens völlig anders. Aber mein Kollege ist 
immerhin total begeistert was man so alles machen kann ;-)  und stellt 
es mir immer gerne für einen Test zur Verfügung.

Florian, mach Dir bitte die Mühe den ganzen Thread hier zu lesen, Du 
solltest alle Infos finden, um das Modul in Betrieb zu nehmen.

Danke Christian!