SIGNALDuino Empfänger Firm- und Hardware

Begonnen von Ralf9, 02 Oktober 2016, 22:59:51

Vorheriges Thema - Nächstes Thema

RaspiLED

Hi,
Ja sollte meiner Meinung nach helfen.
Kommt man halt nur schwer dran ;-) wenn schon alles verlötet ist.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

stefanru

#961
Da hast du recht, deshalb wollte ich erstmal fragen  ;)

Vielen Dank, dann werde ich versuchen dran zu kommen  ;D

P.S.: Ok habs verlötet. Ging eigentlich ganz einfach. Habs gleich bei all meinen Clones gemacht.
Ich werde berichten ob es hilft.


Sidey

Zitat von: stefanru am 11 August 2018, 16:36:42
Da hast du recht, deshalb wollte ich erstmal fragen  ;)

Vielen Dank, dann werde ich versuchen dran zu kommen  ;D

Hi Stefan,

Du schreibst, das Problem kommt erst mit RC7. Mit welcher Firmware hattest Du das Problem denn vorher nicht?

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

stefanru

Hi Sidey,

war eine selbst kompilierte 3.3.1 denke so vom März - April.
Leider kann ich dir Version nicht mehr genau benennen die drauf war.

Das Problem dass nach einem Reboot des Raspberry der Sduino erst nach trennen und neu verbinden ging hatte ich immer.
Aber einmal von Hand verbunden lief er durch.

Mit RC7 ging er von alleine alle 1-2 Tage in Closed.
Aber nach dem löten ist alles bestens und er geht auch direkt nach einem Reboot.

Ich werde mal die Logs beobachten ob der Fehler mit auftritt aber von einem automatischen reconnect überdeckt wird. Konnte aber so etwas bisher noch nicht erkennen.
Sieht also gut aus.
Kann nur empfehlen vorsichtig die 2 Pins zu verlöten.
Ich wollte es eh schon lange machen hab mich aber nie getraut. Es war am Ende nicht so schwer und ich hab keinen einzigen zerstört ;-)

Danke und Gruß,
Stefan

stefanru

So will nochmal Rückmeldung geben.
Nach dem Zusammenlöten bleibt er nun eindeutig online.
Ab und zu sieht man im Log so etwas:

2018.08.18 13:28:26 3: sduino_cc1101/KeepAlive not ok, retry = 2 -> get ping
2018.08.18 13:29:26 3: sduino_cc1101/KeepAlive not ok, retry = 3 -> get ping

das ist aber alles. Er funktioniert einwandfrei.

Was mir aber aufgefallen ist, nach einiger Zeit liefert ein get ccconf komische Werte.
ccconf: freq:95.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:3173.83Baud)

Sowohl Frequenz wie auch Baudzahl sind total schräg. Er sendet aber nach wie vor einwandfrei.
Ist das ein Problem oder nur ein Fehler in der Rückgabe?

Der Sduino ist an einem Raspberry am USB Port angeschlossen.

Gruß,
Stefan

Sidey

Zitat von: stefanru am 18 August 2018, 19:52:31
Was mir aber aufgefallen ist, nach einiger Zeit liefert ein get ccconf komische Werte.
ccconf: freq:95.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:3173.83Baud)

Sowohl Frequenz wie auch Baudzahl sind total schräg. Er sendet aber nach wie vor einwandfrei.
Ist das ein Problem oder nur ein Fehler in der Rückgabe?



Das ist seltsam. Er funktioniert trotzdem einwandfrei? Kannst Du die Register einmal manuell auslesen?


Ich habe nun die RC7 seit 11 Tagen an meinem Testsystem am laufen. Bei mir stimmt die ccconf Ausgabe.
V 3.3.1-RC7 SIGNALduino cc1101 - compiled at May 11 2018 23:00:28


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

stefanru

#966
Hm,

wirklich komisch.
Meinst du ein get raw C99?

Habe etwas beobachtet.

Also zuerst:
ccconf: freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)

ccregAll:

ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71
ccreg 10: 37 C4 30 23 B9 00 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2C 18 1F 41 00 59 7F 3F 88 31 0B


Dann ändert sich die Baudrate so    
freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:3173.83Baud)

ccregAll:

ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71
ccreg 10: 37 00 30 23 B9 00 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: 03 56 11 EF 2C 19 1F 41 00 59 7F 3F 88 31 0B


Danch auch die Frequenz
ccconf: freq:95.920MHz bWidth:464KHz rAmpl:42dB sens:8dB (DataRate:3173.83Baud)
Bei mehrmaligem get cconf bekomme ich aber einmal 433 und dann wieder 95
Register sind dann so:

ccregAll:

ccreg 00: 0D 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71
ccreg 10: 37 00 30 23 B9 00 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2C 19 1F 41 00 59 7F 3F 88 31 0B

oder so:

ccregAll:

ccreg 00: 03 2E 2D 07 D3 91 3D 04 32 00 00 06 00 10 B0 71
ccreg 10: 37 00 30 23 B9 00 07 00 18 14 6C 07 00 91 87 6B
ccreg 20: F8 56 11 EF 2C 19 1F 41 00 59 7F 3F 88 31 0B


Kannst du damit etwas anfangen?

Gruß,
Stefan

KölnSolar

Zitatwirklich komisch

find ich nicht  ;D ;)
IT stellt ja seine "eigene" Frequenz ein und wieder zurück auf die vorher eingestellte.

Woher die 95,92 dann kommen bleibt aber komisch  :-\

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

stefanru

Ok Frequenz könnte verstellt werden.
Sende aber kein IT, nur Somfy.

Und warum ändert sich die Baudrate? von 5603.79Baud auf 3173.83Baud.
Komischerweise scheint das alles der Funktion nicht zu schaden?

Gruß,
Stefan

KölnSolar

Hmm,
kein IT ?
2018.08.11 11:38:12 3: sduino IT: IT_Bewegungsmelder1 2018-08-11 11:38:12->on
2018.08.11 11:38:16 3: sduino_cc1101/KeepAlive not ok, retry = 2 -> get ping
2018.08.11 11:39:16 3: sduino_cc1101/KeepAlive not ok, retry = 3 -> get ping
2018.08.11 11:39:21 3: sduino IT: message "i1FFDFF00" (9) too short!
2018.08.11 11:39:21 3: sduino IT: message "i1FFDFF00" (9) too short!
2018.08.11 11:39:21 3: sduino: Unknown code i1FFDFF00, help me!
sending code[4294562]
sending code[4294562]
2018.08.11 11:40:17 3: sduino IT: IT_1527x4187a on->on
2018.08.11 11:40:17 3: sduino_cc1101/keepalive not ok, retry count reached. Reset
2018.08.11 11:40:17 3: sduino_cc1101 reset
2018.08.11 11:40:17 3: Opening sduino_cc1101 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0
2018.08.11 11:40:17 3: Setting sduino_cc1101 serial parameters to 57600,8,N,1
2018.08.11 11:40:17 1: sduino_cc1101/define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0@57600
2018.08.11 11:40:17 1: sduino_cc1101/init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04XDSD-if00-port0@57600
2018.08.11 11:40:17 3: sduino_cc1101 device opened

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

stefanru

Ja aber er sendet das nicht, das ist ein Empfang. Dafür wechselt er doch nicht die Frequenz, oder?

Ralf9

Hallo,

lässt sich ganz grob abschätzen wieviel freeram übrig bleiben muß, damit der sduino noch stabil und sicher funktioniert?

Für den cmdstring sollten ca 400 byte reichen. Wieviel freeram ist für das was sonst noch alles dynamisch reserviert wird ganz grob nötig?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

andies

FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

jogimaster

Hallo,

ich habe den Threat gefunden und habe mir die Wemos Shield Platine von locutus fertigen lassen.
Wie habt ihr die Durchkontaktierung für D4 und D6 vorgenommen?
Die Pins sind sehr sehr dünn und nicht freigelegt im Layout? Aufbohren würde meiner Meinung nach die Platine zerstören. Alle anderen Teile lassen sich ja ohne Probleme bestücken, auch die SMD Bauteile.

Gruß
Jogimaster

gloob

#974
Zitat von: jogimaster am 23 September 2018, 16:01:10
Hallo,

ich habe den Threat gefunden und habe mir die Wemos Shield Platine von locutus fertigen lassen.
Wie habt ihr die Durchkontaktierung für D4 und D6 vorgenommen?
Die Pins sind sehr sehr dünn und nicht freigelegt im Layout? Aufbohren würde meiner Meinung nach die Platine zerstören. Alle anderen Teile lassen sich ja ohne Probleme bestücken, auch die SMD Bauteile.

Gruß
Jogimaster

Warum willst du die Pins "durch kontaktieren"? Die sind doch normal als Pins am Wemos verfügbar.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway