Hallo zusammen, ich arbeite gerade an einem Funkmodul auf Basis des TI CC1101, welches EnOcean Funk senden und empfangen können soll. Das Problem ist derzeit, dass ich keine Einstellung am CC1101 hin bekomme, die ein sinnvolles Ausgangssignal ergibt. Zunächst folgende Hintergrundinformationen: Derzeit besteht meine Testumgebung aus einem EnOcean USB300 Modul, über das vom PC aus mittels DolphinView EnOcean Pakete gesendet werden. Ein CC1101 Modul wird von einem AVR aus in den synchronen seriellen Modus gebracht, so dass an einem Ausgang die Rohdaten des demodulierten Funksignals mittels Oszilloskop beobachtet werden können. Die Register-Einstellungen des CC1101 sind mittels SmartRF Studio ermittelt (ASK; 868,3MHz; 125kbps; ...) und werden vom AVR in den Transceiver geladen. Die grundsätzlichen Einstellungen (also auch der Zugriff AVR zu CC) scheinen zu funktionieren, da ich am seriellen Ausgang des Transceivers beobachten kann, wenn ich Pakete vom PC aus sende. Das Problem ist, dass diese Pakete weder der EnOcean Funk-Spezifikation entsprechen (ISO IEC 14543-3-10) noch reproduzierbar sind. Die Bits scheinen innerhalb des Pakets wahllos verteilt, wenn vom PC aus mehrfach das gleiche Paket verschickt wird. Ich gehe davon aus, dass meine Einstellungen am Transceiver noch nicht 100%ig stimmig sind. Daher meine Frage: Hat jemand schon mal erfolgreich mit einem Baustein der CC11xx Serie den EnOcean Funk aufgebaut? Bin für jeden Tipp dankbar! Beste Grüße, Alex
Verschlüsselung? Bist du dir sicher, dass man Enocean-Transceiver "so einfach" nachbauen kann (abgesehen von möglichen patentrechtlichen Erwägungen)? Gibt es irgendwo im Netz schon einen Nachbau mit Nicht-Siemens-Transceivern? Grüße Robert
Hallo Robert, vielen Dank für die schnelle Antwort! Prinzipiell ist der EnOcean Funk seit Mitte letzten Jahres offen gelegt und standardisiert (http://www.enocean.com/de/enocean-wireless-standard/). Damit gibt es da nach meinem Verständnis keine (patent-)rechtlichen Probleme. Zudem haben wir den Standard auch offiziell gekauft und sind EnOcean Alliance Mitglied. Verschlüsselung kommt bei dem Paket, welches ich sende, nicht zum tragen. Das gleiche (nicht deterministische) Verhalten ergibt sich auch bei einem EnOcean Taster, der ebenfalls nicht verschlüsselt ist. Da uns, wie oben erwähnt, die komplette Spezifikation vorliegt, ist recht eindeutig, wie die Pakete auf Bit-Ebene definiert sind. Ich habe bisher kein Projekt gefunden, bei dem ein EnOcean Transceiver nachgebaut wurde. Der Beitrag "EnOcean Protokoll auf der Funkstrecke" ist mir bekannt, liefert aber keine Informationen zu meinem Problem. Dort wurde das Protokoll analysiert, als es noch nicht offen gelegt war. Schöne Grüße, Alex
Ok, das ISO habe ich mir jetzt mal angeschaut. In der Tat erstmal alles drin. In Kenntnis der invertierten Bits erklärt sich auch die undurchsichtige Encodierung der Nibbles auf der ersten Seite des PDFs... g Hast du die Möglichkeit über ein schnelles Oszi die gesendete ASK anzuschauen? Um Verständnisprobleme vom Parametrierungsproblem des CC1101 zu unterscheiden. ;-) Stell mal die gewählten Parameter bzw. das Headerfile rein - evtl. kann ich die mal in einen CC101 laden und schauen. Allerdings sind meine TCM310/TCM300 Module noch ungenutzt. Was mich - trotz dem Bewusstsein, dass bei einer ASK nichts großes dabei ist - stutzig macht, ist dass noch kein Bastler die Enocean-Transceiver nachgebaut hat... Grüße Robert
Hi Robert, auf Sender-Seite kann ich leider nichts oszillographieren. Die EnOcean Module (zumindest die mir vorliegenden) sind zu gut gekapselt, als dass man da ran käme. Und für die Messung des modulierten Signals am Antennenausgang fehlt mir passende Messtechnik. Ich habe allerdings noch sehr gute Kontakte zur Uni, so dass ich nächste Woche dort vorbei schauen könnte. Meine Konfiguration werde ich morgen mal einstellen. Ich habe mit einigen Parametern rumgespielt, isb. was die Filter-Bandbreite angeht. Allerdings kam es da zu keinen spürbaren bzw. messbaren Verbesserungen. Es gibt außerdem ein DN von TI zum Thema ASK und CC-Transceivern (http://www.ti.com/lit/an/swra215e/swra215e.pdf), welches ich in die Konfiguration habe einfließen lassen. Mich wundert es auch, dass bisher gar nichts in der Richtung im Netz zu finden ist. Scheinbar verwenden alle die fertigen EnOcean Module, die allerdings preistechnisch und bei in unseren Produkten auch platztechnisch, nicht wirklich attraktiv sind. Wie gesagt, morgen folgt die Konfiguration! Schönen Abend! Alex
Guten Morgen, wie angekündigt hier meine CC1101 Konfiguration:
1 | cc1101RegisterWrite(CC1101_IOCFG2, 0x0C); |
2 | cc1101RegisterWrite(CC1101_IOCFG1, 0x2E); |
3 | cc1101RegisterWrite(CC1101_IOCFG0, 0x0B); |
4 | cc1101RegisterWrite(CC1101_FIFOTHR, 0xC7); |
5 | cc1101RegisterWrite(CC1101_SYNC1, 0); |
6 | cc1101RegisterWrite(CC1101_SYNC0, 0); |
7 | cc1101RegisterWrite(CC1101_PKTLEN, 0xFF); |
8 | cc1101RegisterWrite(CC1101_PKTCTRL1, 0x00); |
9 | cc1101RegisterWrite(CC1101_PKTCTRL0, 0x12); |
10 | cc1101RegisterWrite(CC1101_ADDR, 0x00); |
11 | cc1101RegisterWrite(CC1101_CHANNR, 0x00); |
12 | cc1101RegisterWrite(CC1101_FSCTRL1, 0x06); |
13 | cc1101RegisterWrite(CC1101_FSCTRL0, 0x00); |
14 | cc1101RegisterWrite(CC1101_FREQ2, 0x20); |
15 | cc1101RegisterWrite(CC1101_FREQ1, 0x28); |
16 | cc1101RegisterWrite(CC1101_FREQ0, 0xC4); |
17 | cc1101RegisterWrite(CC1101_MDMCFG4, 0xDC); |
18 | cc1101RegisterWrite(CC1101_MDMCFG3, 0x2F); |
19 | cc1101RegisterWrite(CC1101_MDMCFG2, 0x30); |
20 | cc1101RegisterWrite(CC1101_MDMCFG1, 0x21); |
21 | cc1101RegisterWrite(CC1101_MDMCFG0, 0xE5); |
22 | cc1101RegisterWrite(CC1101_DEVIATN, 0x14); |
23 | cc1101RegisterWrite(CC1101_MCSM2, 0x07); |
24 | cc1101RegisterWrite(CC1101_MCSM1, 0x30); |
25 | cc1101RegisterWrite(CC1101_MCSM0, 0x18); |
26 | cc1101RegisterWrite(CC1101_FOCCFG, 0x16); |
27 | cc1101RegisterWrite(CC1101_BSCFG, 0x6C); |
28 | cc1101RegisterWrite(CC1101_AGCCTRL2, 0x04); |
29 | cc1101RegisterWrite(CC1101_AGCCTRL1, 0x00); |
30 | cc1101RegisterWrite(CC1101_AGCCTRL0, 0x92); |
31 | cc1101RegisterWrite(CC1101_WOREVT1, 0x87); |
32 | cc1101RegisterWrite(CC1101_WOREVT0, 0x6B); |
33 | cc1101RegisterWrite(CC1101_WORCTRL, 0xFB); |
34 | cc1101RegisterWrite(CC1101_FREND1, 0x56); |
35 | cc1101RegisterWrite(CC1101_FREND0, 0x11); |
36 | cc1101RegisterWrite(CC1101_FSCAL3, 0xEA); |
37 | cc1101RegisterWrite(CC1101_FSCAL2, 0x2A); |
38 | cc1101RegisterWrite(CC1101_FSCAL1, 0x00); |
39 | cc1101RegisterWrite(CC1101_FSCAL0, 0x1F); |
40 | cc1101RegisterWrite(CC1101_RCCTRL1, 0x41); |
41 | cc1101RegisterWrite(CC1101_RCCTRL0, 0x00); |
42 | cc1101RegisterWrite(CC1101_FSTEST, 0x59); |
43 | cc1101RegisterWrite(CC1101_PTEST, 0x7F); |
44 | cc1101RegisterWrite(CC1101_AGCTEST, 0x3F); |
45 | cc1101RegisterWrite(CC1101_TEST2, 0x88); |
46 | cc1101RegisterWrite(CC1101_TEST1, 0x31); |
47 | cc1101RegisterWrite(CC1101_TEST0, 0x09); |
Hi Alexander, aus Interesse: Bist du erfolgreich gewesen? Ich habe mich jetzt mangels Zeit erst einmal für den einfachen Weg entschieden und ein EDK350 geordert. Grüße Robert
Hi Robert, nein, bisher leider kein Erfolg zu verzeichnen. Habe mich aber auch nicht mehr sehr intensiv damit beschäftigt. Anfang nächster Woche habe ich wieder Zeit, an dem Projekt weiter zu arbeiten. Prinzipiell müsste man eine Transceiver-Einstellung finden, bei der am asynchronen seriellen Ausgang der Datenstrom des demodulierten EnOcean Protokolls zu erkennen ist. Leider kann man aufgrund der Struktur des EnOcean Protokolls keinerlei Hardwareunterstützung des Transceivers nutzen. Soweit ich mich umgeschaut habe, gibt es auch keinen Transceiver auf dem Markt, der dies leisten könnte (abgesehen von den EnOcean eigenen SoCs). Man muss also die Preamble und den Rest des Paketinhalts in Software anhand von Flankenwechsel detektieren. Prinzipiell möglich, aber wie es mit der Zuverlässigkeit und der Energiebilanz aussieht, ist die andere Frage. Beim Versenden von Paketen könnte ich mir vorstellen, diese vorher entsprechend zu packen und in den FIFO des CC1101 zu laden und dann zu versenden. Hab es aber noch nicht durchgespielt und vermute nur, dass es klappen könnte. Ansonsten besteht wieder die Möglichkeit, die Daten seriell einzuspeisen, was aber wieder recht hohe Anforderungen an die I/O-Verarbeitung des µCs stellt. Alles in allem keine sehr reizvollen Aussichten. Aber alle auf dem Markt vorhandenen "offenen" Funkstandards sind entweder gar nicht so offen wie man erwartet (z.B. Abhängigkeit von einem HW-Lieferanten) oder haben einige technische Nachteile (z.B. ZigBee: hoher Speicherbedarf). Wenn ich nächste Woche noch relevante Fortschritte erziele, werde ich diese gerne teilen. Schöne Grüße, Alex
Hi Alex, wollt mal wissen obs da schon was neues gibt? Ich stehe vor dem selben Problem, muss mit nem cc1101 EnOcean auslesen, senden ist mir egeal. Auch bei mir ist nix brauchbares rausgekommen. Gruß, Michi
Hallo Alex, wie ist der aktuelle Stand? Hattest du erfolg? Wenn ja, wäre es auch möglich MRF89XAM8A von Microchip für die Datenübetragung zu verwenden? Gerade die Stromaufnahme im Rx Mode liegt hier deutlich (Faktor 10) unter dem vom TCM300. LG, Alex
Die Config funktioniert nur mit externem 27MHz Quarz. Auf vielen Referenzdesigns sind aber 26MHz Quarze verbaut und dann würde man bei 836140258,8 MHz landen. Bei einem 26MHz Quarz muss man das nehmen: 21656A wäre für FREQ2 FREQ1 FREQ0 ggf ok und entspricht 868299865,7 MHz Weiß denn jemand, ob die 868,3MHz überhaupt stimmen? Wenn ich mit einem Oszi messe, sehe ich den Maximalausschlag im Bereich von 868,275 - 868,282 MHz.
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.