mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Protokoll ELV Funk-Temperatur-/ Luftfeuchtesensor ASH500


Autor: Black Friday (black_friday)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
kennt zufälligerweise jemand das Protokoll, mit dem der 
Funk-Temperatur-/ Luftfeuchtesensor ASH500 die Messwerte an die 
Basisstation (WS500 oder WS777) überträgt?
Oder weiß jemand noch eine andere Wetterstation, mit der dieser Sensor 
kompatibel ist?
Ich will den Sensor zur automatischen Lüftungssteuerung verwenden.
Der ASH 500 misst Luftfeuchte und Temperatur mit Hilfe eines Sensirion 
SHT1x und ist derzeit bei ELV als Restposten erhältlich.

http://www.elv.de/output/controller.aspx?cid=74&de...

Über Google habe ich noch nichts passendes finden können.
Anscheinend besitzt jeder Sensor eine individuelle Adresse, welche in 
einem EEPROM gespeichert ist.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.elv-downloads.de/Assets/Produkte/6/648/...

6. Technische Daten
Datenübertragung per Funk: .......................... 868,35 MHz
Freifeld-Reichweite: ................................................ 
100 m
Datenübertragungszyklus: ..................................... 3 Min.*
Temperaturmessbereich: ................... -40,0˚C bis +80,0˚C
Auflösung Temperaturmessung: ............................... 0,1˚C
Genauigkeit Temperaturmessung: ............................. ±1˚C
Meßbereich rel. Luftfeuchte: ......... 0% - 99% rel. Feuchte
Auflösung Luftfeuchtemessung: ................................. 1˚%
Genauigkeit Luftfeuchtemessung: ............................. ±5%
Spannungsversorgung: ............... 3 V, 2 x LR6/AA/Mignon
Abmessungen (ØxH): .................................... 54 x 125 mm
Abstand Außensensor zur Anbringungsfläche: ..... 30 mm
* bis ca. 3 Minuten nach Inbetriebnahme Test- und Synchro-
nisationsmodus: Signalaussendung alle 8 s.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du bitte deine Infos posten? Was steckt noch drin? Fotos wären 
toll.

Autor: zipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
du schreibst nicht, wie du den sensor weiter verwenden willst.
wäre aber hilfreich.
die habe i.d.r keine unitäre id(0-16 max), sondern nur ein "versautes" 
protokoll.

du kannst davon ausgehen, das elv alle seine protokolle urheberrechtlich 
geschützt hat.
ich kenne keinen, der reengineered protokolle veröffentlich hat, nicht 
mit einem "netten" schreiben von elv bedacht wurde.
aber schau mal in den wetterforen rum.
es gibt da einen, der das durch hat. der hat das mal für die 433mhz 
gemacht.(http://www.wetterfreaks.de/)
ansonsten gibt es da einen kleinen usb-empfänger für die 868mhz reihe
Artikel-Nr.: 68-920-30 ~30€
vielleicht hilft der dir.

cu zipp

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.elv.de/output/controller.aspx?cid=74&de...

Der USB-WDE1 empfängt die Daten der folgenden ELV-Wettersensoren:

Funk-Kombisensor KS 200/300
Funk-Temperatursensor S 300 IA
Funk-Temperatur- und Luftfeuchte-
sensor S 300 TH und ASH 2200
Poolsensor PS 50

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zipp schrieb:
> du kannst davon ausgehen, das elv alle seine protokolle urheberrechtlich
> geschützt hat.
> ich kenne keinen, der reengineered protokolle veröffentlich hat, nicht
> mit einem "netten" schreiben von elv bedacht wurde.

Da die Wetterstation nicht mehr vertrieben wird, sie aber auch an Leute 
ohne Wetterstation verkaufen, müssen diese Leute, um das gekaufte Gerät 
nutzen zu können, das Protokoll ermitteln, da ELV es anscheinend nicht 
offenlegt. Meine Meinung.

Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,da ich hier grade einen SHT71 in betrieb genommen habe und noch 
einen Sensor gebrauchen könnte hab ich mal einige Fragen.Hat jemand 
schon den ASH500?Wen ja,kann man den Sensor einigermaßen gut auslöten 
(keine SMD erfahrung) und wenn ja,gibt es Sockel,womit man diesen Sensor 
befestigen kann.Entschuldigung das ich deinen Beitrag benutze,aber zu 
dem Preis würde ich mir sofort welche bestellen,wen ich Sie verarbeitet 
bekomme.

gruss

andy

Autor: zipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Info schrieb:
> Da die Wetterstation nicht mehr vertrieben wird, sie aber auch an Leute
> ohne Wetterstation verkaufen, müssen diese Leute, um das gekaufte Gerät
> nutzen zu können, das Protokoll ermitteln, da ELV es anscheinend nicht
> offenlegt. Meine Meinung.

dann tu es.
wünsch dir viel spass. ( und guten RA)

bye zipp

Autor: zipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Godlike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zipp schrieb:
> dann tu es.
> wünsch dir viel spass. ( und guten RA)

Gott lass Hirn regnen. Gefroren oder in flüssiger Form ist mir langsam 
egal !

Autor: zipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Godlike schrieb:
> Gott lass Hirn regnen. Gefroren oder in flüssiger Form ist mir langsam
> egal !

nomen est omen
die flüssige und hochprozentige entspricht dir wohl.
den ersteren aggregatzustand hast du schon bestätigt
bähhh: ich hasse solche threader...

Autor: Black Friday (black_friday)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
anbei ein Photo der Bestückungsseite.
FS1 ist der SHT1x - Sensor (unter einer angeklebten und angeschmolzenen 
Teflonschutzhaube). Zerstörungsfrei bekommt man den sicher nicht mehr 
herunter. Wenn ich den Sensor alleine nutzen wollte würde ich einfach 
das Stück Platine mit dem Sensor absägen und über die Leiterbahnreste 
kontaktieren.
Ich habe inzwischen auch in Wetterstationsforen herumgesucht und 
herausgefunden, dass der im Link beschriebene ASH2000 leider nicht 
kompatibel mit dem ASH500 ist.
Ich will über einen noch zu bauenden Empfänger (evtl. mit RFM12) 
Temperatur und Feuchte von 2 Sensoren empfangen und jeweils die 
Taupunkte berechnen.
Dabei wird der eine Sensor draußen und der andere im Keller angebracht.
Darüber wird dann die Belüftung des Kellers gesteuert.
Am Wochenende werde ich mal das Signal, das zum Funkmodul geht, 
mitschreiben und untersuchen.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für Tipp und Scan. Der Sensor ist also COB.
Kannst du sehen, was das für ein Samsung Mikro ist? Scheint ein 
PRorgramm1er-Header dabei zu sein.

http://www.samsung.com/global/business/semiconduct...

Da hat sich wohl einer vertan, oder einen anderen LDO (?) noch günstiger 
bekommen?

Autor: Black Friday (black_friday)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Controller müsste lt. Beschriftung ein 3p9228azz-qz88 sein (ist 
schlecht zu lesen, die Beschriftung auf dem Controller bekomme ich weder 
mit Aceton, Spiritus, Waschbenzin noch Ipopropanol weg).
Der Baustein unter der Leiterbahnkorrektur ist vermutlich ein EEPROM, in 
dem die Sensoradresse gespeichert ist.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Controller programmieren zu wollen ist wohl Quatsch, da muss man 
erst den passenden Compiler und einen Programmer auftreiben. Ein ATtiny 
dürfte reichen.

An deinem Vorhaben bin ich interessiert. Hast du zufällig eine Betty TV? 
Da ist ein CC1100 drauf, allerdings für 434 MHz beschaltet. 868 tunen 
geht zwar, aber der Empfang ist entsprechend schlecht. Kann man bestimmt 
umbauen. Es gibt viel Firmware, darunter einen Decoder für ELVs FS20 
(868) (http://bettyhacks.com/wiki/index.php/Betty_Hardware)

Autor: Black Friday (black_friday)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Info:
Den Controller wollte ich schon so lassen wie er ist.
Betty TV habe ich, aber da ich die Kontrollstation fest installieren 
will ist sie für mein Vorhaben nicht so gut geeignet.
Ich habe noch RFM12 Module hier, die will ich für den Empfang nutzen. 
Als Controller will ich einen MSP430 verwenden.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich meinte auch mehr mich selber..
Habe die Dinger noch nicht aber versuche gerne mitzurätseln.

http://www.sensirion.com/de/01_humidity_sensors/00...

Die Genauigkeitswerte widersprechen aber den Kennlinien.

http://www.sensirion.com/de/pdf/product_informatio...


Service für AVR-Programmierer / Ausschlachter:
http://www.mikrocontroller.net/forum/codesammlung?filter=sht

Davon in Beitrag "Sensirion SHT11 Code" 2.5 Varianten die 
ganz brauchbar erscheinen (C für AVR, einmal mit Interrupts, einmal 
Polling ohne Warten, teils mit Kompensation der Betriebsspannung).

Autor: Black Friday (black_friday)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang mal ein mitgeschnittenes Protokollpaket.
Sieht nach Manchester - Kodierung aus oder liege ich da falsch?
Mein Problem ist, dass ich keine passende Wetterstation zur Auswertung 
besitze und so die übertragenen Messwerte nicht kenne.
Im Netz findet man rein gar nichts über das Funkprotokoll der 
Wetterstation WS500.

Autor: Black Friday (black_friday)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mal mit dem dekodieren nach Manchester angefangen, aber die 
Ergebnisse sehen sehr seltsam aus (oder ich mache etwas falsch).
Die 1. Zeile im Anhang gehört zu dem bereits geposteten Protokollpaket, 
darunter noch 4 andere Protokollpakete.

Autor: ja ist denn schon wieder Freitag... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde auf eine Bitcodierung tippen ähnlich wie in dem Link von zipp 
weiter oben beschrieben (Puls/Pause) Außerdem vermutlich LSB und MSB 
gemischt und Parity Bits dazwischen. Ohne zu wissen was die Sequenz 
bedeutet wird das sehr mühsam.

Du müsstest mehrere Signale nacheinander aufnehmen und mal vergleichen 
welcher Teil identisch ist.

Grüße,
jidswf

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Komme für prot1.gif auf dasselbe Ergebnis.
Kannst du die Daten vom SHT? auch aufzeichnen?

Ein Paket hätte also etwa 80 Bits, wenn es manchestercodiert wäre.

Es müsste eigentlich ein Teil immer identisch sein, da das Ding ja seine 
ID sendet.

Oder man spart sich das ganze Ratespiel und baut da den günstigsten 
(AVR) drauf, den man finden kann..

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal der "Bitstrom" von prot1, 1 = high:
00010101010101010101010101010101011010100110011001011010011001010110010101010101101010010110101001011001011010010110010110010101101001101010101001101010010110011001010101011001101001010110100110101000

Autor: Kutte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nimm doch den S555TH, kostet bei Conrad 5 Euro. Das Protokoll ist im 
Prinzip bei Etherrape im FS20 Teil und bei DC3YC (s. oben) beschrieben.
Gruß Kutte

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch nicht schlecht.

http://www.conrad.de/ce/ProductDetail.html?product...
Sendefrequenz: ......................... 868,35 MHz
Freifeld-Reichweite: ................... 100 m
Datenübertragungszyklus: ............... 3 Min.
Temperaturmessbereich außen: ........... -20,0°C bis +55,0°C
Auflösung Temperaturmessung: ........... 0,1°C
Genauigkeit Temperaturmessung: ......... ±0,8°C
Messbereich rel. Luftfeuchte: .......... 5% - 95% rel. Feuchte
Auflösung Luftfeuchtemessung: .......... 0,1%
Genauigkeit Luftfeuchtemessung:  ....... ±5%
Spannungsversorgung: ................... 2 x 1,5 V, LR6 (AA/Mignon)
Abmessungen (B x H x T, Sensor): ....... 38 x 138 x 20 mm
Tiefe des Montagefußes: ................ 50 mm

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist doch identisch mit dem hier
http://www.elv.de/Funk-Temperatur-Luftfeuchteau%C3...

Selbst die Doku ist die gleiche. Nur der Preis ist nicht annähernd 
identisch.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, gibt's schon was Neues?
Ich bin schwer am Überlegen, lieber die S555TH von C zu nehmen.

S555TH: "Verfügbar sind 8 Adressen"

Autor: Black Friday (black_friday)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Na, gibt's schon was Neues?

Da ich die Lüftungssteuerung relativ kurzfristig benötige werde ich mir 
wohl übergangsweise zwei von den S555TH holen.
Wie man in verschiedenen Foren liest sollen die aber qualitativ 
schlechter sein als die ASH500. Es fehlt z.B. die Teflonkapselung des 
Sensors und die Feuchtemessergebnisse sollen teilweise Abweichungen 
haben.
Nach wie vor will ich aber noch versuchen, hinter das Protokoll der 
ASH500 zu kommen (zumal ich die bereits hier herumliegen habe).
Weiß zufälligerweise jemand, ob man die Daten der ASH500 mit dem 
USB-WDE1 von ELV empfangbar (also nicht unbedingt dekodierbar) ist?

Autor: ja ist denn schon wieder Freitag... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Junge Junge,

zu schwer auf den ELV Link zu klicken? Hier:

Der USB-WDE1 empfängt die Daten der folgenden ELV-Wettersensoren:

    * Funk-Kombisensor KS 200/300
    * Funk-Temperatursensor S 300 IA
    * Funk-Temperatur- und Luftfeuchte-
      sensor S 300 TH und ASH 2200
    * Poolsensor PS 50

Also nix ASH500.

Der S555TH von Conrad ist soweit ich weis identisch mit dem S 300 TH und 
beim C ja mal richtig preiswert. Allerdings sind diese Sensoren 
eigentlich für den Innenraum gedacht. Ich habe aber einen seit ca. 2 
Jahren im Außeneinsatz (Regengeschützt). Bisher klappts.

Die ASH500 werden wohl deshalb verramscht weil es keine aktuelle 
Wetterstation mehr gibt die den Code kennt. Eventuelkl lohnt es sich 
alleine wegen des Gahäuses...

Autor: Black Friday (black_friday)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Junge Junge, zu schwer auf den ELV Link zu klicken?

Nein, deshalb habe ich ja auch gefragt: "empfangbar (also nicht 
unbedingt dekodierbar)". Der leider nicht mehr erhältliche Vorgänger des 
Empfängers (mit RS232) hat anscheinend bei den Sendern, die er nicht 
dekodieren konnte, zumindest die Rohdaten ausgegeben.

> Allerdings sind diese Sensoren eigentlich für den Innenraum gedacht.
Warum heißt dann das Teil bei Conrad "Temperatur-/Feuchte-Außensensor 
S555TH"?

Autor: ja ist denn schon wieder Freitag... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Black Friday schrieb:
> Nein, deshalb habe ich ja auch gefragt: "empfangbar (also nicht
> unbedingt dekodierbar)".Der leider nicht mehr erhältliche Vorgänger des
> Empfängers (mit RS232) hat anscheinend bei den Sendern, die er nicht
> dekodieren konnte, zumindest die Rohdaten ausgegeben.

Na hättest Du doch mal geschrieben was Du gemeint hattest, stimmt der 
alte Empfänger hatte die Bitfolgen ausgegeben, zurechtpfriemeln musste 
man das dann aber trotzdem selbst.

OK, falls "Der USB-WDE1 empfängt die Daten der folgenden 
ELV-Wettersensoren:"
nicht klar genug war hilft eventuell der Blick in die 
Bedienungsanleitung:

Die empfangbaren Wettersensoren
Der USB-WDE1 kann die Daten aller folgend aufgeführten Wettersensoren
empfangen.
· Funk-Kombi-Sensor KS 300
...

Ein Empfang der bidirektionalen Wettersensoren der Reihe x550 ist nicht
möglich.

Ein Empfang der 500er Serie ist also nicht ausdrücklich ausgeschlossen 
;-)

Da in der Bedienungsanleitung die Ausgabesyntax beschrieben wird, würde 
ich aber nicht darauf wetten, das andere als die angegebenen Sensoren 
erkannt werden.

>> Allerdings sind diese Sensoren eigentlich für den Innenraum gedacht.
> Warum heißt dann das Teil bei Conrad "Temperatur-/Feuchte-Außensensor
> S555TH"?

Na ja, auf der Produktseite heist er ja erst mal 
Temperatur/Feuchtesensor und in der Bedienungsanleitung steht expliziet 
"Der Außensensor ist für den geschützten Außenbereich geeignet (z.B. 
unter einem Dachvorsprung). Betreiben Sie das Produkt niemals in oder 
unter Wasser! Schützen Sie
den Außensensor vor direkten Niederschlägen.

Beim ASH500 steht:
Der Außensensor ASH 500 darf in einem Temperaturbereich
zwischen -40°C und +80°C bei einer maximalen
Luftfeuchtigkeit von 99% im Freien eingesetzt werden.
Die Anweisungen bezüglich der Wahl des Montageortes
sind zu befolgen.

Dort sind dann auch wieder Einschränkungen (extreme Feuchtigkeit... 
usw.) und Montage unter einem Dachvorsprung. Das ist wegen direkter 
Sonneneinstrahlung allerdings sowieso zu empfehlen...

Deine Einschätzung mit dem besseren Gehäuse stimmt also.

Im ELV Wetterstationenjargon heißen übrigens alle nicht fest eingebauten 
Sensoren "Außensensoren", hat aber natürlich nichts mit innen und außen 
zu tun.

So, genug der Haarspalteinen, wie gesagt habe ich den S300TH ja auch 
schon einige Zeit draußen in Betrieb, weil es außer dem Kombisensor ja 
nichts gescheites für außen mehr gibt. (mit den Protokollen die bekannt 
sind)

Der ASH500 hat übrigens eine eindeutige Adresse, da ist nichts 
einzustellen, und die Adressen sollen auch für jeden Sender anders sein.

Falls Du das Protokoll knacken möchtest, und nicht doch lieber auf die 
Arbeit der Ethersex Programmierer zurückgreifen möchtest und den S555TH 
nimmst, kannst Du Dich an der Pulserkennung dort orientieren. Die Bits 
sind mit unterschiedlich langen H und L Zeiten kodiert, da Du ja einen 
Logicport hast, sollte das kein unlösbares Problem sein die richtigen 
Zeiten zu ermitteln (genug Toleranz lassen, lies mal die 
Protokollbeschreibung in der Ethersex Software)
Der ASH500 sendet übrigens nach dem einschalten ca. 3 Minuten lang seine 
Telegramme, danach nur noch alle 3 Minuten.

HTH

Autor: ja ist denn schon wieder Freitag... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei ELV gab es einen Preisrutsch beim ASH500, kostet nur noch 1,95€ ;-)
Für alle die es interessieren könnte...
Bei dem Preis lohnt es sich ja schon wegen des Sendemoduls.

Autor: Black Friday (black_friday)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mist, und zudem gibt es noch eine 5,- EUR Gutscheinaktion.
Ich hätte noch warten sollen mit meiner Bestellung.

Autor: ja ist denn schon wieder Freitag... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
meine sind heute angekommen, das Gehäuse ist schon deutlich besser als 
das vom S300TH/S555, bin gerade am überlegen ab ich nicht vielleicht 
doch einen Sender mit dem WS300 Protokoll da reinbauen soll....

Das S555 Gehäuse ist leider verklebt und nicht ohne kleinere Zerstörung 
zu öffnen. Vermutlich passt die Platine aber auch nicht rein.

Es müsste ja reichen einen neuen Controller als Huckepackplatine 
aufzubauen und den nicht benötigten Kram einfach abzulöten. Allerdings 
ist der Typ des Hygrosensors ja noch nicht ganz klar.

@Black Friday:
bist Du schon weiter mit dem Protokoll? Ich hab mir Deinen Scan noch mal 
angeschaut, sieht wohl doch eher nach Manchester aus wenn man das Timing 
betrachtet. Ist dann bei den ELV Protokollen ein echter Exot, und das 
ist wohl auch der Grund warum der nirgends mehr unterstützt ist. (und 
auch von keinem der Wetterdatenempfänger mehr ausgewertet werden kann, 
vermutlich auch nicht mit dem alten)

Hast Du schon mal probiert Manchester mit einem Controller zu dekodieren 
und die Bits per seriell auszugeben?
http://www.atmel.com/dyn/resources/prod_documents/...

Autor: Black Friday (black_friday)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Derzeit warte ich auf die zusätzlich bestellten S555TH, da ich wie 
gesagt erst einmal diese verwenden will (wg. kurzfristiger 
Realisierung).
Die langem, kalten Winterabende will ich dann zum dekodieren verwenden 
und anschließend mein System auf ASH500 umbauen ;-)

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Hast Du schon mal probiert Manchester mit einem Controller zu dekodieren
> und die Bits per seriell auszugeben?
Beitrag "Re: Protokoll ELV Funk-Temperatur-/ Luftfeuchtesensor ASH500" ff.
Aber das nützt ja nichts, wenn man die Payload-Daten (SHTxx) nicht 
kennt. Wenn jemand einen zweiten Sensor abhört, könnte man u.U. den ID 
Teil erkennen. Aber: in den oben gegeben Daten ändert sich ja sehr 
viel..

Anbei nochmal die manchesterdekodierten Daten aus prot.txt, mit gleichen 
Bits markiert. Werden evtl. mehrere Pakete für die Daten gesendet? Die 
Markierung könnte ein Countdown sein.

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein zweiter Zähler und gespiegelte Werte?

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein paar Geister :-)

Es ist aber nicht immer vertikal 00->1.

Kannst Du noch mehr Daten sammeln bitte?

Autor: A. S. (telekatz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die 16*0 und 1*1 am Anfag werden wohl die Präambel sein. Danach kommen 
je 8 Datenbits und 1 Paritätsbit. Parität ist immer ungerade.

Wieviele Pakete werden pro 3 Minuteninterval gesendet?

Autor: ja ist denn schon wieder Freitag... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein bisschen würde es ja schon helfen, wenn die Temperatur und 
Luftfeuchtewerte der Sensorumgebung bekannt sind (anderes Thermometer)
Möglicherweise ist ein Bit auch noch das Temperatur Vorzeichen. ELV 
schreibt die Daten auch gerne LSB. Eventuell werden auch die einzelnen 
Ziffern separat übertragen.

@Info: liest Du die Daten aus? Wie? Oder sind das die Daten von dem Scan 
oben?

Beim kontinuierlichen mitschreiben kann man ja durch "Handauflegen" bzw. 
anhauchen Temperatur und Luftfeuchte beeinflussen um zu sehen welche 
Bits sich bewegen...

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sind black_fridays manchester-dekodierten Daten aus
Beitrag "Re: Protokoll ELV Funk-Temperatur-/ Luftfeuchtesensor ASH500"

Ich habe noch keine Sensoren. Die Markierungen sind selbstverständlich 
nur wildes Gerate, was mir ins Auge gesprungen ist. Jemand anders sieht 
möglicherweise ganz andere Ähnlichkeiten. Die zwei letzten Pakete passen 
nicht. Vielleicht sind die ersten drei Sendungen der Header für die 
folgenden Nutzdaten?

Mehr Daten wären schön, aber auch das Mitschneiden erfordert 
entsprechende Ausrüstung. Vielleicht schaffe ich es in einer Woche mal, 
einen AVR zum Mithorchen zu dressieren.

Dafür habe ich jetzt Hoffnung, das Telekatz mitmacht und einen Dekoder 
für die Betty schreibt :-) Ein 868->434 Gateway wär' praktisch

Autor: Richard W. (richardw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die von Telekatz vermutete Aufteilung von 8 Datenbits + Parität ungerade 
würde für die meisten Bytes passen. Aber nicht bei allen.

Autor: BillX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bist du denn sicher das jede Zeile zusammen gehört ? oder könnte die 
zuordnung auch anders aussehen ?

Autor: Martin K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

sendet der ASH500 auf 868,35 Mhz mit FSK-Modulation?

Dann könnte man ja einfach ein Pollin Funkmodul RFM01
mit 868 Mhz verwenden!?

Und anschließend das Protokoll reengineeren.

Grüße

Martin

Autor: noname (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
:-)

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei ein bisschen mehr Daten, mit führendem Ruhepegel "0" und dekodiert 
paarweise: "10"-> 1.
Zur Kontrolle das erste Datenpaket im Thread in erster Zeile.

Davor die zwei Befehle und je zwei Antwortbytes des SHT1x.

Ich habe keinen Logikanalysator, die Daten können deshalb fehlerhaft 
sein. Ein paar Pakete habe ich schon aussortiert..

Macht was draus :-)

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noname schrieb:
> :-)

Passt doch gar nicht?

00000000000000001TTTT1AAAV1TTTT1TTTT1TTTT1FFFF1FFFF1FFFF1QQQQ1

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also nicht Manchester?

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Mitschnitt.

Parity stimmt mit ziemlicher Sicherheit. <original>-<berechnet>
Am Ende sind meine Daten kaputt, da stimmt es nicht.

Temperatur- u. Luftfeuchteberechnung mit Parametern nach aktuellem SHT1x 
Datenblatt, wer weiß, ob's stimmt. Falls Ziffern übertragen werden ist 
das natürlich entscheidend..

Die Nibbles lasse ich dezimal ausgeben, da sind einige Zähler drin. 
Teils paarweise vertauscht. Teils wird nur um vier Werte gezählt.

Bei ner doppelten Leerzeile fehlt eine Übertragung

Eine feste ID gibt es wohl nicht. Vielleicht dient der Zähler als ID.

Die Zähler sind bei jedem Einschalten gleich initalisiert.

Das letzte Paket ist angehaucht..

Ich vermute die Daten in den ersten Nibbles. Das zweite Nibble verändert 
sich ständig (bsp. Byte 4 Nibble 2: 0..15)

Vielleicht kann "noname" ja nochmal sagen wo die Bits stecken!? 9 Blöcke 
passen ja schonmal zusammen..

Autor: Richard W. (richardw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, jetzt sind die Dinger alle. 170 Stück waren's in der vergangenen 
Woche.

Ich glaube, ich sehe mittlerweile schon überall Zähler ;-)
Gut möglich, dass dort die Sensornummer drin verschlüsselt steckt.
Paket 1:
  Bit 1-4: zählt rückwärts T*16
  Bit 5-6: zählt rückwärts T*4
  Bit 7-8: zählt vorwärts T

Paket 2:
  Bit 5-6: zählt rückwärts T*4
  Bit 7-8: zählt vorwärts T

Paket 3:
  Bit 5-6: zählt rückwärts T*4
  Bit 7-8: zählt vorwärts T

Paket 4:
  Bit 5-6: zählt vorwärts T*4
  Bit 7-8: zählt vorwärts T

Paket 5:
  Bit 5-6: zählt rückwärts T*4
  Bit 7-8: zählt rückwärts T

Paket 6:
  Bit 5-6: rückwärts T*4
  Bit 7-8: rückwärts T

T*4 bedeutet beispielsweise 4mal so langsam wie T.

Interessant ist auch die Paketfolge
0x3 0x5 0xe6 0x5 0x0 0x58  (20.30 C, 46.46 %RH) 00000000000000001 00010101 0-0 01 05   11110011 1-1 15 03   10111111 0-0 11 15   10010111 0-0 09 07   00000110 1-1 00 06   11100010 1-1 14 02   01101110 0-0 06 14   01100101 1-1 06 05   01010111 0-0 05 07   33 33

0x3 0x5 0xe6 0x5 0x0 0x58  (20.30 C, 46.46 %RH) 00000000000000001 00010010 1-1 01 02   11111100 1-1 15 12   10101000 0-0 10 08   10001000 1-1 08 08   00010001 1-1 01 01   11101101 1-1 14 13   00011001 0-0 01 09   11011010 0-0 13 10   01110100 0-1 07 04   241 241
0x3 0x5 0xe7 0x5 0x0 0x58  (20.34 C, 46.46 %RH) 00000000000000001 00010011 0-0 01 03   11101101 1-1 14 13   10111001 0-0 11 09   10011001 1-1 09 09   00000000 1-1 00 00   11011100 0-0 13 12   01101000 0-0 06 08   01101011 0-0 06 11   01010101 0-1 05 05   1 1

0x3 0x5 0xe6 0x5 0x0 0x58  (20.30 C, 46.46 %RH) 00000000000000001 00010000 0-0 01 00   11111110 0-0 15 14   10101010 1-1 10 10   10001010 0-0 08 10   00010011 0-0 01 03   11101111 0-0 14 15   00011011 1-1 01 11   11011000 1-1 13 08   01111010 0-0 07 10   241 241
0x3 0x5 0xe6 0x5 0x0 0x58  (20.30 C, 46.46 %RH) 00000000000000001 00010001 1-1 01 01   11101111 0-0 14 15   10111011 1-1 11 11   10011011 0-0 09 11   00000010 0-0 00 02   11011110 1-1 13 14   01101010 1-1 06 10   01101001 1-1 06 09   01011011 0-0 05 11   1 1

0x3 0x5 0xe6 0x5 0x0 0x58  (20.30 C, 46.46 %RH) 00000000000000001 00011110 1-1 01 14   11101000 1-1 14 08   10110100 1-1 11 04   10011100 1-1 09 12   00001101 0-0 00 13   11101001 0-0 14 09   00010101 0-0 01 05   11011110 1-1 13 14   01111000 0-1 07 08   241 241
0x3 0x5 0xe6 0x5 0x0 0x58  (20.30 C, 46.46 %RH) 00000000000000001 00011111 0-0 01 15   11111001 1-1 15 09   10100101 1-1 10 05   10001101 1-1 08 13   00011100 0-0 01 12   11111000 0-0 15 08   00000100 0-0 00 04   11001111 1-1 12 15   01011001 0-1 05 09   225 225

0x3 0x5 0xe6 0x5 0x0 0x58  (20.30 C, 46.46 %RH) 00000000000000001 00011100 0-0 01 12   11101010 0-0 14 10   10110110 0-0 11 06   10011110 0-0 09 14   00001111 1-1 00 15   11101011 1-1 14 11   00010111 1-1 01 07   11011100 0-0 13 12   01111110 0-1 07 14   241 241


Da schwanken die mutmaßlichen Daten-Nibbles immer um ein Bit hin und 
her. Aber Sinn ergibt das alles noch nicht wirklich.

Bei der Umrechnung komme ich auf minimal abweichende Werte, ebenfalls 
mit dem aktuellen Datenblatt.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, Zähler und Paketpaare habe ich auch "entdeckt".

Ich kann dem Controller mittlerweile (konstante) Daten unterschieben, 
werde heute abend vielleicht noch ein paar Datensätze hochladen.

Die Sensoren haben eine Nummer & Barcode (EAA1234567), die Zählerwerte 
beim Einschalten sind teils unterschiedlich. Das lässt sich mit 
konstanten Sensordaten aber noch genauer untersuchen.

Eine solche Nummer hat auch der Conrad-Sensor (EAB1234567)! Der ist von 
eQ-3 ("HomeMatic") und hat wohl auch einen SHT?? drauf. Die Pinbelegung 
ist in derselben Reihenfolge wie im Datenblatt (Vcc lässt sich durch den 
Pufferkondensator erkennen).

Blöd ist leider, dass auch bei konstanten Daten die nicht-Zähler-Nibbles 
nicht konstant sind.
Evtl. gibt es bei meinem "SHT-Emulator" Timingprobleme, allerdings waren 
die gesendeten Daten bei zwei aufgenommenen Initialisierungsvorgängen 
identisch.

Autor: A. S. (telekatz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du mal deinen Code posten, mit dem du den SHT emulierst?

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei, aber erwarte nichts Gutes :-)
Braucht > 4 k Flash und einen 8-bit Timer, enthält UART Code von P.D., 
läuft bei mir mit 8 MHz und ist nur für den ASH500 zusammengebastelt. 
Bitte Verbesserungen wieder hier Posten.

Es ist stures Warten auf die passenden Flanken und keinerlei 
Dekodierung. Es werden nur die SHT Bytes gelesen bzw. gesetzt. Die 
Data-Flanken sehen mit 10 k Pull-Up Widerstand wesentlich besser aus, 
aber es macht keinen Unterschied in den gefunkten Daten. Die 
DATA-Leitung muss man natürlich auftrennen.

Wenn du einen LA hast, bitte nochmal prüfen. Ich bin mir bei den 
gesendeten Daten nicht ganz sicher:

"For reading data from the sensor, DATA is valid T_V after SCK has gone 
low and remains valid until the next falling edge of SCK."

soll wahrscheinlich heißen: "until the next rising edge".

Da ich polle, sollte es aber hinhauen den DATA Pegel noch 250 ns nach 
SCK Flanke zu halten (2 Takte bei 8 MHz). Evtl. bau ich noch ein nop 
ein..

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch allgemeine Info:
Der SHTxx ist wohl kein Standardtyp, da per default im low-res mode: 8 
bit humidity und 12 bit temp.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat denn hier jemand einen passenden Empfänger? Mit echten Anzeigedaten 
ließen sich die richtigen Faktoren für die Berechnungen ermitteln..

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hinweis zum Code: bei den gefunkten Daten wird manchmal der erste Puls 
nicht erkannt, evtl. weil er in der Länge von den anderen abweicht.

Anbei noch aufgenommene Daten bei emuliertem SHT, mit Zählern 
entsprechend (richardw). Präambel und Parity lasse ich nun weg.

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei Daten von
0x3 0x6 0x75 0x5 0x0 0x40  (26.02 C, 33.86 %RH)
          ..
0x3 0x6 0x80 0x5 0x0 0x40  (26.46 C, 33.86 %RH)

Ich rate mal wild:
- es werden Ziffern übertragen
- die Berechnungsfaktoren stimmen nicht ganz
- etwa alle zwei Temperatur-Bits entspr. 1/10 Grad (0x77 u 0x78 
identisch)
- bis 0x79 wird in Byte 7 (1..) der Zähler in Bit 7/8 um 1 verändert, 
dann invertiert:
- bei 0x79->0x80 gibt es einen Überlauf

Autor: Richard W. (richardw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die vielen Zähler haben bestimmt einen Grund und sind nicht nur zur 
allgemeinen Verwirrung da. Vielleicht eine Verschlüsselung welche Zähler 
einsetzt?

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es muss eine Referenz geben, zu der ein Zaehler den Wert kodiert. Mit 
der Invertierung gibt es acht Zustaende, wenn min zwei Pakete betrachtet 
werden.

Autor: Black Friday (black_friday)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat zufälligerweise jemand mehr von den Sensoren gekauft als er 
benötigt?
ELV hat meine 2. Bestellung versemmelt (wurde an falsche Adresse 
geschickt und nach Rücklieferung anderweitig verkauft).

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier eine ältere Version des PCB:
http://www.wetterstationsforum.de/phpBB/viewtopic....

Der SO8 ist ein LM285 micropower 3-terminal adjustable band-gap voltage 
reference diode

Bei mir ist aber Pin1 der MCU an R1 gepatcht, evtl. weil sie die MCU 
getauscht haben und jetzt schon eine Spannungsreferenz drin ist?
Oder was könnte die Funktion sein (geht an Pin 40, P0.1/T1CLK/INT)?

Es sieht so aus als wäre ab Byte 6 in Bit 1 für min. 9 Bytes 
(Sendungsübergreifend) von der Spannung an Pin1 abhängig.
Was zur Folge hat, dass in den ersten 5 Bytes auch in folgenden 
Sendungen das erste Bit invertiert wird. Allerding bekomme ich 
identische Pakete bei unterschiedlichen Spannungen: 5 V == 2.2 V, 2.62 V 
== 2.52 V. Aber: bei 2.51 V (vs. 2.52) ändert sich bereits in Byte 2 Bit 
4.

Ich werde versuchen, das zu reproduzieren (0x3 0x6 0x79 0x5 0x0 0x40)

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Korrektur: der MC hat keine interne Referenz. Mit Pin 40 wird die 
Zenerdiode (LM385) an Masse geschaltet, über ihr fallen dann 1.24 V ab. 
Diese werden mit 10-bit ADC Kanal AD0 gemessen, da die Akkuspannung als 
Referenz dient, lässt sich zurückrechnen:

     ADC = 1023 / V_CC * 1.24 V
<=> V_CC = 1023 / ADC * 1.24 V

Der Patch ist also notwendig, da bei dem bestückten Controller der ADC 
Pin woanders sitzt.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Mikrocontroller ist OTP. Theoretisch kann man ihn auslesen, dazu 
fehlt aber das serielle Protokoll und im Datenblatt ist von Read 
Protection die Rede.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In einem neueren Datenblatt steht ein bisschen mehr zum Flashen:
http://www.samsung.com/global/system/business/semi...

Eine Suche ergibt, dass auch 
http://www.elnec.com/en/search/device-list/?prog=9... LabProg+ 
den µC bearbeiten kann.

Zur seriellen Schnittstelle habe ich nichts gefunden.


----

Zur Spannungsmessung ein Auszug aus dem Manual der WS500

"
Funk-Sensoren
Die Batterien in diesen Sensoren haben eine Lebensdauer von bis zu 2 
Jahren
(Alkaline-Batterien). Sie sind zu wechseln, wenn im Sensorfeld „OUTDOOR” 
bei
Anwahl des entsprechenden Sensors ein Batterie-Leer-Symbol (       ) 
erscheint."

Autor: Martin K. (sir_martin)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe jetzt meine ASH500 Sensoren und ELV 868 Mhz Empfänger bekommen.
Okay, zu meiner nicht beantworteten Frage: Es ist eine Amplituden 
Modulation.

Habe am Funksensor ASH500 direkt am Modulationspin vom Samsung 
Mikrocontroller gemessen (gelbe Linie) und den Empfang am ELV 
Empfangsmodul (blaue Linie) ebenfalls.

Sieht stark nach einer Manchester Codierung aus.

Hat jemand einen Manchester Decodierer (Beispielcode in C für AVR) an 
der Hand?

Benutzer "Info": Wie hast Du Deine Daten aufgenommen? Sind diese schon 
von Manchester in Binäry umgewandelt?

Fand den Links vom Benutzer "Zipp" ganz nützlich:
http://www.dc3yc.privat.t-online.de/protocol.htm

Benutzer "Noname" hat uns ja schon einen älteren Protokollaufbau 
geschickt. Denke der ASH500 ist ähnlich aufgebaut. Die Werte sind 
wahrscheinlich BCD codiert.

An Paritybits glaube ich im Funkprotokoll weniger.

Wer kann mir mit Manchester weiterhelfen um Zeit zu sparen?

Grüße

Martin K.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Martin,

gut, dass du hier mitmischst!
Da du jetzt weißt, dass dein neues Spielzeug funktioniert, kannst du ja 
nochmal in Ruhe den Thread durchlesen. Da werden deine Fragen 
beantwortet :-)

Dafür eine Gegenfrage: Welchen Empfänger benutzt du, und wie kommt die 
erste fallende Flanke zustande?

Zur Inspiration das Protokoll einer anderen Wetterstation:
http://members.upc.nl/m.beukelaar/Crestaprotocol.pdf

Autor: A. S. (telekatz)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab deinem Code mal meine Decodierroutine hinzugefügt und ein bischen 
was umgeschrieben.

Irgendwo war da beim Emulieren des SHT wohl ein Fehler drinn. Für die 
Feuchtigkeitswerte von 0x0000 bis 0x007F waren die gesendeten Daten die 
gleichen wie für 0x0080 bis 0x00FF.

Anbei noch ein Log für die Feuchtigkeitswerte von 0x0000 bis 0x0180. 
Jeweils die erste Message nach dem Einschalten des Senders.

Autor: Martin K. (sir_martin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Info,

sorry das mit dem Manchesterdecodieren habe ich glatt überlesen.
Als Empfangsmodul habe ich ein ELV Empfangsmodul RX868-3V, 868 MHz

http://www.elv.de/output/controller.aspx?cid=74&de...

Leider ist es bei dem Modul so, das im Ruhezustand die Datenleitung ganz 
schön umher floatet. Daher die erste unsaubere fallende Flanke.

Werde jetzt erstmal Manchester decodieren programmieren und anschließend 
weiter das Protokoll anschauen. Danke für den Link.

Wenn Du weiterkommest, einfach melden :-)

Grüße

Martin

Autor: Black Friday (black_friday)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank schon mal für das aufnehmen und bereitstellen der Daten!

Diese sehen allerdings immer noch ziemlich verwirrend aus.
Evtl. ist der 1. Wert alleine nicht ausreichend und es wird die 
Abweichung gegenüber einer "Normalzählung" zum kodieren der Daten 
verwendet.
Es kann auch sein, dass die im SHT1x Datenblatt beschriebene 
Korrekturrechnung (mit den 3 Koeffizienten) verwendet wird, so dass man 
nicht 1:1 nach dem Feuchtewert suchen kann.

Wäre es möglich, Temperatur und Feuchte konstant zu lassen und die 
gesendeten Daten fortlaufend eine Weile mitzuschreiben?

Ursprünglich hatte ich gedacht, dass es sich bei D1 um ein EEPROM 
handle, was sich ja als falsch herausgestellt hat.
D.h. die Adressierung der Sensoren muss anders erfolgen.
Bei den SHT2x Sensoren kann man eine Seriennummer auslesen. Gibt es so 
etw. evt. auch (undokumentiert) bei den SHT1x Sensoren? Werden andere 
Befehle als Temperatur- und Feuchteanforderungen vom Mikrocontroller 
gesendet?

Wäre es evtl. möglich, dass die Adressierung über unterschiedliche 
Bestückungen z.B. von C6 oder R4 bewerkstelligt wird?

Autor: Richard W. (richardw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

da der Controller ja OTP ist, könnte die Seriennummer womöglich gleich 
mit im Image stecken.

R4 ist der Feedbackwiderstand für den internen RC-Oszillator.

D1 ist ein LM285, also eine Referenzspannungsquelle. Ich nehme an, damit 
stellt der µC fest, ob die Batterie leer ist. Da die Wetterstation 
diesen Fall angeblich anzeigt, wird das auch noch irgendwie in die 
Funknachrichten reinkodiert.

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Wäre es möglich, Temperatur und Feuchte konstant zu lassen und die
> gesendeten Daten fortlaufend eine Weile mitzuschreiben?

Das hatte ich weiter oben gemacht, für verschiedene Temperaturwerte, 
aber telekatz sagt, dass ein Bug im Code war.

Da ich den Sensor jetzt auch per AVR neustarten kann, und telekatz den 
Code aufgeräumt hat, lassen sich neue Aufnahmen automatisieren. Evtl. 
heute abend.

Anbei eine (vollständige?) Aufnahme von "R Tem 0678 Hum 0000..0AF5":
- Immer das erste Paket nach Reset
- Es gibt mehrere Überläufe der Funkdaten
- Die letzte Zahl steht für die Zeit, die zwischen der Komm. mit dem SHT 
und der Funkübertragung vergeht (* 8 µs)
  o zwei bis drei Pakete sind identisch (wie schonmal geschrieben, das 
weist aus meiner Sicht darauf hin, dass T/H_rel im Sensor gerechnet 
werden).
  o identische Pakete benötigen dieselbe Rechenzeit
  o die Rechenzeit steht im Verhältnis 1:4
  o Rechenzeit wechselt immer
  o wenn zwischen zwei Paketen mehrere Bits in mehreren Bytes geändert 
werden, ist die Paketberechnungsdauerfolge :-) immer lang->kurz
  o mehrere Bytes ändern sich (später) alle 36 Sendungen (anfangs auch 
27, 28)
 o von 0x00 bis 0xFF gibt es 122 Paketpaare/-drillinge. Das passt mit 
0-99% Luftfeuchte leider nicht direkt zusammen.

Es wäre echt gut, wenn wir eine WS500 Basis auftreiben/ausleihen oder 
mit  modifiziertem Sensor beschicken könnten, um Anzeigewerte zu 
bekommen:
http://www.wetterstationen.info/phpBB/viewtopic.php?t=19701

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bezüglich sht_emu: ich habe Übertragungen von Original und Emulation 
verglichen, sieht gut aus bis auf DATA Pulse nach dem ACK.
Das wird eigentlich nur vom SHT nach einem Befehl, und vom Master ggf. 
nach den Datenbytes gemacht. Jedenfalls sind die beim Original nicht zu 
sehen.
RF-Daten sind aber identisch.

Anbei eine Aufnahme der Emulation.

Autor: A. S. (telekatz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mich mal von der "Verschlüsselung" von BidCos inspirieren lassen.
http://fhz4linux.info/tiki-index.php?page=BidCos

Angewendet auf eine Reihe von Paketen ohne Änderung von Temperatur und 
Luftfeuchtigkeit gab es folgendes Ergebnis:

Das XOR des ersten Bytes mit 0x89 (dec[0] = enc[0] ^ 0x89) ergab eine 
korrekt vorwärts laufende Zähler.
Die Nachfolgenden Bytes habe ich mit "dec[n] = (enc[n-1]+0x24) ^ enc[n]" 
decodiert. Das ergab konstante Daten für dec[1] bis dec[7]. Lediglich 
bei dec[1] ändert sic manchmal das 4. Bit.

Diese Decodierung, angewendet auf mein Log von ansteigenden 
Luftfeuchtewerten, ergab einen dazu passenden Zähler in dec[7]. Korrekt 
vorwärts laufend und bei 1 beginnent. Beim Übertrag von 0x7F nach 0x80 
hat sich dann noch Bit 8 von dec[0] geändert.

Das gleiche dann noch mit einem Log von ansteigenden Temperaturwerten 
ergibt einen Zähler in dec[5] und dec[6]. In dec[5] steckt vermutlich 
noch ein Teil der Seriennummer. Bit 8 ist bei meinem Sender und bei dem 
Log von Info unterschiedlich.

Info schrieb:
> o von 0x00 bis 0xFF gibt es 122 Paketpaare/-drillinge. Das passt mit
> 0-99% Luftfeuchte leider nicht direkt zusammen.

Ich denke mal, dass der Sender nur stur umrechnet und nicht überprüft, 
ob der Wert denn überhaupt realistisch ist.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hab mich mal von der "Verschlüsselung" von BidCos inspirieren lassen.
Klingt gut.

In Beitrag "Re: BidCoS-Funksignale sniffen, nur wie? (HomeMatic)" ist kurz 
beschrieben, wie man an die Datenbeschreibung der HomeMatic Komponenten 
herankommt.

Z.B. so ein Gerät hier (gleiches Gehäuse):
http://www.elv.de/HomeMatic-HM-WDS10-TH-O-Funk-Tem...

http://www.homematic-inside.de/index.php/hardware/... 
:

"Die Kombination WS/KS 550 kann an die HomeMatic-Zentrale angelernt 
werden. Die aktuelle Firmware ist allerdings schon etwa 1 Jahr alt! Der 
KS550 funkt mit dem BidCoS-Protokoll, jedoch ist er nicht vollständig 
HM-kompatibel (laut ELV-Support ein etwas anderes Protokoll als beim OC 
3), was zu Problemen führen kann (z.B. nach einem Batteriewechsel)!"

> Ich denke mal, dass der Sender nur stur umrechnet und nicht überprüft,
> ob der Wert denn überhaupt realistisch ist.
Ich hatte blind angenommen, dass 0xff == 100%.

Weiter so. Ich lasse derweil fleißig Pakete aufzeichnen..

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei die jeweils ersten 21 Sendungen für  Tem 0678 Hum 00..2B
Wahrscheinlich schon zuviel des Guten..

Möglicherweise ist die Information für die Batteriespannung verrauscht, 
ich habe den ADC Eingang an einem Spannungsteiler, der allerdings mit 
einer kalten Lötstelle an Masse hing. Also der ADC-Wert dürfte MAX sein. 
Werte aufgenommen mit 5 V Versorgungsspannung.

Sieht ja so aus, als hättest du es fast geschafft. Weiterhin Erfolg beim 
Rätseln!

Autor: A. S. (telekatz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Änder das mal im Sourcecode, dann kommt das decodiert raus:
        uputchar0(FS20inbyte[0]);
        for(x=1;x<(FS20bytecounter);x++) {
          uputchar0(' ');
          uputhex0(FS20inbyte[x]);
        }

        //decode
        uputchar0(' ');
        uputchar0(' ');        
        uputhex0(FS20inbyte[1] ^ 0x89);
        for(x=2;x<(9);x++) {
          uputchar0(' ');
          uputhex0((FS20inbyte[x-1] + 0x24) ^ FS20inbyte[x]);
          
          /*for(y=8; y; y--) {
            if(FS20inbyte[x] & (1<<(y-1)))
              uputchar0('1');
            else
              uputchar0('0');
          }*/
        }
        // done
        uputchar0( '\n' );
        uputchar0( '\r' );
        FS20bytecounter = 0;
        FS20protocol = PROTOCOL_UNKNOWN;

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kleine Zusammenfassung:
868,3 MHZ OOK
Manchester (G.E. Thomas: 0->1 = 0)
Präambel: 00000000000000001
Daten: 9 * (Byte + Parity)

Evtl. sollte man sich auf folgende Zählweise einigen
 Bytes: 0..8
 Bits: 7..0

Daten sind  miteinander verknüpft:

dec[0] = enc[0] ^ 0x89
dec[n] = (enc[n-1]+0x24) ^ enc[n]
 -> konstante Daten für dec[1] bis dec[7], ausgenommen dec[1].4

Dekodierte Bytes:
0 Zähler
1
2
3
4
5 7: Bat oder ID
  6..0: Temp, 2er Komplement, 1/10 °C
6 7..0: Temp  "       "         "
7 Luftfeuchte 1..255.0
  0x7F .. 0x80 -> dec[0].7 geändert
8

Die Temperaturberechnung benutzt anscheinend andere Faktoren, als das 
aktuelle Datenblatt.
Bei der Luftfeuchtigkeit kommt es einigermaßen hin.
Der Sensor kompensiert die Luftfeuchtigkeit mit den Temperaturwerten.

Fehlt noch: ID, evtl. Sensortyp, Batteriestatus, letztes Byte: 
Prüfsumme?

Leider schon spät jetzt..

Autor: A. S. (telekatz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dec[5].7 ist Batteriestatus. Mit neuen Batterien "0" und mit alten "1".

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du den Grenzwert auch schon ermittelt? Das kann ich sonst heute 
nachmittag mal machen.
Wie bist du eigentlich auf BidCos gekommen? Machst du beruflich was mit 
Nachrichtentechnik? Bist du Informatiker und siehst Parity-Bits 
grundsätzlich durch scharfes Hinsehen? :-)

Ich werde weiter etwas mit dem letzten Byte spielen und heute abend noch 
einen anderen Sensor aushorchen. Ideal wäre ja, den Zusammenhang 
zwischen Aufkleber und ID-Bits auch noch herauszufinden..

Autor: A. S. (telekatz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen Grenzwert meinst du?

Zu BidCos selber gehören die Sender ja nicht dazu. Auf BidCos bin ich 
gekommen, weil die Daten dort auch "verschlüsselt" gesendet werden und 
es vom gleichen Hersteller ist. Beruflich hab ich damit nichts zu tun, 
da hab ich mit Hubschraubern zu tun.

Hier noch ein paar unterschiedlich Sender mit ihrer Seriennummer:

EAA0073717  01 12 70 0E 65 80 D0 3B  20.8°C 59%
EAA0073720  01 12 70 0D D0 80 D0 3A  20.8°C 58%
EAA0073726  01 02 70 0D A1 00 E8 3D  23.2°C 61%
EAA0073676  01 12 70 0E 74 80 D0 38  20.8°C 56%
EAA0073677  01 12 70 0D BB 80 C5 45  19.7°C 69%

Einen direkten zusammenhang zwischen Aufkleber und übertragenen Bytes 
sehe ich da nicht.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grenzwert ist das falsche Wort, ich meinte die Schwelle für Batterie 
gut/schlecht. Konnte heute leider noch nicht weitermachen, morgen messe 
ich sie. Hubschrauber finde ich interessant! Kannst/darfst du fliegen? 
Na egal, es geht hier ja um die ASHs.
Evtl. geht die Batteriespannung auch in die RH Kompensation ein..

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Batteriespannungsschwelle (per AD0 ermittelt):
  5,06 V / 2,35 V * 1,24 V = 2,67 V

Scheint mir etwas hoch..

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt anscheinend keine Kompensation der Temperatur mittels gemessener 
Betriebsspannung.

Von SHT Temp 0x8c0 auf 0x8c1 gibt es einen Sprung der gefunkten 
Temperatur: 50.0 -> 52.0 °C
Für die Sauna muss das also kompensiert werden :-)

Die Berechnung der Temperatur bis 50 °C erfolgt anscheinend mit
d_1 = -3.4904151301571e+01
d_2 =  3.8423981997027e-02
d_3 = -3.3922943613259e-07
f =   4.1503742276566e+03
T = d_1+d_2*SO_T+d_3*(SO_T-f)^2

Damit liege ich max 0.1 K neben den gefunkten Daten (bis 50 °C).

Die Faktoren zur Berechnung der Luftfeuchtigkeit passen etwas besser zu 
den V3 Sensoren:

c_1 = -4.0
c_2 = 0.648
c_3 = -7.2e-4

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bis auf Bit 4 ist
 enc[8] = sum(dec[0..7]) ^ 0xED

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bit dec[1].4 ist etwas vertrackt. Wenn man sich nur das erste Paket nach 
Reset ansieht bei laufender Temperatur fallen die zyklischen Wechsel des 
Bits auf:

Das passiert alle 16 Werte, also 1.6 °C.
Es tritt aber auch bei der Luftfeuchtigkeit auf.
Also:

dec[1].4 =  ~(dec[6] ^ dec[7]) & 0x10)

Zyklisch verhält sich auch dec[0].7
Das findet alle 128 Werte statt. Bezugspunkt ist -40 °C.

In beides muss aber noch der Zähler und für dec[0].7 die 
Luftfeuchtigkeit irgendwie eingehen.
So gibt es eine zur Luftfeuchtigkeit (bei konst. Temp.) proportionale 
Anzahl von Bitwechseln dec[1].4 gegen Ende der Synch-Pakete (z.B. 678 
00e .. 678 01f).

Vielleicht seht ihr ja noch mehr..

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der interne LoBat Wert des SHT1x liegt bei 2,47V, wenn die 
Batteriespannung über die Referenz ermittelt wird, ist 2,67V ein 
möglicher Wert.

Die Berechnung der Temperatur ist abhängig von der VDD, da du mit 5V 
arbeitest, weichen die Berechnungen etwas vom tatsächlichen 
Temperaturwert ab.

Weiterhin gehe ich davon aus, dass die Berechnung Temperatur und 
Humidity mit der einfachsten Formel berechnet werden und nicht mit dem 
Aufwand einer floating point Berechnung, wie sie im Datenblatt steht, 
die Toleranzen 10%Humi und 2°C Temperatur ASH500 lassen darauf 
schliessen.

bei Sensirion leider nicht mehr zu finden :
http://www.driesen-kern.de/downloads/nonlinearityc...

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Norbert.

Norbert schrieb:
> Der interne LoBat Wert des SHT1x liegt bei 2,47V, wenn die
Wird nicht benutzt. Ob der SHT überhaupt das Einstellungsregister hat, 
habe ich nicht getestet.

> Batteriespannung über die Referenz ermittelt wird, ist 2,67V ein
> möglicher Wert.
Da ich den ASH und den AVR zum Auslesen an 5V betreibe, habe ich an der 
Referenzspannung gedreht und dann zurückgerechnet.
Der Wert scheint mir etwas hoch, da bei Alkali-Batterien m.W. 1,5 V 
nominal angenommen werden und bei 1.0 V Schluss ist. Vielleicht eine 
etwas pauschale Annahme, da die Entladekurve von mehreren Faktoren 
abhängt. Vielleicht ist bei den geringen Strömen tatsächlich schon bei 
1,35 V Ende.

> Die Berechnung der Temperatur ist abhängig von der VDD, da du mit 5V
> arbeitest, weichen die Berechnungen etwas vom tatsächlichen
> Temperaturwert ab.
Mhh, das vermutest du aber nur? Die Temperatur (SHT Daten) ist laut 
Datenblatt zwar abhängig von VDD, die Berechnung berücksichtigt dies 
aber nicht.

> Weiterhin gehe ich davon aus, dass die Berechnung Temperatur und
> Humidity mit der einfachsten Formel berechnet werden und nicht mit dem
> Aufwand einer floating point Berechnung, wie sie im Datenblatt steht,
> die Toleranzen 10%Humi und 2°C Temperatur ASH500 lassen darauf
> schliessen.
Wieso? Vorsicht mit Annahmen! Wie gesagt, die SHT Daten kann ich nur mit 
obigen Parametern in gute Übereinstimmung mit den vom ASH gesendeten 
Daten bringen.
Das mache ich allerdings auf dem PC und habe es nur mit einem ASH 
ermittelt - wenn du es besser und einfacher mit Integerarithmetik 
hinbekommst, her mit der Information :-)
Allerdings ist es für die "bestimmungsgemäße Verwendung" der ASH mit 
Originalcontroller sowieso egal, was intern gerechnet wird. Das dürfte 
nur diejenigen interessieren, die den unbekannten SHT direkt auslesen.

@telekatz: Treffen meine letzten Posts auch bei dir zu? Wie sind deine 
Pläne (mit Betty?)?

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Info,

deinen genauen Berechnungen ist nichts entgegenzusetzen, nur die von dir 
festgestellten Abweichungen solltest du nicht so hoch bewerten.
Wenn ich mich recht entsinne, hast du die Werte des SHT1x ausgelesen und 
durch Berechnung mit den gesendeten Daten verglichen.

Die Berechnung bzw. Formel bezieht sich auf das Datenblatt, welches über 
den Link zu finden ist. Die Temperatur wird hier immer noch mit float 
berechnet, aber wesentlich einfacher, aber auch ungenauer.

>Die Temperatur (SHT Daten) ist laut
>Datenblatt zwar abhängig von VDD, die Berechnung berücksichtigt dies
>aber nicht.

Temp=d1+d2xSOT
d1=?

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte ja mal die unterschiedlichen Berechnungszeiten zwischen 
SHT-Daten und RF-Sendung erwähnt.
Es sieht so aus, als wäre sie abhängig u.A. vom letzten Bit des RH 
(Luftfeuchtigkeit) Wertes und vom Zähler, die Zeit wechselt alle 2 
Zählwerte.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert schrieb:
>>Die Temperatur (SHT Daten) ist laut
>>Datenblatt zwar abhängig von VDD, die Berechnung berücksichtigt dies
>>aber nicht.
>
> Temp=d1+d2xSOT
> d1=?

Ist das jetzt ein Hinweis auf die Spannungsabhängigkeit?
Wir verstehen uns offensichtlich nicht.

> d1=?
>> Die Temperatur (SHT Daten) ist laut Datenblatt zwar abhängig von VDD
d1 = f(VDD)

>> die Berechnung berücksichtigt dies aber nicht.
Der ASH Controller benutzt die gemessene Betriebsspannung nicht für d_1 
-
Schieb ihm konstante SHT Daten unter, dreh an der Versorgungsspannung, 
es ändert sich nichts an dem gefunkten Wert (in meinem Fall: dreh an der 
Referenzspannung).

Es wird also immer dieselbe Berechnung durchgeführt, konstante 
Parameter.
Berechne jetzt anhand der SHT Daten entsprechend der Formel des 
Datenblatts die Temperatur und Luftfeuchtigkeit -> die Werte stimmen 
nicht mit den gefunkten überein. Warum? Es ist kein SHT mit bekannten 
Spezifizikationen. Wie kommt man an die richtigen Parameter ran? 
Zurückrechnen. Linearer Fit passt nicht. Polynomfit passt ganz 
brauchbar. Ergo: ASH Controller rechnet mit einem Polynom.

Die Genauigkeit des SHT-Sensors hat damit nichts zu tun, es sei denn, es 
gibt zusätzliche Kalibrierdaten auf dem ASH Controller. Dann dürften die 
Faktoren nicht für alle ASH gelten. Halte ich aber für unwahrscheinlich.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer einen Empfänger sucht: der weiter oben genannte kannte zwar den ASH 
nicht dekodieren (aber das €5 Ding von Conrad), enthält aber einen AVR 
mit ISP Header und möglicherweise offenen ungenutzten Pins (oder unter 
dem IC an GND?). Kostet nicht viel mehr als das Modul, was in 
Beitrag "Re: Protokoll ELV Funk-Temperatur-/ Luftfeuchtesensor ASH500" genutzt wird (s.u.)

USB-Wetterdaten-Empfänger USB-WDE1, Komplettbausatz
Artikel-Nr.: 68-846-52
€ 24,95
http://www.elv.de/output/controller.aspx?cid=74&de...
- CP2102
- ATmega88
- RX868-3V

Empfangsmodul RX868-3V, 868 MHz
Artikel-Nr.: 68-641-28
€ 13,55
http://www.elv.de/output/controller.aspx?cid=74&de...


Da ich, wie travelrec, einen feuchten Keller lüften möchte, brauche ich 
entsprechende Aktorik und dachte an Funksteckdosen. Wenn die Betty in 
der Lage wäre, die ASH passabel zu Empfangen, wäre mein Problem gelöst.

@telekatz - Kannst du was zur Empfangsreichweite der Betty bei 868 MHz 
sagen?

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Info,

wir verstehen uns wirklich falsch.

>Schieb ihm konstante SHT Daten unter, dreh an der Versorgungsspannung,
>es ändert sich nichts an dem gefunkten Wert (in meinem Fall: dreh an der
>Referenzspannung).

Der SHT1x hat eine eigene interne Referenz zur Messung der Temp/Humi 
Werte, ist also unabhängig von UB und der Referenz am MC. Die Umrechnung 
des SHT Wertes in einen Temperaturwert ist aber abhängig von d1 und 
ergibt je nachdem was eingesetzt wird (5V=-40°C oder 3V=-39,5°C) einen 
Temperaturunterschied von 0,5°C. Mehr wollte ich nicht mitteilen.

Das Statusregister wird gleich am Anfang angesprochen um die 8/12Bit 
Umschaltung für Temp/Humi zu aktivieren. Nach jeder Messung wird das 
Bit6
(low Voltage detection) im Statusregister gesetzt oder gelöscht in 
Abhängigkeit von der Höhe der UB am SHT1x. Da wie du sagst, das 
Statusregister zwischendurch aber nicht abgefragt wird, verwendet man 
wahrscheinlich die externe Referenz am MC zur Bestimmung des 
Batteriezustandes mit einer höheren Spannung LoBat von 2,67V. Wenn diese 
Spannung unterschritten wird, wie weiter oben schon geschrieben,
Bit7 dec[5] =1.

>Es ist kein SHT mit bekannten Spezifizikationen

Da hast du Recht, versuche es mal mit dem SHT10, der die grössten 
Toleranzen hat und in der Serie SHT1x_7x im Jahr 2005/2006 am billigsten 
war.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Umrechnung des SHT Wertes in einen Temperaturwert ist aber abhängig von
> d1 und ergibt je nachdem was eingesetzt wird (5V=-40°C oder 3V=-39,5°C)
> einen Temperaturunterschied von 0,5°C. Mehr wollte ich nicht mitteilen.

Genau, der Controller im ASH setzt aber immer denselben Wert ein, 
anstatt ihn anhand der gemessene Batteriespannung "auszuwählen".
Der Wert entspricht für die lineare Berechnung der Temperatur ungefähr 
dem aus dem Datenblatt für 5 V. Da wird sich der ELV-Entwickler aber 
hoffentlich etwas dabei gedacht haben, da ja nominal 3 V anliegen..

> Das Statusregister wird gleich am Anfang angesprochen um die 8/12Bit
> Umschaltung für Temp/Humi zu aktivieren.
Hast du das am ASH gemessen? Das wäre mir neu.

Autor: A. S. (telekatz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Info schrieb:
> Batteriespannungsschwelle (per AD0 ermittelt):
>   5,06 V / 2,35 V * 1,24 V = 2,67 V
>
> Scheint mir etwas hoch..

Mit einem regelbaren Netzteil hab ich 2,7V ermittelt. Passt in etwa.

Info schrieb:
> Die Berechnung der Temperatur bis 50 °C erfolgt anscheinend mit
> d_1 = -3.4904151301571e+01
> d_2 =  3.8423981997027e-02
> d_3 = -3.3922943613259e-07
> f =   4.1503742276566e+03
> T = d_1+d_2*SO_T+d_3*(SO_T-f)^2

Ich denke auch, dass das viel zu kompliziert ist und die Temperatur im 
ASH500 so nicht berechnet wird. Diese Formel passt für meine Daten von 
26,6°C bis 32,8°C ausreichend genau:

d_1 + d_2 * SO_t
d_1 = -39,60
d_2 = 0,04

Hast du ein Log mit mehr Temperaturwerten?

Eine Kompensation der Versorgungsspannung ist auch unnötig. Die 
Versorgungsspannung des SHT liegt zwischen etwa 3,3V (Batterie voll) und 
2,7V (Bit dec[5].7 gesetzt). Für die Berechnung der Temperatur wird von 
einer Versorgungsspannung von 3V ausgegangen. Die wegen der Spannung zu 
erwartende Messungenauigkeit liegt hier bei kleiner +-0,05°C. Das ist 
angesichts der Auflösung des ASH500 von 0,1°C unbedeutend und 
vernachlässigbar.

Info schrieb:
> @telekatz - Kannst du was zur Empfangsreichweite der Betty bei 868 MHz
> sagen?

Nicht sehr weit. Vielleicht 5m durch eine Wand. Desshalb werde ich das 
auch nicht großartig in die Betty integrieren. Lediglich den FS20 
Decoder werde ich dahingehend erweitern. Aber so etwas wie eine 
Wetterstation in der Betty hab ich nicht vor.

Autor: Info (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Hast du ein Log mit mehr Temperaturwerten?
Anbei immer das erste Paket nach Reset, Tem 0..0x0D2A Hum 0x005C

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Info,

deine Frage nach dem gemessenen StatusRegister, hat mich stutzig 
gemacht, da nach einem Softreset, wie er auch am ASH500 zu messen ist, 
auf 14/12Bit Messung beim SHT1x geschaltet wird.
Jetzt habe ich mir den Sensor im ASH500 genauer angesehen. Es ist, wie 
du schon vermutet hast, eine OEM-Version mit 12/8Bit 
Temperature/Humidity Messung.
Deshalb habe ich jetzt den Sensor aus dem ASH500 mit einem SHT11 
14/12Bit Auflösung verglichen (die Sensoren liegen in einem Abstand von 
ca. 5cm nebeneinander).
Die Berechnung für den ASH500 Sensor, mit der einfachsten Formel für 
Temp (d1+d2*SO_T) und 2*linear für Humi, ergeben Abweichungen der 
Temperatur von max.0,2°C und der RH von max.2%, über einen Zeitraum von 
2h, im Vergleich mit dem SHT11, der noch die Temperaturkompensation 
berücksichtigt.

Da im ASH500 mit einer Auflösung 12/8Bit gearbeitet wird, kannst du die 
Berechnung für erweiterte Temperaturbereiche vernachlässigen.

12Bit Temperatur 0,1°C bei einer Auflösung von 0,4°C/Bit
8Bit Humidity 1% bei einer Auflösung von 0,5%/Bit

>...- wenn du es besser und einfacher mit Integerarithmetik
>hinbekommst, her mit der Information :-)

Berechnung der Temperatur mit 16Bit Integer:
Temp=SO_T*10/25-396 - wärst du wahrscheinlich auch selber drauf 
gekommen!

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Norbert schrieb:
> Jetzt habe ich mir den Sensor im ASH500 genauer angesehen.
Gut :-) In deinen Beiträgen klang es für mich immer nach Fakten ("wird 
umgeschaltet"). Führt doch nur zu Verwirrung.

Dein Vergleich der Sensoren ist interessant, aber geht etwas an "meinem" 
Thema vorbei. Ausserdem schließt du von Raumtemperatur auf den gesamten 
Meßbereich.
Ich sage ja gar nicht, dass die Werte, die man mit der einfachen 
Berechnung erhält, absolut schlecht sind, oder dass es bei der 
Genauigkeit der Sensoren nicht sowieso egal ist. Nur sind es eben nicht 
die Werte, die der ASH Controller errechnet. Das kann man mit meinen 
zuletzt geposteten Daten nachvollziehen (5 V).
Aber es ist eigentlich auch egal was er rechnet, solange er möglichst 
genaue Daten sendet.

Warten wir nochmal telekatz' Meinung ab :-)
Von ihm würde ich auch gerne wissen, wie lange der Dekoder mit 
Fehlerkorrektur und Anlernfunktion noch braucht ;-)

Nicht zu vergessen: zwei Bits spielen noch verrückt!

Autor: Norbert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>12Bit Temperatur 0,1°C bei einer Auflösung von 0,4°C/Bit
richtig ist: 12Bit Temperatur 0,1°C bei einer Auflösung von 0,04°C/Bit

@ info
>Nur sind es eben nicht die Werte, die der ASH Controller errechnet
suchst du nach Daten des Sensors im Funkpaket, oder möchtest du die 
Daten des Sensors an die Funkdaten anpassen?? :-(

>Nicht zu vergessen: zwei Bits spielen noch verrückt!
ja eben

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachträglich Info zu Beitrag "Re: Protokoll ELV Funk-Temperatur-/ Luftfeuchtesensor ASH500"
Es handelt sich um einen Screenshot von 
http://www.dc3yc.privat.t-online.de/thermohygro.htm gehörend zu 
http://www.dc3yc.privat.t-online.de/protocol.htm
Dort ist das Protokoll von S 300 TH (S300TH) a.k.a. S 555 TH (S555TH) 
beschrieben.
Siehe auch:
http://fhemwiki.de/index.php/S555TH
Dekoder, mit Arduino source: http://www.jansipke.nl/tag/s555th

CUL hat ebenfalls einen Dekoder: h 
ttp://www.koeniglich.de/culfw/culfw.html
Steckt hier irgendwo mit drin: h 
ttp://cvs.berlios.de/cgi-bin/viewvc.cgi/culfw/culfw/clib/rf_receive.c?re 
vision=1.17&view=markup

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Telekatz,

hast du die Berechnung anhand meiner Daten nochmal geprüft?
Und hast du am Decoder schon weitergearbeitet?

Autor: A. S. (telekatz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die einfache Formel für den Temperaturwert stimmt nur für Temperaturen 
von 9,8°C bis 50°C. Die Formel mit den Werten aus der Application Note 
von Norbert liefert auch Ergebnisse, die +-0,1°C genau sind. Die Formel 
lässt sich aber mit diesen Werten leichter umstellen, so das keine 
Gleitkommazahlen benötigt werden.


Der Decoder ist jetzt in Boop drinn.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke. Hier übrigens die AN: 
http://www.sensirion.com/en/pdf/product_informatio... 
(V 1.5, 2008)

Autor: Wettermensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachdem ich bei ebay 2 von den ash500 ersteigert habe bin ich bei der 
Suche nach weiteren Informationen auf diesen Thread gestoßen.
Leider habe ich etwas die Übersicht verloren und deswegen 2 Fragen an 
die hier anwesenden Experten:
1. Ist das Protokoll inzwischen eigentlich vollständig bekannt?
2. Was ist Boop und wo finde ich nähere Informationen darüber?

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 1. Ist das Protokoll inzwischen eigentlich vollständig bekannt?
Nein aber fast, es fehlen noch ein paar Bits.
> 2. Was ist Boop und wo finde ich nähere Informationen darüber?
http://bettyhacks.com/wiki

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, gibt es schon Fortschritte beim Dekodieren der fehlenden Bits, 
Fehlerkorrektur oder im Bereich der Kellerbelüftung?

Kennt sich jemand mit "Fehlerkorrektur" aus und kann etwas dazu 
schreiben, welche Möglichkeiten es bei dieser Übertragung gibt, defekte 
Daten zu reparieren?

Beteiligt: Parity, Zähler, fixe ID, ähnliche Daten, Verknüpfung der 
Bytes, Prüfsumme.

Bei acht Sendern wird es wohl auch längere Zeiten geben, wo mehrere 
Sender gleichzeitig aktiv sind: bei 50 ppm für den Quarz
24*60*60*50e-6 = 4,32 s pro Tag
9 ms auf 3 min
Paketdauer ca. 48 ms

Im besten Fall sind 5 oder 6 Pakete überlagert, wenn die Drift zwischen 
zwei Sendern 50 ppm ist. Da lässt sich dann auch nichts mehr 
Rekonstruieren.
Je langsamer die Drift, desto länger die Überlagerung (und seltener). 
Die Temperatur spielt dabei natürlich auch eine Rolle.

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Info schrieb:
> Na, gibt es schon Fortschritte beim Dekodieren der fehlenden Bits,

Ich tippe mal, das ein bit anzeigt ob die Temperaturen positiv oder 
negtiv sind? So ist es auch bei den anderen Wettersendern und es werden 
als Werte ja nur die Ziffern übertragen.

Dem rekonstruieren von Werten aus der Prüfsumme gebe ich keine Chance, 
wozu auch der Aufwand, in 3 Minuten kommt ja die nächste Messung.

Apropos 3 Minuten, wie genau senden denn die verschiedenen Sensoren? Bei 
den SHT300 variiert der Abstand ja nach Adresse.

HTH,
Jo

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich tippe mal
Falsch getippt.

> Bei den SHT300 variiert der Abstand ja nach Adresse.
Ob das hier auch der Fall ist, habe ich noch nicht geprüft.

Es macht aber Sinn, die Zeiten zu variieren, weil damit das Problem des 
"Durchwanderns" der Übertragung zweier Sender seltener wird.

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Info schrieb:
>> Ich tippe mal
> Falsch getippt.

vielleicht ist es ja etwas komplizierter ;-)
hab gerade das hier gesehen:
http://dokuwiki.nausch.org/doku.php/wetter:ws500:d...

was allerdings die Kommunikation zwischen WS500 und PC beschreibt, aber 
vielleicht ist es ja ähnlich kompliziert beim Temperatursender, mal als 
Anregung für die kleinen grauen.
Da hat sich anscheinend jemand verwirklicht beim Protokoll...

Noch mal was zum Sensor, ist das Protokoll für das auslesen gleich mit 
dem SHT11? Norbert hatte das glaube ich gemacht, aber der Thread ist 
schon etwas länglich, sorry falls schon beschrieben.

Autor: Rubi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt das angehangene Protokoll nun, oder nicht???

Autor: Sandler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube, die Leute, die ihre Projekte zum laufen gebracht haben 
wollen ihr Wissen nicht weitergeben. Die werden dir keine Auskunft mehr 
geben.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, vom wde1 würde ich abraten. Die Empfangseigenschaften von dem 
Teil sind ziemlich schlecht. Dazu habe ich auch mal was im

Beitrag "S555HT AVR Beispielcode"

geschrieben. Hat aber niemanden interessiert.

Autor: frage (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ja, wäre wirklich nett, wenn telekatz es noch einmal einigermaßen 
verständlich zusammenfassen könnte. Der Code unter 
https://boopfirmware.svn.sourceforge.net/svnroot/b... 
der den ASH500-Decoder enthält, ist nicht gerade leicht verständlich.

Danke

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rubi, sandler, frage: Der Großteil des Protokolls ist in nächtelanger 
Arbeit ermittelt worden, es gibt Beschreibungen und Quellcode - was 
bitte erwartet ihr?
@Jürgen: Danke für die Info zu ELVs USB-WDE1

Autor: A. S. (telekatz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
frage schrieb:
> ja, wäre wirklich nett, wenn telekatz es noch einmal einigermaßen
> verständlich zusammenfassen könnte.

Der Protokollaufbau ist hier schon beschrieben:
Beitrag "Re: Protokoll ELV Funk-Temperatur-/ Luftfeuchtesensor ASH500"

frage schrieb:
> Der Code unter
> https://boopfirmware.svn.sourceforge.net/svnroot/b...
> der den ASH500-Decoder enthält, ist nicht gerade leicht verständlich.

Dann nimm mal den Code 
Beitrag "Re: Protokoll ELV Funk-Temperatur-/ Luftfeuchtesensor ASH500"
Der ist für den AVR und enthält auch nur den Teil für den ASH500. 
Zusätzlich noch von hier 
Beitrag "Re: Protokoll ELV Funk-Temperatur-/ Luftfeuchtesensor ASH500"
die Decodierung einbauen.

Autor: frage (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

an diese Beiträge kann ich mich gar nicht mehr erinnern schäm. Damit 
ist jetzt alles klar.

Danke.

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind alle Keller trocken und ist beim Rätsel um das eine Bit schon 
jemand weitergekommen?

Autor: TWJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe die obige Diskussion seitenlang verfolgt... leider ist mein request 
ganz simpel und "materiell":

Habe eine WS 777 und suche dafür noch 3 ASH 500 Temperatur- und 
Luftfeuchtesensor.
Wer kann mir dabei helfen?
Danke
TWJ

Autor: mb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe da mal so eine Farage.
Hat jemand mit dem ELV empfänger ein sicheren empfang hinbekommen?
Denn Manchestercodierung ist nicht alles oder ?
Gruß MB

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mögliche Empfängerhardware:

MSP430 Launchpad mit Anaren AIR BoosterPack (TI CC110L 868 MHz)

http://www.anaren.com/air/cc110l-air-module-boosterpack

Man bekommt ein Set mit zwei und zwei Launchpads für unter 30 $ im 
TI-Store. Das Kit enthält ausserdem zwei MSP430G2553 und Jumperkabel, um 
Hardware UART nutzen zu können.
Die aktuellen Launchpads enthalten MSP430G2553 + MSP430G2452 (und 
brauchen keine Jumperkabel, da angepasstes Layout).

Ich habe die Eignung der Transceiver (http://www.ti.com/product/cc110l) 
aber noch nicht geprüft, ich nehme an, dass es geht, da es mit der Betty 
mit einem Vorgänger-IC ( http://www.ti.com/product/cc1100 ) auch schon 
geklappt hat.

Die obligatorische Frage: ist das Rätsel um das unbekannte Bit schon 
gelöst?

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt einen Sensor im selben Gewand (Quelle: Reichelt 
Produktbeschreibung):

HomeMatic Funk-Temperatur-/Luftfeuchtesensor OTH
Erfassung der Außentemperatur und der Luftfeuchte. Für die Wandmontage.
Anzeige der Daten über Weather Display Center WDC 7000 oder Zentrale 
CCU1 möglich.
Lieferumfang:
• Sensor
• Batterien
• Anleitung
Hersteller : EQ-3
Artikelnummer des Herstellers : HM-WDS10-TH-O

Gibt es in anderem Gehäuse auch für Innenräume (HM-WDS10-TH-I), beide 50 
Euro.

Habe ich beide nicht, kann also nichts zu Hardware/Protokoll sagen..

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.