FHEM Forum

Verschiedenes => Bastelecke => Thema gestartet von: Ralf9 am 13 Dezember 2019, 12:48:26

Titel: Entwicklung SIGNALDuino Empfänger Firm- und Hardware V4 für Maple Mini und ESP32
Beitrag von: Ralf9 am 13 Dezember 2019, 12:48:26
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 Varianten

a:) einfacher SIGNALduino mit nur einem cc1101 Modul

Es 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


Platine

Es 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 Firmware

Hier 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-culw

Es 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)


Bootloader

USB 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 sec


Ab 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)


Kompilieren

Wer 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:

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: Ralf9 am 13 Dezember 2019, 20:12:59
to do Liste

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: sash.sc am 13 Dezember 2019, 20:48:30
Lässt sich das sketch von esp8266 nicht ohne Probleme auf dem esp32 portieren?

Gesendet von meinem MI 9 mit Tapatalk

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: Ralf9 am 07 Januar 2020, 22:40:37
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


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.


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: locutus am 08 Januar 2020, 20:54:14
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!
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: Ralf9 am 08 Januar 2020, 21:26:53
Hallo locutus,

Zitat
Hast 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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: locutus am 08 Januar 2020, 22:32:58
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).
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: Ralf9 am 08 Januar 2020, 22:49:12
Zitat
0% 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.

Titel: Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: RaspiLED am 09 Januar 2020, 22:56:44
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: Ralf9 am 09 Januar 2020, 23:39:31
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: sash.sc am 10 Januar 2020, 06:25:19
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: Ralf9 am 10 Januar 2020, 13:55:26
Nein, von hier:
https://www.amazon.de/dp/B0785R5CCW/ref=dp_prsubs_1
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: sash.sc am 10 Januar 2020, 14:53:22
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: Beta-User am 10 Januar 2020, 15:03:02
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!).
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: RaspiLED am 10 Januar 2020, 17:56:26
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: Ralf9 am 11 Januar 2020, 13:54:43
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: papa am 11 Januar 2020, 16:23:57
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);
  ....
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 11 Januar 2020, 18:08:39
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: papa am 11 Januar 2020, 18:19:21
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 11 Januar 2020, 18:34:18
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 11 Januar 2020, 18:46:27
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: RaspiLED am 11 Januar 2020, 19:37:18
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 11 Januar 2020, 19:47:00
da ich die serial über usb verwenden will, wird er auch über usb versorgt
Titel: Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: RaspiLED am 11 Januar 2020, 20:31:24
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 12 Januar 2020, 08:43:45
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: juergs am 12 Januar 2020, 14:07:28
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 12 Januar 2020, 15:35:36
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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 12 Januar 2020, 22:42:27
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: papa am 13 Januar 2020, 09:00: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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 13 Januar 2020, 23:41:12
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: papa am 14 Januar 2020, 08:34:27
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) ;
}
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 14 Januar 2020, 22:59:33
Zitat
Eigentlich 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};
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: papa am 15 Januar 2020, 08:48:51
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
  }

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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 15 Januar 2020, 09:50:20
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: papa am 15 Januar 2020, 10:57:36
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 15 Januar 2020, 21:26:24
Zitat
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).
Danke damit funktionierts.

Zitat
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.
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);
}
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: papa am 15 Januar 2020, 22:00:39
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 15 Januar 2020, 22:11:27
Zitat
Hilft 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);
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 15 Januar 2020, 23:35:46
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 16 Januar 2020, 19:15:51
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: RaspiLED am 16 Januar 2020, 19:29:36
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 16 Januar 2020, 19:50:49
Zitat
Kann 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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 16 Januar 2020, 21:55:53
Zitat
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".

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 16 Januar 2020, 22:39:50
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.

Zitat
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?
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 16 Januar 2020, 22:48:36
Zitat
nur denke ich sollte man ein paar mm mehr an der Antennenseite spendieren...
ja, kann gerne etwas mehr rausschauen.

Zitat
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.
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.

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: PeMue am 17 Januar 2020, 07:56:59
ich lese hier mal mit  ;)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 Januar 2020, 19:48:32
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 17 Januar 2020, 20:51:19
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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 Januar 2020, 23:53:46
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)

Zitat
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...

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 

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 18 Januar 2020, 12:48:26
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 18 Januar 2020, 12:52:41
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!)

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 18 Januar 2020, 12:59:48
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.


Zitat
Mir 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>" ...)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 18 Januar 2020, 13:27:20
Zitat
ich könnte mir das ganze im Moment so vorstellen:
sieht so recht gut aus

Zitat
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)
Die LED sollte auch sichtbar sein, sonst wäre eine extra LED auf der Platine schön, evtl sogar 2 oder eine DUO LED.

Zitat
Kann 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.
 
Zitat
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...
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: papa am 18 Januar 2020, 16:33:45
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 18 Januar 2020, 17:41:04
@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.

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.

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)?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: sash.sc am 18 Januar 2020, 17:45:21


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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 18 Januar 2020, 17:57:23
Die Hardware ist ja die selbe. An Flash ist momentan noch 49KiB in der a-culfw frei.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 18 Januar 2020, 19:44:50
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


Zitat
Du 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 18 Januar 2020, 20:42:21
Das ist ja auch nicht die Ethernet Lib für den Wizchip über SPI sondern für einen STM32 mit integriertem Ethernet MAC.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 18 Januar 2020, 21:56:12
Zitat
Das 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 18 Januar 2020, 22:08:50
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 18 Januar 2020, 23:35:51
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 19 Januar 2020, 12:38:40
Zitat
Vorschlag, wir lassen hier die Vertauschung (Ethernet SPI1).

Der Schaden ist bei einer ersten kleinen Serie m.E. gering...



Zitat
Die 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Januar 2020, 12:54:15
Zitat
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:
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.

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 19 Januar 2020, 14:44:07
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.

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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Januar 2020, 15:07:24
Zitat
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.
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.

Zitat
LED 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 19 Januar 2020, 16:36:45
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.

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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Januar 2020, 21:07:11
Zitat
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.
Dann müsste ich ja die komplette Ethernet Lib in das Git Repo integrieren.

Zitat
Da 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: sash.sc am 19 Januar 2020, 21:14:13
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: RaspiLED am 19 Januar 2020, 21:28:29
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 19 Januar 2020, 22:18:34
Probier mal die LED auf 32. Der währe noch frei, weil das der Pin an der Taste auf dem Maple Mini ist.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 19 Januar 2020, 22:21:56
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...)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Januar 2020, 22:34:50
Zitat
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!?
Nach meinem Verständnis reicht es nicht nur die eine zu patchende Datei zu übernehmen.

Zitat
Oder 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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Januar 2020, 22:48:44
Zitat
Probier 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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 19 Januar 2020, 23:01:51
Die 32 ist parallel zu BOOT0.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Januar 2020, 23:11:21
Zitat
Die 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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 19 Januar 2020, 23:29:39
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.

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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: RaspiLED am 19 Januar 2020, 23:40:30
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Januar 2020, 23:51:37
Zitat
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.
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 20 Januar 2020, 08:45:51
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...

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 Januar 2020, 17:28:28
Zitat
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.
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 Januar 2020, 21:36:27
@PeMue
hast Du Dir die Platine mal angeschaut?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: PeMue am 20 Januar 2020, 21:49:04
@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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 20 Januar 2020, 22:21:13
Das ist diesmal Eagle 7...
(Teil meiner Strategie künftig nur noch KiCad zu nutzen. Und es ist wirklich viel schlechter als aktuelle Versionen.. )
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 Januar 2020, 22:33:19
Hallo Martin,

wie groß ist für Dich der Aufwand mal zum Vergleich eine Platine zu layouten mit nicht vertauschten SPI?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 21 Januar 2020, 16:23:03
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 Januar 2020, 00:50:39
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.
Titel: Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: HomeAuto_User am 22 Januar 2020, 01:08:26
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 22 Januar 2020, 12:21:15
Zitat
Heisst 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)

Zitat
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.
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...

Zitat
wenn die Empfänger abgeschirmt werden zusätzlich mit einem Metallgehäuse
Daher sind die Transceiver auch auf verschiedenen Seiten und weitestmöglich versetzt.


Zitat
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.
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 23 Januar 2020, 20:29:40
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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 24 Januar 2020, 08:11:00
Zitat
31 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 24 Januar 2020, 17:01:23
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 24 Januar 2020, 17:08:59
Jetzt passt das mit den SPI fast, 31 SPI2/SS sollte doch CC_CS0 heissen
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 24 Januar 2020, 17:22:15
Danke das ist mir durch. Ich hab daher nochmals allgemein die SPI Sachen gegengeckt. Und auch den exportierten Schaltplan wieder konsistent.
=> Done.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 27 Januar 2020, 19:35:43
@PeMue bist Du inzwischen mal dazugekommen es Dir anzuschauen?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 27 Januar 2020, 22:16:37
... ich denke ich bau noch ~zwei Kerben ein um das ganze besser in einem gedruckten Gehäuse zu positionieren...


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 31 Januar 2020, 19:08:26
...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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 31 Januar 2020, 19:21:54
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 31 Januar 2020, 19:30:18
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 31 Januar 2020, 19:39:59
Zitat
Ich 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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 31 Januar 2020, 19:46:27
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.
Titel: Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: RaspiLED am 31 Januar 2020, 22:04:22
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 02 Februar 2020, 15:27:22
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 03 Februar 2020, 19:17:48
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


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 Februar 2020, 08:47:07
@PeMue
Kannst Du ungefähr abschätzen bis wann Du dazukommen wirst, die Platine anzuschauen?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: PeMue am 06 Februar 2020, 08:04:44
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 ...

@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.

@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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 06 Februar 2020, 11:39:50
Zitat
Im Github Repo ist derzeit nur die Platzierung, korrekt?
siehe
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: PeMue am 06 Februar 2020, 17:18:15
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 06 Februar 2020, 17:51:21
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

Zitat
Wofür sind die 5 V bei DBG?
Ist mir auch nicht klar
@Ranseyer, zu was werden beim DBG 5 V benötigt?

Gruß Ralf


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 07 Februar 2020, 13:15:27
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...

Zitat
Ich 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 ?

Zitat
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?
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"...)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: PeMue am 07 Februar 2020, 15:55:01
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 07 Februar 2020, 16:23:58
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 07 Februar 2020, 18:40:53
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 07 Februar 2020, 19:00:33
... 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 07 Februar 2020, 19:14:10
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 07 Februar 2020, 19:17:06
Ok da war ich zu fix... Danke für die Rückmeldung!

Hast du auch eine Meinung zum Bedarf der Abschirmung im Empfangsmodus ?


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Telekatz am 07 Februar 2020, 19:20:35
Da hab ich keine Meinung dazu.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 07 Februar 2020, 19:28:07
Danke, dann bleibe ich bei meiner Meinung: Unnötige optionale Features sind immer, gut, aber nicht um jeden Preis.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 07 Februar 2020, 19:33:34
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 10 Februar 2020, 20:47:14
@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...)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: RaspiLED am 10 Februar 2020, 22:38:59
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 11 Februar 2020, 16:21:04
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...) .
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 13 Februar 2020, 08:53:45
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ranseyer am 13 Februar 2020, 08:57:35
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag 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)
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


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 Februar 2020, 19:40:08
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: locutus am 28 Februar 2020, 14:10:29
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag 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.jsonDas SerialUsb funktioniert bei mir nur mit dem orginal Bootloader.
Ab der Version 4.1.0-dev200427 funktioniert es auch mit dem Bootloader 2.0.

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.h


Empfehlungen 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 28 Februar 2020, 18:21:08
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: sash.sc am 28 Februar 2020, 18:23:57
Mach doch direkt die Unterstützung für alle cc1101 rein.

Gesendet von meinem MI 9 mit Tapatalk

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 28 Februar 2020, 23:02:36
Ich habe hier mal eine Beschreibung angefangen:
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 Februar 2020, 12:01:45
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 02 März 2020, 00:12:14
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 02 März 2020, 22:14:21
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: papa am 06 März 2020, 20:20:35
Da kann ich auch nicht wirklich helfen. Beim Homematic-Empfang steht der RSSI Wert direkt hinter dem Paket.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Ralf9 am 07 März 2020, 00:41:47
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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?
Im Github können die erledigten Einträge abgehakt werden, geht dies hier im fhem Forum auch?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: PeMue am 10 März 2020, 10:52:34
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: habeIchVergessen am 10 März 2020, 15:36:47
@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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 10 März 2020, 16:41:04
Zitat
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?
Nein, die Bytes + RSSI werden hier nicht verarbeitet, sondern direkt ausgegeben. Die Verarbeitung erfolgt im Signalduino Modul
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: locutus am 10 März 2020, 22:32:53
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 mode

Aber 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:50

Angeschlossen 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          18

a-culfw für MapleCUL liefert korrekte Werte zurück.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 10 März 2020, 23:00:04
Zitat
Angeschlossen 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)
CREA
sollte ergeben:
detect A: Partn=0 Ver=20
Falls CC1101_1 (B)
CREB
sollte ergeben:
detect B: Partn=0 Ver=20

Was ergibt ein C99
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 11 März 2020, 09:15:26
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 SCLK


CC1101_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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 11 März 2020, 09:25:10
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};
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 11 März 2020, 09:46:18
@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:
Zitat
For 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 11 März 2020, 19:42:40
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 14 März 2020, 00:45:55
Zitat
version    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.

Zitat
Aber 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 14 März 2020, 11:19:33
Hi zusammen,

die Platinen sind gekommen. Bei Interesse bitte hier melden: https://forum.fhem.de/index.php/topic,109220.0.html


Grüße
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 15 März 2020, 11:52:48
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.

Zitat
Das "-" 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:50

Zitat
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)
Ü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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 15 März 2020, 11:58:26
Hast du das Modul A mit CREA aktiviert?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 15 März 2020, 12:28:09
Danke für den Hinweis!

configRadio:
set MapleMini raw CREAErgebnis:
cc1101 (R: Ai B0*)
Speicherbank initialisieren:
set MapleMini raw bA1Ergebnis:
cc1101 (R: A1 B0*)
freq:800.000MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:115051.27Baud)

Frequenzkorrektur:
set MapleMini cc1101_frequency 868.350Ergebnis:
freq:868.350MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:115051.27Baud)
... soweit alles tutti.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 15 März 2020, 23:06:54
@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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 16 März 2020, 00:55:24
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)


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 19 März 2020, 08:44:16
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 21 März 2020, 15:22:07
Hallo Ralf9,

ich versuche mich gerade am Arduino-IDE-Comiple der SIGNALDuino-4.1.0-dev200306 und scheitere am eeprom_buffered_write_byte

Zitat
exit 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 März 2020, 15:49:04
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 21 März 2020, 16:14:38
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 (?):



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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 März 2020, 17:13:51
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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 Installationen ...

Jürgen
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 21 März 2020, 18:20:15
@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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 März 2020, 18:38:30
Das mit PlatformIO sieht recht kompliziert aus, da ist wahrscheinlich ein recht großer Einarbeitungsaufwand notwendig.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 März 2020, 18:53:49
Zitat
ich 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.


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 21 März 2020, 18:55:35
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 21 März 2020, 19:59:22
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'

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 März 2020, 20:07:32
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 März 2020, 20:25:31
@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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 21 März 2020, 20:37:04
Zitat
die 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 ?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 März 2020, 20:46:29
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 21 März 2020, 20:52:42
Kann man die Frequenz SW-mäßig vorgeben ? (Dann wäre die Lösung: Edding + Konfiguration)

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 21 März 2020, 20:53:34
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 März 2020, 21:00:32
Mich würde erst mal interessieren, wieviele Platinen schon vertauscht gelötet sind.

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 21 März 2020, 21:05:34
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) ?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 März 2020, 21:18:53
Zitat
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) ?

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 21 März 2020, 21:19:34
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-GND
Ist bei der Platine die mit  "DBG" bezeichnete Stiftleiste ...


Zitat
Wenn ich der einzigste bin der die Platine bereits gelötet hat,
... gerade die CC1101 eingelötet gehabt ;-(
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 21 März 2020, 21:53:43
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 März 2020, 01:20:42
Zitat
0x18 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.

Zitat
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) ?
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 22 März 2020, 10:21:41
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 ...  ;)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 22 März 2020, 10:33:18
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.
 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 März 2020, 11:08:44
Zitat
Obwohl 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

Zitat
bei meiner Platine ist der BOOT1-Pin nicht mit GND verbunden
Bei meiner ist der BOOT1-Pin mit GND verbunden.

Zitat
Aber 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.ino

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 22 März 2020, 11:25:12
Zitat
ist 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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 22 März 2020, 11:58:08
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::
Zitat
bitstore.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?

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 März 2020, 12:06:08
Zitat
Welcher Branch?
https://github.com/Ralf9/SIGNALDuino/tree/dev-r41x_cc1101
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 März 2020, 12:18:38
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 22 März 2020, 12:24:01
Zitat
(slowrf) nur auf dem zweiten Modul

Ah, verstanden !
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 22 März 2020, 12:54:52
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 ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 22 März 2020, 13:08:24
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"
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 März 2020, 14:43:40
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 22 März 2020, 16:04:02
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;
   ~~~~~~~^~~~~
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 März 2020, 23:05:35
Es gibt eine neue Version 4.1.0-dev200322
https://github.com/Ralf9/SIGNALDuino/releases

Ich habe einige Warnings beseitigt

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 23 März 2020, 09:32:11
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 23 März 2020, 22:19:20
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 23 März 2020, 22:40:13
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x auch auf Maple Mini
Beitrag von: Reinhard.M am 24 März 2020, 10:00:43
Ich verwende bei der Arduino IDE diesen core
https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.jsonDas SerialUsb funktioniert bei mir nur mit dem orginal Bootloader.
http://docs.leaflabs.com/static.leaflabs.com/pub/leaflabs/maple-bootloader/maple_mini_boot.binMit 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 24 März 2020, 10:39:25
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 März 2020, 17:11:48
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":
Zitat
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]...
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":
Zitat
C:\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:
Zitat
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

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:
Zitat
Some 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 24 März 2020, 18:55:03
Ist dein blaues MapleMini Board wirklich ein Maple Mini oder ein BluePill?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 März 2020, 18:59:42
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? :
Zitat
19: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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 24 März 2020, 20:07:27
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.

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 März 2020, 20:14:05
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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 24 März 2020, 20:53:33
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.

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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 März 2020, 21:01:37
... 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 24 März 2020, 21:16:13
Zitat
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 ...
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 März 2020, 21:18:52
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


Zitat
Ich 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 26 März 2020, 08:10:17
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 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 26 März 2020, 08:18:10
Zitat
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.
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 26 März 2020, 08:25:10
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 26 März 2020, 08:46:23
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/)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 26 März 2020, 12:12:01
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 26 März 2020, 13:01:11
Zitat
Auslö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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 26 März 2020, 13:09:17
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 26 März 2020, 13:31:10
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 )
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 26 März 2020, 13:53:27
Zitat
Wie 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 26 März 2020, 19:57:08
Zitat
ist 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=0180
Durch mein angepasstes 00_SIGNALduino.pm Modul wird es dann wie in der Anlage aufbereitet

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 27 März 2020, 06:57:17
Zitat
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 ..
.

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 27 März 2020, 12:50:54
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 27 März 2020, 18:43:35
Zitat
Da ich kein LAN-Modul nutzen werde/habe, bräuchte ich die Außen-Abmessungen.
reicht das so?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 27 März 2020, 20:08:30
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 29 März 2020, 09:08:45
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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 29 März 2020, 13:35:53
Hallo Martin,

bräuchte noch ein paar Angaben zur Ausführung, noch ohne Gehäuse:

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 ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 März 2020, 14:09:55
Zitat
Die 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 29 März 2020, 14:48:25
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 ....
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 März 2020, 15:01:22
Zitat
Würde der Krümmungs-Radius des Netzwerk-Kabels noch dazu passen?
hab mal mit einem Patchkabel gemessen siehe Anlage
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 29 März 2020, 15:06:31
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 ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 März 2020, 15:13:05
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 März 2020, 15:26:57
Zitat
hab 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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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))
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 29 März 2020, 15:41:24
...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 …  ;)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 29 März 2020, 18:10:04
Locutus MapleCUL  und MapleSDuino PIN-Zuordnung.

Firmware ist leider (noch) nicht kompatibel.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 29 März 2020, 21:10:18
@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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 März 2020, 22:22:50
Zitat
Ich 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   GPIOA

Kann dies mal jemand testen?

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 30 März 2020, 10:40:31
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 01 April 2020, 13:33:48
Vielleicht hilfreiches Tool (https://www.thesycon.de/eng/free_download.shtml) im Zusammenhang mit Bootloader.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 01 April 2020, 21:47:55
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! ?

Zitat
6543.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

 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 01 April 2020, 22:18:18
@Juergs: Ja habe ich übrig!

Bei Bedarf: PN


edit:
Zitat
dass 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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 01 April 2020, 22:25:40
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 02 April 2020, 00:39:28
Ok, danke für die Info.

Dann werde ich morgen nochmal probieren ..

Jürgen
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: trebron106 am 02 April 2020, 10:40:58
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 02 April 2020, 12:12:12
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]# 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
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

Noch das Address-Detail:
Zitat
Memory 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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 02 April 2020, 15:22:46
Ich bin über STLINK so vorgegangen:
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 03 April 2020, 19:17:28
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...

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 April 2020, 10:44:36
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 13:47:27
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:

Zitat
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-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


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 April 2020, 14:21:53
ein ls -l /dev/serial/by-id ergibt bei mir:
usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D82067E4850-if00 -> ../../ttyACM0in der DEF vom sduino steht dann:
/dev/serial/by-id/usb-STMicroelectronics_MAPLEMINI_F103CB_CDC_in_FS_Mode_8D82067E4850-if00@115200
Gruß Ralf

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 14:25:13
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 04 April 2020, 14:31:40
@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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 14:33:24
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!
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 April 2020, 15:45:05
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 17:15:33
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 ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 April 2020, 17:24:53
Zitat
An 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 17:27:21
Ok, reproduziere das über dfu-util, wie Du.
Vielleicht ist da etwas anders ....
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 17:37:16
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,
Zitat
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

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 ...


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 18:04:26
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  ;)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 April 2020, 18:24:35
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 18:29:00
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 April 2020, 20:41:01
Was ergibt ein "get Version"?

Dann ein
get sduino raw CREA
und dann wieder ein "get Version"?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 21:33:42
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 April 2020, 21:42:55
Zitat
(R: Ai B-*)

Das 433 MHz Modul B wird nicht richtig erkannt.
Was ergibt
get sduino raw CREB
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 21:45:49
raw: detect B: timeout, no cc1101
Hatte ich auch vermutet.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 April 2020, 21:51:05
Ich glaube Du kannst noch eine Platine gebrauchen, ist für Dich das Auslöten des MapleMini ein Problem?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 21:55:49
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 April 2020, 23:18:01
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 06 April 2020, 20:59:14
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 08 April 2020, 13:36:41
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

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 08 April 2020, 16:37:53
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 08 April 2020, 17:05:20
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...😅

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 08 April 2020, 17:07:12
Glaube, man muss sich nur auf eine Standard-Bauweise einigen und gut is …  ;) :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 08 April 2020, 17:15:26
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 08 April 2020, 20:39:23
Zitat
Glaube, 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 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 08 April 2020, 21:26:27
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 09 April 2020, 19:46:43
Die nächste Runde:
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 10 April 2020, 10:31:44
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) ?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 10 April 2020, 21:19:44
Anbei die STLs zum Selber-3D-Drucken.

Empfehlung: Lüfter zum Print ausschalten: "M107" oder "M106 S0".
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 11 April 2020, 00:45:56
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?

Zitat
Die 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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: sash.sc am 11 April 2020, 11:43:16
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 11 April 2020, 15:01:42
Zitat
Der 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.

Zitat
Wie 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 11 April 2020, 15:33:21
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: sash.sc am 11 April 2020, 16:43:36
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 11 April 2020, 17:51:18
Zitat
Mein 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: sash.sc am 11 April 2020, 17:59:30
Also dann eher einen esp32?!

Gesendet von meinem MI 9 mit Tapatalk

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 11 April 2020, 18:59:17
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)



Zitat
Ich habe hier 2 Stück Air602 herumliegen, werden mich mal damit etwas beschäftigen ...
plus drei :-)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 11 April 2020, 19:01:16
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 11 April 2020, 19:48:46
Zitat
Wenn 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
Zitat
C:\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)
Zitat
C:\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/)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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.

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


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 16 April 2020, 11:30:56
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.

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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 16 April 2020, 19:41:00
Zitat
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.
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

Zitat
Warum 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 -R
Um 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 device

Fall 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 003

Hier 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 device


Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 16 April 2020, 21:31:33
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)

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"
   
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 April 2020, 00:09:03
Zitat
Da 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


Zitat
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.

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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 17 April 2020, 09:19:38
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 17 April 2020, 09:59:15
Poste hier mal die .bin und die .map Datei von deinem Testsketch.

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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 April 2020, 16:57:53
Zitat
Poste 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);
}

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 17 April 2020, 17:03:22
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 April 2020, 17:08:46
Dann verhält es sich unter Windows anders als unter Linux, ich habe es bis jetzt nur unter Linux getestet
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 17 April 2020, 17:16:04
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 April 2020, 17:18:48
Zitat
Nach 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.

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 17 April 2020, 17:21:02
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?


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 April 2020, 17:41:20
Zitat
Ist 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 17 April 2020, 17:43:30
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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 17 April 2020, 21:52:47
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);
}

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 17 April 2020, 22:01:20
Wäre eine Issue bei Roger (https://github.com/rogerclarkmelbourne/STM32duino-bootloader/issues) wert.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 April 2020, 22:16:18
Zitat
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.
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.

Zitat
Man kann entweder den Bootloader patchen
Dies wäre die bessere Variante.

Kannst Du einen gepatchten Bootloader2.0 erstellen?

Gruß Ralf


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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.

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 17 April 2020, 22:40:49
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!
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 April 2020, 22:49:50
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 17 April 2020, 22:54:58
   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.

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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 April 2020, 23:17:31
Zitat
Anbei 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



Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 18 April 2020, 10:38:44
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 April 2020, 08:47:10
Ich habe von einem STM32 Core Entwickler eine Antwort bekommen:

Zitat
It 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 19 April 2020, 08:49:31
War mit Sicherheit die bessere Wahl dort nachzufragen ...  ;)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 April 2020, 09:49:26
https://www.stm32duino.com/viewtopic.php?p=2172#p2172
Zitat
Rafl9
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 19 April 2020, 10:51:13
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);  //0

Statts:
  pinMode(USB_DISC_PIN, OUTPUT);
  digitalWrite(USB_DISC_PIN, LOW);
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 19 April 2020, 11:28:58
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 April 2020, 11:46:15
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 April 2020, 12:07:12
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 < 10900
Nachtrag:
Ja ist anscheinend so.
Mit #if ARDUINO < 10800 funktioniert es nicht mehr
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 April 2020, 22:00:22
https://www.stm32duino.com/viewtopic.php?p=2197#p2197
Zitat
Ok but the intersting thing is how USB is wired

Kann jemand von Euch diese Info liefern?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 19 April 2020, 22:07:11
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 April 2020, 22:29:47
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 19 April 2020, 22:37:32
Zitat
the 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.

Zitat
wenn 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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 April 2020, 22:49:30
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 19 April 2020, 22:51:31
Vielleicht liegt es nur am Delay, also wie lange der Pulldown anliegt ?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 19 April 2020, 23:29:57
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 April 2020, 19:57:28
Zitat
Der 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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 April 2020, 20:15:04
Zitat
Nun 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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: RaspiLED am 20 April 2020, 20:22:57
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 April 2020, 22:17:49
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 - - - - -
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 20 April 2020, 22:33:19
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 21 April 2020, 07:53:48
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 23 April 2020, 22:23:57
Zitat
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 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 done
Es 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 FC

Sind die Kurzbeschreibungen so ok, oder habt Ihr bessere Vorschläge?

Gruß Ralf

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 23 April 2020, 22:53:11
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  ;)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 23 April 2020, 22:56:26
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 23 April 2020, 22:58:42
Wusste doch dass ich es schon mal gesehen hatte,  wusste nur nicht mehr wo. Danke!  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 April 2020, 16:57:26
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 c

Die EEProm-Settings wurden offenbar korrekt geschrieben und dem richtigen Modul zugeordnet, da wieder Telegramme empfangen werden.

Grüße,
Jürgen 

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 24 April 2020, 17:25:16
Zitat
Die 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;
}

Zitat
Initialisierung ü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.

Zitat
Im 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 24 April 2020, 17:32:29
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 24 April 2020, 17:37:51
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 April 2020, 17:42:24
Hallo Ralf9,
Zitat
Man 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 24 April 2020, 17:51:20
Zitat
D.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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 April 2020, 18:20:12
Zitat
hat 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:
 
Zitat
2020-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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 24 April 2020, 18:33:38
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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 24 April 2020, 18:52:16
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!  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 April 2020, 19:05:43
Zitat
Der 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.txt
oder doch eher diese:
https://github.com/RFD-FHEM/RFFHEM/blob/dev-r35_xFSK/controls_signalduino.txt
Zitat
2020.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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 24 April 2020, 22:23:14
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 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 26 April 2020, 10:25:24
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.

Zitat
2020.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 ...


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 26 April 2020, 10:40:48
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 26 April 2020, 10:50:05
Zitat
Das 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.

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 26 April 2020, 10:52:59
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"  ;)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 26 April 2020, 10:54:45
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 ...  :(
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 26 April 2020, 11:12:31
Zitat
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 ...
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 26 April 2020, 12:18:54
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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 26 April 2020, 14:51:42
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 ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 27 April 2020, 18:15:04
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:23
Zitat
2020.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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 27 April 2020, 22:46:19
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 27 April 2020, 23:31:19
Zitat
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.
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 27 April 2020, 23:54:06
Hallo Ralf,

die MAC-Adresse-auslesen: https://forum.arduino.cc/index.php?topic=453311.0 (https://forum.arduino.cc/index.php?topic=453311.0)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: laserrichi am 28 April 2020, 11:54:59
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 28 April 2020, 12:54:13
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: laserrichi am 28 April 2020, 14:10:11
:-) 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 28 April 2020, 17:00:52
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 28 April 2020, 22:40:19
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 ...  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 29 April 2020, 08:11:30
:-) 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 April 2020, 18:00:58
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 29 April 2020, 19:03:19
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 April 2020, 19:22:44
"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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 29 April 2020, 21:18:28
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 April 2020, 21:26:58
Zitat
Sollte da nicht was mit ccmode=2 stehen?
Das passt so:
Zitat
Mode 2 - IT+ 9.579 kbps (LaCrosse)   -  ccN=2,  ccmode=3

Was ergibt ein "get Version"?

Was ergibt ein "get raw bs"?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 29 April 2020, 21:31:46
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+
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 April 2020, 21:41:59
Müsste eigentlich passen.

Mich interessiert noch ein
get raw b
und
get raw C99

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 29 April 2020, 21:46:32
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 April 2020, 21:53:38
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 29 April 2020, 21:58:29
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;
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 April 2020, 22:08:27
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 30wird dann das LaCrosse device angelegt





Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 29 April 2020, 22:15:31
Sieht gut aus. Baue das morgen mal in meine FHEM Testumgebung ein.
Erstmal danke. :-)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 30 April 2020, 14:30:02
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 15:29:53
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 30 April 2020, 16:39:06
Wenn der Sensor zu nah am Signalduino liegt?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 16:48:14
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 30 April 2020, 16:49:59
Hm, wenn mit XE, dann kam vorher ein XQ (receive disable) ?

Wie sieht  das Log auf verbose 5 aus?

Zitat
Abstand der Nachrichten sind denke ich 10 Sekunden

Auf 868 MHz?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 17:00:14
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 30 April 2020, 17:23:05
Zitat
Edit: 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 April 2020, 17:41:11
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:
bAAntw: switch to radio A

und dann:
V
WS3D
br

 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 18:37:24
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 April 2020, 19:00:30
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   
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 19:39:48
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 April 2020, 20:11:02
Bitte mach mal, wenn er stoppt:

WS3D

C35

br

V
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 20:25:57
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 April 2020, 20:35:03
Läuft es mit

WS36

WS34

wieder an?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 20:40:20
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 April 2020, 20:50:21
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 21:33:36
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 April 2020, 21:45:47
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
 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 22:04:05
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 April 2020, 22:13:46
SlowRF geht momentan nur mit dem zweiten cc1101 (Radio B)
Hast Du den zweiten cc1101 nicht bestückt?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 22:18:45
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 April 2020, 22:22:26
so gehts einfacher
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 30 April 2020, 22:29:34
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. :-)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 April 2020, 22:42:59
Zitat
Wirst 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


Zitat
Wird wohl Ser2Net mit dem Maple funktionieren?
Müsste eigentlich funktionieren, einfach mal testen.
 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 01 Mai 2020, 17:26:09
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 ...

Zitat
Uploading '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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Mai 2020, 17:51:37
Zitat
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
Ist mir nicht klar, welche Richtung blockiert da?

Zitat
Die Ä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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 01 Mai 2020, 18:03:41
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 …

Zitat
Beim 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

Zitat
Uploading '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!
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Mai 2020, 18:23:28
Zitat
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.
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);


Zitat
Momentan 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 01 Mai 2020, 18:28:42
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 ...

 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 01 Mai 2020, 18:30:17
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 01 Mai 2020, 18:33:15
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 01 Mai 2020, 19:10:05
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 01 Mai 2020, 19:19:45
Hallo Ralf,

Du bist in der Binary verewigt...  ;-)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 01 Mai 2020, 21:37:20
Nach Verwendung des richtigen Schaltplans  (Es lebe die Vereinheitlichung!  ;D )
Die CC1101- Belegungen sind Versionsabhängig...

Zitat
V
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 ...

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 03 Mai 2020, 10:44:18
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)
Zitat
by rogerclark » Mon Mar 09, 2020 11:46 pm

Leider:
Zitat
I'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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 03 Mai 2020, 13:12:31
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 -R
Mit "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.0

Mit "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:23
Das 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.


@killah78
hast Du dies getestet?
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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.
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 03 Mai 2020, 21:46:53
Zitat
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.
Ja, dies ist kein Problem, dazu darf der Bank 1 (LaCrosse) kein Radio zugeodnet sein. z.B. durch deaktivieren von Radio A mit
CRDA
Dann mit
bB1das Radio B der Bank 1 zuorden



Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 03 Mai 2020, 22:04:00
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 03 Mai 2020, 22:21:34
Zitat
Auf 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 03 Mai 2020, 23:43:54
Zitat
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 
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 Mai 2020, 00:06:41
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.

Zitat
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.
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
 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 04 Mai 2020, 06:45:07
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  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 Mai 2020, 14:33:55
Hallo Reinhard.M,

danke für Dein Angebot.  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 Mai 2020, 15:01:33
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:

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!

(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)
Zitat
The 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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 Mai 2020, 16:45:18
Beispiel:

Zitat
Server 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"...  :(

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 Mai 2020, 18:26:46
Zitat
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.

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 Mai 2020, 18:55:37
Hallo Ralf9,

Zitat
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?

* 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 Mai 2020, 19:32:10
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 ?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 Mai 2020, 19:39:47
Diese
https://www.arduino.cc/en/Reference/Ethernet

es müsste diese sein
https://github.com/arduino-libraries/Ethernet
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 Mai 2020, 19:43:19
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 ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 Mai 2020, 21:05:15
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:
Zitat
C:.
├───Client
├───LED-AP
├───NTP
├───NTPClient
├───Oneshot-Key
└───Sta

Uh!.

/edit: die Methoden sind im ClientContext versteckt.  :)

Ok, programmiere das mal in Arduino aus ....
 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 Mai 2020, 21:18:31
Es gibt dafür schon was, einfach mal nach "WiFiTelnetToSerial" suchen.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 04 Mai 2020, 21:20:31
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:
Zitat
Server 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  ;) ::)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 05 Mai 2020, 10:19:07
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 05 Mai 2020, 17:29:33
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 05 Mai 2020, 21:33:30
Zitat
Kaum macht man es richtig, schon geht es !
Da bist Du jetzt ein großen Schritt vorwärts gekommen.

Zitat
Ist 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 05 Mai 2020, 22:04:11
Hallo Ralf,
Zitat
Ich 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 05 Mai 2020, 22:06:01
Version 1 reicht bei if/else Konstrukten bereits. Bei case kann sowas zu Fehlern führen.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 05 Mai 2020, 22:58:51
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 05 Mai 2020, 23:38:23
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 06 Mai 2020, 12:48:26
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 06 Mai 2020, 13:10:38
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 06 Mai 2020, 14:38:26
Hallo Ralf9,

hast Du mal mit den Compiler-Optimierungen variiert?

https://gcc.gnu.org/onlinedocs/gnat_ugn/Optimization-Levels.html
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 06 Mai 2020, 22:52:23
Zitat
hast Du mal mit den Compiler-Optimierungen variiert?

Nein habe ich noch nicht gemacht. Meinst Du die in der Anlage?

Was schlägst Du vor?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 06 Mai 2020, 22:53:55
Ja, genau die …. "Smallest" ist evtl. zu drastisch …
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 07 Mai 2020, 09:52:05
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:

GNDGND
3V3VCC
SCLTX3/SCL = Pin 1
SDARX3/SDA = Pin 0
RESNRESET = Pin RESET
DCCC_IN_3 = Pin 14
CSCC_CS3  = Pin 3
BL(Backlight) Brücke mit 3V3
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 07 Mai 2020, 14:26:59
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 07 Mai 2020, 16:20:29
Zitat
Mit LAN oder ohne über USB?
USB läuft stabil, da konnte ich bis jetzt noch keine Abstürze beobachten.


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 );
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 07 Mai 2020, 17:15:27
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 ...  :(
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 07 Mai 2020, 20:08:39
Ich habe ohne LAN, nur mit USB getestet. Hat aber nichts gebracht, der Maple hing nach 7 Stunden wieder fest.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 07 Mai 2020, 20:10:29
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) ?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 07 Mai 2020, 20:11:56
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 07 Mai 2020, 20:14:11
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 ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 07 Mai 2020, 20:32:23
Wie sieht es denn mit dem eingebauten aber deaktivierten Watchdog aus? Was setzt der alles zurück? Wäre das ein Test wert?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 08 Mai 2020, 00:51:20
Zitat
Ich 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.

Zitat
Wie 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,
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 08 Mai 2020, 06:37:02

Hatte 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 08 Mai 2020, 07:45:07
Zitat
Mit 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?

Zitat
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.
@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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 08 Mai 2020, 08:11:50
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.?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 08 Mai 2020, 09:17:27
Zitat
Kann 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 08 Mai 2020, 09:43:32
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 08 Mai 2020, 10:41:17
@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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 08 Mai 2020, 10:45:23
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 08 Mai 2020, 10:53:47
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 08 Mai 2020, 12:44:55
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!

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 08 Mai 2020, 18:43:23
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 08 Mai 2020, 20:03:10
ich hab das hier gefunden,
Zitat
Utility 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 08 Mai 2020, 23:15:05
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? 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 08 Mai 2020, 23:58:46
Mit diesem Befehl lässt sich der Maple Mini reseten
./upload-reset /dev/ttyACM0 750https://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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 09 Mai 2020, 06:33:43
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 09 Mai 2020, 09:28:14
Zitat
Hier 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 09 Mai 2020, 09:34:18
ist Dein "Kandidat" ein original Maple oder ein MapleCUX?
Der Kandidat ist ohne Netzwerkanbindung.

Zitat
Die Binary von Ralf9 oder selbst compiliert, wie upgeloaded?
dev200501.bin aus dem GitHub Repo.

Zitat
Ist /dev/ttyACM0 die richtige Schnittstelle?
Definitv ja!
ls -l /dev/ttyACM0
crw-rw----+ 1 root dialout 166, 0 May  9 09:15 /dev/ttyACM0
Was 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:0003
Zitat
Bootloader 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 09 Mai 2020, 09:45:02
Präziser:
Zitat
Der 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 …

Zitat
Die 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 ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 09 Mai 2020, 09:47:59
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 09 Mai 2020, 10:05:46
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 09 Mai 2020, 11:09:08
hier hat nun auch stevestrong was dazu geschrieben:
https://www.stm32duino.com/viewtopic.php?p=2653#p2653
Zitat
USB 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 09 Mai 2020, 15:49:28
Zitat
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.
Habe das Schreiben in die Readings verbessert
https://github.com/Ralf9/RFFHEM/commit/7294042970f857f554571a508717ca7ac37cf526

Habe heute Abend vor dies einzubauen
Zitat
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 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 09 Mai 2020, 19:29:05
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 09 Mai 2020, 21:56:30
Verwendest Du den Maple Mini oder Deine eigene Hardware?
Meine eigene Hardware. Die USB Disconnect Schaltung ist vorhanden.

Zitat
Funktioniert es mit einem ungepatchten Bootloader2.0?
Nein, auch nicht.

Zitat
mit "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: 6565BF8F3332

Bisher traue ich den EEPROM Updates für RPi4 und den daraus resultierenden Verschlimbesserungen für USB nicht über den weg.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 09 Mai 2020, 22:08:36
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 09 Mai 2020, 22:22:30
Hallo Locutus,

bist Du sicher, dass Deine Schaltung diesem Layout entspricht, wenn Du mit Ralf's Binary arbeitest?

Jürgen
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 09 Mai 2020, 22:47:57
Zitat
bist 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 -> ../../ttyACM0

Das dmesg sieht recht gut aus
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 09 Mai 2020, 23:36:45
Zitat
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.
Hab es eingebaut
https://github.com/Ralf9/RFFHEM/commit/c69593f34a3116f4f5f8dce8ad18a51fbf1b0ebb
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 10 Mai 2020, 13:27:06
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!

Zitat
An 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):

Zitat
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...

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 10 Mai 2020, 13:56:36
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   
---------------------------



Zitat
Counter: 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:

Zitat
Counter: 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!
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: RaspiLED am 11 Mai 2020, 06:27:05
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, ...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 11 Mai 2020, 09:01:31
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 11 Mai 2020, 22:15:31
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 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 12 Mai 2020, 08:22:15
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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

Zitat
Beim "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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 12 Mai 2020, 08:44:56
Hallo Ralf,


Zitat
Habt 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 12 Mai 2020, 10:51:19
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:
Zitat
2020.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  :-[ )
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 12 Mai 2020, 16:53:58
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 12 Mai 2020, 18:39:30
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 12 Mai 2020, 18:57:46
/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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 12 Mai 2020, 19:09:40
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 12 Mai 2020, 19:19:27
Wenn ich als "pi" die Datei aufrufe kommt als Antwort "Binärformat fehlerhaft". Werde gleich mal kompilieren...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 12 Mai 2020, 19:35:25
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 12 Mai 2020, 21:34:54
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.

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 13 Mai 2020, 16:46:36
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 13 Mai 2020, 17:52:41
Zitat
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.
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 13 Mai 2020, 19:54:18
Werde ich testen  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 14 Mai 2020, 08:25:58
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 14 Mai 2020, 08:36:33
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 14 Mai 2020, 08:51:07
Zitat
Wenn 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 14 Mai 2020, 08:53:26
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 14 Mai 2020, 09:43:35
Zitat
Anscheinend 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)

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 14 Mai 2020, 10:04:51
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:
Zitat
raw: detect A: timeout, no cc1101
Mit einem bA1 oder bB0 wird nichts bewirkt. Ein bA schaltet nicht auf Modul A:
Zitat
raw: radio is not aktive!
Was übersehe ich? Habe übrigens die aktuellste Version verwendet:
Zitat
raw: V 4.1.1-dev200509 SIGNALduino cc1101 (R: A- B-*) - compiled at May 14 2020 09:50:49
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 14 Mai 2020, 10:08:02
Das sieht nach der Version für den MapleCul aus
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 14 Mai 2020, 10:14:05
Ganz richtig, ich arbeite mit der MapleCUL Version.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 14 Mai 2020, 10:36:51
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 14 Mai 2020, 12:54:13
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 15 Mai 2020, 08:12:27
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 15 Mai 2020, 20:21:03
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 16 Mai 2020, 10:50:52
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 16 Mai 2020, 22:08:26
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 Mai 2020, 11:56:12
mittlerweile habe ich eine uptime von 4 Tagen und 14 Stunden.

Zitat
mit 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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 17 Mai 2020, 14:36:06
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 Mai 2020, 14:39:48
Zitat
Es ist immer das A-Modul.
Passiert dies auch mit ccmode=4
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 17 Mai 2020, 15:04:26
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 - - - - -

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 18 Mai 2020, 09:47:15
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 18 Mai 2020, 09:59:37
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:

Zitat
2020.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. ;-(
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 18 Mai 2020, 10:22:12
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  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 18 Mai 2020, 10:28:48
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 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 19 Mai 2020, 12:23:49
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 23 Mai 2020, 18:06:32
UART2+3 funktionieren schon mal im Zusammenspiel im MapleSduino_SER2WLAN (https://github.com/juergs/MapleSduino_SER2WLAN).
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 Mai 2020, 11:50:05
Hallo Ralf,

Zitat
void 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
Zitat
while (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":

Zitat
serialEvent.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?

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 24 Mai 2020, 18:22:35
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

Zitat
LTO - 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:
Zitat
Produce 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 Mai 2020, 19:58:24
Zitat
Kann 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.

Zitat
SerialDebug 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 Mai 2020, 19:06:20
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?


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 30 Mai 2020, 08:40:46
@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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 Mai 2020, 10:48:30
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 = 3


Mir 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


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 30 Mai 2020, 11:40:54
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 01 Juni 2020, 01:06:23
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Juni 2020, 10:19:16
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 01 Juni 2020, 11:18:15
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.

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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Juni 2020, 11:38:33
Zitat
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.

@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?

Zitat
Mit 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 01 Juni 2020, 12:31:13
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Juni 2020, 13:11:59
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)


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 01 Juni 2020, 13:36:54
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Juni 2020, 20:23:26
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 01 Juni 2020, 22:08:23
Lösch die "USBD_reenumerate.c" aus dem Projektverzeichnis. Dann funktioniert es auch mit dem core 1.9.0.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Juni 2020, 22:20:22
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 01 Juni 2020, 22:41:25
Bei mir ist der Maple Mini immer noch auswählbar. Das Generic F103CB ist das falsche Board.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Juni 2020, 22:59:13
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Juni 2020, 23:14:51
Meine Auflösung ist nur 1920 * 1080.

Nachdem ich den MapleMini Eintrag ausgewählt habe, funktioniert nun auch das USBD_reenumerate wieder :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 02 Juni 2020, 16:10:19
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  ;)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 02 Juni 2020, 17:07:21
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 02 Juni 2020, 17:44:24
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 03 Juni 2020, 01:32:26
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: RichardCZ am 03 Juni 2020, 10:14:07
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 03 Juni 2020, 19:32:07
Zitat
Im 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

Zitat
k.A. wen da was geritten hat.
Da wird sich Sidey wahrscheinlich nicht mehr daran erinnern was er da vor ca 5 Jahren programmiert hat :)



Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: RichardCZ am 03 Juni 2020, 22:45:04
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."


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 Juni 2020, 16:04:18
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 04 Juni 2020, 20:27:42
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 05 Juni 2020, 01:07:04
Zitat
Eine 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 05 Juni 2020, 19:44:08
Hallo Ralf,
der Watchdog funktioniert:
V 4.1.1-dev200603 SIGNALduino cc1101 (R: A1 B0*) wr - compiled at Jun 4 2020 17:01:52Kam nach ca. 3 Stunden, lief davor aber schon mal 15 Stunden. Sporadisch halt.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 06 Juni 2020, 22:51:27
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

Zitat
Kam 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 07 Juni 2020, 22:12:56
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 07 Juni 2020, 22:38:49
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 08 Juni 2020, 00:00:45
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 08 Juni 2020, 00:20:01
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.binoder
./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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 08 Juni 2020, 08:10:19
@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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 08 Juni 2020, 10:46:54
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 08 Juni 2020, 20:33:42
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 10 Juni 2020, 22:24:42
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: RaspiLED am 11 Juni 2020, 11:16:51
Hi,
meinst Du so etwas:
https://github.com/AlphaLima/ESP32-Serial-Bridge (https://github.com/AlphaLima/ESP32-Serial-Bridge)
Gruß Arnd
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 12 Juni 2020, 18:25:31
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 12 Juni 2020, 19:36:07
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 12 Juni 2020, 21:24:18
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:
Zitat
fhem.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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 12 Juni 2020, 21:35:38
Zitat
Das Ganze auf einem Raspi 4B mit
Der ist dann wahrscheinlich deutlich schneller als der Banana Pi.

Beim Banana Pi habe ich dies
Zitat
Linux banaNAS 5.1.1-BPI-Kernel #1 SMP Thu Aug 22 13:53:49 CST 2019 armv7l GNU/Linux
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 12 Juni 2020, 21:36:46
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 15 Juni 2020, 19:50:41
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 15 Juni 2020, 20:20:15
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 15 Juni 2020, 21:21:25
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.


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"...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 15 Juni 2020, 22:13:51
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 15 Juni 2020, 23:15:38
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:
Zitat
Wenn 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 15 Juni 2020, 23:24:41
Danke, habe die Kondensatoren und die Koaxbuchsen ergänzt.

Zitat
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.

Nein es gibt noch keinen Wiki Artikel zum Maple-SDuino, ist eine sehr gute Idee einen anzulegen.

Zitat
und 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

Zitat
Wenn 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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 16 Juni 2020, 10:46:58
Hallo Ralf9,
vielleicht mal wieder etwas zu Off-Topic: USB-Kabeltester (http://hlembke.de/arduinoablage/crate.php?20180204usbcabletester)

Jürgen
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 16 Juni 2020, 13:27:28
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...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: ph1959de am 16 Juni 2020, 15:07:13

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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)))
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: ph1959de am 16 Juni 2020, 16:53:31
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 16 Juni 2020, 17:14:21
Genau. Anschluss per USB oder LAN.

Aber wohin genau schreiben ? (Magst du das übernehmen?)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: ph1959de am 16 Juni 2020, 17:17:22
Genau. Anschluss per USB oder LAN.

Aber wohin genau schreiben ? (Magst du das übernehmen?)
Gern - links = LAN, rechts = USB?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 16 Juni 2020, 17:18:23
Genau...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 16 Juni 2020, 19:42:19
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 16 Juni 2020, 20:09:31
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

Zitat
Die "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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 16 Juni 2020, 20:36:08
Zitat
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).

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 16 Juni 2020, 21:54:56
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.
Zitat
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.

Diesen gibt es bei Conrad eben nur in der erwähnten Größe.
Kann alternativ ein Kondensator ohne Polung verwendet werden?

Gruß
Rolf

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 16 Juni 2020, 22:08:55
Zitat
Diesen 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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 16 Juni 2020, 22:25:17
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: ph1959de am 17 Juni 2020, 10:00:21
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 Juni 2020, 17:40:03
Zitat
Die 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 17 Juni 2020, 18:42:27
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 :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 18 Juni 2020, 18:37:49
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 19 Juni 2020, 06:38:47
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Juni 2020, 19:24:57
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/

Zitat
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.
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 19 Juni 2020, 20:01:21
Wenn du nur wenige Bytes vor einem Reset retten möchtest, kannst du beim STM32 auch die Backup Register (BKP) verwenden.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 19 Juni 2020, 20:46:55
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Juni 2020, 20:56:06
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 19 Juni 2020, 21:00:05
Wäre perfekt, würde ich gleich einspielen wenn du es eingebaut hast.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Juni 2020, 21:07:07
Kann eine Weile dauern, muß es erst mal an einem Testsketch testen und rausfinden welche inludes notwendig sind
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 19 Juni 2020, 21:09:13
Kein Thema, mir läuft die Zeit nicht weg  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 Juni 2020, 15:18:23
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-"
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 20 Juni 2020, 19:30:43
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 22 Juni 2020, 08:54:31
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 Juni 2020, 09:07:31
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 22 Juni 2020, 09:27:55
Sensor abschalten kann ich testen. Der Sensor ist eine Wetterstation mit Temp, Hum, Wind
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 22 Juni 2020, 11:14:51
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 23 Juni 2020, 20:01:37
Zitat
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.
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-decoder
Dies 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 23 Juni 2020, 21:40:57
Zitat
Empfä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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 23 Juni 2020, 22:51:03
Zitat
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;
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=1
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 23 Juni 2020, 23:43:56
Zitat
Als workaround kannst Du mal folgendes versuchen:
Code: [Auswählen]
CSmaxMsgSizex256=1
Gerade eingetragen, mal sehen was passiert  ::)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 25 Juni 2020, 18:18:11
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?  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 25 Juni 2020, 21:10:31
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 26 Juni 2020, 10:07:04
Zitat
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.

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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 26 Juni 2020, 20:06:58
Zitat
und 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


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 26 Juni 2020, 20:49:57
Zitat
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?  :)
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 26 Juni 2020, 21:46:19
Hallo Ralf,

Zitat
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

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 closed

Unabhä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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 26 Juni 2020, 22:01:32
Zitat
MapleSduino1/define: /dev/serial/by-id/usb-LeafLabs_Maple-if00@57600
Zitat
Die Baudrate wurde auf 115200 erhöht.
Die DEF passt nicht.
DEF /dev/serial/by-id/usb-LeafLabs_Maple-if00@115200
Hast 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 -> ../../ttyACM0


Zitat
Was 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"

Zitat
und 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.0.x
Beitrag von: RaspiLED am 27 Juni 2020, 08:52:22

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Beta-User am 27 Juni 2020, 09:18:45

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...)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 27 Juni 2020, 22:43:40
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.

Zitat
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?
Ja, eine serielle übers LAN sollte machbar sein. Eine serielle über USB ist wahrscheinlich nicht machbar.

Gruß Ralf

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 28 Juni 2020, 15:22:55
Hier sind die aktuellen bin Files
https://github.com/Ralf9/SIGNALDuino/releases/tag/V4.1.1-dev200627
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 28 Juni 2020, 20:33:37
Hallo 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?

Gruß Reinhard
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 28 Juni 2020, 20:40:26
Hallo Ralf,

Zitat
Hast 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:06

Bei der Auswahl der FW war ich etwas verwirrt durch die Information in der Wiki "https://wiki.fhem.de/wiki/Maple-SignalDuino"
Zitat
Die "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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ranseyer am 28 Juni 2020, 20:42:55
@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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 28 Juni 2020, 20:56:36
Zitat
Hallo 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 28 Juni 2020, 21:30:16
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...  :-[
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 28 Juni 2020, 21:35:27
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 28 Juni 2020, 22:01:48
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 28 Juni 2020, 22:21:55
Zitat
Seitdem 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 29 Juni 2020, 18:05:08
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 Juni 2020, 18:55:30
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 29 Juni 2020, 22:17:12
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 29 Juni 2020, 22:52:37
Zitat
Bei 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.

Zitat
aber 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
Zitat
Zudem 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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 Juni 2020, 20:18:59
Hallo Reinhard

konntest Du die LAN Version inzwischen inbetrieb nehmen?

Zitat
Auß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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 30 Juni 2020, 21:20:29
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  ;)

@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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 30 Juni 2020, 21:34:14
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 Juni 2020, 21:53:05
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 Juni 2020, 22:02:11
Zitat
Allerdings 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:41

kann 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 ";"
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 30 Juni 2020, 22:04:28
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 30 Juni 2020, 22:07:38
Hallo Ralf,

vielen Dank.
Zitat
Die 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.

Zitat
Ist 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:04
Zudem 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


Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 30 Juni 2020, 22:23:57
@Reinhard.M
funktioniert die Maple_cul_USB_411dev200627 bei Dir?
Seit mehr als 2 Tagen fehlerfrei  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 Juni 2020, 22:32:23
Hallo Rolf

Zitat
Gibt 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?

Zitat
Lä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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 30 Juni 2020, 22:38:51
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 01 Juli 2020, 15:57:57
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 01 Juli 2020, 19:42:28
Hallo Ralf,

Zitat
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
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.
Zitat
r=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.

Zitat
Hast 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
 

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Juli 2020, 20:47:03
Zitat
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.
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 02 Juli 2020, 20:24:06
Hallo Ralf,

Zitat
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?

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 02 Juli 2020, 21:44:57
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: nagelreo am 02 Juli 2020, 22:24:12
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 02 Juli 2020, 22:44:41
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?

 
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 02 Juli 2020, 23:50:08
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: locutus am 03 Juli 2020, 21:33:54
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 …
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 03 Juli 2020, 23:31:29
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.
Zitat
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. Wäre sicher hilfreich wenn "Bedarf" etwas präzisiert wird.
Habe ich geändert.

Zitat
Ich 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 04 Juli 2020, 08:31:01
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  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Telekatz am 04 Juli 2020, 10:16:00
@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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 Juli 2020, 20:53:17
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.


Zitat
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
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.

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 05 Juli 2020, 23:12:51
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: FunkOdyssey am 06 Juli 2020, 17:56:03
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 06 Juli 2020, 18:53:56
Zitat
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?
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 12 Juli 2020, 18:36:06
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: FunkOdyssey am 13 Juli 2020, 17:34:58
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 13 Juli 2020, 22:26:03
Zitat
An 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: FunkOdyssey am 14 Juli 2020, 11:59:51
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 15 Juli 2020, 00:18:36
Zitat
Ich 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 19 Juli 2020, 17:29:50
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 Juli 2020, 00:49:29
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 26 Juli 2020, 18:26:36
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 30 Juli 2020, 08:42:08
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 August 2020, 00:16:21
Zitat
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?
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 01 August 2020, 11:10:15
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 August 2020, 14:41:20
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 14 August 2020, 08:43:58
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 14 August 2020, 15:48:18
sollte eigentlich funktionieren, hast Du für USB ein fertiges bin File genommen?

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 14 August 2020, 15:59:06
Frisch compiliert. Das gleiche habe ich auf einem zweiten Sduino im Einsatz. Da läuft es problemlos. Werde gleich mal weitersuchen.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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 wirdin der signalDecoder4.h beachtet?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 14 August 2020, 20:31:20
Du hast Recht, das könnte es sein. Da hatte ich nicht mehr dran gedacht. Checke ich heute noch
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 14 August 2020, 22:42:28
hast Du auch das
//#define LAN_WIZ 1 // die Ausgabe ueber Ethernet funktioniert nur, wenn dies hier nochmals definiert wirdin 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.
Titel: Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: smarty_111 am 15 August 2020, 11:49:23
Welche Firmware passt für diesen Doppel CUL?
Oder sind die cc1101 falsch angebunden?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 15 August 2020, 12:07:31
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  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 15 August 2020, 13:01:31
diese hier
sudo dfu-util -d 1eaf:0003 -a 2 -D Maple_cul_USB_411dev200627.bin -R
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 20 August 2020, 13:12:12
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: HomeAuto_User am 20 August 2020, 13:47:16
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 20 August 2020, 14:13:06
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 20 August 2020, 16:10:41
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!
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 20 August 2020, 16:13:28
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 August 2020, 10:08:48
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

Zitat
Da 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


Zitat
Leider 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 22 August 2020, 11:18:13
Zitat
Hast 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 August 2020, 14:02:12
Zitat
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.
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?

Zitat
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.
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 24 August 2020, 10:34:37
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.



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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 25 August 2020, 20:53:07
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 27 August 2020, 15:06:26
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 27 August 2020, 15:27:34
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 27 August 2020, 16:12:09
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 27 August 2020, 16:16:11
Zitat
Ich 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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 27 August 2020, 16:31:26
Zitat
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.
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.

Zitat
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...

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 27 August 2020, 17:36:41
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 02 September 2020, 17:43:29
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 02 September 2020, 18:24:56
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 02 September 2020, 19:09:34
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 02 September 2020, 20:12:56
Zitat
MU;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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 02 September 2020, 22:01:49
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 02 September 2020, 22:18:42
Kannst Du mir bitte per pm oder email (wegen der keys) mal ein List von Deinem Keeloq device schicken?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 03 September 2020, 07:58:08
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 03 September 2020, 10:09:22
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 03 September 2020, 16:11:03
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. :-)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 03 September 2020, 16:43:21
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: emovere am 28 Oktober 2020, 09:49:50
Hallo,
Kann man die SIGNALDuino Firmware für das CC1101_1 Modul (433MHz) in einer MAPLE CUL Ver. 3.5 flashen?
Danke mehrmals!
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 28 Oktober 2020, 12:55:22
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: emovere am 11 November 2020, 07:44:26
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!
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 11 November 2020, 19:55:38
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: DirkS am 01 Dezember 2020, 16:05:34
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 01 Dezember 2020, 22:11:38
Zitat
Die 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: DirkS am 02 Dezember 2020, 08:23:40
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!
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 04 Dezember 2020, 00:33:24
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 1
diese PIN müssen angepasst werden
#elif MAPLE_CUL
#define PIN_LED              33
#define PIN_SEND             17   // gdo0 Pin TX out
        #define PIN_RECEIVE          18
hier 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};


Zitat
Ich 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: DirkS am 06 Dezember 2020, 22:13:58
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.

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 06 Dezember 2020, 23:18:06
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?
Zitat
Zudem 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: DirkS am 07 Dezember 2020, 11:03:33
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 13 Dezember 2020, 16:49:21
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 16 Dezember 2020, 22:16:17
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 Dezember 2020, 20:55:50
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 Dezember 2020, 01:53:05
Zitat
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?
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 Callback

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 22 Dezember 2020, 08:27:06
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 22 Dezember 2020, 23:11:47
Liest hier jemand mit der mir mit dem callback weiterhelfen kann?
@Telekatz
@papa
@juergs
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 23 Dezember 2020, 06:57:00
Hallo Ralf,

ich lese zwar mit muss aber leider genauso passen wie Markus, sorry.

Gruß Reinhard
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 24 Dezember 2020, 10:18:52
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!]

Zitat
Wenn 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) !

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 25 Dezember 2020, 12:33:09
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 27 Dezember 2020, 16:11:41
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 28 Dezember 2020, 12:53:13
Habe es inzwischen mit dem callback hinbekommen
https://onlinegdb.com/PB2zjh7re
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 29 Dezember 2020, 16:54:39
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 30 Dezember 2020, 15:33:09
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: GerhardSt am 03 Januar 2021, 21:13:20
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 03 Januar 2021, 21:34:29
Zitat
Brauch 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.

Zitat
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?
https://wiki.fhem.de/wiki/Maple-SignalDuino#Platine
https://wiki.fhem.de/wiki/Maple-SignalDuino#Teile

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 04 Januar 2021, 06:42:51
Hallo Gerhard,

bezüglich

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 13 Januar 2021, 22:43:37
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);
...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 14 Januar 2021, 00:07:30
hab den Fehler gefunden, jetzt funktioniert das rssi callback
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 16 Januar 2021, 13:19:03
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 16 Januar 2021, 13:40:45
Hallo Ralf9,
Zitat
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?
Einfach eine Leerzeile dazwischen.

Grüße,
Jürgen
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 Januar 2021, 00:05:00
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 17 Januar 2021, 14:15:06
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 Januar 2021, 22:31:00
Hallo Reinhard,

Zitat
Fü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)
Zitat
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.
Ich finde bei der Boardauswahl Text besser als eine Zahl.

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 21 Januar 2021, 09:20:38
Guten Morgen Ralf,
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 Januar 2021, 09:28:55
https://github.com/Ralf9/SIGNALDuino/commit/21915b1827b958bec8b81c97c2ec49b36b4c3369
https://github.com/Ralf9/SIGNALDuino/tree/dev-r412_cc1101
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 21 Januar 2021, 09:34:18
Werde ich heute Abend testen...
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 23 Januar 2021, 14:32:03
Hallo Ralf,
hat leider etwas gedauert. Mit der neuen Version war ich leider nicht erfolgreich, siehe angehängten Screenshot.

Gruß Reinhard
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 23 Januar 2021, 14:35:45
Ich möchte mal sehen was im EEPROM ab der 0x40 steht, bitte mach mal ein "get raw rN0040"
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 23 Januar 2021, 14:38:06
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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 23 Januar 2021, 14:41:09
wenn Du die Bank 0 mit "get raw e0" auf SlowRF zurücksetzt, müsste es passen
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Reinhard.M am 23 Januar 2021, 14:43:15
Kaum macht man's richtig...  ;D

Danke dir, schönes WE
Reinhard
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: jochen_f am 05 Februar 2021, 14:03:24
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 05 Februar 2021, 20:13:23
Welches Board hast Du bei der Arduino IDE zum kompilieren verwendet? Maple Mini?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: jochen_f am 05 Februar 2021, 21:36:44
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 05 Februar 2021, 22:24:40
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 05 Februar 2021, 22:45:38
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 05 Februar 2021, 22:56:17
Hallo Markus,

die V 4.1.2 ist inzwischen soweit fertig, längere Tests habe ich noch nicht gemacht.

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 06 Februar 2021, 11:11:39
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: jochen_f am 06 Februar 2021, 15:43:16
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 06 Februar 2021, 21:53:08
Zitat
Diesen 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;
#endif

In 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();
#endif

Mir ist dabei nicht klar warum jetzt die "serialEvent()" nicht mehr automatisch aufgerufen wird.

Gruß Ralf
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: jochen_f am 07 Februar 2021, 11:29:59
Ich habe versucht es etwas einfacher hinzubekommen:

Funktioniert prima.

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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: bublik10 am 08 Februar 2021, 10:04:13
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??
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: jochen_f am 09 Februar 2021, 08:50:35
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 13 Februar 2021, 12:33:44
Zitat
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.
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 14 Februar 2021, 11:16:43
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 14 Februar 2021, 11:48:58
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 14 Februar 2021, 12:02:09
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: killah78 am 14 Februar 2021, 18:32:02
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: bublik10 am 16 Februar 2021, 07:38:40
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 13 März 2021, 21:03:00
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

Ich hab das hier dazu gefunden:
https://community.st.com/s/question/0D53W000003MAHkSAO/stm32f103c8t6-with-128kb-of-flash-instead-of-64-fake-or-genuine
Zitat
STM32F103x8 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

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 14 März 2021, 11:53:52
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:

Nach langer Pause hat sich wirklich viel getan und der Thread hat deutlich zugenommen ....  :D

Grüße,
Jürgen

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 14 März 2021, 12:57:12
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: rob am 16 März 2021, 22:58:33
...
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 17 März 2021, 17:48:39
Zitat
CC1101_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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 17 März 2021, 18:15:11
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: rob am 17 März 2021, 20:05:37
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 17 März 2021, 20:38:01
Ja, das ist der Sinn dahinter.  ;)

https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Feinfinger am 20 März 2021, 07:18:46
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 20 März 2021, 09:04:47
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 März 2021, 09:59:10
siehe hier
https://forum.fhem.de/index.php/topic,106278.msg1049877.html#msg1049877
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 20 März 2021, 14:49:16
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Feinfinger am 20 März 2021, 14:51:44
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


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?

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 20 März 2021, 14:53:55
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)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Feinfinger am 20 März 2021, 15:14:45
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 20 März 2021, 15:23:20
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Feinfinger am 20 März 2021, 15:31:02
Ich finde auch die Maple_Mini Zeile nicht.

Ist das ein Fehler in der compileConfig.h?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 20 März 2021, 15:32:57
Welche Signalduino Version?

Zitat
Ist 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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Feinfinger am 20 März 2021, 16:31:08
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Feinfinger am 20 März 2021, 16:50:45
Vielleicht kann mir doch jemand eine kompilieren.

MapleMini 128k

Ranseyer Platine

1x 433 MHz

LAN Modul bitte mit DHCP


Danke!

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 März 2021, 17:03:51
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.
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Feinfinger am 20 März 2021, 17:44:40
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.

Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 20 März 2021, 17:51:55
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 21 März 2021, 10:12:39
@ 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 21 März 2021, 10:15:35
Die Einstellungen in Arduino wären was für das Wiki  ;)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Feinfinger am 21 März 2021, 10:33:55
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  :)
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: M_Str am 21 März 2021, 12:53:57

Hallo,
gibt es jemanden, der das Gerät fertig aufgebaut verkauft?

Gruß
Martin
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: juergs am 21 März 2021, 13:19:07
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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Ralf9 am 21 März 2021, 15:36:56
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 ESPdamit 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: Feinfinger am 21 März 2021, 17:56:46
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?
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag 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
Titel: Antw:Entwicklung SIGNALDuino Empfänger Firm- und Hardware V 4.x.x auch auf Maple Mini
Beitrag von: meier81 am 21 März 2021, 20:44:29