Servus allesammt :) Ich hab da ein kleines Problem mit meinem Arduino Board. Ich würde gerne das serielle Protokoll eines Funkempfängers (EnOcean TCM320) auf dem Arduino empfangen und weiter verarbeiten. Nur weiß ich leider nicht mit welchen Funktionen ich die Daten auf dem Arduino speichern kann um sie später weiter zu verarbeiten. Alle Beispiele die ich finde beziehen sich auf die serielle Verbindung von PC zu Arduino. Zu dem zu empfangenen Protokoll: -Baudrate 57600 -TTL Pegel 3.3V, dafür habe ich aber bereits einen Level Converter auf 5V besorgt -je nach Sender variieren die empfangenen Telegramme in ihrer Größe -ein Empfangenes Telegramm mit 35 Bytes könnte z.B so aussehe 55 00 0A 12 03 F3 A5 07 05 05 0E 01 01 F2 D8 00 03 FF FF FF FF 29 00 6B E0 00 29 Bin für jede Hilfe dankbar
Angehängte Dateien:
-
UART_framing.png
55 KB
Ok, die Funktionen waren dann recht simple^^
wollte erst einmal wissen ob ich überhaupt etwas empfange
und habe den kleinen Code geschrieben.
void setup()
{
// setzen der Baudrate des Seriellen Ports zum PC
Serial.begin(57600);
Serial.println(">>> Empfangene Daten <<<");
// Setzen der Baudrate für den EnOcean TCM320
Serial2.begin(57600);
}
//----------------------------------------------------------------------
-----------------------
void loop()
{
if (Serial2.available()) // lese von TCM320
Serial.write(Serial2.read()); // gebe aus
}
Problem ist nun noch das ich nur "Käse" ausgegeben bekomme.
Baudrate in der Konsole ist richtig eingestellt.
Also kann der Arduino die Daten wohl nicht korrekt interpretieren, woran
kann das liegen?
Georg M. schrieb: > Problem ist nun noch das ich nur "Käse" ausgegeben bekomme. Was erwartest du denn, wenn > -ein Empfangenes Telegramm mit 35 Bytes könnte z.B so aussehe > 55 00 0A 12 03 ... vom TCM320 kommt und womit versuchst du das anzugucken?
Ich lass mir das ganze im Serial Monitor in der Arduino IDE anzeigen. Da ich mit dem seriellen I/O's des Arduino noch nicht viel Erfahrung habe, hab ich erst einmal gehofft das er die DatenBits richtig interpretiert und mir die Bytes "Lesbar" ausgibt. Die Default einstellungen des Arduino ist ja 8N1, also kein parity Bit, 8 Datenbits und 1 Stoppbit. Das passt ja schonmal soweit zu dem UART framing des TCM320, nur das dieser noch ein Start Bit (logical 0) hat. Kann ich da was in den Registereinstellungen des UART meines AVR ändern/ anpassen?
Habe jetzt in der HardwareSerial.cpp folgendes gefunden.
void HardwareSerial::begin(unsigned long baud)
{
uint16_t baud_setting;
bool use_u2x = true;
#if F_CPU == 16000000UL
// hardcoded exception for compatibility with the bootloader shipped
// with the Duemilanove and previous boards and the firmware on the
8U2
// on the Uno and Mega 2560.
if (baud == 57600) {
use_u2x = false;
}
#endif
So wie es aussieht gibs es Probleme bei der Baudrate mit meinem Arduino
Mega. Also hab ich das ganze mal auskommentiert.
Bei einer Taktfrequenzen von 16MHz und einer Baurate von 57600Baud
ergibt sich ein Fehlerwahrscheinlichkeit von 2.1%.
Normal sollte der maximale Fehler nicht über 0.2% liegen.
Momentan sehen meine Empfangenen Daten so aus^^
¢ ¥Y,ÿÿÿC ¾Ù
Das kann doch nicht nur an den 2.1% liegen. O_o
Georg M. schrieb: > -Baudrate 57600 Wie kommst du darauf? Im Datenblatt des TCM steht 125kps. Oder kann man das irgendwo umstellen? Mit den Standard-Modem-Geschwindigkeiten haut das demnach sowieso nicht hin. Aber selbst wenn die Geschwindgkeit passt, passt etwas anderes nicht. Denn das Georg M. schrieb: > Momentan sehen meine Empfangenen Daten so aus^^ > ¢ ¥Y,ÿÿÿC ¾Ù sieht doch hervorragend aus. Das Problem ist, daß das: Georg M. schrieb: > 55 00 0A 12 03 F3 A5 07 05 05 0E 01 01 F2 D8 00 03 FF FF FF FF 29 00 6B > E0 00 29 BINÄR-Daten sind. Der Controller, bzw. die Empfangsauswertung deines Programms erwartet aber ASCII-Zeichen und macht halt das Beste draus. mfg.
Probier mal HTerm als Empfänger, da kannst Du Dir die Zeichen wahlweise als ASCII, hexadazimal, dezimal oder binär anzeigen lassen.
Georg M. schrieb: > Das kann doch nicht nur an den 2.1% liegen. O_o Dann überleg' dir mal, was 2.1%-Timingfehler für die Abtastung der seriellen Bits im Empfänger bedeuten: Mit der ersten Flanke des Startbits wird jedesmal synchronisiert. Wenn der Empfänger versucht, dass letzte Bit möglichst in der Mitte zu erwischen, also nach 8,5 Bitzeiten würde sich der Fehler zu nicht einmal 0,2 Bitzeiten aufsummieren. Er erwischt das achte Bit also nicht in der Mitte sondern 0,2 Bitzeiten vorher bzw. später. Bei idealen Signalen ist alles gut, solange der Zeitfehler nicht 0,5 Bit erreicht. Bei nicht zu übel verhunzten Signalen sind 2.1% als noch gut tolerierbar.
Hey Thomas, >> -Baudrate 57600 > Wie kommst du darauf? > Im Datenblatt des TCM steht 125kps. Oder kann man das irgendwo > umstellen? Die 125kps sind die Datenrate des Funksignals vom Transceiver (ASK/OOK auf 868MHz). Das serielle Protokoll hat eine Baudrate von 57600Baud. > Das Problem ist, daß das: > Georg M. schrieb: >> 55 00 0A 12 03 F3 A5 07 05 05 0E 01 01 F2 D8 00 03 FF FF FF FF 29 00 6B >> E0 00 29 > > BINÄR-Daten sind. Der Controller, bzw. die Empfangsauswertung deines > Programms erwartet aber ASCII-Zeichen und macht halt das Beste draus. Ja stimmt. Hatte gehofft das er das vll. alleine in ASCII umwandelt^^ Nachdem ich jetzt die binarys für die serielle Schnittstelle durchgegangen bin, ist mir aufgefallen das er das leider nicht macht. Also ist da noch eine Umwandlung von nöten. Weißt du zufällig mit welcher Funktion ich das bewerkstelligen kann?
Hallo Georg, evt. habe ich ja das falsche Datenblatt hier auf dem Schirm aber in dem steht auf Seite 39 eine serielle Datenrate von 9600 Bd. Ansonsten kommt ist die Umwandlung von Binär in einen Hex-String vor der Ausgabe der Daten immer sehr gut. Gruß Karl-Heinz
Georg M. schrieb: > Weißt du zufällig mit welcher Funktion ich das bewerkstelligen kann? Warum schaust du nicht in der Doku nach? http://arduino.cc/en/Serial/Write Gleich am Anfang: Wenn du nicht binär übertragen willst, dann eben nicht die write Funktion nehmen, sondern print.
Georg M. schrieb: > Weißt du zufällig mit welcher Funktion ich das bewerkstelligen kann? Keine Ahnung. Musst du dir selber schreiben. Aber das brauchst du doch gar nicht. Die Daten sind doch gar nicht zum Lesen bestimmt. Sondern um sie in einer Funktion auszuwerten. mfg. PS Was kostet so ein Modulpaar?
> PS Was kostet so ein Modulpaar?
Der TCM320 Transceiver kostet ca.30€, wenn man ihn einzeln erwirbt.
Der war bei mir beim Developer Kit von EnOcean dabei.
karl-heinz W. schrieb: > Hallo Georg, > > evt. habe ich ja das falsche Datenblatt hier auf dem Schirm aber in dem > steht auf Seite 39 eine serielle Datenrate von 9600 Bd. Habs eben nocheinmal überprüft ;) 9600Baud trifft für das ESP2 zu. (EnOcean Serial Protocol 2). Ich nutze das ESP3 mit dem TCM320, da dort mit dem Telegramm der vom Transceiver gemessene RSSI Wert übermittelt wird für alle von ihm empfangenen Subtelegramme. http://www.enocean.com/fileadmin/redaktion/pdf/tec_docs/EnOceanSerialProtocol3_V1.17.pdf siehe Seite 7
Karl Heinz Buchegger schrieb: > Georg M. schrieb: > > >> Weißt du zufällig mit welcher Funktion ich das bewerkstelligen kann? > > Warum schaust du nicht in der Doku nach? > > http://arduino.cc/en/Serial/Write > > Gleich am Anfang: > Wenn du nicht binär übertragen willst, dann eben nicht die write > Funktion nehmen, sondern print. Vielen Dank :) genau das hab ich gesucht, nur einfach nicht gefunden. Da war google einfach nicht mein Freund :P
Einen schönen guten Morgen allesamt, habe mich eben kurz nochmal meinem kleinen Problem gewidmet und dank eurer Hilfe und Tipps sieht die Ausgabe des Telegramms schon einmal etwa besser aus :) Dafür Vielen Dank. Ich bekomme nun alle empfangenen Daten in Hexadezimal ausgegeben. Hier einmal zwei empfangene serielle Telegramme eines PTM200 Schalters von EnOcean. 557183F6101F5B1B2AFFFFFF2C6AC702C305096A2C30102C9A2C30E055071820F601F5B2 32AFFFFFF2C06B282C20419A22C20179D22C5AFF 5571220D9101F5B1B1AFFFFFF2ABEB109222A6A2C8AFF5501034E0F6001F5B1B2AFFFFFF 2A03B12C2052C201525C22ADA2A20EC Damit lässt sich jeden falls schon einmal mehr anfangen. Ich werde die Daten nun parallel mit dem EnOcean Devoper Kit mitsniffern und schauen ob sich Fehler beim Arduino einschleichen. Also noch einmal vielen Dank an alle :)
Angehängte Dateien:
> Ich werde die > Daten nun parallel mit dem EnOcean Devoper Kit mitsniffern und schauen > ob sich Fehler beim Arduino einschleichen. Nachdem ich nun einige Messungen mit meinem Arduino/TCM320 Aufbau protokoliert habe und mir die Telegramme angeschaut habe muss ich leider ernüchternd feststellen, dass diese doch stark verfälscht sind. :( Parallel zu den Messungen mit dem Arduino habe ich alle Telegramme immer noch mit dem Entwicklerkit von EnOcean mit protokoliert um einen Vergleich zu haben. Viele Bytes werden verfälscht oder gar nicht ausgegeben. Ich habe nun mehrere Ideen dazu. -Der Arduino kommt mit der Verarbeitung der Daten nicht hinterher -Das Signal wird bereits auf der Übertragungsstrecke bereits gestört -Es liegt doch an den 2.01% Fehler durch die Baudrate von 57600. (Wobei mich das irgendwie wundern würde, das TCM320 Modul basiert auf einem EO3000i ASIC. In diesem kommt als Mikrocontroller ein 8051 von Siemens zum Einsatz welcher mit 16MHz getaktet ist. Also dürfte die Baudrate von 57.6kBaud bei 16MHz, mit denen auch der Arduino läuft, keine Probleme bereiten. Sonst würde EnOcean diese wohl kaum verwenden.) Was meint ihr? Hat da jemand eine Idee warum die Bytes so verfälscht werden? Im Anhang habe ich noch eine Skizze des Schaltungsaufbaus angehängt
Georg M. schrieb: > Ich habe nun mehrere Ideen dazu. > > -Der Arduino kommt mit der Verarbeitung der Daten nicht hinterher > > -Das Signal wird bereits auf der Übertragungsstrecke bereits gestört > > -Es liegt doch an den 2.01% Fehler durch die Baudrate von 57600. > (Wobei mich das irgendwie wundern würde, das TCM320 Modul basiert auf > einem EO3000i ASIC. In diesem kommt als Mikrocontroller ein 8051 von > Siemens zum Einsatz welcher mit 16MHz getaktet ist. Also dürfte die > Baudrate von 57.6kBaud bei 16MHz, mit denen auch der Arduino läuft, > keine Probleme bereiten. Sonst würde EnOcean diese wohl kaum verwenden.) > Oder 4-tens Eine Race-Condition
1 | void setup() |
2 | {
|
3 | // setzen der Baudrate des Seriellen Ports zum PC
|
4 | Serial.begin(57600); |
5 | |
6 | Serial.println(">>> Empfangene Daten <<<"); |
7 | |
8 | // Setzen der Baudrate für den EnOcean TCM320
|
9 | Serial2.begin(57600); |
10 | }
|
Geh mit der Baudrate zum PC höher! Die Übertragung zum PC muss schneller laufen als der Empfang von deinem TCM. Wenn du 1 Stunde benötigst um einen Akt zu bearbeiten und dein Chef legt dir pünktlich jede Stunde einen neuen Akt vor, dann schaffst du es gerade so lala dein Arbeitspensum zu erledigen. Da darf dann aber auch nichts dazwischen kommen! Sobald du nur die kleinste Störung hast, und wenn es nur ein paar Sekunden sind, kommt ein Prozess in Gang, bei dem du mehr Arbeit hereinbekommst als du bearbeiten kannst. Die Akten fangen an sich auf deinem Schreibtisch zu stapeln. Hat man einen Computer, der 'in der Mitte' einer Kommunikation sitzt, dann muss die Senderseite immer ein wenig schneller sein, als die Empfängerseite, damit es nicht zu dem Effekt kommt, dass durch den 'Rückstau' der noch nicht bearbeiteten Bytes etwas unter den Tisch fällt. Denn anders als bei deinem Schreibtisch, kann man nicht beliebig viele 'Akten' stapeln. Irgendwann ist auch der großzügigst dimensionierte Speicher voll mit noch nicht bearbeiteten Bytes. Das ist EIN mögliches Szenario. Das heißt nicht, dass das das Problem sein MUSS. Es kann es aber sein. Daher: eliminieren.
Ok, Fehler gefunden :) >Geh mit der Baudrate zum PC höher! Die Übertragung zum PC muss schneller >laufen als der Empfang von deinem TCM. Bin einmal mit der Baudrate zum PC höher gegangen auf 115200Baud und in der HardwareSerial.cpp bei mir war noch ein Stück Code auskommentiert. Der Fehler sitzt eben immer vor dem PC :D HardwareSerial.cpp #if F_CPU == 16000000UL // hardcoded exception for compatibility with the bootloader shipped // with the Duemilanove and previous boards and the firmware on the 8U2 // on the Uno and Mega 2560. if (baud == 57600) { use_u2x = false; } #endif try_again: if (use_u2x) { *_ucsra = 1 << _u2x; baud_setting = (F_CPU 4 baud - 1) / 2; } else { *_ucsra = 0; baud_setting = (F_CPU 8 baud - 1) / 2; } Laut Datenblatt des ATMEGA2560 liegt der Fehler bei -0.8% wenn U2XN=1 ist. Genau das macht dieses Stück Code, welches bei mir auskommentiert war. Wenn das U2XN Bit in UCSRnA gesetzt ist, läuft der ATMEGA im Double Speed Operation Modus. Werde mich jetzt mal mit dem Datenblatt auseinander setzten um die genaue Funktion dahinter zu verstehen. Nochmal vielen Dank an alle :)
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.