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&detail=10&detail2=12385&flv=1&bereich=&marke= Über Google habe ich noch nichts passendes finden können. Anscheinend besitzt jeder Sensor eine individuelle Adresse, welche in einem EEPROM gespeichert ist.
http://www.elv-downloads.de/Assets/Produkte/6/648/64865/Downloads/64865_Funk_Temperatur_Luftfeuchtesensor_ASH_500_UM.pdf 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.
Kannst du bitte deine Infos posten? Was steckt noch drin? Fotos wären toll.
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
http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=29870 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
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.
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
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
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 !
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...
Angehängte Dateien:
-
ASH500_1.jpg
320 KB
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.
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/semiconductor/productList.do?fmly_id=803&xFmly_id=802 Da hat sich wohl einer vertan, oder einen anderen LDO (?) noch günstiger bekommen?
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.
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)
@ 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.
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_humidity_sensors.htm Die Genauigkeitswerte widersprechen aber den Kennlinien. http://www.sensirion.com/de/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf 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).
Angehängte Dateien:
-
prot1.gif
330 KB
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.
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.
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
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..
Hier mal der "Bitstrom" von prot1, 1 = high:
1 | 00010101010101010101010101010101011010100110011001011010011001010110010101010101101010010110101001011001011010010110010110010101101001101010101001101010010110011001010101011001101001010110100110101000 |
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
Auch nicht schlecht. http://www.conrad.de/ce/ProductDetail.html?productcode=646260
1 | Sendefrequenz: ......................... 868,35 MHz |
2 | Freifeld-Reichweite: ................... 100 m |
3 | Datenübertragungszyklus: ............... 3 Min. |
4 | Temperaturmessbereich außen: ........... -20,0°C bis +55,0°C |
5 | Auflösung Temperaturmessung: ........... 0,1°C |
6 | Genauigkeit Temperaturmessung: ......... ±0,8°C |
7 | Messbereich rel. Luftfeuchte: .......... 5% - 95% rel. Feuchte |
8 | Auflösung Luftfeuchtemessung: .......... 0,1% |
9 | Genauigkeit Luftfeuchtemessung: ....... ±5% |
10 | Spannungsversorgung: ................... 2 x 1,5 V, LR6 (AA/Mignon) |
11 | Abmessungen (B x H x T, Sensor): ....... 38 x 138 x 20 mm |
12 | Tiefe des Montagefußes: ................ 50 mm |
Das ist doch identisch mit dem hier http://www.elv.de/Funk-Temperatur-Luftfeuchteau%C3%9Fensensor-S-300-TH/x.aspx/cid_74/detail_10/detail2_20690/flv_1/bereich_/marke_ Selbst die Doku ist die gleiche. Nur der Preis ist nicht annähernd identisch.
Na, gibt's schon was Neues? Ich bin schwer am Überlegen, lieber die S555TH von C zu nehmen. S555TH: "Verfügbar sind 8 Adressen"
> 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?
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...
> 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"?
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
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.
Mist, und zudem gibt es noch eine 5,- EUR Gutscheinaktion. Ich hätte noch warten sollen mit meiner Bestellung.
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/doc9164.pdf
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 ;-)
Angehängte Dateien:
-
prot.png
8,1 KB
> 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.
Angehängte Dateien:
-
prot_c.png
11 KB
Noch ein paar Geister :-) Es ist aber nicht immer vertikal 00->1. Kannst Du noch mehr Daten sammeln bitte?
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?
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...
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
Angehängte Dateien:
-
protocol_parity.png
27 KB
Die von Telekatz vermutete Aufteilung von 8 Datenbits + Parität ungerade würde für die meisten Bytes passen. Aber nicht bei allen.
Bist du denn sicher das jede Zeile zusammen gehört ? oder könnte die zuordnung auch anders aussehen ?
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
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 :-)
noname schrieb: > :-) Passt doch gar nicht? 00000000000000001TTTT1AAAV1TTTT1TTTT1TTTT1FFFF1FFFF1FFFF1QQQQ1
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..
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.
1 | Paket 1: |
2 | Bit 1-4: zählt rückwärts T*16 |
3 | Bit 5-6: zählt rückwärts T*4 |
4 | Bit 7-8: zählt vorwärts T |
5 | |
6 | Paket 2: |
7 | Bit 5-6: zählt rückwärts T*4 |
8 | Bit 7-8: zählt vorwärts T |
9 | |
10 | Paket 3: |
11 | Bit 5-6: zählt rückwärts T*4 |
12 | Bit 7-8: zählt vorwärts T |
13 | |
14 | Paket 4: |
15 | Bit 5-6: zählt vorwärts T*4 |
16 | Bit 7-8: zählt vorwärts T |
17 | |
18 | Paket 5: |
19 | Bit 5-6: zählt rückwärts T*4 |
20 | Bit 7-8: zählt rückwärts T |
21 | |
22 | Paket 6: |
23 | Bit 5-6: rückwärts T*4 |
24 | Bit 7-8: rückwärts T |
T*4 bedeutet beispielsweise 4mal so langsam wie T. Interessant ist auch die Paketfolge
1 | 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 |
2 | |
3 | 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 |
4 | 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 |
5 | |
6 | 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 |
7 | 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 |
8 | |
9 | 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 |
10 | 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 |
11 | |
12 | 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.
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.
Kannst du mal deinen Code posten, mit dem du den SHT emulierst?
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..
Noch allgemeine Info: Der SHTxx ist wohl kein Standardtyp, da per default im low-res mode: 8 bit humidity und 12 bit temp.
Hat denn hier jemand einen passenden Empfänger? Mit echten Anzeigedaten ließen sich die richtigen Faktoren für die Berechnungen ermitteln..
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.
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
Die vielen Zähler haben bestimmt einen Grund und sind nicht nur zur allgemeinen Verwirrung da. Vielleicht eine Verschlüsselung welche Zähler einsetzt?
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.
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).
Hier eine ältere Version des PCB: http://www.wetterstationsforum.de/phpBB/viewtopic.php?p=161556#161556 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)
Angehängte Dateien:
-
ASH500.jpg
64 KB
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.
Der Mikrocontroller ist OTP. Theoretisch kann man ihn auslesen, dazu fehlt aber das serielle Protokoll und im Datenblatt ist von Read Protection die Rede.
In einem neueren Datenblatt steht ein bisschen mehr zum Flashen: http://www.samsung.com/global/system/business/semiconductor/product/2009/4/2/419800um_s3p9228_rev11.pdf Eine Suche ergibt, dass auch http://www.elnec.com/en/search/device-list/?prog=9&man=40#108 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."
Angehängte Dateien:
-
start.png
2,2 KB -
sequenz.png
2,3 KB
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.
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
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.
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&detail=10&detail2=12822&flv=1&bereich=&marke= 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
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?
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.
> 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
Angehängte Dateien:
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.
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.
> 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-Temperatur-Luftfeuchtesensor-OTH/x.aspx/cid_74/detail_10/detail2_21650/flv_/bereich_/marke_ http://www.homematic-inside.de/index.php/hardware/firmwareversions.html : "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..
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!
Änder das mal im Sourcecode, dann kommt das decodiert raus:
1 | uputchar0(FS20inbyte[0]); |
2 | for(x=1;x<(FS20bytecounter);x++) { |
3 | uputchar0(' '); |
4 | uputhex0(FS20inbyte[x]); |
5 | }
|
6 | |
7 | //decode
|
8 | uputchar0(' '); |
9 | uputchar0(' '); |
10 | uputhex0(FS20inbyte[1] ^ 0x89); |
11 | for(x=2;x<(9);x++) { |
12 | uputchar0(' '); |
13 | uputhex0((FS20inbyte[x-1] + 0x24) ^ FS20inbyte[x]); |
14 | |
15 | /*for(y=8; y; y--) {
|
16 | if(FS20inbyte[x] & (1<<(y-1)))
|
17 | uputchar0('1');
|
18 | else
|
19 | uputchar0('0');
|
20 | }*/
|
21 | }
|
22 | // done
|
23 | uputchar0( '\n' ); |
24 | uputchar0( '\r' ); |
25 | FS20bytecounter = 0; |
26 | FS20protocol = PROTOCOL_UNKNOWN; |
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..
dec[5].7 ist Batteriestatus. Mit neuen Batterien "0" und mit alten "1".
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..
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.
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..
Batteriespannungsschwelle (per AD0 ermittelt): 5,06 V / 2,35 V * 1,24 V = 2,67 V Scheint mir etwas hoch..
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
Bis auf Bit 4 ist enc[8] = sum(dec[0..7]) ^ 0xED
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..
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/nonlinearitycompensationec1.pdf
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?)?
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=?
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.
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.
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&detail=10&detail2=24916 - 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&detail=10&detail2=12822 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?
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.
> 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.
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.
> Hast du ein Log mit mehr Temperaturwerten?
Anbei immer das erste Paket nach Reset, Tem 0..0x0D2A Hum 0x005C
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!
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!
>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
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
OT: Hier ein Blick unter die Haube von WDE1 (USB, s. Beitrag "Re: Protokoll ELV Funk-Temperatur-/ Luftfeuchtesensor ASH500") und IPWE1 (Ethernet) http://wetter.tdressler.net/wetter_projekte_2.html
Hallo Telekatz, hast du die Berechnung anhand meiner Daten nochmal geprüft? Und hast du am Decoder schon weitergearbeitet?
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.
Danke. Hier übrigens die AN: http://www.sensirion.com/en/pdf/product_information/Non-Linearity_Compensation_Humidity_Sensors_E.pdf (V 1.5, 2008)
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?
> 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
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.
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
> 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.
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:datensatzbeschreibung 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.
Ich glaube, die Leute, die ihre Projekte zum laufen gebracht haben wollen ihr Wissen nicht weitergeben. Die werden dir keine Auskunft mehr geben.
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.
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/boopfirmware/boop/trunk/cc1100/ der den ASH500-Decoder enthält, ist nicht gerade leicht verständlich. Danke
@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
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.
Hi, an diese Beiträge kann ich mich gar nicht mehr erinnern schäm. Damit ist jetzt alles klar. Danke.
Sind alle Keller trocken und ist beim Rätsel um das eine Bit schon jemand weitergekommen?
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
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
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?
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..
Wie die Zeit vergeht! Ich biete 24 originalverpackte ASH500 für je 2 Euro. Sie sind ungetestet und muffeln etwas nach feuchtem Keller, waren aber zusammen in Folie verpackt, d.h. keine direkte Verschmutzung. Bei Interesse kann ich nächste Woche eine Stichprobe machen. Versand ab 6 Stück z.B. Hermes. Oder Abholung in Berlin-Kreuzberg.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.