Hallo zusammen, ich bin langsam mit meinem Latein am Ende: nachdem ich bei meinem derzeitigen Projekt mit ATSAM4S und Bluetoothmodul 3.0(SPBT2632C2A von ST) zuerst dachte, dass es an meiner unzureichenden Beherrschung des UART interfaces liegt ( Beitrag "Architektur für "background" Uart-Transmission" ), gehe ich inzwischen davon aus, dass folgendes Problem die danach folgende Ursache hat und brauche euren Rat: Problem: Die Datenrate die ich über SPP nutzen muss/ möchte, nähert sich der verwendeten Baudrate (zZt. 115kBaud). Hierbei gehen bei mittleren datenraten (also ca 50kbit/s) keine Daten verloren, bei höheren daten (max ca. 100kbit/s) durchaus. Merkürdig aber: Es gehen nicht etwa einzelne Bytepakete verloren, sondern dann gleich bis zu 31 GANZE 27byte packets meines protokolls. Und das in unregelmäßigen Abständen (mal mehrmals hintereinander, dann sekundenlang gar nicht). Das Problem wäre höchstwahrscheinlich lösbar, wenn ich höhere Baudraten nutzen könnte. Dazu ist das SPBT2632C2A (http://www.st.com/web/catalog/sense_power/FM1968/CL1976/SC1324/PF253470) und der Rest meiner hardware auch durchaus in der Lage, nämlich im SPP bis zu 560kbps. Also wollte ich auf 230kbaud umstellen. Und hier kommt das Problem auf der Empfänger (PC Seite): Ich kann für die COM Einstellungen bei Windoofs 8 (nutze ein Lenovo Thinkpad T440s) nur max. 115kbaud auswählen. Also habe ich recherchiert - und klar wurde: Das liegt (mindestens) an der maximal unterstützten baudrate des bluetooth/serial chips. Also habe ich mir ein typisches Bluetooth-USB-Dongle wie das hier besorgt http://www.pearl.de/a-PX1632-1431.shtml;jsessionid=haan1ZKpmjqE7-zp41Jav - läuft auch nicht (maximal 128kBaud wählbar). Frage: Was kann/muss ich auf der Rechnerseite tun - oder besorgen - um 230kBaud im SPP mode empfangen zu können? Es muss doch (USB)Bluetooth-Empfänger geben, die dazu in der Lage sind - und USB beherrscht die Datenrate ja dann locker...?
@ Alex V. L. (bastel_alex) Benutzerseite >Bluetoothmodul 3.0(SPBT2632C2A von ST) zuerst dachte, dass es an meiner >unzureichenden Beherrschung des UART interfaces liegt ( Ist es auch. >Beitrag "Architektur für "background" Uart-Transmission" ), gehe ich >inzwischen davon aus, dass folgendes Problem die danach folgende Ursache >hat und brauche euren Rat: Warum gehst du davon aus? Hast du die Hinweise in ein lauffähiges Programm umsetzen können? >Problem: Die Datenrate die ich über SPP nutzen muss/ möchte, nähert sich >der verwendeten Baudrate (zZt. 115kBaud). Hierbei gehen bei mittleren >datenraten (also ca 50kbit/s) keine Daten verloren, bei höheren daten >(max ca. 100kbit/s) durchaus. Man kann den UART auch bei 100% Auslastung fehlerfrei nutzen. > Merkürdig aber: Es gehen nicht etwa >einzelne Bytepakete verloren, sondern dann gleich bis zu 31 GANZE 27byte >packets meines protokolls. Und das in unregelmäßigen Abständen (mal >mehrmals hintereinander, dann sekundenlang gar nicht). Klingt nach einem Programmfehler. >Das Problem wäre höchstwahrscheinlich lösbar, wenn ich höhere Baudraten >nutzen könnte. Dazu ist das SPBT2632C2A NEIN!!! Du kaschierst immer noch dein schlechtes Programm! >Frage: Was kann/muss ich auf der Rechnerseite tun - oder besorgen - um >230kBaud im SPP mode empfangen zu können? Es muss doch >(USB)Bluetooth-Empfänger geben, die dazu in der Lage sind - und USB >beherrscht die Datenrate ja dann locker...? Lerne richtig zu programmieren. Wenn du mehr Hilfe brauchst, muss du vollständigen Quelltext als Anhang posten.
Falk B. schrieb: > Warum gehst du davon aus? Hast du die Hinweise in ein lauffähiges > Programm umsetzen können? Ja, deine zumindest. Warum ich davon ausgehe: Weil ich über Tage alle möglichen Fehlerquellen ausgeschlossen habe - z.B. alle möglicherweise störenden interrupts ausgeschaltet, einen unit-test implementiert, der determinierte datenpakete schickt, und außerdem mal das bluetoothmodul rausgenommen und einen standard ftdi chip drangehängt habe - wo interessanterweise NICHTS verloren geht. alles bis zum bluetooth modul läuft also. Falk B. schrieb: > Man kann den UART auch bei 100% Auslastung fehlerfrei nutzen. der UART funktioniert ja auch fehlerfrei. das problem ist die Blackbox inklusive bluetooth modul, luftweg und empfänger... Falk B. schrieb: > NEIN!!! Du kaschierst immer noch dein schlechtes Programm! du bist ein pessimist! Falk B. schrieb: > Lerne richtig zu programmieren. Wenn du mehr Hilfe brauchst, muss du > vollständigen Quelltext als Anhang posten. Ich stimme dir zu, meine Frage hier ging aber nicht um den Code..
@Alex V. L. (bastel_alex) Benutzerseite >Warum ich davon ausgehe: Weil ich über Tage alle möglichen Fehlerquellen >ausgeschlossen habe - z.B. alle möglicherweise störenden interrupts >ausgeschaltet, einen unit-test implementiert, der determinierte >datenpakete schickt, und außerdem mal das bluetoothmodul rausgenommen >und einen standard ftdi chip drangehängt habe - wo interessanterweise >NICHTS verloren geht. alles bis zum bluetooth modul läuft also. OK, dann scheint es wirklich am Bluethoothmodul zu liegen. >du bist ein pessimist! Manchmal schon.
Als nochmal in kurz, weil das hier bestimmt jemand weiß: Was tun (Treiber?) / kaufen (Modul/Dongle?) um am PC mit Bluetooth daten über 115kBaud empfangen zu können, wenn dessen integrierter bluetooth/serial chip die nicht unterstützt?
Alex V. schrieb: > dessen integrierter bluetooth/serial chip Was ist das für eine komische Hardware, die Bluetooth über einen Seriellen Port ansteuert? Ich kenne Bluetooth-Dongles sonst nur mit der HCI-Schnittstelle, und die läuft überlicherweise über USB. Also Statt PC -> Seriell/RS232 -> Seltsamer Chip -> Bluetooth with SPP sowas PC -> USB -> 1€-billigst-Bluetooth-Stösel -> Bluetooth with SPP versuchen. SPP ist dann reine Software-Sache. Welche Baudraten du über SPP fährst, interressiert die USB-Schnittstelle nicht.
Ich bin nicht sicher, ob ich dich richtig verstehe - vielleicht habe ich mich auch nur verquer ausgedrückt. Gemeint war: Der integrierte Bluetooth-empfänger des Laptops gibt mir, wenn ich meine hardware kopple, eine "standardmäßige Seriell-über-Bluletooth-Verbindung" als com port aus. Den kann ich auf maximal 115kbaud nutzen. Was laut google an der hardware im laptop liegt, deshalb ja der dongle. Planlos schrieb: > Was ist das für eine komische Hardware, die Bluetooth über einen > Seriellen Port ansteuert? > > Ich kenne Bluetooth-Dongles sonst nur mit der HCI-Schnittstelle, und die > läuft überlicherweise über USB. > PC -> USB -> 1€-billigst-Bluetooth-Stösel -> Bluetooth with SPP Ja das tut mein Dongle auch! Auch da kann ich aber am virtuellen comport keine höhere Baudrate als 128kBaud einstellen.
:
Bearbeitet durch User
Alex V. schrieb: > Problem: Die Datenrate die ich über SPP nutzen muss/ möchte, nähert sich > der verwendeten Baudrate (zZt. 115kBaud). Hierbei gehen bei mittleren > datenraten (also ca 50kbit/s) keine Daten verloren, bei höheren daten > (max ca. 100kbit/s) durchaus. Merkürdig aber: Es gehen nicht etwa > einzelne Bytepakete verloren, sondern dann gleich bis zu 31 GANZE 27byte > packets meines protokolls. Und das in unregelmäßigen Abständen (mal > mehrmals hintereinander, dann sekundenlang gar nicht). Höhere Baudraten ab 115200 laufen bei Bluetooth SPP nur noch mit aktiver Flusskontrolle (und größeren FIFOs im Modul). Alex V. schrieb: > Frage: Was kann/muss ich auf der Rechnerseite tun - oder besorgen - um > 230kBaud im SPP mode empfangen zu können? Nix. Die Baudrate auf PC Seite interessiert normalerweise niemanden, die wird im Modul i.d.R. auf anderem Wege eingestellt. Siehe UM1547.
Alex V. schrieb: > Auch da kann ich aber am virtuellen comport > keine höhere Baudrate als 128kBaud einstellen. Die Einstellung der Baudrate am virtuellen SPP-Comport beinflusst aber nicht die Übertragungsgeschwindigkeit. Du kannst die auf 300 Baud stellen, und trotzdem 1MBaud rüberjagen. Das einzige was eine Baudraten/Parity-Änderung an dem Virtuellen Comport macht (machen sollte): Es wird ein frame mit Config-Daten an den Empfänger gefunkt, damit dieser, wenn er mag, seine externe Schnittstelle auf eben diese Werte einstellen kann. Idee dahinter: Bluetooth-SPP mit passendem Empfänger ist dann für PC-Software ein transparenter RS232-Kabel-Ersatz.
Verstehe... erstmal ja eine gute nachricht. Jim M. schrieb: > Höhere Baudraten ab 115200 laufen bei Bluetooth SPP nur noch mit aktiver > Flusskontrolle (und größeren FIFOs im Modul). Das SPBT2632C2A (http://www.st.com/web/catalog/sense_power/FM1968/C...) unterstützt das ja eigentlich. ich habe es bisher nur ohne flusskontrolle versucht - die FIFOs sollten intern dort ja angemessen ausgelegt sein. Nur um das richtig zu verstehen: Wenn baudraten/parity-Einstellungen am PC egal sind (wie ich auch in HTerm schon feststellen durfte, da dachte ich nur das liegt daran, dass die eigentliche Konfiguration des BT-ComPorts im Hintergrund eben fest konfiguriert sein muss), gilt das auch für den CTS Flow control? Bezieht sich deine Aussage also nur auf meine hardware-seite (µC-BT Modul)?
:
Bearbeitet durch User
Alex V. schrieb: > Problem: Die Datenrate die ich über SPP nutzen muss/ möchte, nähert sich > der verwendeten Baudrate (zZt. 115kBaud). Hierbei gehen bei mittleren > datenraten (also ca 50kbit/s) keine Daten verloren, bei höheren daten > (max ca. 100kbit/s) durchaus. Merkürdig aber: Es gehen nicht etwa > einzelne Bytepakete verloren, sondern dann gleich bis zu 31 GANZE 27byte > packets meines protokolls. Und das in unregelmäßigen Abständen (mal > mehrmals hintereinander, dann sekundenlang gar nicht). Der Bluetooth UART-Dongel sammelt erst einige Bytes um sie gebündelt zu übertragen. Davon auszugehen das jedes Byte oder gar Bit in Echtzeit übertragen wird ist falsch. Geht dann mal ein Bluetooth-Paket verloren sind danach schon mal 500-1000Bytes deiner Übertragung weg. Normaler weise versucht das Bluetooth-Protokoll verlorene Pakete erneut zu senden, aber wenn dann bereits das nächste Paket Ansteht, wird es dann weg geworfen. (Bluethoots hat bis zu 8168 Bit Nutzdaten pro Paket)
Ich hab mal eben die Hardware Specification und das User Manual überflogen... Ich kenne das Gerät nicht, mir sind aber folgende Dinge aufgefallen: Dir ist bewusst, dass für Baudraten höher als 115k die CPU in einem High Speed Modus geschaltet sein muss? Der standard Modus schafft das dann nicht mehr. Du bist dir auch bewusst, dass du die Baudrate von deinem Mikrocontroller aus einstellen kannst? Ich bin mir an der Stelle unschlüssig, was das Bluetooth Modul mit der Geschwindigkeitsangabe des PCs macht. Vieleicht wird sie ignoriert? Ich hoffe natürlich, dass du RTS und CTS verwendest. Vor allem bei so asynchronen Dingen wie Netzwerk und Bluetooth ist das immer Sinnvoll. Gerade bei Bluetooth mit seinen verhältnismäßig hohen Latenzzeiten (im SPP-Profil)!
Planlos schrieb: > Was ist das für eine komische Hardware, die Bluetooth über einen > Seriellen Port ansteuert? Nennt sich H4-Protokoll, wird sehr gerne verwendet, um Bluetooth auf Mikrocontroller zu implementieren, ohne einen USB Host Stack verwenden zu müssen. Siehe hierzu zum Beispiel die cc25xx von TI, ich arbeite zur zeit mit einem cc2564, welches in einem Panasonic-Gehäuse steckt (PAN1326)(wegen CE-Zertifizierung) Aber das ist hier OT!
Danke für die Erklärung Kirsch, das wusste ich nicht! Und danke für die Anmerkungen lil-b. das AT command set habe ich auf meinem µC implementiert, bisher allerdings nur bruchteile genutzt. dass ich die baudrate dort einstellen kann / muss ist mir klar. Wahrscheinlich wird die angabe vom pc dann ignoriert, zumindest in HTerm kann ich Bdratenmäßig einstellen was ich lustig bin ohne dass sich etwas ändert. Little B. schrieb: > Ich hoffe natürlich, dass du RTS und CTS verwendest. Vor allem bei so > asynchronen Dingen wie Netzwerk und Bluetooth ist das immer Sinnvoll. > Gerade bei Bluetooth mit seinen verhältnismäßig hohen Latenzzeiten (im > SPP-Profil)! das habe ich bisher nicht. mir war auch schon der verdacht gekommen, dass das eng wird (alles noch bei 115kbaud) und habe dann vorsichtshalber mal die CTS line des BT moduls mit dem oszi überwacht - und nie eine flanke gesehen. die können mir aber auch (visuell) durch die lappen gegangen sein... mir beginnt zu dämmern, dass die Bluetooth Nutzung in der jungfräulichen Weise wie es bisher bei niedrigen datenraten immer geklappt hat sich dem Ende nähert, jetzt wo ich höhere datenraten nutze.... :/
:
Bearbeitet durch User
Alex V. schrieb: > habe dann > vorsichtshalber mal die CTS line des BT moduls mit dem oszi überwacht - > und nie eine flanke gesehen. Das ist auch ein EINGANG. Du solltest Dir mal die RTS Leitung anschauen, die ist nämlich ein Ausgang.
sorry, wollte es grade korrigieren.
@Alex V. L. (bastel_alex) Benutzerseite >und nie eine flanke gesehen. die können mir aber auch (visuell) durch >die lappen gegangen sein... Dann stell mal den Trigger auf NORMAL und nicht freilaufend.
ich schaus mir grad nochmal an. nur, weil ich schon in gedanken bei der Reparatur bin: So ein halber software Handshake wäre ja ein einzeiler: Vor dem übertragen eines Bytes im µC den RTS pegel prüfen und davon abhängig senden, mehr nicht..?
Dasselbe Problem hatte ich mit dem RN-42 von Microchip. Ab etwa 57kBaud gingen auch da Daten verloren. Der Support meinte jedoch, dass das ja nicht sein könne. Wenn man ein Terminal auf dem PC offen hatte, fiel auf, dass das Terminal nach einiger Zeit mit der Datenanzeige nicht hinterher kam. Soll heißen, senden durch uC gestoppt, und mehrere 10 Sekunden lang kamen weiterhin Daten an. Vielleicht kommt Windows da auch nicht hinterher? Komischerweise gingen mit dem LMX9838 dann keine Daten mehr verloren. Es könnte also durchaus auch am BT-Modul liegen. Die Baudrate, die im Terminal möglich ist, ist unter Win7 256kBaud. Zur Baudrate unter Win8 kann ich aber nichts sagen, bin und bleibe erstmal Win7-Nutzer...
Alex V. schrieb: > So ein halber software Handshake wäre ja ein einzeiler: Vor dem > übertragen eines Bytes im µC den RTS pegel prüfen und davon abhängig > senden, mehr nicht..? Wieso nicht der Hardware überlassen? Dafür musst du doch nur den USART-Mode auf 0x2 umstellen? (ich kenne atmels nicht so gut...) Oder sind die entsprechenden Pins nicht mehr frei?
Little B. schrieb: > Wieso nicht der Hardware überlassen? Dafür musst du doch nur den > USART-Mode auf 0x2 umstellen? (ich kenne atmels nicht so gut...) > Oder sind die entsprechenden Pins nicht mehr frei? Diese Vorgehensweise bietet sich auch an, wenn der DMA für die Ausgabe benutzt wird. Denn was nützt es, den RTS-Pegel vor einer DMA-Ausgabe von xxx Bytes zu überprüfen, wenn kurz nach dem Start des DMA der RTS schaltet? Viele Grüße, Stefan
Little B. schrieb: > Wieso nicht der Hardware überlassen? Dafür musst du doch nur den > USART-Mode auf 0x2 umstellen? (ich kenne atmels nicht so gut...) > Oder sind die entsprechenden Pins nicht mehr frei? ich habe eins der UART module des atsam4s verwendet, die haben ja keine hardware rts/cts belegung. da hätte ich ein USART modul verwenden müssen, die liegen aber auf anderen pins... :(
:
Bearbeitet durch User
Felix A. schrieb: > Die Baudrate, die im Terminal möglich ist, ist unter Win7 256kBaud. Interessate Aussage. Quellen? Mich wundert es gerade, dass ich schonmal erfolgreich einen FTDI mit 3MBaud betrieben hatte. (mit Putty) Desweiteren sollte die Baudrate über Bluetooth völlig egal sein, da es nur eine Nummer ist, die zum Remote Device übertragen wird.
Also ich habe mir die RTS vom BT Modul nochmal angeschaut. Auch wenn der Trigger richtig eingestellt, d.h. nicht freilaufend ist und nur bei flanke auslöst, tut sich da nichts. Das überrascht mich jetzt auch nicht so: das BT modul hat ja einen internen fifo ringbuffer, ist auf 115kBaud eingestellt und ich gebe ihm maximal in 90µs abständen ein Byte(+Start/stop), d.h. mit 111kbit/s. Aber das heißt: An der (fehlenden) Flusskontrolle liegts nicht! Und damit bin ich wieder ratlos. Wegen Stromverbrauch etc und dem zusätzlichen Implementierungsaufwand würde ich ja eh lieber bei 115kbaud bleiben... Was bei mir nachhängt ist Kirschs Erklärung: Kirsch schrieb: > Der Bluetooth UART-Dongel sammelt erst einige Bytes um sie gebündelt zu > übertragen. > Geht dann mal ein Bluetooth-Paket verloren sind danach schon mal > 500-1000Bytes deiner Übertragung weg. > Normaler weise versucht das Bluetooth-Protokoll verlorene Pakete erneut > zu senden, aber wenn dann bereits das nächste Paket Ansteht, wird es > dann weg geworfen. > (Bluethoots hat bis zu 8168 Bit Nutzdaten pro Paket) Denn mit meinen Unit Tests habe ich ja gemessen, dass überwiegend daten in der Größenordnung von ca 837byte (inkl. Start+Stop: 8370Bit) verloren gehen - das klingt ziemlich nach genau einem Bluetooth Paket. Und dieses wird offensichtlich nicht noch einmal gesendet, wenns verloren geht. Und das alles, während die RTS Leitung still bleibt..
:
Bearbeitet durch User
Alex V. schrieb: >> Normaler weise versucht das Bluetooth-Protokoll verlorene Pakete erneut >> zu senden, aber wenn dann bereits das nächste Paket Ansteht, wird es >> dann weg geworfen. Rückfrage: Hieße das, dass ich alle pakete bekommen sollte, wenn ich so etwas wie eine paket-kontrolle implementieren würde - d.h. die daten für das nächste bluetooth paket erst an das Modul gesendet werden, wenn ein "ACK" von meiner software auf dem pc kommt nach einer validierung, weil so lange erneut gesendet wird bis es geklappt hat? Falls ja müsste ich dafür natürlich genau wissen wie groß die nutzdatenmenge ist, die ich an das BT modul schicken kann bis ein BT-Paket "voll" ist...
:
Bearbeitet durch User
Hallo Alex, ich habe mich mit den Modulen auch schon rumgeärgert, denn die firmware ist ziemlich buggy ! Flußkontrolle per RTS zum Beispiel habe ich nicht zum laufen bekommen. Der Originalhersteller ist Übriges www.ampedrftech.com/ cheers
Darum muss man sich eigentlich nicht kümmern, dass MUSS das Modul allein können! Und wenn Pakete wiederholt werden müssen MUSS das der FIFO im Modul abfangen und ggf. RTS deaktivieren. Alles was ich per UART und aktivem RTS ins Modul reinschiebe MUSS beim Empfänger auch wieder 1:1 ankommen, auch wenn Pakete mehrfach gesendet werden müssen!
Hallo Oscar, das ist ja schonmal "gut" zu hören. Hast du dann bessere alternativen in ähnlicher Größe/Preisrahmen/... gefunden? @Falk Wenn das so ist (freuen würde ich mich ja), wäre interessant, was das verhalten sonst noch erzeugen KANN? ;)
:
Bearbeitet durch User
@Little Basdart Terminal auf und gucken? Windows meckert nicht und der 115.2kBaud-uC versteht dann die Welt nicht mehr.
Angehängte Dateien:
-
HalloWelt.png
46 KB
Hier noch der Screenshot. Jumper auf Pins 2 und 3 gesteckt -> Text kommt Jumper entfernt -> Text bleibt aus Das Brücken von RX und TX am MAX3232 bei 256kBaud führt übrigens zu ... nix. Da endet sein Können.
:
Bearbeitet durch User
Hi Alex, eventuell kannst Du ja was passendes bei Bluegiga oder Laird finden. cheers
So, wen es interessiert: Die Flusskontrolle des SPBT2632C2A muss explizit eingeschaltet werden, was versteckt in der FW doku unter dem entsprechenden Befehl (der allerdings StreamingSerial heisst) steht. Default ist aus, deshalb natürlich auch keine Flanken am Oszi. Der AmpedUp Support hat ebenfalls bestätigt, dass bei dem Speed nicht mehr ohne Flusskontrolle auszukommen ist. Das StreamingSerial Enabled bedeutet nämlich, dass das Modul die eingehenden Daten im Fall eines Stops (zB bei Neusenden eines fehlerhaften Pakets) einfach verwirft. Bei meinen Datenraten ist ohne ein stop dann nicht mehr fehlerfrei zu übertragen. der interne fifo scheint also nicht allzu groß zu sein. Disabled hingegen ergibt flusskontrolle. Damit danke ich allen für die Debugging Hilfe - insbesondere die Tips von Kirsch (Bluetoothpaketlänge) und der erneute RTS-CTS Hinweis von lil-b haben mich hier weitergebracht!
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.