Hallo Leute, ich habe hier ein kleines Problem. Ich habe ein kleines Setup (Atmega168-Arduino,BTM220/222) und sende damit 55bytes an einen beliebigen Empfänger (NICHT BTM !). Das Senden wird per Interrupt vom Atmega ausgelöst. Meine RS232 ist eine "echte" Schnittstelle an meiner Dockingstation die per Bus und nicht per USB verbunden ist. Der BTM 220/222 ist auf 19200Baud konfiguriert. Folgende Test Konfigurationen habe ich mal durchgespielt. Atmega->RS232 : 55Bytes Ok Atemga->BTM220->Bluetooh PC : Datenpaket fragmentiert/zerteilt PC(RS232)->BTM220(an Max3232)->Handy : Datenpaket fragmentiert/zerteilt PC(intenes Bluetooth)->Handy : 55Bytes Ok Stelle ich nun am Sender eine verzögerung von 900ms. pro Sendevorgang ein, so werden die Daten korrekt und als ein "Paket" empfangen. Kann es sein das der BTM220/222 auf UART nicht mehr Daten verarbeiten kann ? Der BTM wird ja auch gerne zur Steuerung von Flugmodellen benutzt, wird da mit weniger Daten gearbeitet ? Ich habe 3 verschiedene BTM220 und 1 BTM222 auf einem BlueController probiert.Überall die gleich Ergebnisse. Das Datenblatt ist ja leider nicht das aussagekräftigste. Kennt jemand dieses Phänomen,hat jemand ein Workaround oder ne Idee was ich ggf. falsch machen könnte ? Und zu guter letzte, kennt jemand ein anderes Class1 BluetoothModul das sich in dem Bereich anders verhält ? Danke im voraus, Ingo
Sende mehr Bytes. Eventuell wartet das BTM oder der Empfänger darauf, dass ein Bluetooth Frame voll wird, bevor die Daten über die Luft transportiert werden.
Moin, danke für die Idee. Ich habe jetzt mal ein paar Pakete ab 128Bytes abwärts probiert. Immer noch das selbe Problem. Auch die gängigen Grüßen 2,4,8,16,32,64,128 führen zu Fragmenten in den Daten.Mal ist das erste Paket 1 Byte lang, dann wieder 2 Byte etc. Mein Sende-Pakete hab ich auf 100Byte festgelegt. Auf Android 2.3.3 scheint der Bluetooth-Buffer vom verwendeten Buffer im ConnectedThread (Bluetoohchat Andoird-SDK Beispiel) abzuhängen, da Logcat ausgibt wieviel Pakete er vom Buffer empfängt (2 of 100 etc. Auch hier hat eine Anpassung nix gebracht. Bei 4.x bekomme ich leider keine Aussage vom BluetoothSocket.cpp wieviel Bytes er erwartet und davon empfängt. Hat jemand noch eine Idee für mich ? Nebenbei meine BTM220a Einstellungen : OK ATC=0, NONE FLOW CONTROL ATD=0000-00-000000, NEVER SET BLUETOOTH ADDRESS ATE=0, NEVER ECHO CHARACTERS ATG=1, ENABLE ALL PAGE AND INQUIRY SCAN ATH=1, DISCOVERABLE ATK=0, ONE STOP BIT ATL=2, BAUD RATE is 19200 ATM=0, NONE PARITY_BIT ATN=NAME, LOCAL NAME ATO=0, ENABLE AUTO CONNECTING ATP=1234, PIN CODE ATQ=1, NEVER SEND RESULT CODE ATR=1, SPP SLAVE ROLE ATS=1, ENABLE AUTO-POWERDOWN OF RS232 DRIVER ATX=0, NEVER CHECK '+++' F/W VERSION: v4.35
Mir ist nicht so ganz klar, was überhaupt der Fehler ist... Was heißt bei dir "Datenpaket fragmentiert/zerteilt"? Es gehen Daten verloren bzw. kommen fehlerhaft an? Ich benutze auch BTM222s mit Android Bluetoothchat und hab damit keine Probleme. Allerdings sende ich hauptsächlich vom Handy zum uC um damit Sachen zu steuern. Aber auch den Rückweg habe ich schon mit kleinen "Paketen" getestet und konnte bislang keine Fehler feststellen. Die Module verwende ich in den Standardeinstellungen. Was ist der Unterschied zwischen BTM220a und BTM222? Hast du schon mal ein anderes Modul probiert? Also mit den Modulen von Octamex hab ich bislang keine Probleme...
Was meinst Du mit "paket" und mit "fragmentiert"? Bei Ethernet gibt es Pakete mit definierter länge. Dort versteht man unter Fragmentierung, dass die ursprünglich gesendeten Pakete in mehrere kleinere Pakete ausgespalten werden. Aber bei UART gibt es keine Pakete - jedenfalls nicht in diesem Sinne.
Ist dein BT-Modul vielleicht etwas schwach auf der Brust? Oder zu empfindlich? Wenn die Frequenzen stark belegt sind, könnte es sein, dass es einfach etwas dauert, bis mal eine Lücke frei ist. Ansonsten kann ich dieses Verhalten auch nicht nachvollziehen. Habe vor ein paar Wochen mit zwei BTM-222 eine Funk-RS232 aufgebaut, die weitestgehend transparent ist. Dabei ist mir keine nennenswerte Latenz aufgefallen.
Ich schätze, er hat verzögerungen in der Datenübertragung bemerkt. Das ist ganz normal - kann durchaus zeitweise auch mehrere hundert Millisekunden dauern. Ich habe diese Verzögerungen des öfteren beobachtet, in Zusammenhang mit einem manuell ferngesteuerten Roboter. Bedenke, dass WLAN Geräte und Mikrowelenöfen im gleichen Frequenzband senden. Manchmal müssen die Bluetooth Geräte auf eine "Sendepause" warten, um selbst zu Wort zu kommen. Dazukommt, dass Bluetooth Paketorientiert arbeitet (wie auch analoge Modems). Die Geräte "sammeln" einzelne Bytes ein, schnüren daraus Pakete mit Prüfsumme und senden sie erst dann. Der Empfänger packt die Pakete wieder aus und gibt die darn enthaltenen Nutzdaten seriell aus. Bei wiederholten Übertragunsgfehlern brechen Bluetooth Module (wie auch Modems) die Wiederholungsscheife ab und geben notfalls ein (bewusst) fehlehafte Bytes aus. Deswegen kommst Du nicht umhin, eine Fehlerkennung auf Applikations-Ebene zu programmieren. Es sei denn, gelegentliche Fehler sind tolerierbar - kann ja gut sein. Bei der Umsetzung von einem seriellen Protokoll auf ein anderes enstehen zwangsläufig Übertragungspausen. Du solltest empfangsseitig nicht erwarten, das gleiche pausen-timing zu erhalten, wie es gesendet wurde. Das ich auch bei seriellen USB Adaptern so, die "versauen" auch das Timing. Nicht weil sie mangelhafte Qualität haben, sondern weil es nicht anders geht. Wenn Du Pakete schnüren willst, dann sende entsprechende Rahmen. Zum Beispiel so: - Start Markierung "PKG" - Anzahl der Daten-Bytes - Daten Bytes - Prüfsumme Beim Empfänger kannst Du dann den Beginn eines Paketes (auch nach einer Übertragungsstörung) zuverlässig erkennen, und du weisst auch immer, auf wieviele Bytes du noch warten musst. Und Du kannst die Daten anhand der (optionalen) Prüfsumme auf Richtigkeit überprüfen.
Hier steht einiges zum Thema Latenzen und Bluetooth, auch Strategien zum Umgang damit: http://www.free2move.se/?page_id=1058
Stefan Frings schrieb: > Was meinst Du mit "paket" und mit "fragmentiert"? Moin, also mir ist aufgefallen das meine "Paket" aus 55Bytes (inkl.Frame) im Bluetoothchat (ohne RingPuffer) in mehreren Teilen ankommt. Sogar das zuerst gesendete. Meistens das erste Byte des Headers, dann zwischen 20 und 40 bytes Daten und im dritten Teil der Rest. Manchmal kommt es auch zu überlappungen von hintereinander folgenden Paketen. Android arbeiten mit einem InputStream und einen Empfangspuffer. Sobald im Buffer eine "-1" empfangen wird, wird eine Message versendet. Logge ich jetzt im Inputstream die Zeit, so kann ich einen Versatz von 40-90ms. zwischen den einzelnen Teilen erkennen. Am PC unter Putty kann man diesen Versatz natürlich nicht erkenne, da ja kein Timestamp mitgeliefert wird und die Daten einfach hintereinander gereiht werden. Bei HTerm stelle zusätzlich ich einen (scheinbar internen) Versatz von 16ms fest.Sowohl über RS232/USB als auch über "echtes" RS232. Stelle ich die "Sende" Frequenz im Atmega auf 900ms. werden alle Pakete korekt empfangen.Dies ist aber nicht praktikabel. Ich werde mir mal den Link von Stefan zu gemüte führen und komme hoffentlich heute Abend dazu einen RingPuffer in den BluetoothChat zu integrieren. Danke schon mal für eure Ideen und frohe Ostern, Ingo
Am einfachsten wäre es definitiv, wenn du hier Code + Schalplan posten würdest. Nachdem du in deinem Code definitiv irgendwie Mist baust, könnte man dir da helfen. Wenn du aber immer nur beschreibst wie es gehen sollte und nie was zur Fehleranalyse beiträgst kann man dir auch schlecht helfen.
Die Geräte, die ein bestimmtes Timing bei der seriellen Übertragung erwarten, sind genau die, die an USB Adaptern nicht mehr funktionieren. Das wir alle gelernt haben, diese Geräte zu hassen, muss ich sicher nicht extra erwähnen.
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.