Selbstbau CUN (MapleCUN)

[A.Harrenberg]

Hallo Telekatz!

Ja, das scheint es gewesen zu sein!

Das Logfile sieht jetzt schon fast gut aus...
Unter normalen Umständen wird jetzt das /n gesendet. Ich habe aber gerade noch ein paar Zeilen gefunden die recht lang sind und dann nicht vollständig ausgegeben werden und dann das /n auch wieder fehlt. Im Log weiter unten ist das z.B. die zweite Zeile und weiter unten noch mal.

Code Auswählen Erweitern

100k: 7d9f6d26ee5e5a43eff65fb75e0feeffabf7ebdbf7bf56efebc7dbfeffffa2fe97fdbdfefff8fffffff771fc7f5b99fefd803fd7ea367c7edc7ff63fd1ffc3d33773ed, CS **
100k: de563aed57d47e3ff8dbd6bfff7fcc7e7053713ff3bf6fdebf6b149fb73d5eeff7ad1affffbddf2fe3ffefff19fffadf2bff5dffdf1fe47af5fe2e97f6dff7, CS **not** ok!

Was mich hier wundert ist das ich die lange Zahl ja einzeln ausgebe und danach noch mal "CS ok\n" oder "CS **not** ok!\n" anhänge, d.h. es dürfte eigentlich auch kein Bufferüberlauf stattfinden.
Ich habe noch ein paar weitere Nachrichten kontroliert, die sind alle genauso lang.

Allerdings scheint das mit dem "Weiterleiten" über den UART oder meinem Logging-Modul zu tun zu haben. Bei direktem logging an der DBG Schnittstelle gibt es teilweise VIEL längere Nachrichten die korrekt mit /n beendet werden.

Ist Dir im Code für die UART Schnittstellen vielleicht irgendwas bewusst was eine Längenbegrenzung verursachen würde? Im logging-Modul ist eigentlich nichts drin was das hervorrufen dürfte.

Code Auswählen Erweitern

2017.04.14 18:59:37.903 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:41.022 5: slog: 100k: 7d9f6d26ee5e5a43eff65fb75e0feeffabf7ebdbf7bf56efebc7dbfeffffa2fe97fdbdfefff8fffffff771fc7f5b99fefd803fd7ea367c7edc7ff63fd1ffc3d33773ed, CS **n100k: Discarding msg, dac59affd8fd0caa ,len:170
2017.04.14 18:59:42.455 5: slog: 100k: Discarding msg, cf2d213c9b6e5bfb ,len:251
2017.04.14 18:59:43.417 5: slog: 100k: msg received with len:109
2017.04.14 18:59:43.417 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:43.563 5: slog: 100k: msg received with len:059
2017.04.14 18:59:43.563 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:43.563 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:43.565 5: slog: 100k: 647e57b78f98e63bf12edfbc3e7ffdff797dbf77f477f62bfff78faff33eff9bcfadb7f19efa1cffb7ddfdfff2e6dff7f7e7df52eb50d67bffaf9f, CS **not** ok!
2017.04.14 18:59:48.237 5: slog: 100k: msg received with len:063
2017.04.14 18:59:48.237 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:48.237 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:49.771 5: slog: 100k: de563aed57d47e3ff8dbd6bfff7fcc7e7053713ff3bf6fdebf6b149fb73d5eeff7ad1affffbddf2fe3ffefff19fffadf2bff5dffdf1fe47af5fe2e97f6dff7, CS **not** ok!100k: msg received with len:103
2017.04.14 18:59:49.771 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:51.535 5: slog: 100k: Discarding msg, 7dd7fd3fddbcdffd ,len:253

Auf jeden Fall schon mal vielen Dank für die Lösung mit _printf!
Andreas.

[Telekatz]

Wenn deine Debug Nachrichten während eines Durchlaufs des rf_zwave_task länger als 256 Bytes werden, läuft der serielle Empfangspuffer voll. Geleert wird der erst wieder in der main loop im cdc_uart_task.

Du könntest versuchen, die TTY_BUFSIZE in board.h zu erhöhen.

[A.Harrenberg]

Hi,

Wenn deine Debug Nachrichten während eines Durchlaufs des rf_zwave_task länger als 256 Bytes werden, läuft der serielle Empfangspuffer voll. Geleert wird der erst wieder in der main loop im cdc_uart_task.

das kann ich nicht ganz ausschliessen, aber glaube es eigentlich nicht. Die "Grenze" liegt ja anscheinend bei 148 bytes, danach geht es ja auch nicht mit irgendwelchem Müll weiter, sondern mit dem nächsten String. Und bis 256 ist da ja noch ein wenig "Platz"...

Du könntest versuchen, die TTY_BUFSIZE in board.h zu erhöhen.

Werde ich mal probieren, ich schau auch mal in den cdc_uart_task, vielleicht kann ich da auch ein paar Debug-Zeilen einfügen um zu sehen wann da was passiert.
Aber das ist erst mal Nebenschauplatz.

Gruß,
Andreas.

[Telekatz]

Hi,das kann ich nicht ganz ausschliessen, aber glaube es eigentlich nicht. Die "Grenze" liegt ja anscheinend bei 148 bytes, danach geht es ja auch nicht mit irgendwelchem Müll weiter, sondern mit dem nächsten String. Und bis 256 ist da ja noch ein wenig "Platz"...
Werde ich mal probieren, ich schau auch mal in den cdc_uart_task, vielleicht kann ich da auch ein paar Debug-Zeilen einfügen um zu sehen wann da was passiert.
Aber das ist erst mal Nebenschauplatz.

Gruß,
Andreas.

Da der Puffer während des rf_zwave_task nicht geleert wird, zählen alle Debugausgaben zu den 256 Bytes:

Code Auswählen Erweitern

2017.04.14 18:59:48.237 5: slog: 100k: msg received with len:063
2017.04.14 18:59:48.237 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:48.237 5: slog: 100k: reading bytes from CC1100: done
2017.04.14 18:59:49.771 5: slog: 100k: de563aed57d47e3ff8dbd6bfff7fcc7e7053713ff3bf6fdebf6b149fb73d5eeff7ad1affffbddf2fe3ffefff19fffadf2bff5dffdf1fe47af5fe2e97f6dff7, CS **not** ok!100k: msg received with len:103
Bis zum Ausrufezeichen sind das inklusive Zeilenumbrüche 256 Bytes.

[A.Harrenberg]

Hallo Telekatz,

ich würde gerne zu Debugzwecken das Signal GDO0 von den CC1100 Modulen nutzen. In ZWave ist der Pin vom cc1100 standardmäßig als 3-state definiert. Ich finde aber nicht wie/wo die IO-konfiguration für GDO0 (oder auch GDO2) beim Maple gemacht wird.

Für CS finde ich in cc1100.c:

Code Auswählen Erweitern

#ifdef USE_HAL
  hal_CC_GDO_init(CC_INSTANCE,INIT_MODE_OUT_CS_IN);
#else
  EIMSK &= ~_BV(CC1100_INT);                 
  SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN ); // CS as output
#endif
Das gleiche dann noch mal in rf_zwave.c:

Code Auswählen Erweitern

#ifdef USE_HAL
hal_CC_GDO_init(CC_INSTANCE,INIT_MODE_OUT_CS_IN);
#else
  SET_BIT( CC1100_CS_DDR, CC1100_CS_PIN );
#endif
Für GDO0 oder GDO2 finde ich keine explizite Initialisierung.

Auf der Platine von Ranseyer wäre das für
CC0 -> CC_OUT_0 = Pin 10 = PA1
CC1 -> CC_OUT_1 = Pin 17 = PB5
CC2 -> CC_OUT_2 = Pin 13 = PC14
CC3 -> CC_OUT_3 -> existiert nicht

Kann ich mich darauf verlassen das die drei Pins auf Input (oder im 3-state mode) sind? Ich möchte nicht unbedingt den cc1100 als Ausgang schalten wenn der Maple den Pin auf Output gesetzt hat.

Wäre nett wenn Du mir hier noch weiterhelfen könntest wo (und wie) die HW-Initianlisierung stattfindet.

Danke,
Andreas.

[Telekatz]

Die Initialisierung der drei GDO Pins des Maples erfolgt in hal_CC_GDO_init. Mit dem Parameter INIT_MODE_OUT_CS_IN wird der Pin für GDO0 am Maple als Ausgang und der Pin für GDO2 als Eingang konfiguriert. Wenn du beide Pins als Eingang definieren möchtest, verwende den Parameter INIT_MODE_IN_CS_IN.

[A.Harrenberg]

Hi,

Die Initialisierung der drei GDO Pins des Maples erfolgt in hal_CC_GDO_init. Mit dem Parameter INIT_MODE_OUT_CS_IN wird der Pin für GDO0 am Maple als Ausgang und der Pin für GDO2 als Eingang konfiguriert. Wenn du beide Pins als Eingang definieren möchtest, verwende den Parameter INIT_MODE_IN_CS_IN.

danke für die RM. Da bin ich aber froh das ich nicht einfach davon ausgegangen bin das der Pin Input/3-state ist...

Ich bin gar nicht auf die Idee gekommen das in dem Codewort alle drei Signale drin stecken, wobei das jetzt mit dem Namen sogar logisch ist.
Vielleicht wäre es sogar eine gute Idee in rf_zwave.c das "INIT_MODE_IN_CS_IN" in den Code zu übernehmen. Der Pin wird in zwave nicht genutzt und kann deshalb auch genausogut Input sein, was im Zweifelsfall besser ist als Output.

Noch eine weitere Frage: Gibt es in der Firmware ein globales Zeitsignal bzw. ein forlaufender Counter den man jederzeit abfragen kann? Ich würde gerne an ein paar Stellen im Code abfragen um eine Zeitabschätzung vornehmen zu können. Momentan logge ich mit einem LogicAnalyser die Pins zu den cc1100 und sehe da teilweise recht lange "Pausen" von etlichen millisekunden die ich mir nicht so wirklich erklären kann.

Danke,
Andreas.

[Telekatz]

Über HAL_GetTick() gibt es eine Counter mit 1 ms Auflösung. Wenn du eine größerer Auflösung benötigst, müsstest du dir etwas mit dem Cycle Count Register DWT->CYCCNT erstellen.

[A.Harrenberg]

Hi Telekatz,

Vielleicht wäre es sogar eine gute Idee in rf_zwave.c das "INIT_MODE_IN_CS_IN" in den Code zu übernehmen. Der Pin wird in zwave nicht genutzt und kann deshalb auch genausogut Input sein, was im Zweifelsfall besser ist als Output.

ich bin jetzt definitiv der Meinung das "INIT_MODE_IN_CS_IN" der Default sein sollte. In rf_zwave_init() wird ein reset befehl an den CC1100 geschickt und danach werden die Kontrollregister beschrieben.
Der Default nach Reset für die Konfiguration des GDO0 ist aber 0x3F, was einem Output von CLK_XOSC/192 enstpricht. D.h. solange bis das Register neu mit 0x2e (3-State) beschrieben wurde arbeiten die Ausgänge von Maple und CC1100 gegeneinander.

Ich kann nämlich jetzt nach dem Reset schön das Taktsignal sehen bis dann das Register neu beschrieben wird.

Gruß,
Andreas.

[locutus]

Hallo zusammen,

ich möchte euch meine Version des MapleCUL in Form eines USB-Sticks vorstellen.
Der USB-Stick besteht in wesentlichen aus einem STM32-Mikrocontroller und einem CC1101 Funkmodul. Weitere Merkmale:
- optionaler zweiter CC1101 Transceiver
- BOOT und RESET Taster
- 4 pol. Debug- und Programmierschnittstelle
- UART (TX1/RX1) Erweiterung
- LED Indicator
- optionale SMA-Buchse(n)
- a-culfw
Abmessungen ohne USB-Stecker (LxB): 50 x 18 mm

Zum Programmieren der a-culfw Firmware ist ein zusätzlicher USB zu TTL Wandler mit 3.3V Logik zwingend erforderlich.
Firmware bauen:

Code Auswählen Erweitern

make clean
make MapleCULx4
Firmware (Bootloader freie Version) flashen:
- GND/3V3/RX/TX am MapleCUL mit einem USB zu TTL Adapter verbinden.
- USB zu TTL Adapter mit dem PC verbinden.
- Taste BOOT am MapleCUL drücken und gerdückt halten.
- Taste RST am MapleCUL drücken.
- Tasten loslassen.
- STM32 Flash loader demonstrator starten.
- COM Port des USB zu TTL Wandlers auswählen, Baud Rate 115200, Parity Even, Echo Disabled, Timeout 1.
- Auf Next drücken.
- Es sollte die Meldung erscheinen: Target is readable. Please click "Next" to proceed.
- Auf Next drücken.
- Auf Next drücken.
- Download to device auswählen.
- Datei MapleCULx4.bin öffnen.
- Erase necessary pages auswählen.
- Auf Next drücken.
- Warten bis Flashvorgang abgeschlossen ist.
- USB zu TTL Adapter vom MapleCUL entfernen.

Der erste Transceiver wird als CUL angelegt.

Code Auswählen Erweitern

define mapleCUL1 CUL /dev/ttyACM0@38400 0123
Der zweite Transceiver wird als STACABLE_CC angelegt.

Code Auswählen Erweitern

define mapleCUL2 STACKABLE_CC mapleCUL1

Im Anhang Gerberdaten, Warenkorb (Stückliste) und Schaltplan für Interessierte, die auch gern selbst mal wieder zum Lötkolben greifen wollen.
Bezugsquelle für ...
unbestückte Leiterplatte(n): ITEAD Studio
Bauteile: Reichelt Elektronik
CC1101 Funkmodul: eBay
2 Pin Push Button 4 x 3 x 1.8 mm: eBay

Die Verwendung der Daten für kommerzielle Zwecke, Herstellung oder gewerblichen Vertrieb ist untersagt.

[juergs]

Hallo Locutus,

hättest Du noch eine Leerplatine für mich übrig?

Grüße,
Jürgen

[locutus]

Leider nein! Nur Fertiggeräte sind in begrenzter Stückzahl verfügbar.
https://forum.fhem.de/index.php/topic,65998.0.html

[RaspiLED]

Guten Morgen,
nachdem mein erster Maple CUL jetzt produktiv läuft ich aber parallel auch mal über einen originalen Busware Stick gefallen bin, habe ich mir die Wikis im Detail durchgelesen. Dabei ist mir aufgefallen, dass das Attribut model CUN beim Maple noch gar nicht diskutiert wurde und nicht im Wiki steht. Konkret:


1.) Wozu wird das attr model überhaupt verwendet?
2.) Brauchet der Maple CUL (Platine ohne Ethernet) ein CUL oder ein CUN?
3.) Brauchet der Maple CUN (Platine mit Ethernet WS5100 oder WS5500) ein CUL oder ein CUN oder müssten wir sogar zwei neue definieren lassen?

Danke für Eure Klärung!

Gruß Arnd

[kleo]

Hallo , ich bin relativer FHEM-Neuling und habe mich am Zusamenbau eines MapleCUL versucht.
Ich habe einen 868MHz CC1101 als ersten und einen 433MHz CC1101 als zweiten Transceiver verbaut.

Ich habe alles nach Wiki und Forumsbeitrag eingerichtet (insbesondere den zweiten Transceiver als gestackt angelegt).
Das scheint auch soweit zu funktionieren. Der erste Transceiver ist im MAX Modus und empfängt meine Thermostate und Türkontakte.
Der zweite (im SlowRF Modus) scheint meine ELRO Funksteckdosen zu schalten (laut Logfile jedenfalls).

Ich bin trotzdem verunsichert, ob jetzt alles richtig eingerichtet ist. Vielleicht kann einer der Experten mal einen kurzen Blick auf
die FHEM-Definitionen für meine beiden Transceiver werfen?

#EDIT (Screenshots durch Code-Listings ersetzt)
Erster CUL/Transceiver (868MHz)

Code Auswählen Erweitern

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXeflptxz*
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@38400 4444
   DeviceName /dev/ttyACM0@38400
   FD         5
   FHTID      4444
   NAME       mapleCUL868
   NR         20
   PARTIAL
   RAWMSG     Z0B330002022EA4025524000046
   RSSI       -39
   STACKED    mapleCUL433
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_03 (F-Band: 868MHz)
   initString X21
Zr
   mapleCUL868_MSGCNT 4
   mapleCUL868_TIME 2017-05-01 10:30:27
   Matchlist:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-04-30 23:11:51   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-05-01 10:26:55   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l p t x z *
     2017-04-30 22:49:49   credit10ms      207
     2017-04-30 21:17:38   raw             is00F00F0FFFFF
     2017-05-01 10:30:27   state           Initialized
Attributes:
   rfmode     MAX


Zweiter, gestackter Transceiver (433MHz)

Code Auswählen Erweitern

Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        mapleCUL868
   IODev      mapleCUL868
   NAME       mapleCUL433
   NOTIFYDEV  mapleCUL868
   NR         30
   NTFY_ORDER 50-mapleCUL433
   PARTIAL
   RAWMSG     r5A47E500133201264401C43C
   RSSI       -44
   STATE      Initialized
   StackLevel 1
   TYPE       STACKABLE_CC
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_03 (F-Band: 433MHz)
   initString X21
   mapleCUL433_MSGCNT 1
   mapleCUL433_TIME 2017-05-01 10:26:58
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-04-30 23:11:36   ccconf          freq:433.970MHz bWidth:406KHz rAmpl:42dB sens:8dB
     2017-05-01 10:26:55   cmds             b C F i A Z N E G M K L U Y R T V W X f z
     2017-05-01 10:29:21   raw             6
     2017-05-01 10:26:58   state           Initialized
     2017-04-30 22:08:30   version         V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_03 (F-Band: 433MHz)
Attributes:
   rfmode     SlowRF

CUL_MAX

Code Auswählen Erweitern

Internals:
   CM_MSGCNT  1
   CM_TIME    2017-05-01 10:30:27
   DEF        123456
   IODev      mapleCUL868
   LASTInputDev mapleCUL868
   MSGCNT     3
   NAME       CM
   NR         23
   STATE      Defined
   TYPE       CUL_MAX
   addr       123456
   cnt        0
   mapleCUL868_MSGCNT 2
   mapleCUL868_RAWMSG Z0B330002022EA40255240000
   mapleCUL868_RSSI -39
   mapleCUL868_TIME 2017-05-01 10:30:27
   pairmode   0
   retryCount 0
   Readings:
     2017-04-30 22:49:52   packetsLost     5
   sendQueue:
Attributes:
   IODev      mapleCUL868

Vielen Dank, Kleo

[KernSani]

Hallo , ich bin relativer FHEM-Neuling und habe mich am Zusamenbau eines MapleCUL versucht.
Ich habe einen 868MHz CC1101 als ersten und einen 433MHz CC1101 als zweiten Transceiver verbaut.

Ich habe alles nach Wiki und Forumsbeitrag eingerichtet (insbesondere den zweiten Transceiver als gestackt angelegt).
Das scheint auch soweit zu funktionieren. Der erste Transceiver ist im MAX Modus und empfängt meine Thermostate und Türkontakte.
Der zweite (im SlowRF Modus) scheint meine ELRO Funksteckdosen zu schalten (laut Logfile jedenfalls).

Ich bin trotzdem verunsichert, ob jetzt alles richtig eingerichtet ist. Vielleicht kann einer der Experten mal einen kurzen Blick auf
die FHEM-Definitionen für meine beiden Transceiver werfen?

Vielen Dank, Kleo

Weiterhelfen kann ich dir nicht, aber als Tipp: Screenshots mag niemand gerne. Gib lieber

Code Auswählen Erweitern

list <device> in die Kommandozeile ein und poste den Output.