Hallo,
da der momentan verwendete Arduino so langsam an seine Grenzen (Geschwindigkeit, Flash und SRAM) kommt, habe ich mir Gedanken über eine neue Version mit leistungsfähiger Hardware gemacht.
Als Hardware wird der STM32F103CBT6 Maple Mini verwendet:
128 Kbytes Flash
20 Kbytes SRAM
2 SPI
Als optimales LAN Modul den USR-ES1 W5500
https://www.usriot.com/download/ES1/USR-ES1-EN%20V1.3.pdf (https://www.usriot.com/download/ES1/USR-ES1-EN%20V1.3.pdf)
Es gibt 2 Konfigurations Variantena:) einfacher SIGNALduino mit nur einem cc1101 ModulEs wird dabei nur das CC1101_1 (B) - für OOK/ASK verwendet.
Schaltplan siehe Anlage. Es kann auch die Platine von @Ranseyer verwendet werden, wenn nur das zweite cc1101 Modul bestückt wird.
Es ist keine cc1101 Modul konfiguration notwendig, das Modul B wird automatisch initialisiert.
Zur Inbetriebnahme ist folgendes notwendig:
- Bootloader 2.0 über USB flashen (https://forum.fhem.de/index.php/topic,106278.msg1073244.html) (bei aktuellen Maple Mini ist der Bootloader 2.0 evtl schon drauf)
- Firmware flashen (die bin Datei muss ggf durch die aktuelle Version ersetzt werden)
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_sduino_USB_411dev200627.bin -R- evtl angepasstes 00_SIGNALduino Modul installieren (https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900)
gegenüber der Version von Sidey vom fhem update, enthält diese Version optimierungen und Komfortfunktionen.
- Erste schritte (https://forum.fhem.de/index.php/topic,106278.msg1032098.html#msg1032098)
b:) mit mehreren cc1101 Modulen und FSK
Aufbau der Hardware (mehrere cc1101 Module für FSK)Ab der Version 4.1.0 werden bis zu 4 cc1101 Module (A-D) unterstützt
Beim MapleSduino sind die cc1101 Module an SPI2 angeschlossen:
28 MOSI
29 MISO
30 SCLK
CC1101_0 (
A)
31 CSN (Chip Select)
11 GD02 (Receive)
10 GD00 (send), optional für die a-culw
CC1101_1 (
B) - 433 MHz für OOK/ASK
12 CSN (Chip Select)
18 GD02 (Receive)
17 GD00 (send)
CC1101_2 (
C)
15 CSN (Chip Select)
16 GD02 (Receive)
13 GD00 (send), optional für die a-culw
PlatineEs gibt von @Ranseyer eine Platine:
https://forum.fhem.de/index.php/topic,109220.0.html (https://forum.fhem.de/index.php/topic,109220.0.html)
Es gibt 2 Bestückungsvarianten: normal (die USB Buchse und die Reset Taste sind oben), gedreht (USB Buchse ist unten in der Aussparung und kann z.B. mit Heisskleber fixiert werden.
Zur Orientierung ist Pin 31 beschriftet.
Wichtig: Bei den V0.1 und V0.2 Platinen ist die vertauschte Beschriftung 433 und 868 MHz manuell zu ändern!433 ist CC0_A
868 ist CC1_B (433 MHz)
Flashen der FirmwareHier ist die Firmware: https://github.com/Ralf9/SIGNALDuino/releases (https://github.com/Ralf9/SIGNALDuino/releases)
Es gibt momentan Binaries für
USB,
LAN und
serial (tx/rx vom DBG Anschluss)
- LAN gibts momentan nur für den MapleSduino
https://forum.fhem.de/index.php/topic,106278.msg1049877.html#msg1049877 (https://forum.fhem.de/index.php/topic,106278.msg1049877.html#msg1049877)
- serial ist z.B. für eine wifi-serial bridge mit dem ESP (z.B. ESP-link)
Es gibt für den MapleSduino und den MapleCul verschiedene Binaries:
Die "Maple_sduino....bin" ist für den MapleSduino und
die "Maple_cul_....bin" ist für den Maple Cul und Maple Cun
Damit kann die Firmware geflasht werden, die bin Datei muss ggf durch die passende Version ersetzt werden
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_sduino_USB_411dev200627.bin -R
oder
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_cul_USB_411dev200627.bin -R
Die Baudrate wurde auf 115200 erhöht.
a-culwEs gibt für den MapleSduino auch eine
a-culw Firmware
https://forum.fhem.de/index.php/topic,106278.msg1037726.html#msg1037726 (https://forum.fhem.de/index.php/topic,106278.msg1037726.html#msg1037726)
BootloaderUSB funktioniert momentan nur mit dem orginal Bootloader
Dies lässt sich auch an der upload Dauer erkennen: Beim orginal Bootloader dauert der Upload ca 30 sec und beim Bootloader 2.0 dauert der Upload nur ca 3 secAb der Version 4.1.0-dev200427 ist für die bin Files der Bootloader2.0 erforderlich. z.B. maple_mini_boot20.bin
https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen (https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen)
Bootloader 2.0 über USB flashen (https://forum.fhem.de/index.php/topic,106278.msg1073244.html)
KompilierenWer es selber kompilieren will:
https://github.com/Ralf9/SIGNALDuino/tree/dev-r41x_cc1101 (https://github.com/Ralf9/SIGNALDuino/tree/dev-r41x_cc1101)
https://forum.fhem.de/index.php/topic,106278.msg1027914.html#msg1027914 (https://forum.fhem.de/index.php/topic,106278.msg1027914.html#msg1027914)
Für die komfortable Bedienung und für FSK ist ein angepasstes 00_SIGNALduino Modul notwendig
Es ist auch bei der Initialisierung des MapleMini eine Optimierung enthalten.
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900 (https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900)
Erste schritte
https://forum.fhem.de/index.php/topic,106278.msg1032098.html#msg1032098 (https://forum.fhem.de/index.php/topic,106278.msg1032098.html#msg1032098)
Hier ist eine allgemeine Befehlsübersicht:
https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921 (https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921)
Hier ist eine Beschreibung "FSK mit dem SIGNALDuino"
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463 (https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463)
Es gibt auch ein Wiki
https://wiki.fhem.de/wiki/Maple-SignalDuino (https://wiki.fhem.de/wiki/Maple-SignalDuino)
Linkliste (https://forum.fhem.de/index.php/topic,111653.msg1058901.html#msg1058901)
Bei dieser Version für den Maple Mini gibt es u.a. die folgenden Neuerungen:
- Das Sendekommando kann eine maximale Länge von 600 Zeichen haben.
- Der Messagepuffer hat nun eine maximale Größe von 1500 Pulsen
Es gibt nun 2 neue Konfigurationsvariablen
CSmaxMsgSizex256 - damit kann die Größe des Messagepuffers konfiguriert werden. Der Wert wird mit 256 multipliziert, d.h. 4 ergibt eine Messagepuffergröße von 1024
CSmaxMuPrintx256 - damit kann die maximale Länge von MU-Nachrichten konfiguriert werden. Der Wert wird mit 256 multipliziert
- Die zweite und folgenden MS-Nachrichten werden nun mit der vorherigen MS-Nachricht verglichen, sind sie gleich, wird am Ende ein "Q" ausgegeben.
Werden 3 gleiche MS-Nachrichten in Folge empfangen, so werden die folgenden MS-Nachrichten nicht mehr ausgegeben.
Per default werden 4 MS-Nachrichten ausgegeben, dies kann z.B. mit CSmscnt=8 auf 8 erhöht werden
Wenn aktiviert, dann steht bei get config (CG): MSEQ=1;
CEQ - aktivieren, dann werden die folgenden gleichen MS-Nachrichten nicht mehr ausgegeben
CDQ - deaktivieren
- CR - configRadio
MIt CRE<A-D> kann ein cc1101 Modul aktiviert werden. z.B. CREA aktiviert das erste cc1101 Modul A
MIt CRD<A-D> kann ein cc1101 Modul deaktiviert werden. z.B. CRDA deaktiviert das erste cc1101 Modul A
- Der Befehl b wurde erweitert:
b<A-D><0-9> damit wird ein cc1101 (A-D) mit einer Speicherbank (0-9) initialisiert. z.B. mit bA3 wird das das erste cc1101 Modul A mit der Speicherbank 3 initalisiert.
b<A-D> damit wird ein cc1101 (A-D) selektiert. Die Befehle zum lesen und schreiben vom EEPROM und cc1101 Registern werden auf das selektierte cc1101 angewendet. Z.B. mit bA wird das erste cc1101 Modul A selektiert.
mit nachgestelltem W wird es im EEPROM gespeichert
- br - damit wird von allen cc1101 eine Bankinfo ausgegeben
- bs - damit wird eine Übersicht von allen Bänken ausgegeben
- Mit V (get Version) bekommt man eine Übersicht über die Module z.B. (R: A1 B0*). Mit * wird das selektierte cc1101 Modul markiert
Ein "-" hinter dem Modul (A-D) , bedeuted, daß dieses Modul nicht richtig erkannt wurde,
ein "i" bedeuted, daß das Modul zwar korrekt erkannt wurde, aber noch keiner Bank zugeordent wurde.
Wenn ein Modul nicht aufgeführt ist, dann ist es noch deaktiviert.
- Mit XQ und XE wird jetzt bei allen cc1101 der Empfang deaktiviert oder aktiviert
Wird bei XQ oder XE ein A-D drangehängt, dann können einzelne Empfänger aktiviert oder deaktiviert werden.
Bei der USB Version ist durch anhängen von W ein XQW zu empfehlen. Mit XQW wird nach einem Reset der Empfang des cc1101 nicht automatisch aktiviert.
Dies kann in einigen Fällen zur Optimierung der Initialisierung beim Fhem Modul nötig sein und ist an "irx0" in der Version erkennbar.
- Die Datenkomprimierung für MS- und MU-Nachrichten (config: Mred=1) ist nun nicht mehr notwendig.
Gruß Ralf
to do Liste
- Platine - wurde mitte Februar von
@Ranseyer bestellt erledigt, die Platinen sind da
https://forum.fhem.de/index.php/topic,109220
- Signalduino Firmware für USB erledigt, funktioniert stabil
Eine erste Version zum Testen ist fertig
https://github.com/Ralf9/SIGNALDuino/releases
Es gibt Binaries für Maple sduino und Maple cul
- Signalduino Firmware für LAN -
ist noch nicht fertig erledigt
https://forum.fhem.de/index.php/topic,106278.msg1049877.html#msg1049877
- a-culw Firmware für MapleSduino, erledigt
https://forum.fhem.de/index.php/topic,106278.msg1037726.html#msg1037726
- Selbstbau_CUL mit nano -> deprecated Hinweis
Ins Wiki
https://wiki.fhem.de/wiki/Selbstbau_CUL
ein Hinweis, daß der nanocul für Neubauten nicht mehr verwendet werden soll, mit Hinweis auf die MapleSduino und MapleCul Hardware
- unterstützung der MapleSduino Firmware auch vom offiziellen Signalduino fhem Modul
Momentan werden vom offiziellen Signalduino fhem Modul der FSK Empfang und die erweiterten Befehle und Ausgaben noch nicht unterstützt.
Es sind angepasste und erweitete fhem Module notwendig:
https://github.com/Ralf9/RFFHEM/issues/4
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Lässt sich das sketch von esp8266 nicht ohne Probleme auf dem esp32 portieren?
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: sash.sc
Hallo Ralf.
Ich habe einen wemos als Signalduino am laufen.
Ist da die Hardware nicht ausreichend?
Oder möchtest du den LAN Anschluss haben?
Gruß Sascha
ja, ich möchte einen LAN Anschluss haben.
Wenn WLAN dann gleich den ESP32
Zitat von: Beta-User am 07 Januar 2020, 11:17:23
Wunschliste II: MapleSignalduino (mit LAN+durchgereichten seriellen Interfaces, auf MapleCUN-Basis)...
Ja sowas ähnliches habe ich in nächster Zeit vor, den Maple Mini und das LAN Modul habe ich schon (siehe Anlage)
Der Maple Mini hat ja 2 SPI Busse, kann man da auf einem SPI das LAN Modul und auf dem anderen SPI dann zwei cc1101 Module anschließen?
Im ersten Schritt reicht für mich erstmal nur ein cc1101 Modul
Für die durchgereichten seriellen Interfaces werde ich Hilfe gebrauchen, das bekomme ich nicht alleine hin.
Hallo Ralf,
der STM32 ist schon eine gute Wahl, allerdings etwas aufwendiger in der Programmierung als ein ATMEGA. Eventuell kannst du die SPI-Anbindung vom mapleCUL (https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/MapleCUN) stibitzen.
Ich versuche schon seit einiger Zeit dem CSM (https://forum.fhem.de/index.php/topic,24651.msg177502.html#msg177502)/megaCUL (https://github.com/damianmelson/megaCUL-868MHz) (ATMEGA1284P) SIGNALDuino beizubringen. Aber trotz Portanpassungen in der Firmware wird der CC1101 nicht erkannt.
Hast Du eventuell Interesse an einem CSM (https://forum.fhem.de/index.php/topic,24651.msg177502.html#msg177502) (mehr SRAM, zwei UART, usw.)? ... ist geschenkt!
Hallo locutus,
ZitatHast Du eventuell Interesse an einem CSM (mehr SRAM, zwei UART, usw.)? ... ist geschenkt!
nein, habe dafür kein bedarf.
Ja der Maple Mini ist für den Signalduino sehr interessant. Es wird aber noch etwas dauern bis ich dazu komme.
Werde dann wahrscheinlich einige Fragen dazu haben.
Aber erstmal möchte ich die sduino V 3.3.4.0 fertig machen, die V.4.0.x wird darauf aufbauen.
Weißt Du zufällig bis zu welcher Baudrate die serielle über USB beim Maple Mini stabil funktioniert?
0% Baudratenfehler bei 57,6Kbps.
https://cw.fel.cvut.cz/wiki/_media/courses/be2m37mam/tasks/stm32-uart.pdf
Der wahre Experte auf dem STM32-Gebiet ist Telekatz (https://forum.fhem.de/index.php?action=profile;u=10183).
Zitat0% Baudratenfehler bei 57,6Kbps.
https://cw.fel.cvut.cz/wiki/_media/courses/be2m37mam/tasks/stm32-uart.pdf
Danke dies ist recht interessant.
Die 57,6Kbps. sind beim sduino in manchen Fällen grenzwertig, z.B. bei sehr langen Nachrichten.
Die 115.2Kbps haben bei 72 MHz auch 0%, ich werde es damit versuchen.
Hi Ralf,
soll ich Dir einen aufgebauten MapleCUL mit 4 cc1101 und LAN zur Verfügung stellen? Auf Ranseyer's großem Board?
Sowas: https://forum.fhem.de/index.php/topic,60458.msg728546.html#msg728546
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Hallo Arnd,
Danke für das Angebot, ist aber nicht nötig, ich habe den Maple Mini, das LAN-Module und 2 cc1101 Modul vorliegen.
Ich benötige aber noch raw Nachrichten von weiteren LaCrosse Sensoren.
ich werde hier noch schreiben was ich u.a. noch gebrauchen kann
https://forum.fhem.de/index.php/topic,106594.0.html
Gruß Ralf
Ich hab mir mal vom MapleCul die PIN-Belegung des Maple Mini für die ersten beiden cc1101 Module rausgesucht -> siehe erster Beitrag.
Ich kann noch ein Pinout vom Maple Mini gebrauchen.
Kann es sein, daß es vom USR-ES1 W5500 kein aktuelles Datenblatt gibt?
Ich habe nur dies gefunden, da passt aber die PIN-Belegung nicht
https://www.usriot.com/download/ES1/USR-ES1-EN%20V1.3.pdf
Zitat von: Ralf9 am 09 Januar 2020, 23:10:53
Hallo Arnd,
Danke für das Angebot, ist aber nicht nötig, ich habe den Maple Mini, das LAN-Module und 2 cc1101 Modul vorliegen.
Ich benötige aber noch raw Nachrichten von weiteren LaCrosse Sensoren.
ich werde hier noch schreiben was ich u.a. noch gebrauchen kann
https://forum.fhem.de/index.php/topic,106594.0.html
Gruß Ralf
Hat du denn maple Mini von Locutus?
Gesendet von meinem MI 9 mit Tapatalk
Nein, von hier:
https://www.amazon.de/dp/B0785R5CCW/ref=dp_prsubs_1
https://r.tapatalk.com/shareLink/topic?url=https%3A%2F%2Fforum%2Efhem%2Ede%2Findex%2Ephp%3Ftopic%3D80872%2E0&share_tid=80872&share_fid=75100&share_type=t&link_source=app
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: Ralf9 am 07 Januar 2020, 22:40:37
Für die durchgereichten seriellen Interfaces werde ich Hilfe gebrauchen, das bekomme ich nicht alleine hin.
Will nicht behaupten, dass ich das alles verstanden hätte. Telekatz zu fragen ist sicher eine gute Idee, der arbeitet aber mWn. nicht mit der Arduino-IDE, sondern mit irgendwas "richtigem".
Hatte irgendwo mal ein Projekt gesehen, das nur die beiden weiteren Schnittstellen nach USB durchreicht, leider finde ich den Link nicht mehr. Im Prinzip waren das aber am Ende nur ein paar Programmzeilen unter Zuhilfenahme dessen, was STM dazu bereitstellt.
Könnte sein, dass sich das auf eine include beschränkt, interessant scheinen mir vor allem die drei Funktionen ab hier zu sein: https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/stm32f1xx_it.c#L311 (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/MapleCUN/stm32f1xx_it.c#L311), sowie die Basisdefines, die irgendwie in den STM-Teilen weit verstreut liegen, z.B. https://github.com/heliflieger/a-culfw/blob/master/culfw/STM32/usbd/usb_device.h#L54 (https://github.com/heliflieger/a-culfw/blob/master/culfw/STM32/usbd/usb_device.h#L54) und über die makefile eingebunden werden (?).
Hoffe, das hilft irgendwie weiter, ich bin da auch ziemlich verloren....
@Ralf9:
Vielleicht noch eine Anmerkung zum Thema "Maple": Ich hatte hier auch schon ein paar andere Boards rumliegen (v.a. "Blue Pill"), aber wirklich gut funktioniert hatten eigentlich nur die "Maple"-Varianten, die ja auch halbwegs erschwinglich sind. Memory&PIN-mäßig macht das vermutlich nicht den Riesen-Unterschied, aber für eine größere Verbreitung wäre mMn. zu empfehlen, ein erprobtes Standardboard als Basis zu nehmen, idealerweise unter Verwendung derselben PIN-Layouts wie beim MapleCUN.
(Bin aber auch da eher User wie Entwickler; kann auch falsch sein!).
Sehe ich auch so, wenn wir schon 100-200 Maple CUL Platinen groß u d noch mehr Kleine haben, dann sollten wir das als Standard nehmen.
Gibt es eine Statistik, wieviele CUL an STACKABLE bzw *_CC hängen?
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
list hier jemand mit der den Maple Mini mit der Arduino IDE programmiert?
Ich verwende mit der Arduino IDE 1.8.10 diesen core:
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
Ich bekomme die serielle Ein- und Ausgabe über USB nicht hin.
wenn ich dies eintrage
void setup() {
SerialUSB.begin(BAUDRATE);
}
meldet sich kein USB device
ls -l /dev/serial/by-id
ls: Zugriff auf '/dev/serial/by-id' nicht möglich: Datei oder Verzeichnis nicht gefunden
Bei der AskSin++ warte ich bei STM32 immer 2 Sekunden im setup(), damit USB genug Zeit hat, sich beim Host anzumelden. Außerdem nutzte ich einfach Serial - im Macro DINIT().
void setup () {
delay(2000); // wait until Maple Mini USB-Serial is available
DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
....
Damit funktioniert es leider auch nicht.
Kann dies auch vom Bootloader abhängen? Ich habe zwar einen anderen Bootloader geflasht ich weiß aber nicht mehr welchen.
Ich kann zwar über USB flashen, aber nur mit Rootrechten und ich muss immer kurz vor dem flashen Reset drücken.
Im perpetual bootloader mode funktioniert bei mir das flashen über USB nicht.
# ./maple_upload ttyACM0 1 1EAF:0003 /tmp/arduino_build_700948/MapleMiniTest.ino.bin
Failed to open serial device.
dfu-util 0.8
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download [=========================] 100% 19668 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
Waiting for /dev/ttyACM0 serial...Done
# ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 11. Jan 17:46 usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 -> ../../ttyACM0
Wenn ich nun reset drücke:
# ls -l /dev/serial/by-id
ls: Zugriff auf '/dev/serial/by-id' nicht möglich: Datei oder Verzeichnis nicht gefunden
Ich habe den Bootloader (glaube ich) nicht geändert. Den Reset vor dem Flashen kenne ich auch. Mittlerweile benutzte ich hauptsächlich das Blue Pill Board - allerdings flashe ich den mit einem ST-Link. Damit kann man auch debuggen.
Schau mal hier https://asksinpp.de/Grundlagen/STM32/01_flashen.html - vielleicht hilft das irgendwie.
Hi,
falls HW-Unterstützung gebraucht wird spendiere ich gerne etwas:
https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Small/top.png
https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Large/V4.0/4.1-top.png
(Dort gibt es auch Schaltpläne usw...)
Wenn man die "zweireihigen" LAN Module verbaut, so halten diese alleine durch das verlöten: https://de.aliexpress.com/af/usr%25252des1.html?d=y&origin=n&SearchText=usr-es1
Im Anhang mal das kleinere Desgn welches nicht so unbedingt für die LAN-Nutzung gedacht war...
Für die große Version gibt es neben käuflichen auch ein schickes Ghäuse zum Drucken (von Gloob).
Grüße
HW-Unterstützung brauche ich momentan noch keine.
Ich brauche erstmal programmier unterstützung.
Die Knackpunkte beim Programmieren sind hier auch mal wieder ganz wo anders als ich ursprünglich gedacht hatte.
Hi Ralf,
mir fällt gerade noch ein, dass es bei der a-CulFW davon abhängt wie man mit Strom versorgt ob Serial/Debug ging oder nicht! Wie versorgst Du mit Strom? Per USB oder per VIN?
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
da ich die serial über usb verwenden will, wird er auch über usb versorgt
Ja macht Sinn ;-)
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/updater_stm32f1/updater_stm32f1.ino
Hier ist ein Sketch als Beispiel für Serial, der gleichzeitig den richtigen Bootloader flashed ;-)
Siehe Readme dazu:
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Ich flashe am liebsten per Bootloader. Falls man den Maple nimmt, dann finde ich den Maple-Bootloader am besten, denn man muss dazu nichts ändern.
Reseten vor dem Upload habe ich nie gemacht. Ich habe einfach dieses Scrip gestartet: https://wiki.fhem.de/wiki/MapleCUN#Trick_zum_USB-Flashen_.28Code_Schnipsel_f.C3.BCr_kleines_Skript.29
Nachdem das Skript läuft wird der Maple per USB angeschlossen und sofort geflasht...
Z.B. dieser Sketch ist funktionsfähig und überträgt die Daten die per Funk empfangen wurden per USB an den Host:
https://github.com/ranseyer/MySensors-HW/blob/master/Experimental/GW-STM32-RS485-RFM/Sketch/MyS-GW-MAPLE-RFM69/MyS-GW-MAPLE-RFM69.ino
Die STM32-Bootloader-Grundlagen:
Maple:
https://born2bastel.de/2017/02/08/maple-mini-clone-bootloader-flashen/ (https://born2bastel.de/2017/02/08/maple-mini-clone-bootloader-flashen/)
BluePill:
https://born2bastel.de/2017/02/08/stm32f103-minimal-board-bootloader-flashen/ (https://born2bastel.de/2017/02/08/stm32f103-minimal-board-bootloader-flashen/)
MSC-Bootloader von Telekatz öffnet ein USB-Drive in dem man das zu programmierende File reinkopiert. Wird automatisch programmiert. (Aber: Adressoffset, leider nicht ohne Änderungen (https://forum.fhem.de/index.php/topic,101610.msg950738.html#msg950738) Arduino-kompatibel):
https://github.com/Telekatz/MSC-stm32f103-bootloader (https://github.com/Telekatz/MSC-stm32f103-bootloader)
Kleine Ergänzung noch...
Der Maple-Mini hat schon einen Bootloader. Dieser ist schlechter als alle anderen Bootloader.
A) Das ist richtig
B) Ist trotzdem die Frage ob er gut genug ist, dann ohne Bootloader-Tausch ist der Nachbau einfacher wenn jemand nur ein einziges Device bauen will
Wenn man keinen Maple hat, oder sowie den Bootloader tauschen will (was ich meist als unnötig sehe), das wäre der MSC-Bootloader vermutlich am einfachsten für Enduser...
sowies aussieht ist in dem aktuellen package in der SerialUSB ein bug:
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
Mit diesem package funktioniert das SerialUSB
http://dan.drown.org/stm32duino/package_STM32duino_index.json
Hat aber den Nachteil, das die EEPROM Emulation 16 Bit Werte schreibt und liest, ich möchte aber 8 Bit Werte schreiben und lesen.
Ich habe noch keine Idee wie ich das hinbekomme.
Hier sind die Definitionen in der EEPROM.h
class EEPROMClass
{
public:
EEPROMClass(void);
uint16 init(void);
uint16 init(uint32, uint32, uint32);
uint16 format(void);
uint16 erases(uint16 *);
uint16 read (uint16 address);
uint16 read (uint16 address, uint16 *data);
uint16 write(uint16 address, uint16 data);
uint16 update(uint16 address, uint16 data);
uint16 count(uint16 *);
uint16 maxcount(void);
uint32 PageBase0;
uint32 PageBase1;
uint32 PageSize;
uint16 Status;
Der Bootloader ist das kleinste Problem, damit komme ich zurecht.
Kurz nach dem drücken von Reset führe ich den beim hochladen mit der Arduino IDE angezeigte Flashbefehl aus:
# ./maple_upload ttyACM0 1 1EAF:0003 /tmp/arduino_build_72752/MapleminiTest.ino.bin
Gruß Ralf
Zitat von: Ralf9 am 12 Januar 2020, 22:42:27
Hat aber den Nachteil, das die EEPROM Emulation 16 Bit Werte schreibt und liest, ich möchte aber 8 Bit Werte schreiben und lesen.
Ich habe noch keine Idee wie ich das hinbekomme.
Vielleicht hift der Code aus der AskSin++ https://github.com/pa-pa/AskSinPP/blob/master/Storage.h
Die InternalEprom-Klasse nutzt für den STM32 1k des Speichern zum Spiegeln der letzten FlashPage. Gelesen wird das ganze im Konstruktor und gespeichert mit store(). Die selbe Klasse kann auch mit einem AVR verwendet werden und nutzt dann die "normale" Arduino-API.
Im Radio.h ist auch die Anbindung des CC1101 über die SPI-Library drin. Könnte auch interessant sein.
Hallo papa,
Danke für Deine Hilfe, mir ist noch nicht klar wie die InternalEprom-Klasse initialsiert wird und wie das lesen mit getByte und das Schreiben mit setByte aussieht.
Ich habe die Hoffnung, daß mit dem aktuellen Arduino package das SerialUSB demnächst funktionieren wird.
Da gibt es dann auch ein gepufferten EEPROM zugriff
https://github.com/stm32duino/STM32Examples/blob/master/examples/NonReg/BufferedEEPROM/BufferedEEPROM.ino
Zitat von: Ralf9 am 13 Januar 2020, 23:41:12
Danke für Deine Hilfe, mir ist noch nicht klar wie die InternalEprom-Klasse initialsiert wird und wie das lesen mit getByte und das Schreiben mit setByte aussieht.
Eigentlich alles ganz einfach.
#include <Arduino.h>
#include <EEPROM.h> // the EEPROM library contains Flash Access Methods
#include "Storage.h"
as::InternalEprom eeprom;
void setup() {
Serial.begin(57600);
}
void loop() {
// read single byte
for( int address=0; address<256; ++address ) {
Serial.print(eeprom.getByte(address),HEX);
Serial.print(" ");
}
Serial.println();
// write single byte
for( int address=0; address<256; ++address ) {
eeprom.setByte(address,address);
}
// write RAM to FLASH
eeprom.store();
// read 256 byte to buffer
uint8_t buffer[256];
eeprom.getData(0, buffer, 256);
for( int address=0; address<256; ++address ) {
Serial.print(buffer[address],HEX);
Serial.print(" ");
}
Serial.println();
// stop program
while(1) ;
}
ZitatEigentlich alles ganz einfach.
Danke damit funktioniert es. Ich musste in der Storage.h ein paar Debugzeilen löschen damit ich das "include debug.h" nicht benötige.
Bei der Radio.h ist mir nicht klar warum Ihr bei der waitMiso nur ein delay macht
void waitMiso () {
_delay_us(10);
}und nicht wie beim Arduino
void waitMiso () {
while(PINTYPE::getState(MISO));
}Ich habe noch ein Problem mit dieser Routine, diese funktioniert nur mit dem Arduino, beim Maple Mini wird nur Müll ausgegeben.
Damit sollen die string_0 bis string_7 ausgegeben werden.
void cmd_help_S() // get help configvariables
{
char buffer[12];
for (uint8_t i = 0; i < CSetAnz; i++) {
strcpy_P(buffer, (char*)pgm_read_word(&(CSetCmd[i])));
MSG_PRINT(F("CS"));
MSG_PRINT(buffer);
MSG_PRINT(F("= "));
}
MSG_PRINTLN("");
}
#define CSetAnz 8
const char string_0[] PROGMEM = "fifolimit";
const char string_1[] PROGMEM = "mcmbl";
const char string_2[] PROGMEM = "mscnt";
const char string_3[] PROGMEM = "muoverflmax";
const char string_4[] PROGMEM = "maxnumpat";
const char string_5[] PROGMEM = "ccmode";
const char string_6[] PROGMEM = "muthresh";
const char string_7[] PROGMEM = "maxpulse";
const char * const CSetCmd[] PROGMEM = { string_0, string_1, string_2, string_3, string_4, string_5, string_6, string_7};
Zitat von: Ralf9 am 14 Januar 2020, 22:59:33
Bei der Radio.h ist mir nicht klar warum Ihr bei der waitMiso nur ein delay macht
Oh - da hast Du noch eine alte Leiche entdeckt. Die LibSPI Klasse ist auf einem AVR entstanden. Dort hat die SPI Library keine API, um die Pins abzufragen. Da das waitMiso() "nur" für die CC1101-Reset-Routine gedraucht wurde, habe ich mal eben schnell nur ein delay eingebaut. Das hat auch bisher scheinbar gut funktioniert :-) Die SPI Library für den STM32 kann aber die Pins zurückgeben. Du kannst ja mal die folgende Implementierung testen (habe gerade keine Hardware da).
void waitMiso () {
#ifdef ARDUINO_ARCH_STM32F1
while(digitalRead(SPI.misoPin()));
#elif defined (PIN_SPI_MISO)
while(digitalRead(PIN_SPI_MISO));
#else
_delay_us(10);
#endif
}
Zitat von: Ralf9 am 14 Januar 2020, 22:59:33
Ich habe noch ein Problem mit dieser Routine, diese funktioniert nur mit dem Arduino, beim Maple Mini wird nur Müll ausgegeben.
Damit sollen die string_0 bis string_7 ausgegeben werden.
void cmd_help_S() // get help configvariables
{
char buffer[12];
for (uint8_t i = 0; i < CSetAnz; i++) {
strcpy_P(buffer, (char*)pgm_read_word(&(CSetCmd[i])));
MSG_PRINT(F("CS"));
MSG_PRINT(buffer);
MSG_PRINT(F("= "));
}
MSG_PRINTLN("");
}
Ich denke das Problem ist
pgm_read_word. Das verarbeitet nur 16 Bit - was für Addressen auf dem AVR auch OK ist. Beim STM32 sind die Addressen aber 32 Bit. Deshalb sollte da besser
pgm_read_ptr verwendet werden. Das müsste für beide Architekturen das richtige machen.
Die Makros pgm_read_word und PROGMEM sind für dem STM32 nicht notwendig, da die ARM Architektur nicht über getrennte Speicherbereiche für Daten und Programm verfügt.
Wenn der gleiche Code für AVR und ARM compilierbar sein soll, musst du die Makros per Postprozessor für ARM entfernen. Ansonsten gleich weglassen.
Die Macros sind für den STM32 richtig definiert. Es muss halt nur auch das richtige Macro für Addressen verwendet werden.
#define pgm_read_word(addr) ({ \
typeof(addr) _addr = (addr); \
*(const unsigned short *)(_addr); \
})
Das schneidet halt eiskalt 2 Byte ab.
#define pgm_read_ptr(addr) ({ \
typeof(addr) _addr = (addr); \
*(void * const *)(_addr); \
})
Dieses gibt die vollen 4 Byte zurück.
ZitatOh - da hast Du noch eine alte Leiche entdeckt. Die LibSPI Klasse ist auf einem AVR entstanden. Dort hat die SPI Library keine API, um die Pins abzufragen. Da das waitMiso() "nur" für die CC1101-Reset-Routine gedraucht wurde, habe ich mal eben schnell nur ein delay eingebaut. Das hat auch bisher scheinbar gut funktioniert :-) Die SPI Library für den STM32 kann aber die Pins zurückgeben. Du kannst ja mal die folgende Implementierung testen (habe gerade keine Hardware da).
Danke damit funktionierts.
ZitatIch denke das Problem ist pgm_read_word. Das verarbeitet nur 16 Bit - was für Addressen auf dem AVR auch OK ist. Beim STM32 sind die Addressen aber 32 Bit. Deshalb sollte da besser pgm_read_ptr verwendet werden. Das müsste für beide Architekturen das richtige machen.
Mit dem pgm_read_ptr funktionierts.
Mir ist noch nicht klar, in welchen Fällen vor den const Definitionen ein static kommt.
Gibt es beim Maple Mini auch eine Möglichkeit das freeram zu ermitteln?
Beim Arduino geht dies z.B. so:
uint16_t freeRam () {
{
extern int __heap_start, *__brkval;
int v;
return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}
Zitat von: Ralf9 am 15 Januar 2020, 21:26:24
Gibt es beim Maple Mini auch eine Möglichkeit das freeram zu ermitteln?
Hilft das hier weiter https://github.com/stm32duino/STM32Examples/blob/master/examples/Benchmarking/MemoryAllocationStatistics/MemoryAllocationStatistics.ino
ZitatHilft das hier weiter
Ja, das freeram müsste dann dies hier sein:
Serial.print("Estimated Free RAM: ");
Serial.println(((stack_ptr < minSP) ? stack_ptr : minSP) - heapend + mi.fordblks);
mittlerweile funktioniert es soweit, daß ich den TX29TDH-IT mit FSK empfangen und über SerialUSB ausgeben kann.
Beim OOK/ASK Empfang (SLOWRF beim Cul) muss ich an der Signaldecoder class noch einiges umbauen.
Mit der Arduino IDE wird das Ethernet nur an der SPI 1 funktionieren, ich habe in der Ethernet Lib keine Möglichkeit gefunden wie ich angeben kann, daß ich die SPI 2 verwenden will.
Der OOK/ASK Empfang wird vorerst nur beim ersten cc1101 Modul funktionieren, ein gleichzeitiger OOK/ASK auf 2 cc1101 Modulen ist mir momentan zu aufwändig.
Über FSK werden nur die unidirektionalen Protokolle funktionieren.
Lesen hier auch HF- und Antennenspezialisten mit?
Beim HW-MAPLE-Small ist der Abstand zwischen der Antennen sehr klein, gibt es da keine gegenseitige Beeinflussungen der Antennen?
Kann z.B. die 868MHz Antenne die direkt neben der 433MHz Antenne ist, den 433MHz Empfang beeinträchtigen?
https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Small/Small_9056.JPG
Hi,
ich nutze die Small u d auch die Locutus 4er Platine aufgrund des Abstands der SMA Buchsen nur mit Antennenkabel.
Bisher ist mir ein übersprechen noch nicht aufgefallen. Die Diskussion gab es ja schon bei den Boardversionen und bei den LaCrosseGW soweit ich mich erinnere.
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
ZitatKann z.B. die 868MHz Antenne die direkt neben der 433MHz Antenne ist, den 433MHz Empfang beeinträchtigen?
Natürlich. Lambda/2 oder lieber Lambda Abstand wäre absolut zu empfehlen. Das ist die Theorie.
Aber: Reicht das nur im entferntesten wenn eine der Antennen auf einer beliebigen Frequenz sendet ?
Ich gehe davon aus: Wenn auch nur eine der Antennen auf knapp 434 oder 868 MHz sendet, sind mit Sicherheit alle Receiver in 1 Meter Entfernung "zugestopft".
Die Praxis ist so dass die meisten genervt waren vom besseren HF-Design z.B. hier: https://raw.githubusercontent.com/ranseyer/CUN-STM32/master/HW-MAPLE-Large/Archiv/Charge5-V1.5/Board-V102.png (geht mir auch so)
Beim Maple-Cul Small von mir ist es ja noch gut. Ich würde empfehlen den nur mit zwei Antennen zu bestücken, dann kann eine nach rechts und die andere nach links zeigen. (Beispiel Polarisation: eine 90 Grad verdrehte Antenne zwischen Sender und Empfänger sollte 3dB kosten = 50% Verlust)
...man sieht das alles ist nur ein Kompromiss. Bei meinem wichtigsten Maple-Cul sind die Antennen alle irgendwie komisch gedreht damit ich ein besseres Gefühl bei den Abständen habe.
Mein Fazit:
-Wer es ordentlich will aus dieser Sicht muss wohl bei fast jedem Design Pigtails anlöten (bringt auch Dämpfung) und die Antennen weiter absetzen...
-Wichtige Empfänger (wo kein Byte verloren gehen darf) sollten auf keinen Fall bei einem Sender in der Nähe sein
Oder halt die Kirch im Dorf lassen... 8)
ZitatNatürlich. Lambda/2 oder lieber Lambda Abstand wäre absolut zu empfehlen. Das ist die Theorie.
Aber: Reicht das nur im entferntesten wenn eine der Antennen auf einer beliebigen Frequenz sendet ?
Ich gehe davon aus: Wenn auch nur eine der Antennen auf knapp 434 oder 868 MHz sendet, sind mit Sicherheit alle Receiver in 1 Meter Entfernung "zugestopft".
Mir gehts dabei nur um den Empfang, bei unidirektionalen Protokollen wird normalerweise nicht so oft gesendet.
Ich habe mir mal darüber Gedanken gemacht, welche Wünsche ich habe.
Der Maple-Cul sollte kleiner sein als der Maple-Cul Small. Er sollte als Nachfolger des Nano Cul verwendbar sein, optional das Lan Modul.
Außerdem noch eine 4er Stiftleiste für einen optimalen Huckepak minicul.
Am Ende des Maple Mini eine Doppel cc1101 Platine, ungefähr so wie in der Anlage.
Wer nur 433 MHz möchte, kann das 868 MHz Modul unbestückt lassen.
Am anderen Ende (bei der USB Buchse) eine optionale Huckepak Platine für einen 868 cc1101.
Für diejenigen die noch einen dritten cc1101 wollen,
oder für diejenigen denen bei der Doppel cc1101 Platine der Abstand zwischen den beiden Antennen zu gering ist,
der Abstand zwischen den Antennen ist dann ca 7-8 cm. Ist dieser Abstand gross genug, damit beim Empfang die Beeinträchtigungen zwischen den beiden Antennen weniger werden?
LAN Modul auf SPI 1
cc1101 auf SPI 2
Gruß Ralf
Hi, der Vorschlag das gefällt mir ehrlich gesagt recht gut, nur denke ich sollte man ein paar mm mehr an der Antennenseite spendieren...
Grund: Denke mal der Cc1101 sollte max. halb unter dem Maple verschwinden. (Ansonsten sollte man ggf. mal Probieren ob/wie die Verschlechterung ist)
Zweite Sache ist die Frage nach der Prio von 433 oder 868 Mhz... Falls diese gleich ist sollte man lieber die 433Mhz Antenne per Default schlechter anbinden.
ZitatAm anderen Ende (bei der USB Buchse) eine optionale Huckepak Platine für einen 868 cc1101.
Für diejenigen die noch einen dritten cc1101 wollen,
oder für diejenigen denen bei der Doppel cc1101 Platine der Abstand zwischen den beiden Antennen zu gering ist,
der Abstand zwischen den Antennen ist dann ca 7-8 cm. Ist dieser Abstand gross genug, damit beim Empfang die Beeinträchtigungen zwischen den beiden Antennen weniger werden?
Davon gehe ich aus. Aber wenn du mehr Abstand willst kannst du ja auch einfach die beiden nebeneinander liegende um 180 grad drehen. Denke das ist ebenfalls gut genug. (Ich gehe da von abgewinkelten Antennen aus)
Zitatnur denke ich sollte man ein paar mm mehr an der Antennenseite spendieren...
ja, kann gerne etwas mehr rausschauen.
ZitatZweite Sache ist die Frage nach der Prio von 433 oder 868 Mhz... Falls diese gleich ist sollte man lieber die 433Mhz Antenne per Default schlechter anbinden.
Ich hätte gerne die 433 als Prio besser als die 868.
Ist die USB Seite die schlechtere?
Nachtrag:
oder ist bei der Doppel cc1101 Platine unten die bessere Seite?
Ich hätte gerne auch noch eine Lötbrücke, damit das optimale cc1101 Modul an der USB Seite auch das zweite cc1101 Modul sein kann, wenn das andere 868 Modul unbestückt bleibt.
ich lese hier mal mit ;)
Hallo Martin (Ranseyer),
hab bei Deinem Entwurf der Platine (a) eine Version (b) gemacht (siehe Anlage) bei der die Stamps ca 10 - 12 mm nach links unter den Maple Mini geschoben werden.Dies ergibt dann bei der oberen stamp eine längere Leiterbahn zur Antenne.
Ich habe die 433 MHz Stamp unten eingezeichnet, da nach meinem Verständniss unten die bessere Seite sein müsste.
Mir ist es egal ob die Platine ca 82 mm (a) oder ca 70-72 mm (b) lang wird. Für mich ist es auch ok, wenn dann bei der 868 MHz stamp die Leiterbahn zur Antenne länger wird.
Wie sehen dies die anderen die hier mitlesen?
Die Vertauschung von SPI1 und SPI2 (SPI 2 ist dann für die cc1101) müsste auch den Vorteil haben, daß dadurch das Layout der Leiterbahnen einfacher wird.
Gruß Ralf
Ich bin mal etwas in mich gegangen...
Wenn man folgendes als Ziele setzt:
-einfach aufzubauen
-Montagereihenfolge am besten egal
-(Quali, mich schmerzt das die höhere=kritischere Frequenz relativ schlecht zu behandeln. Und um auf der Platine 50Ohm Impedanz der Leiterbahnen sicherzustellen fehlt mir das Werkzeug)
...würde ich zu einem ganz simplen klassischen und sauberen Aufbau ohne Kunstgriffe tendieren... (Der FireTV Stick der gerade vor mir liegt hat 12cm)
Ich schau mal ob ich Morgen einen Entwurf posten kann...
ed: Was mir gerade noch einfällt... Ich habe wie auf deinem Foto Maple+LAN-Modul nach oben gepackt. Dann hat eine dritte Stamp unten Platz. Aber die Pins vom LAN Modul werden zu kurz werden wenn beides auf einer Seite ist. Diese Auslöten und gegen Lange ersetzen macht auch nicht jedem Spass.
Die Frage hier für mich ob die dritte Stamp wirklich Sinn macht. Ich schau mir nochmals die Alternativen für die Platzierung an...
Zitat-(Quali, mich schmerzt das die höhere=kritischere Frequenz relativ schlecht zu behandeln. Und um auf der Platine 50Ohm Impedanz der Leiterbahnen sicherzustellen fehlt mir das Werkzeug)
Dann spricht nichts dagegen, es so zu machen wie in der Variante A (82 mm)
Zitated: Was mir gerade noch einfällt... Ich habe wie auf deinem Foto Maple+LAN-Modul nach oben gepackt. Dann hat eine dritte Stamp unten Platz. Aber die Pins vom LAN Modul werden zu kurz werden wenn beides auf einer Seite ist. Diese Auslöten und gegen Lange ersetzen macht auch nicht jedem Spass.
Die Frage hier für mich ob die dritte Stamp wirklich Sinn macht. Ich schau mir nochmals die Alternativen für die Platzierung an...
Demnach hast Du bei dem Maple small die Stiftleisten vom LAN Modul verlängert.
Dann ist es wohl besser es wie im Bild in der Anlage zu machen. Wenn Du so wie ich es eingezeichnet habe beidseitig 3er oder 4er Stiftleisten vorsiehst, dann kann darauf optional eine 868 MHz Stamp.
Das mit den Lötbrücken für die Huckepak Platine für den 3ten Stamp muss nicht sein, wird zu aufwendig, da gehört auch noch GDO0 und GDO2 dazu.
Gruß Ralf
Siehe ich das Richtig, daß das vertauschen der SPI (SPI1 Ethernet) beim Layout Vorteile hat?
Was mir nicht nicht klar ist, kann beim Maple cul das erste ccModul 433 oder 868 MHz haben oder ist dies fest vorgegeben?
Mir brauchen noch einen Namen für den kleinen Maple Cul. "Maple Cul mini" oder "Maple Cul little" oder "Maple Cul tiny" oder ?
@Telekatz
siehst Du bei der a-culw firmware für den Maple Cul Probleme, wenn wir die SPI vertauschen (SPI1 Ethernet, SPI2 cc1101)?
Gibts es bei der a-culw für den Maple Cul für jede Konfiguration eigene Binaries oder lässt sich die Anzahl der cc1101 Module in der a-culw konfigurieren?
Kennst Du außer Deiner Ethernet Library noch andere bei denen auch die SPI2 verwendet werden kann?
Gruß Ralf
Hi,
ich könnte mir das ganze im Moment so vorstellen: https://github.com/ranseyer/MapleSDuino/tree/master/PCB-V01
-Maple
Der Maple kann oben verbaut werden. Ich würde ihn einfach "tiefergelegt" ((und nicht irgendwie verdreht")) unter der Platine verbauen. Die USB Buchse sollte wieder in die Aussparung der Platine passen. Die Buttons sollten durch die Bohrungen bequem zu bedienen sein. So große Bohrungen hatte ich noch nie.
Das verbessert auch die Möglichkeiten für die Heißkleber-Leute rund um die USB Buchse. (Die sind in letzter Zeit oft ziemlich einfach abzureissen)
-HF: Alles kurz und einziger Wehrmutstropfen: Das VIA für 886 MHz
-Dritte Stamp kann man mechanisch stabil aufstecken (rechts+ links fest)
-Debug-Port mit versetzten Pins damit man ggf. den Bootloader bequem ohne Löten tauschen kann, Bzw. auch ein herausgeführter UART +VCC+GND
-Weiterer UART herausgeführt. Beide gegenüber und falls der Platz reicht eine Platine über beide stabil aufsteckbar
-Beschriftungen sollten kein Problem sein vom Platz her
...Was ich vergessen habe: Den RAW Input auch noch herausführen als 5. Pin bei einem der beiden UARTs. Damit kann man ohne USB Buchse ~5V einspeisen...
So und jetzt haut drauf...
(Im speziellen ein Gegencheck der SPI verdrahung, also zum LAN-Modul und den Stamps würde mir sehr helfen!)
Was mir nicht nicht klar ist, kann beim Maple cul das erste ccModul 433 oder 868 MHz haben oder ist dies fest vorgegeben?Kann man machen wie man will... Aber die Software vermutet dass CC0 868Mhz hat und der zweite 433MHz. Falls man sich z.B. verlötet hat oder andere Gründe hat abzuweichen, dann kann man z.B. in FHEM die Frequenz und vor allem auch den Funkmodus umstellen.
Ich kann auch z.B. den Slot 0,2,3 bestücken und die Firmware erkennt und regelt das.
ZitatMir brauchen noch einen Namen für den kleinen Maple Cul. "Maple Cul mini" oder "Maple Cul little" oder "Maple Cul tiny" oder ?
Ich hab das Repo mal vorerst so genannt, solange die HW nicht zu den bestehenden Maple-CUL Binaries kompatibel ist: MapleSDuino
Viel schicker wäre natürlich die HW wieder zusammenzu führen auf den vorherigen Standard. Sollte das nicht gehen, dann wäre natürliche eine SW-Anpassung per Telekatz genial.
Es wäre schade fast gleiche HW zu haben aber inkompatibel...
(Wir sind ja nicht der "Sales von e3<zensiert>" ...)
Zitatich könnte mir das ganze im Moment so vorstellen:
sieht so recht gut aus
ZitatDer Maple kann oben verbaut werden. Ich würde ihn einfach "tiefergelegt" ((und nicht irgendwie verdreht")) unter der Platine verbauen. Die USB Buchse sollte wieder in die Aussparung der Platine passen. Die Buttons sollten durch die Bohrungen bequem zu bedienen sein. So große Bohrungen hatte ich noch nie.
Das verbessert auch die Möglichkeiten für die Heißkleber-Leute rund um die USB Buchse. (Die sind in letzter Zeit oft ziemlich einfach abzureissen)
Die LED sollte auch sichtbar sein, sonst wäre eine extra LED auf der Platine schön, evtl sogar 2 oder eine DUO LED.
ZitatKann man machen wie man will... Aber die Software vermutet dass CC0 868Mhz hat und der zweite 433MHz. Ich kann auch z.B. den Slot 0,2,3 bestücken und die Firmware erkennt und regelt das.
D.H. die Firmware kommt auch damit zurecht, wenn nur das zweite (CC1) mit 433 MHz verbaut ist, als Nachfolger für den NanoCul.
ZitatViel schicker wäre natürlich die HW wieder zusammenzu führen auf den vorherigen Standard. Sollte das nicht gehen, dann wäre natürliche eine SW-Anpassung per Telekatz genial.
Es wäre schade fast gleiche HW zu haben aber inkompatibel...
Das Problem ist z.Zt., daß es für die Arduino IDE keine Ethernet Library gibt, bei der auch die SPI2 verwendet werden kann.
Wenn es mit der Arduino IDE funktioniert, kann evtl mal jemand mit einem C-Compieler und der Ethernet Library von Telekatz versuchen ob er es compilieren kann.
@PeMue
da Du auch hier mitliest, wie ist Deine Meinung dazu?
Gruß Ralf
Zitat von: Ralf9 am 18 Januar 2020, 13:27:20
Das Problem ist z.Zt., daß es für die Arduino IDE keine Ethernet Library gibt, bei der auch die SPI2 verwendet werden kann.
Du kannst ja mal die Libary patchen. Im SPI.cpp ganz am Ende die Definition auskommentieren.
// SPIClass SPI(1);
Im Sketch kannst Du dann mit
SPIClass SPI(2);
das Standard-SPI auf den 2. umbiegen.
Zitat von: Ralf9 am 18 Januar 2020, 12:48:26
@Telekatz
siehst Du bei der a-culw firmware für den Maple Cul Probleme, wenn wir die SPI vertauschen (SPI1 Ethernet, SPI2 cc1101)?
Ich sehe das Problem beim SPI vertauschen nicht in der a-culfw Firmware, die lässt sich ändern. Ich sehe das Problem darin, dass dadurch deine Firmware inkompatibel ist mit den bisher existierenden MapleCUN Boards.
Zitat von: Ralf9 am 18 Januar 2020, 12:48:26
Gibts es bei der a-culw für den Maple Cul für jede Konfiguration eigene Binaries oder lässt sich die Anzahl der cc1101 Module in der a-culw konfigurieren?
Für den MapleCun gibt es zwei Binaries. Eines für den W5100 und eines für den W5500 Ethernet Chip. An welchen CC Port und wie viele CC1101 vorhanden sind wird automatisch erkannt. Und wenn deine Hardware inkompatibel zur bisherigen Hardware bleibt, könnte man die a-culfw auch so ändern, dass auch der SPI Port automatisch erkannt wird.
Zitat von: Ralf9 am 18 Januar 2020, 12:48:26
Kennst Du außer Deiner Ethernet Library noch andere bei denen auch die SPI2 verwendet werden kann?
Du könntest auch eine Fork der vorhandenen Arduino Ethernet Lib anlegen und da den SPI Port ändern.
Hast du eigentlich schon einmal darüber nachgedacht, ob sich der SIGNALDuino Empfangsteil als weiteres Protokoll in die a-culfw integrieren lässt? Was benötigt der Empfangsteil an Ressourcen (RAM, Interrupts, Timer, Platz im EEPROM etc)?
Hast du eigentlich schon einmal darüber nachgedacht, ob sich der SIGNALDuino Empfangsteil als weiteres Protokoll in die a-culfw integrieren lässt? Was benötigt der Empfangsteil an Ressourcen (RAM, Interrupts, Timer, Platz im EEPROM etc)?
Würde das überhaupt von Speicher her geben, oder welche Hardware müsste dann her?
Gesendet von meinem MI 9 mit Tapatalk
Die Hardware ist ja die selbe. An Flash ist momentan noch 49KiB in der a-culfw frei.
Ich bin inzwischen auf das aktuelle Arduino package gewechselt:
https://githttps://github.com/stm32duino/STM32Ethernethub.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
ZitatDu könntest auch eine Fork der vorhandenen Arduino Ethernet Lib anlegen und da den SPI Port ändern.
Hier ist die Ethernet Lib
https://github.com/stm32duino/STM32Ethernet
Ich habe das Problem, daß ich nicht die Stelle finde wo ich den SPI Port ändern muss.
Das ist ja auch nicht die Ethernet Lib für den Wizchip über SPI sondern für einen STM32 mit integriertem Ethernet MAC.
ZitatDas ist ja auch nicht die Ethernet Lib für den Wizchip über SPI sondern für einen STM32 mit integriertem Ethernet MAC.
Danke, da hätte ich lange suchen können.
Mir ist aber nicht klar wo die Ethernet Lib für den Wizchip ist.
Hier habe ich sie bis jetzt nicht gefunden:
https://github.com/stm32duino/Arduino_Core_STM32
Ich vermute, es ist die Ethernet Lib aus den arduino-Libraries:
https://github.com/arduino-libraries/Ethernet (https://github.com/arduino-libraries/Ethernet)
Schau mal in der Build Ausgabe nach, was da alles compiliert wird.
Ja die ist es.
https://github.com/arduino-libraries/Ethernet/blob/7b5ee58ba50ae28341111e4641d35076080b8597/src/utility/w5100.cpp#L104
man müsste dann wahrscheinlich diese Datei patchen
und vor
SPI.begin();
das hier eintragen:
#define mosiPin 28
#define misoPin 29
#define sckPin 30
#define csPin 31
SPI.setMISO(misoPin);
SPI.setMOSI(mosiPin);
SPI.setSCLK(sckPin);
SPI.setSSEL(csPin);
Mir wäre es lieber, wenn wir die SPI bei dieser Hardware vertauscht lassen können.
Ich finde es sauberer, wenn man in der Lib der Arduino nichts patchen muss.
Wenn ich es richtig überblicke hat die Vertauschung der SPI auch Vorteile beim Layout der Platine.
Vorschlag, wir lassen hier die Vertauschung (Ethernet SPI1).
Zum compilieren einer Binary für die Maple large und small kann dann eine gepatchte lib verwendet werden.
Gruß Ralf
ZitatVorschlag, wir lassen hier die Vertauschung (Ethernet SPI1).
Der Schaden ist bei einer ersten kleinen Serie m.E. gering...
ZitatDie LED sollte auch sichtbar sein, sonst wäre eine extra LED auf der Platine schön, evtl sogar 2 oder eine DUO LED.
Sag mir bitte noch zwei Pins und je eine LED Farbe dazu... Dann mach ich mir die Tage mal Gedanken wie man das machen kann (bedrahtete Teile wird wohl etwas schwierig in diesem Fall, würde ich das aber auch nicht als Prio sehen). Es wäre super wenn es keinen großen Konflikte gäbe zu den ersten 3 Transceivern und den UARTs: https://raw.githubusercontent.com/ranseyer/CUN-STM32/master/HW-MAPLE-Large/Archiv/V3.5/schematic.png
ZitatSag mir bitte noch zwei Pins und je eine LED Farbe dazu... Dann mach ich mir die Tage mal Gedanken wie man das machen kann (bedrahtete Teile wird wohl etwas schwierig in diesem Fall, würde ich das aber auch nicht als Prio sehen). Es wäre super wenn es keinen großen Konflikte gäbe zu den ersten 3 Transceivern und den UARTs:
Es würde auch eine LED reichen, die zweite LED nur, wenn Platz dafür da ist und es vom Layout her ohne großen Aufwand machbar ist.
SMD LED sind ok, die Farbe ist erstmal egal, man kann ja später die Farbe bestücken die man will.
Bei den PINs ist es wahrscheinlich am Besten, wenn diese Telekatz raussucht, damit es keine Konflikte gibt.
Zitat von: Ralf9 am 18 Januar 2020, 23:35:51
Mir wäre es lieber, wenn wir die SPI bei dieser Hardware vertauscht lassen können.
Ich finde es sauberer, wenn man in der Lib der Arduino nichts patchen muss.
Wenn ich es richtig überblicke hat die Vertauschung der SPI auch Vorteile beim Layout der Platine.
Vorschlag, wir lassen hier die Vertauschung (Ethernet SPI1).
Zum compilieren einer Binary für die Maple large und small kann dann eine gepatchte lib verwendet werden.
Gruß Ralf
Du musst es ja nur einmal patchen. Und wenn du dann mal eine Binary für die Maple large und small Version erstellst, musst du es sowieso tun. Den Supportaufwand für zwei unterschiedliche Harwarevarianten würde ich vermeiden.
Zitat von: Ralf9 am 19 Januar 2020, 12:54:15
Es würde auch eine LED reichen, die zweite LED nur, wenn Platz dafür da ist und es vom Layout her ohne großen Aufwand machbar ist.
SMD LED sind ok, die Farbe ist erstmal egal, man kann ja später die Farbe bestücken die man will.
Bei den PINs ist es wahrscheinlich am Besten, wenn diese Telekatz raussucht, damit es keine Konflikte gibt.
LED ist beim Maple Mini auf dem nicht herausgeführten Pin PB1. Die restlichen Pins sind beim MapleCUN alle schon belegt.
ZitatDu musst es ja nur einmal patchen. Und wenn du dann mal eine Binary für die Maple large und small Version erstellst, musst du es sowieso tun. Den Supportaufwand für zwei unterschiedliche Harwarevarianten würde ich vermeiden.
Da auch andere in der Lage sein sollen den sketch mit der Arduino IDE zu compilieren, ist es mir lieber, wenn ich zumindest bei dieser Platine keinen Supportaufwand habe zum patchen der Datei. Den erhöhten Aufwand habe ich lieber bei mir, als beim user.
ZitatLED ist beim Maple Mini auf dem nicht herausgeführten Pin PB1. Die restlichen Pins sind beim MapleCUN alle schon belegt.
Wenn es so eng ist, reicht auch eine LED
Was ist mit 3(PB0) und 14(PC13)
Hier sieht es so aus als wären sie frei.
https://wiki.fhem.de/w/images/b/b3/MapleCUN.jpg
Zitat von: Ralf9 am 19 Januar 2020, 15:07:24
Da auch andere in der Lage sein sollen den sketch mit der Arduino IDE zu compilieren, ist es mir lieber, wenn ich zumindest bei dieser Platine keinen Supportaufwand habe zum patchen der Datei. Den erhöhten Aufwand habe ich lieber bei mir, als beim user.
Integriere den geänderten Code in dein Git Repo und verwende den, statt der Arduino Lib. Dann hat jeder schon die gepatchte Version, der das selber compiliert.
Zitat von: Ralf9 am 19 Januar 2020, 15:07:24
Was ist mit 3(PB0) und 14(PC13)
Hier sieht es so aus als wären sie frei.
https://wiki.fhem.de/w/images/b/b3/MapleCUN.jpg
Da hängt der vierte CC1101 dran:
https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=70504;image (https://forum.fhem.de/index.php?action=dlattach;topic=60458.0;attach=70504;image)
ZitatIntegriere den geänderten Code in dein Git Repo und verwende den, statt der Arduino Lib. Dann hat jeder schon die gepatchte Version, der das selber compiliert.
Dann müsste ich ja die komplette Ethernet Lib in das Git Repo integrieren.
ZitatDa hängt der vierte CC1101 dran:
Dann müsste es eigentlich gehen, wenn wir bei dieser Platine hier für die LED 14(PC13) CC IN3 nehmen.
Bei der Platine hier gibt es kein vierten cc1101 und bei der a-culw dürfte es eigentlich nicht stören, da die Prüfung ob der cc1101 vorhanden ist, wahrscheinlich über CC_CS3 geht.
Da ich wegen der LED für den Maple Cul large und small sowieso eigene Binarys brauche ist es auch kein Problem wenn die SPI getauscht sind.
Bei den sduino Binarys für den Maple Cul large und small würde ich dann die LED auf 33 legen.
Was meinen die anderen die hier mitlesen dazu?
Wird beim sduino eine LED benötigt?
Inzwischen habe ich das cc1101 und das LAN-Modul zum laufen bekommen. In der Anlage ist mein Testaufbau.
Gruß Ralf
Würde es nicht Sinn machen, den "maple Duino " über PoE zu versorgen, wenn der netz Port dran ist?
Gesendet von meinem MI 9 mit Tapatalk
Hi,
@Sidey: Schön ist anders ;-)
Reicht es nicht, wenn man nur die Init der Ethernetlib übernimmt und mit anderem SPI anspricht und der Rest include bleibt? Oder Du/Wir dem Maintainer der Ethernetlib mal einen Patch (Default SPI1 aber über Parameter SPIx) anbieten!?
Naja, PoE haben wir ja schon mal diskutiert.
Zusammenfassung:
1) Es gibt keine günstigen fertigen Module für PoE Einspeisung
2) Es gibt keinen Standard für Ampere oder Volt, hängt auch von der ZuleitungslängebdesnEthermetkabels ab w/ Spannungsabfall
3) Bis jetzt kenne ich keine positive Meldung über eine MapleCUL mit PoE
Ich würde mich mal auf den Core des SignalMAPLE konzentrieren ;-)
Just my 2ct.
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Probier mal die LED auf 32. Der währe noch frei, weil das der Pin an der Taste auf dem Maple Mini ist.
Zum Thema LEDs darf ich nichts sagen...
LEDs die ich gut leiden kann, werden nur mit schwarzem Edding verbessert. Die LEDs vom Arduino Pro-Mini erhalten meistens die letzte Segnung mit der Weller Lötstation...
Aber das schöne an einer Platine finde ich, daß auch unnötige Teile schon berücksichtigt sind... (Also gerne LEDs vorsehen, wenn sie sonst nicht Schaden...)
ZitatReicht es nicht, wenn man nur die Init der Ethernetlib übernimmt und mit anderem SPI anspricht und der Rest include bleibt? Oder Du/Wir dem Maintainer der Ethernetlib mal einen Patch (Default SPI1 aber über Parameter SPIx) anbieten!?
Nach meinem Verständnis reicht es nicht nur die eine zu patchende Datei zu übernehmen.
ZitatOder Du/Wir dem Maintainer der Ethernetlib mal einen Patch (Default SPI1 aber über Parameter SPIx)
Hat schon jemand gemacht, aber da hat sich seit Oktober nichts mehr getan:
https://github.com/arduino-libraries/Ethernet/issues/116
Dabei ist aber das Problem, daß bei vielen Librarys jeder sein eigenes Süppchen kocht, z.B. ändern der SPI durch eine neue Instanz
so
SPIClass(uint8_t mosi, uint8_t miso, uint8_t sclk, uint8_t ssel = (uint8_t)NC);bei einem anderen package so:
SPIClass::SPIClass(uint32 spi_num)Dies ist einer der Gründe, warum ich es hier gerne bei der Ethernet lib sauber ohne patchen einer Datei hätte.
Bei der SPI Lib gibt es fast überall ohne patchen einer Datei die Möglichkeit den SPI Port zu ändern,
Bei der Ethernet ist mir keine Lib bekannt wo dies ohne Patchen einer Datei geht.
Gruß Ralf
ZitatProbier mal die LED auf 32. Der währe noch frei, weil das der Pin an der Taste auf dem Maple Mini ist.
Die 32 ist beim Maple Mini nicht rausgeführt.
Mein Vorschlag wäre, wenn sich keiner meldet, der ein LED braucht, dann kommt bei den Binarys die LED auf 33, die ist so hell, daß sie zwischen den Platinen etwas durchscheinen müsste,
wenn es für @Ranseyer ohne großen Aufwand machbar ist, dann SMD Pads für die LED und einen Widerstand auf 14(PC13) vorsehen.
Wer dann eine LED will muß es sich selber compilieren.
Beim sduino ist die LED per Befehl abschaltbar
Die 32 ist parallel zu BOOT0.
ZitatDie 32 ist parallel zu BOOT0.
Dann muss die BOOT0 auf Ausgang konfiguriert werden, kann dann noch die Taste abgefragt werden?
Was ist wenn der Ausgang High ist und die But gedrückt wird, kann da nichts kaputt gehen?
BOOT0 ist kein GPIO. 32 geht auf PB8. Taste und LED gehen natürlich nicht gleichzeitig. Aber benötigst du die Taste überhaupt?
Kaputt kann nichts gehen, da R2 vorhanden ist und die Taste ja auch High durchschaltet.
Zitat von: Ralf9 am 19 Januar 2020, 21:07:11
Dann müsste ich ja die komplette Ethernet Lib in das Git Repo integrieren.
Wo wäre da jetzt das Problem? Andere Libs sind ja jetzt auch schon in deinem Git Repo enthalte.
Hi,
ungetestet und zufällig gestern drüber gestolpert, aber evtl. Hilfst!?
https://github.com/stevstrong/Ethernet_STM32/blob/master/README.md
SPI scheint auswählbar.
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
ZitatBOOT0 ist kein GPIO. 32 geht auf PB8. Taste und LED gehen natürlich nicht gleichzeitig. Aber benötigst du die Taste überhaupt?
Kaputt kann nichts gehen, da R2 vorhanden ist und die Taste ja auch High durchschaltet.
Du weißt wahrscheinlich genauso wenig wie ich ob Du die But Taste evtl in Zukunft brauchen wirst, ich möchte mir diese Option gerne offen halten.
Dann ist die LED Geschichte doch eigentlich ziemlich klar...
Es sollte primär die vorhandene LED vom Maple genutzt werden.
Also muss der Maple und auch die Seite mit der USB Buchse nach unten. Dann sieht man die LED. Die Aussparung für USB und die Bohrungen für die Taster würde ich trotzdem belassen, damit eine alternative Montage möglich bleibt.
Zweite LED kann man
-Boot0 missbrauchen
-vom 4. Transceiver nehmen
Also würde ich empfehlen:
-vorerst weglassen...
ZitatAlso muss der Maple und auch die Seite mit der USB Buchse nach unten. Dann sieht man die LED. Die Aussparung für USB und die Bohrungen für die Taster würde ich trotzdem belassen, damit eine alternative Montage möglich bleibt.
Diese alternative Montage Möglichkeit gefällt mir, da wird dann für die Huckepak Platine für den dritten cc1101 eine längere Stiftleiste benötigt.
Von meiner Seite aus, paßt dies so mit der LED.
Wegen der Ethernet Lib hab ich hier was geschrieben:
https://github.com/arduino-libraries/Ethernet/issues/116
@PeMue
hast Du Dir die Platine mal angeschaut?
Zitat von: Ralf9 am 20 Januar 2020, 21:36:27
@PeMue
Hast Du Dir die Platine mal angeschaut?
Nein, ich war heute beim Hermes Shop (mobiler Paketschein funktioniert prima) ;D ;D ;D.
Ich schaue mir das am Mittwoch oder spätestens am Sonntag an, leider sind die Abende diese Woche ziemlich verplant ...
Gruß Peter
PS: Martin hat immer so aktuelle Eagle Versionen, da kann ich leider nicht mithalten :o
Das ist diesmal Eagle 7...
(Teil meiner Strategie künftig nur noch KiCad zu nutzen. Und es ist wirklich viel schlechter als aktuelle Versionen.. )
Hallo Martin,
wie groß ist für Dich der Aufwand mal zum Vergleich eine Platine zu layouten mit nicht vertauschten SPI?
Das hält sich in Grenzen... Eine Sinn sehe ich darin wenn ich entweder nur diese oder beide Varianten für einen ersten Test bestelle.
Nur um mal zu sehen wie das so ist bringt m.E. wenig. (2 oder 3 Vias hin oder her sind egal)
Heisst das, daß es vom Layout und Länge der Leiterbahnen der SPI keine Rolle spielt ob die SPI vertauscht sind oder nicht?
Gefühlsmässig hätte ich gedacht, daß bei getauschen SPI (Ethernet auf SPI1) das Layout einfacher wird.
Ist es absicht, daß die beiden Stiftleisten vom Radio so weit links sind, ich fände sie in der Mitte besser, damit die Huckepackplatine vom dritten cc1101 nach rechts über die USB Buchse kann und so der Abstand der Antenne zu den andern beiden größer ist.
Guten Tag, ich melde mich ebenso mal kurz zu Wort um meine Erfahrungen einzubringen.
In einem selbst gebauten Projekt mittels ESP und 2 Empfängern welche sehr nah aneinander liegen und eurem Vorhaben ähneln, so erzielt Ihr noch bessere Ergebnisse, wenn die Empfänger abgeschirmt werden zusätzlich mit einem Metallgehäuse. Ich improvisierte da mit Büchsenblech welches ich an die Masse angeschlossen habe. Das Ganze hatte ich sehr gut mitbekommen können, da ich zusätzlich eine LED am Eingang angeschlossen hatte vom Cc1101 um den Empfang / Störungen / Rauschen zu überwachen. Wo manchmal an Orten diese flackerte und ich somit den rAmpleWert verringern musste, konnte ich nach dieser Modifikation diesen wieder erhöhen.
Das Prinzip ist überall in der Technik erkennbar. Gerade HF ist ja nicht das ,,stabilste" wenn die falsche Technik zu nah kommt.
Zusätzlich ist es immer Ratsam, die Masse unter der Antenne (sofern nicht eine externe Antenne angeschlossen ist) so groß wie möglich zu halten. Viele Foren berichten darüber, mindestens die ,,Antennenlänge".
Edit: gerade mit Ethernet und Störungen bitte aufpassen. Dies muss auch geschirmt sein. Bei einer modifizierten alten XS1 ezcontrol hatte ich an die cc1101 einen Anschluss für den pegelwandler angeschlossen. Dieser zeigt mir ,,nur bei Anschluss Ethernet div. Spitzen. Also ebenso Vorsicht und Abschirmung sonst könnte der Spaß genommen werden später.
Gesendet von iPhone mit Tapatalk Pro
ZitatHeisst das, daß es vom Layout und Länge der Leiterbahnen der SPI keine Rolle spielt ob die SPI vertauscht sind oder nicht?
Ich bin der Überzeugung das macht bei einem nicht zu geizigen Layout den Kohl nicht fett... (Wenn man jeden mm weg optimiert schon, aber das finde ich nicht zielführend)
Zitatist es absicht, daß die beiden Stiftleisten vom Radio so weit links sind, ich fände sie in der Mitte besser, damit die Huckepackplatine vom dritten cc1101 nach rechts über die USB Buchse kann und so der Abstand der Antenne zu den andern beiden größer ist.
Hmm, die Idee war, dass man siehe Anlage gleichzeitig ohne Konflikt zum LAN Modul zwei Platinen aufstecken kann.
Links (bei meinem angehängten Bild) sind zwei getrennte "UARTs mit Saft" verfügbar und noch der Pin für 5V Einspeisung den ich vergessen habe.
Rechts auf zwei Seiten verteilt und somit mechanisch stabil der dritte Transceiver. (Natürlich kann ich problemlos UARTs und den Transceiver tauschen!)
Einer der beiden hat immer einen kleinen Nachteil. Das wäre also eher eine Sache der Prio.
Natürlich sind andere Varianten denkbar...
Zitatwenn die Empfänger abgeschirmt werden zusätzlich mit einem Metallgehäuse
Daher sind die Transceiver auch auf verschiedenen Seiten und weitestmöglich versetzt.
ZitatZusätzlich ist es immer Ratsam, die Masse unter der Antenne (sofern nicht eine externe Antenne angeschlossen ist) so groß wie möglich zu halten.
Das muss man differenzieren. Masse braucht man für eine gute Antenne nicht. Den Part macht die Antenne selbst.
A) Der einzelne anglötete Lambda/4 Draht wird also ohne Massefläche nur ganz schlecht performen.
B) Eine gute Antenne braucht keine Massefläche
Aber: Zur Abschirmung sollte man immer möglichst viel Masseflächen und cleveres Layout haben. Dabei hilft: mehr Platz und kein Over-Engeneering mit unnötigem Firlefanz der denn immer die Masseflächen reduziert.
Beispiele: https://forum.fhem.de/index.php/topic,93021.msg856054.html#msg856054 (CS-Family PCB-Antenne ist super, die Drahtspulen sind sch...e, auch mit Massefläche als Gegengewicht)
PS: Dazu machen wir im Moment m.E. einen ersten Prototyp. Ich schau mal ob noch geschickt Platz ist für Pads um ein-zwei optionale Blechdeckel auflöten zu können...
(Ich war mal privat ein bisschen ein einem Projekt mit DVB-S2 Karten beteiligt, das sind ganz andere Frequenzen, und selbst da hält der Hersteller die Blechdeckel inoffiziell für unnötig. Die Prototypen hatten allen keinen Deckel beim Eingangsmischer)
Ich habe gerade eine Menge winzige Änderungen in das Github hochgeladen: https://github.com/ranseyer/MapleSDuino/tree/master/PCB-V01
Etwas plastischer hier: https://cadlab.io/project/2431/master/files
Änderungen waren mindestens:
Pins:
7 SS1 nach SCS vom LAN
31 SS2 nach CSN von allen Radios
0 RX3 korrekt benannt
1 TX3 korrekt benannt
Pads für optionale Schirmung
Der Maple schaut nach unten. Wegen den Aussparungen auch oben montierbar solange er nach unten schaut.
, ...
Die 868MHz Antenne habe ich mal in der "schicken Montagevariante" belassen, statt in der "guten"...
@PeMue: Du hast Schreibrechte auf das Repo.
Denke damit wäre das wichtigste gemacht. Nach Peters Feedback noch die GND Fläche etwas optimieren, Vias verbauen und sauber beschriften...
Zitat31 SS2 nach CSN von allen Radios
wie soll das funktionieren?
Die Radios müssen doch über die einzelnen CSN getrennt ausgewählt werden können.
Zitat von: Ralf9 am 24 Januar 2020, 08:11:00
wie soll das funktionieren?
Chip-Select teilen geht eher nicht... :o Hektik ist wohl nicht immer hilfreich...
Habe eben den schon eine Weile herumliegenden Fix hochgeladen.
@Peter: Ich habe mir das Routen mal gespart, denke von dir kommt auch noch ein Feedback, dann mach ich das erst später.
Jetzt passt das mit den SPI fast, 31 SPI2/SS sollte doch CC_CS0 heissen
Danke das ist mir durch. Ich hab daher nochmals allgemein die SPI Sachen gegengeckt. Und auch den exportierten Schaltplan wieder konsistent.
=> Done.
@PeMue bist Du inzwischen mal dazugekommen es Dir anzuschauen?
... ich denke ich bau noch ~zwei Kerben ein um das ganze besser in einem gedruckten Gehäuse zu positionieren...
...die Chinesen machen nach Meiner Infos ingesamt noch eine Woche länger frei... (das soll eine Entscheidung der Regierung aufgrund des Corona Virus sein; trotzdem ist man bei früherer Bestellung früher in der Warteschlange...) ...
@Peter ich warte trotzdem auf deine Meinung, ob du noch eine entscheidende Idee hast...
Wie lange wird es ungefähr dauern bis die Platinen da sind?
Mir ist noch nicht ganz klar wie ich an die benötigten Bauteile komme.
Bei Amazon könnte ich mir einen weiteren "ARCELI Maple Mini Bord STM32F103CBT6" bestellen.
Gruß Ralf
Keine Ahnung wann in China der Normalzustand wieder eintritt. Normal bei billigem Versand ~4 Wochen.
Hoffe mal die bekommen die Sache mal flott in den Griff, sonst haben ggf. auch andere Sorgen als die Heimautomatisierung...
Eine Maple kann ich dir bestimmt noch aus dem Bestand stiften. Ich kaufe nur Baite (mit dem Aufdruck) die haben bisher zu 100% funktioniert.
https://de.aliexpress.com/item/1400667476.html?spm=a2g0s.9042311.0.0.27424c4dAtXFuz
Neuerdings haben die aber Micro-USB. Da habe ich in unglücklicher Umgebung selbst schon eine abgerissen. (=> außen Nachlöten, oder Heisskleber druff)
Achtung Fakes mit drei Einkerbungen: https://www.mikrocontroller.net/topic/488417#6117201
ZitatIch kaufe nur Baite (mit dem Aufdruck) die haben bisher zu 100% funktioniert.
Den habe ich auch und möchte auch keinen anderen haben.
Wie siehts mit den anderen Bauteilen aus?
433 und 868 cc1101 Briefmarke, Antennenbuchsen, Antennen?
Nachtrag:
Hat Aliexpress eine ähnliche Lieferzeit wie die Platinen?
Die gibt es z.B. hier:
https://de.aliexpress.com/item/32472259186.html
https://de.aliexpress.com/item/32635393463.html
PS: Ich sende dir mal eine PN.
Hi Ralf,
Naja, sag halt was Du brauchst! Das werden wir schon alles im Keller haben ;-)
Hier mal Beispiele:
SMA Buchse:
https://a.aliexpress.com/_Utekq
https://a.aliexpress.com/_TwWeC
SMA Buchse für Gehäuse:
https://a.aliexpress.com/_TQarK
Antenne 433:
https://a.aliexpress.com/_Tx8mE
Antenne 868:
https://a.aliexpress.com/_UNnQm
Gruß
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Jetzt funktioniert auch der ASK/OOK (433MHz) Empfang.
Der Flash und das RAM ist beim Maple Mini ausreichend groß :)
Mit einer cmdstring Länge von max 700 und einem Messagepuffer von 2000 habe ich ein freeram von 11044
Der Sketch verwendet 53348 Bytes (40%) des Programmspeicherplatzes. Das Maximum sind 131072 Bytes.
Globale Variablen verwenden 7132 Bytes (34%) des dynamischen Speichers, 13348 Bytes für lokale Variablen verbleiben. Das Maximum sind 20480 Bytes.
Bin ich hier der einzigste der beim Maple Mini mit der Arduino IDE entwickelt?
Gruß Ralf
Ich habe ein Problem wo ich alleine nicht mehr weiterkomme.
Ich verwende die Arduino IDE 1.8.10 und diesen core
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
Auf dem Maple Mini ist der Bootloader 2.0
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download [=========================] 100% 19884 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
Waiting for /dev/ttyACM0 serial...Done
# ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 3. Feb 18:23 usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 -> ../../ttyACM0
nach einem Reset oder Power off funktioniert die Serielle über USB nicht mehr!
# ls -l /dev/serial/by-id
ls: Zugriff auf '/dev/serial/by-id' nicht möglich: Datei oder Verzeichnis nicht gefunden
Kann mal auf dem Maple Mini mit dem o.g. core und dem folgenden sketch testen ob die Serielle über USB nach einem reset noch funktioniert
int8_t led = 0;
#define csPin 7
#define csPin2 31
void setup() {
pinMode(csPin, OUTPUT);
pinMode(csPin2, OUTPUT);
digitalWrite(csPin, HIGH);
digitalWrite(csPin2, HIGH);
Serial.begin(115200); //this isn't needed, it is pre-initialised , otherwise you could uncomment it to test
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
if(Serial.available()) {
char c = Serial.read();
Serial.print("hello ");
Serial.print(c);
Serial.println();
}
led = ~ led & 1;
digitalWrite(LED_BUILTIN, led);
delay(100);
}
Gruß Ralf
@PeMue
Kannst Du ungefähr abschätzen bis wann Du dazukommen wirst, die Platine anzuschauen?
Zitat von: Ralf9 am 02 Februar 2020, 15:27:22
Bin ich hier der einzige der beim Maple Mini mit der Arduino IDE entwickelt?
Scheint so, Telekatz verwendet etwas "Richtiges" ;)
Allerdings compiliert juergs den Sketch für den BME680 ebenfalls mir der Arduino IDE ...
Zitat von: Ralf9 am 27 Januar 2020, 19:35:43
@PeMue bist Du inzwischen mal dazugekommen es Dir anzuschauen?
Ich habe mir den Schaltplan auf A3 gedruckt und versuche, die Schaltung zu verstehen. Dummerweise bin ich fast jeden Abend teils geschäftlich, teils privat unterwegs und das Wochenende sieht nicht viel besser aus.
Zitat von: Ralf9 am 04 Februar 2020, 08:47:07
@PeMue
Kannst Du ungefähr abschätzen bis wann Du dazukommen wirst, die Platine anzuschauen?
Im Github Repo ist derzeit nur die Platzierung, korrekt?
Gruß Peter
ZitatIm Github Repo ist derzeit nur die Platzierung, korrekt?
siehe
Zitat von: Ranseyer am 24 Januar 2020, 17:01:23
Chip-Select teilen geht eher nicht... :o Hektik ist wohl nicht immer hilfreich...
Habe eben den schon eine Weile herumliegenden Fix hochgeladen.
@Peter: Ich habe mir das Routen mal gespart, denke von dir kommt auch noch ein Feedback, dann mach ich das erst später.
Hallo zusammen,
habe mal versucht den Schaltplan zu verstehen. Folgende Fragen:
- SCL und SDA brauchen wir nicht für andere Dinge und können da Radio 3 anschließen?
- Wofür sind die 5 V bei DBG? Die hängen irgendwie witzlos in der Luft rum. Entweder 3,3 V oder weglassen?
- Für die Schirmung habe ich für die Radarplatine eine Würth Schirmung (inkl. Eagle Bauteil), soll ich mal messen, ob die passen würde?
- Thema Gehäuse: Ich vermute, es gibt kein kurzes/schmales Gehäuse, welches passt? Daher wird jemand ein Gehäuse konstruieren? Ich würde irgendwo noch Zapfen bzw. Löcher vorsehen, damit die Platine dann verklemmt/ggf. verschraubt werden kann.
Ich habe ein paar kosmetische Dinge beim Schaltplan bereinigt und auf dem Layout die Bezeichner der Bauteile hingerückt (siehe github).
Gruß Peter
Zitat- SCL und SDA brauchen wir nicht für andere Dinge und können da Radio 3 anschließen?
Es soll bis auf die vertauschten SPI kompatibel zum Maple Cul sein.
https://wiki.fhem.de/w/images/b/b3/MapleCUN.jpg
Dort ist
CC IN2 = SCL
CC CS2 = SDA
ZitatWofür sind die 5 V bei DBG?
Ist mir auch nicht klar
@Ranseyer, zu was werden beim DBG 5 V benötigt?
Gruß Ralf
Die Diskussion hier ist mir total entgangen (keine Mail bekommen).
Zitat@Ranseyer, zu was werden beim DBG 5 V benötigt?
Das ist nur für die Leute die sich die USB-Buchse abreissen... Der Pin geht direkt zum RAW-Eingang am Maple...
Hätte nie gedacht dass das passieren kann. Aber wenn man das Teil tief vergräbt, kann das insbesonders bei der Micro-USB version durchaus mal passieren...
ZitatIch würde irgendwo noch Zapfen bzw. Löcher vorsehen, damit die Platine dann verklemmt/ggf. verschraubt werden kann.
Dazu die Kerben in der Mitte...
Um an der Seite vom LAN-Modul eine größere definiere Auflage zu haben könnte ich ggf das LAN Modul noch um 2,54mm nach innen schieben. Ich hatte keinen Bedarf gesehen, was meint Ihr ?
ZitatFür die Schirmung habe ich für die Radarplatine eine Würth Schirmung (inkl. Eagle Bauteil), soll ich mal messen, ob die passen würde?
Du kannst es doch einfach mal drauf klatschen (vorerst ohne die vorhandenen Pads zu entfernen ), dann kann je selbst entscheiden:
-Keine Schirmung (mein Favorit!)
- ~Konservendosen-Blech
-Kauf eines schicken Spezial-Teils
...Nur wenn wir davon ausgehen dass mehr als 20% der Nutzer eine Schirmung nutzen, dann gehört die eine SMA-Buchse auf die gegenüberliegende Seite und somit ohne VIA angebunden, sond passt der Kompromiss für micht nicht... (das wäre dann also "Funktion deutlich vor dem Design"...)
Zitat von: Ranseyer am 07 Februar 2020, 13:15:27
Du kannst es doch einfach mal drauf klatschen (vorerst ohne die vorhandenen Pads zu entfernen ), dann kann je selbst entscheiden:
-Keine Schirmung (mein Favorit!)
- ~Konservendosen-Blech
-Kauf eines schicken Spezial-Teils
Ist ein bisschen groß (siehe Bild), ich schaue mal, ob es das Ding eine Nummer kleiner gibt. Aber relativ teuer (Lötseite + Deckel ca. 7 €). Ob es etwas bringt, weiß ich nicht ...
Gruß Peter
Ich habe vorher mal am LAN Modul +C geschoben... (Liegt im Github. Die originalen Eagle Bezeichnungen hatte ich übrigens absichtlich entfernt und gegen eigene Texte ersetzt. Aber das ist im Endeffekt egal, können wir gerne so lassen.)
Bei dem Deckel erwarte ich im Moment Kurzschlüsse hinten an der Stamp. Wenn man diese großzügig vermeiden will und die Kerbe plus 5V behalten will, dass geht das zu Lasten der möglichen Aufsteck Platinen.
Und wir sprechen von einer V0.1. Daher bin ich für weglassen eines kaufbaren Bauteils zur Abschirmung. Und wer das glaubt zu brauchen hat bestimmt die Muße hier ein bisschen zu basteln. 8)
Da ich das schon irgendwie als "meine Platine" sehe nehme ich mir mal raus: Ich schlage von die kaufbare Abschirmung in dieser Version nicht weiter zu verfolgen.
Wenn damit alle einigermaßen leben können, dann gilt das vorerst als beschlossen.
Wenn überhaupt, dann nur optional bei 433 MHz (falls ohne extra Aufwand)
Für 868 kann bei Bedarf evtl später auf der Huckepack Platine eine Abschirmung vorgesehen werden.
Ich hab folgende Zuordung im Kopf
CC0 868 MHz mit via in der Antenne
CC1 443 MHz
CC2 868 MHz Huckepack
Vor was soll die Abschirmung abschirmen?
Gruß Ralf
... das ist der Punkt ...
Vor quasi nicht vorhandener Abstrahlung (=egal!)
Und vor allem vor eventuellen Einstrahlungen.
Damit wir die Kirche im Dorf lassen:
-Kondensatoren sind auch meist "unnötig", kosten aber nix, und stören nicht. => Voll dafür !
-CC1101 abschirmen, ab ich noch nirgens gesehen => Sollten wir nicht verhindern, solange es nicht stört ! (aber auch keinen Aufwand treiben!)
ed: Blödsinn gestrichen.
Die Module, die eQ-3 in den Homematic Geräten verbaut, sind alle geschirmt. Und auf die Geräte von eQ-3 gibt es Gewährleistung. Nur mal so am Rande.
Ok da war ich zu fix... Danke für die Rückmeldung!
Hast du auch eine Meinung zum Bedarf der Abschirmung im Empfangsmodus ?
Da hab ich keine Meinung dazu.
Danke, dann bleibe ich bei meiner Meinung: Unnötige optionale Features sind immer, gut, aber nicht um jeden Preis.
Wenn Peter bei 433 MHz ohne größeren Aufwand eine Abschirmung vorsehen kann, darf er es gerne machen,
dann besteht die Möglichkeit zu testen ob die Abschirmung merkbar was bringt.
BTW:
Was mir aufgefallen ist, die blaue neuftech 433 MHz sind nicht zu empfehlen.
Von der 868 MHz Briefmarke bin ich positiv überrascht.
Sie empfängt 433 MHz mindestens genauso gut (eher noch besser) wie die neuftech.
Die 868 MHz Briefmarke empfängt schwache Signale besser.
@Peter, ist noch kurzfristig mit Feedback zu etwas anderem als zu der Abschirmungs-Sache von dir zu rechnen ?
Falls die Abschirmung das einzige Thema wäre, dann mache ich morgen die Platine fertig und bestelle.
Grund:
-Alle meine anderen Projekte warten nun schon eine Weile auf Bestellung
-Abschirmung geht jetzt auch schon, man wird nur vermutlich sich selbst ein Stückchen Kupfer- oder Weissblech biegen müssen.
PS: Und ich würde eine Sammelbestellung anbieten und kalkuliere für die erste kleine Serie (für diejenigen die jetzt gleich, also ungetestet bestellen) mal so 1,5€ pro Stück...
(Unter Sammelbestellung verstehe ich dann auch alle auf einmal zu versenden...)
Hi,
dann nehme ich mal 3 Signalmaples ;-) Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Hat jemand einen MAPLE Mini übrig, den er gerade nicht benötigt?
Ich könnte noch einen gebrauchen.
Ich habe Probleme mit der serialUsb, ich möchte ausschließen daß es an der Hardware liegt.
Außer mir hat anscheinend niemand Probleme mit der serialUsb.
Gruß Ralf
Zitat von: Ralf9 am 11 Februar 2020, 16:11:42
Hat jemand einen MAPLE Mini übrig, den er gerade nicht benötigt?
Ich könnte noch einen gebrauchen.
Ich habe Probleme mit der serialUsb, ich möchte ausschließen daß es an der Hardware liegt.
Außer mir hat anscheinend niemand Probleme mit der serialUsb.
Gruß Ralf
Hab ich (Bitte PN!). Und du kannst zusätzlich auch alle dubiosen Maple von mir haben ohne Baite Aufdruck (die werden aber ggf. wegen deren Bootloader Zicken machen...) .
Ich habe noch sporadische Abstürze im LAN Betrieb, kann dies evtl an der fliegenden Verkabelung des LAN-Moduls liegen?
Mein Testaufbau:
https://forum.fhem.de/index.php/topic,106278.msg1014957.html#msg1014957
Keine Ahnung, ich nur sagen dass das LAN Modul relativ viel Strom zieht.
(Z.B. kann man den Maple mit LAN Modul nicht flashen wenn man z.B. ein schlechtes USB Kabel/Netzteil zur Spannungsversorgung nutzt.Ohne LAN Modul: kein Problem)
Hier ein paar Anhaltspunkte zum Verbrauch: https://wiki.fhem.de/wiki/MapleCUN#Debugging_.2F_weiteres
Es gibt nun eine erste Testversion für den Maple Mini (V 4.0.1-dev200215)
https://github.com/Ralf9/SIGNALDuino/releases/tag/4.0.1-dev200215
https://github.com/Ralf9/SIGNALDuino/tree/dev-r40x_cc1101
Das Erhöhen des Messagepuffers von 254 auf 1500 war doch aufwändiger als ich gedacht hatte.
Die Protokolle bei denen ein Messagepuffer von 254 zu klein ist, werden mittlerweile immer mehr.
Nun folgt als nächster Schritt die Unterstützung von bis zu 4 cc1101 Modulen (A-D)
Ich habe es wie folgt vor:
Es gibt einen neuen Befehl
CR (Config Radio)Mit CRE<A-D> wird ein cc1101 aktiviert und mit CRD<A-D> deaktiviert
Der Befehl b<0-9> wird erweitert.
Mit b<0-9><A-D> wird eines der cc1101 Module A-D einer EEPROM Speicherbank zugewiesen und damit initialisiert.
Mit b1A wird dann das erste (A) cc1101 der Bank 1 zugewiesen damit initialisiert.
Mit V (get Version) bekommt man dann eine Übersicht über die Module z.B:
V 4.0.1-dev200215 SIGNALduino cc1101 (R: A1 B0 C2) - compiled at ..."R:" für Radio
A1 - der erste cc1101 auf Bank 1
B0 - der zweite cc1101 auf Bank 0
C2 - der dritte cc1101 auf Bank 2
Gruß Ralf
Beim Anschauen des Codes des cc1101 zum Init und zum Detekt ist mir aufgefallen, daß bei der a-culfw nirgends nach einem select() ein waitMiso() verwendet wird,
hat dies keine Nachteile?
Beim AskSinPP und beim Signalduino ist es beim cc1101 reset so eingebaut
https://github.com/pa-pa/AskSinPP/blob/8268dbf6d6b76b66df3fcd081592019ebfb10064/Radio.h#L414
// Pull CSn low and wait for SO to go low (CHIP_RDYn).
spi.select();
spi.waitMiso();
// Issue the SRES strobe on the SI line
uint8_t ret = spi.send(CC1101_SRES);
// When SO goes low again, reset is complete and the chip is in the IDLE state.
spi.waitMiso();
spi.deselect();
Beim Signalduino ist das waitMiso im cmdStrobe enthalten, ist zwar wahrscheinlich nur beim CC1101_SRES notwendig, dürfte aber bei den anderen cmdStrobe auch nicht schaden.
uint8_t cmdStrobe(const uint8_t cmd) { // send command strobe to the CC1101 IC via SPI
cc1101_Select(); // select CC1101
wait_Miso(); // wait until MISO goes low
uint8_t ret = sendSPI(cmd); // send strobe command
wait_Miso(); // wait until MISO goes low
cc1101_Deselect(); // deselect CC1101
return ret; // Chip Status Byte
}
Ich stelle mir einen sauberen Init/Detekt folgendermaßen vor
cc1101_Deselect(); // some deselect and selects to init the cc1101
delayMicroseconds(30);
// Begin of power on reset
cc1101_Select();
delayMicroseconds(30);
cc1101_Deselect();
delayMicroseconds(45);
// Pull CSn low and wait for SO to go low (CHIP_RDYn).
cc1101_Select();
wait_Miso();
uint8_t ret = sendSPICC1101_SRES(); // send SRES strobe command
// When SO goes low again, reset is complete and the chip is in the IDLE state.
wait_Miso();
cc1101_Deselect();
// danach kann beim ersten Init oder beim detekt die Partnum und Version ausgelesen werden
delay(10); // ist dies hier notwendig?
val = readReg(0x30, CC1101_CONFIG); // Partnum (im Datenblatt seht 0x30 (0xF0), was bedeuten die 0xF0?
val = readReg(0x31, CC1101_CONFIG); // Version
Ich würde hier beim wait_Miso() ein Timeout einbauen, damit abgebrochen wird falls bei einem defekten cc1101 das Miso nicht auf low geht
Gruß Ralf
Zitat von: Ralf9 am 16 Februar 2020, 01:51:28
Es gibt nun eine erste Testversion für den Maple Mini (V 4.0.1-dev200215)
Ich würds gerne testen aber ...
- wo ist das kompilierte Binary File für Maple Mini?
- wie sehen die Voreinstellungen in der Arduino IDE für Board: "Generic STM32F1 series" aus?
Soeben den Maple Mini durchs flashen aus der Arduino IDE ins Jenseits befördert. Ich hoffe es ist nur der Bootloader zerschossen.
Edit 09.09.22:
inzwischen gibts den core 2.3.0
dazu wird in der Arduino ide unter "zusätzliche Boardverwalter URLs" folgendes eingetragen:
https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.jsonwichtig, da beim core 2.x.x bei Serial noch ein bug ist, ist bei der Serial und USB Version der core 1.9.0 erforderlich
Es gibt für den core 2.x.x zwar ein workaround, dazu muß aber im core in einer Datei was geändert werden.
Beim core 1.9.0 kommt unter "zusätzliche Boardverwalter URLs" folgendes rein:
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.jsonDanach im Boardverwalter nach STM32 filtern und den core installieren.
In der Anlage sind die Einstellungen für board
In der Arduino IDE habe ich unter Voreinstellungen: "Ausführliche Ausgabe während: hochladen".
Dann steht in der IDE in der Ausgabe folgendes:
maple_upload ttyACM0 1 1EAF:0003 /tmp/arduino_build_944154/RF_Receiver_40x.ino.binDies führe ich dann mit Rootrechten
kurz nach dem reset drücken in einer shell aus, damit klappt dann das timing recht gut. Edit es funktioniert auch ohne reset drücken.
Zitat
wo ist das kompilierte Binary File für Maple Mini?
eine kompilierte Binary gibts momentan noch nicht.Was für eine Hardware verwendest Du zum Testen?
Bis jetzt funktioniert es nur mit USB.Mit dem Lan Modul habe ich noch Abstürze, kann es evtl an meinem fliegenden Aufbau mit 10cm Dupont Kabeln liegen?Edit 12.6.2020:
Der core 1.9.0 hat deutliche Besserung bei der LAN Version gebracht.
Beim core 1.9.0 sind zum compilieren die folgenden Files notwendig:
bitstore.h
cc1101.h
FastDelegate.h
output.h
RF_Receiver_41x.ino
signalDecoder4.cpp
signalDecoder4.h
SimpleFIFO.h
tools.hEmpfehlungen zur Arduino IDE board Konfig:
Optimize: "Fast (-O1)"
C Runtime Library: "Newlib Nano (default)"
Upload method: "Bootloader 2.0"
Für USB:
USART support Enabled (no generic Serial)
USB support CDC (generic Serial supersede U(S)ART)
Für Serial:
USART support Enabled (generic Serial)
USB support keine
Für LAN:
USART support Enabled (no generic Serial)
USB support keine
Ich bin inzwischen soweit, daß es auch mit mehreren cc1101 funktioniert.
Ich weiß noch nicht so richtig wie ich es mit den Versionsnr mache.
Meine Version mit nur einem cc1101 hat die Version: 4.0.1-dev
Welche Versionsnr verwende ich dann bei der Version bei der auch bis zu 4 cc1101 unterstützt werden? 4.0.2 oder 4.1.0
Ich bin gerade an einer Beschreibung, damit das mit den 10 EEPROM Speicherbänken verständlicher wird.
Mach doch direkt die Unterstützung für alle cc1101 rein.
Gesendet von meinem MI 9 mit Tapatalk
Ich habe hier mal eine Beschreibung angefangen:
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463
Zitat von: sash.sc am 28 Februar 2020, 18:23:57
Mach doch direkt die Unterstützung für alle cc1101 rein.
Die Unterstützung von bis zu 4 cc1101 habe ich bei mir schon drin.
Hier ist eine Testversion 4.1.0-dev200301 bei der bis zu 4 cc1101 Module unterstützt werden. USB funktioniert momentan nur mit dem orginal Bootloader.
https://github.com/Ralf9/SIGNALDuino/releases
https://github.com/Ralf9/SIGNALDuino/tree/dev-r41x_cc1101
Gruß Ralf
Ich habe hier bei der ersten Nachricht eine Beschreibung der Hard- und Firmware angefangen.
Vorerst gibt es nur bin files für USB, LAN kommt später
@Telekatz, @papa
ich möchte beim FSK Empfang auch die RSSI abfragen, ich habe es mir so gedacht, hat dies irgendwelche Nachteile?
if (isHigh(pinReceive[radionr])) { // wait for CC1100_FIFOTHR given bytes to arrive in FIFO
if (LEDenabled) {
blinkLED=true;
}
fifoBytes = cc1101::getRXBYTES();
if (fifoBytes > 0) {
uint8_t RSSI = cc1101::getRSSI()
Gruß Ralf
Da kann ich auch nicht wirklich helfen. Beim Homematic-Empfang steht der RSSI Wert direkt hinter dem Paket.
Ich habe das RSSI beim FSK Empfang mal so eingebaut, es scheint einigermaßen zu passen.
Mir ist aufgefallen das die RSSI um ca 5 dB schwankt.
Beim TX29DTH-IT sind bei ähnlicher Entfernung die RSSI Werte um ca 5-10 dB besser als beim PCA301.
Ich möchte eine ToDoListe machen, passt dies hier rein oder ist es besser im Github?
Im Github können die erledigten Einträge abgehakt werden, geht dies hier im fhem Forum auch?
Zitat von: Ralf9 am 10 März 2020, 10:23:33
Ich möchte eine ToDoListe machen, passt dies hier rein oder ist es besser im Github?
Ich mache das immer im ersten Post, den ich dann entsprechend ändere (-> erl., bzw. farblich kennzeichnen).
Im github wäre das vermutlich etwas professioneller.
Gruß Peter
Zitat von: Ralf9 am 06 März 2020, 16:19:12
@Telekatz, @papa
ich möchte beim FSK Empfang auch die RSSI abfragen, ich habe es mir so gedacht, hat dies irgendwelche Nachteile?
if (isHigh(pinReceive[radionr])) { // wait for CC1100_FIFOTHR given bytes to arrive in FIFO
if (LEDenabled) {
blinkLED=true;
}
fifoBytes = cc1101::getRXBYTES();
if (fifoBytes > 0) {
uint8_t RSSI = cc1101::getRSSI()
Gruß Ralf
wäre es nicht besser, per Interrupt die Bytes + RSSI in eine eigene FiFo zu schreiben und die Verarbeitung "nur" auf dieser laufen zu lassen?
Zumidest wird das im Davis-Sketch (RFM69 Funkchip) so gemacht. Hab ich auch "nur" kopiert.
Zitatwäre es nicht besser, per Interrupt die Bytes + RSSI in eine eigene FiFo zu schreiben und die Verarbeitung "nur" auf dieser laufen zu lassen?
Nein, die Bytes + RSSI werden hier nicht verarbeitet, sondern direkt ausgegeben. Die Verarbeitung erfolgt im Signalduino Modul
Zitat von: Ralf9 am 28 Februar 2020, 17:59:48
Was für eine Hardware verwendest Du zum Testen?
Diese hier (https://forum.fhem.de/index.php/topic,80872.0.html).
Ich bin zwei Schritte vorangekommen. maple_mini_boot.bin Bootloader ist drauf und das Flashen der Firmware hat auch funktioniert:
sudo dfu-util -d 1eaf:0003 -a 1 -D Maple_cul_USB_410dev200306.bin -R
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download [=========================] 100% 56104 bytes
Download done.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime modeAber ccconf liefert eine Frequenz von 6656.000 MHz zurück!
Internals:
CFGFN
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
DEF /dev/ttyACM0@115200
DMSG nothing
DevState initialized
DeviceName /dev/ttyACM0@115200
FD 11
FUUID 5e67fb25-f33f-68ff-7223-5befd1b120383244
IDsNoDispatch 2,72.1,82
LASTDMSG nothing
LASTDMSGID nothing
NAME MapleMini
NR 45
PARTIAL
STATE opened
TIME 1583872805
TYPE SIGNALduino
hasCC1101 1
sendworking 0
version V 4.1.0-dev200306 SIGNALduino cc1101 (R: B-*) - compiled at Mar 7 2020 14:27:50
versionProtocols 1.10
versionmodul v3.4.1
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
28:SD_Keeloq ^P(?:87|88)#.*
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2020-03-10 21:44:42 ccconf freq:6656.000MHz bWidth:58KHz rAmpl:42dB sens:16dB (DataRate:1621826.17Baud)
2020-03-10 21:40:14 config MS=1;MU=1;MC=1;Mred=0_MScnt=4;maxMuPrint=768;maxMsgSize=1024;Mdebug=1;MdebFifoLimit=120/170
2020-03-10 21:46:35 ping OK
2020-03-10 21:44:35 state opened
2020-03-10 21:44:35 version V 4.1.0-dev200306 SIGNALduino cc1101 (R: B-*) - compiled at Mar 7 2020 14:27:50Angeschlossen ist nur ein 868 MHz Transceiver. Wie hier (https://github.com/Ralf9/SIGNALDuino/blob/dev-r41x_cc1101/SIGNALDuino.ino) definiert:
#elif MAPLE_CUL
#define PIN_LED 33
#define PIN_SEND 17 // gdo0 Pin TX out
#define PIN_RECEIVE 18a-culfw für MapleCUL liefert korrekte Werte zurück.
ZitatAngeschlossen ist nur ein 868 MHz Transceiver.
Wie ist er angeschlossen?
so
CC1101_0 (A)
31 CSN (Chip Select)
oder so?
CC1101_1 (B)
12 CSN (Chip Select)
Die Befehle werden ausgeführt entweder in der Arduino IDE im seriellen Monitor
oder mit
get sduino raw
Was ergibt ein:
Falls CC1101_0 (A)
CREAsollte ergeben:
detect A: Partn=0 Ver=20Falls CC1101_1 (B)
CREBsollte ergeben:
detect B: Partn=0 Ver=20Was ergibt ein
C99
@Telekatz
gibt es einen besonderen Grund warum hier CC1100_READ_BURST verwendet wird und nicht CC1100_READ_SINGLE?
https://github.com/heliflieger/a-culfw/blob/f4305ea7ca9aba2ace6978c9c29e2645072e5c66/culfw/clib/cc1100.c#L431
uint8_t
cc1100_readReg(uint8_t addr)
{
CC1100_ASSERT;
cc1100_sendbyte( addr|CC1100_READ_BURST );
uint8_t ret = cc1100_sendbyte( 0 );
CC1100_DEASSERT;
return ret;
}
Gruß Ralf
Zitat von: Ralf9 am 10 März 2020, 23:00:04
Wie ist er angeschlossen?
Die Maple_cul_USB_410dev200306.bin Firmware kann nicht funktionieren, da die Portbelegung für CC1101_0 (A) mit dem MapleCUL (https://wiki.fhem.de/wiki/Datei:MapleCUN.jpg) nicht übereinstimmt:
4 MOSI
5 MISO
6 SCLKCC1101_0 (A)
7 CSN (Chip Select)
11 GD02 (Receive)
10 GD00 (Send)
CC1101_1 (B)
12 CSN (Chip Select)
18 GD02 (Receive)
17 GD00 (Send)
CC1101_2 (C)
15 CSN (Chip Select)
16 GD02 (Receive)
13 GD00 (Send)
CC1101_3 (D)
3 CSN (Chip Select)
14 GD02 (Receive)
Ich hatte die falsche Belegung gepostet:
https://github.com/Ralf9/SIGNALDuino/blob/976b9a39016cc04d5e4cf913c59f620b0cf72109/cc1101.h#L32
#elif MAPLE_CUL
#define mosiPin 4 // MOSI out
#define misoPin 5 // MISO in
#define sckPin 6 // SCLK out
SPIClass SPI_2(mosiPin, misoPin, sckPin);
const uint8_t radioCsPin[] = {7, 12, 15, 3};
Zitat von: Ralf9 am 11 März 2020, 00:36:56
@Telekatz
gibt es einen besonderen Grund warum hier CC1100_READ_BURST verwendet wird und nicht CC1100_READ_SINGLE?
https://github.com/heliflieger/a-culfw/blob/f4305ea7ca9aba2ace6978c9c29e2645072e5c66/culfw/clib/cc1100.c#L431
uint8_t
cc1100_readReg(uint8_t addr)
{
CC1100_ASSERT;
cc1100_sendbyte( addr|CC1100_READ_BURST );
uint8_t ret = cc1100_sendbyte( 0 );
CC1100_DEASSERT;
return ret;
}
Gruß Ralf
Ich nehme an, es wurde deshalb gemacht, um auch auf die Register ab 0x30 zugreifen zu können:
ZitatFor register addresses in the range 0x30-
0x3D, the burst bit is used to select between
status registers, burst bit is one, and command
strobes, burst bit is zero (see 10.4 below).
Because of this, burst access is not available
for status registers and they must be accesses
one at a time. The status registers can only be
read.
Ich habe in der ersten Nachricht die Beschreibung zur Version Ausgabe ergänzt:
Mit V (get Version) bekommt man eine Übersicht über die Module z.B. (R: A1 B0*). Mit * wird das selektierte cc1101 Modul markiert
Ein "-" hinter dem Modul (A-D), bedeuted, daß dieses Modul nicht richtig erkannt wurde,
ein "i" bedeuted, daß das Modul zwar korrekt erkannt wurde, aber noch keiner Bank zugeordnet wurde.
Wenn ein Modul nicht aufgeführt ist, dann ist es noch deaktiviert.
Bei der zweiten Nachricht habe ich eine to do Liste angefangen
Zitatversion V 4.1.0-dev200306 SIGNALduino cc1101 (R: B-*) - compiled at Mar 7 2020 14:27:50
Das "-" hinter B bedeutet, daß das zweite Modul (B) nicht richtig erkannt wurde.
ZitatAber ccconf liefert eine Frequenz von 6656.000 MHz zurück!
Ich kann dieses Problem bei mir nicht nachvollziehen.
Ich habe zum Testen auch mal einen blauen Maple Mini mit 10cm Dupont Kabeln mit einem 433 MHz D-SUN cc1101 verbunden (siehe Anlage).
Ich habe die Maple Cul Belegung und die Binary "Maple_cul_USB_410dev200306" verwendet und es hat alles gepasst.
Ich habe es auch mit einem grünen Maple Mini an einem blauen neuftech cc1101 Modul und einer grünen 886 MHz getestet (siehe Anlage)
Gruß Ralf
Hi zusammen,
die Platinen sind gekommen. Bei Interesse bitte hier melden: https://forum.fhem.de/index.php/topic,109220.0.html
Grüße
Zitat von: Ralf9 am 14 März 2020, 00:45:55
Ich habe zum Testen auch mal einen blauen Maple Mini mit 10cm Dupont Kabeln mit einem 433 MHz D-SUN cc1101 verbunden (siehe Anlage).
Ich habe die Maple Cul Belegung und die Binary "Maple_cul_USB_410dev200306" verwendet und es hat alles gepasst.
Selbstverständlich funktioniert deine Schaltung.
ZitatDas "-" hinter B bedeutet, daß das zweite Modul (B) nicht richtig erkannt wurde.
Ich kann dieses Problem bei mir nicht nachvollziehen.
Das Modul B ist gar nicht angeschlossen, daher sind die 6656 MHz nachvollziehbar. Nachdem ich nun ein 433 MHz Modul eingelötet habe, funktioniert die Erkennung zumindest für das Modul B korrekt.
Modul A wird nach wie vor nicht erkannt, weil der Chip Select standardmäßig beim MapleCUL auf Pin 7 (PA4) liegt. Siehe Antwort #146 (https://forum.fhem.de/index.php/topic,106278.msg1031027.html#msg1031027)
ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
version V 4.1.0-dev200306 SIGNALduino cc1101 (R: B0*) - compiled at Mar 7 2020 14:27:50ZitatIch habe es auch mit einem grünen Maple Mini an einem blauen neuftech cc1101 Modul und einer grünen 886 MHz getestet (siehe Anlage)
Übrigens hat die Antenne an deinem 868 MHz Transceiver eine falsche Länge. Siehe Fehlerhafte CC1101 Module (https://forum.fhem.de/index.php/topic,91740.msg1010733.html#msg1010733)
Hast du das Modul A mit CREA aktiviert?
Danke für den Hinweis!
configRadio:
set MapleMini raw CREA
Ergebnis:
cc1101 (R: Ai B0*)
Speicherbank initialisieren:
set MapleMini raw bA1
Ergebnis:
cc1101 (R: A1 B0*)
freq:800.000MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:115051.27Baud)
Frequenzkorrektur:
set MapleMini cc1101_frequency 868.350
Ergebnis:
freq:868.350MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:115051.27Baud)
... soweit alles tutti.
@locutus
Danke fürs Testen.
ZitatÜbrigens hat die Antenne an deinem 868 MHz Transceiver eine falsche Länge.
Danke für den Hinweis.
Dadurch lässt es sich wahrscheinlich erklären, warum das Modul auch bei 433 MHz so gut funktioniert.
Gruß Ralf
Hier noch einige Hinweise und Tipps für diejenigen die seither nur einen Cul hatten.
Die Baudrate bei USB wurde auf 115200 erhöht.
Wenn die raw Befehle mit get sduino raw gesendet werden, wird eine Antwort angezeigt.
Beim Cul müssen normalerweise zwei gleiche Nachrichten empfangen werden, damit sie ausgegeben werden.
Beim sduino gibts dafür das Attribut "doubleMsgCheck_IDs"
Per default ist nur das zweite Modul B aktiviert. Z.Zt. kann bei dieser sduino Version nur das Modul B für OOK/ASK (SlowRF) verwendet werden. Edit: ab der V4.1.2 kann auch das Modul A für OOK/ASK verwendet werden.
Definition in Fhem siehe hier:
https://wiki.fhem.de/wiki/Maple-SignalDuino#Nutzung_in_FHEM_2
Erste schritte:
Hier sind der Einfachheit alles raw Befehle, diese können auch im Seriellen Monitor der Arduini IDE eingegeben werden.
Bei der USB Version ist
XQW
zu empfehlen, damit wird nach einem Reset der Empfang des cc1101 nicht automatisch aktiviert. Dies kann in einigen Fällen zur Optimierung der Initialisierung beim Fhem Modul nötig sein und ist an "irx0" in der Version erkennbar.
Das freeram ist beim Maple Mini deutlich größer als beim nano
R
10964
Bei Version sieht man am Anfang, daß nur das Modul B aktiv ist
V
(R: B0*)
Das folgende ist nicht notwendig, wenn nur das zweite cc1101 (Radio B) verwendet wird
Es ist zu empfehlen zuerst die weiteren cc1101 Module zu aktivieren, damit sieht man auch gleich ob die Module sauber erkannt werden.
Damit wird das erste Modul A aktiviert (als Ver kann auch ein anderer Wert angezeigt werden)
CREA
detect A: Partn=0 Ver=14
Damit wird ggf das Modul C aktiviert
CREC
detect C: Partn=0 Ver=14
Version ergibt dann (Ein "-" bedeuted, daß das Modul nicht erkannt wurde, z.B. "C-")
V
(R: Ai B0* Ci)
Nun können die Bänke mit den rfmodes "gefüttert" werden:
Damit wird die Bank 1 selektiert (wenn wie hier nur ein cc1101 Modul zugeordnet ist, dann reicht es wenn nur die Bank angegeben wird)
b1 oder get sduino cmdBank 1
Wenn die Bank noch nicht initialisiert ist, kommt die folgende Antwort
The bank 1 was not complete initialized, therefore the bank and radio is reseted to sduino defaults (raw e). ccFactoryReset done
Version ergibt nun
V
(R: B1*)
Nun kann die gewählte Bank 1 mit dem gewünschten rfmode "gefüttert" werden
Das "füttern" der Bänke kann komfortabel mit set rfmode gemacht werden oder auch über den raw Befehl:
get sduino raw CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,...
Hier ist eine Übersicht:
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067
danach kann z.B. die Bank 2 selektiert und mit dem gewünschten rfmode "gefüttert" werden
usw
wenn alle gewünschten Bänke definiert sind, dann kann z.B mit
bA1W und bC3W
dem Radio A die Bank 1 und Radio C die Bank 3 zugeordnet und initialisiert werden. Durch das Anhängen von W bleibt die Zuordnung, durch das Speichern im EEPROM, nach einem Reset erhalten.
Bei Version wird dann aus
(R: Ai B0* Ci)
z.B. das:
(R: A1 B0* C3)
Mein Feedback zur aktuellen Platine:
Sieht für mich vorerst gut aus.
Generell will ich an der Platine ändern:
-statt zwei Bohrungen die nicht so 100% passen ein Langloch
-Kondensator zur Spannungsstabilisierung verlegen, der kollidiert, falls man ihn bestückt, bei großer Ausführung mit Maple-Bauteilen und würde das direkte einlöten des LAN Moduls (wegen dessen Pin-Länge) über dem Maple verhindern.
-Transceiver 3 -Kontakte leicht verschieben, da dieser exakt 0mm Abstand zum LAN-Modul hat (zu klären: ob Transceiver 3 + LAN Modul gleichzeitig überhaupt mechanisch Sinn macht...)
-Das Thema saubere Abschirmung halte ich kaum machbar ohne Nachteile (höhere Kurzschlussgefahr bei der Antenne, bedeutet längere Platine erforderlich, und im Prinzip auch breitere Platine wenn man die Zuührung zur SMA Buchse nicht verlängern will)
-Die Außenmaße möchte nur im Notfall ändern. Die sind gut. Ohne LAN ist Schrumpfschlauch das einfachste Gehäuse.
Hallo Ralf9,
ich versuche mich gerade am Arduino-IDE-Comiple der SIGNALDuino-4.1.0-dev200306 und scheitere am
eeprom_buffered_write_byteZitatexit status 1
'eeprom_buffered_write_byte' was not declared in this scope
Using library fastdelegate at version 1.0.0 in folder: C:\Users\js\Documents\Arduino\libraries\fastdelegate
Using library output at version 1.0.0 in folder: C:\Users\js\Documents\Arduino\libraries\output
Using library bitstore at version 1.0.0 in folder: C:\Users\js\Documents\Arduino\libraries\bitstore
Using library signalDecoder at version 1.0.0 in folder: C:\Users\js\Documents\Arduino\libraries\signalDecoder
Using library SimpleFIFO at version 1.0.0 in folder: C:\Users\js\Documents\Arduino\libraries\SimpleFIFO
Using library EEPROM in folder: C:\Users\js\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\EEPROM (legacy)
Using library SPI at version 1.0 in folder: C:\Users\js\Documents\Arduino\hardware\Arduino_STM32\STM32F1\libraries\SPI Gefunden hab ich hier in den Samples etwas: https://github.com/stm32duino/STM32Examples, allerdings keine verwertbare Lib dazu.
Hast Du da vielleicht bein Tipp?
Grüße,
Jürgen
Hallo Jürgen,
welchen Core und welche Arduino IDE Version verwendest Du?
kannst Du dieses Beispiel compilieren
https://github.com/stm32duino/STM32Examples/blob/master/examples/NonReg/BufferedEEPROM/BufferedEEPROM.ino
Gruß Ralf
Ja klar, geht auch nicht.
Die core-Version in
C:\Users\js\Documents\Arduino\hardware\Arduino_STM32 hat ein Timestamp von 13.06.2017.
Ist also doch auch schon etwas betagt.
Ich versuche mal ein Install der neuesten Version ... und probiere es dann nochmal ....
/edit: mit der neuesten Version von hier: https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation (https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation) vom 13.3.2020 ging es auch nicht ....
Alternativen (?):
- https://github.com/stm32duino/Arduino_Core_STM32
- https://www.stm32duino.com/viewtopic.php?f=39&t=12
Dann ergänzt:
http://dan.drown.org/stm32duino/package_STM32duino_index.json,https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json in Preferences.txt...
Update der Installierten auf 1.0.5 der "https://github.com/stm32duino/STM32Examples"
Ohne Erfolg...
Danke + Grüße
Jürgen
Ich verwende dies:
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
Habe ich auch hier beschrieben
https://forum.fhem.de/index.php/topic,106278.msg1027914.html#msg1027914
Gruß Ralf
Die fehlende Installatation von "STM32 cores STMicroelectronics" über den BoardManager war dann wohl das Problem ...
Hoffe das vertägt sich mit allen anderen Installationen ...
Jürgen
@Ralf: Solche Diskussionen würden sich von selbst erledigen wenn du mittelfristig das Projekt in PlatformIO integrieren würdest. Da zieht sich die Umgebung pro Projekt von selbst die definierten Libs... Das machen heute viele so. Vor allem größere Projekte mit vielen Abhängigkeiten sind oft nur noch schwer mit der Arduino IDE selbst zu kompilieren. Ein Beispiel dazu "die" komplexe Firmware für viele Micro-Controller für 3D-Drucker: https://github.com/MarlinFirmware/Marlin/blob/2.0.x/platformio.ini
Das mit PlatformIO sieht recht kompliziert aus, da ist wahrscheinlich ein recht großer Einarbeitungsaufwand notwendig.
Zitatich versuche mich gerade am Arduino-IDE-Comiple der SIGNALDuino-4.1.0-dev200306 und scheitere am eeprom_buffered_write_byte
Das Problem ist momentan das es zwei verschiedene cores gibt, die nicht zueinander Kompatibel sind
https://github.com/stm32duino
und
https://github.com/rogerclarkmelbourne
Hat jede seine Vor- und Nachteile
Beim core von roger z.B. gibt es keine gepufferte EEPROM Zugriffe und es können nur 16 Bit Werte ins EEPROM geschrieben und gelesen werden.
Eigentlich nicht. Es kommt halt auf die Anzahl der Libs an. (Platform ist ja nur eine)
Hab gerade 3-4 andere Themen. Anschliessend würde ich mir das ggf. mal ansehen fall niemand schneller ist. (Da ich nicht der Vollprofi bin geschätzt: Ein Stündchen, falls die Sache mit dem Core+Libs nicht zu schwierig ist)
Hallo Zusammen,
es hat funktioniert ...
Bis auf den TimerOne-Error, aber den finde ich heraus . (;-)
C:\Users\js\AppData\Local\Temp\arduino_build_114648\sketch\src\_micro-api\libraries\TimerOne\src\TimerOne.cpp:21:16: error: 'short unsigned int TimerOne::pwmPeriod' is not a static data member of 'class TimerOne'
C:\Users\js\AppData\Local\Temp\arduino_build_114648\sketch\src\_micro-api\libraries\TimerOne\src\TimerOne.cpp:22:15: error: 'unsigned char TimerOne::clockSelectBits' is not a static data member of 'class TimerOne'
C:\Users\js\AppData\Local\Temp\arduino_build_114648\sketch\src\_micro-api\libraries\TimerOne\src\TimerOne.cpp:23:8: error: 'void (* TimerOne::isrCallback)()' is not a static data member of 'class TimerOne'
TimerOne wird beim MAPLE_Mini gar nicht verwendet
#ifdef MAPLE_Mini
#include <malloc.h>
extern char _estack;
extern char _Min_Stack_Size;
static char *ramend = &_estack;
static char *minSP = (char*)(ramend - &_Min_Stack_Size);
extern "C" char *sbrk(int i);
#else
#include <TimerOne.h> // Timer for LED Blinking
#endif
@Ranseyer
Ich habe die Platine zusammen gelötet, funktioniert soweit.
Dabei ist mir aufgefallen, daß die beiden cc1101 Module vertauscht sind,
das erste Modul (A) ist 433 MHz
das zweite Modul (B) ist 868 MHz
Ich bin davon ausgegangen, daß um mit dem Maple Cul kompatibel zu sein, das erste Modul 868 MHz ist
Nachtrag:
Das 433 MHz Modul hat die Version 0x18, diese kann ich hier nicht finden
https://e2e.ti.com/support/wireless-connectivity/other-wireless/f/667/t/370643?CC1101-VERSION-register-interpretation
Gruß Ralf
Zitatdie beiden cc1101 Module vertauscht sind
Du meinst die Beschriftung ? (Das würde ich dann in der nächsten Version ändern)
PS: Die SMA-Buchsen lötest du sowieso rechts+links direkt an die Ground-Fläche. Und die Groud-Flächen oben+unten sind auch reichlich verbunden. Die Drahtbrücken sind m.E. eher unnötig. (Oder konntest du damit irgendwelche Effekte feststellen ?
Ja, die Beschriftung ist demnach vertauscht.
Nur wie machen wir es dann mit den Platinen die bereits falsch gelötet sind. Die Module wieder auslöten ist mir zu kompliziert.
Kann man die Frequenz SW-mäßig vorgeben ? (Dann wäre die Lösung: Edding + Konfiguration)
Zitat von: Ralf9 am 21 März 2020, 20:25:31
Nachtrag:
Das 433 MHz Modul hat die Version 0x18, diese kann ich hier nicht finden
https://e2e.ti.com/support/wireless-connectivity/other-wireless/f/667/t/370643?CC1101-VERSION-register-interpretation
0x18 gehört zum CC113L. Eigentlich nur ein Receiver.
Mich würde erst mal interessieren, wieviele Platinen schon vertauscht gelötet sind.
20 Platinen sind unterwegs. Bei mir zwei verlötet. Bei einer ist der Maple kaputt weil nicht vorher getestet.
Ich finde es relativ simpel die Teile mit Heißluft oder notfalls mit dem Lötkolben und reichlich Zinn herunter zu bekommen. (Nur wenn man etwas zu hektisch ist und mit Kraft arbeitet reisst man Leiterbahnen ab.)
Aber: Macht es nicht Sinn auch mal temporär die Module mit der anderen Frequenz zu betreiben können (Dass die Leistung dann um (3dB oder 6dB) schlechter wird, akzeptiert man in dem Fall) ?
ZitatAber: Macht es nicht Sinn auch mal temporär die Module mit der anderen Frequenz zu betreiben können (Dass die Leistung dann um (3dB oder 6dB) schlechter wird, akzeptiert man in dem Fall) ?
Wenn ich das 433 MHz Modul (CC113L), das ich von Dir bekommen habe mit 868 MHz betreibe, kann ich nicht senden.
Momentan kann die Firmware bei ASK (slowrf) nur beim 2ten Modul (B) senden, da müsste ich in der Firmware was anpassen.
Wenn ich der einzigste bin der die Platine bereits gelötet hat, sehe ich kein Problem, die andern müssten dann eben die Beschriftung korrigieren
Hallo Martin,
bei meiner Platine ist der BOOT1-Pin nicht mit GND verbunden ... entgegen dem Schaltplan ...
Pin Belegung zum Bootloader flashen:
FTDI-GND an MapleMini-GND
FTDI-VCC an MapleMini-VCC
FTDI-TX an MapleMini-rx1
FTDI-RX an MapleMini-tx1
MapleMini-boot1 an MapleMini-GNDIst bei der Platine die mit "DBG" bezeichnete Stiftleiste ...
ZitatWenn ich der einzigste bin der die Platine bereits gelötet hat,
... gerade die CC1101 eingelötet gehabt ;-(
Noch zum Compile (mit zweierlei Gewalt) :
//#define MAPLE_Mini
//#ifdef MAPLE_Mini
#include <malloc.h>
extern char _estack;
extern char _Min_Stack_Size;
static char *ramend = &_estack;
static char *minSP = (char*)(ramend - &_Min_Stack_Size);
extern "C" char *sbrk(int i);
//#else
// #include <TimerOne.h> // Timer for LED Blinking
//#endif
Obwohl ich nur noch Warnings im Output finden konnte...
Mache morgen mal ein Platformio-Projekt draus ...
GD32VF103 (https://github.com/sipeed/platform-gd32v/tree/master/examples/longan-nano-blink) als Anhaltspunkt und Doku (https://docs.platformio.org/en/latest/core/index.html). Auch für: Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board (https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.html)
https://docs.platformio.org/en/latest/platforms/ststm32.html (https://docs.platformio.org/en/latest/platforms/ststm32.html)
Zitat0x18 gehört zum CC113L. Eigentlich nur ein Receiver.
Zum Glück nur eigentlich ;D
Das 433 Modul weiß anscheinend nicht das es mit der Version 0x18 eigentlich nicht senden kann, das Senden funktioniert trotzdem.
ZitatAber: Macht es nicht Sinn auch mal temporär die Module mit der anderen Frequenz zu betreiben können (Dass die Leistung dann um (3dB oder 6dB) schlechter wird, akzeptiert man in dem Fall) ?
Ja, da das 433 Modul trotz der falschen Version sendet, ist es für mich momentan auch ok, wenn wegen der falschen Frequenz die Leistung dann um (3dB oder 6dB) schlechter wird.
Gruß Ralf
Hallo Ralf9,
wo hast Du den Namespace für z.B. "cc1101::regCheck())" definiert?
Processing maple_mini_origin (platform: ststm32; board: maple_mini_origin; framework: arduino)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/maple_mini_origin.html
PLATFORM: ST STM32 6.0.0 > Maple Mini Original
HARDWARE: STM32F103CBT6 72MHz, 17KB RAM, 108KB Flash
DEBUG: Current (blackmagic) External (blackmagic, jlink, stlink)
PACKAGES:
- framework-arduinoststm32 3.10700.191028 (1.7.0)
- tool-dfuutil 1.9.200310
- toolchain-gccarmnoneeabi 1.70201.0 (7.2.1)
Converting SIGNALDuino.ino
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 15 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <CC1101> 1.0
| |-- <SPI> 1.0
|-- <fastdelegate> 1.0.0
|-- <output> 1.0.0
| |-- <SPI> 1.0
|-- <SPI> 1.0
|-- <signaldecoder> 1.0.0
| |-- <output> 1.0.0
| | |-- <SPI> 1.0
| |-- <fastdelegate> 1.0.0
| |-- <bitstore> 1.0.0
|-- <TimerOne> 1.0.0
|-- <SimpleFIFO> 1.0.0
|-- <EEPROM> 2.0.1
|-- <bitstore> 1.0.0
Building in debug mode
Compiling .pio\build\maple_mini_origin\src\SIGNALDuino.ino.cpp.o
Archiving .pio\build\maple_mini_origin\liba32\libsignalDecoder.a
Compiling .pio\build\maple_mini_origin\libc8e\TimerOne\TimerOne.cpp.o
Archiving .pio\build\maple_mini_origin\libc2f\libSimpleFIFO.a
Da ist noch einiges zu tun um es in PlatformIO zum Laufen zu bringen , bzw. erst mal den Code etwas aufräumen ... ;)
Wer mag, kann sich das mal mit VSCode + PlatformIO mit anschauen (https://docs.platformio.org/en/latest/integration/ide/pioide.html) ... + youtube (https://www.youtube.com/watch?v=EIkGTwLOD7o) mit ATOM-Editor.
Ich benutze allerdings VSCode, der auch unter Linux (Raspi) läuft. (code-oss (https://medium.com/@equus3144/install-vs-code-on-raspbian-raspberry-pi-3-model-b-eb895a9aff6f))
Das Zip ist (unter Windows) im PIO-Standard-Pfad "C:\Users\<user>\Documents\PlatformIO\Projects" zu entpacken dann in VSCode mit PIO "Open project ... " zu öffnen.
Ist aber noch Status "preliminary" ;) und noch buggy.
TODO: COM-PORT(s) in Platformio.ini anpassen! (Momentan muss er zum Compile mit F5 (Debug) leider vorhanden sein!
https://docs.platformio.org/en/latest/projectconf/index.html (https://docs.platformio.org/en/latest/projectconf/index.html)
Aber muss erst mal den Bootloader auf Ranseyers Board bekommen :'(
Anmerkungen:
Bootloader für Maple: https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/STM32F1/binaries/maple_mini_boot20.bin (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/STM32F1/binaries/maple_mini_boot20.bin)
STMFlashLoader: http://gechologic.com/how-to-use-stm32-flash-loader (http://gechologic.com/how-to-use-stm32-flash-loader)
Arduino Python Uploader : C:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32\tools\win
Arduino Java Uploader C:\Users\js\Documents\Arduino\hardware\Arduino_STM32/tools/win/maple_upload.bat COM17 1 1EAF:0003 C:\Users\js\AppData\Local\Temp\arduino_build_180552/Blink.ino.bin
Mit maple_upload.bat <Maple COM Port> 1 <USB Device ID>
Grüße
Jürgen
Bitte PlatformIO-Sourcen von hier (https://forum.fhem.de/index.php/topic,106278.msg1033853.html#msg1033853) nehmen.
ZitatObwohl ich nur noch Warnings im Output finden konnte...
Ein warning war, daß bei sprintf %i bei unsigned Variablen verwendet wurden, habs nach %u und %x korrigiert.
Andere warnings sind:
uint8_t bval;
message.getByte(bstartpos,&bval);Wenn ich schreibe "uint8_t bval=0;" , erzeugt dies zusätzlichen unnötigen Code, oder ist dies besser, da dann die warnings weg sind?
Hallo Jürgen
Zitatbei meiner Platine ist der BOOT1-Pin nicht mit GND verbunden
Bei meiner ist der BOOT1-Pin mit GND verbunden.
ZitatAber muss erst mal den Bootloader auf Ranseyers Board bekommen
Momentan funktioniert USBserial nur mitr dem orginal Bootloader, wenn Du einen neuen Maple Mini hast dann sollte der orginal Bootloader schon drauf sein
Zitat... gerade die CC1101 eingelötet gehabt ;-(
ist es für Dich ein Problem die CC1101 wieder auszulöten?
Zum compileren mit der Arduino IDE werden nur die folgenden Dateien benötigt
bitstore.h
cc1101.h
FastDelegate.h
output.h
signalDecoder4.cpp
signalDecoder4.h
SimpleFIFO.h
tools.h
signalDecoder.inoGruß Ralf
Zitatist es für Dich ein Problem die CC1101 wieder auszulöten?
Könntest du bitte im Startpost noch ergängen ?
"Bei den V0.1 und V0.2 Platinen ist die Beschriftung 433 und 868 MHz manuell zu ändern!"
(Unabhängig davon ob dies später mal ggf. konfigurierbar wird. Denke mal der eine oder andere will z.B. 2x 868 Mhz haben auf der bestehenden HW)
Hallo Ralf9,
auslöten ist kein Problem ;-)
Im Moment fehlt mir die Angabe, welche Lib Du für die CC1101 nutzt:
cc1101.h => wo kommt die her ? Insbesondere der Namespaceaufruf mit
cc1101::Zitatbitstore.h
cc1101.h
FastDelegate.h
output.h
signalDecoder4.cpp
signalDecoder4.h
SimpleFIFO.h
tools.h
signalDecoder.ino
Ok, hab's gesehen: hole sie mir von da: https://github.com/Ralf9/SIGNALDuino/blob/master/cc1101.h
Welcher Branch?
ZitatWelcher Branch?
https://github.com/Ralf9/SIGNALDuino/tree/dev-r41x_cc1101
Ich habe es so eingetragen:
Wichtig: Bei den V0.1 und V0.2 Platinen ist die Beschriftung 433 und 868 MHz manuell zu ändern!
433 ist CC0_A
868 ist CC1_B (433 MHz)Zitat
Unabhängig davon ob dies später mal ggf. konfigurierbar wird. Denke mal der eine oder andere will z.B. 2x 868 Mhz haben auf der bestehenden HW
Die Frequenz ist frei konfigurierbar.
Es können auch alle 3 cc1101 mit 868 bestückt werden.
Momentan gibt es die Einschränkung, daß ASK/OOK (slowrf) nur auf dem zweiten Modul cc1 (B) geht.
Gruß Ralf
Zitat(slowrf) nur auf dem zweiten Modul
Ah, verstanden !
OK, hatte den falschen Branch genommen und das Platformio-Projekt mit den neuen Dateien des Branches: dev-r41x_cc110 angepasst.
Wenn der Compile durchläuft, stelle ich es wieder hier ein ...
Linking .pio\build\maple_mini_origin\firmware.elf
Building .pio\build\maple_mini_origin\firmware.bin
Checking size .pio\build\maple_mini_origin\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [=== ] 28.0% (used 4880 bytes from 17408 bytes)
Flash: [===== ] 52.1% (used 57592 bytes from 110592 bytes)
========================= [SUCCESS] Took 3.84 seconds =========================
Mit einigen Änderungen + Korrekturen und dem richtigen Branch ...
Dann schaue ich mal, ob der der Compile auch das tut, was er soll ;-)
Binary zum Flashen findet man nach dem Compile dort: "C:\Users\<user>\Documents\PlatformIO\Projects\MapleSDuino\.pio\build\maple_mini_origin\firmware.bin"
Zitat von: Ralf9 am 22 März 2020, 11:08:44
Andere warnings sind: warning 'bval' may be unused uninitialized..
uint8_t bval;
message.getByte(bstartpos,&bval);
Wenn ich schreibe "uint8_t bval=0;" , erzeugt dies zusätzlichen unnötigen Code, oder ist dies besser, da dann die warnings weg sind?
Wie ist Eure Meinung zu solchen warnings?
Zitat von: Ralf9 am 22 März 2020, 14:43:40
Wie ist Eure Meinung zu solchen warnings?
in diesem Fall wird der Speicher der Variablen nicht initialisiert, evtl. macht es der Compiler unter der Haube doch....
Sie sollte ja dann in Deinem genannten Fall den Rückgabewert enthalten.
Bei der Arduino-IDE ist der Output des Compilers farblich gleichförmig, da geht ein error schon mal vor lauter warnings unter.... meist muss ich dann den Output per copy & paste in einen Editor reinnehmen, um den expliziten Error zu entdecken...
Hier ist ein anderer Fall :
"resource": "/c:/Users/js/Documents/PlatformIO/Projects/MapleSDuino/src/cc1101.h",
"owner": "cpp",
"severity": 4,
"message": "unused variable 'ret' [-Wunused-variable]",
"startLineNumber": 236,
"startColumn": 11,
"endLineNumber": 236,
"endColumn": 11
C:/Users/js/Documents/PlatformIO/Projects/MapleSDuino/src/SIGNALDuino.ino:1198:11: warning: unused variable 'statRadio' [-Wunused-variable]
uint8_t statRadio = tools::EEread(addr_statRadio + radionr);
^~~~~~~~~
C:/Users/js/Documents/PlatformIO/Projects/MapleSDuino/src/SIGNALDuino.ino: In function 'void cmd_toggleBank()':
C:/Users/js/Documents/PlatformIO/Projects/MapleSDuino/src/SIGNALDuino.ino:1444:11: warning: variable 'bankOffs' set but not used [-Wunused-but-set-variable]
uint16_t bankOffs;
^~~~~~~~
In file included from src/tools.h:6:0,
from src/cc1101.h:12,
from C:/Users/js/Documents/PlatformIO/Projects/MapleSDuino/src/SIGNALDuino.ino:130:
C:\Users\js\.platformio\packages\framework-arduinoststm32\libraries\EEPROM\src/EEPROM.h: At global scope:
C:\Users\js\.platformio\packages\framework-arduinoststm32\libraries\EEPROM\src/EEPROM.h:247:20: warning: 'EEPROM' defined but not used [-Wunused-variable]
static EEPROMClass EEPROM;
^~~~~~
C:/Users/js/Documents/PlatformIO/Projects/MapleSDuino/src/SIGNALDuino.ino: In function 'void configSET()':
C:/Users/js/Documents/PlatformIO/Projects/MapleSDuino/src/SIGNALDuino.ino:1876:27: warning: 'val16' may be used uninitialized in this function [-Wmaybe-uninitialized]
musterDec.MuSplitThresh = val16;
~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
C:/Users/js/Documents/PlatformIO/Projects/MapleSDuino/src/SIGNALDuino.ino:1872:10: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]
ccmode = val;
~~~~~~~^~~~~
Es gibt eine neue Version 4.1.0-dev200322
https://github.com/Ralf9/SIGNALDuino/releases
Ich habe einige Warnings beseitigt
Gruß Ralf
Hallo Ralf9,
werde meine Platformioversion in Github mit Deinen Änderungen einpflegen, dann ist der Platformio-Stand für alle transparent.
Aktueller Stand: USB-Bootloader waren in meinen Maples schon geflasht, aber der aktuelle Compile läuft noch nicht nach dem Hochladen.
Aber es fehlen bisher ja auch noch spezifische Einstellungen: configuration (https://docs.platformio.org/en/latest/platforms/ststm32.html#configuration)
Das Hochladen mit PlatformIO und dem Maple ist auch noch eine Sache. Bevorzugt scheint zu sein: STLINK (http://cool-web.de/arduino/stm32duino-bootloader-flashen-fuer-usb-zugriff-auf-stm32.htm). Alternative: STM32FlashLoader (http://gechologic.com/how-to-use-stm32-flash-loader) per Kommandozeile. Per Python3-Skript (https://github.com/juergs/stm32loader)
STLINK (http://gechologic.com/uploading-arbitrary-data-to-flash) muss ich bei mir noch installieren und einen STLink-Adapter (https://os.mbed.com/users/hudakz/code/STM32F103C8T6_Hello/) oder BluePill (https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Flashing-Bootloader-for-BluePill-Boards) als Adapter könnte ich mir auch vorstellen, muss aber noch mehr Infos dazu sammeln ...
Im Moment lade ich noch per Arduino-Batch-File hoch :
C:\Users\<user>\Documents\Arduino\hardware\Arduino_STM32/tools/win/maple_upload.bat COM17 1 1EAF:0003 C:\Users\<user>\Documents\PlatformIO\Projects\MapleSDuino\.pio\build\maple_mini_origin\firmware.bin
Slashes ggf anpassen ...
Sollte aber eigentlich doch eleganter gehen ... ;)
Grüße,
Jürgen
PS: BluePill-Bootloader per USB-Drive: bluepill-bootloader (https://github.com/lupyuen/bluepill-bootloader) (HID (https://github.com/Serasidis/STM32_HID_Bootloader/releases)) und HowTo (https://www.youtube.com/watch?v=wGbiT6IxGP0)
Zitat von: Ralf9 am 22 März 2020, 23:05:35
Es gibt eine neue Version 4.1.0-dev200322
get <name> cmdsscheint nicht zu funktionieren.
Gibt es einen Grund für die stark abweichende Frequenz nach der Speicherbankinitialisierung?
version V 4.1.0-dev200322 SIGNALduino cc1101 (R: A1* B0) - compiled at Mar 22 2020 21:48:22
ccconf freq:800.000MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:115051.27Baud)
FSK wird momentan noch nicht vom offiziellen Signalduino FHEM Modul unterstützt, wird gerade eingebaut.
Für die FSK und EEPROM Speicherbank unterstützung ist momentan noch eine angepasste und erweiterte Version der 00_SIGNALduino.pm und die signalduino_protocols.pm notwendig:
https://github.com/Ralf9/RFFHEM/issues/4
Zitat
Gibt es einen Grund für die stark abweichende Frequenz nach der Speicherbankinitialisierung?
Wie hast Du die Bank 1 initialisiert?
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067
Gruß Ralf
Zitat von: Ralf9 am 28 Februar 2020, 17:59:48
Ich verwende bei der Arduino IDE diesen core
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
Das SerialUsb funktioniert bei mir nur mit dem orginal Bootloader.
http://docs.leaflabs.com/static.leaflabs.com/pub/leaflabs/maple-bootloader/maple_mini_boot.bin
Mit dem Bootloader 2.0 funktioniert nach einem reset das serialUSB nicht mehr.
Hallo Ralf9,
ich habe ebenfalls die Arduino IDE zum flashen verwendet. Bei mir funktioniert das serialUSB aber grundsätzlich nach einem Reset nicht mehr. Egal ob original oder 2.0 Bootloader. Ich verwende allerdings einen "Doppel-CUL-868-433-USB Stick für FHEM 1x 868MHz + 1x 433MHz CC1101" ohne FTDI. Eventuell eine Idee oder einen Tipp?
Gruß Reinhard
Funktioniert es mit den fertigen bin Dateien?
Wichtig ist, daß der Orginal Bootloader drauf ist, lässt sich u.a. daran erkennen, daß die upload method Bootloader2.0 nicht funktioniert.
Gruß Ralf
Hallo Zusammen,
es gibt ja ziemlich viele verschiendene Ansichten zum Bootloader.
Ich habe heute mit den verschiedenen Bootloadern herumexperimentieren müssen ....
da mein "blaues" MapleMini-Board den Reset-Button schlecht verlötet hatte und ich fast alle Varianten des Uploads ausprobiern musste.
1. Es existieren verschiedene Varianten des MapleMini-Bootloaders mit dem selben Namen die in Verbindung mit Arduino und SerialUsb funktionieren oder auch nicht.
Wichtig ist: Boot1 muss mit GND verbunden sein!
a.) Die richtige Variante, die ein COM-Port aufspannt =>
"STM32duino bootloader v1.0 Upload to Flash 0x8002000":
Zitatmaple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Searching for DFU device [1EAF:0003]...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=316
Starting download: [##################################################] finished!
error resetting after download: usb_reset: could not reset device, win error: Ein nicht vorhandenes Gerät wurde angegeben.
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
2.) die "falsche " (?) Variante von "
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/binaries/maple_mini_boot20.bin":
ZitatC:\Users\js>C:\Users\js\Documents\Arduino\hardware\Arduino_STM32/tools/win/maple_upload.bat COM4 2 1EAF:0003 D:\Work_FHEM\_maple_sduino\4.1.0-dev200306\Maple_sduino_USB_410dev200306.bin
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Searching for DFU device [1EAF:0003]...
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
Couldn't find the DFU device: [1EAF:0003]
timeout waiting for COM4 serial
Ich hänge mal meine Version, die 100%ig auch nach einem Reset funktioniert an (Version v. 23.6.2019). Die neuere Variante hat 22KB mit gleichen Namen funktioniert nicht mit SerialUSB + Arduino ...
Damit lässt sich das auch über die Kommandozeile flashen:
ZitatC:\Users\js\Documents\Arduino\hardware\Arduino_STM32/tools/win/maple_upload.bat COM4 2 1EAF:0003 D:\Work_FHEM\_maple_sduino\4.1.0-dev200306\Maple_sduino_USB_410dev200306.bin
Anmerkung:
Zitat#####Other improvements on the original Maple bootloader
Smaller footprint - now only 8k (This became possible due to code changes by @jonatanolofsson which allowed the GCC optimisation for size flag to be used
Additional DFU AltID upload type was added, which allows the sketch to be loaded at 0x8002000 instead of 0x8005000 (due to the reduced size of the bootloader itself), Note: Upload to 0x8005000 was retained for backward compatibility.
Der "Additional DFU AltID upload" funktioniert wohl nur mit einer Generic-Device-Einstellung in Arduino und nicht mit "MapleMini" .... als DFU oder HID Bootlaoder ...
Wichtig auch die Kombination kleiner Bootloader und Compile für 0x8002000
Oder aber großer Bootloader und Compile für kleine Variante (0x8002000), der eigentlich für 0x8005000 sein sollte => fatal: Bootloader wird überschrieben und nach Reset ist SerialUSB weg....
Und noch zu beachten:
ZitatSome notes: The Maple Mini original bootloader supports 2 upload modes, selected by the uploader program with a parameter called Upload ID. Upload ID=0 uploads to RAM. (This option has been modified so that it returns an error if used - more details below) Upload ID=1 uploads to Flash. It uploads sketches to 0x8005000, thus reserving the initial 20KB of the flash memory for itself. It also reserves the initial 3KB of ram, so sketches can use up to 17KB.
We added a new upload mode.
Upload ID=2 uploads to Flash. It uploads sketches to 0x8002000, thus reserving the initial 8KB of the flash memory for itself. The bootloader no longer operates with upload to RAM, and hence all RAM in the process is always available to the sketch.
To make use of the new bootloader reduce footprint etc, you need to use an up to date version of the repo, as it has additional menu options for the Maple mini and also for generic boards.
On the Maple mini there is a bootloader menu, which lets you select the original or new bootloader. On generic boards, the new bootloader (called the stm32duino bootloader) is available as an upload option. This option always uses Upload ID = 2 (see above)
maple_upload.bat COM4 2 1EAF:0003 D:\Work_FHEM\_maple_sduino\4.1.0-dev200306\Maple_sduino_USB_410dev200306.bin*Upload ID=2 uploads to Flash
Ist dein blaues MapleMini Board wirklich ein Maple Mini oder ein BluePill?
Hallo Telekatz,
blau ist kein BAITE aber ein MapleMini.
Die Baite-Version ist besser gefertigt und macht einen besseren Eindruck.
Wie kann ich das im STLink umgehen? :
Zitat19:04:57 : Can not connect to target!
Please select "Connect Under Reset" mode from Target->Settings menu and try again.
If you're trying to connect to a low frequency application , please select a lower SWD Frequency mode from Target->Settings menu.
19:05:00 : No target connected
Nur nach "richtigem" Zeitpukt nach Reset drücken kommt ein Connect zustande ... wenn man nicht SWIM_RST durchschleift ...
[Window Title]
Visual Studio Code
[Content]
Failed to launch GDB: .pioinit:13: Error in sourced command file:
Remote communication error. Target disconnected.: Success. (from interpreter-exec console "source .pioinit")
[Open launch.json] [Cancel]Beim BluePill funktionierte das Debuggen über STLink gestern einwandfrei ...
Grüße,
Jürgen
Hat mich nur gewundert, dass Bootloader 2 bei dir nicht funktioniert.
Hab den Bootloader gerade bei mir ausprobiert. Grundsätzlich funktioniert der Bootloader schon. War auch bis vor kurzen der Standard Bootloader für den MapleCUN.
Du musst aber, wenn du den Bootloader auf einen leeren MapleMini flashst, den Bootloader manuell aktivieren. Dann ist noch kein Sketch vorhanden, welcher die Serielle Schnittstelle bereitstellt. Und ohne diese kann das Flashprogramm den Bootloader nicht automatisch aktivieren.
In dem Bootloader, den du angehängt hast, ist ein solcher Sketch im bin File bereits enthalten.
Zitat von: juergs am 24 März 2020, 18:59:42
Wie kann ich das im STLink umgehen? :Nur nach "richtigem" Zeitpukt nach Reset drücken kommt ein Connect zustande ... wenn man nicht SWIM_RST durchschleift ...
Ist der Reset Pin am STLink angeschlossen? Vermutlich schaltet dein Programm SWD beim starten ab. Dann hilft nur "Connect Under Reset", um die SWD Verbindung vor dem Programmstart herzustellen
Hallo Telekatz,
ja das ist einleuchtend, deshalb sind hier auch bootloader mit Welcome-Sketch https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/binaries (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/binaries)
War mir so aber nicht bewusst, dass ein zusätzliche Sketch die USBSerial bereitstellt, dachte das ist ein Feature des Bootloaders ....
RST ist nicht verbunden. Da ich das Kabel selbst gefertigt habe war mir zu dem Zeitpunkt noch nicht klar das RST doch noch erforderlich sein würde.
So kann man sich irren, nachdem es gestern überraschend gut mit dem BluePill funktionierte...
Vielen Dank,
Jürgen
PS: Die Frage wäre dann aber, wie konfiguriert man Arduino, wenn mann den Sketch-less BL nutzt? Serial ist da wohl nicht möglich und die Einstellung "MapleMini" lässt nur ein seriellen Port bzw DFU zu ...
Testweise habe ich den BL MapleMini20.bin mit Sketch geladen ... und es blinkt... allerdings ohne USBSerial...
Der Bootloader stellt nur ein DFU Gerät zur verfügung. Beide sind auch nur 8k groß. Der Rest im bin File ist der Sketch.
Zitat von: juergs am 24 März 2020, 20:14:05
PS: Die Frage wäre dann aber, wie konfiguriert man Arduino, wenn mann den Sketch-less BL nutzt? Serial ist da wohl nicht möglich und die Einstellung "MapleMini" lässt nur ein seriellen Port bzw DFU zu ...
Man aktiviert den DFU Bootloader vor dem Flashen manuell. Reset drücken und nach dem loslassen sofort die Taste but=32 drücken.
... und siehe da Debug funktioniert direkt in VSCode mit neuestem MapleMini Bootloader + STLink... :
:D :D :D :D
Vermute aber sehr, dass USBSerial nicht funktionieren wird.
ZitatIch hänge mal meine Version, die 100%ig auch nach einem Reset funktioniert an (Version v. 23.6.2019). Die neuere Variante hat 22KB mit gleichen Namen funktioniert nicht mit SerialUSB + Arduino ...
Habs getestet, beim flashen mit dfu-util funktioniert das serialUSB nach einem reset nicht mehr.
Evtl verhält es sich beim seriellen flashen mit STLink anders als beim flashen über USB mit dfu-util
Ich gehe wieder zurück zum orginal bootloader, damit funktioniert das flashen mit dfu-util und das serialUSB im sketch problemlos.
Gruß Ralf
Hallo Ralf9,
das ganau ist ja auch mein Problem:
Diese Einstellunegn muss ich in VSCode auch hinbekommen (mit dem neuesten Bootloader)
dann könnte es passen ...aber nicht mit Arduino
ZitatIch gehe wieder zurück zum orginal bootloader, damit funktioniert das flashen mit dfu-util und das serialUSB im sketch problemlos.
Sehe ich auch so ... und muss mal eine Nacht drüber sinnieren ... und die Erkenntnisse sortieren ...
Immerhin geht das Debuggen für vscode mit dem neuesten BL.
Hallo und guten Morgen,
vielleicht kann mir von euch mal jemand helfen, habe zur Zeit auch das Problem mit dem USBSerial, nach dem flashen geht es, einmal Reset und ich habe kein Serial mehr.
Folgendes steht in der Ausgabe des Flash-Logs:
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0 Upload to Flash 0x8005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=1123
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
error resetting after download: usb_reset: could not reset device, win error: Ein nicht vorhandenes Ger�t wurde angegeben.
Done!
Resetting USB to switch back to runtime mode
Habe soweit hier alles durchgelesen und auch schon einiges probiert, immer wieder das gleiche Ergebnis. Habe auch die Lib benutzt wie von Ralf9 empfohlen und auch die gleichen Upload-Einstellungen, weiß da zur Zeit echt nicht mehr weiter.
Ach ja, habe auch das Baite-Board.
Gruß
Markus
Zitatvielleicht kann mir von euch mal jemand helfen, habe zur Zeit auch das Problem mit dem USBSerial, nach dem flashen geht es, einmal Reset und ich habe kein Serial mehr.
Wichtig ist, daß Du den orginal Bootloader drauf hast.
Dies lässt sich auch an der upload Dauer erkennen.
Beim orginal Bootloader dauert der Upload ca 30 sec
und beim Bootloader 2.0 dauert der Upload nur ca 3 sec
Gruß Ralf
Hallo Ralf,
dann habe ich sicherlich den Bootloader 2.0 drauf, Upload geht so schnell das ich eigentlich dachte da kann was nicht stimmen.
Den originalen Bootloader kann ich ja nicht über die Onboard-USB-Schnittstelle flashen oder? Falls nicht hätte ich hier noch einen FTUI-Adapter.
Gruß Markus
So,
habe eben mal ne Anleitung gefunden wo das flashen des Bootloaders beschrieben ist, habe den Bootloader von Ralf9 geflasht uns siehe da, jetzt geht soweit alles, USBSerial geht auch nach Reset.
Hier mal der Link der Anleitung für die die auch das Problem haben sollten (oder noch bekommen):
https://born2bastel.de/2017/02/08/maple-mini-clone-bootloader-flashen/ (https://born2bastel.de/2017/02/08/maple-mini-clone-bootloader-flashen/)
Hallo Ralf9 und meier81,
ist Euch aufgefallen dass Ihr immer von "original Bootloader" sprecht, ihn aber nie genau definiert ?
Besonders bei der Namensgleichheit im Moment kann es da schon "vorprogrammiert" zu Missverständnissen kommen ...
@Locutus,
ist Dein STM32-MiniCUL Hardware-kompatibel zur Signalduino-Version?
@Ranseyer,
danke für die Platine, hatte Maple auf die falsche Seite gelötet und beim Auslöten Leiterbahnen mit nahen VIAS unbrauchbar gemacht ...
Das erklärt die fehlende GND-BOOT1-Verbindung (jaja, das Alter und so + zu schnell verlötet ...) ::)
Beim näheren Betrachten der ausgelöteten Platine sind mir noch die zwei SMD-Kondensatoren-Pads aufgefallen, die sich nachträglich nicht mehr bestücken lassen ... :'(
Hatte irgendwo das Bild gesehen wo der Maple auf der 868-Seite montiert war, gehört aber auf die 433-Seite (nach Original-Beschriftung)
/Edit: das Bild: https://forum.fhem.de/index.php?action=dlattach;topic=106278.0;attach=132983;image (https://forum.fhem.de/index.php?action=dlattach;topic=106278.0;attach=132983;image)
Hätte es wissen sollen: Meine Stiftleisten hatte ich auf der anderen Seite angelötet, weil ich annahm, es soll wegen den zwei (Button)-Bohrungen so sein. So kann man sich irren :-[
Grüße,
Jürgen
ZitatAuslöten Leiterbahnen mit nahen VIAS unbrauchbar gemacht ...
Gut dass es nicht an der Platine liegt :-)
Das Foto habe ich schonmal gesehen. Warum verbindest du die Antennenbuchsen nochmals zusätzlich selbst ?
Da für mich aus "easy" ein wichtiges Designziel ist hatte ich schon den Puffer-Kondensator verlegt.
Zwar bin ich ein Freund von "Reihenfolge der Bückung ist möglichst egal". Das gilt aber weniger für Bauteile wie die Kondensatoren die man einfach weglassen kann. Einen vergessenen Entstörkondensator kann man als 0805 z.B. einfach zwischen die beiden Mapple-Pins löten.
Das ist der nächste Potototy der noch ohne euer Feedback auf den Weg ging:
-größere Flächen für die Dosenblech-Abschirmer
-Langloch für die Taster
-dafür sind mir zwei Kleinigkeiten durchgerutscht: Beschriftung und "nochmals was":
https://cadlab.io/project/2431/master/circuit/UENCLVYwMi9tYXBsZVNEdWluby1WMC4yXzAyMi1lYWdsZTcuYnJk
Hallo Martin,
das erwähnte Foto ist nicht von mir ;-)
Kein Problem!
Evtl habe ich aber ein 868er Modul erwischt ...
https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html (https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html)
=> passt, musste die Vollpads etwas auffeilen um besser verlöten zu können ... und die Auslötaktion(en) kompensieren.
Schaue mal, ob ich ein schönes 3D-Gehäuse designed bekomme... :)
Grüße,
Jürgen
Ah, OK...
Wie der Maple drankommt "weiss ich eiegentlich auch nie" ...
Daher habe ich den Pin31 beschriftet! Damit kann man ohne Doku und minimalem Denken zum Ziel kommen, wenn man das weiß.
Gehäuse wäre schick. Hast du dazu noch dringende Wünsche an die Platine selbst ? (Oder reichen die beiden Nuten zum zentrieren?)
Es wäre zwar denkbar dass von Peter noch ein Vorschlag zur Abschirmung kommt. Wenn dadurch die Platine 1-2mm länger wird finde ich OK.
Eine Verbreiterung der Platine scheint mir auf gar keinen Fall OK. Somit nehme ich mal an, dass eine saubere Abschirmung gar nicht machbar ist, ohne eine der Prämissen zu kippen.
(Falls man verbreitert, dann wäre ich eher für zwei Stamps nebeneinander (die dritte darunter) aber das ergibt dann ein ganz anderes Konzept: https://github.com/ranseyer/CUN-STM32/blob/master/HW-MAPLE-Small/top.png )
ZitatWie der Maple drankommt "weiss ich eiegentlich auch nie" ...
War auch mein Problem deshalb hatte ich mich am Bild orientiert ...
Mit den Abmessungen habe ich eigentlich keine Probleme, allerdings mit der Planung des Aufstellungortes ...
Ggf. ein Stand-Gehäuse um es irgenwo in der Nähe des Raspis hingestellt zu bekommen oder eher eine Wandhalterung ?
Das Problem ist in jedem Fall das von unten kommende USB-Kabel und dessen Gewicht und Sperrigkeit ...
Jürgen
Zitatist Euch aufgefallen dass Ihr immer von "original Bootloader" sprecht, ihn aber nie genau definiert ?
Hab die erste Nachricht ergänzt.
Dort habe ich auch die beiden Bestückungsvarianten beschrieben.
Ich habe inzwischen auch das dritte Modul (CC2_C) getestet.
V 4.1.0-dev200322 SIGNALduino cc1101 (R: A1 B0* C3) - compiled at Mar 22 2020 20:04:45Hier ist auf Modul CC0_A die Bank 1 mit LaCrosse
und auf Modul CC2_C die Bank 3 mit PCA301
Ein get sduino raw br ergibt dann
r=A b=1 ccmode=3 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100 r=B b=0 ccmode=0 sync=D391 ccconf=10B07127C43023B900070018146C070090 boffs=0000 r=C b=3 N=3 ccmode=3 sync=2DD4 ccconf=216BD0880B0622F853070018166C436891 boffs=0180Durch mein angepasstes 00_SIGNALduino.pm Modul wird es dann wie in der Anlage aufbereitet
Gruß Ralf
ZitatGgf. ein Stand-Gehäuse um es irgenwo in der Nähe des Raspis hingestellt zu bekommen oder eher eine Wandhalterung ?
Das Problem ist in jedem Fall das von unten kommende USB-Kabel und dessen Gewicht und Sperrigkeit ..
.
Bei mir hängen die ganzen Sachen im Patchfeld herunter oder liegen in einem Schrank/Regal.
Was hältst du von diesem Grundprinzip ?
https://raw.githubusercontent.com/ranseyer/CUN-STM32/master/HW-MAPLE-Large/Case-Gloob-v001.jpg
Hallo Martin,
ja, so ähnlich ;-)
Da ich kein LAN-Modul nutzen werde/habe, bräuchte ich die Außen-Abmessungen.
Wahrscheinlich brauchen wir mehrere Gehäuse-VArianten ...
Jürgen
ZitatDa ich kein LAN-Modul nutzen werde/habe, bräuchte ich die Außen-Abmessungen.
reicht das so?
Hallo Ralf9,
danke für das Bild. :D
Könntest Du bitte noch eines um 90° gedreht machen? (Seitenansicht, mit irgendwas als Skalierungs-Referenz Lineal etc .. )
Danke,
Jürgen
Ich bin zwar nicht Ralf. Aber evtl hilft das ...
Seite9: https://www.usriot.com/download/ES1/USR-ES1-EN-V1.0.pdf
PS: Die grüne Platine vom USR-ES1 steht übrigen geschätzte 1 bis 1,5 mm über die rote Platine heraus...
Hallo Martin,
bräuchte noch ein paar Angaben zur Ausführung, noch ohne Gehäuse:
- Wielviel steht der USR-ES1 über den Platinenrand heraus?
- Die Stifte des USR-ES1 sind bei Dir direkt verlötet, wie ist der Unterschied mit Buchsenleiste?
- SMA-Abmaße, ich benutze direkte Verlötung der Antenn, und werde eine Art Stütze für die Antenne vorsehen. (Als eine Art Knickschutz).
- Aussparung für USB-Stecker je nach Ausführung, wie gestalten? Mini- und/oder Mikro-USB, je nach Maple-Board? [/i]
Anbei mal ein Entwurf mit den Basics.
Überlegung für die Integration der USB-Kabelführung in ein Stand-Sockel. (Vier Richtungen als Option.)
Als Idee: Die Antennenseite des Gehäuses auswechselbar machen, SMA oder direkter Antennenanschluss ...
Schiene zum Einschieben der Platine auf der Antennenseite ...
ZitatDie Stifte des USR-ES1 sind bei Dir direkt verlötet, wie ist der Unterschied mit Buchsenleiste?
Ich verwende Buchsenleisten die nur 5,6 mm hoch sind, damit wird die Gesamthöhe um 2mm höher auf 28mm
Mit normalen Buchsenleisten ist die Gesamthöhe ca 30mm
Würde der Krümmungs-Radius des Netzwerk-Kabels noch dazu passen?
Man sieht schon: der Sockel (verblendet USB+Netz-Stecker) besteht aus einer Grundplatte mit Kabelführungen Netzwerk + USB und der Verbindung zum Gehäuse um den USB und ggf den Netzwerkstecker zu verkleiden.
Beide Komponenten würden mit M3-Schrauben verschraubt werden ...
Der Fuß sollte mit mehreren M10/M12-Schrauen o.ä. beschwert werden können (Aussparungen) => Standfestigkeit.
Ggf. brauche ich deswegen auch kein Fokus auf die Toleranzen der Buchsen-Aussparungen legen ....
ZitatWürde der Krümmungs-Radius des Netzwerk-Kabels noch dazu passen?
hab mal mit einem Patchkabel gemessen siehe Anlage
Danke, dann kann ich das zusätzlich berücksichtigen ;)
Die Gehäusewand (gelb) wird ca. 5 mm dick und jetzt ist der USB-Kabel-Abstand nur 3,2 cm, der Sockel muss also mindestens 2,5 cm höher werden.
Doof ist nur, wenn ich die Platine von der Antennenseite einschiebe, dann brauche ich die gesamte Höhe mit Netzadapter, dann doch besser von unten zum Einschieben und ebenfalls verschraubbar ...
Dann kann ich ab dem Netzadapter verjüngen ... und trotzdem die Antennenseite konfigurierbar machen ...
Zitat von: Telekatz am 21 März 2020, 20:53:34
0x18 gehört zum CC113L. Eigentlich nur ein Receiver.
Dies ist zum Glück nur eigentlich nur ein Receiver.
Das CC113L Modul in der Anlage hat eine Version von 0x08 und kann trotzdem auch senden. Ich konnte keine Unterschiede zum cc1101 feststellen.
@Telekatz
Hast Du inzwischen mal geschaut, ob Du die a-culw mit überschaubaren Aufwand für den MapleSduino anpassen kannst?
Evtl ein zusätzlicher Eintrag in der board.h
Gruß Ralf
Zitathab mal mit einem Patchkabel gemessen siehe Anlage
Mit einem Patchkabel ohne Schirm sind auch 3 cm machbar
Ist ein Krümmungsradius von 2 cm noch ok?
...und die Frage ist ob man bei der LAN Version nicht einfach den Unterteil weglässt. Mir reicht es z.B. das Teil im Patchfeld hängen zu lassen oder in ein Regal zu werfen.
((Ich würde das Unterteil in keinem Fall verwenden wollen))
Zitat von: Ranseyer am 29 März 2020, 15:29:38
...und die Frage ist ob man bei der LAN Version nicht einfach den Unterteil weglässt. Mir reicht es z.B. das Teil im Patchfeld hängen zu lassen oder in ein Regal zu werfen.
((Ich würde das Unterteil in keinem Fall verwenden wollen))
Hallo Martin,
keine Sorge, das plane ich ein. ;)
@Ralf9
über ein variables Sockel-Zwischenteil ... ;)
Locutus MapleCUL und MapleSDuino PIN-Zuordnung.
Firmware ist leider (noch) nicht kompatibel.
Zitat von: Ralf9 am 29 März 2020, 15:13:05
@Telekatz
Hast Du inzwischen mal geschaut, ob Du die a-culw mit überschaubaren Aufwand für den MapleSduino anpassen kannst?
Evtl ein zusätzlicher Eintrag in der board.h
Ich habe hier mal einen Branch erstellt, mit dem man in der board.h auch den SPI Port einstellen kann:
https://github.com/Telekatz/a-culfw/tree/MapleSduino (https://github.com/Telekatz/a-culfw/tree/MapleSduino)
ZitatIch habe hier mal einen Branch erstellt, mit dem man in der board.h auch den SPI Port einstellen kann:
Danke, so habe ich es mir gedacht.
Für den MapleSduino müssten eigentlich in der board.h die folgenden Anpassungen reichen:
https://github.com/Telekatz/a-culfw/blob/MapleSduino/culfw/Devices/MapleCUN/board.h
//#define CC_SPI SPI_1
#define CC_SPI SPI_2
//#define WIZ_SPI SPI_2
#define WIZ_SPI SPI_1
//PORT 0
//#define CC1100_0_CS_PIN 4
//#define CC1100_0_CS_BASE GPIOA
#define CC1100_0_CS_PIN 12
#define CC1100_0_CS_BASE GPIOB
//#define WIZNET_CS_PIN 12
//#define WIZNET_CS_GPIO GPIOB
#define WIZNET_CS_PIN 4
#define WIZNET_CS_GPIO GPIOAKann dies mal jemand testen?
Gruß Ralf
versuche mein lädiertes Board irgendwie zu reaktivieren, dann kann ich diese CUL-Version testen.
Je nach CC1101-Bestand. ;)
Muss aber erst mal die make Umgebung wegen neuem Rechner auf WIN10 oder RASPI wieder zu Laufen bringen. 🤨
Man beachte die Aufbau-Alternative des Maples! ;)
Wenn soweit alles Hardware-mäßig getestet ist, verklebe ich die Anschlüsse mit 2-Komponenten-Kleber.
Vielleicht hilfreiches Tool (https://www.thesycon.de/eng/free_download.shtml) im Zusammenhang mit Bootloader.
Entwicklungsumgebung auf Raspi4 => done.
Make auf aculfw => done.
Bootloader maple_mini_boot20.bin über Windows geflashed. => done.
dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin -R Hat leider nicht, bei aktiviertem DFU-Modus, funktioniert! ?
Zitat6543.210548] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[ 6756.309351] usb 1-1.3: USB disconnect, device number 22
[ 6756.753214] usb 1-1.3: new full-speed USB device number 23 using xhci_hcd
[ 6756.888419] usb 1-1.3: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[ 6756.888434] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6756.888447] usb 1-1.3: Product: Maple 003
[ 6756.888459] usb 1-1.3: Manufacturer: LeafLabs
[ 6756.888471] usb 1-1.3: SerialNumber: LLM 003
[ 6758.357695] usb 1-1.3: USB disconnect, device number 23
[ 6758.663247] usb 1-1.3: new full-speed USB device number 24 using xhci_hcd
[ 6758.799829] usb 1-1.3: New USB device found, idVendor=1eaf, idProduct=0004, bcdDevice= 2.00
[ 6758.799846] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 6758.799859] usb 1-1.3: Product: Maple
[ 6758.799871] usb 1-1.3: Manufacturer: LeafLabs
Als Alternative stm32flash auf Raspi installiert und über FTDI geflashed:
Zitat
pi@Raspi4:~/MapleSduino/a-culfw/culfw/Devices/MapleCUN $ stm32flash -w ./MapleCUNx4_W5500_BL.bin -v -g 0x0 /dev/ttyUSB0
stm32flash 0.5
http://stm32flash.sourceforge.net/
Using Parser : Raw BINARY
Interface serial_posix: 57600 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0410 (STM32F10xxx Medium-density)
- RAM : 20KiB (512b reserved by bootloader)
- Flash : 128KiB (size first sector: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB
Write to memory
Erasing memory
Wrote and verified address 0x0800e620 (100.00%) Done.
Starting execution at address 0x08000000... done.
Da Telekatz den MapleCUL nicht (mehr?) im Repository hat, vermute ich, dass es ohne USR-ES1-Modul als MapleCUN nicht gehen wird ...Hat jemand noch ein USR-ES1-Modul übrig?
Grüße,
Jürgen
@Juergs: Ja habe ich übrig!
Bei Bedarf: PN
edit:
Zitatdass es ohne USR-ES1-Modul als MapleCUN nicht gehen wird ...
Jetzt habe ich die Frage kapiert... Du brauchst also keine zusätzliche HW. Außer wenn du irgenwann mal die LAN Anbindung, die soweit ich weiß noch nicht programmiert ist, testen willst...
Der MapleCUN wird automatisch zum MapleCUL, wenn kein Ethernetmodul angeschlossen ist. Die Firmware kann erkennen, ob ein Modul vorhanden ist. Deshalb sind dafür keine zwei Firmwareversionen notwendig.
Ok, danke für die Info.
Dann werde ich morgen nochmal probieren ..
Jürgen
Hallo,
ich habe die MapleSduino Version von Telekatz mit den Änderungen von Ralf9 in der board.h kompiliert und getestet.
Bei mir läuft diese Version.
Ich habe folgende Toolchain Version genommen ,
gcc version 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437] (GNU Tools for ARM Embedded Processors 6-2017-q2-update).
Mit neueren Versionen kann man zwar kompilieren , die erstellte Bin-File ist kleiner, läuft aber nicht.
Ich hänge einmal meine erstellte Bin-File an.
Gruß
Klaus
Hatte die aktuelle Version auf dem RASPI4 installiert:
arm-none-eabi-gcc (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Da ich den Compile unter Windows 10 in obiger Version durchführen wollte und die Vorgehensweise evtl. für andere ggf. auch interresant sein könnte, hier mein Weg:
- WSL (https://docs.microsoft.com/de-de/windows/wsl/about?redirectedfrom=MSDN): WSL "Ubuntu on Windows" hatte ich bei mir schon installiert
- make hatte gefehlt, installiert: sudo apt-get install make
- GNU-Toolchain für Linux heruntergeladen https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads/6-2017-q2-update (https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads/6-2017-q2-update) und im Arbeitsordner entpackt.
- Bei mir "D:\Work_FHEM\gcc-arm-none-eabi-6-2017-q2-update-linux" unter windows angelegt. Auf auf geringe Verzeichnistiefe achten, ggf. eine Stufe nach oben moven.
- Um Windows-Verzeichnisse im WSL zu erreichen: cd /mnt/d/Work_FHEM/Firmware/a-culfw-MapleSduino_Telekatz/a-culfw-MapleSduino/culfw/Devices/
- Dann Anpassen der Makefiles:
- 1.) Makefile in /Devices -> Pfade zur passenden ARM-Umgebung ergänzen:
# Add the full path name of these tools if necessary
CC=/mnt/d/Work_FHEM/gcc-arm-none-eabi-6-2017-q2-update-linux/bin/arm-none-eabi-gcc
OBJCOPY=/mnt/d/Work_FHEM/gcc-arm-none-eabi-6-2017-q2-update-linux/bin/arm-none-eabi-objcopy
- 2. makefile im MapleCUN-Verzeichnis ebenso:
CC=/mnt/d/Work_FHEM/gcc-arm-none-eabi-6-2017-q2-update-linux/bin/arm-none-eabi-gcc
OBJCOPY=/mnt/d/Work_FHEM/gcc-arm-none-eabi-6-2017-q2-update-linux/bin/arm-none-eabi-objcopy
SIZE=/mnt/d/Work_FHEM/gcc-arm-none-eabi-6-2017-q2-update-linux/bin/arm-none-eabi-size Dann unten im size-Aufruf den obigen SIZE-Alias verwenden, falls benötigt:
$(TARGET).elf: $(OBJS)
$(CC) $(OBJS) $(LDFLAGS) -o $@
$(OBJCOPY) -O ihex $(TARGET).elf $(TARGET).hex
$(OBJCOPY) -O binary $(TARGET).elf $(TARGET).bin
$(SIZE) $(TARGET).elf
- mit /mnt/d/Work_FHEM/Firmware/a-culfw-MapleSduino_Telekatz/a-culfw-MapleSduino/culfw/Devices/make all oder
- /mnt/d/Work_FHEM/Firmware/a-culfw-MapleSduino_Telekatz/a-culfw-MapleSduino/culfw/Devices/MapleCUN$ make MapleCUL das Projekt bauen.
Noch das Address-Detail:
ZitatMemory Configuration
Name Origin Length Attributes
RAM 0x0000000020000000 0x0000000000005000 xrw
FLASH 0x0000000008002000 0x000000000001e000 xr
Immer möglich, dass es elegantere Wege dafür gibt, aber so hat es für mich funktioniert und dabei auch etwas dazugelernt. ;)
Jetzt geht es ans Testen und das Gehäuse ...
Grüße,
Jürgen
/edit: Tippfehler bei
SIZE beseitigt! (Den Screenshot habe ich so gelassen)
Ich bin über STLINK so vorgegangen:
- full erase
- zuerst den 7KB "großen" maple_mini_boot20.bin (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/tree/master/bootloader_only_binaries) Bootloader auf Addresse 0x08000000 geflashed. (Anmerkung: falscher BL, den maple_mini_boot.bin nehmen!)
- Dann MapleCUNx4_W5500_BL.bin von trebron106 an Addresse 0x08002000 geflashed.
Ergebnis: Die MapleCUL COM-Ports sind nach Reset da: V 1.26.08 a-culfw Build: private build (unknown) MapleCUNx4_01 (F-Band: 868MHz))
und LED blinkt :)
- Mein Compile MapleCUNx4_W5500_BL.bin funktioniert ebenso! :D
Hier gibt es ab sofort die Platinenversion 0.2: ...https://forum.fhem.de/index.php/topic,109220.msg1033965.html#msg1033965
Achtung: Die Beschrifting 433 und 868 MHz muss getauscht werden...
Hat inzwischen schon jemand die Firmware V 4.10 auf dem MapleSduino (Maple_sduino_USB_410dev20xxxx.bin) oder MapleCul (Maple_cul_USB_410dev20xxxx.bin) erfolgreich getestet?
Es wäre schön, wenn ich Rückmeldungen bekommen würde.
Gruß Ralf
Hallo Ralf,
habe gestern den aculw und den Signalduino zusammen testen wollen.
D.h. wollte den CUL am BananaPi dranlassen (funktioniert) und dann den MapleSignalduino angeschlossen.
Obwohl er unter Windows funktioniert, konnte Fhem nicht den Port ermitteln.
Die Ports des 1. Maple (aculfw) waren sichtbar, aber die des Signalduino nicht.
Aus dem Output von dmesg werde ich nicht schlau. Beide PID sind da aber ich erkenne die Zuordnung zu welcher tty-Schnittstelle nicht.
Aber das wäre ja noch eine Sonderkonstellation, werde nachher versuchen den Maple zu deaktiveren und ggf den MapleSignalduino zu aktivieren ...
Zitat/dev/serial/by-id/usb-STM32_MapleCUL_88bf416a-if02@57600
stammt noch von den gestrigen Versuchen und ist definitiv nicht die Richtige ...
Das "list" des Devices:
ZitatInternals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:LaCrosse:KOPP_FC:PCA301:SIGNALduino_TOOL:SIGNALduino_un:
DEF /dev/serial/by-id/usb-STM32_MapleCUL_88bf416a-if02@57600
DMSG nothing
DevState disconnected
DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_88bf416a-if02@57600
FUUID 5e87a27e-f33f-33ec-5724-f8b9a27c9bca60f7
IDsNoDispatch 2,72.1,82,87,88
LASTDMSG nothing
LASTDMSGID nothing
NAME MapleSDuino
NR 117
PARTIAL
STATE disconnected
TIME 1585985266.08868
TYPE SIGNALduino
versionmodul v3.4.5-dev_ralf_29.02.
versionprotoL v3.4.5-dev_ralf_28.02.
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
31:KOPP_FC ^kr..................
32:PCA301 ^\S+\s+24
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
90:SIGNALduino_TOOL ^pt([0-9]+(\.[0-9])?)(#.*)?
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^\d+#.*
READINGS:
2020-04-04 09:27:46 state disconnected
2020-04-04 10:19:43 version 0
mcIdList:
....
Attributes:
room Gateways
ein ls -l /dev/serial/by-id ergibt bei mir:
usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D82067E4850-if00 -> ../../ttyACM0
in der DEF vom sduino steht dann:
/dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D82067E4850-if00@115200
Gruß Ralf
Hallo Ralf,
bei ls /dev/serial/by-id/ sthen nur die 3 Ports des CULs drin.
hatte erwartet dass dor auch der Signalduino auftaucht.
Aber Moment, ich schließe nur den Signalduino an. Mal schauen ob er dann zum Vorschein kommt.
@Juergs: Vorschlag: lege Dir doch mal 3 (2) USB Geräte auf den Tisch:
-CUL
-SDuino
-FTDI Adapter
Dann gibst du ein:
"tail -f /varlog/syslog"
Die ersten 5 Zeilen die sofort kommen ignorierst du...
A) dann steckst du ein den Maple-CUL: Zuerst meldet sich ein LeafLabs Gerät bzw. dessen Bootloader, dann gibt es einen USB-Diconnect und die siehst wie sich der Maple-CUL selbst mit drei Devices meldet
B) FTDI Adataper stecken und seine Meldungen studieren
C) SDuino stecken un vergleichen...
Hallo Martin,
danke, gute Idee!
Der MapleCul connect via ttyACM2
FTDI über ttyUSB0
Aber der SignalDuino?
Prüfe nochmal über Win10. => geht auch nicht (mehr)
Flashe die Firmware noch mal neu!
Habs mal bei meinem bananapi getestet:
root@bananapi:/home/ralf# tail -f /var/log/syslog
...
Apr 4 15:39:23 localhost kernel: [ 91.584795] ehci_irq: port change detect
Apr 4 15:39:23 localhost kernel: [ 91.651500] The port change to OHCI now!
Apr 4 15:39:23 localhost kernel: [ 91.947612] usb 5-1: new full-speed USB device number 3 using sw-ohci
Apr 4 15:39:23 localhost kernel: [ 92.209859] cdc_acm 5-1:1.0: This device cannot do calls on its own. It is not a modem.
Apr 4 15:39:23 localhost kernel: [ 92.224425] cdc_acm 5-1:1.0: ttyACM0: USB ACM device
Apr 4 15:39:23 localhost kernel: [ 92.241987] usbcore: registered new interface driver cdc_acm
Apr 4 15:39:23 localhost kernel: [ 92.258930] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Wichtig ist, daß der Orginal Bootloader drauf ist.
Gruß Ralf
Hallo Ralf,
sorry, hatte vorgestern am Signalduino schon Kommandos über ein Terminal ausprobiert ...
Warum das heute nicht kommt : "cdc_acm 5-1:1.0: ttyACM0: USB ACM device" kann ich gerade nicht nachvollziehen.
An welche Adresse flasht Du effektiv "Maple_sduino_USB_410dev200322.bin" nach dem Bootloader?
0x8002000
oder
0x8005000
?
Jürgen
PS: Über den STMFlashLoader ....
4.1.0-dev200306\Maple_sduino_USB_410dev200306.bin
oder
4.1.0-dev200322\Maple_sduino_USB_410dev200322.bin
sollte kein wesentlichen Unterschied machen ...
ZitatAn welche Adresse flasht Du effektiv "Maple_sduino_USB_410dev200322.bin" nach dem Bootloader?
wo sehe ich das?
# ./dfu-util -v -d 1eaf:0003 -a 1 -D Maple_sduino_USB_410dev200322.bin -R
dfu-util 0.8
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download [=========================] 100% 56084 bytes
Download done.
Sent a total of 56084 bytes
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
Ok, reproduziere das über dfu-util, wie Du.
Vielleicht ist da etwas anders ....
D:\Work_FHEM\_maple_sduino\_firmware>"C:\Program Files (x86)\Arduino\hardware\Arduino_STM32\tools\win\dfu-util.exe" -v -d 1eaf:0003 -a 1 -D Maple_sduino_USB_410dev200322.bin -R
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="DFU Program FLASH 0x08005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=1121
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
error resetting after download: usb_reset: could not reset device, win error: Ein nicht vorhandenes Gerõt wurde angegeben.Aha : name="DFU Program FLASH 0x08005000" ;D
Ging nicht über RESET,
ZitatD:\Work_FHEM\_maple_sduino\_firmware>"C:\Program Files (x86)\Arduino\hardware\Arduino_STM32\tools\win\dfu-util.exe" -v -d 1eaf:0003 -a 1 -D Maple_sduino_USB_410dev200322.bin -R
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
Lost Device after reset, assuming prod_id was incremented by oneNo DFU capable USB device found
sondern nur über aus- und ein-Stecken des USB-Steckers ...
Jetzt is es klar.. ::)
Dein Original-Bootloader hat 16KB im Gegensatz zu meinen Versionen und ist nicht die 2.0er Version ...
Dafür aber:
ccconf: freq:6656.000MHz bWidth:58KHz rAmpl:42dB sens:16dB (DataRate:1621826.17Baud)
Modulation:MSK (SYNC_MODE:30/32 + carrier-sense above threshold)
setBank:
B: b=0 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)
Wenigstens funktioniert der 433er ...
Es bleibt einem aber auch nichts erspart ;)
Nein ohne lesen geht es nicht. Hier die erste Nachricht, da gibt es u.a. "erste Schritte"
Hättest Du den MapleCul ohne lesen inbetrieb nehmen können?
Gruß Ralf
Hmm, ok danke für die "Prügel" ;)
Die Betonung liegt auf "mehrfach" lesen .. ;)
Der 868er wehrt sich noch:
cregAll:
ccreg 00: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
ccreg 10: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
ccreg 20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2 - 0xFF (0D) [29]
0x01 IOCFG1 - 0xFF (2E)
0x02 IOCFG0 - 0xFF (2D) [3F]
0x03 FIFOTHR - 0xFF (07)
0x04 SYNC1 - 0xFF (D3)
0x05 SYNC0 - 0xFF (91)
0x06 PKTLEN - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0xFF (04)
0x08 PKTCTRL0 - 0xFF (32) [45]
0x09 ADDR - 0xFF (00)
0x0A CHANNR - 0xFF (00)
0x0B FSCTRL1 - 0xFF (06) [0F]
0x0C FSCTRL0 - 0xFF (00)
0x0D FREQ2 - 0xFF (10) [1E]
0x0E FREQ1 - 0xFF (B0) [C4]
0x0F FREQ0 - 0xFF (71) [EC]
0x10 MDMCFG4 - 0xFF (57) [8C]
0x11 MDMCFG3 - 0xFF (C4) [22]
0x12 MDMCFG2 - 0xFF (30) [02]
0x13 MDMCFG1 - 0xFF (23) [22]
0x14 MDMCFG0 - 0xFF (B9) [F8]
0x15 DEVIATN - 0xFF (00) [47]
0x16 MCSM2 - 0xFF (07) [07]
0x17 MCSM1 - 0xFF (00) [30]
0x18 MCSM0 - 0xFF (18) [04]
0x19 FOCCFG - 0xFF (14) [36]
0x1A BSCFG - 0xFF (6C)
0x1B AGCCTRL2 - 0xFF (07) [03]
0x1C AGCCTRL1 - 0xFF (00) [40]
0x1D AGCCTRL0 - 0xFF (90) [91]
0x1E WOREVT1 - 0xFF (87)
0x1F WOREVT0 - 0xFF (6B)
0x20 WORCTRL - 0xFF (F8)
0x21 FREND1 - 0xFF (56)
0x22 FREND0 - 0xFF (11) [16]
0x23 FSCAL3 - 0xFF (E9) [A9]
0x24 FSCAL2 - 0xFF (2A) [0A]
0x25 FSCAL1 - 0xFF (00) [20]
0x26 FSCAL0 - 0xFF (1F) [0D]
0x27 RCCTRL1 - 0xFF (41)
0x28 RCCTRL0 - 0xFF (00)
0x29 FSTEST - 0xFF
0x2A PTEST - 0xFF
0x2B AGCTEST - 0xFF
0x2C TEST2 - 0xFF
0x2D TEST1 - 0xFF
0x2E TEST0 - 0xFF
https://forum.fhem.de/index.php/topic,106278.150.html
Was ergibt ein "get Version"?
Dann ein
get sduino raw CREA
und dann wieder ein "get Version"?
ein get version:
version: V 4.1.0-dev200322 SIGNALduino cc1101 (R: Ai B-*) - compiled at Mar 22 2020 20:04:45
get raw CREA:
raw: detect A: Partn=0 Ver=20
Zitat(R: Ai B-*)
Das 433 MHz Modul B wird nicht richtig erkannt.
Was ergibt
get sduino raw CREB
raw: detect B: timeout, no cc1101
Hatte ich auch vermutet.
Ich glaube Du kannst noch eine Platine gebrauchen, ist für Dich das Auslöten des MapleMini ein Problem?
Hallo Ralf,
würde morgen noch mal die Pinblegung des 433ers checken. Hatte ich auch schon ausgelötet ...
Auslöten kein Problem, glaube eine neue Platine ist schon unterwegs ... ;)
Danke für die Unterstützung ...
Jürgen
Der CC1101 ist schlecht verarbeitet, gesäubert und Pins von Schlacke befreit.
Lötpunkte gecheckt...
Jetzt liefert "get raw CREB": "raw: detect B: Partn=0 Ver=0 invalid"
CS wird bei ccconf zumindest mal angesteuert.:
ccconf: freq:0.000MHz bWidth:812KHz rAmpl:24dB sens:4dB (DataRate:24.80Baud)
Auf Frequenzvorgabe reagiert er nicht ...
setBank:
B: b=0 freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)
Modulation:2-FSK (SYNC_MODE:No preamble/sync)
Ein Teilerfolg, morgen geht es weiter. 8)
Jürgen
Hallo Ranseyer,
benötige noch Info über Deine SMA-Buchsen-Abmessungen, da ich bei mir die Antennen nur direkt angelötet habe.
In der Zeichnung sind die Auflagepunkte für die Platine auf der Gehäuseunterseite (USB ist links).
Wie groß ist die Auflagehöhe die die SMA-Buchse noch horizontal aufträgt?
(Habe leider andere Bauform, würde aber beide Versionen der SMA-Buchse berücksichtigen.
Die Stützpunkte werden 2mm extrudiert, dann kommen die Fixier-"Zapfen" dazu.
Zwischen Platine und Gehäusewand (orange, gestrichelt) habe ich 2mm Platz.
Grüße,
Jürgen
Ein paar konzeptuelle Anmerkungen:
Die SMA-Buchsen lassen sich unterschiedlich anordnen.
a. innerhalb der Flucht ( benötigen Bohrung neben der 433er SMA-Buchse für Verbindung zum Antennenausgang des CC1101-Moduls)
b. außerhalb der Flucht
Dann noch ein Beispiel zum klassischen Planungsfehler. ;D
Ich werde die SMA-Buchse mit in die Gehäuse-Wand integrieren um die volle Länge für die Schraubantenne nutzen zu können
und dafür das Gehäuse etwas kürzen.
Gibt es irgendwelche HF-Bedenken die SMAs so oder so anzuordnen? (Außer mit evtl. Verlusten mit Zuführung zur Antennenbuchse?)
Bei der Höhe des Ethernetmoduls hat man eigentlich gar kein Spielraum zur Verfügung. Es kann nur aufgesetzt werden und angelötet werden.
Dami noch ein kleiner Luftspalt zwischen Maple und Modul bleibt.
Grüße,
Jürgen
Hi, Jürgen
die SMA Buchsen sind nicht in der Flucht um das beste und nicht das schönste Ergebnis zu erreichen.
Auf meinen Platinen kann man diese nicht "schick" sondern nur "funktioniell" auflöten.
Das war Anfangs eine bewusste Designentscheidung. Auch im Rahmen der Abschirmungs usw. Diskussionen...
(Auch eine andere Entscheidung wäre möglich gewesen, gemäß dem Motto, eine Durchkontaktierung macht den Kohl nicht fett. Aber: Wenn dánn wäre die Durchkontaktierung bei 433MHz zu machen gewesen...)
Ist bei dieser kleinen Version aus meiner Sicht jetzt so entschieden. (Hier mit erweiterbarkeit auf 3fach)
Ich denke es kommt ferner Zeit auch mal ein Version "3fach" die ist hier "schicker" ...
Grüße
Zitat von: juergs am 08 April 2020, 13:06:23
Ein paar konzeptuelle Anmerkungen:
Die SMA-Buchsen lassen sich unterschiedlich anordnen.
a. innerhalb der Flucht ( benötigen Bohrung neben der 433er SMA-Buchse für Verbindung zum Antennenausgang des CC1101-Moduls)
b. außerhalb der Flucht
Dann noch ein Beispiel zum klassischen Planungsfehler. ;D
Ich werde die SMA-Buchse mit in die Gehäuse-Wand integrieren um die volle Länge für die Schraubantenne nutzen zu können
und dafür das Gehäuse etwas kürzen.
Gibt es irgendwelche HF-Bedenken die SMAs so oder so anzuordnen? (Außer mit evtl. Verlusten mit Zuführung zur Antennenbuchse?)
Bei der Höhe des Ethernetmoduls hat man eigentlich gar kein Spielraum zur Verfügung. Es kann nur aufgesetzt werden und angelötet werden.
Dami noch ein kleiner Luftspalt zwischen Maple und Modul bleibt.
Grüße,
Jürgen
Hallo Martin,
dreht sich nur um die Gehäuse-Ausführungen.
Da muss ich alle Aufbauarten berücksichtigen, evtl. auch den gedrehten Aufbau des Maples.
Wahrscheinlich passt dann mit gedrehtem Maple (Button 0+1 oben) das Ethernet-Modul nicht
bzw. nur mit Pfriemelei in die Lötaugen...
Bei gedrehtem Maple mit Ethernet-Modul käme man auch nicht mehr an die Boot-Buttons ;-)
Grüße,
Jürgen
Den Maple kannst du problemlos auf die andere Platinen Seite löten. Nur müsste man leider den Maple vor dem LAN Modul fehlerfrei einlösen. (Mein vorletzter war defekt, und ausnahmsweise nicht getestet vor dem Verarbeiten, der erste Defekte von Baite)
Sollte der Maple versterben muss das LAN Modul leider immer runter...😅
Glaube, man muss sich nur auf eine Standard-Bauweise einigen und gut is ... ;) :)
Genau.
(Und war der Meinung mein Muster ist am geschicktesten, weil eine Seite der Platine weitgehend leer bleibt (nur die Stamp)
Auf der anderen dann der Maple und manchmal auch LAN.
ZitatGlaube, man muss sich nur auf eine Standard-Bauweise einigen und gut is
Zitat(Und war der Meinung mein Muster ist am geschicktesten, weil eine Seite der Platine weitgehend leer bleibt (nur die Stamp)
Auf der anderen dann der Maple und manchmal auch LAN.
Ja, denke ich auch, mit LAN ist es so am geschicktesten
https://forum.fhem.de/index.php/topic,106278.msg1035723.html#msg1035723
Ohne LAN müssten mit einer etwas größeren Öffnung für USB beide Aufbauvarianten passen.
Gruß Ralf
Der erste Prototyp der Unterseite.
Es gibt leider wenig "Angriffspunkte" um die Platine zu fixieren ;)
Noch sind 1.4mm der des Ethernet-Moduls im Weg... >:(
Die SMA-Seite konnte ich um 2.5mm verkürzen.
Ansonsten passt es jetzt wie "angegossen". ;D
Die nächste Runde:
Manche Ideen, stellen sich in der Praxis dann doch anders dar!
Die Deckelausführung als Snapin (https://www.youtube.com/watch?v=E0NVC8xhf3I) auszuführen, also ohne Verschraubung => braucht etwas Nachbearbeitung, da der 3D-Drucker die Überhänge nicht
so präzise (>> A tolerance of 0.5 mm is recommended) hinbekommt.
Die Nut im Deckel stellt sich als Hinderlich beim Einbauen dar... Ok, bei 2mm Gehäusebreite mit einer 1mm-Nut stößt an die Grenzen meines 3D-Druckers.
Also kurzerhand wieder entfernt, da genau diese Nut das Einschnappen behindert ...
Die Implementierung ist durchaus eine Hearusforderung ;)
Muss auch die Verschraubungsmöglichkeit des Deckels noch mal prüfen ... Vielleich doch außen, wie in Gloobs Modell ?
Das Gehäuse nochmal für Verschraub-Antennen um 1mm kürzen. :(
Das Resultat des Fusion-Slicers (https://www.youtube.com/watch?v=QWFRh-MdKxo) ist auf alle Fälle besser als den von mir verwendeten RepetierHost.
Das mag auch an meinen Einstellungen liegen, aber das langwierige Ausprobieren möchte ich mir zur Zeit nicht antun...
Das Ergebnis lässt sich als 3D-Druck aber durchaus ansehen (benutze transparentes Filament für Protoypen) ... benötigt aber im Moment noch etwas manuelle Nachbearbeitung.
Eigentlich hatte ich vorgesehen die Front- und Rückseite austauschbar zu machen, verschiebe das aber noch.
Dennoch: Wie soll die Fixierung des Ständers (mit Kabelführung) am Gehäuse befestigt werden (Verschraubung oder SnapIn) ?
Anbei die STLs zum Selber-3D-Drucken.
Empfehlung: Lüfter zum Print ausschalten: "M107" oder "M106 S0".
Der MapleSDuino lässt sich natürlich auch als Nachfolger vom NanoCul als normaler sduino verwenden, dazu muß nur das zweite (B) cc1101 433 Mhz Modul bestückt werden.
Ein "get Version" enthält dann (R: B0*)
Es ist nicht mehr zu empfehlen, einen NanoCul zu kaufen oder selbst zubauen.
Kann jemand hier vermerken,
https://wiki.fhem.de/wiki/Selbstbau_CUL
daß es mit dem MapleSduino einen Nachfolger gibt?
ZitatDie Betonung liegt auf "mehrfach" lesen
Meine Dokumention ist anscheinend noch verbesserungsfähig.
Es wäre schön, wenn jemand für den MapleSduino einen Wiki Eintrag machen könnte.
@andies liest Du hier mit?
Gruß Ralf
Nur nochmal zum Verständnis.
Der mapleduino kann dar was der Signalduino kann + nano cul +LaCrosse?
Wie sieht es denn aus, das ganze auf einem wemos d1 Mini bzw pro Ton laufen zu bekommen, wegen der wlan Anbindung?
Gesendet von meinem MI 9 mit Tapatalk
ZitatDer mapleduino kann dar was der Signalduino kann + nano cul +LaCrosse?
Wenn die a-culw geflasht wird, kann er auch das was der nanocul kann.
Mit der sduino Firmware kann er durch LaCrosse auch zum großen Teil was der JeeLink kann.
ZitatWie sieht es denn aus, das ganze auf einem wemos d1 Mini bzw pro Ton laufen zu bekommen, wegen der wlan Anbindung?
Wenn auf dem wemos d1 Mini das esplink drauf ist und seriell mit dem Debugport vom MapleSDuino oder MapleCul verbunden wird, dann funktioniert es auch über WLAN (siehe Anlage)
Dazu ist eine spezielle firmware notwendig bei der anstatt USB RX und TX verwendet wird, bei bedarf kann ich die bin File erstellen.
Auf dem ESP32 müsste die firmware funktionieren, da er für den Zeit kritischen Teil einen Coprocessor hat, aber da bräuchte ich Hilfe beim programmieren des Coprocessors
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/ulp.html
Gruß Ralf
Es gäbe vielleicht noch eine günstigere Option:
https://www.makerfabs.com/desfile/files/Air602%20Hardware%20Design%20Manual.pdf (https://www.makerfabs.com/desfile/files/Air602%20Hardware%20Design%20Manual.pdf)
http://wiki.seeedstudio.com/Air602_Firmware_Programming_Manual/ (http://wiki.seeedstudio.com/Air602_Firmware_Programming_Manual/)
http://wiki.seeedstudio.com/Air602_WiFi_Development_Board/#typical-applications (http://wiki.seeedstudio.com/Air602_WiFi_Development_Board/#typical-applications)
Aber: Einen WLAN-Sender in der Nähe von 433 und 868 MHZ Empfängern zu betreiben finde ich HF-technisch nicht gerade von Vorteil.
Da der WLAN Betrieb möglicherweise den HF-Empfang sowieso schwächerer Stationen einfach weg "drückt" ...
Ich habe hier 2 Stück Air602 herumliegen, werden mich mal damit etwas beschäftigen ...
https://yoursunny.com/t/2018/Air602-blink/ (https://yoursunny.com/t/2018/Air602-blink/)
https://yoursunny.com/t/2018/Air602-weather/ (https://yoursunny.com/t/2018/Air602-weather/)
Grüße,
Jürgen
Mein Gedanke war, ob es möglich ist, die Firmware von mapleduino auf nen wemos zu portieren. Sprich nen wemos mit 2 oder 3 cc1101 dran. Dann hat man es auf einen Prozessor inl. wlan. Ohne nen wemos parallel an den maple zu verbinden
Gesendet von meinem MI 9 mit Tapatalk
ZitatMein Gedanke war, ob es möglich ist, die Firmware von mapleduino auf nen wemos zu portieren.
Ja, das sollte möglich sein, wenn das zeitkritische einlesen der Nachrichtenpulse in einen FIFO Speicher in einen Coprocessor ausgelagert wird, das programmieren des Coprocessor ist aber nicht so einfach.
Da der ESP8266 keinen Coprocessor hat, müsste dafür z.B. ein Promini verwendet werden.
Das es ohne Coprocessor nicht 100% funktioniert, sieht man am SignalESP bei dem zwar das meiste funktioniert, aber es gibt ein paar Protokolle die nicht sauber oder gar nicht funktionieren.
Gruß Ralf
Also dann eher einen esp32?!
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: juergs am 11 April 2020, 15:33:21
Es gäbe vielleicht noch eine günstigere Option:
Falls du dich damit erfolgreich befasst würde ich das Thema ggf. auch nochmals angehen.
(Beim Maple-CUL hatte ich das Teil eine Zeit lang eingeplat, inkl. Antenne. Resonanz war leider gleich Null:-(
https://raw.githubusercontent.com/ranseyer/CUN-STM32/master/HW-MAPLE-Large/Archiv/V3.4/bot.png)
ZitatIch habe hier 2 Stück Air602 herumliegen, werden mich mal damit etwas beschäftigen ...
plus drei :-)
Zitat von: juergs am 10 April 2020, 21:19:44
Anbei die STLs zum Selber-3D-Drucken.
Danke, Testdruck ist durch. Sieht recht ordentlich aus und ist präzise.
Wenn es zum verschrauben und ohne LAN wäre, das wäre perfekt... 8)
ZitatWenn es zum verschrauben und ohne LAN wäre, das wäre perfekt...
.. I know ;D
Ja, das LAN-Modul trägt etwas auf, ohne LAN wäre das Ganze etwas schlanker.
Allerdings die Idee mit Schienen habe ich ad acta gelegt: die CC1101 sind zu nah am Rand ... ;)
Die SnapIns passen nicht 100%ig und brauchen etwas Nachbearbeitung (bei meinem ANET A8), habe sie etwas zu weit unten platziert ...
D.h. noch eine weitere Runde ...
Grüße,
Jürgen
PS: Zum Air602: Oh, wie ich AT-Befehle mag ::)
Aber:
https://yoursunny.com/t/2018/Air602-blink/ (https://yoursunny.com/t/2018/Air602-blink/) mit GCC :)
https://w600.chip.haus/ (https://w600.chip.haus/)
https://docs.wemos.cc/en/latest/tutorials/w600/get_started_with_micropython_w600.html (https://docs.wemos.cc/en/latest/tutorials/w600/get_started_with_micropython_w600.html)
http://www.winnermicro.com/en/upload/1/editor/1568715663185.pdf (http://www.winnermicro.com/en/upload/1/editor/1568715663185.pdf)
https://docs.wemos.cc/en/latest/tutorials/w600/get_started_with_micropython_w600.html (https://docs.wemos.cc/en/latest/tutorials/w600/get_started_with_micropython_w600.html)
http://www.winnermicro.com/en/html/1/156/158/536.html (http://www.winnermicro.com/en/html/1/156/158/536.html)
AT+
AT+WPRT=0
AT+SSID=<Eigene_WLAN_SSID>
AT+KEY=1,0,<WLAN_PWD>
AT+WJOIN
AT+NIP=!0
AT+LKSTT
>> +OK=1,"192.168.178.114","255.255.255.0","192.168.178.1","192.168.178.1","0.0.0.0"
Mit Accesspoint verbunden
ZitatC:\Users\js>ping 192.168.178.114
Ping wird ausgeführt für 192.168.178.114 mit 32 Bytes Daten:
Antwort von 192.168.178.114: Bytes=32 Zeit=14ms TTL=255
Antwort von 192.168.178.114: Bytes=32 Zeit=6ms TTL=255
Antwort von 192.168.178.114: Bytes=32 Zeit=14ms TTL=255
Antwort von 192.168.178.114: Bytes=32 Zeit=4ms TTL=255
Ping-Statistik für 192.168.178.114:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 4ms, Maximum = 14ms, Mittelwert = 9ms
und fertig zur Socket-Übertragung .... oder zum Durchschleusen eines Seriellen Ports. :)
Statt mit AT-Befehlen geht es auch mit Micro Python für W600:
https://github.com/vshymanskyy/w600tool (https://github.com/vshymanskyy/w600tool)
ZitatC:\Users\js>python3 "D:\Work_STM32\_Hardware\Air602\_software\w600tool-0.1\w600tool.py" -p COM15 --upload D:\Work_STM32\_Hardware\Air602\_firmware\W600_Micropython_Firmware\W60X_MicroPython_1.10_B1.3_IMG\wm_w600_gz.img --upload-baud 115200
Opening device: COM15
Push reset button to enter bootloader...
Uploading D:\Work_STM32\_Hardware\Air602\_firmware\W600_Micropython_Firmware\W60X_MicroPython_1.10_B1.3_IMG\wm_w600_gz.img
0% [##############################] 100% | ETA: 00:00:00
Total time elapsed: 00:00:32
Reset board to run user code...
https://www.wemos.cc/en/latest/tutorials/w600/get_started_with_micropython_w600.html (https://www.wemos.cc/en/latest/tutorials/w600/get_started_with_micropython_w600.html)
Zitat>>> import network
>>>
>>> sta_if = network.WLAN(network.STA_IF)
>>> sta_if.active(True)
True
>>> sta_if.scan()
[(b'mywlan', b'|\xffM_\xab7', 1, -36, 32, False), (b'Sydney', b'l\x19\x8f\x07\x9dt', 1, -79, 60, False), (b'UPC1807062', b"\xc4'\x95w5\xa0", 1, -97, 60, False), (b'UPCE86A363', b'8C}\x10\x02#', 1, -91, 60, False), (b'FRITZ!Box 6490 Cable', b'\x98\x9b\xcbd\xf6X', 1, -89, 32, False), (b'adm', b'\x80*\xa8q\xce\xd0', 6, -63, 32, False), (b'DIRECT-25-HP OfficeJet Pro 8710', b'\x80\xceb\xf6g)', 6, -79, 32, False), (b'FRITZ!Box 7490', b'41\xc4\xf2\x03\x9a', 6, -81, 32, False), (b'onkel hubert', b'$e\x11?\xa0"', 8, -91, 32, False), (b'FRITZ!Box Gastzugang', b'.:\xfd\xfeZf', 10, -93, 32, False), (b'FRITZ!Box 6591 Cable IB', b',:\xfd\xfeZf', 10, -91, 32, False), (b'HZN245502401', b'\x1c:\xdet\x1f&', 13, -79, 60, False)]
>>> sta_if.connect("mywlan","mywlan_pwd")
>>>
>>> sta_if.isconnected()
True
>>>
>>>
Ein Schritt weiter: http://www.ultratechie.com/projects/w600-micropython/ (http://www.ultratechie.com/projects/w600-micropython/)
Ich habe rausgefunden daß die Anbindung über das LAN Modul stabil funktioniert, wenn ich die SerialUSB deaktiviere.
Ohne USB sollte es dann auch mit dem Bootloader2.0 funktionieren.
Ich habe vor die Befehle vom MapleCun zu übernehmen:
Wim - MAC Address
Wia - IPV4 Address
Wig - IPV4 gateway
Win - IPV4 network mask
Da "R" beim Signalduino schon für freeram verwendet ist, werde ich zum auslesen "ri" verwenden.
Ich habe bei der Ethernetlib noch keine Möglichkeit gefunden wie ich die MAC Adresse des W5500 auslesen kann
https://www.arduino.cc/en/Reference/Ethernet
Kann mit der culw die "build in" MAC Adresse des W5500 ausgelesen werden, dann könnte ich diese ausgelesene MAC mit "Wim" für den Signalduino verwenden.
Gruß Ralf
Der W5500 hat keine individuelle MAC Adresse. Die muss man dem selber geben. Für die a-culfw verwende ich den Adressbereich des VEB Kombinat Robotron und erzeuge mit der Seriennummer des STM32 eine zufällige MAC Adresse. Bei der Verwendung in einem lokalen Netzwerk sollte das keinen Adressenkonflikt verursachen.
Zitat von: Ralf9 am 15 April 2020, 23:30:19
Ich habe rausgefunden daß die Anbindung über das LAN Modul stabil funktioniert, wenn ich die SerialUSB deaktiviere.
Ohne USB sollte es dann auch mit dem Bootloader2.0 funktionieren.
Warum funktioniert es mit USB nicht mit dem Bootloader 2.0?
ZitatFür die a-culfw verwende ich den Adressbereich des VEB Kombinat Robotron und erzeuge mit der Seriennummer des STM32 eine zufällige MAC Adresse.
Mir ist noch nicht klar wie ich an die Seriennummer des STM32 rankomme
https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/ethernet.c
#define bsbg boot_signature_byte_get
ZitatWarum funktioniert es mit USB nicht mit dem Bootloader 2.0?
Ich weiß auch nicht warum, mit "dmesg -w -e" lässt sich erkennen, daß mit dem Bootloader2.0 nach einem reset das USB nicht richtig initialisiert wird:
Ich verwende in der Arduino IDE den core 1.8.0
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
Ich nehme zum Testen den folgenden Sketch
int8_t led = 0;
//#define USBD_ENUM_DELAY 500
void setup() {
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
led = ~ led & 1;
digitalWrite(LED_BUILTIN, led);
delay(200);
}Ich flashe damit:
./dfu-util -d 1eaf:0003 -a 1 -D /tmp/arduino_build_70869/MapleminiTestusb.ino.bin -RUm zu sehen ob das USB richtig initialisiert wird, öffne ich eine Konsole mit "dmesg -w -e"
Fall 1, Orginalbootloader:USB funktioniert auch nach power on oder reset
[ +7,407971] usb 3-9: new full-speed USB device number 11 using xhci_hcd
[Apr13 00:37] usb 3-9: New USB device found, idVendor=1eaf, idProduct=0003
[ +0,000001] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000001] usb 3-9: Product: Maple 003
[ +0,000001] usb 3-9: Manufacturer: LeafLabs
[ +0,000001] usb 3-9: SerialNumber: LLM 003
[ +2,451835] usb 3-9: USB disconnect, device number 11
[ +0,306822] usb 3-9: new full-speed USB device number 12 using xhci_hcd
[ +0,149432] usb 3-9: New USB device found, idVendor=0483, idProduct=5740
[ +0,000002] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000000] usb 3-9: Product: MAPLEMINI_F103CB CDC in FS Mode
[ +0,000001] usb 3-9: Manufacturer: STMicroelectronics
[ +0,000001] usb 3-9: SerialNumber: 6D8824785548
[ +0,000460] cdc_acm 3-9:1.0: ttyACM0: USB ACM deviceFall 2, Bootloader2.0:
## reset Taste
[ +20,228840] usb 1-9: USB disconnect, device number 60
[ +0,470319] usb 1-9: new full-speed USB device number 61 using xhci_hcd
[ +0,149091] usb 1-9: New USB device found, idVendor=1eaf, idProduct=0003
[ +0,000001] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000001] usb 1-9: Product: Maple 003
[ +0,000001] usb 1-9: Manufacturer: LeafLabs
[ +0,000005] usb 1-9: SerialNumber: LLM 003
## flash
[ +1,507190] usb 1-9: reset full-speed USB device number 61 using xhci_hcd
[ +0,147934] usb 1-9: device firmware changed
[ +0,000081] usb 1-9: USB disconnect, device number 61
[ +0,127730] usb 1-9: new full-speed USB device number 62 using xhci_hcd
[ +0,149344] usb 1-9: New USB device found, idVendor=0483, idProduct=5740
[ +0,000002] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000001] usb 1-9: Product: MAPLEMINI_F103CB CDC in FS Mode
[ +0,000000] usb 1-9: Manufacturer: STMicroelectronics
[ +0,000001] usb 1-9: SerialNumber: 8D7452895051
[ +0,000449] cdc_acm 1-9:1.0: ttyACM0: USB ACM device
## reset Taste
[ +6,039450] usb 1-9: USB disconnect, device number 62
[ +0,000065] cdc_acm 1-9:1.0: failed to set dtr/rts
[ +0,414680] usb 1-9: new full-speed USB device number 63 using xhci_hcd
[ +0,149008] usb 1-9: New USB device found, idVendor=1eaf, idProduct=0003
[ +0,000002] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000001] usb 1-9: Product: Maple 003
[ +0,000000] usb 1-9: Manufacturer: LeafLabs
[ +0,000001] usb 1-9: SerialNumber: LLM 003Hier fehlt nach einem reset dieser Teil:
[ +2,451835] usb 3-9: USB disconnect, device number 62
[ +0,306822] usb 3-9: new full-speed USB device number 63 using xhci_hcd
[ +0,149432] usb 3-9: New USB device found, idVendor=0483, idProduct=5740
[ +0,000002] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000000] usb 3-9: Product: MAPLEMINI_F103CB CDC in FS Mode
[ +0,000001] usb 3-9: Manufacturer: STMicroelectronics
[ +0,000001] usb 3-9: SerialNumber: 6D8824785548
[ +0,000460] cdc_acm 3-9:1.0: ttyACM0: USB ACM deviceGruß Ralf
Zitat von: Ralf9 am 16 April 2020, 19:41:00
Mir ist noch nicht klar wie ich an die Seriennummer des STM32 rankomme
https://github.com/heliflieger/a-culfw/blob/master/culfw/clib/ethernet.c
#define bsbg boot_signature_byte_get
Der Teil gehört auch zu AVR. Der ARM Code ist darüber:
#ifdef ARM
uint32_t fserial = flash_serial();
buf[2] = 'm'; strcpy_P(buf+3, PSTR("008041"));
tohex((uint8_t)(fserial>>16 & 0xff), (uint8_t*)buf+9);
tohex((uint8_t)(fserial>>8 & 0xff), (uint8_t*)buf+11);
tohex((uint8_t)(fserial & 0xff), (uint8_t*)buf+13);
write_eeprom(buf);//MAC
Da der Cube zuerst da war und da die Serialnummer vom Dataflash Baustein verwendet wird, steht der entsprechende Code in eeprom.c (https://github.com/heliflieger/a-culfw/blob/master/culfw/STM32/avr/eeprom.c)
Zitat von: Ralf9 am 16 April 2020, 19:41:00
Ich flashe damit:
./dfu-util -d 1eaf:0003 -a 1 -D /tmp/arduino_build_70869/MapleminiTestusb.ino.bin -R
Ist der Sketch für den Originalbootloader oder den Bootloader2.0 gelinkt worden? Der Parameter "-a 1" bedeutet Startadresse ist 0x8005000. Ein für den Bootloader2.0 gelinkter Sketch muss mit "-a 2" geladen werden.
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=0, name=""
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0 Upload to Flash 0x8005000"
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
ZitatDa der Cube zuerst da war und da die Serialnummer vom Dataflash Baustein verwendet wird, steht der entsprechende Code in eeprom.c
Ich habe testweise die UID mal ausgelesen:
66bff57 50518349 87085332
Wenn ich das richtig verstehe, dann wird in der a-culfw von den Byte 0 - 8 (57 50518349 87085332) eine 32 Bit crc Prüfsumme gebildet.
Von dieser 32 Bit crc Prüfsumme werden das Byte 0 - 2 für die MAC Adresse verwendet. Dies sieht recht aufwendig aus.
Ist es nicht auch ausreichend, daß direkt die Bytes 0 - 2 für die MAC Adresse verwendet werden, mit der o.g. UID wäre die MAC dann: 00 80 41 08 53 32
ZitatIst der Sketch für den Originalbootloader oder den Bootloader2.0 gelinkt worden? Der Parameter "-a 1" bedeutet Startadresse ist 0x8005000. Ein für den Bootloader2.0 gelinkter Sketch muss mit "-a 2" geladen werden.
Es macht keinen Unterschied ob das bin-file für den Originalbootloader oder den Bootloader2.0 gelinkt worden ist ( Parameter "-a 1" oder "-a 2")
Gibt es eine Möglichkeit dies zu debuggen?
Bei der IDE gibt es bei optimize die Option debug (-g)
Hallo Ralf9,
und wenn man wirklich mal den anderen Typ von (MSC)-Bootloader (https://forum.fhem.de/index.php/topic,101610.msg951724.html#msg951724) von telekatz (https://github.com/Telekatz/MSC-stm32f103-bootloader) ausprobiert?
=> Reset nach Einschalten 2 mal hintereinander drücken, dann öffnet sich ein USB-Laufwerk, idas man die Binary einfach reinlegen muss. Programmiert sich quasi selbst :) :D
Würde ich auch mal ausprobieren, vielleicht verträgt sich der BL mit dem SD-Binary und serieller Schnittstelle(n)...
Das wäre eine wirklich eine komfortable Art, die SignalDuino-Binary zu Flashen (auf Grund der Infos von Telekatz mit den -a1 und -a2 Parametern kein Aufwand mehr) ...
Debugmöglichkeiten wären mit VSCode (habe das hier noch gefunden https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug (https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug)) und ggf. von meiner Seite mit VisualStudio und https://visualgdb.com/tutorials/arm/stm32/ (https://visualgdb.com/tutorials/arm/stm32/).
Aber, Grundvorraussetzung wäre wirklich das "Aufräumen" des Codes um "einfacher" (!), also ohne große C/C++ Klimmzüge und "Tricks" kompilieren zu können.
Das Debuggen mit STLINK (SW-DEBUG) oder Black Magic Probe funktioniert bei mir.
Habe vor kurzem versucht Sideys Version zu kompilieren,aber es scheint eigentlich nur unter Linux kompilierbarzu sein (...) und er macht Klimmzüge, dass eine Kompilierbarkeit mit make-Umgebung + Arduino-IDE gegeben ist.
Das führt zu quasi aus meiner Sicht zu unendlich viel Problemen beim Portieren auf WIN10. Was aber nicht heißen soll, dass es nicht geht: Stichwort WSL und Ubuntu. Inzwischen auch mit grafischer Oberfläche und XRDP:
(https://www.codeproject.com/Tips/5255423/Linux-on-Windows (https://www.codeproject.com/Tips/5255423/Linux-on-Windows))
Gruß,
Jürgen
/edit, Geht sogar auf leeren Maple ohne CC1101-Module Nach dem Soft-Reset des STLINKs kamen nur 2 Schnittstellen, nach Reset-Button und Abziehen USB dann 3, wie gewohnt.:
Zitat? (? is unknown) Use one of 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
V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) MapleCUNx4_00 (F-Band: 868MHz)
Check nach Reset:
Zitat? (? is unknown) Use one of 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
Geht auch prima. :D
Poste hier mal die .bin und die .map Datei von deinem Testsketch.
Zitat von: Ralf9 am 17 April 2020, 00:09:03
Ich habe testweise die UID mal ausgelesen:
66bff57 50518349 87085332
Wenn ich das richtig verstehe, dann wird in der a-culfw von den Byte 0 - 8 (57 50518349 87085332) eine 32 Bit crc Prüfsumme gebildet.
Von dieser 32 Bit crc Prüfsumme werden das Byte 0 - 2 für die MAC Adresse verwendet. Dies sieht recht aufwendig aus.
Ist es nicht auch ausreichend, daß direkt die Bytes 0 - 2 für die MAC Adresse verwendet werden, mit der o.g. UID wäre die MAC dann: 00 80 41 08 53 32
Mir erschien es sicherer, eine CRC Prüfsumme über die UID zu verwenden. Für den Fall, dass während der Produktion nicht die ersten Bytes für die Seriennummer hochgezählt werden.
ZitatPoste hier mal die .bin und die .map Datei von deinem Testsketch.
uint8_t led = 0;
//#define USBD_ENUM_DELAY 20
void setup() {
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
led = ~ led & 1;
digitalWrite(LED_BUILTIN, led);
delay(2000);
}
Hallo Ralf,
erst mal Deine bin (MapleminiTestusb.ino.bin) geflasht.
Blinkt und Serielle COM30 ist angelegt.
Beim Einrichten nach dem Einlegen in das USB-LW kam eine andere Melung Maple ... FSC. usw, war leider zu schnell um ein Screenshot zu machen.
Dann verhält es sich unter Windows anders als unter Linux, ich habe es bis jetzt nur unter Linux getestet
Welches Verhalten meinst Du?
Nach Reset Schnittstelle nicht mehr da, das hatte ich aber auch (https://forum.fhem.de/index.php/topic,106278.msg1038464.html#msg1038464) schon mit dem 2.0er Bootloader.
ZitatNach Reset Schnittstelle nicht mehr da, das hatte ich aber auch schon mit dem 2.0er Bootloader.
Ja, dieses verhalten mit dem 2.0er Bootloader und dem core 1.8.0 meine ich.
Ist bei mir mit dem MSC-BL von Telekatz nicht der Fall.
Läuft.
Versuche mal den MapleCUN Compile von trebron106 . => geht aber nicht: da hängt der BL (https://forum.fhem.de/index.php/topic,106278.msg1037726.html#msg1037726) mit drin !
@Ralf9: hast Du ein Binary der "dev-r334_cc1101" Maple-SDuino Version auf 0x8002000?
ZitatIst bei mir mit dem MSC-BL von Telekatz nicht der Fall.
Läuft.
Ich habe nun auch mal den MSC-BL geflasht, damit läuft es bei mir auch
Zitat
[ +9,037119] usb 1-9: USB disconnect, device number 34
[ +0,000067] cdc_acm 1-9:1.0: failed to set dtr/rts
[ +1,944667] usb 1-9: new full-speed USB device number 35 using xhci_hcd
[ +0,149355] usb 1-9: New USB device found, idVendor=0483, idProduct=5740
[ +0,000002] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ +0,000001] usb 1-9: Product: MAPLEMINI_F103CB CDC in FS Mode
[ +0,000001] usb 1-9: Manufacturer: STMicroelectronics
[ +0,000000] usb 1-9: SerialNumber: 8D7452895051
[ +0,000410] cdc_acm 1-9:1.0: ttyACM0: USB ACM device
MAPLEMINI_F103CB CDC in FS Mode
War bei mir auch die Meldung !
Schön, dass es geht.
Das 2mal Reset-Pressen zum Neu-Flashen muss man noch das "Gefühl" dafür entwickeln ... ;D
PS: Schau mal in Dein Postfach...
Der Fehler am Bootloader2.0 ist der, dass beim verlassen des Bootloaders USB nicht getrennt wird. Dadurch findet keine erneute enumeration des CDC Devices statt.
Man kann entweder den Bootloader (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/df689808b6030280480c0d151ee9c552ecf6b405/hardware.c#L208) patchen:
void jumpToUser(u32 usrAddr) {
/* tear down all the dfu related setup */
// disable usb interrupts, clear them, turn off usb, set the disc pin
// todo pick exactly what we want to do here, now its just a conservative
flashLock();
usbDsbISR();
nvicDisableInterrupts();
#ifndef HAS_MAPLE_HARDWARE
usbDsbBus();
#else
gpio_write_bit(USB_DISC_BANK,USB_DISC_PIN,1);
#endif
// Does nothing, as PC12 is not connected on teh Maple mini according to the schemmatic setPin(GPIOC, 12); // disconnect usb from host. todo, macroize pin
systemReset(); // resets clocks and periphs, not core regs
setMspAndJump(usrAddr);
}
Oder man trennt die Verbindung kurz im setup Teil vom Sketch:
uint8_t led = 0;
//#define USBD_ENUM_DELAY 200
void setup() {
pinMode(D34, OUTPUT);
digitalWrite(D34,1);
delay(100);
digitalWrite(D34, 0);
pinMode(LED_BUILTIN, OUTPUT);
}
void loop() {
led = ~ led & 1;
digitalWrite(LED_BUILTIN, led);
delay(2000);
}
Wäre eine Issue bei Roger (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues) wert.
ZitatDer Fehler am Bootloader2.0 ist der, dass beim verlassen des Bootloaders USB nicht getrennt wird. Dadurch findet keine erneute enumeration des CDC Devices statt.
Der Fehler wirkt sich aber nur beim STM32 Core 1.8.0 aus, mit Rogers Core funktioniert das USB nach einem Reset auch mit dem Bootloader 2.0.
ZitatMan kann entweder den Bootloader patchen
Dies wäre die bessere Variante.
Kannst Du einen gepatchten Bootloader2.0 erstellen?
Gruß Ralf
pinMode(D34, OUTPUT);
digitalWrite(D34,1);
delay(100);
digitalWrite(D34, 0);
Was ist D34, ich kann nichts darüber finden.
Bei mir hat gerade der Kompile mit Arduino geklappt:
? Use one of ?S ? b CE CD CG CR CS CW C eC e P r R S t T V W x XE XQ
V 4.1.0-dev200322 SIGNALduino cc1101 (R: B-*) - compiled at Apr 17 2020 22:31:14
Wow, ein Act! ::)
Mit einigen Anpassungen und Vereinfachungen!
Ich habs getestet, bei der sduino V 4.1.0 firmware funktioniert das USB mit dem Bootloader 2.0 auch nach einem Reset, wenn ich dies nach setup einfüge.
void setup() {
pinMode(D34, OUTPUT);
digitalWrite(D34,1);
delay(100);
digitalWrite(D34,0);
Wird es auch noch problemlos funktionieren, wenn die Verbindung kurz im setup Teil vom Sketch getrennt wird und ein gepatchter Bootloader 2.0 verwendet wird?
Zitat von: Ralf9 am 17 April 2020, 22:31:35
pinMode(D34, OUTPUT);
digitalWrite(D34,1);
delay(100);
digitalWrite(D34, 0);
Was ist D34, ich kann nichts darüber finden.
D34 ist PB_9 (USB DISC). Findet man in der variant.cpp.
Anbei der gepatchte Bootloader2.0.
Zitat von: Ralf9 am 17 April 2020, 22:49:50
Wird es auch noch problemlos funktionieren, wenn die Verbindung kurz im setup Teil vom Sketch getrennt wird und ein gepatchter Bootloader 2.0 verwendet wird?
Ich denke ja.
ZitatAnbei der gepatchte Bootloader2.0.
Danke, für Deine Hilfe, damit funktioniert es wie gewünscht auch mit dem Bootloader2.0
Wie soll ich nun weiter vorgehen.
Das sauberste wäre ein Issue bei Roger zu machen, damit der Fehler im Bootloader2.0 gepatcht wird.
Ich würde dann neue sduino V.4.1.x bin Files für den Bootloader2.0 machen, wer diese bin verwenden will muss vorher den neuen gepatchten Bootloader2.0 flashen
Da Roger meist schnell antwortet, habe ich mir erlaubt, diese Issue bei ihm einzustellen:
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues/91 (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues/91)
Ich habe von einem STM32 Core Entwickler eine Antwort bekommen:
ZitatIt seems stange as the core already handle the reenum:
https://github.com/stm32duino/Arduino_Core_STM32/blob/16f3644e7b9f8225dcb01f48bd857bdc3a978580/cores/arduino/stm32/usb/usbd_if.c#L19
This will change in the 1.9.0 to be more compliant with USB specs
https://github.com/stm32duino/Arduino_Core_STM32/commit/e1d409f1203d5820e563e7be4bb084b57dc5b4b6
anyway still one issue to fix for hardware which does not follow the spec:
https://github.com/stm32duino/Arduino_Core_STM32/issues/1029
Nachtrag:
https://www.stm32duino.com/viewtopic.php?p=2168#p2168
War mit Sicherheit die bessere Wahl dort nachzufragen ... ;)
Ohne die Hilfe von Telekatz wäre ich da aber wahrscheinlich nicht weitergekommen.
Anscheinend hält sich der Maple Mini nicht ganz an die USB Spec
Mir ist noch nicht klar was ich an der
https://github.com/stm32duino/Arduino_Core_STM32/blob/16f3644e7b9f8225dcb01f48bd857bdc3a978580/cores/arduino/stm32/usb/usbd_if.c#L19
ändern muss
Gruß Ralf
https://www.stm32duino.com/viewtopic.php?p=2172#p2172
ZitatRafl9
Main issue is why you get issue, sveral other user (including me) does not have this issue.
So, it seems in your case the reenum does not have the expected effect, call too earlier? Delay should be increased?
You can override the core reenum function as it is a weak one or increase the delay as th delay is a definition wchich can be rederfined
Zitat von: Ralf9 am 19 April 2020, 09:14:24
Ohne die Hilfe von Telekatz wäre ich da aber wahrscheinlich nicht weitergekommen.
Anscheinend hält sich der Maple Mini nicht ganz an die USB Spec
Mir ist noch nicht klar was ich an der
https://github.com/stm32duino/Arduino_Core_STM32/blob/16f3644e7b9f8225dcb01f48bd857bdc3a978580/cores/arduino/stm32/usb/usbd_if.c#L19
ändern muss
Gruß Ralf
Ich glaube, den DISC_PIN mit etwas Delay togglen:
pinMode(USB_DISC_PIN, OUTPUT);
digitalWrite(USB_DISC_PIN,High); //1
delay(100);
digitalWrite(USB_DISC_PIN, Low); //0Statts:
pinMode(USB_DISC_PIN, OUTPUT);
digitalWrite(USB_DISC_PIN, LOW);
Richtig, der USB_DISC_PIN muss einmal auf High und dann wieder auf Low gesetzt werden. Denn auf Low ist er ja schon nach dem verlassen des Bootloaders.
Füge die angehängte Datei mal in dein Sketch Verzeichnis hinzu. Die sollte das korrigieren.
Am saubersten wäre es wahrscheinlich, wenn wir es ohne einen Patch im core 1.8.0 hinbekommen können.
Im core 1.9.0 ist der Bug anscheinend behoben.
evtl so?
#ifdef core gleich 1.8.0 // ist dies möglich den core abzufragen?
#define USBD_REENUM_DISABLED // kann ich damit das USBD_REENUM disablen?
#endif
void setup() {
#ifdef core gleich 1.8.0 // ist dies möglich den core abzufragen?
hier dann die neue USBD_REENUM
pinMode(USB_DISC_PIN, OUTPUT);
digitalWrite(USB_DISC_PIN, HIGH);
delay(10);
digitalWrite(USB_DISC_PIN, LOW);
pin_function(pinDP, STM_PIN_DATA(STM_MODE_OUTPUT_PP, GPIO_NOPULL, 0));
digitalWriteFast(pinDP, LOW);
delay(USBD_ENUM_DELAY);
pin_function(pinDP, STM_PIN_DATA(STM_MODE_INPUT, GPIO_NOPULL, 0));
#endif
Nachtrag:
Heißt das, wenn ich die USBD_reenumerate.c in das sketch Verzeichniss lege, dann wird diese anstatt der im core verwendet?
Dies wäre auch eine Möglichkeit.
Zitat von: Telekatz am 19 April 2020, 11:28:58
Füge die angehängte Datei mal in dein Sketch Verzeichnis hinzu. Die sollte das korrigieren.
Ja, damit funktionierts.
Bedeuted dies kleiner core 1.9.0?
#if ARDUINO < 10900Nachtrag:
Ja ist anscheinend so.
Mit
#if ARDUINO < 10800 funktioniert es nicht mehr
https://www.stm32duino.com/viewtopic.php?p=2197#p2197
ZitatOk but the intersting thing is how USB is wired
Kann jemand von Euch diese Info liefern?
Hallo Ralf,
im ihrem Forum-Wiki ist das PDF kaputt...
Aber hier ist es noch vorhanden: https://github.com/leaflabs/maplemini/blob/master/maplemini.pdf (https://github.com/leaflabs/maplemini/blob/master/maplemini.pdf)
Links unten mit PB9 als "DISC" schaltet USB.
Verstehe ich das richtig, daß wenn DISC high ist, dann liegt der Pullup R10 nicht mehr an VCC, und das 23_USBDP kann nicht mehr high werden
Zitatthe pull-up actually perform two tasks, connection and speed sensing.
Detecting a pull-up lets the host controller know a device is connected. USB is a master/slave protocol with most of heavy lifting being performed by the host controller.
Low speed devices use unshielded cable and cannot operate at higher speed so it is important signalling occur at low speed.
Zitatwenn DISC high ist, dann liegt der Pullup R10 nicht mehr an VCC, und das 23_USBDP kann nicht mehr high werden
Ja, der 2 Transistor leitet dann nicht mehr , weil seine Basis auf Low gezogen wird und < 0.7V sperrt dieser.
Siehe auch hier: https://www.dslreports.com/forum/r27625645-why-a-pullup-on-USB-D (https://www.dslreports.com/forum/r27625645-why-a-pullup-on-USB-D)
Danke, damit ist es für den Bootloader2.0 klar,
mir ist aber nicht klar, warum das USBD_reenumeratees beim Orginalbootloader funktioniert, obwohl im core das USB_DISC_PIN nicht kurz auf high wechselt.
Vielleicht liegt es nur am Delay, also wie lange der Pulldown anliegt ?
Der Originalbootloader ruft beim Verlassen des Bootloaders in jumpToUser (https://github.com/leaflabs/maple-bootloader/blob/6a47cf0c4f722702ede3eb19a93f803d08e06859/hardware.c#L141) die Funktion usbDsbBus (https://github.com/leaflabs/maple-bootloader/blob/6a47cf0c4f722702ede3eb19a93f803d08e06859/usb.c#L54) auf, die den USB_DISC Pin wieder auf High setzt und damit die USB Verbindung trennt. Der 1.8 Arduino Core setzt dann nach dem Start in USBD_reenumerate den USB_DISC Pin wieder auf low, wodurch der USB Host erneut eine Enumeration macht.
Der Bootloader2.0 setzt den Pin beim verlassen nicht wieder auf High und die USB Verbindung bleibt als DFU Gerät bestehen. Das setzen des Pins auf Low hat dann im 1.8 Arduino Core keine Auswirkungen mehr, da der Pin ja schon auf Low ist.
ZitatDer Originalbootloader ruft beim Verlassen des Bootloaders in jumpToUser die Funktion usbDsbBus auf, die den USB_DISC Pin wieder auf High
Danke, damit ist mir einiges klarer geworden.
Und hier bin ich damit einen großen Schritt weitergekommen,
https://www.stm32duino.com/viewtopic.php?p=2200#p2200
ZitatNun wird als Beispiel das Modul A der EEPROM Speicherbank 1 zugeordnet.
bA1
Error! Bank 1 is not initialized
Ich möchte die Fehlermeldung die kommt, wenn versucht wird ein cc1101 Modul einer nicht initialisierten EEPROM Speicherbank zuzuordnen, erweitern.
Error! Bank 1 is not initialized, you can with the command e the bank initialize with the sduino defaultsDies gefällt mir so noch nicht so richtig, Verbesserungsvorschläge sind willkommen
Hi, wenn klar ist, dass man eh raw e machen muss, warum dann als Fehler ausgeben?
Wie wäre es statt dessen einen Werksreset zu machen und als Fehlercode vorher ein:
The bank was not complete initialized, therefore the modul was reseted (raw e). Please update your settings accordingly.
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Ich verwende diese Meldung um zu testen ob eine Bank noch frei (nicht initialisiert) ist.
Ich könnte diesen automatischen Werksreset e machen, dann bräuchte ich einen neuen Befehl mit dem eine Übersicht über die Bankbelegung ausgegeben wird.
Ich weiss noch nicht wie ich den Befehl benennen soll
bi
bs - Bank summary
bo - Bank overview
oder?
Die Ausgabe könnte dann z.B. so aussehen (N = - bedeuted Bank nicht initialisiert):
Bank(Radio N/ccmode): 0(B 0/0) 1(A 0/3) 2(2/3) 3(C 3/3) 4(4/2) 5(0/0) 6(-) 7(-) 8(-) 9(-)
oder
Bank(N/ccmode Radio): 0(0/0 B) 1(0/3 A) 2(2/3) 3(3/3 C) 4(4/2) 5(0/0) 6(-) 7(-) 8(-) 9(-)
oder
Bank__ 0 1 2 3 4 5 6 7 8 9 Radio_ B A - C - - - - - - N_____ 0 0 2 3 4 - - - - - ccmode 0 3 3 3 2 - - - - -
wenn im signalduino fhem Modul dann alle doppelten Leerzeichen durch einen Zeilenumbruch ersetzt werden, sieht es im Ausgabefenster so aus:
Bank__ 0 1 2 3 4 5 6 7 8 9
Radio_ B A - C - - - - - -
N_____ 0 0 2 3 4 - - - - -
ccmode 0 3 3 3 2 - - - - -
Ich würde bs, allerdings mit der Bedeutung"bank status" bevorzugen. Als Ausgabe betrachte ich die letzte Version als die übersichtlichste. Bei mir läuft die 4.1 übrigens hervorragend auf einem Maple Mini mit 2 cc1101 Modulen.
Hallo Ralf9,
ein bisschen Off-Topic ... noch zum Thema "STM32-Bootloader verstehen":
http://kevincuzner.com/2018/06/28/building-a-usb-bootloader-for-an-stm32/ (http://kevincuzner.com/2018/06/28/building-a-usb-bootloader-for-an-stm32/)
https://github.com/kcuzner/led-watch (https://github.com/kcuzner/led-watch)
Übersicht:
http://www.bdtic.com/en/st/stm32f103r8 (http://www.bdtic.com/en/st/stm32f103r8)
ZitatIch könnte diesen automatischen Werksreset e machen, dann bräuchte ich einen neuen Befehl mit dem eine Übersicht über die Bankbelegung ausgegeben wird.
Ich habe es eingebaut:
https://github.com/Ralf9/SIGNALDuino/commits/dev-r41x_cc1101
Es wird nun dies ausgegeben:
The bank 4 was not complete initialized, therefore the bank and radio is reseted to sduino defaults (raw e). ccFactoryReset doneEs gibt einen neuen Befehl "bs", siehe Anlage.
Ich habe vor die Ausgabe vom "bs" Befehl noch um eine max 8 Zeichen Kurzbeschreibung der Bänke zu erweitern
Dies könnte dann z.B. so aussehen:
Bank__ 0 1 2 3 4 5 6 7 8 9
Radio_ B A - C - - - - - -
N_____ 0 0 2 3 4 - - - - -
ccmode 0 3 3 3 2 - - - - -
0 - SlowRF
1 - M1 IT+
2 - M2 IT+
3 - PCA 301
4 - Kopp FCSind die Kurzbeschreibungen so ok, oder habt Ihr bessere Vorschläge?
Gruß Ralf
Sieht gut aus, wüsste nicht was man da besser machen könnte. Wenn jetzt noch irgendwo die Abkürzungen erklärt werden ist es perfekt ;)
siehe
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067
SlowRF (ASK/OOK)
Mode 1 - IT+ 17.241 kbps (LaCrosse)
Mode 2 - IT+ 9.579 kbps (LaCrosse)
Mode 3 - PCA 301 - 868.9500MHz, 6.631kbps
Kopp Free Control Datarate: 4785,5 Baud (GFSK)
Nachtrag:
Bei ccmode sind z.Zt. die folgenden Werte möglich:
0 - normal (OOK)
1 - FIFO auslesen normal, z.B. für Kopp
2 - FIFO auslesen ohne Wiederholungen
3 - FIFO auslesen LaCrosse
9 - FIFO auslesen mit Debug Ausgaben
Beim mode 9 ist vor und nach dem Ausgeben die Anzahl der Bytes im FIFO in Klammern angegeben.
M13 bedeutet das marcstate Register = 13
Wusste doch dass ich es schon mal gesehen hatte, wusste nur nicht mehr wo. Danke! :)
Hallo Ralf9,
habe die neue Version gerade auf mein zweites MapleSignalDuino-Board über Arduino geflasht:
Zitat
C:\Users\js\AppData\Local\Arduino15\packages\STM32\tools\STM32Tools\1.3.2/tools/win/maple_upload.bat COM39 1 1EAF:0003 C:\Users\js\AppData\Local\Temp\arduino_build_148822/SIGNALDuino.ino.bin
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="DFU Program FLASH 0x08005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=1137
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
error resetting after download: usb_reset: could not reset device, win error: Ein nicht vorhandenes Gerät wurde angegeben.
Done!
Resetting USB to switch back to runtime mode
Zitat
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03 ok,N=2,ccmode=3
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03 ok,ccmode=3
MN;D=9946331EDAAAAA000032E817;R=237;
MN;D=9946331EDAAAAA0000E95BE0;R=238;
MN;D=9946331EDAAAAA00001EFA69;R=239;
MN;D=9946331EDAAAAA0000C06447;R=239;
?
? Use one of ?S ? b CE CD CG CR CS CW C eC e P r R S t T V W x XE XQ
V
V 4.1.0-dev200422 SIGNALduino cc1101 (R: A1* B-) - compiled at Apr 24 2020 16:18:35
BS
Unsupported command
MN;D=9946331EDAAAAA0000BA8AFB;R=239;
MN;D=0C053010FFFFFFFFFFFFFFFF;R=215;
bs
Bank__ 0 1 2 3 4 5 6 7 8 9 Radio_ - A*- - - - - - - - N_____ 0 0 - - - - - - - - ccmode 0 3 - - - - - - - -
MN;D=9946331EDAAAAA000058AA37;R=238;
MN;D=9946331EDAAAAA0000C712D1;R=238;
Die Bankinfo will einfach nicht mit CR /CRLF/Auto korrekt formatieren ... (TeraTerm)
Initialisierung über Terminal (zum Testen des Boards) klappt auch (mit nur einem 868-Transceiver bestückt, local echo on) :
Zitat
e1W
write set ccFactoryReset done
r=A b=1 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0100
bs
Bank__ 0 1 2 3 4 5 6 7 8 9 Radio_ - A*- - - - - - - - N_____ 0 0 - - - - - - - - ccmode 0 0 - - - - - - - -
CREA
detect A: Partn=0 Ver=24
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03 ok,ccmode=3
V
V 4.1.0-dev200422 SIGNALduino cc1101 (R: Ai* B-) - compiled at Apr 24 2020 16:18:35
e
ccFactoryReset done
r=A b=1 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0100
V
V 4.1.0-dev200422 SIGNALduino cc1101 (R: Ai* B-) - compiled at Apr 24 2020 16:18:35
e1
set ccFactoryReset done
r=A b=1 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0100
bA1W
write set r=A b=1 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0100
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03 ok,ccmode=3
MN;D=9946331EDAAAAA000078F47D;R=239;
MN;D=9946331EDAAAAA0000349364;R=240;
MN;D=9946331EDAAAAA0000575FF3;R=239;
...
V
V 4.1.0-dev200422 SIGNALduino cc1101 (R: A1* B-) - compiled at Apr 24 2020 16:18:35
bs
Bank__ 0 1 2 3 4 5 6 7 8 9 Radio_ - A*- - - - - - - - N_____ 0 0 - - - - - - - - ccmode 0 3 - - - - - - - -
Hoffe, ich habe die richtige Befehlsabfolgen gewählt. Die ersten Ausgaben stammen noch von Versuchen ...
Empfängt jetzt schön FSK-Geräte in Mode 1 - IT+ 17.241 kbps. Im Modus 2 habe ich bei mir nichts empfangen.
Nach einem Neu-Einstecken des Boards:
Reading values from eeprom
CCInit
detect A: Partn=0 Ver=24
detect B: Partn=0 Ver=0 invalid
Starting timerjob
MN;D=9946331EDAAAAA000054D348;R=238;
V
V 4.1.0-dev200422 SIGNALduino cDie EEProm-Settings wurden offenbar korrekt geschrieben und dem richtigen Modul zugeordnet, da wieder Telegramme empfangen werden.
Grüße,
Jürgen
ZitatDie Bankinfo will einfach nicht mit CR /CRLF/Auto korrekt formatieren ... (TeraTerm)
Die saubere Formatierung funktioniert momentan nur mit meinem angepassten 00_Signalduino fhem Modul, dort werden die doppelten Leerzeichen durch "\n" ersetzt:
if ($msg =~ m/Bank__.* Radio_ /) {
$msg =~ s/ /\n/g;
$msg = "\n\n" . $msg;
return $msg;
}ZitatInitialisierung über Terminal klappt auch (mit nur einem 868-Transceiver bestückt, local echo on) :
ja, ist recht flexiblel, es gibt momentan nur die Einschränkung, daß SlowRF (Ask) nur mit dem zweiten cc1101 (Radio B) funktioniert.
ZitatIm Modus 2 habe ich bei mir nichts empfangen.
Der Modus 2 hat eine Baudrate von 9.579 kbps, hast Du ein Sensor mit 9.579 kbps?
https://wiki.fhem.de/wiki/JeeLink#Unterst.C3.BCtzte_Sensoren_und_Aktoren_incl._Wetterstation_WS_1600
Gruß Ralf
Man kann den MapleSduino auch recht einfach als nanoCul Nachfolger verwenden.
Man muß dazu nur das zweite cc1101 (Radio B) bestücken.
Per default wird Radio B der Bank 0 zugeordnet und mit SlowRF initialisiert
Ein Entwickler hat was zu dem Problem mit dem USBD_reenumerate geschrieben:
https://www.stm32duino.com/viewtopic.php?p=2283#p2283
Looking deeply,
it seems there is something weird in the bootloader management of the DISC pin depending if an upload is requested or not.
The way it works with libMaple core seems related to timing because I didn't see any difference btw the management except the fact it is called later when the USB begin() is called (in USBComposite library).
I guess the proper way should be to ensure the bootloader leave the USB in a proper state if no upload is requested.
Hallo Ralf9,
ZitatMan muß dazu nur das zweite cc1101 (Radio B) bestücken.
D.h. es würde für SlowRF auch statt ein 433-Modul auch ein zweites mit 868MHz funktionieren?
Das mit der Formatierung der Bankinfo im Terminal ist eher Kosmetik. Die CRLF/CR - Erkennung steht jetzt auf AUTO... ;)
Danke für die Info.
Jürgen
ZitatD.h. es würde für SlowRF auch statt ein 433-Modul auch ein zweites mit 868MHz funktionieren?
Ja, wenn Du eine 433 MHz Antenne verwendest, kannst Du für das zweite cc1101 (Radio B) eins mit 868 MHz verwenden, hat dann aber wegen der falschen Antennenanpassung eine etwas höhere Dämpfung
Zitathat dann aber wegen der falschen Antennenanpassung eine etwas höhere Dämpfung
Mit SMA geht der Tausch recht leicht ... ;)
Im Log habe ich folgenden Output gefunden:
Zitat2020-04-24 18:16:41 SIGNALduino maple_sduino cc1101_config: Freq: 0.000 MHz, Bandwidth: 812 KHz, rAmpl: 24 dB, sens: 4 dB, DataRate: 24.80 Baud
2020-04-24 18:16:41 SIGNALduino maple_sduino cc1101_config_ext: Modulation: 2-FSK, Syncmod: No preamble/sync
cc1101_config
Freq: 0.000 MHz, Bandwidth: 812 KHz, rAmpl: 24 dB, sens: 4 dB, DataRate: 24.80 Baud
2020-04-24 18:16:41
cc1101_config_ext
Modulation: 2-FSK, Syncmod: No preamble/sync
2020-04-24 18:16:41
cc1101_patable
C3E = FF FF FF FF FF FF FF FF
2020-04-24 18:16:42
state
opened
Zitat von: Ralf9 am 24 April 2020, 17:51:20
Ja, wenn Du eine 433 MHz Antenne verwendest, kannst Du für das zweite cc1101 (Radio B) eins mit 868 MHz verwenden, hat dann aber wegen der falschen Antennenanpassung eine etwas höhere Dämpfung
Sorry, ich kann euch nicht ganz folgen...
Aus SW-Sicht sind 433 und 868MHz Module doch identisch nutzbar. (Unabhängig von der Frequenz)
Aus HW Sicht würde ich natürlich immer das Modul welches zur Frequenz passt verbauen inkl. passender Antenne. Also wenn es "Not tut" 2*868 MHz in grün verbauen...
Der CC1101 erzeugt prinzipbedingt massiv "Oberwellen". Diese werden am Ausgang mit einem Bandpass-Filter (https://de.wikipedia.org/wiki/Bandpass) weggefiltert. Dieser Filter lässt im Idealfall nur den 433 oder 868 MHz Bereich durch. Dass man den anderen Bereich auch (schlecht!) nutzen kann ist also nur das Ergebnis des Kompromisses beim Ausgangsfilter...
=> Ich will damit sagen, ich würde immer genau so bestücken wie ich auch funken will...
Habe den bootloader_2.0 mit der Demonstrator GUI und die neue Version mit Arduino v1.8.12 auf meinen Doppel-CUL-868-433 gepackt, läuft problemlos. Super! :)
ZitatDer CC1101 erzeugt prinzipbedingt massiv "Oberwellen".
Aber doch eigentlich nur beim Senden?!
@Ralf9,
Ist das die noch passende Modul-Version?
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txtoder doch eher diese:
https://github.com/RFD-FHEM/RFFHEM/blob/dev-r35_xFSK/controls_signalduino.txtZitat2020.04.24 19:14:29 1 : PERL WARNING: Use of uninitialized value $r[0] in string eq at ./FHEM/98_update.pm line 315.
2020.04.24 19:14:29 1 : PERL WARNING: Use of uninitialized value $r[0] in string ne at ./FHEM/98_update.pm line 325.
2020.04.24 19:14:29 1 : nothing to do...
bei der RFFHEM/dev-r34 ist noch keine FSK Unterstützung enthalten.
Mit der RFFHEM/blob/dev-r35_xFSK müsste eigentlich auch das FSK funktionieren, dort fehlen aber (noch?) die Komfortfunktionen,
wie z.B. das "get raw", das es in der aktuellen Version nicht mehr gibt.
Es gibt zwar ein set raw, da werden aber die Rückmeldungen nicht angezeigt.
Ich bin gerade dabei meine angepasstes 00_Signalduino Modul zu aktualisieren
https://github.com/Ralf9/RFFHEM/issues/4
Gruß Ralf
Hallo Ralf9,
ich habe mir mal die Datenübetragung des Signalduinos (Ethernet) angeschaut:
Zitat> Server Started on Port: 21
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> New Client: 192.168.178.23
XQ
V
V
V
> Client closed conection.
> New Client: 192.168.178.23
XQ
V
V
V
> Client closed conection.
> New Client: 192.168.178.23
XQ
V
V
V
> Client closed conection.
> New Client: 192.168.178.23
XQ
V
V
S: V 4.1.0-dev200422 SIGNALduino cc1101 (R: A1 B-*) - compiled at Apr 24 2020 16:18:35
br
XE
P
P
P
> Client closed conection.
> New Client: 192.168.178.23
XQ
V
V
V
> Client closed conection.
> New Client: 192.168.178.23
XQ
V
V
V
> Client closed connection.
Zitat2020.04.26 10:21:04.112 3: Opening netduino device 192.168.178.56:21
2020.04.26 10:21:04.119 1: netduino/define: 192.168.178.56:21
2020.04.26 10:21:04.119 1: netduino/init: 192.168.178.56:21
2020.04.26 10:21:04.120 3: netduino device opened
2020.04.26 10:21:05.623 3: netduino/init: disable receiver (XQ)
2020.04.26 10:21:06.122 3: netduino/init: get version, retry = 0
2020.04.26 10:21:16.136 3: netduino/init: get version, retry = 1
2020.04.26 10:21:26.150 3: netduino/init: get version, retry = 2
2020.04.26 10:21:36.164 3: netduino/init: get version, retry = 3
2020.04.26 10:21:36.164 2: netduino/init retry count reached. Closed
2020.04.26 10:21:36.165 2: netduino closed
Das heißt für eine WLAN-Anbindung müsste ich "nur" die fhem-Kommandos aus dem WLAN-Telnet-Client über RX1/TX1 in die loop-Schleife einschleusen und das Ergebnis
wieder über RX1/TX1 dann per WLAN (Telnet in ethernetLoop() ) zurückgeben ...
Zitat von: juergs am 24 April 2020, 19:05:43
Aber doch eigentlich nur beim Senden?!
Die Oberwellen werden nur beim Sender erzeugt. Der Filter verschwindet aber nicht währen er gerade "Freizeit" hat...
Der Filter filtert als auch den Empfang. Da der Filter sicherlich OK ist wird er den Empfang nicht merkbar verschlechtern. Aber der er auch in diese Richtung funktioniert hält er auch noch gleich starke Signale anderer Frequenzbänder weitgehend fern. Das schützt somit den ersten Mischer oder ggf. eher den LNA am Eingang vor Übersteuerung. Ansonsten würde er möglichweise das einwandfreie Nutzsignal auf dem gewünschten Band nicht erkennen weil z.B. der Nachbar auf irgendeiner gang anderen Frequenz irgendein verbotenes Videostreaming oder so berteibt...
Seite 3: https://ess.cs.tu-dortmund.de/Teaching/SS2014/SuS/Downloads/SuS-Uebung-5.pdf
=> Das Ziel des Filters ist also alles was nicht das gewünschte Band ist massiv abzuschwächen.
ZitatDas Ziel des Filters ist also alles was nicht das gewünschte Band ist massiv abzuschwächen
Dieses Ziel wird aber mit diesem Filter nicht ganz erreicht. Ich kann mit einer 868 cc1101 Stamp auf 433 eingestellt noch problemlos die Temperatursensoren durch eine Betondecke empfangen.
Zitat von: Ranseyer am 26 April 2020, 10:40:48
Die Oberwellen werden nur beim Sender erzeugt. Der Filter verschwindet aber nicht währen er gerade "Freizeit" hat...
Der Filter filtert als auch den Empfang. Da der Filter sicherlich OK ist wird er den Empfang nicht merkbar verschlechtern. Aber der er auch in diese Richtung funktioniert hält er auch noch gleich starke Signale anderer Frequenzbänder weitgehend fern. Das schützt somit den ersten Mischer oder ggf. eher den LNA am Eingang vor Übersteuerung. Ansonsten würde er möglichweise das einwandfreie Nutzsignal auf dem gewünschten Band nicht erkennen weil z.B. der Nachbar auf irgendeiner gang anderen Frequenz irgendein verbotenes Videostreaming oder so berteibt...
Seite 3: https://ess.cs.tu-dortmund.de/Teaching/SS2014/SuS/Downloads/SuS-Uebung-5.pdf
=> Das Ziel des Filters ist also alles was nicht das gewünschte Band ist massiv abzuschwächen.
Ein klassischer "Bandpass" ;)
Zitat von: Ralf9 am 26 April 2020, 10:50:05
Dieses Ziel wird aber mit diesem Filter nicht ganz erreicht. Ich kann mit einer 868 cc1101 Stamp auf 433 eingestellt noch problemlos die Temperatursensoren durch eine Betondecke empfangen.
Das war bei mir selbst mit den 433er Modulen und besserer Antenne bei mir kaum möglich,
deshalb sind wohl auch die 433er Module vom Markt verschwunden ... :(
ZitatDas heißt für eine WLAN-Anbindung müsste ich "nur" die fhem-Kommandos aus dem WLAN-Telnet-Client über RX1/TX1 in die loop-Schleife einschleusen und das Ergebnis
wieder über RX1/TX1 dann per WLAN (Telnet in ethernetLoop() ) zurückgeben ...
Mir ist nicht ganz klar wie Du das meinst.
Am einfachsten ist es die USB Version mit deaktiviertem USB zu kompilieren, dann wird für serial automatisch RX und TX verwendet.
An RX und TX kannst Du dann das Air602 anschließen.
Gruß Ralf
Zitat von: juergs am 26 April 2020, 10:54:45
Das war bei mir selbst mit den 433er Modulen und besserer Antenne bei mir kaum möglich, deshalb sind wohl auch die 433er Module vom Markt verschwunden ... :(
Hmm, das hätte ich keinesfalls so "gesagt"....
Hier hat sich jemand die Mühe gemacht die Filter zu inspizieren:
https://wiki.fhem.de/wiki/Selbstbau_CUL#Die_unterschiedlichen_Ausf.C3.BChrungen_des_Funkmoduls
Das sollte man bei neuer Quelle wohl immer checken...
(Also ob das "T" nach innen zeigt, oder nach unten. Leider sehen aktuell viele Module nochmals anders aus. da hilft im Zweifelsfall nur abmalen...)
TI macht ja auch Vorgaben dazu. Denke nur dass 433 MHz zu wenig gekauft wird...
Finde eh, dass das auf 50 Ohm angepasste Balun die bessere Variante mit weniger Bauteilen ist. ;-)
@Ralf9
ich schaue mit das mit der Umleitung auf die Serielle Schnittstelle mal an, muss aber noch die Verbindung zu fhem mit MicroPhyton aufbauen.
Bin auf der Suche nach Beispielen "TelnetLib" etc. und es muss auf den W60X-Port passen ...
Also, bin etwas weiter (Client):
Zitat__ __
\ \ /\ / /
\ \ / \ / /
\ \/ /\ \/ /
\ / \ /
/ /\ / /\
/ /\ \/ /\ \
/ / \ / \ \
/_/ \/ \_\
WinnerMicro W600
MicroPython v1.10-284-g2eee4e2-dirty on 2019-11-08; WinnerMicro module with W600
Type "help()" for more information.
>>> import connect_jsi_main
>>> connect_jsi_main.main()
*** Connecting to WLAN jsifrz and establih a FTP-server on port 21 user=root password=root
*** Returning the sta_if object for disconnect() of WLAN
***connected, ip is 192.168.178.114
ftpserver is running.
***FTP-server on port 21 user=root password=root IP=192.168.178.114
<WLAN>
>>> import testsock
>>> testsock.run()
Preparing for socket..
Socket sent: hello world!
b'Huhu 123\r\n'
gegen einen Socket-Server, nach aufgebauter WLAN-Verbindung, getestet.
Jetzt muss ich mir die Gegebenheiten um FHEM anschauen und ggf einen Server implementieren um FHEM ansprechen zu können ...
Frage mich nur welchen Port (21, telnet ?) 21 ist FTP und schon vergeben ... Port 23 dafür gesetzt.
define netduino SIGNALduino 192.168.178.114:23Zitat2020.04.27 18:28:47.827 1: netduino: Can't connect to 192.168.178.114:23: Illegal seek
2020.04.27 18:28:47.829 1: netduino: Can't connect to 192.168.178.114:23: 192.168.178.114: Connection refused (111)
2020.04.27 18:28:47.830 3: netduino: 192.168.178.114: Connection refused (111)
/edit: SIGNALESP: WiFiServer Server(23); // port 23 = telnet
Zitat von: juergs am 27 April 2020, 18:15:04
define netduino SIGNALduino 192.168.178.114:23
Das würde mich auch mal brennend interessieren wie ich den SIGNALduino mittels LAN ansprechen kann, kompilieren des Sketches funktioniert ja mit LAN einwandfrei, jetzt kann man ihn nur mit der Definition in FHEM nicht ansprechen.
Gruß
Markus
ZitatDas würde mich auch mal brennend interessieren wie ich den SIGNALduino mittels LAN ansprechen kann, kompilieren des Sketches funktioniert ja mit LAN einwandfrei, jetzt kann man ihn nur mit der Definition in FHEM nicht ansprechen.
LAN ist noch nicht ganz fertig, da fehlen noch ein paar Kleinigkeiten.
https://forum.fhem.de/index.php/topic,106278.msg1042866.html#msg1042866
Gruß Ralf
Hallo Ralf,
die MAC-Adresse-auslesen: https://forum.arduino.cc/index.php?topic=453311.0 (https://forum.arduino.cc/index.php?topic=453311.0)
Sorry wenn ich da jetzt mal nachfrage. Ich bin noch etwas verwirrt und versuche über die ganzen Maple einen Überblick zu bekommen.
Ich habe 2x Signalduino 433 und 868 am laufen.
Die neue Firmware ist dann auf Maple LUN LUX mini ?
Vieleicht anders gefragt: ich würde die Signalduino ablösen, und würde noch zigbee mit draufpacken. das geht dann aber nur mit Maple LUN LUX oder auch mit dem mini ? Der hat soweit ich sehe max 2 cc1101 on Board.
hallo laserrichi,
mir sagt "Maple LUN LUX mini" leider nichts.
Du hast wohl "Maple Mini" gemeint ?
.. und ja er soll den 433er und den 868 NanoSignalduino in CC1101-Union ablösen ... ;)
https://wiki.fhem.de/wiki/MapleCUN (https://wiki.fhem.de/wiki/MapleCUN)
und dort:
https://forum.fhem.de/index.php/topic,106278.0.html (https://forum.fhem.de/index.php/topic,106278.0.html)
Grüße,
Jürgen
:-) ich hatte MapleCUN MapleCUX und Maple mini gemeint :-) zuviele Miss Maple's
wie kam ich nur auf LUN ;-)
Aber ist dann mit der 4.x.x Version dann auch zigbee möglich ?
Wenn ich das richtig verstehe unterscheiden sich die Maple nur vom Board was man an an Empfängern draufpacken kann.
Zitat von: laserrichi am 28 April 2020, 14:10:11
1.) Aber ist dann mit der 4.x.x Version dann auch zigbee möglich ?
2.) Wenn ich das richtig verstehe unterscheiden sich die Maple nur vom [Anmerk: Signalduino-] Board, was man an an Empfängern draufpacken kann.
1.) nein, Zigbee ist eine andere Protokoll-Art und funkt auf 2.4 GHz. (Wie etwa Bluetooth oder WLAN)
2.) Im Prinzip ja, unterscheiden sich nur in den Empfangbaren Funkprotokollen. (+ LAN und ggf. auch bald auch WLAN, wie SignalEsp)
Ein kleiner Schritt weiter ...
WLAN-Verbindung aufbauen IP-Adresse erhalten und die Verbindung mit Signalduino in FHEM steht!
Der W600 antwortet auf die "V"-Anfrage des Signalduino-Moduls. Signalduino geht in Status "Opened" :D
Die serielle Schnittstelle funktioniert ebenfalls an UART1 des W600.
Jetzt geht es an die Implementierung der Durchschleif-Logik und wieder zurück zum Client ...
Nach einigen interessanten Nicklichkeiten (Rookie) ein Durchbruch. :)
/Edit: Aber vieleicht muss man das Rad nicht neu erfinden und ser2tcp (https://github.com/pavelrevak/ser2tcp) adaptieren ... :)
Zitat von: laserrichi am 28 April 2020, 14:10:11
:-) ich hatte MapleCUN MapleCUX und Maple mini gemeint :-) zuviele Miss Maple's
Aber ist dann mit der 4.x.x Version dann auch zigbee möglich ?
Hi,
mit den Maple CULs kann man im Prinzip kein Zigbee machen. Aber diese habe zwei frei UARTs (also sowas wie serielle Schnittstellen).
Die Maple-CUL SW hat mit der SDuino Software nichts zu tun.
Wenn du meine Umsetzung vom Maple-CUL nimmst kannst du direkt ein AddOn für Zigbee darauf stecken...
https://github.com/ranseyer/CUN-STM32/tree/master/HW-MAPLE-Large/V4.0
Der Maple-CUl bringt das Zigbee Modul dann an den USB Anschluss oder ans LAN.
Das Thema ist aber hier komplett OT. Weiter ggf hier: https://forum.fhem.de/index.php?topic=97739.new;topicseen#new
Es gibt eine neue Version.
https://github.com/Ralf9/SIGNALDuino/releases/tag/4.1.0-dev200427
Ab dieser Version ist für die bin Files der Bootloader2.0 erforderlich.
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_sduino_Boot20_USB_410dev200427.bin -R
Nun gibt es für die EEPROM Speicherbänke eine Kurzbeschreibung (max 8 Zeichen), diese wird beim bs Befehl mit ausgegeben (siehe Anlage).
Ich habe dazu den CW Befehl erweitert (Adr 0x40 bis 0x47)
Mode 1 - IT+ 17.241 kbps (LaCrosse)
CW404d,4131,425f,4349,4454,452b,4600
oder hinten angehängt
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03,404d,4131,425f,4349,4454,452b,4600
Mode 2 - IT+ 9.579 kbps (LaCrosse)
CW404d,4132,425f,4349,4454,452b,4600
oder hinten angehängt
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03,404d,4132,425f,4349,4454,452b,4600
Ich habe die für FSK notwendigen Registeränderungen aktualisiert:
https://forum.fhem.de/index.php?topic=106594.msg1005067#msg1005067
Gruß Ralf
Hi Ralf9,
also flashen hat gut funktioniert. Auch mit dem BL2 läuft das jetzt gut.
Ich weiss nur nicht so recht wie ich jetzt den Mode2 start.
Wenn ich bank1 erstmal lösche mit e1 und anschließend:
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03
CW404d,4132,425f,4349,4454,452b,4600
mache, passiert nix. Fehlt mir da noch etwas? Oder sollte ich das dann direkt sehen?
Habe neben dem MapleDuino ein TX35-IT liegen.
Ich hänge derzeit nur direkt per USB dran. Gibt es da ein Testmodul für FHEm?
Gruss
"CW404d,4132,425f,4349,4454,452b,4600" ist nur dir Kurzbeschreibung für Mode 2 hier ist der komplette Befehl:
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03,404d,4132,425f,4349,4454,452b,4600
Du müsstest dann so was ähnliches empfangen:
MN;D=9A05922F8180046818480800;N=2;
Für die FSK und EEPROM Speicherbank unterstützung ist eine angepasste und erweiterte Version der 00_SIGNALduino.pm und die signalduino_protocols.pm notwendig:
https://github.com/Ralf9/RFFHEM/issues/4
Gruß Ralf
ich bekokmme das als Antwort auf den genannten CW Befehl:
CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03,404d,4132,425f,4349,4454,452b,4600 ok,N=2,ccmode=3
Sollte da nicht was mit ccmode=2 stehen?
Einen Empfang sehe ich noch nicht.
Gruss
ZitatSollte da nicht was mit ccmode=2 stehen?
Das passt so:
ZitatMode 2 - IT+ 9.579 kbps (LaCrosse) - ccN=2, ccmode=3
Was ergibt ein "get Version"?
Was ergibt ein "get raw bs"?
noch bewege ich mich nicht in FHEM, will das morgen mal in meiner Testumgebung so integrieren.
V:
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1*) - compiled at Apr 29 2020 00:29:05
bs:
Bank__ 0 1 2 3 4 5 6 7 8 9 Radio_ - A*- - - - - - - - N_____ 0 2 - - - - - - - - ccmode 0 3 - - - - - - - - 0 - SlowRF 1 - M2_IT+
Müsste eigentlich passen.
Mich interessiert noch ein
get raw b
und
get raw C99
b:
r=A b=1 N=2 ccmode=3 sync=2DD4 ccconf=21656A88820622F856070018166C436891 boffs=0100
C99:
ccreg 00: 01 2E 46 02 2D D4 FF 00 02 00 00 06 00 21 65 6A ccreg 10: 88 82 06 22 F8 56 07 00 18 16 6C 43 68 91 87 6B ccreg 20: F8 56 11 E9 2A 00 11 41 00 59 7F 3F 88 31 0B
Steht in dem ccconf oben auch die Frequenz mit drin?
ja, da ist die Frequenz mit drin, die Registerwerte werden dann im fhen Modul in die Frequenz und andere Werte umgerechnet.
Sieht soweit alles gut aus.
Bitte mach noch ein
get raw XE
get raw WS3D
Ha das wars. Nach dem XE kamen die Nachrichten.
XE:
rxA=1
WS3D:
cmdStrobeReg 3D chipStatus 1 delay2 1
Wofür stehen diese beiden Befehle?
Jetzt kommen Nachrichten rein, alle 5 Sekunden:
MN;D=9166066A46382351E06891C4;N=2;R=91;
siehe hier
https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921
WS3D:
3D No operation. May be used to get access to the chip status byte.
XE -> enableReceiver
Dies ergibt dann
MN;D=9166066A46382351E06891C4;N=2;R=91;
in fhem:
2020.04.29 21:59:32.440 4 : sduinoD/msg get raw: MN;D=9166066A46382351E06891C4;N=2;R=91;
2020.04.29 21:59:32.440 4 : sduinoD Parse_MN: Found 2-FSK Protocol id 103 -> Lacrosse mode 2
2020.04.29 21:59:32.440 4 : sduinoD LaCrosse_convert: ID=103, addr=5 temp=20.6 channel=1 nohum=106 bat=0 batInserted=128
2020.04.29 21:59:32.440 4 : sduinoD ParseMN: ID=103 dmsg=OK 9 5 129 4 182 106
2020.04.29 21:59:32.441 4 : sduinoD Dispatch: OK 9 5 129 4 182 106, -28.5 dB, dispatch
2020.04.29 21:59:32.476 3 : LaCrosse: Unknown device 05, please define it
Mit einem
set LaCrossePairForSec 30
wird dann das LaCrosse device angelegt
Sieht gut aus. Baue das morgen mal in meine FHEM Testumgebung ein.
Erstmal danke. :-)
Hallo Zusammen,
ich habe jetzt einen funktionierenden Prototyp für eine WLAN-SERIAL-BRIDGE zum Maple-Signalduino in Micropython realisiert.
Allerdings muss jetzt noch ausgiebig getestet werden, um ggf. den Ablauf ggf. noch verfeinern.
Die Parametrierung + Programmierung ist über einen seriellen Adapter (FTDI) relativ einfach.
Sie könnte aber auch über USB an den UART_1 des Maples, in einer Art "Programmiermodus", durchgeschleift werden.
Eine Eigenart der W600-Implementierung des Sockets ist, dass die recv-Methode "blocking" ist und die Übertragung auf
eine Anfrage/Telegramm von FHEM wartet. (Ggf. könnte man das im Modul als Attribut berücksichtigen?)
Non-Blocking habe bisher noch nicht hinbekommen, da die Methode socket.socket_setblocking(0) nicht in diese MP-Version übernommen
bzw. implementiert wurde. (Falls dazu jemand eine Lösungs-Idee hat... ;) )
Leider ist der IST-Zustand von MP und der der Doku leider doch etwas unterschiedlich ...
Die ESP8266/ESP32-Plattform scheint da besser "ausgrüstet" zu sein ...
Der W600 scheint mir aber schon wegen der Größe vorteilhaft zu sein.
Im Moment habe ich die Variante mit dem Managen von mehreren Client-Verbindungen gespart und lasse nur eine TCP-Connection zu.
Das sollte im Normalfall reichen ... ;)
Jetzt baue ich mir noch ein Testsystem dazu auf und probiere das Ganze mit FHEM aus ...
Grüße,
Jürgen
/Edit: durch die Verwendung von Micropython wäre der Code ebenfalls portabel zur ESP8266/ESP32-Hardware !
/Edit2: HowTo (https://github.com/juergs/W600_Tcp_To_Serial_Bridge) auf meiner Github-Wiki-Seite.
Hi, wie angekündigt, habe ich den mapleduino heute mal in mein FHEMtest angebunden.
Funktionierte auch wie angedacht.
Allerdings ist mir dann folgendes aufgefallen: Nach einigen empfangenen Meldungen hört der Empfang auf! generell bekomme ich weiterhin Antworten und kann zB. Version abfragen. Ich empfange erst weitere Meldungen wenn ich erneut ein "XE" sende.
Als Test habe ich hier mein TX35-IT liegen, Signalstärke sollte also auch nicht das Problem sein.
Hat das schonmal jemand so beobachten können?
Stromverbrauch habe ich derzeit mit einem Stamp ca 0.04A bei 5.10V. Sollte also nicht das Problem sein.
Gruss
Wenn der Sensor zu nah am Signalduino liegt?
Zitat von: juergs am 30 April 2020, 16:39:06
Wenn der Sensor zu nah am Signalduino liegt?
Nein, derzeit 10 Meter Entfernung. Hatte ich auch probiert.
Wie gesagt, Empfang hört auf und kann dann mit XE wieder für eine kurze Zeit gestartet werden.
Teilweise werden 20 Nachrichten hintereinander Empfangen, manchmal nur 2.
Abstand der Nachrichten sind denke ich 10 Sekunden.
Hm, wenn mit XE, dann kam vorher ein XQ (receive disable) ?
Wie sieht das Log auf
verbose 5 aus?
ZitatAbstand der Nachrichten sind denke ich 10 Sekunden
Auf 868 MHz?
Ich habe jetzt vorerst wieder aus dem FHEM rausgenommen und beobachte per Serial-Monitor.
Ein XQ kam von mir nicht. In der Ausgabe selbst sehe ich auch nichts.
Ein Debugport mit weiteren Meldungen gib es nicht?
Phänomen ist an mehreren Rechnern, sowohl Intel/Windows, als auch ARM/Linux.
Ich habe jetzt meinen mapleCUL, den ich mir Zeitgleich aufbaue mal in mein FHEMtest eingebunden, ob der stabil läuft, Das wäre dann die selbe (Hardware-)charge vom Maple Mini und den Stamps.
Aber der läuft bisher sehr stabil, jedoch SlowRF, nicht Lacrosse.
Das Log im FHEM hatte übrigens im verbose 5 nichts interessantes vermeldet. Habe ich aber jetzt verworfen, und wie gesagt derzeit nur am SerialMonitor.
Edit: Ja 868MhZ, Lacrosse Mode2. Ist ein TX35-IT Temperatursensor mit neuen Batterien.
Nochmal Edit: aha. Sendebeschränkung? Gibt es da auch eine Prüfung irgendwo?
ZitatEdit: aha. Sendebeschränkung? Gibt es da auch eine Prüfung irgendwo?
Ja genau! Eigenlich nur alle 6 Minuten (10% pro Stunde-Regel), wenn ich mich recht erinnere ...
Du kannst den Mapl-Signalduino auch nur per Serial (Bitrate 115200,8,n,1) steuern.
"V"
"XQ"
"XE"
immer CR oder CR/LF ...
dann sollten die empfangenen Funkpakete im Terminal kommen.
Sollte dann irgendwann mal nichts mehr kommen, liegt es an.... ;D
Die 10% pro Stunde-Regel gibts nur beim Senden, Du empfängst ja nur.
Wenn der Empfang auch im Terminal aufhört dann gib mal folgendes ein:
bA
Antw: switch to radio A
und dann:
V
WS3D
br
Hmmh. Also im Moment verstehe ich es nicht. Im Moment funktioniert es.
Ich hatte den Stick längere Zeit nicht angeschlossen. Jetzt wieder angeschlossen und er empfängt ohne Probleme.
Das einzige was mir aufgefallen ist, dass wenn ich ein "C99" mache, ist alles mit "FF" gefüllt.
Erst mit einem bA1 erscheint das wieder korrekt. Aber trotzdem wird empfangen.
Ich lasse das jetzt mal so laufen und beobachte, ob er wieder irgendwann aufhört.
Das Problem dabei ist, daß ich diesen Fall, daß jemand nur den ersten cc1101 (Radio A) verwendet, bis jetzt noch nicht berücksichtigt habe.
Per default ist normalerweise Radio B selektiert, bei Version ist hinter B ein *
Deshalb fehlt bei Version der *
(R: A1)
Nach einem "bA" (switch to radio A) ist dann Radio A selektiert, in Version steht dann
(R: A1*)
Ich muß da noch eine Abfrage einbauen, daß wenn es Radio B nicht, gibt daß dann Radio A per default selektiert ist.
Oder muss ich auch damit rechnen, daß jemand nur das dritte cc1101 (Radio C) verwendet.
Zitat
Das einzige was mir aufgefallen ist, dass wenn ich ein "C99" mache, ist alles mit "FF" gefüllt.
Die Register abfragen werden immer auf das selektierte Radio gemacht, da hier das nicht vorhandene Radio B selektiert ist, kommt FF zurück
Also er stoppt wieder. Es sind allerdings deutlich mehr Nachrichten empfangen worden.
Trotzdem stoppt er.
Das stimmt, wenn ich starte ist A1 ohne Sternchen, also nicht selektiert.
Ich starte nochmal neu und selektiere zu Anfang direkt mal Radio A.
Mal sehen ob es eine Änderung bringt.
Edit: Stoppt trotzdem.
ich habe zuerst Radio A selektiert. Dann sind 13 Nachrichten gekommen. Dann habe ich 5 Minuten gewartet, ein V und ein XE gemacht und es kamen weitere Nachrichten.
MN;D=97C6136AFA35E7AFF1E5EFFE;N=2;R=236;
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1) - compiled at Apr 29 2020 00:29:05
switch to radio A
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1*) - compiled at Apr 29 2020 00:29:05
MN;D=97C6136AFAFB9EF4F75D3C73;N=2;R=230;
MN;D=97C6136AFACFBF966CD5410D;N=2;R=241;
MN;D=97C6136AFAAF457E5D937F53;N=2;R=243;
MN;D=97C6136AFAEE7F5B68BDDF1F;N=2;R=237;
MN;D=97C6136AFA1D779DFDEA7EC5;N=2;R=234;
MN;D=97C6146A54FA55D77B34F8FF;N=2;R=231;
MN;D=97C6146A54CBF832F77F7B8F;N=2;R=222;
MN;D=97C6146A543DDD7A17EFF9FD;N=2;R=237;
MN;D=97C6146A54B7F767D07CAFB9;N=2;R=242;
MN;D=97C6146A54ED779E6BFF52B3;N=2;R=242;
MN;D=97C6146A54FB775FAEFEAC5F;N=2;R=243;
MN;D=97C6146A547DF3C90754FE9D;N=2;R=240;
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1*) - compiled at Apr 29 2020 00:29:05
rxA=1
MN;D=97C6136AFA3FF3F77DFAEFFC;N=2;R=244;
MN;D=97C6136AFA3FCFDF75FDCFD6;N=2;R=246;
MN;D=97C6136AFA75EEE5F3ED1E3B;N=2;R=246;
MN;D=51113D05471500FBFEDB35DE;N=2;R=221;
MN;D=97C6136AFAEB9FED799F51E5;N=2;R=245;
Anschließend kamen nur noch 7 Nachrichten bis zum erneuten Stop.... und danach nur 9 Nachrichten.
Komisch finde ich, dass ich vorhin als ich den Signalduino nach langem Ausstöpseln lange betreiben konnte, bzw er mehrere Hundert Nachrichten empfangen hat. Und jetzt wieder nur einige wenige.
zur Vervollständigung:
Als Antwort auf bA, V, WS3D, br:
switch to radio A
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1*) - compiled at Apr 29 2020 00:29:05
cmdStrobeReg 3D chipStatus 1 delay2 1
r=A b=1 N=2 ccmode=3 sync=2DD4 ccconf=21656A88820622F856070018166C436891 boffs=0100
Bitte mach mal, wenn er stoppt:
WS3D
C35
br
V
cmdStrobeReg 3D chipStatus 1 delay2 1
C35 = 0D
r=A b=1 N=2 ccmode=3 sync=2DD4 ccconf=21656A88820622F856070018166C436891 boffs=0100
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1*) - compiled at Apr 29 2020 00:29:05
Läuft danach aber nicht wieder an. Erst mit einem XE.
Läuft es mit
WS36
WS34
wieder an?
Ja, mit WS34 empfängt er wieder Nachrichten.
Edit: ... um nach 8 Nachrichten wieder zu stoppen...
Nochmal Edit: Jetzt beim zweiten Starten läuft es schon etwas länger. Ich musste aber erst WS36 und dann WS34 machen, damit es startet.
Hat da jemand eine Idee an was das liegen könnte? @Telekatz? @papa?
Wenn der Empfang stoppt, dann ergibt mit "WS3D" ein chip status von 1 (receive mode)
Ein C35 (MARCSTATE Register) ergibt 0D (RX)
Nach einem strobe command WS34 (Enable RX) funktioniert der Empfang wieder
Was ist denn "Maple_cul_Boot20_USB_410dev200427.bin"? Ist das für das MapleCUL board?
Was muss ich im SerialMonitor eingeben, damit ich SlowRF in Bank 2 speichere?
Dann könnte ich mal probieren, ob es warum auch immer stabiler läuft.
Ja das "Maple_cul_Boot20_USB_410dev200427.bin" ist für den MapleCUL
Per Default wird Bank 0 mit SlowRF initialisiert und dem Radio B zugerordnet.
In Version steht (R: B0*)
Mit
bB2
wird Radio B der Bank 2 zugeordnet:
The bank 2 was not complete initialized, therefore the bank and radio is reseted to sduino defaults (raw e). ccFactoryReset done
ok, also bA2,
ich empfange hier aber nichts, während der mapleCUL einige Nachrichten reinbekommt. auf 868 SlowRF.
bs:
Bank__ 0 1 2 3 4 5 6 7 8 9 Radio_ - - A*- - - - - - - N_____ 0 2 0 - - - - - - - ccmode 0 3 0 - - - - - - - 0 - SlowRF 1 - M2_IT+ 2 - SlowRF
Fehlt da noch was?
SlowRF geht momentan nur mit dem zweiten cc1101 (Radio B)
Hast Du den zweiten cc1101 nicht bestückt?
Ah ok.
Nein bisher ist nur Radio A mit einem 868 bestückt, das 433 Stamp ist noch auf dem Weg aus China.
ich überlege, ob ich ein 433 Modul, also mit Pin, mal übergangsweise dranlöte.
so gehts einfacher
Ja das stimmt. Habe aber schon alles auf der Ranseyer Platine verlötet. Nur eben Radio B fehlt noch.
Ich probiere das morgen mal mit dranzubasteln, so dass Radio A und B verwendet werden.
Ich sage erstmal vielen Dank für die Hilfestellung und die vielen Infos.
Ich hoffe, dass sich das mit dem Lacrosse-Stop noch auflöst.
By the way noch eine Frage: Wirst du zum späteren Zeitpunkt auch die weiteren Seriellen Schnittstellen mit implementieren?
Und: Wird wohl Ser2Net mit dem Maple funktionieren? Da es ja nicht wirklich eine echte Serielle Schnittstelle ist...
Schönen Abend noch. :-)
ZitatWirst du zum späteren Zeitpunkt auch die weiteren Seriellen Schnittstellen mit implementieren?
Ja das durchreichen der seriellen habe ich vor, da werde ich beim programmieren aber Hilfe gebrauchen.
Das durchreichen der seriellen wird nur bei der LAN Version funktionieren
ZitatWird wohl Ser2Net mit dem Maple funktionieren?
Müsste eigentlich funktionieren, einfach mal testen.
Zitat von: Ralf9 am 30 April 2020, 22:42:59
Ja das durchreichen der seriellen habe ich vor, da werde ich beim programmieren aber Hilfe gebrauchen.
Das durchreichen der seriellen wird nur bei der LAN Version funktionieren
Müsste eigentlich funktionieren, einfach mal testen.
Wird leider noch ein weilchen daueren, irgendwie wurde meine USB-Infrastruktur lahmgelegt.
Der Maple wird nicht mehr erkannt ...
Mit der WLAN-Bridge sind noch einige Tests zu machen bevor man das Einsetzen kann.
In der momentanen Konfiguration bauche ich ein Änderung am Perl-Modul.
Die Socket.reccv-Methoe blockiert im Moment.
In Micropython kann man aber über "select" das Empfangen asynchron, sozusagen mit Callback, machen ....
Das muss ich noch kapieren wie das geht ... ;D
@Ralf9
Ich habe nun Deine 0427-Version in Visual-Studio-VisualMicro (Dank an Tim Leek, er hat mir meine Lizenz angepasst :) ) am Laufen... wenn der Upload mit OpenOCD+STLINK noch klappen würde. :(
.. und ich mein Testsystem dann mit einem CC1101 zu Laufen bringe ...
Die Änderungen mit der Übergabe über die serielle Schnittstelle im Sketch würde ich dann implementieren ...
ZitatUploading 'MapleSduino_V27_VS' to 'Generic STM32F1 series' using 'COM12'
Uploader started for board Generic STM32F1 series
Upload method will be: bootloader
Uploading via Bootloader
C:\ProgramData\vmicro\tools\openocd-0.10.0.20200213\bin\openocd.exe -d2 -s "C:\ProgramData\vmicro\tools\openocd-0.10.0.20200213/scripts/" -f "interface/stlink.cfg" -f "target/stm32f1x.cfg" -c "echo -n {****[vMicro]**** Uploading ELF :}" -c "reset_config; telnet_port disabled; program {C:\Users\js\AppData\Local\Temp\VMBuilds\MAPLES~1\STM32_~1\Release/MapleSduino_V27_VS.ino.elf} reset;reset_config;shutdown"
Open On-Chip Debugger 0.10.0+dev-01058-g853a05287 (2020-02-13-16:41)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
debug_level: 2
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
****[vMicro]**** Uploading ELF :Info : clock speed 1000 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
The uploader process failed
Info : Target voltage: 3.563444
Error: init mode failed (unable to connect to the target)
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked
Melde mich wieder, wenn alles lauffähig ist .. ;D
Grüße,
Jürgen
ZitatIn der momentanen Konfiguration bauche ich ein Änderung am Perl-Modul.
Die Socket.reccv-Methoe blockiert im Moment.
In Micropython kann man aber über "select" das Empfangen asynchron, sozusagen mit Callback, machen ....
Das muss ich noch kapieren wie das geht ... ;D
Ist mir nicht klar, welche Richtung blockiert da?
ZitatDie Änderungen mit der Übergabe über die serielle Schnittstelle im Sketch würde ich dann implementieren ...
Das geht doch viel einfacher, Du musst doch nur in der Arduino IDE den USB Support deaktivieren.
Wenn Du die serielle Schnittstelle für die WLAN-Bridge verwendest, wird das USBserial nicht benötigt.
Gruß Ralf
Zitat von: Ralf9 am 01 Mai 2020, 17:51:37
Ist mir nicht klar, welche Richtung blockiert da?
Das geht doch viel einfacher, Du musst doch nur in der Arduino IDE den USB Support deaktivieren.
Wenn Du die serielle Schnittstelle für die WLAN-Bridge verwendest, wird das USBserial nicht benötigt.
Gruß Ralf
1.)
socket.recv() bleibt solange stehen, bis eine Übertragung über WLAN stattfindet.
Dann wird die Serielle Schnittstelle des Targets mittels
readline() abgefragt und Daten sind dann sozusagen im Puffer.
Dann kommt wieder
recv() zur Ausführung und bleibt solange dort stehen, bis eine
weitere WLAN-Übertragung kommt.
Dann erst kann der Pufferinhalt des vorhergehenden seriellen Einlesens an Fhem geschickt werden.
Das ist ein ungünstiges Verhalten, das auch eine gewisse Timing-Komplexität beinhaltet ...
Die Implementierung mit "
set_blocking_mode(False)" scheint nicht zu funktionieren...
Die Lösung wird sein das blockierende Element asynchron zu setzen. Das kann man wohl mittels "
select" machen ..
2.) Momentan komme ich per USB nicht an den Maple ran...
Das muss ich wieder in Ordnung bringen ...
Immerhin funktioniert mein STLINK wieder, bzw. wird erkannt ...
ZitatBeim Start des Geräts USB\VID_0000&PID_0002\5&38e97a59&0&9 ist ein Problem aufgetreten.
Treibername: usb.inf
Klassen-GUID: {36fc9e60-c465-11cf-8056-444553540000}
Dienst:
Untere Filter:
Obere Filter:
Problem: 0x2B
Problemstatus: 0x0
/edit: Wechseln des USB-Port ... :D
ZitatUploading 'MapleSduino_V27_VS' to 'Generic STM32F1 series' using 'COM41'
Uploader started for board Generic STM32F1 series
Upload method will be: bootloader
Uploading via Bootloader
C:\Users\js\AppData\Local\arduino15\packages\STM32\tools\STM32Tools\1.3.2\tools\win\maple_upload.bat COM41 2 1EAF:0003 "C:\Users\js\AppData\Local\Temp\VMBuilds\MAPLES~1\STM32_~1\Release/MapleSduino_V27_VS.ino.bin"
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=1149
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Zitat1.) socket.recv() bleibt solange stehen, bis eine Übertragung über WLAN stattfindet.
Dann wird die Serielle Schnittstelle des Targets mittels readline() abgefragt und Daten sind dann sozusagen im Puffer.
Heisst das, daß Fhem per polling die empfangenen Daten abfragen muss?
Dies wäre timingmässig ein sehr ungünstiges Verhalten
Lässt sich nicht wie beim ESP die serielle in einer Loop abfragen?
if(Serial.available()){
uint8_t len = Serial.available();
uint8_t sbuf[len];
Serial.readBytes(sbuf, len);ZitatMomentan komme ich per USB nicht an den Maple ran...
Hast Du schon den Bootloader neu geflasht? Das Bootloader flashen sollte normal immer funktionieren, auch bei defektem Bootloader
Hallo Ralf9,
die Serielle Abfrage ist nicht das Problem!
Der Code "hängt" zuzusagen in "socket.recv()" fest bis eine Übertragung stattfindet.
Das ist sehr ungünstig und ich muss eine Lösung dafür finden ...
Hi. Also wegen meines Stoppens: ich muss das etwas umbenennen in stottern. Sieht so aus, als ob auch alleine irgendwann wieder anläuft. Habe jetzt über fhem seit gestern Abend geloggt und es sind teilweise stundenlange Aussetzer. Wenn aber das XE abgegeben wird läuft er sofort wieder an. Habe jetzt auch Radio B mit SlowRf dran und da bisher keine Auffälligkeiten.
Ich beobachte Mal weiter.
Könnte auch sowas sein: https://forum.fhem.de/index.php/topic,91740.0.html (https://forum.fhem.de/index.php/topic,91740.0.html)
Ja das kenne ich und habe nach dem Thread ein "gutes" Modul.
Aber ich denke auch an ein Hardware Problem.
Habe aber mehrere davon schon verbaut für Homematic Sensoren und das läuft problemlos.
Zitat von: killah78 am 01 Mai 2020, 18:36:23
Ja das kenne ich und habe nach dem Thread ein "gutes" Modul.
Aber ich denke auch an ein Hardware Problem.
Habe aber mehrere davon schon verbaut für Homematic Sensoren und das läuft problemlos.
Wird schwierig sein, das Problem zu identifizieren ...
Bei mir geht alles erst mal wieder über den Arduino-Compile mit einem CC1101 Modul auf CS1:
? Use one of ?S ? b CE CD CG CR CS CW C eC e P r R S t T V W x XE XQ
V 4.1.0-dev200427 SIGNALduino cc1101 (R: B-*) - compiled at May 1 2020 18:34:51
Bank__ 0 1 2 3 4 5 6 7 8 9 Radio_ - - - - - - - - - - N_____ 0 - - - - - - - - - ccmode 0 - - - - - - - - - 0 - SlowRF
@Ralf, der String wird jeweils in einem Telegramm (SinalESP) pro Buchstabe übergeben...
? Use one of ?S ? b CE CD CG CR CS CW C eC e P r R S t T V W x XE XQ
Hallo Ralf,
Du bist in der Binary verewigt... ;-)
Nach Verwendung des
richtigen Schaltplans (Es lebe die Vereinheitlichung! ;D )
Die CC1101- Belegungen sind Versionsabhängig...
ZitatV
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A0* B- C- D-) - compiled at May 1 2020 18:34:51
bs#
Bank__ 0 1 2 3 4 5 6 7 8 9 Radio_ A*- - - - - - - - - N_____ 0 0 - - - - - - - - ccmode 3 3 - - - - - - - - 1 - M1_IT+
CREA
detect A: Partn=0 Ver=24
bA1..
Bank 1 is already used by radio B
bA0
set r=A b=0 ccmode=3 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0000
WS3D
cmdStrobeReg 3D chipStatus 0 delay2 0
C35
C35 = 01
XE
rxA=1
.MN;D=9946262D55AAAA000091CB8E;R=248;.
.MN;D=9946262D55AAAA00004266BC;R=248;.
.MN;D=9946262E06AAAA000057021B;R=247;.
.MN;D=9946262D55AAAA0000E2E212;R=243;.
.MN;D=9946262E06AAAA000071F58B;R=244;.
.MN;D=CD0C05201AFFFFFFFFFFFFFF;R=224;.
.MN;D=9946262D55AAAA0000D4A550;R=244;.
.MN;D=9946262E06AAAA000097E062;R=246;.
.MN;D=9946262D55AAAA00007CB686;R=248;.
.MN;D=9946262D55AAAA00006A18E6;R=248;.
.MN;D=9946262E06AAAA00006B968E;R=247;.
Ich lasse es jetzt mal länger laufen.
Mir ist bewusst, dass es Mode1 mit LaCrosse ist. https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067 (https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067)
/edit: läuft bei mir ohne Stocken durch ...
Es gibt eine neue Version V 4.1.0-dev200501
https://github.com/Ralf9/SIGNALDuino/releases/tag/4.1.0-dev200501
@killah78
es gibt nun ein ccmode 4, das macht das gleiche wie ccmode 3 hat aber ein anders timing, Du kannst mal testen ob damit der Mode 2 besser funktioniert.
Wenn die Bank selektiert ist, bei Version (R: A1*)
dann bitte dies eingeben:
CSccmode=4
Gruß Ralf
STM32duino bootloader has been updated to resolve some problems with the fastboot bootloader (https://www.stm32duino.com/viewtopic.php?f=59&t=218&sid=2c5642f2d9ddd97dc2b201c9d89bd230)
Zitatby rogerclark » Mon Mar 09, 2020 11:46 pm
Leider:
ZitatI've not updated the GD32 version, as the GD32 variant was removed as an option some time ago due to differences in its functionality from the STM32 and lack of availability of these boards.
Es gibt nun eine neue Version V 4.1.1-dev200503 für die LAN Anbindung
https://github.com/Ralf9/SIGNALDuino/commit/d1ff85c42cde949068411dc415225af8bf821c1e
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_sduino_Boot20_LAN_411dev200503.bin -RMit "
ri " kann die LAN Konfig ausgegeben werden:
z.B.
mac = 00:80:41:34:15:B8
ip = 192.168.0.10
gw = 192.168.0.1
nm = 255.255.255.0Mit "Wi..." kann die ethernet config geändert werden, sie wird erst nach einem Reset wirksam
Wia - address
Wig - gateway
Win - network mask
z.B. Wia192.168.0.100
Die Default Werte sind
IP = 192.168.0.244
Gateway = 192.168.0.1
Netmask = 255.255.255.0
Die DEF in fhem ist damit
192.168.0.244:23Das LAN funktioniert momentan nur mit dem MapleSduino, für den MapleCul ist noch ein patch in der Ethernetlib erforderlich.
Ich musste bei mir in der Arduino IDE das USB und serial deaktivieren (siehe Anlage), sonst ist der Maple Mini ab und zu abgestürzt.
Nachtrag:Ab der Version V4.1.2-dev210522 wird bei der ersten Inbetriebnahme DHCP verwendet.
DHCP wird verwendet, wenn die letzte Stelle der IP-Adresse 0
Durch eine gepatchte Ethernet Lib gibts nun auch LAN Version für MapleCul LAN (MapeCUN)
@killah78
hast Du dies getestet?
Zitat von: Ralf9 am 02 Mai 2020, 00:25:02
Es gibt eine neue Version V 4.1.0-dev200501
https://github.com/Ralf9/SIGNALDuino/releases/tag/4.1.0-dev200501
@killah78
es gibt nun ein ccmode 4, das macht das gleiche wie ccmode 3 hat aber ein anders timing, Du kannst mal testen ob damit der Mode 2 besser funktioniert.
Wenn die Bank selektiert ist, bei Version (R: A1*)
dann bitte dies eingeben:
CSccmode=4
Gruß Ralf
Hi. Ja habe es jetzt 36 lStunden aufen gehabt. Ich habe noch ab und an ca 20 minütige Aussetzer, aber ich würde es als deutlich stabiler bezeichnen. Vorher hatte ich ja Stunden lange Aussetzer, jetzt habe ich in 36 Stunden 5 Aussetzer von ca je 20 min. gefunden. Also deutlich besser, wenn auch nicht ganz perfekt.
Aber hatte das bisher noch niemand anders mit einem Lacrosse Thermometer getestet?
Könnte ich das 433 Radio auf Platz B auch so umbiegen , dass das Lacrosse empfängt? Dann könnte ich die Hardware vielleicht ausschließen.
ZitatKönnte ich das 433 Radio auf Platz B auch so umbiegen , dass das Lacrosse empfängt? Dann könnte ich die Hardware vielleicht ausschließen.
Ja, dies ist kein Problem, dazu darf der Bank 1 (LaCrosse) kein Radio zugeodnet sein. z.B. durch deaktivieren von Radio A mit
CRDADann mit
bB1das Radio B der Bank 1 zuorden
Sehr schön. Funktioniert auf Anhieb, Frequenz scheinbar auch mit gespeichert. Gefällt mir gut.
Seltsam: Das 433er hat einen besseren Rssi.
Muss glaube ich Mal meinen ganzen Krempel testen und Mal aussortieren.
Auf dem "normalen" Signalduino läuft das FSK doch auch, oder? Das könnte ich auch Mal testen.
Ich lass das jetzt über Nacht Mal so laufen, ob das jetzt fehlerfrei empfängt, dann wäre es ja ein Hardwareproblem.
ZitatAuf dem "normalen" Signalduino läuft das FSK doch auch, oder? Das könnte ich auch Mal testen.
Ja, wenn es eine nanocul oder minicul Hardware mit einem 868 MHz cc1101 ist.
z.B. damit
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.4.0-dev200126
ZitatIch musste bei mir in der Arduino IDE das USB und serial deaktivieren (siehe Anlage), sonst ist der Maple Mini ab und zu abgestürzt
Hallo Ralf ,
ich habe das Problem scheinbar ebenfalls. Mit der Version vom 1.5. und früher. Ungefähr einmal am Tag passiert es, dass der Maple disconnected ist. Im Log sehe ich mehrfache Resetversuche die schlussendlich in einem "closed" des Maple münden. USB Reset auf dem Raspi hat nicht geholfen. Der Maple war nicht mehr erreichbar, erst nachdem ich ihn abgezogen und wieder angesteckt habe. Irgendeine Idee wie ich das debuggen kann?
Dein angepasstes SIGNALduino Modul scheint mit den Readings noch ein Problem zu haben, da steht bei mir im Grunde kaum etwas Nachvollziehbares. Falsche Version, falsche Konfiguration. Ich vermute, das ist dem Beta Stadium geschuldet. Sehe ich das richtig?
Seit ich bei der aktuellen Version beim compile der IDE das USB und die serielle deaktiviert habe, hatte ich keine Abstürze mehr.
Werde jetzt auch mal langzeit Tests machen.
Ein reset über USB funktioniert beim Maple Mini anscheinend nicht.
ZitatDein angepasstes SIGNALduino Modul scheint mit den Readings noch ein Problem zu haben, da steht bei mir im Grunde kaum etwas Nachvollziehbares. Falsche Version, falsche Konfiguration.
Bei der Version im reading ist noch ein Fehler.
Das ccconf wird momentan nur in den Internals gespeichert. Die Ansicht der Internals wird nicht automaisch aktualisiert, es muss manuell ein Browser Refresh gemacht werden
Gruß Ralf
Wie gesagt, wenn ich beim Debuggen irgendwie unterstützen kann lass es mich wissen. Ich habe die Arduino 1.8.12 IDE und den MSC Bootloader von Telekatz im Einsatz.
Ganz nebenbei aber nicht unwichtig: Ihr alle die an diesem Projekt arbeitet macht einen echt geilen Job :)
Hallo Reinhard.M,
danke für Dein Angebot. :)
Hallo Zusammen,
nach dem ich nun Einiges (https://medium.com/vaidikkapoor/understanding-non-blocking-i-o-with-python-part-1-ec31a2e2db9b) [ 2 (https://www.studytonight.com/network-programming-in-python/blocking-and-nonblocking-socket-io) ] zur Serial WLAN-Bridge (https://github.com/juergs/W600_Tcp_To_Serial_Bridge/wiki/Introduction-to-Micropython-on-Air602-(W600-family)-WLAN-enabled-module-board) probiert habe, musste ich nun doch die Gegebenheiten des Micropython- Socket-Ports zum W600 so erst mal hinnehmen. :(
Ich habe mehrere "Verfahren" ausprobiert die .recv()-Methode nicht zum Blockieren zu bewegen und hatte keinen Erfolg damit.
"select" (https://steelkiwi.com/blog/working-tcp-sockets/), "polling-select-in-python (https://stackoverflow.com/questions/7459408/i-cant-understand-polling-select-in-python)" und "set_socket_settimeout()" um nur Einige davon zu nennen.
Hinzu kommt noch, dass die Funktion
serial.readline() nicht auf das "CR/LF" des seriellen Empfangstrings wartet ... (/edit:
timeout => nicht implementiert! (https://docs.micropython.org/en/latest/library/machine.UART.html))
Dazu habe ich mir folgende Vorgehsweise als
Lösungsmöglichkeit überlegt:
1.) da Fhem mit der Antwort des Kommandos "V" erkennt, dass ein Signalduino angeschlossen ist, warte ich in einer ersten Schleife auf eine Connection eines TCP-Clients.
Hier wird das Kommando an den Signalduino weitergereicht und die Antwort an den Client 1:1 übertragen. (Die XQ+XE-Kommandos mal vernachlässigt).
2.) Dann wird in eine zweite Schleife eingetreten, die nur die Readings aus dem seriellen Port an den FHEM-Client zurückschickt.
Manko: in der zweiten Schleife kann ich keine Kommandos von FHEM verarbeiten, wie gesagt die Abfrage (recv) blockiert den gesamten Ablauf!
Selbst eine Timer-Tick Lösung wird blockiert....
Als Lösung dafür sehe ich nur, über eine zusätzliche Webseite (Port 80) oder einen Jumper wieder "manuell" zurück in den Kommando-Modus zu schalten, um über WLAN auch von FHEM aus Parametrieren zu können.
Ggf. würde ein Client-Disconnect evtl. auch ausreichen um nach einem neuen Connect immer wieder in den Kommando-Modus zu gelagen ....
Oder ggf. darauf zu verzichten und nur über USB/LAN zu parametrieren ....
Meiner Meinung nach, wird der Signalduino ja nur "einmal" (initial) eingestellt, dann läuft er eigenlich nur noch im Erfassungsmodus weiter und schickt fleißig seine Readings an FHEM.
Mit der Serial-Bridge-Variante wird nur der weitere serielle Port (RX1/TX1) des Maples beaufschlagt.
In der "loop"-Schleife würde ich nur ein
Serial1Event() hinzufügen und die Ausgabe der Readins auch zusätzlich an Serial_1 senden.
Alle anderen Interfaces werden ja nicht beeinträchtigt und bleiben weiterhin erhalten!
- Hat jemand eine bessere Idee?
- Habe ich bestimmte Konstellationen nicht beachtet?
(Aktives Umschalten der CC1101-Receiver?)
[/list]
Grüße,
Jürgen
Da der Code weitestgehend portabel ist, könnte man das auch mit dem ES8266 (https://docs.micropython.org/en/latest/esp8266/quickref.html)/ESP32 betreiben.
Der W600 ist aber wegen seiner "Größe" schon attraktiver .. ;D
Anmerkung zu esp-link (https://github.com/jeelabs/esp-link)
ZitatThe connections on port 23 and 2323 have a 5 minute inactivity timeout. This is standard with Espressif's SDK and esp-link does not change it. The reason is that due to memory limitations only a few connections can be open (4 per port) and it's easy for connections to get "lost" staying open forever, for example, due to wifi disconnects. That could easily make it impossible to connect to esp-link due to connection exhaustion. Something smarter is most likely possible...
/Edit: Frage: Wie ist eigentlich die Chip-Antenne korrekt zu verdrahten?
Beispiel:
ZitatServer Started on Port: 23
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> New Client: 192.168.178.23
XQ
V
V
XQ
> Client closed conection.
> New Client: 192.168.178.23
XQ
V
V
V
> Client closed conection.
> New Client: 192.168.178.23
XQ
V
V
V
> Client closed conection.
> New Client: 192.168.178.23
S: V 3.3.1 SIGNALduino cc1101 (chip CC1101) - compiled at Dec 3 2019 19:40:46
XQ
V
S: V 3.3.1 SIGNALduino cc1101 (chip CC1101) - compiled at Dec 3 2019 19:40:46
XE
P
Erreicht ein "V" keine Reaktion wird die Connection abgebrochen und 3 mal ein Wiederholungsversuch gestartet.
Der dritte Versuch hat geklappt und der State wechselt auf "opened".
Fhem sendet dann ein "P" als Ping.
Im schlimmsten Fall wird doch eine Antwort "OK" als isAlive erwartet .... :(
Leider ja, bei einem nicht beantwortetem "P"
geht das Signalduino-Device in "STATE closed"... :(
ZitatMeiner Meinung nach, wird der Signalduino ja nur "einmal" (initial) eingestellt, dann läuft er eigenlich nur noch im Erfassungsmodus weiter und schickt fleißig seine Readings an FHEM.
Die Senderichtung muss auch funktionieren
z.B. für den Ping Befehl
und der Sduino muß auch z.B. an Steckdosen einen Schaltbefehl senden können.
Hast Du wegen der blockierenden .recv()-Methode mal bei dem Entwickler nachgefragt.
Gibts für den W600 keinen C Compiler?
Gruß Ralf
Hallo Ralf9,
ZitatSduino muß auch z.B. an Steckdosen einen Schaltbefehl senden können.
Hast Du wegen der blockierenden .recv()-Methode mal bei dem Entwickler nachgefragt.
Gibts für den W600 keinen C Compiler?
* An Steckdosen-Sendebefehle hatte ich nicht gedacht ... :(
* Ich schaue mal im MP-Forum vorbei. Mit den bisher gefundenen Beispielen kam ich nicht zurecht oder funktionierten einfach nicht ...
* C-Compile: Ist ja ein M3-Core, sollte der gleiche wie der des STM2F103 sein ....
* Schaue mir das dann in der Arduino-IDE in C/C++ noch mal an ... , den Upload der IDE habe ich schon realisiert.
Deine Implementierung mit der Arduino-Lib für den WIZ5500 schaue ich mir auch mal an.
Schade hätte gepasst ...
Jürgen
Hallo Ralf9,
welche Ethernet-Lib benutzt Du?
https://github.com/adafruit/Ethernet2 (https://github.com/adafruit/Ethernet2)
oder diese:
https://www.arduino.cc/en/Reference/Ethernet ?
Diese
https://www.arduino.cc/en/Reference/Ethernet
es müsste diese sein
https://github.com/arduino-libraries/Ethernet
Ah ok, hatte es gerade auch gefunden ;-)
Komischerweise ist die EthernetServer read()-Funktion nicht in der offiziellen Doku "erwähnt" :
https://forum.arduino.cc/index.php?topic=123756.msg930967#msg930967 (https://forum.arduino.cc/index.php?topic=123756.msg930967#msg930967)
Die scheint nicht blockierend zu sein ...
/edit: habe die Frage im MP-Forum eingestellt, muss aber noch "approoved" werden ...
Die W600- Implenmentierung des WiFi-Servers für Arduino:
https://github.com/juergs/divers_use/blob/master/Local_Arduino15_packages_w600_hardware_w600_0.2.6_libraries_WiFiServer.png (https://github.com/juergs/divers_use/blob/master/Local_Arduino15_packages_w600_hardware_w600_0.2.6_libraries_WiFiServer.png)
beinhaltet keine read-Funktion.
In den Samples zur Lib ist nur ein Client-beispiel aufgenommen, aber kein Server !
Library-Examples:
ZitatC:.
├───Client
├───LED-AP
├───NTP
├───NTPClient
├───Oneshot-Key
└───Sta
Uh!.
/edit: die Methoden sind im ClientContext versteckt. :)
Ok, programmiere das mal in Arduino aus ....
Es gibt dafür schon was, einfach mal nach "WiFiTelnetToSerial" suchen.
Hallo Ralf),
ja, gut gemeint:
#include <ESP8266WiFi.h>aber evtl. doch zu gebrauchen:
https://github.com/esp8266/Arduino/blob/master/tests/host/common/ClientContextSocket.cpp (https://github.com/esp8266/Arduino/blob/master/tests/host/common/ClientContextSocket.cpp)
ESP8266:
ZitatServer Class
Methods documented for the Server Class in Arduino
WiFiServer()
begin()
available()
write()
print()
println()
Fällt da was auf?
:D
Suche morgen erst mal ein Beispiel....
In den ESP-Samples: https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/examples/WiFiHTTPSServer/WiFiHTTPSServer.ino
Um das zu Portieren : https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/src/WiFiServer.cpp
Wenn ich Glück habe funktioniert es einfach im W600: WiFiTelnetToSerial ;) ::)
Hallo,
die Anfrage im MP-Forum wurde quasi sofort kompetent beantwortet!
Respekt!
D.h. das Blocking-Thema ist ad acta zu legen, es funktoniert einfach. (Wenn man weiß, wie es geht...)! :D
Grüße,
Jürgen
Kaum macht man es richtig, schon geht es !
Ist noch Feintuning angesagt, insbesondere ein close() une ein reconnect() handlen.
Geht jetzt aber vom Ablauf her schon im "Trockentest" direkt aus FHEM.
Als nächstes werde ich den Signalduino dranhängen und den Gegenpart implementieren, dann weiter Testen.... ;-)
W600_serial_tcp_bridge.py (https://github.com/juergs/W600_Tcp_To_Serial_Bridge/blob/master/W600_serial_tcp_bridge.py)
ZitatKaum macht man es richtig, schon geht es !
Da bist Du jetzt ein großen Schritt vorwärts gekommen.
ZitatIst noch Feintuning angesagt, insbesondere ein close() une ein reconnect() handlen.
Im 00_Signalduino Modul gibts bereits eine Keep Alive Routine, wenn eine Minute nichts empfangen wird, dann wird eine Ping (P) Befehl gesendet.
Die sporatischen Abstürze bei der LAN-Version sind wahrscheinlich recht schwer zu finden.
Vorgestern lief es recht stabil, ich hatte während 11 Stunden keinen Absturz.
Gestern hatte ich schon nach weniger als eine halbe Stunde einen Absturz.
Heute Abend hatte ich erst nach ca 3 Stunden einen Absturz.
Ich versuche gerade herauszufinden, ob es davon abhängt, ob ich nur SlowRF oder nur FSK oder ob ich SlowRF und FSK empfange.
Können die Abstürze auch mit Interrupts zusammenhängen?
Ich will versuchen die Abstürze mit LEDs einzugrenzen. Z.B. indem ich eine LED vor dem Ethernet Print einschalte und nach der Ausgabe wieder ausschalte.
Kann ich an RX2 und TX2 auch LEDs anschließen, wenn ich sie als Ausgang konfiguriere?
Ich habe noch ein kleines Verständnis Problem mit "else if"
Momentan habe ich es so:
if (ccmode == 0) {
else if (ccmode < 15) {
Die Bedingung 1 soll bei ccmode == 0 ausgeführt werden.
Die Bedingung 2 soll bei ccmode 1 bis 14 ausgeführt werden.
Oder ist es so besser?
if (ccmode == 0) {
else if (ccmode > 0 && ccmode < 15) {
Gruß Ralf
Hallo Ralf,
ZitatIch habe noch ein kleines Verständnis Problem mit "else if"
Momentan habe ich es so:
Code: [Auswählen]
if (ccmode == 0) {
else if (ccmode < 15) {
Die Bedingung 1 soll bei ccmode == 0 ausgeführt werden.
Die Bedingung 2 soll bei ccmode 1 bis 14 ausgeführt werden.
Oder ist es so besser?
Code: [Auswählen]
if (ccmode == 0) {
else if (ccmode > 0 && ccmode < 15) {
Das lässt sich doch einfach in 2 hintereinandergelegten If's abfragen ...
if (ccmode == 0)
{
tu_dies;
}
if ccmode > 0 && ccmode <15
{
tu_das ;
}
Ist glaube ich verständlicher, als solche Schachtelungen (KISS-Prinzip) ...
Ein switch war glaube ich langsamer in der AAusführung als die If's:
switch (ccmode)
{
case 0:
tu_dies;
break;
case 0:
case 1:
..
case 14:
tu_das;
}
Habe den WIZNet-code nur kurz überflogen und leider noch nicht ausprobieren können.
Aber als nächstes kann ich Dich ggf. beim Fehlersuchen unterstützen, wenn die Sensor-Protokoll Bedingungen
bei mir auch irgendwie reproduzierbar sind.
Kannst Du die Testbedingungen mal formulieren?
Also, welches Protokoll, wie Einstellen, was wird erwartet ...
Man könnte auch ein OLED SS1306, ein TFT-2,4 '' oder ein TFT-7750-Display an den I2C-Bus hängen und den Debug-Output dort als Terminal ausgeben ....
Glaube, das werde ich sowieso tun müssen, wenn ich über die Serial1 andocke ... ;)
Jürgen
Version 1 reicht bei if/else Konstrukten bereits. Bei case kann sowas zu Fehlern führen.
Mich interessiert bei der LAN Version folgende Test:
a.) nur Radio A für FSK Empfang (z.B. LaCrosse) aktiv
b.) nur Radio B für SlowRF (ASK) aktiv
c.) Radio A und B aktiv für SlowRF und FSK Empfang
Gibt es bei allen 3 Varianten Abstürze?
Ich habe auf alle Fälle Abstürze im Fall c). Die anderen beiden kann ich momentan nicht testen.
Nachtrag:
Die Abstürze kommen bei mir relativ regelmäßig ungefähr alle 24 Stunden. Ich würde einen überlaufenden Counter in Erwägung ziehen.
können überlaufende Counter einen Absturz verursachen?
Bei einem überlaufenden Puffer oder Array kann ich es mir vorstellen.
Ich habe den Eindruck, wenn mehr Nachrichten ausgegeben werden, daß dann der Absturz früher kommt.
Du hast Recht, Counter macht lediglich einen Wrap Around. Wird allerdings ein Counter für einen Pointer auf einen Buffer verwendet und wird dieser Pointer nicht ab 0 sondern ab 1 verwendet kann das schon merkwürdige Effekte erzeugen wenn dann doch plötzlich eine 0 auftaucht. War auch nur so eine Idee.
Was ich aber bei mir beobachte ist eine Wiederholung der Abstürze etwa alle 22 bis 25 Stunden (Ungefähr!). Seit mehreren Tagen. Irgendwo scheint zumindest ein Zähler im Spiel zu sein. Messages sind jedenfalls nicht auffällig mehr oder weniger gewesen. Ich werde weiter genau hinschauen.
Hallo Ralf9,
hast Du mal mit den Compiler-Optimierungen variiert?
https://gcc.gnu.org/onlinedocs/gnat_ugn/Optimization-Levels.html
Zitathast Du mal mit den Compiler-Optimierungen variiert?
Nein habe ich noch nicht gemacht. Meinst Du die in der Anlage?
Was schlägst Du vor?
Ja, genau die .... "Smallest" ist evtl. zu drastisch ...
Ich habe gerade die Fast (O1) Variante compiliert und geladen. Mal sehen was passiert. Diesmal hatte sich der Maple nach 9 Stunden verabschiedet.
Hallo, habe gestern meine Basis-Version als Startpunkt in mein Github (https://github.com/juergs/MapleSduino_SER2WLAN)-Repository gestellt.
Sie enthält eine Vereinheitlichung und Anpassung des gesamten Codes auf eine für mich passende Form,
von der ich meine Änderungen für das WLAN-Interface in entsprechende
Branches eintragen werde.
Die
Master-Version ist von Ralfs Version
SIGNALDuino-4.1.0-dev200427 abgeleitet und beinhaltet noch keine Änderungen bezüglich WLAN-Interface!
Der Compile lief in der Arduino IDE unter Windows 10 durch und läuft bei mir in Ranseyers Platinen-Version:
MapleSDuino V0.2 mit zwei 868Mhz-CC1101 erfolgreich.
Grüße,
Jürgen
/edit: zum Anschliessen eines TFT-Displays (ST7735 (https://de.aliexpress.com/i/32983527714.html?spm=a2g0x.12057483.0.0.64d4ade9kvZixn), 1,8'' 128x160 Pixel) werde ich diese Anschlüsse nutzen:
GND | GND |
3V3 | VCC |
SCL | TX3/SCL = Pin 1 |
SDA | RX3/SDA = Pin 0 |
RES | NRESET = Pin RESET |
DC | CC_IN_3 = Pin 14 |
CS | CC_CS3 = Pin 3 |
BL | (Backlight) Brücke mit 3V3 |
Zitat von: Reinhard.M am 07 Mai 2020, 08:30:47
Ich habe gerade die Fast (O1) Variante compiliert und geladen. Mal sehen was passiert. Diesmal hatte sich der Maple nach 9 Stunden verabschiedet.
Mit LAN oder ohne über USB?
ZitatMit LAN oder ohne über USB?
USB läuft stabil, da konnte ich bis jetzt noch keine Abstürze beobachten.
Zitat von: killah78 am 03 Mai 2020, 21:35:36
Hi. Ja habe es jetzt 36 lStunden aufen gehabt. Ich habe noch ab und an ca 20 minütige Aussetzer, aber ich würde es als deutlich stabiler bezeichnen. Vorher hatte ich ja Stunden lange Aussetzer, jetzt habe ich in 36 Stunden 5 Aussetzer von ca je 20 min. gefunden. Also deutlich besser, wenn auch nicht ganz perfekt.
Ich teste gerade mit USB den Empfang von Mode1 LaCrosse.
Dazu schreibe ich mit "event-min-interval .*:60" jede Minute den state ins Filelog.
Damit das state auch ins reading geschrieben wird, wenn sich der state nicht ändert, musste ich in der 36_LaCrosse.pm was auskommentieren:
readingsBulkUpdate($rhash, "state", $state); # if( Value($rname) ne $state );
Die Idee mit dem TFT war ja nicht schlecht,
bis auf das meine funktionierenden Libs in der "Maple"-Konfiguration laufen und nicht in der Core-Variante.
Weil die sich nicht an die STMDuino <SPI.h> Funktionen gehalten bzw. auf die Kompatibilität verzichtet haben ....
Mal schauen, ob sich das für das doch noch einfach für ST7735 lösen lässt, oder .... das erst mal von der Todo-Liste streiche ... :(
Ich habe ohne LAN, nur mit USB getestet. Hat aber nichts gebracht, der Maple hing nach 7 Stunden wieder fest.
Könntest Du noch die Firmware-Version, die du benutzt angeben?
Diese: https://github.com/Ralf9/SIGNALDuino/releases/tag/4.1.0-dev200501 (https://github.com/Ralf9/SIGNALDuino/releases/tag/4.1.0-dev200501) ?
Die 4.1 vom 1.5.
Sorry! Muss mich korrigieren
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 7 2020 08:18:12
Und, fals wichtig, ich compiliere für den CUL
Dann probier mal die Vorgängerversion dagegen:
https://github.com/Ralf9/SIGNALDuino/releases/tag/4.1.0-dev200427 (https://github.com/Ralf9/SIGNALDuino/releases/tag/4.1.0-dev200427)
Dann können wir ausschließen dass ggf. ein Fehler mit dem LAN-Anteil "neu" hinzugekommen ist ...
Wie sieht es denn mit dem eingebauten aber deaktivierten Watchdog aus? Was setzt der alles zurück? Wäre das ein Test wert?
ZitatIch teste gerade mit USB den Empfang von Mode1 LaCrosse.
Dazu schreibe ich mit "event-min-interval .*:60" jede Minute den state ins Filelog.
Hatte eine uptime von ca 8 Stunden, es gab keine Aussetzer,ins Filelog ist jede Minute ein Wert geschrieben worden.
ZitatWie sieht es denn mit dem eingebauten aber deaktivierten Watchdog aus? Was setzt der alles zurück? Wäre das ein Test wert?
Damit habe ich mich noch nicht befasst,
Zitat von: Ralf9 am 08 Mai 2020, 00:51:20Hatte eine uptime von ca 8 Stunden, es gab keine Aussetzer,ins Filelog ist jede Minute ein Wert geschrieben worden.
Damit habe ich mich noch nicht befasst,
Mit welcher Version? Dann würde ich die ebenfalls testen. Meiner hat sich heute morgen um 5 Uhr etwa wieder verabschiedet. Ansonsten nehme ich den Watchdog in Betrieb.
ZitatMit welcher Version? Dann würde ich die ebenfalls testen. Meiner hat sich heute morgen um 5 Uhr etwa wieder verabschiedet.
Hast Du auch das bin File von mir getestet oder nur selbst compielert?
ZitatHi. Ja habe es jetzt 36 lStunden aufen gehabt. Ich habe noch ab und an ca 20 minütige Aussetzer, aber ich würde es als deutlich stabiler bezeichnen. Vorher hatte ich ja Stunden lange Aussetzer, jetzt habe ich in 36 Stunden 5 Aussetzer von ca je 20 min. gefunden. Also deutlich besser, wenn auch nicht ganz perfekt.
@killah78
Wie lange hattest Du den MapleSduino in Betrieb? Hattest Du dabei Abstürze?
Welche Werte hast Du beobachtet, nur den state oder auch andere Werte? Beim LaCosse Modul wird der state nur bei einer Änderung ins Reading geschrieben.
Gruß Ralf
Zitat von: Ralf9 am 08 Mai 2020, 07:45:07
Hast Du auch das bin File von mir getestet oder nur selbst compielert?
Momentan habe ich mein selbst compiliertes File im Einsatz. Hatte es bis gestern mit deinen Einstellungen hier aus dem Forum compiliert, gestern habe ich den Compiler auf -O1 umgestellt. Ergebnis ist aber das gleiche. Kann auch mal dein Compilat laden, das vom 27.4.?
ZitatKann auch mal dein Compilat laden, das vom 27.4.?
Ja, diese ist auch ok. Ich möchte ausschließen, daß die Arduino IDE Version einen Einfluss hat. Ich habe die 1.8.10
Maple_cul_Boot20_USB_410dev200427.bin erledigt:
V 4.1.0-dev200427 SIGNALduino cc1101 (R: A1 B0*) - compiled at Apr 29 2020 00:33:48
Mal sehen wie sich das Teil verhält.
Zitat von: Ralf9 am 08 Mai 2020, 07:45:07
@killah78
Wie lange hattest Du den MapleSduino in Betrieb? Hattest Du dabei Abstürze?
Welche Werte hast Du beobachtet, nur den state oder auch andere Werte? Beim LaCosse Modul wird der state nur bei einer Änderung ins Reading geschrieben.
Gruß Ralf
Das waren einige Tage. Im Moment habe ich den nanoSduino wieder im Test. Aber ich switche mal wieder auf den Maple. Wie äußern sich denn diese Abstürze? Ich habe nur diese "Aussetzer" beobachtet. Zum Testen logge ich alle empfangenen Daten (nicht nur jede Minute). Und ich hatte auch den Eindruck, dass das state Reading immer aktualisiert wird. Ohne dass ich in LaCrosse.pm irgendwas geänder hatte. Daneben gibts noch Temperature und Humidity.
Zitat von: killah78 am 08 Mai 2020, 10:41:17
Das waren einige Tage. Im Moment habe ich den nanoSduino wieder im Test. Aber ich switche mal wieder auf den Maple. Wie äußern sich denn diese Abstürze? Ich habe nur diese "Aussetzer" beobachtet. Zum Testen logge ich alle empfangenen Daten (nicht nur jede Minute). Und ich hatte auch den Eindruck, dass das state Reading immer aktualisiert wird. Ohne dass ich in LaCrosse.pm irgendwas geänder hatte. Daneben gibts noch Temperature und Humidity.
Bei mir hängt sich der Maple schlicht auf. Kein LED ping und nicht mehr über USB erreichbar. Ich habe SlowRF und LaCross Mode 1 gleichzeitig im Einsatz.
Also state aktualisiert tatsächlich nicht bei gleichem Wert, die anderen Readings aber schon. Ist mir bisher nicht aufgefallen.
Ich habe jetzt Radio A auf Lacrosse Mode2 und B auf SlowRF. Ich lasse mal so laufen und gucke was passiert.
Obwohl, die Displays die gleiche Bezeichnung tragen, unterscheiden sie sich doch in "kleinen" Details. ;)
Aber immerhin: ein zweiter Maple mit TFT am MapleSDUINO sollte für tiefer gehende Debugzwecke mit dem Text-Terminal reichen. ;)
Leider verträgt sich die Lib nicht mit dem STM32-core, dann wäre der Umweg über eine Serielle (UART_3) nicht unbedingt erforderlich ...
Mein MapleSDuino war heute morgen ebenfalls im Nirwana und musste ihn resetten.... :(
Dann werde ich mich um die TFT-Lib-Korrekturen kümmern und diese "Variante" einpflanzen" ...
Jürgen
/edit: Das ist eine 7735-Lib-Tüftelei, da es unterschiedlich Versionen gibt, mit unterschiedlichen Befehls-Umfängen !!! :o
Noch nicht 100%ig perfekt aber: geht so ... ;)
Angepasster code und Libraries zu den Gegebenheiten des Displays, welches ich verwende ... (!) :o >:(
(billig != gut, z.B. ist bei einem Display ein Stempel auf der Unterseite des Displayglases!)
https://github.com/juergs/Maple_TFT_ST7735_TextTerminal/blob/master/README.md (https://github.com/juergs/Maple_TFT_ST7735_TextTerminal/blob/master/README.md)
Benutze diese Lib-Variante: Adafruit_ILI9341_STM für den STM32F10x und nicht diese: Adafruit_ST7735_and_ST7789_Library, da sie von Adafruit_SPITFT erbt, leider mit viel zu wenig Funktionalität!
Hallo Ralf,
ich habe hier einen Kandidaten mit dem gepatchten Bootloader und der dev200501 Firmware, der den initialen USB Check nicht besteht:
opened -> no SIGNALduino found -> closed
2020.05.08 15:14:16 3: Opening MapleMini device /dev/ttyACM0
2020.05.08 15:14:16 3: Setting MapleMini serial parameters to 115200,8,N,1
2020.05.08 15:14:16 1: MapleMini: DoInit, /dev/ttyACM0@115200
2020.05.08 15:14:16 3: MapleMini device opened
2020.05.08 15:14:16 3: MapleMini: Attr, setting Verbose to: 5
2020.05.08 15:14:16 3: MapleMini: getAttrDevelopment, IdList ### Attribute development is in this version ignored ###
2020.05.08 15:14:16 3: MapleMini: IdList, attr whitelist disabled or not defined (all IDs are enabled, except blacklisted and instable IDs):
2020.05.08 15:14:16 3: MapleMini: IdList, MS 0 0.1 0.2 0.3 0.4 0.5 1 3 3.1 4 6 7 13 13.2 14 15 17 20 23 25 33 33.1 33.2 35 41 49 51 53 54.1 55 65 68 74.1 87 88 90 91.1 93
2020.05.08 15:14:16 3: MapleMini: IdList, MU 8 9 13.1 16 17.1 19 21 22 24 26 27 28 29 30 31 32 34 36 37 38 39 40 42 44 44.1 45 46 48 49.1 49.2 50 54 56 59 60 61 62 64 66 67 69 70 71 72 73 74 76 79 80 81 83 84 85 86 89 91 92 94 95 97
2020.05.08 15:14:16 3: MapleMini: IdList, MC 10 11 12 18 43 47 52 57 58 96
2020.05.08 15:14:16 4: MapleMini: IdList, development skipped = 2 5 63 72.1 75 77 82
2020.05.08 15:14:16 3: MapleMini: IdList, development protocol is active (to activate dispatch to not finshed logical module, enable desired protocol via whitelistIDs) = 2 72.1 82
2020.05.08 15:14:17 3: MapleMini: SimpleWrite_XQ, disable receiver (XQ)
2020.05.08 15:14:17 5: MapleMini: SimpleWrite, XQ
2020.05.08 15:14:18 3: MapleMini: StartInit, get version, retry = 0
2020.05.08 15:14:18 5: MapleMini: SimpleWrite, V
2020.05.08 15:14:28 5: MapleMini: CheckVersionResp, called without msg
2020.05.08 15:14:28 1: MapleMini: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.05.08 15:14:28 3: MapleMini: StartInit, get version, retry = 1
2020.05.08 15:14:28 5: MapleMini: SimpleWrite, V
2020.05.08 15:14:38 5: MapleMini: CheckVersionResp, called without msg
2020.05.08 15:14:38 1: MapleMini: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.05.08 15:14:38 3: MapleMini: StartInit, get version, retry = 2
2020.05.08 15:14:38 5: MapleMini: SimpleWrite, V
2020.05.08 15:14:48 5: MapleMini: CheckVersionResp, called without msg
2020.05.08 15:14:48 1: MapleMini: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.05.08 15:14:48 3: MapleMini: StartInit, get version, retry = 3
2020.05.08 15:14:48 2: MapleMini: StartInit, retry count reached. Reset
2020.05.08 15:14:48 3: MapleMini: ResetDevice,
2020.05.08 15:15:18 3: Opening MapleMini device /dev/ttyACM0
2020.05.08 15:15:18 3: Setting MapleMini serial parameters to 115200,8,N,1
2020.05.08 15:15:18 1: MapleMini: DoInit, /dev/ttyACM0@115200
2020.05.08 15:15:18 3: MapleMini device opened
2020.05.08 15:15:19 3: MapleMini: SimpleWrite_XQ, disable receiver (XQ)
2020.05.08 15:15:19 5: MapleMini: SimpleWrite, XQ
2020.05.08 15:15:20 3: MapleMini: StartInit, get version, retry = 0
2020.05.08 15:15:20 5: MapleMini: SimpleWrite, V
2020.05.08 15:15:30 5: MapleMini: CheckVersionResp, called without msg
2020.05.08 15:15:30 1: MapleMini: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.05.08 15:15:30 3: MapleMini: StartInit, get version, retry = 1
2020.05.08 15:15:30 5: MapleMini: SimpleWrite, V
2020.05.08 15:15:40 5: MapleMini: CheckVersionResp, called without msg
2020.05.08 15:15:40 1: MapleMini: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.05.08 15:15:40 3: MapleMini: StartInit, get version, retry = 2
2020.05.08 15:15:40 5: MapleMini: SimpleWrite, V
2020.05.08 15:15:50 5: MapleMini: CheckVersionResp, called without msg
2020.05.08 15:15:50 1: MapleMini: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.05.08 15:15:50 3: MapleMini: StartInit, get version, retry = 3
2020.05.08 15:15:50 2: MapleMini: StartInit, init retry count reached. Closed
2020.05.08 15:15:50 2: MapleMini: CloseDevice, closed
Mit dem gepatchten Bootloader und a-culfw hingegen verrichtet er wie gewohnt seine Dienste als CUL.
ich hab das hier gefunden,
ZitatUtility to send the reset sequence on RTS and DTR and chars
which resets the libmaple and causes the bootloader to be run
https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/tools/linux64/src/upload-reset/upload-reset.c
Dies müsste ins 00_Signalduino Modul eingebaut werden, ich kann aber nicht abschätzen ob dies machbar ist.
Hallo Locutus,
ist Dein "Kandidat" ein original Maple oder ein MapleCUX?
Die Binary von Ralf9 oder selbst compiliert, wie upgeloaded?
Ist /dev/ttyACM0 die richtige Schnittstelle?
Bootloader lässt sich ja Testen: ein einfaches Serial-Sample hochzuladen, bzw. läuft dann mit einer Seriellen?
Mit diesem Befehl lässt sich der Maple Mini reseten
./upload-reset /dev/ttyACM0 750
https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/tools
Wenn ich den upload-reset im 00_Signalduino Modul in der Sub SIGNALduino_ResetDevice einbaue, sollte sich der Maple Mini, so wie es auch beim nano funktioniert, sich beim einem Absturz selber reseten.
Ich teste dazu, so wie's auch beim avrdude gemacht wird, ob es das File upload-reset gibt
my $avrdudefound=0;
my $tool_name = "avrdude";
for my $path ( split /:/, $ENV{PATH} ) {
if ( -f "$path/$tool_name" && -x _ ) {
$avrdudefound=1;
last;
}
}
Damit es funktioniert muss dann die "upload-reset" dann in ein Verzeichnis der PATH Veriable kopieren.
Gruß Ralf
Zitat von: Ralf9 am 08 Mai 2020, 09:17:27
Ja, diese ist auch ok. Ich möchte ausschließen, daß die Arduino IDE Version einen Einfluss hat. Ich habe die 1.8.10
Halo Ralf,
auch mit dem 1.8.10 Binary hängt sich der Maple auf. Die LED blinkt nicht mehr und das USB-Interface ist disconnected. Hier hilft auch kein Reset von Seiten des FHEM. Ich werde heute mal versuchen den Watchdog in Betrieb zu nehmen.
ZitatHier hilft auch kein Reset von Seiten des FHEM
Der jetzige Reset funktioniert bem Maple Mini nicht, wenn ich das "upload-reset" ins 00_Signalduino Modul einbaue, sollte der Reset funktionieren.
Zitat von: juergs am 08 Mai 2020, 23:15:05
ist Dein "Kandidat" ein original Maple oder ein MapleCUX?
Der Kandidat ist ohne Netzwerkanbindung.
ZitatDie Binary von Ralf9 oder selbst compiliert, wie upgeloaded?
dev200501.bin aus dem GitHub Repo.
ZitatIst /dev/ttyACM0 die richtige Schnittstelle?
Definitv ja!
ls -l /dev/ttyACM0
crw-rw----+ 1 root dialout 166, 0 May 9 09:15 /dev/ttyACM0Was mich allerdings wundert, ist das hier:
lsusb
Bus 001 Device 006: ID 0483:5740 STMicroelectronics Virtual COM Port
Sollte das nicht so aussehen?
Bus 001 Device 007: ID 1eaf:0003ZitatBootloader lässt sich ja Testen: ein einfaches Serial-Sample hochzuladen, bzw. läuft dann mit einer Seriellen?
Die serielle Kommunikation mit a-culfw ist nicht beeinträchtigt.
Präziser:
ZitatDer Kandidat ist ohne Netzwerkanbindung.
Frage deshalb, ob der "Kandidat" die
DICOVER (https://forum.fhem.de/index.php/topic,106278.msg1044375.html#msg1044375)-Funktionalität (USB-Reenumeration) beherrscht, oder nicht.
Bei Roger war auch mal von der falschen Quarzfrequenz die Rede ...
ZitatDie serielle Kommunikation mit a-culfw ist nicht beeinträchtigt.
aculw mit dem
gleichen Bootloader?
Das Verhalten hatte ich auch schon mal und zwar mit dem falschen Bootloader, der nicht gepatcht war ...
Unter Windows das USBTreeView-Tool (https://www.uwe-sieber.de/deutsch.html) oder den Output dmesg.
Um zu sehen "was" connected ist ...
Verwendest Du den Maple Mini oder Deine eigene Hardware?
Funktioniert es mit einem ungepatchten Bootloader2.0?
Mit "lsusb" erhalte ich
Bus 001 Device 031: ID 0483:5740 STMicroelectronics STM32F407
mit "dmesg" erhalte ich am Ende
[18617.777084] usb 1-9: new full-speed USB device number 30 using xhci_hcd
[18617.926244] usb 1-9: New USB device found, idVendor=1eaf, idProduct=0003
[18617.926245] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[18617.926246] usb 1-9: Product: Maple 003
[18617.926247] usb 1-9: Manufacturer: LeafLabs
[18617.926247] usb 1-9: SerialNumber: LLM 003
[18619.244092] usb 1-9: USB disconnect, device number 30
[18619.553088] usb 1-9: new full-speed USB device number 31 using xhci_hcd
[18619.702396] usb 1-9: New USB device found, idVendor=0483, idProduct=5740
[18619.702397] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[18619.702398] usb 1-9: Product: MAPLEMINI_F103CB CDC in FS Mode
[18619.702399] usb 1-9: Manufacturer: STMicroelectronics
[18619.702399] usb 1-9: SerialNumber: 8D7452895051
[18619.702852] cdc_acm 1-9:1.0: ttyACM0: USB ACM device
Bei mir hat sich so ganz "unbemerkt" ein älterer ARM-Compiler eingeschlichen ...
\AppData\\Local\\Arduino15\\packages\\Seeeduino\\tools\\arm-none-eabi-gcc\\4.8.3-2014q1/bin/arm-none-eabi-ar"
Wohl weil er am Anfang des Pfadeintrages sitzt... :(
https://forum.fhem.de/index.php/topic,60458.msg1040559/topicseen.html#msg1040559 (https://forum.fhem.de/index.php/topic,60458.msg1040559/topicseen.html#msg1040559)
https://forum.fhem.de/index.php/topic,38404.msg306225.html#msg306225 (https://forum.fhem.de/index.php/topic,38404.msg306225.html#msg306225)
https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update (https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update)
hier hat nun auch stevestrong was dazu geschrieben:
https://www.stm32duino.com/viewtopic.php?p=2653#p2653
ZitatUSB DISC PIN low means that USB DP is tied to +5V.
This is correct, the USB DP pin must be high when initializing the USB.
Important is to toggle the USB DP pin from low -> high, wherein the last high is sometimes done by re-configuring the pin, see
https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/variants/generic_stm32f103c/wirish/boards_setup.cpp#L103-L107
In this case USB_DISC pin should toggle from high -> low and stay in this state.
Demnach muß der Bootloader2.0 nicht gepatcht werden.
Der Bug ist demnach im core 1.8.0 dort fehlt anscheinend dies:
https://github.com/rogerclarkmelbourne/Arduino_STM32/blob/master/STM32F1/variants/generic_stm32f103c/wirish/boards_setup.cpp#L103-L107
ZitatDein angepasstes SIGNALduino Modul scheint mit den Readings noch ein Problem zu haben, da steht bei mir im Grunde kaum etwas Nachvollziehbares. Falsche Version, falsche Konfiguration.
Habe das Schreiben in die Readings verbessert
https://github.com/Ralf9/RFFHEM/commit/7294042970f857f554571a508717ca7ac37cf526
Habe heute Abend vor dies einzubauen
ZitatWenn ich den upload-reset im 00_Signalduino Modul in der Sub SIGNALduino_ResetDevice einbaue, sollte sich der Maple Mini, so wie es auch beim nano funktioniert, sich beim einem Absturz selber reseten.
Ich habe mittlerweise in meinem Testsystem bei der USB Version eine uptime von 20 Stunden
Nachtrag:
habe auch in der Firmware ein paar Kleinigkeiten ergänzt
https://github.com/Ralf9/SIGNALDuino/commit/88f72c279e7a6c0f878be065259a0340667e1e49
https://github.com/Ralf9/SIGNALDuino/releases
hat es schon jemand hinbekommen, daß "dfu-util" auch ohne Root Rechte funktioniert?
> ./dfu-util -v -d 1eaf:0003 -a 2 -D Maple_sduino_Boot20_USB_411dev200509.bin -R
dfu-util 0.8
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: Cannot open DFU device 1eaf:0003
dfu-util: No DFU capable USB device available
dies habe ich schon ausgeführt
#!/bin/sh
if sudo [ -w /etc/udev/rules.d ]; then
echo "Copying Maple-specific udev rules..."
sudo cp -v 45-maple.rules /etc/udev/rules.d/45-maple.rules
sudo chown root:root /etc/udev/rules.d/45-maple.rules
sudo chmod 644 /etc/udev/rules.d/45-maple.rules
echo "Reloading udev rules"
sudo udevadm control --reload-rules
echo "Adding current user to dialout group"
sudo adduser $USER dialout
else
echo "Couldn't copy to /etc/udev/rules.d/; you probably have to run this script as root? Or your distribution of Linux doesn't include udev; try running the IDE itself as root."
fi
Gruß Ralf
Zitat von: Ralf9 am 09 Mai 2020, 09:47:59
Verwendest Du den Maple Mini oder Deine eigene Hardware?
Meine eigene Hardware. Die USB Disconnect Schaltung ist vorhanden.
ZitatFunktioniert es mit einem ungepatchten Bootloader2.0?
Nein, auch nicht.
Zitatmit "dmesg" erhalte ich am Ende
Die Device ID stimmt also. Auch der dmesg Inhalt ist nahezu identisch:
[ 1839.883664] usb 1-1.3: new full-speed USB device number 4 using xhci_hcd
[ 1840.018965] usb 1-1.3: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[ 1840.018980] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1840.018994] usb 1-1.3: Product: Maple 003
[ 1840.019007] usb 1-1.3: Manufacturer: LeafLabs
[ 1840.019018] usb 1-1.3: SerialNumber: LLM 003
[ 1842.346071] usb 1-1.3: USB disconnect, device number 4
[ 1842.643692] usb 1-1.3: new full-speed USB device number 5 using xhci_hcd
[ 1842.778873] usb 1-1.3: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[ 1842.778888] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1842.778901] usb 1-1.3: Product: Maple 003
[ 1842.778914] usb 1-1.3: Manufacturer: LeafLabs
[ 1842.778925] usb 1-1.3: SerialNumber: LLM 003
[ 1874.874337] usb 1-1.3: reset full-speed USB device number 5 using xhci_hcd
[ 1875.004771] usb 1-1.3: device firmware changed
[ 1875.005703] usb 1-1.3: USB disconnect, device number 5
[ 1875.104130] usb 1-1.3: new full-speed USB device number 6 using xhci_hcd
[ 1875.241676] usb 1-1.3: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[ 1875.241692] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1875.241705] usb 1-1.3: Product: MAPLEMINI_F103CB CDC in FS Mode
[ 1875.241717] usb 1-1.3: Manufacturer: STMicroelectronics
[ 1875.241729] usb 1-1.3: SerialNumber: 6565BF8F3332
[ 1875.313695] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[ 1875.315306] usbcore: registered new interface driver cdc_acm
[ 1875.315315] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 2116.050533] usb 1-1.3: USB disconnect, device number 6
[ 2116.547564] usb 1-1.3: new full-speed USB device number 7 using xhci_hcd
[ 2116.682763] usb 1-1.3: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
[ 2116.682778] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2116.682791] usb 1-1.3: Product: Maple 003
[ 2116.682804] usb 1-1.3: Manufacturer: LeafLabs
[ 2116.682815] usb 1-1.3: SerialNumber: LLM 003
[ 2129.768080] usb 1-1.3: reset full-speed USB device number 7 using xhci_hcd
[ 2129.898599] usb 1-1.3: device firmware changed
[ 2129.899566] usb 1-1.3: USB disconnect, device number 7
[ 2129.997833] usb 1-1.3: new full-speed USB device number 8 using xhci_hcd
[ 2130.135378] usb 1-1.3: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[ 2130.135394] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2130.135407] usb 1-1.3: Product: MAPLEMINI_F103CB CDC in FS Mode
[ 2130.135419] usb 1-1.3: Manufacturer: STMicroelectronics
[ 2130.135431] usb 1-1.3: SerialNumber: 6565BF8F3332Bisher traue ich den EEPROM Updates für RPi4 und den daraus resultierenden Verschlimbesserungen für USB nicht über den weg.
Die STMduion 1.8er core zickt etwas herum mit den USARTS 2+3:
HardwareSerial Serial2(USART2);
HardwareSerial Serial3(USART3);
In setup():
Serial.begin(BAUDRATE);
Serial2.setTx(PA2)
Serial2.setRx(PA3)
Serial3.setTx(PB10)
Serial3.setRx(PB11)
Serial2.begin(115200); //--- is W600 port cmd/data port // See: C:\Users\js\AppData\Local\Arduino15\packages\STM32\hardware\stm32\1.8.0\cores\arduino\HardwareSerial.h
Serial3.begin(115200);//--- debug TextTerminal
und:
if (Serial2.available())
Serial2.println("Setup done. #2");
if (Serial3.available())
Serial3.println("Setup done. #3");
Es gibt auch noch Varianten z.B. für 8N1:
Serial2.begin(115200, 0x06);
Wie in: "HardwareSerial.cpp" definiert.
Hat leider noch nicht funktioniert. Scheint doch etwas komplizierter zu sein, als ich dachte.
Versuche morgen nochmal mein Glück. ;)
https://github.com/stm32duino/wiki/wiki/API#hardwareserial (https://github.com/stm32duino/wiki/wiki/API#hardwareserial)
Hallo Locutus,
bist Du sicher, dass Deine Schaltung diesem Layout entspricht, wenn Du mit Ralf's Binary arbeitest?
Jürgen
Zitatbist Du sicher, dass Deine Schaltung diesem Layout entspricht, wenn Du mit Ralf's Binary arbeitest?
Das Layout sollte zum Testen egal sein, es wird bei falschem Layout zwar kein cc1101 erkannt, aber die Befehle funktionieren trotzdem.
Wenn mit "ls -l /dev/serial/by-id" das "ttyACM0" erkannt wird, sollten in einem seriellen Terminal Befehle wie z.B. P oder V oder ? funktionieren
Bei mir sieht es so aus
# ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 9. Mai 21:32 usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 -> ../../ttyACM0Das dmesg sieht recht gut aus
ZitatWenn ich den upload-reset im 00_Signalduino Modul in der Sub SIGNALduino_ResetDevice einbaue, sollte sich der Maple Mini, so wie es auch beim nano funktioniert, sich beim einem Absturz selber reseten.
Hab es eingebaut
https://github.com/Ralf9/RFFHEM/commit/c69593f34a3116f4f5f8dce8ad18a51fbf1b0ebb
Hallo Locutus,
ich glaube ich hatte heute ein ähnliche Phänomen mit einem neuen MapleMini.
Der hatte initial den MapleLeaf-Originalbootloader drauf.
Sketch hochgeladen und erkannt = alles OK. (Einstellung: STMDuino, Original BL 17k)
Dann Telekatz-gepatchte Version mit STLink hochgeladen und (Einstellung: STMDuino, BL 2.0 20k)
es ging nichts mehr!
ZitatAn error occurred while uploading the sketch
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Searching for DFU device [1EAF:0003]...
dfu-util - (C) 2007-2008 by OpenMoko Inc.
Couldn't find the DFU device: [1EAF:0003]
This program is Free Software and has ABSOLUTELY NO WARRANTY
timeout waiting for COM44 serial
Auch nach Ausschalten und Wiedereinschalten, verschiedene Bootloader geflasht. Es ging einfach nichts mehr.
Dann Rogers Maple_Mini_20.bin geflasht, Rechner ausgeschalten, Board vom USB entfernt. Rechner wieder eingeschalten ...
Board an anderer USB-Schnittstelle wieder eingesteckt: Meldung "Installing Maple ... " => geht.
Board wieder zurück auf "problematischne" USB-Port : geht wieder !
Telekatz-gepatchte Version geflasht: geht wieder. (Magic!)
Da ich unter WIN10 arbeite kann es schon etwas Anderes sein, aber irgendwas ist beim Einrichten des Devices (BL mit STLINK und Reset) schief gegangen, welches sich durch Zufall
durch Wechsel auf anderen anderem USB-Port wieder bereinigt hat ...
Vielleicht ist das unter Linux ähnlich?
Grüße,
Jürgen
/edit: der Bootloader streikt ebenfalls, wenn auf serielle 1..3 Daten ausgegeben werden
Wenn ich mein seriellen test von unten laufen lasse, geht nichts mehr Upload streikt
(siehe Screenshot: Serielles Device_Statts Maple.png):
Zitatmaple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
dfu-util - (C) 2007-2008 by OpenMoko Inc.
Couldn't find the DFU device: [1EAF:0003]
This program is Free Software and has ABSOLUTELY NO WARRANTY
timeout waiting for COM48 serial
Lösung: mit STLINK komplett Erase des Flashspeichers und Bootloader neu Flashen ... :( :o
Aber mein Grundproblem:
Keine Ausgabe unter Seriellem Port >0
Zum Testen hier mit Arduino_STM32 (https://github.com/rogerclarkmelbourne/Arduino_STM32)-Version, als Gegencheck zur stm32duino - Arduino_Core_STM32 (https://github.com/stm32duino/Arduino_Core_STM32)-Version ....
Beide Varianten geben am Port nichts aus ... Compile läuft aber ohne Fehler durch ...
Jetzt weiter mit
stm32duino - Arduino_Core_STM32 (https://github.com/stm32duino/Arduino_Core_STM32)-Version getestet:
#include <Arduino.h>
//#include <HardwareSerial.h> // wird wohl nicht direkt benötigt
void setup() {
// put your setup code here, to run once:
// Maple_Serial3._STMDuino:9:10: error: 'class USBSerial' has no member named 'Println'
delay(2000);
Serial.begin(115200);
Serial.println("bin da...");
Serial1.begin(115200);
Serial1.println ("Bin auch auf 1 da");
Serial2.begin(115200);
Serial2.println ("Bin auch auf 2 da");
Serial3.begin(115200);
Serial2.println ("Bin auch auf 3 da");
}
void loop()
{
// put your main code here, to run repeatedly:
while(true)
{
for (uint8_t i=32; i<128; i++)
{
delay(2000);
Serial1.println(i);
Serial2.println(i);
Serial3.println(i);
}
}
}@ me: No support of UART2 & 3 in Version 1.8.0 <-- https://github.com/stm32duino/wiki/wiki/API#hardwareserial (https://github.com/stm32duino/Arduino_Core_STM32/issues/966)
======================================================
@Ralf9: CDC Serial write and flush lock up when interrupts are disabled (https://github.com/stm32duino/Arduino_Core_STM32/issues/803)
======================================================
/*
* Blink without delay and UART Test
*
* https://github.com/stm32duino/wiki/wiki/API#hardwareserial
*/
#include <HardwareSerial.h>
// Variables:
int previousMillis = 0; // will store the last time the LED was updated
int interval = 500; // interval at which to blink (in milliseconds)
uint32_t counter = 0;
// RX TX
HardwareSerial Serial2(PA3, PA2);
HardwareSerial Serial3(PB11, PB10);
void setup() {
// Set up the built-in LED pin as output:
pinMode(PC13, OUTPUT);
Serial1.begin(19200);
Serial2.begin(19200);
Serial3.begin(19200);
}
void loop() {
// Check to see if it's time to blink the LED; that is, if the
// difference between the current time and last time we blinked
// the LED is bigger than the interval at which we want to blink
// the LED.
if (millis() - previousMillis > interval) {
// Save the last time you blinked the LED
previousMillis = millis();
Serial1.print("Counter: ");
Serial1.print(counter);
Serial1.println(" - Hello UART 1!");
Serial2.print("Counter: ");
Serial2.print(counter);
Serial2.println(" - Hello UART 2!");
Serial3.print("Counter: ");
Serial3.print(counter);
Serial3.println(" - Hello UART 3!");
counter ++;
// If the LED is off, turn it on, and vice-versa:
digitalWrite(PC13,!digitalRead(PC13));
}
}
// ===> will be an working a *not* example.Aber das hier?
/*
* Blink without delay and UART Test
*
* https://github.com/stm32duino/wiki/wiki/API#hardwareserial
*/
#include <HardwareSerial.h>
// Variables:
int previousMillis = 0; // will store the last time the LED was updated
int interval = 500; // interval at which to blink (in milliseconds)
uint32_t counter = 0;
// RX TX
//HardwareSerial Serial2(PA3, PA2);
//HardwareSerial Serial3(PB11, PB10);
HardwareSerial Serial2(USART2);
HardwareSerial Serial3(USART3);
void setup() {
// Set up the built-in LED pin as output:
pinMode(PC13, OUTPUT);
Serial1.setTx(PA9);
Serial1.setRx(PA10);
Serial2.setTx(PA2);
Serial2.setRx(PA3);
Serial3.setTx(PB10);
Serial3.setRx(PB11);
Serial1.begin(115200);
Serial2.begin(115200);
Serial3.begin(115200);
}
void loop()
{
// Check to see if it's time to blink the LED; that is, if the
// difference between the current time and last time we blinked
// the LED is bigger than the interval at which we want to blink
// the LED.
if (millis() - previousMillis > interval) {
// Save the last time you blinked the LED
previousMillis = millis();
Serial1.print("Counter: ");
Serial1.print(counter);
Serial1.println(" - Hello UART 1!");
Serial2.print("Counter: ");
Serial2.print(counter);
Serial2.println(" - Hello UART 2!");
Serial3.print("Counter: ");
Serial3.print(counter);
Serial3.println(" - Hello UART 3!");
counter ++;
// If the LED is off, turn it on, and vice-versa:
digitalWrite(PC13,!digitalRead(PC13));
}
}
// ===> will be an working example.Geht, aber ohne Stoppbits (FTDI-Adapter!) ?
Zitat---------------------------
CoolTerm - Warning
---------------------------
A Serial Port Error Occured
103: No Stop Bit received
---------------------------
OK
---------------------------
ZitatCounter: 0 - Hello UART 3!
Counter: 1 - Hello UART 3!
Counter: 2 - Hello UART 3!
Counter: 3 - Hello UART 3!
Counter: 4 - Hello UART 3!
Counter: 5 - Hello UART 3!
Counter: 6 - Hello UART 3!
Counter: 7 - Hello UART 3!
Counter: 8 - Hello UART 3!
Counter: 9 - Hello UART 3!
Counter: 10 - Hello UART 3!
=========
Damit geht es:
=========
// RX TX
//HardwareSerial Serial2(PA3, PA2); // -> Fehler beim Compile
//HardwareSerial Serial3(PB11, PB10); // -> Fehler beim Compile
HardwareSerial Serial2(USART2, SERIAL_8N1 );
HardwareSerial Serial3(USART3, SERIAL_8N1 ); //--- überladener Konstruktor mit 8N1
void setup() {
// Set up the built-in LED pin as output:
pinMode(PC13, OUTPUT);
Serial1.setTx(PA9);
Serial1.setRx(PA10);
Serial2.setTx(PA2);
Serial2.setRx(PA3);
Serial3.setTx(PB10);
Serial3.setRx(PB11);
Serial.begin(115200);
Serial1.begin(115200);
Serial2.begin(115200);
Serial3.begin(115200);
}
Negativer Beigeschmack: Upload über Arduino geht nicht mehr! /edit: neuer Flash und Reset erhöht den COM-Schnittstellen-Index von COM48 auf COM49 und, wie erwartet: Serial0 wird als USB-Serial ausgegeben:
ZitatCounter: 17 - Hello USB-Serial 0!
Counter: 18 - Hello USB-Serial 0!
Counter: 19 - Hello USB-Serial 0!
Counter: 20 - Hello USB-Serial 0!
Counter: 21 - Hello USB-Serial 0!
Counter: 22 - Hello USB-Serial 0!
Counter: 23 - Hello USB-Serial 0!
Counter: 24 - Hello USB-Serial 0!
Hi COM49?
Da wird es mal Zeit im Gerätemanager alle ungenutzten COMs zu löschen und wieder bei einer Zahl unter 16 anzufangen.
Ich habe schon viele Programme unter Windows gesehen, die nur bis COM16 klarkamen.
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Hallo Arnd,
gut gemeint, danke. ;D ;)
https://superuser.com/questions/408976/how-do-i-clean-up-com-ports-in-use (https://superuser.com/questions/408976/how-do-i-clean-up-com-ports-in-use)
https://www.ftdichip.com/Support/Documents/AppNotes/AN_132_Re-Assigning_COM_Port_Numbers_Using_Registry.pdf (https://www.ftdichip.com/Support/Documents/AppNotes/AN_132_Re-Assigning_COM_Port_Numbers_Using_Registry.pdf)
Habt Ihr mal getestet ob das "upload-reset" bei einem Absturz funktioniert?
Zitat@Ralf9: CDC Serial write and flush lock up when interrupts are disabled
Wenn ich das richtig überblicke, kann die serielle USB Ausgabe blockieren, wenn bei gesperrtem Interrupt ausgegeben wird.
Beim sduino werden in den beiden Interruptroutinen zwar die Interrupts gesperrt, aber es wird nichts ausgegeben.
Gruß Ralf
Hallo Ralf,
in meinem Log steht folgendes (falls es hilft): "reset: upload-reset not found". Was fehlt mir? Arbeite noch mit der "V 4.1.0-dev200427" MapleCUL, selber kompiliert. Teste hiermit gerade den Watchdog.
Ja, Dir fehlt noch das File upload-reset, dies wird in allen Verzeichnissen der path Variablen gesucht
https://github.com/Ralf9/RFFHEM/commit/c69593f34a3116f4f5f8dce8ad18a51fbf1b0ebb
ZitatBeim "set reset" wird nun der MapleSduino oder MapleCul (V 4.1.x) mit "upload-reset" reseted.
Dazu muss das File "upload-reset" auf den fhem Server kopiert werden
https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/tools
Hallo Ralf,
ZitatHabt Ihr mal getestet ob das "upload-reset" bei einem Absturz funktioniert?
Nein leider noch nicht, meine Version läuft gerade durch:
Zitat
V 4.1.0-dev200422 SIGNALduino cc1101 (R: A1 B-*) - compiled at Apr 24 2020 16:18:35
uptime: 3 21:26:25
Zitat von: Ralf9 am 12 Mai 2020, 08:32:13
Ja, Dir fehlt noch das File upload-reset, dies wird in allen Verzeichnissen der path Variablen gesucht
https://github.com/Ralf9/RFFHEM/commit/c69593f34a3116f4f5f8dce8ad18a51fbf1b0ebb (https://github.com/Ralf9/RFFHEM/commit/c69593f34a3116f4f5f8dce8ad18a51fbf1b0ebb)
Habe ich versucht:
Zitat2020.05.12 10:27:12 3: myMaple reset
/bin/upload-reset: 1: /bin/upload-reset: Syntax error: word unexpected (expecting ")")
Was wäre sonst noch möglich? (Sorry, arbeite mich in allem bezüglich "Smart Home" gerade erst ein :-[ )
Das upload-reset file muss in eines der Vezeichnisse kopiert werden das bei "echo $PATH" angezeigt wird,
z.B.
/usr/local/bin:/usr/bin:/bin:
Ich habe es bei mir nach "/usr/local/bin" kopiert.
Das upload-reset ist auch bei der Arduino IDE beim STM32 core dabei, in dem Verzeichnis wo auch das dfu-util Verzeichnis ist.
Ausgeführt wird es mit den folgenden Parametern:
upload-reset /dev/ttyACM0 750
Ich hatte das upload-reset direkt in das /bin Verzeichnis kopiert:
Zitat
/bin/upload-reset: 1: /bin/upload-reset: Syntax error: word unexpected (expecting ")")
/usr/local/bin/upload-reset: 1: /usr/local/bin/upload-reset: Syntax error: word unexpected (expecting ")")
Wie du siehst wird upload-reset gefunden, aus irgendeinem Grund generiert das aber einen Syntaxfehler. Zur Erinnerung: Ich arbeite noch mit der "V 4.1.0-dev200427 SIGNALduino cc1101" und nicht mit der aktuellsten Version. Sollte es nur mit der aktuellsten Version funktionieren bitte noch ein wenig warten, ich teste derzeit den Watchdog.
Nachtrag:
Das "/dev/ttyACM0" ist vorhanden.
/bin/upload-reset: 1: /bin/upload-reset: Syntax error: word unexpected (expecting ")")
Dies ist unabhängig von der firmware.
Ich hab mal danach gegoogled, da gibts einige Treffer, hat evtl was mit verwendeten Linux shell zu tun.
Welches Linux OS hast Du?
Funktioniert dies?
upload-reset /dev/ttyACM0 750
Ich arbeite mit einem Raspi 4B und folgender Linux Version:
Zitat
Linux raspi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux
Nachtrag:
Das von dir unten angegebene "upload-reset" erzeugt genau das von mir angehängte Ergebnis.
Bei mir zu finden unter:
"C:\Program Files (x86)\Arduino\hardware\Arduino_STM32\tools\win\src\upload-reset\upload-reset.c"
muss aber auf dem Raspi compiliert werden:
https://raspberrypi.stackexchange.com/questions/5599/how-to-compile-c-files-in-terminal (https://raspberrypi.stackexchange.com/questions/5599/how-to-compile-c-files-in-terminal)
Wenn ich als "pi" die Datei aufrufe kommt als Antwort "Binärformat fehlerhaft". Werde gleich mal kompilieren...
Zitat von: juergs am 12 Mai 2020, 19:16:15
Bei mir zu finden unter:
"C:\Program Files (x86)\Arduino\hardware\Arduino_STM32\tools\win\src\upload-reset\upload-reset.c"
muss aber auf dem Raspi compiliert werden:
https://raspberrypi.stackexchange.com/questions/5599/how-to-compile-c-files-in-terminal (https://raspberrypi.stackexchange.com/questions/5599/how-to-compile-c-files-in-terminal)
Perfekt, das war der richtige Hinweis. Die Binaries von Roger passten nicht zum Raspi.
Hatte jetzt nach 1 Tag und ca 18 Stunden auch einen Absturz bei der USB Version.
Habe dann das upload-reset.c compiliert,
pi@banaNAS:~/prog$ gcc upload-reset.c -o upload-reset
upload-reset.c:121:1: warning: return type defaults to 'int' [-Wimplicit-int]
main(int argc, char *argv[])
^~~~
upload-reset.c: In function 'main':
upload-reset.c:127:3: warning: 'return' with no value, in function returning non-void
return;
^~~~~~
upload-reset.c:121:1: note: declared here
main(int argc, char *argv[])
^~~~
Das reseten mit upload-reset hat dann funktioniert.
Einfach mal kurz eingeworfen:
Mein maple Sduino läuft seit letzten Donnerstag.
Die letzte größere "Empfangsschwäche" war am Samstag. Danach nur einmal am Montag einen Aussetzer für 20 Minuten. In allen anderen Zeiten ein vorbildlicher Empfang.
Warum auch immer das bei mir mit Lacrosse Mode2 so ist.
Ein Absturz im Sinne von keine Antwort mehr hatte ich bisher noch nie.
Gruss
Zitat von: killah78 am 13 Mai 2020, 15:55:17
Einfach mal kurz eingeworfen:
Mein maple Sduino läuft seit letzten Donnerstag.
Die letzte größere "Empfangsschwäche" war am Samstag. Danach nur einmal am Montag einen Aussetzer für 20 Minuten. In allen anderen Zeiten ein vorbildlicher Empfang.
Warum auch immer das bei mir mit Lacrosse Mode2 so ist.
Ein Absturz im Sinne von keine Antwort mehr hatte ich bisher noch nie.
Gruss
So rund läuft es bei mir nicht. Im Lacrosse Mode1 habe ich Aussetzer die über Stunden gehen. Mit einem raw WS36, raw WS34 lässt sich bis jetzt der CC1101 aber sofort wieder zum Arbeiten bringen. Der Watchdog, den ich aktiviert habe, hat inzwischen schon 2 Mal einen Reset ausgelöst und den Maple wieder auf die Beine gestellt. Da muss ich noch schauen ob ich die Triggerzeit hochsetzen muss.
ZitatSo rund läuft es bei mir nicht. Im Lacrosse Mode1 habe ich Aussetzer die über Stunden gehen. Mit einem raw WS36, raw WS34 lässt sich bis jetzt der CC1101 aber sofort wieder zum Arbeiten bringen.
Ich habe hier das Problem, daß ich dies bei mir überhaupt nicht nachvollziehen kann.
Ich habe hier ein TX29 DTH-IT (Mode 1) und 3 PCA301 (Mode 3) bei denen ich bis jetzt noch keine Aussetzer hatte.
Ist Dir bekannt, daß bei LaCrosse der state nur bei Änderungen geschrieben wird.
Hast Du schon mal den neuen ccmode 4 getestet? Da wird zum Auslesen des FIFOs des cc1101 genauso wie bei der a-culw gemacht,
get raw CSccmode=4
Werde ich testen :)
Zitat von: Reinhard.M am 13 Mai 2020, 19:54:18
Werde ich testen :)
Wenn ich auf ccmode=4 umstelle reagiert anschließend der Maple so gut wie überhaupt nicht mehr. Egal welchen get Befehl ich danach sende, es kommt keine Antwort. Ob der ccmode richtig eingestellt ist kann ich ebenfalls nicht auslesen.
Nachtrag:
Anscheinend mag mein Maple den ccmode=4 überhaupt nicht. Ich habe jetzt permanent RX-FIFO overflow und komme aus diesem Zustand auch mit Reset nicht mehr heraus. CSccmode=0 hat auch nichts gebracht.
Also ich laufe auf ccmode=4 und ich habe das Gefühl, je länger der am Stück läuft, um so weniger Aussetzer gibt es. Aber ich bin etwas beruhigt, dass noch weitere diese Aussetzer haben. Wie gesagt, komplette Abstürze hatte ich bisher noch nicht.
ZitatWenn ich auf ccmode=4 umstelle reagiert anschließend der Maple so gut wie überhaupt nicht mehr.
Das ccmode 4 funktioniert erst ab 4.1.0-dev200501
https://github.com/Ralf9/SIGNALDuino/commit/aec52b7d62134d1d8f48b9ef3601f76ade2e0217
Zitat von: Ralf9 am 14 Mai 2020, 08:51:07
Das ccmode 4 funktioniert erst ab 4.1.0-dev200501
https://github.com/Ralf9/SIGNALDuino/commit/aec52b7d62134d1d8f48b9ef3601f76ade2e0217
Wie komme ich da jetzt wieder raus? Wie gesagt, der Baustein hat komplett die Arbeit eingestellt und erzeugt nur noch Fehler, Overflows.
Wenn sich dies ändert wird die config im EEPROM zurückgesetzt
#define VERSION_1 0x41
#define VERSION_2 0x0d
Entweder eine Version mit geänderten VERSION_x Werten compilieren oder eine a-culw flashen
ZitatAnscheinend mag mein Maple den ccmode=4 überhaupt nicht.
Hattest Du beim umstellen des ccmode evtl das Radio B mit Bank 0 selektiert.
Du musst vor dem umstellen des ccmode erst das RadioA selektieren (mit Befehl bA)
Zitat von: Ralf9 am 14 Mai 2020, 09:11:40
Wenn sich dies ändert wird die config im EEPROM zurückgesetzt
#define VERSION_1 0x41
#define VERSION_2 0x0d
Entweder eine Version mit geänderten VERSION_x Werten compilieren oder eine a-culw flashen
Jetzt habe ich mir scheinbar alles zerschossen. Mit einem CREA oder CREB kommt folgendes:
Zitatraw: detect A: timeout, no cc1101
Mit einem bA1 oder bB0 wird nichts bewirkt. Ein bA schaltet nicht auf Modul A:
Zitatraw: radio is not aktive!
Was übersehe ich? Habe übrigens die aktuellste Version verwendet:
Zitatraw: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A- B-*) - compiled at May 14 2020 09:50:49
Das sieht nach der Version für den MapleCul aus
Ganz richtig, ich arbeite mit der MapleCUL Version.
Du testet demnach an einem MapleCul.
Wenn die MapleCul firmware nicht auf dem Maplecul funktioniert, bitte eine Version davor testen
Nachtrag:
Die MapleCul firmware kann wegen den vertauschten SPI auf einen MapleSduino nicht funktionieren
Zitat von: Ralf9 am 14 Mai 2020, 10:36:51
Nachtrag:
Die MapleCul firmware kann wegen den vertauschten SPI auf einen MapleSduino nicht funktionieren
Ganz richtig :-[
Ich hatte alle Anpassungen bezüglich Watchdog im neuen ino File nachgezogen. Nur die Umschaltung auf MapleCUL hatte ich vergessen. Peinlich. Jetzt läuft jedenfalls alles wieder wie am Schnürchen :) Mal sehen welche Uptime ich zusammenbekomme.
Guten Morgen Zusammen!
Mit der Uptime war es nicht so dolle, letzte Nacht hatte ich gleich mehrere Aussetzer nacheinander. Innerhalb einer halben Stunde hat der Watchdog insgesamt 5 Mal zugeschlagen:
Zitat
2020-05-14_12:42:39 myMaple state: opened
2020-05-15_01:57:28 myMaple DISCONNECTED
2020-05-15_01:58:31 myMaple CONNECTED
2020-05-15_01:58:33 myMaple state: opened
2020-05-15_02:00:06 myMaple DISCONNECTED
2020-05-15_02:00:39 myMaple CONNECTED
2020-05-15_02:00:42 myMaple DISCONNECTED
2020-05-15_02:01:07 myMaple CONNECTED
2020-05-15_02:01:19 myMaple state: opened
2020-05-15_02:03:15 myMaple DISCONNECTED
2020-05-15_02:04:21 myMaple CONNECTED
2020-05-15_02:04:23 myMaple state: opened
2020-05-15_02:12:42 myMaple DISCONNECTED
2020-05-15_02:13:45 myMaple CONNECTED
2020-05-15_02:13:47 myMaple state: opened
2020-05-15_02:20:35 myMaple DISCONNECTED
2020-05-15_02:20:38 myMaple CONNECTED
2020-05-15_02:20:40 myMaple DISCONNECTED
2020-05-15_02:21:08 myMaple CONNECTED
2020-05-15_02:21:10 myMaple state: opened
2020-05-15_02:22:10 myMaple DISCONNECTED
2020-05-15_02:23:10 myMaple CONNECTED
2020-05-15_02:23:12 myMaple state: opened
2020-05-15_02:24:16 myMaple DISCONNECTED
2020-05-15_02:25:18 myMaple CONNECTED
2020-05-15_02:25:20 myMaple state: opened
Davor war ca. 13 Stunden und danach is bislang Ruhe. Den Watchdog habe ich auf ~5 Sekunden Trigger eingestellt. Das Ganze führe ich auf einem MapleCUL mit der Firmware "version: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 14 2020 10:47:57" durch. Hat eventuell jemand eine Idee wie ich hier mehr Informationen herauziehen kann um dem Fehler auf die Schliche zu kommen?
Beim Maple Mini gibt es debug Möglichkeiten, damit kenne ich mich aber nicht aus.
Ich mache gerade ein Dauertest mit dem BananaPI als fhem Testserver.
Nach ca 1 Tag und 19 Stunden hatte ich einen Absturz, die LED ist aus geblieben, ich konnte ihn mit dem upload-reset Program reseten.
Nun habe ich eine uptime von 2 Tagen und 22 Stunden.
Um die changen für einen Absturz zu erhöhen, und damit den Fehler evtl ein wenig eingrenzen zu können, habe ich vor mit 2-3 MapleSduino parallel zu testen.
Mich interessiert folgendes:
- lässt sich bei jedem Absturz der MapleMini mit dem upload-reset Program reseten?
- gibt es Abstürze, wenn nur das Radio A (FSK) aktiv ist?
- gibt es Abstürze, wenn nur das Radio B (SlowRF) aktiv ist?
- gibt es Abstürze, wenn anstatt USB das RX/TX verwendet wird? z.B. mit einen USB Seriell Wandler
Dazu muß bei Arduino IDE folgendes konfiguriert werden:
USART Support: generic Serial
USB Support: keine
Hängt der Maple an einem Testsystem oder am Produktivsystem?
Werden beim SlowRF besonders viele Sensoren (auch von Nachbarn) empfangen?
Ich habe 9 Temperatursensoren und die WH3080 Wetterstation.
Bei FSK Mode1 habe ich nur ein Sensor
Auf dem FSK Mode 1 habe ich ebenfalls nur einen Sensor, auf dem SlowRF laufen bis zu 3 Temperatursensoren auf. Als der Watchdog zugeschlagen hat waren es aber nur ein oder zwei Sensoren. Der Mode1 Sensor sendet etwa alle 4 Sekunden, die anderen bestenfalls alle 30 Sekunden. Overload sollte da eigentlich nicht auftauchen. In einem Reset Fall war der Mode1 Sensor bereits seit mehreren Minuten ruhig, hat also nicht mehr aufgezeichnet. Das geschieht bei mir ja immer wieder mal und kann Stunden dauern (mit einem XQ/XE konnte ich heute das Modul wieder reaktivieren). Könnte das eventuell ein Indiz sein, dass das SlowRF Modul für den Ärger sorgt? Ich habe jedenfalls verbose auf 4 gesetzt und warte jetzt auf den nächsten Aussetzer. Eventuell zeigt sich ja unmittelbar davor etwas in der Aufzeichnung. Wenn ich es hinbekomme werde ich auch mal das RX/TX Interface testen.
Ganz am Rande, ich würde mir gerne einen MapleSduino zusammenbauen. Kann mir jemand sagen wie ich an das Material komme?
Hi,
hier meine Info:
ich habe den MapleSduino an meinem Testsystem. Ist ein Docker Container auf dem gleichen System wie meine Produktivumgebung.
Ich habe 7 eigene Temperatursensoren, empfange aber noch ein paar andere aus der Nachbarschaft. Daneben habe ich auch noch eine 1080 Wetterstation. Lacrosse Mode 2 habe ich nur einen Temperatursensor.
Ich hatte den MapleSduino in Betrieb nur mit Radio A installiert, zur Zeit mit A FSK und B SlowRF.
Er läuft jetzt seit 9 Tagen ohne Absturz (Hatte bisher noch nie einen).
Lediglich diese Aussetzer, mal besser mal schlechter.
Ich habe den Bootloader 2.0, nicht gepatched.
Wie meinst du das mit zusammenbauen? Platine? Die bekommst du von Ranseyer. Die 868 und 433 Stamps habe ich von Ali und den Maple auch. Ich denke es handelt sich da bei mir um einen Maple Clone. Gehäuse habe ich noch nicht dafür.
Gruss
mittlerweile habe ich eine uptime von 4 Tagen und 14 Stunden.
Zitatmit einem XQ/XE konnte ich heute das Modul wieder reaktivieren
Welches der Module Radio A (FSK) oder Radio B (SlowRF) musst Du ab und zu reaktivieren?
Zu kannst die auch einzeln mit XQA / XEA oder XQB / XEB reaktivieren
Hast Du schon mal das ccmode=4 getestet, gibt es eine Verbesserung?
Gruß Ralf
Zitat von: Ralf9 am 17 Mai 2020, 11:56:12
Welches der Module Radio A (FSK) oder Radio B (SlowRF) musst Du ab und zu reaktivieren?
Es ist immer das A-Modul. Meistens habe ich mit bA auf das Modul geschaltet und mit WS36/WS34 zurückgesetzt. Mit XQA/XEA kann ich es aber auch mal versuchen.
ZitatEs ist immer das A-Modul.
Passiert dies auch mit ccmode=4
Habe ich gerade aktiviert und teste jetzt Modul A mit ccmode=4:
Zitat
Bank__ 0 1 2 3 4 5 6 7 8 9
Radio_ B A*- - - - - - - -
N_____ 0 0 2 3 4 - - - - -
ccmode 0 4 3 3 2 - - - - -
Zitat von: Ralf9 am 17 Mai 2020, 14:39:48
Passiert dies auch mit ccmode=4
Modul-A lief mit ccmode=4 und hat heute Morgen wieder den Empfang eingestellt. Nach 1:20 Stunde habe ich das Modul-A mit XQA/XEA "zurückgesetzt", seitdem läuft der Empfang wieder problemlos. Weiterhin Lacross Mode-1 mit ccmode=4.
Hallo Reinhard.M,
versuche mal für das SignalDuino-Attribut "verbose" auf 5 zu stellen und den Zeitpunkt des Aussetzens mit dem Log zu "synchronisieren"
und das Ergebnis hier einzustellen. (Als Auszug oder als gesamtes Log im Anhang.)
Da mit Aussagen wie: "
.. hat ausgesetzt" uns bei der Fehlersuche nicht unbedingt bei der Fehlereingrenzung geholfen ist. ;-)
Ist in etwa gleichzusetzen wie:
... es ist ein Fehler passiert!... :D ;D
Vielleicht ist es ein bestimmter Typ von Sensor oder Telegramm, evtl. überlagert mir mehreren
gleichzeitigen Sendeversuchen, die nicht dekodiert werden konnten, wie z.B. bei mir:
Zitat2020.05.01 01:41:09 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data B1DF8, code B1D
2020.05.01 01:42:46 3: sduino: Unknown code u40#327B0110, help me!
2020.05.01 01:43:17 3: sduino: Unknown code u19#327B00, help me!
2020.05.01 01:44:07 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data C77E1, code C77
2020.05.01 01:44:19 3: sduino: Unknown code u19#93D80, help me!
2020.05.01 01:44:19 3: sduino: Unknown code u40#4F600, help me!
2020.05.01 01:46:46 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 0B0BF, code 0B0
2020.05.01 01:51:21 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 00000, code 000
2020.05.01 01:51:32 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data FC380, code FC3
2020.05.01 01:51:32 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data E01A6, code E01
2020.05.01 01:58:16 3: sduino: Unknown code u40#327B010B34, help me!
2020.05.01 02:07:34 3: sduino: Unknown code u19#0213E0, help me!
2020.05.01 02:07:51 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 058EF, code 058
2020.05.01 02:07:51 1: sduino: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 34, data 38068, code 380
2020.05.01 02:08:05 3: sduino: Unknown code u40#327D0, help me!
2020.05.01 02:08:05 3: sduino: Unknown code u19#0427C, help me!
2020.05.01 02:11:11 3: sduino: Unknown code u19#0106DC, help me!
2020.05.01 02:16:45 1: sduino: SD_UT_Parse UNDEFINED sensor unknow
Ich habe hier viele "Nachbarschafts"-Sensoren die "unsynchronisiert" in der Gegend herumfunken und sich ggf. auch nicht an die Sendepausen-Regel halten
und ggf. auch gegenseitig stören.
Das ist im 443Mhz beim mir ebenfalls häufig der Fall. Dann registriere ich Aussetzer von einigen Minuten bis Stunden bis der Sendezeitpunkt bei den Sensoren wieder auseinanderläuft.
Sehr selten kommt der Sduino oder auch mal der RASPI ins "Stocken", aber ob man von einer generellen "Instabilität" reden kann, wage ich zu bezweifeln. ;-)
Grüße,
Jürgen
Als Beispiel habe ich mal ein
MapleCUL-Plot von einem CUL_TX-Sensor auf 433MHz, der ca. 20cm von der Antenne entfernt ist.
Ich glaube solche "Situationen" lassen sich nicht verhindern, da die Sensoren nur nach festgelegtem Schema senden und nicht "horchen", ob gerade jemand anderes funkt,
wie es z.B. bei einem (CAN)-Bus gemacht wird...
Allerdings grenzt das die Möglichkeit eines oder mehrerer Bugs auch nicht aus. ;-(
Hallo Jürgen,
ich hatte das schon mal mit verbose=4 versucht. Das hat mir innerhalb kürzester Zeit das Log auf 15MB aufgeblasen. Hat leider keine weiterführenden Informationen geliefert. Höchstens das bereits kurz vorher Empfangssamples verloren wurden (bei mir kommt alle 4 Sekunden etwas vom LaCross Sender). Ich werde das Maple Log mal auf täglich umstellen und hoffe darin dann noch etwas wiederzufinden.
Gruß
Reinhard
P.S.: Mir ist schon klar, dass meine Aussagen recht vage sind, HW/SW debugging mache ich bereits seit sehr vielen Jahren. Leider ist das komplette System (FHEM, Maple, Radio, ...) für mich neu und ich muss mich an vielen Stellen erst einmal orientieren und einarbeiten. Es wird aber von Tag zu Tag besser :)
Hallo Reinhard,
bitte nicht falsch verstehen, war kein Vorwurf!
15 MB ist jetzt auch nicht unbedingt "viel" ;-)
Vielleicht hilft dann schon ein tail -f -n 200 in der Konsole auf das Log?
Du kannst ja den einem Plot den Referenz-Zeitpunkt entnehmen, danach einfach wieder verbose auf 3 zurücksetzen.
Grüße,
Jürgen
Zwischeninfo:
Seit gestern 0 Uhr bis jetzt, also ca 36h, nur eine(1) 'Verzögerung' von nur 30 Sekunden. Ansonsten immer Empfang zwischen 5 und 10 Sekunden. Ich dachte immer der Intervall sei 10 Sekunden, aber scheinbar sind es 5.
Signalduino läuft jetzt 12 Tage.
Am ersten Tag gab es eine Verzögerung von 20 Stunden, es wurde von Tag zu Tag besser. Jetzt aktuell quasi fehlerfrei.
UART2+3 funktionieren schon mal im Zusammenspiel im MapleSduino_SER2WLAN (https://github.com/juergs/MapleSduino_SER2WLAN).
Hallo Ralf,
Zitatvoid serialEvent()
{
while (MSG_PRINTER.available())
{
char inChar = (char)MSG_PRINTER.read();
switch(inChar)
{
case '\n':
case '\r':
case '\0':
case '#':
_command_available = true;
break;
default:
cmdstring += inChar;
}
if (cmdstring.length() > maxCmdString)
{
cmdstring = ""; //--- restliche Zeichen ignorieren
MSG_PRINT(F("cmd to long! (max "));
MSG_PRINT(maxCmdString);
MSG_PRINTLN(F(")"));
}
}
if (cmdstring != "")
{
MSG_PRINT("serialEvent.cmdstring = ");MSG_PRINTLN(cmdstring);
}
}
Ich glaube, dass die Bedingung
Zitatwhile (MSG_PRINTER.available())
von der zeitlichen Abfolge der Übergabe des KommandoStrings abhängt!
Ist sie zu lang (wie z.B. bei einer manueller Eingabe), schaltet
available zwischendurch gemäß ihrem internen Timeout auf
false.
=> Wäre zu klären, wie lange das Timeout sein darf ? (Vermute es sind 1..n Char-Übertragungs-Zeiten bis es kippt.)
Dann wird das folgende "CR" oder "LF" als eigenständiger Befehl interpretiert und liefert "
Unknown Command":
ZitatserialEvent.cmdstring = V
serialEvent.cmdstring = V
serialEvent.cmdstring = V
serialEvent.cmdstring = V
serialEvent.cmdstring = V
serialEvent.cmdstring = V
...
HandleCommand.cmd0=V. Length:1 : Char: V
HandleCommand.cmd1=V. Length:1 : Char: .
HandleCommand.TokenFound: V. Index: 18
HandleCommand.cmdstring = >V<
HandleCommand.cmd0=V. Length:1 : Char: V
HandleCommand.cmd1=V. Length:1 : Char: .
HandleCommand.break: Length=1
V 4.2.0-dev20050z6_juergs SIGNALduino cc1101 (R: Ai B-* C- D-) - compiled at May 24 2020 11:36:19
HandleCommand.cmd0=. Length:0 : Char: .
HandleCommand.cmd1=. Length:0 : Char: .
HandleCommand.cmdstring = ><
...
HandleCommand.cmd0=. Length:0 : Char: .
HandleCommand.cmd1=. Length:0 : Char: .
HandleCommand.i=23 unsupported?
Unsupported command
Das scheint mir ein Manko bei der Eingaberoutine zu sein ... und muss mal über eine Lösungs-Möglichkeit grübeln.... ;)
Ggf. ist aber nur eine Ausprägung beim manuellen Testen und käme "automatisiert" so eigentlich nicht vor ?
Die SerialCommand (https://github.com/kroimon/Arduino-SerialCommand)-Lib scheint mir da besser geeignet und komfortabler zu sein...
Der Unterschied zwischen USBSerial und HardwareSerial? => unterschiedliche Timeoutzeiten?
Ich hab mir mal die optimize Optionen bei der Arduino IDE angeschaut:
-Os
-O1
-O2
-O3
with LTO
-g (debug)verwendet wird beim MapleMini der "arm-none-eabi-c++"
ich hab zu den Optimize-Options folgendes gefunden
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options
ZitatLTO - Link-Time-Optimizations:
Der Linker optimiert den kompletten Code. Da er nicht nur ein Source-File, sondern alle kennt, kann er optimieren, wo dem Compiler Informationen fehlen. Achtung: bei älteren Compiler-Versionen muss nach diesem Flag noch einmal die Optimierungsstufe angegeben werden.
Da beim -Os folgendes steht und das -O0 nicht zur Auswahl steht
Zitat-Os - Optimize for size. -Os enables all -O2 optimizations except those that often increase code size:
müsste eigentlich das -O1 die wenigsten Optimierungen machen.
zu
-g habe ich folgendes gefunden:
ZitatProduce debugging information in the operating system's native format (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging information.
On most systems that use stabs format, -g enables use of extra debugging information that only GDB can use; this extra information makes debugging work better in GDB but probably makes other debuggers crash or refuse to read the program. If you want to control for certain whether to generate the extra information, use -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below).
Kann ich die debug Info irgendwie nutzen um bei einem Absturz den Grund rauszufinden?
Gruß Ralf
ZitatKann ich die debug Info irgendwie nutzen um bei einem Absturz den Grund rauszufinden?
Das erzeugt nur Metafiles die über einen Debugger genutzt werden könnten. Ohne explizite Debugausgaben z.B. Led ein oder sogar ein Muster bei Interrupt-Routinen ein etc. wäre wahrscheinlich
einfacher die Code-Ebene bzw. ein Deadlock einzugrenzen.
Wie Du schon erwähnt hast, bedeuten serielle Debugausgaben auch eine Beeinflussung der Performance.
Schau Dir mal diese Lib dazu an: https://github.com/JoaoLopesF/SerialDebug (https://github.com/JoaoLopesF/SerialDebug)
Die Java-App dazu gibt es leider nicht mehr ... geht aber über Serial-Monitor genauso.
Dort kann man sogar online den Tracelevel ändern und scheint ganz brauchbar zu sein.
ZitatSerialDebug takes care of inputs from serial, and process predefined commands as:
? or help -> display these help of commands
m -> show free memory
n -> set debug level to none
v -> set debug level to verbose
d -> set debug level to debug
i -> set debug level to info
w -> set debug level to warning
e -> set debug level to errors
s -> silence (Not to show anything else, good for analysis)
p -> profiler:
p -> show time between actual and last message (in millis)
p min -> show only if time is this minimal
r -> repeat last command (in each debugHandle)
r ? -> to show more help
reset -> reset the Arduino board
f -> call the function
f ? -> to show more help
dbg [on|off] -> enable/disable the simple software debugger
Only if debugger is enabled:
g -> see/change global variables
g ? -> to show more help
wa -> see/change watches for global variables
wa ? -> to show more help
Not yet implemented:
gpio -> see/control gpio
ich habe für mein angepasstes 00_SIGNALduino.pm ein neues Thema angelegt
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Ich mache gerade ein Dauertest über WLAN ich verwende dafür den Wemos D1 mini als serielle Bridge, die Verbindung läuft stabil ohne Abbrüche oder Aussetzer.
Es gibt dafür eine firmware bei der anstatt USB die erste serielle RX und TX verwendet wird
https://github.com/Ralf9/SIGNALDuino/releases
@Reinhard.M
hast Du inzwischen den MapleSduino zusammengebaut, funktioniert es damit besser?
Zitat von: Ralf9 am 29 Mai 2020, 19:06:20
@Reinhard.M
hast Du inzwischen den MapleSduino zusammengebaut, funktioniert es damit besser?
Hallo Ralf,
ich warte noch auf die Maple Platinen vom Ali. Hatte in der Zwischenzeit weitere Aussetzer des Empfängers auf Modul A, Lacross. Bei selbstheilenden Aussetzern ging der Empfang nach einiger Zeit einfach weiter. Ohne irgendeine Einwirkung von mir. Wenn ich einen solchen Aussetzer beobachtet habe, meist nach mehreren Stunden, brauchte ich den Receiver nur mit einem simplen "get Maple XEA" einschalten und der Empfang ging ebenfalls weiter.
Hatte außerdem wieder "Device Closed" Fehler. Der Maple war also komplett abgeschaltet. Watchdog hatte entweder überhaupt nicht zugeschlagen oder zu spät, so dass der Maple vom FHEM abgehängt wurde. Ein "upload_reset" über Raspi hat ihn nicht wieder auf die Beine gestellt. Mehrfach wiederholt. Erst ein "set Maple reset" über FHEM brachte das Teil wieder zum Laufen. Oftmals mit mehreren Restarts (DISCONNECTED, CONNECTED, DISCONNECTED, ...) kurz nacheinander. Danach aber alles bestens.
Soviel vorab, ich versuche weiterhin aus den Log Daten Auffälligkeiten abzuleiten. Bislang konnte ich noch nichts entdecken. Muss auch noch mehr über Abhängigkeiten im FHEM lernen und verstehen, dauert etwas. Und momentan ist mein Zeitkonto dafür extrem dünn :-\ Ich hoff aber in den kommenden Tagen mehr Zeit zu haben :) Dann werde ich die aufbereiteten Log Daten hier zur Verfügung stellen.
Gruß
Reinhard
Hallo Reinhard,
Zitat
Hatte in der Zwischenzeit weitere Aussetzer des Empfängers auf Modul A, Lacross.
Ich habe hier überhaupt keine Ausetzer, bei Modul A, Lacross.
Ich habe momentan eine uptime von 2 Tagen und 12 Stunden
Ich habe ein "event-min-interval .*:600" gesetzt und im filelog habe ich alle 10 Min einen Eintrag.
Ich habe hier nur einen Lacross Sensor.
Evtl ist bei Dir mehr als ein Lacross Sensor in Reichweite und es kommt zu überlagerungs Effekten
oder es gibt bei Dir ein Problem mit der Hardware mit dem meine Firmware nicht zurecht kommt.
Zitat
Hatte außerdem wieder "Device Closed" Fehler.
Du kannst mal schauen ob Du im Log so was ähnliches findest.
Ich habe in der aktuellen Version vom 00_SIGNALduino Modul was geändert, seither war beim init bei get version ein timeout von 10 sek,
nun erhöht sich bei jedem rety der timeout um 30 sek
2020.05.28 16:01:22.494 3: sduino/KeepAlive not ok, retry = 2 -> get ping
2020.05.28 16:02:22.499 3: sduino/KeepAlive not ok, retry = 3 -> get ping
2020.05.28 16:03:22.499 3: sduino/keepalive not ok, retry count reached. Reset
2020.05.28 16:03:22.499 3: sduino reset
2020.05.28 16:03:22.499 3: Opening sduino device 192.168.0.13:23
2020.05.28 16:03:22.603 1: sduino/define: 192.168.0.13:23
2020.05.28 16:03:22.603 1: sduino/init: 192.168.0.13:23
2020.05.28 16:03:22.603 3: sduino device opened
2020.05.28 16:03:24.105 3: sduino/init: disable receiver (XQ)
2020.05.28 16:03:24.604 3: sduino/init: get version, retry = 0
2020.05.28 16:03:34.617 3: sduino/init: get version, retry = 1
2020.05.28 16:04:14.632 3: sduino/init: get version, retry = 2
2020.05.28 16:05:24.645 3: sduino/init: get version, retry = 3Mir ist auch aufgefallen, daß der Maple Mini mit dem Bootloader 2.0 ein seltsames Verhalten hat.
Nach dem reset funktioniert der serielle Empfang über USB sofort wieder und fällt dann nach sehr kurzer Zeit wieder kurz aus
2020.05.30 09:29:10.001 3 : Setting sduinoRXB serial parameters to 115200,8,N,1
2020.05.30 09:29:10.002 1 : sduinoRXB/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.05.30 09:29:10.002 1 : sduinoRXB/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.05.30 09:29:10.002 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 reappeared (sduinoRXB)
2020-05-30 09:29:10.003 SIGNALduino sduinoRXB CONNECTED
2020.05.30 09:29:10.022 3 : sduinoRXB/noMsg Parse: Reading values from eeprom
2020.05.30 09:29:10.022 3 : sduinoRXB/noMsg Parse: CCInit
2020.05.30 09:29:10.023 3 : sduinoRXB/noMsg Parse: detect A: Partn=0 Ver=24
2020.05.30 09:29:10.025 3 : sduinoRXB/noMsg Parse: detect B: Partn=0 Ver=20
2020.05.30 09:29:10.027 3 : sduinoRXB/noMsg Parse: detect C: Partn=0 Ver=20
2020.05.30 09:29:10.028 3 : sduinoRXB/noMsg Parse: Starting timerjob
2020.05.30 09:29:10.084 3 : sduinoRXB/noMsg Parse: rxA=1 rxB=1 rxC=1
2020.05.30 09:29:11.502 3 : sduinoRXB/init: disable receiver (XQ)
2020.05.30 09:29:11.513 3 : sduinoRXB/noMsg Parse: Unsupported command
2020.05.30 09:29:12.003 3 : sduinoRXB/init: get version, retry = 0
2020.05.30 09:29:13.584 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 disconnected, waiting to reappear (sduinoRXB)
2020-05-30 09:29:13.586 SIGNALduino sduinoRXB DISCONNECTED
2020.05.30 09:29:22.014 3 : sduinoRXB/init: get version, retry = 1
2020.05.30 09:29:30.029 3 : Setting sduinoRXB serial parameters to 115200,8,N,1
2020.05.30 09:29:30.030 1 : sduinoRXB/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.05.30 09:29:30.030 1 : sduinoRXB/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.05.30 09:29:30.030 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 reappeared (sduinoRXB)
2020-05-30 09:29:30.031 SIGNALduino sduinoRXB CONNECTED
2020.05.30 09:29:31.532 3 : sduinoRXB/init: disable receiver (XQ)
2020.05.30 09:29:31.542 3 : sduinoRXB/noMsg Parse: rxA=0 rxB=0 rxC=0
2020.05.30 09:29:32.031 3 : sduinoRXB/init: get version, retry = 0
2020.05.30 09:29:32.041 3 : sduinoRXB/noMsg Parse: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0* C3) - compiled at May 9 2020 19:14:17
2020-05-30 09:29:32.043 SIGNALduino sduinoRXB opened
2020.05.30 09:29:32.054 3 : sduinoRXB/noMsg Parse: r=A b=1 rx=0 ccmode=3 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100 r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07137C43023B900070018146C070090 boffs=0000* r=C b=3 rx=0 N=3 ccmode=3 sync=2DD4 ccconf=216BD0880B0622F853070018166C436891 boffs=0180
2020.05.30 09:29:32.054 2 : sduinoRXB: initialized. v3.4.5-dev_ralf_05.28.
2020.05.30 09:29:32.064 3 : sduinoRXB/init: enable receiver (XE)
2020.05.30 09:29:32.065 3 : sduinoRXB/noMsg Parse: rxA=1 rxB=1 rxC=1 Gruß Ralf
Hallo Ralf,
danke für das schnelle Feedback. Wie gesagt möchte ich brauchbares Feedback liefern aber dafür brauche ich noch Zeit. Gerade bei den Funkprotokollen bin ich quasi noch bei null und muss mir noch einiges anlesen. Vom FHEM Wiki und Forum abgesehen weiß ich allerdings noch nicht wo. Muss halt suchen. Falls du mir einen Tipp geben kannst - herzlichen Dank :)
Mein Lacross jagt alle 4 Sekunden ein Telegram raus, scheint aber der einzige Sender dieser Art zu sein. Konnte bislang jedenfalls keinen anderen entdecken.
Seit ich den Watchdog aktiviert habe sehe ich den von dir gezeigten 2020.05.28 16:03:22.499 3: sduino reset nicht mehr. Wohl aber ein "disconnected/connected". Ich werde mal den Watchdog Timer hochdrehen auf 15 Sekunden, derzeit steht er noch auf 5 Sekunden.
Ich verwende den MSC_Bootloader von Telekatz und nicht den Bootloader_2.0, der 2.0 sollte also keinen Einfluss haben. Aber dein letzter Codeschnipsel 2020-05-30 09:29:13.586 SIGNALduino sduinoRXB DISCONNECTED
2020-05-30 09:29:30.031 SIGNALduino sduinoRXB CONNECTED kommt mir sehr bekannt vor. So ähnlich sieht es bei mir auch aus. Teilweise mehrfach nacheinander.
Bitte noch ein wenig Geduld, ich möchte das vernünftig dokumentieren damit ihr mit den Informationen auch etwas anfangen könnt.
Hallo Ralf,
ich habe jetzt einen recht stabilen Fehlerfall dokumentiert, eventuell kannst du aus den angehängten Daten erkennen.
Ich verwende den Maple auch für die Rollosteuerung in meinem Haus. Sobald ein Steuerbefehl raus geht ruft das einen Reset des Maples hervor. So massiv ist es mir bislang nicht aufgefallen. Allerdings habe ich heute den Watchdog Timer von 4s auf 20s gesetzt und dafür die v4.1.1 neu kompiliert:
Zitat
#define MAPLE_CUL 1
V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
Hier noch die komplette Aufzeichnung eines solchen Absturz:
2020.05.31 23:59:32.485 3: myMaple: SingleJaro set up 7
2020.05.31 23:59:32.485 4: myMaple/set: sending via SendMsg: SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121232451512451242451242451512424245124515124512451515124245124245151512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.05.31 23:59:32.487 SingleJaro LastAction_Channel_07: up
2020.05.31 23:59:32.487 SingleJaro button: up
2020.05.31 23:59:32.487 SingleJaro channel: 7
2020.05.31 23:59:32.487 SingleJaro channel_control: no
2020.05.31 23:59:32.487 SingleJaro counter_send: 8521
2020.05.31 23:59:32.487 SingleJaro state: send up
2020.05.31 23:59:32.595 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121232451512451242451242451512424245124515124512451515124245124245151512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.05.31 23:59:32.595 4: myMaple/msg READ: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.05.31 23:59:32.596 3: myMaple/noMsg Parse: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.05.31 23:59:32.596 4: myMaple/msg READ: 1. Received answer (V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05) for sendraw does not match ^S(R|C|M|N);
2020.05.31 23:59:34.596 4: myMaple/HandleWriteQueue: nothing to send, stopping timer
2020.05.31 23:59:34.596 4: myMaple/HandleWriteQueue: sendraw no answer (timeout)
2020.05.31 23:59:35.319 4: myMaple/msg READ: MU;P0=-6472;P1=1116;P2=3172;CP=1;R=230;D=010202020202010101020201020202010102020202010201010102020202020101020202020102020201;e;
2020.05.31 23:59:35.752 4: myMaple/msg READ: MU;P0=-6496;P1=3144;P2=1111;CP=2;R=230;D=01020101010101020202010102010101020201010101020102020201010101010202010101010201010102;e;
2020.05.31 23:59:35.928 4: myMaple Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.05.31 23:59:35.928 4: myMaple/msg READ: MN;D=9205393F3BAAAA0000AF52BA;R=221;
2020.05.31 23:59:35.929 4: myMaple Dispatch: OK 9 8 1 4 115 63, -91.5 dB, dispatch
2020.05.31 23:59:35.929 4: myMaple LaCrosse_convert: ID=100, addr=8 temp=13.9 hum=63 bat=0 batInserted=0
2020.05.31 23:59:35.929 4: myMaple ParseMN: ID=100 dmsg=OK 9 8 1 4 115 63
2020.05.31 23:59:36.069 3: myMaple: SingleJaro set stop 7
2020.05.31 23:59:36.069 4: myMaple/set: sending via SendMsg: SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151242451242424515151515151515124245151242424512424515124245151512424515151515151515151245124515151515124245151245151515151245151515151515151516;
2020.05.31 23:59:36.074 SingleJaro LastAction_Channel_07: stop
2020.05.31 23:59:36.074 SingleJaro button: stop
2020.05.31 23:59:36.074 SingleJaro channel: 7
2020.05.31 23:59:36.074 SingleJaro channel_control: no
2020.05.31 23:59:36.074 SingleJaro counter_send: 8522
2020.05.31 23:59:36.074 SingleJaro state: send stop
2020.05.31 23:59:36.179 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151242451242424515151515151515124245151242424512424515124245151512424515151515151515151245124515151515124245151245151515151245151515151515151516;
2020.05.31 23:59:36.553 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 disconnected, waiting to reappear (myMaple)
2020.05.31 23:59:36.555 myMaple DISCONNECTED
2020.05.31 23:59:36.800 SD_WS_85_THW_1 myRD: myMaple T: 11.8 H: 72 W: 0
2020.05.31 23:59:38.180 4: myMaple/HandleWriteQueue: sendraw no answer (timeout)
2020.05.31 23:59:38.181 4: myMaple/HandleWriteQueue: nothing to send, stopping timer
2020.05.31 23:59:38.628 3: Setting myMaple serial parameters to 115200,8,N,1
2020.05.31 23:59:38.632 1: myMaple/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.05.31 23:59:38.632 1: myMaple/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.05.31 23:59:38.633 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 reappeared (myMaple)
2020.05.31 23:59:38.634 myMaple CONNECTED
2020.05.31 23:59:38.654 4: myMaple/msg READ: Reading values from eeprom
2020.05.31 23:59:38.655 3: myMaple/noMsg Parse: CCInit
2020.05.31 23:59:38.655 3: myMaple/noMsg Parse: Reading values from eeprom
2020.05.31 23:59:38.655 3: myMaple/noMsg Parse: detect A: Partn=0 Ver=20
2020.05.31 23:59:38.655 4: myMaple/msg READ: CCInit
2020.05.31 23:59:38.655 4: myMaple/msg READ: detect A: Partn=0 Ver=20
2020.05.31 23:59:38.657 3: myMaple/noMsg Parse: detect B: Partn=0 Ver=24
2020.05.31 23:59:38.657 4: myMaple/msg READ: detect B: Partn=0 Ver=24
2020.05.31 23:59:38.658 3: myMaple/noMsg Parse: Starting timerjob
2020.05.31 23:59:38.658 4: myMaple/msg READ: Starting timerjob
2020.05.31 23:59:38.712 3: myMaple/noMsg Parse: rxA=1 rxB=1
2020.05.31 23:59:38.712 4: myMaple/msg READ: rxA=1 rxB=1
2020.05.31 23:59:39.990 4: myMaple/msg READ: MN;D=9205393F3BAAAA0000D36BA8;R=222;
2020.05.31 23:59:39.991 4: myMaple LaCrosse_convert: ID=100, addr=8 temp=13.9 hum=63 bat=0 batInserted=0
2020.05.31 23:59:39.991 4: myMaple ParseMN: ID=100 dmsg=OK 9 8 1 4 115 63
2020.05.31 23:59:39.991 4: myMaple Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.05.31 23:59:39.992 4: myMaple Dispatch: OK 9 8 1 4 115 63, -91 dB, dispatch
2020.05.31 23:59:40.133 3: myMaple/init: disable receiver (XQ)
2020.05.31 23:59:40.416 3: myMaple/noMsg Parse: Unsupported command
2020.05.31 23:59:40.416 4: myMaple/msg READ: Unsupported command
2020.05.31 23:59:40.633 3: myMaple/init: get version, retry = 0
2020.05.31 23:59:40.644 4: myMaple/msg READ: OK
2020.05.31 23:59:40.645 4: myMaple/msg READ: 2. Received answer (OK) for version does not match V\s.*SIGNAL(duino|ESP).*
2020.05.31 23:59:40.645 4: myMaple/noMsg Parse: OK
2020.05.31 23:59:41.305 3: myMaple/noMsg Parse: 10948
2020.05.31 23:59:41.305 4: myMaple/msg READ: 10948
2020.05.31 23:59:41.305 4: myMaple/msg READ: 3. Received answer (10948) for version does not match V\s.*SIGNAL(duino|ESP).*
2020.05.31 23:59:44.036 3: myMaple/noMsg Parse: Unsupported command
2020.05.31 23:59:44.036 4: myMaple/msg READ: Unsupported command
2020.05.31 23:59:44.037 1: myMaple: Not an SIGNALduino device, setting attribute dummy=1 got for V: Unsupported command
2020.05.31 23:59:44.039 myMaple state: no SIGNALduino found
2020.05.31 23:59:44.047 2: myMaple closed
2020.05.31 23:59:44.050 myMaple state: closed
2020.05.31 23:59:44.056 di_myMaple state: closed, reset device
2020.05.31 23:59:45.054 3: Opening myMaple device /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00
2020.05.31 23:59:45.054 3: myMaple reset
2020.05.31 23:59:45.055 1: myMaple: Can't open /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00: Device or resource busy
2020.05.31 23:59:45.056 myMaple reset
2020.06.01 00:00:04.849 3: Setting myMaple serial parameters to 115200,8,N,1
2020.06.01 00:00:04.853 1: myMaple/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.06.01 00:00:04.853 1: myMaple/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.06.01 00:00:04.854 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 reappeared (myMaple)
2020.06.01 00:00:04.856 myMaple CONNECTED
2020.06.01 00:00:06.354 3: myMaple/init: disable receiver (XQ)
2020.06.01 00:00:06.365 4: myMaple/msg READ: rxA=0 rxB=0
2020.06.01 00:00:06.366 3: myMaple/noMsg Parse: rxA=0 rxB=0
2020.06.01 00:00:06.366 4: myMaple/msg READ: 1. Received answer (rxA=0 rxB=0 ) for version does not match V\s.*SIGNAL(duino|ESP).*
2020.06.01 00:00:06.854 3: myMaple/init: get version, retry = 0
2020.06.01 00:00:06.866 3: myMaple/noMsg Parse: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.06.01 00:00:06.866 4: myMaple/msg READ: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.06.01 00:00:06.868 myMaple state: opened
2020.06.01 00:00:06.874 di_myMaple state: opened, set patable 10dBm
2020.06.01 00:00:06.884 4: myMaple/init: firmwareversion with ccBankSupport and multi cc1101 found
2020.06.01 00:00:06.895 4: myMaple/msg READ: r=A b=1 rx=0 ccmode=4 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100 r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000*
2020.06.01 00:00:06.896 3: myMaple/noMsg Parse: r=A b=1 rx=0 ccmode=4 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100 r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000*
2020.06.01 00:00:06.896 4: myMaple/init: Write ccBankInfo: (r=A b=1 rx=0 ccmode=4 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100 r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000*) to Internal ccconf
2020.06.01 00:00:06.897 2: myMaple: initialized. v3.4.5-dev_ralf_05.24.
2020.06.01 00:00:06.907 3: myMaple/init: enable receiver (XE)
2020.06.01 00:00:06.908 3: myMaple/noMsg Parse: rxA=1 rxB=1
2020.06.01 00:00:06.908 4: myMaple/msg READ: rxA=1 rxB=1
2020.06.01 00:00:08.307 SD_WS_85_THW_1 myRD: myMaple T: 11.8 H: 72 W: 0
2020.06.01 00:00:10.875 myMaple cc1101_patable_433 10_dBm
2020.06.01 00:00:12.499 LaCrosse_08 myRD: myMaple T: 13.8 H: 63
2020.06.01 00:00:16.561 LaCrosse_08 myRD: myMaple T: 13.9 H: 63
2020.06.01 00:00:24.699 LaCrosse_08 myRD: myMaple T: 13.8 H: 63
2020.06.01 00:00:28.756 LaCrosse_08 myRD: myMaple T: 13.9 H: 63
2020.06.01 00:00:32.820 LaCrosse_08 myRD: myMaple T: 13.8 H: 63
Ich hoffe diese Daten helfen etwas weiter. Momentan habe ich den Verbose Level des Maples auf 4 gesetzt, sollte es nötig sein kann ich es mit 5 wiederholen.
Gruß Reinhard
es sieht so aus als würde kurz nach dem Senden der watchdog auslösen
2020.05.31 23:59:32.595 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121232451512451242451242451512424245124515124512451515124245124245151512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.05.31 23:59:32.595 4: myMaple/msg READ: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.05.31 23:59:32.596 3: myMaple/noMsg Parse: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
2020.05.31 23:59:32.596 4: myMaple/msg READ: 1. Received answer (V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05) for sendraw does not match ^S(R|C|M|N);
2020.05.31 23:59:34.596 4: myMaple/HandleWriteQueue: nothing to send, stopping timer
2020.05.31 23:59:34.596 4: myMaple/HandleWriteQueue: sendraw no answer (timeout)
2020.05.31 23:59:35.319 4: myMaple/msg READ: MU;P0=-6472;P1=1116;P2=3172;CP=1;R=230;D=010202020202010101020201020202010102020202010201010102020202020101020202020102020201;e;
2020.05.31 23:59:35.752 4: myMaple/msg READ: MU;P0=-6496;P1=3144;P2=1111;CP=2;R=230;D=01020101010101020202010102010101020201010101020102020201010101010202010101010201010102;e;
2020.05.31 23:59:35.928 4: myMaple Parse_MN: Found 2-FSK Protocol id 100 -> Lacrosse mode 1
2020.05.31 23:59:35.928 4: myMaple/msg READ: MN;D=9205393F3BAAAA0000AF52BA;R=221;
2020.05.31 23:59:35.929 4: myMaple Dispatch: OK 9 8 1 4 115 63, -91.5 dB, dispatch
2020.05.31 23:59:35.929 4: myMaple LaCrosse_convert: ID=100, addr=8 temp=13.9 hum=63 bat=0 batInserted=0
2020.05.31 23:59:35.929 4: myMaple ParseMN: ID=100 dmsg=OK 9 8 1 4 115 63
2020.05.31 23:59:36.069 3: myMaple: SingleJaro set stop 7
2020.05.31 23:59:36.069 4: myMaple/set: sending via SendMsg: SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151242451242424515151515151515124245151242424512424515124245151512424515151515151515151245124515151515124245151245151515151245151515151515151516;
2020.05.31 23:59:36.074 SingleJaro LastAction_Channel_07: stop
2020.05.31 23:59:36.074 SingleJaro button: stop
2020.05.31 23:59:36.074 SingleJaro channel: 7
2020.05.31 23:59:36.074 SingleJaro channel_control: no
2020.05.31 23:59:36.074 SingleJaro counter_send: 8522
2020.05.31 23:59:36.074 SingleJaro state: send stop
2020.05.31 23:59:36.179 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151242451242424515151515151515124245151242424512424515124245151512424515151515151515151245124515151515124245151245151515151245151515151515151516;
2020.05.31 23:59:36.553 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 disconnected, waiting to reappear (myMaple)
2020.05.31 23:59:36.555 myMaple DISCONNECTED
Der watchdog muss regelmässig getriggert werden, damit er nicht auslöst, evtl passt da etwas noch nicht so ganz
Seltsam ist, daß fast zeitgleich mit dem Senden die Antwort von einem "get version" empfangen wird:
2020.05.31 23:59:32.595 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121232451512451242451242451512424245124515124512451515124245124245151512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.05.31 23:59:32.595 4: myMaple/msg READ: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A1 B0*) - compiled at May 31 2020 20:36:05
Zitat von: Ralf9 am 01 Juni 2020, 10:19:16
es sieht so aus als würde kurz nach dem Senden der watchdog auslösen
Der watchdog muss regelmässig getriggert werden, damit er nicht auslöst, evtl passt da etwas noch nicht so ganz
Ich hatte den Watchdog von 4 auf 20 Sekunden hochgesetzt. Eventuell habe ich den Timer überzogen, ich habe noch nicht herausgefunden wie hoch ich ihn maximal stellen kann. Mit 4 Sekunden ist das Verhalten nicht zu sehen, das habe ich gerade nochmals getestet.
Bislang wird der WD nur in der Hauptschleife getriggert, also so, wie es momentan im 'SIGNALDuino.ino' schon vorgegeben ist. Und mit 4 Sekunden lief auch alles problemlos.
Zitat von: Ralf9 am 01 Juni 2020, 10:19:16
Seltsam ist, daß fast zeitgleich mit dem Senden die Antwort von einem "get version" empfangen wird:
Auf mich macht es den Eindruck, dass in der Message Queue etwas hängen bleibt. Der Maple fliegt ja quasi mit dem Senden der Message raus:
2020.06.01 00:57:36.980 3: myMaple: SingleJaro set up 7
2020.06.01 00:57:37.080 5: myMaple SW: SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151515124515124512424242451512424515124512451515124512424512451512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.06.01 00:57:37.090 4: myMaple SendrawFromQueue: msg=SR;R=5;P0=1520;P1=-400;P2=400;P3=-4000;P4=-800;P5=800;P6=-16000;D=01212121212121212121212121235151515124515124512424242451512424515124512451515124512424512451512424515151515151515151245124515151515124245151245151515151512451515151515151516;
2020.06.01 00:57:37.609 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 disconnected, waiting to reappear (myMaple)
Zwischen Senden und Disconnect liegt nicht einmal eine Sekunde, das lässt sich tatsächlich jederzeit reproduzieren. Etwa 4 Sekunden später folgt dann die merkwürdige Versionsabfrage (der IWDG ist hier auf ~20s eingestellt). Und was könnte das mit dem Setting des IWDG zu tun haben?
ZitatIch hatte den Watchdog von 4 auf 20 Sekunden hochgesetzt. Eventuell habe ich den Timer überzogen, ich habe noch nicht herausgefunden wie hoch ich ihn maximal stellen kann.
@Telekatz :
weisst Du zufällig wie hoch man den Watchdogtimer setzen kann?
Verwendest Du bei der a-culw einen Watchdog? Wie hoch hast Du ihn gesetzt?
ZitatMit 4 Sekunden ist das Verhalten nicht zu sehen, das habe ich gerade nochmals getestet.
4 Sekunden sollten eigentlich reichen, gibt es bei 4 sek noch Probleme?
Mit dem Watchdog habe ich mich noch nicht beschäftigt.
Hast Du mir mal den Code wie Du den Watchdog aktivierst?
Hast Du im Internet eine Beschreibung darüber gefunden?
Gruß Ralf
Zitat von: Ralf9 am 01 Juni 2020, 11:38:33
4 Sekunden sollten eigentlich reichen, gibt es bei 4 sek noch Probleme?
Ich hatte es auf 20 Sekunden gesetzt um dein Timout von 10 Sekunden im "00_SIGNALDuiono.pm " zu überschreiten. Mit 4 sek gibt es keine Probleme dieser Art. Ich werde mal testen ob die 20 sek das Problem sind, also ob 15 sek z.B. noch funktionieren.
Zitat
Mit dem Watchdog habe ich mich noch nicht beschäftigt.
Hast Du mir mal den Code wie Du den Watchdog aktivierst?
Hast Du im Internet eine Beschreibung darüber gefunden?
Im SIGNALDuino.ino gibt es folgende Änderungen von mir:
#define WATCHDOG 1 // Der Watchdog ist in der Entwicklungs und Testphase deaktiviert. Es muss auch ohne Watchdog stabil funktionieren.
#ifdef WATCHDOG
// #include <avr/wdt.h>
// #define WDTO 25000 // 25000 entspricht ~20 Sekunden
// #define WDTO 5000 // 5000 entspricht ~4 Sekunden
#define WDTO 2500 // 2500 entspricht ~2 Sekunden
#include "wdt.h"
#endif
#ifdef WATCHDOG
/*
if (MCUSR & (1 << WDRF)) {
MSG_PRINTLN(F("Watchdog caused a reset"));
}
if (MCUSR & (1 << BORF)) {
DBG_PRINTLN("brownout caused a reset");
}
if (MCUSR & (1 << EXTRF)) {
DBG_PRINTLN("external reset occured");
}
if (MCUSR & (1 << PORF)) {
DBG_PRINTLN("power on reset occured");
}
*/
//wdt_reset();
iwdg_feed();
//wdt_enable(WDTO_2S); // Enable Watchdog
iwdg_init(WDTO);
#endif
#ifdef WATCHDOG
//wdt_reset();
iwdg_feed();
#endif
#ifdef WATCHDOG
//wdt_reset();
iwdg_feed();
#endif
Wenn du im Code nach WATCHDOG suchst findest du die Einträge schnell. Aus dem Netz habe ich folgenden Link verwendet:
https://www.stm32duino.com/viewtopic.php?f=7&t=190&p=1350&hilit=watchdog#p1350 (https://www.stm32duino.com/viewtopic.php?f=7&t=190&p=1350&hilit=watchdog#p1350)
Für den STM32 Watchdog gibt es aber einiges mehr.
Danke, habe damit die Beschreibung vom watchdog gefunden
https://github.com/stm32duino/Arduino_Core_STM32/tree/master/libraries/IWatchdog
Hier ist die Maximal timeout definiert:
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/libraries/IWatchdog/src/IWatchdog.h
// Maximal timeout in microseconds
#define IWDG_TIMEOUT_MAX (((256*1000000)/LSI_VALUE)*IWDG_RLR_RL)
Dann lag ich mit meinen 20 sek ja noch locker im Range. Hatte vorhin den Code ganz vergessen:
#ifndef _WDT_H_
#define _WDT_H_
#include <stdint.h>
#define IWDG_PR_DIV_4 0x0
#define IWDG_PR_DIV_8 0x1
#define IWDG_PR_DIV_16 0x2
#define IWDG_PR_DIV_32 0x3
#define IWDG_PR_DIV_64 0x4
#define IWDG_PR_DIV_128 0x5
#define IWDG_PR_DIV_256 0x6
void iwdg_feed(void) {
IWDG->KR = 0xAAAA;
}
void iwdg_init(uint16_t reload) {
IWDG->KR = 0x5555;
IWDG->PR = IWDG_PR_DIV_32;
IWDG->RLR = reload;
IWDG->KR = 0xCCCC;
IWDG->KR = 0xAAAA;
}
#endif /* _WDT_H_ */
Auch mit dem 32er Vorteiler sollte der 25000er reload Wert immer noch passen.
ich hatte es schon befürchtet, ich habe heute auf den core 1.9.0 geupdatet, damit funktioniert das USBD_reenumerate mit dem Bootloader2.0 auch nicht :(
Der workaround mit der "USBD_reenumerate.c" funktioniert auch nicht mehr.
Lösch die "USBD_reenumerate.c" aus dem Projektverzeichnis. Dann funktioniert es auch mit dem core 1.9.0.
Hab ich gemacht, es funktioniert aber trotzdem nicht.
Ich verwende den ungepatchten Bootloader2.0 und
Board part number: Gerneric F103CB
der Maple Mini steht nicht mehr zur auswahl
Bei mir ist der Maple Mini immer noch auswählbar. Das Generic F103CB ist das falsche Board.
Ja, ich hab den mapleMini Eintrag inzwischen auch gefunden, meine Bildschirmauflösung ist dafür anscheinend zu klein.
Das Auswahlfeld hat bei mir unten keinen Pfeil
Meine Auflösung ist nur 1920 * 1080.
Nachdem ich den MapleMini Eintrag ausgewählt habe, funktioniert nun auch das USBD_reenumerate wieder :)
Hallo,
könnt ihr mir dann mal kurz helfen, habe auch auf die aktuelle V1.9.0 geupdatet, vorher lief alles einwandfrei, AdruinoIDE ist die 1.8.12.
Sketch alles gleich zu vorher, bekomme mit der 1.9.0 folgenden Fehler:
P.S.: Hab die Einstellungen noch angehängt ;)
Beim core 1.9.0 gab es bei der Timer Interrupt Routine eine Änderung
alt
void cronjob(HardwareTimer*) {
neu
void cronjob() {
oder
#ifdef MAPLE_Mini
#if ARDUINO < 190
void cronjob(HardwareTimer*) {
#else
void cronjob() {
#endif
noInterrupts();
#else
void cronjob() {
cli();
#endif
Ich mache heute Abend einen Commit mit den Änderungen, ich habe auch vor den Watchdog einzubauen
Zitat von: Ralf9 am 02 Juni 2020, 17:07:21
Ich mache heute Abend einen Commit mit den Änderungen, ich habe auch vor den Watchdog einzubauen
Das mit dem Watchdog höre ich gerne :)
Da ich mich im Maple-Code nicht sonderlich auskenne hatte ich keine Debug Messages für den WD hinzugefügt. Wirst du das entsprechend einfügen?
hab die notwendigen Änderungen für den core 1.9.0 und den watchdog commited
https://github.com/Ralf9/SIGNALDuino/commit/035416ca079c59a4ba2884f0a6372a0ac4dbaee7
Ich muß bei meinem angepassten 00_Signalduino Modul noch bei der Init Routine noch was optimieren.
https://forum.fhem.de/index.php/topic,111061.msg1060120.html#msg1060120
Im FHEM Code sind das Zeilen 3882 und 3932 +/-1.
Der Vollständigkeit halber:
my $osv2byte = "";
$osv2byte=NULL;
$osv2byte=substr($bitData,$idx,16);
->
my $osv2byte = substr($bitData, $idx, 16);
und
my $osv3nibble = "";
$osv3nibble=NULL;
$osv3nibble=substr($bitData,$idx,4);
->
my $osv3nibble = substr($bitData, $idx, 4);
k.A. wen da was geritten hat.
ZitatIm FHEM Code sind das Zeilen 3882 und 3932 +/-1.
Der Vollständigkeit halber:
Danke für den Hinweis, werde ich in meinem angepassten 00_Signalduino Modul korrigieren.
Sidey ist gerade dabei das 00_Signalduino Modul zu überarbeiten, da ist es schon korrigiert
https://github.com/RFD-FHEM/RFFHEM/blob/feaa3f38f3bf58db049218aa9f79eed406627bce/FHEM/lib/SD_Protocols.pm#L873
Zitatk.A. wen da was geritten hat.
Da wird sich Sidey wahrscheinlich nicht mehr daran erinnern was er da vor ca 5 Jahren programmiert hat :)
Zitat von: Ralf9 am 03 Juni 2020, 19:32:07
Danke für den Hinweis, werde ich in meinem angepassten 00_Signalduino Modul korrigieren.
Sidey ist gerade dabei das 00_Signalduino Modul zu überarbeiten, da ist es schon korrigiert
https://github.com/RFD-FHEM/RFFHEM/blob/feaa3f38f3bf58db049218aa9f79eed406627bce/FHEM/lib/SD_Protocols.pm#L873
Hm. Mein Vorschlag ist besser.
my $x = 0;
$x = 5;
... da muss ich doch an Helmut Kohl denken: "Wichtig ist, was hinten rauskommt."
kurzer Zwischenstand, so wies aussieht läufts mit dem core 1.9.0 stabiler.
Ich habe mit der LAN Version inzwischen eine uptime von fast 12 Stunden
Habe die neue Version ebenfalls auf 1.9.0 compiliert und auf meinem MapleCUL installiert. Mal sehen wie sie bei mir läuft. Eine Frage zur Anzeige des "wr". Wird es bei einem WD-Reset immer mit der Version ausgegeben oder nur beim ersten Mal auslesen?
ZitatEine Frage zur Anzeige des "wr". Wird es bei einem WD-Reset immer mit der Version ausgegeben oder nur beim ersten Mal auslesen?
Es wird nach einem WD-Reset solange das "wr" in der Version ausgegeben bis ein normaler Reset erfolgt.
Hallo Ralf,
der Watchdog funktioniert:
V 4.1.1-dev200603 SIGNALduino cc1101 (R: A1 B0*) wr - compiled at Jun 4 2020 17:01:52
Kam nach ca. 3 Stunden, lief davor aber schon mal 15 Stunden. Sporadisch halt.
Ich hab für die Version V 4.1.1-dev200603 nun auch bin-Files erstellt, sie sind mit dem core 1.9.0 compiliert
https://github.com/Ralf9/SIGNALDuino/releases
Ich habe auch mein angepasstes 00_SIGNALduino Modul erweitert und optimiert
https://github.com/Ralf9/RFFHEM/commit/356f85ce5ec8f801e8940ddb743c7ef4580c6103
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Ich teste grad die LAN Version
Zuerst hatte ich ein uptime von 1 Tag und 14 Stunden,
dann habe ich mit einem andern MapleSduino weiter getestet, da habe ich bis jetzt eine uptime von 1 Tag und 2 Stunden
ZitatKam nach ca. 3 Stunden, lief davor aber schon mal 15 Stunden. Sporadisch halt.
@Reinhard.M
kannst Du die Stromversorgung als Ursache ausschließen?
Sind auf der MapleCul Platine Kondensatoren, z.B. 10uF?
Gruß Ralf
Hallo,
nach etwas längerem Warten habe ich die Teile für den maple-mini erhalten (STM 32F 103 CBT6 ) und zusammen gelötet.
Nach dem Versuch den bootloader auf die Version "maple_mini_boot20.bin" zu flashen funktioniert USB nicht mehr. Ich habe sehr viel gelesen und und über den Seriellen Port probiert, bisher leider ohne Erfolg.
Wer kann mir helfen?
Gruß
Rolf
War das flashen des "maple_mini_boot20.bin" erfolgreich?
Welche Anleitung hast Du dazu verwendet?
Nachtrag:
Hier z.B. ist eine Anleitung
https://wiki.fhem.de/wiki/MapleCUN
und hier noch eine
https://taillieu.info/index.php/hardware/microprocessors/302-maple-mini-serial-programming-and-upgrading-to-bootloader-2-0
Hallo Ralf,
vielen Dank für die schnelle Antwort/Frage.
Wir haben das flashen mit verschiedenen Verfahren bzw. Anleitungen probiert.
Mit dm FTDI Adapter und Python konnte der boot-loader erfolgreich geflasht und verifiziert werden. Leider funktionierte USB am Raspberry und Windows-PC nicht.
Da ich mit dem Python noch nicht so vertraut bin, habe ich danach mit
- FTDI Adapter am Windows PC mit Arduino IDE 1.8 und
- Raspberry (serieller Port) How To: STM32F103C8T6 As An USB Device ( Virtual Serial Port / CDC ) (https://www.youtube.com/watch?v=YZjnCOun1wU)
probiert zu flashen.
Mit Arduino gab es am Schluss die Fehlermeldung
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
dfu-util - (C) 2007-2008 by OpenMoko Inc.
Couldn't find the DFU device: [1EAF:0003]
This program is Free Software and has ABSOLUTELY NO WARRANTY
Am Rasp kam ich mit den Angaben zum boot-loader nicht klar, http://github..... und Name , siehe Anhang.
Gruß
Rolf
Mit Windows kann ich nicht weiterhelfen, ich habe Linux verwendet.
Bei mir funktioniert das flashen nur mit Rootrechten
./stm32flash -w maple_mini_boot20.bin -v /dev/ttyUSB0
evtl ist vorher noch ein "-k Disable the flash read-protection" notwendig:
./stm32flash -k /dev/ttyUSB0
Es kann sein, daß das firmware flashen auch nur mit Rootrechten funktioniert
entweder mit
./maple_upload ttyACM0 2 1EAF:0003 Maple_sduino_USB_411dev200603.bin
oder
./dfu-util -v -d 1eaf:0003 -a 2 -D Maple_sduino_USB_411dev200603.bin -R
Beim dfu-util muß man kurz vorher Reset drücken
Zitat von: Ralf9 am 06 Juni 2020, 22:51:27
@Reinhard.M
kannst Du die Stromversorgung als Ursache ausschließen?
Sind auf der MapleCul Platine Kondensatoren, z.B. 10uF?
Hallo Ralf,
ich habe mal zwischen die Basis und Maple Platinen geschaut und konnte kein C entdecken. Gänzlich ausschließen kann ich die Stromversorgung natürlich nicht. Da müsste ich mit dem Oszi mal drauf schauen. Bei einem Spannungseinbruch hätte es aber einen Power-On Reset und keinen WD-Reset gegeben. Seit 1,5 Tagen läuft der Maple auch gerade ohne Probleme.
Zitat von: nagelreo am 08 Juni 2020, 00:00:45
vielen Dank für die schnelle Antwort/Frage.
Wir haben das flashen mit verschiedenen Verfahren bzw. Anleitungen probiert.
Mit dm FTDI Adapter und Python konnte der boot-loader erfolgreich geflasht und verifiziert werden. Leider funktionierte USB am Raspberry und Windows-PC nicht.
Aktivier den DFU Bootloader manuell. Board an USB anstecken, Reset drücken und unmittelbar nach dem loslassen der Resettaste die Taste but=32 für etwa 1 Sekunde drücken. Der Maple blinkt dann vor sich hin. Danach ganz normal in der Arduino IDE den Sketch hochladen. Welchen COM Port man dabei in der IDE auswählt ist dabei egal.
Irgendwas passt bei dem UsbSerial noch nicht so richtig.
Bei ca jedem 5 - 10 ten Reset kommt beim UsbSerial was durcheinander. Da ist im log auch das USBD_reenumerate zu sehen.
Zwischen dem ersten CONNECTED und DISCONNECTED wird das gesendete XQ vom Maple noch nicht erkannt
cmd(9) = AT^SQPOXQ
cmd(3) = RT?
sieht ohne das XQ so aus (Query Port Type), kommt dies vom Linux Betriebsystem?
cmd(10) = AT^SQPORT?
Nach dem zweiten CONNECTED ist was durcheinander,
Als Antwort zu "XQ" kommt "Unsupported command"
Als Antwort zu "V" kommt die Antwort vom "XQ": "rxA=0 rxB=0 rxC=0"
Bei allen nachfolgenden gesendeten Befehlen ist es dann genauso, daß anstatt des gesendeten Befehl von Maple der zuvor gesendete Befehl empfangen wird!
Dies lässt sich nur durch einen Reset beheben.
2020.06.08 17:54:08.088 3 : Setting sduino serial parameters to 115200,8,N,1
2020.06.08 17:54:08.089 1 : sduino/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.06.08 17:54:08.089 1 : sduino/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.06.08 17:54:08.089 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 reappeared (sduinoRXB)
2020-06-08 17:54:08.090 SIGNALduino sduino CONNECTED
2020.06.08 17:54:08.100 3 : sduino/noMsg Parse: Watchdog enabled
...
2020.06.08 17:54:08.103 3 : sduino/noMsg Parse: detect B: Partn=0 Ver=20
2020.06.08 17:54:08.162 3 : sduino/noMsg Parse: rxA=1 rxB=1 rxC=1
2020.06.08 17:54:09.589 3 : sduino/init: disable receiver (XQ)
2020.06.08 17:54:09.590 3 : sduino SW: XQ
2020.06.08 17:54:09.600 3 : sduino/noMsg Parse: Unsupported command
2020.06.08 17:54:09.996 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 disconnected, waiting to reappear (sduinoRXB)
2020-06-08 17:54:09.998 SIGNALduino sduinoRXB DISCONNECTED
2020.06.08 17:54:32.007 3 : Setting sduino serial parameters to 115200,8,N,1
2020.06.08 17:54:32.007 1 : sduino/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.06.08 17:54:32.007 1 : sduino/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00@115200
2020.06.08 17:54:32.007 1 : /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7452895051-if00 reappeared (sduinoRXB)
2020-06-08 17:54:32.009 SIGNALduino sduino CONNECTED
2020.06.08 17:54:33.508 3 : sduino/init: disable receiver (XQ)
2020.06.08 17:54:33.508 3 : sduino SW: XQ
2020.06.08 17:54:33.519 3 : sduino/noMsg Parse: Unsupported command
2020.06.08 17:54:34.008 3 : sduino/init: get version, retry = 0
2020.06.08 17:54:34.008 3 : sduino SW: V
2020.06.08 17:54:34.018 3 : sduino/noMsg Parse: rxA=0 rxB=0 rxC=0
Ich habe bei der serialEvent Routine eine serielle debug Ausgabe eingebaut:
void serialEvent()
{
while (MSG_PRINTER.available())
{
char inChar = (char)MSG_PRINTER.read();
Serial2.println((uint8_t)inChar);
switch(inChar)
{
case '\n':
case '\r':
case '\0':
case '#':
command_available=true;
Serial2.print("cmd(");
Serial2.print(cmdstring.length());
Serial2.print(") = ");
Serial2.println(cmdstring);
break;
default:
cmdstring += inChar;
}
if (cmdstring.length() > maxCmdString)
{
cmdstring = ""; // todo die restlichen Zeichen ignorieren
MSG_PRINT(F("cmd to long! (max "));
MSG_PRINT(maxCmdString);
MSG_PRINTLN(F(")"));
}
}
}
79
88
81
10
cmd(9) = AT^SQPOXQ
82
84
63
13
cmd(3) = RT?
94
66
77
67
59
...
67
65
84
13
cmd(64) = ^BMC;LL=-2583;LH=3;C=1L=32;R=40;s23;b2^^BMC;LL=-2584;LH=3;C=^CAT
94
66
77
83
59
80
48
61
45
52
49
52
57
59
80
49
45
59
67
94
67
94
66
77
83
59
80
48
61
45
52
49
52
57
59
80
49
61
59
67
80
94
67
13
cmd(0) =
10
cmd(0) =
85
110
115
117
112
112
111
114
116
101
100
32
99
111
109
109
85
110
115
117
112
112
111
114
116
101
100
32
99
111
109
109
13
cmd(17) = mUnsupported comm
10
cmd(17) = mUnsupported comm
13
cmd(17) = mUnsupported comm
10
cmd(17) = mUnsupported comm
65
85
110
115
117
112
112
111
114
116
101
100
32
99
111
109
109
84
13
cmd(18) = AUnsupported commT
65
85
110
115
117
112
112
111
114
116
101
100
32
99
111
109
109
84
13
cmd(18) = AUnsupported commT
126
0
cmd(1) = ~
120
240
126
126
0
cmd(1) = ~
120
240
126
88
81
10
cmd(2) = XQ
86
10
cmd(1) = V
86
10
cmd(1) = V
...
normal sieht es so aus
65
84
94
83
81
80
79
82
84
63
13
cmd(10) = AT^SQPORT?
65
84
13
cmd(2) = AT
65
84
13
cmd(2) = AT
65
84
13
cmd(2) = AT
126
0
cmd(1) = ~
120
240
126
126
0
cmd(1) = ~
120
240
126
88
81
10
cmd(2) = XQ
86
10
cmd(1) = V
98
114
10
cmd(2) = br
88
69
10
cmd(2) = XE
Es macht wahrscheinlich Sinn, daß ich was einbaue, daß nach einem Reset nur XQ und V ausgewetet wird und alles andere ignoriert wird
Hallo Ralf, Hallo Telekatz,
vielen Dank für die Anregungen.
Mit Unterstützung läuft der maple-mini nun. Bootloader "maple_mini_boot20.bin" und "MSCboot_maplemini.bin" über Python am PC-USB und dem FTDI Adapter geflasht. Danach die Firmware "MapleCUNx4_W5500_BL.bin" über den PC-USB auf den maple-mini kopiert und am Raspberry angeschlossen.
Ich hoffe, das Einrichten funktioniert etwas einfacher.
Gruß
Rolf
Hi,
meinst Du so etwas:
https://github.com/AlphaLima/ESP32-Serial-Bridge (https://github.com/AlphaLima/ESP32-Serial-Bridge)
Gruß Arnd
Es gibt eine neue Version "V 4.1.1-dev200611"
https://github.com/Ralf9/SIGNALDuino/commit/b13089915a48bc175082ef9b165440dcf8319fe6
Es kann nun bei XQ und XE ein W angehängt werden. Mit XQW wird nach einem Reset der Empfang des cc1101 nicht automatisch aktiviert,
es werden auch bei falschen Befehlen die "unsupported Commands" Meldungen unterdrückt bis zum senden des Befehls XE.
Dies ist bei der USB Variante bei einigen fhem Servern notwendig.
Es ist evtl von der Hardware und dem Betriebssystem abhängig (beim Banana Pi konnte ich es nicht feststellen).
Bei ca jedem 5 - 10 ten Reset kommt schon nach ca 1-3 sek diese Ausgabe im log:
Watchdog enabled
Reading values from eeprom
CCInit
detect A: Partn=0 Ver=0x14
detect B: Partn=0 Ver=0x18
detect C: Partn=0 Ver=0x14
Starting timerjob
Wenn kurz nach dieser Ausgabe der Maple über USBserial was ausgibt, kommt einiges durcheinander.
Ich konnte über die serielle Debugausgabe beobachten, daß einige dieser Ausgaben als Echo wieder per serialEvent zurückgekommen sind.
Danach kam es zu einem Disconnect und nach einem erneuten connect hat das USBserial per serialEvent nicht mehr richtig funktioniert.
Wenn ein paar mal was gesendet wurde hat der watchdog ausgelöst
Wenn mit XQW der automatische cc1101 Empfang nach einem Reset deaktiviert wird, dann ist dieses Problem bei mir nicht mehr vorgekommen,
Dies ist auch an "irx0" in der Version erkennbar:
V 4.1.1-dev200611 SIGNALduino cc1101 (R: A1* B0 C3) irx0 - compiled at Jun 11 2020 23:55:06
@Reinhard.M
ich konnte diesen Effekt bei einem log von Dir beobachten, was für ein fhem Server und Betriebssystem hast Du?
Die LAN Version funktioniert bei mir jetzt recht stabil, ich hatte einen Dauertest über 6 Tage und dabei auch eine uptime von 6 Tagen
Gruß Ralf
Hey und hallo,
wird den bei der 1.9.0 noch die Datei USBD_reenumerate.c in Sketchordner benötigt oder kann ich die weglassen?
Gruß
Markus
Zitat von: Ralf9 am 12 Juni 2020, 18:25:31
ich konnte diesen Effekt bei einem log von Dir beobachten, was für ein fhem Server und Betriebssystem hast Du?
Hallo Ralf,
bei mir läuft die FHEM 6.0 Release:
Zitatfhem.pl 22134 2020-06-08 08:26:05Z rudolfkoenig
Das Ganze auf einem Raspi 4B mit
Zitat
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
ID_LIKE=debian
Linux raspi 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l
Reicht dir das an Informationen?
Gruß Reinhard
ZitatDas Ganze auf einem Raspi 4B mit
Der ist dann wahrscheinlich deutlich schneller als der Banana Pi.
Beim Banana Pi habe ich dies
ZitatLinux banaNAS 5.1.1-BPI-Kernel #1 SMP Thu Aug 22 13:53:49 CST 2019 armv7l GNU/Linux
hier sind auch die bin Files
https://github.com/Ralf9/SIGNALDuino/releases/tag/V4.1.1-dev200611
Beim core 1.9.0 sind zum compilieren die folgenden Files notwendig:
bitstore.h
cc1101.h
FastDelegate.h
output.h
RF_Receiver_41x.ino
signalDecoder4.cpp
signalDecoder4.h
SimpleFIFO.h
tools.h
siehe auch hier:
https://forum.fhem.de/index.php/topic,106278.msg1027914.html#msg1027914
Gruß Ralf
Ich habe hier mal eine Bauteile Liste angefangen:
Ich habe die aliexpress Links zufällig ausgewählt.
Bitte mal drüberschauen und ergänzen und ggf die Links korrigieren
STM32F103CBT6 Maple Mini
https://de.aliexpress.com/item/1400667476.html
oder auch schneller bei Amazon
Welche Bauform haben die Kondensatoren? Sind die auch in Stückzahlen unter 50 erhältlich?
C6 22PF
Conrad Artikelnummer 445432
C5 10uF
Conrad Artikelnummer 457966
CC1101 868MHZ
https://de.aliexpress.com/item/32635393463.html
https://de.aliexpress.com/item/4000594832541.html
CC1101 433 Mhz
https://de.aliexpress.com/item/32472259186.html
Koaxbuchsen
https://de.aliexpress.com/item/4000009303962.html
USR-ES1 W5500
https://de.aliexpress.com/item/32598945210.html
433Mhz Antenne 5dbi SMA Stecker
https://de.aliexpress.com/item/33016447871.html
433MHz Antenne 3dbi SMA Stecker
https://de.aliexpress.com/item/32968791512.html
https://de.aliexpress.com/item/32963301530.html
868 MHz Antenne 5dbi SMA Stecker
https://de.aliexpress.com/item/33012349050.html
Bei den Cs passt die 0805 Bauform. Keramikkondensatoren. Gibt es auch bei Conrad für 2 bzw 9 Cent. Minimum 10 Stck. Artikelnummer 445432 (22pf) und 457966 (10uf}. Auf meinen Maple vom Ali warte ich heute noch. Bei den Antennen habe ich zumindest für mich festgestellt, dass eine Lamda/4 mehr bringt. Bei mir waren es ganze 6dB.
Gibt es schon einen Wiki Artikel zum Maple-SDuino ?
Wenn nicht, kann ich gerne mal einen anlegen. Aus meiner Sicht ist das ein großes SW-Thema und ein winziges HW-Thema.
Zitat von: Ralf9 am 15 Juni 2020, 19:50:41
Ich habe hier mal eine Bauteile Liste angefangen:
Da würde ich gerne einiges zu den Bauteilen beitragen und vor allem nochmals darauf Hinweisen dass man keine Kondensatoren braucht, oder auch andere nehmen kann, je nachdem was halt da ist...
22pf: Ein kleiner Kondensator der hochfrequente Störungen zwischen VCC und GND am Maple kurzschliesst (Größe: wenige pF passen...). Wenn der Maple nicht regelmäßig abstürzt: unnötig. Wenn der Maple regelmäßig abstürzt: Vermutlich SW Fehler... 8) (der CC1101 hat bereits einen eigenen solchen Abblock-Kondensator am Eingang)
10uF Pufferkondensator (oder von mir aus bis 500uF falls der Platz reicht um Spannungsschwankungen leicht abzumildern, und die Versorgung inkl. des CC1101 sicherzustellen. Im Sendefall würde übrigens der Stromverbrauch und somit der Bedarf dafür steigen)
Antennen: Würde ich im Wiki mal auf den Antennen-Thread verweisen...
Beispiel: https://de.aliexpress.com/item/32968791512.html / https://de.aliexpress.com/item/32963301530.html
Da ist bestimmt eine Drahtspule drin. Und alle solchen Antennen die ich vermessen habe waren eigentlich "immer ein bisschen Schei..e"...
Zitat von: Ralf9 am 15 Juni 2020, 19:50:41
Ich habe hier mal eine Bauteile Liste angefangen:
Koaxbuchsen
Link?
Hi und guten Abend,
hab dir mal hier den Link für die Antennenbuchsen angefügt, die hatte ich mir damals bestellt:
https://de.aliexpress.com/item/4000009303962.html?spm=a2g0o.detail.1000023.9.25505083ZngZpX (https://de.aliexpress.com/item/4000009303962.html?spm=a2g0o.detail.1000023.9.25505083ZngZpX)
Gruß
Markus
Zitat von: Ranseyer am 15 Juni 2020, 21:21:25
Antennen: Würde ich im Wiki mal auf den Antennen-Thread verweisen...
Beispiel: https://de.aliexpress.com/item/32968791512.html / https://de.aliexpress.com/item/32963301530.html
Da ist bestimmt eine Drahtspule drin. Und alle solchen Antennen die ich vermessen habe waren eigentlich "immer ein bisschen Schei..e"...
Hallo Martin,
welchen Thread meinst du? Würde ich mir gerne anschauen. Mit einem einfachen Search habe ich im Forum nichts gefunden. Und meine kurzen Tests decken sich mit deinen Messungen :)
Nachtrag:
ZitatWenn nicht, kann ich gerne mal einen anlegen. Aus meiner Sicht ist das ein großes SW-Thema und ein winziges HW-Thema.
Die Wiki Idee finde ich sehr gut. Habe auch schon überlegt die verstreuten Infos aufzusammeln.
Danke, habe die Kondensatoren und die Koaxbuchsen ergänzt.
ZitatGibt es schon einen Wiki Artikel zum Maple-SDuino ?
Wenn nicht, kann ich gerne mal einen anlegen. Aus meiner Sicht ist das ein großes SW-Thema und ein winziges HW-Thema.
Nein es gibt noch keinen Wiki Artikel zum Maple-SDuino, ist eine sehr gute Idee einen anzulegen.
Zitatund vor allem nochmals darauf Hinweisen dass man keine Kondensatoren braucht, oder auch andere nehmen kann, je nachdem was halt da ist...
ja, der 22pF Kondensator ist wahrscheinlich nicht so wichtig, falls vorrätig irgendwas zwischen 22pF und 100nF, sonst weglassen.
Der Pfufferkondensator ist meiner Meinung nach zur Sicherheit zu empfehlen, falls bei slowRF viel gesendet werden soll, wenn z.B mit 7 oder 10dB mit einem sehr langem Sendebefehl oder vielen Wiederholungen gesendet wird.
Irgendwas ab 10uF
ZitatWenn der Maple regelmäßig abstürzt: Vermutlich SW Fehler.
Ich habe den verdacht, daß bei der USB Version auch das USB Kabel einen Einfluß hat.
Ich hatte den Maple mit einem 1m USB Kabel an den BananaPi angeschlossen und alle paar Stunden einen Absturz, mit einem 50cm USB Kabel habe ich inzwischen eine uptime von einem Tag und 10 Stunden.
Mit dem selben 1m USB Kabel läuft es an der USB3 Buchsen an meinem PC stabil.
Die LAN Version habe inzwischen an meinem Produktivsystem hängen und eine uptime von 2 Tagen und 2 Stunden
Gruß Ralf
Hallo Ralf9,
vielleicht mal wieder etwas zu Off-Topic: USB-Kabeltester (http://hlembke.de/arduinoablage/crate.php?20180204usbcabletester)
Jürgen
Zitat von: Ralf9 am 15 Juni 2020, 23:24:41
Nein es gibt noch keinen Wiki Artikel zum Maple-SDuino, ist eine sehr gute Idee einen anzulegen.
Hier mal ein erster Stand (inkl. Link zum Antennenthread).
https://wiki.fhem.de/wiki/Maple-SignalDuino
Bitte gerne durch Jedermann editieren...
Zitat von: Ranseyer am 16 Juni 2020, 13:27:28
Hier mal ein erster Stand (inkl. Link zum Antennenthread).
https://wiki.fhem.de/wiki/Maple-SignalDuino
Bitte gerne durch Jedermann editieren...
Ich habe mal Wikifiziert (andere Wiki Seiten verlinkt), kategorisiert, "Infobox Hardware" eingefügt (bitte noch vervollständigen / korrigieren, die "Anleitung" dazu ist hier: https://wiki.fhem.de/wiki/Vorlage:Infobox_Hardware), Links auf Forenbeiträge auf die Vorlage umgestellt und verschiedene kleinere Korrekturen gemacht... und hoffentlich dabei nichts "verbogen".
Peter
Vielen Dank. Das sieht super aus. ((Vor allem seit ich noch ein Bild eingefügt habe 8)))
Zitat von: Ranseyer am 16 Juni 2020, 16:49:48
Vielen Dank. Das sieht super aus. ((Vor allem seit ich noch ein Bild eingefügt habe 8)))
Sind das auf dem Bild zwei verschiedene Ausführungen (LAN / Wifi oder so) oder Vorder-/Rückseite? Falls ja, würde ich das beim Bildtext noch erwähnen.
Genau. Anschluss per USB oder LAN.
Aber wohin genau schreiben ? (Magst du das übernehmen?)
Zitat von: Ranseyer am 16 Juni 2020, 17:14:21
Genau. Anschluss per USB oder LAN.
Aber wohin genau schreiben ? (Magst du das übernehmen?)
Gern - links = LAN, rechts = USB?
Genau...
Das MapleSduino Wiki sieht schon sehr gut aus.
2 Dinge sind mir aufgefallen.
- Im Foto sind noch die beiden Module vertauscht, es wäre nicht so gut, wenn jemand nach dem Foto nachbaut.
Im ersten Beitrag habe ich das Foto von der LAN Version aktualisiert. Ohne LAN habe ich kein passendes Foto.
- es fehlt noch die a-culw Firmware
Gruß Ralf
Hallo,
zum 22 pF Kondensator von Conrad (445432) habe ich eine Frage bzw. Anmerkung.
Der Kondensator ist relativ groß (Höhe 5.5 mm, Durchmesser 4.0 mm). Die Laschen zum Anlöten sind unter dem 4.3 x 4.3 mm Sockel eingeklappt und decken die Lötpads nahezu ab.
Wie kann man den Kondensator "professionell" anlöten?
Noch eine "dumme" Frage zum Wiki Artikel Maple-SignalDuino
ZitatDie "Maple_sduino_USB....bin" ist für die Belegung siehe diese Wiki-Seite.
Die "Maple_cul_USB_....bin" ist für den MapleCUL und MapleCUN.
Kann die Firmware MapleCUL auch für den Maple_sduino verwendet werden?
Vielen Dank und Gruß
Rolf
Zitatzum 22 pF Kondensator von Conrad (445432) habe ich eine Frage bzw. Anmerkung.
Der Kondensator ist relativ groß (Höhe 5.5 mm, Durchmesser 4.0 mm).
Der Kondensator hat die Bauform 0805, Länge 2mm Breite 1.25mm
https://de.wikipedia.org/wiki/Chip-Bauform
Zitat
Kann die Firmware MapleCUL auch für den Maple_sduino verwendet werden?
siehe hier
https://forum.fhem.de/index.php/topic,106278.msg1037726.html#msg1037726
Gruß Ralf
Hallo Ralf,
vielen Dank für die schnelle Antwort.
Sorry, bei dem Kondensator habe ich mich vertan, meine Frage betrifft den C5 Kondensator mit 10 µF. Im Schaltplan "MapleSDUINO-Schematic_Ranseyer.png" ist dieser mit Polung eingezeichnet.
ZitatDer Kondensator ist relativ groß (Höhe 5.5 mm, Durchmesser 4.0 mm). Die Laschen zum Anlöten sind unter dem 4.3 x 4.3 mm Sockel eingeklappt und decken die Lötpads nahezu ab.
Diesen gibt es bei Conrad eben nur in der erwähnten Größe.
Kann alternativ ein Kondensator ohne Polung verwendet werden?
Gruß
Rolf
ZitatDiesen gibt es bei Conrad eben nur in der erwähnten Größe.
Kann alternativ ein Kondensator ohne Polung verwendet werden?
Ja die empfohlenen sind Keramikkondensatoren und haben keine Polung.
Die Conrad Artikelnummer 457966 hat auch die Bauform 0805
Zitat von: nagelreo am 16 Juni 2020, 21:54:56
meine Frage betrifft den C5 Kondensator mit 10 µF. Im Schaltplan "MapleSDUINO-Schematic_Ranseyer.png" ist dieser mit Polung eingezeichnet.
...Kann alternativ ein Kondensator ohne Polung verwendet werden?
Der Schaltplan ist das maximal mögliche. (Mal von Murksen abgesehen) Und auch nicht alle Teile sind nötig.
Gepolte sind generell kleiner, weil dazu Kinder Tantal aus afrikanischen Minen holen. Dabei hilft dann der Aufdruck +/- auf der Platine.
10uF mit 20-30V Spannungsfestigkeit sind ziemlich groß...
Aber 10uF mit ~6V gibt es als 0805 Version. (Und die haben gemessen auch fast 10uF und mir ist auch noch nie einer abgefackelt.
(Tantal verpolt fackelt ordentlich ab.)
Die gepolten Kondensatoren haben den Vorteil: Mehr Kapazität bei gleicher Spannungsfestigkeit. Nachteil: Beim verpolen gibt es zumindest Gestank und einen schwarzen Fleck.
Zitat von: Ralf9 am 16 Juni 2020, 19:42:19
Das MapleSduino Wiki sieht schon sehr gut aus.
...
- Im Foto sind noch die beiden Module vertauscht, es wäre nicht so gut, wenn jemand nach dem Foto nachbaut.
Im ersten Beitrag habe ich das Foto von der LAN Version aktualisiert. Ohne LAN habe ich kein passendes Foto.
Die linke Platine auf dem Foto im Wiki (https://wiki.fhem.de/wiki/Maple-SignalDuino) (oben rechts in der Infobox) hat doch die RJ45-Buchse drauf - also die LAN-Version. Liege ich da so falsch oder meinst Du ein anderes Foto?
Peter
ZitatDie linke Platine auf dem Foto im Wiki (oben rechts in der Infobox) hat doch die RJ45-Buchse drauf - also die LAN-Version. Liege ich da so falsch oder meinst Du ein anderes Foto?
Die cc1101 Module haben die falsche Farbe, sie müssten grün sein, evtl lässt sich mit einer brauchbaren Bildbearbeitung aus dem blau ein grün machen.
Sie wurden ganz am Anfang noch falsch eingelötet, da in der aktuellen Platine die Beschriftungen 433 MHz und 868 Mhz vertauscht sind.
Gruß Ralf
Zitat von: Ralf9 am 15 Juni 2020, 23:24:41
Ich habe den verdacht, daß bei der USB Version auch das USB Kabel einen Einfluß hat.
Hallo Ralf,
ich habe bei mir mal einen USB-A auf USB-Mini-B für den Anschluss des Maple verwendet, also kein Kabel dazwischen. Weiterhin Abstürze mit "wr". Das USB-Kabel und dessen Länge hat zumindest bei mir keinerlei Einfluss auf das Verhalten. Ich hatte auch mit USB Kabel schon Laufzeiten von 2 Tagen und 2 Stunden. Danach eine halbe Stunde. Äußerlich, also über Log Dateien, kann ich keinerlei Abhängigkeiten entdecken. Außer dem was auch du gesehen hast: Merkwürdige Antworten (Version ohne Nachfrage). Ach ja, das alles bezieht sich natürlich auf deine aktuellste Version "V 4.1.1-dev200611". Da habe ich aber noch keine merkwürdigen Antworten gesehen. Nur "wr".
BTW, meine Maples sind seit letztem Donnerstag in Frankfurt, es wird :)
Ich habe unter "Allgemeine Informationen - Wiki" für Verbesserungs- und Ergänzungswünsche des Wikis ein neues Thema erstellt
https://forum.fhem.de/index.php/board,80.0.html
Hallo Ralf,
kannst du bei jedem Funktionsaufruf eine Kennung speichern die zusammen mit dem "wr" bei einem Watchdog Reset ausgegeben wird? Bei mir schlägt weiterhin der Watchdog sporadisch aber regelmäßig zu. Zwischen einer Stunde und zwei Tagen habe ich schon alles gesehen. Eventuell gibt es ja da Regelmäßigkeiten.
Gruß
Reinhard
Hallo Reinhard,
die Kennung müsste ich dann so im RAM speichern, daß sie bei einem Reset nicht neu initialisiert wird.
Ich habe dies gefunden, das müsste ich dann mal testen ob dies auch beim STM32 funktioniert.
https://atadiat.com/en/e-how-to-preserve-a-variable-in-ram-between-software-resets/
ZitatBei mir schlägt weiterhin der Watchdog sporadisch aber regelmäßig zu. Zwischen einer Stunde und zwei Tagen habe ich schon alles gesehen. Eventuell gibt es ja da Regelmäßigkeiten.
Bei Dir ist anscheined irgendwas besonderes, daß der Watchdog so oft zuschlägt.
Betreibst Du den Maple an einem Testsystem oder am Produktivsystem. Hast Du evtl fhem Module durch die fhem ab und zu blockiert wird?
Ber der LAN Version hat der Watchdog nach ca 2,5 Tagen das erste mal und nach ca 3,5 Tagen das zweite mal zugeschlagen.
Über USB habe ich bis jetzt eine uptime von 5 Tagen und 6 Stunden
Gruß Ralf
Wenn du nur wenige Bytes vor einem Reset retten möchtest, kannst du beim STM32 auch die Backup Register (BKP) verwenden.
Sagen wir mal Testsystem. Ich beschäftige mich erst seit ein paar Monaten mit FHEM um meine Rollosteuerung zu zentralisieren. Habe aber Gefallen daran gefunden mehr und mehr andere Dinge einzubinden :)
Für die Rückmeldung würde ja bereits ein Byte genügen das jeweils beim Einstieg in die Funktion gesetzt wird. Damit könnten wir zumindest feststellen ob es immer bei dem gleichen Aufruf zum Reset kommt. Was denkst du?
Ja ein Byte würde reichen.
Ich habe hier was gefunden
https://www.mikrocontroller.net/topic/264560?goto=new#new
demnach wird damit geschrieben
PWR_BackupAccessCmd(ENABLE);
BKP_WriteBackupRegister(BKP_DR1, 0x0000000C);
PWR_BackupAccessCmd(DISABLE);
und damit gelesen
BKP_ReadBackupRegister(BKP_DR1)
Wäre perfekt, würde ich gleich einspielen wenn du es eingebaut hast.
Kann eine Weile dauern, muß es erst mal an einem Testsketch testen und rausfinden welche inludes notwendig sind
Kein Thema, mir läuft die Zeit nicht weg :)
Habe nun eingebaut, daß in einigen Stellen verschiedene Werte ins Backupregister geschrieben werden
1 FifoReceive begin
2 FifoReceive end
3 processMessage begin
4 print MS Nachricht
5 print MC Nachricht
6 print MU Nachricht
7 processMessage end
8 HandleCommand begin
9 HandleCommand end
In der Setup Routine wird der Wert des Backupregister dann ausgegeben und gemerkt.
Der gemerkte Wert steht dann auch in der Version z.B." -7-"
Zitat von: Ralf9 am 20 Juni 2020, 15:18:23
Habe nun eingebaut, daß in einigen Stellen verschiedene Werte ins Backupregister geschrieben werden
Habe es compiliert und eingebaut, mal sehen was der Watchdog so von sich gibt.
Hallo Ralf,
ich kann bereits erste Ergebnisse liefern. Der Watchdog schlägt bislang immer mit "5" zu, also einem "print MC Nachricht". Ich habe mal meine alten Logs durchsucht und konnte bei fast allen Resets eine entsprechende Korrelation feststellen. Keine Ahnung ob es direkt dieser Printbefehl ist aber in diesem Umfeld macht es Sinn genauer hinzuschauen. Eine Sequenz stellt sich typischerweise im fhem.log so dar:
2020.06.22 07:06:01.479 4: myMaple/msg READ: MC;LL=-499;LH=466;SL=-266;SH=229;D=492492;C=243;L=24;R=252;i;s6;b5;w;
2020.06.22 07:06:01.481 4: myMaple/msg READ: MC;LL=-499;LH=466;SL=-266;SH=229;D=4924924;C=243;L=26;R=252;s108;b107;w;
2020.06.22 07:06:01.483 4: myMaple/msg READ: MC;LL=-499;LH=466;SL=-266;SH=229;D=4924920;C=243;L=25;R=252;s105;b104;w;
2020.06.22 07:06:05.414 4: myMaple/keepalive ok, retry = 0
2020.06.22 07:06:22.259 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 disconnected, waiting to reappear (myMaple)
2020.06.22 07:06:24.314 3: Setting myMaple serial parameters to 115200,8,N,1
2020.06.22 07:06:24.317 1: myMaple/define: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.06.22 07:06:24.317 1: myMaple/init: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00@115200
2020.06.22 07:06:24.317 1: /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_5D8252463435-if00 reappeared (myMaple)
2020.06.22 07:06:24.330 4: myMaple/msg READ: BackupReg = 5
2020.06.22 07:06:24.330 3: myMaple/noMsg Parse: BackupReg = 5
2020.06.22 07:06:24.330 4: myMaple/msg READ: Watchdog caused a reset
2020.06.22 07:06:24.330 3: myMaple/noMsg Parse: Watchdog caused a reset
2020.06.22 07:06:24.331 4: myMaple/msg READ: Watchdog enabled
2020.06.22 07:06:24.331 3: myMaple/noMsg Parse: Watchdog enabled
2020.06.22 07:06:24.331 4: myMaple/msg READ: Reading values from eeprom
2020.06.22 07:06:24.331 3: myMaple/noMsg Parse: Reading values from eeprom
2020.06.22 07:06:24.331 4: myMaple/msg READ: CCInit
2020.06.22 07:06:24.331 3: myMaple/noMsg Parse: CCInit
2020.06.22 07:06:24.331 4: myMaple/msg READ: detect A: Partn=0 Ver=0x14
2020.06.22 07:06:24.332 3: myMaple/noMsg Parse: detect A: Partn=0 Ver=0x14
2020.06.22 07:06:24.333 4: myMaple/msg READ: detect B: Partn=0 Ver=0x18
2020.06.22 07:06:24.333 3: myMaple/noMsg Parse: detect B: Partn=0 Ver=0x18
2020.06.22 07:06:24.334 4: myMaple/msg READ: Starting timerjob
2020.06.22 07:06:24.334 3: myMaple/noMsg Parse: Starting timerjob
2020.06.22 07:06:24.388 4: myMaple/msg READ: rxA=1 rxB=1
2020.06.22 07:06:24.388 3: myMaple/noMsg Parse: rxA=1 rxB=1
Hoffe du kannst damit etwas anfangen. Sonst melde dich. Habe am Samstag endlich die Maple Platinen bekommen und lasse seit gestern auch einen Sduino mitlaufen. Da gab es aber noch keinen Ausfall dieser Art.
Gruß
Reinhard
Was ist das für ein Sensor von dem Du die MC Nachrichten empfängst?
Interessant wäre jetzt ob der Watchdog noch zuschlägt, wenn Du mit "set disableMessagetype MC.." die MC-Nachrichten deaktivierst.
Gruß Ralf
Sensor abschalten kann ich testen. Der Sensor ist eine Wetterstation mit Temp, Hum, Wind
Muss mich korrigieren, der Sduino ist ebenfalls schon über ein WR gegangen:
Line 103588: 2020.06.22 06:14:57.376 3: myMaple/noMsg Parse: BackupReg = 5
Line 104179: 2020.06.22 06:17:03.336 3: myMaple/noMsg Parse: BackupReg = 5
Line 116798: 2020.06.22 07:05:52.263 3: mySduino/noMsg Parse: BackupReg = 5
Line 116928: 2020.06.22 07:06:24.330 3: myMaple/noMsg Parse: BackupReg = 5
Line 143555: 2020.06.22 08:49:54.252 3: myMaple/noMsg Parse: BackupReg = 5
Line 143834: 2020.06.22 08:50:57.077 3: mySduino/noMsg Parse: BackupReg = 5
Line 150697: 2020.06.22 09:19:19.621 3: myMaple/noMsg Parse: BackupReg = 5
Line 151044: 2020.06.22 09:20:53.755 3: mySduino/noMsg Parse: BackupReg = 5
Line 154719: 2020.06.22 09:36:39.601 3: myMaple/noMsg Parse: BackupReg = 5
Line 154884: 2020.06.22 09:37:10.702 3: mySduino/noMsg Parse: BackupReg = 5
Line 158342: 2020.06.22 09:51:53.302 3: mySduino/noMsg Parse: BackupReg = 5
Line 158560: 2020.06.22 09:52:56.288 3: mySduino/noMsg Parse: BackupReg = 5
Line 158696: 2020.06.22 09:53:28.653 3: myMaple/noMsg Parse: BackupReg = 5
Line 158849: 2020.06.22 09:53:59.822 3: mySduino/noMsg Parse: BackupReg = 5
Was mir hier auffällt, Beide machen einen WR fast zur gleichen Zeit. Nicht nur einmal, fast immer im Abstand von 30 bis 60 Sekunden. Schalte jetzt mal beim "myMaple" MC ab.
ZitatHoffe du kannst damit etwas anfangen. Sonst melde dich. Habe am Samstag endlich die Maple Platinen bekommen und lasse seit gestern auch einen Sduino mitlaufen. Da gab es aber noch keinen Ausfall dieser Art.
Empfängst Du bei Dir viele Sensoren, auch welche von Nachbarn?
Ich vermute, daß dies fehlerhafte MC-Nachrichten sind, die einen Absturz verursachen können. Sie können durch überlagerungen mit anderen Nachrichten entstehen.
Ohne zu wissen wie so eine fehlerhafte MC-Nachricht als MU-Nachricht ausieht wird es wahrscheinlicht recht schwierig diesen Bug zu finden. Anscheinend tritt dies nur bei Dir so massiv auf.
Ich hatte bis jetzt nur alle 2 - 5 Tage einen watchdog Reset. Ich habe bei der USB Version auch mal den MC-Decoder deaktiviert und bin jetzt bei einer uptime von 3 Tagen.
Es wäre hilfreich, wenn ich diese evtl absturz verursachenden MC-Nachrichten in der Form von MU-Nachrichten (DMC) hätte.
In der "signalDecoder4.h" gibt es ein auskommentiertes define
#define MCDEBUGDECODE 2 // debug mc-decoderDies sieht dann z.B. so aus:
2020.06.23 19:52:02.034 4: sduino/msg READ: DMC;P0=21872;P1=-5624;P2=921;P3=-1028;P4=-532;P5=433;D=01_232324545354542453245354545423245453235423235423545423542354545454245454545323545454245453545423232323542454535454545454545424545453545_4;e;
2020.06.23 19:52:02.045 4: sduino/msg READ: MC;LL=-1028;LH=921;SL=-532;SH=433;D=A8E4F45ADDBE0BC7558FF0E;C=485;L=91;R=245;s2;b2;s01_LlLlLsSsSlSsSsLsSlLsSlSsSsSsLl;Gruß Ralf
ZitatEmpfängst Du bei Dir viele Sensoren, auch welche von Nachbarn?
Ich empfange bei mir einiges, auch aus der Nachbarschaft. Die meisten Protokolle habe ich aber über eine Whitelist ausgeschlossen. Als ich vorhin nochmals prüfen wollte welcher Sensor den Fehler hervorruft habe ich festgestellt, dass dieser zu den von der Whitelist ausgeschlossenen gehören muss. Ich habe genau einen OREGON (ID10) mit MC-Protokoll. Alle anderen MC sind nicht auf der Whitelist. Kannst du aus den folgenden Messages etwas ableiten?
2020.06.22 06:16:40.194 4: myMaple/msg READ: MC;LL=-487;LH=484;SL=-242;SH=248;D=49248;C=243;L=17;R=253;s15;b14;O;w;
2020.06.22 06:16:40.210 4: myMaple/msg READ: MC;LL=-476;LH=495;SL=-237;SH=255;D=49248;C=243;L=17;R=253;s255;b254;O;w;
2020.06.22 06:16:40.315 4: myMaple/msg READ: MC;LL=-489;LH=496;SL=-243;SH=241;D=49248;C=244;L=17;R=253;s117;b116;O;w;
2020.06.22 06:16:40.388 4: myMaple/msg READ: MC;LL=-485;LH=493;SL=-249;SH=241;D=49248;C=244;L=17;R=253;s255;b254;O;w;
LL ist bei einem Absturz bislang immer im -400/-500er Bereich gewesen. Der Maple läuft seit MC=0 durch, inzwischen mehr als 32Std. Der Sduino hatte bereits wieder ein Reset. Ich habe außerdem einen Nano (V 3.4.0-dev SIGNALduino) laufen der bislang noch nie über dieses Problem gestolpert ist. Ich werde mal die MU Nachrichten aktivieren und dir das Ergebnis schicken.
Zitat2020.06.22 06:16:40.388 4: myMaple/msg READ: MC;LL=-485;LH=493;SL=-249;SH=241;D=49248;C=244;L=17;R=253;s255;b254;O;w;
Danke, dies war der entscheidende Hinweis.
Bei diesen kaputten MC-Nachrichten, kommt es ab und zu vor, daß der Start der MC-Nachricht erst ab einer Position größer 255 ist, da der MC-Start in einer 8 Bit Variable gemerkt wird, kann es hier einen Absturz geben.
Zitat// Start vom MC Signal suchen, dazu long suchen. Vor dem longlow darf kein Puls groesser long sein
Als workaround kannst Du mal folgendes versuchen:
CSmaxMsgSizex256=1Der Messagepuffer hat nun eine maximale Größe von 1500 Pulsen
Es gibt nun 2 neue Konfigurationsvariablen
CSmaxMsgSizex256 - damit kann die Größe des Messagepuffers konfiguriert werden. Der Wert wird mit 256 multipliziert, d.h. 4 ergibt eine Messagepuffergröße von 1024
CSmaxMuPrintx256 - damit kann die maximale Länge von MU-Nachrichten konfiguriert werden. Der Wert wird mit 256 multipliziert
ZitatAls workaround kannst Du mal folgendes versuchen:
Code: [Auswählen]
CSmaxMsgSizex256=1
Gerade eingetragen, mal sehen was passiert ::)
Halo Ralf,
mit den von dir vorgeschlagenen MC Anpassungen laufen jetzt sowohl mein Sduino und als auch mein Maple stabil. Beim Maple hatte ich ja zunächst MC komplett abgeschaltet. Seitdem (mehr als 3 Tage) kein Absturz. Ich habe jetzt beim Maple "CSmaxMsgSizex256=1" gesetzt und MC wieder aktiviert. Mal sehen wie es damit weitergeht. Beim Sduino hatte ich "CSmaxMsgSizex256=1" vor einem Tag und 20 Stunden gesetzt. Kein Reset mehr. Message Pakete wie ich sie unten gezeigt hatte kommen aber immer noch. Sie führen aber nicht mehr zum Absturz. Wäre das eine Anpassung im Code wert? :)
Hallo Ralf,
leider bekomme ich meine maple mini nicht zum laufen. Im Maple-SignalDuino habe ich die Ranseyer-Platine V0.2 und 2 CC1101 Module (433 und 868 MHz) verbaut, dabei die falsche Beschriftung der CC-Module berücksichtigt.
Als BL "maple_mini_boot20.bin" und die FW "MapleCUNx4_W5500_BL.bin" geflasht. Am Raspberry 4 blinkt der maple fleißig vor sich hin und lässt sich auch anmelden und die LED über raw schalten. Mehr geht aber nicht.
Ich habe den maple nach der Anleitung "Maple-SignalDuino" und den entsprechenden Links zum Fhem Forum angemeldet und bisher erfolglos versucht die beiden CC-Module zu aktivieren.
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXeflptxz
CUL1_868_MSGCNT 7
CUL1_868_TIME 2020-06-25 20:48:34
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :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 /dev/serial/by-id/usb-STM32_MapleCUL_a1cfb49b-if00@115200 0000
DeviceName /dev/serial/by-id/usb-STM32_MapleCUL_a1cfb49b-if00@115200
FD 4
FHTID 0000
FUUID 5ee667d7-f33f-a993-7170-a10f81b7287fde3d
NAME CUL1_868
NR 85
PARTIAL
RAWMSG OFF
STACKED CUL1_868Stack
STATE Initialized
TYPE CUL
VERSION V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) MapleCUNx4_00 (F-Band: 868MHz)
initString X21
MatchList:
0:FS20V ^81..(04|0c)..0101a001......00[89a-f]...
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......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:
2020-06-25 20:50:19 ccconf freq:0.000MHz bWidth:812KHz rAmpl:24dB sens:16dB
2020-06-25 20:50: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
2020-06-24 11:18:15 fhtbuf AE
2020-06-25 20:50:55 raw No answer
2020-06-25 20:50:56 state Initialized
2020-06-25 16:37:52 version V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) MapleCUNx4_00 (F-Band: 868MHz)
Attributes:
icon cul_868
room Maple_Test
nternals:
CFGFN
CMDS
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :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 FHEM:DEVIO:CUL_868Stack:9600 0000
DeviceName FHEM:DEVIO:CUL_868Stack:9600
FHTID 0000
FUUID 5ef4a8fe-f33f-a993-35fd-baf8b8c3619999fe
NAME CUL1_433
NR 152
PARTIAL
STATE disconnected
TYPE CUL
initString X21
MatchList:
0:FS20V ^81..(04|0c)..0101a001......00[89a-f]...
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......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:
2020-06-25 16:42:33 state disconnected
2020-06-25 16:37:24 version No answer
Attributes:
rfmode SlowRF
room Maple_Test
Save config
CUL_IR
FS20
Global
Maple_Test
SD_UT
SOMFY-Define
SOMFY-FB
SOMFY-Garten
SOMFY-Rollo
Unsorted
Winter-Garten
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
CFGFN
DEF CUL1_868
FUUID 5ef4a8d7-f33f-a993-b2f1-5b102fd79066e707
IODev CUL1_868
NAME CUL1_868Stack
NOTIFYDEV CUL1_868
NR 148
NTFY_ORDER 50-CUL1_868Stack
STATE Defined
TYPE STACKABLE
Attributes:
room Maple_Test
Was mache ich falsch?
Vielen Dank und Gruß
Rolf
Zitatleider bekomme ich meine maple mini nicht zum laufen. Im Maple-SignalDuino habe ich die Ranseyer-Platine V0.2 und 2 CC1101 Module (433 und 868 MHz) verbaut, dabei die falsche Beschriftung der CC-Module berücksichtigt.
Als BL "maple_mini_boot20.bin" und die FW "MapleCUNx4_W5500_BL.bin" geflasht. Am Raspberry 4 blinkt der maple fleißig vor sich hin und lässt sich auch anmelden und die LED über raw schalten. Mehr geht aber nicht.
Hast Du diese bin verwendet? Die a-culw für den Maple Cul funktioniert beim Maple Sduino nicht.
https://forum.fhem.de/index.php/topic,106278.msg1037726.html#msg1037726
Zitatund bisher erfolglos versucht die beiden CC-Module zu aktivieren.
Die cc1101 Module werden bei der a-culw automatisch erkannt.
Mit "set raw C31" kannst Du abfragen ob ein cc1101 Modul erkannt wurde, die Rückmeldung siehst Du dann im Log. Bei einem Wert von FF oder 0 wurde kein Modul erkannt
z.B.
2020.06.26 15:33:54.765 3 : set myCUL raw C31
2020.06.26 15:33:54.769 4 : CUL_Parse: myCUL C31 = FF / 255
Zitatmit den von dir vorgeschlagenen MC Anpassungen laufen jetzt sowohl mein Sduino und als auch mein Maple stabil. Beim Maple hatte ich ja zunächst MC komplett abgeschaltet. Seitdem (mehr als 3 Tage) kein Absturz. Ich habe jetzt beim Maple "CSmaxMsgSizex256=1" gesetzt und MC wieder aktiviert. Mal sehen wie es damit weitergeht. Beim Sduino hatte ich "CSmaxMsgSizex256=1" vor einem Tag und 20 Stunden gesetzt. Kein Reset mehr. Message Pakete wie ich sie unten gezeigt hatte kommen aber immer noch. Sie führen aber nicht mehr zum Absturz. Wäre das eine Anpassung im Code wert? :)
Ich habe mit abgeschaltetem MC Decoder inzwischen eine uptime von 6 Tagen und 9 Stunden.
Beim MC-Decoder habe ich ein paar Dinge gefunden und gefixt die nicht gepasst haben, bin gerade am Testen.
Ich könnte von Dir noch log Daten mit verbose 4 gebrauchen.
Ca 30 Minuten mit aktiviertem MC-Decoder
und ca 30 Minuten mit "CSmaxMsgSizex256=4" und abgeschaltetem MC-Decoder.
Mit interessieren besonders die langen MU-Nachrichten mit einem Datenteil ("D=....;") von mehr als 255 Zeichen
Gruß Ralf
Hallo Ralf,
ZitatHast Du diese bin verwendet? Die a-culw für den Maple Cul funktioniert beim Maple Sduino nicht.
https://forum.fhem.de/index.php/topic,106278.msg1037726.html#msg1037726
Ich habe die Maple_sduino_USB_411dev200611.bin und eben noch die Maple_sduino_USB_411dev200603.bin getestet.
Bei der letzteren ist nach dem Start bzw. reset State opened und DevState inactive, nach einiger Zeit wechselt State auf closed. Dazu gibt es eine Diskussion im Forum, muss ich nochmals genauer lesen.
2020.06.26 21:28:53 3: Opening MapleSduino1 device /dev/serial/by-id/usb-LeafLabs_Maple-if00
2020.06.26 21:28:53 3: Setting MapleSduino1 serial parameters to 57600,8,N,1
2020.06.26 21:28:53 1: MapleSduino1/define: /dev/serial/by-id/usb-LeafLabs_Maple-if00@57600
2020.06.26 21:28:53 1: MapleSduino1/init: /dev/serial/by-id/usb-LeafLabs_Maple-if00@57600
2020.06.26 21:28:53 3: MapleSduino1 device opened
2020.06.26 21:28:55 3: MapleSduino1/init: disable receiver (XQ)
2020.06.26 21:28:55 3: MapleSduino1/init: get version, retry = 0
2020.06.26 21:29:05 3: MapleSduino1/init: get version, retry = 1
2020.06.26 21:29:45 3: MapleSduino1/init: get version, retry = 2
2020.06.26 21:30:55 3: MapleSduino1/init: get version, retry = 3
2020.06.26 21:30:55 2: MapleSduino1/init retry count reached. Closed
2020.06.26 21:30:55 2: MapleSduino1 closedUnabhängig davon verstehe ich das Wiki Maple-SignalDuino (https://wiki.fhem.de/wiki/Maple-SignalDuino#Platine) nicht.
Was bedeutet dann der Hinweis "Die "Maple_cul_USB_....bin" ist für den MapleCUL und MapleCUN", und was "Ab der Version 4.1.0 werden bis zu vier cc1101 Module (A-D) unterstützt, Beim MapleSduino sind die cc1101 Module an SPI2 angeschlossen:"
Vielen Dank und Gruß
Rolf
ZitatMapleSduino1/define: /dev/serial/by-id/usb-LeafLabs_Maple-if00@57600
ZitatDie Baudrate wurde auf 115200 erhöht.
Die DEF passt nicht.
DEF /dev/serial/by-id/usb-LeafLabs_Maple-if00@115200Hast Du den Bootloader2.0 drauf?
Die dev/serial/by-id/ sieht bei mir so aus:
ls -l /dev/serial/by-id
usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_6D8824785548-if00 -> ../../ttyACM0ZitatWas bedeutet dann der Hinweis "Die "Maple_cul_USB_....bin" ist für den MapleCUL und MapleCUN",
Da beim MapleSduino die cc1101 Module an SPI2 und beim MapleCUL/MapleCUN die cc1101 Module an SPI1 angeschlossen sind,
https://de.wikipedia.org/wiki/Serial_Peripheral_Interface
gibt es für den MapleSduino die Firmware "Maple_sduino...bin"
und für den MapleCUL/MapleCUN die Firmware Maple_cul...bin"
Zitatund was "Ab der Version 4.1.0 werden bis zu vier cc1101 Module (A-D) unterstützt
Es gibt auch ältere Versionen z.B. 4.01. mit der nur ein cc1101 Modul unterstützt wird
Zitat von: Beta-User am 10 Januar 2020, 15:03:02
Hatte irgendwo mal ein Projekt gesehen, das nur die beiden weiteren Schnittstellen nach USB durchreicht, leider finde ich den Link nicht mehr. Im Prinzip waren das aber am Ende nur ein paar Programmzeilen unter Zuhilfenahme dessen, was STM dazu bereitstellt.
Hi, meinst Du soetwas?
https://github.com/AlphaLima/ESP32-Serial-Bridge (https://github.com/AlphaLima/ESP32-Serial-Bridge)Gruß Arnd
Zitat von: RaspiLED am 27 Juni 2020, 08:52:22
Hi, meinst Du soetwas?
https://github.com/AlphaLima/ESP32-Serial-Bridge (https://github.com/AlphaLima/ESP32-Serial-Bridge)
Gruß Arnd
Das ist auch nicht uninteressant (aber eben WiFi, also tendenziell doch Bäh...). Ich meinte was auf STM32-Basis. Auf die Schnelle habe ich jetzt dazu aber "nur" das hier gefunden, k.A. wie gut der Code ist, und das ist wesentlich neuer als meine ursprüngliche verlorene Fundstelle: https://github.com/iu3kxa/stm32f103-usb-cdc-to-triple-serial-port, und es ging auch erst mal nur um USB.
Hat sich aber ja weitestgehend erledigt, wenn ich das richtig interpretiert habe, oder? Denn der Maple-LAN-Signalduino kann ja auch die beiden anderen seriellen Schnittstellen - wie der MapleCUN - via USB und/oder im LAN bereitstellen, oder unterliege ich da einem Irrtum? (Falls noch nicht: Das wäre ein mMn. wichtiges Feature, und die Experten für sowas lesen hier ja mit, oder...)
Ich habe beim MC Decoder den Code angepasst.
https://github.com/Ralf9/SIGNALDuino/commit/1498259712f695922bc9b2793dda3c4d3e599fe7
In der signalDecoder4.cpp werden in der "isManchester()" Routine alle MU-Nachrichten geprüft ob es eine MC Nachricht sein könnte.
Bei MU-Nachrichten die merkmale einer MC-Nachricht haben und einer Datenlänge größer 255, konnte es zu Abstürzen kommen.
ZitatDenn der Maple-LAN-Signalduino kann ja auch die beiden anderen seriellen Schnittstellen - wie der MapleCUN - via USB und/oder im LAN bereitstellen, oder unterliege ich da einem Irrtum?
Ja, eine serielle übers LAN sollte machbar sein. Eine serielle über USB ist wahrscheinlich nicht machbar.
Gruß Ralf
Hier sind die aktuellen bin Files
https://github.com/Ralf9/SIGNALDuino/releases/tag/V4.1.1-dev200627
Hallo Ralf,
ich würde gerne die LAN Schnittstelle in Betrieb nehmen scheitere aber derzeit wahrscheinlich an meiner eigenen Blindheit:
- Meine Maple Boards scheinen einen 2.0 Bootloader zu haben, jedenfalls habe ich auf einen mit der Ardunino IDE und dem 2.0 Bootloader Setting die Firmware laden können
- Wenn ich die aktuelle Version mit LAN_WIZ und DEBUG_BackupReg kompiliere und hochlade kann ich nicht mehr über den USB Port zugreifen. In der SignalDecoder habe ich wie angegeben ebenfalls die DEF Settings auskommentiert. Außerdem habe ich die Standard-IP Adressen auf mein Netz angepasst.
- Versuche ich mit Telent heranzukommen gibt es ein Timeout
- dfu-util bekomme ich auf dem Raspi nicht zum Laufen da keine Ports gefunden werden. Ich kann also deine Binaries momentan nicht direkt hochladen.
Wie sollte das grundsätzliche Vorgehen bei der LAN Variante aussehen?
Gruß Reinhard
Hallo Ralf,
ZitatHast Du den Bootloader2.0 drauf? / Die dev/serial/by-id/ sieht bei mir so aus:
Ja, ich habe den bootloader2.0 verwendet, aber auf den BL-leeren maple. Offensichtlich hat das flashen der Firmware nicht richtig funktioniert, warum weiß ich noch nicht.
Jetzt habe ich die FW "Maple_sduino_USB_411dev200611.bin" mit "MSCboot_maplemini.bin " geflasht und siehe da der mapleSduino funktioniert.
usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D713F805053-if00 -> ../../ttyACM0
version: V 4.1.1-dev200611 SIGNALduino cc1101 (R: Ai B0*) - compiled at Jun 11 2020 23:55:06Bei der Auswahl der FW war ich etwas verwirrt durch die Information in der Wiki "https://wiki.fhem.de/wiki/Maple-SignalDuino"
ZitatDie "Maple_cul_USB_....bin" ist für den MapleCUL und MapleCUN.
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_sduino_Boot20_USB_410dev200501.bin -R
oder
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_cul_Boot20_USB_410dev200501.bin -R
Ich gebe zu, mit etwas genauerem Nachdenken und Studium der Forum-Beiträge, wird klar, was gemeint ist.
Dennoch die Frage , ob die Info zum MapleCUL/CUN dort stehen muss. Zudem finde ich einen Hinweis und Link zum Device "SIGNALDuino" sehr hilfreich.
Die Info zum SPI und zu den Modulen war für mich sehr hilfreichen.
Vielen Dank für die Unterstützung
Gruß
Rolf
@Reinhard.M
...hier mal ein paar allgemeine Tipps zum Flashen inkl. Alternativen...
https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen
PS: Wenn der Offset im Firmware-Binary nicht zum Binary der Firmware passt, wird diese nicht laufen. (Ich vermute mal, wenn du den Bootloader nicht selbst geflasht hast, wird es nicht der 2.0 sein)
ZitatHallo Ralf,
ich würde gerne die LAN Schnittstelle in Betrieb nehmen scheitere aber derzeit wahrscheinlich an meiner eigenen Blindheit:
Wie sollte das grundsätzliche Vorgehen bei der LAN Variante aussehen?
Bei der LAN Version wird USB nicht verwendet, Du kannst in der Arduino IDE den "USB Support" auf "keine" setzen.
Per default sollte er mit den fogenden Werten per Ping und Telnet erreichbar sein:
ip_def[] = { 192, 168, 0, 244 }
gateway_def[] = { 192, 168, 0, 1 }
netmask_def[] = { 255, 255, 255, 0 };Du kannst auch die USB Version flashen und dann mit dem Befehl
ri die IP-Werte auslesen.
mit "Wi..." kann die ethernet config geändert werden, wird erst nach einem Reset wirksam
Wia - address
Wig - gateway
Win - network mask
z.B. Wia192.168.0.100
Gruß Ralf
Interpretiere ich das gerade richtig Ralf, das USB Binary kann ich auch über die LAN Schnittstelle ansprechen? Andernfalls würde die Möglichkeit die IP Adresse über USB zu lesen und zu ändern keinen Sinn machen. Ich bin verwirrt... :-[
Du kannst mit dem USB Binary über USB mit ri die IP-Werte auslesen und mit wi die IP-Werte ändern
und dann wieder die LAN Version flashen
Zitat von: Ralf9 am 27 Juni 2020, 22:43:40
Ich habe beim MC Decoder den Code angepasst.
Seitdem werden meine Oregon Sceintific THGR (Manchester) nicht mehr empfangen ...
2020.06.28 21:52:33 5: MapleMini: Get ccconf executed
2020.06.28 21:52:33 5: MapleMini: AddSendQueue, MapleMini: C0DnF (1)
2020.06.28 21:52:33 4: MapleMini: HandleWriteQueue, called
2020.06.28 21:52:33 4: MapleMini: SendFromQueue, called
2020.06.28 21:52:33 5: MapleMini: SimpleWrite, C0DnF
2020.06.28 21:52:33 4: MapleMini: Read, msg: C0Dn11=10B07157C43023B900070018146C070091
2020.06.28 21:52:33 5: MapleMini: Parse, noMsg: C0Dn11=10B07157C43023B900070018146C070091
2020.06.28 21:52:33 5: MapleMini: Read, msg: regexp=C0Dn11=[A-F0-9a-f]+ cmd=ccconf msg=C0Dn11=10B07157C43023B900070018146C070091
2020.06.28 21:52:33 5: MapleMini: Read, try asyncOutput of message Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud, Modulation: ASK/OOK, Syncmod: No preamble/sync
2020.06.28 21:52:33 4: MapleMini: HandleWriteQueue, called
2020.06.28 21:52:33 4: MapleMini: HandleWriteQueue, nothing to send, stopping timer
2020.06.28 21:52:48 4: MapleMini: KeepAlive, ok, retry = 0
2020.06.28 21:53:12 4: MapleMini: KeepAlive, not ok, retry = 1 -> get ping
2020.06.28 21:53:12 5: MapleMini: AddSendQueue, MapleMini: P (1)
2020.06.28 21:53:12 4: MapleMini: HandleWriteQueue, called
2020.06.28 21:53:12 4: MapleMini: SendFromQueue, called
2020.06.28 21:53:12 5: MapleMini: SimpleWrite, P
2020.06.28 21:53:12 4: MapleMini: Read, msg: OK
2020.06.28 21:53:12 5: MapleMini: Parse, noMsg: OK
2020.06.28 21:53:12 5: MapleMini: Read, msg: regexp=^OK$ cmd=ping msg=OK
2020.06.28 21:53:12 4: MapleMini: HandleWriteQueue, called
2020.06.28 21:53:12 4: MapleMini: HandleWriteQueue, nothing to send, stopping timer
2020.06.28 21:53:48 4: MapleMini: KeepAlive, ok, retry = 0
2020.06.28 21:54:12 4: MapleMini: KeepAlive, not ok, retry = 1 -> get ping
2020.06.28 21:54:12 5: MapleMini: AddSendQueue, MapleMini: P (1)
2020.06.28 21:54:12 4: MapleMini: HandleWriteQueue, called
2020.06.28 21:54:12 4: MapleMini: SendFromQueue, called
2020.06.28 21:54:12 5: MapleMini: SimpleWrite, P
2020.06.28 21:54:12 4: MapleMini: Read, msg: OK
2020.06.28 21:54:12 5: MapleMini: Parse, noMsg: OK
2020.06.28 21:54:12 5: MapleMini: Read, msg: regexp=^OK$ cmd=ping msg=OK
2020.06.28 21:54:12 4: MapleMini: HandleWriteQueue, called
2020.06.28 21:54:12 4: MapleMini: HandleWriteQueue, nothing to send, stopping timer
2020.06.28 21:54:48 4: MapleMini: KeepAlive, ok, retry = 0
ZitatSeitdem werden meine Oregon Sceintific THGR (Manchester) nicht mehr empfangen ...
Es sieht so aus als würde gar nichts mehr empfangen oder hast Du nur THGR?
Bringt es was, wenn Du mit dem raw Befehl "XE" den Empfang aktivierst?
Falls dies nichts bringt, kannst Du mal mit "set disableMessagetype MC.." den MC Decoder deaktivieren, dann werden die Nachrichten vom THGR als MU Nachrichten ausgegeben.
Bitte poste diese MU-Nachrichten.
Nachtrag:
bitte poste auch mal ein "get config"
Gruß Ralf
XE oder set disableMessagetype manchesterMC haben keine Auswirkung auf den Empfang.
Config:
MS=1;MU=1;MC=0;Mred=0_MScnt=4;maxMuPrint=768;maxMsgSize=1024;Mdebug=1;MdebFifoLimit=150/170
Welche Hardware verwendest Du? MapleCul oder MapleSduino?
Welche Firmware?
Maple_cul_USB_411dev200627.bin
oder
Maple_sduino_USB_411dev200627.bin
oder selbst compiliert?
Du kannst mal "eC" (Init eeprom to defaults) versuchen
eC
Init eeprom to defaults
detect B: Partn=0 Ver=0x08
und dann
CG
MS=1;MU=1;MC=1;Mred=0_MScnt=4;maxMuPrint=768;maxMsgSize=1024;Mdebug=1;MdebFifoLimit=150/170
V
V 4.1.1-dev200627 SIGNALduino cc1101 (R: B0*) - compiled at Jun 28 2020 15:12:54
C35
C35 = 0D
WS3D
cmdStrobeReg 3D chipStatus 1 delay2 1
Gruß Ralf
Hallo Ralf,
bin gerade dabei den mapleSduino zu testen. Das CC-Modul B (433 MHz) funktioniert soweit. Das CC-Modul A (868 MHz) kann ich zwar aktivieren und einrichten (?), aber nichts empfangen (Hoermann Garagen-Tor). Zudem irritiert micht die Liste der Clients und die Fragezeichen im Readings-cmds.
Set raw bA1
get raw cmdBank:
A: b=1 freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100]
ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)
set raw bB0
get raw cmdBank:
B: b=0 freq:433.600MHz bWidth:812KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:LaCrosse:KOPP_FC:PCA301:SIGNALduino_TOOL:SIGNALduino_un:
DEF /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D713F805053-if00@115200
DMSG YsA04545459CBF20
DevState initialized
DeviceName /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D713F805053-if00@115200
EQMSGCNT 0
FD 8
FUUID 5ef8b993-f33f-a993-3e8c-8067f74309ffc172
LASTDMSG YsA04545459CBF20
LASTDMSGID 43
MSGCNT 19
NAME MapleSduino1
NR 83
PARTIAL
RAWMSG MC;LL=-1246;LH=1315;SL=-610;SH=677;D=A04545459CBF20;C=641;L=53;R=211;s6;b6;
RSSI -96.5
STATE opened
TIME 1593461068
TYPE SIGNALduino
b_ccconf b=0 freq:433.600MHz bWidth:812KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
cc1101_frequency 433.600
sendworking 0
version V 4.1.1-dev200627 SIGNALduino cc1101 (R: Ai B0*) - compiled at Jun 28 2020 13:30:04
versionmodul v3.4.5-dev_ralf_06.06.
versionprotoL v3.4.5-dev_ralf_12.05.
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95|97|99|104)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
31:KOPP_FC ^kr..................
32:PCA301 ^\S+\s+24
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
90:SIGNALduino_TOOL ^pt([0-9]+(\.[0-9])?)(#.*)?
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2020-06-29 16:58:14 bWidth C10 = 57
2020-06-29 21:51:10 cc1101_config freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK)
2020-06-29 15:39:13 ccpatable 433 MHz, C3E = 00 84 00 00 00 00 00 00 => 5_dBm
2020-06-29 15:39:30 ccreg Unsupported command
2020-06-29 21:57:23 cmdBank
Unsupported command
2020-06-29 21:31:30 cmds ?S ? b CE CD CG CR CS CW C eC e P r R S t T V W x XE XQ
2020-06-29 21:31:40 config MS=1;MU=1;MC=1;Mred=0_MScnt=4;maxMuPrint=768;maxMsgSize=1024;Mdebug=1;MdebFifoLimit=150/170
2020-06-29 18:09:05 freeram 10864
2020-06-29 22:06:08 ping OK
2020-06-29 21:44:12 raw set r=A b=1 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0100
2020-06-29 21:53:08 state opened
2020-06-28 21:33:13 uptime 0 02:34:08
2020-06-29 21:31:53 version V 4.1.1-dev200627 SIGNALduino cc1101 (R: Ai B0*) - compiled at Jun 28 2020 13:30:04
getcmd:
keepalive:
ok 0
retry 0
mcIdList:
43
mnIdList:
msIdList:
14
muIdList:
69
83
98
Attributes:
room sduino
verbose 4
whitelist_IDs 14,43,69,83,98
Unklar ist mir, ob die Register und die selektierte Bank korrekt sind.
Vielen Dank und Gruß
Rolf
ZitatBei der Auswahl der FW war ich etwas verwirrt durch die Information in der Wiki
Ich habe es mal hier im ersten Beitrag aktualisiert, ich hoffe es ist so verständlicher.
Die Einrichtung im Fhem ist im Wiki nun auch aktualisiert.
Zitataber nichts empfangen (Hoermann Garagen-Tor).
Ist das Hoermann Garagen-Tor SlowRF oder FSK (native)?
SlowRF funktioniert momentan nur auf Modul B. Ist wie noch einiges anderes auch auf der ToDo Liste.
Nachtrag
ZitatZudem irritiert micht die Liste der Clients und die Fragezeichen im Readings-cmds.
Es gibt für SlowRF und FSK eine gemeinsame Client Liste.
Es gibt auch die CMDs "?" und "?S"
Gruß Ralf
Hallo Reinhard
konntest Du die LAN Version inzwischen inbetrieb nehmen?
ZitatAußerdem habe ich die Standard-IP Adressen auf mein Netz angepasst.
Beim ersten inbetriebnehmen der firmware (auch bei der USB Version) werden die Standard-IP Adressen ins EEPROM/Flash geschrieben, ein nachträgliches ändern im Quellcode hat keine Auswirkung mehr.
Ich könnte von Dir noch log Daten mit verbose 4 gebrauchen.
Ca 30 Minuten mit aktiviertem MC-Decoder
und ca 30 Minuten mit "CSmaxMsgSizex256=4" und abgeschaltetem MC-Decoder.
Mit interessieren besonders die langen MU-Nachrichten mit einem Datenteil ("D=....;") von mehr als 255 Zeichen
Gruß Ralf
Hallo Ralf,
habe die LAN Version inzwischen zum Laufen bekommen. Dein Tipp mit dem Wi im USB Mode war mein fehlendes Puzzle Teil ;D
Sowohl mein Maple als auch mein Sduino liefen vorher mit der MessageSize Anpassung 6 bzw 5 Tage fehlerfrei bis ich die aktuelle Version aufgespielt habe. Bislang (seit 2 Tagen) keine Fehler. Allerdings schmeißt die LAN Variante immer wieder einen "wr -6-". Werde morgen mal die beiden Logs kreieren, kann ich die MessageSize auch auslesen? Und welches Kürzel sagt mir etwas über die Länge der Message? Wie gesagt, bin diesbezüglich noch blutiger Anfänger. Sammel gerade alles was ich bezüglich Befehlen und sonstigen Angaben zum Sduino in den Forenbeiträgen finden kann und möchte es den Wiki Autoren zur Verfügung stellen, macht mir das Nachlesen leichter ;)
Zitat von: Ranseyer am 28 Juni 2020, 20:42:55
@Reinhard.M
...hier mal ein paar allgemeine Tipps zum Flashen inkl. Alternativen...
Hallo Martin,
danke für den Hinweis, war mir bekannt :) Mein Fehler war, dass ich die "but=32" Taste überhaupt nicht oder nicht schnell genug nach der Reset Taste gedrückt habe. Dadurch kam ich nicht in den DFU Mode. Mich hatte gewundert, dass ich die FW nur aus dem Arduino IDE direkt aufspielen konnte. Mit der Tastenakrobatik konnte ich dann die Binaries auch direkt aufspielen. Meine Maple Boards hatten bereits den 2.0 Bootloader aufgespielt, leide habe ich noch keine Möglichkeit gefunden das auszulesen. Alles andere funktioniert bestens, habe jetzt 3 Sduinos zum Testen 8)
Zitat von: Ralf9 am 29 Juni 2020, 18:55:30
Welche Hardware verwendest Du? MapleCul oder MapleSduino?
MapleCul mit Maple_cul_USB_411dev200627.
Ich kann's mir nicht erklären. Obwohl das CC113L Funkmodul korrekt initialisiert wird, empfängt es weiterhin keine Funkpakete.
Die obligatorische Gegenprobe mit a-culfw belegt, dass der Empfang mit diesem Funkmodul auf 433 MHz funktioniert.
Funktioniert es mit der Maple_cul_USB_411dev200611.bin?
Ich habe auch CC113L Funkmodule mit der Version 0x18 und 0x08, die funktionieren problemlos.
Ich habe auch mal mit fliegender Verdrahtung die Maple_cul_USB_411dev200627.bin getestet.
Hat das
eC - Init eeprom to defaults
was gebracht?
@Reinhard.M
funktioniert die Maple_cul_USB_411dev200627 bei Dir?
ZitatAllerdings schmeißt die LAN Variante immer wieder einen "wr -6-".
bei mir läuft die LAN Version bis jetzt stabil ohne wr
uptime: 3 03:45:52
version: V 4.1.1-dev200627 SIGNALduino LAN cc1101 (R: A1 B0*) -0- compiled at Jun 27 2020 18:03:41kann ich die MessageSize auch auslesen? Und welches Kürzel sagt mir etwas über die Länge der Message?nein da gibt es keine Möglichkeit.
Ich kopiere die sehr langen MU Nachrichten in einen Texteditor, da sehe ich dann die Länge hinter "D=" bis ";"
Zitat von: Ralf9 am 30 Juni 2020, 21:53:05
Funktioniert es mit der Maple_cul_USB_411dev200611.bin?
Ja, das hat es bis zu dem Zeitpunkt, als ich auf 411dev200627 umgeflasht habe.
eC hat nichts bewirkt.
Hallo Ralf,
vielen Dank.
ZitatDie Einrichtung im Fhem ist im Wiki nun auch aktualisiert.
Das habe ich schon gesehen, aus meiner Sicht ist das perfekt und wird dem Einen oder Anderen beim Installieren helfen.
ZitatIst das Hoermann Garagen-Tor SlowRF oder FSK (native)?
Leider SlowRF. Da ich aber die Ursache für das Nichtfunktionieren kenne und die Client Liste geplant ist, kann ich damit leben.
Gibt es eine Möglichkeit die Funktion vom Modul A zu testen?
Beim Einrichten der CC-Module habe ich etwas "gespielt" und dabei einiges durcheinander gebracht. Nachdem ich die CC-Module deaktiviert habe und nach der Anleitung "https://wiki.fhem.de/wiki/Maple-SignalDuino, erste Schritte" wieder eingerichtet habe, schien alles wieder zu funktionieren. Nachdem reboot waren die CC-Module deaktiviert.
version: V 4.1.1-dev200627 SIGNALduino cc1101 (R: A1 B0*) - compiled at Jun 28 2020 13:30:04
version: V 4.1.1-dev200627 SIGNALduino cc1101 (R: Ai* Bi) - compiled at Jun 28 2020 13:30:04Zudem ist die cmdBank der CC-Module durcheinander.
A: b=0 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)Lässt sich das wieder richten, oder muss ich neu flashen?
Gruß
Rolf
Zitat von: Ralf9 am 30 Juni 2020, 21:53:05
@Reinhard.M
funktioniert die Maple_cul_USB_411dev200627 bei Dir?
Seit mehr als 2 Tagen fehlerfrei :)
Hallo Rolf
ZitatGibt es eine Möglichkeit die Funktion vom Modul A zu testen?
Nur mit FSK, dies sind die native Mode N1 bis N3 von der a-culw
Hast Du homematic?
ZitatLässt sich das wieder richten, oder muss ich neu flashen?
Am einfachsten mit dem raw Befehl
eC
Init eeprom to defaults
ein Ai und Bi nach einem Reset bedeutet, daß Du die Bankkonfiguration nicht durch ein anhängen von W gespeichert hast
Zitat von: locutus am 30 Juni 2020, 22:04:28
Ja, das hat es bis zu dem Zeitpunkt, als ich auf 411dev200627 umgeflasht habe.
eC hat nichts bewirkt.
Funktioniert FSK
Hast Du schon versucht ob es wieder funktioniert, wenn Du wieder zurück flasht auf Maple_cul_USB_411dev200611.bin?
Hallo Ralf,
habe jetzt die Daten zusammen. Die MessageSize lässt sich übrigens doch mit einem "get <sduino> config" auslesen.
Habe gerade feststellen müssen, dass die Antwotlänge begrenzt wird, muss alles nochmals zusammenstellen. File kommt mit dem nächsten Posting.
In der angehängten Datei findest du jetzt 2 Phasen zusammengefasst. Immer mit maxMsgSize=1024, einmal mit MC=1 und einmal MC=0. Ich habe immer alle 3 Empfänger damit laufen lassen, damit stehen auch Vergleichsmöglichkeiten zur Verfügung. Einen "-wr-" hat es bislang nicht mehr gegeben:
myMaple uptime: 2 22:56:13
myLAN uptime: 1 05:50:08
mySduino uptime: 2 22:38:17
Wenn du weitere Infos brauchst lass es mich wissen.
Gruß Reinhard
Hallo Ralf,
ZitatAm einfachsten mit dem raw Befehl eC Init eeprom to defaults. ein Ai und Bi nach einem Reset bedeutet, daß Du die Bankkonfiguration nicht durch ein anhängen von W gespeichert hast
Da ich mir nicht sicher war, was ich alles durcheinander gebracht habe, habe ich die CC-Module mit CRDA und CRDB deaktiviert und "Init eeprom to defaults" mit raw eC durchgeführt. Nach der neuen Definition beider Module nach der Anleitung "https://wiki.fhem.de/wiki/Maple-SignalDuino, erste Schritte" funktioniert das CC-Modul B (433 MHz) wieder. Wie von Dir beschrieben, muss die Bankkonfiguration mit bA1W gespeichert werden.
Nur so funktioniert das CC-Modul B (A kann ich noch nicht testen) nach dem reboot und die ccconf's werden im Internals angezeigt.
Zitatr=A b=1 rx=0 ccmode=0 sync=D391 ccconf=21627657C43023B900070018146C070090 boffs=0100
r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10AD4A07C43023B900070018146C070090 boffs=0000*
In der Anleitung "erste Schritte" ist das Speichern mit "Bei Bedarf kann diese Zuordnung durch anhängen von W im EEPROM gespeichert werden" erwähnt. Ich habe das im Zusammenhang mit der Eingabe von neuen Werten gesehen. Wäre sicher hilfreich wenn "Bedarf" etwas präzisiert wird.
ZitatHast Du homematic?
Leider nein. Zwar benötige ich das CC-Modul A (868 MHz) erst wenn es die SlowRF Clients gibt, da ich aber beim Empfang mit dem CC-Modul B eine Wechselwirkung mit dem CC_Modul A beobachtet habe, will ich das Modul doch zeitnahe testen.
Beim Empfang der Signale von meinem SOMFY Sonnen-Wind Sensor werden alle 15 Minuten 4*5 Signale gesendet. Über 24 Stunden habe ich mit dem CC-Modul A (433 MHz) nur 2 unknown Signale erhalten, mit RSSI Werten zwischen -50 und -60.
Wenn ich das CC_Modul A (868 MHz) aktiviere liegen die RSSI Werte zwischen -90 und -99, vereinzelt bei -60.
Gibt es hierfür eine Erklärung?
Danke und Gruß
Rolf
Nachtrag: Der Effekt korreliert mit der eingestellten Frequenz im Modul A. Wenn ich diese auf 433 MHz ändere, sind die RSI Werte ok, wenn ich sie wieder auf 868 MHz ändere, wieder schlecht.
Gruß
Rolf
Zitatda ich aber beim Empfang mit dem CC-Modul B eine Wechselwirkung mit dem CC_Modul A beobachtet habe, will ich das Modul doch zeitnahe testen.
Ist mir noch nicht aufgefallen, muss ich mal drauf achten.
Hast Du die Antennen in verschiedene Richtungen ausgerichtet?
Hast Du den Effekt auch, wenn Du Modul A Bank 1 mit "Mode 1 - IT+ 17.241 kbps (LaCrosse)" konfigurierst?
get sduino raw CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03,404d,4131,425f,4349,4454,452b,4600
Hallo Ralf,
ZitatHast Du die Antennen in verschiedene Richtungen ausgerichtet?
Hast Du den Effekt auch, wenn Du Modul A Bank 1 mit "Mode 1 - IT+ 17.241 kbps (LaCrosse)" konfigurierst?
Die Antennen sind im ca. 45° Winkel ausgerichtet. Die Ausrichtung schließe ich aber aus, da der Effekt auch ohne die 868 Antenne auftritt.
Ich habe heute den Einfluss vom Modul A (868 und 433 MHz) nochmals bestätigt und unter identischen Bedingungen den Einfluss der Antenne sowie der LaCrosse Konfiguration untersucht, in Summe ware das ca. 400 Signale.
- Ein negativer Einfluss (RSSI ca. -60 (ca. 40%) bis -95 (ca. 60 %)) gibt es nur durch das Modul A mit 868 MHz SlowRF mit und ohne Antenne.
- Kein signifikanten Einfluss (RSSI - 53 bis -60) gibt es durch das Modul A mit 433 MHz SlowRF und LaCrosse.
Beim Konfigurieren von LaCrosse bin ich mir nicht sicher, ob das korrekt erfolgte, Details siehe unten.
Nur CC-Modul B
b_ccconf b=0 rx=0 freq:433.600MHz bWidth:812KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
2020.07.02 06:57:00 4: MapleSduino1: Found manchester Protocol id 43 clock 638 RSSI -53.5 -> Somfy RTS
2020.07.02 06:57:00 4: MapleSduino1: Somfy bitdata: 10100000010001010100010101000101100111001011111100100010 (56)
2020.07.02 06:57:00 4: MapleSduino1 Dispatch: YsA04545459CBF22, -53.5 dB, dispatch
2020.07.02 06:57:00 4: MapleSduino1: Somfy RTS preprocessing check: 5 enc: A04545459CBF22 dec: A0E50000D9239D
2020.07.02 06:57:00 4: MapleSduino1/msg READ: MC;LL=-1275;LH=1277;SL=-627;SH=657;D=A04545459CBF22;C=639;L=56;R=41;s9;b9;
CC-Modul A FSk und CC-Modul B
a_ccconf b=1 rx=0 freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:17257.69Baud) [boffs=0100]
a_ccconfFSK ccmode=3 sync=2DD4 Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold)
b_ccconf b=0 rx=0 freq:433.600MHz bWidth:812KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000*]
2020.07.02 19:46:58 4: MapleSduino1: Found manchester Protocol id 43 clock 639 RSSI -58.5 -> Somfy RTS
2020.07.02 19:46:58 4: MapleSduino1: Somfy bitdata: 10100000010001010100010101000101100111001011111100100010 (56)
2020.07.02 19:46:58 4: MapleSduino1 Dispatch: YsA04545459CBF22, Dropped (1) due to short time and equal msg
2020.07.02 19:46:58 4: MapleSduino1/msg READ: MC;LL=-1247;LH=1319;SL=-600;SH=667;D=A04545459CBF22;C=638;L=56;R=29;s17;b17;w;
CC-Modul A 868 MHz und CC-Modul B
a_ccconf b=1 rx=0 freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100*]
b_ccconf b=0 rx=0 freq:433.600MHz bWidth:812KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
2020.07.02 15:13:07 4: MapleSduino1: Found manchester Protocol id 43 clock 639 RSSI -96.5 -> Somfy RTS
2020.07.02 15:13:07 4: MapleSduino1: Somfy bitdata: 10000001000101010001010100010110011100101111110010001000 (54)
2020.07.02 15:13:07 4: MapleSduino1 Dispatch: Ys8115151672FC88, -96.5 dB, dispatch
2020.07.02 15:13:07 4: MapleSduino1: Somfy RTS preprocessing check: 4 enc: 8115151672FC88 dec: 81940003648E74
2020.07.02 15:13:07 4: MapleSduino1/msg READ: MC;LL=-1222;LH=1336;SL=-591;SH=690;D=A04545459CBF22;C=639;L=56;R=210;s10;b10;
2020.07.02 15:13:07 4: MapleSduino1: Found manchester Protocol id 43 clock 639 RSSI -97 -> Somfy RTS
2020.07.02 15:13:07 4: MapleSduino1: Somfy bitdata: 10100000010001010100010101000101100111001011111100100010 (56)
2020.07.02 15:13:07 4: MapleSduino1 Dispatch: YsA04545459CBF22, -97 dB, dispatch
2020.07.02 15:13:07 4: MapleSduino1: Somfy RTS preprocessing check: 5 enc: A04545459CBF22 dec: A0E50000D9239D
2020.07.02 15:13:08 4: MapleSduino1/msg READ: MC;LL=-1221;LH=1335;SL=-603;SH=686;D=A04545459CBF22;C=640;L=56;R=26;s11;b11;
2020.07.02 15:13:08 4: MapleSduino1: Found manchester Protocol id 43 clock 640 RSSI -61 -> Somfy RTS
2020.07.02 15:13:08 4: MapleSduino1: Somfy bitdata: 10100000010001010100010101000101100111001011111100100010 (56)
2020.07.02 15:13:08 4: MapleSduino1 Dispatch: YsA04545459CBF22, Dropped (1) due to short time and equal msg
2020.07.02 15:13:08 4: MapleSduino1/msg READ: MC;LL=-1247;LH=1320;SL=-609;SH=676;D=A04545459CBF22;C=641;L=56;R=211;s9;b9;w;
CC-Modul A 868 MHz ohne Antenne und CC-Modul B
a_ccconf b=1 rx=0 freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100*]
b_ccconf b=0 rx=0 freq:433.600MHz bWidth:812KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
2020.07.02 17:00:53 4: MapleSduino1: Found manchester Protocol id 43 clock 640 RSSI -96.5 -> Somfy RTS
2020.07.02 17:00:53 4: MapleSduino1: Somfy bitdata: 10100000010001110100011101000101100111001011111100100010 (56)
2020.07.02 17:00:53 4: MapleSduino1 Dispatch: YsA04747459CBF22, Dropped (3) due to short time and equal msg
2020.07.02 17:00:58 4: MapleSduino1/msg READ: MC;LL=-1235;LH=1327;SL=-588;SH=685;D=4747459CBF22;C=639;L=48;R=211;s2;b1;
2020.07.02 17:00:58 4: MapleSduino1/msg READ: MC;LL=-1237;LH=1337;SL=-576;SH=685;D=3A3A2CE5F910;C=639;L=45;R=211;s4;b1;w;
2020.07.02 17:00:58 4: MapleSduino1/msg READ: MC;LL=-1237;LH=1337;SL=-576;SH=685;D=A04747459CBF22;C=639;L=56;R=211;s17;b17;w;
2020.07.02 17:00:58 4: MapleSduino1: Found manchester Protocol id 43 clock 639 RSSI -96.5 -> Somfy RTS
2020.07.02 17:00:58 4: MapleSduino1: Somfy bitdata: 10100000010001110100011101000101100111001011111100100010 (56)
2020.07.02 17:00:58 4: MapleSduino1 Dispatch: YsA04747459CBF22, -96.5 dB, dispatch
2020.07.02 17:00:58 4: MapleSduino1: Somfy RTS preprocessing check: 7 enc: A04747459CBF22 dec: A0E70002D9239D
2020.07.02 17:00:58 4: MapleSduino1/msg READ: MC;LL=-1237;LH=1337;SL=-576;SH=685;D=A04747458;C=639;L=34;R=211;s17;b17;
2020.07.02 17:00:59 4: MapleSduino1/msg READ: MC;LL=-1246;LH=1319;SL=-603;SH=675;D=A04747459CBF22;C=640;L=56;R=33;s20;b20;
2020.07.02 17:00:59 4: MapleSduino1: Found manchester Protocol id 43 clock 640 RSSI -57.5 -> Somfy RTS
2020.07.02 17:00:59 4: MapleSduino1: Somfy bitdata: 10100000010001110100011101000101100111001011111100100010 (56)
2020.07.02 17:00:59 4: MapleSduino1 Dispatch: YsA04747459CBF22, Dropped (1) due to short time and equal msg
2020.07.02 17:01:02 4: MapleSduino1/msg READ: MC;LL=-1247;LH=1423;SL=-601;SH=674;D=A04747459CBF22;C=657;L=56;R=211;s10;b10;
CC-Modul A 433 MHz und CC-Modul B 433 MHz
a_ccconf b=1 rx=0 freq:433.600MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100]
b_ccconf b=0 rx=0 freq:433.600MHz bWidth:812KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000*]
2020.07.02 17:14:45 4: MapleSduino1: Found manchester Protocol id 43 clock 639 RSSI -55.5 -> Somfy RTS
2020.07.02 17:14:45 4: MapleSduino1: Somfy bitdata: 10100000010001110100011101000101100111001011111100100010 (56)
2020.07.02 17:14:45 4: MapleSduino1 Dispatch: YsA04747459CBF22, Dropped (2) due to short time and equal msg
2020.07.02 17:14:45 4: MapleSduino1/msg READ: MC;LL=-1232;LH=1320;SL=-584;SH=685;D=A04747459CBF22;C=636;L=56;R=37;s2;b2;
Beim Konfigurieren vom Modul A fiel mir auf, dass nach get raw CREA "raw: detect A: Partn=0 Ver=0x14" und nicht "... Ver=0x20" ausgegeben wird.
Vielen Dank und Gruß
Rolf
Hallo Rolf,
Modul A funktioniert nicht mit SlowRF, bei SlowRF werden die Pulse über eine Interruptroutine eingelesen. Das Einlesen der Pulse über eine Interruptroutine funktioniert momentan nur bei Modul B.
Bei Modul A werden die Pulse über den FIFO des cc1101 eingelesen und dies funktioniert nicht, wenn Modul A auf SlowRF konfiguriert ist.
Gruß Ralf
Hallo Ralf,
das Modul A mit SlowRF aktuell nicht funktioniert war mir bewusst. Verstehe ich das richtig, wenn SlowRF beim Modul A funktioniert, ist der Einfluss auf Modul B weg?
Danke und Gruß
Rolf
Dies lässt sich wahrscheinlich vorab nicht testen.
Ich möchte jetzt erst mal eine Version haben die stabil und fehlerfrei läuft.
Ich habe bei den Interrupts noch ein paar Verständnisprobleme und habe dazu noch ein paar Fragen.
Wer kennt sich damit näher aus und kann mir weiterhelfen. @Telekatz?
Hallo locutus,
ich hab momentan keine so richtige Idee, warum bei Dir mit dem cc1101 Modul B nichts empfangen wird.
Hast Du außer den Oregon noch andere Sensoren?
Normalerweise werden auch noch MS- oder MU-Nachrichten von anderen Sensoren empfangen, z.B. von Nachbarn.
Hast Du schon mal mit einem Logicanalyzer geschaut ob an "18 GD02 (Receive)" Pulse ankommen.
Evtl bringt es was die Bandbreite zu erhöhen.
In der Anlage ist eine Version, bei der einige Debugausgaben aktiviert sind.
Gruß Ralf
Aus der Nachbarschaft werden für gewöhnlich SD, TCM und TX Sensoren empfangen. Die Bandbreitenerhöhung brachte auch nichts.
Ich habe nun den Speicherinhalt des STM32F komplett gelöscht und anschließend die 411dev200627 installiert.
Nun empfängt er wieder tadellos ...
Bei mir sieht es jetzt recht gut aus.
Bei der
USB Version habe ich eine uptime von 5 Tagen und fast 8 Stunden.
Bei der
LAN Version habe ich eine uptime von 6 Tagen und fast 5 Stunden.
Bei der
serial (über WemosD1 mini) Version habe ich eine uptime von fast 5 Tagen.
Ich habe hier bei der ersten Nachricht unten XQ und XE ergänzt.
Bei den Hinweisen zum compilieren habe ich die Empfehlungen für die Arduino IDE board konfig ergänzt.
ZitatIn der Anleitung "erste Schritte" ist das Speichern mit "Bei Bedarf kann diese Zuordnung durch anhängen von W im EEPROM gespeichert werden" erwähnt. Wäre sicher hilfreich wenn "Bedarf" etwas präzisiert wird.
Habe ich geändert.
ZitatIch habe nun den Speicherinhalt des STM32F komplett gelöscht und anschließend die 411dev200627 installiert.
Nun empfängt er wieder tadellos ...
@Telekatz hast Du dafür eine Erklärung?
@Reinhard.M
Danke für Logs. Der TFA 30.3222.02 (protocol-id 85) sendet sehr lange Nachrichten. Er sendet die Daten ca 6 mal mit jeweils 140 Pulsen. Dies ergibt eine Datengesamtlänge von über 800.
Hier ist eine ToDo Liste, wird aber noch eine Weile dauern, ich kann dabei Hilfe gebrauchen
- SlowRF auch zusätzlich für cc1101 Modul A oder C
- bei der LAN Version eine Serial-Bridge zu einer seriellem Port.
- unterstützung von platformio
- "verschönerung" vom code. Die defines in ein eigenes File auslagern.
Ich würde gerne die FastDelegate.h durch normales callback ersetzen.
Hallo Ralf,
für die Defines wollte ich auch schon eine eigene Header vorschlagen. Werde kommende Woche mal einen Vorschlag ausarbeiten. Falls nicht jemand anderes schneller ist :)
Zitat von: Ralf9 am 03 Juli 2020, 23:31:29
@Telekatz hast Du dafür eine Erklärung?
Ich vermute mal, das sind irgendwelch gespeicherten Konfigurationseinstellungen, die beim Flashen einer neuen Firmwareversion nicht überschrieben werden. Hast du eine Factory Reset Funktion für die Konfigurationseinstellungen?
Zitat von: Telekatz am 04 Juli 2020, 10:16:00
Ich vermute mal, das sind irgendwelch gespeicherten Konfigurationseinstellungen, die beim Flashen einer neuen Firmwareversion nicht überschrieben werden. Hast du eine Factory Reset Funktion für die Konfigurationseinstellungen?
Ich habe einen Befehl "
e" zum zurücksetzen des gewählten cc1101 und der zugeordneten EEPROM Bank auf die SlowRF defaults,
und einen Befehl "
eC" für die Factory Reset Funktion der Konfig im EEPROM.
Da locutus testweise auch die a-culw geflasht hatte, wurde dann durch die nicht mehr passende Versionswerte am Anfang des EEPROMs schon automatisch die Factory Reset Funktion ausgeführt.
Ich werde im Maple Signalduino Wiki am Ende ein Abschnitt "Debugging / weiteres" ergänzen und dort u.a. zum Factory Reset was schreiben.
Zitatfür die Defines wollte ich auch schon eine eigene Header vorschlagen. Werde kommende Woche mal einen Vorschlag ausarbeiten. Falls nicht jemand anderes schneller ist
Ich denke es macht Sinn dafür ein neues Thema aufzumachen oder im Github zu schreiben.
Ich kann Vorschläge für einen Namen für die neue Header Datei gebrauchen.
Ich habe mal die Protocol ID Übersicht angeschaut, und geschaut bei welchen Protocol IDs der vergrößerte Messagepuffer deutliche Vorteile bringt:
- Bei der protocol-id 85 sendet der TFA 30.3222.02 sehr lange Nachrichten. Er sendet die Daten ca 6 mal mit jeweils 140 Pulsen. Dies ergibt eine Datengesamtlänge von über 800.
Mit dem seitherigen maximalem messagepuffer von 254 würden sie nur einmal empfangen.
Von den folgenden Protocol IDs kann ich noch lange MU-Nachrichten gebrauchen
"48" => ## Joker Dostmann TFA 30.3055.01
"54" => ## TFA Drop 30.3233.01 - Rain gauge
"69" => ## Hoermann HSM2, HSM4, HS1-868-BS (868 MHz)
"82" => ## Fernotron shutters and light switches
"95" => # Techmar / Garden Lights Fernbedienung, 6148011 Remote control + 12V Outdoor receiver
"105" => # Remote control BF-301 (Roller shade system) from Shenzhen BOFU Mechanic & Electronic Co.
Es gibt eine neue Version meines angepassten 00_SIGNALduino.pm fhem Moduls
versionmodul: v3.4.5-dev_ralf_05.07.
versionprotoL: v3.4.5-dev_ralf_05.07.
update all https://raw.githubusercontent.com/Ralf9/RFFHEM/master/controls_signalduino.txt
https://github.com/Ralf9/RFFHEM/commits/master
Init für Maple Mini optimiert
perlcritic
Device specific help aktualisiert
neue protocol ID 105 für remote control BF-301 (Roller shade system) von markisol
Per Zufall bin ich auf diesen Thread gekommen und habe diesen kurz überflogen.
Ich habe einen 4-fach-MapleCUL von Locutus (https://forum.fhem.de/index.php/topic,80872.0.html).
Ich konnte das nicht auf Anhieb erkennen, aber kann man diese SIGNALDuino-Entwicklung nicht nur auf einem Maple Mini installieren, sondern auch auf ältere MapleCULs?
ZitatIch habe einen 4-fach-MapleCUL von Locutus (https://forum.fhem.de/index.php/topic,80872.0.html).
Ich konnte das nicht auf Anhieb erkennen, aber kann man diese SIGNALDuino-Entwicklung nicht nur auf einem Maple Mini installieren, sondern auch auf ältere MapleCULs?
USB "Maple_cul_USB_411dev200627.bin"
und WLAN "Maple_cul_serial_411dev200627.bin"
sollte eigentlich funktionieren.
Laut Schaltplan wird wie beim Maple Mini der STM32F103CBT6 verwendet.
Ich gehe mal davon aus, daß bei allen Varianten das zweite cc1101 Modul 433 MHz ist.
Gruß Ralf
So wies aussieht läufts inzwischen recht stabil.
Bei der USB Version habe ich eine uptime von 14 Tagen
Bei der LAN Version habe ich eine uptime von 15 Tagen.
Ich habe auch das 36_PCA301.pm Modul für den Signalduino erweitet
https://github.com/Ralf9/36_PCA301.pm
Liest hier jemand mit der einen WS 1600 (TX22) hat?
@nagelreo
Ich habe das Wiki und "erste Schritte" überarbeitet, ich hoffe, daß es so besser verständlich ist.
Was für eine Hoermann Fernbedienung hast Du?
Für Hoermann gibts die Protokol ID 69
"69" => ## Hoermann HSM2, HSM4, HS1-868-BS (868 MHz)
Ich könnte einige raw Nachrichten (es müssten MU-Nachrichten sein) brauchen.
Gruß Ralf
Zitat von: Ralf9 am 06 Juli 2020, 18:53:56
USB "Maple_cul_USB_411dev200627.bin"
und WLAN "Maple_cul_serial_411dev200627.bin"
sollte eigentlich funktionieren.
Laut Schaltplan wird wie beim Maple Mini der STM32F103CBT6 verwendet.
Ich gehe mal davon aus, daß bei allen Varianten das zweite cc1101 Modul 433 MHz ist.
Ich habe große Lust, das auszuprobieren. Ich muss es nur leider mit der echten Umgebung ausprobieren.
An meinem MapleCUL habe ich noch einen HM-MOD-UART. Hat die neue Signalduino-Firmware Einfluss darauf?
Entschuldige, dass ich möglicherweise komische Fragen stelle.
ZitatAn meinem MapleCUL habe ich noch einen HM-MOD-UART. Hat die neue Signalduino-Firmware Einfluss darauf?
Der Bezeichnung nach (MapleCUL) ist die Anbindung über USB.
Der HM-MOD-UART wird mit der Signalduino-Firmware nicht funktionieren. Eine serielle durchleitung über USB ist mit der Signalduino-Firmware wahrscheinlich nicht machbar.
Schade. Ich möchte ungern wieder eine Vielzahl an CULs in Betrieb nehmen.
Ich mag Signalduino aufgrund seiner stetigen Weiterentwicklung und der Vielzahl an unterstützen Geräte. Nicht weil ich diese brauche, sondern einfach nur weil ich es könnte. ;D
Der Wechsel von MapleCUL (ja, USB) auf Maple-Signalduino wäre daher ganz mein Wunsch gewesen. Aber dann müsste ich mir für Homematic eine neue Lösung einfallen lassen.
Ich habe die Unterschiede nie so richtig verstanden:
- Signalduino decodiert in der Hardware/Firmware?
- Und MapleCxx überlassen das den FHEM-Modulen?
Sorry fürs offtopic.
ZitatIch habe die Unterschiede nie so richtig verstanden:
- Signalduino decodiert in der Hardware/Firmware?
- Und MapleCxx überlassen das den FHEM-Modulen?
Nein umgekehrt, der Signalduino überträgt die raw Nachrichten zum FHEM-Modul, dort erfolgt dann die Decodierung mit Hilfe der Protocol IDs.
Beim Cul erfolgt die Decodierung in der Firmware.
Ich finde das Flashen des Bootloaders noch recht kompliziert, dies müsste doch evtl noch etwas einfacher gehen?
https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen
Momentan ist entweder ein USB TTL Adapter oder die Arduino IDE mit dem passenden core notwendig.
Es müsste doch eigentlich auch ohne die Arduino IDE funktionieren, wenn die updater_stm32f1.ino compiliert wird und dann das bin File mit dem dfu-util geflasht wird
https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/updater_stm32f1/updater_stm32f1.ino
Kann bitte mal jemand die updater_stm32f1.ino mit dem core von Roger und der upload method "bootloder orginal" compilieren und das bin File dann hier posten?
Ich möchte testen ob man damit auch den bootloader 2.0 flashen kann.
Es fehlt auch noch eine Beschreibung wie man erkennen kann ob auf dem Maple Mini der orginal Bootloader oder bereits der bootloader 2.0 drauf ist.
Gruß Ralf
Ich habe es mit der updater_stm32f1.bin mal getestet.
Eine Möglichkeit zum Testen ob bereits der Bootloader 2.0 drauf ist, ist einfach mal versuchen die Maple_sduino firmware zu flashen.
Dazu die reset Taste drücken und innerhalb einer Sekunde, folgenden Befehl ausführen:
sudo ./dfu-util -v -d 1eaf:0003 -a 2 -D Maple_sduino_USB_411dev200627.bin -R
wenn das flashen erfolgreich war kommt ungefähr die folgende Ausgabe
...
Download [=========================] 100% 67404 bytes
Download done.
Sent a total of 67404 bytes
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
Wenn das flashen der firmware nicht funktioniert, muß der Bootloader 2.0 geflasht werden.
Dazu die reset Taste drücken und innerhalb einer Sekunde, folgenden Befehl ausführen (updater_stm32f1.bin siehe Anlage)
sudo ./dfu-util -v -d 1eaf:0003 -a 1 -D updater_stm32f1.bin
Danach die Resettaste drücken und den seriellen Monitor der Arduino IDE oder ein anderes serielles Terminal mit einer Baudrate von 9600 öffnen
Wenn die folgende Ausgabe kommt, "Y" senden.
Serial.println ("**************************************************************************************************");
Serial.println ("*** This sketch will update the bootloader in the Maple Mini to the STM32duino bootloader ****");
Serial.println ("*** With this you can use up to 120KB of Flash and 20KB of RAM for a Sketch ****");
Serial.println ("*** Uploading is also considerably faster on OSX (and possibly faster on Linux) ****");
Serial.println ("*** ****");
Serial.println ("*** Only use with Maple mini boards ****");
Serial.println ("*** ****");
Serial.println ("*** WARNING. If the update fails your Maple mini may not have a functional bootloder. ****");
Serial.println ("*** ****");
Serial.println ("*** YOU UPDATE AT YOUR OWN RISK ****");
Serial.println ("*** ****");
Serial.println ("*** To confirm and proceed, enter Y ****");
Wenn die folgende Ausgabe kommt, war das Flashen des Bootloader 2.0 erfolgreich und es kann mit den o.g. Befehl die Maple_sduino firmware geflasht werden
Writing flash page 1 of 7
Writing flash page 2 of 7
Writing flash page 3 of 7
Writing flash page 4 of 7
Writing flash page 5 of 7
Writing flash page 6 of 7
Writing flash page 7 of 7
Update completed successfully. - Please test by uploading a different sketch
Wenn aber die Meldung "WARNING, Update Failed!!..." kommt hat das flashen nicht geklappt.
Die ursache kann z.B. eine "flash read-protection sein", dann funktioniert das flashen des Bootloader 2.0 nur mit einem USB TTL Adapter, siehe hier
https://wiki.fhem.de/wiki/MapleCUN#Bootloader_flashen
https://wiki.fhem.de/wiki/MapleCUN#Firmware_flashen:
Hat jemand Erfahrung wie oft das vorkommt, daß bei einem neuen MapleMini eine "flash read-protection" drin ist?
Gruß Ralf
Inzwischen läufts bei mir stabil.
Ich habe produktiv eine LAN Version mit 2 cc1101 Modulen und einer uptime von fast 29 Tagen.
Auf einem Testsystem auf einem BananaPi hängt eine USB Version mit 3 cc1101 Modulen und einer uptime von 28 Tagen
Ein "get sduino cmdBank s" siehe Anlage.
Mit dem cc1101 B empfange ich meine WH3080 und 7 Temperatursensoren
Mit dem cc1101 A empfange ich ca alle 5 sec ein Technoline TX29 DTH-IT und schreibe die Temperatur alle 10 Min in ein Filelog, es sind keine Aussetzer erkennbar.
Mit dem cc1101 C mache alle 10 Min ein Statusrequest einer PCA301 Steckdose und speichere die Power in einem Filelog, es sind auch keine Aussetzer erkennbar.
Ich habe in der ersten Nachricht eine Beschreibung ergänzt
"einfacher SIGNALduino mit nur einem cc1101 Modul"
Gruß Ralf
Hey und guten Morgen,
hab mal ne Frage bezüglich dem SIGNALduino V4. Ich nutze zur Zeit in meinem Produktivsystem noch einen SIGNALduino mit einem Arduino nano, FW-Version V 3.3.2.1-rc9, SW-Version v3.4.4.
Ich steuere hier meine Jarolift-Rollläden über den SIGNALduino mittels Rollo-Modul und AutoShuttersControl. Jetzt ist mir aufgefallen das meine Rollläden nicht ganz in die Beschattungsstellung fahren, was sich auf die Fahrzeit zurückführen lässt. Das Rollo-Modul gibt die Anweisung zum fahren des Rollos und startet den Timer für die Fahrzeit, mein Rollladen fährt aber erst evtl. 2 Sekunden später los, was natürlich für den Stand des Rollladens schon falsch ist.
Das ASC-Modul setzt bei mir 7 Rollläden gleichzeitig auf "Beschattung", dieses gibt die Fahrbefehle an das Rollo-Modul weiter, das verarbeitet diese auch zeitgleich und gibt sie an den SIGNALduino weiter, diese kommen laut Log auch zeitgleich an:
2020.07.29 08:44:54 3: SIGNALduino: JaroLift set down 10
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 9
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 8
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 5
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 6
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 7
2020.07.29 08:44:55 3: SIGNALduino: JaroLift set down 3
Kann das sein das der SIGNALduino da eine Schleife für die Befehle eingebaut hat, z.B. Abarbeitung alle Sekunde oder so? Oder kann das am Arduino selbst liegen das dieser so langsam ist?
Hab mir vor einiger Zeit mal einen MapleCUL zusammen gebaut mit einem Maple Mini, müsste mal die FW aktualisieren und den testen, vielleicht könnt ihr mir aber im Vorfeld schon einmal was dazu sagen.
Gruß und mercy
Markus
ZitatKann das sein das der SIGNALduino da eine Schleife für die Befehle eingebaut hat, z.B. Abarbeitung alle Sekunde oder so? Oder kann das am Arduino selbst liegen das dieser so langsam ist?
In der firmware wird sofort gesendet, sobald das Sendekommando komplett empfangen wurde.
Im 00_SIGNALduino Modul werden die gleichzeitigen Sendebefehle in einer SendQueue gepuffert und nacheinander gesendet, der nächste Sendebefehl wird erst gesendet, wenn von der firmware die Rückmeldung kommt das der Sendebefehl gesendet wurde, beim offiziellen Modul von Sidey ist dabei eine Verzögerung von 0.1 Sek eingebaut.
Wie sieht es aus, wenn nur an einen Rolladen ein Befehl gesendet wird? Da dürfte es keine Verzögerung geben.
Gruß Ralf
Hallo Ralf,
ja bei Einzelbedienung wir sofort gesendet, ohne wirklich merkbare Verzögerung (evtl. max. 0,1 Sek. vom drücken des Buttons auf der Oberfläche bis dann wirklich der Rollladen fährt).
Ich merke aber auch wenn ich abends bzw. morgens die Rollläden eines Zimmers (2 Rolläden) über das ASC-Modul mittels roommate hoch- bzw. runterfahre das dort auch schon eine Verzögerung (werde die Zeit heute mal messen, geführt so fast ne Sekunde) vorhanden ist.
Markus
Hallo Markus,
Da dies kein Firmware Thema ist habe ich bei "Sonstige Systeme" dafür ein neues Thema aufgemacht
https://forum.fhem.de/index.php/topic,113268.0.html
Hallo Ralf,
ich wollte heute einen meiner LAN-SIGNALduinos wieder auf USB umstellen. Das geht zwar grundsätzlich, er liefert mir aber aus Einstellungs daten wie Version Config und ähnliches keinerlei Sensordaten. Als ich wieder zurück auf die LAN-FW gegangen bin, kamen die Daten wie erwartet. Habe ich etwas übersehen? Hängt irgendwo ein Setting?
Gruß Reinhard
sollte eigentlich funktionieren, hast Du für USB ein fertiges bin File genommen?
Gruß Ralf
Frisch compiliert. Das gleiche habe ich auf einem zweiten Sduino im Einsatz. Da läuft es problemlos. Werde gleich mal weitersuchen.
hast Du auch das
//#define LAN_WIZ 1 // die Ausgabe ueber Ethernet funktioniert nur, wenn dies hier nochmals definiert wird
in der signalDecoder4.h beachtet?
Du hast Recht, das könnte es sein. Da hatte ich nicht mehr dran gedacht. Checke ich heute noch
Zitat von: Ralf9 am 14 August 2020, 20:12:27
hast Du auch das
//#define LAN_WIZ 1 // die Ausgabe ueber Ethernet funktioniert nur, wenn dies hier nochmals definiert wird
in der signalDecoder4.h beachtet?
Das war's! Besten Dank für den Trigger. Irgendwie muss ich es noch dazwischen bekommen die Header-Dateien soweit anzupassen das solche Settings zentral an einer Stelle gemacht werden.
Welche Firmware passt für diesen Doppel CUL?
Oder sind die cc1101 falsch angebunden?
Ist alles recht ausführlich im ersten Posting zu finden:
https://forum.fhem.de/index.php/topic,106278.msg1001477.html#msg1001477 (https://forum.fhem.de/index.php/topic,106278.msg1001477.html#msg1001477)
Fall ich die Frage nicht falsch verstanden habe :)
diese hier
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_cul_USB_411dev200627.bin -R
Hi, ich habe mich mal an einen neuen Test gemacht den mapleduino zu testen. Leider habe ich generell noch immer Probleme mit meinem Lacrosse Sensor. Dieser wird sporadisch empfangen und hat dann längere Aussetzer.
Aber anders Thema: ich habe jetzt auch mal den 433 Empfang mal verglichen mit dem Signalduino auf nano-Basis.
Folgende Voraussetzung:
- Signalduino Nano und Mapleduino direkt nebeneinander platziert.
- Antenne hat gleiche Ausrichtung (aufrecht nach oben)
- gleiche Antenne an beiden Platinen
- Radio A mit 866 am maple deaktiviert
- CC1101 auf nano ist ein Steckmodul, auf Maple ist ein Stamp.
- nano läuft auf Prodtivsystem, maple auf testsystem (sollte ja keinen Unterschied machen)
Ich habe jetzt verschiedene Temperatursensoren auf unterschiedlicher Distanz:
Die RSSI Werte sind durchgehend schlechter: (nano vs maple)
nah: 45,5 vs 48,5
mittel: 55,5 vs 63
fern: 69,5 vs 81,5
Woran könnte das liegen?
Ich habe auch als Gegentest den MapleCUL gegen einen nanoCUL verglichen. Hier kamen die gleichen CC1101 module bzw stamps (also aus jeweils der gleichen Lieferung) zum Einsatz. Hier sind die Werte vergleichbar, der Maple sogar leicht besser.
Hat sowas schonmal jemand verglichen? Also RSSI Werte vom mapleduino vs nano signalduino?
Hallo,
denkst du wirklich RSSI Werte sind vergleichbar?
Wenn du einen plausiblen Vergleich erzielen möchtest, so kannst du das Ergebnis nur ,,annähernd plausibel" gestalten wenn du mit einer Hardware und einem Standort die Tests machst. Du müsstest die Firmware immer wechseln. Bei Funk kommt es auf cm drauf an und die unsichtbaren Verhältnisse sind nie gleich.
Alle Tests mit 2 Versionen von Hardware und Empfängern kann man meines Erachtens nicht pauschalisieren und vergleichen weil zu viele Faktoren da einspielen.
Mit freundlichen Grüßen Marco
Ja das verstehe ich ja was du sagst, für mich ist es halt seltsam, dass der gleiche Test mit einem mapleCUL vs nanoCUL ähnliche RSSI Werte bringen. Während der Vergleich maple signalduino vs nano signalduino größere Differenzen ergeben.
Ich hatte ja versucht, mögliche Gleichheit herzustellen.
Ich finde die Abweichungen da etwas hoch, da die Werte immer schlechter sind, auch wenn ich den Ort bzw Antennenausrichtung etwas ändere.
Ich mache vielleicht auch mal einen Reichweitetest, wann jeweils der Empfang abreisst.
Atennentechnik ist ein sehr heikles Thema dem sich hier im Forum ein eigener Thread widmet:
https://forum.fhem.de/index.php/topic,93021.0.html (https://forum.fhem.de/index.php/topic,93021.0.html)
Bei mir war es z.B. so, dass eine gekaufte Antenne um 6dB schlechter performed hat als ein auf passender Länge geschnittener Draht. Am gleichen Board mit gleicher Firmware!
Ja Thema kenne ich auch. Daher habe ich ja auch Antennen aus gleicher Lieferung verwendet und diese auch sogar mal getauscht, aber die Differenz im RSSI ist geblieben. Daher glaube ich nicht, dass es an der Antenne liegt.
Edit:
Hmmh. OK habe jetzt mal die Reichweite getestet. Und da ist der maple tatsächlich besser. Da empfange ich mit -76 noch einen Wert, den der nano sduino nicht mehr bekommt.
Scheint also kein schlechterer Empfang zu sein, sondern nur eine schlechtere Anzeige es Rssi Wertes.
Zitat- Radio A mit 866 am maple deaktiviert
Hast Du auch die 866 Antenne entfernt?
Zitat- CC1101 auf nano ist ein Steckmodul, auf Maple ist ein Stamp.
Was für ein Steckmodul und was für eine Stamp?
Die blaue Stamp gibt es in 2 Versionen, mit Aufdruck und einer Version 14 und ohne Aufdruck und einer Version 18
ZitatDa empfange ich mit -76 noch einen Wert, den der nano sduino nicht mehr bekommt.
Ja, mit dem Maple empfange ich auch noch Sensoren mit bis zu ca -90
ZitatLeider habe ich generell noch immer Probleme mit meinem Lacrosse Sensor. Dieser wird sporadisch empfangen und hat dann längere Aussetzer.
Was für ein Lacrosse Sensor ist das? Hast Du die Aussetzer nur bei den Reading und Events oder auch bei den empfangenen Raw Nachrichten?
Ich habe bei dem TX29DTH-IT+ keine Aussetzer
@Reinhard.M
Hast Du beim Lacrosse Sensor auch noch Ausetzer, falls ja was ist das für ein Sensor?
Gruß Ralf
ZitatHast Du beim Lacrosse Sensor auch noch Ausetzer, falls ja was ist das für ein Sensor?
Guten Morgen Ralf!
In den letzten 2 Wochen kann ich keine Aussetzer finden. Allerdings zeichne ich mit 3 Devices auf: Maple, SignalDuino und SignalDuino LAN. Alle mit der aktuellen 4.1.1. Die RSSI Werte sind vom LaCross dabei eher bescheiden, ich habe schon -104 gesehen. Derzeit sehe ich außerdem extreme Sprünge von mehreren Grad, ich würde Mal sagen, Bitfehler wegen schwachem Pegel. Aussetzer habe ich Mal vor ein paar Wochen gesehen, sind aber deutlich seltener geworden. Kann auch wiederum am schwachen Sender liegen. Allgemein kann ich sagen, dass die FW extrem stabil läuft, sehr viel stabiler als die "offizielle" SignalDuino die ich in der aktuellen 3.4.0 Version auf einem Nano laufen habe.
Hallo Reinhard,
was definierst du als stabiler im Vergleich der originalen Version vom Signalduino? Von welcher Hardware / Devices urteilst du da?
Die inoffizielle Version von Ralf ist nicht mehr zu vergleichen mit der offiziellen. Die Hardwareunterstützung ist unterschiedlich und solltest du Probleme besitzen, dann diese Bitte melden.
Liebe Grüße Marco
ZitatDie RSSI Werte sind vom LaCross dabei eher bescheiden, ich habe schon -104 gesehen. Derzeit sehe ich außerdem extreme Sprünge von mehreren Grad, ich würde Mal sagen, Bitfehler wegen schwachem Pegel.
Evtl hast Du einen Lacrosse Sensor (was ist das für einer?) der nicht so stark sendet oder eine nicht so gute 868 Antenne? Betonwände?
Ich empfange den TX29DTH-IT+ durch 2 Ziegelwände mit ca -70 bis - 75.
Wie Du wahrscheinlich auch schon gemerkt hast, gibts bei den Antennen veschiedene Qualitäten, ich habe eine die am Ende abgeschrägt ist, so wie diese hier https://de.aliexpress.com/item/32812387108.html
Temperatursprünge konnte ich bei mir keine beobachten, dies sollte es durch die Prüfsumme eigentlich nicht geben.
Wie oft kommen diese Temperatursprünge vor? Hast Du davon auch raw Nachrichten?
ZitatAllgemein kann ich sagen, dass die FW extrem stabil läuft, sehr viel stabiler als die "offizielle" SignalDuino die ich in der aktuellen 3.4.0 Version auf einem Nano laufen habe.
Ja die V 4.1.1 läuft sehr stabil, ich habe mittlerweile eine uptime von 55 Tagen.
Bevor ich bei meinem produktiven sduino zum Maple gewechselt bin, hatte ich mit meiner V 3.3.2.1-rc9 auf dem ProMini eine uptime von über einem Jahr
Gruß Ralf
Hi, nein, die 868 Antenne hatte ich tatsächlich dran gelassen.
Steckmodul ist grün mit Aufschrift "RF1101SE-V3.1", Stamp (blau) hat Aufschrift "CC1101 @433MHz RF".
Ich wollte damit sagen, dass die -76 mein Maximum war. Weitere Entfernung wurden dann garnicht mehr empfangen. Allerdings hat der nano Signalduino auch nichts mehr empfangen. Jetzt aktuell habe ich zB. ein Poolthermometer im Garten. Der nano Signauduino empfängt mit -74,5, der Maple aktuell nichts.
Mich hat halt nur die Differenz in der Anzeige zwischen nano und maple gewundert.
Weil ich eben in der gleichen Konstellation mit CUL "ähnliche" Werte sehe.
Habt ihr denn "ähnliche" Werte, wenn ich den Empfang zwischen nano und maple am selben Ort vergleicht?
Das Thema mit dem Lacrosse hatten wir ja im Mai schon. Ist der TX35-IT. Läuft auch noch auf ccmode4. Damals war es so, dass es stabiler wurde, je länger der Maple lief. Seltsam finde ich das trotzdem.
Zitat von: Ralf9 am 22 August 2020, 10:08:48
Hast Du auch die 866 Antenne entfernt?
Was für ein Steckmodul und was für eine Stamp?
Die blaue Stamp gibt es in 2 Versionen, mit Aufdruck und einer Version 14 und ohne Aufdruck und einer Version 18
Ja, mit dem Maple empfange ich auch noch Sensoren mit bis zu ca -90
Was für ein Lacrosse Sensor ist das? Hast Du die Aussetzer nur bei den Reading und Events oder auch bei den empfangenen Raw Nachrichten?
Ich habe bei dem TX29DTH-IT+ keine Aussetzer
Zitat von: Ralf9 am 03 Mai 2020, 13:12:31
Das LAN funktioniert momentan nur mit dem MapleSduino, für den MapleCul ist noch ein patch in der Ethernetlib erforderlich.
Hi und guten Abend. Wollte mich mal erkundigen ob es bezüglich dem Patch für die EthernetLib schon etwas neues gibt bzw. jemand weiß was dort geändert werden muss, habe hier einen MapleCUL und würde den gerne per LAN eibinden, geht ja aber zur Zeit leider noch nicht.
Gruß Markus
Zitat von: HomeAuto_User am 22 August 2020, 13:16:49
Hallo Reinhard,
was definierst du als stabiler im Vergleich der originalen Version vom Signalduino? Von welcher Hardware / Devices urteilst du da?
Die inoffizielle Version von Ralf ist nicht mehr zu vergleichen mit der offiziellen. Die Hardwareunterstützung ist unterschiedlich und solltest du Probleme besitzen, dann diese Bitte melden.
Liebe Grüße Marco
Hallo Marco,
sorry für die späte Antwort, im Moment habe ich ein paar Themen zu viel auf dem Teller :)
Ich spreche von "stabiler" in Bezug auf die "uptime". Der Nano (nanoCUL CC1101 433MHz USB:FTDI) läuft keine 24 Stunden ohne Reset. Der Reset wird durch ein "KeepAlive not ok, retry = 3" ausgelöst. Das die "inoffizielle" nichts mit der "offiziellen" FW mehr zu tun hat ist mir ebenfalls klar, sie haben halt eine gemeinsame Wurzel und ich habe mit dem Nano angefangen. Bislang hatte ich nicht die Zeit um das genauer zu analysieren, leider. Ist aber alles kein echtes Problem für mich da der Reset den Nano ja immer wieder auf die Beine stellt. Sind diese Angaben für dich nachvolziehbarer?
Liebe Grüße Reinhard
Zitat von: Ralf9 am 22 August 2020, 14:02:12
Evtl hast Du einen Lacrosse Sensor (was ist das für einer?) der nicht so stark sendet oder eine nicht so gute 868 Antenne? Betonwände?
Ich empfange den TX29DTH-IT+ durch 2 Ziegelwände mit ca -70 bis - 75.
Wie Du wahrscheinlich auch schon gemerkt hast, gibts bei den Antennen veschiedene Qualitäten, ich habe eine die am Ende abgeschrägt ist, so wie diese hier https://de.aliexpress.com/item/32812387108.html
Temperatursprünge konnte ich bei mir keine beobachten, dies sollte es durch die Prüfsumme eigentlich nicht geben.
Wie oft kommen diese Temperatursprünge vor? Hast Du davon auch raw Nachrichten?
Ja die V 4.1.1 läuft sehr stabil, ich habe mittlerweile eine uptime von 55 Tagen.
Bevor ich bei meinem produktiven sduino zum Maple gewechselt bin, hatte ich mit meiner V 3.3.2.1-rc9 auf dem ProMini eine uptime von über einem Jahr
Gruß Ralf
Hallo Ralf,
es handelt sich um eine "Techno Line WS 9274" mit einem Außensender TX45TH-IT. Luftlinie ist er etwa 8m, 9m vom Empfänger entfernt. Dazwischen eine Glasscheibe und eine Jalousie die aber keinen erkennbaren Einfluss hat. Ich muss da noch genauer drauf schauen woher die Sprünge kommen, im log sieht es etwas merkwürdig aus. Wenn ich genaueres weiß melde ich mich aber wieder.
Mit den Antennen - yeep! Da habe ich schon einiges durchprobiert. Weitere Baustelle, muss ich auch noch ran. Bist du mit deiner vom Ali zufrieden? Dann würde ich mir davon ebenfalls welche zulegen. Wenn ich das richtig hier verfolge sind einige Funkamateure unterwegs mit einer Menge Know How. An denen würde ich mich gerne orientieren und lese bereits den ein oder anderen Antennen Thread. Wenn du mir da eine Empfehlung geben könntest...
Gruß Reinhard
Zitat von: meier81 am 25 August 2020, 20:53:07
Hi und guten Abend. Wollte mich mal erkundigen ob es bezüglich dem Patch für die EthernetLib schon etwas neues gibt bzw. jemand weiß was dort geändert werden muss, habe hier einen MapleCUL und würde den gerne per LAN eibinden, geht ja aber zur Zeit leider noch nicht.
Nein es gibt noch nichts neues, ich hatte es mir am Anfang mal angeschaut, prinzipiell müsste es möglich sein ist aber wahrscheinlich etwas aufwändiger. Ich hatte seither auch noch andere Themen.
Kann noch eine weile dauern.
Wie dringend ist dies bei Dir?
Gruß Ralf
ZitatIch spreche von "stabiler" in Bezug auf die "uptime". Der Nano (nanoCUL CC1101 433MHz USB:FTDI) läuft keine 24 Stunden ohne Reset.
Ob es an der Hardware oder an der Firmware liegt, kannst Du einfach eingrenzen, wenn es mit meiner V 3.3.2.1-rc9 stabil läuft, dann liegts an der firmware von Sidey.
Zitates handelt sich um eine "Techno Line WS 9274" mit einem Außensender TX45TH-IT. Luftlinie ist er etwa 8m, 9m vom Empfänger entfernt. Dazwischen eine Glasscheibe und eine Jalousie die aber keinen erkennbaren Einfluss hat. Ich muss da noch genauer drauf schauen woher die Sprünge kommen, im log sieht es etwas merkwürdig aus. Wenn ich genaueres weiß melde ich mich aber wieder.
Solche Probleme sind von einem Entwickler sehr schwer zu finden und zu fixen solange bei ihm diese Probleme nicht auftreten oder es keine Möglichkeit gibt diese Probleme nachzustellen.
Ich habe keine Idee mehr an was dies liegen könnte.
Diese Erfahrung musste ich beim Problem mit dem Bootloader2.0 auch schon machen.
ZitatMit den Antennen - yeep! Da habe ich schon einiges durchprobiert. Weitere Baustelle, muss ich auch noch ran. Bist du mit deiner vom Ali zufrieden? Dann würde ich mir davon ebenfalls welche zulegen. Wenn ich das richtig hier verfolge sind einige Funkamateure unterwegs mit einer Menge Know How. An denen würde ich mich gerne orientieren und lese bereits den ein oder anderen Antennen Thread. Wenn du mir da eine Empfehlung geben könntest...
Es gibt 2 Sorten von Antennen.
- die runde wo innen ein Draht ist
- und die nicht ganz runde und am Ende abgeschrägte wo innen eine Platine ist
Wenn ich es richtig verstanden habe, ist die mit der Platine besser
ich habe aber auch keine grosse Ahnung von Antennen
Gruß Ralf
Zitat von: Ralf9 am 27 August 2020, 16:12:09
Nein es gibt noch nichts neues, ich hatte es mir am Anfang mal angeschaut, prinzipiell müsste es möglich sein ist aber wahrscheinlich etwas aufwändiger. Ich hatte seither auch noch andere Themen.
Kann noch eine weile dauern.
Wie dringend ist dies bei Dir?
Hallo Ralf,
was heißt dringend. Ich bin mittlerweile von meinem Raspberry auf meine QNAP-NAS auf eine Debian-VM umgezogen, das läuft seit 2-3 Monaten soweit stabil. Jetzt muss ich allerdings meine USB-Geräte (SIGNALduino, HM mittels HB-RF-USB und meinen Modbus-Adapter) in die VM durchrouten, das klappt soweit auch recht gut, da stürzt aber ab und zu die Verbindung ab, und wenn du debmatic den HM-Empfänger abziehst friert das Debian ein und Feierabend.
Damit ich von dem USB wegkomme (dann kann ich die Geräte auch irgendwo im Haus hinstellen) habe ich am Wochenende den Modbus mittels Modbus 485 / Modbus TCP Wandler umgesetzt, für HM gibt es mittlerweile ganz neu auch eine Platine für Ethernet, die HB-RF-ETH. Hab ich die Tage auch umgestellt, läuft auch super.
Jetzt wäre halt der SIGNALduino das letzte USB Gerät das auf LAN umzustellen ist. Deshalb dacht ich frage mal nach bezüglich dem Stand. Eventuell muss ich dann doch noch den MAPLESduino zusammenlöten, ich hab beides hier und halt erstmal den MapleCUL zusammengelötet.
Gruß Markus
Hi, ich weiss nicht, ob es hier hingehört, aber da es sich um ein Test mit meinem Maple Signalduino handelt, probier ich es hier mal.
Ich empfange kein Jarolink Keeloq. Ich kann manuell angelegt senden, aber meine Fernbedienung wird nicht erkannt und angelegt.
Das Protokoll 87 ist in der Whitelist. Auch habe ich development=1.
Versionen:
version
V 4.1.1-dev200627 SIGNALduino cc1101 (R: B0*) - compiled at Jun 28 2020 13:30:04
versionmodul
v3.4.5-dev_ralf_04.08.
versionprotoL
v3.4.5-dev_ralf_05.08.
Log:
2020.09.02 17:31:53 4: maple_sduino/msg READ: MU;P0=800;P1=-428;P2=407;P3=-818;P4=-2878;P5=1540;P6=-3964;CP=2;R=49;D=010101232301230101012323230123232323230101010123010101010101010104560101232301230101010123012323232301230123230101010101232301230123010101010101010101012323012301010123232301232323232301010101230101010101010101045601012323012301010101230123232323012301232301010101012323012301230101010101010101010123230123010101232323012323232323010101012301010101010101010456010123230123010101012301232323230123012323010101010123230123012301010101010101010101232301230101012323230123232323230101010123010101010101010104560101232301230101010123012323232301230123230101010101232301230123010101010101010101012323012301010123232301232323232301010101230101010101010101045601012323012301010101230123232323012301232301010101012323012301230101010101010101010123230123010101232323012323232323;O;
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 19 -> minify matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA | Mandolyn | Pollin ISOTRONIC matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 40 -> Romotec matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: decoded matched MU Protocol id 40 dmsg u40#5C41EFF length 28 RSSI = -49.5
2020.09.02 17:31:53 4: maple_sduino: decoded matched MU Protocol id 40 dmsg u40#5E853E57FE5C41EFF length 68 repeat 1 RSSI = -49.5
2020.09.02 17:31:53 4: maple_sduino: equalDMS u40#5C41EFF (1)
2020.09.02 17:31:53 4: maple_sduino Dispatch: u40#5C41EFF, -49.5 dB, dispatch
2020.09.02 17:31:53 4: SIGNALduino_unknown incomming msg: u40#5C41EFF
2020.09.02 17:31:53 4: SIGNALduino_unknown rawData: 5C41EFF
2020.09.02 17:31:53 4: SIGNALduino_unknown Protocol: 40
2020.09.02 17:31:53 4: SIGNALduino_unknown converted to bits: 0101110001000001111011111111
2020.09.02 17:31:53 4: maple_sduino: decoded matched MU Protocol id 40 dmsg u40#5E853E57FE5C41EFF length 68 repeat 2 RSSI = -49.5
2020.09.02 17:31:53 4: maple_sduino: decoded matched MU Protocol id 40 dmsg u40#5E853E57FE5C41EFF length 68 repeat 3 RSSI = -49.5
2020.09.02 17:31:53 4: maple_sduino: decoded matched MU Protocol id 40 dmsg u40#5E853E57FE5C41EFF length 68 repeat 4 RSSI = -49.5
2020.09.02 17:31:53 4: maple_sduino: equalDMS u40#5E853E57FE5C41EFF (4)
2020.09.02 17:31:53 4: maple_sduino Dispatch: u40#5E853E57FE5C41EFF, -49.5 dB, dispatch
2020.09.02 17:31:53 4: SIGNALduino_unknown incomming msg: u40#5E853E57FE5C41EFF
2020.09.02 17:31:53 4: SIGNALduino_unknown rawData: 5E853E57FE5C41EFF
2020.09.02 17:31:53 4: SIGNALduino_unknown Protocol: 40
2020.09.02 17:31:53 4: SIGNALduino_unknown converted to bits: 01011110100001010011111001010111111111100101110001000001111011111111
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 60 -> WS2000 matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: WS2000 Sensortyp 5 - ERROR lenght of message 65 (40)
2020.09.02 17:31:53 4: maple_sduino: WS2000 Sensortyp 5 - ERROR lenght of message 65 (40)
2020.09.02 17:31:53 4: maple_sduino: WS2000 Sensortyp 5 - ERROR lenght of message 65 (40)
2020.09.02 17:31:53 4: maple_sduino: WS2000 Sensortyp 5 - ERROR lenght of message 65 (40)
2020.09.02 17:31:53 4: maple_sduino: WS2000 Sensortyp 5 - ERROR lenght of message 55 (40)
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 91 -> Atlantic security matches, trying to demodulate
2020.09.02 17:31:53 4: maple_sduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
Irgendwie versucht er 87 garnicht zu erkennen. Was ist da falsch?
Ich verwende genau diese Konfiguration, problemlos und fehlerfrei. Auch die original Fernbedienung wird erkannt. Allerdings kann es vorkommen, dass man nicht lange genug drückt damit sie sicher erkannt werden. Ich verwende sie daher im Grunde nicht mehr. Geht alles über ASC
Muss auch sagen bei mir läuft das alles problemlos, verwende auch die originale Fernbedienung nicht, liegt nur im Keller rum. Sobald ich Batterien reinmache und ne Taste drücke habe ich sofort ein neues Device in FHEM, meine Fernbedienung nämlich. Geht tadellos. Zur Sicherheit probiere ich das nachher nochmal, habe an meinem Produktivsystem die gleiche Modulversion und Protokollversion wie du, benutze dort allerdings zur Zeit noch einen SIGNALduino (Arduino) mit der Firmware 3.3.2.1-rc9.
Wenn überhaupt könnte ich mir vorstellen das es an dem Unterschied liegt.
Gruß
Markus
ZitatMU;P0=800;P1=-428;P2=407;P3=-818;P4=-2878;P5=1540;P6=-3964;CP=2;R=49;D=01010123230123010101232323012323232323010101012301010101010101010456010123230123010101012301232323230123012323010...
Das Problem ist, daß hier der Sync nicht passt, er ist hier 56 er müsste aber 26 sein.
Welche Bezeichnung hat die Fernbedienung?
Das ist eine tdrc08. Ich gucke morgen nochmal andere Nachrichten an, ob da auch 56 steht. Es funktioniert allerdings auch nicht mit dem nano signalduino
version
V 3.4.0-dev SIGNALduino cc1101 (chip CC110 unknown) - compiled at Jan 5 2020 23:38:20
versionProtocols
1.20
versionmodul
v3.4.4
Kannst Du mir bitte per pm oder email (wegen der keys) mal ein List von Deinem Keeloq device schicken?
Habe ich per PM geschickt. Hier auch nochmal für alle entschärft.
Das Problem ist aber nicht das manuell angelegte Device(das hatte ich irgendwo hier so im Forum gefunden), das funktioniert problemlos.
Leider wird bei mir die Fernbedienung nicht erkannt.
Ich habe jetzt nochmal andere Nachrichten durchsucht. Der Sync besteht immer aus 1550 und -3950
Denkst du, dass die 8 Kanal Fernbedienung "anders" ist, als die 4 Kanal?
Internals:
DEF EE5000
FUUID 5f4f777d-f33f-ac66-e26c-7049f28dd2a2e4e5
IODev maple_sduino
NAME JaroLift
NR 1132
STATE Defined
TYPE SD_Keeloq
READINGS:
2020-09-02 13:37:35 DDSelected 1
2020-09-02 17:00:05 LastAction_Channel_01 stop
2020-09-02 17:00:05 button stop
2020-09-02 17:00:05 channel 1
2020-09-02 17:00:05 channel_control no
2020-09-02 17:00:05 counter_send 46
2020-09-02 17:00:05 state send stop
2020-09-02 12:48:36 user_info messages can be received and send!
2020-09-02 12:48:36 user_modus all_functions
Attributes:
ChannelFixed 1
ChannelNames Küche
Channels 10
IODev maple_sduino
KeeLoq_NLF 0xxxxxxxxE
LearnVersion new
MasterLSB 0xxxxxxxx5
MasterMSB 0xxxxxxxxB
Serial_send 9AF000
UI Einzeilig
model JaroLift
room SD_Keeloq
Edit: Ich habe jetzt mal versuchsweise umgestellt auf
sync => [4,-10],
Klappt aber auch nicht. ID87 wird nicht durchlaufen.
2020.09.03 09:18:04 4: maple_sduino/msg READ: MU;P0=-18855;P1=-404;P2=417;P3=1521;P4=-3961;P5=808;P6=-815;P7=-2899;CP=2;R=20;D=121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121345126515126512626512626512626512626512651262626265126262626515151515151515151515151512626512651515126262651262626262651515151512651515151515151573451265151265126265126265126265126265126512626262651262626265151515151515151515151515126265126515151262626512626262626515151515126515151515151515734512651512651262651262651262651262651265126262626512626262651515151515151515151515151262651265151512626265126262626265151515151265151515151515157345126515126512626512626512626512626512651262626265126262626515151515151515151515151512626512651515126262651262;e3;
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 19 -> minify matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: Starting demodulation (Signal: (?:51|26){19,} Pos 221) length_min_max (19..23) length=71
2020.09.03 09:18:04 5: maple_sduino: skip demodulation (length 71 is to long)
2020.09.03 09:18:04 5: maple_sduino: 1.restarting demodulation (length 71 to long) at Pos 367 regex ((?:)((?:51|26){19,}))
2020.09.03 09:18:04 5: maple_sduino: 2.restarting demodulation (length 71 to long) at Pos 513 regex ((?:)((?:51|26){19,}))
2020.09.03 09:18:04 5: maple_sduino: 3.restarting demodulation (length 54 to long) at Pos 659 regex ((?:)((?:51|26){19,}))
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 34 -> QUIGG | LIBRA | Mandolyn | Pollin ISOTRONIC matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: regex ((?:5)((?:65|62){19,}(?:6)?)) did not match, aborting
2020.09.03 09:18:04 5: maple_sduino applied filterfunc: SIGNALduino_compPattern, count=0
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 40 -> Romotec matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: regex ((?:21)((?:51|26){12,})) did not match, aborting
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 60 -> WS2000 matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: Starting demodulation (Signal: (?:26|51){38,} Pos 221) length_min_max (38..82) length=71
2020.09.03 09:18:04 5: maple_sduino: applying postDemodulation , value before : 0 1 0 0 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 0 1 1 1 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 0 1 1 1 0 1 1 1 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0
2020.09.03 09:18:04 5: maple_sduino: WS2000 protolength: 71, datastart: 1, datalength 70
2020.09.03 09:18:04 4: maple_sduino: WS2000 Sensortyp 4 Adr 5 - ERROR examination bit
2020.09.03 09:18:04 5: maple_sduino: rcode=0, after calling postDemodulation
2020.09.03 09:18:04 5: maple_sduino: 1.restarting demodulation at Pos 367 regex ((?:)((?:26|51){38,}))
2020.09.03 09:18:04 5: maple_sduino: applying postDemodulation , value before : 0 1 0 0 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 0 1 1 1 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 0 1 1 1 0 1 1 1 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0
2020.09.03 09:18:04 5: maple_sduino: WS2000 protolength: 71, datastart: 1, datalength 70
2020.09.03 09:18:04 4: maple_sduino: WS2000 Sensortyp 4 Adr 5 - ERROR examination bit
2020.09.03 09:18:04 5: maple_sduino: rcode=0, after calling postDemodulation
2020.09.03 09:18:04 5: maple_sduino: 2.restarting demodulation at Pos 513 regex ((?:)((?:26|51){38,}))
2020.09.03 09:18:04 5: maple_sduino: applying postDemodulation , value before : 0 1 0 0 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 0 1 1 1 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 0 1 1 1 0 1 1 1 1 1 0 0 0 0 0 1 0 0 0 0 0 0 0
2020.09.03 09:18:04 5: maple_sduino: WS2000 protolength: 71, datastart: 1, datalength 70
2020.09.03 09:18:04 4: maple_sduino: WS2000 Sensortyp 4 Adr 5 - ERROR examination bit
2020.09.03 09:18:04 5: maple_sduino: rcode=0, after calling postDemodulation
2020.09.03 09:18:04 5: maple_sduino: 3.restarting demodulation at Pos 659 regex ((?:)((?:26|51){38,}))
2020.09.03 09:18:04 5: maple_sduino: applying postDemodulation , value before : 0 1 0 0 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 0 1 1 1 1 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 0 0 0 1 1 1 0 1
2020.09.03 09:18:04 5: maple_sduino: WS2000 protolength: 54, datastart: 1, datalength 53
2020.09.03 09:18:04 4: maple_sduino: WS2000 Sensortyp 4 - ERROR lenght of message 50 (70)
2020.09.03 09:18:04 5: maple_sduino: rcode=0, after calling postDemodulation
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: Starting demodulation (Signal: (?:26|21){30,} Pos 1) length_min_max (30..48) length=109
2020.09.03 09:18:04 5: maple_sduino: skip demodulation (length 109 is to long)
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: Starting demodulation (Signal: (?:51|21){50,} Pos 1) length_min_max (50..58) length=109
2020.09.03 09:18:04 5: maple_sduino: skip demodulation (length 109 is to long)
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: Starting demodulation (Signal: (?:21|21){59,} Pos 1) length_min_max (59..67) length=109
2020.09.03 09:18:04 5: maple_sduino: skip demodulation (length 109 is to long)
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: Starting demodulation (Signal: (?:51|21){50,} Pos 1) length_min_max (50..67) length=109
2020.09.03 09:18:04 5: maple_sduino: skip demodulation (length 109 is to long)
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: Starting demodulation (Signal: (?:26|21){104,} Pos 1) length_min_max (104..114) length=109
2020.09.03 09:18:04 5: maple_sduino: applying postDemodulation , value before : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
2020.09.03 09:18:04 3: maple_sduino: EM Protocol - Start not found or length msg (113
2020.09.03 09:18:04 5: maple_sduino: rcode=0, after calling postDemodulation
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: regex ((?:)((?:26|51|57){100,})) did not match, aborting
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 91 -> Atlantic security matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: regex ((?:45)((?:62|15){36,}(?:1|6)?)) did not match, aborting
2020.09.03 09:18:04 4: maple_sduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2020.09.03 09:18:04 5: maple_sduino: regex ((?:26)((?:26|26){50,})) did not match, aborting
So wies aussieht ist für diese Fernbedienung eine neue Protokolldefinition notwendig. Sie hat einen anderen Sync und kein Presync.
Ich hab dafür mal zum Testen die ProtocolId 587 (siehe Anlage) angelegt.
Zum Testen bitte diese Zeichenfolge in das sduino Attribut "userProtocol" kopieren.
{"changed":"20200902 new","clientmodule":"SD_Keeloq","clockabs":400,"comment":"remote control JAROLIFT TDRC_16W / TDRCT_04W","format":"twostate","id":"587","length_max":"85","length_min":"71","name":"JAROLIFT","one":[1,-2],"pause":[-40],"preSync":[3.8,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1,1,-1],"preamble":"P87#","reconstructBit":"1","start":[3.8,-10],"zero":[2,-1]}
Wenn ich es damit mit dem dummysduino simuliere sieht es bei mir so aus:
2020.09.03 09:44:52.124 4 : sduinoD/msg get raw: MU;P0=800;P1=-428;P2=407;P3=-818;P4=-2878;P5=1540;P6=-3964;CP=2;R=49;D=010101232301230101012323230123232323230101010123010101010101010104560101232301230101010123012323232301230123230101010101232301230123010101010101010101012323012301010123232301232323232301010101230101010101010101045601012323012301010101230123232323012301232301010101012323012301230101010101010101010123230123010101232323012323232323010101012301010101010101010456010123230123010101012301232323230123012323010101010123230123012301010101010101010101232301230101012323230123232323230101010123010101010101010104560101232301230101010123012323232301230123230101010101232301230123010101010101010101012323012301010123232301232323232301010101230101010101010101045601012323012301010101230123232323012301232301010101012323012301230101010101010101010123230123010101232323012323232323;O;
2020.09.03 09:44:52.124 4 : sduinoD: Fingerprint for MU Protocol id 587 -> JAROLIFT matches, trying to demodulate
2020.09.03 09:44:52.124 5 : sduinoD: Starting demodulation (StartStr: 56 cut Pos 66; Signal: (?:23|01){71,}(?:2|0)? Pos 0) length_min_max (71..85) length=72
2020.09.03 09:44:52.124 4 : sduinoD: last part pair=0 reconstructed, bit=0
2020.09.03 09:44:52.124 5 : sduinoD: dispatching bits: 001101000010111101011000001101010000000000110100011101111100001000000000
2020.09.03 09:44:52.124 4 : sduinoD: decoded matched MU Protocol id 587 dmsg P87#342F5835003477C200 length 72 RSSI = -49.5
2020.09.03 09:44:52.124 5 : sduinoD: 1.restarting demodulation at Pos 146 regex ((?:56)((?:23|01){71,}(?:2|0)?))
2020.09.03 09:44:52.124 4 : sduinoD: last part pair=0 reconstructed, bit=0
2020.09.03 09:44:52.124 5 : sduinoD: dispatching bits: 001101000010111101011000001101010000000000110100011101111100001000000000
2020.09.03 09:44:52.124 4 : sduinoD: decoded matched MU Protocol id 587 dmsg P87#342F5835003477C200 length 72 repeat 1 RSSI = -49.5
2020.09.03 09:44:52.124 5 : sduinoD: 2.restarting demodulation at Pos 292 regex ((?:56)((?:23|01){71,}(?:2|0)?))
2020.09.03 09:44:52.124 4 : sduinoD: last part pair=0 reconstructed, bit=0
2020.09.03 09:44:52.124 5 : sduinoD: dispatching bits: 001101000010111101011000001101010000000000110100011101111100001000000000
2020.09.03 09:44:52.125 4 : sduinoD: decoded matched MU Protocol id 587 dmsg P87#342F5835003477C200 length 72 repeat 2 RSSI = -49.5
2020.09.03 09:44:52.125 5 : sduinoD: 3.restarting demodulation at Pos 438 regex ((?:56)((?:23|01){71,}(?:2|0)?))
2020.09.03 09:44:52.125 4 : sduinoD: last part pair=0 reconstructed, bit=0
2020.09.03 09:44:52.125 5 : sduinoD: dispatching bits: 001101000010111101011000001101010000000000110100011101111100001000000000
2020.09.03 09:44:52.125 4 : sduinoD: decoded matched MU Protocol id 587 dmsg P87#342F5835003477C200 length 72 repeat 3 RSSI = -49.5
2020.09.03 09:44:52.125 4 : sduinoD: equalDMS P87#342F5835003477C200 (4)
2020.09.03 09:44:52.125 5 : sduinoD Dispatch: P87#342F5835003477C200, test ungleich: disabled
2020.09.03 09:44:52.125 4 : sduinoD Dispatch: P87#342F5835003477C200, -49.5 dB, dispatch
2020.09.03 09:44:52.125 5 : sduinoD: dispatch P87#342F5835003477C200
2020.09.03 09:44:52.159 1 : PERL WARNING: Use of uninitialized value $binsplit in concatenation (.) or string at ./FHEM/14_SD_Keeloq.pm line 793.
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 button: stop
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 channel: 1
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 DDSelected: ch1
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 channel_control: no
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 counter_receive: 214
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 last_digits: 1
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 receive stop on single control
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 user_modus: all_functions
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 user_info: none
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 LastAction_Channel_01: stop
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 Protocol_ID: 587
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 RSSI: -49.5
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 DMSG: P87#342F5835003477C200
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 RAWMSG: MU;P0=800;P1=-428;P2=407;P3=-818;P4=-2878;P5=1540;P6=-3964;CP=2;R=49;D=010101232301230101012323230123232323230101010123010101010101010104560101232301230101010123012323232301230123230101010101232301230123010101010101010101012323012301010123232301232323232301010101230101010101010101045601012323012301010101230123232323012301232301010101012323012301230101010101010101010123230123010101232323012323232323010101012301010101010101010456010123230123010101012301232323230123012323010101010123230123012301010101010101010101232301230101012323230123232323230101010123010101010101010104560101232301230101010123012323232301230123230101010101232301230123010101010101010101012323012301010123232301232323232301010101230101010101010101045601012323012301010101230123232323012301232301010101012323012301230101010101010101010123230123010101232323012323232323;O;
2020-09-03 09:44:52.169 SD_Keeloq SD_Keeloq_3EE2C0 DMSGequal: 4
Ja, das ist es. Fernbedienung wird erkannt und angelegt.
Also die Fernbedienung ist eine 8 Kanal Fernbedienung TDRC08.
Auf dem Typschild steht auch noch "2018" drauf. Ich weiss nicht, ob das ein Hinweis auf den anderen Sync ist.
Funktioniert prima. Vielen Dank. :-)
Die nächsten Schritte wären dann:
- herauszufinden ob es bei der 8 Kanal Fernbedienung TDRC08 eine Möglichkeit gibt auf das normale Protokoll umzuschalten.
- herauszufinden ob es auch noch weitere user gibt, welche diese Fernbedienung TDRC08 haben, z.B. hier:
https://forum.fhem.de/index.php/topic,13596.0.html
oder unter "sonstige Systeme" fragen
- eine neue ProtocolID 87.1 in die Protokollliste zufügen
Hallo,
Kann man die SIGNALDuino Firmware für das CC1101_1 Modul (433MHz) in einer MAPLE CUL Ver. 3.5 flashen?
Danke mehrmals!
Für den MapleCul gibts die Firmware "Maple_cul_USB_411dev200627.bin"
https://github.com/Ralf9/SIGNALDuino/releases/download/V4.1.1-dev200627/Maple_cul_USB_411dev200627.bin
Danke mehrmals Ralf9!
Ich frage mich ob wäre es möglich eine Art von a-culw + Signalduino Firmware zu schaffen über MapleCUL/CUN.
z.B. MapleCUL mit 3 CC1101 Module (868+433+868): A für FHT, B für Signalduino und C für WM-BUS.
Oder muss man entscheiden entweder Signalduino oder a-culw für alle Module?
Danke nochmals!
Ja, man muss entscheiden entweder Signalduino oder a-culw für alle Module.
FHT 80TF und FHT 80TF-2 auch für's cc1101 Modul A ist geplant. Die Unterstützung der FHT Stellmotoren ist zu aufwändig.
WM-BUS habe ich vor in die Maple Signalduino Firmware einzubauen.
Gruß Ralf
Bin mir nicht sicher, ob ich hier einfach reingrätschen kann.
Hatte mal wieder etwas Zeit übrig und mir meine Sammlung von Modulen angesehen. Da fiel mir auf, dass ich noch zwei "Black Boards" https://stm32-base.org/boards/STM32F103C8T6-Black-Board (https://stm32-base.org/boards/STM32F103C8T6-Black-Board) und ein passenden CC1101 rumliegen hatte. Die passen direkt auf die nrf24 Pfosten. Nur ist hier SPI1 und nicht SPI2 verdrahtet.
Habe mir nun also das Git von Ralf genommen und die Anpassung gemacht.
Nach ein paar Versuchen mit unterschiedlichen Versionen der Frameworks, hat es sich compilieren lassen, dass war es dann auch schon als Erfolg. Manchmal findet er ein CC1101, aber die Versionsnummer variiert und manchmal ist er der Meinung, dass die Einstellungen nicht passen und mit "e" ein Reset macht werden soll.
Wenn ich z.B. den FreqTest aus dem AskSinPP Paket compiliere auf dem Board, wird der CC1101 immer unter der gleichen Version gefunden.
In der AskSinPP ist von Hardware SPI die Rede und es werden auch keine Pins in der Config benötigt.
Zufällig jemand einen Denkanstoss für mich?
ZitatDie passen direkt auf die nrf24 Pfosten
Das cc1101 hat eine andere Belegung als das nrf24
Außerdem hat das Black Board nur 64K flash, der MapleMini hat 128K Flash. Momentan belegt die Firmware ca 63K flash
Hallo Ralf,
bei der Pinbelegung hast du nur bedingt Recht. Es gibt CC1101 die genau die gleiche Pinbelgung haben. Ich habe diese Module e07-m1101d.
Ich habe zwei leicht unterschiedliche Black Boards. Das eine hat keine Extras und tatsächlich nur 64kb/20kb. Das zweite (mit schräger MCU) hat 128km/20kb, EEprom, Flash, TF Card Slot, etc. Aber beide zeigen die gleichen Symptome.
[Nachtrag]
Ich habe nun noch einmal alles kontrolliert. Auf dem Board mit 128kb Flash läuft es jetzt. Ich habe die dev-r3.5_xFSK genommen. Vermute, es ist aber nicht der Grund. Auf den Board mit 64kb Flash hat sich wohl zusätzlich eine kalte Lötstelle eingeschlichen. Dies habe ich gemerkt, als ich die Pins mit einer LED kontrolliert habe. Die LED flackerte und leuchtete teilweise dunkler.
Wenn also jemand Interesse an der Konfiguration hat, bitte melden!
ok, mit dem e07-m1101d passt die Pin-Belegung
Demnach hast Du die folgenden Anpassungen alle gemacht:
In der SIGNALDuino.ino:
//#define MAPLE_SDUINO 1
#define MAPLE_CUL 1diese PIN müssen angepasst werden
#elif MAPLE_CUL
#define PIN_LED 33
#define PIN_SEND 17 // gdo0 Pin TX out
#define PIN_RECEIVE 18hier muss für das cc1101 Modul B die 18 angepasst werden
const uint8_t pinReceive[] = {11, 18, 16, 14};cc1101.h
hier muss die 12 angepasst werden
const uint8_t radioCsPin[] = {7, 12, 15, 3};ZitatIch habe die dev-r3.5_xFSK genommen.
Wenn Du nur ein cc1101 mit 433MHz SlowRF verwenden willst kannst Du auch das Signalduino Modul vom normalen fhem update nutzen.
Das dev-r3.5_xFSK ist beim FSK leider nicht mit meiner Firmware kompatibel.
Beim Signalduino Modul von Sidey fehlen auch die komfort Funktionen.
Gruß Ralf
Anpassungen an den Pins für den CC1101 und der LED hatte ich vorgenommen.
Zudem hatte ich das Board und MCU angepasst. Nachdem ich die kalte Lötstelle behoben habe, funktioniert nun auch das andere Board.
Ich habe jetzt das Release 3.4.0 benutzt.
Ich könnte ein Pull request vorbereiten, wenn gewünscht. Müsste nur wissen, dann in welche Version.
wo hast Du das Black Board mit 128k flash gekauft? bei Aliexpress und ebay habe ich es nicht gefunden.
Mit den Erweiterungen die ich noch geplant habe, wird meine Firmware größer als 64k werden.
Gibt es das e07-m1101d Modul auch als 868 MHz Version?
ZitatZudem hatte ich das Board und MCU angepasst.
Ich verwende diese STM32 Boards,
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
da ist das Blackboard nicht dabei. Funktioniert es auch ohne boardanpassungen mit dem "Gerneric STM32F103CBT6" board?
Gruß Ralf
Glaube die e07-mm1101d gibt es nur mit 433MHz.
Das Black Board mit 128k hat gleiche Abmessungen aber ein etwas anderes Layout.
Ist von Aliexpress
https://www.aliexpress.com/item/32525208361.html
Ein Problem war, dass die Pin Nummer nicht mit dem Board übereinstimmten. Nachdem ich die Konstanten (z.B. PB1,PA7,...) benutzt hatte, funktionierte es.
Müsste also einmal probieren, ob dies mit dem Generic Settings noch übereinstimmen.
Demnach können bei den PINs anstatt der Nummern auch die Portbezeichungen (z.B. PB0) verwendet werden.
Mit der Pin Belegung des e07-mm1101d
1 - GND Ground plane
2 - VCC +3.3V rail
3 - GDO0 PB0
4 - CSN PB2
5 - SCK PA5
6 - MOSI PA7
7 - MISO PA6
8 - GDO2 PA15
ergeben sich dann die folgenden Ergänzungen:
In der SIGNALDuino.ino:
//#define MAPLE_SDUINO 1
//#define MAPLE_CUL 1
#define BLACKBOARD 1
..
#ifdef BLACKBOARD
#define MAPLE_Mini
#define CMP_CC1101
#endif
..
#elif BLACKBOARD
#define PIN_LED PA1
#define PIN_SEND PB0 // gdo0 Pin TX out
#define PIN_RECEIVE PA15
#define PIN_WIZ_RST PC14
cc1101.h
#elif BLACKBOARD
#define mosiPin PA7 // MOSI out
#define misoPin PA6 // MISO in
#define sckPin PA5 // SCLK out
SPIClass SPI_2(mosiPin, misoPin, sckPin);
const uint8_t radioCsPin[] = {7, PB2, 15, 3};
Mit dem Backboard lässt sich ohne Löten ein Signalduino zusammenbauen, aber nur mit einem 433 cc1101 für slowRF. FSK ist nicht möglich.
Gruß Ralf
Ich habe vor die Firmware so zu erweitern, daß auf den cc1101 Modulen A und B gleichzeitig ASK/OOK (SlowRF) möglich ist, ich bin mir aber unsicher ob es beim gleichzeitigen Empfang von z.B 433 MHz SlowRF und 868 MHZ SlowRF zu Beeinflussungen kommen kann.
Bei den empfangenen Pulsen (GDO2 Pin) werden bei jeder Flanke die Interruptroutine (handleInterruptA) aufgerufen.
In der Interruptroutine wird die Pulsdauer gemessen und in den FiFo gespeichert.
Damit ein gleichzeitiges empfangen von 2 SlowRF Nachrichten möglich ist, sind getrennte Interruptroutinen und FiFo notwendig.
handleInterruptA für cc1101 Modul A und handleInterruptB für cc1101 Modul B
Da habe ich nun ein Verständnisproblem:
in der Interruptroutine werden die Interrupts gesperrt,
wenn nun durch eine Pulsflanke von Modul A handleInterrupt aufgerufen wird und noch bevor die Interruptroutine beendet ist, von Modul B eine Pulsflanke kommt, was passiert dann? Die Interrupts sind noch gesperrt.
Kann jemand ganz grob abschätzen (Größenordnung reicht) wie lange die Ausführung der Interruptrotine dauert?
SimpleFIFO<int16_t,FIFO_LENGTH> FiFoA;
SimpleFIFO<int16_t,FIFO_LENGTH> FiFoB;
volatile unsigned long lastTimeA = micros();
volatile unsigned long lastTimeB = micros();
void handleInterruptA() {
noInterrupts();
const unsigned long Time=micros();
const unsigned long duration = Time - lastTimeA;
lastTimeA = Time;
if (duration >= pulseMin) {//kleinste zulaessige Pulslaenge
int16_t sDuration;
if (duration < maxPulse) {//groesste zulaessige Pulslaenge, max = 32000
sDuration = int16_t(duration); //das wirft bereits hier unnoetige Nullen raus und vergroessert den Wertebereich
}else {
sDuration = maxPulse; // Maximalwert set to maxPulse defined in lib.
}
if (isHigh(pinReceive[0])) { // Wenn jetzt high ist, dann muss vorher low gewesen sein, und dafuer gilt die gemessene Dauer.
sDuration=-sDuration;
}
//MSG_PRINTLN(sDuration);
FiFoA.enqueue(sDuration);
} // else => trash
interrupts();
}
void handleInterruptB() {
noInterrupts();
const unsigned long Time=micros();
const unsigned long duration = Time - lastTimeB;
lastTimeB = Time;
if (duration >= pulseMin) {//kleinste zulaessige Pulslaenge
int16_t sDuration;
if (duration < maxPulse) {//groesste zulaessige Pulslaenge, max = 32000
sDuration = int16_t(duration); //das wirft bereits hier unnoetige Nullen raus und vergroessert den Wertebereich
}else {
sDuration = maxPulse; // Maximalwert set to maxPulse defined in lib.
}
if (isHigh(pinReceive[1])) { // Wenn jetzt high ist, dann muss vorher low gewesen sein, und dafuer gilt die gemessene Dauer.
sDuration=-sDuration;
}
//MSG_PRINTLN(sDuration);
FiFoB.enqueue(sDuration);
} // else => trash
interrupts();
}
Gruß Ralf
wenn ich mit
attachInterrupt(digitalPinToInterrupt(PIN_RECEIVE), handleInterrupt, CHANGE);
bei einer Flanke an einem Eingang per Interrupt eine handleInterrupt Routine aufrufen möchte,
ist mir nicht klar was passiert, wenn während der Flanke z.B. in einer Interruptroutine mit
noInterrupts();
die Interrupts deaktiviert sind.
Sehe ich das richtig, daß die Interruptanforderung der Flanke im "Pending request register" gemerkt wird?
Wird dann nach einem
Interrupts();
der pending Interrupt der Flanke aktiv und ruft die handleInterrupt Routine auf?
Gruß Ralf
ZitatSehe ich das richtig, daß die Interruptanforderung der Flanke im "Pending request register" gemerkt wird?
Wird dann nach einem
Interrupts();
der pending Interrupt der Flanke aktiv und ruft die handleInterrupt Routine auf?
Dies scheint so zu funktionieren, ich habe mir dazu ein Testprogramm geschrieben.
Ich habe damit angefangen die Firmware so zu erweitern, daß auch beim cc1101 Modul A SlowRF (ASK) möglich ist.
Momentan wird in der signalDecoder4.cpp per callback "cc1101::getRSSI" in der SIGNALDuino.ino aufgerufen.
Es wird dazu FastDelegate.h verwendet.
Ich möchte das callback ohne das FastDelegate.h machen, dafür reichen aber meine Kenntnisse nicht aus.
Kann mir da jemand helfen?
Hat mir jemand eine Beschreibung wo das callback gut erkärt wird.
Momentan ist es so realisiert:
signalDecoder4.cpp
rssiValue = _rssiCallback();signalDecoder4.h
class SignalDetectorClass
{
public:
typedef fastdelegate::FastDelegate0<uint8_t> FuncRetuint8t;
void setRSSICallback(FuncRetuint8t callbackfunction) { _rssiCallback = callbackfunction; }SIGNALDuino.ino
SignalDetectorClass musterDec;
musterDec.setRSSICallback(&cc1101::getRSSI); // Provide the RSSI CallbackGruß Ralf
Hallo Ralf,
wie gerne würde ich dir helfen, stecke aber leider noch nicht mal so tief wie du in der Materie. Trotzdem lese ich immer fleißig mit und versuche mich auch über´s Internet schlau zu machen bzw. nachzulesen, sollte ich da was finden werde ich es berichten.
Gruß Markus
Liest hier jemand mit der mir mit dem callback weiterhelfen kann?
@Telekatz
@papa
@juergs
Hallo Ralf,
ich lese zwar mit muss aber leider genauso passen wie Markus, sorry.
Gruß Reinhard
Zitat@Telekatz
@papa
@juergs
Hallo Ralf,
stecke, wie meine Vorredner, leider auch gerade nicht so tief in der spezifischen Materie drin.
Schaue mal, was ich tun kann ...
Grüße + schöne Weihnachten
Jürgen
http://homepage.cem.itesm.mx/carbajal/Microcontrollers/SLIDES/Interrupts.pdf (http://homepage.cem.itesm.mx/carbajal/Microcontrollers/SLIDES/Interrupts.pdf) ab Seite 40.
https://www.st.com/content/ccc/resource/training/technical/product_training/3b/10/15/3e/57/60/4f/37/STM32L4_System_NVIC.pdf/files/STM32L4_System_NVIC.pdf/jcr:content/translations/en.STM32L4_System_NVIC.pdf (https://www.st.com/content/ccc/resource/training/technical/product_training/3b/10/15/3e/57/60/4f/37/STM32L4_System_NVIC.pdf/files/STM32L4_System_NVIC.pdf/jcr:content/translations/en.STM32L4_System_NVIC.pdf)
http://stefanfrings.de/stm32/stm32f3.html#nvic (http://stefanfrings.de/stm32/stm32f3.html#nvic)
https://stackoverflow.com/questions/55003417/synchronisation-mechanism-without-disabling-interrupts-on-cortex-m0 (https://stackoverflow.com/questions/55003417/synchronisation-mechanism-without-disabling-interrupts-on-cortex-m0)
=> https://stm32f4-discovery.net/2014/08/stm32f4-external-interrupts-tutorial/ (https://stm32f4-discovery.net/2014/08/stm32f4-external-interrupts-tutorial/)
=>https://stackoverflow.com/questions/50105120/stm32f427-interrupt-clear-pending-bit/51221126#51221126 (https://stackoverflow.com/questions/50105120/stm32f427-interrupt-clear-pending-bit/51221126#51221126)
Wenn das Problem sauber "artikuliert" werden kann, dann könnte man auch die
StackOverflow-STM32-Community (https://stackoverflow.com/questions/tagged/stm32) anfragen. ["Ask question"-Empfehlung!]
ZitatWenn das Signal zu früh verschwindet, während der Interrupt-Controller nach einer Gelegenheit sucht, den Interrupt-Handler auszuführen, geht es verloren. Der Interrupt-Handler wird dann nicht ausgeführt.
Für das Ermitteln der Interrupt-Dauer kann ich gerne mit einem Logikanalyzer bestimmen.
Benötige allerdings mehr Infos über das "Grundproblem". => Gleichzeitige Auslösung zweier Interrupts? Testprogramm?
TIPP:Ich kann bei Darstellung von Abläufen
PlantUML (https://plantuml.com/de/sitemap-language-specification (https://plantuml.com/de/sitemap-language-specification) ) insbesondere Aktivitäts- (https://plantuml.com/de/activity-diagram-legacy) und Sequenz (https://plantuml.com/de/sequence-diagram)-Diagramme empfehlen.
Mit VSCode/Code-OSS oder vscodium (https://vscodium.com/) und https://marketplace.visualstudio.com/items?itemName=jebbs.plantuml (https://marketplace.visualstudio.com/items?itemName=jebbs.plantuml)-Plugin = genial, mit Preview (benötigt Java) !
Hallo Jürgen,
Danke für die Links, ein Teil hatte ich selber schon gefunden, aber Du bist im suchen irgendwie etwas besser :)
Wegen dem callback da habe ich inzwischen dies gefunden
http://tedfelix.com/software/c++-callbacks.html
Wünsche Dir und allen die hier mitlesen schöne Weihnachten und Gesundheit
Gruß Ralf
ich möchte es mal mit der hier beschriebenen "Interface Class" callback Methode versuchen
http://tedfelix.com/software/c++-callbacks.html
Ich habe mal in dem Beispielcode in Bezug auf den Signalduino einige Bezeichnungen angepasst
https://onlinegdb.com/0g0Mcc3nN
das main ist in der Signalduino.ino
die SignalDetectorClass ist in der Signalduino.h
mein Problem ist nun, daß die per callback aufgerufene callbackfunktion Callee auch eine class ist, das bring mir aber so nichts.
Ich möchte per callback "cc1101::getRSSI()" aufrufen.
getRSSI() ist in der Datei "cc1101.h" im namespace cc1101
Gruß Ralf
Habe es inzwischen mit dem callback hinbekommen
https://onlinegdb.com/PB2zjh7re
Hallo Ralf,
hab gerade gesehen du hast auf GitHub mittlerweile die 4.1.2 online, ist die schon soweit zum testen einsetzbar, hab bei mir einen SIGNALduino mit Ethernetmodul im Einsatz, 4.1.1 als Software drauf von dir. Läuft einwandfrei bisher.
Gruß Markus
nein bei der 4.12 ist die Entwicklung noch ganz am Anfang.
Als ersten Schritt habe ich eine compile_config.h zugefügt in der die defines stehen.
Gruß Ralf
Hallo Ralf,
das habe ich auch schon gesehen, finde das recht gut. Da kann man alle wichtigen Einstellungen vornehmen und kann vom Rest die Finger lassen.
Als Option könntest du dort einfließen lassen ob man die IP Adresse statisch oder per DHCP vergeben haben möchte, habe bei mir nämlich die Konfig für DHCP angepasst und in meiner FritzBox eingestellt das der Signalduino immer die gleiche IP bekommt.
Gruß Markus
Hallo,
ich such schon länger nach einer Lösung meinen SignalDuino weiter entfernt zu montieren, da ich mit der Reichweiter Probleme habe.
Dabei bin ich auf diesen Beitrag hier gestossen.
Brauch ich hier zum Netzwerkkabel auch noch ein Stromkabel oder läuft dies auch über POE?
Hab gesehen, ihr habt da schon eine Platine entwickelt, nur wo ist der Unterschied mit den einzelnen Versionen und was für Teile werden noch alle benötigt?
Vielleicht kann mir die Fragen wer beantworten, danke!
Gruß Gerhard
ZitatBrauch ich hier zum Netzwerkkabel auch noch ein Stromkabel oder läuft dies auch über POE?
Du brauchst auch noch ein Stromkabel, das W5500 LAN Modul kann kein POE.
ZitatHab gesehen, ihr habt da schon eine Platine entwickelt, nur wo ist der Unterschied mit den einzelnen Versionen und was für Teile werden noch alle benötigt?
https://wiki.fhem.de/wiki/Maple-SignalDuino#Platine
https://wiki.fhem.de/wiki/Maple-SignalDuino#Teile
Gruß Ralf
Hallo Gerhard,
bezüglich
Zitat von: GerhardSt am 03 Januar 2021, 21:13:20
Brauch ich hier zum Netzwerkkabel auch noch ein Stromkabel oder läuft dies auch über POE?
kannst du ja eventuell auf so etwas zurückgreifen:
https://www.amazon.de/Revotech-Anschluss-Splitter-Standard-USB0502-Black-usb0502/dp/B0822PF7WV/ref=sr_1_14?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=142VTE1H42LL8&dchild=1&keywords=poe+adapter+micro+usb&qid=1609738822&sprefix=poe+adapter+micro%2Caps%2C165&sr=8-14 (https://www.amazon.de/Revotech-Anschluss-Splitter-Standard-USB0502-Black-usb0502/dp/B0822PF7WV/ref=sr_1_14?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=142VTE1H42LL8&dchild=1&keywords=poe+adapter+micro+usb&qid=1609738822&sprefix=poe+adapter+micro%2Caps%2C165&sr=8-14)
Gruß Markus
Zitat von: Ralf9 am 28 Dezember 2020, 12:53:13
Habe es inzwischen mit dem callback hinbekommen
https://onlinegdb.com/PB2zjh7re
Habe versucht das callback in die V 4.12 einzubauen, aber ich bekomme beim kompilieren mit der Arduino IDE einen error:
SIGNALDuino:116:1: error: 'musterDecB' does not name a type
116 | musterDecB.rssiConnectCallback(&callee);
| ^~~~~~~~~~https://github.com/Ralf9/SIGNALDuino/commit/362966631a956191853464d830ca89757906e880
Ich komme da alleine nicht weiter :(
signalDecoder4.h
class rssiCallbackInterface // fuer getRSSI
{
public:
// The prefix "cbi" is to prevent naming clashes.
virtual uint8_t cbiRssiCallbackFunction(void) = 0;
};
class SignalDetectorClass
{
friend class ManchesterpatternDecoder;
public:
SignalDetectorClass() : first....
...
// Clients can connect their callback with this
void rssiConnectCallback(rssiCallbackInterface *cb)
{
m_cb = cb;
}
...
private:
// The callback provided by the client via connectCallback().
rssiCallbackInterface *m_cb;
};
SIGNALduino.ino:
...
#include "cc1101.h"
//#include "FastDelegate.h"
#include "output.h"
#include "bitstore4.h"
#include "signalDecoder4.h"
#include "SimpleFIFO.h"
// "Callee" can provide a callback to Caller.
class Callee : public rssiCallbackInterface
{
public:
// The callback function that Caller will call.
uint8_t cbiRssiCallbackFunction()
{
return cc1101::getRSSI();
}
};
SimpleFIFO<int16_t,FIFO_LENGTH> FiFoA; //store FIFO_LENGTH
SimpleFIFO<int16_t,FIFO_LENGTH> FiFoB; //store FIFO_LENGTH
//SignalDetectorClass musterDecA;
SignalDetectorClass musterDecB;
Callee callee;
// Connect the rssiCallback
//musterDecA.rssiConnectCallback(&callee);
musterDecB.rssiConnectCallback(&callee);
...
hab den Fehler gefunden, jetzt funktioniert das rssi callback
Hallo,
ich hab nun in die "SIGNALduinoAdv 4.1.2-dev..." eingebaut, daß auch beim cc1101 ModulA das Empfangen und Senden von SlowRF funktioniert
hier ist eine Testversion
https://github.com/Ralf9/SIGNALDuino/tree/dev-r412_cc1101
- Zur Unterscheidung wird bei SlowRF von Modul A bei "CG" (get config) am anfang "A: " ausgegeben.
- damit SlowRF über das cc1101 Modul A gesendet wird, muß an den Sendebefehl ein A angehängt werden, z.B.
SRA;R=3;...
SMA;...
SCA;...
Das Senden über das 00_Signalduino Modul funktioniert noch nicht, da ist noch eine Anpassung notwendig,
wenn niemand eine bessere Idee hat baue ich ein neues Attribut "sendSlowRF_A_IDs" ein, da werden die Protokoll IDs eingetragen die über das Modul A senden sollen.
- Da die configset Variablen im EEPROM verschoben und ergänzt wurden, muss die Konfiguration im EEPROM zurückgesetzt werden ("eC")
Durch die Änderung vom #define VERSION_2 wird beim ersten starten automatisch die Konfiguration im EEPROM mit den Defaultwerten initialisiert.
Wichtig: Das bedeutet dann aber auch, daß bei jedem wechsel der Firmware zwischen 4.12 und 4.11 die EEPROM konfig neu initialisiert wird.
Ich habe versucht die zum kompilieren mit der Arduino IDE notwendigen Dateien in die README.md einzutragen, es wird aber leider alles in einer Zeile ausgeben, weiß jemand wie ich da Zeilenumbrüche einbauen kann?
Gruß Ralf
Hallo Ralf9,
ZitatIch habe versucht die zum kompilieren mit der Arduino IDE notwendigen Dateien in die README.md einzutragen, es wird aber leider alles in einer Zeile ausgeben, weiß jemand wie ich da Zeilenumbrüche einbauen kann?
Einfach eine Leerzeile dazwischen.
Grüße,
Jürgen
Hab bei meiner Variante der 00_SIGNALduino.pm bei der dev Version das SlowRF Senden über das Modul A eingebaut.
https://forum.fhem.de/index.php?topic=111653.msg1058900#msg1058900
Wenn z.B. beim Attribut "sendSlowRF_A_IDs" 74 eingetragen wird, dann wird FS20 über das Modul A gesendet.
Hallo Ralf,
ich habe mir die FW für meine Sduino, Sduino LAN und CUL Boards kompiliert und eingespielt. Sieht soweit alles gut aus - wenn man wieder alle Module aktiviert hat :) Selbstverständlich habe ich auch die pm Files upgedatet. Dabei habe ich jetzt gesehen, dass der "set <device> cmdBank s" Befehl nicht mehr sauber funktioniert. Für Bank 0 wird irgendetwas in der Auflistung ausgegeben wenn überhaupt (siehe angefügtes Bild).
Nebenbei habe ich mir noch die compile_config.h angeschaut. Da ich beim umkommentiere gene mal vergesse ein define wieder wegzunehmen, habe ich für mich das config File etwas angepasst. So kann ich immer nur ein Board auswählen. Schau es dir mal an, eventuell ist es ja etwas für dich.
Gruß Reinhard
Hallo Reinhard,
ZitatFür Bank 0 wird irgendetwas in der Auflistung ausgegeben wenn überhaupt (siehe angefügtes Bild).
Habe es gefixt.
Wenn bei ccmode 0 im EEPROM eine Kurzbeschreibung ist, dann wird diese anstatt "SlowRF" ausgegeben, da hat was nicht ganz gepasst.
0x40-0x47 bis Bank 9 0x88-0x8F # Bank 0 bis Bank 9, Kurzbeschreibungen (max 8 Zeichen)ZitatNebenbei habe ich mir noch die compile_config.h angeschaut. Da ich beim umkommentiere gene mal vergesse ein define wieder wegzunehmen, habe ich für mich das config File etwas angepasst.
Ich finde bei der Boardauswahl Text besser als eine Zahl.
Gruß Ralf
Guten Morgen Ralf,
Zitat von: Ralf9 am 20 Januar 2021, 22:31:00
Hallo Reinhard,
Habe es gefixt.
Wenn bei ccmode 0 im EEPROM eine Kurzbeschreibung ist, dann wird diese anstatt "SlowRF" ausgegeben, da hat was nicht ganz gepasst.
0x40-0x47 bis Bank 9 0x88-0x8F # Bank 0 bis Bank 9, Kurzbeschreibungen (max 8 Zeichen)
Mit welcher Version kann ich es verifizieren?
Zitat
Ich finde bei der Boardauswahl Text besser als eine Zahl.
Gruß Ralf
Dein Baby, deine Entscheidung :)
Gruß Reinhard
https://github.com/Ralf9/SIGNALDuino/commit/21915b1827b958bec8b81c97c2ec49b36b4c3369
https://github.com/Ralf9/SIGNALDuino/tree/dev-r412_cc1101
Werde ich heute Abend testen...
Hallo Ralf,
hat leider etwas gedauert. Mit der neuen Version war ich leider nicht erfolgreich, siehe angehängten Screenshot.
Gruß Reinhard
Ich möchte mal sehen was im EEPROM ab der 0x40 steht, bitte mach mal ein "get raw rN0040"
Bitteschön:
readEEPROM64:
EEPROM 0040: 4D 31 5F 49 54 2B 00 FF 4D 31 5F 49 54 2B 00 FF
EEPROM 0050: 4D 32 5F 49 54 2B 00 FF 50 43 41 5F 33 30 31 00
EEPROM 0060: 4B 6F 70 70 5F 46 43 00 4D 35 5F 49 54 2B 00 FF
EEPROM 0070: 57 48 35 31 00 FF FF FF FF FF FF FF FF FF FF FF
wenn Du die Bank 0 mit "get raw e0" auf SlowRF zurücksetzt, müsste es passen
Kaum macht man's richtig... ;D
Danke dir, schönes WE
Reinhard
Zitat von: Ralf9 am 13 Dezember 2020, 16:49:21
Mit dem Backboard lässt sich ohne Löten ein Signalduino zusammenbauen, aber nur mit einem 433 cc1101 für slowRF. FSK ist nicht möglich.
Gruß Ralf
Sogar noch besser. Ich habe mir auch so ein Teil zugelegt, aber zusätzlich die serielle Schnittstelle auf UART2 umgebogen und einen ESP01 mit esp-link auf den zweiten Sockel gesteckt.
Damit kann man die Antenne dann überall platzieren, wo man Strom findet und FHEM per Netz anbinden. Klappt hervorragend :)
Gruß, Jochen
Hallo Jochen,
was für ein STM32 ist auf Deinem Black Board drauf?
STM32F103CBT6 mit 128K flash oder
STM32F103C8T6 mit nur 64K flash?
Die V 4.1.2 passt mit ca 69K nicht mehr auf den STM32F103C8T6 drauf
Gruß Ralf
Hallo Ralf,
Ist wohl ein Fake STM32F103C8T6 mit 128k.
Die V 4.1.2 hat gepasst.
Gruß, Jochen
Welches Board hast Du bei der Arduino IDE zum kompilieren verwendet? Maple Mini?
Ich habe zuerst einen passenden DFU Bootloader per ST-LINK geflasht. In der arduino IDE habe ich Maple Mini ausgewählt und dann USB abgeschaltet. Dann per Key und Reset den Flash Mode aktiviert und über die IDE mit DFU 2.0 geflasht.
Ich habe im github in der V 4.1.2 das Blackboard zugefügt.
Es gibt nun in der compile_config.h einen neuen Eintrag "define BLACK_BOARD 1"
Es wird nur die Variante mit 128K flash unterstützt
https://github.com/Ralf9/SIGNALDuino/commit/f4225b0965fc31fc6371b350692f7192cba6b69d
Zitat von: Ralf9 am 29 Dezember 2020, 18:43:09
nein bei der 4.12 ist die Entwicklung noch ganz am Anfang.
Als ersten Schritt habe ich eine compile_config.h zugefügt in der die defines stehen.
Gruß Ralf
Hallo Ralf,
ich hatte dir mal die Frage gestellt bezüglich den Update von der 4.1.1 auf die 4.1.2, da war die Aussage das die 4.1.2 noch ziemlich am Anfang steht, wollte mich mal erkundigen ob dies mittlerweile möglich ist, hab hier einen SIGNALduino mit Ethernetmodul, nutze ihn ausschließlich für 433MHz Keeloq.
Gruß Markus
Hallo Markus,
die V 4.1.2 ist inzwischen soweit fertig, längere Tests habe ich noch nicht gemacht.
Gruß Ralf
Hier sind die Änderungen und Neuerungen der V 4.1.2
Die bin Dateien kommen heute Abend
https://github.com/Ralf9/SIGNALDuino/releases/tag/V4.1.2-dev210205
Funktioniert prima :)
Diesen Patch nutze ich noch für die Umleitung der seriellen Schnittstelle auf den ESP01:
diff --git a/SIGNALDuino.ino b/SIGNALDuino.ino
index 993cd1e..843df96 100644
--- a/SIGNALDuino.ino
+++ b/SIGNALDuino.ino
@@ -143,6 +143,12 @@ Callee rssiCallee;
HardwareSerial HwSerial(SerialNr);
#endif
+#ifdef SER_USART2
+ #include <HardwareSerial.h>
+
+ HardwareSerial HwSerial2(USART2);
+#endif
+
#define pulseMin 90
#define maxCmdString 600
@@ -350,6 +356,9 @@ void setup() {
#ifdef DEBUG_SERIAL
HwSerial.begin(BAUDRATE);
#endif
+ #ifdef SER_USART2
+ HwSerial2.begin(BAUDRATE);
+ #else
Serial.begin(BAUDRATE);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB
@@ -360,6 +369,7 @@ void setup() {
break;
}
}*/
+ #endif
digitalWrite(PIN_LED, LOW);
#ifdef DEBUG_SERIAL
HwSerial.println(F("serial init ok"));
@@ -604,9 +614,10 @@ void loop() {
bool state;
uint8_t fifoCount;
-/*#ifdef MAPLE_Mini
+#ifdef SER_USART2
serialEvent();
#endif*/
+
#ifdef LAN_WIZ
serialEvent();
ethernetLoop();
diff --git a/compile_config.h b/compile_config.h
index 844b992..5d64622 100644
--- a/compile_config.h
+++ b/compile_config.h
@@ -2,9 +2,10 @@
// Config flags for compiling correct options / boards Define only one
-#define MAPLE_SDUINO 1
+//#define MAPLE_SDUINO 1
//#define MAPLE_CUL 1
-//#define BLACK_BOARD 1
+#define BLACK_BOARD 1
+#define SER_USART2 1
//#define LAN_WIZ 1 // nur fuer MAPLE_SDUINO mit USR-ES1 W5500
#define MAPLE_WATCHDOG 1
diff --git a/src/_micro-api/libraries/output/src/output.h b/src/_micro-api/libraries/output/src/output.h
index d14650a..bcb2e38 100644
--- a/src/_micro-api/libraries/output/src/output.h
+++ b/src/_micro-api/libraries/output/src/output.h
@@ -58,6 +58,10 @@
extern EthernetClient client;
#define MSG_PRINTER client
+#elif SER_USART2
+ extern HardwareSerial HwSerial2;
+
+#define MSG_PRINTER HwSerial2
#else
#define MSG_PRINTER Serial
#endif
@@ -65,6 +69,8 @@
#ifdef LAN_WIZ
//#ifdef ETHERNET_DEBUG
#define DBG_PRINTER client
+#elif SER_USART2
+#define DBG_PRINTER HwSerial2
#else
#define DBG_PRINTER Serial
#endif
Gruß,
Jochen
ZitatDiesen Patch nutze ich noch für die Umleitung der seriellen Schnittstelle auf den ESP01:
Ich habe versucht es etwas einfacher hinzubekommen:
In der Arduino IDE habe ich beim board: "USART Support: Enabled (no generic serial)"
in der compile_config.h
#define BLACK_BOARD 2 // 1 - USB, 2 - serial USART2 für ESP
#if BLACK_BOARD == 2
#define SERIAL_USART2
#endif
in der output.h
#ifdef SERIAL_USART2
extern HardwareSerial Serial;
#endifIn der Signalduino.ino
#if defined(DEBUG_SERIAL) || defined(SERIAL_USART2)
#include <HardwareSerial.h>
#endif
#ifdef DEBUG_SERIAL
HardwareSerial HwSerial(SerialNr);
#endif
#ifdef SERIAL_USART2
HardwareSerial Serial(USART2);
#endif
in der loop()
#ifdef SERIAL_USART2
serialEvent();
#endifMir ist dabei nicht klar warum jetzt die "serialEvent()" nicht mehr automatisch aufgerufen wird.
Gruß Ralf
Zitat von: Ralf9 am 06 Februar 2021, 21:53:08
Ich habe versucht es etwas einfacher hinzubekommen:
Funktioniert prima.
Zitat von: Ralf9 am 06 Februar 2021, 21:53:08
Mir ist dabei nicht klar warum jetzt die "serialEvent()" nicht mehr automatisch aufgerufen wird.
Ich habe es nicht weiter untersucht, aber ohne das serialEvent() ist der SIGNALDuino auf USART2 taub.
Gruß, Jochen
Hallo Zusammen, eins vorweg: Tolle Idee und tolle Software!!
Ich habe diese auf einem 4x Maple CUL laufen. Der 433MHz läuft problemlos aber ich habe Probleme mit LaCrosse Sensoren.
Mal kommen die Daten im Minutentakt dann aber(meistens) nur alle 15 bis 30 Minuten oder noch gößeren Abständen.
Meine Konfiguartion ist:
Chip A: b=1 rx=0 freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:17257.69Baud) [boffs=0100*] a_ccconfFSK ccmode=3 sync=2DD4 Modulation:2-FSK
(SYNC_MODE:16/16 + carrier-sense above threshold)
Chip B: b=0 rx=0 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
Chip C: b=2 rx=0 freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:9571.08Baud) [boffs=0140]
Ich habe zwei Sensoren TX35DTH und TX29, was mache ich falsch??
Mein TX29 wird zuverlässig alle ca 5 - 10 Sek empfangen.
Evtl passt die Frequenz nicht genau.
Es gibt cc1101 Module und Sensoren bei denen die Frequenz nicht passt.
Habe hier im Forum was darüber gelesen, kann es aber gerade nicht finden.
Gruß Ralf
Ja, siehe https://forum.fhem.de/index.php/topic,91740.0.html
Das zuletzt in dem Beitrag vorgestellte 868MHz CC1101 Board wäre für das Blackboard auch noch eine interessante Option, dann aber nicht mehr ganz lötfrei.
Gruß, Jochen
ZitatDas zuletzt in dem Beitrag vorgestellte 868MHz CC1101 Board wäre für das Blackboard auch noch eine interessante Option, dann aber nicht mehr ganz lötfrei.
Der Vorteil vom Blackboard ist, daß man nicht löten muss.
Wenn man ein 868MHz CC1101 benötigt und deshalb beim Blackboard löten müsste, ist die Platine von Ranseyer die bessere Wahl
Gruß Ralf
Zitat von: Ralf9 am 08 Februar 2021, 19:19:21
Mein TX29 wird zuverlässig alle ca 5 - 10 Sek empfangen.
Evtl passt die Frequenz nicht genau.
Es gibt cc1101 Module und Sensoren bei denen die Frequenz nicht passt.
Habe hier im Forum was darüber gelesen, kann es aber gerade nicht finden.
Gruß Ralf
Also zu dem Thema muss ich leider auch sagen, dass es bei mir nicht korrekt mit Lacrosse funktioniert. Allerdings liegt es nicht an der Signalduino Software. Ich habe das auch mit dem MapleCUL beobachtet. Auch auf beiden Platinen (sduino, CUL) mit der signalduino software getestet.
Zum Thema Modul und Frequenz: Ich hatte Module verwendet, aus einer vermeintlich zuverlässigen Aliexpress-Quelle. Aber das muss ja erstmal nix heißen. Ich habe dann auch das Homematic Frequenzestprogramm mal durchlaufen lassen. Ergebnis war sehr gut. Also keine Abweichungen.
Trotzdem habe ich diese Empfangsaussetzer bei Lacrosee. Mit einem TX35-IT (Mode 2).
Aber es ist interessant, dass weitere diese Aussetzer haben, auch mit Mode 1.
@bublik10 Du nutzt die Briefmarkenmodule? Wo hast du diese gekauft? Aber wie gesagt, ich glaube nicht, dass es an den Funkmodulen liegt.
Es kann auch sein dass bei der a-culw die cc1101 Registerwerte für Lacrosse nicht ganz stimmen, ich habe die cc1101 Registerwerte von der a-culw übernommen.
Bei CSccmode=4 verwende ich für den Empfang die selbe Routinen wie die a-culw.
Solange keiner der Entwickler solch einen Lacrosse Sensor mit Aussetzern hat, wird es schwierig den Fehler zu finden
Gruß Ralf
Zum Thema TX35-IT :
https://github.com/merbanan/rtl_433/blob/master/src/devices/lacrosse_tx35.c (https://github.com/merbanan/rtl_433/blob/master/src/devices/lacrosse_tx35.c)
Zitat...tune to 868240000Hz...
Aussetzer zeigen eigentlich an, dass das Empfangsfenster nur in der Nähe der Sendefrequenz des Sensors liegt.
Wahrscheinlich ist es besser, mal mit der Frequenz etwas zu variieren ...
Außerdem gibt es ja auch noch andere Rahmenbedingungen: "schlechte" Antenne, zu große Dämpfung der Zuleitung etc.
Eine #SDRSharp-Session (https://airspy.com/quickstart/) (neue Version (https://airspy.com/download/) ) gäbe u.U. auch Aufschluss über die Sachlage. ;)
MapleCUL868 ccconf => freq:868.550MHz bWidth:325KHz rAmpl:42dB sens:8dBBei bWidth:325KHz sind es ca. 162KHz um die Mittenfrequenz!
Grüße,
Jürgen
Ich kann das mal probieren, mit SDRSharp.
Ich hatte übringens auch schon mal getestet, ob mit rtl_433 korrekt empfange wird, weil ich ausschließen wollte, dass der Sender irgendwie defekt ist. aber damit wurde korrekt empfangen.
Aber ich versuche das mal mit SDRSharp. Kann aber ein paar Tage dauern.
Ich hatte einen ersten AHA Effekt nachdem ich den MapleCUL von meine NAS-Geäuse entfernt habe.
Allerdings hat es das Problem nicht ganz gelöst, hier mal eine Beispielhistorie, wie unregelmäßig die Daten eintrudeln:
Die Position der Sensoren habe ich nicht verändert.
2021-02-16_00:47:58 16.7
2021-02-16_01:31:38 16.6
2021-02-16_01:54:58 16.5
2021-02-16_03:05:58 16.4
2021-02-16_03:06:18 16.4
2021-02-16_03:06:28 16.4
2021-02-16_03:07:58 16.4
2021-02-16_03:17:13 16.4
2021-02-16_03:17:18 16.4
2021-02-16_04:12:48 16.5
2021-02-16_04:12:58 16.5
2021-02-16_04:14:28 16.5
2021-02-16_04:14:58 16.5
2021-02-16_05:05:58 16.8
2021-02-16_07:14:58 16.7
#laTemp4:temperature:::
Na ja ich werde mal auch mit den Frequenzen rumspielen.
Zitat von: Ralf9 am 05 Februar 2021, 16:53:09
Hallo Jochen,
was für ein STM32 ist auf Deinem Black Board drauf?
STM32F103CBT6 mit 128K flash oder
STM32F103C8T6 mit nur 64K flash?
Die V 4.1.2 passt mit ca 69K nicht mehr auf den STM32F103C8T6 drauf
Gruß Ralf
Zitat von: jochen_f am 05 Februar 2021, 17:40:13
Hallo Ralf,
Ist wohl ein Fake STM32F103C8T6 mit 128k.
Die V 4.1.2 hat gepasst.
Gruß, Jochen
Ich hab das hier dazu gefunden:
https://community.st.com/s/question/0D53W000003MAHkSAO/stm32f103c8t6-with-128kb-of-flash-instead-of-64-fake-or-genuine
ZitatSTM32F103x8 and STM32F103xB are the same chip. So the 128k flash are on chip.
On a STM32F103xB, the upper 64 kB are fully tested, on a a STM32F103x8 the flash is probably not tested or was tested bad.
So if you play with a a STM32F103x8, you can try to use the upper flash. But do not rely on that flash to work right!
Gruß Ralf
Hallo Ralf,
vielen Dank fürs aktuelle "
aufs Gleis" setzen! ;D :D ;)
TYPE: SIGNALduino
a_ccconf: b=0 rx=0 freq:868.320MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
b_ccconf: b=1 rx=0 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100]
c_ccconf: b=2 rx=0 freq:868.200MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0140*]
cc1101_frequency: 868.200
sendworking: 0
unknownmessages
version: V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A0 B1 C2*) - compiled at Feb 6 2021 00:26:38
versionmodul: v3.4.5-ralf_18.08.
versionprotoll: v3.4.5-dev_ralf_28.02.Habe die Konfiguration der CC1101-Module jetzt wohl im Griff. xFSK muss ich noch einschalten bzw. anpassen.
Einige Fragen bleiben noch:
- Im Moment schalte ich zur Konfiguration der 3 Receiver mit dem Befehl EEprom-Bank setzen "bA0" auf den entsprechenden Receiver um. Um dann diesen konfigurieren zu können.
Geht das "einfacher"? Ja, steht im Wiki: "b<x>" mit x= A|B|C|D
- Nach erfolgter Konfiguration kann ich den Output der a_ccconf + b_ccconf + c_ccconf-Anzeige nur nach einem Reset neu einlesen?
Nach langer Pause hat sich wirklich viel getan und der Thread hat deutlich zugenommen .... :D
Grüße,
Jürgen
Hallo Jürgen,
zum selektieren einen cc1101 reicht bA bB oder bC
Es gibt dafür bei meinem fhem Modul "get sduino cmdBank" (siehe Anlage)
Mit "r" wird eine Bankinfo von allen cc1101 ausgegeben und die ccconf internals aktualisiert
Gruß Ralf
Zitat von: Ralf9 am 13 Dezember 2019, 12:48:26
...
Ab der Version 4.1.0 werden bis zu 4 cc1101 Module (A-D) unterstützt
...
Kurze Frage: Wie müssen die PIN-Belegungen für den 4. Transceiver konkret lauten?
CC1101_3 (
D)
3 ?? CSN (Chip Select)
14 ?? GD02 (Receive)
?? GD00 (send), optional für die a-culw
Hab im Wiki, auf Github im Code, in Ranseyers Platinen-Doku und im Thread geschaut. Sorry, falls ich es überlesen/ falsch verstanden haben sollte.
Danke und viele Grüße
rob
ZitatCC1101_3 (D)
3 ?? CSN (Chip Select)
14 ?? GD02 (Receive)
?? GD00 (send), optional für die a-culw
Ja, das passt.
Das lässt sich auch hier rauslesen:
radioCsPin[] = {31, 12, 15, 3};
pinReceive[] = {11, 18, 16, 14};Bei CC1101_3 (D) gibts kein GD00 (send), da dies bei FSK nicht benötigt wird.
Gruß Ralf
oder hier: https://forum.fhem.de/index.php?action=dlattach;topic=106278.0;attach=137497;image (https://forum.fhem.de/index.php?action=dlattach;topic=106278.0;attach=137497;image)
cc_cs3 wäre das vierte Modul.
Supi. Danke Euch für die flinken Rückmeldungen :)
Eine Verständnisfrage möchte ich gerne noch platzieren: Wenn ich auf einer Frequenz z.B. 868Mhz OOK mache und nun noch FSK benötige, dann muss ich folglich zwei 868er Funk-Module am Maple-SDuino einsetzen. Hab ich das korrekt aufgefasst?
Vielen und beste Grüße
rob
Ja, das ist der Sinn dahinter. ;)
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Hallo zusammen,
Ich habe mir mit der Platine von Ranseyer auch mal einen MapleSduino aufgebaut.
Flashen klappt problemlos, allerdings bekommt der Maple keine IP zugewiesen. LED´s am LAN Modul leuchten bzw. blinken, und die LED am STM blinkt auch gelegentlich.
Wenn ich die USB Version flashe bekommt kann ich den Maple auch ansprechen auf der Console.
pi@raspberrypi:~ $ ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 Mär 20 05:54 usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_005C6F6A3759-if00 -> ../../ttyACM0
Hab bereits die Maple_sduino_LAN_411dev200627.bin als auch die Maple_sduino_LAN_412dev210205.bin getestet.
Muss an dem LAN Modul noch etwas konfiguriert werden?
Zitat von: Feinfinger am 20 März 2021, 07:18:46
Flashen klappt problemlos, allerdings bekommt der Maple keine IP zugewiesen.
.....
Muss an dem LAN Modul noch etwas konfiguriert werden?
Hallo und guten Morgen,
wenn du das fertige Image flashst hast du das Problem das die Netzwerkkarte nicht auf DHCP steht sondern eine feste IP eingestellt ist, steht in der SIGNALDuino.ino:
const uint8_t mac_def[] = { 0x00, 0x80, 0x41 };
const uint8_t ip_def[] = { 192, 168, 0, 244 };
const uint8_t gateway_def[] = { 192, 168, 0, 1 };
const uint8_t netmask_def[] = { 255, 255, 255, 0 };Ich habe mir das ganze in der Arduino-IDE selbst kompiliert und in der SIGNALDuino.ino die Zeile 340 wie folgt angepasst:
Ethernet.begin(mac);Dann hat er keine Parameter vorgegeben und steht somit auf DHCP.
Du kannst die IP soweit ich weiß auch über RAW-Befehle ändern, dazu musst du aber mit deinem Rechner dann im gleichen Netz wie der SIGNALDuino sein (siehe oben) damit du Verbindung zu ihm hast, wie die Befehle da aber genau lauten kann ich dir leider nicht sagen.
Gruß
Markus
siehe hier
https://forum.fhem.de/index.php/topic,106278.msg1049877.html#msg1049877
Da man besonders zum Testen über die Serielle Schnittstelle immer mal eine Übersicht des Signalduinos braucht, aber gerade nie zur Hand hat ... :D
Anbei eine Übersicht, aber ohne Anspruch auf Vollständigkeit ...
Grüße,
Jürgen
Danke für die Antwort, das klärt das Problem.
Ich habe aber Schwierigkeiten beim kompilieren, bekomme immer diesen Fehler angezeigt:
sketch\src\_micro-api\libraries\TimerOne\src\TimerOne.cpp:21:16: error: 'short unsigned int TimerOne::pwmPeriod' is not a static data member of 'class TimerOne'
21 | unsigned short TimerOne::pwmPeriod = 0;
| ^~~~~~~~
sketch\src\_micro-api\libraries\TimerOne\src\TimerOne.cpp:22:15: error: 'unsigned char TimerOne::clockSelectBits' is not a static data member of 'class TimerOne'
22 | unsigned char TimerOne::clockSelectBits = 0;
| ^~~~~~~~
sketch\src\_micro-api\libraries\TimerOne\src\TimerOne.cpp:23:8: error: 'void (* TimerOne::isrCallback)()' is not a static data member of 'class TimerOne'
23 | void (*TimerOne::isrCallback)() = NULL;
| ^~~~~~~~
exit status 1
Fehler beim Kompilieren für das Board Generic STM32F1 series.
@ Markus
Zitat von: meier81 am 20 März 2021, 09:04:47
Ich habe mir das ganze in der Arduino-IDE selbst kompiliert und in der SIGNALDuino.ino die Zeile 340 wie folgt angepasst:
Ethernet.begin(mac);
Dann hat er keine Parameter vorgegeben und steht somit auf DHCP.
Kannst Du mir deine .bin mit DHCP zur Verfügung stellen?
Hallo Feinfinger,
wenn es jeder komilieren könnte ... Nein Spaß bei Seite, das ist seit Urzeiten ein u.A. eingebauter Fehler in der Lib, der sich hartnäckig hält und dauernd nervt ... ;)
Aber nicht für die Maple-Version relevant ist, da TimerOne in MapleSDuino nicht aktiv ist!
Hast Du das richtige Board in Arduino selektiert?
Zitat#ifdef MAPLE_Mini
#include <malloc.h>
extern char _estack;
extern char _Min_Stack_Size;
static char *ramend = &_estack;
static char *minSP = (char*)(ramend - &_Min_Stack_Size);
extern "C" char *sbrk(int i);
#else
#include <TimerOne.h> // Timer for LED Blinking
#endif
Im Anhang ist eine lauffähige Einstellung der Arduino IDE (ohne Gewähr) ;). => korrektere USB-Einstellungen hier: https://forum.fhem.de/index.php?action=dlattach;topic=106278.0;attach=149251;image (https://forum.fhem.de/index.php?action=dlattach;topic=106278.0;attach=149251;image)
Ich gehe davon aus es richtig in der compile config.h eingestellt zu haben
.
#define MAPLE_SDUINO 1
//#define MAPLE_CUL 1
//#define BLACK_BOARD 1
#define LAN_WIZ 1 // nur fuer MAPLE_SDUINO mit USR-ES1 W5500
#define MAPLE_WATCHDOG 1
//#define DEBUG_BackupReg 1
//#define DEBUG_SERIAL 2 // debug level
#define SerialNr USART1 // serial2 = USART2
//#define DEBUGSENDCMD 1
// ---- this options are current not possible, because the V 4.x firmware is only for STM32 (Maple Mini)
//#define ARDUINO_ATMEGA328P_MINICUL 1
//#define OTHER_BOARD_WITH_CC1101 1
//#define WATCHDOG 1 // Der Watchdog ist in der Entwicklungs und Testphase deaktiviert. Es muss auch ohne Watchdog stabil funktionieren.
// ---------------------------------------
// Do not Change anything below this line
Versuche mal meine (korrigierte?) kompilierbare Version:
In
Zitat\SIGNALDuino-dev-r412_cc1101_r9\SIGNALDuino\src\_micro-api\libraries
austauschen.
Ich sehe bei Dir kein.
Zitat#define MAPLE_Mini
Weil:
Board-Einstellung auf Maple_mini gemacht? siehe #791
Ich finde auch die Maple_Mini Zeile nicht.
Ist das ein Fehler in der compileConfig.h?
Welche Signalduino Version?
ZitatIst das ein Fehler in der compileConfig.h?
Nein, den liefert Dir normalerweise die IDE, wenn Du die Boardeinstellung unter Tools richtig gewählt hast.
Suche mal in der
SIGNALDuino.ino einfach nach
TimerOne?
Danke für die Hilfe, aber der Fehler bleibt.
Die STM32 Bibliothek ist auch up to date.
Verstehe ehrlich gesagt nicht, warum er immer den Fehler auswirft.
Vielleicht kann mir doch jemand eine kompilieren.
MapleMini 128k
Ranseyer Platine
1x 433 MHz
LAN Modul bitte mit DHCP
Danke!
Bitte lösche mal die TimerOne aus Deinem sketchverzeichnis.
Mir ist nicht klar warum die Arduino IDE die TimerOne kompileren will, obwohl sie beim MapleMini gar nicht verwendet wird.
Dann meckert er wieder, das die Datei nicht vorhanden ist.
Wie muss die config.h denn aussehen für Maple Mini mit LAN modul und 433MHz?
Board ist so eingestellt.
hast Du das komplette TimerOne Verzeichnis gelöscht?
Es werden nur die Dateien die in der README.md stehen benötigt
https://github.com/Ralf9/SIGNALDuino/blob/dev-r412_cc1101/README.md
Zitat von: Feinfinger am 20 März 2021, 14:51:44
@ Markus
Kannst Du mir deine .bin mit DHCP zur Verfügung stellen?
Hallo und guten Morgen,
hab dir mal meine kompilierte Datei mit DHCP angehängt, zudem noch meine Einstellungen der IDE.
Gruß Markus
Die Einstellungen in Arduino wären was für das Wiki ;)
Zitat von: meier81 am 21 März 2021, 10:12:39
Hallo und guten Morgen,
hab dir mal meine kompilierte Datei mit DHCP angehängt, zudem noch meine Einstellungen der IDE.
Gruß Markus
Danke an alle für die Mithilfe!
Läuft jetzt.
Habe die IDE neu instaliiert und nochmal von vorne angefangen, jetzt klappt das kompilieren auch.
Mit den Einstellungen fürs Board von Markus funktioniert dann auch die von mir selbst kompilierte FW auf dem Maple :)
Hallo,
gibt es jemanden, der das Gerät fertig aufgebaut verkauft?
Gruß
Martin
Hallo M_Str,
als Suche in https://forum.fhem.de/index.php/board,16.0.html (https://forum.fhem.de/index.php/board,16.0.html)?
Vielleicht auch näher definieren, was Du an HW-Features haben möchtest.
Grüße,
Jürgen
ich hab im Github dev-r412_cc1101 ein wenig aufgeräumt und die nicht mehr benötigten Verzeichnisse TimerOne, fastdelegate und firmware gelöscht.
In der "compile_config.h" gibts nun für die Black Board hardware eine weitere Option
#define BLACK_BOARD 1 // 1 - USB, 2 - serial USART2 fuer ESP
damit kann nun für den ESP Steckplatz für die serial auch der USART2 verwendet werden
es gibt für LAN ein neues define
#define LAN_INIT_DHCP 1
damit wird bei der ersten Inbetriebnahme DHCP verwendet
Es wird nun beim LAN DHCP verwendet, wenn die letzte Stelle der IP-Adresse 0 ist.
https://github.com/Ralf9/SIGNALDuino/commit/5b00e34846327c665186a2393f18b085ef126f62
Gruß Ralf
Soweit funktioniert das senden und empfangen einwandfrei.
Eine Frage habe ich aber noch.
Sollte auf der seriellen Konsole (sprich dem seriellen Monitor der IDE) ein output kommen?
Nein, die empfangenen Nachrichten werden nur übers LAN ausgegeben.
Es gibt ein "#define DEBUG_SERIAL", damit können debuginfos über serial1 oder serial2 ausgegeben werden
Da war der Ralf jetzt schneller als ich mit dem antworten ;)
Zitat von: Ralf9 am 21 März 2021, 20:42:39
Nein, die empfangenen Nachrichten werden nur übers LAN ausgegeben.
Es gibt ein "#define DEBUG_SERIAL", damit können debuginfos über serial1 oder serial2 ausgegeben werden
Danke :)
Ich hab da mal ne Frage... vor mir liegt ein Doppel-CUL für 868/433 MHz. Da steckt meines Wissens auch Maple drin. Kann ich die Signalduino-Firmware auch drauf flashen? Gehen dann beide Frequenzen, oder nur eine? Und wie flashe ich das am besten? Geht das auch ünber ein Windows-Tool?
Wär toll, wenn mir da jemand auf die Sprünge helfen könnte...
Hallo beaune,
es gibt eine ,,Maple"-CUL-Variante der Signalduino FW.
Siehe auch Antwort #715
https://github.com/Ralf9/SIGNALDuino/releases/download/V4.1.1-dev200627/Maple_cul_USB_411dev200627.bin
Ok danke, probier ich aus. Aber gehen damit dann auch BEIDE Sender der Doppel-Culs, oder muss ich das irgendwo auswählen? Das ist mir nicht klar. Und ich bin mir auch unsicher, welches Flash-Tool ich einsetzen kann. Da wär mir etwas für Windows das liebste, falls es da etwas gibt.
Ja,
https://forum.fhem.de/index.php/topic,106278.msg1141506.html#msg1141506
Die Befehlsliste.... 😙 nur zwei Pages zurück .... oder einfach im Wiki nachschauen ..😄
ZitatAber gehen damit dann auch BEIDE Sender der Doppel-Culs,
Ja es können beide Sender verwendet werden.
Für was möchstest Du das 868 MHz Modul verwenden?
Gruß Ralf
Vielleicht ist mein Problem einfach, dass ich noch nicht richtig verstanden habe, wie so ein Doppel-CUL funktioniert. Um Missverständnissen vorzubeugen: ich meine dieses Ding: https://www.ebay.de/itm/372666403939?chn=ps&norover=1&mkevt=1&mkrid=707-134425-41852-0&mkcid=2&itemid=372666403939&targetid=1112021128307&device=c&mktype=pla&googleloc=1004707&poi=9044090&campaignid=12599143907&mkgroupid=119504145573&rlsatarget=pla-1112021128307&abcId=9300525&merchantid=7364532&gclid=EAIaIQobChMIrausnsnc7wIVrgZ7Ch3NagoCEAQYASABEgI_CvD_BwE (https://www.ebay.de/itm/372666403939?chn=ps&norover=1&mkevt=1&mkrid=707-134425-41852-0&mkcid=2&itemid=372666403939&targetid=1112021128307&device=c&mktype=pla&googleloc=1004707&poi=9044090&campaignid=12599143907&mkgroupid=119504145573&rlsatarget=pla-1112021128307&abcId=9300525&merchantid=7364532&gclid=EAIaIQobChMIrausnsnc7wIVrgZ7Ch3NagoCEAQYASABEgI_CvD_BwE)
Mein Ziel ist es, beide Funkkanäle als Signalduino in fhem zu betreiben, also einen auf 868 und einen auf 433 MHz. Ich bin bisher davon ausgegangen, dass so ein DoppelCUL EINE Firmware hat, die eben für beide Kanäle zum Einsatz kommt. Ist das falsch? Muß/kann man die Kanäle getrennt flashen? Und mit welchem Tool mache ich das am besten? Aus fhem heraus unter Linux? Oder gehts auch unter Windows?
Bin für jede Hilfe echt dankbar.
Hallo beaune,
wie hast Du den CUL den in FHEM eingebunden?
Dort müsstest Du doch zwei MapleCul Devices definiert haben?
Das Thema "Maple-CUL" + "MapleCUL" + "MapleCUx" ist im Wiki unter dem Thema "MapleCUN" verborgen ;)
https://wiki.fhem.de/wiki/MapleCUN (https://wiki.fhem.de/wiki/MapleCUN)
Ich schlage vor, Du schaust Dir das Wiki mal durch und entscheidest dann, ob Du Dir das Prozedere auch zutraust?
GGf. wäre ein get version hilfreich, um herauszufinden welchen FW-Versionstand Dein MapleCUL beherbergt.
Ich habe noch diese Version bei mir im Einsatz: "MapleCUL433 version => V 1.24.02 a-culfw Build: private build (unknown) MapleCULx4_03 (F-Band: 433MHz)"
Grüße,
Jürgen
/edit:
https://forum.fhem.de/index.php/topic,60458.msg1066158.html#msg1066158
(!!!)
Hi,
ja das sind aus fhem-Sicht 2 Devices, die aber eine Abhängigkeit haben:
Der 868MHz-Teil ist so eingebunden (Windows-System, deshalb sieht das vielleicht etwas ungewöhnlich aus):
defmod MapleCUL_0_868 CUL COM5@115200 1234
Der 433MHz-Teil dann so:
defmod MapleCUL_1_433 STACKABLE_CC MapleCUL_0_868
So richtig verstehe ich diese Konstruktion nicht, aber sie war so vorgegeben und funktioniert ja auch. Nur was das eben heißt, wenn ich statt V 1.26.08 a-culfw-Firmware lieber sduino verwenden möchte, krieg ich noch nicht so ganz gegriffen.
ZitatV 1.26.08 a-culfw-Firmware lieber sduino verwenden möchte, krieg ich noch nicht so ganz gegriffen.
Genau das ist das Problem. Ralf9 hat ja auch nachgefragt, was Du Dir davon versprichst?
Hast Du einen besonderen, konkreten Anwendungsfall dafür?
Ansonsten:
never change a running system.
Es sein denn, Du hast mit Deinem Kenntnisstand gerade Lust + Zeit auf Abenteuer ;)
Also arbeite Dich bitte erst in die Thematik ein und für konkrete Fragen, sollte immer ein offenes Ohr da sein.
Grüße,
Jürgen
Da hast Du mich jetzt missverstanden: Ich weiß sehr wohl, was ein Signalduino kann, und nutze bereits einen in einer anderen Installation. Meine Frage ist einzig und alleine, ob und in welchem Umfang ich den Doppel-CUL als Signalduino nutzen kann, und wie ich das Umflashen vornehmen muß. Sind das keine konkreten Fragen?
hmmm, meine Antwort war : Ja . => Antwort #814 am: Gestern um 19:29:28 »
#===================================================================================
#
define MapleSDuino SIGNALduino /dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7208705255-if00@115200
setuuid MapleSDuino 6d37e15f-4e46-4b59-8451-60cbb5a98956
attr MapleSDuino room Gateways
attr MapleSDuino verbose 3
#===================================================================================
Soweit ich das mitbekommen habe, benutzt Du Windows als FHEM-Server. Dann solltest Du den Part: "/dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D7208705255-if00"
durch COM5 ersetzen.
Mit der Firmware V4.1.2
https://github.com/Ralf9/SIGNALDuino/releases/tag/V4.1.2-dev210205
ist auf beiden Modulen Slowrf möglich, z.B. FS20 auf dem 868MHz Modul
Was möchstet Du auf 868MHz empfangen und senden?
Gruß Ralf
Damit auch bei 868MHz slowrf gesendet werden kann gibts bei meinem 00_SIGNALduino.pm dev Modul ein neues Attribut
https://forum.fhem.de/index.php/topic,111653.75.html
Zitat16.01.21
Attribut "sendSlowRF_A_IDs" zugefügt
Damit können komma getrennt die protocolId angegeben werden bei denen das cc1101 Modul A zum senden verwendet wird (Nur für MapleSduino Firmware ab V 4.12)
Edit:
Bei FSK wird beim Senden automatisch das richtige Modul verwendet
Ich möchte auf 868 Mhz FS20-Geräte ansteuern und empfangen, und auf 433 Funksteckdosen ansteuern, die von der CUL-Firmware nicht unterstützt werden, z.B. IT-Steckdosen, sowie SD_WS07-Sensoren empfangen. Soweit ich weiß ist das alles Slowrf, sollte demnach also mit der vorgenannten Firmware gehen.
Bleibt nur noch die Frage, wie ich das Bin-File in den Doppel-CUL bekomme. Wenn der WIKI-Beitrag zum MapleCUN wie Jürgen schreibt hier auch zutrifft, müßte das ja unter Windows mit dfu-util gehen. Probiere ich aus. Einen Bootloader brauche ich ja nicht mehr flashen, wenn vorher schon V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) MapleCUNx4_03 drauf war, oder?
Danke für Eure Geduld!
So, ich habs jetzt gewagt und den DoppelCUL auf Firmware V4.1.2 umgeflasht sowie die 00_SIGNALduino.pm und die signalduino_protocols.pm ausgetauscht. Hat auch funktioniert, ich konnte das Device als Signalduino in fhem einbinden und es empfängt auch.
Was mir jetzt aber noch nicht klar ist, ist die Sache mit den zwei Frequenzen. Der jetzt eingebundene Signalduino benutzt die 433 MHz. Was muß ich tun, um auch 868 MHz parallel zu benutzen? Muß ich dann so ähnlich wie beim DoppelCUL vorher auch ein zweites Device definieren? Oder kann ich den Signalduino-Device sagen, dass es beide Kanäle nutzen soll? Das Attribut sendSlowRF_A_IDs hab ich gefunden, aber das ist noch nicht alles glaube ich. Hier bräuchte ich nochmal Eure Hilfe.
Hier unter erste Schritte steht was
https://forum.fhem.de/index.php/topic,106278.msg1032098.html#msg1032098
muss ich für das zweite slowrf noch etwas anpassen und ergänzen hab es angepasst
Super, hat funktioniert! Danke für die Unterstützung! Interessant was die Nachbarn alle für mir bis dato unbekannte Geräte haben ;)
Ich hab jetzt noch zwei Fragen:
- Kann man eigentlich irgendwo sehen, über welches der Module die Nachricht gekommen ist? Ist sicher keine kriegsentscheidende Funktion, aber ich fand es schon gut, dass man vorher bei den Devices sehen konnten, über welchen CUL (und damit über welche Frequenz) etwas empfangen wurde. Jetzt ist die Quelle im Internal LASTInputDev immer dieselbe. Vielleicht könnte man dafür ein weiteres Internal definieren, wo diese Info ankommt. Oder vielleicht sieht man es auch irgendwo schon, und ich hab es übersehen.
- Jetzt da ich SlowRF im Griff habe würde mich noch interessieren, wie man FSK-Devices definiert. Ein paar Beispiele gibts ja schon, aber ich vermisse noch die dahinter stehenden Regeln, also welche Register muß ich bei welchen Modulationsparametern wie beschreiben. Gibts dazu schon was? Und noch was Grundlegendes: schließen sich SlowRF und FS auf demselben Modul eigentlich aus? Vermutlich ja, oder?
ZitatKann man eigentlich irgendwo sehen, über welches der Module die Nachricht gekommen ist?
Direkt nicht. Zwischen SlowRF Modul A und Modul B gibts momentan keine Unterscheidungsmöglichkeit.
MU-, MS- und MC-Nachrichten kommen von einem Modul mit SlowRF.
MN-Nachrichten kommen von einem Modul mit FSK
Bei MN-Nachrichten gibts die Konfigvariable N, damit ist eine Zuordnung zum cc1101 Modul möglich. Z.B. N=3 ist Mode 3 - PCA 301
Zitatwürde mich noch interessieren, wie man FSK-Devices definiert. Ein paar Beispiele gibts ja schon, aber ich vermisse noch die dahinter stehenden Regeln, also welche Register muß ich bei welchen Modulationsparametern wie beschreiben
Die Register sind im Datenblatt vom cc1101 beschrieben.
Verschiedene Modulationsarten schliessen sich gegenseitig aus
Gruß Ralf
Zitat von: killah78 am 14 Februar 2021, 18:32:02
Aber ich versuche das mal mit SDRSharp. Kann aber ein paar Tage dauern.
Hier bin ich wieder mit meinem TX35-IT (Lacrosse Mode 2). Also so wie ich das in SDR Sharp deuten kann, sollte die Frequenz so passen.
Ich empfange jetzt aber nix mehr. Weder mit Signalduino, no mit rtl_433. Naja. Ich lege den Sensor einfach wieder weg, brauche ihn auch nicht wirklich, da ich eh größtenteils 433 Thermometer habe.
Aber ein anderes Thema: Wenn ich ein neues FSK Gerät einbauen wollen würde, wie müsste ich das analysieren? Also muss da die Modulation und baudrate usw bekannt sein? Aktuelles Beispiel ist eine Honeywell Funktürklingel. Protokoll ist soweit bekannt, aber ist ja dann auch eine Frage der Modulation etc.
Wie muss ich da vorgehen?
Also es geht in dem Fall um das hier:
Protokoll: https://github.com/klohner/honeywell-wireless-doorbell
rtl_433 unterstützt es auch: https://github.com/merbanan/rtl_433/blob/master/src/devices/honeywell_wdb.c
Kann man da etwas abgucken?
Hier steht was über FSK
ZitatWhen the wireless doorbell button is pressed, it sends out a signal centered at 916.8 MHz. It seems to be using 2FSK modulation with a 50 kHz deviation. The modulation rate seems to be 6250 baud, so each HIGH or LOW symbol is 160 microseconds (μs).
Demnach lässt es sich evtl auch als ASK/OOK (SlowRF) empfangen
ZitatBecause it is using digital symbols over 2FSK modulation, it essentially looks like two separate, simultaneous, out-of-phase OOK transmissions 100 kHz away from each other, at 916.85 MHz and and 916.75 MHz. In FSK parlance, these higher and lower frequencies are respectively referred to as the "mark" and "space" frequencies.
Ok, das heißt über SlowRF sollte ich das Signal schon empfangen? Wie ich das lese wird zwar 2FSK eingesetzt, aber es wird die exakt gleiche Bitfolge frequenzverschoben gesendet? So dass man mit SlowRF die Nachricht dekodieren kann?
Um jetzt erstmal irgendwas vom Funkgong zu empfangen, muss ich da in SlowRF etwas verändern? So ohne Weiteres habe ich im Protokoll nix dem Funkgong zuordnen können.
Der andere Test wäre ein Empfang per FSK. Da muss ich Modulation 2FSK, Deviation und Baudrate setzen. Das würde schon reichen? Oder gib es da weitere relevante Register die passen müssen?
PS: Es handelt sich übrigens um das hier: Honeywell dw915s
Zitatout-of-phase OOK transmissions 100 kHz away from each other,
Die SlowRF Frequenz ist demnach ca 100 kHz neben der FSK Frequenz
Hi,
ich habe jetzt mal rumprobiert, war aber leider erfolglos.
Ausser dass ich bald eingeliefert werde, weil meine Familie sich sorgen macht, warum ich ständig zur Tür renne und klingele. :-)
Also ich konnte mit rtl_433 per OOK kein Signal empfangen, wie es auf der Github Seite beschrieben war. Jedoch aber per FSK
Ich empfange per sdrsharp ein 2FSK Signal (Siehe Anhang).
Ich habe versucht ein Register in den Signalduino zu schreiben, der das FSK Signal empfängt. Leider kommt das Signal nicht rein.
Ich muss sagen, ich bin da auch eher unbedarft. Habe die RFStudio Software benutzt und mit Daten gefüllt, die ich für richtig erachte.
Also ich erwarte ein Signal mit 160/320 Flanken im Protokoll. Sehe ich aber nicht.
Kannst du mal über die Register gucken, ob dir da was auffällt?
ccregAll:
ccreg 00: 29 2E 06 07 D3 91 FF 04 05 00 00 06 00 21 65 6A
ccreg 10: 87 F8 03 22 F8 50 07 30 18 16 6C 03 40 91 87 6B
ccreg 20: FB 56 10 E9 2A 00 1F 41 00 59 7F 3F 81 35 09
cc1101 reg detail - addr, name, value, (OOK default),[reset]
0x00 IOCFG2 - 0x29 (0D)
0x01 IOCFG1 - 0x2E
0x02 IOCFG0 - 0x06 (2D) [3F]
0x03 FIFOTHR - 0x07
0x04 SYNC1 - 0xD3
0x05 SYNC0 - 0x91
0x06 PKTLEN - 0xFF (3D) [0F]
0x07 PKTCTRL1 - 0x04
0x08 PKTCTRL0 - 0x05 (32) [45]
0x09 ADDR - 0x00
0x0A CHANNR - 0x00
0x0B FSCTRL1 - 0x06 [0F]
0x0C FSCTRL0 - 0x00
0x0D FREQ2 - 0x21 (10) [1E]
0x0E FREQ1 - 0x65 (B0) [C4]
0x0F FREQ0 - 0x6A (71) [EC]
0x10 MDMCFG4 - 0x87 (57) [8C]
0x11 MDMCFG3 - 0xF8 (C4) [22]
0x12 MDMCFG2 - 0x03 (30) [02]
0x13 MDMCFG1 - 0x22 (23)
0x14 MDMCFG0 - 0xF8 (B9)
0x15 DEVIATN - 0x50 (00) [47]
0x16 MCSM2 - 0x07
0x17 MCSM1 - 0x30 (00)
0x18 MCSM0 - 0x18 [04]
0x19 FOCCFG - 0x16 (14) [36]
0x1A BSCFG - 0x6C
0x1B AGCCTRL2 - 0x03 (07)
0x1C AGCCTRL1 - 0x40 (00)
0x1D AGCCTRL0 - 0x91 (90)
0x1E WOREVT1 - 0x87
0x1F WOREVT0 - 0x6B
0x20 WORCTRL - 0xFB (F8)
0x21 FREND1 - 0x56
0x22 FREND0 - 0x10 (11) [16]
0x23 FSCAL3 - 0xE9 [A9]
0x24 FSCAL2 - 0x2A [0A]
0x25 FSCAL1 - 0x00 [20]
0x26 FSCAL0 - 0x1F [0D]
0x27 RCCTRL1 - 0x41
0x28 RCCTRL0 - 0x00
0x29 FSTEST - 0x59
0x2A PTEST - 0x7F
0x2B AGCTEST - 0x3F
0x2C TEST2 - 0x81
0x2D TEST1 - 0x35
0x2E TEST0 - 0x09
ccconf: freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:6248.47Baud)
Modulation:2-FSK (SYNC_MODE:30/32 sync)
Edit: Ich habe jetzt auch Syncmode 0 eingestellt (SYNC_MODE:No preamble/sync), da das so in dem Python Testprogramm mit RFLib für CC1111 eingestellt ist. Aber da bekomme ich auch nichts im Log.
Da gibt es noch mehr zu beachten, ich habe hier schon angefangen und werde da noch ein paar wichtige Sachen ergänzen
https://forum.fhem.de/index.php/topic,106594.0.html
@killah78
bitte versuche mal folgendes:
Mit
get sduino raw e
die cc1101 Speicherbank auf default zurücksetzen
mit
get sduino raw CW1200,1550
das Reg 0x12 auf 0 und das Reg 0x15 auf 50 setzen
evtl muß noch die Frequenz, rAmpl und sens angepasst werden.
Ich konnte mit dieser konfig damit von einem sduino zu einem anderen senden:
SRA;R=3;P0=480;P1=-480;P2=160;P3=-160;P4=320;P5=-320;D=014343434343434343252525434343254325432543252525;
Ich bin gerade dabei ins 00_SIGNALduino.pm Modul einzubauen, daß bei get ccconf auch die deviation angezeigt wird (siehe Anlage)
Gruß Ralf
Hi Ralf,
vielen Dank für deinen Support.
Ich habe jetzt mal die neuste FW geflashed. War noch auf 4.1.1.
Dann nach dem Reset und CW1200,1550 kam noch kein Empfang.
Ich habe dann noch die Baudrate angepasst mit CW1057,11F8
Und tatsächlich empfange ich etwas, was ich dem Türgong zuordne:
Edit: Empfang im Anhang, hat hier nicht reingepasst.
Ich kann daraus aber noch nichts deuten und erkenne keine 160 oder 320.
Cconf:
ccconf: freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:6248.47Baud)
Modulation:2-FSK (SYNC_MODE:No preamble/sync)
Die Nachrichten passen, die meisten MU-Nachrichten sind aber zu kurz, evtl passt die datarate noch nicht ganz.
Diese MU-Nachricht enthält 2 Nachrichten
MU;P0=-381;P1=100;P2=260;P3=-220;P4=419;P5=-544;CP=1;R=248;D=010101010101010101010101010101023101023452310102310231010101023101010102310232310101010101010231010101010101010101010101010101010231010234523101023102310101010231010101023102323101010101010102310101010101010101010101010101010102310102345231010231023101010102310;e;
Sie fängt mit 45 an
45231010231023101010102310101010231023231010101010101023101010101010101010101010101010101023101023
45231010231023101010102310101010231023231010101010101023101010101010101010101010101010101023101023
Mit dieser Protokolldefinition
"200" => # Honeywell ActivLink, wireless door bell, PIR Motion sensor
{
name => 'Honeywell ActivLink',
comment => 'Wireless doorbell and motion sensor (PIR)',
changed => '20210420 new',
id => '200',
knownFreqs => '868.3',
one => [2.6,-2.2],
zero => [1 ,-3.8],
start => [4.2,-5.4],
clockabs => 100,
clockpos => ['zero',0],
format => 'twostate',
#modulation => '2-FSK',
preamble => 'u200#',
#clientmodule => '',
#modulematch => '',
length_min => '48',
length_max => '48',
}
ergibt sich:
2021.04.20 22:45:05.694 4 : sduinoD/msg get raw: MU;P0=-381;P1=100;P2=260;P3=-220;P4=419;P5=-544;CP=1;R=248;D=010101010101010101010101010101023101023452310102310231010101023101010102310232310101010101010231010101010101010101010101010101010231010234523101023102310101010231010101023102323101010101010102310101010101010101010101010101010102310102345231010231023101010102310;e;
2021.04.20 22:45:05.694 4 : sduinoD: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate, msgClock=100 (zero) is in tol
2021.04.20 22:45:05.694 5 : sduinoD: Starting demodulation (StartStr: 45 cut Pos 39; Signal: (?:23|10){48,} Pos 0) length_min_max (48..48) length=48
2021.04.20 22:45:05.694 5 : sduinoD: dispatching bits: 100101000010000101100000001000000000000000001001
2021.04.20 22:45:05.694 4 : sduinoD: decoded matched MU Protocol id 200 dmsg u200#942160200009 length 48 RSSI = -78
2021.04.20 22:45:05.694 5 : sduinoD: 1.restarting demodulation at Pos 98 regex ((?:45)((?:23|10){48,}))
2021.04.20 22:45:05.694 5 : sduinoD: dispatching bits: 100101000010000101100000001000000000000000001001
2021.04.20 22:45:05.694 4 : sduinoD: decoded matched MU Protocol id 200 dmsg u200#942160200009 length 48 repeat 1 RSSI = -78
2021.04.20 22:45:05.694 4 : sduinoD: equalDMS u200#942160200009 (2)
2021.04.20 22:45:05.696 5 : sduinoD: dispatch u200#942160200009
2021.04.20 22:45:05.696 4 : SIGNALduino_unknown incomming msg: u200#942160200009
2021.04.20 22:45:05.696 4 : SIGNALduino_unknown rawData: 942160200009
2021.04.20 22:45:05.696 4 : SIGNALduino_unknown Protocol: 200
2021.04.20 22:45:05.696 4 : SIGNALduino_unknown converted to bits: 100101000010000101100000001000000000000000001001
mit dieser Bescheibung
https://github.com/klohner/honeywell-wireless-doorbell#the-data-frame
ist mit der rawdata 942160200009
KEY ID: 94216
Die 2 ist DEVICE TYPE (10 = doorbell)
Gruß Ralf
Danke. Das Empfangen funktioniert damit gut. Ein Senden konnte ich aber noch nicht hinbekommen.
Dazu folgende Fragen:
Die High und Low Symbole entsprechen ja nicht der Beschreibung. Ein Symbol sollte ja 160ms entspechen. Hier ist es aber 100 (P1) bzw. 130 (2xP2). In Summe passen ja die 480ms für 3 Symbole bzw. 1 Bit.Warum ist das so und kann man das noch irgendwie anpassen, damit auch ein Senden möglich wäre?
Und die 45 für den Start sind die End-Symbole (3x High) bei Abschluss der Vor-Sequenz und die Start-Symbole (3x Low) bei Anfang der aktuellen Sequenz, müsste also laut Beschreibung auch eher 480, -480 (statt P4=419, P5=-544) sein.
ich hatte mal sowas probiert, aber erfolglos:
set raw signalduino SR;;R=3;;P0=-381;;P1=100;;P2=260;;P3=-220;;P4=419;;P5=-5441;;D=4523101023102310101010231010101023102323101010101010102310101010101010101010101010101010102310102345;;
Worin liegt denn der Unterschied zwischen format=twostate und modulation=2FSK?
PS: Senden würde eben die Möglichkeit geben bis zu 5 Sender mit unterschiedlichen Blinkzeichen oder Gongtönen zu nutzen. Also für unterschiedliche "Benachrichtigungen".
wenn Du das cc1101 Modul A verwendest, dann muß hinter das SR ein A (set raw signalduino SRA; )
bitte teste mal folgendes:
set raw signalduino SRA;;R=3;;P0=-381;;P1=100;;P2=260;;P3=-220;;P4=419;;P5=-544;;D=45231010231023101010102310101010231023231010101010101023101010101010101010101010101010101023101023;;
oder
set raw signalduino SRA;;R=3;;P0=-381;;P1=100;;P2=260;;P3=-220;;P4=419;;P5=-544;;D=52310102310231010101023101010102310232310101010101010231010101010101010101010101010101010231010234;;ZitatDie High und Low Symbole entsprechen ja nicht der Beschreibung. Ein Symbol sollte ja 160ms entspechen. Hier ist es aber 100 (P1) bzw. 130 (2xP2). In Summe passen ja die 480ms für 3 Symbole bzw. 1 Bit.Warum ist das so und kann man das noch irgendwie anpassen, damit auch ein Senden möglich wäre?
Auf Anhieb habe ich keine Idee. Ändert sich was, wenn Du die datarate erhöhst?
ZitatWorin liegt denn der Unterschied zwischen format=twostate und modulation=2FSK?
wird z.Zt. beim verarbeiten und demodulieren nicht verwendet.
Es wird nur zur Unterscheidung der Nachrichtentypen verwendet.
bei format = 'manchester' ist die Protocol ID eine MC-Nachricht
wenn es modulation gibt, dann ist die Protocol ID eine MN-Nachricht
Sehr cool. Hat geklappt nach ein paar Änderungen. Ich darf ja natürlich nicht mit der gleichen Adresse senden, denn der Gong reagiert ja nicht auf sich selbst. Aber ein Anlernen eines neuen Codes hat geklappt.
Ich hatte das alles vorher mit Radio B getestet, jetzt aber, nach deinem Hinweis, auf Radio A umgestellt.
Zusätzlich habe ich 50 Wiederholungen eingestellt:
set maple_sduino raw SRA;;R=50;;P0=-381;;P1=100;;P2=260;;P3=-220;;P4=419;;P5=-544;;D=52310102310231023101023101010102310232310101010101010231010101010101010101010101010101010101010234;;
Mit diesem konnte ich jetzt einen neuen Sender anlernen und auch einen Gong auslösen.
Toll.
Allderings klappte das nicht mit sendMsg:
2021.04.22 10:04:30 5: maple_sduino: sendmsg msg=P200#000100101010010000101100000001000000000000000000001111#R50
2021.04.22 10:04:30 5: maple_sduino: sendmsg Preparing rawsend command for protocol=200, repeats=50, clock=100 bits=000100101010010000101100000001000000000000000000001111
2021.04.22 10:04:30 5: AddSendQueue: maple_sduino: SR;R=50;P0=420;P1=-540;P2=260;P3=-220;P4=100;P5=-380;D=01454545234545234523452345452345454545234523234545454545454523454545454545454545454545454545454545454523232323; (1)
2021.04.22 10:04:30 4: maple_sduino/set: sending via SendMsg: SR;R=50;P0=420;P1=-540;P2=260;P3=-220;P4=100;P5=-380;D=01454545234545234523452345452345454545234523234545454545454523454545454545454545454545454545454545454523232323;
2021.04.22 10:04:31 5: maple_sduino SW: SR;R=50;P0=420;P1=-540;P2=260;P3=-220;P4=100;P5=-380;D=01454545234545234523452345452345454545234523234545454545454523454545454545454545454545454545454545454523232323;
2021.04.22 10:04:31 4: maple_sduino SendrawFromQueue: msg=SR;R=50;P0=420;P1=-540;P2=260;P3=-220;P4=100;P5=-380;D=01454545234545234523452345452345454545234523234545454545454523454545454545454545454545454545454545454523232323;
2021.04.22 10:04:31 4: maple_sduino/msg READ: Radio B is not active!
2021.04.22 10:04:31 5: maple_sduino/noMsg Parse: Radio B is not active!
2021.04.22 10:04:31 4: maple_sduino/msg READ: 1. Received answer (Radio B is not active!) for sendraw does not match ^S(R|C|M|N);
2021.04.22 10:04:33 4: maple_sduino/HandleWriteQueue: sendraw no answer (timeout)
2021.04.22 10:04:33 4: maple_sduino/HandleWriteQueue: nothing to send, stopping timer
Da stimmen erstens die vor-"000" und End-"111" nicht. Und er will immer durch das Radio B senden. Das hatte ich jetzt für diesen Test deaktiviert. Kann man diese Vor- und Nachsymbole im Protokol so einstellen? Der start passt ja so, aber wie wird das hinten angehangen?
ZitatUnd er will immer durch das Radio B senden.
Dafür gibts das Attribut "sendSlowRF_A_IDs"
ZitatNur für MapleSduino Firmware ab V 4.12
Hier können komma getrennt die protocolId angegeben bei denen das cc1101 Modul A zu senden verwendet wird.
Das Attribut "sendSlowRF_A_IDs" habe ich nicht. Per userattr hinzugefügt hat es keine Funktion.
Ich habe zwischenzeitlich mal im Log mal die Sequenz genommen, was sendMsg erstellt, und das dann per raw gesendet. Und das hat tatsächlich funktioniert. Also muss wohl das Ende nicht mit den "111" abgeschlossen werden. Soweit so gut.
Ich nutze die Version "v3.4.5-ralf_18.08.", ist das nicht die aktuellste dev Version?
ZitatDas Attribut "sendSlowRF_A_IDs" habe ich nicht. Per userattr hinzugefügt hat es keine Funktion.
dies ist momentan nur in der dev Version enthalten.
Eine Testversion von 00_SIGNALduino.pm und signalduino_protocols.pm habe ich unter "FSK mit dem SIGNALDuino" gepostet, dort ist das Honeywell bereits enthalten:
https://forum.fhem.de/index.php/topic,106594.msg1152006.html#msg1152006
Dort ist 000 am Anfang und 111 am Ende
start => [-5.4],
end => [4.2],Beim sendMsg können die Daten auch in Hex angegeben werden
sendmsg P200#0x942160200009#50Bitte teste mal ob dies so passt:
CW000D,012E,022D,0307,04D3,0591,063D,0704,0832,0D21,0E65,0F6A,1087,11F8,1200,1323,14B9,1550,1700,1818,1914,1B43,1C00,1D91,2211,23E9,242A,2500,2611,3D00,3E00,4048,4177,4253,436C,446F,4577,4652,4746
Nein, mit den Registern kommt nichts an.
Ich muss die Frequenz auf 868.350 lassen damit es funktioniert. Ich weiss, da sagt mein Screenshot aus sdr# was anderes.... Sollte ich vielleicht mal kalibrieren....
Ich habe derzeit folgende Register gesetzt, mit der es klappt:
ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 21 65 E8
ccreg 10: 57 F8 00 23 B9 50 07 00 18 14 6C 07 00 90 87 6B
ccreg 20: F8 56 11 EF 2C 17 1F 41 00 59 7F 3F 88 31 0B
Habe die dev Version vom Modul gefunden und funktioniert wunderbar. sendMsg funktioniert damit auch.
ich habe die cc1101 Register für das Honeywell ActivLink auch bei "FSK mit dem SIGNALDuino" eingetragen
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067
Bei den cc1101 Registern 1B und 1D hast Du noch andere Werte als bei den anderen FSK Protokollen üblich.
Bitte teste mal ob es mit 1B43 und 1D91 genausogut funktioniert.
Sind MapleSduino und MapleCU(N|L) eigentlich wirklich so viel unterschiedlich, dass die LAN-Firmware von einem MapleSduino nicht auf einen MapleCUN passt?
Ich hatte hier vor langer Zeit im Thread (https://forum.fhem.de/index.php/topic,106278.msg1070330.html#msg1070330) mal erwähnt, dass ich es mal testen möchte. Aber ich bin vom CUL weg und muss eine CUN-Lösung haben. Für einen MapleCUN gibt es leider keine Signalduino-Firmware.
Ist hier noch etwas in Planung? Oder kann ich auch einfach versuchen, die LAN-Firmware des MapleSduino zu flashen?
Die LAN-Firmware des MapleSduino wird nicht auf dem MapleCUN funktionieren.
Beim MapleSduino ist das LAN an SPI1 des Maplemini angeschlossen.
Beim MapleCUN ist das LAN an SPI2 des MapleMini angeschlossen.
Ich habe das hier gefunden
https://github.com/arduino-libraries/Ethernet/pull/134
Demnach sind an der Ethernet lib einige Anpassungen nötig, damit das LAN auch an SPI2 funktioniert.
Evtl funktioniert es auch ohne diese Anpassungen, wenn in der SIGNALDuino.ino dies
#ifdef MAPLE_CUL
SPIClass SPI_1(28, 29, 30);
Ethernet.init((31);
#endif
vor dieser Zeile eingefügt wird
if (ip[3] != 0) {
https://github.com/Ralf9/SIGNALDuino/blob/5b00e34846327c665186a2393f18b085ef126f62/SIGNALDuino.ino#L344
Kann dies bitte mal jemand mit einem MapleCUN testen?
Gruß Ralf
Hallo Ralf9,
zuerst mal guten Tag hier im Forum.
Meine Funksteckdosen vom Typ Well-Light (433 MHz) werden vom Maple_Signalduino leider nicht erkannt.
Der Versuch des Sendens des Befehls schlägt fehl:
set maple_sduino raw MC;;LL=-1048;;LH=908;;SL=-562;;SH=418;;D=A8CA345ACB860A916AFB7;;C=489;;L=84;;R=221;;s1;;b1;;
Zitat2021.05.16 14:10:38 4: maple_sduino: KeepAlive, ok, retry = 0
2021.05.16 14:10:39 4: maple_sduino: Set_raw, raw MC;LL=-1048;LH=908;SL=-562;SH=418;D=A8CA345ACB860A916AFB7;C=489;L=84;R=221;s1;b1;
2021.05.16 14:10:39 5: maple_sduino: AddSendQueue, maple_sduino: MC;LL=-1048;LH=908;SL=-562;SH=418;D=A8CA345ACB860A916AFB7;C=489;L=84;R=221;s1;b1; (1)
2021.05.16 14:10:39 4: maple_sduino: HandleWriteQueue, called
2021.05.16 14:10:39 4: maple_sduino: SendFromQueue, called
2021.05.16 14:10:39 5: maple_sduino: SimpleWrite, MC;LL=-1048;LH=908;SL=-562;SH=418;D=A8CA345ACB860A916AFB7;C=489;L=84;R=221;s1;b1;
2021.05.16 14:10:39 4: maple_sduino: Read, msg: Unsupported command
2021.05.16 14:10:39 5: maple_sduino: Parse, noMsg: Unsupported command
2021.05.16 14:10:39 4: maple_sduino: HandleWriteQueue, called
2021.05.16 14:10:39 4: maple_sduino: HandleWriteQueue, nothing to send, stopping timer
Warum sendet der Maple_Sduino den Raw Befehl nicht?
Grüße Jake (i.A. juergs)
ZitatMeine Funksteckdosen vom Typ Well-Light (433 MHz) werden vom Maple_Signalduino leider nicht erkannt.
ich habe dafür unter Sonstige Syteme ein neues Thema aufgemacht
https://forum.fhem.de/index.php/topic,121103.0.html
Gruß Ralf
Hi Ralf, funktioniert genauso.
Viele Grüße
Zitat von: Ralf9 am 29 April 2021, 20:08:55
Bitte teste mal ob es mit 1B43 und 1D91 genausogut funktioniert.
Zitat von: Ralf9 am 16 Mai 2021, 00:40:09
Evtl funktioniert es auch ohne diese Anpassungen, wenn in der SIGNALDuino.ino dies
#ifdef MAPLE_CUL
SPIClass SPI_1(28, 29, 30);
Ethernet.init((31);
#endif
vor dieser Zeile eingefügt wird
if (ip[3] != 0) {
https://github.com/Ralf9/SIGNALDuino/blob/5b00e34846327c665186a2393f18b085ef126f62/SIGNALDuino.ino#L344
Kann dies bitte mal jemand mit einem MapleCUN testen?
Ich versuche aktuell mein MapleCUL mit der Signalduino-USB-Firmware in Betrieb zu nehmen.
Ich habe den Maple bereits mehrmals geflasht und auch den Bootloader vorsichtshalber per FTDI-Adapter neu geschrieben.
Sobald der CUL in FHEM bei mir läuft, werde ich die deinen Patch für LAN-Variante für den MapleCUN ausprobieren.
Da ich dann erstmals Signalduino kompiliere, habe ich noch eine Frage. Ich muss doch nur folgendes anpassen, oder?
// #define MAPLE_SDUINO 1
#define MAPLE_CUL 1
//#define BLACK_BOARD 1 // 1 - USB, 2 - serial USART2 fuer ESP
#define LAN_WIZ 1 // nur fuer MAPLE_SDUINO mit USR-ES1 W5500
#define LAN_INIT_DHCP 1 // damit wird bei der ersten Inbetriebnahme DHCP verwendet
#define MAPLE_WATCHDOG 1Ich teste gerade, wie ich für STM32-boards kompilieren kann. Ich habe "Arduino core support for STM32 based boards" (Quelle: https://github.com/stm32duino/Arduino_Core_STM32) eingebunden.
Aber dennoch habe ich folgenden Fehler in der IDE. Hast du einen Tipp für mich?
Branch: https://github.com/Ralf9/SIGNALDuino/tree/dev-r412_cc1101
Arduino: 1.8.15 (Windows 10), Board: "Generic STM32F1 series, Generic F103CBTx, Maple DFU Bootloader 2.0, Enabled (no generic 'Serial'), None, Low/Full Speed, Fast (-O1), Newlib Nano (default)"
In file included from Y:\SIGNALDuino\cc1101.h:12,
from Y:\SIGNALDuino\SIGNALDuino.ino:98:
Y:\SIGNALDuino\tools.h: In function 'void tools::EEwrite(uint16_t, uint8_t)':
tools.h:82:3: error: 'eeprom_buffered_write_byte' was not declared in this scope
82 | eeprom_buffered_write_byte(adr, val);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Y:\SIGNALDuino\tools.h: In function 'void tools::EEbankWrite(uint8_t, uint8_t)':
tools.h:92:3: error: 'eeprom_buffered_write_byte' was not declared in this scope
92 | eeprom_buffered_write_byte(bankOffset + reg, val);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Y:\SIGNALDuino\tools.h: In function 'void tools::EEstore()':
tools.h:102:3: error: 'eeprom_buffer_flush' was not declared in this scope
102 | eeprom_buffer_flush(); // Copy the data from the buffer to the flash
| ^~~~~~~~~~~~~~~~~~~
Y:\SIGNALDuino\tools.h: In function 'void tools::EEbufferFill()':
tools.h:109:3: error: 'eeprom_buffer_fill' was not declared in this scope
109 | eeprom_buffer_fill();
| ^~~~~~~~~~~~~~~~~~
Y:\SIGNALDuino\tools.h: In function 'uint8_t tools::EEread(uint16_t)':
tools.h:117:11: error: 'eeprom_buffered_read_byte' was not declared in this scope
117 | return eeprom_buffered_read_byte(adr);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
exit status 1
'eeprom_buffered_write_byte' was not declared in this scope
Das Thema hatten wir schon ;)
https://forum.fhem.de/index.php/topic,106278.msg1033434.html#msg1033434 (https://forum.fhem.de/index.php/topic,106278.msg1033434.html#msg1033434)
und ff.
Jürgen
Das hatte ich schon gelesen, aber deine Lösung gibt es nicht mehr.
Zitat von: juergs am 21 März 2020, 18:09:59
Die fehlende Installatation von "STM32 cores STMicroelectronics" über den BoardManager war dann wohl das Problem ...
Hoffe das vertägt sich mit allen anderen Instralationen ...
Jürgen
Bist Du mit der neuesten Version unterwegs?
https://github.com/stm32duino/Arduino_Core_STM32/releases/tag/2.0.0
Ja, genau. Die v2.0.0 wie auch zum Testen den aktuellen Master-Branch.
Meine Version trägt den timestamp (W10):
%LOCALAPPDATA%\Arduino15\packages\stm32duino\hardware\STM32F3\2018.4.17Die findest Du unter den ge-Taggten Versionen ganz unten:
https://github.com/stm32duino/Arduino_Core_STM32/tags (https://github.com/stm32duino/Arduino_Core_STM32/tags)
Zitat1.2.0 ...
on 23 Mar 2018
einfach mal diese Version prüfen.
Hab ich gar nicht mitbekommen, daß es inzwischen einen core 2.0.0 gibt
bei Enhancements/improvements: habe ich gefunden
Move the STM32 eeprom driver from core to built-in library
evtl muß ich für den core 2.0.0 fürs EEPROM was anpassen.
Ich versuche gerade den core 2.0.0 in der Arduino IDE zu installieren
das habe ich bei Einstellungen eingetragen
https://github.com/stm32duino/BoardManagerFiles/raw/master/package_stmicroelectronics_index.json
nun muss ich noch den neuen core 2.0.0 im Boardverwalter finden
Das Problem habe ich auch. Ich habe irgendetwas mit STM32 und MCU-Boards gefunden.
Den genauen Wortlaut habe ich aktuell nicht mehr.
Ich muss noch einmal um Hilfe fragen, denn ich bin kurz davor mein MapleSDuino-Projekt aufzugeben.
Ich habe den MapleCUL von locutus. (Quelle: https://forum.fhem.de/index.php/topic,80872.0.html)
Bestückt mit 3x868 CC1101 und auf dem 2. Anschluss ein CC1101 mit 433 Mhz.
Im Thread von locutus wird erwähnt, dass der CUL SIGNALduino-fähig ist.
Der Bootloader war eigentlich aktuell, aber vorsichtshalber habe ich maple_mini_boot20.bin per TTY/FTDI-Adapter neu geschrieben.
Das habe ich auch ausprobiert:
dfu-util -v -d 1eaf:0003 -a 1 -D updater_stm32f1.bin
Und im Monitor erschien nur "Congratulations. You are already using...".
Flash-Log
D:\Arduino_STM32-1.0.0\tools\win\dfu-util-0.9-win64>dfu-util -v -d 1eaf:0003 -a 1 -D d:\updater_stm32f1.bin
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #1 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download [=========================] 100% 25308 bytes
Download done.
Sent a total of 25308 bytes
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Die Firmware für den MapleCUL habe ich auch mehrmals geschrieben:
dfu-util -d 1eaf:0003 -a 2 -D Maple_cul_USB_412dev210205.bin -R
Flash-Log
D:\Arduino_STM32-1.0.0\tools\win\dfu-util-0.9-win64>dfu-util -v -d 1eaf:0003 -a 2 -D d:\Maple_cul_USB_412dev210205.bin -R
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download [=========================] 100% 69880 bytes
Download done.
Sent a total of 69880 bytes
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
Resetting USB to switch back to runtime mode
In FHEM ist das Device folgendermaßen:
defmod MapleCulSIGNALduino SIGNALduino /dev/ttyACM0@115200
attr MapleCulSIGNALduino hardware Maple_cul_USB
versionmodul: v3.4.6-dev_ralf_01.05.
versionprotoL: v3.4.6-dev_ralf_30.04.
Im Log sehe ich nur wie die Verbindung nicht funktioniert:
2021.05.20 18:12:46.869 3: MapleCulSIGNALduino/init: get version, retry = 3
2021.05.20 18:12:46.869 2: MapleCulSIGNALduino/init retry count reached. Reset
2021.05.20 18:12:46.869 3: MapleCulSIGNALduino reset
2021.05.20 18:13:17.176 3: Opening MapleCulSIGNALduino device /dev/ttyACM0
2021.05.20 18:13:17.177 3: Setting MapleCulSIGNALduino serial parameters to 115200,8,N,1
2021.05.20 18:13:17.177 1: MapleCulSIGNALduino/define: /dev/ttyACM0@115200
2021.05.20 18:13:17.177 1: MapleCulSIGNALduino/init: /dev/ttyACM0@115200
2021.05.20 18:13:17.177 3: MapleCulSIGNALduino device opened
2021.05.20 18:13:19.678 3: MapleCulSIGNALduino/init: disable receiver (XQ)
2021.05.20 18:13:20.178 3: MapleCulSIGNALduino/init: get version, retry = 0
2021.05.20 18:13:30.189 3: MapleCulSIGNALduino/init: get version, retry = 1
2021.05.20 18:14:00.201 3: MapleCulSIGNALduino/init: get version, retry = 2
2021.05.20 18:14:50.211 3: MapleCulSIGNALduino/init: get version, retry = 3
2021.05.20 18:14:50.212 2: MapleCulSIGNALduino/init retry count reached. Closed
2021.05.20 18:14:50.212 2: MapleCulSIGNALduino closed
dfu-util --list
Found DFU: [1eaf:0003] ver=0201, devnum=14, cfg=1, intf=0, path="2-14", alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=14, cfg=1, intf=0, path="2-14", alt=1, name="STM32duino bootloader v1.0 Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=14, cfg=1, intf=0, path="2-14", alt=0, name="STM32duino bootloader v1.0 ERROR. Upload to RAM not supported.", serial="LLM 003"
Könnt ihr erkennen, wo ich einen Fehler mache oder habe?
Vielen Dank für eure Hilfe.
Hab den core 2.0.0 nun installiert
https://github.com/stm32duino/wiki/wiki/Getting-Started#installing-stm32-cores
In tools.h muß "#ifndef MAPLE_Mini" auskommentiert werden
//#ifndef MAPLE_Mini
#include <EEPROM.h>
//#endif
was ergibt ein
ls -l /dev/serial/by-id
~> ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 20. Mai 21:28 usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_498F386E3230-if00 -> ../../ttyACM0
Das hier:
lrwxrwxrwx 1 root root 13 May 20 21:36 usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_6565BF823332-if00 -> ../../ttyACM0
Hast du einen Tipp, wie ich das noch debuggen kann? Normalerweise würde ich in PIO oder Arduino IDE nun im Monitor mitlesen. Aber beim SIGNALduino habe ich keine Ausgabe. Oder mache ich etwas falsch?
was passiert, wenn Du es in der Arduino IDE mit dem seriellen Monitor versuchst?
Nach dem einstecken des Maple musst Du kurz warten, sonst kommt beim öffnen des seriellen Monitors:
Fehler beim Öffnen des seriellen Ports "/dev/ttyACM0". (Port busy)
Im seriellen Monitors kannst Du dann Befehle eingeben. zB ? oder V
Ist etwas schwierig zu diagnostizieren.
Benutzt Du Dein eigenes Compile.?
Hast Du es mit Ralfs fertigen Binaries probiert.?
Zum Debuggen mit einem Terminal auf die Schnittstelle gehen und schauen, was bei Eingabe von ,,V" mit Return zurückkommt.
In einem Arduino mit "Arduino core support for STM32" habe ich im Monitor doch plötzlich eine Ausgabe. Eigentlich hatte ich im Monitor bisher noch nie etwas gesehen. Könnte vielleicht daran liegen, dass ich sonst immer mit der Baudrate 115220 geprüft habe.
Watchdog enabled
Reading values from eeprom
CCInit
detect B: Partn=0 Ver=0x18
Starting timerjob
rxB=1
Sende ich ein V ab, so bleibt die Fenster stehen. Ich kann den Monitor nicht mehr mit X beenden. Die Ausgabe im Fenster verändert sich nicht.
Nach dem Einstecken des Maples in meinem Windows-System habe ich ein COM13 mit der Bezeichnung "STM Serial".
Andere Treiber habe ich mit Zadig ausprobiert. Doch nun nutze ich die Treiber aus von rogerclarkmelbourne\Arduino_STM32-1.0.0.
USB Device Tree Viewer zeigt mir zum COM-Port diese Informationen an:
=========================== USB Port14 ===========================
Connection Status : 0x01 (Device is connected)
Port Chain : 2-14
========================== Summary =========================
Vendor ID : 0x0483 (STMicroelectronics)
Product ID : 0x5740
USB version : 2.00 -> wrong, device is Full-Speed only
Port maximum Speed : High-Speed
Device maximum Speed : Full-Speed
Device Connection Speed : Full-Speed
Self Powered : yes
Demanded Current : 100 mA
Used Endpoints : 4
======================== USB Device ========================
+++++++++++++++++ Device Information ++++++++++++++++++
Friendly Name : STM Serial (COM13)
Device Description : STM Serial
Device Path 1 : \\?\USB#VID_0483&PID_5740#6565BF823332#{a5dcbf10-6530-11d2-901f-00c04fb951ed} (GUID_DEVINTERFACE_USB_DEVICE)
Device Path 2 : \\?\USB#VID_0483&PID_5740#6565BF823332#{86e0d1e0-8089-11d0-9ce4-08003e301f73} (GUID_DEVINTERFACE_COMPORT)
Kernel Name : \Device\USBPDO-5
Device ID : USB\VID_0483&PID_5740\6565BF823332
Hardware IDs : USB\VID_0483&PID_5740&REV_0000 USB\VID_0483&PID_5740
Driver KeyName : {4d36e978-e325-11ce-bfc1-08002be10318}\0009 (GUID_DEVCLASS_PORTS)
Driver : \SystemRoot\System32\drivers\usbser.sys (Version: 10.0.19041.906 Date: 2021-04-18)
Driver Inf : C:\WINDOWS\inf\oem33.inf
Legacy BusType : PNPBus
Class : Ports
Class GUID : {4d36e978-e325-11ce-bfc1-08002be10318} (GUID_DEVCLASS_PORTS)
Service : usbser
Enumerator : USB
Location Info : Port_#0014.Hub_#0003
Location IDs : PCIROOT(0)#PCI(1400)#USBROOT(0)#USB(14), ACPI(_SB_)#ACPI(PCI0)#ACPI(XHC_)#ACPI(RHUB)#ACPI(HS14)
Container ID : {a21d4e5a-4c90-5981-9f27-76046bd6f170}
Manufacturer Info : STMicroelectronics
Capabilities : 0x94 (Removable, UniqueID, SurpriseRemovalOK)
Status : 0x0180600A (DN_DRIVER_LOADED, DN_STARTED, DN_DISABLEABLE, DN_REMOVABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER)
Problem Code : 0
HcDisableSelectiveSuspend: 0
EnableSelectiveSuspend : 0
SelectiveSuspendEnabled : 0
EnhancedPowerMgmtEnabled : 0
IdleInWorkingState : 0
WakeFromSleepState : 0
Power State : D0 (supported: D0, D3, wake from D0)
COM-Port : COM13 (\Device\USBSER000)
+++++++++++++++++ Registry USB Flags +++++++++++++++++
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\048357400000
osvc : REG_BINARY 00 00
---------------- Connection Information ---------------
Connection Index : 0x0E (Port 14)
Connection Status : 0x01 (DeviceConnected)
Current Config Value : 0x01 (Configuration 1)
Device Address : 0x10 (16)
Is Hub : 0x00 (no)
Device Bus Speed : 0x01 (Full-Speed)
Number Of Open Pipes : 0x03 (3 pipes to data endpoints)
Pipe[0] : EndpointID=3 Direction=IN ScheduleOffset=0 Type=Interrupt
Pipe[1] : EndpointID=1 Direction=OUT ScheduleOffset=0 Type=Bulk
Pipe[2] : EndpointID=2 Direction=IN ScheduleOffset=0 Type=Bulk
Data (HexDump) : 0E 00 00 00 12 01 00 02 02 02 00 40 83 04 40 57 ...........@..@W
00 00 01 02 03 01 01 01 00 10 00 03 00 00 00 01 ................
00 00 00 07 05 83 03 08 00 10 00 00 00 00 07 05 ................
01 02 40 00 00 00 00 00 00 07 05 82 02 40 00 00 ..@..........@..
00 00 00 00 ....
--------------- Connection Information V2 -------------
Connection Index : 0x0E (14)
Length : 0x10 (16 bytes)
SupportedUsbProtocols : 0x03
Usb110 : 1 (yes, port supports USB 1.1)
Usb200 : 1 (yes, port supports USB 2.0)
Usb300 : 0 (no, port not supports USB 3.0)
ReservedMBZ : 0x00
Flags : 0x00
DevIsOpAtSsOrHigher : 0 (Device is not operating at SuperSpeed or higher)
DevIsSsCapOrHigher : 0 (Device is not SuperSpeed capable or higher)
DevIsOpAtSsPlusOrHigher : 0 (Device is not operating at SuperSpeedPlus or higher)
DevIsSsPlusCapOrHigher : 0 (Device is not SuperSpeedPlus capable or higher)
ReservedMBZ : 0x00
Data (HexDump) : 0E 00 00 00 10 00 00 00 03 00 00 00 00 00 00 00 ................
---------------------- Device Descriptor ----------------------
bLength : 0x12 (18 bytes)
bDescriptorType : 0x01 (Device Descriptor)
bcdUSB : 0x200 (USB Version 2.00) -> wrong, device is Full-Speed only
bDeviceClass : 0x02 (Communications and CDC Control)
bDeviceSubClass : 0x02
bDeviceProtocol : 0x00 (No class specific protocol required)
bMaxPacketSize0 : 0x40 (64 bytes)
idVendor : 0x0483 (STMicroelectronics)
idProduct : 0x5740
bcdDevice : 0x0000
iManufacturer : 0x01 (String Descriptor 1)
Language 0x0409 : "STMicroelectronics°"
iProduct : 0x02 (String Descriptor 2)
Language 0x0409 : "MAPLEMINI_F103CB CDC in FS Mode°"
iSerialNumber : 0x03 (String Descriptor 3)
Language 0x0409 : "6565BF823332°"
bNumConfigurations : 0x01 (1 Configuration)
Data (HexDump) : 12 01 00 02 02 02 00 40 83 04 40 57 00 00 01 02 .......@..@W....
03 01 ..
------------------ Configuration Descriptor -------------------
bLength : 0x09 (9 bytes)
bDescriptorType : 0x02 (Configuration Descriptor)
wTotalLength : 0x0043 (67 bytes)
bNumInterfaces : 0x02 (2 Interfaces)
bConfigurationValue : 0x01 (Configuration 1)
iConfiguration : 0x00 (No String Descriptor)
bmAttributes : 0xC0
D7: Reserved, set 1 : 0x01
D6: Self Powered : 0x01 (yes)
D5: Remote Wakeup : 0x00 (no)
D4..0: Reserved, set 0 : 0x00
MaxPower : 0x32 (100 mA)
Data (HexDump) : 09 02 43 00 02 01 00 C0 32 09 04 00 00 01 02 02 ..C.....2.......
00 00 05 24 00 10 01 05 24 01 00 01 04 24 02 02 ...$....$....$..
05 24 06 00 01 07 05 83 03 08 00 10 09 04 01 00 .$..............
02 0A 00 00 00 07 05 01 02 40 00 00 07 05 82 02 .........@......
40 00 00 @..
---------------- Interface Descriptor -----------------
bLength : 0x09 (9 bytes)
bDescriptorType : 0x04 (Interface Descriptor)
bInterfaceNumber : 0x00
bAlternateSetting : 0x00
bNumEndpoints : 0x01 (1 Endpoint)
bInterfaceClass : 0x02 (Communications and CDC Control)
bInterfaceSubClass : 0x02 (Abstract Control Model)
bInterfaceProtocol : 0x00 (No class specific protocol required)
iInterface : 0x00 (No String Descriptor)
Data (HexDump) : 09 04 00 00 01 02 02 00 00 .........
-------------- CDC Interface Descriptor ---------------
bFunctionLength : 0x05 (5 bytes)
bDescriptorType : 0x24 (Interface)
bDescriptorSubType : 0x00 (Header Functional Descriptor)
bcdCDC : 0x110 (CDC Version 1.10)
Data (HexDump) : 05 24 00 10 01 .$...
-------------- CDC Interface Descriptor ---------------
bFunctionLength : 0x05 (5 bytes)
bDescriptorType : 0x24 (Interface)
bDescriptorSubType : 0x01 (Call Management Functional Descriptor)
bmCapabilities : 0x00
D7..2 : 0x00 (Reserved)
D1 : 0x00 (sends/receives call management information only over the Communication Class interface)
D0 : 0x00 (does not handle call management itself)
bDataInterface : 0x01
Data (HexDump) : 05 24 01 00 01 .$...
-------------- CDC Interface Descriptor ---------------
bFunctionLength : 0x04 (4 bytes)
bDescriptorType : 0x24 (Interface)
bDescriptorSubType : 0x02 (Abstract Control Management Functional Descriptor)
bmCapabilities : 0x02
D7..4 : 0x00 (Reserved)
D3 : 0x00 (not supports the notification Network_Connection)
D2 : 0x00 (not supports the request Send_Break)
D1 : 0x01 (supports the request combination of Set_Line_Coding, Set_Control_Line_State, Get_Line_Coding, and the notification Serial_State)
D0 : 0x00 (not supports the request combination of Set_Comm_Feature, Clear_Comm_Feature, and Get_Comm_Feature)
Data (HexDump) : 04 24 02 02 .$..
-------------- CDC Interface Descriptor ---------------
bFunctionLength : 0x05 (5 bytes)
bDescriptorType : 0x24 (Interface)
bDescriptorSubType : 0x06 (Union Functional Descriptor)
bControlInterface : 0x00
bSubordinateInterface[0] : 0x01
Data (HexDump) : 05 24 06 00 01 .$...
----------------- Endpoint Descriptor -----------------
bLength : 0x07 (7 bytes)
bDescriptorType : 0x05 (Endpoint Descriptor)
bEndpointAddress : 0x83 (Direction=IN EndpointID=3)
bmAttributes : 0x03 (TransferType=Interrupt)
wMaxPacketSize : 0x0008 (8 bytes)
bInterval : 0x10 (16 ms)
Data (HexDump) : 07 05 83 03 08 00 10 .......
---------------- Interface Descriptor -----------------
bLength : 0x09 (9 bytes)
bDescriptorType : 0x04 (Interface Descriptor)
bInterfaceNumber : 0x01
bAlternateSetting : 0x00
bNumEndpoints : 0x02 (2 Endpoints)
bInterfaceClass : 0x0A (CDC-Data)
bInterfaceSubClass : 0x00
bInterfaceProtocol : 0x00
iInterface : 0x00 (No String Descriptor)
Data (HexDump) : 09 04 01 00 02 0A 00 00 00 .........
----------------- Endpoint Descriptor -----------------
bLength : 0x07 (7 bytes)
bDescriptorType : 0x05 (Endpoint Descriptor)
bEndpointAddress : 0x01 (Direction=OUT EndpointID=1)
bmAttributes : 0x02 (TransferType=Bulk)
wMaxPacketSize : 0x0040 (64 bytes)
bInterval : 0x00 (ignored)
Data (HexDump) : 07 05 01 02 40 00 00 ....@..
----------------- Endpoint Descriptor -----------------
bLength : 0x07 (7 bytes)
bDescriptorType : 0x05 (Endpoint Descriptor)
bEndpointAddress : 0x82 (Direction=IN EndpointID=2)
bmAttributes : 0x02 (TransferType=Bulk)
wMaxPacketSize : 0x0040 (64 bytes)
bInterval : 0x00 (ignored)
Data (HexDump) : 07 05 82 02 40 00 00 ....@..
----------------- Device Qualifier Descriptor -----------------
Error : ERROR_GEN_FAILURE
-------------------- String Descriptors -------------------
------ String Descriptor 0 ------
bLength : 0x04 (4 bytes)
bDescriptorType : 0x03 (String Descriptor)
Language ID[0] : 0x0409 (English - United States)
Data (HexDump) : 04 03 09 04 ....
------ String Descriptor 1 ------
bLength : 0x26 (38 bytes)
bDescriptorType : 0x03 (String Descriptor)
Language 0x0409 : "STMicroelectronics°" *!*ERROR contains 1 NULL character
Data (HexDump) : 26 03 53 00 54 00 4D 00 69 00 63 00 72 00 6F 00 &.S.T.M.i.c.r.o.
65 00 6C 00 65 00 63 00 74 00 72 00 6F 00 6E 00 e.l.e.c.t.r.o.n.
69 00 63 00 73 00 i.c.s.
------ String Descriptor 2 ------
bLength : 0x40 (64 bytes)
bDescriptorType : 0x03 (String Descriptor)
Language 0x0409 : "MAPLEMINI_F103CB CDC in FS Mode°" *!*ERROR contains 1 NULL character
Data (HexDump) : 40 03 4D 00 41 00 50 00 4C 00 45 00 4D 00 49 00 @.M.A.P.L.E.M.I.
4E 00 49 00 5F 00 46 00 31 00 30 00 33 00 43 00 N.I._.F.1.0.3.C.
42 00 20 00 43 00 44 00 43 00 20 00 69 00 6E 00 B. .C.D.C. .i.n.
20 00 46 00 53 00 20 00 4D 00 6F 00 64 00 65 00 .F.S. .M.o.d.e.
------ String Descriptor 3 ------
bLength : 0x1A (26 bytes)
bDescriptorType : 0x03 (String Descriptor)
Language 0x0409 : "6565BF823332°" *!*ERROR contains 1 NULL character
Data (HexDump) : 1A 03 36 00 35 00 36 00 35 00 42 00 46 00 38 00 ..6.5.6.5.B.F.8.
32 00 33 00 33 00 33 00 32 00 2.3.3.3.2.
Zitat von: juergs am 20 Mai 2021, 21:56:39
Benutzt Du Dein eigenes Compile.?
Hast Du es mit Ralfs fertigen Binaries probiert.?
Ich nutze die Binaries von Ralf.
Primär: https://github.com/Ralf9/SIGNALDuino/releases/tag/V4.1.2-dev210205 (Maple_cul_USB_412dev210205.bin)
Aber auch schon diese ausprobiert: https://github.com/Ralf9/SIGNALDuino/releases/tag/V4.1.1-dev200627 (Maple_cul_USB_411dev200627.bin)
Hast Du den Maple in FHEM deaktiviert?
FHEM und der Serielle Monitor funktioniert nicht gleichzeitig
Bitrate "115220" ? => sollte 115200 sein. Tippfehler?
Dies Ausgabe ist aber OK!
ZitatWatchdog enabled
Reading values from eeprom
CCInit
detect A: Partn=0 Ver=0x14
detect B: Partn=0 Ver=0x14
detect C: Partn=0 Ver=0x14
detect D: Partn=0 Ver=0x04
Starting timerjob
rxA=1 rxB=1
.MU;P0=-15870;P1=4095;P2=-854;P3=-4866;P4=884;P5=3097;P6=1573;CP=4;R=216;D=0121343534353535353534343434353434343534343535343534343536;e;.
.MU;P0=652;P1=-4868;P2=3099;P3=-31009;P4=4071;P5=-885;P6=906;CP=6;R=220;D=0121234541612161212121212161616161216161612161612121612161612121212121212;e;.
.MU;P0=-32001;P1=4087;P2=-858;P3=-4843;P4=871;P5=3088;CP=4;R=217;D=01213435343535353535343434343534343435343435353435343434;e;.
.MU;P0=2297;P1=-4899;P2=3107;P3=-31058;P4=4049;P5=-919;P6=894;CP=2;R=219;D=0121212121212345416121612121212121616161610;e;.
Jetzt nur nocht die Radios aktivieren:
https://forum.fhem.de/index.php/topic,106278.msg1141506.html#msg1141506
Dann werden wie oben ggf. Telegramme empfangen... :)
Zitat von: Ralf9 am 20 Mai 2021, 22:23:51
Hast Du den Maple in FHEM deaktiviert?
FHEM und der Serielle Monitor funktioniert nicht gleichzeitig
Ich stecke den Maple um. IDE und dfu-util laufen auf einem eigenen Windows-System.
Zitat von: juergs am 20 Mai 2021, 22:25:43
Bitrate "115220" ? => sollte 115200 sein. Tippfehler?
Ja. Tippfehler.
Ich habe die Unterstützung vom core 2.0 und dem LAN vom MapleCul (MapleCUN) ins github commited
https://github.com/Ralf9/SIGNALDuino/commit/4048ba2970f8dba5fda0fae741ea916cd76bd303
https://github.com/Ralf9/SIGNALDuino/tree/dev-r412_cc1101
für MapleCul LAN ist in der "compile_config.h" die folgende config notwendig:
//#define MAPLE_SDUINO 1
#define MAPLE_CUL 1
//#define BLACK_BOARD 1 // 1 - USB, 2 - serial USART2 fuer ESP
#define LAN_WIZ 1 // nur fuer USR-ES1 W5500
Ich kann es selber nicht testen da ich kein MapleCUN habe
Liest hier jemand mit der einen MapleCUN hat und das LAN testen kann?
Benötigt Ihr noch ein bin-File?
Sonst muss ich mir selber zum Testen was mit Dupont Kabeln zusammenstecken.
Daß es so mit dem LAN funktionieren könnte, habe ich zufällig in einem Beispiel zur Ethernet Lib gesehen.
Ich habe deine Änderungen gestern getestet und konnte meinen MapleCUN über die Arduino IDE flashen. Aber mehr ist auch nicht passiert. Ich finde Wiznet nicht im LAN. Weder per DHCP noch wenn ich im Sketch die IP statisch vergebe.
Flash-Log:
maple_loader v0.1
Resetting to bootloader via DTR pulse
Reset via USB Serial Failed! Did you select the right serial port?
Searching for DFU device [1EAF:0003]...
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
Found it!
Opening USB Device 0x1eaf:0x0003...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=1451
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
error resetting after download: usb_reset: could not reset device, win error: Ein nicht vorhandenes Ger�t wurde angegeben.
Done!
Resetting USB to switch back to runtime mode
timeout waiting for COM13 serial
Es macht aber sicher Sinn, wenn noch ein weitere Vertreter das testet. Da ich ja auch Probleme mit der MapleCUL-FW hatte, schließe ich allgemeine Probleme bei mir nicht aus.
Hallo Ralf,
habs gerade gesehen.
ZitatLiest hier jemand mit der einen MapleCUN hat und das LAN testen kann?
Würde mal versuchen Testen ..
Musste leider feststellen: Habe nur Ranseyers Signaduino-Mini-Variante mit Netzwerk, nicht die CUN-Variante.
Zitat von: FunkOdyssey am 20 Mai 2021, 22:11:51
Watchdog enabled
Reading values from eeprom
CCInit
detect B: Partn=0 Ver=0x18
Starting timerjob
rxB=1
Kann man an dieser Ausgabe erkennen, ob der Sketch funktioniert?
Ich habe eigentlich vier CC1101-Stamps auf dem Maple. Müsste er diese nicht anzeigen?
Oder erscheinen die erst, wenn man die Radios aktiviert wie von Jürgen vorgeschlagen?Alles im Wiki gefunden.
Ich lese gerade hier: https://forum.fhem.de/index.php/topic,106278.msg1034620.html#msg1034620
Darum werde ich später einen anderen Bootloader ausprobieren. Ich nutze den BL aus dem Thread von locutus.
Ich denke zwar, dass der BL problemlos funktioniert. Trotzdem ich versuche es.
@Ralf:
git clone -b dev-r412_cc1101 --recurse-submodules -c core.symlinks=true https://github.com/Ralf9/SIGNALDuino.gitDownload funktioniert komplett mit der Micro-Api! :)
@FunkOdyssey:
Warum nimmst Du nicht einfacherhalber diesen Bootloader:
https://github.com/Telekatz/MSC-stm32f103-bootloader/releases/download/V1.1/MSCboot_maplemini.bin (https://github.com/Telekatz/MSC-stm32f103-bootloader/releases/download/V1.1/MSCboot_maplemini.bin)
Der ist am Einfachsten: 2mal in einer Sekunde den Reset Button drücken. USB Laufwerk öffnet sich. Bin-Datei reinlegen und gut ist ... ;)
Diese Ausgabe erzeugt schon Dein Maple via serieller Ausgabe und ist die
Standard-Ausgabe des Signalduinos beim Einschalten:
ZitatWatchdog enabled
Reading values from eeprom
CCInit
detect B: Partn=0 Ver=0x18
Starting timerjob
rxB=1
In FHEM oder je nach Gusto: Terminalprogramm Cutecom unter Linux z.B. oder Miniterm auf der Konsole funktioniert.
Egal mit welcher Bitrate, der Maple mit Signalduino-FW passt sich automatisch an.
Ich benutze "meines" mit ein paar nützlichen Features: SerialTerminal (https://github.com/juergs/SerialTerminal/releases/download/V1.0/Release_SerialTerminal_V1.zip) für Windows.
Dort kannst Du Kommandos eingeben:
⦁ Mit V (get Version) bekommt man eine Übersicht über die Module z.B. (R: A1 B0*).
Mit * wird das selektierte cc1101 Modul markiert
Ein "-" hinter dem Modul (A-D) , bedeuted, daß dieses Modul nicht richtig erkannt oder angelegt wurde,
ein "i" bedeuted, daß das Modul zwar korrekt erkannt wurde, aber noch keiner Bank zugeordent wurde.
Wenn ein Modul nicht aufgeführt ist, dann ist es noch deaktiviert.
(Anmerkung: ist bei 4er Versionen der Standard-Fall: Es wird nur A+B angezeigt. mit e EEPROM initialisieren, dann mit CREC + CRED erzeugen bzw. mit CRECW, CRECDW festschreiben.)
Add zum Bild: Die freien Register können z.B. für OOK/FSK mit versch. Bitraten genutzt werden und beliebig umgeschalten bzw. gesetzt werden!
Hier geht's zu FSK: https://forum.fhem.de/index.php/topic,111653.15.html (https://forum.fhem.de/index.php/topic,111653.15.html)
Befehlslisten: https://forum.fhem.de/index.php/topic,106278.msg1141506.html#msg1141506 (https://forum.fhem.de/index.php/topic,106278.msg1141506.html#msg1141506)
https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921 (https://forum.fhem.de/index.php/topic,58396.msg497921.html#msg497921)
Linkliste Signaduino: https://forum.fhem.de/index.php/topic,111653.msg1058901.html#msg1058901 (https://forum.fhem.de/index.php/topic,111653.msg1058901.html#msg1058901)
Beispiel-Konfiguration (mit nicht erreichbarem B-Modul)
ZitatSENT: e
ccFactoryReset done
r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000
SENT: CREBW
detect B: timeout, no cc1101
SENT: bs
Bank__ 0 1 2 3 4 5 6 7 8 9 Radio_ - - - - - - - - - - N_____ 0 0 - - - - - - - - ccmode 0 3 - - - - - - - - 0 - SlowRF
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B-*) - compiled at Feb 5 2021 23:12:37
SENT: ?
? Use one of ?S ? b CE CD CG CR CS CW C eC e P r R S t T V W x XE XQ
SENT: CREA
detect A: Partn=0 Ver=0x14
SENT: CREAW
detect A: Partn=0 Ver=0x14
SENT: bA0CREAW
Bank 0 is already used by radio B
SENT: bA1
set r=A b=1 ccmode=3 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100
SENT: e
ccFactoryReset done
r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000
SENT: CREBW
detect B: timeout, no cc1101
SENT: bs
Bank__ 0 1 2 3 4 5 6 7 8 9 Radio_ - - - - - - - - - - N_____ 0 0 - - - - - - - - ccmode 0 3 - - - - - - - - 0 - SlowRF
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B-*) - compiled at Feb 5 2021 23:12:37
SENT: CREA
detect A: Partn=0 Ver=0x14
SENT: CREAW
detect A: Partn=0 Ver=0x14
SENT: bA0CREAW
Bank 0 is already used by radio B
SENT: bA1
set r=A b=1 ccmode=3 sync=2DD4 ccconf=21656A895C0622F856070018166C436891 boffs=0100
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A1* B-) - compiled at Feb 5 2021 23:12:37
MN;D=CC060D060337099601410000;R=43;
MN;D=9946042F32AAAA00006D0CD3;R=254;
MN;D=9946032F9CAAAA000014F717;R=252;
MN;D=CD0C051C1CFFFFFFFFFFFFFF;R=40;
MN;D=CC060D060337099601410000;R=43;
MN;D=9946042F32AAAA00006D0CD3;R=254;
MN;D=9946032F9CAAAA000014F717;R=252;
MN;D=CD0C051C1CFFFFFFFFFFFFFF;R=40;
Zitat von: Ralf9 am 16 Mai 2021, 00:40:09
Evtl funktioniert es auch ohne diese Anpassungen, wenn in der SIGNALDuino.ino dies
#ifdef MAPLE_CUL
SPIClass SPI_1(28, 29, 30);
Ethernet.init((31);
#endif
vor dieser Zeile eingefügt wird
if (ip[3] != 0) {
https://github.com/Ralf9/SIGNALDuino/blob/5b00e34846327c665186a2393f18b085ef126f62/SIGNALDuino.ino#L344
Hab mal ein LAN Modul auf die SPI-2 verkabelt und getestet, es funktioniert so nicht.
Werde mal ein Testprogramm schreiben.
Inzwischen funktioniert auch beim MapleCUL das LAN (MapleCUN). Hab mir ein MapleCUN zusammengesteckt (siehe Anlage).
In der Anlage sind zwei Bin Files
Maple_cul_LAN_Os_412dev210522
Maple_cul_LAN_O1_412dev210522
Falls das omtimize Fast -O1 nicht stabil funktioniert, kann auch das Os versucht werden.
omtimize Fast -O1 75048 Bytes (57%)
omtimize Smallest -Os 65808 Bytes (50%)
Wer es selber kompilieren will, der benötigt dazu eine gepatchte Ethernetlib
https://github.com/arduino-libraries/Ethernet/pull/134
an dem patch lässt sich auch erkennen, warum ich mich an das LAN für den MapleCUL seither nicht so richtig rangetraut habe:
https://github.com/arduino-libraries/Ethernet/pull/134/commits/37927e7c4efd01d04ca32893329e3f3fa77a9b12
Wenn dies soweit funktioniert, mache ich im github einen neuen branch dev-r420_cc1101
V 4.2.0-dev210514 SIGNALduinoAdv ESP32 (R: B0*)
Mit einem RXB6 Empfänger habs ich schon getested
Gruß Ralf
Ich habe gestern einige Stunden mit dem Maple zugebracht. Alles versucht und den MapleCUL mit der Signalduino-Firmware nicht in Betrieb nehmen können.
Danach habe ich viele nervöse Stunden damit verbracht, den MapleCUL mit a-culfw wieder in den Ursprungszustand zu versetzen.
Ich dachte schon, dass ich nur noch Müll auf dem Tisch liegen habe. Doch per LAN lief a-culfw einwandfrei.
Egal wie und wo ich flashe, ich habe ein Problem mit dem seriellen Monitorzugriff auf den Maple.
Selbst die Anleitung von locutus (https://forum.fhem.de/index.php/topic,80872.0.html), in der man mit screen die Baudrate der UARTs anpassen kann, klappt bei mir nicht. Auf pb0@115200 kam keine Reaktion.
Also habe ich sogar mit a-culfw Probleme. Die vier CC1101 konnte ich aber als CUL und CUN in FHEM (wieder) einbinden.
Auch der MSC-Bootloader hat bei mir Probleme. Das USB-Laufwerk wurde nach 2xReset zwar angezeigt, aber Windows und Linux konnten nicht darauf zugreifen. Der Windows-Explorer ist beim Zugriff eingefroren.
Heute ist ein neuer Tag und ich habe direkt deine Binaries ausprobiert. Ich bin mit Maple_cul_LAN_O1_412dev210522.bin angefangen.
Einfach mit dfu-util drübergeflasht und in FHEM eingebunden. Und es läuft. Und eigentlich wollte ich auch immer ein MapleCUN mit SignalDuino-Firmware haben. Also hast du es besser gemacht, als ich vor Tagen noch gehofft hatte.
Jetzt muss ich mich mit der Konfiguration beschäftigen und Erfahrungen mit der Stabilität sammeln. Aktuell bin ich erst einmal froh über ein opened anstatt eines disconnected.
Vielen Dank, Ralf. Und auch Danke an Jürgen.
Nachtrag: Du musst in deinem Module das hardware-Attribut dann noch erweitern auf Maple_cul_LAN. :D
so wie's aussieht ist im core 2.0.0 noch ein Bug.
Aufgefallen ist es mir als ich diesen raw Befehl senden wollte:
CW0001,012E,0246,0306,042D,05D4,06FF,07C0,0802,0D21,0E65,0FE8,1088,114C,1202,1322,14F8,1551,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D07,3E04,4042,4172,4265,4373,4473,4535,4631,4700
da gabs dann immer ein reset vom maple.
Wenn ich am Ende die letzten 5 Zeichen ",4700" entferne, dann ist es ok.
Habe mir einen Testsketch geschrieben
String cmdstring = "";
bool command_available=false;
void setup() {
cmdstring.reserve(600);
Serial.begin(115200);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB
}
}
void loop() {
if (command_available == true) {
command_available=false;
Serial.println(cmdstring.length());
Serial.println(cmdstring);
if (!command_available) {cmdstring = "";}
}
}
void serialEvent()
{
while (Serial.available())
{
char inChar = (char)Serial.read();
switch(inChar)
{
case '\n':
case '\r':
case '\0':
command_available=true;
break;
default:
cmdstring += inChar;
}
}
}
Mit 191 Zeichen funktioniert es noch:
191
123456789z123456789z223456789z323456789z423456789z523456789z623456789z723456789z823456789z923456789z023456789z123456789z223456789z323456789z423456789z523456789z623456789z723456789z823456789z9
Mit 192 Zeichen macht der Maple einen reset
123456789z123456789z223456789z323456789z423456789z523456789z623456789z723456789z823456789z923456789z023456789z123456789z223456789z323456789z423456789z523456789z623456789z723456789z823456789z92
Gruß Ralf
Zwischenstand von mir:
Stabile Uptime von 6 Tagen.
Keine Abbrüche beim MapleCUN mit Signalduino.
Hallo Ralf,
in meinem STM32-Core
Zitat%LOCALAPPDATA%\Arduino15\packages\STM32\hardware\stm32\1.9.0\cores\arduino\HardwareSerial.h
ist in HardwareSerial.h folgendes definiert (http://shelvin.de/arduino-serial-buffer-size-aendern/):
#ifndef HardwareSerial_h
#define HardwareSerial_h
#include <inttypes.h>
#include "Stream.h"
#include "uart.h"
// Define constants and variables for buffering incoming serial data. We're
// using a ring buffer (I think), in which head is the index of the location
// to which to write the next incoming character and tail is the index of the
// location from which to read.
// NOTE: a "power of 2" buffer size is reccomended to dramatically
// optimize all the modulo operations for ring buffers.
// WARNING: When buffer sizes are increased to > 256, the buffer index
// variables are automatically increased in size, but the extra
// atomicity guards needed for that are not implemented. This will
// often work, but occasionally a race condition can occur that makes
// Serial behave erratically. See https://github.com/arduino/Arduino/issues/2405
#if !defined(SERIAL_TX_BUFFER_SIZE)
#define SERIAL_TX_BUFFER_SIZE 64
#endif
#if !defined(SERIAL_RX_BUFFER_SIZE)
#define SERIAL_RX_BUFFER_SIZE 64
#endif
#if (SERIAL_TX_BUFFER_SIZE>256)
typedef uint16_t tx_buffer_index_t;
#else
typedef uint8_t tx_buffer_index_t;
#endif
#if (SERIAL_RX_BUFFER_SIZE>256)
typedef uint16_t rx_buffer_index_t;
#else
typedef uint8_t rx_buffer_index_t;
#endifHier ist der Puffer noch kleiner... und die Bitrate von 115200 "überrennt" möglicherweise den Puffer. (= race condition).
https://github.com/arduino/ArduinoCore-avr/issues/177 (https://github.com/arduino/ArduinoCore-avr/issues/177)
Dann müsste man
SERIAL_RX_BUFFER_SIZE + SERIAL_TX_BUFFER_SIZE (im eigenen Code) größer definieren.
dies ist erst seit dem core 2.0.0, im core 1.9.0 oder mit dem Arduino nano kann ich problemlos deutlich mehr als 200 Zeichen senden
Evtl. eine Issue (https://github.com/stm32duino/Arduino_Core_STM32/issues) dafür aufmachen?
https://www.stm32duino.com/viewtopic.php?f=62&t=1096
es gibt dafür schon ein issue
https://github.com/stm32duino/Arduino_Core_STM32/issues/1399
Habe es unter VSCode, Platformio und dem MSC-Bootloader auch probiert.
Bei 191 zeichen ist Schluß, allerdings weder Reset noch USB wegnehmen funktioniert dann noch.
Muss den Maple praktisch neu mit STLINK programmieren, dass es wieder funktioniert.
Krasser Fehler!
Zitat[env:maple_mini]
; all options for MAPLE_Mini
; extra_scripts = pre:custom_hwids.py ; to write USB PID for device | needed to right reconnected
; platform = ststm32 ; Stable version
platform = https://github.com/platformio/platform-ststm32.git ; Development version V13 (!)
board = maple_mini_origin
board_build.mcu = stm32f103cbt6 ; https://docs.platformio.org/en/latest/projectconf/section_env_platform.html#board-build-mcu
board_build.core = STM32Duino ; https://docs.platformio.org/en/latest/platforms/ststm32.html#configuration
framework = arduino
build_flags=
-D PIO_FRAMEWORK_ARDUINO_ENABLE_CDC ; CDC (generic Serial supersede U(S)ART)
-D USBCON ; !! work only with maple_mini bootloader v1.0 !!
-D USBD_PID=0x0004 ; Device
-D USBD_VID=0x0483 ; Serielles USB-Geraet (COMxx)
-D USB_MANUFACTURER="STMicroelectronics"
-D USB_PRODUCT="\"Maple\""
; Windows, example
; debug_port = COM4
; monitor_port = COM4
;upload_port = COM18
upload_protocol = stlink
;upload_protocol = dfu
Hallo Reinhard,
hast Du bei Deinem Lacrosse Sensor noch Aussetzer?
@nagelreo hat ein ähliches Problem
Zitat von: nagelreo am 24 April 2021, 17:17:06
Die sporadischen "Aussetzer" beim Empfang vom TFA 30.3155.WD treten immer noch auf, in den letzten 3 Wochen 14 mal.
Ich hab mir dafür was überlegt
Dafür müsste ich wissen, ob es reicht, wenn mit dem folgenden beiden raw-Befehlen der Empfang kurz deaktiviert wird
get sduino raw WS36
Rückmeldung: cmdStrobeReg 36 chipStatus 1 delay2 0get sduino raw WS34
Rückmeldung: cmdStrobeReg 34 chipStatus 0 delay2 1mit "get sduino raw WS3D" kann der cc101 Status abgefragt werden
0 - IDLE
1 - Empfang
Ich würde dann einen weitere Konfigvariable einbauen z.B. ccRXTimeout (1 wären dann 10 Min und 144 wären 1 Tag)
Die Variable wird dann alle 10 Min runtergezählt und bei 0 wird dann WS36 und WS34 ausgeführt.
Bei jeder empfangenen Nachricht wird die Variable wieder auf den Wert von ccRXTimeout gesetzt.
Gruß Ralf
Guten Morgen Ralf,
schön von dir zu hören :) Ich habe hier keine weiteren Aussetzer beobachtet. Zumindest ist mir nichts mehr aufgefallen. Allerdings bin ich weiterhin oftmals mit kleiner -90 am Empfangslimit. Da fehlen dann schon Mal ein paar Stunden Daten von dem ein oder anderen Modul.
Gruß Reinhard
Hallo Ralf,
habe dies Version
Maple_cul_USB_412dev210205.bin auf Ranseyers 4fach-MapleCUL installiert.
Neuer MapleMini mit MSC-Bootloader mit dieser letzten Version: https://github.com/Ralf9/SIGNALDuino/releases/tag/V4.1.2-dev210205 (https://github.com/Ralf9/SIGNALDuino/releases/tag/V4.1.2-dev210205)
Hier mein Init über ein Serial-Tool:
ZitatWatchdog enabled
Reading values from eeprom
CCInit
detect B: Partn=0 Ver=0x14
Starting timerjob
rxB=1
MS;P1=-2076;P2=552;P3=-4119;P4=-9091;P5=412;D=2423212153532121212121232321212121212121232121212123232123212123232121232123;CP=2;SP=4;R=3;e;b72;m0;
MS;P1=-2076;P2=552;P3=-4119;P4=-9091;P5=412;P6=32001;P7=-3069;D=2423515153232121212121232321212121212121232121212123232123212123232121236723;CP=2;SP=4;R=3;e;m1;
MS;P1=-2076;P2=552;P3=-4119;P4=-9091;P5=412;P6=32001;P7=-3069;D=2423212123232121212121232321212121212121232121212123232123212123232121232123;CP=2;SP=4;R=3;e;m2;
MS;P1=-2076;P2=552;P3=-4119;P4=-9091;P5=412;P6=32001;P7=-3069;D=2423212123232121212121232321515151212121232121212123232123212123232121232123;CP=2;SP=4;R=3;e;m3;
MU;P0=90;P1=-1039;P2=498;P4=-1947;P5=-4004;CP=2;R=219;D=01212121212424212421212124242424242421212124242421242521212121212424212421212121212124242124212121242424242424212121242424212424;e;
MS;P0=-2059;P1=432;P2=-1043;P3=-4017;D=13121212121210101210121212121212101012101212121010101010101212121010101210;CP=1;SP=3;R=219;e;b73;m0;
MS;P0=-2059;P1=432;P2=-1043;P3=-4017;D=13121212121210101210121212121212101012101212121010101010101212121010101210;CP=1;SP=3;R=219;Q;e;m1;
MS;P0=-2059;P1=432;P2=-1043;P3=-4017;P5=178;D=131212121212101012101212121212121010121012121210101010101012121210101012105;CP=1;SP=3;R=219;e;m2;
MU;P0=226;P1=-3993;P2=473;P3=-1073;P4=-2015;P5=113;P6=-114;CP=2;R=219;D=0123232323232424232423232323232324242324232323242424242424232323242356;e;
MU;P0=296;P1=-1022;P2=471;P3=-2007;P4=-1359;CP=2;R=218;D=01212323212321212121212123232123212121232323232323212121232324;e;
MS;P1=464;P2=-1052;P3=-2017;P4=-4036;D=14121212121213131213121212121212131312131212121313131313131212121313131213;CP=1;SP=4;R=218;e;b5;m0;
MS;P1=464;P2=-1052;P3=-2017;P4=-4036;D=1412121212121313121312121212121213131213121212131313131313121212131313121;CP=1;SP=4;R=218;Q;e;m1;
MS;P1=223;P2=-5524;P3=109;P4=-2301;P5=149;P6=-1397;D=123454141654141654163616141616341636141436141432;CP=1;SP=2;R=218;e;
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B0*) - compiled at Feb 6 2021 00:26:38
MU;P0=-25693;P1=1304;P2=-1071;P3=498;CP=3;R=224;D=01212121232123212121212121212121212321212121212123232323232323232121212123232323232123230121212123212321212121212121212121232121212121212323232323232323212121212323232323212323;e;
MC;LL=-1081;LH=872;SL=-574;SH=396;D=A8DDF41ACE7DF7916AB5E94;C=487;L=90;R=220;s1;b1;
MC;LL=-1064;LH=868;SL=-604;SH=387;D=A8DDF41AEE7DF7916AB4FE4;C=487;L=90;R=221;s1;b1;
MC;LL=-1079;LH=858;SL=-590;SH=390;D=A0D6F3EFBC8B55AB22;C=486;L=71;R=220;s3;b2;
MS;P2=-3952;P3=464;P4=-989;P5=-1994;D=32343434353434353435343434343434353435343434343534353535353434343434343434;CP=3;SP=2;R=221;e;b75;m0;
MS;P2=-3952;P3=464;P4=-989;P5=-1994;D=32343434353434353435343434343434353435343434343534353535353434343434343434;CP=3;SP=2;R=221;Q;e;m1;
MS;P2=-3952;P3=464;P4=-989;P5=-1994;D=32343434353434353435343434343434353435343434343534353535353434343434343434;CP=3;SP=2;R=221;Q;e;m2;
MS;P2=-3952;P3=464;P4=-989;P5=-1994;D=32343434353434353435343434343434353435343434343534353535353434343434343434;CP=3;SP=2;R=221;Q;e;m3;
MU;P0=226;P1=-2007;P2=440;P3=-992;CP=2;R=220;D=01232123232323232321232123232323212321212121232323232323;e;
MU;P0=282;P1=-1010;P2=446;P3=-3960;P4=187;P5=-91;P6=136;P7=-2097;CP=2;R=220;D=0121212123210145612721212721072121212121;e;
MU;P0=-1047;P1=448;P2=-2009;P3=307;P4=179;P5=-4217;CP=1;R=216;D=01210101030121012121232101030101040301035;e;
MU;P0=112;P1=-1998;P2=448;P3=-1026;P4=315;CP=2;R=219;D=0123232323232321432123232323212321212121230;e;
MU;P0=91;P1=-1023;P2=411;P3=-1991;P5=-4008;CP=2;R=219;D=0121232123232323212121212121212125212121;e;
MU;P0=-139;P1=126;P2=-2037;P3=419;P4=-1007;CP=3;R=217;D=012343432343234343434343432343234343434323432321;e;
SENT: eA
ccFactoryReset done
r=B b=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000
MU;P0=-30236;P1=4164;P2=-789;P3=-4827;P4=948;P5=3138;P6=220;CP=4;R=217;D=0121343534353535353534343434353434343435353535353435353434343536;e;
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B0*) - compiled at Feb 6 2021 00:26:38
MU;P0=234;P1=460;P2=1243;P3=-28323;P4=-21967;P5=-342;P6=-1101;P7=-202;CP=1;R=233;D=706162616261626161626262626162616262616161626262626162616262626131405;p;
MU;P0=-1103;P1=454;P2=-222;P3=-112;P4=184;P5=1244;CP=1;R=235;D=01213401050105010501010505050501050105050101010505050501050105050501;e;
MU;P0=-117;P1=225;P2=-1105;P3=456;P4=1247;P5=-26177;P6=302;CP=3;R=232;D=0123242423242324232423242324242324242324242424242324242324242323232424565;e;
MU;P0=-314;P1=243;P2=-1112;P3=1233;P4=452;CP=3;R=232;D=01012123242324232423232423232423232323232423232423232424242323;e;
SENT: e
ccFactoryReset done
r=B b=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B0*) - compiled at Feb 6 2021 00:26:38
MS;P1=539;P2=-9105;P3=-4138;P4=-2082;D=1213141413131414141414131314141414141414131414141413131413141413131414131413;CP=1;SP=2;R=18;e;m0;
MS;P0=-6325;P1=539;P2=-9105;P3=-4138;P4=-2082;P5=405;D=12501413131414141414131314141414141414131414141413131413141413131414131413;CP=1;SP=2;R=18;e;m1;
MS;P1=539;P2=-9105;P3=-4138;P4=-2082;P5=405;P6=230;D=12135363531414141414131314141414141414131414141413131413141413131414131413;CP=1;SP=2;R=18;e;m2;
MS;P1=539;P2=-9105;P3=-4138;P4=-2082;P5=405;P6=230;D=1213141413531414141414131314141414141414131414141413131413141413131414131413;CP=1;SP=2;R=18;e;m3;
MS;P1=-2081;P2=521;P3=-4143;P4=-9106;P5=-6856;D=24252123232121212121232321212121212121232121212123232123212123232121232123;CP=2;SP=4;R=19;e;b72;m0;
MU;P0=-7289;P1=532;P2=-2089;P3=-4135;CP=1;R=17;D=0121313121212121213131212121212121213121212121313121312121313121213121;e;
MC;LL=-1068;LH=901;SL=-569;SH=403;D=A8DDF41AC985F7916ACA6C4;C=490;L=90;R=222;s1;b1;
MC;LL=-1059;LH=898;SL=-566;SH=400;D=A8DDF41AE985F7916ACB7B4;C=487;L=90;R=221;s1;b1;
MC;LL=-1059;LH=892;SL=-567;SH=410;D=A8DDF41AD985F7916ACAE14;C=487;L=90;R=222;s1;b1;
SENT: **V
MU;P0=-7893;P1=911;P2=-1509;P3=199;P4=-21198;CP=3;R=73;D=01212121232123212121212123232323212321212123232323212121212121232123232323212121232321214121212123212321212121212323232321232121212323232321212121212123212323232321212123232121412121212321232121212121232323232123212121232323232121212121212321232323232121212323212141212121232123212121212123232323212321212123232323212121212121232123232323212121232321214121212123212321212121212323232321232121212323232321212121212123212323232321212123232121;e;
MU;P0=153;P1=-2031;P2=439;P3=-1050;P4=270;P5=-4050;CP=2;R=218;D=0121212321452323232323212123212323232323232121232123212323212121212123232321212123212523232323232121232123232323234;e;
MU;P0=176;P1=-2018;P2=449;P3=-1056;P4=-4027;CP=2;R=218;D=01212123232321212123212423232323232121230;e;
MU;P0=264;P1=-2030;P2=445;P3=-1058;P4=-4036;CP=2;R=218;D=012323232323232121232123212323212121212103232321212123212423230;e;
MS;P0=424;P1=-2072;P3=-1053;P4=320;P5=-4074;P6=205;D=05034303030301014301030303030303010103016301030301010101010303030101010301;CP=0;SP=5;R=219;e;b40;m0;
MU;P0=90;P1=-1071;P2=432;P3=-2057;P4=241;P5=-4088;P6=117;CP=2;R=219;D=0121212121232321232121212121212323412321232121232323232321212123232321232521216;e;
MU;P0=-1080;P1=415;P2=-2051;P4=204;P5=-112;P6=126;P7=-4088;CP=1;R=216;D=012121012101210101245621212121010101212124012171010101010126;e;
MU;P0=-130;P1=196;P2=-1059;P3=434;P4=-2054;P5=325;P6=-4047;CP=3;R=218;D=01234343454543252323434343234363232323232;e;
MU;P0=-1253;P1=205;P2=-210;P3=132;P4=-2201;P6=96;P7=-3801;CP=1;R=220;D=012341010341412341010301432343467626062141017;e;
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B0*) - compiled at Feb 6 2021 00:26:38
MU;P0=-20227;P1=1330;P2=-1046;P3=530;P4=-28716;CP=3;R=225;D=01212121232123212121212121212121212321212121212123232323232323232121212123232323232123234121212123212321212121212121212121232121212121212323232323232323212121212323232323212323;e;
MU;P0=-269;P1=516;P2=-1002;P3=1512;P4=-1509;CP=1;R=236;D=01232321232123212321212321212121212121212121232321232121412121212121212123212323212121212321232323232321232123212321212321212121212121212121232321232121412121212121212123212323212121212321232323232321232123212321212321212121212121212121232321232121;e;
MU;P0=-16341;P1=4127;P2=-813;P3=-4801;P4=956;P5=3152;CP=4;R=217;D=01213435343535353535343434343534343434353535353534353435353535353535;e;
MU;P0=-31491;P1=4147;P2=-821;P3=-4812;P4=953;P5=3153;CP=4;R=217;D=0121343534353535353534343434353434343435353535353435343535353535353501213435343535353535343434343534343434353535353534353435353535353535;e;
MU;P0=-2745;P1=4116;P2=-837;P3=-4813;P4=957;P5=3166;CP=4;R=217;D=01213435343535353535343434343534343434353535353534353435353535353535;e;
MU;P0=-1543;P1=883;P2=161;P3=-21348;CP=2;R=72;D=010101010102020202010202010102020202010101010101010102020202010101020201023101010102010201010101010202020201020201010202020201010101010101010202020201010102020102310101010201020101010101020202020102020101020202020101010101010101020202020101010202010231010101020102010101010102020202010202010102020202010101010101010102020202010101020201023101010102010201010101010202020201020201010202020201010101010101010202020201010102020102;e;
MU;P0=-1091;P1=449;P2=-111;P3=-156;P4=134;P5=1259;P6=-28320;CP=1;R=237;D=0121340505050105010501010501050505050105010501050561;e;
MU;P0=201;P1=-1092;P2=101;P3=-139;P4=469;P6=1258;CP=4;R=238;D=01234341234341614161416141416141616161614161416141616;e;
MU;P0=1239;P1=-28088;P2=271;P3=-1105;P4=459;P5=-178;P7=-90;CP=4;R=238;D=34543474343030343030303030343030343030343434303012;e;
MU;P0=-1544;P1=162;P2=886;P4=-21335;CP=1;R=72;D=010101020101010201020102020202020102010201020102020202010102014202020201020102010101020101010102010101020102010202020202010201020102010202020201010201420202020102010201010102010101010201010102010201020202020201020102010201020202020101020142020202010201020101010201010101020101010201020102020202020102010201020102020202010102014202020201020102010101020101010102010101020102010202020202010201020102010202020201010201;e;
SENT: XQ
rxB=0
SENT: bS
Unsupported command
SENT: br
r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000*
SENT: CREA0
detect A: Partn=0 Ver=0x04
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: Ai B0*) - compiled at Feb 6 2021 00:26:38
SENT: CREC2
detect C: Partn=0 Ver=0x04
SENT: CRED3
detect D: Partn=0 Ver=0x04
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: Ai B0* Ci Di) - compiled at Feb 6 2021 00:26:38
SENT: CREA0W
detect A: Partn=0 Ver=0x04
SENT: CREB1W
detect B: Partn=0 Ver=0x14
SENT: CREC2W
detect C: Partn=0 Ver=0x04
SENT: CRED3W
detect D: Partn=0 Ver=0x04
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: Ai Bi* Ci Di) - compiled at Feb 6 2021 00:26:38
SENT: CREB1W
detect B: Partn=0 Ver=0x14
SENT: XE
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: Ai Bi* Ci Di) - compiled at Feb 6 2021 00:26:38
SENT: bA
Error! radio has no bank
SENT: bA0W
write set r=A b=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000
SENT: bA
switch to radio A
MU;P0=-826;P1=1533;P2=-1496;P3=-4994;P4=5506;P5=-2959;P6=2901;P7=2127;CP=1;R=223;D=12121212121212121212121343121212151212126215701;p;
MU;P0=3066;P1=-1068;P2=577;P3=1408;P4=-300;P6=-687;CP=2;R=227;D=01210134043101213631212121313131313121213121313;e;
MU;P0=3813;P1=1489;P2=-1039;P3=570;P4=-217;P5=-773;P6=1997;P7=-396;CP=1;R=228;D=1212121232123212121212121212321232323214351212670412;p;
MU;P0=-1970;P1=115;P2=-3943;P3=482;P4=-960;CP=3;R=221;D=01234343430343430343034343434343430343034343430343030303030343;e;
MS;P2=-974;P3=486;P4=-3931;P5=-1976;D=34323232353232353235323232323232353235323232353235353535353232323232323232;CP=3;SP=4;R=222;e;b13;m0;
MS;P2=-974;P3=486;P4=-3931;P5=-1976;D=34323232353232353235323232323232353235323232353235353535353232323232323232;CP=3;SP=4;R=222;Q;e;m1;
MS;P2=-974;P3=486;P4=-3931;P5=-1976;D=34323232353232353235323232323232353235323232353235353535353232323232323232;CP=3;SP=4;R=222;Q;e;m2;
MS;P2=-974;P3=486;P4=-3931;P5=-1976;D=34323232353232353235323232323232353235323232353235353535353232323232323232;CP=3;SP=4;R=222;Q;e;m3;
SENT: CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03,404d,4131,425f,4349,4454,452b,4600
CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03,404d,4131,425f,4349,4454,452b,4600 ok,N=0,ccmode=3
MN;D=9946733FE4AAAA0000196C84;R=230;
MN;D=C8020D066441099900290000;R=70;
MN;D=CC0605026441019800300000;R=71;
SENT: bC
Error! radio has no bank
SENT: bC2W
The bank 2 was not complete initialized, therefore the bank and radio is reseted to sduino defaults (raw e). ccFactoryReset done
SENT: eC
Init eeprom to defaults
detect B: Partn=0 Ver=0x14
SENT: bC2W
radio is not aktive!
SENT: bC
radio is not aktive!
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B0*) - compiled at Feb 6 2021 00:26:38
SENT: e
ccFactoryReset done
r=B b=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000
MU;P0=-32001;P1=4157;P2=-786;P3=-4747;P4=985;P5=3189;P7=1974;CP=5;R=222;D=01213435343535353535343434343534343734353535353534353435353535353535;e;
MU;P0=-31473;P1=4171;P2=-762;P3=-4783;P4=990;P5=3181;CP=4;R=223;D=0121343534353535353534343434353434343435353535353435343535353535353501213435343535353535343434343534343434353535353534353435353535353535;e;
MU;P0=-9684;P1=4163;P2=-767;P3=-4767;P4=991;P5=3191;CP=4;R=226;D=01213435343535353535343434343534343434353535353534353435353535353535;e;
SENT: XQ
rxB=0
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B0*) - compiled at Feb 6 2021 00:26:38
SENT: CREC2W
detect C: Partn=0 Ver=0x04
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B0* Ci) - compiled at Feb 6 2021 00:26:38
SENT: e
ccFactoryReset done
r=B b=0 rx=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B0* Ci) - compiled at Feb 6 2021 00:26:38
SENT: ?S
CSccN= CSccmode= CSmcmbl= CSmscnt= CSfifolimit= CSmaxMuPrintx256= CSmaxMsgSizex256= CSfifolimitA= CSmaxMuPrintx256A= CSmaxMsgSizex256A= CSonlyRXB= CSmaxnumpat= CSmuthreshx256= CSmaxpulse=
Warum geht die Konfiguration (R: Ai Bi* Ci Di) verloren, nachdem ich für Modul A
Mode 1 - IT+ 17.241 kbps (LaCrosse) - ccN=0, ccmode=3konfiguriert habe?
SENT: CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03,404d,4131,425f,4349,4454,452b,4600
( https://forum.fhem.de/index.php/topic,106594.0.html )
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: Ai Bi* Ci Di) - compiled at Feb 6 2021 00:26:38
SENT: bA
Error! radio has no bank
SENT: bA0W
write set r=A b=0 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070090 boffs=0000
SENT: bA
switch to radio A
Bei Deinen raw Befehlen ist mir einiges aufgefallen was nicht geht:
ZitatSENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: Ai B0* Ci Di) - compiled at Feb 6 2021 00:26:38
SENT: CREA0W
Du bringst Da Befehle durcheinnander.
Mit "CREA" wird das Modul aktiviert, es kann damit nicht auch noch gleichzeitig dem Modul eine Bank zugewiesen werden.
Mit "bA1W" wird dann dem Modul A die Bank 1 zugewiesen und gemerkt.
ZitatSENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: Ai Bi* Ci Di) - compiled at Feb 6 2021 00:26:38
SENT: bA
Error! radio has no bank
Du kannst kein Modul auswählen dem noch keine Bank zugeordnet ist
Hallo Ralf,
danke.
Mache heute nochmal einen Anlauf ;)
Die Quellen für die grüne MapleMini-Platinen scheinen wohl versiegt zu sein ...
und diese hier
STM32 Black Pill STM32F411CEU6 100MHz - 512kB Flash (https://www.amazon.ca/CANADUINO-STM32-Black-Genuine-STM32F411CEU6-100MHz/dp/B0844QMB4F)
haben sich als vielleicht mögliche Alternative im Preis verdreifacht ...
/edit:
ZitatStarted!
Watchdog enabled
Init eeprom to defaults
ccFactoryReset done
CCInit
detect B: Partn=0 Ver=0x14
Starting timerjob
rxB=1
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: B0*) - compiled at Feb 6 2021 00:26:38
SENT: CREA
detect A: Partn=0 Ver=0x14
SENT: bA0W
Bank 0 is already used by radio B
SENT: bA1W
The bank 1 was not complete initialized, therefore the bank and radio is reseted to sduino defaults (raw e). ccFactoryReset done
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A1* B0) - compiled at Feb 6 2021 00:26:38
SENT: CREC
detect C: Partn=0 Ver=0x14
SENT: bC2W
The bank 2 was not complete initialized, therefore the bank and radio is reseted to sduino defaults (raw e). ccFactoryReset done
SENT: XQ
rxA=0 rxB=0 rxC=0
SENT: bD3W
radio is not aktive!
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A1 B0 C2*) - compiled at Feb 6 2021 00:26:38
SENT: CRED
detect D: Partn=0 Ver=0x04
SENT: bD3W
The bank 3 was not complete initialized, therefore the bank and radio is reseted to sduino defaults (raw e). ccFactoryReset done
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A1 B0 C2 D3*) - compiled at Feb 6 2021 00:26:38
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A1* B0 C2 D3) - compiled at Feb 6 2021 00:26:38
SENT: CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03,404d,4131,425f,4349,4454,452b,4600
CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03,404d,4131,425f,4349,4454,452b,4600 ok,N=0,ccmode=3
SENT: bC
switch to radio C
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A1 B0 C2* D3) - compiled at Feb 6 2021 00:26:38
SENT: CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03,404d,4132,425f,4349,4454,452b,4600
CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03,404d,4132,425f,4349,4454,452b,4600 ok,N=2,ccmode=3
SENT: bD
switch to radio D
SENT: V
V 4.1.2-dev210205 SIGNALduinoAdv cc1101 (R: A1 B0 C2 D3*) - compiled at Feb 6 2021 00:26:38
SENT: CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03,404d,4132,425f,4349,4454,452b,4600
CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1088,1182,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D02,3E03,404d,4132,425f,4349,4454,452b,4600 ok,N=2,ccmode=3
SENT: br
r=A b=1 rx=0
ccmode=3 sync=2DD4
ccconf=21656A895C0622F856070018166C436891 boffs=0100
r=B b=0 rx=0
ccmode=0 sync=D391
ccconf=10B07157C43023B900070018146C070090 boffs=0000
r=C b=2 rx=0 N=2 ccmode=3 sync=2DD4 ccconf=21656A88820622F856070018166C436891 boffs=0140
r=D b=3 N=2 ccmode=3 sync=2DD4
ccconf=21656A88820622F856070018166C436891 boffs=0180*
SENT: XE
rxA=1 rxB=1 rxC=1 rxD=1
Kaum macht man es richtig (*), schon geht es!
:)
(*)
- Für Ranseyers Board (https://cadlab.io/project/1060/master/circuit/SFctTUFQTEUtTGFyZ2UvVjQuMC9BcmNoaXYvbWFwbGVDVXhfbGFyZ2VfNC4wLTAxMi5zY2g%3D) die CUL-Binary nehmen!
- Den "richtigen" MSC-Bootloader mit STLINK flashen.
- Ein "i" bedeuted, daß das Modul zwar korrekt erkannt wurde, aber noch keiner Bank zugeordent wurde.
Wenn ein Modul nicht aufgeführt ist, dann ist es noch deaktiviert.
[/list]
ZitatDie Quellen für die grüne MapleMini-Platinen schein wohl versiegt zu sein ...
In blau gibt's sie momentan noch ausreichend
Zitat von: Ralf9 am 20 Juni 2021, 11:23:47
In blau gibt's sie momentan noch ausreichend
Hast Du einen Tipp für mich wo ich noch welche bekomme?
Vielen Dank und viele Grüße
Fritz
Einfach bei Amazon, ebay oder aliexpress nach "maple mini stm32" suchen.
Normalerweise ist im Maple Mini ein STM32F103CBT6
Es gibt auch welche mit STM32F103RCBT6, weiß jemand was das R in der Bezeichnung bedeutet?
Gruß Ralf
Ich hätte da was (siehe Anhang) :)
Wobei 4 Buchstaben nicht richtig sein können ???
Gruß Reinhard
Zitat von: Ralf9 am 23 Juni 2021, 19:48:50
Es gibt auch welche mit STM32F103RCBT6, weiß jemand was das R in der Bezeichnung bedeutet?
Ich würde auf Schreibfehler im Amazon Shop tippen, die Boards sehen gleich aus.
Gruß Peter
Hallo Ralf,
wollte mir mal heute die V4.2.0 für meinen MAPLE_SDUINO kompilieren, leider bekomme ich die folgende Fehlermeldung:
In file included from C:\Users\Familie\Documents\Arduino\SIGNALDuino\cc1101.h:11,
from C:\Users\Familie\Documents\Arduino\SIGNALDuino\SIGNALDuino.ino:119:
C:\Users\Familie\Documents\Arduino\libraries\output\src/output.h:37:17: error: #elif with no expression
37 | #elif MAPLE_Mini
| ^
exit status 1
Fehler beim Kompilieren für das Board Generic STM32F1 series.
Arduino IDE ist aktuell, Einstellungen des Boards sollten auch alles passen, waren ja alle okay für die V4.1.2.
Falls du noch Infos brauchst melde dich.
Gruß Markus
P.S.: Kann es sein das in der Datei output.h die Zeile 37 #elif defined(MAPLE_Mini) lauten sollte? Falls ja bekomme ich anschließend folgende Fehler:
In file included from C:\Users\Familie\Documents\Arduino\SIGNALDuino\SIGNALDuino.ino:123:
C:\Users\Familie\Documents\Arduino\libraries\SimpleFIFO\src/SimpleFIFO.h:45:7: error: variable or field 'IRAM_ATTR' declared void
45 | void IRAM_ATTR enqueue(int16_t element ); //add an element
| ^~~~~~~~~
C:\Users\Familie\Documents\Arduino\libraries\SimpleFIFO\src/SimpleFIFO.h:45:7: error: expected ';' at end of member declaration
45 | void IRAM_ATTR enqueue(int16_t element ); //add an element
| ^~~~~~~~~
| ;
C:\Users\Familie\Documents\Arduino\libraries\SimpleFIFO\src/SimpleFIFO.h:45:41: error: ISO C++ forbids declaration of 'enqueue' with no type [-fpermissive]
45 | void IRAM_ATTR enqueue(int16_t element ); //add an element
| ^
C:\Users\Familie\Documents\Arduino\libraries\SimpleFIFO\src/SimpleFIFO.h:64:16: error: expected initializer before 'SimpleFIFO'
64 | void IRAM_ATTR SimpleFIFO::enqueue(int16_t element) {
| ^~~~~~~~~~
C:\Users\Familie\Documents\Arduino\SIGNALDuino\SIGNALDuino.ino: In function 'void setup()':
SIGNALDuino:457:2: error: 'getEthernetConfig' was not declared in this scope
457 | getEthernetConfig(true);
| ^~~~~~~~~~~~~~~~~
C:\Users\Familie\Documents\Arduino\SIGNALDuino\SIGNALDuino.ino: At global scope:
SIGNALDuino:840:16: error: expected constructor, destructor, or type conversion before ';' token
840 | noInterrupts();
| ^
SIGNALDuino:847:2: error: expected unqualified-id before 'if'
847 | if (RXenabledSlowRfA) {
| ^~
SIGNALDuino:864:2: error: expected unqualified-id before 'if'
864 | if (RXenabledSlowRfB) {
| ^~
SIGNALDuino:881:15: error: expected constructor, destructor, or type conversion before '(' token
881 | digitalWrite(PIN_LED, blinkLED);
| ^
SIGNALDuino:882:3: error: 'blinkLED' does not name a type
882 | blinkLED = false;
| ^~~~~~~~
SIGNALDuino:885:14: error: expected constructor, destructor, or type conversion before ';' token
885 | interrupts();
| ^
SIGNALDuino:890:2: error: expected unqualified-id before 'if'
890 | if (cnt0++ == 0) {
| ^~
SIGNALDuino:895:1: error: expected declaration before '}' token
895 | }
| ^
C:\Users\Familie\Documents\Arduino\SIGNALDuino\SIGNALDuino.ino: In function 'void loop()':
SIGNALDuino:928:2: error: 'ethernetLoop' was not declared in this scope; did you mean 'ethernet_h_'?
928 | ethernetLoop();
| ^~~~~~~~~~~~
| ethernet_h_
C:\Users\Familie\Documents\Arduino\SIGNALDuino\SIGNALDuino.ino: In function 'void getEthernetConfig(bool)':
SIGNALDuino:3204:3: error: 'initEthernetConfig' was not declared in this scope; did you mean 'getEthernetConfig'?
3204 | initEthernetConfig();
| ^~~~~~~~~~~~~~~~~~
| getEthernetConfig
exit status 1
'getEthernetConfig' was not declared in this scope
da haben ein paar Sachen noch nicht gepasst, ich habe es gefixt:
https://github.com/Ralf9/SIGNALDuino/tree/dev-r420_cc1101
Bin bei mir beim Arduino_Core_STM32 wieder von 2.0.0 auf die 1.9.0 zurückgegangen.
Bis der Bug in der 2.0.0 (STM32F10xx Serial bus fault on large data) gefixt ist, wird es wahrscheinlich noch etwas dauern
https://github.com/stm32duino/Arduino_Core_STM32/milestone/13
Gruß Ralf
Hallo Ralf,
hab mir mal die gefixte Version runtergeladen, hab aber leider weiterhin Probleme beim kompilieren mit dem MapleMini:
In file included from C:\Users\Familie\Documents\Arduino\libraries\SimpleFIFO\src\SimpleFIFO.cpp:5:
C:\Users\Familie\Documents\Arduino\libraries\SimpleFIFO\src\SimpleFIFO.h:59:28: error: 'FIFO_LENGTH' was not declared in this scope
59 | volatile int16_t rawFifo[FIFO_LENGTH];
| ^~~~~~~~~~~
C:\Users\Familie\Documents\Arduino\libraries\SimpleFIFO\src\SimpleFIFO.h: In member function 'void SimpleFIFO::enqueue(int16_t)':
C:\Users\Familie\Documents\Arduino\libraries\SimpleFIFO\src\SimpleFIFO.h:76:2: error: 'rawFifo' was not declared in this scope
76 | rawFifo[nextIn] = element;
| ^~~~~~~
C:\Users\Familie\Documents\Arduino\libraries\SimpleFIFO\src\SimpleFIFO.h: In member function 'int16_t SimpleFIFO::dequeue()':
C:\Users\Familie\Documents\Arduino\libraries\SimpleFIFO\src\SimpleFIFO.h:84:9: error: 'rawFifo' was not declared in this scope
84 | return rawFifo[nextOut++];
| ^~~~~~~
exit status 1
Fehler beim Kompilieren für das Board Generic STM32F1 series.
Als Info hier meine compile_config.h:
#define MAPLE_SDUINO 1
//#define MAPLE_CUL 1
//#define BLACK_BOARD 1 // 1 - USB, 2 - serial USART2 fuer ESP
//#define SIGNALESP32 1
//#define EVIL_CROW_RF 1
//#define ESP32_SDUINO_TEST 1
#define LAN_WIZ 1 // nur fuer MAPLE_SDUINO mit USR-ES1 W5500
#define LAN_INIT_DHCP 1 // damit wird bei der ersten Inbetriebnahme DHCP verwendet
#define MAPLE_WATCHDOG 1
//#define DEBUG_BackupReg 1
//#define DEBUG_SERIAL 2 // debug level
#define SerialNr USART1 // serial2 = USART2
//#define DEBUGSENDCMD 1
// ---- this options are current not possible, because the V 4.x firmware is only for STM32 (Maple Mini)
//#define ARDUINO_ATMEGA328P_MINICUL 1
//#define OTHER_BOARD_WITH_CC1101 1
//#define WATCHDOG 1 // Der Watchdog ist in der Entwicklungs und Testphase deaktiviert. Es muss auch ohne Watchdog stabil funktionieren.
Gruß Markus
das ist seltsam, wenn ich es mit der Arduino IDE compiliere verhält es sich anders.
Das Problem ist in der SimpleFIFO_h Zeile 37
#define FIFO_LENGTH 200
damit bekomme ich beim compilieren die folgende warning:
In file included from ... SIGNALDuino.ino:123
sketch/SimpleFIFO.h:37: warning: "FIFO_LENGTH" redefined
37 | #define FIFO_LENGTH 200
Wenn ich in der SimpleFIFO.h das "#define FIFO_LENGTH 200" auskommentiere, dann bekomme ich beim compilieren keine warnings
//#define FIFO_LENGTH 200
Zitat von: Ralf9 am 29 Juni 2021, 17:37:56
Wenn ich in der SimpleFIFO.h das "#define FIFO_LENGTH 200" auskommentiere, dann bekomme ich beim compilieren keine warnings
//#define FIFO_LENGTH 200
Hallo Ralf,
die Zeile ist bei mir eh auskommentiert, habe mir eben nochmals das aktuelle ZIP-Archiv von GitHub runtergeladen, entpackt und alle vorhandenen Dateien gelöscht und komplett neu benutzt. In der compile_config.h oben genannte Einstellungen vorgenommen, gleicher Fehler wie gestern beschrieben. Wenn ich die Zeile in der SimpleFIFO.h das auskommentieren rausnehme kommen noch mehr Fehler.
Arduino IDE habe ich 1.8.15, Einstellung für das Board siehe Anhang.
Ich habs nochmal getestet, das kompilieren mit der Arduino IDE funktioniert nur, wenn nur die Dateien die hier in der README.md unter Getting started stehen, in den sketchordner kopiert werden.
https://github.com/Ralf9/SIGNALDuino/tree/dev-r420_cc1101
Wenn im sketchordner auch die SimpleFIFO.cpp ist, dann gibts beim kompilieren errors
Mir ist nicht klar wozu die "SimpleFIFO.cpp" überhaupt benötigt wird.
Es funktioniert auch ohne diese Datei, sie enthält nur eine Codezeile
#include "SimpleFIFO.h"
Hallo Ralf,
jetzt gebe ich dir Recht, so funktioniert´s. Ich muss gestehen ich habe die readme nicht wirklich gelesen, ich habe immer den Inhalt des libraries-Ordners in den libraries-Ordner der Arduino-IDE kopiert, da wo die restlichen libraries liegen. Das hatte bislang immer so funktioniert ohne Probleme, bei der 4.2.0 hat sich da wohl was geändert. Habe das jetzt aber berücksichtigt und nur die von dir genannten erforderlichen Dateien alle im Sketch-Ordner, schon läuft´s.
Gruß Markus
@Ralf9
Was ist der Hintergrund warum in der kompilierten .bin die LAN Konfig mit default
ZitatIP = 192.168.0.244
Gateway = 192.168.0.1
Netmask = 255.255.255.0
belegt ist? Warum nicht dhcp per default? Nur so eine Frage eines noobs ;-)
Danke und viele Grüße
Fritz
Hallo Ralf9,
zwei Verbesserungsvorschläge:
- evtl. das Github Repository ändern und so gestalten dass man nicht immer kopieren muss.
- Eine AutoConfigure-Funktion einführen. Die Firmware erkennt ja wie viele CC1101-Module vorhanden sind und kann eine Default-Konfiguration setzen, wie es z.B. mit Modul B schon gemacht wird.
Dann wäre der Standard-Fall ja abgedeckt (3x868 + 1x433MHz) und kein "Laie" müsste sich mit mehr mit CREA..D etc. , ich sag mal "herumärgern" ;) ;D
Grüße,
Jürgen
ZitatWas ist der Hintergrund warum in der kompilierten .bin die LAN Konfig mit default
belegt ist? Warum nicht dhcp per default? Nur so eine Frage eines noobs ;-)
In der "compile_config.h" ist normalerweiser per Default das folgende define gesetzt
#define LAN_INIT_DHCP 1 // damit wird bei der ersten Inbetriebnahme DHCP verwendetDamit wird als Kennzeichen für DHCP der letzte Wert der IP Adresse auf 0 gesetzt.
Zitatevtl. das Github Repository ändern und so gestalten dass man nicht immer kopieren muss.
Wenn ich die Dateien so ablege, daß es für die Arduino IDE passt (wie in der readme.md beschrieben alle benötigten Dateien in den Sketchordner), passt es dann auch für Visual Studio und platformio?
Gruß Ralf
ZitatWenn ich die Dateien so ablege, daß es für die Arduino IDE passt (wie in der readme.md beschrieben alle benötigten Dateien in den Sketchordner), passt es dann auch für Visual Studio und platformio?
Würde ich am WoE ausprobieren. Zumindest passen dann die Includes ... ;-)
Grüße,
Jürgen
Hallo Zusammen,
ich habe mich in den letzten Tagen in das Thema etwas eingearbeitet und sehe ein wenig Optimierungspotenzial für den entsprechenden Wiki-Eintrag. Ich fühle mich mal berufen und mache entsprechend ein paar Änderungen im Wiki. Bitte schaut mal bei Gelegenheit über den Wiki Eintrag rüber und gebt ruhig eine Rückmeldung wenn ich da Mist verzapft habe.
Vielen Dank und viele Grüße
Fritz
Hallo Ralf9,
ich habe bzgl. des angepassten 00_Signalduino.pm Moduls zwei Fragen:
1. Wenn das angepasste Modul genutzt wird, kann dann weiterhin ein Siganlduino auf nano Basis betrieben werden?
2. Ist es möglich, wenn auf die angepasste Version gewechselt wurde, wieder auf das "original Modul" zu wechseln mit dem Befehlupdate all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt
Ich Frage weil ich das entsprechend ins Wiki eintragen möchte.
Vielen Dank und viele Grüße
Fritz
Wenn das angepasste Modul genutzt wird, kann dann weiterhin ein Siganlduino auf nano Basis betrieben werden?
Ja meine Firmware auf promini und nano Basis wird auch voll unterstützt.
Die Firmware von Sidey sollte auch funktionieren, mit Ausnahme der FSK Modulation.
Ist es möglich wieder auf das "original Modul" zu wechseln mit dem Befehl.
Ja, mit dem 00_SIGNALDuino Modul von Sidey das es aktuell im normalen fhem update gibt, sollte meine Firmware mit Einschränkungen funktionieren.
Es kann aber sein, daß mit dem aktuellen 00_SIGNALDuino Modul vom github RFD-FHEM von Sidey meine Firmware nicht mehr funktioniert.
Es gibt einen neuen branch
https://github.com/Ralf9/SIGNALDuino/tree/dev-r421_cc1101
dort sind die benötigten Dateien im Ordner "SIGNALduinoAdv"
Es lässt sich nun auch mit platformio kompilieren, dazu muß der Ordner "SIGNALduinoAdv" und die platformio.ini ins Projektverzeichniss kopiert werden.
Es ist noch nicht ganz fertig, bis jetzt gibt es nur "env:Maple_sduino_USB", "env:Maple_sduino_LAN" und "env:ESP32_sduino-devkit-v1"
Beim ESP32 muss noch in der platformio.ini bei build_flags die Variante angepasst werden: SIGNALESP32, EVIL_CROW_RF oder ESP32_SDUINO_TEST
Bei der Arduino IDE muss beim ESP32 noch zusätzlich der "tzapu WiFiManager" installiert werden.
Gruß Ralf
Zitatplatform = ststm32@~7.0.0
der platformio stm32duino core 13 funktioniert auch noch
Zitatplatform = ststm32@~13.0.0
Wenn man von der Arduino IDE zu platformio wechselt ändert sich die /dev/serial/by-id:
firmware mit der Arduino IDE
usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_firmware mit platformio
usb-STMicroelectronics_MAPLE_MINI_B20_CDC_in_FS_Mode_@Fritz
noch ein Hinweis zum Bootloader 2.0, die Wahrscheinlichkeit ist recht hoch, daß bei einem aktuell gekauften Maple Mini der Bootloader 2.0 bereits drauf ist.
Bei den Maple Mini die ich in letzter Zeit gekauft habe, war bei allen der Bootloader 2.0 schon drauf.
Zitat von: Ralf9 am 07 Juli 2021, 21:03:13
@Fritz
noch ein Hinweis zum Bootloader 2.0, die Wahrscheinlichkeit ist recht hoch, daß bei einem aktuell gekauften Maple Mini der Bootloader 2.0 bereits drauf ist.
Bei den Maple Mini die ich in letzter Zeit gekauft habe, war bei allen der Bootloader 2.0 schon drauf.
Danke für den Hinweis, werde in den nächsten Tagen das Wiki ergänzen. Dazu konkret noch eine Frage bzgl. "Inbetriebnahme/Erstkonfig", wie geht man da vor. Ausgangspunkt ist ein MapleSduino mit 3 Radios. Zunächst ist ja nur Radio B on, A und C sind off. Was muss nun gemacht werden. Wahrscheinlich zuerst die Bänke mit den rfmodes "füttern", das geht wahrscheinlich über set rfmode .... Richtig? Wenn dann alle benötigten Bänke definiert sind werden dann die Radios eingeschaltet, und dann selektiert und mit entsprechender Bank initialisiert?! Ich steh da auf dem Schlauch.
Bitte schlaut mich mal auf das ich das entsprechend ins Wiki schreiben kann. Vielen Dank und viele Grüße
Fritz
ZitatWas muss nun gemacht werden. Wahrscheinlich zuerst die Bänke mit den rfmodes "füttern", das geht wahrscheinlich über set rfmode .... Richtig?
Ob zuerst mit CREA und CREC die cc1101 Module A und C aktiviert werden oder ob zuerst die Bänke mit den rfmodes gefüttert werden ist egal.
Wenn alle benötigten Bänke definiert sind, dann kann z.B mit
bA1W und
bC3Wdem Radio A die Bank 1 und Radio C die Bank 3 zugeordnet und initialisiert werden.
Bei Version wird dann aus
(R: Ai B0* Ci)z.B. das:
(R: A1 B0* C3)Das füttern der Bänke kann komfortabel mit set rfmode gemacht werden oder auch über den raw Befehl:
get sduino raw CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,...Gruß Ralf
Zitat von: Ralf9 am 09 Juli 2021, 00:13:28
Ob zuerst mit CREA und CREC die cc1101 Module A und C aktiviert werden oder ob zuerst die Bänke mit den rfmodes gefüttert werden ist egal.
Wenn alle benötigten Bänke definiert sind, dann kann z.B mit
bA1W und bC3W
dem Radio A die Bank 1 und Radio C die Bank 3 zugeordnet und initialisiert werden.
Bei Version wird dann aus
(R: Ai B0* Ci)
z.B. das:
(R: A1 B0* C3)
Das füttern der Bänke kann komfortabel mit set rfmode gemacht werden oder auch über den raw Befehl:
get sduino raw CW0001,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,...
Habe das nach meinem Wissensstand bzw. Interpretation ins Wiki übernommen.
Viele Grüße
Fritz
Hallo Ralf,
entschuldige bitte wenn ich nochmal mit dem Thema nerve.
Zitat von: Ralf9 am 30 Juni 2021, 21:17:38
In der "compile_config.h" ist normalerweiser per Default das folgende define gesetzt
#define LAN_INIT_DHCP 1 // damit wird bei der ersten Inbetriebnahme DHCP verwendet
Damit wird als Kennzeichen für DHCP der letzte Wert der IP Adresse auf 0 gesetzt.
Wenn die kompilierte
Maple_sduino_LAN_412dev210205.bin geflasht wird, ist dann DHCP vom Maple aktiv oder ist die LAN Konfig mit
IP = 192.168.0.244
Gateway = 192.168.0.1
Netmask = 255.255.255.0manuell definiert? Ich habe die kompilierte Version mal geflasht und bei mir war DHCP aus und LAN Konfig manuell wie oben beschrieben definiert
Danke und viele Grüße
Fritz
Hallo euch allen,
ich habe mal ne Frage bezüglich dem ESP32. Hat den von euch schon jemand in Einsatz, falls ja welchen habt ihr den benutzt und wie habt ihr den verschaltet?
Als ESP32 hätte ich einen der folgenden Links genommen:
https://www.ebay.de/itm/162736953138?chn=ps&norover=1&mkevt=1&mkrid=707-134425-41852-0&mkcid=2&itemid=162736953138&targetid=1270189284895&device=c&mktype=pla&googleloc=9041832&poi=&campaignid=10215338563&mkgroupid=122520030916&rlsatarget=pla-1270189284895&abcId=1139676&merchantid=138405830&gclid=EAIaIQobChMI2OPdibnl8QIVSOJ3Ch3mbQDvEAQYASABEgJBUvD_BwE (https://www.ebay.de/itm/162736953138?chn=ps&norover=1&mkevt=1&mkrid=707-134425-41852-0&mkcid=2&itemid=162736953138&targetid=1270189284895&device=c&mktype=pla&googleloc=9041832&poi=&campaignid=10215338563&mkgroupid=122520030916&rlsatarget=pla-1270189284895&abcId=1139676&merchantid=138405830&gclid=EAIaIQobChMI2OPdibnl8QIVSOJ3Ch3mbQDvEAQYASABEgJBUvD_BwE)
https://www.amazon.de/Espressif-Development-Bluetooth-WROOM32-NodeMCU/dp/B07K68RQTS/ref=asc_df_B07K68RQTS/?tag=googshopde-21&linkCode=df0&hvadid=407342190625&hvpos=&hvnetw=g&hvrand=5422462145293728654&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9041832&hvtargid=pla-862519322535&psc=1&th=1&psc=1&tag=&ref=&adgrpid=85377202485&hvpone=&hvptwo=&hvadid=407342190625&hvpos=&hvnetw=g&hvrand=5422462145293728654&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9041832&hvtargid=pla-862519322535 (https://www.amazon.de/Espressif-Development-Bluetooth-WROOM32-NodeMCU/dp/B07K68RQTS/ref=asc_df_B07K68RQTS/?tag=googshopde-21&linkCode=df0&hvadid=407342190625&hvpos=&hvnetw=g&hvrand=5422462145293728654&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9041832&hvtargid=pla-862519322535&psc=1&th=1&psc=1&tag=&ref=&adgrpid=85377202485&hvpone=&hvptwo=&hvadid=407342190625&hvpos=&hvnetw=g&hvrand=5422462145293728654&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=9041832&hvtargid=pla-862519322535)
Gruß
Markus
ich verwende das "ESP32 DEVKIT V1"
in der compile_config.h gibts das define:
#define SIGNALESP32 1
da hat dann das 433Mhz cc001 Modul B die selbe Pinbelegung wie der SignalESP von Sidey
#elif SIGNALESP32
const uint8_t pinSend[] = {26, 4};
const uint8_t pinReceive[] = {25, 13, 14, 21};
#define PIN_LED 2
#define PIN_RECEIVE_A pinReceive[0] // gdo2 cc1101 A
#define PIN_RECEIVE_B pinReceive[1] // gdo2 cc1101 B
#ifdef SIGNALESP32
const uint8_t radioCsPin[] = {27, 5, 22, 33};
@Fritz Muster
habs mir nochmals angeschaut, das mit dem LAN_INIT_DHCP funktioniert erst ab der Version 4.1.2-dev210321
https://github.com/Ralf9/SIGNALDuino/commit/5b00e34846327c665186a2393f18b085ef126f62
bei der Initialisierung wird geprüft ob im EEPROM ab der Adr 0xc0 die folgenden 3 Werte stehen: 00:80:41, dies ist die vordere Häfte der Macadresse.
wenn dies nicht drin steht, wird die aus der Seriennummer ermittelte Mac Adresse und die Default IP-Adresse ins EEPROM geschrieben.
Wenn LAN_INIT_DHCP definiert ist, dann wird nach der Initialisierung der IP-Adresse als Kennzeichen für DHCP der letzte Wert der IP-Adresse auf 0 gesetzt.
Gruß Ralf
Die platformio unterstützung ist inzwischen soweit fertig. Den Eindruck den ich am Anfang von Platformio hatte, hat sich bestätigt.
Es ist sehr mühsam und aufwendig sich in Platformio einzuarbeiten. Eine platformio.ini zu schreiben ist nichts für Anfänger, die Dokumentation lässt zu wünschen übrig, einige der Infos musste ich aus den json Dateien holen.
Die Installation und das Bedienen der Platformio ist zwar schwieriger als die Arduino IDE, aber es lohnt sich. Die ganze Boardeinstellungen und installieren von evtl benötigten library entfällt bei Platformio, da dies in der platformio.ini steht.
Unter Windows 10 muß dazu Python 3 und git installiert werden und der Pfad von Python in die PATH Variable von Windows eingetragen werden.
Dann muss noch Visual Studio Code und Platformio installiert werden, wenn ein neues Projektverzeichnis erstellt wurde und die SignalduinoAdv Dateien hineinkopiert wurden, dann sieht es ungefähr so aus wie in der Anlage.
Da der serial big Data Bug vom core 2.0.0 bei der LAN Variante nicht relevant ist, kann da der core 2.0.0 verwendet werden.
Da aber beim platformio noch ein bug beim core 2.0 und dem Bootloader 2.0 ist, kann der core 2.0 nur mit der upload Methode Bootloader Orginal verwendet werden
Gruß Ralf
Ich habe nun auch bei releases die Firmware bin-Files abgelegt (das bin-File für den ESP32 habe ich noch nicht getestet)
https://github.com/Ralf9/SIGNALDuino/releases
und die readme.md aktualisiert
https://github.com/Ralf9/SIGNALDuino/tree/dev-r421_cc1101
Hilfen bei der Dokumentation, Entwicklung und Änderungs- und Ergänzungswünsche sind natürlich gerne willkommen.
Gruß Ralf
Hallo zusammen,
Hat schon jemand von euch ein Gehäuse für den MapleSduino konstruiert und würde mir die STL zur Verfügung stellen?
ZitatMapleSduino
welchen (https://cadlab.io/project/2431/master/files)? :D
Zitat von: juergs am 04 August 2021, 18:26:26
welchen (https://cadlab.io/project/2431/master/files)? :D
:D
V09
https://forum.fhem.de/index.php/topic,120090.0.html (https://forum.fhem.de/index.php/topic,120090.0.html)
Die Abmaße der V02-Platine könnten passen.
Hallo zusammen.
Gibt es einen Schaltplan, wo der genaue Anschluß der CC1101 Module an einem ESp32 beschrieben ist?
Ich würde mich bei Zeiten dran setzen einen ESP32 mit 2 CC1101 Modulen (433 und 868MHz) zusammen zu bauen.
Mit dem ziel das LaCrosse Gateway zu entfernen.
Gruß
Sascha
Hallo Ralf,
ich habe gerade die neue LAN_421 auf meinen Sduino geladen und musste feststellen, dass LAN damit nicht mehr funktioniert. Ich habe die entsprechende USB_421 geladen und mit "ri" die Konfiguration ausgelesen. Die Adressen waren alle richtig eingetragen. Nochmals die 421 versucht, wieder konnte ich nicht darauf zugreifen. Dann habe ich die 412 geladen die auch vorher schon drauf war. Damit läuft es jetzt wieder problemlos. Irgendeine Idee woran es liegen könnte?
Gruß Reinhard
hast Du das beachtet?
Zitatanpassungen für platformio
Da der serial big Data Bug vom core 2.0.0 bei der LAN Variante nicht relevant ist, wird bei platformio beim LAN der core 2.0.0 verwendet.
Da aber beim platformio noch ein bug beim core 2.0 und dem Bootloader 2.0 ist, kann der core 2.0 nur mit der upload Methode Bootloader Orginal verwendet werden
Zitat von: Ralf9 am 04 September 2021, 15:07:15
hast Du das beachtet?
Gelesen ja, verstanden anscheinend nein :-[
Wenn ich es richtig sehe verwende ich den Bootloader 2.0. Der Upload funktionierte bei mir problemlos, ich hatte somit vermutet das alles ok ist. Bedeutet das, ich muss den alten Bootloader suchen, reinschießen und dann funktioniert auch die 421? BTW, ich habe nichts selber kompiliert sondern deine Images verwendet. Falls ich auf den alten Bootloader umsteigen muss belasse ich es lieber bei der 412 Version vom 20.1. Die läuft bei mir stabil.
Gruß Reinhard
Der Bootloader 2.0 ist abwärts kompatibel zum Orginalbootloader.
Beim dfu-util bestimmt -a die upload Methode.
-a 1 ist der orginal Bootloader
-a 2 ist der Bootloader 2.0
Beim Bootloader 2.0 wird das bin File an eine andere Adresse im Flash geladen als beim Orginal Bootloader.
Damit wird dann die upload Methode orginal Bootloader verwendet
dfu-util -d 1eaf:0003 -a 1 -D Maple
Gruß Ralf
Zitat von: Ralf9 am 04 September 2021, 15:27:40
Der Bootloader 2.0 ist abwärts kompatibel zum Orginalbootloader.
Beim dfu-util bestimmt -a die upload Methode.
-a 1 ist der orginal Bootloader
-a 2 ist der Bootloader 2.0
Beim Bootloader 2.0 wird das bin File an eine andere Adresse im Flash geladen als beim Orginal Bootloader.
Damit wird dann die upload Methode orginal Bootloader verwendet
dfu-util -d 1eaf:0003 -a 1 -D Maple
Gruß Ralf
Habe gerade den Rechner ausgeschaltet, werde ich heute Abend testen :)
Zitat von: Reinhard.M am 04 September 2021, 15:32:48
Habe gerade den Rechner ausgeschaltet, werde ich heute Abend testen :)
Kaum macht man es richtig, schon funktioniert's :)
Besten Dank für den Stubser in die richtige Richtung.
Gruß Reinhard
Hab mal wieder bei Amazon, ebay und Ali Express nach dem Maple Mini gesucht, die grünen scheint es nicht mehr zu geben nur noch die blauen.
https://www.amazon.de/s?k=STM32F103CBT6
Interessant unter welchen Bezeichnungen diese u.a. angeboten werden:
ZitatOumefar Hauptsteuerplatine Professional High Presision 1pcs für Industrie für Fabrik
Gruß Ralf
Hallo Ralf,
ich möchte Signale von meiner Wetterstation empfangen und SOMFY-Signale empfangen und senden können. Dafür benötige ich zwei 433 MHz-Module: 433.92 MHz für die Wetterstation und 433.20 MHz für SOMFY.
Ist es möglich mit einem MapleSDuino auf der Ranseyer-Platine zwei 433 MHz-Module mit OOK/ASK zu betreiben?
Im Wiki ließt sich das so, als ob maximal zwei 868MHz- und nur ein 433 MHz-Modul betrieben werden können. Andererseits sprichst Du hier im Thread https://forum.fhem.de/index.php/topic,106278.msg1111414.html#msg1111414 (https://forum.fhem.de/index.php/topic,106278.msg1111414.html#msg1111414) davon, die Firmware dementsprechend zu erweitern. In der Release-Note V4.1.2-dev210205 ist zu lesen, dass nun auch mit dem cc1101 Modul A slowRF empfangen und gesendet werden kann. Ich bin verunsichert.
Viele Grüße
Zitatich möchte Signale von meiner Wetterstation empfangen und SOMFY-Signale empfangen und senden können. Dafür benötige ich zwei 433 MHz-Module: 433.92 MHz für die Wetterstation und 433.20 MHz für SOMFY.
Es kann sein, daß dafür ein cc1101 Modul reicht, wenn Du eine Frequenz zwischen 433.92 MHz und 433.20 MHz wählst und die Bandbreite etwas erhöhst. Es gibt im Forum einige denen es gelungen ist.
ZitatIst es möglich mit einem MapleSDuino auf der Ranseyer-Platine zwei 433 MHz-Module mit OOK/ASK zu betreiben?
Es sind mit meiner Firmware beliebige Kombinationen von 433 und 868 MHz möglich. Es gibt die Beschränkung, daß slowrf nur beim Modul A und B möglich sind.
Super, dann habe ich sogar zwei Optionen. Dann werde ich mal mit der Ersten starten.
Viele Grüße
Zitat von: Romoker am 12 Januar 2022, 21:07:46
Im Wiki ließt sich das so, als ob maximal zwei 868MHz- und nur ein 433 MHz-Modul betrieben werden können.
Habe das im Wiki entsprechend ergänzt/angepasst.
Viele Grüße
Fritz
Hallo,
ich bin z.Zt. dabei WMBus S, T und C einzubauen. Ich verwende dabei die Routinen von der culw.
Diese Routine funktioniert so nicht
uint16 verifyCrcBytesCmodeB(uint8* pByte, uint8* pPacket, uint16 packetSize)
{
uint16 crc = 0;
uint16 i = 0;
if (packetSize > 128) {
...
}
while (i < packetSize - 2) {
crc = crcCalc(crc, pByte[i]);
pPacket[i] = pByte[i];
++i;
}
if ((~crc) != (pByte[packetSize - 2] << 8 | pByte[packetSize - 1])) {
return (PACKET_CRC_ERROR);
}
pPacket[packetSize - 2] = pByte[packetSize - 2];
pPacket[packetSize - 1] = pByte[packetSize - 1];
return (PACKET_OK);
}
Weiß jemand warum diese Abfrage beim Maple Mini und der Arduino IDE so nicht funktioniert?
if ((~crc) != (pByte[packetSize - 2] << 8 | pByte[packetSize - 1])) {
so auch nicht
if ((~crc) != ((uint16_t)pByte[packetSize - 2] << 8 | pByte[packetSize - 1])) {
So funktionierts:
uint16_t ic;
uint16_t ii;
ic = ~crc
ii = (uint16_t)pByte[packetSize - 2] << 8 | pByte[packetSize - 1]
if (ic != ii) {
Gruß Ralf
Hallo Ralf,
habe versucht es zu vereinfachen:
https://www.tutorialspoint.com/compile_c_online.php (https://www.tutorialspoint.com/compile_c_online.php)
#include <stdio.h>
#include <stdint.h>
#include <stdbool.h>
int main()
{
printf("Hello, World!\n");
uint16_t ic = 0;
uint16_t ii = 0;
uint16_t crc = 0;
uint8_t byte_h = 128;
uint8_t byte_l = 1;
printf("crc = %u\n", crc);
printf("crc = %x\n", crc);
ic = ~crc;
printf("~crc = %u => %x\n", ic, ic);
printf("byte_h/l = %u -> %u\n", byte_h, byte_l);
printf("byte_h shifted => %u => %x\n", byte_h<<8, byte_h<<8);
//--- Fall 1
bool isEqual = ( (~crc) != (byte_h << 8 | byte_l) );
printf("isEqual = %u \n", isEqual);
//--- Fall 2
ii = ((uint16_t) byte_h << 8) | byte_l ;
printf("ii = %u => %x\n", ii, ii);
return 0;
}liefert:
Zitat$gcc -o main *.c -lm
$main
Hello, World!
crc = 0
crc = 0
~crc = 65535 => ffff
byte_h/l = 128 -> 1
byte_h shifted => 32768 => 8000
isEqual = 1
ii = 32769 => 8001
isEqual ist False.
Bei Fall1 scheint byte_h <<8 (byte_h shifted) automatisch in den nächst höheren Datentyp gecastet zu werden...
Damit kann ichs nachstellen. Hier funktioniert der Fall 1 nicht, nur warum scheint der Fall 1 beim Arduino zu funktionieren?
#include <stdio.h>
#include <stdint.h>
#include <stdbool.h>
int main()
{
bool isnotEqual;
uint16_t ic;
uint16_t ii;
uint16_t crc = 0x2233;
uint8_t byte_h = 0xdd;
uint8_t byte_l = 0xcc;
printf(" crc = %x\n", crc);
ic = ~crc;
printf("~crc = %x\n", ic);
printf("byte_h/l = %x / %x\n", byte_h, byte_l);
printf("byte_h shifted => %x\n", byte_h<<8);
//--- Fall 1
isnotEqual = ( (~crc) != (byte_h << 8 | byte_l) );
printf("isnotEqual = %u \n", isnotEqual);
//--- Fall 2
ii = (byte_h << 8) | byte_l ;
isnotEqual = ( ic != ii);
printf("isnotEqual = %u , ii = %x\n", isnotEqual, ii);
return 0;}
Zitat$gcc -o main *.c -lm
$main
crc = 2233
~crc = ddcc
byte_h/l = dd / cc
byte_h shifted => dd00
isnotEqual = 1
isnotEqual = 0 , ii = ddcc
Hallo Ralf,
es liegt wohl am "~crc" ::) :o Im Speziellen am ,,~"-Operator.
#include <stdio.h>
#include <stdint.h>
#include <stdbool.h>
int main()
{
bool isnotEqual;
uint16_t ic;
uint16_t ii;
uint16_t crc = 0x2233;
uint8_t byte_h = 0xdd;
uint8_t byte_l = 0xcc;
printf(" crc = %x\n", crc);
ic = ~crc;
printf("~crc = %x\n", ic);
printf("byte_h/l = %x / %x\n", byte_h, byte_l);
printf("byte_h shifted => %x\n", byte_h<<8);
printf("toUInt16 => %x\n", (byte_h << 8 | byte_l));
//--- Fall 1
isnotEqual = ( (~crc) != ( byte_h << 8 | byte_l ) );
printf("isnotEqual_a = %u \n", isnotEqual);
isnotEqual = ( (ic) != (byte_h << 8 | byte_l) );
printf("isnotEqual_b = %u \n", isnotEqual);
//--- Fall 2
ii = (byte_h << 8) | byte_l ;
isnotEqual = ( ic != ii);
printf("isnotEqual = %u , ii = %x\n", isnotEqual, ii);
printf("true = %u , false = %u\n", true, false);
return 0;
}Ergebnis:
======
Zitat
$gcc -o main *.c -lm
$main
crc = 2233
~crc = ddcc
byte_h/l = dd / cc
byte_h shifted => dd00
toUInt16 => ddcc
isnotEqual_a = 1
isnotEqual_b = 0
isnotEqual = 0 , ii = ddcc
true = 1 , false = 0
Vielleicht etwas in dieser Richtung: https://stackoverflow.com/questions/48106169/with-new-gcc-version-getting-warning-bool-comparision (https://stackoverflow.com/questions/48106169/with-new-gcc-version-getting-warning-bool-comparision)
Mit einem cast funktionierts auch, nur warum brauch ich da ein cast (uint16_t), wenn crc schon uint16_t ist?
isnotEqual = ( (uint16_t)(~crc) != ( byte_h << 8 | byte_l ) );
Hallo,
in der Anlage ist von der V4.2.2 für den Maple sduino USB und den Maple CUL USB vorab eine Testversion (ist noch nicht im Github)
Es ist dafür die v3.4.10-dev_ralf meiner Variante des 00_SIGNALduino.pm notwendig
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Es kann damit WMBus S, T und C empfangen und WMBus S und T gesendet werden. Es funktioniert nicht am vierten cc1101 Modul D und nicht mehr als ein cc1101 Modul gleichzeitig
Beim Senden mit "set raw" kann auch das CUL Format bss... und bst.. verwendet werden,
Mit z.B.
set raw sduino bss0F44AE0C7856341201074447780B12436587255D
wird das gesendet
SN;N=11;D=bss0F44AE0C7856341201074447780B12436587255D;
Beim Empfang können bei Bedarf mit
get sduino raw TD
auch Debugausgaben aktiviert werden.
Mit "get sduino raw Td" werden sie wieder ausgeschaltet.
Bei aktivierten Debugausgaben wird bei jedem empfangenen sync "mbSyn" ausgegeben.
Es kann z.B. so aussehen:
mbSyn
L=93
L=62
L=31
mb L=64 S=0
MN;D=374468500905276739C3BFFFA2109F27CE480158623A0000819E1D8DA7BD34EA579A562B000000000000D0C01E0279CC4D5597C5852269AFAA2B7E2C37E92B048047;N=12;
dabei sind "L=xx" die Bytes die noch vom cc1101 FIFO empfangen werden müssen.
"mb L=64 S=0" bedeuted, daß die Nachricht nach der Decodierung eine Länge von 64 Byte hat. Bei S > 0 gab es einen Fehler
Gruß Ralf
Zitat von: Ralf9 am 17 Juli 2021, 12:25:00
Hilfen bei der Dokumentation, Entwicklung und Änderungs- und Ergänzungswünsche sind natürlich gerne willkommen.
Ich habe ein ESP32 Devkit V4 (https://www.az-delivery.de/products/esp-32-dev-kit-c-v4), ein CC1101-433 und ein CC1101-868. Beide an einem ESP zu betreiebn, wäre natürlich toll. Außerdem wünsche ich mir, dass mein Sduino meine Klingel "hört" (https://github.com/RFD-FHEM/RFFHEM/issues/946).
Aktuell ist der cc1101-868 so verbunden (https://github.com/RFD-FHEM/SIGNALDuino/issues/189#issuecomment-825042553) und funktioniert mit SIGNALDuino_ESP32cc1101_3.5.0-dev+20210808 (https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.5.0-dev%2B20210808/SIGNALDuino_ESP32cc1101_3.5.0-dev+20210808.hex).
An welche Pins muss nun der andere cc1101? Sind die Pulse für meine Klingel klein genug? Stellst du bitte noch V4.2.2 für ESP32 zur Verfügung?
ZitatSind die Pulse für meine Klingel klein genug?
Nein bei den fertigen bin Files ist die default "pulseMin 90"
Du bist bis jetzt der einzigste, der ein kleineres pulseMin benötigt.
Es muss erstmal rausgefunden werden wie klein die pulseMin sein muss, das es funktioniert.
Kannst Du die firmware selbst kompilieren oder benötigst Du dabei Hilfe?
ZitatStellst du bitte noch V4.2.2 für ESP32 zur Verfügung?
ja, kommt demnächst
ZitatAn welche Pins muss nun der andere cc1101?
GPIO25 -> GDO2
GPIO27 -> CSN
GPIO26 -> GDO0
In VSCode SIGNALDuino (https://github.com/Ralf9/SIGNALDuino) ausgecheckt, env:ESP32_sduino_devkitV1 ausgewählt, PulseMin auf 30 (https://github.com/Ralf9/SIGNALDuino/blob/dev-r421_cc1101/SIGNALduinoAdv/SIGNALduinoAdv.ino#L203) gesetzt, Upload gedrückt, SIGNALduino-Modul aktualisiert & neugestartet (https://github.com/Ralf9/RFFHEM/tree/dev), so dass ich jetzt Folgendes sehe:
version 4.2.1-dev210711 SIGNALduinoAdv ESP32 cc1101 (R: B0*) - compiled at Mar 12 2022 13:43:41
versionmodul v3.4.10-dev_ralf_12.02.
versionprotoL v3.4.10-dev_ralf_16.02.
Und meine bereits am ESP-12F laufende AC-114 (https://github.com/RFD-FHEM/RFFHEM/issues/906) und in FHEM eingerichtete Fernebdienung wird sauber dekodiert.
Setze ich, wie von Ralf9 empfohlen, set sduino cc1101_dataRate 10000 wird meine Klingel auch gehört (https://github.com/RFD-FHEM/RFFHEM/issues/946#issuecomment-1065945828).
Vielen Dank @Ralf9 für die Hilfe!
Bei dem was Du vorhast (sehr kleine PulseMin Werte) hast Du wahrscheinlich mit dem MapleMini die größten Changen es hinzubekommen.
Beim ASK/OOK löst jede Signalflanke einen Interrupt aus. Der ESP muß sich aber noch um andere Dinge kümmern, wie z.B. das WLAN.
Da die Pulse Deiner Klingel sehr viel kürzer als normal sind, werden viel mehr Interrupts ausgelöst, dadurch hat der ESP evtl zu wenig Zeit für die anderen Dinge.
Wenn Du die PulseMin ca halbierst, dann muß Du auch die Datarate vom cc1101 auf ca 10000 erhöhen.
Gruß Ralf
Hallo zusammen,
ich könnte etwas Orientierungshilfe gebrauchen.
Ich bin dabei, einen Maplemini "mit mehreren cc1101 Modulen und FSK" zu bauen. Später soll noch ein W5500 drauf. Ich habe den Maple (ohne cc1101) mit den Bootloader (updater_stm32f1.bin) geflasht. Damit funktioniert nun das Flashen der FW wie erwartet.
Nun die Fragen:
Muss ich den Maple vor dem Flashen der Firmware mit einem oder beiden cc1101 verbinden, oder kann ich ihn auch ohne testen?
Es gibt V3.3.4-dev211207, die ich schon auf einem Signalduino nano verwende. Läuft die auch auf dem Maple-Signalduino, bzw. mit mehreren cc1101,
oder ist Maple_sduino_USB_421dev210711 bzw. später Maple_sduino_LAN_421dev210711 die richtige Firmware?
Eine Terminalverbindung hatte ich bisher nur über die IDE mit "Generic STM32F103C", während ich den Bootloader hochgeladen habe. Vorhergehende Versuche mit Putty/Minicom (9600 8N1) /dev/maple zu öffnen sind gescheitert. Was macht die IDE anders?
Mit der V3.3.4-dev211207 auf dem Maple erhalte ich folgendes Bild:
#Der Maple wird beim Einstecken erkannt.
May 28 12:17:01 buster-pi kernel: [73467.407815] usb 1-1.4.2: new full-speed USB device number 23 using dwc_otg
May 28 12:17:01 buster-pi kernel: [73467.640518] usb 1-1.4.2: New USB device found, idVendor=1eaf, idProduct=0003, bcdDevice= 2.01
May 28 12:17:01 buster-pi kernel: [73467.640533] usb 1-1.4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 28 12:17:01 buster-pi kernel: [73467.640541] usb 1-1.4.2: Product: Maple 003
May 28 12:17:01 buster-pi kernel: [73467.640549] usb 1-1.4.2: Manufacturer: LeafLabs
May 28 12:17:01 buster-pi kernel: [73467.640556] usb 1-1.4.2: SerialNumber: LLM 003
#über die Rules wird ein SymLink /dev/maple erzeugt.
pi@buster-pi:~ $ sudo udevadm info --query=property --name=/dev/maple
DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4.2
DEVNAME=/dev/bus/usb/001/023
DEVTYPE=usb_device
DRIVER=usb
PRODUCT=1eaf/3/201
TYPE=0/0/0
BUSNUM=001
DEVNUM=023
MAJOR=189
MINOR=22
SUBSYSTEM=usb
USEC_INITIALIZED=73467327249
ID_MM_DEVICE_IGNORE=1
ID_VENDOR=LeafLabs
ID_VENDOR_ENC=LeafLabs
ID_VENDOR_ID=1eaf
ID_MODEL=Maple_003
ID_MODEL_ENC=Maple\x20003
ID_MODEL_ID=0003
ID_REVISION=0201
ID_SERIAL=LeafLabs_Maple_003_LLM_003
ID_SERIAL_SHORT=LLM_003
ID_BUS=usb
ID_USB_INTERFACES=:fe0102:
DEVLINKS=/dev/maple
#Nach dem Flashen blinkt die LED. Öffnen von /dev/maple aber nicht möglich.
Found DFU: [1eaf:0003] ver=0201, devnum=22, cfg=1, intf=0, path="1-1.4.2", alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=22, cfg=1, intf=0, path="1-1.4.2", alt=1, name="STM32duino bootloader v1.0 Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=22, cfg=1, intf=0, path="1-1.4.2", alt=0, name="STM32duino bootloader v1.0 ERROR. Upload to RAM not supported.", serial="LLM 003"
Wenn ich die "Maple_..." Firmware flashe, wird der Maple nach reset nicht mehr erkannt.
Ich hoffe, ihr könnt mich auf den Weg bringen.
VG Hajo
Nein die V3.3.x ist nicht für den Maple, die ist nur für den Arduino.
Die Maple_sduino_USB_421dev210711 ist momentan noch die aktuelle Firmware, es kommt demnächst die V4.2.2.
Ja, die V4.2.x firmware kannst Du auch ohne die cc1101 Module testen.
Bei der Terminalverbindung mit der firmware ist die Baudrate 115200
Du kannst auch mal testweise mit der IDE das Blinkbeispiel hochladen (IDE Boardkonfig siehe Anlage)
Gruß Ralf
Danke Ralf, jetzt hab ich 's. :)
Gruß
Hajo
Hallo Ralf, ich habe nun meinen Maplemini auf die Platine von Martin gesockelt und einen 868er Stamp aufgelötet.
Der Maple erkennt das Modul als "A". Ich hatte vermutet, dass es "B" (weil CC2?) werden müsste. Die Bank 0 ist aber offenbar für "B" reserviert. Ich habe also Bank 1 zugewiesen. Sieht so m.E. ok aus.
V 4.2.1-dev210711 SIGNALduinoAdv cc1101 (R: A1* B- C-) irx0
Als nächsten Schritt möchte ich noch einen 433er und einen weiteren 868er anschließen. Die beiden 868er sollen auf slowRF bzw. FSK konfiguriert werden.
Was passiert mit der Zuordnung (A,B,C, Bank 0...), wenn die anderen Module angeschlossen sind?
Das nun angeschlossene Modul ist ein CC101L. Sind dazu schon konkrete Einschränkungen bekannt?
Gibt es bezüglich A-C Einschränkungen (RFmode/Frequenz?)
Hallo Hajo,
das passt so, normalerweise ist das 868er Modul auf A und das 433er auf B.
Das Default Slowrf (ASK/OOK) ist Modul B und normalerweise auf Bank 0, das zweite slowrf ist Modul A
Slowrf (ASK/OOK) geht nur auf Modul A und B
ZitatWas passiert mit der Zuordnung (A,B,C, Bank 0...), wenn die anderen Module angeschlossen sind?
Dann kann es z.B. so aussehen (R: A1* B0 C2)
Zitat
Das nun angeschlossene Modul ist ein CC101L. Sind dazu schon konkrete Einschränkungen bekannt?
Welche Version wird angezeigt? Du kannst die cc1101 Version auch mit dem Register 31 abfragen.
Von der Bezeichnung her, kann man nur erkennen ob das Modul einschränkungen haben könnte.
Ich hab z.B. ein cc113L und mir sind keine einschränkungen aufgefallen.
Gibt es bezüglich A-C Einschränkungen (RFmode/Frequenz?)Du kannst alle Module für FSK verwenden und bei jedem Modul geht 433 oder 868
Gruß Ralf
Zitat von: Ralf9 am 02 Juni 2022, 23:39:08
... Welche Version wird angezeigt? Du kannst die cc1101 Version auch mit dem Register 31 abfragen.
Die Version 17 wird ausgegeben.
Gruß
Hajo
17 ist der CC110L
Ich hab dazu folgendes gefunden:
ZitatThe CC1101 and the CC110L are compatible. Actually the CC110L is based on the CC1101, but with some functionality removed in order to make it at a lower cost.
https://blog.katastros.com/a?ID=00250-58db5e76-f1e9-4ea8-a463-a42f2fe9c5ec
Es fehlen z.B.
- Forward error correction (FEC) and interleaving error correction
- Data Whitening
- Preamble quality threshold (PQT) indication (used to gate sync word detection)
- Link quality (LQI) indication
Es kann sein, daß dies beim Empfang von einigen Sensoren oder Fernbedienungen Nachteile hat. Bei normalen Temperatursendern wie z.B. Lacrosse dürfte dies keine Rolle spielen
Im github gibts jetzt die Firmware
V 4.2.2-dev220604https://github.com/Ralf9/SIGNALDuino/tree/dev-r422_cc1101
Zitat von: Ralf9 am 18 Februar 2022, 00:08:44
Es kann damit WMBus S, T und C empfangen und WMBus S und T gesendet werden. Es funktioniert nicht am vierten cc1101 Modul D und nicht mehr als ein cc1101 Modul gleichzeitig
- Es gibt für die Firmware V3.3.5 und die V4.2.2 optimierte cc1101 Registerkonfigurationen rfmodeTesting,
Bei dem 00_SIGNALDuino Modul ab v3.4.13-dev_ralf_29.05. gibts ein neues Attribut "rfmode_testing", damit wird bei set ein neuer Eintrag "rfmodeTesting" aktiviert
- Bei cmd_bank kann nun auch mit "-" hinter der Banknr die Bank deaktiviert (ungültig) gemacht werden
- Bei send_ccFIFO wird nun nach dem Senden nicht mehr der ReceiveMode aktiviert, wenn der cc1101 bereits im Rx Mode ist (ccReg 0x17 - TXOFF_MODE[1:0] = Rx)
- es gibt nun auch die Möglichkeit die Werte der cc1101 Register TEST2 - TEST0 ins EEPROM zu speichern.
Für den ESP32 gits noch keine fertige Firmware, wer es mit der Arduino IDE selbst kompilieren will, der benötigt noch die Bibliothek WiFiManager von tzapu
Gruß Ralf
Ich habe die neue Version mal geflasht. Nachdem ich mich dann beim Update von 00_SIGNALduino erst ein bisschen selbst ausgetrickst habe, läuft es aber. :)
Gruß
Hajo
Ich habe da doch noch ein Problem.
Auf dem Nano wird die Bresser Wetterstation offenbar nicht mehr verarbeitet:
2022.06.07 11:34:41 4: Signalduino868usb Parse_MN: Found 2-FSK Protocol id 207 length 56 -> Bresser Profi 7in1
2022.06.07 11:34:41 5: Signalduino868usb Bresser_7in1: dmsg=B7DFD34B2100B2000000000005081690690041840000000000 crc16 ok
2022.06.07 11:34:41 4: Signalduino868usb ParseMN: ID=207 dmsg=W207#D34B2100B2000000000005081690690041840000000000
2022.06.07 11:34:41 5: Signalduino868usb Dispatch: W207#D34B2100B2000000000005081690690041840000000000, test ungleich: disabled
2022.06.07 11:34:41 4: Signalduino868usb Dispatch: W207#D34B2100B2000000000005081690690041840000000000, -82 dB, dispatch
2022.06.07 11:34:41 5: Signalduino868usb: dispatch W207#D34B2100B2000000000005081690690041840000000000
2022.06.07 11:34:41 4: Signalduino868usb: SD_WS_Parse protocol 207, rawData D34B2100B2000000000005081690690041840000000000
2022.06.07 11:34:41 2: Signalduino868usb: SD_WS_Parse unknown message, please report. converted to bits: 1101001101001011001000010000000010110010000000000000000000000000000000000000000000000101000010000001011010010000011010010000000001000001100001000000000000000000000000000000000000000000
2022.06.07 11:34:41 3: Signalduino868usb: Unknown code W207#D34B2100B2000000000005081690690041840000000000, help me!
Auf dem Nano ist
V 3.3.5-dev210522 SIGNALduino cc1101
versionmodul v3.4.13-dev_ralf_29.05.
versionprotoL v3.4.13-dev_ralf_29.05.
rfmode Bresser_5in1_u_7in1__B28_N7_8220 => ok,N=7,ccmode=4
Gruß
Hajo
Hast Du auch das 14_SD_WS Modul von mir installiert?
"Version 14_SD_WS.pm" ergibt:
14_SD_WS.pm 21666 2022-05-01 20:00:00Z Ralf9
https://github.com/Ralf9/14_SD_WS/blob/main/FHEM/14_SD_WS.pm
update all https://raw.githubusercontent.com/Ralf9/14_SD_WS/main/controls_ralf9_sd_ws.txt
Zitat von: Ralf9 am 07 Juni 2022, 16:38:00
Hast Du auch das 14_SD_WS Modul von mir installiert?
Ich dachte mir schon, dass ich beim Update doch noch etwas vergessen habe. Das war es.
Vielen Dank
Hajo
Hallo,
Ist der "5V" Pin an der EXT-Buchse für die Spannungsversorgung gedacht? Ich möchte gern eine zusätzliche Buchse für die Versorgung einbauen. Gibt es da eine Schutzdiode auf dem Maple?
VG Hajo
Ja mit dem "5V" Pin kann der Maple Mini alternativ zu USB versorgt werden, ein Spannungsregler macht dann aus den 5V (laut der Beschriftung am Maple kann Vin max 15V sein) die 3.3V Betriebsspannung VCC des Maple.
https://raw.githubusercontent.com/leaflabs/maplemini/master/maplemini.pdf
Gruß Ralf
Danke, für die Bestätigung.
Meine beiden Maples funktionieren erstmal soweit. Beim zweiten Maple fehlt mir aber noch das 3. CC1101.
Testweise habe ich das 3. Modul vom ersten Maple abgezogen und an den zweiten gesteckt. Am Zweiten ließ sich das nicht Modul aktivieren. Der Ausgabe nach wurde es erkannt und sollte wohl mit Bank 15 (0x0F) initialisiert werden. Am Ende wurde "invalid" ausgegeben. Ich habe daraufhin das Eeprom mit "e" gelöscht. Das hatte den Effekt, dass ich auch die anderen Beiden nicht mehr aktivieren konnte. Im Grunde wurde kein CC1101 mehr erkannt. Ich habe Modul 3 wieder abgezogen und dann ließen sich die beiden anderen Module wieder aktivieren. Schließlich habe ich das 3. Modul wieder angesteckt. Beim Start kam dann diese Meldung
V 4.2.2-dev220604 SIGNALduinoAdv LAN cc1101 (R: A1 B1* C15) - compiled at Jun 5 2022 15:48:20 Allerdings wurde B tatsächlich mit Bank 0 initialisiert und C war nicht aktiv. Die Gute Nachricht ist, dass ich dann C aktivieren konnte, womit dann auch alle Einstellungen möglich waren.
Am Ende läuft nun der Maple mit den 3 Modulen.
Was mir bei Lacrosse noch aufgefallen ist, ist eine Abweichung bei der Frequenz. Scheinbar liegt mein CC1101 tatsächlich 50 kHz niedriger. Mit 868,3 MHz empfange ich nichts, aber bei 868,35 bekomme ich alle Sensoren. Alternativ könnte ich auch die Bandbreite erhöhen. DIe Frequenzänderung liefert aber ein besseres Signal. Im Gegensatz dazu läuft das gleiche Modul mit den Bresser Einstellungen ohne Frequenzanpassung. Allerdings habe ich noch nicht probiert, ob eine Erhöhung der Frequenz auch hier ein besseres Signal liefern würde.
Ich habe meine LaCrosse Einstellungen nun auf der Bank 3 abgelegt. Ich könnte jetzt theoretisch zwischen Bank 2 und 3 z.B. alle 20 Sekunden umschalten, um LaCrosse und Bresser über das selbe Modul zu empfangen. Funktioniert das auf Dauer?
ZitatDer Ausgabe nach wurde es erkannt und sollte wohl mit Bank 15 (0x0F) initialisiert werden.
Ich konnte es nachvollziehen. Da ist noch ein kleiner Bug in der Firmware, wenn das Modul C mit "CREC" enabled wird, bevor es gesteckt wird und es dann erst gesteckt wird, dann wird bei V C15 anstatt Ci ausgegeben.
Wenn das Modul erst enabled wird nachdem es gesteckt wird, dann funktioniert es korrekt.
ZitatIch könnte jetzt theoretisch zwischen Bank 2 und 3 z.B. alle 20 Sekunden umschalten, um LaCrosse und Bresser über das selbe Modul zu empfangen. Funktioniert das auf Dauer?
Ja, da beim Bank umschalten nichts ins EEPROM geschrieben wird, sollte es auf Dauer funktionieren.
Beim normalen Bank umschalten wird jedes mal der cc1101 zurückgesetzt und initialisiert.
Ich werde in der firmware noch eine optimierte Umschalteroutine einbauen, so wie sie bereits in der FSK Firmware für den Arduino drin ist:
ZitatEs werden die Register der alten und neuen Bank verglichen und dann nur die Differenz in die cc1101 Register geschrieben.
Zum Aktivieren wird nun nur noch der cc1101 in kurz den IDLE Modus konfiguriert.
Beim optimierten Bankwechsel wird ein "f" angehängt.
Z.B. b1f
In der aktuellen "V 4.2.2-dev220620" hab ich den bug beim radioDetekt gefixt und das optimierte wechseln der aktiven EEPROM Bank eingebaut:
https://github.com/Ralf9/SIGNALDuino/commit/902d8e3179b139fc66f9122d0e86a3fba92ac5f8
In der Anlage ist erstmal nur die Maple_sduino_USB Firmware
Gruß Ralf
Ich hab nun bei der aktuellen V4.2.2-dev220712 im github auch ein release Eintrag mit Firmware Dateien angelegt:
https://github.com/Ralf9/SIGNALDuino/releases/tag/V4.2.2-dev220712
https://github.com/Ralf9/SIGNALDuino/tree/dev-r422_cc1101
Gruß Ralf
Top. Vielen Dank :D 8)
Bei mir ist der Maple mit LAN zwar noch mit fliegender Verdrahtung experimentellerweise im Einsatz, aber das läuft schon richtig gut (noch mit zwei Radio-Endtöpfen ;) ). Bislang hatte ich die LAN-Version aus diesem Fred im Einsatz.
VG
rob
Hallo Ralf,
kannst du mir evtl. mal kurz helfen, wollte meinen SIGNALDuino eben mal updaten auf die aktuelle 4.2.2, hab mir die Dateien zum kompilieren runtergeladen, in PlatformIO kompiliert (alles ohne Fehler) und hänge nun beim hochladen, da kommt die Meldung:
Looking for upload port...
Auto-detected: COM3
Uploading .pio\build\Maple_sduino_LAN\Maple_sduino_LAN_422dev220819.bin
maple_loader v0.1
Resetting to bootloader via DTR pulse
Searching for DFU device [1EAF:0003]...
Reset via USB Serial Failed! Did you select the right serial port?
Assuming the board is in perpetual bootloader mode and continuing to attempt dfu programming...
dfu-util - (C) 2007-2008 by OpenMoko Inc.
Couldn't find the DFU device: [1EAF:0003]
This program is Free Software and has ABSOLUTELY NO WARRANTY
Hast du da eine Idee was ich gerade falsch mache? War da was mit Reset drücken beim hochladen?
Wenn man sich halt nicht alles notiert....
Danke schonmal, Gruß Markus
"Resetting to bootloader via DTR pulse" scheint nicht zu funktionieren.
Zum flashen gibts mehrere Möglichkeiten, ich flashe immer mit dfu-util
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_sduino_LAN_422dev220819.bin -R
Ich drücke immer kurz vor dem flashen die reset Taste, dabei ist das Timing wichtig.
Es gibt auch eine Tastenkombination mit der man den Maple in den Bootloader Modus bringen kann, das ist mir bis jetzt aber noch nicht gelungen.
Gruß Ralf
Hallo Ralf.
Der Bodenfeuchtesensor Opus xt300 scheint von dem sd Modul nicht mehr erkannt zu werden.
Habe den Signalduino auf esp32 Basis.
Der Sensor wurde von den originalen Modul erkannt sidey hatte sag Protokoll mit eingebaut.
Gruß Sascha
Bitte poste mal einige RAW Nachrichten die vom Opus empfangen werden.
Hallo Rald.
Hatte es damals hier als thread angelegt. Hoffe die Info´s reichen !
https://forum.fhem.de/index.php/topic,57734.0.html (https://forum.fhem.de/index.php/topic,57734.0.html)
Gruß
Sascha
P.S.:
Ich habe noch ein Signalduino mit WLAN Anbindung. Dieser erkennt nur Unknown Code vom OPUS Xt300.
Hier die Internals von dem Signalduino mit Wlananbindung
CFGFN ./FHEM/fhem.receiver.cfg
Clients :CUL_TCM97001:SD_WS:SD_WS09:Hideki:OREGON:CUL_EM:CUL_WS:CUL_TX:SD_AS:IT:FS10: :FS20:SOMFY:FLAMINGO:SD_WS_Maverick:SD_BELL:SD_GT:SD_RSL:SD_UT:CUL_FHTTK:FHT:RFXX10REC: :Revolt:Dooya:SD_Keeloq:Siro:LTECH:SIGNALduino_un:
ClientsKeepOrder 1
DEF 192.168.2.20:23
DMSG TXAEFC59059E
DevState initialized
DeviceName 192.168.2.20:23
EQMSGCNT 0
FD 7
FUUID 5d8e5c38-f33f-852e-c46f-86101352aec17855
FVERSION 00_SIGNALduino.pm:v3.4.14-s3414/2022-07-21
LASTDMSG TXAEFC59059E
LASTDMSGID 8
MSGCNT 11
NAME wlanduino433
NR 76
PARTIAL
RAWMSG MU;P0=-28888;P1=-4020;P2=491;P3=-160;P4=-7664;P6=-1087;P7=1311;D=12324262676267626262676262626262626767676267626267676267676767676267626267676262626262076767676267626762626267626262626262676767626762626767626767676767626762626767626262626207676767626762676262626762626262626267676762676262676762676767676762676262676762;CP=2;R=67;O;
RSSI -40.5
STATE opened
TIME 1661504255.79369
TYPE SIGNALduino
eventCount 2
rmsgRaw Mu;���;���;��;���;��;���;���;D2Bbgbgbbbgbbbbbbgggbgbbggbgggggbgbbggbbbbbgggbgbgbbbgbbbbbbgggbgbbggbgggggbgbbggbbbbbgggbgbgbbbgbbbbbbgggbgbbggbgggggbgbbggb;C2;R43;O;
sendworking 0
unknownmessages
version V 3.4.0-dev SIGNALduino cc1101 (chip CC1101) - compiled at Dec 4 2019 22:02:15
versionmodul v3.4.14-dev_ralf_21.07.
versionprotoL v3.4.14-dev_ralf_21.07.
DoubleMsgIDs:
MatchList:
01:IT ^i......
02:CUL_TCM97001 ^s[A-Fa-f0-9]+
03:SD_RSL ^P1#[A-Fa-f0-9]{8}
04:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
05:CUL_TX ^TX..........
06:SD_AS ^P2#[A-Fa-f0-9]{7,8}
07:Hideki ^P12#75[A-F0-9]+
09:CUL_FHTTK ^T[A-F0-9]{8}
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|114|118|121|123)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
31:KOPP_FC ^kr..................
32:PCA301 ^\S+\s+24
33:SD_Rojaflex ^P109#[A-Fa-f0-9]+
34:WMBUS ^b.*
35:HMS ^810e04......a001
36:IFB ^J............
37:LTECH ^P31#[A-Fa-f0-9]{26,}
90:SD_Tool ^pt([0-9]+(\.[0-9])?)(#.*)?
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2022-08-25 11:23:51 cc1101_config freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK)
2022-01-01 22:51:54 cc1101_patable C3E = 00 84 00 00 00 00 00 00 => 5_dBm
2022-08-26 07:57:35 ping OK
2022-08-26 10:52:02 state opened
2022-08-25 11:24:06 version V 3.4.0-dev SIGNALduino cc1101 (chip CC1101) - compiled at Dec 4 2019 22:02:15
keepalive:
ok 1
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
mnIdList:
msIdList:
1
3
3.1
4
6
13
13.2
15
17
23
25
33
33.1
33.2
35
49
51
55
65
68
74.1
87
88
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
31
32
36
37
38
39
40
44
44.1
45
48
50
56
59
60
61
62
64
66
67
69
70
71
72
73
74
79
80
84
85
89
94
rfmodesets:
rfmode Avantek_433__B8_N9_FSK,Bresser_5in1_u_7in1__B28_N7_8220,Bresser_6in1__B20_N7_8220,DP100_WH51_WH57_433__B16_N16_17241,DP100_WH51_WH57_868__B16_N6_17241,HoneywActivL__SlowRf_FSK,KOPP_FC__B20_N4_4785,Lacrosse_mode1_WS1080_TX38__B12_N1_17241,Lacrosse_mode2__B12_N2_9579,PCA301_mode3__B32_N3_6631,Rojaflex_433__B12_N8_GFSK,SlowRF_ccFactoryReset,W136__B24_N10_4798,WH24_WH25__B20_N1_17241,WMBus_S__N11_ab_firmware_V422,WMBus_T_u_C__N12_ab_firmw_V422,WS1600_TX22_mode5__B16_N5_8842,custom
rfmodesetsTesting:
rfmodeTesting Avantek_433__B5_N5_FSK,Bresser_5in1_u_7in1__B26_N7_8220,Bresser_6in1__B18_N7_8220,DP100_WH51_WH57_433__B14_N16_17241,DP100_WH51_WH57_868__B14_N6_17241,Elero__N13_ab_firmw_V335_u_V422,Lacrosse_mode1_TX38__B5_N1_17241,Lacrosse_mode1_WS1080_TX38__B10_N1_17241,Lacrosse_mode2__B5_N2_9579,PCA301_mode3__B12_N3_6631,W136__B24_N10_4798,WH24_WH25__B16_N1_17241,WS1600_TX22_mode5__B5_N5_8842
Attributes:
alias wlanduino433
devStateIcon opened:thum_up@lime closed|disconnected:cul_wlan@red
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
hardware nanoCC1101
icon cul_wlan@green
longids 1
room 99_receiver
updateChannelFW Ralf9
verbose 3
whitelist_IDs 1,3,3.1,4,6,8,9,10,11,12,13,13.1,13.2,15,16,17,17.1,18,19,21,22,23,24,25,26,27,28,31,32,33,33.1,33.2,35,36,37,38,39,40,43,44,44.1,45,47,48,49,50,51,52,55,56,57,58,59,60,61,62,64,65,66,67,68,69,70,71,72,73,74,74.1,79,80,84,85,87,88,89,94,96
ZitatHatte es damals hier als thread angelegt. Hoffe die Info´s reichen !
https://forum.fhem.de/index.php/topic,57734.0.html
Nein, das hilft leider nicht weiter.
Ist evtl die Entfernung vom Opus zum sduino zu groß?
Luftlinie ca. 4m mit einer Scheibe dazwischen.
Ich schaue mal bei Zeiten, was ich an Daten bekomme.
Gruß Sascha
Hallo Ralf.
Wird das Kompilieren via Arduino IDE noch unterstützt? Ich möchte gern für meinen Maple-Mini den LED-Pin ändern, um eine LED zum Gehäuse herauszuführen (die Onboard-LED ist so winzig, da kann ich nix dranlöten).
Habe den Ordner SIGNALduinoAdv wie hier beschrieben https://github.com/Ralf9/SIGNALDuino/tree/dev-r422_cc1101#getting-started (https://github.com/Ralf9/SIGNALDuino/tree/dev-r422_cc1101#getting-started) in meinen Sketch-Ordner kopiert und die SIGNALduinoAdv.ino geöffnet.
Zunächst kommen diese Hinweise:
"mbus_3outof6.cpp" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.
"mbus_3outof6.h" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.
"mbus_crc.cpp" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.
"mbus_crc.h" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.
"mbus_manchester.cpp" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.
"mbus_manchester.h" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.
"mbus_packet.cpp" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.
"mbus_packet.h" enthält unbekannte Zeichen. Wenn der Code mit einer älteren Version von Arduino erstellt wurde, sollten Sie eventuell über Werkzeuge -> Kodierung korrigieren & neu laden den Sketch auf UTF-8-Kodierung aktualisieren. Wenn nicht, sollten Sie die ungültigen Zeichen manuell entfernen, um diese Warnung zu deaktivieren.
Neu laden wie angegeben ändert aber nix. Ich habe die v.1.8.19.
Hab trotzdem mal kompiliert, dann geht es weiter mit:
SIGNALduinoAdv:181:51: fatal error: TimerOne.h: No such file or directory
#include <TimerOne.h> // Timer for LED Blinking
^
compilation terminated.
exit status 1
TimerOne.h: No such file or directory
Es gibt so eine Lib von Paul Stoffregen. Soll ich diese installieren oder woher sollte ich diese TimerOne besser holen?
Wenn die Arduino IDE nicht mehr unterstützt wird, würde ich notfalls zu VS-Code mit PlatformIO wechseln (ich mag das Zeug halt nicht so gern, da für mich total unübersichtlich/ überfrachtet, alles dunkel und immer, typisch Microsoft, irgendwas im Hintergrund rödelt).
Wunschgedanke: Wenn man den LED-Pin per "set raw ..." ändern könnte, müsste ich neue Versionen nicht mehr ändern + kompilieren. Aber wahrscheinlich nur schwer machbar und womöglich wäre ich der Einzige, der sich darüber freut ;)
Vielen Dank und beste Grüße
rob
Ja, das kompilieren via Arduino IDE wird unterstützt, ich kompiliere es damit auch.
ZitatSIGNALduinoAdv:181:51: fatal error: TimerOne.h: No such file or directory
#include <TimerOne.h> // Timer for LED Blinking
Die TimerOne.h wird vom Maple Mini und ESP nicht verwendet, was hast Du in der "compile_config.h" definiert?
Gruß Ralf
Zitat von: Ralf9 am 09 September 2022, 12:30:23
Ja, das kompilieren via Arduino IDE wird unterstützt, ich kompiliere es damit auch.
Sehr gut. Dann kann ich VS-Code noch etwas meiden ;D
Die Sourcen habe ich komplett unangetastet gelassen. Sollte ich da etwas auskommentieren?
Ah, wahrscheinlich schon, woher soll es sonst wissen, dass ich den MAPLE_SDUINO mit LAN-Modul möchte. Sorry, das hab ich nicht umrissen ::)
Habe testweise diese zwei aktiviert:
#define MAPLE_SDUINO 1
//#define MAPLE_CUL 1
//#define BLACK_BOARD 1 // 1 - USB, 2 - serial USART2 fuer ESP
//#define SIGNALESP32 1
//#define EVIL_CROW_RF 1
//#define ESP32_SDUINO_TEST 1
#define LAN_WIZ 1
Jetzt geht es weiter, doch leider schimpft er noch mit mir:
tools.h:85:38: error: 'eeprom_buffered_write_byte' was not declared in this scope
eeprom_buffered_write_byte(adr, val);
Habe ich noch etwas anderes nicht beachtet/ falsch?
VG
rob
Welchen core verwendest Du?
Ich habs gerade getestet.
Ich habe den aktuellen core 2.3.0 verwendet
Dazu habe ich unter zusätzliche Boardverwalter URLs:
https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
eingetragen.
In dem Bordverwalter ist es dann:
STM32 MCU based boards by STMicroelectronics
Perfekt! Das war noch der entscheidende Hinweis.
Ich hatte irgendwas altes noch drin, wo ich den Maple auch ansteuern konnte. Jetzt habe ich das richtige Board und den aktuellsten Core - wie Du geschrieben hast. Einstellungen habe ich aus diesem Post https://forum.fhem.de/index.php/topic,106278.msg1027914.html#msg1027914 (https://forum.fhem.de/index.php/topic,106278.msg1027914.html#msg1027914) übernommen. Nun läuft es durch.
Vielen lieben Dank für Deine geduldige Unterstützung :D
VG
rob
Mit "get sduino raw T" kannst Du Dir die core Version anzeigen lassen.
Ich hab die Beschreibung angepasst
Zitat von: Ralf9 am 28 Februar 2020, 17:59:48
Edit 09.09.22:
inzwischen gibts den core 2.3.0
dazu wird in der Arduino ide unter "zusätzliche Boardverwalter URLs" folgendes eingetragen:
https://github.com/stm32duino/BoardManagerFiles/raw/main/package_stmicroelectronics_index.json
wichtig, da beim core 2.x.x bei Serial noch ein bug ist, ist bei der Serial und USB Version der core 1.9.0 erforderlich
Es gibt für den core 2.x.x zwar ein workaround, dazu muß aber im core in einer Datei was geändert werden.
Beim core 1.9.0 kommt unter "zusätzliche Boardverwalter URLs" folgendes rein:
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
Danach im Boardverwalter nach STM32 filtern und den core installieren.
OT: Ich arbeite mit Linux Mint und dort gibt es die aktuelle IDE nur als Flatpak (Sandbox). Weil das Flashen direkt aus der IDE heraus nicht klappt, soll man lt. Wiki den Befehl mit sudo auf der CLI ausführen. Nur leider legt die IDE das Kompilat unter "/tmp//arduino_build_blabla" ab - innerhalb der Sandbox. Da kommt man einfach nicht dran.
Also die Arduino IDE gemäß dieser Anleitung https://docs.arduino.cc/software/ide-v1/tutorials/Linux (https://docs.arduino.cc/software/ide-v1/tutorials/Linux) nochmals lokal installiert, Sourcen erneut kompiliert, jetzt auch für den Host zugreifbar und per sudo den Befehl ausgeführt. Klappt sofort.
sudo ~/.arduino15/packages/STMicroelectronics/tools/STM32Tools/2.1.1/linux/maple_upload.sh ttyACM0 2 1EAF:0003 /tmp/arduino_build_788122/SIGNALduinoAdv.ino.bin
Bisher hatten mich die Flatpak-Dinger nicht gestört. Hier kommen aber zwei Dinge zusammen: Output-Pfad fürs Kompilat in der IDE nicht konfigurierbar und Sandbox gibt keinen Zugriff auf /tmp/...
Aber jetzt ist wieder alles gut :) Die externe LED blinkt im Versuchsaufbau fleißig und ich kann weiter machen.
VG
rob
Bei der IDE gibts auch bei Sketch den Menüpunkt "Kompilierte Binärdatei exportieren" dann ist die bin Datei im Sketchordner.
P.S.
Mich interessieren auch Rückmeldungen über WMBus, ab der Version 4.2.2 wird auch WMBus unterstützt.
Hat schon mal jemand getestet was mit den WMBus rfmodes alles empfangen wird?
Och menno, da siehst mal wieder was ich mich auskenne ::)
Hab mehrmals auf den Menüpunkt gehackt - ich erwartete irgendeine Art Datei-Speichern-Popup-Menü. Weil es scheinbar nix tat, tat ich es abhaken. Du hast natürlich recht, ich finde dort die gewünschte Binärdatei.
Mit welchen Gerätschaften bzgl. WMBus sollte man sich denn angesprochen fühlen?
Vielen Dank und beste Grüße
rob
ZitatMit welchen Gerätschaften bzgl. WMBus sollte man sich denn angesprochen fühlen?
Wasserzähler
Wärmezähler
PV Wechselrichter
u.a.
Hallo Ralf,
mal ne Frage. Ich habe bei mir den SIGNALDuino mit ranseyer´s Platine im Einsatz. Zur Zeit nur den 433MHz Empfänger aufgelötet, ich steuere damit lediglich meine Jarolift-Rollläden.
Ich hätte nun vor meine Wärmemengenzähler beim Austausch mit WMBUS auszustatten, was ja mittlerweile mit der Firmware geht. Ist es jetzt möglich das ich hier das 868MHz Modul einfach auflöte bzw. funktioniert WMBUS auf dem Modulplatz?
Falls ja was muss ich den speziell dafür konfigurieren, zur Zeit läuft bei mir die "Standard-Konfig"
Gruß Markus
Hallo Markus,
WMBus funktioniert auf den cc1101 Modulen A-C, aber nur auf einem Modul.
Es ist bei allen Modulplätzen egal ob Du ein 433 oder 868 MHz Modul auflötest.
Zum Aktivieren musst Du nur die entsprechende Registerkonfiguration (rfmode) übertragen.
Gruß Ralf
Hallo Ralf.
Ich hab jetzt endlich meinen Mapleduino auf der Hutschiene in Betrieb und die Signalduinos (434+868) + Jeelink außer Betrieb nehmen können. Funktioniert soweit alles supi :)
Ein Haar in der Suppe habe ich noch und hoffentlich nix überlesen: auf 433MHz habe ich ein paar Taster (IT V3; Smartwares), ansonsten ist der Maple nur mit Sensorik beschäftigt. Ein Tastendruck wird tw. erst nach 10-20 sec. ausgeführt.
Habe ich eine Möglichkeit es wieder so flink zu bekommen wie mit einem dedizierten S'duino@434? Der ganze andere Sensorik-Krams ist ja nicht so zeitkritisch, Taster leider doch.
Vielen Dank und beste Grüße
rob
ZitatEin Tastendruck wird tw. erst nach 10-20 sec. ausgeführt
Wird ein Tastendruck der IT Fernbedienung vom Signalduino erst verzögert erkannt
oder wird eine IT Steckdose nach einem Sendebefehl erst verzögert geschaltet?
Zitat von: Ralf9 am 10 Oktober 2022, 22:34:19
Wird ein Tastendruck der IT Fernbedienung vom Signalduino erst verzögert erkannt oder wird eine IT Steckdose nach einem Sendebefehl erst verzögert geschaltet?
Erstes. Beobachtet mit IT Taster und IT Fernbedienung.
Ich habe das mit einer Uhr nachgestellt: Uhr und FB nebeneinander. Erst alle 20 sec. off gedrückt und die nächste Minute alle 10 sec. - auf der FB wurde jeder kurze Tastendruck mit einer LED bestätigt.
Nebenher ließ ich den Event Monitor laufen, eingeschränkt auf die Taste der FB.
So schauts aus:
gedrückt um Monitor
08:30:00 2022-10-12 08:30:01 IT IT_00F0F0FFFF off
08:30:20 2022-10-12 08:30:25 IT IT_00F0F0FFFF off
2022-10-12 08:30:25 IT IT_00F0F0FFFF long
08:30:40 2022-10-12 08:30:57 IT IT_00F0F0FFFF off
2022-10-12 08:30:57 IT IT_00F0F0FFFF long
08:31:00 2022-10-12 08:31:03 IT IT_00F0F0FFFF off
08:31:10 2022-10-12 08:31:20 IT IT_00F0F0FFFF off
08:31:20 2022-10-12 08:31:29 IT IT_00F0F0FFFF off
2022-10-12 08:31:29 IT IT_00F0F0FFFF long
08:31:30 2022-10-12 08:31:30 IT IT_00F0F0FFFF off
08:31:40 2022-10-12 08:31:50 IT IT_00F0F0FFFF off
08:31:50 2022-10-12 08:32:00 IT IT_00F0F0FFFF off
2022-10-12 08:32:00 IT IT_00F0F0FFFF long
08:32:00 2022-10-12 08:32:01 IT IT_00F0F0FFFF off
Die Verzögerungen lassen sich ganz gut erkennen. Sie sind nicht gleich. So erlebe ich es auch beim Schalten mit dem Taster:
Raum betreten, An-Taste drücken, dauert - Licht an.
Aus-Taste drücken - Licht geht fast sofort aus.
erneut, An-Taste - Licht sofort an.
Aus-Taste drücken - dauert gefühlt 20 sec. - Licht aus.
(Die long-press Events sind so nicht richtig. Dürfte aber ein anderes Thema sein, das an der FB liegen dürfte.)
Meine Aktoren sind in keinem Fall IT-Geräte, sondern einmal SonOffs --> Wifi oder Zwave-Aktoren. Ich kenne den Verzögerungseffekt bei IT-Funk, wenn man Geräte mit selbem Medium indirekt steuert. Das dürften wir hier ausschließen können.
Antennen, Anschluss und Position sind beim Maple im Vergleich zu den S'duinos die selben. Wo vorher die 3 Geräte saßen, sitzt jetzt der Maple. Mit den dedizierten S'duinos hatte ich obiges Phänomen nicht. Die mussten sich ja auch nur um einen CC1101 kümmern ;)
Kurioserweise bekomme ich von meiner Wetterstation (WH1080@868) sehr viel öfter Daten, als mit dem S'duino zuvor, sodass ich am event-on-change-reading noch nachschärfen muss (mein SVG lädt etw. länger als vorher).
Der Maple schaltet doch zw. den Radios um, oder? Wir oft/ schnell macht er das? Bin ich der einzige mit dieser Beobachtung?
Wenn ich die Taster auf 434 priorisieren könnte, wäre das ggf. hilfreich. Der Krams, der über die anderen Radios kommt, ist eher Temperaturgedöns und nicht zeitkritisch. Zur Not müsste ich die Taster abschaffen oder den S'duino@434 zusätzlich wieder einsetzen :-\
Viele Grüße
rob
Mein Maple ist via LAN angebunden. Hier ein List:
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10: :CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:LaCrosse:KOPP_FC:PCA301:SD_Rojaflex:SD_Tool:SIGNALduino_un:
DEF 192.168.0.108:23
DMSG W84#035A1077F6
DevState initialized
DeviceName 192.168.0.108:23
EQMSGCNT 0
FD 132
FUUID 633f4a25-f33f-a385-7eb4-35ed20872e6bcde5
FVERSION 00_SIGNALduino.pm:v3.4.6-s347/2021-06-24
IDsNoDispatch 2,43.1,72.1,82
ITClock 250
LASTDMSG W84#035A1077F6
LASTDMSGID 84
LASTInputDev myMapleDuino
MSGCNT 109849
NAME myMapleDuino
NR 447
NR_CMD_LAST_H 1
PARTIAL
RAWMSG MU;P0=-22184;P1=329;P2=-922;P3=626;P4=248;P5=-609;P7=-252;CP=4;R=249;D=0123232324545454545453737453745373745374545454537454545454537373745373737373737374537373;e;
RSSI -77.5
STATE opened
TIME 1665557844.16277
TYPE SIGNALduino
a_ccconf b=0 rx=0 freq:868.400MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
b_ccconf b=1 rx=0 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100*]
c_ccconf b=2 rx=0 freq:868.350MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:17257.69Baud) [boffs=0140]
c_ccconfFSK ccmode=4 sync=2DD4 Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold) DEVIATN:88.867kHz
cc1101_frequency 433.920
eventCount 6310
myMapleDuino_DMSG P9#FF6A15100A2C44A0248B24
myMapleDuino_DMSGequal 2
myMapleDuino_MSGCNT 161
myMapleDuino_Protocol_ID 9
myMapleDuino_RAWMSG MU;P0=-32001;P1=497;P2=-978;P3=1462;CP=1;R=225;D=012121212121212123212123212321232323232123212321232323212323232323232323212321232323212321212323232123232321232321232123232323232323212323212323212323232123212123232123232123;e;
myMapleDuino_RSSI -89.5
myMapleDuino_TIME 2022-10-12 08:05:23
sendworking 0
unknownmessages
version V 4.2.2-dev220712 SIGNALduinoAdv LAN cc1101 (R: A0 B1* C2) - compiled at Sep 9 2022 17:18:59
versionmodul v3.4.7-ralf_24.06.
versionprotoL v3.4.7-ralf_24.06.
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|201)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
31:KOPP_FC ^kr..................
32:PCA301 ^\S+\s+24
33:SD_Rojaflex ^P109#[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
90:SD_Tool ^pt([0-9]+(\.[0-9])?)(#.*)?
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2022-10-09 02:11:46 state opened
XMIT_TIME:
1665553979.37612
getcmd:
keepalive:
ok 1
retry 0
mcIdList:
10
11
18
43
47
52
57
58
96
mnIdList:
100
101
102
103
107
108
109
112
msIdList:
1
3
3.1
4
7
13
13.2
14
15
17
20
23
25
32.1
33
33.1
33.2
41
49
51
54.1
55
65
68
74.1
90
91.1
93
106
muIdList:
8
9
13.1
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
44
44.1
45
46
48
49.1
49.2
50
54
56
59
60
61
62
64
66
67
69
70
71
73
74
79
80
81
83
84
85
86
89
91
92
94
95
97
98
99
104
105
110
111
200
201
rfmodesets:
rfmode Avantek_433_FSK,DP100_WH51_17241,HoneywActivL_SlowRf_FSK,KOPP_FC_4785,Lacrosse_mode1_17241,Lacrosse_mode2_9579,PCA301_mode3_6631,Rojaflex_433_GFSK,SlowRF_ccFactoryReset,WS1600_TX22_mode5_8842,bresser_5in1_8220
sendAslowrfID:
Attributes:
blacklist_IDs 0,0.1,0.2,0.3,0.4,0.5,6,12,16,35,42,53,87,88,72,78
verbose 0
Ping sagt:
ping -c 10 -D -i 0.5 192.168.0.108
PING 192.168.0.108 (192.168.0.108) 56(84) bytes of data.
[1665558124.632706] 64 bytes from 192.168.0.108: icmp_seq=1 ttl=128 time=0.362 ms
[1665558125.151034] 64 bytes from 192.168.0.108: icmp_seq=2 ttl=128 time=0.236 ms
[1665558125.662985] 64 bytes from 192.168.0.108: icmp_seq=3 ttl=128 time=0.250 ms
[1665558126.174987] 64 bytes from 192.168.0.108: icmp_seq=4 ttl=128 time=0.246 ms
[1665558126.686970] 64 bytes from 192.168.0.108: icmp_seq=5 ttl=128 time=0.235 ms
[1665558127.199045] 64 bytes from 192.168.0.108: icmp_seq=6 ttl=128 time=0.263 ms
[1665558127.711061] 64 bytes from 192.168.0.108: icmp_seq=7 ttl=128 time=0.282 ms
[1665558128.222961] 64 bytes from 192.168.0.108: icmp_seq=8 ttl=128 time=0.213 ms
[1665558128.735062] 64 bytes from 192.168.0.108: icmp_seq=9 ttl=128 time=0.228 ms
[1665558129.247058] 64 bytes from 192.168.0.108: icmp_seq=10 ttl=128 time=0.231 ms
--- 192.168.0.108 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 4614ms
rtt min/avg/max/mdev = 0.213/0.254/0.362/0.043 ms
Sollte eigentlich OK sein.
Die Firmware ist selbst kompiliert. Geändert ist aber nur der LED-Pin für eine externe LED (geändert auf Pin #1).
Das mit den Verzögerungen bei IT Fernbedienungen habe ich so noch nie gesehen.
Dies "IT_00F0F0FFFF" sieht nach IT V1 aus, ich habs bei mir mit einer IT V1 Fernbedienung auch mal getestet, ich habe keine Verzögerung.
Wenn Du bei fhem ein "set myMapleDuino close" machst, kann Du es Dir auch mit "telnet 192.168.0.108" anschauen.
Beim drücken der Taste müssten solche Nachrichten kommen:
MS;P1=-1105;P2=1030;P3=-414;P4=306;P5=-11204;D=45412341414141414141414141414141414141412341234123;CP=4;SP=5;R=82;e;b48;m0;
MS;P1=-1105;P2=1030;P3=-414;P4=306;P5=-11204;D=45412341414141414141414141414141414141412341234123;CP=4;SP=5;R=82;Q;e;m1;
MS;P1=-1105;P2=1030;P3=-414;P4=306;P5=-11204;D=45412341414141414141414141414141414141412341234123;CP=4;SP=5;R=82;Q;e;m2;
MS;P1=-1105;P2=1030;P3=-414;P4=306;P5=-11204;D=45412341414141414141414141414141414141412341234123;CP=4;SP=5;R=82;Q;e;m3;
Ist Dein Netzteil ok?
Die radios sind alle immer aktiv. Bei ASK/OOK löst jede Signalflanke einen Interrupt aus und bei FSK gehts über den FIFO des cc1101
Ich hätte eine Info erwartet á la "... muss so, weil er halt die Radios durchrotiert ..." o.ä. ;D
Nun nehme ich aber die wichtige Info mit: Darf so garnicht sein. Sehr gut. Also muss bei mir irgendwo das Problem sitzen.
Telnet habe ich gemacht. Die Nachrichten kommen quasi verzögerungsfrei.
Zitat von: Ralf9 am 12 Oktober 2022, 14:36:41
Ist Dein Netzteil ok?
Eigentlich schon. Hängen zwar ein paar Dinge dran, ist mit 12V/ 7,5A aber auch recht üppig leistungsfähig.
Mmmh, aber Du bringst auf etwas: Ich habe einen Step-Down zur Versorgung das Maple im Einsatz. Mit ein paar von denen hatte ich schon Probleme. (bei meinen MySensors@RFM868 wollten die RFM69HW ums Verrecken nicht arbeiten. Eine Diode sekundärseitig tat es dann)
Bei meinem Maple gibt es offensichtl. auch ein Problem, wenngleich es sich anders äußert. Vielleicht sind die RFM69HW empfindlicher als die CC1101?
Also Testaufbau mit Spannungsversorgung via USB direkt am Maple:
gedrückt um Monitor
20:54:20 2022-10-12 20:54:19 IT IT_00F0F0FFFF on
20:54:30 2022-10-12 20:54:29 IT IT_00F0F0FFFF on
20:54:30 2022-10-12 20:54:29 IT IT_00F0F0FFFF long
20:54:40 2022-10-12 20:54:39 IT IT_00F0F0FFFF on
20:54:40 2022-10-12 20:54:39 IT IT_00F0F0FFFF long
20:55:00 2022-10-12 20:54:59 IT IT_00F0F0FFFF on
20:55:00 2022-10-12 20:54:59 IT IT_00F0F0FFFF long
20:55:10 2022-10-12 20:55:09 IT IT_00F0F0FFFF on
20:55:20 2022-10-12 20:55:19 IT IT_00F0F0FFFF on
20:55:20 2022-10-12 20:55:19 IT IT_00F0F0FFFF long
20:55:30 2022-10-12 20:55:29 IT IT_00F0F0FFFF on
20:55:30 2022-10-12 20:55:29 IT IT_00F0F0FFFF long
* diesmal on, sonst wurd's arg dunkel ;)
Fazit: Es scheint tatsächlich an der Spannungsversorgung zu liegen. Also statt der 12V-Speisung den Stepdown raus und 5V direkt gespeist. Bis jetzt reagieren die Taster wieder wie vorher/ gewünscht 8) 8)
Werd' es noch beobachten, aber ich denke das könnte nun passen.
Vielen Dank für Deine Unterstützung.
Beste Grüße
rob
OK, falsch gedacht. Durch die schlechte Erfahrung mit den StepDowns habe ich denen wohl alles zugetraut ::)
Tatsächlich scheint ein Neustart des Maple den Unterschied zu machen. Zunächst reagiert er dann flink auf die IT-Nachrichten, aber nach wenigen Minuten kommen doch wieder die Verzögerungen.
Und weil ich gestern auf eine andere Energieversorgung umstellte, griff natürlich der Effekt. StepDown, verwendetes Netzteil - hab versch. getestet, macht alles keinen Unterschied. Ursache dann leider doch wieder unklar :(
Via telnet sehe ich ja die Nachrichten und würde den CC1101 als Ursache ausschließen. Habe trotzdem mit einem anderen Chip gegengeprüft: selbes Spiel.
Hab ich dann in meiner Config oder auf der Strecke zw. Maple und FHEM einen Bock? Mein FHEM läuft in einem Docker-Container. Also habe ich kurzerhand den Container geentert und von dort nochmal ping und telnet gemacht. Ping ist mit ca. 0.6ms etwas langsamer.
Die Nachrichten via telnet sind auch nicht ganz verzögerungsfrei. Wenn grad "Sprechpause" ist kommt es sofort - 4 Nachrichten m0 bis m3, wie Du geschrieben hast.
Aber bei best. anderen Nachrichten kommt nix durch oder es fehlen m2/m3. Schwer zu beschreiben.
MN;D=9E458045AAAAAA0000A3554B;R=30;
MN;D=9D458543E7AAAA0000B28994;R=240;
MU;P0=-1711;P1=370;P2=-871;P3=828;P4=247;P5=-615;P6=603;P7=-245;CP=4;R=247;D=0123232324545454545456767456745456745456745454567454545456745674545456745454545674567674;e;
MS;P0=-10151;P1=320;P4=-995;P5=969;P6=-336;D=10141414141456141414561414145614561456145614561414;CP=1;SP=0;R=27;p;b42;m0;
MS;P0=-10151;P1=320;P4=-995;P5=969;P6=-336;D=10141414141456141414561414145614561456145614561414;CP=1;SP=0;R=27;Q;p;m1;
MN;D=9E458045AAAAAA0000C4D86A;R=29;
MN;D=9E458045AAAAAA0000347724;R=30;
oder
MN;D=9F46043D1AAAAA0000CED0B5;R=242;
MN;D=DD458543E7AAAA000089858F;R=239;
MN;D=9E458045AAAAAA000053477E;R=30;
MS;P1=313;P2=-993;P4=968;P5=-354;P6=-10141;D=16121212121245121212451212124512451245124512451212;CP=1;SP=6;R=23;e;b49;m0;
MS;P1=313;P2=-993;P4=968;P5=-354;P6=-10141;D=16121212121245121212451212124512451245124545454545;CP=1;SP=6;R=23;e;m1;
MS;P1=313;P2=-993;P4=968;P5=-354;P6=-10141;D=161212121212451212124512121245124512451245454545451;CP=1;SP=6;R=23;Q;e;m2;
MN;D=9E458045AAAAAA000057F2BE;R=30;
MS;P1=305;P2=-1002;P4=967;P5=-343;P6=-10146;D=16121212121245121212451212124512451245124512451212;CP=1;SP=6;R=12;e;b49;m0;
MS;P1=305;P2=-1002;P4=967;P5=-343;P6=-10146;D=16121212121245121212451212124512451245124512451212;CP=1;SP=6;R=12;Q;e;m1;
MS;P1=305;P2=-1002;P4=967;P5=-343;P6=-10146;D=161212121212451212124512121245124512451245454545451;CP=1;SP=6;R=12;e;m2;
Nach besagtem Neustart sind die m0-m3 immer vollständig.
Auch keine heiße Spur, oder?
Nein ich hab auch keine Idee.
Ich hab auch ein Maplesduino mit LAN und 3 cc1101, ich kann es damit nicht nachvollziehen, ich habe keine Verzögerungen.
Es kann evtl auch probleme geben, wenn Dein fhem Server die Nachrichten übers LAN nicht schnell genug abholen kann
Hallo Ralf,
gibt es eine Version, die sowohl LAN auf dem MapleCUN unterstützt (wie die 4.1.2) als auch WMBus (wie die 4.2.2)? Auf GitHub hatte ich nur entweder oder gefunden, aber keine für beides.
Dazu noch eine andere Frage: Anscheinend habe ich einen MapleCUN erwischt, bei dem das Maple Board keinen USB-Anschluss hat. Wie würde ich denn in dem Fall überhaupt die Firmware flashen? Bootloader flashen über FTDI am Debug-Port mit stm32flash funktioniert. Bei dem MapleCUN scheint es sich um die Version MapleCUN Large 3.0 von Ranseyer zu handeln (die Beschriftung ist aber unter dem Maple).
Zitat von: Ralf9 am 14 Oktober 2022, 22:23:41
...hab auch ein Maplesduino mit LAN und 3 cc1101...
Womit machst Du bei Dir LAN, Wiz5500?
Sind Deine cc1101 alle die Stamp-Dinger, auch für 433MHz?
Ich hab mal getestet, ob ein taufrisches FHEM einen Unterschied macht. Nein, macht es nicht. Dann kann ich zumindest ausschließen, dass irgendwas in FHEM kurz blocked o.ä.
Wahrscheinlich muss ich peu a peu durchtesten: nur USB, ein Stamp, zwei Stamps usw. irgendwo muss doch der Unterschied herkommen...
ZitatWomit machst Du bei Dir LAN, Wiz5500?
Sind Deine cc1101 alle die Stamp-Dinger, auch für 433MHz?
Es ist auch ein Wiz5500 und es sind alle stamps
Vieleicht macht dies auch etwas aus? Ich habe bei der Arduino IDE bei Optimize "Fast (-O1)" verwendet.
Du kannst den Empfang der Module A-C auch einzeln deaktivieren und aktivieren
XQA / XEA
XQB / XEB
XQC / XECHallo xenos1984
ZitatAnscheinend habe ich einen MapleCUN erwischt, bei dem das Maple Board keinen USB-Anschluss hat.
Ist demnach beim MapleMini die USB Buchse abgebrochen?
Die Firmware müsste man eigentlich auch über den Debugport flashen können.
Für LAN auf dem MapleCUN gibts bis jetzt noch keine 4.2.2
Das Problem ist, die Ethernet Lib funktioniert nur auf SPI 1 aber beim MapleCUN ist das LAN auf SPI 2
Es gibt inzwischen ein Patch für die Ethernet Lib, der Pullrequest ist aber noch nicht durch
https://github.com/arduino-libraries/Ethernet/pull/134
https://github.com/KooLru/Ethernet/tree/spi2
Ich habe bei mir mal in der platformio.ini dies eingefügt, das bin File ist in der Anlage
[env:Maple_cul_LAN]
platform = https://github.com/platformio/platform-ststm32.git
;platform = ststm32
board = maple_mini_b20
board_build.core = STM32
board_build.variant = STM32F1xx/F103C8T_F103CB(T-U)
board_build.arduino.variant_h=variant_MAPLEMINI_F103CB.h
board_build.framework_extra_flags.arduino=-DARDUINO_MAPLEMINI_F103CB
framework = arduino
lib_deps = https://github.com/KooLru/Ethernet#spi2
build_flags =
-D PIO_FRAMEWORK_ARDUINO_SERIAL_DISABLED
-D MAPLE_CUL=1
-D LAN_WIZ=1
-D MAPLE_WATCHDOG=1Gruß Ralf
Zitat von: Ralf9 am 15 Oktober 2022, 18:22:45
Ist demnach beim MapleMini die USB Buchse abgebrochen?
Das könnte sein... Genau erkennen kann ich es nicht, die Seite ist aufgelötet.
Zitat
Die Firmware müsste man eigentlich auch über den Debugport flashen können.
Ja, in der Tat, so ging es:
stm32flash -w Maple_cul_LAN_422dev221015.bin -v -S 0x2000 -R /dev/ttyUSB2
Zitat
Ich habe bei mir mal in der platformio.ini dies eingefügt, das bin File ist in der Anlage
Danke - funktioniert! :)
Mal ne andere Frage blauäugig losgefragt: Z-Wave wäre mit Maple-Signalduino (z.B. via 3. Radio) nicht machbar, oder?
Ich frage so doof daher, weil es den ZWCUL im experimentellen Status gibt (https://wiki.fhem.de/wiki/ZWCUL (https://wiki.fhem.de/wiki/ZWCUL)) und ggf. doch etwas machbar wäre. Verschlüsselung habe ich eh nicht im Einsatz.
Vielen Dank und beste Grüße
rob
ZitatMal ne andere Frage blauäugig losgefragt: Z-Wave wäre mit Maple-Signalduino (z.B. via 3. Radio) nicht machbar, oder?
Ob das Einbauen von Z-Wave in den Maple-Signalduino machbar wäre, kann ich nicht abschätzen, mit Z-Wave habe ich mich noch nicht befasst.
Gibt es noch den Maple Mini? Wenn ich nach Maple Mini oder "STM32F103CBT6" bekomme ich entweder nackte Chips, oder Seiten, auf denen Maple Mini ausverkauft ist, oder aber Preise ab 20 EUR.
Ist das die Folge der Chipkrise, oder gibt es einen anderen Grund? Gibt es irgendwas besser Verfügbares, was pinkompatibel ist?
Ja, ist mir auch schon aufgefallen, seit einiger Zeit ist es sehr schwierig welche unter 19,99 zu bekommen.
Bei Aliexpress habe auch keine mehr gefunden.
Ab und zu gibts mal welche.
Hier habe ich gerade welche gefunden:
https://electropeak.com/leaflabs-maple-mini-stm32-32bit-arm
Bei AliExpress habe ich jetzt auch noch was gefunden, wenn auch nicht wirklich günstiger:
https://www.aliexpress.com/item/1005004778782583.html (https://www.aliexpress.com/item/1005004778782583.html)
Zitat von: mirko_s am 19 November 2022, 18:20:52
Das Gerät SIGNALduino spuckt beim klick auf Version folgendes aus:
version: V 4.2.2-dev220712 SIGNALduinoAdv cc1101 (R: B-*) - compiled at Nov 19 2022 17:00:52
Wie ich deiner Doku entnehmen kann ist wohl das 433Mhz Modul standardmäßig aktiv und die anderen 3 sind deaktiviert. Problem ist nun das ich mein CC1101 Modul nicht aktivieren kann.
Der Befehl (von https://wiki.fhem.de/wiki/Maple-SignalDuino#Inbetriebnahme.2FKonfiguration (https://wiki.fhem.de/wiki/Maple-SignalDuino#Inbetriebnahme.2FKonfiguration))
get SIGNALduino CREA liefert ein
Unknown argument CREA, choose one of ccconf:noArg ccpatable:noArg ccreg cmdBank cmds config:noArg freeram:noArg ping:noArg protocolIdToJson raw uptime:noArg version:noArg zAvailableFirmware:noArg
Kannst du mir sagen was hier das Problem sein könnte?
Im Wiki ist noch ein Fehler
Es muss heißen
get SIGNALduino raw CREA
Zitat von: Ralf9 am 19 November 2022, 18:36:13
Im Wiki ist noch ein Fehler
Es muss heißen
get SIGNALduino raw CREA
Hab's korrigiert ... und angenommen, dass das analog auch für die nächste Zeile (... CREC) gilt.
Du bist aber fix :)
Ja, das gilt für beide.
Die raw Befehle können entweder in FHEM mit "get sduino raw" oder z.B. im seriellen Monitor der Arduino IDE direkt eingegeben werden.
Ich werde den Abschnitt "Inbetriebnahme.2FKonfiguration" im wiki noch etwas überarbeiten:
Per default ist das Modul B und Bank 0 aktiv, da macht es dann Sinn das Modul B auf Bank 0 zu lassen,
und dann Modul A auf Bank 1
Zitat von: Ralf9 am 19 November 2022, 20:08:18
ich habe dort geanwortet, Du hast dies aber inzwischen selbst rausgefundensieht gut aus
Hast Du bei "CREA" in etwa die folgende Rückmeldung erhalten?
Wenn es bei Dir in der Nähe Slowrf Sensoren gibt, kannst Du mal testen ob Du mit dem rfmode slowrf was empfängst
Der Befehl
get SIGNALduino raw CREA lieferte:
raw: detect A: Partn=0 Ver=0x17Ich hab den Stick nun 2h mit rfmode WMBus_T_u_C laufen lassen, aber es kam kein Signal an.
Nach dem Umschalten auf SlowRF
set SIGNALduino rfmode SlowRF_ccFactoryResetkonnte ich erfolgreich meine 433Mhz Intertechno Lampen out of the box steuern. Auch habe ich plötzlich von einem CUL_TCM97001 die Außentemperatur empfangen. Das Signal hat mein alter nanoCUL433 nie empfangen. :)
Aber wie kann es denn sein das ein CC1101 mit 868MHz plötzlich 433 MHz Signale empfangen kann? Habe gerade noch mal den CC1101 gecheckt, da steht wirklich 868 MHz drauf. sehr komisch.....
1) gibt es Möglichkeiten irgendwas zu Debuggen? mein nanoCUL868 konnte die WMBus Signale immer erfolgreich empfangen. Von hier https://forum.fhem.de/index.php/topic,24517.msg869758.html#msg869758 habe ich die Firmware Datei von kaihs.
2) Wo finde ich eine Erklärung was es mit den "Bänken" auf sich hat? Modul A,B,C,D ist klar, das sind die CC1101 aber was ist eine Bank 0,1,2,3...
Mit "attr SIGNALduino verbose 4" müssten ungefähr solche MN-Nachrichten im log stehen:
MN;D=Y25442D2C492843571B168D20E7504D4122CD6877FC4AB6C08A2F7A9AB88C898C8B3FD9966B328FFB;N=12;
Evtl passt die Frequenz nicht ganz, Du kann die Frequenz mal in 0.05 Schritten ein wenig ändern
Mit einem 868 Modul kann auch 433 MHz empfangen werden, die Dämpfung ist dabei etwas höher
Ich hab im Wiki bei "Inbetriebnahme/Konfiguration" das Beispiel korrigiert und ein weiteres Beispiel zugefügt.
https://wiki.fhem.de/wiki/Maple-SignalDuino#Inbetriebnahme.2FKonfiguration
Zitatraw: detect A: Partn=0 Ver=0x17
Ver=0x17 ist die low cost Variante cc110L
https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/153153/cc110l-vs-cc1101
Zitat von: Ralf9 am 20 November 2022, 00:58:26
Ich hab im Wiki bei "Inbetriebnahme/Konfiguration" das Beispiel korrigiert und ein weiteres Beispiel zugefügt.
https://wiki.fhem.de/wiki/Maple-SignalDuino#Inbetriebnahme.2FKonfiguration
Ver=0x17 ist die low cost Variante cc110L
https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/153153/cc110l-vs-cc1101
Danke für den Hinweis mit der Low Cost Variante. Hat der Verkäufer mich schön reingelegt, bzw. was falsches verkauft. >:(
1) In deinem Wiki sind kleine Tippfehler drin. Kannst du bitte cmdbank in cmdBank ändern. Der Befehl scheint CaseSensitiv zu sein und cmdbank liefert eine Fehlermeldung. cmdBank funktioniert dagegen.
2) Das mit den Bänken ist mir immer noch unklar. Was bedeutet das?
3) Für WMBUS muss ich doch den rfmode WMBus_T_u_C nehmen? in deinem Beispiel steht aber SlowRF_CCFactoryReset in Verbindung 868MHz. Ist SlowRF nicht für die 433MHz Komponenten? oder ist das eine Einstellung die alles Empfangen kann aber nur auf eine bestimmte Frequenz hört?
4) in der FHEM GUI gibt es jadie Möglichkeit die cc1101_freq über ein Dropdown Feld auszuwählen. Wenn ich nun aber mehr als ein Radio installiert habe, auf welches Radio bezieht sich diese Einstellung dann? Wie wähle ich das Radio aus auf das sich diese Konfiguration bezieht?
5) Ich habe gerade noch mal komplett von vorne begonnen um jeglichen Fehler auszuschließen, und habe mich an das WIKI gehalten.
Hardware: ein CC110L in 868 MHz Ausführung auf der Platine von Ranseyer mit der V 4.2.2-dev220712 SIGNALduinoAdv Firmware:
get SIGNALduino raw e #reset Antwort: ccFactoryReset done
get SIGNALduino raw eC #reset Antwort: Init eeprom to defaults
shutdown restart #FHEM Neustart
get SIGNALduino cmdBank r #Config ausgeben Antwort: "leer"
get SIGNALduino raw CREA #aktiviert Radio A Antwort: raw: detect A: Partn=0 Ver=0x17Der nächste Befehl war
get SIGNALduino cmdBank A #selektiert Radio A Antwort: cmdBank: Error! radio has no bankAntwort: cmdBank: Error! radio has no bank Was hat das zu bedeuten?
gestern Abend stand in deinem WIKI noch dieses. Damit kam keine Fehlermeldung:
get SIGNALduino raw bA1 #den ersten CC1101 auswählen Antwort: raw: set r=A b=1 ccmode=0 sync=D391 ccconf=10B07157C43023B900070018146C070091 boffs=0100ist das gleichzusetzen mit dem "
get SIGNALduino cmdBank A" und "
get SIGNALduino cmdBank 1" Befehl?
die Ausgabe erscheint mir "richtig", nur die Frequenz passt nicht.
get SIGNALduino cmdBank r #Config ausgeben Antwort: cmdBank: A* b=1 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100*] ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)Auf den Befehl
set SIGNALduino rfmode WMBus_T_u_Ckommt überhaupt keine Antwort in FHEM. und
get SIGNALduino cmdBank r liefert danach das gleiche Ergebnis wie oben 433MHz..
EDIT: problem gefunden. Ich hatte "
update all https://raw.githubusercontent.com/Ralf9/RFFHEM/master/controls_ralf9_signalduino.txt"
anstatt "
update all https://raw.githubusercontent.com/Ralf9/RFFHEM/dev/controls_dev_ralf9_signalduino.txt"
Der Speicherbefehl hat danach geklappt.
get SIGNALduino raw bA1W #config speichern Antwort: raw: write set r=A b=1 N=12 ccmode=8 sync=543D ccconf=216BD05C040622F8440700182EBF4309B5 boffs=0100
jetzt finde ich im Logfile auch WMBus Einträge. juhuuuu. mal schauen ob die Daten korrekt interpretiert werden.
2022.11.20 11:06:57.881 4: SIGNALduino/KeepAlive not ok, retry = 1 -> get ping
2022.11.20 11:06:57.994 4: SIGNALduino/msg READ: OK
2022.11.20 11:06:57.994 4: SIGNALduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2022.11.20 11:06:58.294 4: SIGNALduino/HandleWriteQueue: nothing to send, stopping timer
2022.11.20 11:07:57.883 4: SIGNALduino/keepalive ok, retry = 0
2022.11.20 11:08:57.887 4: SIGNALduino/KeepAlive not ok, retry = 1 -> get ping
2022.11.20 11:08:58.000 4: SIGNALduino/msg READ: OK
2022.11.20 11:08:58.001 4: SIGNALduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2022.11.20 11:08:58.301 4: SIGNALduino/HandleWriteQueue: nothing to send, stopping timer
2022.11.20 11:09:10.997 4: SIGNALduino/msg READ: MN;D=X49449344077658121606CD03780DFF5F350082300000100007C113FF671BFF53720700BF2C67760500DF2A376407A41F00AE00CA00E600C9001D01AB00FB008F120C00BB005B008B00B3002F046D090BD42B123C82FE;N=12;
2022.11.20 11:09:11.000 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 210 length 173 RSSI = -75 LQI = 130 -> WMBUS C
2022.11.20 11:09:11.001 4: SIGNALduino ParseMN: ID=210 dmsg=b49449344077658121606CD03780DFF5F350082300000100007C113FF671BFF53720700BF2C67760500DF2A376407A41F00AE00CA00E600C9001D01AB00FB008F120C00BB005B008B00B3002F046D090BD42B123C82FE
2022.11.20 11:09:11.001 4: SIGNALduino Dispatch: b49449344077658121606CD03780DFF5F350082300000100007C113FF671BFF53720700BF2C67760500DF2A376407A41F00AE00CA00E600C9001D01AB00FB008F120C00BB005B008B00B3002F046D090BD42B123C82FE, dispatch
2022.11.20 11:09:57.892 4: SIGNALduino/keepalive ok, retry = 0
2022.11.20 11:10:57.894 4: SIGNALduino/KeepAlive not ok, retry = 1 -> get ping
2022.11.20 11:10:58.006 4: SIGNALduino/msg READ: OK
2022.11.20 11:10:58.006 4: SIGNALduino/msg READ: regexp=^OK$ cmd=ping msg=OK
2022.11.20 11:10:58.307 4: SIGNALduino/HandleWriteQueue: nothing to send, stopping timer
2022.11.20 11:11:04.441 4: SIGNALduino/msg READ: MN;D=X49449344409258121607D1FF780DFF5F350082A40000810007C113FF26BEFF10382300BF2C59771800DF2A15172379CA009701C4012202DB013D0262010D0280D43D01EB012E013F01AB012F046D090BD42B7D66870D;N=12;
2022.11.20 11:11:04.444 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 210 length 173 RSSI = -67.5 LQI = 135 -> WMBUS C
2022.11.20 11:11:04.445 4: SIGNALduino ParseMN: ID=210 dmsg=b49449344409258121607D1FF780DFF5F350082A40000810007C113FF26BEFF10382300BF2C59771800DF2A15172379CA009701C4012202DB013D0262010D0280D43D01EB012E013F01AB012F046D090BD42B7D66870D
2022.11.20 11:11:04.445 4: SIGNALduino Dispatch: b49449344409258121607D1FF780DFF5F350082A40000810007C113FF26BEFF10382300BF2C59771800DF2A15172379CA009701C4012202DB013D0262010D0280D43D01EB012E013F01AB012F046D090BD42B7D66870D, dispatch
2022.11.20 11:11:57.896 4: SIGNALduino/keepalive ok, retry = 0
2022.11.20 11:12:41.226 4: SIGNALduino/msg READ: MN;D=X49449344899158121607EA2A780DFF5F3500828600005E0107C113FF6934FF69123200BF2C14242700DF2A760032706A00230250021B022802220217023202FADA3F014702CB01C9001B012F046D0E0BD42B9DBF96E4;N=12;
2022.11.20 11:12:41.227 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 210 length 173 RSSI = -88 LQI = 150 -> WMBUS C
2022.11.20 11:12:41.228 4: SIGNALduino ParseMN: ID=210 dmsg=b49449344899158121607EA2A780DFF5F3500828600005E0107C113FF6934FF69123200BF2C14242700DF2A760032706A00230250021B022802220217023202FADA3F014702CB01C9001B012F046D0E0BD42B9DBF96E4
2022.11.20 11:12:41.228 4: SIGNALduino Dispatch: b49449344899158121607EA2A780DFF5F3500828600005E0107C113FF6934FF69123200BF2C14242700DF2A760032706A00230250021B022802220217023202FADA3F014702CB01C9001B012F046D0E0BD42B9DBF96E4, dispatch
2022.11.20 11:12:57.900 4: SIGNALduino/keepalive ok, retry = 0
2022.11.20 11:12:57.942 4: SIGNALduino/msg READ: MN;D=X49449344409258121607D1FF780DFF5F350082A400000F0007C113FFBDF7FF10382300BF2C59771800DF2A15172379CA009701C4012202DB013D0262010D0280D43D01EB012E013F01AB012F046D0B0BD42B0B06810A;N=12;
2022.11.20 11:12:57.945 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 210 length 173 RSSI = -69 LQI = 129 -> WMBUS C
2022.11.20 11:12:57.945 4: SIGNALduino ParseMN: ID=210 dmsg=b49449344409258121607D1FF780DFF5F350082A400000F0007C113FFBDF7FF10382300BF2C59771800DF2A15172379CA009701C4012202DB013D0262010D0280D43D01EB012E013F01AB012F046D0B0BD42B0B06810A
2022.11.20 11:12:57.947 4: SIGNALduino Dispatch: b49449344409258121607D1FF780DFF5F350082A400000F0007C113FFBDF7FF10382300BF2C59771800DF2A15172379CA009701C4012202DB013D0262010D0280D43D01EB012E013F01AB012F046D0B0BD42B0B06810A, dispatch
2022.11.20 11:13:13.939 4: SIGNALduino/msg READ: MN;D=X3944934440925812160752E87AA50000200C13103823004C135977186D0E00426CBF2CCC081315172300C2086CDFC2222A02BB560000326CFFFF046D0B0BD42B698F8209;N=12;
2022.11.20 11:13:13.942 4: SIGNALduino Parse_MN: Found 2-FSK Protocol id 210 length 137 RSSI = -69.5 LQI = 130 -> WMBUS C
2022.11.20 11:13:13.942 4: SIGNALduino ParseMN: ID=210 dmsg=b3944934440925812160752E87AA50000200C13103823004C135977186D0E00426CBF2CCC081315172300C2086CDFC2222A02BB560000326CFFFF046D0B0BD42B698F8209
2022.11.20 11:13:13.942 4: SIGNALduino Dispatch: b3944934440925812160752E87AA50000200C13103823004C135977186D0E00426CBF2CCC081315172300C2086CDFC2222A02BB560000326CFFFF046D0B0BD42B698F8209, dispatch
2022.11.20 11:13:15.081 4: SIGNALduino/msg READ: write set r=A b=1 N=12 ccmode=8 sync=543D ccconf=216BD05C040622F8440700182EBF4309B5 boffs=0100
2022.11.20 11:13:15.082 4: SIGNALduino/msg READ: regexp=.* cmd=raw msg=write set r=A b=1 N=12 ccmode=8 sync=543D ccconf=216BD05C040622F8440700182EBF4309B5 boffs=0100
2022.11.20 11:13:15.092 4: SIGNALduino/msg READ: mbus_init
2022.11.20 11:13:15.342 4: SIGNALduino/HandleWriteQueue: nothing to send, stopping timer
2022.11.20 11:13:57.902 4: SIGNALduino/keepalive ok, retry = 0
Ich werde es mal ein paar Stunden so laufen lassen.
ZitatDanke für den Hinweis mit der Low Cost Variante. Hat der Verkäufer mich schön reingelegt, bzw. was falsches verkauft
Auf die Versionsnr kann man sich nicht verlassen, es kann trotzdem ein cc1101 sein
ZitatIn deinem Wiki sind kleine Tippfehler drin. Kannst du bitte cmdbank in cmdBank ändern.
habs im Wiki geändert
Zitatin der FHEM GUI gibt es jadie Möglichkeit die cc1101_freq über ein Dropdown Feld auszuwählen. Wenn ich nun aber mehr als ein Radio installiert habe, auf welches Radio bezieht sich diese Einstellung dann? Wie wähle ich das Radio aus auf das sich diese Konfiguration bezieht?
Die Einstellungen beziehen sich auf das gerade selektierte cc1101 Modul und Speicherbank. Dies sieht man an "get cmdBank" oder am "*" bei "get version" oder "get cmdBank s".
ZitatDer nächste Befehl war "get cmdBank A" -> "Antwort: cmdBank: Error! radio has no bank"
Diese Fehlermeldung kommt, da dem Modul A noch keine Speicherbank zugeordnet ist, habs im Wiki korrigiert.
Zu den Speicherbänken, jede Bank hat einen Bereich im EEPROM. Bei "get cmdBank" wird die Adresse im EEPROM angezeigt. Z.B. Bank 6 [boffs=0240]
Änderungen an cc1101 Registern werden zum cc1101 gesendet und im EEPROM gespeichert, zB. bei Bank 6 im Addressbereich ab Hex 0240. Dabei gilt EEPROM Adresse = cc1101 Register + 2
Wenn z.B. mit "get cmdBank A3" die Bank gewechselt wird, wird der cc1101 zurückgesetzt und die cc1101 Register mit den im EEPROM gespeicherten Werte initialisiert.
Zitatjetzt finde ich im Logfile auch WMBus Einträge.
die Nachrichten passen
2022.11.20 11:48:38 4 : sduinoD/msg get raw: MN;D=X49449344409258121607D1FF780DFF5F350082A40000810007C113FF26BEFF10382300BF2C59771800DF2A15172379CA009701C4012202DB013D0262010D0280D43D01EB012E013F01AB012F046D090BD42B7D66870D;N=12;
2022.11.20 11:48:38 4 : sduinoD Parse_MN: Found 2-FSK Protocol id 210 length 173 RSSI = -67.5 LQI = 135 -> WMBUS C
2022.11.20 11:48:38 2 : autocreate: define WMBUS_QDS_12589240_22_7 WMBUS b494493...
2022-11-20 11:48:38 WMBUS WMBUS_QDS_12589240_22_7 RSSI: -67.5
2022-11-20 11:48:38 WMBUS WMBUS_QDS_12589240_22_7 LQI: 135
...
2022-11-20 11:48:38 WMBUS WMBUS_QDS_12589240_22_7 batteryState: ok
2022-11-20 11:48:38 WMBUS WMBUS_QDS_12589240_22_7 is_encrypted: 0
2022-11-20 11:48:38 WMBUS WMBUS_QDS_12589240_22_7 decryption_ok: 1 und
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 RSSI: -69.5
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 LQI: 130
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 1_type: VIF_VOLUME
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 1_storage_no: 0
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 1_value: 233.81
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 1_unit: m³
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 1_value_type: Instantaneous value
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 2_type: VIF_VOLUME
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 2_storage_no: 1
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 2_value: 187.759
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 2_unit: m³
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 2_value_type: Instantaneous value
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 3_type: VIF_TIME_POINT_DATE
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 3_storage_no: 1
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 3_value: 2021-12-31
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 3_unit:
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 3_value_type: Instantaneous value
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 4_type: VIF_VOLUME
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 4_storage_no: 257
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 4_value: 231.715
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 4_unit: m³
2022-11-20 11:51:53 WMBUS WMBUS_QDS_12589240_22_7 4_value_type: Instantaneous value
Zitat von: Ralf9 am 20 November 2022, 12:38:54
Zu den Speicherbänken, jede Bank hat einen Bereich im EEPROM. Bei "get cmdBank" wird die Adresse im EEPROM angezeigt. Z.B. Bank 6 [boffs=0240]
Änderungen an cc1101 Registern werden zum cc1101 gesendet und im EEPROM gespeichert, zB. bei Bank 6 im Addressbereich ab Hex 0240. Dabei gilt EEPROM Adresse = cc1101 Register + 2
Wenn z.B. mit "get cmdBank A3" die Bank gewechselt wird, wird der cc1101 zurückgesetzt und die cc1101 Register mit den im EEPROM gespeicherten Werte initialisiert.
ok, verstehe ich zum Teil. ;) Als COBOL Entwickler ist man Hardware Nahe Programmierung gewöhnt aber mit EPROMS musste ich mich noch nicht beschäftigen. Wozu braucht man ganz praktisch verschiedene Bänke? Kann man damit verschiedene Konfigurationen zu einem CC1101 abspeichern und bei Bedarf einfach laden und benutzen? Also z.b.: Radio 1, Bank 1 = 433.00Mhz, Radio 1, Bank 2 = 434.88 MHz, Radio 1, Bank 3 = ??? MHz??
Der erste Use Case mit dem Empfang der Wasserzähler und WMBus_T_u_C war mittlerweile erfolgreich. Ich konnte alle Zählerstände empfangen. perfekt!!!
Nun der zweite Use Case, Empfangen und Schalten von IT Geräten.
Out of the Box wurden die Geräte mittels autocreate angelegt, angezeigt und der Status on / off wurde korrekt in FHEM angezeigt. Nun wollte ich die über FHEM auch Schalten. Beim Klick auf das Lampen Symbol bekomme ich aber diese Meldung im Logfile:
2022.11.20 13:10:40.576 3: SIGNALduino IT_set: IT_V3_269df54b on
2022.11.20 13:10:40.581 4: SIGNALduino/set: sending via SendMsg: SR;R=6;P0=250;P1=-2500;P2=-1250;P3=-250;P4=-10000;D=010302020303020302020302030302020303020302020302030203030202030203020302030203030202030302020303020203030203020203020303020203020304;
2022.11.20 13:10:40.751 4: SIGNALduino SendrawFromQueue: msg=SR;R=6;P0=250;P1=-2500;P2=-1250;P3=-250;P4=-10000;D=010302020303020302020302030302020303020302020302030203030202030203020302030203030202030302020303020203030203020203020303020203020304;
2022.11.20 13:10:40.753 4: SIGNALduino/msg READ: Radio B is not active!
2022.11.20 13:10:40.753 4: SIGNALduino/msg READ: 2. Received answer (Radio B is not active!) for sendraw does not match ^S(R|C|M|N);
2022.11.20 13:10:42.754 4: SIGNALduino/HandleWriteQueue: sendraw no answer (timeout)
2022.11.20 13:10:42.754 4: SIGNALduino/HandleWriteQueue: nothing to send, stopping timer
2022.11.20 13:10:50.000 4: SIGNALduino/keepalive ok, retry = 0
Die Meldung "READ: Radio B is not active!" ist korrekt aber doch unverständich. Wieso will FHEM das Gerät über Radio B schalten wenn es doch vorher selber über Radio A angelegt wurde. Gibt es hier ein Problem mit dem Autocreate?
get SIGNALduino version
version: V 4.2.2-dev220712 SIGNALduinoAdv cc1101 (R: A1*) - compiled at Nov 19 2022 17:00:52Wenn ich mich recht erinnere bedeutet der * das dieses Radio/Bank als default genommen wird. Scheint FHEM aber beim schalten nicht wirklich zu interessieren ;D Oder ist das nur ein Problem weil ich einen 868MHz CC1101 verwende und nicht einen 434MHz CC1101?
und der dritte Use Case: Ich wollte schon einige Jahre lang die Temperatur von meinem Maverick ET-733 BBQ Thermometer empfangen. Der SIGNALduino schreibt jedes mal wenn der Maverick etwas sendet, ein Log. Aber es wird in FHEM kein Device angelegt. Muss ich für das Ding noch etwas ändern?
2022.11.20 13:38:45.042 4: SIGNALduino/msg READ: MU;P0=-319;P1=157;P3=410;P4=-631;P6=290;P7=-224;CP=1;R=227;D=0103014303410301410343014103014343434643437;e;
2022.11.20 13:38:45.049 4: SIGNALduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2022.11.20 13:38:45.051 4: SIGNALduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.11.20 13:38:45.053 4: SIGNALduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.11.20 13:38:45.054 4: SIGNALduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.11.20 13:38:45.056 4: SIGNALduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.11.20 13:38:45.057 4: SIGNALduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2022.11.20 13:38:45.060 4: SIGNALduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.11.20 13:38:45.062 4: SIGNALduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.11.20 13:38:45.065 4: SIGNALduino: Fingerprint for MU Protocol id 121 -> Busch-Transcontrol matches, trying to demodulate
2022.11.20 13:38:45.066 4: SIGNALduino: Fingerprint for MU Protocol id 200 -> Honeywell ActivLink matches, trying to demodulate
2022.11.20 13:38:56.822 4: SIGNALduino/msg READ: MU;P0=177;P1=133;P2=-4963;P5=389;P6=-617;P7=-359;CP=0;R=245;D=202020202020202565656565706075706075706565656560757061757065656075706075657060757065656565656565656560756565706565607570656075716565607570607520202020202020202565656565716175716;p;
2022.11.20 13:38:56.836 4: SIGNALduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2022.11.20 13:38:56.839 4: SIGNALduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.11.20 13:38:56.842 4: SIGNALduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.11.20 13:38:56.844 4: SIGNALduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.11.20 13:38:56.849 4: SIGNALduino: Fingerprint for MU Protocol id 79 -> wireless doorbell matches, trying to demodulate
2022.11.20 13:38:56.851 4: SIGNALduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.11.20 13:38:56.856 4: SIGNALduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2022.11.20 13:38:56.864 4: SIGNALduino: Fingerprint for MU Protocol id 91 -> Atlantic security matches, trying to demodulate
2022.11.20 13:38:56.884 4: SIGNALduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.11.20 13:38:56.888 4: SIGNALduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.11.20 13:38:56.893 4: SIGNALduino: Fingerprint for MU Protocol id 121 -> Busch-Transcontrol matches, trying to demodulate
2022.11.20 13:38:57.011 4: SIGNALduino/msg READ: MU;P0=-366;P1=210;P2=-692;P3=382;P4=-4956;CP=1;R=229;D=012321030123232103012103414141414141414143212;e;
2022.11.20 13:38:57.025 4: SIGNALduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2022.11.20 13:38:57.029 4: SIGNALduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.11.20 13:38:57.032 4: SIGNALduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.11.20 13:38:57.035 4: SIGNALduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.11.20 13:38:57.038 4: SIGNALduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.11.20 13:38:57.040 4: SIGNALduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2022.11.20 13:38:57.045 4: SIGNALduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.11.20 13:38:57.048 4: SIGNALduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.11.20 13:38:57.052 4: SIGNALduino: Fingerprint for MU Protocol id 121 -> Busch-Transcontrol matches, trying to demodulate
2022.11.20 13:38:57.074 4: SIGNALduino/msg READ: MU;P0=-597;P1=98;P2=-341;P3=401;P4=161;P6=-13026;CP=3;R=239;D=012321030303030423240423210303042324042303240423240303030303030303030423030324030304232403042324030304232404236;e;
2022.11.20 13:38:57.090 4: SIGNALduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2022.11.20 13:38:57.094 4: SIGNALduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.11.20 13:38:57.097 4: SIGNALduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.11.20 13:38:57.099 4: SIGNALduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.11.20 13:38:57.102 4: SIGNALduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.11.20 13:38:57.104 4: SIGNALduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2022.11.20 13:38:57.110 4: SIGNALduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.11.20 13:38:57.113 4: SIGNALduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.11.20 13:38:57.115 4: SIGNALduino: Fingerprint for MU Protocol id 111 -> TS-FT002 matches, trying to demodulate
2022.11.20 13:38:57.119 4: SIGNALduino: Fingerprint for MU Protocol id 121 -> Busch-Transcontrol matches, trying to demodulate
2022.11.20 13:39:08.772 4: SIGNALduino/msg READ: MU;P0=-196;P1=150;P2=-587;P3=397;P4=113;P5=-360;P6=-4468;CP=1;R=230;D=12323232324535121535123232153512153235121535123232323232323232321532323512323215351232153512323215351215361230;e;
2022.11.20 13:39:08.783 4: SIGNALduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2022.11.20 13:39:08.786 4: SIGNALduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.11.20 13:39:08.789 4: SIGNALduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.11.20 13:39:08.790 4: SIGNALduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.11.20 13:39:08.792 4: SIGNALduino: Fingerprint for MU Protocol id 78 -> BeSmart_Sx matches, trying to demodulate
2022.11.20 13:39:08.794 4: SIGNALduino: Fingerprint for MU Protocol id 79 -> wireless doorbell matches, trying to demodulate
2022.11.20 13:39:08.796 4: SIGNALduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.11.20 13:39:08.798 4: SIGNALduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2022.11.20 13:39:08.801 4: SIGNALduino: Fingerprint for MU Protocol id 91 -> Atlantic security matches, trying to demodulate
2022.11.20 13:39:08.803 4: SIGNALduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.11.20 13:39:08.806 4: SIGNALduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.11.20 13:39:08.808 4: SIGNALduino: Fingerprint for MU Protocol id 111 -> TS-FT002 matches, trying to demodulate
2022.11.20 13:39:08.811 4: SIGNALduino: Fingerprint for MU Protocol id 121 -> Busch-Transcontrol matches, trying to demodulate
2022.11.20 13:39:08.836 4: SIGNALduino/msg READ: MU;P0=-587;P1=153;P2=-343;P3=408;CP=1;R=231;D=012321030303030123210123210303012321012303212;e;
2022.11.20 13:39:08.846 4: SIGNALduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2022.11.20 13:39:08.849 4: SIGNALduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.11.20 13:39:08.851 4: SIGNALduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.11.20 13:39:08.853 4: SIGNALduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.11.20 13:39:08.855 4: SIGNALduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.11.20 13:39:08.857 4: SIGNALduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2022.11.20 13:39:08.859 4: SIGNALduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.11.20 13:39:08.860 4: SIGNALduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.11.20 13:39:08.863 4: SIGNALduino: Fingerprint for MU Protocol id 121 -> Busch-Transcontrol matches, trying to demodulate
2022.11.20 13:39:08.868 4: SIGNALduino/msg READ: MU;P0=-203;P1=159;P2=-363;P3=381;P4=-587;P6=-4160;CP=3;R=231;D=0123214343434343434343434123434321434341232143412321434341232141236;e;
2022.11.20 13:39:08.875 4: SIGNALduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2022.11.20 13:39:08.877 4: SIGNALduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.11.20 13:39:08.879 4: SIGNALduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.11.20 13:39:08.881 4: SIGNALduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.11.20 13:39:08.883 4: SIGNALduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.11.20 13:39:08.884 4: SIGNALduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2022.11.20 13:39:08.887 4: SIGNALduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.11.20 13:39:08.889 4: SIGNALduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.11.20 13:39:08.892 4: SIGNALduino: Fingerprint for MU Protocol id 121 -> Busch-Transcontrol matches, trying to demodulate
2022.11.20 13:39:08.966 4: SIGNALduino/msg READ: MU;P0=-1319;P1=-603;P2=392;P3=-354;P4=150;P7=32001;CP=4;R=233;D=121212123414323414323412121212143234143234121214323414321234143234121212121212121212143212123412121432341214370412121432341432;p;
2022.11.20 13:39:08.973 4: SIGNALduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2022.11.20 13:39:08.975 4: SIGNALduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.11.20 13:39:08.977 4: SIGNALduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.11.20 13:39:08.978 4: SIGNALduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.11.20 13:39:08.979 4: SIGNALduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.11.20 13:39:08.981 4: SIGNALduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2022.11.20 13:39:08.983 4: SIGNALduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.11.20 13:39:08.985 4: SIGNALduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.11.20 13:39:08.986 4: SIGNALduino: Fingerprint for MU Protocol id 111 -> TS-FT002 matches, trying to demodulate
2022.11.20 13:39:08.988 4: SIGNALduino: Fingerprint for MU Protocol id 121 -> Busch-Transcontrol matches, trying to demodulate
2022.11.20 13:39:09.064 4: SIGNALduino/msg READ: MU;P0=-122;P1=662;P2=-590;P3=400;P4=-342;P5=160;P6=-4408;P7=90;CP=5;R=231;D=01232323234525434525434523232323254345254345232325434525432345254345232323232323232323254323234523232543452325434523232543452543670;e;
2022.11.20 13:39:09.066 4: SIGNALduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2022.11.20 13:39:09.069 4: SIGNALduino: Fingerprint for MU Protocol id 19 -> minify matches, trying to demodulate
2022.11.20 13:39:09.071 4: SIGNALduino: Fingerprint for MU Protocol id 27 -> EFTH-800 matches, trying to demodulate
2022.11.20 13:39:09.077 4: SIGNALduino: Fingerprint for MU Protocol id 54 -> TFA 30.3233.01 matches, trying to demodulate
2022.11.20 13:39:09.079 4: SIGNALduino: Fingerprint for MU Protocol id 61 -> FS10 matches, trying to demodulate
2022.11.20 13:39:09.081 4: SIGNALduino: Fingerprint for MU Protocol id 70 -> FHT80TF matches, trying to demodulate
2022.11.20 13:39:09.084 4: SIGNALduino: Fingerprint for MU Protocol id 73 -> FHT80 matches, trying to demodulate
2022.11.20 13:39:09.085 4: SIGNALduino: Fingerprint for MU Protocol id 74 -> FS20 matches, trying to demodulate
2022.11.20 13:39:09.088 4: SIGNALduino: Fingerprint for MU Protocol id 80 -> EM1000WZ matches, trying to demodulate
2022.11.20 13:39:09.093 4: SIGNALduino: Fingerprint for MU Protocol id 82 -> Fernotron matches, trying to demodulate
2022.11.20 13:39:09.098 4: SIGNALduino: Fingerprint for MU Protocol id 95 -> Techmar matches, trying to demodulate
2022.11.20 13:39:09.099 4: SIGNALduino: Fingerprint for MU Protocol id 99 -> Navaris 44344.04 matches, trying to demodulate
2022.11.20 13:39:09.104 4: SIGNALduino: Fingerprint for MU Protocol id 111 -> TS-FT002 matches, trying to demodulate
2022.11.20 13:39:09.108 4: SIGNALduino: Fingerprint for MU Protocol id 121 -> Busch-Transcontrol matches, trying to demodulate
2022.11.20 13:39:12.048 4: SIGNALduino/keepalive ok, retry = 0
ZitatWozu braucht man ganz praktisch verschiedene Bänke? Kann man damit verschiedene Konfigurationen zu einem CC1101 abspeichern und bei Bedarf einfach laden und benutzen?
Ja es kann damit einfach zwischen den Bänken gewechselt werden. Es kann auch mit einem "doif" oder "at" automatisch z.B. alle 10 Min die Bank gewechselt werden.
ZitatDie Meldung "READ: Radio B is not active!" ist korrekt aber doch unverständich. Wieso will FHEM das Gerät über Radio B schalten wenn es doch vorher selber über Radio A angelegt wurde. Gibt es hier ein Problem mit dem Autocreate?
SIGNALduino/set: sending via SendMsg: SR;R=6;P0=...Mit dem Sendekommando "SR;..." wird immer über Radio B gesendet.
Zum Senden über Radio A gibts das Sendekommando "SRA;..."
Dafür gibts das Attribut "sendSlowRF_A_IDs":
ZitatHier können komma getrennt die protocolId angegeben bei denen das cc1101 Modul A zu senden verwendet wird
Zitat
und der dritte Use Case: Ich wollte schon einige Jahre lang die Temperatur von meinem Maverick ET-733 BBQ Thermometer empfangen. Der SIGNALduino schreibt jedes mal wenn der Maverick etwas sendet, ein Log.
Da passt irgendwas nicht. Bitte teste es nochmal wenn Du das 433 MHz Modul B hast
Nur ein kleiner Hinweis: im FHEMWiki wird unter Selbstbau CUL gezeigt, wie man an Hand der Beschaltung erkennen kann, für welche Frequenz das Modul ausgelegt ist. Im Anfang wurden meist 433MHz Module als 868MHz verkauft.
Ich habe im Januar von meinem Wasserversorger einen neuen Zähler Hydrus 2.0 eingebaut bekommen.
Der Zähler hat eine 868MHz Schnittstelle, die ich mit einem SignalDuino auf Basis eines ESP32 auslesen möchte.
Als Empfänger habe ich das CC1101 868 MHz Wireless Funk Modul (https://www.makershop.de/module/funk/cc1101-868-mhz/ (https://www.makershop.de/module/funk/cc1101-868-mhz/)) eingesetzt.
Die Registereinstellungen für
falsch: mbus_mode = WMBUS_SMODE
richtig: mbus_mode = WMBUS_TMODE des CC1101 habe ich aus dem TI-Dokument (https://www.ti.com/lit/an/swra234a/swra234a.pdf?ts=1674969785716&ref_url=https%253A%252F%252Fwww.google.com%252F (https://www.ti.com/lit/an/swra234a/swra234a.pdf?ts=1674969785716&ref_url=https%253A%252F%252Fwww.google.com%252F)) entnommen:
static const uint8_t initVal[] PROGMEM = // WMBus (S-Mode)
{
// IDX NAME RESET COMMENT
0x06, // 00 IOCFG2 29 GDO2 FIFO sync word has been sent / received
0x2E, // 01 IOCFG1 GDO1 Tri-State
0x00, // 02 IOCFG0 3F GDO0 00 rxFIFO is filled / 02 txFIFO is filled
0x07, // 03 FIFOTHR Bytes in FIFO
0x76, // 04 SYNC1 76 (rx) 54 (tx)
0x96, // 05 SYNC0 96 (rx) 76 (tx)
0xFF, // 06 PKTLEN 0F
0x00, // 07 PKTCTRL1
0x00, // 08 PKTCTRL0 45
0x00, // 09 ADDR
0x00, // 0A CHANNR
0x08, // 0B FSCTRL1 0F 203kHz IF Frquency
0x00, // 0C FSCTRL0
0x21, // 0D FREQ2 1E 868.3MHz Freq
0x65, // 0E FREQ1 C4
0x6A, // 0F FREQ0 EC
0x6A, // 10 MDMCFG4 8C bWidth 270kHz
0x4A, // 11 MDMCFG3 22 DataRate 32.73kHz
0x05, // 12 MDMCFG2 02 Modulation: 2-FSK, Manchester, 16/16 sync word bits detected
0x22, // 13 MDMCFG1 22
0xF8, // 14 MDMCFG0 F8 ChannelSpace: 50kHz
0x47, // 15 DEVIATN 47
0x07, // 16 MCSM2 07
0x30, // 17 MCSM1 30 Bit 3:2 RXOFF_MODE
0x18, // 18 MCSM0 04 Calibration: RX/TX->IDLE
0x2E, // 19 FOCCFG 36
0x6D, // 1A BSCFG
0x04, // 1B AGCCTRL2 03 42 dB instead of 33dB
0x09, // 1C AGCCTRL1 40
0xB2, // 1D AGCCTRL0 91 8dB decision boundery
0x87, // 1E WOREVT1
0x6B, // 1F WOREVT0
0xFB, // 20 WORCTRL
0xB6, // 21 FREND1
0x10, // 22 FREND0 16 0x11 for no PA ramping
0xEA, // 23 FSCAL3 A9 E9 ??
0x2A, // 24 FSCAL2 0A
0x00, // 25 FSCAL1 20 19 ??
0x1F, // 26 FSCAL0 0D
0x41, // 27 RCCTRL1
0x00, // 28 RCCTRL0
// 0x59, // 29 FSTEST
// 0x7F, // 2A PTEST
// 0x3F, // 2B AGCTEST
// 0x81, // 2C TEST2
// 0x35, // 2D TEST1
// 0x09 // 2E TEST0
};Mit diesen Einstellungen wird zwar etwas empfangen, aber beim 2.Byte schlägt das
ManchesterDecoding immer fehl.
Ich bin mir auch nicht sicher, wann der Zähler Hydrus 2.0 Daten sendet.
- Kann man den Zähler über die optische Schnittstelle zwingen, Daten zu senden?
- Wie kann ich erkennen, ob die empfangenen Daten von diesem Zähler stammen?
Das sind die Einstellungen in FHEM:
defmod sduino886 SIGNALduino 192.168.1.113:23
attr sduino886 addvaltrigger DMSG
attr sduino886 alias ESP17-868
attr sduino886 cc1101_frequency 868.35
attr sduino886 debug 1
attr sduino886 devStateIcon {my $devIcon = 'it_wifi@gray';;;;$devIcon='it_wifi@#F5830A' if (ReadingsVal($name,"state","disconnected") eq "opened");;;;"<div>".FW_makeImage("$devIcon","$devIcon")." </div><div>".ReadingsVal($name,"state","disconnected")." / ".ReadingsTimestamp($name,'ping','')."</td></div>"}
attr sduino886 eventlogging 1
attr sduino886 group Devices
attr sduino886 hardware ESP32cc1101
attr sduino886 icon icoESPEasy
attr sduino886 rawmsgEvent 1
attr sduino886 rfmode SlowRF
attr sduino886 room ESPEasy
attr sduino886 sortby 99
attr sduino886 suppressDeviceRawmsg 0
setstate sduino886 opened
setstate sduino886 2023-01-30 12:03:15 cc1101_config Freq: 868.300 MHz, Bandwidth: 270 kHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 32.73 kBaud
setstate sduino886 2023-01-30 12:03:15 cc1101_config_ext Modulation: 2-FSK, Syncmod: 15/16 + carrier-sense above threshold, Deviation: 47.61 kHz
setstate sduino886 2023-01-30 12:03:16 cc1101_patable C3E = 00 84 00 00 00 00 00 00
setstate sduino886 2023-01-29 10:39:09 cmds rxB=0
setstate sduino886 2023-01-28 20:21:58 config MS=1;;MU=1;;MC=1;;Mred=0 ;;MsMoveCountmax=4;;maxMuPrint=768;;maxMsgSize=1024;;maxNumPat=8;;Mdebug=1;;MdebFifoLimit=150/200
setstate sduino886 2023-01-16 22:56:54 freeram 269072
setstate sduino886 2023-01-30 12:28:15 ping OK
setstate sduino886 2023-01-30 12:03:14 state opened
setstate sduino886 2023-01-29 23:19:18 uptime 0 00:01:39
Welche Firmware verwendest Du?
Bei meiner V4.2.2 ist auch WMBUS dabei, es gibt dafür auch die passenden Registereinstellungen (rfmodes).
Du kannst es auch mal mit einem nanoCul testen
@killah78 hat hier ein hex File mit einem Buffer 220 gepostet
https://forum.fhem.de/index.php/topic,24517.msg915481.html#msg915481
Gruß Ralf
Hallo Ralf,
Danke für die schnelle Antwort.
Ich verwende die Firmware SIGNALDuino-WMBus-4.2.2-dev220712, die ich mit den Vorgaben der CC1101-Register für den S- und T-Mode angepasst habe.
Nachdem ich die CC1101-Register auf den T-Mode (aus dem o.g. TI-Dokument (https://www.ti.com/lit/an/swra234a/swra234a.pdf?ts=1674969785716&ref_url=https%253A%252F%252Fwww.google.com%252F) ) umgestellt habe, wird empfangen und dekodiert.
Hier ist eine Raw-Message, die vom ESP32-SignalDuino dekodiert wurde:
MN;D=4344A511750350727607264C8C0015900F002C25ABBE01001758C773AB17DB6F53217AAB00210710AA4A62C1FA42EEE3A3B0107E5D584DB7D8AC94C106084E2A005FF5164922D26C1C4224F12B848025;N=12;
Jetzt muss die Raw-Message noch in FHEM dekodiert werden.
Kannst Du mir bitte den Link auf die dazu verwendeten Datein schicken?
Danke!
2023.01.30 17:32:56.905 4: sduinoD/msg get raw: MN;D=4344A511750350727607264C8C0015900F002C25ABBE01001758C773AB17DB6F53217AAB00210710AA4A62C1FA42EEE3A3B0107E5D584DB7D8AC94C106084E2A005FF5164922D26C1C4224F12B848025;N=12;
2023.01.30 17:32:56.905 4: sduinoD Parse_MN: Found 2-FSK Protocol id 209 length 160 RSSI = -55.5 LQI = 128 -> WMBUS T
2023.01.30 17:32:56.905 4: sduinoD ParseMN: ID=209 dmsg=b4344A511750350727607264C8C0015900F002C25ABBE01001758C773AB17DB6F53217AAB00210710AA4A62C1FA42EEE3A3B0107E5D584DB7D8AC94C106084E2A005FF5164922D26C1C4224F12B848025
2023.01.30 17:32:56.905 4: sduinoD Dispatch: b4344A511750350727607264C8C0015900F002C25ABBE01001758C773AB17DB6F53217AAB00210710AA4A62C1FA42EEE3A3B0107E5D584DB7D8AC94C106084E2A005FF5164922D26C1C4224F12B848025, dispatch
2023.01.30 17:32:56.905 3: WMBUS Unknown device b4344A511750350727607264C8C0015900F002C25ABBE01001758C773AB17DB6F53217AAB00210710AA4A62C1FA42EEE3A3B0107E5D584DB7D8AC94C106084E2A005FF5164922D26C1C4224F12B848025, please define it
2023.01.30 17:32:56.909 2: autocreate: define WMBUS_DME_72500375_118_7 WMBUS b4344A511750350727607264C8C0015900F002C25ABBE01001758C773AB17DB6F53217AAB00210710AA4A62C1FA42EEE3A3B0107E5D584DB7D8AC94C106084E2A005FF5164922D26C1C4224F12B848025
2023.01.30 17:32:56.914 3: WMBUS_DME_72500375_118_7: I/O device is sduinoD
2023.01.30 17:32:56.915 2: autocreate: define FileLog_WMBUS_DME_72500375_118_7 FileLog ./log/WMBUS_DME_72500375_118_7-%Y-%m.log WMBUS_DME_72500375_118_7
2023-01-30 17:32:56.911 WMBUS WMBUS_DME_72500375_118_7 RSSI: -55.5
2023-01-30 17:32:56.911 WMBUS WMBUS_DME_72500375_118_7 LQI: 128
2023-01-30 17:32:56.915 Global global DEFINED WMBUS_DME_72500375_118_7
2023.01.30 17:34:32.704 2: WMBUS WMBUS_DME_72500375_118_7 Error during ApplicationLayer parse:encrypted message and no aeskey providedso wies aussieht brauchst Du auch noch den aeskey
Zitat
Kannst Du mir bitte den Link auf die dazu verwendeten Datein schicken?
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Hallo Ralf,
sind es die Dateien aus
https://github.com/Ralf9/RFFHEM/tree/dev,
d.h. die 00_SIGNALduino.pm mit v3.4.14?
Ich habe noch einen anderen SignalDUINO mit Firmware V 3.5.0 SIGNALESP cc1101 (chip CC1101) für meine Somfys laufen.
Gibt es da Probleme mit den neuen Dateien?
ja es sind diese mit v3.4.14-dev
ZitatIch habe noch einen anderen SignalDUINO mit Firmware V 3.5.0 SIGNALESP cc1101 (chip CC1101) für meine Somfys laufen.
Gibt es da Probleme mit den neuen Dateien?
Nein solange Du mit der V 3.5.0 kein FSK empfangen willst, sollte es keine Probleme geben.
Falls Du den SIGNALESP auch zum Empfang vom den Somfy Fernbedienungen verwendest, kann es sich durch optimierungen in meinen Dateien verbessern.
Hallo Ralf,
mit den Modulen aus v3.4.14-dev bekomme ich in FHEM folgende Fehlermeldung:
2023.01.30 18:52:52 1: DEBUG>sduino886: incoming message: (MN;D=4344A511750350727607264C8C001B900F002C2543C00100B9A5E23C370DFD0EDDE37A4300210710740FB904C401361F85F8DD65B3519537E0498BE0717BD65C708B5C60C44C62D30CC3290D022F8020;N=12;)
2023.01.30 18:52:52 1: DEBUG>sduino886: extracted data 4344A511750350727607264C8C001B900F002C2543C00100B9A5E23C370DFD0EDDE37A4300210710740FB904C401361F85F8DD65B3519537E0498BE0717BD65C708B5C60C44C62D30CC3290D022F8020
2023.01.30 18:52:52 1: DEBUG>sduino886: extracted xFSK Native Nr 12
2023.01.30 18:52:52 1: reload: Error:Modul 36_WMBUS deactivated:
Attempt to reload WMBus.pm aborted.
Compilation failed in require at ./FHEM/36_WMBUS.pm line 13.
BEGIN failed--compilation aborted at ./FHEM/36_WMBUS.pm line 13.
2023.01.30 18:52:52 0: Attempt to reload WMBus.pm aborted.
Compilation failed in require at ./FHEM/36_WMBUS.pm line 13.
BEGIN failed--compilation aborted at ./FHEM/36_WMBUS.pm line 13.
2023.01.30 18:52:52 0: ERROR: Cannot autoload WMBUS
2023.01.30 18:52:52 3: sduino886: Unknown code b4344A511750350727607264C8C001B900F002C2543C00100B9A5E23C370DFD0EDDE37A4300210710740FB904C401361F85F8DD65B3519537E0498BE0717BD65C708B5C60C44C62D30CC3290D022F8020, help me!
Die Module 36_WMBUS.pm und WMBus.pm sind auf dem aktuellen Stand.
Nach dem Kopieren der Module aus v3.4.14-dev habe ich die FHEM-Installation neu gestartet.
Fehlt mir sonst noch etwas?
vermutlich fehlt bei Dir davon was
# $Id: WMBus.pm 25166 2021-11-01 16:04:05Z kaihs $
package WMBus;
use strict;
use warnings;
use feature qw(say);
use Scalar::Util qw(looks_like_number);
use Digest::CRC; # libdigest-crc-perl
eval "use Crypt::Mode::CBC"; # cpan -i Crypt::Mode::CBC
my $hasCBC = ($@)?0:1;
eval "use Crypt::Mode::CTR"; # cpan -i Crypt::Mode::CTR
my $hasCTR = ($@)?0:1;
eval "use Digest::CMAC"; # cpan -i Digest::CMAC
Ja, es fehlte das package libdigest-crc-perl.
sudo apt-get install libdigest-crc-perl
Jetzt habe ich ein WMBUS device. ;)
Nun werde ich probieren, ob mir mein Versorger den AESkey herausrückt.
Nochmals DANKE für die schnelle Hilfe.
Hallo Ralf,
ich brauche mal deine Hilfe. Ich hab seit Jahren den MAPLESduino für 433 MHz im Einsatz, läuft tadellos.
Jetzt hab ich mir noch einen MAPLE mini zum spielen gekauft, ich habe hier auch noch eine MAPLECUL-Platine von Ranseyer rumliegen gehabt 868er Modul auf Radio A und 433er Modul auf Radio B.
Die habe ich jetzt geflasht mit der aktuellen Maple_cul_LAN_422dev20220712.bin, hat auch alles soweit funktioniert und läuft.
Nun ist das 433er Modul auf Radio B ja schon aktiviert und empfängt auch Daten.
Jetzt habe ich mit CREA das Modul auf A aktiviert, bekomme ich auch so angezeigt mit der Abfrage "V"
Bis hierhin alles klar.
Nun müsste ich doch mit "cmdBank A1" dem Radio A die Bank 1 zuordnen, dann mit "rfmode" einen rfmode einstellen. Ich wollte hier mal WMBUS probieren, was wäre denn hierfür einzustellen? Habe da leider nichts gefunden.
Gruß Markus
Hallo Markus,
Ich habe mit rfmode schlicht den WMBUS_T_u_C selektiert. Funktioniert mit meiner Wasseruhr perfekt :)
Gruß Reinhard
Hallo Reinhard,
vielen Dank für die Info. Keine Ahnung was sich da gestern nochmal aktualisiert hat, ich weiß aber das ich einige Male in die Auswahlliste vom rfmode geschaut habe und dort nie was mit WMBUS stand :(
Wie auch immer, die Einträge sind nun da, werde ich dann morgen mal so ausprobieren.
Gruß Markus
Hallo Markus,
evtl hast Du im rfmodeTesting geschaut
https://ralf9.github.io/SD_rfmode.html
Die rfmode für WMBUS gibts schon seit über einem Jahr.
Gruß Ralf
Zitat von: Ralf9 am 26 April 2023, 23:15:30Hallo Markus,
evtl hast Du im rfmodeTesting geschaut
https://ralf9.github.io/SD_rfmode.html
Die rfmode für WMBUS gibts schon seit über einem Jahr.
Gruß Ralf
Ja, das Problem sitzt halt oft vor dem Bildschirm ;)
heute wollte ich mal mein Maverick Thermometer aktivieren aber irgendwie bekomme ich keine Werte mehr. zuletzt hatte es im Dezember funktioniert.
Geändert habe ich an meinen maple nichts. Nur bin ich auf bullseye gewechselt seitdem.
weis jeztt nicht genau ob es zeitlich das richtige ist was ich mitgeschnitten habe, es funkt hier doch einiges durch die gegend:
2023.06.14 22:29:04 4: MapleSignalduino/msg READ: ␂MS;P0=245;P1=-4901;P3=478;P4=-516;P5=-278;D=013434343435040535040535043434340534343435043434053504053434350405343504053504343405350405343504340534343435040534343504053504053431;CP=0;SP=1;R=26;e;s12;m0;␃
2023.06.14 22:29:04 4: MapleSignalduino/msg READ: ␂MS;P0=245;P1=-4901;P3=478;P4=-516;P5=-278;D=013434343435040535040535043434340534343435043434053504053434350405343504053504343405350405343504340534343435040534343504053504053431;CP=0;SP=1;R=26;Q;e;s14;m1;␃
2023.06.14 22:29:04 4: MapleSignalduino/msg READ: ␂MS;P0=245;P1=-4901;P3=478;P4=-516;P5=-278;P6=32001;P7=-1263;D=013434343435040535040567043434340534343435043434053504053434350405343504053504343405350405343504340534343435040534343504053504053431;CP=0;SP=1;R=26;e;s14;m2;␃
2023.06.14 22:29:04 4: MapleSignalduino/msg READ: ␂MS;P0=245;P1=-4901;P3=478;P4=-516;P5=-278;P6=32001;P7=-1263;D=01343434343504053504053504343434053434343504343405350405343435040534350405350434340535040534350434053434343504053434350405350405343;CP=0;SP=1;R=26;e;s14;m3;␃
die Config die ich für den Empfänger b habe:
b_ccconf
b=2 rx=0 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0140]
Eine Idee wo ich suchen könnte ?
Wenn ich diese Nachrichten in eine Manchester Nachricht wandle bekomme ich
MC;LL=-516;LH=478;SL=-278;SH=245;D=AA99956A959A9A656696A9A99A;C=252;L=104;
Dies ergibt:
2023.06.15 23:08:50.170 4: sduinoD/msg get raw: MC;LL=-516;LH=478;SL=-278;SH=245;D=AA99956A959A9A656696A9A99A;C=252;L=104;
2023.06.15 23:08:50.170 4: sduinoD: Found manchester Protocol id 47 clock 252 -> Maverick
2023.06.15 23:08:50.170 5: sduinoD: dispatch P47#6A959A9A656696A9A99A
2023.06.15 23:08:50.170 4: sduinoD SD_WS_Maverick decoded protocolid: temp-food=26, temp-bbq=;
Bitte poste mal ein "get MapleSignalduino config"
Gruß Ralf
also ich bin einen mm weiter..
erstmal get config von modul B
config: MS=1;MU=1;MC=1;Mred=0_MScnt=4;maxMuPrint=768;maxMsgSize=1024;maxNumPat=8;Mdebug=1;MdebFifoLimit=150/170auch mit disable von syncedMS geht nichts:
config: MS=0;MU=1;MC=1;Mred=0_MScnt=4;maxMuPrint=768;maxMsgSize=1024;maxNumPat=8;Mdebug=1;MdebFifoLimit=150/170
Meinen alten Signalduino habe ich deswegen mal angeklemmt und hier bekomme ich Daten wenn ich MS=0 setze und bei MS=1 dann nicht mehr.
Wundert mich denn mit syncedMS ging es da damals ja auch...
Das get config passt.
Bitte poste mal die Nachrichten als MU-Nachrichten
config: MS=0;MU=1;MC=0;...
ok hier mal ein mitschnitt was so los ist :-)
023.06.16 00:09:34 4: MapleSignalduino/msg READ: ␂MU;P0=-15078;P1=477;P2=-986;P3=1461;P4=-30981;CP=1;R=4;D=012121212121212123212323212321232121212323212323232321212321232321232321232321232323232323232323232323232323232323232323232121232123212123232123232323212121232121232123212321412121212121;e;␃
2023.06.16 00:09:34 4: MapleSignalduino: Fingerprint for MU Protocol id 9 -> weatherID9 matches, trying to demodulate
2023.06.16 00:09:34 5: MapleSignalduino: Starting demodulation (Signal: (?:12|32){60,}(?:1|3)? Pos 1) length_min_max (60..120) length=87
2023.06.16 00:09:34 4: MapleSignalduino: last part pair=1 reconstructed, bit=1
2023.06.16 00:09:34 5: MapleSignalduino: dispatching bits: 1111111101001010111001000011010010010010000000000000000000000110101100100001110110101010 with anzPadding=1
2023.06.16 00:09:34 4: MapleSignalduino: decoded matched MU Protocol id 9 dmsg P9#FF4AE43492000006B21DAA length 87 RSSI = -72
2023.06.16 00:09:34 4: MapleSignalduino: equalDMS P9#FF4AE43492000006B21DAA (1)
2023.06.16 00:09:34 5: MapleSignalduino Dispatch: P9#FF4AE43492000006B21DAA, test ungleich: disabled
2023.06.16 00:09:34 4: MapleSignalduino Dispatch: P9#FF4AE43492000006B21DAA, -72 dB, dispatch
2023.06.16 00:09:34 5: MapleSignalduino: dispatch P9#FF4AE43492000006B21DAA
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_Parse0 msg=FF4AE43492000006B21DAA Bin=1111111101001010111001000011010010010010000000000000000000000110101100100001110110101010 syncp=1 length:88
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_Parse CRC_AUS:0
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_Parse_SHIFT_1 NOK raw:FF4AE43492000006B21DAA crc:230 -> shift
2023.06.16 00:09:34 5: MapleSignalduino: SD_WS09_SHIFT_1 bitdata: 1111111110100101011100100001101001001001000000000000000000000011010110010000111011010101 length:88
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_Parse_SHIFT_2 OK raw:FFA5721A49000003590ED5 msg:P9#FFA5721A49000003590ED5 crc:0
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_CRC_test2 rwa:FFA5721A49000003590ED5 msg:P9#FFA5721A49000003590ED5 CRC:0
2023.06.16 00:09:34 5: MapleSignalduino: SD_WS09_Parse_0 whid=1010
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_Parse_1 msg=10100101011100100001101001001001000000000000000000000011010110010000111011010101 length:80
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_Parse_2 WH1080 id:87, Windspeed bit: 00000000 Dec: 0.0
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_Parse_3 WH1080 id:87, Windguest bit: 00000000 Dec: 0.0
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_Parse_4 WH1080 id:87, Rain bit: 001101011001 Dec: 257.1
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_Parse_5 WH1080 id:87, bat:ok, temp=13.8, hum=73, winddir=14:NW wS=0.0, wG=0.0, rain=257.1
2023.06.16 00:09:34 4: MapleSignalduino: SD_WS09_Parse_19 WH1080 id:87 :10100101011100100001101001001001000000000000000000000011010110010000111011010101
2023.06.16 00:09:34 4: MapleSignalduino/msg READ: ␂MU;P0=-32001;P1=1454;P2=-983;P3=485;CP=3;R=4;D=012321232121232123212323232121232121212123232123212123212123212123212121212121212121212121212121212121212121212323212321232321212321212121232323212323212321232123;e;␃
2023.06.16 00:09:34 4: MapleSignalduino: Fingerprint for MU Protocol id 9 -> weatherID9 matches, trying to demodulate
2023.06.16 00:09:34 5: MapleSignalduino: Starting demodulation (Signal: (?:32|12){60,}(?:1|3)? Pos 1) length_min_max (60..120) length=81
2023.06.16 00:09:34 4: MapleSignalduino: last part pair=3 reconstructed, bit=1
2023.06.16 00:09:34 5: MapleSignalduino: dispatching bits: 010100101011100100001101001001001000000000000000000000011010110010000111011010101000 with anzPadding=3
2023.06.16 00:09:34 4: MapleSignalduino: decoded matched MU Protocol id 9 dmsg P9#52B90D24800001AC876A8 length 81 RSSI = -72
2023.06.16 00:09:34 4: MapleSignalduino: equalDMS P9#52B90D24800001AC876A8 (1)
2023.06.16 00:09:34 5: MapleSignalduino Dispatch: P9#52B90D24800001AC876A8, test ungleich: disabled
2023.06.16 00:09:34 4: MapleSignalduino Dispatch: P9#52B90D24800001AC876A8, -72 dB, dispatch
2023.06.16 00:09:34 5: MapleSignalduino: dispatch P9#52B90D24800001AC876A8
2023.06.16 00:09:34 3: MapleSignalduino: Unknown code P9#52B90D24800001AC876A8, help me!
2023.06.16 00:09:38 4: MapleSignalduino/msg READ: ␂MU;P0=-31793;P1=699;P2=-980;P3=980;P4=-493;P5=464;P6=146;P7=-10612;CP=3;R=222;D=12323232323232323232323232323232345254345254323452323254345254323452543452323232323254345232323232323254345232323254345232325434523232543234525434523232323232325434525434523254323452323232323232325434525434523232325432345254345232673232323232323232323232323232323234525434525432345232325434525432345254345232323232325434523232323232325434523232325434523232543452323254323452543452323232323232543452543452325432345232323232323232543452543452323232543234525434523260;e;␃
2023.06.16 00:09:38 4: MapleSignalduino: Fingerprint for MU Protocol id 9 -> weatherID9 matches, trying to demodulate
2023.06.16 00:09:38 5: MapleSignalduino: regex ((?:)((?:52|32){60,}(?:5|3)?)) did not match, aborting
2023.06.16 00:09:39 4: MapleSignalduino/msg READ: ␂MU;P0=272;P1=-2090;P2=462;P3=-1085;CP=2;R=219;D=012121032121212323232323232321232123232321232121210;e;␃
2023.06.16 00:09:41 4: MapleSignalduino/msg READ: ␂MN;D=5100E3370D7F0DF875FFFFFF006E2049;N=16;R=12;␃
2023.06.16 00:09:41 4: MapleSignalduino Parse_MN: Found 2-FSK Protocol id 107 length 32 -> WH51 DP100
2023.06.16 00:09:41 4: MapleSignalduino ParseMN: ID=107 dmsg=W107#5100E3370D7F0DF875FFFFFF006E2049
2023.06.16 00:09:41 5: MapleSignalduino Dispatch: W107#5100E3370D7F0DF875FFFFFF006E2049, test ungleich: disabled
2023.06.16 00:09:41 4: MapleSignalduino Dispatch: W107#5100E3370D7F0DF875FFFFFF006E2049, -68 dB, dispatch
2023.06.16 00:09:41 5: MapleSignalduino: dispatch W107#5100E3370D7F0DF875FFFFFF006E2049
2023.06.16 00:09:41 4: MapleSignalduino: SD_WS_Parse protocol 107, rawData 5100E3370D7F0DF875FFFFFF006E2049
2023.06.16 00:09:41 4: MapleSignalduino: SD_WS_Parse protocol 107, sum = ref = 110, CRC = 00
2023.06.16 00:09:41 4: MapleSignalduino: SD_WS_Parse decoded protocol-id 107 (WH51), sensor-id 00E337
2023.06.16 00:09:41 4: MapleSignalduino: using longid for 0 device SD_WS_107_H_00E337
2023.06.16 00:09:42 4: MapleSignalduino/msg READ: ␂MU;P0=32001;P1=233;P2=-10236;P4=-4901;P5=472;P6=-519;P7=-273;CP=1;R=10;D=12141414141414565656565716175716175716565656175656565716565617571617565716175657165656175716175657161757161756571617565657161756565656571617565414141414141414145656565657161757160;p;␃
2023.06.16 00:09:42 4: MapleSignalduino/msg READ: ␂MU;P0=-1263;P1=482;P2=-270;P3=224;P4=-514;P5=-4904;CP=3;R=10;D=012341414143214141412341414321234321412343214123414143212343214123432123432141234321414123432141414141234321415353535353535353514141414123432123432123414141432141414123414143212343214123432141234141432123432141234321234321412343214141234321414141412343214153535353535353535141414141234321234321234141414321414141234141432123432141234321412341414321234321412343212343214123432141412343214141414123432141;e;␃
2023.06.16 00:09:46 4: MapleSignalduino/msg READ: ␂MN;D=4344A511256109697607B4048C00DF900F002C25F3CE43008CEF55218118106B4D307AF30021071032C992DB46EE067D9136BA3C81AF9A6A2E5F8ED9398859E4693119BDEFDD1508628CBDA4906E91E4;N=12;␃
2023.06.16 00:09:46 4: MapleSignalduino Parse_MN: Found 2-FSK Protocol id 209 length 160 RSSI = -88 LQI = 145 -> WMBUS T
2023.06.16 00:09:46 4: MapleSignalduino ParseMN: ID=209 dmsg=b4344A511256109697607B4048C00DF900F002C25F3CE43008CEF55218118106B4D307AF30021071032C992DB46EE067D9136BA3C81AF9A6A2E5F8ED9398859E4693119BDEFDD1508628CBDA4906E91E4
2023.06.16 00:09:46 5: MapleSignalduino Dispatch: b4344A511256109697607B4048C00DF900F002C25F3CE43008CEF55218118106B4D307AF30021071032C992DB46EE067D9136BA3C81AF9A6A2E5F8ED9398859E4693119BDEFDD1508628CBDA4906E91E4, test ungleich: disabled
2023.06.16 00:09:46 4: MapleSignalduino Dispatch: b4344A511256109697607B4048C00DF900F002C25F3CE43008CEF55218118106B4D307AF30021071032C992DB46EE067D9136BA3C81AF9A6A2E5F8ED9398859E4693119BDEFDD1508628CBDA4906E91E4, dispatch
2023.06.16 00:09:46 5: MapleSignalduino: dispatch b4344A511256109697607B4048C00DF900F002C25F3CE43008CEF55218118106B4D307AF30021071032C992DB46EE067D9136BA3C81AF9A6A2E5F8ED9398859E4693119BDEFDD1508628CBDA4906E91E4
2023.06.16 00:09:46 5: WMBUS raw msg b4344A511256109697607B4048C00DF900F002C25F3CE43008CEF55218118106B4D307AF30021071032C992DB46EE067D9136BA3C81AF9A6A2E5F8ED9398859E4693119BDEFDD1508628CBDA4906E91E4
2023.06.16 00:09:46 3: WMBUS Unknown device b4344A511256109697607B4048C00DF900F002C25F3CE43008CEF55218118106B4D307AF30021071032C992DB46EE067D9136BA3C81AF9A6A2E5F8ED9398859E4693119BDEFDD1508628CBDA4906E91E4, please define it
2023.06.16 00:09:47 4: MapleSignalduino/msg READ: ␂MN;D=4344A511126009697607E91B8C00B6900F002C25C2D558004B5E494B37034A2F72127AC200210710EFFC8FCEF3F1C27CCBFE34A994006FCEC3C6164AE94D29006A015A4C6C41C7CA0BA1D63728A0810F;N=12;␃
2023.06.16 00:09:47 4: MapleSignalduino Parse_MN: Found 2-FSK Protocol id 209 length 160 RSSI = -66.5 LQI = 129 -> WMBUS T
2023.06.16 00:09:47 4: MapleSignalduino ParseMN: ID=209 dmsg=b4344A511126009697607E91B8C00B6900F002C25C2D558004B5E494B37034A2F72127AC200210710EFFC8FCEF3F1C27CCBFE34A994006FCEC3C6164AE94D29006A015A4C6C41C7CA0BA1D63728A0810F
2023.06.16 00:09:47 5: MapleSignalduino Dispatch: b4344A511126009697607E91B8C00B6900F002C25C2D558004B5E494B37034A2F72127AC200210710EFFC8FCEF3F1C27CCBFE34A994006FCEC3C6164AE94D29006A015A4C6C41C7CA0BA1D63728A0810F, test ungleich: disabled
2023.06.16 00:09:47 4: MapleSignalduino Dispatch: b4344A511126009697607E91B8C00B6900F002C25C2D558004B5E494B37034A2F72127AC200210710EFFC8FCEF3F1C27CCBFE34A994006FCEC3C6164AE94D29006A015A4C6C41C7CA0BA1D63728A0810F, dispatch
2023.06.16 00:09:47 5: MapleSignalduino: dispatch b4344A511126009697607E91B8C00B6900F002C25C2D558004B5E494B37034A2F72127AC200210710EFFC8FCEF3F1C27CCBFE34A994006FCEC3C6164AE94D29006A015A4C6C41C7CA0BA1D63728A0810F
2023.06.16 00:09:47 5: WMBUS raw msg b4344A511126009697607E91B8C00B6900F002C25C2D558004B5E494B37034A2F72127AC200210710EFFC8FCEF3F1C27CCBFE34A994006FCEC3C6164AE94D29006A015A4C6C41C7CA0BA1D63728A0810F
2023.06.16 00:09:54 4: MapleSignalduino/msg READ: ␂MU;P0=-270;P1=228;P2=-10303;P3=91;P4=-4908;P6=476;P7=-514;CP=1;R=6;D=12341414141414676767676017106017106017676767671060171060176767106017106760171067601767671060171067601710601767671067601710676767601767676767671414141414141414146767676760171060171060176767676710601710601767671060171067601710676017676710601710676017106017676710676017106767676017676767676714141414141414141467676767601710601710601767676767106017106017676710601710676017106760176767106017106760171060176767106760171067676760176767676767141414141414141414676767676017106017106017676767671060171060176767106017106760171067601767671060171067601710601767671067601710676767601767676767671;e;␃
2023.06.16 00:09:59 4: MapleSignalduino/keepalive ok, retry = 0
2023.06.16 00:10:03 4: MapleSignalduino/msg READ: ␂MN;D=4344A511126009697607E91B8C00B6900F002C25C3D558004E4D3EEA4DBD3E3D0CB07AC300210710311CCE2775DA605E3394B219113A5BC79F1CB093B0A85B69EF115B3DDFCB6AC0D50D0649C218810F;N=12;␃
2023.06.16 00:10:03 4: MapleSignalduino Parse_MN: Found 2-FSK Protocol id 209 length 160 RSSI = -66.5 LQI = 129 -> WMBUS T
2023.06.16 00:10:03 4: MapleSignalduino ParseMN: ID=209 dmsg=b4344A511126009697607E91B8C00B6900F002C25C3D558004E4D3EEA4DBD3E3D0CB07AC300210710311CCE2775DA605E3394B219113A5BC79F1CB093B0A85B69EF115B3DDFCB6AC0D50D0649C218810F
2023.06.16 00:10:03 5: MapleSignalduino Dispatch: b4344A511126009697607E91B8C00B6900F002C25C3D558004E4D3EEA4DBD3E3D0CB07AC300210710311CCE2775DA605E3394B219113A5BC79F1CB093B0A85B69EF115B3DDFCB6AC0D50D0649C218810F, test ungleich: disabled
2023.06.16 00:10:03 4: MapleSignalduino Dispatch: b4344A511126009697607E91B8C00B6900F002C25C3D558004E4D3EEA4DBD3E3D0CB07AC300210710311CCE2775DA605E3394B219113A5BC79F1CB093B0A85B69EF115B3DDFCB6AC0D50D0649C218810F, dispatch
2023.06.16 00:10:03 5: MapleSignalduino: dispatch b4344A511126009697607E91B8C00B6900F002C25C3D558004E4D3EEA4DBD3E3D0CB07AC300210710311CCE2775DA605E3394B219113A5BC79F1CB093B0A85B69EF115B3DDFCB6AC0D50D0649C218810F
2023.06.16 00:10:03 5: WMBUS raw msg b4344A511126009697607E91B8C00B6900F002C25C3D558004E4D3EEA4DBD3E3D0CB07AC300210710311CCE2775DA605E3394B219113A5BC79F1CB093B0A85B69EF115B3DDFCB6AC0D50D0649C218810F
2023.06.16 00:10:03 4: MapleSignalduino/msg READ: ␂MN;D=4344A511256109697607B4048C00DF900F002C25F4CE4300A3799D746AE6710D416C7AF400210710249F4A08EEA0EA181FD71BD6DE09EAB81A8C3E8EE2BD886CACA5D46EAF08633B7DC4903B3CB08FE0;N=12;␃
2023.06.16 00:10:03 4: MapleSignalduino Parse_MN: Found 2-FSK Protocol id 209 length 160 RSSI = -90 LQI = 143 -> WMBUS T
2023.06.16 00:10:03 4: MapleSignalduino ParseMN: ID=209 dmsg=b4344A511256109697607B4048C00DF900F002C25F4CE4300A3799D746AE6710D416C7AF400210710249F4A08EEA0EA181FD71BD6DE09EAB81A8C3E8EE2BD886CACA5D46EAF08633B7DC4903B3CB08FE0
2023.06.16 00:10:03 5: MapleSignalduino Dispatch: b4344A511256109697607B4048C00DF900F002C25F4CE4300A3799D746AE6710D416C7AF400210710249F4A08EEA0EA181FD71BD6DE09EAB81A8C3E8EE2BD886CACA5D46EAF08633B7DC4903B3CB08FE0, test ungleich: disabled
2023.06.16 00:10:03 4: MapleSignalduino Dispatch: b4344A511256109697607B4048C00DF900F002C25F4CE4300A3799D746AE6710D416C7AF400210710249F4A08EEA0EA181FD71BD6DE09EAB81A8C3E8EE2BD886CACA5D46EAF08633B7DC4903B3CB08FE0, dispatch
2023.06.16 00:10:03 5: MapleSignalduino: dispatch b4344A511256109697607B4048C00DF900F002C25F4CE4300A3799D746AE6710D416C7AF400210710249F4A08EEA0EA181FD71BD6DE09EAB81A8C3E8EE2BD886CACA5D46EAF08633B7DC4903B3CB08FE0
2023.06.16 00:10:03 5: WMBUS raw msg b4344A511256109697607B4048C00DF900F002C25F4CE4300A3799D746AE6710D416C7AF400210710249F4A08EEA0EA181FD71BD6DE09EAB81A8C3E8EE2BD886CACA5D46EAF08633B7DC4903B3CB08FE0
2023.06.16 00:10:03 3: WMBUS Unknown device b4344A511256109697607B4048C00DF900F002C25F4CE4300A3799D746AE6710D416C7AF400210710249F4A08EEA0EA181FD71BD6DE09EAB81A8C3E8EE2BD886CACA5D46EAF08633B7DC4903B3CB08FE0, please define it
2023.06.16 00:10:03 4: MapleSignalduino/msg READ: ␂MN;D=510103080F7F120087000000AF332049;N=16;R=40;␃
2023.06.16 00:10:03 4: MapleSignalduino Parse_MN: Found 2-FSK Protocol id 107 length 32 -> WH51 DP100
2023.06.16 00:10:03 4: MapleSignalduino ParseMN: ID=107 dmsg=W107#510103080F7F120087000000AF332049
2023.06.16 00:10:03 5: MapleSignalduino Dispatch: W107#510103080F7F120087000000AF332049, test ungleich: disabled
2023.06.16 00:10:03 4: MapleSignalduino Dispatch: W107#510103080F7F120087000000AF332049, -54 dB, dispatch
2023.06.16 00:10:03 5: MapleSignalduino: dispatch W107#510103080F7F120087000000AF332049
2023.06.16 00:10:03 4: MapleSignalduino: SD_WS_Parse protocol 107, rawData 510103080F7F120087000000AF332049
2023.06.16 00:10:03 4: MapleSignalduino: SD_WS_Parse protocol 107, sum = ref = 51, CRC = 00
2023.06.16 00:10:03 4: MapleSignalduino: SD_WS_Parse decoded protocol-id 107 (WH51), sensor-id 010308
2023.06.16 00:10:03 4: MapleSignalduino: using longid for 0 device SD_WS_107_H_010308
2023.06.16 00:10:04 4: MapleSignalduino/msg READ: ␂MU;P0=-691;P1=91;P2=-18425;P3=489;P4=-1952;P5=-967;P6=-4005;P7=379;CP=3;R=246;D=1232343435343535353535353535343535343434343434343434353535353535353536353434343434353435353535353535353435353434343434343434343535353535353535367534343434343534353535353535353534353534343434343434343435353535353535353675343434343435343535353535353535343535343434343434343434353535353535353536753434343434353435353535353535353435353434343434343434343535353535353535367534343434343534353535353535353534353534343434343434343435353535353535353675343434307;e;␃
2023.06.16 00:10:04 4: MapleSignalduino/msg READ: ␂MU;P0=-32001;P1=482;P2=-1943;P3=-974;P4=-3958;P6=1480;CP=1;R=246;D=01213131313131313131213131212121212121212121313131313131313141312121212121312131313131313131312131312121212121212121213131313131313131413121212121213121313131313131313121313121212121212121212131313131313131314131212121212131363131313131313131213131212121212121212121313131313131313141;e;␃
2023.06.16 00:10:04 4: MapleSignalduino: Fingerprint for MU Protocol id 9 -> weatherID9 matches, trying to demodulate
2023.06.16 00:10:04 5: MapleSignalduino: regex ((?:)((?:13|63){60,}(?:1|6)?)) did not match, aborting
2023.06.16 00:10:06 4: MapleSignalduino/msg READ: ␂MU;P0=-4906;P1=219;P3=471;P4=-529;P5=-283;CP=1;R=6;D=0101010101010343434343514153514153514343434341535141535143434153514153435141534351434341535141534351415351434341534351415343434351434343434341010101010101010103434343435141535141535143434343415351415351434341535141534351415343514343415351415343514153514343415343514153434343514343434343410101010101010101034343434351415351415351434343434153514153514343415351415343514153435143434153514153435141535143434153435141534343435143434343434101010101010101010343434343514153514153514343434341535141535143434153514153435141534351434341535141534351415351434341534351415343434351434343434341;e;␃
hab jetzt MS=1 wieder gesetzt da ich sonst von einen Thermometer nichts bekomme. Aber hilft wohl nichts mein mitschnitt.
Bin ratlos da es ja schon funktionierte.
Hab momentan auch keine Idee.
Mit welcher Firmware hat's schon mal funktioniert? Mit der aktuellen oder mit einer älteren?
Macht es einen Unterschied ob du ein oder zwei Temperaturfühler angeschlossen hast?
es hatte ja mit genau dieser Konfiguration funktioniert. Verstehe es nicht. Am Empfang kann es ja nicht liegen, nur das Linux selbst ist ja auf Bullseye gewandert mit ner frischen Installation. Schließe ich ebenfalls aus, da es mit dem normalen Signalduino ja funktioniert nur mit Maple nicht.
Habe jetzt nochmal den Empfänger B mit Bank 0 geladen und dann wieder mit Bank 2...
jetzt geht es mit den selben Einstellungen, allerdings nur wenn syncedMS disabled ist.. geht das nicht mit syncedMS auch ? Ging ja auch mal so.
Warum sich jetzt der Knoten gelöst hat ist rätselhaft... da die Bank 2 ja nicht verändert wurde.
Bitte teste mal folgendes ob sich da was ändert:
- nur "Sensor-1-food" angeschlossen
- nur "Sensor-2-bbq" angeschlossen
- beide Sensoren angeschlosenn
Unterstützt die Umsetzung von LaCrosse für Maple-SignalDuino auch die Umschaltung zwischen unterschiedlichen Datenraten? Mit dem JeeLink ist das so möglich:
ZitatBeispiel initCommands
6m 30t v
Zwischen 8.842 kbps und 9.579 kbps wechseln (4+2=6), alle 30 Sekunden
Wenn ja, wie kann man das konfigurieren, ich habe in der Doku keinen Hinweis darauf gefunden (oder übersehen)?
Eine Umschaltung ist möglich, dies geht aber nicht automatisch.
ZitatDas Wechseln der aktiven EEPROM Bank wurde optimiert (nur bei FSK, ccmode 1-4). Es werden nun die Register der alten und neuen Bank verglichen und dann nur die differenz in die cc1101 Register geschrieben.
Zum Aktivieren wird nun nur noch der cc1101 kurz den IDLE Modus konfiguriert.
Beim optimierten Bankwechsel wird ein "f" angehängt. Es wird die Anzahl der geänderten cc1101 Register zurückgegeben.
Wenn z.B. bei dem cc1101 A auf der Speicherbank 1 FSK mit einer Datenrate von 8.842 kbps und auf der Speicherbank 2 FSK mit einer Datenrate von 9.579 kbps ist,
kann z.B. mit einem DOIF zwischen den Speicherbänken gewechselt werden indem z.B. die folgenden Befehle abwechselt ausgeführt werden:
get sduino cmdBank A1f
get sduino cmdBank A2fGruß Ralf
Danke, das klingt schon mal gut.
Gibt es Erfahrungen, wie viel Last ich damit in FHEM erzeuge, wenn ich das alle 30s per DOIF machen lasse? Wäre es direkt in der SIGNALDuino-Firmware nicht ressourcenschonender?
Zitat von: Ralf9 am 04 Juli 2023, 00:53:44Bitte teste mal folgendes ob sich da was ändert:
- nur "Sensor-1-food" angeschlossen
- nur "Sensor-2-bbq" angeschlossen
- beide Sensoren angeschlosenn
das hatte ich alles schon probiert.. "weiße Flagge" ... fazit... wenn grillen.. entweder signalduino anstöpseln oder syncedMS ausknipsen..
Wenn Du einen Sensor ausgesteckt hast, hast Du dann jeweils eine Weile gewartet? Es kann evtl etwas dauern bis das erkannt wird.
Welche firmware hat der Signalduino?
ja hatte eine weile mit Verschiedenen settings gegrillt. Es wundert mich halt das es am 31.12. an Sylvester empfangen wurde. Aber mach dir jetzt keinen Kopf... das Fleisch ist schon verzehrt ;-)
V 4.2.2-dev220712 SIGNALduinoAdv cc1101 (R: A1 B2 C3 D4*) - compiled at Jul 13 2022 13:07:38
Mit welcher Hardware und Firmware funktionierts?
Mit welcher Hardware und Firmware funktionierts nicht?
mit dem Maple_sduino_USB gehts nicht da wo ich die 4 Empfänger drin habe.
Mit dem nanoCC1101 gehts.
Aber ich habe das mit dem Synced nicht verstanden muss ich ehrlich zugeben. Hat das dann mit der reihenfolge der Erkennung der Messages was zu tun ?
Du musst jetzt nicht mit Gewalt dich da reinhängen, hast ja schon sehr viel geleistet. Und es ist ja "auslaufmodell" das Maverick.
Bei Synced wird zuerst geprüft ob es am Anfang der Nachricht ein Sync gibt.
Wenn eine MS Nachricht erkannt wurde, wird nicht mehr geprüft ob es auch eine MC-Nachricht sein könnte.
Ich versuche einen Maple-Signalduino über LAN in Betrieb zu nehmen.
Aufbau:
- Platine von Ranseyer
- CC1101 433 MHz und CC1101 868 MHz
- Maple_sduino_LAN_422dev20220712.bin
- W5500 bis jetzt nur provisorisch gesteckt, nicht verlötet
- Stromversorgung über USB, Datenleitungen nicht verbunden
Beim PowerOn blinkt die LED auf dem Maple-Mini einige Male und geht dann aus. Die Link-LED (grün) des W5500 leuchtet dauerhaft, die Activity-LED (orange) blinkt. Trotzdem wird keine IP vom DHCP-Server gezogen. Habe ich irgendwas übersehen? Kann ich den W5500 verläßlich auf Funktion testen? Dann würde ich ihn auch verlöten, um Kontaktprobleme auszuschließen. Leider gibt es bei USR IOT keine Doku mehr zu dem Modul.
Wenn Du noch ein Maple Mini hast, kannst Du ihn auch zum Testen mit Dupont Kabeln mit dem W5500 verbinden.
Hi Ralf,
passt denn das Verhalten der Maple-LED? Bei der USB-Version leuchtet sie nämlich kontinuierlich im Betrieb, hier geht sie aus.
Kann mein W5500 irgendwelche komische IP voreingestellt haben, oder wird die allein durch die Signalduino-SW vorgegeben?
Edit: einen 2. nackten Maple-Mini habe ich leider nicht, habe nur 2 fertige Maple-Signalduinos hier. Aber ich habe noch einen 2. W5500, den ich eben auch auf die gleiche Art und Weise ausprobiert habe, mit dem gleichen Ergebnis. Kann man mit der LAN-Version noch irgendwie anders kommunizieren, als über den LAN-Port (Debug-Serial o.ä.)?
Zitatpasst denn das Verhalten der Maple-LED?
Ja, nach kurzem schnellen blinken geht sie aus, daran kann man aber nur erkennen, dass der Maple funktioniert.
Wenn Du die USB Firmware flasht, dann kannst Du mit "ri" die IP Adresse auslesen und ändern, eine 0 am Ende bedeutet, dass DCHP verwendet wird
https://forum.fhem.de/index.php?topic=106278.msg1049877#msg1049877
Zitat von: Ralf9 am 02 August 2023, 09:31:06Wenn Du die USB Firmware flasht, dann kannst Du mit "ri" die IP Adresse auslesen und ändern
OK, das ist also der Trick :) Hatte zwar schon den Beitrag gelesen, aber mich gefragt, wie ich überhaupt "
ri" eingeben kann.
Edit:- Ich konnte die LAN-Config mit der USB-FW auslesen, war aber korrekt DHCP eingestellt
- Ich habe den W5500 per (verlötete) Buchsenleiste drauf gesetzt, dann hat es auch mit der IP geklappt
Danke!
Hallo,
vielen Dank schon mal an dieser Stelle für die super Arbeit!!! :)
Ich habe seit einigen Tagen nun auch einen SignalDuino? am Start, weil:
- mich das schon immer interessiert hat (was "hier" so "rumfunkt"), ich aber bislang noch nicht dazu kam (auch weil ich dachte es wäre "kompliziert" ;) -> "Irrtum" 8) )
- ich schon ewig einen "nanoCUL433" rumliegen habe aber nie dazu kam was damit zu machen (433MHz hab ich alles rausgeworfen)
- ich für einen Bekannten (und nun wohl auch für mich ;) ) eine "Klingelerweiterung" machen soll/darf und da bin ich über einen simplen 433MHz Klingelsignalgeber gestossen und dachte mir, das probiere ich doch mal aus: läuft! :)
Aktuell habe ich also einen alten nanoCUL als SignalDuino in Betrieb mit diesem Klingeldingens: Graviers Funksignale Weiterleitung (https://www.amazon.de/dp/B09QL9BZYS)
Ist der Kleinste den ich so finden konnte.
Aktuell habe ich Homematic-Selbstbau (weil der fertige zu groß war) mit Batterie -> unschön...
Das ist dann für den Bekannten...
Da bei mir alle USB-Plätze belegt sind bzw. ich eigentlich nichts mehr dran stecken will habe ich mir einen SignalESP gebaut (aktuell noch Steckbrett), läuft auch prima! :)
Allerdings wäre mir LAN (noch) lieber! 8)
Bei der Suche bin ich hier bzw. hier https://forum.fhem.de/index.php?topic=106278.msg1049877#msg1049877 bzw. hier https://github.com/Ralf9/SIGNALDuino/commit/d1ff85c42cde949068411dc415225af8bf821c1e gelandet...
Allerdings habe ich ja "nur" einen (normalen) ESP32 und keinen Maple-irgendwas...
Von "Basteleien" mit Ahoy-DTU (ESP zum Auslesen von Hoymilles Wechselrichtern) habe ich noch einen W5500 "über" bzw. auch einen WT32-ETH01 (wollte ich eigentlich aber das ging mit Ahoy-DTU [noch] nicht)...
Sorry, lange Geschichte nun die Frage:
Kann ich einen SignalESP mit LAN bauen?
Wie muss ich den W5500 anschließen (gut ergibt sich aus der FW ;) )?
Gibt es bereits eine passende FW? -> wenn nein wo wie muss geändert angepasst werden, also kann ich eine "SignalESP.ino" nehmen und mich anhand der Version von git (mit LAN) irgendwie "durchkämpfen" versuchen?
Gruß, Joachim
ZitatKann ich einen SignalESP mit LAN bauen?
Wie muss ich den W5500 anschließen (gut ergibt sich aus der FW ;) )?
Ja, ein SignalESP mit LAN zu bauen sollte möglich sein.
An der Firmware sind aber größere Änderungen erforderlich:
- ich habe mal kurz gesucht und keine Möglichkeit gefunden, das WLAN abzuschalten
- der ESP32 hat 2 SPI (VSPI und HSPI).
Die cc1101 Module sind aktuell an VSPI angeschlossen. Da das LAN Modul auch an das VSPI angeschlossen wird, muss die PIN Belegung der cc1101 Module von VSPI auf HSPI geändert werden.
- es müssen auch noch einige Abfragen geändert werden:
u.a
#ifdef ESP32
#elif defined(ESP32)
Danke für die schnelle Antwort...
...so ganz bin ich (noch) nicht im Bilde :-\
Wifi abschalten, evtl.:
WiFi.mode(WIFI_OFF);
btStop();
https://github.com/espressif/arduino-esp32/issues/1077
Evtl. schaue ich auch mal bei AHOY-DTU, ob ich da im Code was finde...
Welche Code-Basis würde ich (am besten) nehmen?
Die Anpassungen aus dem git (also von hier: https://github.com/Ralf9/SIGNALDuino/commit/d1ff85c42cde949068411dc415225af8bf821c1e) müssen ja irgendwie (abgewandelt/angepasst?) rein?
Reicht das, neben umverdrahten (wobei ich habe ja noch Steckbrett und da geht das schnell) und anpassen der Pins?
Hat aber keine Eile, da ich aktuell nicht wirklich (viel) Zeit dafür habe/hätte...
...wollte nur mal wissen 8)
EDIT: stehe aber für Tests und "Schandtaten" bereit... Und mit einer guten Start-Basis bzgl. Code evtl. sogar für mehr...
Gruß, Joachim
Am einfachsten und schnellsten wird es gehen, wenn Du Dir für ca 10-12 Euro einen Maple Mini (STM32F103CBT6) kaufst.
Zitat von: Ralf9 am 02 August 2023, 17:21:13Am einfachsten und schnellsten wird es gehen, wenn Du Dir für ca 10-12 Euro einen Maple Mini (STM32F103CBT6) kaufst.
Danke für den Hinweis!
Ich dachte immer das Maple-... wäre so ein "Bausatz" mit vielen Funkmodulen usw.
Eieiei...
Aber klar, dann besorge ich mir so einen :)
Das hier:
Zitat von: Ralf9 am 02 August 2023, 16:20:36Die cc1101 Module sind aktuell an VSPI angeschlossen. Da das LAN Modul auch an das VSPI angeschlossen wird, muss die PIN Belegung der cc1101 Module von VSPI auf HSPI geändert werden.
gilt es zu tun?[/s]
EDIT: ich schliesse einfach mal so https://github.com/ranseyer/MapleSDuino bzw. https://github.com/ranseyer/MapleSDuino/blob/master/PCB-V09/Schematic.png an...
Und dann die "normale" Firmware drauf und läuft?
(DHCP ist ja Voreinstellung? )Ich nehme einfach mal was ich so finde ;)
Zitat von: https://wiki.fhem.de/wiki/Maple-SignalDuinoLAN und WLAN (ESP32)
Ist der Maple-SDuino per LAN oder ESP32-SDuino per WLAN in FHEM eingebunden so lautet das define
define <eigener-SIGNALduino-Name> SIGNALduino 192.168.0.244:23
Bei der LAN Version ist in der Grundeinstellung DHCP vom Maple-SignalDuino aktiviert. In älteren bereits kompilierten .bin Files ist die LAN Config voreingestellt auf IP=192.168.0.244 Gateway=192.168.0.1 Netzwerk-Maske=255.255.255.0
Danke!
EDIT: jetzt brauche ich nur noch so nen Maple Mini...
Gruß, Joachim
Hallo Ralf,
ich habe mal eine Frage an dich: Ich würde gerne meine MapleSduino eine andere IP zuweisen, bin zur Zeit daran meine IP-Adressen umzustrukturieren. Jetzt habe ich in der Fritzbox ihm eine andere IP zugewiesen und ihn neu gestartet, er behält aber immer die alte IP und bezieht keine neue. Gibt es da einen Trick wie ich ihm sagen kann er soll die IP-Adresse erneuern?
Gruß Markus
Hast du im maple eine statische ip oder DHCP konfiguriert?
Mit get raw ri kannst du es abfragen.
Wenn die ip mit 0 endet ist DHCP eingestellt
Halo Ralf,
ich glaube dann habe ich eine feste IP Adresse vergeben hab mal einen Screenshot von der Ausgabe von "ri" angehängt. Mein aktueller Versionsstand ist
V 4.2.0-dev210628 SIGNALduinoAdv LAN cc1101 (R: B0*) - compiled at Jul 3 2021 09:48:18
Muss mal schauen wo ich das in der Config einstellen kann mit dem DHCP oder kann ich das im laufenden Betrieb ändern? Evtl. werde ich dann auch gleich die aktuelle Version 4.2.2 draufspielen.
Gruß Markus
Hallo Ralf,
hab´s rausgefunden, hab mit Wia192.168.179.0 die IP-Adresse auf DHCP gestellt und dann über die Fritzbox eine neue zugewiesen, funktioniert einwandfrei.
Danke trotzdem für den Hinweis ;)
LG Markus
Zitat von: MadMax-FHEM am 03 August 2023, 10:42:30EDIT: jetzt brauche ich nur noch so nen Maple Mini...
Dank tndx habe ich jetzt einen MapleMini und eine Platine usw. :)
Hab alles mal zusammengesteckt: läuft auch mit LAN :)
Jetzt noch alles zusammenlöten und gut... 8)
Danke, Joachim
Guten Morgen,
mich hat wieder Bastelfieber gepackt, ich habe mir nun einen MapleSDuino zusammengebaut, für USB, mit je einem 433 und 866 MHz Stamp.
Der SDuino soll meinen 433 CUL und Jeelink ablösen.
Der CUL hat einen externen Thermometer empfangen und ein paar meiner IT-Komponenten gesteuert. Das mit dem Thermometer klappt nun auch mit dem SDuino, die IT-Komponenten können allerdings weder empfangen noch gesteuert werden. Da die Doku zum Sduino doch recht verteilt ist, kann sein, dass ich irgendwas übersehen habe, aber ich komme nicht darauf, was.
hier ist die cconf:
B: b=1 freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK [boffs=0100]
ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)
Als IODev bei den IT-Geräten ist mein MapleSDuino eingetragen.
Vielleicht könnt ihr mir einen Tipp geben
Der Thermometer der vom sduino empfangen wird, hat der auch 433.92 MHz?
Es gibt cc1101 Module mit ungenauem Quarz wo die Frequenz nicht genau passt.
Du kannst mal versuchen die bWidth etwas zu erhöhen.
Bei den IT devicees gibts das Attribut ITclock, evtl muss dies angepasst werden.
IT-Frequenzproblem (https://forum.fhem.de/index.php?action=dlattach;attach=60571;image)
Die Bandbreite bwidth ist eher dem Empfang zuzuorden.
IT-Steckdosen reagieren u.U. auf einer anderen Frequenz, wie eigentlich aufgedruckt ist.
Deren Fernbedienung sendet sehr breitbandig um alle Abweichler zu erwischen.
Ein Vorteil vom Cc1101 das Senden auf exakt der Frequenz,die sich aus den in den Registern eingestellt wurde und aus der Genauigkeit des verwendeten Quarzes und anderen Bauteiltoleranzen.
Das ist bei IT-Steckdosen nicht so vorteilhaft, da bei vielen Modellen überhaupt keine Antenne verbaut ist. Sie brauchen deshalb eine hohe Feldstärke des Sendesignals um sicher zu empfangen und durchzuschalten.
Außerdem können Antenne + Standort ebenfalls eine Rolle spielen.
Hier im Forum gibt es schon x Beispiele, wie man optimieren könnte...
Grüße
Jürgen
Hallo,
ich habe ja nun auch endlich meinen MapleMini mit LAN :)
Ziel war ja einen (diesen hier: https://www.amazon.de/dp/B09QL9BZYS) einfachen Klingelsensor zu empfangen.
Mit dem, den ich schon (für einen Bekannten) hatte und einem SignalDuino (Arduino Nano) hat das auch prima geklappt und läuft seit gestern auch "produktiv"...
...allerdings bei dem Bekannten...
Nun habe ich mir auch noch mal so einen Klingelsensor bestellt, kam gestern :)
Leider klappt das nicht, bzw. hat es genau einmal geklappt und es wurde ein ähnlicher IT_... angelegt.
(die Definition könnte ich aus dem Backup des Bekannten fischen, wenn das helfen würde)
Danach wurde aber nichts mehr empfangen bzw. im Log immer was von "faulty message" (wobei ich irgendwas mit unvollständige Nachricht im Kopf habe) und "unknown code" (wobei ich irgendwas mit "CRC fehlt" im Kopf hab) oder so ähnlich...
Ich glaube das ist eine solche Meldung (bin aber nicht wirklich sicher, ob die genau dazu gehört)
2023.08.18 22:22:07 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8039;P2=264;P3=-775;P4=779;P5=-258;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=37;Q;e;m1;
2023.08.18 22:22:07 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8039;P2=264;P3=-775;P4=779;P5=-258;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=37;Q;e;m2;
2023.08.18 22:22:07 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8039;P2=264;P3=-775;P4=779;P5=-258;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=37;Q;e;m3;
2023.08.18 22:22:08 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-813;P3=226;P4=781;P5=-248;P6=-8043;D=36323232323232323232454545324532323232454545323232;CP=3;SP=6;R=36;Q;e;m1;
2023.08.18 22:22:08 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-813;P3=226;P4=781;P5=-248;P6=-8043;D=36323232323232323232454545324532323232454545323232;CP=3;SP=6;R=36;Q;e;m2;
2023.08.18 22:22:08 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-813;P3=226;P4=781;P5=-248;P6=-8043;D=36323232323232323232454545324532323232454545323232;CP=3;SP=6;R=36;Q;e;m3;
2023.08.18 22:22:11 3: MapleDuinoLAN: Unknown code i007438, help me!
Dann habe ich meinen SignalESP genommen, mit dem hat der andere Klingelsensor auch funktioniert aber auch damit: nix.
(nur um sicher zu gehen, dass der MapleMini-Duino mit LAN auch tut / andere Dinge aus der Nachbarschaft werden empfangen, daher geht er wohl prinzipiell)
Gut, das angelegte Device gelöscht und den MapleDuino verbose auf 4...
Dann kommt beim Klingeln folgendes im Log (3x geklingelt glaube ich):
2023.08.18 22:29:03 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8045;P2=266;P3=-768;P4=795;P5=-255;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=37;O;b50;m0;␃
2023.08.18 22:29:03 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:03 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3 dmsg i007438 length 24 RSSI = -55.5
2023.08.18 22:29:03 4: MapleDuinoLAN IT: message "i007438" (7)
2023.08.18 22:29:03 4: MapleDuinoLAN IT: msgcode "0000F1F001D0" (12) bin = 000000000111010000111000
2023.08.18 22:29:03 3: MapleDuinoLAN: Unknown code i007438, help me!
2023.08.18 22:29:03 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8045;P2=266;P3=-777;P4=778;P5=-256;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=37;e;m1;␃
2023.08.18 22:29:03 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:03 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3 dmsg i007438 length 24 RSSI = -55.5
2023.08.18 22:29:03 4: MapleDuinoLAN: Dispatch, i007438, Dropped due to short time or equal msg
2023.08.18 22:29:03 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8045;P2=266;P3=-777;P4=778;P5=-256;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=37;Q;e;m2;␃
2023.08.18 22:29:03 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8045;P2=266;P3=-777;P4=778;P5=-256;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=37;Q;e;m2;
2023.08.18 22:29:03 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8045;P2=266;P3=-777;P4=778;P5=-256;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=37;Q;e;m3;␃
2023.08.18 22:29:03 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8045;P2=266;P3=-777;P4=778;P5=-256;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=37;Q;e;m3;
2023.08.18 22:29:04 4: MapleDuinoLAN: Read, msg: ␂MS;P2=-814;P3=220;P4=788;P5=-246;P6=-8040;D=36323232323232323232454545324532323232454545323232;CP=3;SP=6;R=34;e;b18;m0;␃
2023.08.18 22:29:04 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:04 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3 dmsg i007438 length 24 RSSI = -57
2023.08.18 22:29:04 4: MapleDuinoLAN: Dispatch, i007438, Dropped due to short time or equal msg
2023.08.18 22:29:04 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3.1 -> itv1_sync40
2023.08.18 22:29:04 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3.1 dmsg i007438 length 24 RSSI = -57
2023.08.18 22:29:04 4: MapleDuinoLAN: Dispatch, i007438, Dropped due to short time or equal msg
2023.08.18 22:29:04 4: MapleDuinoLAN: Read, msg: ␂MS;P2=-814;P3=220;P4=788;P5=-246;P6=-8040;D=36323232323232323232454545324532323232454545323232;CP=3;SP=6;R=34;Q;e;m1;␃
2023.08.18 22:29:04 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-814;P3=220;P4=788;P5=-246;P6=-8040;D=36323232323232323232454545324532323232454545323232;CP=3;SP=6;R=34;Q;e;m1;
2023.08.18 22:29:04 4: MapleDuinoLAN: Read, msg: ␂MS;P2=-814;P3=220;P4=788;P5=-246;P6=-8040;D=36323232323232323232454545324532323232454545323232;CP=3;SP=6;R=34;Q;e;m2;␃
2023.08.18 22:29:04 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-814;P3=220;P4=788;P5=-246;P6=-8040;D=36323232323232323232454545324532323232454545323232;CP=3;SP=6;R=34;Q;e;m2;
2023.08.18 22:29:04 4: MapleDuinoLAN: Read, msg: ␂MS;P0=-1765;P2=-814;P3=220;P4=788;P5=-246;P6=-8040;P7=32001;D=36323232323232323270454545324532323232454545323232;CP=3;SP=6;R=34;e;m3;␃
2023.08.18 22:29:04 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:04 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3.1 -> itv1_sync40
2023.08.18 22:29:06 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8052;P2=274;P3=-768;P4=797;P5=-238;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=35;O;b50;m0;␃
2023.08.18 22:29:06 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:06 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3 dmsg i007438 length 24 RSSI = -56.5
2023.08.18 22:29:06 4: MapleDuinoLAN IT: message "i007438" (7)
2023.08.18 22:29:06 4: MapleDuinoLAN IT: msgcode "0000F1F001D0" (12) bin = 000000000111010000111000
2023.08.18 22:29:06 3: MapleDuinoLAN: Unknown code i007438, help me!
2023.08.18 22:29:06 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8044;P2=267;P3=-764;P4=789;P5=-249;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=35;O;m1;␃
2023.08.18 22:29:06 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:06 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3 dmsg i007438 length 24 RSSI = -56.5
2023.08.18 22:29:06 4: MapleDuinoLAN: Dispatch, i007438, Dropped due to short time or equal msg
2023.08.18 22:29:06 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8045;P2=264;P3=-781;P4=778;P5=-254;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=35;O;m2;␃
2023.08.18 22:29:06 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:06 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3 dmsg i007438 length 24 RSSI = -56.5
2023.08.18 22:29:06 4: MapleDuinoLAN: Dispatch, i007438, Dropped due to short time or equal msg
2023.08.18 22:29:06 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8047;P2=262;P3=-782;P4=785;P5=-246;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=35;O;m3;␃
2023.08.18 22:29:06 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:06 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3 dmsg i007438 length 24 RSSI = -56.5
2023.08.18 22:29:06 4: MapleDuinoLAN: Dispatch, i007438, Dropped due to short time or equal msg
2023.08.18 22:29:06 4: MapleDuinoLAN: Read, msg: ␂MS;P0=242;P1=-8041;P3=-804;P4=782;P5=-255;D=01030303030303030303454545034503030303454545030303;CP=0;SP=1;R=35;e;m0;␃
2023.08.18 22:29:06 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:06 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3 dmsg i007438 length 24 RSSI = -56.5
2023.08.18 22:29:06 4: MapleDuinoLAN: Dispatch, i007438, Dropped due to short time or equal msg
2023.08.18 22:29:06 4: MapleDuinoLAN: Read, msg: ␂MS;P0=242;P1=-8041;P3=-804;P4=782;P5=-255;D=01030303030303030303454545034503030303454545030303;CP=0;SP=1;R=35;Q;e;m1;␃
2023.08.18 22:29:06 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=242;P1=-8041;P3=-804;P4=782;P5=-255;D=01030303030303030303454545034503030303454545030303;CP=0;SP=1;R=35;Q;e;m1;
2023.08.18 22:29:06 4: MapleDuinoLAN: Read, msg: ␂MS;P0=242;P1=-8041;P3=-804;P4=782;P5=-255;D=01030303030303030303454545034503030303454545030303;CP=0;SP=1;R=35;Q;e;m2;␃
2023.08.18 22:29:06 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=242;P1=-8041;P3=-804;P4=782;P5=-255;D=01030303030303030303454545034503030303454545030303;CP=0;SP=1;R=35;Q;e;m2;
2023.08.18 22:29:06 4: MapleDuinoLAN: Read, msg: ␂MS;P0=242;P1=-8041;P3=-804;P4=782;P5=-255;D=01030303030303030303454545034503030303454545030303;CP=0;SP=1;R=35;Q;e;m3;␃
2023.08.18 22:29:06 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=242;P1=-8041;P3=-804;P4=782;P5=-255;D=01030303030303030303454545034503030303454545030303;CP=0;SP=1;R=35;Q;e;m3;
2023.08.18 22:29:08 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8044;P2=262;P3=-775;P4=785;P5=-257;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=34;e;b50;m0;␃
2023.08.18 22:29:08 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:08 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3 dmsg i007438 length 24 RSSI = -57
2023.08.18 22:29:08 4: MapleDuinoLAN IT: message "i007438" (7)
2023.08.18 22:29:08 4: MapleDuinoLAN IT: msgcode "0000F1F001D0" (12) bin = 000000000111010000111000
2023.08.18 22:29:08 3: MapleDuinoLAN: Unknown code i007438, help me!
2023.08.18 22:29:08 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8044;P2=262;P3=-775;P4=785;P5=-257;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=34;Q;e;m1;␃
2023.08.18 22:29:08 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8044;P2=262;P3=-775;P4=785;P5=-257;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=34;Q;e;m1;
2023.08.18 22:29:08 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8044;P2=262;P3=-775;P4=785;P5=-257;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=34;Q;e;m2;␃
2023.08.18 22:29:08 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8044;P2=262;P3=-775;P4=785;P5=-257;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=34;Q;e;m2;
2023.08.18 22:29:08 4: MapleDuinoLAN: Read, msg: ␂MS;P1=-8044;P2=262;P3=-775;P4=785;P5=-257;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=34;Q;e;m3;␃
2023.08.18 22:29:08 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8044;P2=262;P3=-775;P4=785;P5=-257;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=34;Q;e;m3;
2023.08.18 22:29:09 4: MapleDuinoLAN: Read, msg: ␂MS;P2=-791;P3=731;P4=-276;P5=254;P6=-8040;D=56525252525252525252343434523452525252343434525252;CP=5;SP=6;R=32;e;b33;m0;␃
2023.08.18 22:29:09 4: MapleDuinoLAN: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.08.18 22:29:09 4: MapleDuinoLAN: Parse_MS, Decoded matched MS protocol id 3 dmsg i007438 length 24 RSSI = -58
2023.08.18 22:29:09 4: MapleDuinoLAN: Dispatch, i007438, Dropped due to short time or equal msg
2023.08.18 22:29:09 4: MapleDuinoLAN: Read, msg: ␂MS;P2=-791;P3=731;P4=-276;P5=254;P6=-8040;D=56525252525252525252343434523452525252343434525252;CP=5;SP=6;R=32;Q;e;m1;␃
2023.08.18 22:29:09 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-791;P3=731;P4=-276;P5=254;P6=-8040;D=56525252525252525252343434523452525252343434525252;CP=5;SP=6;R=32;Q;e;m1;
2023.08.18 22:29:09 4: MapleDuinoLAN: Read, msg: ␂MS;P2=-791;P3=731;P4=-276;P5=254;P6=-8040;D=56525252525252525252343434523452525252343434525252;CP=5;SP=6;R=32;Q;e;m2;␃
2023.08.18 22:29:09 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-791;P3=731;P4=-276;P5=254;P6=-8040;D=56525252525252525252343434523452525252343434525252;CP=5;SP=6;R=32;Q;e;m2;
2023.08.18 22:29:09 4: MapleDuinoLAN: Read, msg: ␂MS;P2=-791;P3=731;P4=-276;P5=254;P6=-8040;D=56525252525252525252343434523452525252343434525252;CP=5;SP=6;R=32;Q;e;m3;␃
2023.08.18 22:29:09 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-791;P3=731;P4=-276;P5=254;P6=-8040;D=56525252525252525252343434523452525252343434525252;CP=5;SP=6;R=32;Q;e;m3;
2023.08.18 22:29:21 4: MapleDuinoLAN: KeepAlive, ok, retry = 0
2023.08.18 22:30:21 4: MapleDuinoLAN: KeepAlive, not ok, retry = 1 -> get ping
2023.08.18 22:30:21 4: MapleDuinoLAN: HandleWriteQueue, called
2023.08.18 22:30:21 4: MapleDuinoLAN: SendFromQueue, called
2023.08.18 22:30:21 4: MapleDuinoLAN: Read, msg: OK
2023.08.18 22:30:22 4: MapleDuinoLAN: HandleWriteQueue, called
2023.08.18 22:30:22 4: MapleDuinoLAN: HandleWriteQueue, nothing to send, stopping timer
2023.08.18 22:31:21 4: MapleDuinoLAN: KeepAlive, ok, retry = 0
2023.08.18 22:32:21 4: MapleDuinoLAN: Attr, Calling sub with args: del verbose =
2023.08.18 22:32:21 3: MapleDuinoLAN: Attr, setting Verbose to:
Hier ein get ccconf
ccconf: Freq: 433.920 MHz, Bandwidth: 325 kHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5.60 kBaud, Modulation: ASK/OOK
War/ist beim SingalESP genauso und war (denke ich) auch beim SignalDuino (Arduino Nano) so...
(da habe ich aber leider aktuell keinen Zugriff mehr drauf)
Nun die Frage: ist der Klingelsensor defekt? Oder kann ich auf Empfangsseite noch was tun, damit es evtl. (trotzdem) geht?
Wollte nur mal fragen, bevor ich das Ding reklamiere...
Danke, Joachim
Hallo Joachim,
ohne die Gegebenheiten bei Dir genau zu kennen,
würde ich Dir empfehlen, bei einem RSSI von -57, den Sense- und rAmpl-Parameter
etwas herunterzunehmen. Bei hoher Bandbreite und hoher Verstärkung holst Du Dir alles an Störungen mit ins Nutzsignal (mit SDR besser beurteilbar).
Das könnte eine Möglichkeit sein. Genauso die passende ,,Mittenfrequenz"—Einstellung, wäre auch ein Ansatz.
Grüße
Jürgen
Hallo Jürgen,
danke für deine Antwort.
Ich habe ein wenig mit diesen Parametern "rumgespielt" und auch mal mit Bandbreite...
Aber es bleibt wie es ist :'(
Die RSSI, gut zuletzt hatte ich den Klingelsensor und den MapleDuinoLAN und auch den ESPDuino nahe beieinander...
Ich habe nun das Backup (das ich gemacht hatte, bevor es zum Bekannten ging) eingespielt, hier ein List des Klingelsensors der geht (auch bereits bei meinem ESPDuino und auch bei einem Steckbrett-Signalduinio, mit dem hatte ich mal begonnen, ob der Klingelsensor überhaupt tut / zum Glück habe ich mit dem angefangen, der geht, ansonsten hätte ich die Idee wohl verworfen 8) ):
Internals:
DEF 1527x00686 1000 0000
FUUID 64c53eb1-f33f-a014-c79f-9b426fb48205618b
IODev SunDuino
NAME KlingelSensor
NR 56
STATE ???
TYPE IT
XMIT 0000fdd0fd
XMITdimdown 00
XMITdimup 00
XMIToff 0000
XMITon 1000
CODE:
1 1527x00686
READINGS:
2023-08-20 14:28:38 IODev SunDuino
2023-08-02 14:07:45 protocol EV1527
Attributes:
room Eingang
Ich habe dann den Steckbrett Signalduino reaktiviert und auch das Testsystem (noch ohne Backup), dort den Signalduino neu angelegt (war ja noch nicht da) und dann noch mal den Klingelsensor betätigt.
Daraufhin wurde zwar (wieder) ein Sensor/Device angelegt aber danch nichts mehr weiter...
...genau wie das erste Mal beim MapleDuinoLAN.
Hier mal das List davon:
Internals:
CFGFN
DEF 0000F1F001 0F F0
FUUID 64e200eb-f33f-a014-8de9-b5d8554e1a66552d
IODev SignalDuino
NAME IT_0000F1F001
NR 113
STATE ???
TYPE IT
XMIT 0000f1f001
XMITdimdown 00
XMITdimup 00
XMIToff f0
XMITon 0f
CODE:
1 0000f1f001
READINGS:
2023-08-20 14:02:51 IODev SignalDuino
2023-08-20 14:03:32 protocol V1
Attributes:
room IT
Nicht von dem IODev verwirren lassen:
Mit dem Namen SunDino bin ich gestartet...
Den Namen SignalDuino nutze ich jetzt (auch beim Bekannten und für den jetzt neu angelegten SignalDuino Nano auf dem Steckbrett)...
Im Eventmonitor sehe ich auf beiden Systemen (also Hauptsystem mit MapleDuinoLAN und ESPDuino und Testsystem mit "Steckbrett" SignalDuino Nano) folgendes:
2023-08-20 14:11:29 SIGNALduino MapleDuinoLAN UNKNOWNCODE i007438
2023-08-20 14:11:31 SIGNALduino MapleDuinoLAN UNKNOWNCODE i007438
2023-08-20 14:11:33 SIGNALduino MapleDuinoLAN UNKNOWNCODE i007438
Darauf könnte ich zwar auch triggern und den Klingelsensor behalten...
...aber ich denke der Klingelsensor ist defekt.
Werde ihn wohl mal zurückgeben und einen neuen besorgen.
Danke, Joachim
Hallo Joachim,
wenn ich mit i007438 ein dispatch zum IT-Modul mache, bekomme ich:
2023.08.20 16:22:51.607 4: sduinoD/msg get dispatch: i007438
2023.08.20 16:22:51.607 5: sduinoD: dispatch i007438
2023.08.20 16:22:51.607 4: sduinoD IT: msgcode "0000F1F001D0" (12) bin = 000000000111010000111000
2023.08.20 16:22:51.607 5: sduinoD IT: V1 housecode = 0000F1F001 onoffcode = D0
2023.08.20 16:22:51.607 4: sduinoD IT: 0000F1F001 not defined (Switch code: D0)
2023-08-20 16:22:51.609 Global global UNDEFINED IT_0000F1F001 IT 0000F1F001 0F F0
mit der IT def "0000F1F001 D0 F0" bekomme ich:
2023.08.20 16:31:24.700 3: sduinoD IT: IT_0000F1F001 on->on
2023-08-20 16:31:24.702 IT IT_0000F1F001 on
Bitte ändere mal bei der IT def "0000F1F001 0F F0" das 0F in D0 (0000F1F001 D0 F0)
Gruß Ralf
Hallo Ralf,
sieh mal an: geht :)
Gut, ich frag mich: warum? Und warum ist der andere Sensor, der gleich ging anders definiert, also ganz anderes Protokoll?
EDIT: noch ein warum ;) Warum wird denn dann, sobald schon mal ein Device angelegt war und ich es lösche kein neues mehr angelegt?
(damit ich nun den Klingelsensor auf mein Hauptsystem kriege muss ich die RawDef aus meinem Testsystem rüberkopieren)
Hmm, dann lasse ich das mit dem Zurücksenden, geht ja...
Danke, Joachim
Das hängt vom housecode ab ob er als V1 oder EV1527 angelegt wird.
Es kann sein, daß nach dem Löschen eines devices ein FHEM Neustart gemacht werden muss
Zitat von: Ralf9 am 20 August 2023, 16:55:47Das hängt vom housecode ab ob er als V1 oder EV1527 angelegt wird.
Es kann sein, daß nach dem Löschen eines devices ein FHEM Neustart gemacht werden muss
Ok.
Mal testen...
Was aber bleibt ist:
2023.08.20 16:55:01 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=32001;P1=-8042;P2=244;P3=-791;P4=795;P5=-250;P6=-1774;D=21232323230623232323454545234523232323454545232323;CP=2;SP=1;R=49;p;b50;m0;
2023.08.20 16:55:01 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=32001;P1=-8042;P2=244;P3=-791;P4=795;P5=-250;P7=-1246;D=21232323232323232323450745234523232323454545232323;CP=2;SP=1;R=49;p;m1;
2023.08.20 16:55:01 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=32001;P1=-8042;P2=244;P3=-791;P4=795;P5=-250;P7=-1246;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=49;p;m2;
2023.08.20 16:55:01 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=32001;P1=-8042;P2=244;P3=-791;P4=795;P5=-250;P7=-1246;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=49;Q;p;m3;
2023.08.20 16:55:04 3: MapleDuinoLAN IT: itKlingelsensor on->on
2023.08.20 16:55:05 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=223;P1=-8051;P3=-824;P4=790;P5=-249;D=01030303030303030303454545034503030303454545030303;CP=0;SP=1;R=49;Q;e;m1;
2023.08.20 16:55:05 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=223;P1=-8051;P3=-824;P4=790;P5=-249;D=01030303030303030303454545034503030303454545030303;CP=0;SP=1;R=49;Q;e;m2;
2023.08.20 16:55:05 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=223;P1=-8051;P3=-824;P4=790;P5=-249;D=01030303030303030303454545034503030303454545030303;CP=0;SP=1;R=49;Q;e;m3;
2023.08.20 16:55:08 3: MapleDuinoLAN IT: itKlingelsensor on->on
2023.08.20 16:55:08 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8047;P2=249;P3=-791;P4=747;P5=-245;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=50;Q;e;m1;
2023.08.20 16:55:08 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8047;P2=249;P3=-791;P4=747;P5=-245;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=50;Q;e;m2;
2023.08.20 16:55:08 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8047;P2=249;P3=-791;P4=747;P5=-245;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=50;Q;e;m3;
2023.08.20 16:55:10 3: MapleDuinoLAN IT: itKlingelsensor on->on
2023.08.20 16:55:10 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8048;P2=270;P3=-764;P4=784;P5=-251;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=48;Q;e;m1;
2023.08.20 16:55:10 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P1=-8048;P2=270;P3=-764;P4=784;P5=-251;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=48;Q;e;m2;
2023.08.20 16:55:11 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-254;P3=239;P4=-796;P5=786;P6=-8046;D=36343434343434343434525252345234343434525252343434;CP=3;SP=6;R=49;Q;e;m1;
2023.08.20 16:55:11 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-254;P3=239;P4=-796;P5=786;P6=-8046;D=36343434343434343434525252345234343434525252343434;CP=3;SP=6;R=49;Q;e;m2;
2023.08.20 16:55:11 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P2=-254;P3=239;P4=-796;P5=786;P6=-8046;D=36343434343434343434525252345234343434525252343434;CP=3;SP=6;R=49;Q;e;m3;
4x "geklingelt" nur 3x Event...
Sind die Meldungen "normal"/"ok" oder ist da (trotzdem es jetzt "geht") etwas "schief"?
Ich müsste mal sehen, ob ich im Backup des anderen Systems ähnliche Meldungen finde...
EDIT: hmm. Eigentlich gibt es beim MapleDuinoLAN kein Attribut verbose, damit sollte es 0 sein? Beim Testsystem mit einem SignalDuino Nano ist das Attribut weg und da sind diese Meldungen nicht... Ich suche mal weiter...
EDIT: Testsystem mit SignalDuino
2023.08.20 16:55:01 3: SunDuino IT: IT_0000F1F001 on->on
2023.08.20 16:55:04 3: SunDuino IT: IT_0000F1F001 on->on
2023.08.20 16:55:08 3: SunDuino IT: IT_0000F1F001 on->on
2023.08.20 16:55:10 3: SunDuino IT: IT_0000F1F001 on->on
Gut keine Fehlermeldungen aber trotz (implizitem) Verbose 0 Einträge...
Kann ich aber verschmerzen... ;)
EDIT: ok, explizit auf 0 -> nix mehr :)
Also bis auf
2023.08.20 17:08:07 3: MapleDuinoLAN IT: itKlingelsensor on->on
2023.08.20 17:08:10 3: MapleDuinoLAN IT: itKlingelsensor on->on
Aber irgendwie ist der SignalDuino "besser"? Also immer mind. 1x mehr Klingelevents als auf dem Hauptsystem bzw. ist auf dem Testsystem erst einer "durchgerutscht". Zuletzt eigentlich gleiche Bedingungen, also in etwa gleiche Entfernung... Aber klar: CC1101, Anschaltung, Antenne, LAN/USB, ...
Ich denke ich kann damit leben :)
Danke noch mal!!
Gruß, Joachim
2023.08.20 16:55:01 3: MapleDuinoLAN: Parse_MS, faulty msg: MS;P0=32001;P1=-80Du verwendest demnach das 00_SIGNALDuino Modul vom normalen fhem update.
Dort ist eine sehr scharfe regex drin
sub SIGNALduino_Parse_MS {
my $hash = shift // return; #return if no hash is provided
my $rmsg = shift // return; #return if no rmsg is provided
if ($rmsg !~ /^MS;(?:P[0-7]=-?\d+;){3,8}D=[0-7]+;(?:[CS]P=[0-7];){2}((?:R=\d+;)|(?:O;)?|(?:m=?[0-9];)|(?:[sbeECA=0-9]+;))*$/){
$hash->{logMethod}->($hash->{NAME}, 3, qq[$hash->{NAME}: Parse_MS, faulty msg: $rmsg]);
return ; # Abort here if not successfull
}
Bei meiner firmware kommen bei einigen Nachrichten am Ende andere Zeichen als bei der firmware von Sidey, diese Nachrichten werden als fehlerhaft erkannt und verworfen.
Damit mit dem MapleDuino alles funktioniert ist mein angepasstes 00_SIGNALduino Modul notwendig
https://forum.fhem.de/index.php?topic=111653.msg1058900#msg1058900
Hallo Ralf,
jep: erst mal alles "original" 8)
Erst wenn was nicht geht wird "getrickst"... ;)
FW habe ich folgende: Maple_sduino_LAN_422dev20220712.bin
OK, oder sollte ich da auch was anderes nehmen? (wenn ich schon mal "rumfrage" ;) )
EDIT: hier mal noch ein list (man weiß ja nie ;) )
Internals:
Clients :CUL_EM:CUL_FHTTK:CUL_TCM97001:CUL_TX:CUL_WS:Dooya:FHT:FLAMINGO:FS10:FS20: :Fernotron:Hideki:IT:KOPP_FC:LaCrosse:OREGON:PCA301:RFXX10REC:Revolt:SD_AS:SD_Rojaflex: :SD_BELL:SD_GT:SD_Keeloq:SD_RSL:SD_UT:SD_WS07:SD_WS09:SD_WS:SD_WS_Maverick:SOMFY: :Siro:SIGNALduino_un:
DEF 192.168.1.138:23
DMSG i007438
DevState initialized
DeviceName 192.168.1.138:23
FD 204
FUUID 64c7fbcc-f33f-753d-e4e1-2de2f4181db72b95
IDsNoDispatch 2,72.1,82
ITClock 250
LASTDMSG i007438
LASTDMSGID 3
MSGCNT 385
NAME MapleDuinoLAN
NR 2156
NR_CMD_LAST_H 1
PARTIAL
RAWMSG MS;P1=-8035;P2=250;P3=-782;P4=793;P5=-243;D=21232323232323232323454545234523232323454545232323;CP=2;SP=1;R=79;e;b50;m0;
RSSI -34.5
STATE opened
TIME 1692545471.97123
TYPE SIGNALduino
cc1101_available 1
eventCount 1566
sendworking 0
unknownmessages
version V 4.2.2-dev220712 SIGNALduinoAdv LAN cc1101 (R: B0*) - compiled at Jul 13 2022 13:19:01
versionProtocols 1.48
versionmodul 3.5.4
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|114|118|121)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
31:KOPP_FC ^kr\w{18,}
32:PCA301 ^\S+\s+24
33:SD_Rojaflex ^P109#[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2023-08-20 14:07:51 cc1101_config Freq: 433.920 MHz, Bandwidth: 325 kHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5.60 kBaud
2023-08-20 14:07:51 cc1101_config_ext Modulation: ASK/OOK
2023-08-20 14:06:02 cc1101_patable C3E = 00 84 00 00 00 00 00 00 => 5_dBm
2023-08-20 18:49:03 ping OK
2023-08-20 14:06:00 state opened
XMIT_TIME:
1692547170.43527
additionalSets:
helper:
keepalive:
ok 1
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
119
mnIdList:
100
101
102
103
107
107.1
108
109
112
115
116
116.1
117
msIdList:
0
0.1
0.2
0.3
0.4
0.5
1
3
3.1
4
6
7
7.1
13
13.2
14
15
17
20
23
25
33
33.1
33.2
35
41
49
51
53
54.1
55
65
68
74.1
87
88
90
91.1
93
106
113
118.1
muIdList:
8
9
13.1
16
17.1
19
20.1
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49.1
49.2
50
54
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
78
79
80
81
83
84
85
86
89
91
92
94
95
97
98
99
104
105
110
111
114
118
120
121
122
Attributes:
comment SignalDuino:
/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
MapleDuino USB:
/dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_6D8E115E4855-if00
MapleDuino LAN:
192.168.1.141:23
Flash FW:
press reset
sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download Maple_sduino_LAN_422dev20220712.bin
evtl. customized 00_SIGNALduino.pm https://forum.fhem.de/index.php?topic=111653.msg1058900#msg1058900
press reset
sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download Maple_sduino_USB_422dev20220712.bin
Schematic MapleMini:
https://wiki.fhem.de/wiki/Datei:MapleSduino_Schaltplan_nur_Modul_B.png
LAN:
https://github.com/ranseyer/MapleSDuino/blob/master/PCB-V09/Schematic.png
CC1101 pinout:
https://quadmeup.com/assets/2017/12/CC1101-868mhz-radio-module-pinout.jpg
https://projects.gepeo.fr/wp-content/uploads/2021/01/cc1101-module-pinout.png
devStateIcon opened:max_rf@green .*:max_rf@red
group IO-Module
hardware MAPLEMINI_F103CBcc1101
room System
Angepasstes Modul probiere ich mal aus...
(Master oder Dev? )
Danke, Joachim
Ja die 422dev20220712 ist aktuell.
Vom 00_SIGNALDuino Modul ist diese dev Version die aktuelle
versionmodul v3.4.16-dev_ralf_23.07.
versionprotoL v3.4.16-dev_ralf_23.07.
https://forum.fhem.de/index.php?topic=111653.msg1283522#msg1283522
Eingespielt (auf dem Testsystem / Hauptsystem mache ich eben :) ): läuft :)
Also die "falschen Messages Meldungen" sind weg.
Allerdings wird der Sensor immer noch falsch angelegt...
Also 0F? statt D0...
Aber jetzt weiß ich es ja 8)
Musste den MapleDuinoLAN power cyclen, davor dachte ich schon: uiuiui, da geht ja so gar nichts mehr... ;)
Aber danach alles gut...
Danke noch mal, Joachim
Hi,
ich bin relativ neu hier und habe bisher den offiziellen Signalduino mit einem CC1101 im Einsatz, um damit Somfy Rolläden zu steuern. Das funktioniert auch, allerdings ist die Performance nicht so toll. Wenn ich alle Rollläden auf einem Stockwerk gleichzeitig auf bzw. zu mache, dann ist der erste fertig, bevor der letzte anfängt sich zu bewegen :)
Gibt es Vergleichswerte zwischen der MapleMini / ESP32 Variante und dem Arduino Nano bzgl. Performance?
@Ralf9: Kann deine Variante mit vier (identischen) CC1101 bestückt werden und dann quasi als "LoadBalancer" arbeiten, um die Performance zu verbessern?
Zitatich bin relativ neu hier und habe bisher den offiziellen Signalduino mit einem CC1101 im Einsatz, um damit Somfy Rolläden zu steuern. Das funktioniert auch, allerdings ist die Performance nicht so toll. Wenn ich alle Rollläden auf einem Stockwerk gleichzeitig auf bzw. zu mache, dann ist der erste fertig, bevor der letzte anfängt sich zu bewegen
Das hat nichts mit der firmware zu tun, wenn Du alle Rollläden auf einem Stockwerk gleichzeitig auf bzw. zu machst, werden die Sendebefehle in dem 00_SIGNALDuino Modul in einer Sendewarteschlange gespeichert und dann nacheinander mit einer kurzen Pause dazwischen gesendet.
Okay, ich hatte den Arduino Nano als Flaschenhals im Verdacht, da im FHEM Wiki steht, dass die Leistungsreserven knapp werden. Welche Möglichkeiten bestehen dann noch das ganze zu beschleunigen? Kann die Pause oder die Anzahl der Wiederholungen angepasst werden?
Ich habs bei mir auf dem Testsystem mal getestet.
Ich habe eine structure mit 3 somfy test devices angelegt
Wie im log zu sehen ist, werden alle 3 in die SendQueue zugefügt und dann nacheinander gesendet (SW: SC...)
"READ: SC.." ist die Rückmeldung von der firmware, daß gesendet wurde.
Ich sehe da kein Optimierungspotential.
Du kannst es bei Dir auch mal im log anschauen.
2023-09-10 14:47:32.226 structure somfyStruct on
2023.09.10 14:47:32.228 5: AddSendQueue: sduinoA: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A4EBFD7D5CAAAA;F=10AB85550A; (1)
2023.09.10 14:47:32.229 5: AddSendQueue: sduinoA: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=82CCCCCBB7DEDD;F=10AB85550A; (2)
2023.09.10 14:47:32.231 5: AddSendQueue: sduinoA: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=83CACAC9041811;F=10AB85550A; (3)
2023.09.10 14:47:32.328 5: sduinoA SW: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A4EBFD7D5CAAAA;F=10AB85550A;
2023.09.10 14:47:33.056 4: sduinoA/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=A4EBFD7D5CAAAA;
2023.09.10 14:47:33.057 5: sduinoA SW: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=82CCCCCBB7DEDD;F=10AB85550A;
2023.09.10 14:47:33.784 4: sduinoA/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=82CCCCCBB7DEDD;
2023.09.10 14:47:33.785 5: sduinoA SW: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=83CACAC9041811;F=10AB85550A;
2023.09.10 14:47:34.512 4: sduinoA/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=645;D=83CACAC9041811;
Gruß Ralf
Ich bin mir gerade nicht sicher was ich falsch mache ??? Sollte ich die Einträge unter dem Hauptmenüpunkt "Logfile" sehen? Dort wird bei mir nichts in der Art eingetragen. Ich habe bisher noch das Standard-Somfy Modul im System, liegt es ggf. daran?
Zitat von: n-b-dy am 08 September 2023, 08:19:11Wenn ich alle Rollläden auf einem Stockwerk gleichzeitig auf bzw. zu mache, dann ist der erste fertig, bevor der letzte anfängt sich zu bewegen :)
Definiere doch eine neue Steuerung in FHEM, die beim auslösen alle gleichzeitig bewegt (also die neue Steuerung bei allen Rolläden erneut anlernen).
Ja, das mit dem definieren einer neuen Steuerung ist wahrscheinlich die beste Lösung.
Bei gleichzeitigen senden über die SendQueue gibts mindestens eine Verzögerung von ca 0,7-0,8 sek pro Rolladen.
Damit Du die Einträge im log siehst, must Du das sduino verbose auf 5 erhöhen
Danke für den Input!
Das mit der neuen Steuerung wird die Backup-Lösung. Ich hatte noch genügend Einzelteile um einen zweiten Signalduino zu bauen und habe bei jedem zweiten Fenster den Rollladen auf den zweiten Signalduino umgestellt. Damit habe ich bei der Einzelsteuerung pro Raum auf jeden Fall die gewünschte Reaktionszeit.
Allerdings macht mir die Funktion "ganzes Stockwerk Rollladen auf/zu" mit den zwei Signalduinos einen Strich durch die Rechnung. Es geht immer nur die "eine Hälfte" der Rollläden, die einzelne Ansteuerung funktioniert aber.
Die beiden Signalduino hängen über einen USB-Hub via ser2net an einem per LAN angebundenen openWRT Router in der Mitte des Gebäudes.
Hoffe ihr habt eine Idee, woran das liegen könnte :)
Hallo Ralf,
ich nutze nun seit einiger Zeit den MapleSduino und bin soweit zufrieden, an dieser Stelle vielen Dank für deine Arbeit!
Nun wollte ich die Reichweite etwas vergrößern und habe versucht einen Arduino Nano Signalduino per Ser2Net mit einzubinden (dieser hat mit den Modulen die mit FHEM ausgeliefert werden vorher funktioniert). Leider sieht es so aus, als würde der Nano Sigduino mit deinem Modul nicht erkannt wird. Ist dein Modul komplett nur auf Mapleduino zugeschnitten und hat keine "Abwärtskompatibilität"? Oder muss ich eine andere FW auf den Nano flashen?
Ich fände es super wenn der Nano hier zur Mitarbeit überredet werden könnte.
Hier der Verboselog vom Nano Sigduino:
2023.11.14 19:50:44 3: SigDuino: Protocolhashversion: v3.4.16-dev_ralf_23.07.
'MODIFIED SigDuino'
'MODIFIED SigDuino'
2023.11.14 19:50:44 3: SigDuino IDlist attr whitelist disabled (all IDs active, except blacklisted and instable IDs):
2023.11.14 19:50:44 5: SigDuino IDlist sort: 0 0.1 0.2 0.3 0.4 0.5 1 2 3 3.1 4 5 6 7 8 9 10 11 12 12.1 13 13.1 13.2 14 15 16 17 17.1 18 19 20 20.1 21 22 23 24 25 26 27 28 29 30 31 32 32.1 33 33.1 33.2 34 35 36 37 38 39 40 41 42 43 43.1 44 44.1 45 46 47 48 49 49.1 49.2 50 51 52 53 54 54.1 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 72.1 73 74 74.1 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 91.1 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 118 118.1 119 119.1 120 121 122 123 124 124.1 127 127.1 128 128.1 129 198 199 200 200.1 201 202 203 204 205 205.1 206 207 208 209 210 211 212 213 214
2023.11.14 19:50:44 3: SigDuino: IDlist MS 0 0.1 0.2 0.3 0.4 0.5 1 3 3.1 4 6 7 13 13.2 14 15 17 20 23 25 32.1 33 33.1 33.2 35 41 49 51 53 54.1 55 65 68 74.1 90 91.1 93 106 113 118.1 124.1 127.1 128.1
2023.11.14 19:50:44 3: SigDuino: IDlist MU 8 9 13.1 16 17.1 19 20.1 21 22 24 26 27 28 29 30 32 34 36 37 38 39 40 42 44 44.1 45 46 48 49.1 49.2 50 54 56 59 60 61 62 64 66 67 69 70 71 72 73 74 78 79 80 81 83 84 85 86 89 91 92 94 95 97 98 99 104 105 110 111 114 118 120 121 122 124 127 128 198 200 200.1
2023.11.14 19:50:44 3: SigDuino: IDlist MC 10 11 12 18 43 47 52 57 58 96 119 129 212
2023.11.14 19:50:44 3: SigDuino: IDlist MN 100 101 102 103 107 108 109 112 115 116 123 201 202 203 204 205 206 207 208 209 210 211 213 214
2023.11.14 19:50:44 3: SigDuino: IDlist development skipped = 2 5 12.1 31 43.1 63 72.1 75 76 77 82 87 88 119.1 199 205.1
2023.11.14 19:50:44 3: SigDuino: IDlist development protocol is active (to activate dispatch to not finshed logical module, enable desired protocol via whitelistIDs) = 2 43.1 72.1 82 87 88
2023.11.14 19:50:44 1: SigDuino/define: 192.168.XXX.YYY:ZZZZ
2023.11.14 19:50:44 1: SigDuino/init: 192.168.XXX.YYY:ZZZZ
2023.11.14 19:50:44 3: SigDuino device opened
2023.11.14 19:50:47 3: SigDuino/init: disable receiver (XQ)
2023.11.14 19:50:47 5: SigDuino SW: XQ
2023.11.14 19:50:47 3: SigDuino/init: get version, retry = 0
2023.11.14 19:50:47 5: SigDuino SW: V
2023.11.14 19:50:57 3: SigDuino/init: get version, retry = 1
2023.11.14 19:50:57 5: SigDuino SW: V
2023.11.14 19:51:37 3: SigDuino/init: get version, retry = 2
2023.11.14 19:51:37 5: SigDuino SW: V
2023.11.14 19:52:47 3: SigDuino/init: get version, retry = 3
2023.11.14 19:52:47 2: SigDuino/init retry count reached. Closed
2023.11.14 19:52:47 2: SigDuino closed
Nein, mein 00_SIGNALDuino Modul sollte mit jeder sduino Hard- und Firmware funktionieren.
Evtl hängt es mit Ser2Net zusammen.
Funktioniert ein "telnet 192.168.XXX.YYY:ZZZZ"
In der Telnet Verbindung dann V eingeben
Die Rückgabe ist :
Escape character is '^]'.
V
o-<l{<o,=n,<Q�Q$*10(**1)1))*)v}
Das passt so nicht, es muss so was ähnliches zurückkommen:
V 3.xxx SIGNALduino - compiled at ...
Du kannst auch mal CG eingeben, da kommt dann
MS=1;MU=1;MC=1...
hmm, da kommt leider auch nur Murks raus..
Evtl. passt die bitrate nicht..
so sieht meine Ser2Net config aus und ich meine diese hat auch mal früher funktioniert..
connection: &con01
accepter: tcp,4004
connector: serialdev,
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0,9600n71,local
options:
kickolduser: true
max-connections: 3
Die Baudrate passt nicht, beim sduino ist sie 57600
Danke, das war es ::)
der Vollständigkeit halber, das ist der korrekte Ser2Net Eintrag:
connection: &con01
accepter: tcp,4004
connector: serialdev,
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0,9600n81,local
options:
kickolduser: true
max-connections: 3
Hallo Ralf,
ich habe mal wieder eine Frage an dich. Ich nutze den MapleSduino LAN jetzt schon einige Zeit, läuft soweit echt super und fehlerfrei ;D
Hab nun die Tage ein Problem gehabt. Die Stadtwerke hatten bei mir den Strom abgestellt und somit ist hier alles danach neu gestartet. Da mein MapleSduino ja am Netzwerk hängt und auch die FRITZBox neu gestartet ist war der MapleSduino schneller mit dem Start wie die FRITZBox und somit hat sich hier was mit dem Netzwerk aufgehängt, nachdem dann Abends die Rollläden nicht gefahren sind und ich dann festgestellt habe das ich den MapleSduino nicht erreiche habe ich den neu gestartet und dann ging alles wieder.
Ist es hier machbar das der in einer Art Schleife bleibt wenn er kein Netzwerk hat und es z.B. alle 10 Sekunden probiert sich neu zu verbinden?
Danke dir schonmal im Voraus.
Gruß Markus
Hallo,
sorry, ich komme beim firmware flashen vom maple mini nicht weiter. Das Wiki, bzw die unterschiedlichen Vorgehensweisen bekomme ich so nicht hin. Könnt ihr mir helfen?
Basis:
Ubuntu 20.04
STM32F103CBT6
1.
Bootloader 2.0 flashen (hat funktioniert, bootloader from RogerClark):
sudo dfu-util -d 1eaf:0003 -a 2 -D maple_mini_boot20.bin -R
2. firmware
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_sduino_LAN_422dev20220712.bin -R
Fehler:
dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
Es kommt keine Verbindung zustande, auch nach drücken der Rst Taste am Maple nicht
Was mache ich falsch?
Das flashen mit sudo dfu-util ... -a 2 funktioniert nur wenn das Bootloader 2.0 flashen erfolgreich war.
Wenn es mit sudo dfu-util ... -a 1 funktioniert, dann ist noch der Bootloader 1 drauf.
Zum flashen muß der STM32F103CBT6 im flash Modus sein, da gibts verschiedene Möglichkeiten, ich drücke die Resettaste und starte dann innerhalb ca 1 sek das flashen
Gruß Ralf
Vielen Dank,
das flashen hat funktioniert, Bootloader 2.0 war nicht drauf..
Sorry wenn ich hier frage. Kann ich den Signalduino ohne Umweg über FHEM+Mqtt in Homeassistant einsetzen? Am besten über LAN und mit dem Addon Wmbusmeters
Hallo Ralf,
ich habe nun auch einen ESP32-Duino im Einsatz nur scheint der irgendwie immer wieder Probleme zu haben, sodass er nichts mehr richtig verarbeiten kann.
An dem ESP32 habe ich einen CC1101 mit 868Mhz dran.
Nach der korrekten Komfiguration wie folgt:
get <dein Maple-SDuino> raw CREA #aktiviert Radio A
get <dein Maple-SDuino> cmdBank A1 #selektiert Radio A und aktiviert Speicherbank 1
set <dein Maple-SDuino> rfmode SlowRF_CCFactoryReset #speichert rfmode SlowRF in aktivierter Speicherbank (wenn die Bank vorher leer war, wird sie automatisch mit SlowRf initialisiert)
set <dein Maple-SDuino> cc1101_freq 868.35
get <dein Maple-SDuino> cmdBank A1W #Zuordnung Radio A mit Speicherbank 1 im EEPROM speichern
Funktioniert es einige Zeit auch richtig, nach einiger Zeit kommt nur noch Murks von dem ESP32Duino und die Konfiguraion sieht dann auch seltsam aus, insbesondere was in cc1101_config steht:
Internals:
Clients :CUL_TCM97001:SD_WS:SD_WS07:SD_WS09:Hideki:LaCrosse:OREGON:CUL_EM:CUL_WS:CUL_TX:SD_AS:IT: :FS10:FS20:SOMFY:FLAMINGO:SD_WS_Maverick:KOPP_FC:PCA301:SD_BELL:SD_GT:SD_RSL:SD_UT:WMBUS:HMS: :IFB:CUL_FHTTK:FHT:RFXX10REC:Revolt:Dooya:Fernotron:SD_Keeloq:SD_Rojaflex:Siro:LTECH:SD_Tool:SIGNALduino_un:
ClientsKeepOrder 1
DEF 192.168.180.115:23
DMSG nothing
DevState initialized
DeviceName 192.168.180.115:23
EQMSGCNT 0
FD 49
FUUID 6556364c-f33f-dd49-02c0-ff71865fdf1448aa
FVERSION 00_SIGNALduino.pm:v3.4.15-s3416/2023-07-23
IDsNoDispatch 2,43.1,72.1,82,87,88
ITClock 250
LASTDMSG nothing
LASTDMSGID nothing
MSGCNT 422
NAME ESP32Sigduino
NR 758
PARTIAL
RAWMSG MU;P0=101;P1=-2315;P2=-912;P3=552;P4=-420;P6=1503;P7=-112;CP=3;R=218;D=2323232323232323404623262626232623232323262626701;e;
RSSI -93
STATE opened
TIME 1705603192.7228
TYPE SIGNALduino
a_ccconf b=1 freq:868.350MHz bWidth:541KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100]
cc1101_frequency 868.350
eventCount 200
sendworking 0
unknownmessages 2024-01-18 18:33:16-MU;P0=-897;P1=90;P2=-101;P3=1517;P5=554;P7=146;CP=5;R=220;D=0123030503050505030505050305030505050503030303032703030;e;#2024-01-18 18:33:16-MU;P0=-319;P1=529;P2=-977;P3=1522;P4=122;P5=-90;CP=1;R=218;D=01212321232321232323232121232123212121212123232454;e;#2024-01-18 18:33:48-MU;P0=-620;P1=341;P2=-875;P3=673;P4=520;P5=1535;P6=-348;P7=91;CP=4;R=219;D=123242424242424252424242525676425242424230;e;#2024-01-18 18:33:49-MU;P0=-1851;P1=330;P2=-935;P3=536;P4=1508;P5=-543;P6=90;P7=-267;CP=3;R=219;D=0123232323232323245673232324242324232323;e;#2024-01-18 18:34:04-MU;P0=-131;P1=551;P2=-923;P3=1524;P4=138;P5=-357;P6=-90;P7=-690;CP=3;R=220;D=45323232323232323232323232323232364737323232321212121232104732321232323;e;#2024-01-18 18:34:48-MU;P0=-390;P1=537;P2=-902;P3=1511;P5=-91;P6=144;CP=1;R=220;D=0121212123212121232321232121212123232323232123215623212321230;e;#2024-01-18 18:34:52-MU;P0=-952;P1=1509;P2=530;P3=-476;P4=964;P5=-247;CP=1;R=217;D=01010101010101010102020202013401010201015;e;#2024-01-18 18:34:52-MU;P0=91;P1=-913;P2=1570;P3=539;P4=-248;CP=2;R=217;D=0121212121212121313131312131212131212124;e;#2024-01-18 18:36:28-MU;P0=-453;P1=1518;P2=-924;P3=540;P4=-681;CP=1;R=218;D=012121212121212121212121232323232123212123214;e;#2024-01-18 18:36:28-MU;P0=-135;P1=551;P2=-962;P3=1521;P4=-184;P5=91;P6=-512;P7=135;CP=1;R=208;D=12323212323232321212321232121212123214561270;p;#2024-01-18 18:37:16-MU;P0=-472;P1=1516;P2=-933;P3=513;P4=-698;P5=-114;P6=116;P7=-181;CP=3;R=219;D=012123212323232123234321232123232321232121212121564121217;e;#2024-01-18 18:38:04-MU;P0=-1817;P1=343;P2=-926;P3=521;P4=1508;CP=3;R=219;D=0123232323232323232423242424232423232323;e;#2024-01-18 18:38:48-MU;P0=110;P1=-673;P2=1549;P3=-922;P4=559;P5=-132;CP=2;R=219;D=0123432323232323232323232323232323232323232325;e;#2024-01-18 18:38:52-MU;P0=91;P1=-919;P2=544;P3=1503;CP=2;R=216;D=012121212121212121312131313121312121212131313121312121;e;#2024-01-18 18:39:40-MU;P0=-200;P1=525;P2=-907;P3=1538;P4=-340;CP=1;R=213;D=0121232123232123232323212123212123232123234;e;#2024-01-18 18:41:48-MU;P0=-674;P1=557;P2=-940;P3=1502;P4=-281;P5=117;P6=-519;CP=1;R=218;D=012121212345612121232321232121212123232323234;e;#2024-01-18 18:42:04-MU;P0=-578;P1=1500;P2=-944;P3=527;CP=1;R=215;D=012321232323232121212121212121212121212121212321;e;#2024-01-18 18:42:49-MU;P0=92;P1=-325;P2=135;P3=512;P4=-936;P5=1499;P7=-160;CP=5;R=214;D=012134345454545454345434543454345454545454545454545454545457;e;#2024-01-18 18:42:52-MU;P0=-629;P1=535;P2=-914;P3=1502;P4=-163;P5=91;P6=-285;P7=132;CP=1;R=216;D=012123212323232123212121212323232123450121212367;e;#2024-01-18 18:42:52-MU;P0=-679;P1=1496;P2=-946;P3=513;P4=-252;P5=21745;P6=-90;P7=150;CP=3;R=215;D=123232321232321212321232323232145212121212123236701210;e;#2024-01-18 18:47:40-MU;P0=-264;P1=480;P2=-979;P4=1455;P5=-114;CP=1;R=214;D=0121212121212421242424212421212121242424212421215;e;#2024-01-18 18:55:40-MU;P0=-7631;P1=342;P2=-947;P3=519;P4=1495;P5=-306;P6=250;P7=-408;CP=3;R=214;D=01232323232323232324232424242324232323567324245;e;#2024-01-18 18:55:40-MU;P0=101;P1=-960;P2=1476;P3=-515;P5=-264;P6=518;P7=-341;CP=2;R=213;D=012123052121212121212121212121216121212127;e;#2024-01-18 18:55:40-MU;P0=-1456;P1=290;P2=-983;P3=473;P4=1464;P6=-160;CP=3;R=212;D=01232323232323232324232424242324232323236;e;#2024-01-18 18:55:49-MU;P0=-969;P1=479;P4=1478;CP=1;R=213;D=010101010104010101040401040101010104040404040104;e;
version V 4.2.2-dev220712 SIGNALduinoAdv ESP32 cc1101 (R: A1) - compiled at Jul 13 2022 01:11:33
versionmodul v3.4.16-dev_ralf_23.07.
versionprotoL v3.4.16-dev_ralf_23.07.
DoubleMsgIDs:
Helper:
DBLOG:
cc1101_config:
logdb:
TIME 1705604340.01304
VALUE freq:0.000MHz bWidth:812KHz rAmpl:24dB sens:4dB (DataRate:24.80Baud)
cc1101_config_ext:
logdb:
TIME 1705604340.01304
VALUE Modulation:2-FSK (SYNC_MODE:No preamble/sync) DEVIATN:1.587kHz
cmdBank::
logdb:
TIME 1705604368.28652
VALUE A: b=1 freq:868.350MHz bWidth:541KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100] ccmode=0 sync
ping::
logdb:
TIME 1705604336.17974
VALUE OK
state:
logdb:
TIME 1705603195.92022
VALUE opened
MatchList:
01:IT ^i......
02:CUL_TCM97001 ^s[A-Fa-f0-9]+
03:SD_RSL ^P1#[A-Fa-f0-9]{8}
04:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
05:CUL_TX ^TX..........
06:SD_AS ^P2#[A-Fa-f0-9]{7,8}
07:Hideki ^P12#75[A-F0-9]+
09:CUL_FHTTK ^T[A-F0-9]{8}
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|114|118|121|124|127|128|199)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
28:SD_Keeloq ^P(?:87|88)#.*
29:SD_GT ^P49#[A-Fa-f0-9]+
30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
31:KOPP_FC ^kr..................
32:PCA301 ^\S+\s+24
33:SD_Rojaflex ^P109#[A-Fa-f0-9]+
34:WMBUS ^b.*
35:HMS ^810e04......a001
36:IFB ^J............
37:LTECH ^P31#[A-Fa-f0-9]{26,}
90:SD_Tool ^pt([0-9]+(\.[0-9])?)(#.*)?
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2023-12-20 20:06:25 bWidth Setting MDMCFG4 (10) to 27 = 541 KHz
2024-01-18 19:59:00 cc1101_config freq:0.000MHz bWidth:812KHz rAmpl:24dB sens:4dB (DataRate:24.80Baud)
2024-01-18 19:59:00 cc1101_config_ext Modulation:2-FSK (SYNC_MODE:No preamble/sync) DEVIATN:1.587kHz
2024-01-18 19:59:28 cmdBank
A: b=1 freq:868.350MHz bWidth:541KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0100]
ccmode=0 sync
2023-12-20 20:23:07 config A: MS=1;MU=1;MC=1;Mred=0_MScnt=4;maxMuPrint=768;maxMsgSize=1024;maxNumPat=8;Mdebug=1;MdebFifoLimit=150/200
2024-01-18 19:58:56 ping OK
2023-12-20 20:22:36 raw Unsupported command
2023-12-20 19:52:14 rfmode SlowRF_ccFactoryReset => ccFactoryReset done
2024-01-18 19:39:55 state opened
2023-11-16 18:22:01 version V 4.2.2-dev220712 SIGNALduinoAdv ESP32 cc1101 (R: A1*) - compiled at Jul 13 2022 01:11:33
getcmd:
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
96
119
129
212
mnIdList:
100
101
102
103
107
108
109
112
115
116
123
201
202
203
204
205
206
207
208
209
210
211
213
214
msIdList:
0
0.1
0.2
0.3
0.4
0.5
1
3
3.1
4
6
7
13
13.2
14
15
17
20
23
25
32.1
33
33.1
33.2
35
41
49
51
53
54.1
55
65
68
74.1
90
91.1
93
106
113
118.1
124.1
127.1
128.1
muIdList:
8
9
13.1
16
17.1
19
20.1
21
22
24
26
27
28
29
30
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49.1
49.2
50
54
56
59
60
61
62
64
66
67
69
70
71
72
73
74
78
79
80
81
83
84
85
86
89
91
92
94
95
97
98
99
104
105
110
111
114
118
120
121
122
124
127
128
198
200
200.1
rfmodesets:
rfmode Avantek_433__B8_N9_FSK,Bresser_5in1_u_7in1__B28_N7_8220,Bresser_6in1__B20_N7_8220,DP100_WH51_WH57_433__B16_N16_17241,DP100_WH51_WH57_868__B16_N6_17241,HoneywActivL__SlowRf_FSK,KOPP_FC__B20_N4_4785,Lacrosse_mode1_WS1080_TX38__B12_N1_17241,Lacrosse_mode2__B12_N2_9579,PCA301_mode3__B32_N3_6631,Rojaflex_433__B12_N8_GFSK,SlowRF_ccFactoryReset,W136__B24_N10_4798,WH24_WH25__B20_N1_17241,WMBus_S__N11_ab_firmware_V422,WMBus_T_u_C__N12_ab_firmw_V422,WS1600_TX22_mode5__B16_N5_8842,custom
rfmodesetsTesting:
rfmodeTesting Avantek_433__B5_N9_FSK,Bresser_5in1_u_7in1__B26_N7_8220,Bresser_6in1__B18_N7_8220,DP100_WH51_WH57_433__B14_N16_17241,DP100_WH51_WH57_868__B14_N6_17241,Elero__N13_ab_firmw_V335_u_V422,Inkbird_433__B18_N14_FSK,Lacrosse_mode1_TX38__B5_N1_17241,Lacrosse_mode1_WS1080_TX38__B10_N1_17241,Lacrosse_mode2__B5_N2_9579,PCA301_mode3__B12_N3_6631,W136__B24_N10_4798,WH24_WH25__B16_N1_17241,WS1600_TX22_mode5__B5_N5_8842
sendAslowrfID:
Attributes:
WS09_CRCAUS 2
WS09_WSModel WH3080
devStateIcon opened:cul_868@green initialized:cul_868@yellow disconnected:cul_868@red
group Kommunikation
hardware ESP32_sduino_devkitV1
icon cul_868
room 10_Technik
sortby 21
verbose 5
Wenn nach einiger Zeit nur noch Murks kommt, passt dann "get version" noch?
Was ergibt "get ccconf" und "get cmdBank"?
Wenn Du mit "get raw e" einen CCFactoryReset machst und dann "set cc1101_freq 868.35"
Was ergibt dann "get ccconf" und "get cmdBank"?
Gruß Ralf
get ccconf:
ccconf: freq:0.000MHz bWidth:812KHz rAmpl:24dB sens:4dB (DataRate:24.80Baud)
Modulation:2-FSK (SYNC_MODE:No preamble/sync) DEVIATN:1.587kHz
get cmdbank:
cmdBank:
B: b=0 rx=0 freq:433.920MHz bWidth:812KHz rAmpl:42dB sens:8dB (DataRate:43.78Baud,Modulation:ASK/OOK) [boffs=0000]
ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)
Es ist aber nur ein Radio angeschlossen und konfiguriert.
nach dem set Befehl bleibt die Ausgabe von get ccconf unverändert, get cmdbank ändert sich:
cmdBank:
B: b=0 rx=0 freq:868.350MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud,Modulation:ASK/OOK) [boffs=0000]
ccmode=0 sync=D391 Modulation:ASK/OOK (SYNC_MODE:No preamble/sync)
Und nach einigen Tagen / Wochen ändert es sich selbstständig wieder zu dem oben genannten..
Evtl ein fehlerhaftes Netzteil oder ein Problem mit der Verkabelung vom ESP32 zum cc1101. Hast Du eine fliegende Verkabelung des cc1101? Wie lang sind die Kabel?
Ok, das Netzteil tausche ich mal, die Kabel zwischen ESP32 und CC1101 sind sehr kurz.
Ich stolpere gerade über ein generelles Thema:
Gibt es irgendwo eine Auflistung, für welches Protokoll aus der Liste man welchen rfmode einstellen soll? Habe wirklich danach gesucht, bin aber nicht fündig geworden.
Konkret geht es mir gerade um FS20.
Aber ich würde mal anregen, dass man den rfmode zusätzlich in die Protokollliste als weitere Spalte mit aufnimmt.
Wenn in der Protocollist in der Bemerkung nichts besonderes steht, ist es der default Mode slowrf (ASK/OOK)
https://ralf9.github.io/SD_Device_Proto.html
FS20 ist die ProtocolId 74 mit der Frequenz 868.35MHz
Die rfmodes sind für die Modulation xFSK.
N=.. ist die Durchnummerierung der verschiedenen rfmode. Wenn z.B. ein rfmode mit N=7 gewählt wird, dann können nur die ProtocolId empfangen werden wo in der Bemerkung N=7 steht
Gruß Ralf
Danke für die Erklärung, so macht es Sinn!
Das könntest du bei Gelegenheit noch in die Hilfe für das ...Adv Modul aufnehmen.
Meine Marantec Garagenfernbedienung wehrt sich bisher noch, in FHEM integriert zu werden. Die Fernbedienung trägt die Aufschrift "Marantec Digital 302 868,3 MHz". Ich habe mir jetzt einen RTL2832 SDR Stick besorgt und mit SDRSharp das Funkksignal mitgeschnitten (Export als Baseband WAV).
Ist damit eine Einschätzung möglich, ob der SignalDuino dieses Signal verstehen kann?
siehe
https://forum.fhem.de/index.php?topic=136976.0
Zitat von: meier81 am 04 Dezember 2023, 18:28:28Hab nun die Tage ein Problem gehabt. Die Stadtwerke hatten bei mir den Strom abgestellt und somit ist hier alles danach neu gestartet. Da mein MapleSduino ja am Netzwerk hängt und auch die FRITZBox neu gestartet ist war der MapleSduino schneller mit dem Start wie die FRITZBox und somit hat sich hier was mit dem Netzwerk aufgehängt, nachdem dann Abends die Rollläden nicht gefahren sind und ich dann festgestellt habe das ich den MapleSduino nicht erreiche habe ich den neu gestartet und dann ging alles wieder.
Ist es hier machbar das der in einer Art Schleife bleibt wenn er kein Netzwerk hat und es z.B. alle 10 Sekunden probiert sich neu zu verbinden?
Kann das bei mir hier nicht nach vollziehen, musste bis jetzt noch nie nach einem Stromausfall den MapleSduinoLAN neustarten. Habe auch eine Fritzbox.
Bei uns im Ort war heute Abend der Strom für ca eine Stunde weg, danach lief alles wieder.
Gruß Ralf