Signalduino Entwicklung

[Sidey]

Ah ok, die Nachrichten mit einer 0 könnte man wohl korrigieren, wenn ich die Ausgabe von vollen bytes auf Nibble umstelle. Aktuell werden immer zwei Nibble ausgegeben.

Das mit der 00 am Ende kann nur passieren, wenn 00 empfangen wurde, oder z.B. nur eines der 8 Bit.
Das kann man dann aber nur in FHEM erkennen schätze ich.

Grüße Sidey

[Ralf9]

Ah ok, die Nachrichten mit einer 0 könnte man wohl korrigieren, wenn ich die Ausgabe von vollen bytes auf Nibble umstelle. Aktuell werden immer zwei Nibble ausgegeben.

Nur wegen dem Oregon V3 brauchst Du es nicht korrigieren. Ich kann es mit dem folgenden Hash in der SIGNALduino_OSV2() korrigieren:

Code Auswählen Erweitern

my %OSV3sensorIdList  = (
"1A89" => '88',    # WGR800
"1A99" => '88',    # WTGR800 Anenometer
"FAB8" => '80',    # WTGR800 Temp hydro
"2A19" => '92',    # PCR800 rain
"CA48" => '68',    # THWR800
"DA78" => '72',    # UVN800
"FA28" => '80'     # THGR810
);

Gruß Ralf

[pejonp]

.....
Das mit der 00 am Ende kann nur passieren, wenn 00 empfangen wurde, oder z.B. nur eines der 8 Bit.
...

Hallo Sidey,

hier sind mal 2 Seiten auf denen die Oregonsensoren beschrieben werden. Dort werden auch die Zeitabstände beschrieben, vielleicht hilft es ja etwas weiter.
http://www.altelectronics.co.uk/projects/thn128-compatible-temperature-sensor/ -> weiter unten auf der Seite.
http://www.connectingstuff.net/blog/tag/oregon/
http://www.connectingstuff.net/blog/decodage-des-protocoles-oregon-scientific-sur-arduino-2/

Jörg

[Sidey]

Nur wegen dem Oregon V3 brauchst Du es nicht korrigieren. Ich kann es mit dem folgenden Hash in der SIGNALduino_OSV2() korrigieren:

Hi Ralf,

das ist eine gute Idee.
Ich würde dennoch zwei Dinge im Arduino anpassen.
1. Es werden Nibble und nicht Byte ausgewertet. Das ist dann erst mal richtiger als heute. Das ist eine recht kleine Anpassung.

2. Da das letzte Nibble ggf. ja trotzdem aufgefüllt wird, werde ich die Anzahl an Bits mit übergeben.
Diesen Wert kann man in dem parse_MC Teil Auswerten.

Wenn dann noch was offen bleibt könnten wir das mit dem Hash lösen.

Grüße Sidey

[Sidey]

Hallo Sidey,
hier sind mal 2 Seiten auf denen die Oregonsensoren beschrieben werden. Dort werden auch die Zeitabstände beschrieben, vielleicht hilft es ja etwas weiter.

Hi Jörg,

den Inhalt kenne ich, die Seiten nicht alle.
Solange die Signale so kommen wie im Lehrbuch beschrieben geht es auch.

Jetzt gibt es so ein paar Feinheiten, die noch austariert werden müssen.

Konntest Du die FW schon mal mit den Hideki Sensoren testen?

Grüße Sidey

[pejonp]

Hallo Sidey,
Die hideki Sensoren werden empfangen. Ich denke auch sehr gut, muss ich aber mal genauer überprüfen. Den Empfänger der wh1080 müsste ich noch updaten. Dieser ist über esp8266 per WLAN angeschlossen. Ein Update übers WLAN habe ich noch nicht hinbekommen. Habe nach ein paar versuchen erst einmal aufgegeben.
Jörg

[Burny4600]

Anbei das Log mit deaktivierten MC.

Verstehe zwar nicht wieso gerade MC deaktiviert werden musste.

[cerberus]

Hallo, ich habe ein Signalduino nach Anleitung im Fhemwiki gebaut ( selbstbau CUL http://www.fhemwiki.de/wiki/Selbstbau_CUL ) um meine Oregon 3.0 Wettersensoren zu empfangen. Ich habe auch mit der entsprechen nano Firmware aus FHEM erfolgreich geflascht. Heute habe ich mein Funkmodul erhalten und wollte das ganze in Betrieb nehmen. Der Signalduino wird auch erkannt, jedoch empfange ich augenscheinlich nichts. Ich habe nochmal alles durchgemessen aber keinen Fehler in der Verkabelung finden können. Welche Möglichkeit habe ich zu testen ob das Funkmodul vom Arduino erkannt wird?

anbei ein Screenshot aus FHEM

Grüße
cerberus

[sash.sc]

Cul und Signalduino sind doch 2 verschiedene paar Schuhe? Die unterscheiden sich doch völlig!

Gesendet von meinem SM-T560 mit Tapatalk

[micky0867]

Anleitung für den Bau eines Signalduino
http://www.fhemwiki.de/wiki/SIGNALduino

[cerberus]

Hallo micky0867, du hast Recht. Ich habe meinen Denkfehler  schon bemerkt und die alternative CUL Firmware geflasht.

Grüße
cerberus

[hjgode]

Genau, laut Datenblatt hat  der ESP alles was man braucht, dazu noch mehr RAM, mehr Flash und mehr CPU Leistung.

Da könnte man auch zwei Empfänger an einem ESP betreiben.

Grüße Sidey

Hallo

nur so, als Warnung?, der ESP kann bzgl. Interrupt-Verarbeitung mit einem Atmega nicht mithalten. Ich denke mit einem ESP wird es schwierig bis unmöglich die Pulslängen  der verschiedenen OOK modulierten Signale zu erfassen, zu verarbeiten und dann noch den zeitkritischen WiFi Stack am Laufen zu halten.
Ich würde das erst mal Tests fahren, ob der ESP überhaupt verläßliche OOK Signale erkennen kann.

Nur so ein Gedanke...bevor da jemand viel Arbeit reinsteckt.

~Josef

[Sidey]

Anbei das Log mit deaktivierten MC.

Verstehe zwar nicht wieso gerade MC deaktiviert werden musste.

Danke. Durch das deaktivieren des MC decoders, werden die Daten so im Log ausgegeben, wie sie der MC decoder intern erhält.
Dadurch kann ich das mit deinen Signalen mal besser nachstellen und optimieren.

Grüße Sidey

[Burny4600]

Ok. Alles klar.
Stelle in der Zwischenzeit wieder alles zurück.

[Sidey]

Hallo

nur so, als Warnung?, der ESP kann bzgl. Interrupt-Verarbeitung mit einem Atmega nicht mithalten.

Hallo Josef,

ja Du hast recht. Wir müssen das testen.
Meine Idee war auch, den ESP erst mal mit serieller Anbindung laufen zu lassen.
Die notwendigen Änderungen halten sich so in Grenzen. Soweit ich das sehe müssen nur alle PIN Operationen wieder umgeschrieben werden. Wenn man den 1. Test auf das Empfangen beschränkt, dann ist das im Interrupt und im Setup Teil zu modifizieren.

Bezüglich der Interrupt Latenz habe ich 5 uS nachlesen können.
Das ist für unser Setup zu verkraften.

Ich bin gespannt, ob das funktioniert.

Grüße Sidey