Ziel:
Die 15 elektronischen Heizkörperthermostate im Haus per BUS (I2C oder
RS xxx) konfigurieren und auslesen können. Die Funklösung der Fa. ELV
(FHZ8x) ist hier das Vorbild, war mir aber mit 70 und mehr pro Raum zu
teuer. Die Rondostat HR20E kosten z.Zeit bei ebay ca. 30 !
Die Thermostate sind vom Typ Honeywell Rondostat HR20E. Bedienung per 3
Tipptasten und 1 Stellrad mit Drehgeber. LCD-Display und Stellmotor für
Heizungsventil. Prozessor ist ein 80-pol. NEC 753016AG-E33 (2k-ROM und
1kRAM). EEPROM ist ein Seiko-3-Wire vom Typ S93C5x (2K).
Auf der Leiteplatte ist noch ein 10pol.Pfostenleiste die zum
NEC-Prozessor führt, wahrscheinlich Schnittstelle für Prüffeld während
der Herstellung oder gar Vernetzungsschnittstelle ?
Ich möchte nun einen AVR (2313 o.ä.) pro HR20E dazu einsetzen, die
Steuerung des HR20E einweder per Tastenemulation, per
EEPROM-Manipulation oder über Eingriff über diese besagte Pfostenleiste
zu realisieren. Der AVR soll dann die BUS-Anbindung übernehmen.
Hat schon einmal jemand mit diesen Rondostat HR20E o.ä. in der Richtung
was gemacht oder gleiche Vorhaben?
Hallo,
ich habe mich mal einen Tag mit diesem Controller beschaeftigt und
einige Informationen gewinnen und zusammentragen koennen.
Es wird die Hardwareschnittstelle + das Kommandset zu einem Grossteil
dokumentiert.
Die letzte Version befindet sich auf:
http://www.cornelius-consult.de/hr20_doc.txt
Viel Spass
(Feddback erwuenscht)
Werner
Hallo Werner,
es hört sich nicht schlecht an.
Hast Du es geschafft, die Solltemperatur zu ändern ?
Mein Ziel wäre über EIB die Temperatur auf bestimmten Wert zu setzen.
Gruß
Gordian
HR20E
Naja, Honeywell hat die Firma nur zugekauft, die diese Dinger
herstellt. Unter der Hand sind die Hersteller übrigens nicht all zu
überzeugt von dem HR20E und verweisen auf den Nachfolger, der
zugegebener Maßen nicht all zu gut aussieht.
vieleicht könnt ihr euch mit ganz einfachen Stellmotoren, z.B. von
Jung, oder sowas anfreunden?
Erstens sind die Dinger aus Metall und damit deutlich langlebiger,
kleiner, ihr könnt sie direkt ansteuern und der Temperaturfühler 20
Zentimer neben dem Heizkörper ist auch nicht ganz das Gelbe vom Ei
Ach ja, für den Nachfolger gibt es einen externen Temperatursensor,
oder soll es zumindest geben. Darüber könnte man zumindest die
Messwerte des Thermofühlers beeinflussen... und letztendlich die
Funkton des Gerätes
Der Knackpunkt bei der ganzen Geschichte ist der Preis.
Ich brauche keine 0.1 Grad genaue Temperatursteuerung.
Die HRs laufen soweit OK, was mich nur reizt ist die
Änderung der Solltemperatur über EIB.
Anwendung: Fernverstellung der Zimmertemperatur.
Gruß
Gordian
Guten Abend,
Ziel der Uebung war nicht, ein professionelles System zu erstellen. Das
mit dem Temperaturfuehler neben der Heizung ist an den Geraeten leider
sehr stoerend (vor allen Dingen wenn die Heizung mehr oder minder
"ueberdacht" ist), ansonsten funktionieren die fuer den Preis aber
ganz gut und vor allen Dingen auch autark, also nicht nur per
Fernsteuerung.
In meiner erstellten Doku ist die Abfrage und Aenderung der
Solltemperatur ja dokumentiert um auf obige Frage einzugehen.
Sowhl permanent (im EEPROM) als auch Temporaer (analog zum Drehen am
Knopf) funktioniert.
Das ganze hat mich als Uebung mal gerade einen halben Tag gekostet, das
kann man mal investieren. Vielleicht kriegt ja noch jemand anders was
interessantes zur Verwendung heraus.
Ich habe jetzt auch testhalber mal diese Korrektur der Temperatur wegen
der Naehe des Fuehlers zur Heizung umgestellt, mal sehen ob das
vielleicht auch schon ohne sonstige Eingriffe eine verbesserte Funktion
bringt.
Sollte das halbwegs klappen, bin ich mit dem Dingern eigentlich voellig
zufrieden (Ok Feiertage etc. sollte man noch programmieren koennen,
gerade in Betrieben).
Gruss
Werner
absolute Spitzenarbeit von Werner. Die Solltemperatur läßt sich mit dem
überschreiben der Speicherzelle 0x136 (Hex) lesen und schreiben.
(siehe Beschreibung -> 0x136 aktuelle Solltemperatur, kann bis zur
naechsten automatischen Umstellung per Uhr wohl ueberschrieben werden.
Im nauellen Mode bleibt der Wert dauerhaft erhalten Wert in 1/10 Grad
Celsius mit Offset 6.0 Grad -> 0 = 6.0 Grad, 10dez =
7.0 Grad )
Das sind für mich fast 90% dessen was ich wollte. Der Rest ist
schmückendes Beiwerk...
Im Übrigen: Der HR20 ist billig (~30), läuft bei mir seit 2 Jahren
fehlerfrei (18 Stück) und ist nun auch noch steuerbar. (und wenn die
Steuerung mal nicht geht, läuft das Teil selbstständig weiter)
Gruß Uwe
>absolute Spitzenarbeit von Werner.
Dem schliesse ich mich auch an.
Die HR20s sind auf jeden Fall das Geld wert.
Was mir fehlt ist eine zusätzliche Heizperiode.
Zusätzlich möchte ich auch die Temperatur fernsteuern.
Dazu ist dank Werner der erster Schritt getan.
Ich werde die HR20s an EIB adaptieren.
Det MEGA128 wird als MC dienen.
Da die Kommunikation zum HR20 seriell statt findet, ist die Ankopplung
sehr einfach.
Gruß
Gordian
Zitat:
Nummerierung des Steckers wie normaler Pfostenstecker.
Pfostenstecker mit Nase nach oben aufsetzen. Markierter Pin 1 ist dann
der hinterste Pin der oberen Reihe. Pin 2 der hinterste Pin der
unteren Reihe.
Zitat Ende.
Ich habe heute nach der Anleitung einen Adapter nach RS232 gebaut.
Nichts ging.
Dann habe ich die Spannung am Pfostenstecker gemessen.
Oberste Reihe, hinterster Pin soll Pin 1 sein.
Der dadrunter Pin 2.
Pin 1 (A) hat bei mir +3V, gemessen gegen Pin 2 (B) GND.
In der Beschreibung steht es umgekehrt ?
Wo liegt nun der Fehler ?
Ich habe eine Zeichnung beigefügt.
Absichtlich ist hier kein Pin 1 gekennzeichnet.
Ich hoffe damit den HR20E nicht abgeschossen zu haben.
Gruß
Gordian
Hallo,
hab gerade mal nachgemessen. Bei mir ist die Spannung genauso gepolt,
wie in der Anleitung von Werner beschrieben. Also nach deinem Bild: A->
+3V, B-> GND
Gruß
Filzlaus
Hallo,
laut Beschreibung:
> Markierter Pin 1 ist dann der hinterste Pin der oberen Reihe.
Also im Bild Stift A (+3V)
> Pin 2 der hinterste Pin der unteren Reihe.
Also im Bild Stift B (GND)
Pin 1 (Stift A) wird im Weiterem mit GND bezeichnet, Pin 2 (Stift B)
mit VCC.
Also genau andersrum.
Wo liegt nun der Knackpunkt und wie ist die richtige Zuordnung.
A=VCC, B=GND, C= ???, D= ???
Habe ich was übersehen ?
Gruß aus Lüdenscheid
Gordian
...stimmt, irgendwas passt da nicht ganz!
Ich werde das nächste Woche mal testen. Wenn die Spannung richtig
gepolt ist, dann kann dabei ja eigtl. nicht so viel kaputt gehen.
Gruß
filzlaus
Hallo,
nun konnte ich mit HR20, per Terminal, Daten austauschen.
Die Temperaturverstellung funktioniert aber nicht, wenn der Regler per
Hand auf On oder Off gestellt wird.
Habt Ihr es rausbekommen wo diese Info steht ?
Gruß
Gordian
Hallo Micha,
an den Heizkörpern habe ich EIB Leitung gelegt.
So gesehen werde ich es an EIB adaptieren.
Die Schnittstelle zum HR20e ist super einfach.
Hier wird es keine Probleme geben.
Was interessant wäre, rauszubekommen, wie die aktuelle Temperatur
aus den internen Registern zu lesen ist und wie erkenne ich die On/OFF
Stellung.
Gruß
Gordian
Zur Ergänzung der Doku:
Register 0x20C liest eingestellte Temperatur im Manu und Auto Mode.
0x0000 = OFF
0x0014 = 8.0°
0x0019 = 8.5°
0x001E = 9.0°
...
0x00DC = 28.0°
0x00FF = ON
/Michael
Moin moin,
wo ich mich doch grad mit der Thematik befasse - ich hab zuhause sowas
ähnliches an programmierbaren Thermostaten, und zwar die Danfoss
RA-plus. Sind zwar nicht so komfortabel wie die Honeywell-Teile (nur
zwei Zeitgruppen einstellbar), aber sie erfüllen mal ihren Zweck.
Nun hab ich neugierdehalber eins von meinen Danfoss-Teilen zerlegt.
Überraschung... Die haben auch einen NEC-Prozessor (siehe Foto);
ebenfalls in einem 80poligen Gehäuse!
Der hat zwar ne etwas seltsame Beschriftung, aber wenn ich mir das
Datenblatt des µPD753016A
(http://www.am.necel.com/docs/files/U11662EJ2V1DS00.pdf) und das Pinout
so überfliege, könnte der sogar pinkompatibel sein.
Gibt also noch genug Beschäftigung für die langen Wintertage ;-)
Gruß
Micha
Nachtrag:
Experimente mit dem Danfoss RA-plus lohnen sich wohl nicht. Das Teil
hat keine elektronische Temperatursteuerung; der Stellmotor fährt
lediglich das Ventil zu den (Nacht-)Absenkzeiten zu und später wieder
auf. EEPROM ist auch keins vorhanden.
@Gordian S.: bei mir ist auch der...
PIN 1 (oben) der Plus
&
PIN 2 (unten) der Minus
...an den Rest hab ich mich irgendwie noch nicht so gewagt.
Gruß
Jan
Es scheint, als hätte sich beim HR-20E die Firmware geändert. Ich habe
vor einiger Zeit einen neuen bekommen und dort sind die 'geheimen'
Sonderfunktionen anders belegt. Es gibt viel weniger und insbesondere
lässt sich mit 02:xx die Funktion des Displays nicht mehr umschalten.
Die offensichtlichste Änderung ist, dass beim Einlegen der Batterien
und beim Reset - dafür gibt es jetzt eine Tastenkombination - kurz der
Text "2.0" im Display erscheint.
>Es scheint, als hätte sich beim HR-20E die Firmware geändert.
Hoffentlich hat siche der Zugriff auf die internen Register nicht
geändert :-)
Gruß
Gordian
Ich habe zum Testen mal einen neuen HR-20E an den PC angeschlossen
(Firmware Version 2.04 mit Hardware Version 2). Die Belegung der
Stiftleiste scheint noch die gleich zu sein, aber ansonsten hat sich
einiges geändert:
Verbinden mit PC -> 9600 Baud, 1 Stopp, keine Parität
Befehle:
rxxx - lese ein Byte aus Adresse XXX
wxxxyy - schreibe das Byte YY an Adresse XXX
txx - ???
d - ???
i - gibt so was wie eine Seriennummer aus
v - Versionsinfo
Ich habe dann ein kleines Programm geschrieben mit dem man den gesamten
Speicher von 0x000 bis 0xfff abziehen kann, danach mal die
SollTemperatur am HR-20E geändert und den Speicher erneut abgezogen.
Leider sind beide Speicherabzüge identisch.....
Ist jemand vielleicht schon erfolgreicher gewesen ? Ich suche lediglich
eine Funktion mit der man im manuellen Betrieb des Thermostats die
Zieltemperatur remote ändern kann.
Hallo Trix,
hab gerade gemerkt, dass du der Entwickler des Tools bist :)
Nur eine kleine Frage. Hast du das Tool auch mit einem neuen Rondostat
Thermostat getestet. Die Neuen haben eine andere Firmware und ein
anderes Protokoll ?
Hallo
Es tut mir leid, wenn das Programm nicht mit der Firmware > 1
funktioniert. Leider haben alle Rondostaten die sich in meinem Besitz
befinden eine Einzer Firmware (ich hab die schon etwa zwei Jahre). Aus
diesem Grund wird es wohl in näherer Zukunft keine Adaption auf die neue
Firmware geben. Somit werden wohl nur Leute mit der alten Firmware von
den Tool profitierern. sorry
Aber Danke für den Hinweis, ich werde es auf der Seite mit Vermerken.
Gruß Trix
Hallo,
habe mir gerade einen neuen HR-20E gekauft.
Nach dem einschalten zeigt er: 2.04 , ich vermute das ist die
Firmwareversion.
Zerlegen offenbart: der uC ist ein Atmel mega169V.
Werde in den nächsten Tagen für mal evaluieren ob es lohnt eine
Firmware selbst zu programmieren.
Zunächst werde ich mal einen Schaltplan erstellen.
Norbert
hallo,
kann es sein das mit der neuen Firmaware nur noch der Weg über deine
Simulation der Tastendrücke möglich ist?
Also eine Controlleplatine die die manuelle Eingabe einer Solltemperator
direkt an den Tasten des Thermostates simuliert und somit doch noch eine
Fernsteuerung ermöglicht.
Hallo,
warum muß es der Honeywell Rondostat sein? Ich kaufte mir von Conrad das
Funk-Heizköper-Themostat-Set (Best-Nr.56 06 06). Die Steuereinhait kann
bis zu 8 Ventile in einem! Raum steuern. Man könnte hier den Funkcode
"erforschen" , eine eigene Steuerung bauen und die Elektr. Ventilsteller
nutzen.
Was mein ihr dazu? Ideen, oder gar Erfahrungen?
Hans-Jürgen
> Man könnte hier den Funkcode "erforschen" ,....
Stelle dir das nicht unbedingt so einfach vor. Ich habe das mal mit
einer Wetterstation versucht. Das Protokoll zu entschlüsseln (d. h. wie
wird physikalisch eine "1" oder "0" gesendet) war relativ einfach, auch
die Daten zu dekodieren war noch relativ einfach. ABER: Die Übertragung
ist natürlich mit einem Prüfbyte versehen. Dieses selber zu berechnen
ist mir bis heute leider noch nicht möglich. Fazit: Ich kann die Sender
zwar empfangen (leider ohne Prüfung ob auch korrekt übertragen), selber
zu senden ist mir nicht möglich.
Noch eine Frage: Wie genau funktioniert denn so ein Regler eigendlich
mechanisch? Ist da ein Schrittmotor drinn? Wie wird das Heizkörperventil
verstellt? Wenn also die Temperatur zu hoch ist, fährt der Regler dann
etwas zu oder gleich komplett? Wie sieht das eigendlich mit den
Geräuschen aus, wenn das Ventil verstellt wird?
Fragen über Fragen,
Gruß Martin
Im Rondostat ist ein normaler DC Motor drin, der über ein Getriebe und
eine Schnecke den Zentralstift des Ventils betätigt.
Bin mir nicht ganz sicher bei der Erkennung der Endstellungen (Auf/Zu)
des Stifts, unabhängig vom Endanschlag der Schnecke. Könnte sein, das es
durch die Stromaufnahme des Motors geprüft wird, etwa beim Lernlauf nach
einem Batteriewechsel.
Der Regler fährt aus meiner Erfahrung in kleinen Schritten mit längeren
Intervallen. Es wird schon der Durchfluss am Ventil reguliert, ist also
keine reine Zweipunktregelung mit Auf oder Zu.
Der Geräuschpegel ist erträglich, ich bin Nachts noch nie davon wach
geworden, dürfte aber auch Gewöhnungssache sein, und ein wenig Fett
wirkt manchmal Wunder.
Hallo,
@ Martin:
Danke für die Warnung vor den Schwierigkeiten bei der "Erforschung" des
Datenprotokolls.
Den Regler habe ich noch nicht geöffnet, kommt noch. Das Ventil wird
proportional verstellt. Meinem ersten Eindruck nach wird der Weg bei der
Initialisierung ermittelt: Ganz offen ist fest eingestellt (Stift voll
aus dem Ventil raus) und der Punkt Ventil zu wird über die Blockierung
des Antriebes (Stift läßt sich nicht weiter eindrücken) und der daraus
erhöhten Stromaufnahme? ermittelt.
Wenn ich die Geräte öffne, werde ich selbstverständlich nach den
Controllern usw. schauen. Ob das Auslesen der Programms gesperrt ist?
Viele Grüße
Hans-Jürgen
Hallo zusammen,
nach meinen Tests zu urteilen fährt der Rondostat sowohl
die "offen Stellung" als auch die "geschlossen Stellung"
mechanisch an. Durch die Optoelektronik detektiert der
Thermostat dass sich der Antriebsmotor nicht mehr bewegt
wenn er am Anschlag ist. Dies löst auch die Frage: Woher
weiß der Thermostat ob ich das Einstellrad nach Abnahme
des Bedienteils bewegt habe ?
Zur neuen Firmware:
Habe ein erstes Testprogramm per JTAG in den controller
eingespielt. LCD ansteuererung funktioniert.
Alles weitere folgt ...
Ziel:
Stellt euch mal vor es gäbe ein kleines Platinchen zum
aufstecken für den Rondostat. Ihr könntet eine RS485
Bus Leitung anschliessen und einen embedded controller
welcher zur Steuerung eines solches Busses in der Lage
ist anschliessen. (TinyTiger Wilke GmbH ,etc ...).
Ein batteriegetriebener, abgesetzter Raumthermostat mit
regelmäßiger Temperaturmeldung über den Bus wäre sicherlich
auch nicht schwierig zu bekommen,
Am Rande:
Hat jemand Erfahrung/Sourcen für die Regelschleife eines
Heizkörper-Thermostaten ?
Nachtrag:
Es war natürlich nicht möglich die bestehende Firmware aus-
zulesen. Alle möglichen Fuse-Bits waren gesetzt ! Es muss also
was eigenes her !
Hier die Pinbelegung des 10pol Steckers:
1 Vcc Target sense
2 do not use
3 TMS
4 TCK
5 TDO
6 TxD (uninverted CMOS Pegel, out)
7 Rxd (uninverted CMOS Pegel, in)
8 TDI
9 battery positive power supply
10 battery negative, GND
Wie erwartwartet: COM Schnittstelle, JTAG
Interface und Stromversorgung.
Pin 1 ist Richtung Ventil und entsprechend eines
Standard Pfostensteckverbinders.
>>Hat jemand Erfahrung/Sourcen für die Regelschleife eines>>Heizkörper-Thermostaten ?
An was hattest du denn gedacht?
Problem einer "richtigen" Regelung dürfte hier die Reaktionszeit der
Regelstrecke sein. Die ist ja nun nicht unbedingt fix, und ändert sich
mit den Umgebungsparametern (Raumgröße zB.)
Könnte es funktionieren, wenn man das Ventil in fixen Intervallen um
einen bestimmten Betrag öffnet bzw. schliesst, und dann abwartet wie
sich die Raumtemperatur verhält? Den Betrag der Ventilansteuerung würde
ich dann wieder an die Differenz zwischen Soll/Ist anpassen, also je
höher die Differenz um so weiter sollte das Ventil pro Intervall bewegt
werden.
Die Raumtemperatur zu regeln dürfte wirklich kein größes Problem sein da
die Temperatur ja nicht so schnell steigt. Ich würde das so machen umso
größer die Differenz zw. Soll und Ist desto weiter muss das Ventil
öffnen, dann kann man messen wie schnell die Temperatur ansteigt um
vorher wieder zurückzudrehen weil der Heizkörper ja mit schließen des
Ventils nicht abrupt aufhört zu heizen. Also rechtzeitig wieder
zurückdrehen um bei Annäherung an die Ist-Temp eine flachere
Anstiegszeit zu erhalten. Uu Überschwingern dürfte es dann garnicht
kommen.
Über welchen Zeitraum würdest du den Temperaturanstieg messen? Und
welchen Anstiegsbetrag würdest du als Maß nehmen? Anstieg um 1° dürfte
zu wenig sein oder?
Einfach mal messen jeder Funkwecker hat ja heutzutage ein Thermometer
drin das eine Auflösung von 0,1° hat.
Stell also mal einen in die Nähe des Thermostates drehe die Heizung voll
auf und zeichne dir mal ein Diagramm in dem du z.b. alle 2 Min die
Temperatur einträgst. Dann weist du schonmal wie linear(oder auch nicht)
das ganze verläuft.
Kannst ja auch mal vor der erwünschten Ist-Temp die Heizung abstellen
oder zurückdrehen um den weiteren Temperaturanstieg zu messen.
Also erst ausgiebig aufzeichnen, damit du weißt wie deine Regelung
reagieren muss. Man könnte das Programm ja so gestalten das es solche
Kurven aufzeichnet und sich so an die Raumverhältnisse anpasst.
Hallo from Denmark.
Has anyone tryed the Rondo-set program? I can connect with Telix, but
not with Rondo-set, do anyone have a diagram? I have attached how I
connect with the Rondostat.
Regards
Michael
Hilfe!!!!
Ich habe seit vier Wochen acht Rondostat HR-20E an meine Heizkörper
montiert und es zeigt sich folgender Fehler:
Nach dem Zufallsprinzip bleiben oft morgens Heizkörper kalt, obwohl das
Display die eingestellten 21°C anzeigt. Ich senke die Temperatur ab 19°°
auf 16°C ab und lasse ab 6°° wieder auf 21°C heizen.
Um den Fehler zu beseitigen nehme ich das Bedienteil dann ab, drehe kurz
am "großen" Rad, das das Ventil betätigt, montiere das Bedienteil wieder
und alles funzt.
Ich habe die Rondostat mit Akkus bestückt - Spannung zu gering ?
Es wäre schön, wenn mir jemand einen Tip geben kann, die Dinger treiben
mich zur Verzweiflung.
Danke Rainer
Ich habe einige HR-20E.
Zwei sind älteren Baujahrs, andere habe ich später gekauft.
Verhalten sich etwas unterschiedlich.
Deinen beschriebene Fehler habe ich jedoch noch nicht.
Ich habe Batterien drin.
==> Ich würde die Akkus gegen Batterien tauschen.
Akkus sind von selbst leer nach 2-3 Monaten und ob 2,4 Volt ausreicht,
ist ebenfalls fraglich, wie Du selbst schon schreibst.
4er Packung kosten 0,99 beim preiswerten Markt an der Kasse.
Alkali sollen's schon sein.
Bei mir halten die ca. 1,5 Jahre, bei 2 Schaltpunkten täglich.
Wichtig ist auch, dass das Teil mit dem Adapter richtig FEST draufsitzt.
Schraube am Adapter festziehen!
Die Absenkung von 21° auf 16° ist auch unrealistisch stark, da muss der
Motor viel drehen.
Es kühlt im Raum normal nicht bis auf 16° ab, bei täglicher Beheizung.
Es reicht von 21° auf 19° oder 18°.
Das Rondostat kann ja nur den Stift des Ventils reindrücken, rausziehen
kann es den nicht. Meistens hängt dieser Stift, nimm einfach ne große
Rohrzange packe diesen Stift und bewege in kräftig rein und raus. Auch
solltest du ihn mal über den Anschlag hinaus rausziehen, aber nicht ganz
raus sonst kommt dir das Wasser entgegen. Danach sollte es wieder gehen.
Ich habe das auch jedes Jahr in einem Zimmer wo die Heizung fast nie
läuft aber nach dieser Kur ist dieser Stift wieder leichtgängig und wird
durch die Federkraft wieder bis zu seinem Anschlag rausgedrückt.
Hallo Leute !
Ich habe seit ca. 5 Jahren ein HR20E im Einsatz. Mittlerweile sind die
Batteriekontakte so abgenutzt , oder was auch immmer, jedenfalls haben
sie einen sehr hohen Übergangswiederstand.
Da die 3V auch an der 10poligen Pfostenleiste anliegen, hab ich mir
gedacht die 3V durch externe Spannungsversorgung an das HR20E zu
bringen.
Meine Frage ist nun, funktioniert dies Problemfrei, hat jemand Erfahrung
damit. Liegen diese Anschlüsse direkt parallel zu den Batterien, wenn ja
dann spricht ja nichts dagegen. Aber ich weis auch nicht wie die
Beschaltung ist.
Währe schön wenn jemand Tipps diesbezüglich hätte.
MfG
Ralf
Hallo,
Ich wäre schon sehr an der Schaltung des V2 HR-20 interessiert,
da ich überlege meine V1 mit einem Mega649 aufzupeppen und ich nicht
allzu
inkompatiebel werden möchte.
wer was weiß bitte melden.
Sven
PS: weiß jemand wo die Eichwerte stehen ? Ich habe nach einem Reset
27°C
unkorrigierte Temperatur ( in wirklichkeit 21° bei Heizung aus)
Hallo,
@Rainer: das Temperaturproblem hatte ich auch schon öfter. Keine
Erklärung; zumal der Stift reindreht, damit es wärmer wird. Sollte er
hängen, müßte es warm bleiben, aber es wird manchmal trotz korrekter
Einstellung nicht wieder warm. Oder läuft das Ventil anders?!
@Alle: kann die neue Firmware ab Version 2.0x mehr als 4 Schaltzeiten
(2x an und 2x aus) ? Weiss das jemand.
Danke für einen Hinweis.
Gruß, Matthias
Also bei mir ist Stift "ganz raus" am wärmsten, wenn der Stift nicht
hängt. Ich mußte bei normalen Ventilen aber auch schon einige Stifte
gängig machen.
> @Alle: kann die neue Firmware ab Version 2.0x mehr als 4 Schaltzeiten> (2x an und 2x aus) ? Weiss das jemand.
Ist auch bei der neuen Version genau so (2x an, 2x aus)
Hat einer schon neue Infos über das Protokoll des HR20E 2.04
Ist er nun genauso fernsteuerbar wie wie der 1.xx
Das Ziel ist eigentlich mit einer Haussteuerung ihm die soll Temp
vorzugeben oder auf "off" zu stellen wenn ein Fenster offen steht
(Fensterkontakt).
Hat ihn schon mal jemand mit 3V von extern versorgt und erfahrungen
gemacht?
Hab bei Marktkauf heute Einzelgeräte gesehen die von einer Anderen Firma
(Aufdruck/Beiblatt) waren, Aussehen absolut identisch. Nur der
Dreierpack war Honeywell. ??????????
hallo zusammen,
ich habe ein problem mit meinem Honeywell Rondostat ( typ keine ahnung
möglich HR20 ) !
nach dem Battteriewechsel habe ich nur noch eine schaltzeit !? vorher
konnte ich zwei zeiten progammieren.
wie kann ich den Honeywell Rondostat zurück setzen, werkseinstellung ?
bin aber ein laie.
danke für die hilfe
hallo :-)
wer sucht der findet, manchmal :-)
hab es getestet und geht wunderbar freu
gruß jens
ich hab was gutes gefunden - DANKE an klimalex
http://www.klimalex.de/html/heizungsthermostat.html
Sonderfunktionen des Rondostat HR-20E (Nicht im Handbuch des
Heizungsthermostat enthalten)
Im Grundzustand des Gerätes die Taste „Prog“ 20 Sekunden gedrückt
halten, erst blinkt „1-7“,
dann die Jahreszahl, schließlich „01:01“. Damit ist das Menü für die
Sonderfunktionen erreicht.
Mit dem „+/-“-Drehrad werden die Werte in den einzelnen
Menüauswahloptionen geändert. Mit
der „Prog“-Taste werden die Einstellungen gespeichert und Sie gelangen
zum nächsten
Menüpunkt.
„01:01“ blinkt, Auswahlmöglichkeiten:
• „01:01“ = automatische Sommer- / Winterzeitumschaltung aktiv
• „01:00“ = keine Umschaltung
„02:01“ blinkt, Auswahlmöglichkeiten:
Hinweis: Bedeutung der Balkenanzeige.
• „02:00“ = keine Balkenanzeige
• „02:01“ = Gew. Raumtemperatur, Balken zeigen Schaltzeiten
• „02:02“ = Gew. Raumtemperatur, Balken zeigen Schaltzeiten und aktuelle
Uhrzeit
• „02:03“ = Gew. Raumtemperatur, Balken zeigen Ist-Temperatur (6 bis
24°C). Bei Temperaturen
über 24°C blinkt das letzte Segment.
• „02:04“ = Gew. Raumtemperatur, Balkensegment zeigt Position des
Ventils -> rechts =
geschlossen, links = voll geöffnet
„03:05“ blinkt, Auswahlmöglichkeiten:
Hinweis: Rückkehrzeit aus Fensterfunktion.
• „03:00“ = Fensterfunktion ausgeschaltet
• „03:05“ = Rückkehrzeit aus Fensterfunktion 05 * 6 minuten
„04:04“ blinkt, Auswahlmöglichkeiten:
Hinweis: Anzahl der Schaltzeiten pro Tag.
• „04:04“ = Maximal 4 Schaltzeiten pro Tag
• „04:02“ = Maximal 2 Schaltzeiten pro Tag
„05:00“ blinkt, Auswahlmöglichkeiten:
• „05:00“ = KEIN Hardware-Reset auf Werkseinstellung
• „05:01“ = Hardware-Reset auf Werkseinstellung
„08:30“ blinkt, Auswahlmöglichkeiten:
Hinweis: Ab 15°C aufwärts ist die Raumtemperatur nach unten korrigiert,
um
die erhöhte Raumtemperatur in Radiatornähe auszugleichen.
• „08:30“ = bei 28°C wird um 30 / 10 = 3°C vermindert, bei 20°C um etwa
1,15°C
• „08:00“ = keine Absenkung der Ist-Temperatur
„09:16“ blinkt, Auswahlmöglichkeiten:
• Vorgesehen für Regelparameter: Integrierzeit, nicht aktiv
„10:00“ blinkt, Auswahlmöglichkeiten:
• Vorgesehen für Regelparameter: P-Anteil, nicht aktiv
„11:50“ blinkt, Auswahlmöglichkeiten:
Hinweis: Korrektur des Schließpunktes nach der Adaption.
• „11:50“ = keine Änderung
• „11:00“ = 50 Optopulse Richtung „Auf“, entspricht 0,2mm oder
0,004mm/Digit
• „11:99“ = 49 Optopulse Richtung „Zu“, entspricht 0,2mm
Bei den neuen Versionen (2.04) scheint das alles anders zu sein. Das
Sondermenü geht nur noch bis 4 und die Funktionen darin sind auch
anders.
Hat evt. jemand die Funktionen für die neue Versionen herausgefunden?
mfg Frank
Cool, bin gerade erst hier drauf gestoßen. Hab auch die "alten"
Rondostat im Einsatz und war schon drauf und dran, mir diese
bidirektionalen Conrad Teile zu kaufen, um sie miteinander zu vernetzen.
Ich würd mir einen Controller dranbasteln, der über 433 MHZ von einem
Master-Controller gesteuert wird, wie bei dem Conrad System. Die
Übertragung sollte auch mit den Conrad Temperatursendern zusammenpassen.
Ob die Conrad Heizungsthermostate auch nach diesem Protokoll arbeiten
weiß ich allerdings nicht.
Bei den Wetterstationen sieht das Protokoll so aus:
0000 1010 0000 00100110 01110011 0111 0111 00111101 23.7°C
AAAA BBBB CCCC DDDDDDD EEEEEEEEE FFFFFGGGG Prüfsumme
AAAA: Sequenz zum Einpendeln des Empfängers
BBBB: Startsequenz
CCCC: Sensortyp (0000 für Temperatur, 1110 für rel. Luftfeuchte)
DDDDDDDD: Müßte die Sendernummer sein (wechselt nach RESET)
EEEEEEEE: (Zehner und Einer)+50 (vom Wert also noch 50 abziehen)
FFFF: Zehntelgrad
GGGG: scheint die Summe aller Nibbles zu sein = Prüfsumme
0000 10100000 11100111 01110101 10010111 01010000 25.9°C wurde auf Kanal
2 registriert
0000 10100000 11011111 01110101 10010111 01010111 25.9°C wurde Kanal 3
zugewiesen
0000 10101110 11011111 01000000 00000100 00001100 40%
0000 10101110 00000100 00110101 00000011 01011100 35%
0000 10101110 11011111 01000000 00000100 00001100 40%
also 4x Null, dann 5 Bytes. Oder 11 Nibbles.
Beim Hygrosensor ist die Sache recht einfach: Die Zahlen werden
BCD-codiert übertragen: Byte3 -> 0x40, die Zehnerstelle wird im unteren
Nibble von Byte4 nochmal wiederholt.
Das erste Nibble von Byte 5 scheint nochmal das zweite Nibble von Byte 3
zu sein.
Zum Timing der Übertragung: logische Null: Träger ein für ca. 1ms, dann
Träger aus für ca. 0,8ms.
logisch Eins: Träger ein für ca. 0,4ms, Träger aus für 0,8ms
sieht also so aus:
___-------______---______---______--------______
____| log. 0....... | log. 1.. | log. 1 ...| log. 0......... |
Vielleicht auch noch interessant:
http://www.cc2net.de/Foren/CC2Net_Forum/extindex.php?d_eintrag=8457
Ist gut wann kein Kabel vorhanden ist, bei mir soll aber möglichst viel
über Kabel laufen.
Ich habe Erfahrungen mit den HR 20 und dem über funk laufenden
Thermostaten von ELV/Conrad. Der HR 20 läuft erheblich besser und ist in
der Version 1 (leider wohl der 2er nicht) in die eigenentwickelte
Schaltung einbindbar.
Weiterer Nachteil ist das mit dem ELV Regler 2 Batteriesätze benötigt
werden, Tempfühler-Sender und Ventielsteller. Wenn ich am HR 20 ein
Kabel zum fernsteuern habe kommt auch die Versorgungsspannung mit
darüber.
OK, alles noch nicht fertig, aber wird hoffentlich mal...
Nur mal so ne Idee am Rande.
Wie wäre es denn wenn es ein Kit gäbe das den mechanischen Teil abdeckt.
Dann könnte jeder seine eigenen Vorstellungen verwirklichen. Gesucht
wäre also ein Adapter mit Motor etc.. Dann sind der Phantasie keine
Grenzen mehr gesetzt. Gibt es sowas vielleicht schon ?
Wer will kann dann den Kabel und Funkwellen freien Lauf lassen.
Ja, schon mal drüber nachgedacht. Aber...
Erstmal nichts gefunden und ausserdem müsste man die komplette
Temperaturregelung programmieren. Bei der HR 20 Version müsste nur die
gewünschte Temp vorgegeben werden.
For people looking for this topic, I have put together a page with my
project of controlling a HR-20E over RS-485 (using an AVR micro for
interfacing). Most of the information so far was found here (especially
from what Werner Cornelius has gathered), but I have managed to find a
few additional pieces (including how to switch between automatic and
manual mode).
Information is at http://symlink.dk/projects/rondo485/.
Servus erstmal,
zufällig bin ich mitarbeiter bei Honeywell und hatte schon so einiges zu
tun mit dem HR20 ... und werde es in zukunft auch noch ...
So und nu ist die Sache, ich wollt euch mal drauf hinweisen das es zwei
HR20 gibt! Einen mit Atmel und einen mit NEC Controller. Soweit ich mich
errinern kann ist bei den beiden auch die Pinbelgung der schnittstelle
unterschiedlich. Die mit NEC sind eigentlich die alten und sollten
garnicht mehr aufm Markt sein - aber eben nur eigentlich. Hab damit auch
schon böse erfahrungen gemacht weil die teile eben aus taiwan kommen.
greez kay
@kay
Das Du bei Honeywell mit den HR20 zu tun hast klingt ja erst mal ganz
vielversprechend für die HR20-Bastler...
Ich denke, das der überwiegende Teil der hier betrachteten HR20 im
Augenblick noch die mit dem NEC sind. Kannst Du uns evtl. bestätigen,
das unser "erlauschtes" Protokoll richtig ist? Oder gibt es evtl. sogar
eine offizielle Protokollbeschreibung inkl. Speicherbelegung.
Gruß
Uwe
Hallo zusammen, bin gerade am basteln mit dem Rondostat HR20E V 2.04.
Ich habe nach Anleitung ein Handydatenkabel genommen und mich mit dem
Rondostat über Hyperterminal verbunden allerdings kann ich nur vom
Rondostat gesendete Werte empfangen (alle 4 min und bei Sollwertänderung
sendet der Rondostat Datum, Uhrzeit, Ventilstellung, Ist- und
Solltemperatur) ich kann aber keine bestimmte Speicherstelle abfragen
oder überhaupt eine Abfrage starten, keiner der Befehle wird
beantwortet. Was habe ich beim verbinden falsch gemacht oder worauf muss
ich achten.......?
Die Idee ist es eigentlich die vom Rondostat gesendeten Daten per Funk
von allen Räumen zentral zu sammeln (Ventilstellung, Differenz Soll- und
Isttemperatur) hieraus eine ideale Vorlauftemperatur zu berechnen und
die Leistung der Therme zu steuern um somit den größtmöglichen
Wirkungsgrad der Terme zu erreichen.
Gruß Bitjäger
@ Frank vom 15.02.2007:
Bei der neuen Version 2.04 habe ich bis jetzt 2 Sondermenüfunktionen
gefunden:
02:01 Display zeigt Soll-Ventilöffnung in %
02:02 Display zeigt Ist-Temperatur
Für weitere wäre ich jederzeit dankbar!
Hallo zusammen, ich versuche gerade mit dem Rondostat HR20E V 2.04 über
die RS232-Schnittstelle zu kommunizieren. Über einen MAX3232 habe ich
mir eine Pegelanpassung gebaut. Die Datenübertragung via Terminal
funktioniert bestens, leider geht der HR20E nach ca. 90s ohne
Datenkommunikation in den Ruhezustand. Mit welchem Befehl kann ich die
Datenabfrage wieder aktivieren ? Wer hat hier Erfahrung ?
Gruß R.L.
Hallo :-)
ich bin nun auch ein stolzer Besitzer von den Teilen ( HR20E).
Softwareversion 2.04 !
Weiß schon jemand mehr über die Sonderfunktionen.
Die Funktion 02:02 finde ich klasse ( Ist Temperatur Anzeige).
Im Standard war die Funktion 01:00 eingestellt.Was bedeutet dies ?
Sommer/Winterzeitumstellung aus ??
Gruß
Lothar
Hallo Forumteilnehmer,
Brauche Tips für Fehlersuche an HR20.
Seit Jahren habe habe mehrere HR20, einer davon ist jetzt irgendwie
defekt.
Bis vor kurzem hat er problemlos funktioniert!
Es wird der Fehlercode “ E 1 “ angezeigt, stehend für “keine Adaption
möglich”.
Folgende Probleme kann ich AUSSCHLIESSEN:
= Batterien (bereits mehrfach neue eingesetzt) ; keine Akkus.
= Befestigung am Adapter Heizkörper: Durch Tausch mit anderem Gerär
ermittelt: Es liegt am Kopf des speziellen HR20.
= Mechanische Blockade, “Hänger” des Ventilstifts (drehbar, wird heiss
während “AdAP”).
= Vollständiger Defekt (“AdAP” läuft bei Abnahme und Aufstecken).
Es ist ein älteres Gerät, welches bei Abnahme und Wiederaufstecken
“AdAP” durchführt, ein komplettes öffnen und wieder schliessen. Das
funktioniert.
Während “AdAP” kommt wird Heizköper auch kurz heiss.
Das Ventil wird nach “AdAP” komplett geschlossen und verbleibt zu; es
bleibt “kalt”.
Ein Drehen auf höhere Temperatur führt nach kurzer Zeit wieder zu
Fehlercode “ E 1 “, ohne daß Bewegung erfolgt. Bleibt weiter kalt.
Hat jemand eine Idee oder ist es einfach “kaputt” ?
Was kann ich noch probieren ?
Dann läute ich mal das Projekt unter dem Arbeitstitel: "Pimp my
Rondostat"
ein.
Ich werde mich noch dieses Wochenende weiter um den Schaltplan kümmern.
Habe danach vor mir eine Entwicklungsumgebung aufzubauen, also ein
mechanischer Aufbau wo nichts rumbaumelt und mit dem man vernünftig
entwickeln kann.
Dazu werde ich:
- die Kabel vom Motor verlängern, damit ich messen kann,
wie die Originalsoftware den ansteuert
- irgendeine Mechanik basteln, um den Anschlag des Ventils zu
simulieren
- Einen Adapter von meinem Jatag an das Board löten.
Wenn ich soweit bin, gibt es wieder Bilder dazu.
Man sieht schon: Hardwaremäßig habe ich keine Probleme, auch die
theoretischen Grundlagen der Regelungstechnik sind weniger ein Problem.
Hilfe brauche ich beim Programmieren selber, besonders bei so Sachen
wie:
- Stromsparen
- genaue Uhrzeit
- Menuesteuerung
- Kommunuikation
habe ich kaum Erfahrung und tue mich noch richtig schwehr.
Das wird dann nicht mehr so schnell gehen, wie die Hardwareentwicklung.
Als erstes werde ich mich an die Ansteuerung des LCD machen, das ist ja
noch sehr hardwarenah, ich hoffe das ich die LCD-Routinen vom Butterfly
als Basis verwenden kann.
Dario
Hallo :-)
@Dario
tolle Arbeit. Hört sich sehr interessant an.
Kann der mega169 ohne weiteres neu programmiert werden? Ich überlege
gerade den Controller zu entlöten und einen neuen mega169 draufzusetzen.
Dann kann der ursprüngliche Controller ggf. auch wieder verwendet
werden.
Über ISP wird es bestimmt auch gehen, denn MOSI MISO und SCK liegen
an den drei Tasten an und sollten daher mit dem ISP Prommer nicht
kollidieren, man muss dann nur ein entsprechendes Kabel anlöten.
Den Controller zu auszulöten und gegen eine neuen mega169 zu ersetzen
würde ich nicht machen, für 30 Euro kann man sich ja so ein Teil kaufen.
Da lohnt fast die Arbeit nicht und der Mega kostet auch noch mal 4 Euro.
Außerdem ist es ein zusätzlicher Grund das Projekt fertig zu machen,
wenn man nicht mehr zurück kann. Das einzige Argument was gilt, ist
dass man am Originalprogramm eventuell später nochmal was messen will.
Dann würde das eventuell Sinn machen, aber ich werde vorher alles
messen, was es zu messen gibt und dann einfach den Atmel löschen.
Dario
Der Aufwand für den Controller wechseln ist mit dem richtigen Equipment
maximal 5 Minuten. Werd das in der Arbeit machen. Nur muss ich mir noch
einen HR20E zulegen. Hab nur einen alten mit Software-Version 1.x. Wo
bekommt man den HR20E mit Software-Version 2.04 günstig?
So den Schaltplan habe ich fertig, die Adressen der Bilder sind die
alten.
Jetzt mache ich mich an den Probeaufbau.
Das Kabel vom Motor habe ich verlängert, dann habe ich noch 10 Signale
abgegriffen und nach außen geführt. Mal sehen, ob es so funktioniert
wie ich will. Muss noch den JTAG Adapter löten und eine Halterung
für die Batterieen machen, dann bin ich soweit. Bilder gibt es dann
auch.
Jetzt mal die Programmierer an die Front. Wer will was programmieren?
@filzlaus:
> Wo bekommt man den HR20E mit Software-Version 2.04 günstig?
Bei Conrad für 34,95, ab 3 Stück nur noch 29,95.
Ach so, eventuell kann jemand mal was zum Schaltplan sagen.
Folgende Fragen habe ich:
Sehe ich das richtig, dass mit PB4 und PB7 die Richtung gewählt wird in
die der Motor drehen muss?
Wozu dient PG4?
Was macht IC2? Ich finde das nirgends.
Es es hat den SMD Code: 312h. Scheint die Versorgungsspannung zu regeln
und die Spannung für die Reflex-Lichtschranke, oder sehe ich das falsch?
Dario
Hat jemand den Adaptionsvorgang genauer verstanden?
Anscheinend wird zuerst das Ventil ganz geöffnet bis zum Anschlag (keine
Impulse von der Lichtschranke mehr/funktioniert auch wenn der Motor von
Hand angehalten wird). Dann wird die Richtung des Motors geändert. Ab
einer bestimmten Stellung wird die Drehzahl erniedrigt??? Wird jetzt der
Motor angehalten, dann wird dies als Stellung-> Ventil-Zu erkannt???
Ich werd demnächst mal die Impulse bis zur Verringerung der Drehzahl
ermitteln und sehen ob die Anzahl konstant ist.
Hi !
Bezüglich der Motorsteuerung habe ich rausgefunden wie es geht. Ist
tricky. Als PDF habe ich mal die Ersatzschaltbilder angehängt, je
nachdem ob der Motor vorwärts oder rückwärts läuft.
Hier schnell als Text erklärt:
Alle Pins die mit dem AVRverbunden sind, sind Ausgänge (also PG4, PB4,
PG3, PB7)!!
1. Motor läuft vorwärts: Motor Plus an 3,3V, Motor Minus an Masse (GND)
PG4, PB7 = 0 (sind somit GND)
PB4, PG3 = 1 (sind 3,3V )
Dadurch ergibt sich, daß T3 sich im OFF Zustand befindet und weggelassen
werden kann, T2 hat dadurch keinen Basisstrom und kann ebenfalls
weggelassen werden. T6 ist ebenfalls OFF, dadurch hat T7 keinen
Basisstrom und kann auch weggelassen werden.
Übrig bleiben die leitenden Transistoren T5,T8 und der Treibertransistor
T4 für T5. Der Strom fließt somit von 3.3V durch T5 - Motor - T8 nach
Masse.
Wie für den rückwäts laufenden Motor geht kann sich jeder selbst
herleiten oder ins PDF schauen.
Die BAV99 habe ich weggelassen, da diese Dioden lediglich die
Spitzenspannung kurzschließen, die immer dann entsteht, wenn man den
Motor ausschaltet.
Grüße
Dirk
Hallo DE(Gast)!
Gute Erklärung, aber:
Die H-Brücke würde doch auch arbeiten wenn die 4 AVR-Ports
direkt an T7,T5,T8 und T2 hängen, oder?
Wenn dem so ist, wozu dann T3, T4 und T6?
Grüße, Bernd
Hi !
Ganz einfach, der Strom der AVR Ports ist nicht groß genug um die
Treiber direkt anzusteuern, deshalb hat man jedem "Endstufentransistor"
einen Treiber vorgeschaltet. Ganz klar ist mir die "Denke" vom
Analogentwickler allerdings nicht, betrachtet man z.B. den
eingeschalteten T5, so fließt dessen Basisstrom zwar über den Treiber T4
und PB4 ist entlastet, jedoch muss der ganze Strom über PG4 nach Masse
abfließen, hier hat man wohl nicht zuende gedacht. Genau wie T8 sowieso
direkt vom AVR ohne Treiber angesteuert wird. Vielleicht habe ich auch
noch einen Kniff übersehen, bin für jeden Tipp dankbar. Bzgl. der
Funktion bin ich mir aber sicher, daß es so funktioniert wie im PDF
beschrieben.
Grüße
Dirk
P.S.: Die Nummerierung der Pins von IC2 ist falsch. Der Punkt ist Pin1.
Solage man aber nicht weiss was das Teil macht ist es eh Wurst. Sicher
ist, daß es ein Spannungsregler ist, vielleicht mit einem
Schaltausgang??
Dann will ich mal meinen Senf dazu geben.
Fangen wir an mit der linken Seite: Die Ausgänge vom AVR sind PB7 und
PG3.
Die können vier Zustände haben mit folgendem Ergebnis:
1
PB7 PG3 T6 T7 T8 linker Motoranschluss
2
0 0 sperrt sperrt sperrt kein Potential
3
0 1 sperrt sperrt leitet GND
4
1 0 leitet leitet sperrt +UB
5
1 1 sperrt sperrt leitet GND
Wir sehen, die Schaltung verhindert dass beide Transistoren T7 und T8
gleichzeitig leiten. Wenn der AVR einen Fehler hat und aus Versehen
beide Ausgänge auf High schaltet passiert so nix.
Jetzt die rechte Seite: Die Ausgänge vom AVR sind PG4 und PB4.
Die können auch vier Zustände haben:
1
PB4 PG4 T4 T3 T5 T2 recher Motoranschluss
2
0 0 sperrt sperrt sperrt sperrt kein Potential
3
0 1 sperrt leitet sperrt leitet GND
4
1 0 leitet sperrt leitet sperrt +UB
5
1 1 sperrt sperrt sperrt sperrt kein Potential
Wir sehen, auch diese Schaltung verhindert dass beide Transistoren
T5 und T2 gleichzeitig leiten. Aber um die Polarität der Motorklemme
umzuschalten braucht man nur ein Bit zu kippen.
Die Drehrichtung des Motors ist also wie folgt
1
PB4 PB7 PG3 PG4
2
0 1 0 1 Richtung 1
3
1 0 1 0 Richtung 2
4
1 1 1 0 Richtung 2
5
Minimaler Stromverbrauch bei
6
0 0 0 0
7
1 0 0 1
8
alles andere keine Funktion am Motor.
(Achtung Reihenfolge der Ports neu sortiert)
Was ich nicht verstehe, ist warum die beiden Seiten nicht gleich
aufgebaut sind.
Ich sehe auch nicht, wie man eine der beiden Klemmen auf eine
andere Spannng als GND oder 3,3Volt legen kann um so die
beschriebene Geschwindigkeitsänderung zu realisieren.
Dario.
Geschwindigkeitsänderung liese sich durchaus mit einer PWM realisieren,
PB4 ist ein OutputCapture vom Timer0, damit könnte Timer0 als PWM
Generator laufen.
Hi !
Interessant wäre noch, warum hängt der Motortreiber an der geregelten
Versorgung?
IC2 könnte ein Spannungsregler mit AUX Schaltausgang sein, damit könnte
dann die LED in der Lichtschranke geschaltet werden, allerdings ist mit
der Doppeldiodenkonstrukt am Regler unklar. Genauso könnte IC2 ein
Spannungsregler mit Bypass-Switch sein, so könnte man die Schaltung
incl. Motor an die ungeregelte Spn. hängen um die Drehzahl zu ändern.
Wie man dann die LED schaltet bliebe offen. PWM scheint mir aber
wahrscheinlicher, vielleicht kann man das mal nachmessen.
Fraglich ist sowieso warum der Motortreiber an der geregelten Spannung
hängt, macht verlusttechnisch keinen Sinn. Ob der Treiber dann
funktionieren würde habe ich jetzt nicht geprüft.
Dabei fällt mir auf, daß im Schematics ein Fehler sein müsste, die
Spannung hinter dem Regler kann unmöglich auf 3,3V designt sein.
Entweder ist es dann kein Regler oder Du hast Dich vertan. Bei 2 Zellen
ist man in der Regel sofort unterhalb der Dropout Spannung sein, was
bedeuten würde, daß die Regelung flach fällt.
Grüße
Dirk
P.S.: Die Aufnahme der Schaltung ist eine super Arbeit!
> Geschwindigkeitsänderung liese sich durchaus mit einer PWM realisieren,> PB4 ist ein OutputCapture vom Timer0, damit könnte Timer0 als PWM> Generator laufen.
Wird die Geschwindigkeit des Motors tatsächlich geregelt? Ich habe eher
den Eindruck, dass der nur deshalb etwas langsamer wird, weil beim
Zudrehen am Ende mehr Kraft notwendig ist.
Hi,
DE wrote:
> Interessant wäre noch, warum hängt der Motortreiber an der geregelten> Versorgung?
Wenn Du das Dir das Photo mal ansiehst, dann siehst Du einen 0 Ohm
wiederstand Südlich von IC2, der dient nicht als Brücke, weil da nix
drunter läuft, kann sein, dass das vorher mal anders geplant war.
> IC2 könnte ...
Wie kann man das denn rauskriegen, auch ob R8 wirklich ein Widerstand
ist würde ich gerne wissen, der Code ist X1B.
> Dabei fällt mir auf, daß im Schematics ein Fehler sein müsste, die> Spannung hinter dem Regler kann unmöglich auf 3,3V designt sein.
Ich habe da einfach mal 3,3V drangeschrieben, es ist die geregelte
Spannung nach IC2, gemessen habe ich die noch nicht.
> P.S.: Die Aufnahme der Schaltung ist eine super Arbeit!
Danke
Fertig.
So ich habe das Development Board fertig.
http://www.carluccio.de/img/hr20/devboard.jpg
Ich habe die einzelnen Leitungen aus dem HR20 heraus geführt und an
Stiftleisten angelötet, so kann ich die messen, während der HR20
arbeitet.
Im einzelnen sind das:
1
1 - PF2 - NTC In
2
2 - PF3 - NCT Out
3
4
3 - PE3 - Reflex OUT
5
4 - PE4 - Reflex IN
6
7
5 - PB5 - Impulsrad
8
6 - PB6 - Impulsrad
9
10
7 - PB7 - Motor L1
11
8 - PG4 - Motor L2
12
9 - PG4 - Motor R1
13
10 - PB4 - Motor R2
14
15
11 - GND
16
12 - GND
Zusätzlich noch einen Jumper mit dem ich die Stellung des Kontaktes
einstellen kann, der anzeigt, ob der HR20 aufgesteckt ist.
Eine Halterung für 2 Mignons fehlt mir noch, der zweite Jumper dient
als Ein-/Ausschalter.
Das JTAG habe ich auch verbunden, dazu eine Frage:
Ich habe TDI, TMS, TDO und TCK sowie VCC und GND verbunden.
Reicht das?
Wozu braucht man VREF, NSRST und NTRST?
Der Motor sowie der Reflexsensor sind verlängert, den kann ich jetzt
mit der Hand anhalten.
Oszi und Logicanalyser sind auch schon geliehen, bald kann ich mit
dem Messen beginnen, dann später hier mehr.
So jetzt muss ich schnell schlafen, morgen muss ich um 4:00 raus :-(
Bye
Dario
Hi !
> Wozu braucht man VREF, NSRST und NTRST?
VREF "sagt" dem ICE, daß der AVR in Betrieb ist, muss also gegen
Versorgung verbunden werden. Gilt im Wesentlichen für den original Atmel
JTAG ICE, ob es andere Emulatoren auswerten ist mir nicht bekannt. Ich
würde es verbinden, schaden tut es auf keinen Fall.
nSRST kann (muss nicht) mit der RESET Leitung des AVR verwunden werden.
nTRST wird nicht verwendet.
> Wenn Du das Dir das Photo mal ansiehst, dann siehst Du einen 0 Ohm> Widerstand südlich von IC2, der dient nicht als Brücke, weil da nix> drunter läuft, kann sein, dass das vorher mal anders geplant war.
Links neben den besagten 0 Ohm sind 2 freie Pads für ein Bauelement,
wenn man dort 0 Ohm bestücken würde und die anderen 0 Ohm weglässt wäre
der Motortreiber direkt mit der Batterie verbunden. Igendwas haben sie
anscheinend schon gedacht, immerhin war es mal vorgesehen.
Grüße
Dirk
Hi !
Nochmal ich...
> Wie kann man das denn rauskriegen, auch ob R8 wirklich ein Widerstand> ist würde ich gerne wissen, der Code ist X1B.
Mal angenommen es heisst nicht X1B sondern 81X, dann wäre es nach
folgeder Tabelle:
http://www.marsport.org.uk/smd/res.htm
Ein 68.1Ohm Widerstand.
Grüße
Dirk
Hallo,
ich verfolge die Diskussion gespannt. Kann mir jemand sagen, ob es
möglich ist, die Version des Rondostat von außen zu erkennen? Zum
Basteln hätte ich nömlich gerne die Version mit dem Atmel-Chip ;-)
Schönen Dank,
-Mathias
> Wird die Geschwindigkeit des Motors tatsächlich geregelt? Ich habe eher> den Eindruck, dass der nur deshalb etwas langsamer wird, weil beim> Zudrehen am Ende mehr Kraft notwendig ist.
Die Geschwindigkeit wird tatsächlich verringert. Nimmt man den HR20E vom
Heizkörper ab und drückt mit der Hand den Kontakt, der angibt ob der
Hr20E aufgesteckt ist, dann kann man das ohne Widerstand vom
Thermostatkopf ausprobieren.
Heizungssteuerung HR20
Ich mal wieder.
So die Messungen sind fertig und ich kann folgendes berichten:
Motoransteuerung:
Der Motor wird über eine PWM mit PB4/OC0A angesteuert.
Die Periodenlänge ist 64µs.
Soll es wärmer werden, dann sind PG3, PG4 und PB7 alle HIGH und das
Verhältnis ist 18µs Puls zu 46µs Pause.
Soll es kälter werden, dann sind PG3, PG4 und PB7 alle LOW und das
Verhältnis ist 46µs Puls zu 18µs Pause. Ich verstehe nicht, wieso PB7
LOW ist, das müsste meines Erachtens HIGH sein, es sei denn T6 wäre ein
PNP Transistor, aber laut SMD-Code ist es ein NPN. Hat jemand eine Idee?
http://www.carluccio.de/img/hr20/la_motor_mach_heiss.pnghttp://www.carluccio.de/img/hr20/la_motor_mach_kalt.pnghttp://www.carluccio.de/img/hr20/schaltplan.png
Drehzahlmesser:
Der Drehzahlmesser wird eingeschaltet indem PE3 HIGH gesetzt wird.
Wenn der Motor bei dem beschriebenen Verhältnis frei dreht, dann erzeugt
die Reflexlichtschranke ca. alle 59ms einen Impuls von 14ms länge. Wenn
ich den Motor von Hand bremse, dann schaltet er 620ms nach dem letzten
Impuls ab.
http://www.carluccio.de/img/hr20/la_reflex_lichtschranke.pnghttp://www.carluccio.de/img/hr20/la_reflex_bremse.png
Motorboost:
Den beschriebenen Boost des Motors wenn die Last größer wird, kann ich
nicht bestätigen. Das Verhältnis der PWM bleibt bei mir immer konstant.
Es ist natürlich denkbar, dass sich das verändert, wenn die Batterien
nachlassen, aber woher weiß der Atmel über den Batteriestand Bescheid?
Temperaturmessung:
Die Temperatur wird alle 500ms gemessen. Dazu wird der Ausgang PF3 HIGH
geschaltet und zwar alle 500ms dreimal. Zuerst für die Dauer von ca.
117µs, nach einer Pause von ca. 920 µs, noch einmal für ca. 170µs und
nach weiteren 51µs ein letztes mal für 120µs. Warum das so ist weiß ich
nicht.
http://www.carluccio.de/img/hr20/la_temp_event.pnghttp://www.carluccio.de/img/hr20/la_temp_intervall.png
Impulsgeber:
Das Rag zum Einstellen der Temperatur und zum Programmieren hängt an
einem Impulsgeber, welcher an die Pins PB5 und PB6 angeschlossen ist.
Die Messung hat ergeben, dass sich je Rastposition am Drehrad sich der
Zustand beider Leitungen ändert. Je nach Drehrichtung und altem Zustand
ändert er sich mal bei PB5 zuerst und mal bei PB6 zuerst:
Alter Zustand 00, Neuer Zustand 11: wenn PB5 zuerst HIGH schaltet, dann
geht es Richtung Minus, schaltet PB6 zuerst HIGH, dann geht es nach
Plus.
Alter Zustand 11, Neuer Zustand 00: wenn PB6 zuerst LOW schaltet, dann
geht es Richtung Minus, schaltet PB5 zuerst LOW, dann geht es nach Plus.
Schalten nicht beide um, dann hat man nicht über einen Klick gedreht,
oder es sind Störungen, die kommen wenn sich der Motor dreht.
Der Abstand zwischen den beiden Schaltvorgängen hängt von der
Geschwindigheit ab, mit der man am Rad dreht. Bai Maximalgeschwindigkeit
konnte ich einen Abstand von 799µs messen (Dabei habe ich alle 2ms einen
Klick erzeugt). Dreht man ganz langsam am Rad, dann ist der Abstand bei
ca. 30ms, das gilt für einen Klick alle 2 Sekunden.
http://www.carluccio.de/img/hr20/la_impulse_ab_langsam.pnghttp://www.carluccio.de/img/hr20/la_impulse_ab_mittel.pnghttp://www.carluccio.de/img/hr20/la_impulse_ab_schnell.pnghttp://www.carluccio.de/img/hr20/la_impulse_auf_langsam.pnghttp://www.carluccio.de/img/hr20/la_impulse_auf_mittel.pnghttp://www.carluccio.de/img/hr20/la_impulse_auf_schnell.pnghttp://www.carluccio.de/img/hr20/la_impulse_stoehrungen.png
So das war's erstmal für heute.
Hallo,
sehr schön das sich hier wieder einiges zum HR20E tut, und das dann auch
gleich mit so viel elan.
Wollt ihr die Tempregelung beim HR20E belassen und ihm nur den
gewünschten Temp-Wert über einen externen µC übermitteln?
Wir haben bei unserem Projekt einer Haussteuerung die alte Version des
HR20E eingebunden, nur der ist ja nicht mehr zu bekommen (ausser
gebraucht mit unbekannten Zustand). Da ich nicht genug von den HR20E
habe ist das natürlich schlecht. Das Einstellrad ist vom dem Neuen auch
besser.
Habt ihr schon die Spannungsversorgung über extern versucht
(Erfahrungen)?
Gruß
Jan
Hi David
> Wollt ihr die Tempregelung beim HR20E belassen und ihm nur den> gewünschten Temp-Wert über einen externen µC übermitteln?
Ja, bis auf die Tatsache, dass man dazu den HR20 komplett neu
programmieren muss. Dann könnte man aber auf der seriellen
Schnittstelle genau das selbe Protokoll implementieren, wie es
bei den alten HR20 war, so könntest Du Deine alte Steuerung
weiter verwenden.
> Habt ihr schon die Spannungsversorgung über extern versucht> (Erfahrungen)?
Klar, da die Batterieklemmen direkt mit den Pins 9 und 10 des
Steckers verbunden sind ist das auch kein Problem.
Grüße
Dario
Nochmal Ich,
ich schrieb:
> Ich verstehe nicht, wieso PB7 LOW ist, das müsste meines Erachtens> HIGH sein, es sei denn T6 wäre ein PNP Transistor, aber laut SMD-Code> ist es ein NPN. Hat jemand eine Idee?
Nach langem Zweifeln an meiner Schaltung habe ich festgestellt, dass
ich PG3 falsch angelötet habe, ich habe den nicht an die Emitter von
T6 angeschlossen, sondern an die Basen von T3 und T4 und somit über
R4 an PB4, werde die Messungen demnächst wiederholen.
BTW: Hat jemand Ahnung von der LC Ansteuerung? Kann ich das einfach so
probieren, oder gibt es da auch Signale, die ich messen sollte. Beim
Überfliegen des Datenblattes vom Mega169 habe ich gesehen, dass man
da echt viel einstellen kann. Oder ist das trivial?
Dario
Das hört sich ja alles sehr sehr gut an.
Wenn das klappt mit dem umprogrammieren des AVR, wäre das echt klasse.
Dann müsste ich mir 6 Stück davon besorgen.
Wenn noch genug Platz wäre, könnte ich gleich noch meinen Steuerbus
einbauen, externen RS485 Wandler ran und fertig :-)
Dann werde ich mich mal umsehen nach einem Ort wo ich die herbekomme und
vorher testen kann ob die den auch Version v2 sind.
Wirklich Super Arbeit bisher !
Lassen die Dinger sich leicht und zerstörungsfrei öffnen ?
Gruss
Juergen
Das Öffnen ist kein Problem.
Einfach mit dem blauen Stellrad anfangen - mit mehreren Schraubenziehern
(Schraubendrehern ;-) ) nach vorn weghebeln.
Der Rest ergibt sich...
Gruß
Jan
Guten Morgen,
es geht mir auch um den Rondostat HR20E, von dem wir seit einem Jahr 3
Stück im Einsatz haben. Jetzt wollte ich die Programmierung
tagindividuell vornehmen. Es sollte eigentlich eine einfache Sache sein,
aber woher weiß daß Programm denn, welches Datum zu welchem Wochentag
paßt?
Meine Fragestellung ist also auf deutlich geringerem technischen Niveau
als in diesem Forum an den Tag gelegt wird, aber vielleicht kann mir
dennoch jemand helfen. Wäre schön und Dank im Voraus!
WolfgangSLP
Stimmt so nicht, denn in der Bedienungsanleitung ist angegeben, daß nach
dem Einlegen der Batterien Datum und Zeit eingegeben werden kann und
auch korrigierbar ist. Das funktioniert so ja auch, aber ich kann keinen
Weg erkennen, Wochentag und Datum in Übereinstimmung zu bringen. Also,
woher weiß daß Teil, daß der 06.01.2008 ein Sonntag, also Tag 7, ist und
die Heizung dann auch so steuert? Ist noch immer rätselhaft.
Gruß
Wird wohl in der Programmierung abgelegt sein. Dein PC weis ja auch den
Wochentag wenn nur das Datum eingegeben wird. Der Videorekorder auch -
die Telefonanlage, die Heizung, der Radiowecker, die Digital Kamera...
Ja, dafür gibt es eine ziemlich einfache Berechnung (Zellers Kongruenz):
Die Formel, um einen Wochentag im Gregorianischer Kalender zu einem
gegebenen Datum zu ermitteln lautet:
Jh := Jahrhundert
(die ersten beiden Stellen der Gesamt-Jahreszahl)
J := Jahreszahl innerhalb des Jahrhunderts
(die letzten beiden Stellen der Gesamt-Jahreszahl)
M := Monat
Die Monate Januar und Februar werden als 13. bzw. 14. Monat des
Vorjahres betrachtet. Das Jahr J ist dann auch um Eins zu reduzieren.
T := Tag
Wt := Wochentag
( 1 := Sonntag, 2 := Montag, 3 := Dienstag, 4 := Mittwoch, 5 :=
Donnerstag, 6 := Freitag, 0 := Samstag )
Möchte man, wie heutzutage üblich, dass die Woche mit dem Montag
beginnt, so muss man einfach Eins von der Formel subtrahieren.
Siehe auch hier:
http://de.wikipedia.org/wiki/Zellers_Kongruenz
Bin ja mal gespannt, ob das wirklich dieser ist, den es bei Lidl gibt...
Ich habe mir inzwischen so ein Teil gekauft, nachdem ich im Netz ein
wenig dazu gelesen habe. Fernziel ist natürlich die Ansteuerung per
AVR/ARM/whatever. Bis dahin wollte ich erstmal die Ist-Temperatur und
den Ventilstatus angezeigt haben.
Unter http://www.klimalex.de/html/heizungsthermostat.html habe ich eine
Liste von Sonderfunktionen gefunden und das erstmal ausprobiert. Leider
verhält sich mein Rondostat doch etwas anders. Zuerst kommt nicht
"01:01", sondern "01:00". Naja, egal... Aber die Einstellung "02:04" hat
keinen Effekt, es wird weiterhin die Programmierung angezeigt. Nichts
von Ist-Temperatur.
Habe ich evtl. eine etwas ältliche Firmware erwischt? Die Kurzanleitung
hat die Markierung "HR-20E-OM-L//0//2005-01-26". Kann jemand etwas damit
anfangen? Würde natürlich gerne einen Satz halbwegs aktueller
Thermostate haben, vielleicht sind ja die bei Lidl dazu die "richtigen"
:)
Grüsse aus Dresden, Torsten
Hat jemand schon die Hardware des HR40 mit der des HR20 verglichen? Ich
wollte mich eher mit der Vernetzung von HR40 per RS485 beschäftigen (ist
bestellt, noch nicht da), dass nach spärlichen Informationen aus dem
Netz wohl zumindest in aktuellen Hardwareversionen auch mit einem
ATmega169 ausgestattet ist. Grund: um Fachhandel eher und hoffentlich
langfristiger verfügbar (aber etwas teurer). Wäre natürlich prima, wenn
der Code dann auch halbwegs problemlos auf die beiden Modelle
übertragbar wäre.
Hallo Torsten,
bei meinem HR-20 wird mit "02:04" auch keine Ist-Temperatur angezeigt!
Ich habe aber auch die Software 2.04 (wird nach dem Einlegen der
Batterie angezeigt). Bei diesem Software-Stand wir die Ist-Temp. über
"02:02" (als Zahlenwert) angezeigt, und die Ventilstellung über "02:01".
Es gibt also mindestens zwei unterschiedliche Software-Stände, bei denen
die Parameter eben auch unterschiedliche sind. Bei mir gibt es nur die
Parameter 01, 02 und 03.
Siehe auch: http://www.haustechnikdialog.de/forum.asp?thema=941
Gruß Markus
@filzlaus,
hab 3 der Burg Twister beim Lidl erstanden. Das steckt ein Atmel 169PV
drin. Der kann maximal mit 8MHz getaktet werden und kommt mit minimal
1.8V Spannung aus (allerdings bei sehr viel niedrigerem Takt, hier wohl
32kHz?). Der Stromverbrauch ist beim PV Typ auch geringer als bei den
anderen Varianten. Platine scheint zwar überarbeitet worden zu sein,
aber bisher konnte ich noch keinen Unterschied zum HR20E ausmachen.
Bild von der platien habe ich hochgeladen und kann hier:
http://img407.imageshack.us/img407/3056/burgtwisterplatinest3.jpg
bestaunt werden (hat 1,5MB und ist mit einer Fuji F30 aufgenommen). Die
Rückseite der Platine habe ich gespiegelt, damit man leichter den Bahn-
und Kontaktverlauf von Oben mit Unten vergleichen kann.
Nach dem Einlegen der Batterie wird 2.04 angezeigt. Hat sich also beim
SW Stand nix geändert.
Hab auch noch einen Thermotronic:
Leiterplatte sieht so aus:
http://img407.imageshack.us/img407/8021/thermotronicplatinekl2.jpg
Schaltbild gibt es hier:
https://www.mikrocontroller.net/attachment/29357/schematic.png
@Dario C.: Bin sehr daran interssiert die Thermostaten selber steuern zu
können. Hab bei der letzten Renovierung einen Haufen an Kabel verlegt
und würde gerne irgendwannmal die Thermostaten zentral einstellen
können, in der Endausbaustufe sogar vom Internet aus. Gibt es schon eine
Art Arbeitsgruppe? Hab mal Fernsehtechniker gelernt, E-Technik studiert
und früher schon mal Micropcontroller programmiert. Schreib aber schon
seit 18Jahren GUIs und hab leider mit Controllern und Hardware nicht
mehr soviel am Hut. Mit dem Atmel kenne ich mich nicht besonders aus,
müsste mich da erst reinarbeiten. Weiss nicht wie weit Du das Teil
kennst. Wäre es denkbar ins RAM ein kleines Stück Code per JTAG zu
injizieren, den PC darauf zu stellen, mit dem Code das Flash auszulesen
und per Schnittstelle nach draussen zu führen?
Oder wäre es möglich nicht das ganze Flash zu löschen, in den freien
Bereich ebensolchen Code reinzubrennen und den Inhalt auszulesen. Das
ganze könnte man dann mit einem zweiten Atmel in einem anderen
Speicherblock durchziehen, erhält dann die fehlende Lücke aus dem ersten
Auslesen, setzt das ganze zusammen und macht nur noch die nötigen
Anpassungen statt alles neu zu schreiben.
Das neu Schreiben ist verdammt viel Arbeit, bis man sich das ganze Know
How dazu erarbeitet hat. Das ist kein Hexenwerk aber es macht echt
Arbeit, denn ganz so Trivial ist die Aufgabe nicht, wenn man sie gut
lösen will. 16k Speicher scheint mir auch nicht allzuviel zu sein.
Könnte es sein, dass IC2 (312V) nicht die Spannung stabilisiert sondern
neben der Spezialaufgabe die Reflexlichtschranke anzusteuern, je nach
Betriebsmodus die Spannung für den Atmel runter schaltet, um Strom zu
sparen? Wenn am Ausgang 3,3V anliegen, dürfte das auf Augenhöhe mit der
Batteriespannung sein. D.h. es würde keine Spannung vorgehalten, um
etwas ausregeln zu können.
Falls man irgendwo mitmachen kann, bitte melden.
Gruß
Karim
>Wäre es denkbar ins RAM ein kleines Stück Code per JTAG zu>injizieren, den PC darauf zu stellen, mit dem Code das Flash auszulesen>und per Schnittstelle nach draussen zu führen?
Bei der Kontroller Architektur des AVR's ist es nicht möglich Programm
Code aus dem RAM auszuführen.
@filzlaus,
Du kannst es bei einer anderen Filiale probieren oder an einem anderen
Tag nochmal. Einige der Thermostaten werden wieder zurückgegeben.
Ansonsten gibt es bei ebay auch ein reichhaltiges Angebot zu
vergleichbaren Preisen.
@Michael, danke für die Info. Vermutlich wird es nicht gehen, den Code
auszulesen. Man könnte noch bei Honeywell anfragen, ob über die
Schnittstelle Einstellungen möglich sind aber die werden die
wahrscheinlich nicht bekannt geben, selbst wenn was geht.
Hab etwas rumgelesen. Es kann schon mal vorkommen, dass ein Lock Bit
nicht richtig gesetzt wird. Dazu müsste man aber jedemenge von den AVRs
durchchecken, ist also nicht praktikabel. Dann gibt es scheints noch
Firmen, die sich darauf spezialisert haben mit unkonventionellen
Methoden den Inhalt auszulesen, in dem Sie den Chip freilegen und mit
einem Laser die Lock Bits umstellen oder bestrahlen. Ist hier aber auch
nicht praktikabel, da wahrscheinlich zu teuer.
Wenn man den AVR selber programmiert, hat das den Vorteil, dass man
dabei soviel Know How ansammelt, dass man gut für andere Anwendungen
einsetzen kann und davon gibt es beliebig viele.
Gruß
Karim
Hab nochmal über IC2 nachgegrübelt. Pin 3 und 2 dienen
höchstwahrscheinlich dem Verpolschutz für falsch eingelegte Batterien,
der hoffentlich etwas intelligenter ausgelegt ist als der vom
Thermotronic Modul, dass dazu einfach eine Diode (D2) verwendet, um eine
falsch gepolte Batteriespannung satt kurtzzuschlissen.
Zum R8 hat DE schon ganz richtig geschrieben, dass nicht X1B drauf steht
sondern 81X, was einem Widerstand von 68,1 Ohm entspricht. Habs aber
noch nicht nachgemessen, da ich den Thermostaten dazu zerlegen muss.
Werds aber bei der nächsten Gelegenheit nachholen.
Zu der Mimik an Pin 5 und 6 kann ich nur mutmassen, dass D1 mit R8 eine
konstantstromquelle für die Reflexlichtschranke (Sendediode) bilden,
über PE3 die Spannng an Pin 6 nach oben "floatet" und die Funkion
einschaltet (Pin 5 und 6 würden dann intern "zusammengelegt" und über R8
fliesst ein konstanter Strom, da die Diode D1 die Spannung auf 1,2V
begrenzt ...). Genaueres könnte man sagen, wenn man die interne
Beschaltung von IC2 kennt. Wird aber vermutlich kein Standardchip,
sondern spzielle für Honeywell hergestellter sein.
Vielleicht weiss jemand, welcher Hersteller seine Chips mit diesen
runden Kreisen kennzeichnet die hier
http://img407.imageshack.us/img407/3056/burgtwisterplatinest3.jpg
(achtung, 1.5MB) auf dem 312V (ganz rechts im Bild, mittlere Höhe) zu
erkennen sind.
Ich habe einen Rondostat (alte Version).
Der nach dem Anlegen der Stromversorgung und nach der Referenzfahrt.
Den Frostschutz aktiviert. Obwohl laut Software(RondoSet) die
Raumtemperatur bei 24,95°C liegt.
Weis jemand ob die einen extra Sensor auf der Platine haben wo für den
Frostschutz zuständig ist?
Hi zusammen
@ Karim L. (louk)
> steckt ein Atmel 169PV drin.
Das ist auch der einzige echte Unterschied, den ich entdecke zwischen
Deiner und meiner Platine, ich habe nämlich "nur" einen Atmel 169V.
Ansonsten meine ich beide Platinen sind identisch.
> Der kann maximal mit 8MHz getaktet werden und kommt mit minimal 1.8V> Spannung aus (allerdings bei sehr viel niedrigerem Takt, hier wohl> 32kHz?).
Ne, der läuft mit ziemlicher Sicherheit auf 1MHz mit dem internen RC
Oszillator. Der 32kHz Quarz ist der Uhrenquarz.
> Bin sehr daran interssiert die Thermostaten selber steuern zukönnen.> Hab bei der letzten Renovierung einen Haufen an Kabel verlegt und> würde gerne irgendwannmal die Thermostaten zentral einstellen> können, in der Endausbaustufe sogar vom Internet aus.
Viele Kabel habe ich auch verlegt, CAT5 neben jede Steckdose, aber die
Heizkörper habe ich vergessen, ich Idiot. Aber das ist kein Problem,
in der nähe der Heizkörper findet man immer auch Steckdosen :-)
Das Endziel ist bei allen sicherlich das selbe: Zentrale Steuerung
aller Thermostaten, mit der Möglichkeit diese mit anderen System zu
verbinden (Haussteuerung, Web-Server, etc.)
> Gibt es schon eine Art Arbeitsgruppe?
Noch nicht.
Ich könnte sogar einen Raum anbieten in dem man sich treffen könnte,
wenn sich eine Arbeitsgruppe im Ruhrgebiet finden würde:
www.das-labor.org
> Hab mal Fernsehtechniker gelernt,
ich Kommunikationselektroniker (bei Nixdorf Computer AG)
> E-Technik studiert
ich auch (in Bochum)
> Schreib aber schon seit 18Jahren GUIs und hab leider mit Controllern> und Hardware nicht mehr soviel am Hut.
Auch das brauchen wir später, sei es um die Teile mit dem Internet
oder einem PC zu verbinden. Ich würde gerne alles per CAN steuern.
> Mit dem Atmel kenne ich mich nicht besonders aus,
da kann ich helfen.
> Weiss nicht wie weit Du das Teil kennst.
Technisch sehr gut, aber ich bin nicht so der erfahrene
C-Programmierer, ich kann Verschlüsselungs-Algorithmen schnell machen
auf den Teilen...
> Wäre es denkbar ins RAM ein kleines Stück Code per JTAG zu> injizieren,
Nein, da AVR eine Harvard Architektur ist, aber das hat ja Michael
Wolf (mictronics) schon beantwortet.
> Flash auszulesen [...] nur noch die nötigen Anpassungen statt alles> neu zu schreiben.
Geht nicht, kann man jemanden im Osten mit beauftragen: Kosten so um
die 20-100k€. Ausserdem ist die Soft doch nicht so toll und ich würde
sie besser machen. (Mehr Debug infos, etc.) Auslesen der Ist
Temperatur über Interface, etc.
Und so viel ist das auch nicht, oder?
> Das neu Schreiben ist verdammt viel Arbeit, bis man sich das ganze> Know How dazu erarbeitet hat. Das ist kein Hexenwerk aber es macht> echt Arbeit, denn ganz so Trivial ist die Aufgabe nicht, wenn man> sie gut lösen will. 16k Speicher scheint mir auch nicht allzuviel zu> sein.
Ich schätze dass man mit unter 4k hinkommt. Das Theoretische Know-How
habe ich. Was mir fehlt ist die Erfahrung das alles in C zu
programmieren. Was kommt in eine ISR, wie nutzt man die Zeitbasis und
den Sleep-Modus, etc.
Und ich würde auch das Interface noch verschlüsseln, oder einen
Boot-Loader implementieren. Dann könnte man den über RS232, bzw. CAN
neu flashen.
> Könnte es sein, dass IC2 (312V) nicht die Spannung stabilisiert> sondern neben der Spezialaufgabe die Reflexlichtschranke> anzusteuern, je nach Betriebsmodus die Spannung für den Atmel runter> schaltet, um Strom zu sparen?
Mir ist eine ganz andere Idee gekommen. Was ist wenn in IC2 einfach
nur zwei Mosfets oder Transistoren drin sind. So wie die BAV99 Dioden
(Aufdruck: A7W) Ist das denkbar?
> Falls man irgendwo mitmachen kann, bitte melden.
Ich.
> Wenn man den AVR selber programmiert, hat das den Vorteil, dass man> dabei soviel Know How ansammelt, dass man gut für andere Anwendungen> einsetzen kann und davon gibt es beliebig viele.
Dafür.
Also ich wäre dabei. Habe jetzt drei Wochen Urlaub und wollte mich mal
darum kümmern. Habe nur leider noch viele andere Projekte, daher kann
ich nix garantieren.
Wer macht mit?
Dario
Hallo Dario,
> Ne, der läuft mit ziemlicher Sicherheit auf 1MHz mit dem internen RC> Oszillator. Der 32kHz Quarz ist der Uhrenquarz.
Könnte sein aber bei 32kHz währe der Stromverbrauch am niedrigsten und
die Speed müsste für diese Anwendung noch ausreichen. Eng könnte es aber
bei der Bedienung der COM bei 9600 Baud werden.
> Aber das ist kein Problem,> in der nähe der Heizkörper findet man immer auch Steckdosen :-)> Das Endziel ist bei allen sicherlich das selbe: Zentrale Steuerung> aller Thermostaten, mit der Möglichkeit diese mit anderen System zu> verbinden (Haussteuerung, Web-Server, etc.)
Bei mir liegen an jedem Heizkörper eine 8 Draht- und 4 Drahtleitung.
Wenn ich es nochmal zutun hätte, hätte ich statt der 8 Drahtleitung ein
CAT5 rumgelegt, die die Option auf Netzwerk eröffnet hätte. Mal schauen.
In jedem Raum liegt auf jedenfall auch noch ein Netzwerkanschluss.
>> Gibt es schon eine Art Arbeitsgruppe?> Noch nicht.> Ich könnte sogar einen Raum anbieten in dem man sich treffen könnte,> wenn sich eine Arbeitsgruppe im Ruhrgebiet finden würde:> www.das-labor.org
Das Labor wäre sehr Ideal für den Austausch, leider wohne ich in BW, ist
also etwas weit zum hinfahren. Falls es aber zu einer fruchtbaren
Zusammenarbeit kommt, kann ich mal hochdüsen. Bin alle ca. 8 Wochen eh
in der Eifel. Von da aus geht es halbwegs.
> Auch das brauchen wir später, sei es um die Teile mit dem Internet> oder einem PC zu verbinden. Ich würde gerne alles per CAN steuern.
Liebäugle da eher mit I²C Bus und vorerst wird es dann COM werden. Die
Interfaces kann man später noch aufbohren.
>> Weiss nicht wie weit Du das Teil kennst.> Technisch sehr gut, aber ich bin nicht so der erfahrene> C-Programmierer, ich kann Verschlüsselungs-Algorithmen schnell machen> auf den Teilen...
Sieht so aus, als könnte wir uns gut ergänzen. Hab früher viel in C
programmiert, danach C++, JAVA und jetzt C#, allerdings nicht
hardwarenah. Aber das bekommen wir schon hin.
> Ausserdem ist die Soft doch nicht so toll und ich würde> sie besser machen. (Mehr Debug infos, etc.) Auslesen der Ist> Temperatur über Interface, etc.
Das ist das schöne daran, wenn man es selber macht. Man hat alle
Freiheitsgrade für eine individuelle Lösung die mehr kann.
> Ich schätze dass man mit unter 4k hinkommt. Das Theoretische Know-How> habe ich. Was mir fehlt ist die Erfahrung das alles in C zu> programmieren. Was kommt in eine ISR, wie nutzt man die Zeitbasis und> den Sleep-Modus, etc.
Was den Speicher angeht, bin ich da andere Dimensionen gewohnt. Ein
printf und 60k sind weg wie nix ;-). In eine ISR kommt natürlich
möglichst wenig rein. Beachten muss man die Priorisierung des Interrupts
und ob der reentrent sein muss/darf und welche Register noch frei sind.
Es gibt zyklich ablaufende Timer, die Routinen aufrufen und eine Aufgabe
abarbeiten. Lösungen müssten sich aus anderen Projekten oder Beispiele
herleiten lassen. Was den Sleep Modus angeht, muss man sich einfach im
Detail das Datenblatt durchlesen. Die RTC und die Displayansteuerung
laufen jedefalls weiter. Möglicherweise geht es den Sleepmode im Wechsel
permanent einzusetzen und den Stromverbrauch weiter abzusenken.
> Und ich würde auch das Interface noch verschlüsseln, oder einen> Boot-Loader implementieren. Dann könnte man den über RS232, bzw. CAN> neu flashen.
Yep, einen Bootloader sollten wir möglichst früh haben. Die Daten auf
der Schnittstelle zu verschlüsseln, halte ich auch für eine gute Idee.
> Mir ist eine ganz andere Idee gekommen. Was ist wenn in IC2 einfach> nur zwei Mosfets oder Transistoren drin sind. So wie die BAV99 Dioden> (Aufdruck: A7W) Ist das denkbar?
Den gedanken hatte ich auch schon. Funktion wäre dann Verpolschutz und
eventuell Stromkonstanter für die IR Diode der Reflexlichtschranke. Ist
aber auch egal, wenn man das Teil als Black Box betrachtet.
Die SW sollte so vorgesehen werden, dass man damit auch den Thermotronic
bedienen kann.
> Wer macht mit?>> Dario
Also dann wären wir schon mal zwei.
Gruß
Karim
Bestimmt mögen alle mithelfen die von hier nach oben schon einmal
aufgetaucht sind, nur fehlt oft das Wissen. Es sind bestimmt auch sehr
viele nur leser die hier immer wieder nachschauen.
Wenn ich aus dem Verlauf erkennen kann das ich was beitragen kann melde
ich mich auf jeden Fall. Leider wird es nicht sehr viel sein :-((
Schön ist auch wenn die die wirklich interesse haben sich hier
regestrieren und dadurch auch mal anmailbar sind. Das macht auch mal das
Aufwecken oder Nachfragen möglich wenn der jenige länger nicht da war.
Ich glaube ich hatte schon mal gefragt, aber ist dann wieder die eigene
Tempregelung des HR-20 integriert wenn ihr soweit wie geplant seit? Oder
gebt ihr ihm immer die Ventielöffnung vor?
Mein Ziel war es ja nur den Sollwert zu übertragen und den Rest macht er
selber.
Dadurch zentrale Bedienung/ perfekte Fenster auf-zu Funktion / beliebige
Schaltzeiten.
Bis jetzt alles nur (bis jetzt) mit der alten Version machbar :-(
@Jan David,
aus meiner Sicht müssen die Module weiterhin so funktionieren wie
bisher, also völlig autark. Über die Schnittstelle sollte das komplette
Programm vorgebbar sein (also Tages- und Wochenprogramm, Man/Auto-Mode,
Temperatur usw.). Darüber hinaus hätte ich gerne z.B. für die Zonen
unterschiedliche Einschalttemperaturen, weil ich es morgens nicht so
warm brauche wie abends. Ein Datenlogger wäre schön. Weiss nicht ob die
Module sich automatisch an die Raum- und Heizungsparameter adaptieren
(wie lange vorher muss man Einschalten, um die gewünschte Temperatur zu
einer Zeit zu erhalten und wie früh muss man abregeln, damit man eine
kleine Hysterese erhält).
1) Hilfe werden wir auf jedenfall beim Testen brauchen (diverse
Heizkörper typen mit unterschiedlichem Ventilhub, unterschiedliche
Heizkörpergrößen und Räume). Die Helfer sollten einen Thermostaten haben
und so lange wie es keinen Bootloader gibt einen ISP zum flashen. Später
einen PC mit RS-232 und ein passendes Kabel. Ein Kollege von mir hat
Interesse an der Platform für andere Zwecke, will aber einen Bootloader
schreiben, den wir dann nehmen können.
2) Für @filzlaus und andere Entwickler die mitmachen wollen, gibt es
auch reichlich zutun. Weiss nicht, wie es mit der Real Time Clock
bestellt ist. Falls die nicht inteligent ist (so auf den ersten Blick
ins Datenblatt gibt es Timer aber garkeine richtige RTC), könnte sich
einer darum kümmer, die Tagesanzahl im Monat zu ermitteln, die
Schaltjahre zu berechnen und die Sommer/Winterzeit umstellung
durchzuführen.
3) Dann wird ein Algorithmus für einen PID Regler gebraucht.
4) Eine Verschlüsselung für die Remotedaten des Interfaces (wichtig z.B.
für die, die eine Funkschnittstelle einsetzen wollen, Abhör- und
Manipuliersicher). Ein Konzept für die Adressierung der Module, wenn sie
parallel hängen (I²C Bus, Ethernet). Da wäre es z.B. gut, wenn sich
jemand mit den etablierten Standards auskennt und etwas vorschlagen
kann.
5) Eine Tastenentprellung.
6) Ein Pulszähler mit Richtungserkennung für das Drehrad.
7) Routine zum Ansteurn des Display mit Blinkoption.
8) Routine die Motor vor oder zurückdreht (langsam, schnell,
asymptotisch, geräuschoptimiert), bis eine vorgegebene Pulszahl von der
Reflexlichtschranke erreicht ist aber Stopp, wenn keine Pulse mehr
kommen (Anschlag erreicht), status melden: Zielposition konnte erreicht
werden oder nicht als Rückgabewert.
9) Routine zum Anfahren des Anschlagpunktes nach Aufsetzen des Moduls.
10) Setzen einer sinnvollen Schwelle für die Brown-Out Detection.
11) Temperatur ermitteln mit verrechung von Abgleichdaten. Dazu müsste
mal jemand mit einem Refenzthermometer die Kurve Temperatur über die
Spannung ermitteln und mit ein paar Module vergleichen, um zusehen, wie
weit die Streuung liegt, ob die Kurven nur einen Offeset haben und z.B.
nur ein Abgleichpunkt von nöten ist oder ob man ganz ohne auskommt, weil
die sich alle gleich verhalten. Wie genau ist die Referenzspannung?
Brauchen wir zum genauen Auslesen den ADC Noise Reduction Mode?
12) Wie können wir für die batteriebetriebenen Geräte die Sleep Modes so
einsetzen, dass der Batteriewechselintervall möglichst lange ist.
13) Routinen zum Bedienen von Schnittstellen (In/Out,
(AUTO?)Konfigurtaion)
14) Konzept zur Fehlerbehandlung.
15) Sammeln von statistischen Parameter wie Betriebsstundenzahl, aktive
Zeit für Motoreinsatz, wie oft lag Störung vor und was einem sonst noch
so einfällt.
16) Wir brauchen eine Ideensammlung. Wir werden sicher zuerst mal ganz
einfach anfangen und das nötigste Realisieren aber je früher man weiss,
was eventuell noch alles kommen kann, desto eher kann man die SW so
schreiben, dass man sich nix verbaut.
17) Erfahrene Entwickler die nicht direkt mitwirken wollen, könnten als
Ansprechpartner zur Verfügung stehen um Details zu klären.
Ansonsten ist jede helfende Hand willkommen.
Das ist jetzt mal ein Anfang für Aufgaben die abzuarbeiten sind. Weitere
Ideen und Anregungen bitte hier mitteilen oder mir zumailen.
Wer für den 169 oder die vergleichbaren Atmels schon etwas geschrieben
hat, was thematisch passt (z.B. Bootloader, RS-232 bedienen, Temperatur
erfassen...) kann das zum Recyclen hier vorstellen.
Gruß
Karim
Hallo Dario,
hätte mir viel vom Geschreibsel sparen können währende Du
zwischenzeitlich Dein Post abgesetzt hast sehe ich gerade. Da haben wir
auf jedenfall eine ähnlich Vorstellung was gebraucht wird. Für heute
lockt aber nur noch das Bett.
Gruß
Karim
ALso....
könnte die Tastaturentprelllung (incl erkennung ob lange gedrückt oder
mehrere Tasten auf einmal), denke auch die encoder ansteuerung.
Sowie einen bootloader mit AES verschlüsselung beitragen.
habe allerdings momentan nur alte rondostate, bräuchte erstmals ein
neues.
ich persönlich würde die Thermostate gerne per ZigBee Funkmodul
ansteuern. Dieses würde ich dann ebenfalls versuchen modular
beizutragen.
könnte auch ggf. etwas zum pid regler beitragen.
Es wäre super wenn wir ein subversion repository hätten für die
Versionsverwaltung, sowie ggf. ein Bugzilla für die Bugreports, nen wiki
haben wir ja schon.
Falls ich das nicht überlesen habe müssten wir uns noch auf eine
Entwicklungsumgebung bzw Compiler einigen.
Ich würde vorschlagen die aktuelle WinAVR version (20071221) zu
benutzen, also sprich GCC 4.2.2 sowie avr-libc 1.6.0.
Hallo Ralf,
das geht ja schon gut los. Finde ich klasse. Im weiteren Ausbau ein
Funkmodul mit zu integrieren ist super. Hätte da auch noch Ideen für
abgesetzte Anwendungen dafür mit weiteren Aufbauten, wobei da
wahrscheinlich ein Tiny für reicht. Das wäre ein Aussentemperaturmesser
und Abgesetzter im Raum, zur optmierung der Heizunssteuerung und ein
Fenster-/Balkontür offen Sensor wer es genauer wissen will. Falls es
sinnvoll wäre die Luftfeuchte (wegen gefühlter Temperatur) mit in den
Regelalgorithmus aufzunehmen, würde auch das gehen. Es gibt von Dallas
Sensoren die beides drin haben und seriell abfragbar sind. Dann hat man
als Abfallprodukt schon fast eine Wetterstation dabei. Aber um solche
Kleinigkeiten kümmern wir uns später.
Falls Du den Bootloader schon fertig hast, könnte man den ja schon
gleich bereit stellen. Am besten das HEX File und den Code an Dario
senden, damit er es im Wiki verlinken kann.
Was die Entwicklungsumgebung angeht, brauchen wir auf jedenfall eine
Referenzplattform, die den Stand dann 100%ig erzeugen kann. Was spricht
gegen das AVR Studio 4? Da hat man doch alles zusammen (Code Editor mit
Syntax Coloring und Online Hilfe, Debugger, Programmer...). Was würde
für Dein Vorschlag sprechen?
Hab im Wiki einen Abschnitt Entwicklungsumgebung hinzugefügt. Da sollten
die Erfahrenen unter uns (bin da unbedarft), was vorgeben.
Was könnten wir als JTAG ICE verwenden? Ein AVR Dragon ist günstig zu
bekommen und beherrscht auch Debug Wire um die kleinren Prozessoren
Debuggen zu können. Die Beschränkung auf 30kByte Flash ist da glaube ich
nicht so tragisch. Und man kann das Teil über USB ansteuern, mein
Notebook hat nämlich keine RS-232 mehr.
Thermostaten gibt es bei ebay genug (siehe z.B.
http://heimwerker.search-desc.ebay.de/burg-twister-HR-20E_Installation_W0QQ_trksidZm37QQcatrefZC12QQcoactionZcompareQQcoentrypageZsearchQQcopagenumZ1QQdfspZ32QQfromZR10QQftrtZ1QQftrvZ1QQftsZ2QQga10244Z10425QQsabfmtsZ1QQsacatZ30565QQsaobfmtsZinsifQQsaprchiZQQsaprcloZQQsatitleZQ28burgQ20twisterQ2cQ20HRQ2d20EQ29)
und oft günstiger wie im Handel.
Hab Deine Anregungen ins Wiki eingepflegt. Kannst das aber auch
überarbeiten oder etwas hinzufügen.
Dank an Dario für das Anlegen des Wiki. So, muss jetzt weg.
Gruß
Karim
wenn du mit AVRStudio in C Entwickel willst "brauchst" du winavr.
AVRStudio beinhaltet nur den assembler nicht den compiler.
Das Funkmodul welches ich meine ist von meshnetics. Das geniale daran
ist das dort auch ein avr drauf werkelt ;-)
http://www.meshnetics.com/zigbee-modules/
habe hier zwei ZDM-A1281-A2 zum evaluieren. (kosten glaube ich 18euro
netto)
Debug werkzeug kann denke ich jeder selbst wählen was er bevorzugt, da
das nichts mit dem sourcecode zu tun hat.
Bootloader habe ich fertig für nen mega162 werde das morgen mal
versuchen anzupassen. Einziger nachteil ist das dieser mit iar
entwickelt wurde, mal sehen ob ich den umgebaut bekomme.
Karim L. schrieb --->
1) Hilfe werden wir auf jedenfall beim Testen brauchen (diverse
Heizkörper typen mit unterschiedlichem Ventilhub, unterschiedliche
Heizkörpergrößen und Räume). Die Helfer sollten einen Thermostaten
haben
und so lange wie es keinen Bootloader gibt einen ISP zum flashen.
Später
einen PC mit RS-232 und ein passendes Kabel. Ein Kollege von mir hat
Interesse an der Platform für andere Zwecke, will aber einen Bootloader
schreiben, den wir dann nehmen können.
Hallo Karim,
habe bei mir 2 oder 3 der neuen im Einsatz. Wede bei bedarf 2 zum Tasten
bereitstellen. Müssten uns dann nur genauer über das wie unterhalten,
bin aber zu allem bereit wenn sie zum Test an meienem Heizkörper hängen
werden (sonst wirds mit der Zeit einfach zu heiß in den beiden Räumen
;-)
Ihr sagt mir wie programmieren und ich bekomme es dann bestimmt auch hin
(Notebook MIT RS-232)
Meintest Du mehr als Nacht und Tagtemp schon am HR-20 direkt
programmierbar? Tolle Idee, beschäftige mich schon länger damit, aber
die Idee hatte ich noch garnicht!
Gruß
Jan
Hallo Jan,
yep, zumindest mehr als nur eine Tag Temperatur. Es geht sogar noch
ausgefeilter. Wenn ich abends Heim kommen, hätte ich gere ein gewisses
Temperaturniveau. Da ich aber noch in Aktion bin (z.B. Haushalt
erledigen), bin ich noch in Bewegung und brauch es nicht ganz so warm.
Später, wenns ans lümmeln auf der Coach geht, dürfte die Temperatur
höher sein. Da wäre es gut wenn die Temperatur entlang einer Rampe
hochgefahren wird.
Dann könnte ichmir noch vor stellen, wenn man einen Feuchtesensor
einbaut, dass es ganz neue Applikationen ermöglicht für Räume die
feuchter sind. Typischerweise ein Bad oder Küche wo viel gekocht wird.
In beiden Fällen könnte man dazu beitragen, dass sich die
Schimmelbildungsgefahr mindert, wenn man die Temperatur entsprechend
anpasst. Aber sowas kommt wohl erst in Phase 3 oder 4. Zunächst muss
erst mal dass programmiert werden, was das Teil schon kann.
Es ist aber trotzdem gut, jetzt schon eine Vision zu entwickeln, um den
Weg im Design dafür offenzuhalten. Wem also noch etwas einfällt, der
möge es kundtun.
Gruß
Karim
Nur so als Idee: Als Einstieg ist vielleicht die GCC-Portierung der
Butterfly-Firmware nützlich, da geht es ja auch um den Mega169,
Sparsamkeit, LCD-Ansteuerung.
Ahoi, Martin (interessiert)
@Karim L.
Nette Idee, dabei muss natürlich das Regelverhalten so genau sein das
Deine Änderungen im Verlauf nicht kleiner sind als die Schwankungen des
Regelverhaltens.
Und wenn das hinhaut sollte der Raum in der, vermutlich kurzen Zeit,
auch die Temperatur zu bringen sein.
Zum Regelverhalten:
Ich hab die ELV Wetterstation mit den Funkinnensensoren in den Räumen.
Die Daten wurden, bis zum Einzug ins neue Haus auch von dem Datenlogger
aufgezeichnet und dann in den PC übertragen. Dort konnte man dann schön
das Regelverhalten per Kurve sehen. Es war ein Pendeln ähnlich soner
Elkoladekurve. Durchs neue Haus nur leider sehr viel anderes um die
Ohren und daher nicht wieder so in betrieb. Ich werd mal versuchen sone
Kurve wieder zu finden um auch die Tempdiffenrenz der Kurve zu haben.
Die Kurve konnte man vor allem, oder fast nur, nachts ausmachen - kein
Lüften, keine Sonne, kein Kamin... , also HR-20 und der Raum ganz
allein!
@Ralf,
danke für den Hinnweis. Mit dem AVR Studion kann man leider keinen
C-Code erstellen bzw. debuggen. Schade eigentlich.
@Martin,
da der 169 für mich neuland ist, sind Beispiele immer gut zum
Reinkommen. Was ist das denn für eine Firmware für den Tiny?
Weiss Du, ob es für die Atmels ein Micro Realtime OS gibt? Müsste nicht
viel können.
Nachrichten über Queues verschicken, an Que Penden, Tasksuspend,
Taskswitcher, Sleep, Interrupt- und Eventhandling und eine Systemtime
anbieten. Damit würde sich viel eleganter Programmieren lassen. Ohne
wird es stellenweise ziemlich krampfig die Abläufe zu Programmieren.
@Jan,
im idealfall ist das Programm so ausgelegt, dass es an die Verhältnisse
(Raum- und Heizkörpergröße, Vorlauftemperatur) nach ein paar Lernzyklen
automatisch adaptiert, um die Hysterese klein zu halten. Eine Rampe so
wie ich es beschrieben habe ist wahrscheinlich übertrieben. Zwei
zusätzliche Temperaturwerte erfüllen da auch ihren Zweck.
Die Wetterstation mit der Fähigkeit zum Loggen ist ideal um das
Regelverhalten zu testen, so lange wie diese Log-Funktion nicht
integriert ist. Da der Temperaturesensor im Modul steckt und das
eigentlich nicht so ideal ist, kann man parallel mit Deinem abgesetzten
Temperaturfühler einen anderen Platz im Raum mit loggen und dann
vergleichen. Vielleicht lässt sich daraus ein Optmierungspotential
ableiten. Das könnte im einfachsten Fall ein einstellbarer Offset für
die Temperatur sein.
Gruß
Karim
Hi Karim
> Mit dem AVR Studion kann man leider keinen C-Code erstellen bzw.> debuggen.
Natürlich kann man das, sogar schon seit über zwei Jahren.
Auch Eclipse kann das im übrigen. Aber damit es keine Probleme gibt
schlage ich vor einen Makefile zu schreiben, den kann man nutzen oder
nicht. Beim AVR-Studio kann man den sogar einbnden, dann nutzt das den.
Und unter Linux braucht man auch nur das makefile. Finde ich die beste
Lösung.
> da der 169 für mich neuland ist, sind Beispiele immer gut
Auf dem Butterfly Modul befindet sich auch ein ATmega 196. Dazu gibt
es von Atmel eine Beispielanwendung die der Martin Thomas mal in GCC
portiert hat. Der hat auch einen Datalogger programmiert, die ich hie
im Einsatz habe.
Butterfly: http://www.mikrocontroller.net/articles/AVR_Butterfly
Logger: http://www.siwawi.arubi.uni-kl.de/avr_projects/bf_logger> Weiss Du, ob es für die Atmels ein Micro Realtime OS gibt?
Gibt es, sogar OpenSource: AVRX
Einige bei uns im Labor, dort gibt es auch ein SVN was man browsen und
auschecken kann, z.B. das Projekt TorControl
AVRX: http://www.barello.net/avrx
Labor: http://www.das-labor.orghttps://rl.das-labor.org/trac/browser/microcontroller-2/LaborAccess/TorControl> Müsste nicht viel können.
Schau es Dir mal an.
Dario
Hallo Dario,
danke für die Hinnweise.
Hab das AvrX in der Mittagspause etwas überflogen. Da ist eine
Beispielapplikation bei, um eine COM Schnittstelle zu benutzen. So wie
es ausschaut, kann ich das auch für den Mega8 einsetzen, wofür ich ein
Evalboard habe. Wenn ich dazu komme, versuche ich mich am Wochenende
daran. Am Samstag muss ich aber leider bei einem Umzug helfen, mal
schauen, ob ich es ans laufen bekomme.
Gruß
Karim
Hallo Karim
> AvrX
Ich meine, dass man das auch ohne hinbekommen sollte.
Ich glaube das man mehr Probleme mit OS hat also ohne.
So richtig Realtim brauchen wir nicht.
Ich wüsste auch nichts was kritisch wäre.
Die Uhr im IRQ, die Serielle auch.
Wenn der Motor eine Position anfährt oder kallibriert,
kann die Applikation ruhig hängen bleiben.
Oder?
Einer wollte doch per Funk?
Hab da mal überlegt das ich doch irgendwas gelesen habe und heute ist es
mir wieder eingefallen das es in ner Elektor war. Hab sie auch gefunden.
Hier mal die Überschrift:
"Funkzwerge
iDwaRF - netzwerkfähige WirelessUSB-Funkmodule
iDwaRF kombiniert einen Cypress-WirelessUSB-Transciver mit einem
Atmel-AVR zu einem netzwerkfähigen 2,4-GHz-Funkmodul und bietet den
Vorteil einer kostenlosen Protokollsoftware mit freier
Entwicklungsumgebung."
Ist in der Elektor 3/2007 und ist ein ATmega168-20MI drauf.
Hoffe es hilft...
@Jan, danke für die Info. Wir kommen dann gegebenenfalls darauf zurück,
wenn es soweit ist. Im Moment müssen wird das Teil aber erst mal
tragfähig aufsetzen.
@Dario, sagen wirs mal so, es wird nicht gerade einfacher am Anfang,
wenn man ein RTOS anwenden muss, dass man nicht mal kennt und ohnehin
noch nie eines konfiguriert hat. Und wenn die Jungs die AvrX geschrieben
haben, irgendwo doch noch geschlampt haben, kann man sich einen Wolf
nach dem Fehler suchen. Trotzdem hat ein RTOS eindeutig vorzüge, weil
der eigene Code leichter zu verstehen, zu erstellen und zu warten ist.
Und man kann Tasks parallel laufen haben (z.B. Debug Task, Display Task,
Menü Task, Motor Stelltask, Regel Task). Während der Motor verstellt
wird, kann weiter bedient werden. Oder während im Menühandler auf eine
Eingabe gewartet wird, kann debugged werden oder ein Log abgezogen
werden. Das System bleibt flüssig. Hab mal für das Menü C-Code up from
scrath uncompiliert als Beispiel erstellt, wie das prinzipiell aussehen
könnte. Ist zuviel geworden um es hier zu posten, der Thead ist eh schon
zu lange (oder gibt es hier im Forum eine Aufklapp-/Zuklapp- Möglichket
für Codepastes). Werds Dir per Email zuschicken. Da wo die pend_key_que
aufgerufen werden, könnte man auch eine Funktion einsetzen, die darauf
wartet, das die Keyboard ISR einen neuen Keyevent in einer globalen
Variable oder Register abliefert. Dann ginge es auch ohne RTOS.
Irgendetwas während der Wartezeit anstoßen kann man dann aber nur noch
über ISRs und die sollten schnell durchlaufen.
Wenn mal irgendwo eine Schleife hängt, kann man nicht eine Task
abschiessen und neu starten. Wenn man die SW wie im Beispiel aufbaut,
liesse sich ein RTOS auch noch nachträglich relativ einfach einsetzen.
Durch die lange gedrückten Tasten oder mehrfachtasten, kommt man nicht
alleine mit dem Interrupt der Taste aus. Wir brauchen noch einen Timer,
der nachschaut, ob die Taste immer noch gedrückt ist. Zudem wird ein
Keycode Event beim drücken und beim loslassen, sowie bei mittel lang und
lang gedrückter Taste benötigt. Das HR20E kann dazu noch die
Drehradpulse verarbeiten. Das nur am Rande. Da ist ein wenig knobeln
angesagt.
Gruß
Karim
Hi krzysin,
hab das Modul (Burg Twister) mal per RS-232 (9600 Baud, 8 Data Bits, No
Parity, 1 Stop Bit) über ein Hyperterminal angeschlossen.
Nach dem Einlegen der Batterie wird folgendes ausgegeben:
HR20 SW Version 204 vom 08. Mar. 2006 12:00 HW Version 2
Wenn man die Soll Temperatur ändert oder die Regelung den Motor
nachstellt, liefert das Modul z.B. folgenden String zurück:
D: 27.1.2008 U: 10:36 V: 0 I: 1985 S: 1550
Dabei ist
D: Datum DD.MM.YYYY
U: Uhrzeit HH:MM
V: Ventilposition
I: Ist Temperatur in °C x100
S: Soll Temperatur °C x100
Man sieht an den Abkürzungen, dass diese SW wahrscheinlich aus
Deutschland stammt.
Wie Du sehen kannst, weichen einige Abkürzungen in der Bedeutung von
denen, die Du im Wiki angegeben hast ab.
Wenn man eine Taste drückt, wird der zugehörige Keykode gesendet:
Prog Taste: K: 0b10
Temp Taste: K: 0b1
Auto Taste: K: 0b100
Beim Drücken mehrerer Tasten, erscheint die Kombination aus obigen
Werten (Beispiel Prog und Auto: K 0b110).
Beim Loslassen der Taste wird K: 0b0 gesendet.
Das Modul nimmt aber leider keine der von Dir angegebenen Befehle
entgegen. Wie hast Du das Datenversenden eingestellt (Zeilenende CRLF,
nur CR oder nur LF?)
In case you don't understand german: As you can see, partially the
meaning of the letters differs from what you stated in the wiki and the
modul does not respond on send commands. Can you tell us, how you set up
your terminal settings for the end of the line?
When did you bought the module, what is its brand, what SW Version is
displayed when you place the batteries and did you take a look to the
board (does it look like this
http://img407.imageshack.us/img407/3056/burgtwisterplatinest3.jpg)?
Which microcontroller is in use?
Gruß
Karim
Habe nun in die Analyse die Serielle Schnittstelle mit aufgenommen.
Den anderen unbestätigten Kram werde ich aus der Wiki erstmal löschen,
da ich das auch nicht nachvollziehen konnte.
BTW: Womit zeichne ich so Programm Ablauf Pläne?
Dario
Hallo Dario,
PAPs kann man mit der Zeichenfunktion von Word erstellen oder mit Power
Point. Das Profitool wäre Visio. Darüber hinaus gibt es auf freeware
Programme, die aus C Code ein Ablaufdiagramm generieren können.
Muss keine PAPs generieren, daher kann ich Dir nix empfehlen. Eventuell
ist hier:
http://www.supershareware.com/dbresult/flowchart.htmlhttp://forum.fachinformatiker.de/algorithmik/39936-kostenloses-tool-zum-pap-erstellen.html
etwas dabei.
Die Angaben von krzysin waren leider für die Füße. Zumindest habe ich
mal gesehen, was die HR20 für Infos liefern.
Gruß
Karim
So,
das erste selbstgeschriebene Programm läuft auf meinem HR20.
Damit habe ich auch jetzt herausgefunden, welche Segmente vom LCD an
welchen Bits des LCD Controllers hängen.
Morgen werde ich das alles mal aufschreiben und dann die LCD Lib
zum Ansteuern des LCD schreiben.
Irgendwelche wünsche an die API?
Dario
Hallo Dario,
ein Vorschlag für das API wäre:
Es sollte Funktionen geben, mit denen die Applikation an die Displaytask
übermittelt, was angezeigt werden soll. Diese merkt sich die Vorgabe in
einem Displayspeicher und beschreibt die Segmente. Vermutlich
unterstützt der Ateml aber keine Blinkfunktion. Das heisst, jeder
Segmentspeicher hat auch ein Blinkflag. Ist nur ein einziges Segment auf
blinken gesetzt, wird ein Timer aufgesetzt, der die Diplaytask aufruft.
In diesem Takt, muss die Displaytask die betroffenen Segmente an- und
ausschalten.
Ein API könnte so aufgebaut sein, dass es mehrere Methoden anbietet, um
unabhängig von der Vorgeschichte, einzelne Segmente anzusteuern. Das
zurücksetzen eines Segmentes löscht dabei auch das Blinkflag
DISPLAY_CLS(); // Löscht Displayspeicher -> alle
Segmente aus.
DISPLAY_TEXT("172C", FLASH_D1|FLASH_D2); // 172C wird ausgegeben und 2C
blinkt
DISPLAY_TEXT("boot", FLASH_NONE); // Es wird boot ausgegeben
DISPLAY_7SEG(7SEG_D3, '7', SOLID); // Schreibt in Segment 3 eine 7
nicht blinkend rein
DISPLAY_SEG(17, SOLID); // Alle Segmente (58?) erhalten eine
Nummer und können einzeln geschaltet werden
DISPLAY_DOT(SOLID, FLASH); // Erlaubt das setzen des
Doppelpunktes einzeln blinkend oder nicht blinkend
DISPLAY_DOT(FLASH, UNCHANGED); // Verändert nur den Zustand des
unteren Punktes
DISPLAY_BAR(1,8, FLASH); // Erlaubt das setzen der Balken, hier
1-8 blinkend an
DISPLAY_BAR(9, 13, BLANK); // Schaltet die Balken 9-13 aus
DISPLAY_MODE( AUTO ); // Schaltet den Indikator Auto/Man
DISPLAY_OPERATION_MODE( MODE_ACTIVE ); // Schaltet das Sonnen oder
Mondsymbol
// Die nachfolgenden Methoden könnten sinn machen, wenn eine Task das
Display übernehmen will und später der ursprünglich Zustand wieder
hergestellt werden soll. Kann man vorerst weglassen.
DISPLAY_GETMEM(char[] display_mem); // liefert den Displayspeicher
DISPLAY_SETMEM(char[] display_mem); // beschreibt den
Displayspeicher in einem rutsch
enum SEG_FLASH_MODE { FLASH_D1=0b0001, FLASH_D2=0b0010,
FLASH_D3=0b0100, FLASH_D4=0b1000, FLASH_NONE=0};
enum 7SEG { 7SEG_D1, 7SEG_D2, 7SEG_D3, 7SEG_D4 };
enum DISP_MODE { SOLID, // Anzeige Schalten
FLASH, // Anzeige blinkend Schalten
UNCHANGED, // betrofenen Displayspreicher nicht
verändern
BLANK // betroffenen Displayspeicher samt
Blinkflag löschen
};
enum OPERATION_MODE { MODE_ACTIVE, MODE_SAVE, MODE_ACTIVE_SAVE_OFF
/* die nachfolgenden Modi eventuell später */
MODE_ACTIVE_FLASH, MODE_SAVE_FLASH,
MODE_ACTIVE_SAVE, MODE_ACTIVE_SAVE_FLASH};
enum AUTO_MODE { AUTO, MAN, AUTO_MAN_OFF };
Die Formatierung wird es durch die TABS etwas zerreissen, schicke es Dir
noch per Email zu. Mit den obigen Funktion kann man ganz gut abdecken
was man fürs Erste braucht. Bei der entgültigen Realisierung wird man
mehr sehen.
Gruß
Karim
Hallo Dario,
noch was. Vor der Benutzung des Display muss ein Blanking (LCDBL)
ausgeführt werden, beim Power Down ebenfalls, um
Gleichspannungsanteile/Restladung abzubauen, eine ordentliche Anzeige zu
gewährleisten und die Lebensdauer des Displays hoch zu halten.
Aber das hast Du sicher schon gelesen.
Gruß
Karim
Hi,
Habe heute den Ganzen Tage programmiert und die Display API ist fast
fertig.
*Das Beste ist: Sie funktioniert. *
Wer will kann Sie sich im SVN ansehen.
https://opensvn.csie.org/traccgi/hr20
Nur noch die Funktionen für die Balkenanzeige habe ich noch nicht
fertig.
Da Will ich zwei Stück von machen:
*LCD_Bar_Point(uint8_t pixel, uint8_t mode)* Einen Punkte setzen
*LCD_Bar_Field(*uint8_t pm[3], uint8_t mode)* Punkte aus Array setzen
Dann muss ich für die 7Segment noch eine Schow Temp machen, die einen
unit8_t Wert als Temperatur ausgiens, so wie der Original HR20 (OFF,
5,0C-30,0, ON), dabei gilt 0=off,n=4,9+(n/10),255=ON, Dazu muss ich noch
das kleine N machen.
@ Karim:
> Vor der Benutzung des Display muss ein Blanking (LCDBL)> ausgeführt werden, beim Power Down ebenfalls
Eigentlich nur, wenn man vorher die Porst anderweitig benutzt hat.
So habe ich das verstanden und beim Power-Down geht es ja quasi nicht,
denn wir nehmen ja einen Sleep Mode, bei dem der Display-Controller
weiter läuft. Und wenn man ein Gerät mit LCD einfach abschaltet (z.B.:
über einen Schalter) dann kann der auch kein LCDBL mehr machen. Ich sehe
das gelassen und beobachte bei mir auch kein nachleuchten oder so.
N8
Dario
Hallo Dario,
bist echt fleissig, da komme ich jetzt richtig in Zugzwang :-).
Die Flüssigkristalle haben ein gewisses Eigenleben und zersetzen sich,
wenn sie ionisiert bleiben. Wenn Du einen Elektrolytkondensator nimmst,
auflädts, nur kurz kurzschliesst, wirst Du mit dem Voltmeter trotzdem
wieder eine Spannung messen. Wenn Du jetzt eine Wechselspannung
höherohmig an den Kondensator anlegst, wird es eine Weile dauern, bis
die mittlere Spannung auf 0 geht.
Da der HR20 im normalfall durchläuft, ist das der nicht kritische Fall
aber wenn das Teil abgeklemmt wird und eine kleine Restladung auf dem
Display verbleibt, kann es mit der Zeit die Flüssigkeit zersetzen. Falls
der 169 eine Power Down Detection hat, wäre noch Zeit, ein Blanking
auszuführen, um kein Risiko einzugehen. Siehe auch 22.3.7 und 22.4.3 in
der Doku vom 169P.
Wenn ich vom twister die Batterie abklemme und die V24 noch dran habe,
schickt das Teil in einer Endlosschleife HR20 HR20... raus. Hab aber
nicht getestet wie lange. Jedenfalls scheint der zu erkennen, wann der
Saft abgedreht wird und kann noch irgendetwas anstellen. Der Atmel
verbraucht so wenig Strom, dass man mit einem Kondensator ausreichend
lange den Betrieb aufrecht erhalten kann, um noch aufzuräumen.
Gruß
Karim
Hi,
habe vor einigen Monaten diese Diskussion gelesen und darauf ein HR40
gekauft. Jetzt bin ich durch meine Lesezeichen wieder auf diese
Diskussion gestoßen, super.
Ich hatte schon ein angefangen meinnen genauer unter die Lupe zu nehmen,
Potos gemacht etc.
Mein HR40 sagt:
>HR40 SW Version 204 vom 08. Mar. 2006 12:00 HW Version 2
Innen sieht es auch ganz ähnlich aus. Ich denke das Ergebnis sollte sich
sehr leicht portieren lassen, wenn überhaupt nötig. Fotos folgen.
@Dario,
hab gerade gesehen, dass Du Dich auch des RTC Themas gewidmet hast. Das
ist zwar einerseit schön, andererseits habe ich das ganze Wochenende
zufälligerweise mit dem gleichen Thema verbracht und ebenfalls kodiert.
Das war verdammt viel Arbeit und jetzt haben wir Verlustleistung
produziert. Das nächste Mal müssen wir uns glaube ich besser abstimmen
:-(.
Die EMail-Benachrichtung vom Forum hat scheints auch nicht funktioniert,
sonst hätte ich am Sonntag etwas anderes machen können.
Jetzt müssen Wir uns zunächst darüber einigen, welchen Lösungsansatz wir
weiter verfolgen. Mir gefällt das mit der Systemtime auf Sekundenbasis
und die Datum/Zeit-Erzeugung erst nach Bedarf ganz gut. Was meinst Du?
Gruß
Karim
Hi,
könnt ihr mir bitte genau erklären wie ich 'ne RS232-Schnittstelle an
den HR-20 anschließe? Welche Pins müssen wohin? Welche Widerstände habt
Ihr eingesetzt?
Danke,
Gruß Markus
Hallo Markus,
Du schriebst:
> könnt ihr mir bitte genau erklären wie ich 'ne RS232-Schnittstelle an> den HR-20 anschließe? Welche Pins müssen wohin? Welche Widerstände habt> Ihr eingesetzt?
Steht alles hier: http://www.carluccio.de/img/hr20/analyse.pdf
In Kapitel 7 Seite 12 findest Du die Pinbelegung
Die Daten und Widerstend zu 4V Kabel in Kapitel 5 Seite 20
Noch Fragen?
Dario
Hallo Dario,
eigentlich arbeitet eine RS-232 mit +-12V, zudem sind die Signale
invertiert. Beim Rondostat fehlt der Pegelwandler, daher 0-3V
nichtinvertiert. Die neueren RS-232 Bausteine sind TTL Kompatibel, daher
kommen die auch mit 0-5V zurecht, aber es müsste trotzdem noch
invertiert werden und auf der Emfangsleitung vom HR muss der
Spannungsteiler rein wie hier
http://kulknet.homeip.net/Steffen/Softwareprojekte/RondoSet/RondoSet.htm
und aus Deiner Super Doku zu sehen. Die Pinbelegung des Steckers am PC
findet man hier http://de.wikipedia.org/wiki/EIA-232, abhängig davon ob
es eine 9 oder 25polige (alt) Buchse ist.
Ohne Pegelwandler auf der Gegenseite, kann bei 0-5V über einen
Spannungsteiler direkt angekoppelt werden.
Weitere Infos gibt es hier Beitrag "RS232 an 5V".
Gruß
Karim
Zur Brown Out Detection (siehe 27.5), es gibt ein Register BODLEVEL, in
dass man 4 verscheidene Werte eintragen kann:
BODLEVEL 2..0 Fuses Min V Typ V Max V
111 BOD Disabled
110 1.7 1.8 2.0 V
101 2.5 2.7 2.9
100 4.1 4.3 4.5
Zum Aktivieren müssen wir entweder 101 oder wenn das noch ausreicht 110
verwenden. Zum Abschalten wird 111 eingetragen. Die Hyterese der BOD
beträgt 50mV.
Nachdem der Reset ausgeführt wurde (vermutlich bei einer
Motoreinstellaktion), gibt es ein Register (MCUSR, siehe 9.5.1, 24.8.2),
indem der Grund für den Reset steht (BODR & 0b100). Wenn nach dem wieder
Hochfahren ein BOD Reset festgestellt wird, wird im Display (Vorschlag)
'batt' angezeigt und der Betrieb eingestellt. Das MCUSR muss sehr früh
gelöscht werden, damit eine Resetquelle wieder sicher erkannt werden
kann.
Da BOD wegen der eingeschalteten Referenzquelle ständig 15uA zieht, kann
man sich noch überlegen, ob man ca. 6% Lebensdauer das Batterie dafür
spendieren will oder den BOD nur sporadisch aktiviert.
In der Hauptinitialisierungsfunktion muss das MCUSR ausgelesen und
danach zurück gesetzt werden. Bei einem BOD 'batt' anzeigen, in den
Sleep Mode wechslen und warten, bis die Batterien ausgewechslet werden.
Der Batteriewechsel sollte dann zu einem Power On Reset führen (erstes
Bit in MCUSR gesetzt) und den BODR aufheben.
Karim
Hallo Zusammen,
die letzten Tage habe ich einen HR20 hier am PC gehabt und
ununterbrochen die Ausgaben auf der seriellen Schnittstelle geloggt.
Daraus habe ich ein Diagramm gebastelt, welches Soll- und Isttemperatur
(multipliziert mit 10), sowie den Wert der Ventilstellung zeigt.
http://carluccio.de/img/hr20/regel.gif
Dann noch etwas herausgezoom, dort habe ich aber, damit es besser in die
Grafik passt auf die Ventilstellung 100 addiert. 150 bedeutet also 50%.
http://carluccio.de/img/hr20/regelzoom.gif
Kennst sich jemand mit Regelalgorithmen aus?
Dario
Hallo Dario,
sieht nach PI Regler aus. Es gibt einige Stellen die irritieren, z.B. da
wo die Temperatur noch deutlich abfällt, obwohl das Ventil offen ist.
War da ein Fenster oder Tür offen oder hängt das Ventil schon mal?
Dann gibt es stellen, wo das Ventil zu ist und die Temperature trotzdem
auf einmal ansteigt. Könnte von Sonneneinstrahlung oder einer anderen
Heizquelle herrühren.
Beim gezoomten Ausschnitt ist vermutlich die Aussentemperatur
abgefallen, weswegen die Reaktion auf die Ventilöffnung eher Träge
wirkt. Man müsste die Aussentemperatur mit protokollieren oder sich
einen Tag aussuchen, wo die Temperatur nur wenig schwankt.
Etwas Lektüre gibt es z.B. hier:
http://de.wikipedia.org/wiki/ReglerBeitrag "Algorithmus fuer PID (Heizungsregelung)"http://www.mikrocontroller.net/attachment/552/PID.doc
Gruß
Karim
Hallo Zusammen,
ich komme nicht weiter, denn ich habe ein Problem.
Aus der Analyse weiss ich, dass der Motor mit eine PWM angesteuert wird,
die an Timer0 (OC0A) hängt und mit 15,625 kHz läuft.
Nun ist die maximale PWM Frequenz laut Datenblatt Systemtakt / 256.
Bei 1 MHz also nur 3,9 kHz. Das lässt darauf schließen, dass die
Originalsoftware (zumindest wenn der Motor läuft) auf 4MHz läuft.
Um nun weiteren Problemen aus dem Weg zu gehen, würde ich gerne die
Frequenz fest auf 4MHz einstellen. (Wenn ich ständig zwischen 1MHz und
4MHz hin und her schalte bekomme ich mit Sicherheit Probleme mit dem
UART)
Hat das jemand schon mal gemacht.
Würde das so gehen
1
cli();
2
CLKPR=(1<<CLKPCE);
3
CLKPR=(1<<CLKPS0);
4
sei();
Nicht dass mir da der compiler was wegoptimoert.
Oder hat jemand ne andere Idee?
Dario
Habe mir gerade mal eine Cross-Toolchain für avr erzeugt und make
ausgeführt.
Fehlermeldung siehe Attachment:
Linking: main.elf
avr-gcc -mmcu=atmega169 -I. -gdwarf-2 -DF_CPU=1000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=obj/main.o -std=gnu99 -Wundef -MMD -MP
-MF .dep/main.elf.d obj/main.o obj/lcd.o obj/rtc.o --output main.elf
-Wl,-Map=main.map,--cref -lm
/usr/libexec/gcc/avr/ld: cannot open linker script file
ldscripts/avr5.x: No such file or directory
Wo kriege ich dieses Linker-Script her?
@ "Ich würde vorschlagen die aktuelle WinAVR version (20071221) zu
benutzen, also sprich GCC 4.2.2 sowie avr-libc 1.6.0."
Es hat nicht jeder Windows ...
OK, mit dem Symlink-Workaround geht es dann.
Aber, nächster Fehler:
jens@fairtrade ~/devel/hr20/source $ LC_ALL=C make
Size after:
avr-size: unrecognized option `--mcu=atmega169'
Usage: avr-size [option(s)] [file(s)]
Displays the sizes of sections inside binary files
If no input file(s) are specified, a.out is assumed
The options are:
-A|-B --format={sysv|berkeley} Select output style (default is
berkeley)
-o|-d|-x --radix={8|10|16} Display numbers in octal, decimal
or hex
-t --totals Display the total sizes (Berkeley
only)
--common Display total size for COM syms
--target=<bfdname> Set the binary file format
@<file> Read options from <file>
-h --help Display this information
-v --version Display the program's version
avr-size: supported targets: elf32-avr elf32-little elf32-big srec
symbolsrec tekhex binary ihex
-------- end --------
Scheint ein Bug in binutils zu sein?
Hi Jens
Du schreibst:
> Warum ist main.hex eingecheckt? Das wird doch beim Bauen erzeugt?
Stimmt, aber ich persönlich will mir oft bei anderen Projekten nur den
IST-Stand ansehen, ohne es selber compilieren zu müssen und da freue ich
mich immer, wenn das aktuelle HEX da noch rumfliegt.
Dario.
Hallo Jens
Du schriebst:
>> aktuelle WinAVR version (20071221) zu benutzen,>> also sprich GCC 4.2.2 sowie avr-libc 1.6.0."> Es hat nicht jeder Windows ...
Stimmt, aber ich würde mal sagen 100% des jetzigen codes kommt
von Windows Nutzern.
GCC 4.2.2 sowie avr-libc 1.6.0. sind systemunabhängig.
Und jeder der nicht Windows nutzen will, kann sich das makefile
anpassen.
Wenn Du das makefile so änderst, dass es auf beiden Systemen läuft:
besser!
Ich habe bisher viel Arbeit darein gesteckt und sehr viel dokumentiert.
Bislang hat sich das für mich nicht "gelohnt", denn die ganze Arbeit
habe
ich trotzdem.
Ich hoffe eben, dass sich hier mal eine Dynamik entwickelt ...
Dario.
Dario C. wrote:
> Hallo Jens>> Du schriebst:>>> aktuelle WinAVR version (20071221) zu benutzen,>>> also sprich GCC 4.2.2 sowie avr-libc 1.6.0.">>> Es hat nicht jeder Windows ...>> Stimmt, aber ich würde mal sagen 100% des jetzigen codes kommt> von Windows Nutzern.>> GCC 4.2.2 sowie avr-libc 1.6.0. sind systemunabhängig.>> Und jeder der nicht Windows nutzen will, kann sich das makefile> anpassen.>> Wenn Du das makefile so änderst, dass es auf beiden Systemen läuft:> besser!
Sorry, ich wollte Dich da nicht angreifen.
Hast Du die Hilfeausgabe von avr-size unter Windows? Hätte gedacht, daß
das ebenfalls die ganz normalen binutils sind. Vermutlich eine andere
Version?!
Hab gerade mal nach diesem WinAVR gegooglet: Das schaut eigentlich nach
der gleichen Toolchain aus, die ich auch unter Linux habe, und die
binutils müßten laut
http://winavr.cvs.sourceforge.net/winavr/patches/binutils/ auch die
gleichen sein (ich habe 2.18).
Deshalb wundert es mich halt, daß der unter Windows die Parameter --mcu
und --format akzeptieren soll ...
Dario C. wrote:
> Hi Jens>> Du schreibst:>> Warum ist main.hex eingecheckt? Das wird doch beim Bauen erzeugt?>> Stimmt, aber ich persönlich will mir oft bei anderen Projekten nur den> IST-Stand ansehen, ohne es selber compilieren zu müssen und da freue ich> mich immer, wenn das aktuelle HEX da noch rumfliegt.>> Dario.
Ja, schon klar. Das Problem war bloß: Ich habe das gebaut, dann svn up
gemacht, und dann gab es einen Konflikt ...
Nächstes Mal weiß ich Bescheid: make clean for dem svn up.
Hallo miteinander,
ich verfolge den Thread auch schon ein paar Tage,
bis jetzt aber nur mit einem Auge, da ich kein HR20 o.ä. habe, sondern
solche:
http://www.eurotronic.org/index.php?id=7
Die gibts hin und wieder bei diversen Supermärkten, hab das letzte für
ca. 23€ bekommen.
Dieses ist ziemlich ähnlich zum HR20, hab auch schon eins geopfert für
die Wissenschaft ;-)
Das LCD ist gleich, nur ist die Software nicht ganz so komfortabel,
erfüllt aber seinen Zweck. RS232-Ausgang, bzw. überhaupt Stecker, gibts
keinen.
Das Ventilfreifahren ist am Freitag um 11Uhr.
Aber es ist auch ein Mega169V verbaut.
Die Belegung des LCDs ist aber etwas anders als ich hier gefunden habe,
ist alles ein Pin verschoben und das letzte dann am Anfang ;-)
ISP- und JTAG-Pins könnte man auch abgreifen, aber mangels JTAG-Adpater
kann ich das nicht testen. Per ISP habe ich keinen Kontakt bekommen,
wobei ich nicht überprüft habe ob das am Spannungsunterschied lag. Das
muss ich gelegentlich nochmal wiederholen, um zu sehen obs an mir oder
an den Fusebits liegt.
Was an diesem noch gut ist, es sind die Kontakte für die grössere
Bauform (TQFP) des M169 schon auf der Platine, so könnte man sich einen
neuen holen und austauschen, evtl. sogar einen M329 ;-)
mfG
Hi Jens
Du schriebst:
> Sorry, ich wollte Dich da nicht angreifen.
Kein Problem, ich habe auch nur dargestellt, warum es so ist wie es ist.
Ich freue mich wenn sich mehr Leute einbringen und mitmachen, egal ob
Windosen oder Linuxer.
> Hast Du die Hilfeausgabe von avr-size unter Windows?
1
D:\>avr-size --help
2
Usage: avr-size [option(s)] [file(s)]
3
Displays the sizes of sections inside binary files
4
If no input file(s) are specified, a.out is assumed
5
The options are:
6
-A|-B|-C --format={sysv|berkeley|avr} Select output style (default is berkel
7
ey)
8
--mcu=<avrmcu> MCU name for AVR format only
9
-o|-d|-x --radix={8|10|16} Display numbers in octal, decimal or hex
10
-t --totals Display the total sizes (Berkeley only)
Danke. Ich werde mal schauen, ob ich vielleicht meine Toolchain noch mit
anderen Optionen bauen kann.
avr steht auf
http://www.gentoo.org/proj/en/base/embedded/cross-development.xml nicht
als "CPU architecture", sondern als "special machine name". Was auch
immer das heißt.
Ich habe jetzt angefangen den HR40 genauer zu analysieren. Bisher habe
ich keine Abweichungen zu dem HR20 gefunden was die Schaltung betrifft.
Den Motorteil habe ich noch nicht, aber Schalter und Sensoren sind
soweit identisch angeschlossen.
Hi Patrick
Du schriebst:
> Bisher habe ich keine Abweichungen zu dem HR20 gefunden> was die Schaltung betrifft.
Das ist ja schon mal gut.
Aber was sind denn die Unterscheide in der Software.
Ich weiss ist ne schwehre Frage, wenn Du die Software des HR20 nicht
kennst, aber vielleicht weisst Du ja doch was.
Dario
Ich habe keine Abweichnungen gefunden. Habe das Bild nach deinem
Schaltplan beschriftet und werde es dann hier zur Verfügung stellen,
heut' nicht mehr.
@dario: Weiss ich nicht. Ich könnte mir vorstellen, dass die ähnlich
bzw. gleich sind.
Unter welcher Lizenz ist der Quellcode denn zu nutzen, der schon
existiert?
Viele Grüße
Patrick
Patrick Büker wrote:
> Unter welcher Lizenz ist der Quellcode denn zu nutzen, der schon> existiert?
GPL v2 oder höher
Muss ich noch in die Quellen eintragen
Die Bedienungsanleitung zum HR40 gibt es bei Honeywell zum Download. Da
konnte ich aber keinen Unterschied zum Burg Twister ausmachen.
Zum HR40 gibt es wohl ein Netzteil, dass man anstatt der Batterien
einsetzen kann und es gibt einen HR40F der ein Kabelgebundenes
abgesetzes Bedien- und Temperaturerfasseungsteil hat.
Mögliche Unterschiede könnten aber in einem langlebigeren sparsameren
Motor liegen, vorgealterten Bauteilen oder besserem Kundensupport.
Letzteres halte ich für das am ehesten wahrscheinliche.
Ein Thermotronic Modul habe ich wieder in Betrieb genommen. Das ist
lauter, hat keinen Notbedienung, keine Möglichkeit von aussen einen
Stecker anzuschliessen, hat keine Erkennung für abgenommenes Bedienteil,
sieht nicht ganz so schön designt aus, bietet keine Möglichkeit die
aktuelle Raumtemp. anzeigen zu lassen, hat zum aufschrauben eine
Kunststoff- statt wie beim Twister eine Metallverschraubung. Ist aber
sonst von den Funktionen vergleichbar.
Gruß
Karim
Hallo zusammen,
erstmal ein großes Lob an Alle. Ja auch ich verfolge diese Sache schon
länger im Hindergrund mit, da ich einige der hier erwähnten Teile auch
in meinem Besitz führe.
Ich war sehr erstaunt als Patrick von Ähnlichkeit des HR40 zum HR20
schrieb, darauf öffnete ich meinen HR40. Er hat ein ganz anderes
Platinenlayout, besitzt eine RJ22-Buchse für einen Fernfühler und der
Chip ist mit 'NECIRELAND 4515 926 HR40 1.00 0001E8002' beschriftet.
Da giebt es wohl verschiedene Baureihen !?
Bilder folgen.
Gruß Ralf
Meiner hat, wie man dem Layout entnehmen kann diesen Anschluß für den
Fühler nicht. Auf der Verpakkung wie auf dem Regler steht: HR40 V 2.04.
Werde Fotos davon zusammen mit dem Rest Morgen ind Netz stellen.
edit:
Kannst du vielleicht davon auch Bilder reinstellen? - Dann könnte man
eine Typensammlung machen. Vielleicht für ein späteres FAQ oder so
sinnvoll.
Jens Müller wrote:
>> Aber, nächster Fehler:>
[...]
>> avr-size: supported targets: elf32-avr elf32-little elf32-big srec> symbolsrec tekhex binary ihex>
Damit hatte ich auch Probleme, ich habe mir jetzt damit geholfen:
Hi,
habe ich das richtig verstanden? Da der HR20 ein JTAG Anschluß hat,
können wir ihn nur einen JTAG ICE oder JTAG ICE mkII programmiern. Was
gibt es denn da günstiges auf dem Markt? Reicht der USBprog 3.0 aus dem
Shop ?
Ja, so habe ich das auch verstanden. Aber ich habe leider auch noch
keinen Weg meinen HR20 zu programmieren. erstmal muss ich zugeben, das
ich mich nicht so wirklich mehr auskenne bei Mikrocontrollern, ist schon
länger her, dass ich damit zu tun hatte (und das war ein 8051 Typ).
Jetzt habe ich mir auch ertmal den USBProg gekauft und bin dann direkt
an die entsprechenden Pins des Controllers. Mit der "AVRISP mk2 Klon"
Firmware. Ich hoffe ich kriege das zum laufen, im Moment habe ich
Probleme mit dem USBProg.
Achja, das beschriftete Bild der HR40 Platine ist hier:
http://patrickbueker.de/de/publications/pictures/img_4042bearb.jpg
Einige Bauteile sind noch nicht beschriftet, konnte ich noch nicht
zuordnen.
Ein Thermotronic habe ich mir auch mal gekauft, werde mir das auch mal
anschauen. Weiter oben hatte ja schon jemand was gepostet.
Vom Thermotronic hab ich auch mal ein Bild gemacht.
Statt den gelben und schwarzen Kabeln gehört normal der
Temperatursensor. Die Pins gleich daneben, für den Motor, habe ich auch
selber eingelötet, um die Platine besser aus-/einbauen zu können, hier
war das Flachbandkabel direkt eingelötet.
Hi Tobias,
Du schreibst:
> wie weit bis du gekommen, hast du eine Temperturanzeige im Simulator?> Bei mir kam keine Anzeige.
Je nach dem welche version Du hast kommt auch keine Anzeige.
In der aktuellen Version sollte es aber gehen, wenn Du einen
Breakpoint int main() in der mian.c in diesem Bereich setzt:
1
// POST Screen
2
LCD_AllSegments(LCD_MODE_ON);// all segments on
3
delay(1000);
4
LCD_AllSegments(LCD_MODE_OFF);
5
LCD_PrintDec(REVHIGH,1,LCD_MODE_ON);// print version
6
LCD_PrintDec(REVLOW,0,LCD_MODE_ON);
7
LCD_Update();
8
delay(1000);
9
LCD_AllSegments(LCD_MODE_OFF);// all off
Jeweils bei dem delay könnetst Du ein Breakpoint setzten, nach dem
Befehl
1
LCD_AllSegments(LCD_MODE_ON);// all segments on
sollten alle Segmente an sein. Und nach
1
LCD_PrintDec(REVHIGH,1,LCD_MODE_ON);// print version
2
LCD_PrintDec(REVLOW,0,LCD_MODE_ON);
3
LCD_Update();
Sollte da die Revision stehen.
Was passiert bei Dir?
Dario.
Hallo zusammen,
nachdem ich jetzt schon länger mitlesen, wollte ich erst mal meinen
Respekt an alle Bastler hier aussprechen. Ich finde das Thema hoch
interessant, obwohl ich nur Servicetechniker für Automatisierungstechnik
(SIMATIC) war und jetzt Maschinenbau studiere. (hab´s also nicht so mit
Programmieren... :)
Nachdem überlegt wurde, ob es evtl. nicht Alternativen gäbe, die die
rein mechanische Komponente abdecken, ist mir heute im hiesigen Baumarkt
folgendes Teil aufgefallen.
Ich hab jede Seite der Verpackung fotografiert, aber keine Ahnung, ob es
auch klappt, diese Fotos als Gast hier auch reinstellen zu können!
Gruß
Andreas
ps. wenn kemand die Fotos hier reinstellen kann, kann ich diese jemanden
auch gern per mail schicken, wenn mir jemand seine Adresse gibt...
Hallo Andreas,
hast Du das Teil nur abgelichtet oder auch gekauft?
Was soll denn das gute Stück kosten?
Das Produkt ist von Ansatz her eigentlich keine schlechte Idee, da man
die Regelung weiterhin dem Thermostaten überlässt wie auch die
Temperaturwahl. Zum Abschaltzeitpunkt wird zwischen Thermostat und
Ventil vermutlich ein mechanischer Offset eingerichtet, der für ca. 4°C
Absenkung sorgt.
Uhrzeiteinstellung ist vermutlich nicht nötig. Da steckt ne nicht
einstellbare Uhr drin und die merkt sich zu welcher Zeit eine Ansenkung
oder eine Aktivierung betätigt wurde und wiederholt das jeden Tag bzw.
im Wochenrhythmus. Angenommen es sind zwar 21Uhr aber die interne Uhr
steht auf 16Uhr. Man drückt den Knopf HZ an. Sieben Tage später wird zur
Internen Zeit 16Uhr die HZ eingeschaltet, obwohl es tatsächlich 21Uhr
sind aber das ist dann so gewollt.
Das bedeutet aber auch das die Programmierung im Voraus nicht möglich
ist. Man muss zu der Zeit wo man eine Schalte haben will da sein und
einen Knopf drücken. Die Schalte wird dann im Wochenrhythmus wiederholt.
Sommer/Winterzeit Schalte ist somit nicht möglich. Es gibt keine
Temp.Anzeige, keine Anzeige der eingestellten Zeiten (Blindflug), keine
Möglichkeit einen abgesetzten Temp.Sensor einzusetzen ausser der
Thermostat bietet das.
Da Gehäuse ist etwas globig. Wenn die LED allerdings während dem
Heizbetrieb ständig leuchtet, wage ich die 5 Jahre Batterielebensdauer
zu bezweifeln.
Der HR20E benötigt im Leerlauf schwankend 60-120uA, wenn man bedient ca.
2mA und wenn der Motor läuft ca. 20mA. Eine LED benötigt je nach
Ausführung 5-20mA.
Mir gefällt der HR20E besser, wegen Anzeige, Programmierung und
Flexibilität. Zwischen An- und Abschalttemperatur können auch mehr wie
4°C liegen und wenn das Teil umprogrammiert ist, wird man es fernsteuern
können, auf die Regelcharakteristik Einfluß nehmen und weitere
Anwendungen realisieren können.
Gruß
Karim
Ich habe mal etwas gesucht in der Hoffnung bei Atmel vielleicht auf eine
Application-Note zu dem Thema zu finden. Da die verschiedenen
Konstruktionen sich so ähneln wäre das ja möglich.
Leider bin ich nur auf folgenden Artikel gestoßen:
http://www.atmel.com/dyn/resources/prod_documents/battery.pdf
Das gesamte Heft auch hier:
http://www.atmel.com/journal/documents/JOURNAL_2.pdf
Dort wird zwar ein Thermostat beschrieben, aber nicht im Detail.
Vielleicht existiert doch eine Application-Note?
@ Ralf H. (Gast)
Dein HR40 wird vermutlich eine andere, frühere Serie sein. Es gibt
nämlich auch HR20 mit NEC-Chip. Das würde auch darauf hindeuten, dass
beide damals auch schon vom Innenleben gleich waren.
So,
ich habe mich einmal an die Doku des bestehenden Source Codes gemacht.
Eine Vorabversion befindet sich auf www.carluccio.de/hr20
Das Ganze kann mit doxygen aus den Quelltexten erzeugt werden.
Das Doxygen Config File liegt im svn.
Dario
Hallo Dario,
kanst Du bitte mal die Rev. 33 überprüfen.
In einer ältere Version war RTC_MM noch declariert.
Ich erhalte folgende Fehler:
Build started 7.3.2008 at 17:34:22
avr-gcc.exe -mmcu=atmega169p -Wall -gdwarf-2 -std=gnu99
-DF_CPU=1000000UL -O0 -funsigned-char -funsigned-bitfields -fpack-struct
-fshort-enums -MD -MP -MT rtc.o -MF dep/rtc.o.d -c ../rtc.c
../rtc.c: In function 'RTC_Init':
../rtc.c:110: error: expected ';' before 'RTC_hh'
../rtc.c:115: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c:115: error: (Each undeclared identifier is reported only once
../rtc.c:115: error: for each function it appears in.)
../rtc.c: In function 'RTC_GetMonth':
../rtc.c:138: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c:139: warning: control reaches end of non-void function
../rtc.c: In function 'RTC_SetMonth':
../rtc.c:231: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c: In function 'RTC_AddOneSecond':
../rtc.c:438: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c: In function 'RTC_AddOneDay':
../rtc.c:482: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c: At top level:
../rtc.c:504: error: conflicting types for 'RTC_DaysOfMonth'
../rtc.c:66: error: previous declaration of 'RTC_DaysOfMonth' was here
../rtc.c: In function 'RTC_DaysOfMonth':
../rtc.c:505: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c:514: warning: control reaches end of non-void function
../rtc.c: In function 'RTC_IsLastSunday':
../rtc.c:546: error: 'RTC_MM' undeclared (first use in this function)
../rtc.c: In function 'RTC_SetDayOfWeek':
../rtc.c:583: error: 'RTC_MM' undeclared (first use in this function)
make: *** [rtc.o] Error 1
Build failed with 13 errors and 2 warnings...
// Tobias
Hallo Tobias,
> kanst Du bitte mal die Rev. 33 überprüfen.> In einer ältere Version war RTC_MM noch declariert.
Jepp, da habe ich beim Dokumentieren wohl auch einen Fehler reingehauen.
Sollte in der Rev34 behoben sein.
Lass es mich wissen, wenn Du noch Probleme hast.
Dario.
Hallo,
ich hab´s nur fotografiert und nicht gekauft,
da ich mittlerweile 8x HR20 in unserem Haus verbaut habe.
Der Preis war glaub ich irgendwas zwischen 20-25 Euro.
Das das HR20 komfortabler ist, ist mir auch bewusst,
aber hier stellte ja jemand die Frage nach einer Alternative,
die nur aus einem Stellmotor besteht. Deswegen hab ich bei
diesem Gerät an euch gedacht.
Gruß
Andreas
Achja, wo ich schon hier bin, möcht ich euch gleich über einen Fehler
informieren, der bei meinen neuen HR20 aufgetreten ist.
Bei mir ist seit etwa 4 Jahren ein altes Model dieses Thermostats ohne
Problem und zuverlässig im Einsatz, deswegen hab ich vor 4 Wochen bei
conrad.de zugeschlagen und 7 Stück zu je 29,90 Euro gekauft.
Wie sich rausstellte sind alle 7 nun ein neueres Model, nur leider macht
sich bei diesen jetzt ein kleines Problem bemerkbar, das beim alten noch
nicht war. Sporadisch gehn alle 7 Thermostate zurück in den
Einstellmodus in dem man Datum und Uhrzeit einstellen muss. Dies
passiert entweder ganz von allein, oder wenn man am Stellrat die
Themperatur nachregelt. Dumm für mich ist, dass fast alle HR20 von oben
nicht einsehbar unter Fensterbänken sind, und so steht dann das eine,
oder andere im Eingabemodus, regelt dabei nicht mehr und jeder fragt
sich, warum die Heizkörper kalt bleiben.
Der nette Herr an der Hotline von KAZ Hausgeräte GmbH sagte mir, dass
dieser Softwarefehler bekannt sei und diesen ab und zu ein paar Geräte
haben, jedoch hat er noch nie 7 davon auf einmal gehabt. (hab ich wohl
ne Serie Montagsgeräte erwischt :/ ) Er hat mir auf jeden fall geraten,
die Geräte an Conrad zurück zu schicken und Austauschgeräte zu nehmen.
Vielleicht ist dieser Fehler bei euch ja auch schon mal aufgetreten?
Wollt euch dieses Verhalten auch nicht vorenthalten! : )
Gruß
Andreas
Hallo Andreas,
Du kannst die Thermostaten doch auch um 90° gekippt montieren. Dann
kannst Du drauf schauen.
Zu den Aussetzern habe ich bei einem Modul folgende Erfahrung gemacht.
Am Metallbügel der nach dem einlegen der Batterie diese brückt ist eine
kleine Lasche dran, die dazu dient, mit dem Fingernagel die Lasche
bedienen zu können. Die liegt so dicht an dem grauen Zahnrad, dass wenn
das Zahnrad zum Modul hin bewegt wird, die Zähne an der Lasche streifen
können und der Bügel mitgezogen wird/schwenkt. Folge ist, dass die
Batterien garnicht oder nur halblebig miteinander verbunden sind.
Abhilfe schafft ein leichtes Auf- oder Zubiegen dieser Lasche, um Sie
aus der "Gefahrenzone" zu bringen. Wenn Du das nächste Mal ein Modul im
Startmodus findest, öffne die zwei Verriegelungen, nimm das Modul ab und
prüf mal den Sitz des Metallbügels.
Das Verbiegen der Lasche geht im eingebauten Zustand schlecht. Das
ausbauen ist etwas kniffelig, wegen dem Kunststoffschnapper. Da sollte
man Fingerspitzengefühl walten lassen, damit nix bricht.
Gruß
Karim
So,
ich habe nun meine 6 Rondostat bestellt. Ich hoffe mal die sind Version
2.04, also mit Atmel Chip.
"C" hat da ja im Moment ein Angebot :-)
Jetzt muss ich nur noch Zeit haben die alle zu Montieren :-)
Wenn ich das richtig verstanden habe, kann man die ja von außen neu
flashen über JTAG ?
Ist das Protokoll für die Serielle schon definiert ? Da kann ich sicher
helfen, sowas ist mein täglich Brot :-)
Dann könnte ich schon mal an meinem Protokollumsetzer an den AXLink Bus
meiner AMX arbeiten ;-)
Gruss
Jürgen
Achtung ! Der Tipp mit der Rohrzange ist unvollständig !
Vorsicht ! : wenn man zu weit auf den Stift fasst, kommt der Bereich -
den die Zange gefasst bzw. beschädigt hat - später beim Reindrücken-
fahren des Ventis evtl in den Bereich der O-Ring Dichtung. Also: bitte
nur ganz ganz kurz anfassen. Am Besten, man nimmt eine wirklich
gute/neue Combizange. Denn diese ist vorne so scharfkantig/winkelig,
dass sie den Stift ganz vorne greifen kann. Dieser Brereich kommt später
nicht in die Nähe des O-Rings.
Mit freundlichem Gruß
Lothar Peters
Heizungs- und Sanitärbedarf (Hürth)
durch Zufall (Google - HR-E 20 :-) bin ich auf diesen Thread aufmerksam
geworden. Ich bin begeistert. Nur bin ich leider ekin Elektroniker :-(
Ich bin Heizungsmonteur Kesselbauer Schmied.
Passt zwar nicht - bin aber leidenschaftlicher Bastler und stell am
Liebsten ALLES in Frage. Daher regt mich, was diesen Thread betrifft
eher ein primitiver Gedanke:
Da ich hier einiges gelesen habe und ich soeben bei Saturn im EKZ-Hürth
(Köln)
einen HR-E 20 gekauft habe, sah ich schon mal beim Einlegen der
Batterien die Version 2.04. Das weiß ich nun. Aber. Was ich nicht weiß:
Kann man die Anschlüsse (seitliche Kappe) irgendwie nutzen, um eine
schnelle Umschaltung auf Absenken zu forcieren?
Das mit manuell und wieder automatik ist mir zu primitiv. Dann könnte
ich auch einen konventionellen Thermostatkopf auf nd zu drehen :-)
Wenn man mit einer einzigen voreingestellten Absenktemperatur leben
kann, dann wäre das optimal. Ein Klick und er steht auf absenken. Das
gleiche wieder zurück. Ich hoffe das man mich verstehen konnte :-)
Wahrscheinlich wäre es für den Hersteller eine zusätzliche Erweiterung
gewesen. Vielleicht habe ich es nicht gelesen. Aber, wie ich es sehe,
hat der HR-E 20 diese Funktion nicht. Einfach einen Knopf, der alle
anderen Funktionen nachrangig schaltet. Klick = Absnken (bis zum
rücksetzen) und Klick = Hochfahren. So. jetzt reichts erstmal. Antwort
wäre sehr hilfreich.
Danke
PS. löscht sich das Programm beim Akkuwechsel ?
Hallo Karim,
bei neuen Heizkörpern ist das schon klar, dass man da das HR20 um 90
Grad drehen und dann drauf schauen kann, aber bei alten Heizkörper und
das sind so ziemlich alle in meinem Haus (Altbau) sind die Thermostate
so montiert, dass du von vorne auf das Stellrad guckst. Man könnte das
HR20 umd 360 grad drehen und könnte in keiner Position das Display
ablesen... :(
Andreas
Hallo Lothar
Du schriebst:
> durch Zufall (Google - HR-E 20 :-) bin ich auf diesen Thread> aufmerksam geworden.
Ich liebe Google, machmal ist es doch zu was gut.
> Ich bin Heizungsmonteur Kesselbauer Schmied.> Passt zwar nicht
Doch, da hebe ich gleich 1000 Fragen an Dich, zum einen bezüglich
des Projektes hier zum anderen meine private Heizungsanlage betreffend.
Wenn Du Zeit und Lust hast mir ein paar Fragen zu beantowrten, dann
schreib mir bitte mal eine Mail.
> Version 2.04.> Kann man die Anschlüsse (seitliche Kappe) irgendwie nutzen, um eine> schnelle Umschaltung auf Absenken zu forcieren?
Mit der Software der Version 2.04 nicht, aber es wäre eine Idee das
in die hier programmierte Version einzubauen. Allerdings sehe ich da
ein kleines Problem und zwar wie kann man das synchronisieren.
Wenn ich 4 Thermostate habe und drei stehen auf abgesenkt und einer auf
Komfort, dann würde nach dem Impuls drei auf Komfort und einer abgesenkt
sein. Nehmen wir mal an die werden mit Schaltuhr alle um 17:00 auf
Komfort geschaltet und die Uhren gehen leicht unterschiedlich, dann ist
das gar nicht so unwahrscheinlich.
Daher würde ich zwei Eingänge vorschlagen, einer für Komfort und einer
für Absenken. Muss ich mir nochmal Gedanken zu machen, inwiefern sich
das negativ auf die Lebensdauer der Batterie auswirkt, aber ansonsten
ist das progammiertechnisch kein Problem.
> PS. löscht sich das Programm beim Akkuwechsel ?
Keine Ahnung, die Hardware könnte es, ob die das programmiert haben
weiss
ich nicht.
Dario
Hallo Jürgen,
Du schriebst:
> Jetzt muss ich nur noch Zeit haben die alle zu Montieren :-)> Wenn ich das richtig verstanden habe, kann man die ja von> außen neu flashen über JTAG ?
Stimmt, aber wenn Du nicht einmal die Zeit findest die zu montieren,
dann hast Du erst recht nicht die Zeit die auch neu zu flashen.
Der Vollständigkeit halber: Von Außen geht JTAG immer. ISP geht, wenn
man es aufschraubt und die ISP-Kabel selber anlötet. Und wenn man erst
mal einen Bootloader drin hat, kann man auch den Atmel auch von außen
über die serielle Schnittstelle (RS232 3,3v) programmieren.
> Ist das Protokoll für die Serielle schon definiert ?
Nö, nur die ersten Denkansätze sind da.
> Da kann ich sicher helfen, sowas ist mein täglich Brot :-)
Ach, erzähl!
Was machst Du, nur Protokolle definieren, oder auch programmieren.
> Dann könnte ich schon mal an meinem Protokollumsetzer an den> AXLink Bus meiner AMX arbeiten ;-)
Was ist ein AXLink Bus und was ist eine AMX
Dario, der jetzt erstmal Googeln geht....
Dario C. wrote:
> Stimmt, aber wenn Du nicht einmal die Zeit findest die zu montieren,> dann hast Du erst recht nicht die Zeit die auch neu zu flashen.> Der Vollständigkeit halber: Von Außen geht JTAG immer. ISP geht, wenn> man es aufschraubt und die ISP-Kabel selber anlötet. Und wenn man erst> mal einen Bootloader drin hat, kann man auch den Atmel auch von außen> über die serielle Schnittstelle (RS232 3,3v) programmieren.
Montiert sind die Jetzt, uff die alle synchron einzustellen (3
Heizkörper in einem großen offenen Raum) ist ja je ne mords Arbeit :-)
>> Ist das Protokoll für die Serielle schon definiert ?> Nö, nur die ersten Denkansätze sind da.>>> Da kann ich sicher helfen, sowas ist mein täglich Brot :-)> Ach, erzähl!> Was machst Du, nur Protokolle definieren, oder auch programmieren.
Mich Tag für Tag mit Protokollen anderer Geräte Rumschlagen und diese
von der AMX aus ansteuern, meist sogar nur per Telefonischem Support. Da
weis man eben was man besser machen kann.
>> Dann könnte ich schon mal an meinem Protokollumsetzer an den>> AXLink Bus meiner AMX arbeiten ;-)> Was ist ein AXLink Bus und was ist eine AMX
AXLink ist einer der Steuer Busse der AMX. Die AMX ist letztendlich ein
Freiprogrammierbares Steuersystem. Dessen Support und Programmierung ist
mein Täglich Brot.
Aber das ist für das Projekt jetzt eher unwichtiger. Ich denke man muss
nur ein Gutes und einfach zu parsendes Protokoll definieren. Dann kann
jeder mit seinem Bus dran von Außen, oder sogar mit dem PC.
Wenn die zur Verfügung stehenden Daten feststehen, also Temperatur, Max
Temp, Min Temp usw, kann ich da gerne einen Vorschlag machen. Eventuell
auch mithelfen. Aber meine Zeit ist zur Zeit eher Limitiert.
Was ich mir noch überlegt habe, könnte man nicht auch optional I2C als
Schnittstelle anbieten ? Es wäre so einfacher mehrere Thermostate an
einen IC zu koppeln. Ich muss mir mal die Schnittstelle vom Thermostat
nochmals ansehen.
> Dario, der jetzt erstmal Googeln geht....
Und Erfolg gehabt ?
Gruss
Jürgen
Hallo Jürgen
Du schriebst:
>> Was machst Du, nur Protokolle definieren, oder auch programmieren.> Mich Tag für Tag mit Protokollen anderer Geräte Rumschlagen> [...]> Da weis man eben was man besser machen kann.
Schön, ich möchte eigentlich ein universelles Protokoll, was alles kann.
Sprich nicht nur Heizung, sondern Lichtschalter, Lampen, Dimmer,
Sensoren, Alarmanlage, Türöffner und was ich sonst noch so habe.
Nach Möglichkeit alles über einen Bus, und wenn es geht auch irgendwie
geschützt gegen Übertragungsfehler und Kollisionen.
Dann könnte man an die jeweiligen Geräte die unterschiedlichsten
Interfaces anbinden (CAN, RS232, I2C, RFM12) Speziel für das letzte
braucht man zwingend eine Kollisionserkennung und / oder Vermeidung,
da es ja ein Funktprotokoll ist.
> Die AMX ist letztendlich ein Freiprogrammierbares Steuersystem.> Dessen Support und Programmierung ist mein Täglich Brot.
Das habe ich auch auf Google gefunden und das gefällt mir sehr gut.
Ich habe nämlich noch kein System um die vielen einzelnen Geräte zentral
zu bedienen. Ich dachte an ein EPAI-Board mit TFT und Touchscreen. Suche
zur Zeit noch nach einem Touchscreen (15-19"), was kostet denn so ein
AMX? Preise habe ich irgendwie keine gefunden, ist bestimmt sauteuer.
Dario
Dario C. wrote:
>>> Was machst Du, nur Protokolle definieren, oder auch programmieren.>> Mich Tag für Tag mit Protokollen anderer Geräte Rumschlagen>> [...]>> Da weis man eben was man besser machen kann.> Schön, ich möchte eigentlich ein universelles Protokoll, was alles kann.> Sprich nicht nur Heizung, sondern Lichtschalter, Lampen, Dimmer,> Sensoren, Alarmanlage, Türöffner und was ich sonst noch so habe.>> Nach Möglichkeit alles über einen Bus, und wenn es geht auch irgendwie> geschützt gegen Übertragungsfehler und Kollisionen.
Das würde ich nicht tun sondern so:
Ich würde Empfehlen ein Basisprotokoll zu machen, das einfach in einem
Terminalprogramm verwendet werden kann.
Erfordert die Hardware eine Prüfsumme, kümmert diese sich um die
Verpackung.
RS232 und I2C sollten so sicher sein, das hier keine Prüfsumme notwendig
ist. Zumindest auf kürzen Längen und niedrigen Datenraten.
CAN hat seine eigenen Sicherungsalgorhythmen.
RFM12 braucht auf alle Fälle eine Prüfsumme.
Stelle dir das so vor: (jeweils ohne [] die dienen nur der
Veranschaulichung)
Basisprotokoll: [?TEMP-MAX]
Antwort [@TEMP-MAX=22]
Abgeschlossen mit CR und eventuell LF
Bei RMF12 eben so
[R009][?TEMMP-MAX][Checksumme 16 Bit]
[R012][@TEMP-MAX=22][Checksumme 16 Bit]
Das Protokoll ist jetzt mal Ohne groß nachdenken Entstanden.
Jedes Kommando ist per CR abgeschlossen.
Jedes Kommando beginnt mit einem Kennzeichen ("!" tue was, "?" sag mir
den aktuellen Wert, "@" Antwort), Das Kommando Schlüsselwort Endet mit
einem immer gleichen Zeichen, hier eben "-". Sehr einfach zu parsen.
Einfach zu Implementieren, das Basisprotokoll wird einfach eingefügt in
die Schnittstellen abhängigen Protokolle.
Kann auch einfach im Terminal Simuliert werden für Tests.
Um das Auszudenken, müsste man Allerdings mal alle Angedachten
Funktionen in einer Liste haben. Dann kann ich da mal länger drüber
nachdenken
> Dann könnte man an die jeweiligen Geräte die unterschiedlichsten> Interfaces anbinden (CAN, RS232, I2C, RFM12) speziell für das letzte> braucht man zwingend eine Kollisionserkennung und / oder Vermeidung,> da es ja ein Funkprotokoll ist.
Siehe oben. Schwierig ist es natürlich, wenn die Jeweilige Anbindung
keine eigene Intelligenz hat sondern nur Pegelwandler ist. Aber man wird
so oder so nicht jedes Protokoll implementieren können.
> [...]> zur Zeit noch nach einem Touchscreen (15-19"), was kostet denn so ein> AMX? Preise habe ich irgendwie keine gefunden, ist bestimmt sauteuer.
Uff, grob gesagt fängt das bei ca 3000€ an, aber das ist Off Topic. Wenn
Du mehr wissen Möchtest, gerne per PM.
Gruss
Jürgen
Hallo Jürgen,
I²C Bus wäre auch mein Favorit, weil ich bei der letzten Renovierung
einen Kabelring verlegt habe, wo ich die Module mit Daten und Strom
versorgen kann. Der Bus läuft beim Atmel unter TWI (SDA liegt auf Port
E7 und SCL auf Port E6). Port E6 wird leider schon für die
Reflexlichtschranke benötigt. Die müsste man auf Port E9 Umwehrdrahten
und die SW anpassen oder einen Tiny verwenden und an die RS-232 klemmen,
der die Daten nur durchreicht. Ist aber alles noch viel Arbeit, die erst
später angegangen wird. Zuerst muss das Teil mal so spielen wie bisher.
Wenn Du Lust hast, kannst Du einen Parser schreiben, der reinkommende
Befehle analysiert.
void Parser_ReceiverChar( char c)
{
static string cmd_str;
......
......
if (bCMDComplete)
{
// Befehl vollständig eingelesen
ParseCmd( string cmd_str);
cmd_str="";
}
else
strcat( cmd_str, c);
return;
}
Die Funktion würde von der RS232 bei jedem empfangenen Zeichen
aufgerufen. Ist eine Befehlszeile als Vollständig eingegangen erkannt
(CRLF), wird sie an den Parser übergeben:
void ParseCmd( string cmd_str);
Der Parser ermittelt den Befehl, die Anzahl der Parameter und ruft die
zugehörige Bearbeitungsmethode auf.
Analyse...
CMD=...
Param1=...
Param2=...
Param3=...
switch(CMD)
{
GET_BDS1: // Kommando BDS1 adr?
Get_ByteDataSet1(Param1);
break;
SET_BDS1: // Kommando BDS1 adr, data
Set_ByteDataSet1(Param1, Param2);
break;
GET_BDS2: // Kommando BDS2 adr?
Get_ByteDataSet1(Param1);
break;
SET_BDS2: // Kommando BDS2 adr, data
Set_ByteDataSet1(Param1, Param2);
break;
GET_BPDS3: // Kommando BPDS3 adr, passw?
Get_ByteProtectedDataSet1(Param1, Param2);
break;
SET_BDS3: // Kommando BPDS3 adr, data, passw
Set_ByteProtectedDataSet1(Param1, Param2, Param3);
break;
STIME: // Kommando 19:18:30
// Setzt die Uhrzeit Std, Min, Sek
Set_Time( Param1, Param2, Param3 );
break;
SDate: // Kommando D 15.03.2008
// Setzt das Datum Tag, Monat, Jahr
Set_Date( Param1, Param2, Param3 );
break;
SProgTime: // Kommando ST 1, 2, 08:30 (Abschaltzeit Montag 8:30)
// Setzt eine Programnmierzeit für einen Wochentag
Set_ProgTime( Param1, Param2, Param3 );
break;
GProgTime: // Kommando ST 3, 2? (Abfrage der zweiten Schaltzeit für
Mittwoch )
// Fragt eine Schaltzeit eines Wochentages ab
Get_ProgTime( Param1, Param2, Param3 );
break;
GVersion: // Kommando V?
GetVersion();
break;
default: // Unbekannter Befehl, Fehlerhinnweis senden
SendErrorInfo(cmd_str);
}
Im Prinzip könnte das wie oben aufgebaut sein. In CMD wird das erkannte
Kommando (#define, enum) abgelegt. In Param1-3 die mitgelieferten
Parameter. Im Switch wird die Bearbeitungsfunktion mit den zugehörigen
Parametern aufgerufen. Einleitungssequenzen für Kommandos können
natürlich auch wie von Dir vorgeschlagen aussehen (!, ?, @). Das bringt
mich noch auf eine Idee. !DS1, P#, P1, P2, ...PN\CR\LF würde bedeuten
Setze Data Set 1, es folgen P# (Anzahl) Parameter P1...PN.
Zunächst mal wird es nur darum gehen, in eine Interne Datenstruktur an
einer bestimmten Adresse ein Byte zu schreiben oder zu lesen. Geh mal
von 3 Datesets aus wobei das dritte Passwortgeschützt ist.
Wenn noch genug Speicherplatz bleibt, könnte man auch komfortablere
Befehle realisieren wie das Setzen der Zeit, Datum, Schaltzeiten,
Versionsabfrage usw.
Wäre schön, wenn Du ein Grundgerüst für den Parser liefern könntest mit
den zwei Schnittstellenfunktionen:
void Parser_ReceiverChar( char c); und
void ParseCmd( string str);
Die anderen Funktionen kannst Du als gegeben annehmen. Wenn das Gerüst
mal steht, kann man es relativ leicht um weitere Befehle erweitern, die
Namen der Befehle ändern bzw. die Anbindung vervollständigen.
Im Moment schlage ich mich mit dem Thema Regelungstechnik rum. Dabei
habe ich ein Problem mit dem Integrierer. Wenn die Temperatur ständig
über der eingestellten steht (z.B. Thermostat steht auf 16°C und Raum
ist aber über 18°C Warm, dann summiert der Intergrierer ins unendliche.
k
Ik = Sum (Soll-Ist)
0
Wo legt man da sinnvollerweise eine Grenze? Werden negative Werte
zugelassen?
Empfiehlt sich für eine Simulation der Heizstrecke ein PT2 glied und von
welchen Totzeiten (Tu) für das Ansprechen und T95 (Zeit für erreichen
von 95% der Solltemp.) kann man in der Praxis bei einer Heizung
ausgehen. Das hängt natürlich von Raumgröße, Heizkörper,
Vorlauftemperatur, Isolation, Aussentemperatur ab. An die
Heizanlagenpraktiker: Wie ist die zu erwartenden Bandbreite für das
Ansprechverhalten (Tu, T95) der Heizung?
Je wärmer schon ein Raum ist, desto langsamer vollzieht sich wohl ein
zusätzlicher Temperaturanstieg. Wenn das Ventil linear ausgefahren wird,
ändert sich der Durchfluß auch linear oder überproportional?
Falls sich jemand mit der Thematik auskennt, wäre ich für ein paar Tips
dankbar.
Gruß
Karim
Ich kann mir mal meine Gedanken machen, wie Prinzipiell das ganze
Aussehen soll.
Erst muss die Basis stehen, also das Protokoll, dann kann ich die Parser
Routinen machen.
Dann wäre es aber wohl Sinnvoll wenn ich auch SVN Zugriff hätte.
Ich muss aber gleich von Vorne herein sagen, das ich Zeitlich etwas
knapp bin. Wenn dann kann ich nur am Wochenende, aber Nächste Woche hat
das ja 4 Tage ;-)
Ich würde mir dann das Protokoll zu Ende denken, Grob Notieren und dann
den Parser schreiben und testen.
Gruss
Juergen
Hallo Dario, Hallo Karim,
Ich habe mir jetzt erst mal WinAVR und Co installiert (Arbeite
normalerweise mit Linux). Danke der Anleitung im SVN war das ja einfach
:-) Danke an den Autor.
Allerdings lässt sich das aktuelle SVN nicht übersetzen. Das sind ein
paar ";" an der falschen Stelle. Und ein Kommentar ist wohl falsch ("/*"
statt "//").
wie gesagt werde ich mir das mal ansehen und meine Gedanken zu einem
Protokoll machen und versuchen einen Parser aufzusetzen.
Wäre es Möglich auch SVN Zugriff zu bekommen ?
Dann könnte ich meine Ideen dort direkt pflegen und so schneller
Feedback von Euch bekommen.
Gruss
Jürgen
Hi Dario
natürlich kannst du mir Fragen stellen. Aber bitt direkt an:
peters-lothar@online.de
PS. dass diese Elektronik keinen aufwendigen Speicher besitzt, habe ich
mir schon gedacht...
Aber.. nun.. ich bin kein Elektroniker.. aber man könnte doch -so fern
man alles richtig macht und diesen Aufwand betreiben möchte -
Parallele Stromversorgung vorsehen oder nicht ?
Ich meine, wenn man zusätzliche Akkus vor dem Wechsel kontaktiert dann
habe ich doch - parallel - keine erhöhung der Spannung sondern nur die
Stromstärke erhöht - oder nicht ?
Es fließt doch kein größerer Strom und nach dem Kontakt der zusätzlichen
Akkus kann ich doch in aller Ruhe - sofern dieses Gefummel auf dem
beengten Raum glückt - die leeren Akkus entfernen. Oder ?
bis dann
Lothar
Hallo Lothar
Du schriebst:
> PS. dass diese Elektronik keinen aufwendigen Speicher besitzt, habe ich> mir schon gedacht...
Da hast Du mich falsch verstanden. Die Elektronik hat einen solchen
Speicher. Die Frage ist aber, ob die Programmierer den auch benutzt
haben.
Ich habe es gerade einmal getestet bei einem Original 2.04er:
Man kann die Batterien wechseln und danach ist die Programmierung noch
vorhanden, nur die Uhrzeit muss man neu stellen.
Dario
@jsachs: Mit welcher Distribution? Unter Gentoo habe ich die passende
Crossdev-Toolchain recht fix installiert bekommen, danach mußte ich halt
noch einzelne Änderungen am Code vornehmen ...
Ich hatte mir auch mal ein paar Gedanken gemacht, was alles steuerbar
sein sollte. Hier mal ein Anfang:
- aktiviere/deaktiviere Debug output
- aktiviere/deaktiviere Echo
- show (and set) actual valveposition
- show and set timetable with temperatures
- show actual temperature
- show Time and date / DLS /Leap Jear
- show/set serial number
- show/set tuning Parameters (P,I,D,DB (DEADBAND) - for PID controller?)
- show Battery Voltage
- show Battery Change Date
- show/set Mode (Auto / Manual)
- show Last-Error Log min-temp - max-temp
- show Calibration Data / start Calibration
- show/set valve Lift minEnd maxEnd
- show/set window function (max-time, temp-fall responsiveness)
- show/set valve-protection (ON/OFF, period)
- show/set alarm (temp, battery)
- reset device / bootloader
- set password
- reset/download/upload Configuration
Jens Müller wrote:
> @jsachs: Mit welcher Distribution? Unter Gentoo habe ich die passende> Crossdev-Toolchain recht fix installiert bekommen, danach mußte ich halt> noch einzelne Änderungen am Code vornehmen ...
Ich nutze Suse Linux 10.3. Das ist auch nicht das Problem. Ich
programmiere AVRs schon Jahre unter Linux in C(++). Anfangs auch in
Assembler, aber das war mir doch zu mühselig :-)
Die RPMs für Suse 10.3 sind die im OSS Repository.
Aber so ist es erstmal einfacher. Wenn alles Läuft kann ich das immer
noch unter Linux weiter machen :-)
So spare ich mir im Moment auch die Makefile pflege.
Danke trotzdem
Jürgen
@Dario und Karim,
Ich war mit meinem Protokoll schneller als das Wiki :-)
Habe das mal da eingetragen, bin aber schon viel weiter, aufgrund der
Diskussion hier.
Ich habe meinen Vorschlag mal im SVN unter "/doc/protokoll/"
einsortiert.
Und habe das auch fast schon Implementiert. Der Speicherverbrauch ist
Minimal, das meiste liegt im Flash.
Bin Momentan an den ISRs, dann kann ich das auf meinem atmega16 mal
testen. an meine HR20E will ich noch ned ran :-)
Mein Hauptproblem ist das ich noch keinen Umsetzer auf 3,3V habe.
Gruss
Juergen
Jürgen Sachs wrote:
> Mein Hauptproblem ist das ich noch keinen Umsetzer auf 3,3V habe.
Eventuell ein Daten-Kabel vom Siemens Handy vorhanden? Soll gehen!
--- Test auf eigene Gefahr ;-)
Hallo Jürgen,
elegant liesse sich das mit der RS-232 lösen, wenn Du einen Simulator
für den UART einsetzen würdest, wie es Ihn hier
http://www.helmix.at/hapsim/#hapsimdownload gibt. Dazu müsstest Du aber
auf Windows (das Standardbetriebssystem ;-) umsteigen oder nach einer
Lösung für Linux suchen.
Dann könntest Du Dir den ganzen Kabelsalat ersparen und das bequem
simulieren. Wäre super praktisch.
Gruß
Karim
Mal was zur Temperaturmessung:
Ich habe nun die Temperaturkennline versucht aufzunehmen. Dazu habe ich
ein Original HR20 genommen und in den Ansichtsmodus 02:02 gestellt
(Ist-Temperatur anzeigen) und mein Bastel-HR20 so programmiert dass es
mir immer den A/D Wert des Thermofühlers anzeigt.
Dann die beiden den PTC ausgelötet und einen Stecker angelötet.
Nun habe ich eine Spindeltrimmerkaskade 28k-58k an den original HR20
angeschlossen und den Poti so eingestellt, dass dieser 5C° anzeigt.
Dann habe ich den Poti an meinen HR20 angeschlossen und den ADC Wert
abgelesen. Daraus habe ich eine Tabelle erstellt.
Eine Funktion durch diese Messwerte zu legen war weniger erfolgreich.
Ein einigermaßen gutes Ergebnis konnte ich erst durch ein Polynom
dritten Gerades erzielen.
Zusätzlich habe ich ein normales Thermometer neben den original HR20
gelegt um die Unterschiede zu Messen, wobei ich darauf gekommen bin,
dass der HR20 immer 1-2°C weniger anzeigt. Es scheint som dass der
Temperaturunterschied in Heizungsnähe direkt bei der Messung
ausgeglichen wird.
All das veranlasst mich nun dazu die Temperaturkennline disket mit
einigen Messpunkten zu erfassen und dazwischen linear zu interpolieren.
Mit den folgenden Kennlinienpunkten bin ich schon ganz zufrieden.
ADC - Temp °C
675 - 5,0
614 - 10,0
549 - 15,0
472 - 20,0
397 - 25,0
340 - 30,0
304 - 34,0
Meine Idee ist nun folgende:
1
// Values for ACD to Temperatur conversion.
2
// Will be stored in EEPROM later, so they can be adapted later
Hier mal was zu dem Problem, dass einige die HR20 immer das Jahr
anzeigen, weil sie sich sporadisch resetten.
Ich habe jetzt auch einen HR20, bei dem das auftritt.
Nachdem ich das näher analysiert habe liegt es tatsächlich an den
Batteriekontakten. Konkret lag es in meinem Fall lag es nicht daran,
dass die Lasche von dem Zahnrad verschoben wird, sondern schlicht
daran, dass man durch einfaches Klopfen gegen den HR20 die Spannungs-
versorgung kurzzeitig unterbrechen und damit einen Reset auslösen
konnte.
Bei mit lag es an einer Kombination aus alten Akkus (mit korrodierten
Kontakten) und zu schwach eingestellten Federn. Wenn man den Hebel zum
Entfernen der Batterien dreht, sollten einem die Batterien schon ein
kleines Stück entgegenkommen. Ist das nicht der Fall ist Abhilfe leicht:
Einfach mit einem breiten Blech das Drehrad abhebeln.
(Das Drehrad ist nur über das Gehäuse geklippst).
Dann die Batterielaschen nach innen biegen.
Wenn alles richtig lief, stehen die Batterien jetzt ein deutliches
Stück am anderen Ende über und werden durch die Lasche in das
Gehäuse gedrückt.
Viel Erfolg
Dario.
Ich habe mal den Parser grundlegend eingebaut.
Allerdings musste ich aus technischen Gründen wieder zu Linux als
Entwicklungsumgebung wechseln. Ich hoffe es geht alles unter Windows.
Feedback willkommen !
- Im Moment gehen Notify für Temperatur, Version und Batterie.
- Im Moment gehen Kommandos für Temperatur, Version und Batterie.
Allerdings Temperatur und Batterie noch mit Fake Werten. Ich muss erst
mal sehen wo ich die Echtwerte herbekomme.
Gruss
Juergen
Also bei mir geht's.
Insbesondere ist delay in main.h definiert.
Linking: main.elf
avr-gcc -mmcu=atmega169 -I. -gdwarf-2 -DF_CPU=4000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=obj/main.o -std=gnu99 -Wundef -MMD -MP
-MF .dep/main.elf.d obj/main.o obj/adc.o obj/lcd.o obj/rtc.o obj/motor.o
obj/serialprotocol.o --output main.elf -Wl,-Map=main.map,--cref -lm
- so lautet der Linker-Befehl bei mir.
Warum sieht das bei Dir so anders aus?
Ah jetzt ja.
Ich hab im Moment eine angepasste Umgebung am laufen, da ich zum
entwickeln einen mega16 nehme. Mir fehlt noch die 3V Anpassung für
meinen usbprogV3.
Da brauche ich nicht alle Programmteile.
Aber so wie das aussieht muss ich mir da jetzt was basteln damit ich
meinen HR20E direkt programmieren kann.
Spätestens bei der rtc.c ist Schluss mit Kompatibilität :-(
Und nachdem ich hier die Funktionen aufrufen muss, geht nichts mehr.
Danke, ich habe überall nach der Funktion gesucht, außer in der main.c.
Juergen
Eine Frage zu dem Seriellen Protokoll.
Hier kam der Wunsch auf Datasets zu lesen und zu schreiben.
Was genau soll hier geschrieben / gelesen werden ?
- Variablen
- EEPROM
- Flash
Wenn ich die Infos hätte könnte ich das Theoretisch (ich kann es nicht
testen) Implementieren.
Gruss
Juergen
Jürgen Sachs wrote:
> Eine Frage zu dem Seriellen Protokoll.> Hier kam der Wunsch auf Datasets zu lesen und zu schreiben.>> Was genau soll hier geschrieben / gelesen werden ?> - Variablen> - EEPROM> - Flash
Verstehe ich das so, das Du wissen möchtest was über den seriellen Port
alles Veränderbar/Abfragbar ist?
Zum HR-20
-soll Temp (Wert oder auch "off")
-man./auto
-Fenster-offen-Frkennung ein/aus
-Zeit/Datum & Programme + Temp´s (um alle von der Haussteuerung zu
setzen)
vom HR-20
-eingestellete Temp (kontrolle)
-Ventielöffnung in Prozent
-ist Temp (Messung des HR-20)
-Batterie Zustand (wenn es möglich ist den zu ermitteln)
Das fällt mir gerade ein und ist bestimmt nicht vollständig.
Gruß
Jan
Jan David wrote:
>> Eine Frage zu dem Seriellen Protokoll.>> Hier kam der Wunsch auf Datasets zu lesen und zu schreiben.>>>> Was genau soll hier geschrieben / gelesen werden ?>> - Variablen>> - EEPROM>> - Flash>> Verstehe ich das so, das Du wissen möchtest was über den seriellen Port> alles Veränderbar/Abfragbar ist?
Jein, hier wurde immer wieder das Wort Dataset lesen und schreiben
verwendet. Hier wollte ich wissen was gemeint ist.
Aktuell kann die Software (Theoretisch, ich konnte es noch nicht auf
einem HR20) testen:
- Temperatur
- Ventilöffnung
- Batteriespannung (laut Code kann man die messen, auch wenn ich laut
Schaltplan keine Verbindung zu einem AD Eingang sehe)
- Version
- Uhrzeit
Generell werden alle Veränderungen Automatisch gemeldet, die Uhrzeit nur
jede Minute.
Im Moment kann man nur manuell einen "Calibrate" des Ventils auslösen.
Rein sollte (Übernehme ich nachher ins Wiki):
- Soll Temp setzen
- Manuell / Auto Umschaltung
- Datum / Zeit Einstellung
- Sommer Winterzeit setzen
- Programm für die Wochentage 1-7, vermute hier auch 2 Zeiten pro Tag
- Temperatur für Absenk Temp und Normal Temp
- Bootloader starten für Update
Setzen und abfragen, wo möglich.
Aber mir ginge es um die Datasets, oder war hier die Tagesprogramm
Programmierung gemeint ?
Gruss
Juergen
"- Batteriespannung (laut Code kann man die messen, auch wenn ich laut
Schaltplan keine Verbindung zu einem AD Eingang sehe)"
Vielleicht über einen integrierten Spannungsregler?
Jens Müller wrote:
> "- Batteriespannung (laut Code kann man die messen, auch wenn ich laut> Schaltplan keine Verbindung zu einem AD Eingang sehe)">> Vielleicht über einen integrierten Spannungsregler?
So wie ich das sehe hängt die Spannungsversorgung des uC nur an einem
Digitaleingang "PE6". Da aber genug Analog Eingänge frei sind, kann man
das sicher noch "Patchen" wenn man will :-)
Hauptsache wir bekommen eine Meldung "Battery low". Die Original
Software kann das ja auch.
Hallo,
hab gerade nicht viel Zeit. Nur soviel. Die Batt. Spannung wird dadurch
ermittelt, dass man die Refferenzspannung per interner Aufschaltung
misst, wobei man als Refferenz die Spannungversorgung des ADC verwendet.
Das kann man so programmieren und über den Weg ist es möglich die
Versorgungsspannung zu messen, ohne irgendetwas verdrahten zu müssen.
Die Datasets die gelesen und geschrieben werden sollen sind noch nicht
definiert. Dabei wird es sich aller vorraussicht nach um eine Struktur
handeln, die diverse Daten wie sie oben von Euch schon beispielhaft
aufgezählt sind enthalten.
Beschreiben und lesen geht dabei mit weniger komfort, weil einfach
bestimmte Bytes im Speicher bearbeitet werden und man genau wissen muss,
was man tut. Damit lässt sich alles setzen auch ohne das man High Level
Befehle dafür implementiert.
Gruß
Karim
Karim L. wrote:
> Hallo,>> hab gerade nicht viel Zeit. Nur soviel. Die Batt. Spannung wird dadurch> ermittelt, dass man die Refferenzspannung per interner Aufschaltung> misst, wobei man als Refferenz die Spannungversorgung des ADC verwendet.> Das kann man so programmieren und über den Weg ist es möglich die> Versorgungsspannung zu messen, ohne irgendetwas verdrahten zu müssen.
Wenn Du das sagst glaube ich dir mal :-) Hauptsache deine Funktion
liefert den richtigen Wert. Für mich ist die eine "Black Box".
> Die Datasets die gelesen und geschrieben werden sollen sind noch nicht> definiert. Dabei wird es sich aller vorraussicht nach um eine Struktur> handeln, die diverse Daten wie sie oben von Euch schon beispielhaft> aufgezählt sind enthalten.> Beschreiben und lesen geht dabei mit weniger komfort, weil einfach> bestimmte Bytes im Speicher bearbeitet werden und man genau wissen muss,> was man tut. Damit lässt sich alles setzen auch ohne das man High Level> Befehle dafür implementiert.
Hmm, das müssen wir mal genauer definieren. Weil das Dataset Kommando ja
wieder wissen muss wohin mit den Daten.
==============
Im übrigen bin ich nun soweit das ich einen funktionierenden Bootloader
für das XModem Protokol habe. Habs Heute getestet, wieder mit meinem
mega16. Klappt prima mit Hyperterminal.
1) File auswählen
2) senden drücken
3) AVR rebooten
4) Übertragung startet
5) wenn fertig wird wieder ins Hauptprogramm gesprungen
Allerdings ist der mega169 Bootloader viel größer, vermutlich durch
andere Startfiles. Das sehe ich mir noch an.
Ich habe hier auf fertige Routinen zurück gegriffen, siehe File Header
im Unterverzeichnis "Bootloader/hr20boot.c".
Leider braucht der fast 1 kb. hier kann man viel machen, aber unter 512
Byte zu kommen halte ich für fast unmöglich. Als Größe haben wir eben
512 Byte, 1 kByte oder eben 2 kByte.
==============
Das nächste Problem ist die Größe des eigentlichen HR20 Programms.
Ohne Optimierung ist es 15 kb groß, mit nur noch 9kb.
Auch das sehe ich mir an, aber so war es gedacht, das der Compiler hier
viel Optimieren kann.
Gibt es einen Grund das Ihr noch ohne Size Optimierung arbeitet ?
Gruss
Juergen
Den Code hat bisher Dario geschrieben. Der hat schon einige Erfahrung
damit und hat das so schnell geschrieben, dass ich da nicht ganz
mitkomme. Hab hier und da zu der einen oder anderen Idee beigetragen und
beschäftige mich zurzeit mit der Regelungstechnik.
Beim Bootloader dachte ich an den Einsatz dieser
http://avrubd.googlepages.com/avrub.htm Version, weil man die auch für
andere Megas einsetzen kann und sich dann nicht alles wieder neu
zusammensuchen muss.
Wenn der AVR losstartet, sollte er eine Checksumme über den Codebereich
ermitteln und mit einem Eintrag im Code vergleichen. Stimmen beide
überein, ist alles ok und es wird zur Main Routine der Hauptapliaktion
verzweigt. Wenn nicht, wird der Bootloader gestartet, der dann auf Daten
an der Schnittstelle wartet und im Display wird boot ausgegeben oder ein
Punkt blinkt.
Die Checksumme muss man entweder ins EEprom schreiben, auf eine Adresse
legen, die bei der Checksummenbildung nicht miterfasst wird oder den zu
brennenden Code zweistufig generieren. -> Code erzeugen, Chaecksumme
berechnen, Checksumme in Code (Konstante) eintragen, Komplement für
Checksumme berechnen und ebenfalls eintragen die dafür sorgt, das die
erste Eintragung neutralisiert wird, so dass die Checksummeneintragungen
nicht die bereits ermittelte Checksumme ändert, Code erneut übersetzen
und flashen.
Diese Prüfung sichert, dass bei fehlerhaftem Flashen der Bootloader
wieder aufgerufen wird und nicht ein JTAG nötig wird, um das Modul
wieder in Gang zu setzen.
Der Bootloader sollte auch vom Menü startbar sein und muss es auf
jedenfall per Befehl an der Schnittstelle.
Gegen den Einsatz der Optimierung spricht nix ausser das es beim
Debuggen Probleme bereiten kann. Da sollte es ein Pragma geben, um
gegebenenfalls gezielt Bereiche ohne Optimierung übersetzen zu können,
in denen man einen Fehler suchen möchte.
Wenn jetzt schon 9kB mit Optimierung verprasst sind, werden wir
wahscheinlich den Code etwas straffen müssen.
Den Zeitaufwand habe ich etwas unterschätzt. Muss sagen, dass ich nicht
soviel Zeit spendieren kann, wie ich gerne würde, so dass es bei mir nur
in keinen Schritten weiter geht und mansche Dinge wollen erst erarbeite
sein. Bitte daher nicht böse sein, wenn masche Antwort auf sich warten
lässt.
Gruß
Karim
Karim L. wrote:
> Beim Bootloader dachte ich an den Einsatz dieser> http://avrubd.googlepages.com/avrub.htm Version, weil man die auch für> andere Megas einsetzen kann und sich dann nicht alles wieder neu> zusammensuchen muss.
Ich habe mich mal auf XModem festgelegt. Das ganze ist ebenfalls sehr
einfach portierbar und wir brauchen keine zusätzliche Software zum
FLashen schreiben.
Allerdings will ich den jetzt kleiner kriegen, daher wird die
Portierbarkeit leiden.
> Wenn der AVR losstartet, sollte er eine Checksumme über den Codebereich> ermitteln und mit einem Eintrag im Code vergleichen. Stimmen beide> [...]> Diese Prüfung sichert, dass bei fehlerhaftem Flashen der Bootloader> wieder aufgerufen wird und nicht ein JTAG nötig wird, um das Modul> wieder in Gang zu setzen.
Das habe ich mal soweit geprüft. Es wird im Bootloader gestartet, und
nach ca 10 Sekunden in die Applikation gesprungen. Steht hier nur Müll
resetet der Atmel (oder eben Manuell) und springt wieder in den
Bootloader. Hab das mit ner Übergroßen Mülldatei probiert, war kein
Problem.
Sol wirklich eine Checksumme rein, könnte man auch folgendes machen:
- nach erfolgreichem übertragen der Firmware wird eine Checksumme
berechnet und vom Controller in die letzte Page vor dem Bootloader
geschrieben. kostet allerdings 128 Byte (Seitengröße).
> Der Bootloader sollte auch vom Menü startbar sein und muss es auf> jedenfall per Befehl an der Schnittstelle.
Jep, kommt als nächstes. Sollte kein Problem sein, Eventuell über einen
Reset durch den Watchdog. Geplant ist aber ein direkter Sprung in den
Bootloader.
> Gegen den Einsatz der Optimierung spricht nix ausser das es beim> Debuggen Probleme bereiten kann. Da sollte es ein Pragma geben, um> gegebenenfalls gezielt Bereiche ohne Optimierung übersetzen zu können,> in denen man einen Fehler suchen möchte.> Wenn jetzt schon 9kB mit Optimierung verprasst sind, werden wir> wahscheinlich den Code etwas straffen müssen.
Ja, ich habe mir mal angesehen was den Code so aufbläst. Ich bin kein
Assembler Spezialist, aber was der Compiler ohne Optimierung macht ist
... (Das ist klar, man sagt mach mal und Optimiere nichts).
Aber das aus einer Funktion die nur einen Wert einer Variablen Meldet 40
Befehle werden... Mit Optimierung ist es wie es sein soll.
Am Code sehe ich nicht allzu viel Optimierungs Potential ohne das die
Lesbarkeit leidet. Zudem muss man dran denken, das Funktionen wie ATOI
und ITOA auch etwas Platz brauchen. Aber kürzer bringt man das fast
nicht hin.
> Den Zeitaufwand habe ich etwas unterschätzt. Muss sagen, dass ich nicht> soviel Zeit spendieren kann, wie ich gerne würde, so dass es bei mir nur> in keinen Schritten weiter geht und mansche Dinge wollen erst erarbeite> sein. Bitte daher nicht böse sein, wenn masche Antwort auf sich warten> lässt.
Ja, mir geht es hier ähnlich. Was ich Heute nicht schaffe und evtl
Morgen, bleibt liegen bis zum nächsten Wochenende.
Ich muss jetzt nur zusehen wie ich den HR20E geflashed bekomme mit
meinem usbprogV3. Das Levelshifterboard macht ja 3.3V, das ist etwas
viel nehme ich an.
Dann könnte ich endlich mal am Lebenden Objekt testen. Im Moment ist nur
noch alles Theorie und Simulator.
Gruss
Juergen
Karim L. wrote:
> Für die Pegelanpassung kannst Du einen MAX3222 verwenden, den es z.B.> bei Rechelt gibt:
Für die RS232 ja. Mir geht es im Moment erst mal um den JTAG. Irgendwie
muss mein Bootloader ja mal in den HR20E rein ;-)
> http://www.reichelt.de/?SID=28JATM4qwQARwAAAUphcs495a2de94ead88ac931d991e5f91449e;ACTION=4>> Datenblatt:> http://www.ortodoxism.ro/datasheets/maxim/MAX3222-MAX3241.pdf
Verflixt ich habe nur den ST232CN hier. Der kann nur 4,5 - 5,5V.
> Spannungsversorgung kannst Du dabei vom Modul anzapfen.
Mein Hauptproblem ist das ich nachher an ein Modul ran muss das im
Moment auf 5V Designed ist. Das aber nur mit RX un TX. Aber da bastle
ich mir was. Das schöne ist das ich die Invertierung der Signale an
meinem Modul beeinflussen kann. Ich nehme an hier baue ich mir was mit
zwei Transistoren und 2 Pullups. Ich bekomme ja nie negative Spannungen,
dann sollte das einfach gehen.
Ob das auch beim JTAG geht weis ich nicht. Aber ich glaube da ist keine
Signal Bidirektional ?!
> Finde es gut, wenn mehrere an dem Projekt arbeiten, weil es entlastet.> Ein etwas höherer Aufwand entsteht dabei mit dem Koordinieren und das> der rote Faden nicht verloren geht.
Das Problem hat man immer wen mehrere an einem Projekt arbeiten. Aber es
klappt doch prima im Moment !
Jeder hat seinen Bereich.
Gruss
Juergen
Du kannst zum Flashen an den Batterieanschlüssen vom HR20E von einer
externen Qeulle oder dritte Batterie 4.5-5V drauf geben. Der Atmel kann
dass schlisslich und beim Rest der Beschaltung sehe ich kein Hindernis.
Aber achtung, die Spannung darf nicht höher sein. Hatte schon mal mit
einem Spike von meinem Netzteil ein Modul ins Nirvana befördert.
Ansonsten müsste es auch mit einem Inverter per Transistorschaltung
gehen, um ein 3.3V an ein 5V System anzukoppeln auch wenn nur 3.3V zur
Verfügung stehen. Musst aber schauen ob die Signale schon invertiert
sind oder nicht. Eventuell brauchst Du dann zwei Invertierer
hintereinander.
Gruß
Karim
Karim L. wrote:
> Du kannst zum Flashen an den Batterieanschlüssen vom HR20E von einer> externen Qeulle oder dritte Batterie 4.5-5V drauf geben. Der Atmel kann> dass schlisslich und beim Rest der Beschaltung sehe ich kein Hindernis.> Aber achtung, die Spannung darf nicht höher sein. Hatte schon mal mit> einem Spike von meinem Netzteil ein Modul ins Nirvana befördert.
Aaaah, Supper... Da hatte ich bedenken das das geht.
Der usbProg kann Spannung vom USB liefern über ne Shotky Diode.
Eben nachgemessen. kommen 4,7V raus, perfekt !
Ich hatte da zuviel bedenken wegen Lichtschranke und Motor. Nicht das
die Treiber durch den höheren Strom kaputt gehen. Aber ist ja nur zum
Flashen.
> Ansonsten müsste es auch mit einem Inverter per Transistorschaltung> gehen, um ein 3.3V an ein 5V System anzukoppeln auch wenn nur 3.3V zur> Verfügung stehen. Musst aber schauen ob die Signale schon invertiert> sind oder nicht. Eventuell brauchst Du dann zwei Invertierer> hintereinander.
Jep, aber das ist kein Problem. Wie gesagt kann ich die Invertierung
auch in Software machen.
Besten Dank für die Tips.
Juergen
Karim L. wrote:
> Du kannst zum Flashen an den Batterieanschlüssen vom HR20E von einer> externen Qeulle oder dritte Batterie 4.5-5V drauf geben. Der Atmel kann> dass schlisslich und beim Rest der Beschaltung sehe ich kein Hindernis.> Aber achtung, die Spannung darf nicht höher sein. Hatte schon mal mit> einem Spike von meinem Netzteil ein Modul ins Nirvana befördert.
@Karim
Ich habe das eben mal probiert. Aber ich scheitere schon am auslesen der
Signatur. Hier bekomme ich immer 0xFFFFFF.
Das hatte ich mit dem Pollin Board auch schon, da war die Verkabelung
dann falsch.
Ich habe es jetzt nach dem Bild im SVN unter
doc/steckerbelegung/steckerbelegung.jpg verkabelt.
Auch schon TDO und TDI vertauscht und zig mal geprüft.
Eine Idee woran das liegen kann ?
Hallo Jürgen
Du schriebst:
> Ich habe es jetzt nach dem Bild im SVN unter> doc/steckerbelegung/steckerbelegung.jpg verkabelt.> Auch schon TDO und TDI vertauscht und zig mal geprüft.> Eine Idee woran das liegen kann ?
Ich tippe mal es liegt am USB Prog!
Ich habe den auch und dazu die Pegelwandlerplatine [1] und damit habe
ich es auch nicht hinbekommen, weder zu programmieren noch die Signatur
auszulesen.
Mit meinem JTAG-Clone von Olimex[2], der an der seriellen Schnittstelle
hängt habe ich hingegen kein Problem, nur ist es da besser alles über
eine externe 3 Volt Quelle zu versorgen, weil meine alten Mignons nur
noch 2,3 Volt bringen und das nicht zum Betrieb des JTAG ausreicht.
Wie gesagt, mit dem USB-Prog habe ich es auch noch nicht geschafft und
ich habe mir einen Adapter HR20 auf JTAG[3] gebaut, den ich beim JTAG
und beim USB-Prog mit Flachbandkabeln benutze, daher schließe ich Fehler
in der Pinbelegung und der Verkabelung einmal aus.
[1] http://tinyurl.com/2alysy
[2] http://www.olimex.com/dev/avr-jtag.html
[3] http://www.carluccio.de/img/hr20/dev_board.jpg
Dario
Dario C. wrote:
> Ich tippe mal es liegt am USB Prog!>> Ich habe den auch und dazu die Pegelwandlerplatine [1] und damit habe> ich es auch nicht hinbekommen, weder zu programmieren noch die Signatur> auszulesen.
Ups, hab ich mir doch Heute auch den Pegelwandler bestellt. Wenn das
nichts hilft, wäre es echt schade... Eventuell liegt es ja am ATmega169
?
Anderes Timing oder der gleichen.
Im Zweifel löte ich die SPI an und führe diese nach draußen.
> Mit meinem JTAG-Clone von Olimex[2], der an der seriellen Schnittstelle> [...]
Hmm, noch einen Programmer wollte ich mir nicht zulegen, ich habe schon
2 :-)
Vielleicht bekomme ich ja mit meinem Oszi noch raus woran das liegt. Zur
not eben über SPI.
> [...]> und beim USB-Prog mit Flachbandkabeln benutze, daher schließe ich Fehler> in der Pinbelegung und der Verkabelung einmal aus.
Danke für die Links. So ein Adapter Board zu bauen hatte ich als
nächstes vor. Dummer weise ist einer meiner HR20E hinüber und ich muss
mein "Testobjekt" erst mal wieder in den Offiziellen Dienst schicken.
Dachte erst der hätte dieses Kontaktproblem an den Batterien, aber der
macht keinen Mukser mehr.
Danke fürs Feedback.
Juergen
Andy24 wrote:
> Habt ihr auf der basis von diesem Programm angefanngen oder komplett> neu?
Das ist eine komplette Neuentwicklung.
Die Hardware ist aderst aufgebaut und bietet mehr Möglichkeiten.
Es wäre auch sicher nicht klug das Herstellerprodukt 100% zu kopieren,
das könnte Rechtliche Probleme geben.
Was ist der Grund für deine Frage ?
Gruss
Jürgen
Das Programm was da angeboten ist, bedient bloss das vorgänger Modul,
dass nicht mehr verkauft wird. Beim neuen HR20E stehen leider die
Einstellfunktionen über die V24 nicht zur Verfügung bzw. wenn es welche
gäbe, sind sie nicht offengelegt.
Drum ist es nötig, die SW neu zu schreiben die im Modul steckt und eine
Schnittstelle zu implementieren, die wieder das Fernsteuern erlaubt.
Weiterer Vorteil wäre, dass man eigene Funktionen implemetieren kann.
Ein Programm wie das auf der verlinken Seite zu schreiben ist dabei das
geringste Problem. Das ist mit dem Visual Studio in C# schnell
geschrieben.
Gruß
Karim
Hallo,
finde das Projekt sehr gelungen und habe mich auch schon ein bischen
damit beschäftigt. Im Repository vermisse ich eine Datei HR20protocol.c,
die im Makefile explizit verlangt wird
.
.
## Compile
HR20protocol.o: ../source/HR20protocol.c
$(CC) $(INCLUDES) $(CFLAGS) -c $<
.
.
AVR Studio findet beim Zusammenbauen des Projekts einige Funktionen
nicht, die möglicherwiese in der fehlenden Datei sind, oder?
Gruss Wolf
Hallo Wolf,
Du schriebst:
> Im Repository vermisse ich eine Datei HR20protocol.c,> die im Makefile explizit verlangt wird
Jürgen Sachs hat in der rev 53 das Makefile komplett umgestellt.
Vorübegehend schlage ich vor Du lädst Dir das makefile aus einer
Revision davor z.B.: Rev 42.
Da steht dan drin:
Dario C. wrote:
>> Im Repository vermisse ich eine Datei HR20protocol.c,>> die im Makefile explizit verlangt wird
Die Datei ist nur zum Testen bei mir. Die wird nicht benötigt. Dieses
Makefile war nicht fürs Repo gedacht.
> Jürgen Sachs hat in der rev 53 das Makefile komplett umgestellt.> Vorübergehend schlage ich vor Du lädst Dir das makefile aus einer> Revision davor z.B.: Rev 42.
Das war so nicht gedacht. Das Makefile war nur zum Test nicht für das
Repo.
Danke für den Hinweis.
Das Makefile nochmals überarbeiten. Mir ist die komplette Umstellung gar
nicht aufgefallen.
Gruss
Juergen
W.-d. W. wrote:
> Hallo,>> finde das Projekt sehr gelungen und habe mich auch schon ein bischen> damit beschäftigt. Im Repository vermisse ich eine Datei HR20protocol.c,> die im Makefile explizit verlangt wird
Die Datei war nur für Tests gedacht, ebenso wie das Makefile.
Ich hab die Ursprüngliche Datei wieder hergestellt und angepasst.
> AVR Studio findet beim Zusammenbauen des Projekts einige Funktionen> nicht, die möglicherwiese in der fehlenden Datei sind, oder?
Bei mir unter Linux geht es problemlos.
Nur avr-size beschwert sich über nicht passende Parameter. Das ist aber
durch den Unterschied von winavr zu Linux avr tools gegeben. Da gibt es
einen Trick im Makefile, den ich mal einbauen kann.
Ich hoffe jetzt geht wieder alles.
Danke noch fürs Feedback.
Gruss
Juergen
Jürgen Sachs wrote:
> Ich hoffe jetzt geht wieder alles.> Danke noch fürs Feedback.
Hallo,
vielen Dank für die prompten Reaktionen.
Zu den bei mir gefundenen "Fehlern" etwas genauer (ich verwende AVR
Studio 4.13 SP2 und WinAVR 20071221):
Die Fehlerlemendungen beziehen sich auf in serialprotocol.c auf die UART
Register, die zum Mega32 passen, aber nicht zum Mega169P (!!). Ich hab
den Code erstmal so "umgebogen"
.........
#define UDR UDR0 <--- !
#define UCSRB UCSR0B <--- !
#define UDRIE UDRIE0 <--- !
// Functions
/*!
************************************************************************
*******
* Initialize and clear serial buffer, setup Baudrate
*
* \note
* - Initialize buffers
* - set Baudrate
************************************************************************
******/
void parserInit(uint16_t baud)
{
inBuffer.bytesInBuffer = 0;
outBuffer.bytesInBuffer = 0;
byteToSend = 0;
parserError = P_ERR_NONE;
parserErrorCmdType = CMD_TYPE_REPLY;
cmdComplete = false;
// Baudrate berechnen
//long ubrr_val = ((F_CPU)/(baud*16L)-1);
uint16_t ubrr_val = ((F_CPU)/(baud*16L)-1);
UBRR0H = (unsigned char)(ubrr_val>>8); <-------- UART Register
UBRR0L= (unsigned char)ubrr_val; <--------- Mega169P
/* Enable receiver and transmitter */
UCSR0B = (1<<RXEN0)|(1<<TXEN0);
/* Set frame format: 8data, 2stop bit */
UCSR0C = (_BV(UCSZ00) | _BV(UCSZ01)); // Asynchron 8N1
...
Damit funktioniert dann die Compilation.
Was mich nur wundert ist, warum es bei Euch keine Probleme gegeben hat?
An anderer Stelle allerdings berücksichtigt der Code schon gewisse
Besonderheiten des AVR169P z.B hier:
...
#ifdef AVR_IOM169_H
ISR(USART0_UDRE_vect)
#else
ISR(USART_UDRE_vect)
#endif
...
Gruss Wolf
W.-d. W. wrote:
> vielen Dank für die prompten Reaktionen.> Zu den bei mir gefundenen "Fehlern" etwas genauer (ich verwende AVR> Studio 4.13 SP2 und WinAVR 20071221):
Immer gerne, ich finde es gut wenn es auch jemand außer uns testet.
> Die Fehlerlemendungen beziehen sich auf in serialprotocol.c auf die UART> Register, die zum Mega32 passen, aber nicht zum Mega169P (!!). Ich hab> den Code erstmal so "umgebogen"
Gerade eben geprüft.
Ich habe für den Mega169 kompiliert, nicht für den Mega169p, da heisen
die Register anders. Ich sehe mir das an und baue da mal ifdefs ein.
Wenn ich noch richtig weis gibt es Platinen mit mega169 und mega169p.
Gruss
Juergen
Ich habe das jetzt mal umgebaut und die notwendigen ifdefs eingebaut.
Da sollten noch viel mehr Fehler auftauchen als in der "parserInit()".
Ich konnte das aber noch nicht testen auf einem "Target" da werde ich
erst am Wochenende dazu kommen.
Im Moment ist der Mega169 und der Mega169p unterstützt. Dabei dachte ich
immer die sind identisch und die "P" Variante ist ein Strom spar Typ.
Gruss
Juergen
Hi everyone
I have the same not serial responding version of HR20E
After inserting battery controller sends to Tx (9600 8-N-1):
HR20 SW Version 202 vom 09. Nov. 2005 12:00 HW Version 2
and later for an each 4 minutes:
>D: 2.4.2008 U: 19:31 V: 66 I: 2252 S: 2300
Best regards
Jürgen Sachs wrote:
>> Bei mir unter Linux geht es problemlos.> Nur avr-size beschwert sich über nicht passende Parameter. Das ist aber> durch den Unterschied von winavr zu Linux avr tools gegeben. Da gibt es> einen Trick im Makefile, den ich mal einbauen kann.>>
Hi,
ich hatte hier ( Beitrag "Re: Honeywell Rondostat HR20E per AVR steuern und konfigurie" )
schonmal eine Änderung am Makefile gepostet, die wiederum auf Jens
Müllers Beitrag aufsetzte. Das sollte dann unter Linux und Windows
gehen. Vielleicht kann das ja mal jemand unter Windows testen und dann
in Repoitory aufnehmen?
Ich muss jetzt erstmal mit meinem neuen AVR Butterfly rumspielen und in
den AVR einarbeiten, hoffentlich kann ich dann auch was beitragen.
Hallo,
ich habe mir einen JTAG ICE Nachbau bestellt. Der hat 27,33 EUR gekostet
und kann USB auf 3,3V.
Der Adapter spricht auch:
Setting device parameters for jtag programming .. OK
Entering programming mode.. OK
Reading signature.. 0x1E 0x94 0x05 ..OK
Leaving programming mode .. OK
Nur bei:
Reading fuse bits (low to high).. FAILED!
Beim Setzen der FUSE bits bin ich mir aber unsicher, sieht bei mir ganz
anders aus als bei \hr20\doc\fuses
wir verwenden doch alle die Version 4.13 Build 571
Also bei mir war das Problem eine zu Hohe Geschwindigkeit.
Kannst ja mal schauen ob das Drosseln kannst bei deinem JTAG. Nicht über
1/4 des CPU Takt.
Gruss
Juergen
Hi,
die Lösung:
Hello, Tobias.
Yes - I know about that. But this is not problem of hardware - this is
error in AVR Studio, you can find about this problem in Internet. You
use AVR studio 4.13 SP2, isn't it? Please reinstall AVR Studio to 4.13
SP1 version from CD and all must be ok. Please inform me - this is help
you?
Best regards, Sergey
Vielen Dank an Sergey
Jetzt habe ich auch die gleichen FUSES.
Hi,
http://www.atmel.no/beta_ware/as4/414rc1/releasenotes.txt
Atmel schreib unter Punkt : 6948 , das das Problem mit dem Lesen und
Schreiben der fuses in Version 4.14 RC1 behoben ist. Vielleicht ist das
ganze Bug Fix für unsere Entwickler interessant.
Hallo Entwicklerteam HR20E,
laßt uns bitte nicht im Stich. Wir warten hier draußen sehnsüchtig
auf eine Lösung zur Ansteuerung von HR20E per I2C bzw RS232. Da sich
aber seit einem Monat hier nichts mehr rührt, hoffe ich doch, das es mal
wieder weiter geht. Meldet Euch doch mal, wie der aktuelle Stand
ist.
Mit vielen Grüßen
Detlev
Hab im Moment ziemlich Stress an allen Fronten. Hab das Projekt aber
nicht abgehakt. Muss erst mal wieder Kräfte sammeln, bevor ich mich
wieder dran geben kann. Arbeit gibt es schliesslich noch genug. Freut
mich aber, das ich nicht der Einzige bin, der Interesse am I²C Bus hat.
Kann leider noch nicht sagen, wann ich wieder dazu komme, etwas
beizutragen.
Gruß
Karim
Ja, I2C ist interessant, nur die Kabellängen sind doch nicht so lang
möglich. Oder? Die Steuereinheit wird ja an einem Zentralen Punkt sitzen
und Kabel zu den ganzen HR-20E im Haus gehen (Kabel liegen schon).
Gruß
Jan
Yep, Kabellänge könnte ein Problem werden. Allerdings ist I²C Bus nicht
so sehr schnell und der Master bestimmt den Takt, den man runter
schalten kann. Mit einem speziellen Protokoll kann man eventuell auch
auf einer schlechten Leitung arbeiten (Checksumme mitschicken,
bestätigung von Datenempfang, bei Fehler Daten neu anfordern,
Zeitfenster für Response usw.). Wird sich zeigen.
Also Ansteuerung über RS232 funktioniert schon recht gut.
Es fehlt noch an einigen Details wie die Programmierung der
Schaltzeiten.
Leider hat mich mein Rechner verlassen und ich muss alles neu aufsetzen.
Auch ist es Geschäftlich gerade mehr als Stressig.
Aber auch ich werde weiter machen an dem Projekt.
Meine nächste Idee wäre hier RS485. Das ist einfacher umzusetzen als
RS232. Zudem kann man über den freien Pin PE2 die Datenrichtung für den
RS485 umschalten. Leitungslänge ist kein Problem.
Dann wäre nur eine kleine Platine mit einem RS485 Wandler notwendig, die
man an den 10Pin des HR20E steckt.
Regelung der Heizung benötigt auch nicht viel Tempo bei der Ansteuerung.
Gruss
Juergen
Hallo,
bezüglich I2C noch einige Anmerkungen. Ich habe meine Haussteuerung
vollstänig mit I2C realisiert. Bezüglich der Kabellängen kann ich auf
folgenden Beitrag verweisen:
I2C als Feldbus (I2C mit langen Leitungen)
[[http://www.cc2net.de/Tips/tips.html]]
dort wird von bis zu 50 Meter Leitungslänge berichtet. Die bei mir
realisierten Leitungslängen betragen maximal ca. 15 Meter. Bei cc2net
gibt es übrigens nützliche Bausteine für den I2C z.B. I2C-Bus-Extender,
I2C-Koppler, I2C-Tranceiver usw.
Viele Grüße
Detlev
Hallo zusammen,
ich habe mich nicht durch das ganze Forum gelesen, da doch einiges zu
lesen da ist. Jedoch habe ich erfahren, dass es wohl Probleme gibt/gab
bei unterschiedlichen Versionen von Rondostat.
Mein Anliegen ist folgendes:
Ich möchte den Rondostat ebenfalls mit RS232 ansteuern. Andernfalls
würde ich die Taster und den Drehgeber Simulieren.
Kann man den Speicher über RS232 auslesen und neu beschreiben?
Möchte die Parameter für die Regelung später mit einem Touchscreen
einstellen können (eDip 240-7).
Vielen Dank für eure Hilfe.
@ h.fuchs
Du schriebst:
> ich habe mich nicht durch das ganze Forum gelesen,> da doch einiges zu lesen da ist.
Was erwartest Du nun von uns?
Das wir Dir den Thread vorlesen?
SCNR.
Dario
vielleicht erwartet er deiner Ansicht nach zu viel und möchte doch bitte
im Thread nachlesen. Aber 1.) ist deine Antwort wenig konstruktiv und
2.)wäre es schön, wenn sich Leute - die offensichtlich so
hochqualifiziert sind wie die Teilnehmeer in diesem Forum - einmal
Gedanken über eine interne Suchmaschine machen könnten. Programmierer
wissen sicherlich wovon ich rede. Das wäre allerdings in tausenden von
Foren und anderen hilfreichen Seiten angebracht. War nur n Vorschlag.
Gruß
Lotharaus Hürth
Im Moment ruht das Projekt und ist nicht soweit, dass man den Rondostat
mit der neuen SW verwenden kann.
Tastatur und Drehgeber kann Fuchs zwar simulieren wenn er will aber das
ist Murks hoch 10. Viel spass dabei.
Hab noch ein technisches Problem mit meinem neuen Notebook und immer
noch keinen Programmer. So bald beides verfügbar ist, werde ich mich
wieder an das Projekt geben. Kann aber noch einen Monat dauern. Optimal
wäre es, wenn es bis zu den Ferien hinhaut. Denke mal, dass wir aber
dieses Jahr noch eine verwendbare Release hinbekommen werden (hoffe es
zumindest).
Der Thread ist zu lange und da hier jeder Posten kann, ist viel dabei,
dass besser gelöscht gehört. Vielleicht sollte man einen neuen Thread
aufmachen.
Gruß
Karim
Karim L. wrote:
>> Tastatur und Drehgeber kann Fuchs zwar simulieren wenn er will aber das> ist Murks hoch 10. Viel spass dabei.
Hatte ich auch erst überlegt, aber hat einfach zu viele Nachteile. Der
Größte: keine Rückmeldung!
>> Der Thread ist zu lange und da hier jeder Posten kann, ist viel dabei,> dass besser gelöscht gehört. Vielleicht sollte man einen neuen Thread> aufmachen.>
Dadurch gehen aber viele Infos flöten die sich immer dazwischen befinden
und es gibt bestimmt schon sehr viele die hier nach dem Fortschritt
schauen. Ein neuer Thread ist auch nicht vor "vielen" Posten geschützt.
Wenn man nun aber auf einen geschützten Bereich wechseln würde, gebe es
keine neue Unterstützung und passive Zuschauer mehr.
Hallo,
ich würde als nächstes gerne 485 Implementieren, die rs232 geht schon
recht gut.
485 daher, da Protokoll usw gleich bleiben kann und nur ein weiterer Pin
notwendig ist. Das Protokoll wäre dann aber, zumindest im ersten
Schritt, Master Slave, die einzelnen HR20 werden also gepollt, jedoch
Intelligent.
Master -> Slave : Hast Du was neues ?
Slave -> Master : Antwortet mit Neuigkeit oder "NONE"
Master -> Slave : frägt solange bis None zurück kommt und dann den
nächsten. Das natürlich "gemächlich", wir wollen ja Strom sparen :-)
Würde man den RS485 4 Adrig ausführen, könnte man die
Spannungsversorgung mitführen, also +12V (oder weniger), A, B, GND.
Die Umschaltung RS485 auf RS232 erfolgt zum einen Automatisch über die
Erkennung der externen Platine und optional über einen neuen Befehl.
Die Erkennung der Externen Platine würde über einen Widerstand an der
"PE2" Leitung am 10 Pin erfolgen. Dieser "R" sorgt auch dafür das ohne
angeschlossenen HR20 der Treiber auf Empfang steht.
Auf der Platine wäre dann:
- RS485 Wandler
- Spannungsaufbereitung 12V auf 3V für HR20E
- "R" für Erkennung
Würde also sehr kompakt möglich sein.
Wäre das so OK ?
Zu I2C. Bei I2C sollte man das Protokoll ganz anders aufbauen. Generell
müssten dort alle Daten "I2C" Typisch als Byte Array verfügbar sein und
jeweils einer bestimmten Funktion zugeordnet sein. Byte 1 Also MAX Temp,
Byte 2 MIN Temp usw. Der I2C Master entscheidet wie viel Bytes er liest
und demnach welche Werte er bekommt.
I2C wird eher nicht wie eine RS232 zum Transport eines richtigen ASCII
Protokolls benutzt.
Zum Temperatur Preset für die Wochentage sollte man sich überlegen was
man alles Möchte. Ich vermute 4 Schaltzeiten pro Wochentag sind mehr als
genug. Wenn man mehr will kann man ja vom Zentralen Controller über den
Bus eine Virtuelle Einstellung über z.B. Preset 0 vornehmen und damit
unbegrenzte Schaltzeiten fahren. Der Controller muss dann eben jede neue
Schaltzeit laden.
Gruss
Juergen
Wenn die Platine in eine Unterputzdose passt wäre dass sehr hilfreich.
Zu den Schaltzeiten: Es ist richtig das der externe Controller das
übernehmen kann, ist bei mir ja auch so geplant. Aber einige wollen den
HR-20 noch allein laufen lassen, was bei mir nur bei
Haussteuerungsausfall gedacht ist.
Die Platine würde eher direkt an dem HR20E sitzen, eben an dessen 10
Poliger Schnittstelle. Zumindest die erste Version. Was auch Sinn macht,
sonst muss man ja RX, TX, GND, Batt und PE2 zur Platine führen.
In eine UP-Dose passt Sie in jedem Fall.
Jetzt frei gedacht würde unten aus der Platine ein 10 Polige Buchse
ragen die in den HR20E gesteckt wird. Auf der Oberseite wäre dann eine 4
Polige Schraubverbindung für den RS485 Bus und die Bauteile. Ist der
HR20E so montiert das die Platine Richtung Wand Zeigt wäre Sie nicht zu
erkennen.
Es wäre eine Überlegung wert hier RJ11 oder RJ45 Stecker zu nehmen.
Allerdings braucht man dann zwei Buchsen auf der Platine um
durchschleifen zu können. Netzwerkkabel wären ideal für RS485, da
verdrillt und abgeschirmt und überall billig zu haben.
Der HR20E braucht bei einer Versorgung über den Bus natürlich keine
Batterien mehr.
Und Ja, der Zentrale Controller kann die Kontrolle übernehmen.
Wobei ich dazu tendieren würde, einen "Preset 0" zu schaffen, der nur
Temporär gültig und auch nicht ins EEPROM geschrieben wird. Wird dieser
aktiviert, regelt der HR20E nur noch nach dieser Einstellung. Wird
dieser deaktiviert, läuft alles nach den gespeicherten Presets.
Eine direkte Ansteuerung des Ventils halte ich nicht für Sinnvoll. Fällt
der Bus oder die Zentrale aus, kann es ganz schön Warm werden :-) Wird
nur die Solltemperatur vorgegeben, kann nichts passieren.
Ein Preset besteht hierbei aus Solltemperatur, der Startzeit sowie dem
zugehörigen Wochentag.
Die Endezeit wird ja durch die nächste Startzeit bestimmt.
Für die eigentlich Regelung brauchen wir ja nur die Solltemperatur, der
Rest ist schnick schnack ;-)
Abhängig von der Differenz Soll und Ist Temperatur wird dann das Ventil
angesteuert.
Gruss
Juergen
Ich hatte mir das so gedacht das es ein Kabel mit dem Pfostenstecker für
den HR-20 auf der einen Seite und ein RJ45 Stecker auf der anderen Seite
wird. In der Wand sitzt dann einfach eine Rj45 Dose und dahinter die
Platine. Von dort dann durch die Wand das Kabel zum zentralen Controller
(die Kabel liegen bei mir schon und sind IY (St) 6x2x0.6 Telefonkabel).
Der Controller soll dann immer nur die Soll-Temp vorgeben und der HR-20
regelt selbst, was dann auch die von Die beschriebene Ausfallsicherheit
bietet (gerade ja bei Selbstbauprojekten ;-))
Das Ganze ist ja auch mit der alten Version des HR-20 möglich, nur
leider bei der neueren nicht mehr was mir halt sorgen macht, da ich
leider bei der Umprogrammierung nicht mithelfen kann (und hier ist es so
ruhig geworden).
Gruß
Jan
Das Kabel sollte Ok sein.
Theoretisch sollte es kein Problem sein ob die Platine am HR20 sitzt
oder in der Dose. ABER: Der HR20E arbeitet nur mit 3V. Lange
Kabelstrecken sind mit dem Pegel nicht drin. Auch die Stromversorgung
wird schwieriger. Immer an die Störeinstrahlung denken.
Daher werde ich die Platine am HR20 befestigen und von dort auf mein
bestehende Verkabelung gehen (alles CAT5e).
Einzig die Optik ist nicht so schön wenn die Platine am HR20 hängt. Ein
Kabel geht so oder so zum HR20.
Mal sehen was ich da über die nächsten Wochen machen kann.
Gruss
Juergen
Kabelstrecke: Dosen immer max 30cm vom HR-20 entfernt.
Kabel von Dose zum Zentralen-Controller: bis 30m Cat3 - halt
Telefonkabel.
Wo ist denn der aktive Rest von hier geblieben?
Das Projekt ist noch nicht für den Produktiveinsatz geeignet.
Es gibt nur Grundroutinen, die Temperaturregelung und Zeitsteuerung
fehlen noch ganz.
Ich bin aber guter Dinge das es eine Alpha Version zu den kalten Tagen
geben wird.
Meine Kollegen haben hier ja schon gut vorgelegt.
Gruss
Juergen
Hallo an alle frimelfans!
meiner einer hatte seit 3 Jahren ne ZeitschaltUhr -verbunden mit einem
Heimeier stellschalter sag ich mal(funtioniert mit ne ausdehnugnskissen
bei 230 Volt)
meine Idee war noch nene temperaturfühler zu integriere, aber , das teil
macht einfach zu viel lärm, weil es das Ventil in ruckartigen stößen
bewegt, also besser nicht kaufen( macht kanck-knack knack, im
sekundentackt)
Erinnerte mich immer um 22:00 Uhr, das es Zeit wird schlafen zu gehen
:-)
so nun bin ich auch an dem HR20E dran, scheint lautlos zu sein,
zumindest leiser, wie der Wassserfluss durch die Heizung.
Uhrsrünglich wollte ich einfach das Bedinteil per Kabel verlängern, weil
ich nicht unter dem Flipper zur Heizung kriechen will um es mir wärmer
zu machen. aber die Idee, es per PC zu steuern, der eh immer an ist,
gefällt mir(in jedem fall zusätzlich), das bedienteil kommt ans Sofa,
das steht fest.
Der anfang des Threads klang gut und einfach, aber nun Version 2.04?
Keine einfache möglichkeit, wie von:
http://kulknet.homeip.net/Steffen/Softwareprojekte/RondoSet/RondoSet.htm
na einfach war es für ihn nicht, aber es hat geklappt.
Also nehm doch bitte wieder den roten Faden auf.
Mein wunsch wäre: Rondostat --> USB --> Sorftware einstellen ,
Temperatur in der taskleiste anzeigen.
((Hotbutton, damit sich die weiblichen besucher ausziehen, weils so warm
wird ::--))
mein Betrag wäre testen/hr20e zerstören zur not, und mit viel geduld
auch was mit Visual C++
Hallo zusammen,
ich habe zwar schon einige Erfahrung mit AVRs aber noch nicht im
Zusammenhang mit JTAG, deshalb eine Frage. Verstehe ich das Richtig,
dass durch die Einstellung der Fuses im Originalzustand der Weg zu einer
eigenen Firmware eine Einbahnstraße ist? Oder gibt es eine Möglichkeit
die originale Firmware über das JTAG Interface auszulesen und bei
Problemen zurück zu spielen?
In der PDF-Doku habe ich außerdem gelesen: "Um das Verhalten der
Spannung in Abhängigkeit der Temperatur zu messen, wurde die Funktion
der Originalsoftware genutzt, welche die Ist-Temperatur kontinuierlich
auf dem Display anzeigt." Wie bringe ich die Firmware dazu die
Ist-Temperatur anzuzeigen? Ich habe gefunden wie das mit der alten
Version geht, aber zu der 2.04 um die es hier geht finde ich das leider
nicht.
Danke schonmal
Sebastian.
Hallo,
ich versuche gerade, einen hr20e mit einem Atmega16 anzusteuern, komme
aber nicht weiter.
Zwar empfange ich beim Einschalten die Versionsmeldung des HR20e, aber
mehr klappte bisher nicht.
Sende ich einen Lese- oder Schreibbefehl, erhalte ich "not implemented"
zurück.
Den Atmega versorge ich über die Stiftleiste am Thermostat. RX und TX
habe ich direkt verbunden, ohne Widerstände, PullDowns usw.
Der Atmega hat einen externen 4Mhz Oszillator.
Im Anhang mal das Code-Schnipsel (Avr-gcc), das die "Adresse" 136 lesen
soll.
Ergebnis ist "not implemented". Bei Befehlen erhalte ich auch nur "V02"
zurück anstelle von z.B. "M1231234".
Die Pausen zwischen den chars musste ich einbauen, ansonsten kommt
überhaupt keine Rückmeldung vom hr20.
Die LCD-Ausgabe im Interrupt ist natürlich Murks, aber zum Testen tut
es.
Vielleicht hat jemand einen Tip?
Gruß,
Freisi
Hello,
Due to problem with https://OpenSVN.csie.org/hr20 repository we have
another source repository on https://sourceforge.net/projects/openhr20/
Current status on project:
- it is able use it as controler for fixed temperature
- complete new light serial protocol (incomplete, but possible to use)
- timers is not implemented (I am working on it)
- LCD menu+keys is working, but without timer programing, service menu
allow setup internal parameters (hold all fronend buttons)
What you can to do?
1) test it, or try to tune PID controler
P constant is at configuration position 05
I constant is at configuration position 06
D constant is at configuration position 07
scale for constants is at configuration position 08
2) improve Doxygen documentation
3) any sugestion is welcome. If you wan't make some changes at code,
please inform me. I would like prefer to do not make conflicts in code.
Asks:
Karim L.: Can I use
http://img407.imageshack.us/img407/3056/burgtwisterplatinest3.jpg in
project documentation
jdobry wrote:
> Due to problem with https://OpenSVN.csie.org/hr20 repository we have> another source repository on https://sourceforge.net/projects/openhr20/
I am not aware of any problems...
I can still use the old repo.
Also some revision are missing in the new one. this is no good. We
should not use two repos to gain the same project...
I would prefer to continue with sourceforge, but first import ALL
revisions from the old one.
According to the wiki we are still using the opensvn.csie.org.
Maybe some other developers could clear up things.
Juergen
@jdobry,
you may use the Image for documentation.
For this kind of regulator as far as I analysed it, you can forget about
the D component and also the I component will not yield much
improvements. The original SW seems to use P regulator with some non
linear adjustments which has only slight effects. You will get quiet
good results with a simple P regulator. Unfortunately I have still no
time to continue the work although I still want it.
The old repository is still working fine and I would prefer to continue
using it.
Für die Anderen. Soweit ich das untersucht hatte, wirkt bei der Original
SW überwiegend ein P Regler mit ein paar nicht linearen Eingriffen, die
man aber auch weg lassen kann. Genauen Zusammenhang konnte ich noch
nicht ermitteln, die Abweichung vom P Regler ist aber gering. Wegen der
Trägheit des Systems reicht der P Regler aus.
Hab leider noch keine Zeit weiter am Projekt zu werkeln.
Gruß
Karim
I have this problems with https://OpenSVN.csie.org/hr20 :
1) slow communication 0-5kB/s (I have 5mbit/s connection)
2) too many lost communications. Example: when I try to create branch, I
must do it around 2 hours. Each try take around 1-2 minute and
communication was usualy lost.
If you wan't to use my sources, it is also under GPL. It is completly
rewriteln, because old code from https://OpenSVN.csie.org/hr20 is too
buggy.
For example you can't use shared variables between interupts and main
code without locks. "volatile" keyword is not sufficient and have
different meaning. Temperature measurement for <5C is wrong. Battery
measure is wrong. Impulse counter from motor is wrong (real impulses is
aroud 737-740 and you measure 820-900) Code is too big, you will not
able add all of this parts (writeln with same style): keyboard, LCD
menu, configuration storage, wireless communication.
PS: you are right that "new" repository don't have all revisions. But
current code use very small part of old code. Compare it. For example,
communication is completly new.
I am able to realease beta version with more possibilities than original
2.04SW this or next week. But you can still use
https://OpenSVN.csie.org/hr20
@ Karim L.: thanks for picture, I will use it.
PS: Old code have problem with current throw pullups. It dramaticaly
reduce battery life. You must disable it temporary (1 wire from wheel
and 1 wire from "mont" contact).
Hello jdobry,
seems you have done a nice work. In my opinion the code was consuming to
much memory too. To the other points I can't say much, because I was not
involved.
But I think you found at least a good starting point of this orphan work
made mostly by Dario here. In case you want to take the scepter of the
project, I would please you to do a good documentation, so that every
body can reproduce the thoughts of the implementation and is able to
build the project by himself.
You might also publish work left to do or which is just in progress to
prevent double work or get support.
Best Regards,
Karim
Hallo Leute,
ich habe den Thread teilweise durchgelesen. Mich wundert, dass niemand
spezifisch auf den Regelalgorithmus eingeht. Ich habe hier im Wohnzimmer
den Funkthermostat von ELV. Leider sind die Eigenschaften des
implementierten Reglers eher ungünstig. Der Temperaturverlauf zeigt
zumindest bei uns ein starkes Überschwingen, wenn der Raum aufgeheizt
wird. Hier wäre eigentlich ein selbstoptimierender Algorithmus
notwendig, oder wenigstens die Möglichkeit, Regelparameter anzupassen.
Aber bei derart unterschiedlichen Konstellationen aus Anordnung von
Thermostat und Heizung, Raumgrößen, Wärmeverlusten, Heizleistung, Größe
der Heizkörper etc. gibt es halt keine optimale Variante.
ciao
Marcus
To Karim L: "double work" is nightmare of many projects.
This was main reason why I was post message to this thread about SVN on
SF.net (also created by Dario C.)
Current status is that I have many parts "in process". I have controler
part on my PC, but not tested and I am writing LCD menu for timer
programing.
I hope that reconstruction with basic functionality like original SW
this week. I will inform you about possible tasks.
But at this moment you can:
- add some "watched variables" into watch.c - nice for debug
- tune my PID setting in real situations, it may be completly wrong
- review my code. I am sure, that it contain bugs. I wrote it very
quickly and it need review. I can do it, but comebody other have another
point of view and it is better.
- setting and functionality for "auto lock" after timeout feature.
setting is 0=disable function, 1-255 is timeout to auto lock I have
small dauthers :-)
Later (please wait for my check in)
- menu.c is not optimized and it is not follow coding standard. May need
small rework.
Differences from original SW:
- 8 point of setting per day (original 4)
- 4 temperatures (original 2)
- service menu is another from original. For my code it is long press
all buttons. Original need press "PROG" button and switch on.
@Marcus,
wenn der Heizkörper zu groß ist bzw. eine zu hohe Wärmespeicherkapazität
hat, kann es zu einem überschwingen kommen. Mit einem klassischen Regler
bekommt man das Kaum in den Griff. Eher müsste man die Sprungantwort
ermitteln entlang der man das Ventil steuert in Kombination mit einem P
Regler, der kleinere Differenzen ausregelt.
@jdobry,
I can try to review your code and add smaller parts of code. But as I
said, I will currently have not the necessary time for a full support.
But others here may provide help as well.
For an adaptive valve control, it is required to have different hardware
valves or at least knowledge about existing differences on the market,
which I don't have. Some hints from heating engineers would be helpful
as well. But we can try to search for the required infos before
implementing an algorithm.
Hello,
For new valve calibration I need some data from more valves. If you want
to use OpenHR20 SW later, please send me data from your valve. For test
you need ttps://sourceforge.net/projects/openhr20/ SW !!revision 55 !!
After reset motor try to found calibration and send some data to serial.
I need this data and type of your valve. Please send me log (jdobry at
centrum dot cz).
This is example from my valve in graph. Blue is open, red is close. Y
scale is time between motor pulses.
http://img261.imageshack.us/my.php?image=valve1sg5.png
Jiri
Hi Jiri,
I have logged the output from four (three different)
valves with revision 55.
The results are stored here: http://datundwat.de/HR20-Valve.zip
The following files contain the serial-output:
HR20_Bad.log
HR20_Buero.log
HR20_Wohnzimmer_1.log
HR20_Wohnzimmer_2.log
I took some pictures of the valves:
Bad.jpg
Buero.jpg
Wohnzimmer.jpg (I have two of them)
Each logfile contains the output of more calibrations,
each started with a manual reset.
Dario.
Thanks to DarioC and ThomasG I have real mesure from few valves.
Values is different from my valve values.
Result is, that noise protection for "motor eye" must be improved. It is
not sufficiend near to close position
Situation near to open
________|--|___________________|--|___________________|--|______________
_____|--|___________________|--|
Situation near to close
________|--------------------------------|______________________________
_______________________
Current SW protection have fixed value and catch noise on this
edge"---|___"
It must be improved to dynamic change depend to cycle length. I will
prepare it for next revision.
I thing that SW will be prepare for 1.0BETA release very soon. Byt I
have big problem to find any time for user documentation (I am litle bit
overloaded on my job and I don't have motivation)
Therefore what you can to do:
- write Doxygen comments for generate user documentatio to
--- eeprom values numbering and setting
--- watched values numbering and meaning
--- communication protocol
--- user manual for menu&setting
--- user manual for automatic and manual valve calibration (manual cal:
unmount HR20 from valve, close valve manualy to close positon not to
hard end, pres&hold "C" button and remount HR20 to valve, It is similar
like HR40 manual calibration. Return to auto is similar but press&hold
"PROG" button
Some information about revision 72 at
https://sourceforge.net/projects/openhr20/
- eeprom contend is NOT compatible with previous version
- new method to detect motor range
- new method to calculate motor eye noise protection value
-> result? I need new calibration logs from your valves. It works
perfectly for me. I hope that detection of "close" position is much
better than before.
Latest TODO list is here:
http://openhr20.svn.sourceforge.net/viewvc/openhr20/trunk/source/TODO.txt?view
TODO list looks long, but it not contain any critilcal task or relative
bigger task.
I realy want somebody who will write user documentation in doxygen.
Reason for doxygen usage is simple, documentaion on external file is
usualy obsolete.
I realy need review of code. Some parts I code very quickly without self
review.
Remark to SW Revison72:
Values for motor eye tunning is not final. It is just first idea.
/* 0e */ uint8_t motor_end_detect; //!< stop timer threshold in % to
previous average
/* 0f */ uint8_t motor_eye_noise_protect; //!< motor eye noise
protection in % of previous average
Commands:
G0e<enter> read 0e value
S0exx<enter> write xx(hexa) as value
Default value for:
0e - 150% of eye cycle
0f - 40% of eye cycle
(0e) value means that motor is stopped when time exceed 150% of previous
cycle average
(0f) is value in % of cycle where is eye not used. It is mask for
problematic area.
Revision 75 is little bit experimental
- experimental approximation of human temperature feeling
(add valve position to real temperature, humans feel warm heating and
we can use smaller real temperature)
- experimental change of PID constants (stability test)
For this moment this is setting with best results for this moment. It is
not fare from original SW:
S0532<enter> (default in EEPROM)
S0602<enter>
S0719<enter>
S0864<enter> (default in EEPROM)
But it is not exactly what I wan't. Better can be some form of fuzzy
logic. Do you have some material for this problem someone? I have only
teoritical experience from university, but it is too fare for me.
Hi all,
We can test rev 86.
Major change is non-linear PID controller
It is much better for reduce motor actions and save batteries. I hope
that it is better than original SW for my room and valve.
Motor position for constant temperature
http://img92.imageshack.us/img92/9367/motorzn7.png
X scale is minute/4
results from rev86 can be improved but we need some changes at "I" part
of PID controler limits (I will prepare it for next revision)
remark: rev 87 is identical to Rev 86, changes is only in TODO list and
change log
Dank der unermüdlichen Arbeit von Jiri
haben wir nun einen Stand erreicht, wo der Open-HR20 mehr kann
als der originale HR20.
Ich selber habe schon fünf HR20 mit der neuen Software im Einsatz
und konnte noch keine Probleme Feststellen.
Jetzt brauchen wir
- Tester, Tester, Tester, Tester, Tester.
- eine PC-Software umd mit dem HR20 zu kommunizieren,
die Schnittstelle ist ja jetzt bekannt und man kann
viel einstellen.
-----
Thanks to Jiri
we know have a software which can do all the things the original HR20
can do.
Now we need:
- Tests, Tests, Tests, Tests, Tests
- PC-Software to control the OpenHR20
DArio
new revision 90
- updated motor.c
- add verbose output for temperature
If you want to help me with window open functionality please change in
debug.h this line
#define DEBUG_PRINT_MEASURE 0
to this
#define DEBUG_PRINT_MEASURE 0
and send me log including window open.
Revision 91 is small bugfix for rev90
Here:
http://img253.imageshack.us/img253/302/motor2fv0.png
you can see results from Rev91 in graph
X scale in minutes
blue - wanted temperature (20.5)
red - measured tempetature
yellow - valve position
It is simply best what I ever see including original SW
PS: if you can send me log in window open and close condition in your
environment it will be helpfull. Please enable bebug (see my last post)
Hallo,
Habe gerade 8 Stück von Conrad bekommen, Version 2.04 - Sonderangebot!!!
Ich hab gerade das Pollin Evalboard gebaut und werde am Wochenende den
ersten Regler damit umprogrammieren.
Hi Jiri,
I have downloaded and compiled the project, which worked well. Recently
I purchased a JTAGICE MKII and I am trying to get it connected to the
HR20.
I am still busy with other stuff but I think I can spend now several
hours to the project to add help where required. I would like to write a
windows program for remote setting the HR20, which can be extended to
pick up loggings or download new SW.
Also very important is a clear easy to understand description how to get
started (where to get the tools and SW, how to install and configure,
how to connect, how to remote control...). It will increase the number
of users for testing and may be adding features. Thats what I would like
to do first as soon as I get my HR20 flashed.
On the first sight of the code you have done a good job. Many thanks for
the effort you spent.
Since I have no experience with flashing Atmel controllers it would be
nice to get brief hints for the required settings concerning clock rate
(4MHz?), fuse bits, lock bits and other required settings.
Best regards,
Karim
Dr. G. Reed wrote:
> Kann man mit AVR Studio und einem STK500 den HR20 programmieren ?
In dem gekauften Zustand, kann man den HR20 nur über JTAG programmieren,
dazu braucht man einen AVR JTAG oder einen Clone davon, zum Beispiel von
Olimex.
Wenn man aber die Mühe nicht scheut, kann man sich die Leitungen für den
ISP anlöten. Dazu muss man ein paar Käbelchen (MOSI, MISO, SCK, RST, VCC
und GND) anlöten und mit dem ISP Programmer verbinden, dabei beachten,
dass die Leitungen alle 3V Pegel haben und nicht 5V.
Denkbar wäre es auch mit dem JTAG einmalig einen Bootloader zu
programmieren und von da an die neue SW über die serielle Schnittstelle
einzuspielen, dazu reicht dann ein normales Handy-Kabel auf PL2303
Basis. Nachteil ist, dass der Bootloader etwas Speicher verbraucht und
das die maximale Größe des Programms dann um diesen Betrag kleiner wird.
Einen Bootloader hatte ich mal programmiert und der sollte eigentlich
auf dem HR20 laufen, oder eben den JTAG von Olimex, der kostet nicht
viel und kann 3V.
http://www.olimex.com/dev/avr-jtag.htmlhttp://www.olimex.com/dev/avr-usb-jtag.html
Dario
Karim L. wrote:
> Since I have no experience with flashing Atmel controllers it would be> nice to get
brief hints for the required settings concerning clock rate
> (4MHz?), fuse bits, lock bits and other required settings.
Connect the JTAG with the folowing Pins:
1 /Reset Reset
3 TMS JTAG
4 TCK JTAG
5 TDO JTAG
8 TDI JTAG
9 + Batt Batterie
10 GND
Then connect 3V to the HR20 (and the JTAG) and start AVR Studio.
You can select ATMEGA169P ans you use default values for Clock, etc.
Press "READ SIGNATURE" and it should display the Signature of the ATMEGA
and the text: "The signature matches the selected device"
Then you can:
- ersae the Flash
- Change Fuses
- EESAVE to disabled
- BOOTSZ to 512 Words
- CKDIV8 to 0
- New Fuses should be:
- Extended: 0xFD
- High: 0x9B
- Low: 0xE2
- program Flash
- program EEPROM
- Have fun!
Dario
Vierauge wrote:
> Habe gerade 8 Stück von Conrad bekommen, Version 2.04 - Sonderangebot!!!
Wie teuer waren die?
> Ich hab gerade das Pollin Evalboard gebaut und werde am Wochenende den> ersten Regler damit umprogrammieren.
Das glaube ich nicht Tim.
Programmieren kannst Du sie eigentlich problemlos nur über JTAG, ich
glaube nicht, dass Du es ohne weiteres mit dem Pollin Board schaffst.
Lies einfach meine anderen Antworten von heute.
Dario
Hallo Dario,
hab eben den JTAGICE MKII angeschlossen, der wird auch erkannt aber das
AVR Studio beschwert sich darüber, dass die Versorgungsspannung vom
Target zu niedrig wäre (1,338V). Habs aber gemessen und die liegt bei
2,8V. Ist Dir da was bekannt?
Kann es sein, dass man sich um die Fuse und Lockbits usw. nicht zu
kümmern braucht, weil die Einstellungen über JTAG ausgelesen und
zunächst als Default übernommen werden?
Gruß
Karim
Für die Linux/BSDler:
ich habe gerade meine ersten Rondostat erfolgreich programmiert:
AVRDragon am usb-Port, avrdude mit libusb-Support und ein JTAG-Kabel
wie von Tobias Koch am 8.4.2008 oben beschrieben. Folgendes Kommando
habe ich benutzt:
avrdude -p m169 -c dragon_jtag -P usb -e -U flash:w:hr20.hex \
-U eeprom:w:hr20.eep -U efuse:w:0xfd:m -U hfuse:w:0x9b:m -U
lfuse:w:0xe2:m
Musste vorher einmal dasselbe Kommando ohne eeprom-Update durchlaufen
lassen, die Fuses müssen dafür wohl zuerst korrekt sein.
Himtronics
Karim L. wrote:
> warst gerade schneller.
Was für ein Zufall, hast Du auch nebenbei Football geguckt?
Ich habe das Thanksgiving-Game geguckt und das war so langweilig,
dass ich nebenbei auf dem Sofa mal ein paar Anfragen bearbeitet habe.
> Problem mit der Spannung weg ist. Ne Idee?
Woher hast Du den Strom. Ich habe das Problem, dass es mit Batteriern
nicht immer geht. Da bricht die Spannung wohl auch mal recht stark
zusammen. Derzeit habe ich folgende Schaltung:
USB - PL2303 Handykabel - HR20
USB - USB/RS232-Kabel - JTAG - HR20
Am HR20 dann:
HR20 || JTAG || PL2303
-----+--------++-----+--------++--------
1 | /Reset || 6 | /Reset ||
3 | TMS || 5 | TMS ||
4 | TCK || 1 | TCK ||
5 | TDO || 3 | TDO ||
6 | TxD || | || TxD
7 | RxD || | || RxD
8 | TDI || 9 | TDI ||
9 | +Batt || 4+7 | VCC || 3V
10 | GND || 2+10| GND || GND
Beide Kabel stecken im USB desselben Computers.
So kann ich Programmieren und die serielle Ausgabe beobachten
ohne umzustöpseln und Batterieen brauche ich auch nicht.
Wie machst Du es?
Dario
Leute meint ihr nicht das es gegenüber Jirji (jdobry) fair wäre wenn ihr
die Diskussionen hier besser in Englisch statt in Deutsch führt?
Er investiert viel Zeit in das Projekt und versteht dann nicht was ihr
hier schreibt.
Please use english instead of german. I think it is good when jirji can
read what you wrote.
Artax
Hallo Dario,
danke für die Antwort. Fußball habe ich keines geschaut, war Zufall. Bei
mir ist die Glotze meistens aus.
Hab einen JTAGICE MKII Clone. Da war ein Kabelsatz dabei, zum
"fliegenden" Verdrahten. In der Doku zum JTAG stand dass Masse auf Pin 2
und 10 liegt. Nach Merphy habe ich 2 gewählt. Deswegen ging es nicht. Es
muss Pin 10 sein, eventuell muss man Pin 2 mit an Masse hängen.
Hab jetzt aber noch eine Frage. Gehe ich recht in der Annahme, dass in
der Datei hr.epp die EEPROM Daten sind und im hr.hex die Flash Daten
stecken die zu brennen sind?
Ist der Bootloader für späteres Flashen über die V24 schon mit drin?
Gruß
Karim
Artax wrote:
> Please use english instead of german. I think it is good when jirji can> read what you wrote.
Sure, but if i answer to topics that are not souce related, like setting
up an enviroment and programming the HR20 with a JTAG this is no issue
for Jiri.
He knows how to compile and programm. I think answering questions in
German to german useres, which are not Source-Code related is OK.
Dario.
By the Way, I found an Error:
Revision:
93
Error:
when setting date and time (after reset od with longpress of AUTO)
it is possible to set an invalid date e.g.: 31th november
Dario.
Hallo Dario,
hab das Teil jetzt geflasht bekommen. Die Revion im config.h File habe
ich noch auf 0.93 erhöht, sonst sieht man am Gerät beim Einschalten
nicht die aktuelle Revision.
Die Idee mit dem PL2303 Kabel finde ich gut, die gibt es für 3,5 EUR bei
ebay. Hab aber keines gefunden, das mit Vista zusammenspielt. Da muss
man drauf aufpassen.
Gruß
Karim
Hallo Dario & Juri,
the day setting (limiting to the maximum days in the month) fails,
because in function RTC_DaysOfMonth() (Modul rtc.c) a wrong index is
used to get the day of month out of the table. -1 must be added to the
index.
uint8_t dom = pgm_read_byte(&RTC_DayOfMonthTablePrgMem[RTC_MM-1]);
Karim
Logfile for Open Window.
Here is my logfile with temp values while windows was opened.
I entered V<CR> three times before opening the Window.
Outside Temp was about 2°C, room temp about 21°C.
HR20.log: 565
1
V: OpenHR20 SW version 0.81 build Nov 27 2008 23:45:24 $Rev: 93 $
2
T: 2094
3
V: OpenHR20 SW version 0.81 build Nov 27 2008 23:45:24 $Rev: 93 $
4
T: 2094
5
V: OpenHR20 SW version 0.81 build Nov 27 2008 23:45:24 $Rev: 93 $
The temperatur falled to 14,7°C.
Before closing the windown I entered V<CR> two times.
HR20.log: 2395
1
V: OpenHR20 SW version 0.81 build Nov 27 2008 23:45:24 $Rev: 93 $
2
T: 1477
3
V: OpenHR20 SW version 0.81 build Nov 27 2008 23:45:24 $Rev: 93 $
The temperature started to climb to 19,4°C, but the HR20 showed
"OPEN" and the Valve was closed.
Then i pressed AUTO two times at 18:21 and the HR10 resumed
to heat to 21°C
HR20.log: 9179
Dario: thanks for window open log.
Dario & Karim: thanks for bug report & bugfix
------------------
For next revision I have update for PID controller. Problem is delivery
delay from valve action to real temperature change.
PID controlers can use in this situation "Smith predictor" but in this
case we need verry accurate model of this predictor. Otherwise it make
controler unstable. I worry, that we are not abble to create generic
model for it. We are using too many different valves in too many
different rooms.
But I hope, that I found I found work arround. It works for me, but it
take some hours to test in in real conditions.
Jiri
Revision 94 contains improved PI controller.
Test it. You you can send me log, it would be nice.
It's works perfectly for me, but I can't test all conditions.
Jiri
PS: window open detection is still without change. Open detection is
correct, close detection not work.
Hello window close detection can be problem.
From measures, we can found increase of temperature is only
0.13 to 0.20 degree / minute
temperature resolution is only aprox 0.07 degree
current method (compare current temperature and 1 minute old
temperature) can works, but we must change one eeprom constant
"S1c12<enter>" for 0.18 degree/minute window open/close detection
But I worry that we will have too many false positives.
We can:
1) test it with "S0112<enter>" settings
2) found better method (I have not any idea at this moment)
Any idea?
Revision 95 is try to improve window detect.
WARNING: EEPROM contend and layout is changed. Previous numbers of Sxxxx
is obsolete.
significant config is:
G1d / S1dxx : window_thld = treshold for window open/close detection
unit is 0.1C
G1e / S1exx : window_noise_filter, number how many times must be 1
minute difference over window_thld
It is not tested fully. We will see.
Jiri
Revision 96 improve window close detection
G1d / S1dxx : window_open_thld = treshold for window open/close
detection
unit is 0.1C
G1e / S1exx : window_open_noise_filter, number how many times must be 1
minute difference over window_open_thld
G1f / S1fxx : window_close_noise_filter, number how many times must be
teperature > (temperature at t-1min). Condition teperature ==
(temperature at t-1min) not interrupt this counter, but not increase it
Test it,
Jiri
default window_open_thld configuration is too small and have false
positives.
Change value to 32 with this command or change "1d" configuration in
service menu.
S1d20<enter>
Jiri
Hallo,
mal ein DAU-Feedback zur OpenHR20-Firmware von
openhr20.svn.sourceforge.net:
Ich habe gerade erfolgreich die Version 0xF083 kompiliert und
eingespielt.
Entgegen der Aussage hier im Forum habe ich es aber nicht ueber SPI
einspielen koennen (MISO,MOSI,SCK sind ja an kleinen Vias recht gut mit
Lackdraht anzuloeten), aber der Upload ist mir nicht gelungen.
Hab ich was falsch gemacht oder ist SPI-Reprogramming disabled?
Der Upload hat dann doch mit dem JTAGICE mkII gefunzt.
Erste Frage: ist grundsaetzlich die Menuefuehrung aehnlich der
Orginalfirmware?
Nach rumprobieren wuerde ich sagen: ja, bis auf folgende Unterschiede:
Der Mittlere Button zeigt kurz IstTemp / Valve% / Zeit an, richtig?
Im Prog_Modus kann man zwischen 4 Temperaturen waehlen
(Mond,Sonne,Sonne+Mond,Schneestern = Eco/SuperCOmfy/Comfy/Frostschutz),
richtig?
Gibt es sonst noch Unterschiede, was verstellt und angezeigt werden
kann?
Wenn ja, ist das irgendwo dokumentiert bisher? Tweaks wuerden mich auch
interessieren.
In der Anfangs-MoorCalib-Phase lustige Ausgaben aufs Display geschrieben
("Ad 3" glaub ich) werden - was bedeutet das? Gibts sonstige Meldungen
auch, und was heissen sie?
Ausserdem hab ich entdeckt, dass schon jemand ein RFM-FunkModul auf die
Platine geloetet hat und sogar ein Schematic dazu. Gibts dazu auch
irgendwo auch Code und oder sonstige Doku? Das RFM-Interface wuerde ich
schon fuer eine absolute KillerApplication halten ;)
Ok, dann danke fuer eine Aufklaerung, und ein grosses Lob an die
Entwickler!
Gruesse aus Muenchen
Mario
Hallo Mario,
eine Bedienungsanleitung gibt es leider noch nicht. Den Bediencode hat
Jiri geschrieben bzw. um jetzigen Stand vollendet. Wenn man es genau
wissen will, muss man in das Modul menu.c, eeprom.h und eventuell andere
Dateien durchsehen.
Eine Bedienunsganleitung sollten wir haben und um Jiri zu entlasten,
sollte die jemand anders in englisch schreiben.
Die sollte enthalten:
-Beschreibung des Funktionsumfangs
(Wieviele Schaltzeiten und Temperaturen, Auto/Man Modus, Fenster offen
Erkennung, automatische Sommer/Winterzeit Schalte, Fehlercodes Ex,
Beschreibung der Adx Werte, Anbringen auf das Ventil, Einlegen der
Batterie und besoonderheiten der Verriegelung usw.)
-Bedienfolgen über Knöpfe und Drehrad
-Pin Belegung
-Serielle Schnittstelle
-Befehle der Programmierschnittstelle
-Service Menü
-Kalibrierwerte
-Flashen des HR20 mit diversen Tools mit kurzer Beschreibung wie zu
verbinden ist (Kabel, Adapter), wie man die SW benutzt, wo man den Code
zum Flashen herbekommt
-Debug Ausgaben
-Sobald implementiert, Flashen per Bootloader
Wenn Du möchtest, kannst Du das anfangen.
Gruß
Karim
Hallo Karim,
Ich bin gerne bereit Dokumentation beizusteuern.
Allerdings bin ich der Meinung, dass man nicht alles erklaeren muss.
"Anbringen auf das Ventil" steht ja wohl in der mitgelieferten
Bedienungsanleitung.
Und generell sollten nur die Unterschiede und neuen Features der
OpenFirmware gegenueber der orginalen FW in ein Manual, denn
weniger Text ist leichter verstaendlich.
Noch ein Usabillity-Feedback zum Schaltzeiten-Programmieren:
Hat man jetzt 4 Schaltzeiten pro Tag (also sowas wie
"7:00=SonneMond,9:00=Mond,17:00=Sonne,23:00=Mond") oder mehr? Und was
passiert wenn man in der letzten Schaltzeit auf oder ueber die 0:00
geht?
Mich verwirrt das etwas.
Ich werd mir den Code anscauen und schon rauskriegen, wies gemeint ist,
aber noch bin ich DAU und danach sollte sich das Menu-ing evtl ein
bischen orientieren ;)
Ansonsten wuerd mich immer noch der RFM-Support interessieren:
Wer ist denn derjenige, der das RFM-Modul auf die Platine geloetet hat
und einen Schaltplan gemalt hat? Gibts da auch Code dafuer?
@jdobry:
window_open_thld ist ein gutes Stichwort:
Wollte sowieso anmerken, dass mein HR20 staendig OPEN gemeckert hat,
obwohl das Ding stundenlang auf dem Schreibtisch bei konstanter
Raumtemperatur lag. Da scheint wohl irgendetwas ueberempfindlich zu
reagieren.
Ich haette eine WindowOpenDetection sowieso gerne abschaltbar oder
zeitlih-verzoegerbar einstellbar, da das ein ziemlicher Batteriekiller
sein kann, besonders wenn sie etwas ueberempfindlich ist.
First of all, you did a great job in implementing a new firmware in the
HR20!
I'm interested in building a control panel for the HR20 which is away
from the radiator and connected to the HR20 via RS-232.
The reason for this is, that the HR20 is mounted on top of my radiator
below the floor. In this case the built in temperature sensor cannot be
used to measure the room temperature.
Would it be possible to implement a RS-232 command that accepts
temperature values from an external device. So i can send e.g. every
second or minute the room temperature to the HR20 an it ignores the
internal temperature sensor?
Probably two commands are needed:
disable internal temperature sensor
receive temperature from external sensor
What do you think?
Regards,
STB
Hallo Mario
die Original Bedienungsanleitung ist ziemlich lausig und gerade das
Montieren bereitet vielen Schwierigkeiten.
Zu den Schaltzeiten. Es gibt 4 Paare von Ein/Ausschaltzeiten. Wenn ----
im Display steht, bedeutet das, die Schaltzeit wird nicht verwendet.
Hab das auch noch nicht alles genau gesichtet, könnte mir aber
vorstellen, dass Fehlbedienung möglich ist. Falls Dir da was auffällt,
bitte berichten.
Bin gerade dabei, ein Windows Programm zum Fernsteuern zu schreiben. In
dem Zuge werde ich einige Details ermitteln auch wegen der Zuordnung der
Temperaturen zu den Schaltzeiten.
Das RFM Modul hat glaube ich Dario verwendet, eventuell auch Jürgen
siehe oben. Es gibt an anderer Stellen in diesem Forum (z.B.
Beitrag "RFM12 - Funkmodul",
Beitrag "Beispielprogramm für RFM12 433MHz Funk-Module") lange Threads zu diesem
Modul. Da findet man auch Codebeispiele. In der momentanen SW habe ich
keine Integration gesichtet.
Den Schwellwert für die Open Window Erkennung kann man über Datum S1d
verstellen. Hole Dir die neue Revision. Vermutlich hat da Jiri den
Default schon angepasst, ansonsten kannst Du über Serielle Schittstelle
mit dem Befehl S1d20 den Wert auf 20 stellen. Dann sollte es besser
sein. Über den Parameter kann man dann auch die Erkennung ganz
abschalten bzw. auf unempfinlich schalten.
Gruß
Karim
Hi D. E.,
I see the same need for that. I is allways better to measure the
temperature there, where you sit.
The easiest way would be, to solder out the sensor add a shielded caple
of desired length, place the sensor where you want and reconnect it to
the module.
Sending the temperature via rs232 to the module would be also a nice
option.
Regards,
Karim
Hi Karim,
danke fuer die schnelle Antwort!
Also Schaltzeiten und WindowOpen werd ich jetzt gleich mal ausprobieren!
*RFM:*
Zu der RFM-GEschichte, ok, da sprech ich den Dario mal direkt drauf an,
bzw wahrscheinl wird er es eh bald hier lesen.
Wollt zum RFM noch ein paar Anmerkungen machen:
Wenn das HR20 nur seinen Zustand
(IstTemp,SollTemp,Valve%,BatteryStatus,...) gelegentlich melden soll,
dann ist die ganze Geschichte an sich kein Problem. Seine eigene ID
sollte er halt noch mit in das Funktelegramm dazupacken damit man die
Dinger auseinanderhalten kann.
Schick waers wenn man diese ID in einem Programmiermodus einstellen
kann, denn man will nicht unbedingt fuer jeden Thermostaten ne eigene FW
kompilieren.
Interessanter aber auch komplizierter sieht die Sache aus, wenn man den
RFM bidirektional beteibt: Interessanter, weil man dem HR20 eben auch
Sollwerte/Stellwetrte/Schaltzeiten/Uhrzeit/... befehlen kann.
Generell gibts da aber 2 Sachen zu beachten:
1. Strom sparen: Der RFM sollte nicht unbedingt permanent auf Listening
geschalten sein, weil er so relativ viel Strom frisst. Er sollte nur
gelegentlich mal kurz hoeren ob was gesendet wird. Um diesen Zeitpunkt
zu erkennen gibts mehrere Moeglichkeiten:
1.1.Die Conrad-Funkheizungsventile zB horchen nur alle 117 Sekunden auf
ein Telegramm. Da muss auch (vom Raumcontroller IMMER eins gesendet
werden, zwecks Clock Recovery). So kann mans machen, ich find aber
1.2. besser: Der HR20 sendet zu regelmaessigen Zeitpunkten ein
Statustelegramm. Danach ist er jeweils 1 Sekuned auf Lauschen
geschalten.
Das finde ich eine bessere Art des Syncens, denn es setzt keinen
permanent laufenden Sender (Raumcontroller) vorraus, UND man ist
wahrscheinlich eh an regelmaessigen Statusmeldungen interessiert. Das
ganze eignet sich auch noch ganz gut um
2. Sicherheitsaspekte zu beruecksichtigen: Damit keine Unbefugten dem
HR20 Befehle geben duerfen, bietet sich eine einfache Absicherung via
Challenge-Response an: In seiner regelmaessigen Statusmeldung sendet der
HR20 auch gleich eine Zufallszahl mit, ueber die sich ein "Befehlsgeber"
beim HR authentisieren kann. Das waere dann relativ sicher (PlayBack
Attack).
Ich hab mal sowas fuer einen FUnkschalter (2RFMs und 2 AVRs) gecodet,
das koennt ich da gerne einbauen falls interesse.
Die Kommunikation koennte dann so aussehen:
1. HR sendet regelmaessig
/[HR's ID,SollTemp,IstTemp,Valve,RandomNumber]/
2. Falls ein Kommando an den HR gehen soll, so muss die Gegenseite
innerhalb von 1 Sekunde folgendes zuruecksenden:
/[HR's ID,Hash(RandomNumber,Key),Kommandos]/
3. Der HR prueft ob /Hash(RandomNumber,Key)/ passt (beide Seiten kennen
Key), und wenn ja exect er das Kommando und sendet Antwort zurueck.
Die Kommandos selber koennten der Einfachheit COM-Port-Befehle sein, am
besten mehrere auf einmal, die dann nacheinander an den COM-Interpreter
geleitet werden (so muss man keinen neuen Kommandointerpreter
schreiben).
Die gesammelten Antworten gehen dann als ein Paket zurueck:
/[HR20'sID,Antworten]
Falls das irgendwer fuer brauchbar haelt (hallo Dario ;) wuerd ich da
gern was in die Richtung machen. Ein paar Codeschnipsel fuer RFM
speziell in der OpenHR-Firmware laufend wuerden mich auf jeden Fall
interessiern.
@Mario Fischer: message for me you must write in english. I am not abble
to read german, sorry.
@ D. E.: push temperature from external source is possible (remove
temp_average macro, create int16_t variable with same name, create com
function for write into this value) We will need something like this on
2.xx versions with master/slave control (cable or wirelless)
Edit: your last reply and my intersected, but nevermind...
I know the RFM@HR20-pictures, but are there also some lines of code?
ok, heres the english version:
Some Ideas about the RFM-Module in a HR20:
If the HR20 should just broadcast it's state
[CurrentTemp,WantedTemp,ValvePos,BatteryStatus,...], it's implementation
is quite simple. The only thing to be aware of is to definetly switch
the RFM off when not in use and to send a individual Device ID within
the broadcasted status message.
It would be nice if this ID could be programmed via Menue and not be a
constant in the firmeware's source code (no own compiling for each
HR20).
If the HR20 should be able to receive commands from a "master" it gets
more interesting and sophisticated:
Interesting, because now it is possible to remotely adjust WantedTemp,
ValvePos, SwitchingTimes, ..., sophisticated because you have to take
care about power saving and security.
1. Power saving:
RFM's receiver circuit may not be switched on the whole time, it
consumes too much power. It is ok, if it only listens "sometimes" for a
short while if a command is being sent.
This "sometimes" can be done in multiple ways:
1.1 In the Remote-Heating-Valves from Conrad Electronics, the Valve
listens for a command for 1 second every 117 seconds. The rest of the
time the valve's receiver is switched off. For clock recovery, a master
("room controller") MUST send every 117 a telegram (even when no valve
change is needed).
This is one solution but i like better the other one:
1.2 The HR20 sends regulary a status telegram. After this sending, the
HR20 turns on the receiver for 1 second. Within this second, the master
must send a command (if he wants to). That is a nice way of clock
recovery, because it doesnt require a regulary sending master like at
Conrad, and you will be interesed in HR20's status anyway. Also the
status broadcast can be used to acheive
2. Security:
To avoid that unauthorized "masters" may send commands to the HR20, a
simple challenge-response could be implemented easily. It just requires
a hash function and a shared key, so it's not very
programspace-consuming.
2.1 When the HR20 broadcasts a status message, it also sends a random
number n(each time a different):
/ [HR20'sID,Random,CurrentTemp,WantedTemp,ValvePos,BatteryStatus,...] /
2.2 If the master wants to send a command to the HR20, he has to respond
within one second with this Telegram
/ [HR20'sID,hash(Random+SharedKey),Command] /
2.3 The HR20 checks weather the hash is as expected (can only be correct
if opponent knew the right SharedKey), and if so, Command is executed
and the response is sent back
/ [HR20'sID,Response] /
For code-reuse, Command could be the same format as the COM-protol, so n
extra parser is needed.
After step 2.3. the HR20 will listen another second for a further
possible command. If no command occurs, the HR will turn of the entire
RFM off till the next status broadcast.
I implemented such a protocol with 2 RFMs and 2 AVRs so i could recycle
some code and add it to the project if desired. Some code snipplets
about the RFM that was soldered to the HR20's PCB would be interesting
for a start up (not for getting familiar with the RFM (i know him ;),
but rather for how to integrate it into the Firmware).
XTEA seems short, but it is just a symetric-algorithm (am i right?).
so this doesnt protect you from sending unauthorized commands to the
HR20, since playback-attacks are always possible.
i would say that messages like "ID32: set wanted temp 24.5C" do not need
to be encrypted. but the should not be recorded and resent to the HR20
while i am on hollidays ;)
so i would suggest challenge-response, which just requires a hash
function which requires even less than 500B.
Hallo zusammen,
zunächst einmal ein ganz grosses Lob für die viele Arbeit in die
Heizungssteuerung.
Ich bin jetzt auch ein wenig eingestiegen und habe folgende Frage:
Habt Ihr schon die Speicherplätze 0x006, 0x136, sowie 0x00f bis 0x01c
(galt für die Version 1.xx; siehe Werner Cornelius) für die Version 2.04
ausfindig machen können?
Befehle kann ich - zwar leidlich, da die Verbindung immer mal wieder
abbricht - an einzelne Speicherplätze z.B. per Norton Terminal senden,
diese scheinen aber anders besetzt zu sein!
Das Zuweisen eines Wertes an bestimmte Speicherplätze (z.B. an 0x080)
funktioniert zumindest. Mir fehlen aber die "richtigen"
Speicheradressen.
Könnt Ihr mir weiterhelfen?
Vielen Dank, Gerd
@Mario Fischer: Thanks for english translation.
You are right, XTEA is symetric-algorithm and we can't use it without
challenge-response in encryped packets due to replay attack. I know.
You are right that with batteries we can't use RFM12 permanetly. For
this moment I have this idea:
1.1 (by your numbering) in points:
- master MUST send time synchronization packets
- after time synchronization HR20 will have windows for tramsit
- HR20 transmit windows is smaller (200ms) and in order of network
address (address 1 have window 1, addr 2 window 2 etc)
1.2 Problem is that we must solve colisions in shared media. this is not
2point protocol. I worry that this version can have collisions.
2. security:
I am using seed-hash algoritm in one my web aplication. I agree that it
is possible use.
For this moment I don't know what encryption is best.
But your protocol have one disadvantage: Status packets from HR20 is
not encrypted. It means that anybody can know mode of usage of your
rooms. It is very easy to find time when nobody leave in home. And
bad-man can plan unwanted visit :-( I belive that it can be fixed.
From your text it is clear that you are little bit fare than I. Current
code haven't any line for RFM12 modules. Previous priority was another,
and now is right time to thing about next steps. Therefore some code
sniplets will be very helpfull. If you want, I can try to integrate it
into project. (jdobry at centrum dot cz)
Technical: you can see on RFM@HR20-pictures that SPI interface is not
used. Simply before pins are used for keys and reconect it on curent PCB
is nightmare. SPI need SW implementation.
I have HW for master. It is ATMEGA16 with RFM12 connected to SPI and
have RS232 serial line. Plan is connect this master to some linux based
router (cheap and need less power than computer, usualy run 24/7 and
have connection to internet. For HW see to OpenWRT project). ATMEGA will
communicate with RFM module and manage low level network and encryption
layer. On serial line we will have something that current OpenHR20
procokol with network addresing extension.
********************
** ADVICE NOTE: **
********************
At this moment I will add only this items from TODO list:
- com: add command for manu/auto and wanted temperature change
- improve watch.c (add more significant values for Txx command)
After this we can release 1.00 BETA version. (I hope)
Next I plan to leave v1.xx OpenHR20 development. For my interrest I need
to continue on wireless communication for OpenHR20 (v2.xx) on branch.
Therefore we need to find maintainer for 1.xx line. Some volunteer?
PS: it is one of basic principes of public projects. Anybody can improve
project for self and result is better and more generic.
Hi jdobry,
thanks for thinking about my suggestions!
Some comments on your comments ;)
1.1. do i understand you right? you want to have a master that
round-robinly sais "id 1, if you want to say something, do it now" pause
"id 2 ..." ...
okay, good approach for collission avoidance, but i see the problem,
that if the master is offline once (battery change, power plug out,
firmware update, or simply one HR20 doesnt recognize the telegram for
radio noise), all clock recovery is lost. you would somehow have to
"reboot" all your HR20s or they would have to enter in some kind of
"resync mode" ... looks complex to me!
thats why i favour
1.2. i see your collission remark, but i dont think they are likely:
packet transmission time is very short compared to intervals (sth like
10 bytes @ 19kbs every 120 seconds for assumptions). i dont think a
collission is very likely. but we could very simply improve it that HR
with ID i sends in an interval of something (120sec + i*sec + 0.1*rand).
i think this would make colls very unlikely.
2. ok, could be a fundamental discussion, if plain status messages
indicating eco-temperature on heater attracts burglars - but anyway,
your point is good.
beside, sym. chipering of the messages sent does make sense anyway,
because otherwise an attacker could calculate the key offline:
attacker snoops one message session, which means he gets Rand and
HashVal.
Then he can calculate offline
for (i=0; i<KEYMAX;i++) if (HashVal==hash(Rand+i)) printf "Key= i"
note that offline brute force in ths scenario can make sense, because
radio packets must be short, which means 128bit keys make packets so
long that packet losses become likely.
a online brute force attac can be easily avoided: if authentication
fails, HR20 waits a penalty time till it accepts next auth try.
the whole thing is a trade off between security, package loss and
battery saving anyway. we can't secure it like a WLAN, but i think these
kind of security thoughts are good.
looking at the available home automation radio crap you see that the
dudes who built did not give a single thought about security...
I tried the latest FW this evening (since the version before permanently
told me "OPEN") -
the HR reported "bATT" after booting and told me that the temperature
was 11C, the motor did not calibrate or move in any way.
The strange thing about it is, that the HR was powered by a power supply
device running with clean and stable 3.3 V.
The original FW of the HR never complained about low battery.
The previous version of the Open FW i tried also reported bATT in the
beginning, but later it disappeared (also powered with stable 3V3 from
supply device).
Is there a problem with the ADC checking the battery?
@Mario Fischer:
I thing about it and 1.2 communication would be better. TX packet need
more current than RX, but with 1.2 I need TX short time. In 1.1 case I
need enable RX for longer time, tepend to packet timing tolerance.
PS: for 1.1 I mean send only one packet from master, windows for slaves
is calculated from this timestamp.
Your problem: "HR reported bATT after booting" is caused by empty
EEPROM, check it. (empty EEPROM default value is 0xFF and it mean 5.12V,
your voltage is smaller ;-)
Offline attack is possible only teoreticaly. "As of 2004, the best
attack reported on XTEA is a related-key differential attack on 26 out
of 64 rounds of XTEA, requiring 2^20.5 chosen plaintexts and a time
complexity of 2^115.15 (Ko et al, 2004)." -
http://en.wikipedia.org/wiki/XTEA
TEA (XTEA predictor) is used in XBOX and you probably know, that it have
succesfull attack. But XTEA is better and motivation to attack some
heating system mis much smaller than attack XBOX
Hi jdobry,
First Question:
Should we open a new Thread
"OpenHR20: Firmware for Honeywell Rondostat HR20E" ?
This one is quite long and touches lots of other HR20 issues.
Security:
Offline-BruteForce: Of course BruteForce with 128 Key is not efficient.
But transporting radio telegrams containing 128 bit long challenges of
responses seemed to radio-expensive to me. It is important to keep the
packets short for energy saving and not getting them destroyed by air
noise.
But the whole discussion about BitLengthes of Random, Response and Key
are a little too off-topic in the current project phase. We can discuss
that later as well, since we almost agree anyway ;)
EEPROM & Empty Battery:
Ok i will flash the EEPROM as well! This sounds also like it is the
cause for ths strange temperature (Conversion Table) and why the motor
doesnt want to move (to save the weak battery)...
I will give feedback when i tried it with the flashed EEPROM. Hope the
WindowOpen is stable now ;)
RFM on SPI:
Im not sure if i got u right but connecting the RFM to the hardware SPI
is not that neccessary. It saves probably some CPU-cycles and some lines
of code, but Software SPI is really easy and cheap and we can select
Pins that we find nice to solder ;)
I would suggest to wire the RFM's IRQ-Pin as Well to an available
IRQ-Pin of the AVR, because during the sending, you can put the AVR to
sleep between SPIing a sendbyte to the RFM and waiting till the RFM sent
it ... it's quite simple some extra uAmps ;)
@Mario Fischer:
Create another thread is good idea.
EEPROM: problem is, that you must write Flash and after EEPROM in this
order. Problem is that we have "preserve EEPROM" fuse in AVR disabled.
And rewrite flash need erase device and EEPROM is also lost.
You can get measured battery value by serial line, (command T01 or D)
or you can read it on LCD on service menu (press & hold all buttons,
after this press "C", move wheel to second bar on hourbar line. value is
hex)
RFM on SPI:
- SW SPI - I agree, this is not problem
- I hope that I found pins easy to solder
- IRQ will be used, see to my pictures, pin PE6. It is small work
arround, we don't have any free pin on AVR. (PD0 is not possible use by
AVR LCD controller design, PE5&PE7 have connection bellow MCU, I have
tools to remove MCU and put it back, but it is not usual). See to RFM
documentation, SDO is possible use as IRQ, but only with active nSEL and
before egde on SCK. We must only disable/enable nSEL and after wait to
IRQ.
A new thread is a good idea.
I've bought some other electronic radiator controllers, one HR40, one
THERMOtronic and two HR20E. Like I said earlier in the thread they seem
to be identical or pin-compatible in the inside. So I'll check if I can
program those too. (Maybe we can name the thread ... and others)
I'll also begin the documentation and manual as soon as my JTAG device
arrives and I have a working openHR20E to test with.
Thanks for the great work!
I created a new Thread
* OpenHR20: Firmware for Honeywell Rondostat HR20E * in
Beitrag "OpenHR20: Firmware for Honeywell Rondostat HR20E"
Please put all Questions&Answers about this open Firmware there.
Please write in English there.
Hallo,
ich versuch´s noch mal - hatte bisher keine Antwort erhalten - oder bin
ich vielleicht im falschen Forum?
Ich beschäftige mich auch ein wenig mit der Steuerung des HR20 und habe
folgende Frage:
Habt Ihr schon die entsprechenden Speicherplätze 0x006 (Komfort- und
Spartemp), 0x136 (Solltemp), sowie 0x00f bis 0x01c (Wochentage - galt
für die Version 1.xx; siehe Werner Cornelius) für die Version 2.04
ausfindig machen können?
Befehle kann ich - zwar leidlich, da die Verbindung immer mal wieder
abbricht - an einzelne Speicherplätze z.B. per Norton Terminal senden,
diese scheinen aber anders besetzt zu sein!
Das Zuweisen eines Wertes an bestimmte Speicherplätze (z.B. an 0x080)
funktioniert zumindest. Mir fehlen aber die "richtigen"
Speicheradressen. Es ist ausserdem nur das Senden von jeweils einem
Befehl möglich (nicht zwei, wie bei der Version 1.xx)
Könnt Ihr mir weiterhelfen oder mir schreiben, woran ich mich wenden
kann?
Vielen Dank, Gerd
@Gerd,
Nobody knows the commands when ever existent for version 2.04, which has
a total different behavior as the old version.
Therefor the SW was completely new written and has allready more
functions as the old one (e.g. additional On/Off Times + comfort temp.)
and can be remote controlled.
But you have to use a programmer to flash the device. Later on the
module will include a bootloader, so you can exchange the SW over rs-232
but the first version must never the less be flashed with a programmer.
You can get the code here https://sourceforge.net/projects/openhr20/
Currently I am working on a windows program for comfortable remote
control. The other freaks are tossing on wireless connections and later
on WEB access is intended.
Regards,
Karim
Hallo,
Ich habe mir auch den HR20E bei Conrad bestellt und bei drei Geräten das
gleiche Problem:
Im Voll-Hub-Modus funktionieren sie problemlos. Im Standard-Hub-Modus
(default) bleiben nach circa drei Tagen die Heizkörper kalt, obwohl das
Gerät eine hoehere Solltemperatur anzeigt. Nimmt man das Thermostat ab
und dreht das blaue Regelrad ganz auf werden die Heizkörper schnell warm
und wenn es zu warm wird auch wieder automatisch und richtig
abgeschaltet.
Die Batterien sind neu und Markenprodukte, daran sollte es nicht liegen.
Die Ventilstifte in der Heizung werde von selbst herausgedrueckt, denn
wenn man das blaue Regelrad selbst aufdreht wird die Heizung warm. Das
Problem mit dem Batteriefach, dass vom Regelrad aufgedreht wird kann es
auch nicht sein, da das die Thermostate im Voll-Hub-Modus keine Probleme
machen.
Mir scheint als wuesste das Thermostat im Default-Hub-Modus nach ein
paar Tagen nicht mehr ob es schon richtig aufgedreht hat, glaubt es
waere offen und bleibt an der Position.
Weiss jemand eine Lösung hierfuer? Im Voll-Hub-Modus sind mir die
Temperaturschwankungen zu hoch, da die Heizkoerper sehr schnell heiss
werden.
Danke für eure Antworten,
Robert
I was looking for this for a long time now. Need input on this amzon is
giving 300 off on it
<IMG>http://www.imagefrost.com/img/ih/iG.jpg</IMG>;
Is it worth the price...? and has anyone used sony bravia can give any
input.
Thanks
>Autor: Robert (Gast)>Datum: 21.12.2008 09:59
Habe deine Frage in neuem Thread nochmals eingestellt, da ich exakt
dieselben Probleme habe:
Beitrag "Honeywell Rondostat HR20: technische Probleme"
Ich denke, die Fortführung dieses uralten Artikels macht keinen Sinn
mehr.
Weiteres siehe genannter neuer Beitrag.
Klaus
Hi,
habe eine Wohnung mit dem Rondostat 20E übernommen, aber ohne
Gebrauchsanweisung.
könntest Du mir bitte die wichtigste/n Seiten zumailen.
Sind nirgens im Web und der Vertreiber will 5€ dafür.
Danke
:)
Hallo,
es gibt zwar inzwischen einen neuen Thread, der soll sich
aber nur mit technischen Fragen beschäftigen;
nachdem dieser hier immer noch lebt, bleiben wir also hier:
lt. Sonderangebotsprospekt bietet Marktkauf ab Montag den
HR-20E für 29,99 EUR an (falls das regional sein sollte:
Süddeutschland / Raum Tübingen)
Kennt jemand eine billigere Quelle (Versandkosten?) ?
Bei ebay gehen die Dinger über 30EUR, aktuell steht ein 3er-Set
bei 91EUR + Versandkosten, ein Sofort-Kaufen für 85EUR + 5EUR
ist auch nicht viel besser...
Grüße
Stefan
Reichelt hat unlängst den Preis gesenkt und damit mit dem 3er-Pack-Preis
von Conrad gleichgezogen, knapp 30 EUR. Bei Conrad aber erst ab drei,
bei Angelika halt schon fürs Einzelstück.
Da es Conrad-Filialen in manchen Orten gibt, kann man sich dort (ab
drei) die Versandkosten sparen. Auch wenn man sich in dem Laden sonst
nicht wohlfühlen mag.
Habe eine Frage zu dem HP20E:
Ich habe das Problem das immer wieder die Temperatur Manuell (mit dem
Drehrad) auf "ON" gedreht wird und nicht wieder zurückgedreht wird. Auf
Auto steht der Regler immer nur das bis zur nächst eingestellten Zeit
die Heizung voll durchläuft. Kann man die Temperatur nicht irgendwie
begrenzen? Aus 21 oder 22 Grad dann soll der Regler wieder zudrehen,
selbst wenn der Regler mit dem Drehrad Manuell aufgedreht wurde.
Ich suche eine Temperaturbegrenzung mehr nicht für das Drehrad, selbst
wenn man voll aufdreht das nicht mehr als 21 oder 22 Grad gehen. Das
"ON" sollte nicht mehr "andrehbar" sein...
mfg
Hallo Leute!
Ich hab normalerweise nicht zwei linke Hände, aber wie geht das Stellrad
runter ohne das was zu Bruch geht?
Update:
OK hab es geschafft nach der alten Regel "Wenn es mit Gewalt nicht geht,
dann einfach mit mehr Gewalt!".
Mg
Leo
> Update:> OK hab es geschafft nach der alten Regel "Wenn es mit Gewalt nicht geht,> dann einfach mit mehr Gewalt!".
Update2:
Den Motor mit dem Getriebe auch auszubauen war eine schlechte Idee.
Hallo Leute,
Thema: Mischbetrieb HR20(V1) und HR20(V2.04) an einem BUS
Seit ich vor über 4 Jahren diesen Thread mit meiner Anfangsfrage
gestartet habe ist viel erreicht worden. Sicherlich wurden die
Erkenntnisse in den verschiedensten Projekten genutzt. Ich bin bei
meiner Anfangsaufgabenstellung geblieben und habe bei mir im Haus 24
Stück HR20 (V1) mit selbstgestrickten BUS-Adaptern an einen
Masterkontroller angebunden und bin seit 2 Jahren hochzufrieden.
Nun wollte ich weitere Räume anbinden und bekomme nur noch die
HR20-V2.04 (auch Duracraft-Theromtronic).
Hat schon jemand herausgefunden, wie das V2.04-Protokoll aussieht?
Eine andere ketzerische Frage wäre: Kann OpenHR20 evtl. auch so
programmiert werden, das der HR20 sich dann wie ein HR20-V1 benimmt? Hat
das evtl. sogar schon jemand gebaut?
Ich denke, dass sich die Frage nach Ersatzlösungen für die so langsam
nicht mehr beschaffbaren HR20-V1 immer mehr stellen wird.
Alternativ könnte ich zwar alles auf V2.04 umstellen, könnte dann aber
die noch laufenden HR20-V1 nicht mehr einsetzen. (2400-8-E-1 und
9600-8-N-1 beißen sich auf einem dummen BUS)
Gruß Uwe
@ Uwe Felgentreu:
"Kann OpenHR20 evtl. auch so programmiert werden, das der HR20 sich dann
wie ein HR20-V1 benimmt? Hat das evtl. sogar schon jemand gebaut?"
Klar geht das!
Das OpenHR-Projekt ist sehr gut und modular programmiert.
Du muesstest die Unit
http://openhr20.svn.sourceforge.net/viewvc/openhr20/trunk/source/com.c?view=markup
anpassen. Dann kompilieren und via JTAG draufspielen (siehe OpenHR
Dokumentation). Aber eventuell ist es fuer dich aber auch weniger
Arbeit, die OpenHR-Firmware als Blackbox zu belassen, nur zu kompilieren
und draufzuflashen, und dann deinem Master einfach das (sehr leichte)
OpenHR-Protokoll zusaetzlich beizubringen. Duerfte weniger Arbeit sein,
falls dein Master ein Linux-PC ist.
Mein Master ist ein ATmega128 mit RX1/TX1 zum HR20-BUS und RX0/TX0 zum
COM-Server.(und dann per Ethernet weiter in Richtung W2k3-Server mit
Steuerprogramm und Datenbank)
Unabhängig von der Art des Masters stört mich, dass die alten HR20 mir
2400-8-E-1 und die neuen HR20/OpenHR20 mit 9600-8-N-1 auf dem gleichen
BUS kommunizieren würden. Meine "BUS-Adapter" sind eigentlich nichts
anderes als Adressdekoder in der Richtung Master->HR20 und bei richtiger
Adresse dann Rückwärts (HR20->Master) Freigabe auf den gemeinsamen
TX-Zweig. Logisch gesehen habe ich alle Rx der HR20 am Tx1 des mega128
und die Tx der HR20 über ein Gate welches der Adressdekoder freigibt auf
den Rx1 des mega128 geschaltet. Da sind 2 Baudraten auf dem gleichen BUS
nicht optimal.
Die Idee, das fertige OpenHR20-System als Blackbox zu nutzen kam mir
auch schon, wurde aber aus o.g. Gründen zurückgestellt.
Da wird mir wohl nur das anpassen der OpenHR20-Firmware übrigbleiben.
Da muss ich als alter Bascom-User aber erstmal meinen inneren
Schweinehund überwinden ;-)
Uwe
Ich hab bei Reichelt das "Eurotronic Sparmatic Zero" (22,95 Euro)
entdeckt und bestellt. Das ganze gibt es mit einem
USB-Programmieradapter (Eurotronic SM Zero Stick, 29,95 Euro). In dem
Thermostat steckt auch ein Atmel ATMEGA 169PV.
Ich werde mir das ganze mal in den nächsten Tagen anschauen, das scheint
ja auf den ersten Blick genau das richtige für eine externe
Programmierung zu sein.
Markus
Hallo Forengemeinde,
wie ist eigentlich der aktuelle Status bezüglich der
openHR20-Firmware. Gibt es momentan ein funktionierendes Szenario, bei
dem die HR20 mit Funkmodulen aufgerüstet und bspw. über ein
linux-programm / weboberfläche gesteuert werden können?
Und kann auch ich als nicht-Elektroiker so ein HR20 Thermostat um das
RFM12 erweitern?
Dank und Gruß
Ralf
Hallo,
hast Du den Eurotronic Sparmatic Zero schon zerlegt??
Wie wird der Motor angesteuert??
Wie die Temperatur gemessen??
Könnte man seine komplett eigene Soft aufspielen und vir Funkmodul
(UART) senden?
Hallo, habe mit Begeisterung alles verfolgt.Alle Achtung bei dem was
dabei rausgekommen ist.
Bin im Besitz von mehreren Thermotronic´s. Habe es auch schon geschafft
über die Schnitstelle(ISP)mittels Pony-Prog Datensatz auszulesen. Pony
deswegen weil ich nur isp-Interface mit parallele Schnittstelle habe.
Nun habe ich mich mit WinAVR versucht.Hmmm, bekomme ich nicht wirklich
hin. Habe dort:
http://openhr20.svn.sourceforge.net/viewvc/openhr20/trunk/source/ sachen
gefunden die auch für die Themotronic´s sind. Gibt es nicht schon eine
fertige .....hex für die Thermotronic´s die ich dann nur noch mittels
pony rübersende? Oder habe ich irgendwo ein denkfehler?
Gruß Jens
Hallo jensi38,
wenn ich das richtig sehe (beschäftige mich selber erst seit wenigen
Tagen damit) brauchst du zum Flashen auf jeden Fall einen Jtag-Adapter.
Über ISP scheint es nicht zu gehen (korrigiert mich, wqenn ich falsch
liege).
@All: Gibt es eigentlich ein "Benutzerhandbuch" für OpenHR20, in dem
alle Funktionen und Tastenkombinationen beschrieben sind?
Gruß,
Chris
Hallo zusammen,
ich habe einige der HR20E von Honeywell im Einsatz.
Dabei ist mir aufgefallen, dass die Batterien leider schnell den Geist
aufgeben. Daher habe ich Akkus eingebaut. Das Aufladen Akkus nervt
jedoch... daher habe ich mir Gedanken gemacht über eine alternative
Stromversorgung.
Was haltet ihr von einem Thermogenerator (http://thermalforce.de/).
Ein Peltier-Element mit einem Kühlkörper sollte doch gehen oder?
Passende gibt es schon ab 20€...
Damit sollte es möglich sein während der Heizphasen den Akku wieder zu
laden.
Hat jemand eine Idee wie man das umsetzen kann?
Gruß,
Tobi
"Über ISP scheint es nicht zu gehen (korrigiert mich, wqenn ich falsch
liege)."
Ich habe bei meinen Rondostat die ISP Pins nach aussen gelegt und
programmiere die dann mit AVRDUDE.
Ist allerdings ein wenig Fummelei und man muss einen feinen Lötkolben
haben.
Gruss
Axel
Tobias John schrieb:> Dabei ist mir aufgefallen, dass die Batterien leider schnell den Geist> aufgeben. Daher habe ich Akkus eingebaut. Das Aufladen Akkus nervt> jedoch... daher habe ich mir Gedanken gemacht über eine alternative> Stromversorgung.
Dann ist irgendewas im Gange, was viel Strom verbraucht. Ein Satz
Batterien / Akkus sollte mindestens eine komplette Heizperiode halten,
wenn nicht länger. Der mittlere Stromverbrauch sollte nicht wesentlich
über 40µA liegen.
Travel Rec. schrieb:> Dann ist irgendewas im Gange, was viel Strom verbraucht. Ein Satz> Batterien / Akkus sollte mindestens eine komplette Heizperiode halten,> wenn nicht länger. Der mittlere Stromverbrauch sollte nicht wesentlich> über 40µA liegen.
Der Stromverbrauch - wenn der Motor nicht in Betrieb ist - liegt bei
etwa 3 mA.
Ausser dass die Batterien schnell leer werden, kommt es oft vor, dass
der Motor das Ventil nicht öffnet oder schließt.
Davon abgesehen - was ist mit der Idee des "Thermogenerators" ?
Gruß,
Tobias
3mA?! Schläft der Controller zwischendurch nicht?! Na dann ist´s kein
Wunder. Den Thermogenerator kannst Du dahingehend vergessen, daß Du für
dessen Betrieb eine hohe Thermodifferenz brauchst und daß dieser
Generator verhältnissmässig großflächig werden wird.
Hallo Profis !
Ich habe nun einen Tag investiert und die meisten der verlinkten Threads
und das Wiki in mich aufgesogen ;-)
Habe gerade einen HR20, HR20Style, Comet und TFA Energiesparregeler C
gestestet:
Vom Comet rate ich ab, der schließt nicht richtig... Der TFA ist der
leiseste, aber dafür gibt es anscheinend noch kein OpenSource Projekt...
Also bleibt nur der HR20. Beide HR20 haben idente Hard+Software (Mega
169PV, V2.04). Also reine Geschmackssache...
NUN MEINE BITTE / FRAGE:
Ich war 20 Jahre in der Automatisierungsbranche und habe das letzte Mal
vor 15 Jahren auch mal C programmiert. SVN hatte ich noch nie in der
Hand. Davor auch Assembler (6502,8051,...). Ich hätte große Lust auf das
Projekt, aber es ist eben alles schon verdammt lange her ...
Dieser Post dient auch dazu, zu checken, ob sich einer von euch erbarmt
und mir unter die Arme greifen würde ;-)
ALSO: Sind die Empfehlungen vom Wiki noch aktuell ?
1.Entwicklungsumgebung: AVR Studio 4 mit Service Pack 2 (V4.13. build
571)
die sind mittlerweile bei AVR Studio 4.18 SP3
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725
2.Compiler: WinAVR V20071221
aktuell WinAVR-20100110-install.exe
http://sourceforge.net/projects/winavr/files/WinAVR/20100110/WinAVR-20100110-install.exe/download
3.LCD Simulation: AVR LCD Visualizer Welche version ?
AVR LCD Visualizer (1 MB, revision 1.0, updated 02/04)
http://www.atmel.com/dyn/resources/prod_documents/AvrLcd.msi
Ich habe noch nie eine JTAG Programmer in der Hand gehabt... Also was
brauche ich alles ??
4.Programmer: Dragon, JTAGICE mkII Wo liegt der große Unterschied ?
5.Ersetzt das
- AVR-USB-JTAG KAbel von Olimex
http://www.olimex.com/dev/avr-usb-jtag.html
- mySmartUSB
http://www.produktinfo.conrad.com/datenblaetter/175000-199999/191510-da-01-ml-MYSMARTUSB_AVR_PROGRAMMER_de_en.pdf
- Olimex Starterkit (inkl. USBprog, Netzteil und ATMega8)
http://shop.embedded-projects.net/index.php?module=artikel&action=artikel&id=108
den Programmer bzw. was kann ich damit gegenüber 4. dann nicht tun ?
6.Brauche ich ein Evaluation Board / Starter Kit ?
7.Wo habt ihr die Sachen inkl. der Kabel (PL2303 o.ä.) gekauft
Richard G. schrieb:> Vom Comet rate ich ab, der schließt nicht richtig...
Ist das nur mit der Originalware so oder auch mit dem Mod? Zumindest bei
der Originalware weiss ich, dass nach dem Adaptieren das Ventil
ordentlich geschlossen ist, die Hardware kann´s also ;-). Danach macht
der Thermostat ein paar Regelungen und einen Tag später ist der
Heizkörper im geschlossenen Zustand handwarm. Bin mit meinen eigenen
Experimenten mit dem Comet noch nicht soweit...
Hallo zusammen,
bin gestern über den Mammutbeitrag gestolpert. Wie es der Zufall so
will, habe ich 3 von diesen HR-Dingern ;-)
Nun, ist das Projekt noch am Leben, ober wirde es bereits aufgegeben ?
Ich bekomme bem Versuch das openhr20 downzuloaden immer eine Meldung,
das es keine Files mehr zum Download gibt :-(
Thomas
Richard G. schrieb:> Habe gerade einen HR20, HR20Style, Comet und TFA Energiesparregeler C> gestestet:> Vom Comet rate ich ab, der schließt nicht richtig... Der TFA ist der> leiseste, aber dafür gibt es anscheinend noch kein OpenSource Projekt...>> Also bleibt nur der HR20.
Es gibt noch den Sparmatic Zero, den bekommt man vereinzelt noch zu
kaufen, scheint aber auszulaufen. Dazu gibt es 2 Threads hier im Forum:
Beitrag "Preisgünstiger Heizungsregler bei Praktiker"Beitrag "Alternative Firmware für Sparmatic Zero Heizungsthermostat"Richard G. schrieb:> 1.Entwicklungsumgebung:
Nimm das neuste AVR-Studio mit ASM, GCC oder einen C-Compiler Deiner
Wahl. Den Mega169PV unterstützen alle.
Richard G. schrieb:> 3.LCD Simulation:
Brauchst Du nicht oder kannst Du nicht gebrauchen. Die Displays sind so
angeschlossen, wie sie gerade auf die Platine gefallen sind.
Richard G. schrieb:> 4.Programmer:
Alle Controller sind (auch) über ISP erreichbar. Beim Zero und Comet ist
JTAG über Pins und ISP über die Mini-USB-Buchse erreichbar. Ich würde
Dir einen originalen AVR-ISP mkII oder einen Dragon empfehlen.
Richard G. schrieb:> 5.Ersetzt das> - AVR-USB-JTAG KAbel von Olimex> http://www.olimex.com/dev/avr-usb-jtag.html> - mySmartUSB> http://www.produktinfo.conrad.com/datenblaetter/17...> - Olimex Starterkit (inkl. USBprog, Netzteil und ATMega8)> http://shop.embedded-projects.net/index.php?module...>> den Programmer
Gar nicht erst drüber nachdenken.
Richard G. schrieb:> 6.Brauche ich ein Evaluation Board / Starter Kit ?
Nein. Der Thermostat ist das alles in einem Gerät. Brauchst Du nur noch
zu proggen.
Richard G. schrieb:> 7.Wo habt ihr die Sachen inkl. der Kabel (PL2303 o.ä.) gekauft
Die PL2303 machen oft Ärger. Nimm lieber ein Kabel mit FT232R-Chip.
Erkennbar daran, dass es als USB2.0 zu Seriell-Wandler angeboten wird
und 3 EUR mehr kostet. Kaufen kann man die bei Reichelt oder TME,
Programmer gibt es zum Beispiel bei CSD-electronics, Reichelt oder
anderen.
Hallo Richard G.
Kabel mit FT232R-Chip bei Reichelt DELOCK 61460 für 8,80€, sehr zu
empfehlen.
Mit PL2303 hatte ich auch schon Ärger (mit anderer Hardware).
Mit der Programmierhardware bin ich nach verschieden Nachbauten und
Käufen (Pech, keine Ahnung oder einfach nur zu blöd) bei USB AVR-Lab
gelandet und kann es nur wärmstens empfehlen.
siehe hier: http://wiki.ullihome.de/index.php/USBAVR-ISP/de
Für 15€ fast geschenkt und für mich interessant, Unterstützung für
Linux!
Ansonsten bin ich mit den HR20 sehr zufrieden,gegenüber der
Orginalsoftware. Vor allem hat er mehr als 2 Schaltzeiten pro Tag und
mehr als
2 Temperaturen!
Das Regelverhalten gefällt mir auch besser, meine Meinung.
Tschüß ein Ehefrauennerver
Ich danke euch für die vielen Tips und Infos ... ist echt ein tolles
Forum !
So ganz bin ich nat. immer noch nicht "durchgestiegen"...
1.Mit welchem Programmer od. Entwicklungsboard kann ich einen Mega169
emulieren.
2. Ich möchte da dann auch Highlevelbreakpoints (in C) setzen und Single
Steppen ?
3. Kann man Variablen tracen (permanente Anzeige der Variable)
Richard G. schrieb:> 1.Mit welchem Programmer od. Entwicklungsboard kann ich einen Mega169> emulieren.
Emulieren oder besser "simulieren" kannst Du mit AVR-Studio, wenn Du in
ASM oder mit GCC programmierst.
2. und 3. kann ich nicht beantworten, da ich ASMer bin ;-)
Was mache ich falsch ?
Die Abfrage der RS232 findet in der Do-Loop-Schleife statt. INNPUT
sollte eigentlich auf ein chr(13) warten, doch es kommt keins. Es kommt
eigentlich überhaupt nichts. Habe aber mit einer Logikprobe
nachgemessen, da fliegen schon irgendwelche Daten.Stimmt das Protokoll
nicht ? Habs auch schon mal ohne Invertierung probiert, nichts :-(
Thomas
PS: Schaltplan im Anhang
Was sind eure Erfahrungen ???
Welche Genauigkeit erreicht der HR20 mit der Originalfirm und welche mit
der hier im Forum erstellten Firmware ???
Gehen wir davon aus, dass das System (Heizkörper/regler) eingeschwungen
ist ??
Habe den HR20 nun mit einem Dragon OpenHR20 programmiert und würde gerne
die Serielle Schnittstelle ansehen.
Dazu halte ich den DELOCK 61460 USB > Seriell in Händen.
1 Wie ist bitte die Serielle Seite des Delock zu beschalten ?
DSUB <-> HR20
2 RXD - 6 TXD
3 TXD - 7 RXD
5 GND - 10
????? - 9 Vcc
2 Brauch ich einen Pegelwandler ?
3 Wit welchem Terminal Programm bzw. wie geht das unter WinXP
(Hyperterminal?)
So wie das aussieht, kannst du den DELOCK 61460 nicht ohne Pegelwandler
an den HR20 anschließen. Das ist eigentlich blöd, denn im DELOCK sitzt
auch schon ein Pegelwandler, du müsstest RX und TX also intern
abgreifen.
Als Terminalprogramm benutze ich privat HTerm:
http://www.der-hammer.info/terminal/
Hallo Richard G.
Ich benutze einen MAX 3232 CPE als "zusätzlichen" Pegelwandler. Bei
Reichelt für 2,15€ zu haben. Schaltung dazu findest Du im Internet. MAX
3232 CPE wird vom Zielsystem versorgt. Leicht zu löten 4 Drähte zum
Zielsystem, 3 zum
DELOCK 61460 und 3 Kondensatoren, ferig. Ansonsten gibt es noch genug
andere Varianten
Ein Ehefrauennerver
Danke - ich habe jetzt auch den MAX3232 genommen...
Könnt ihr mir den Unterschied zw. Delock 61425 u. 61460 erklären...habe
beide von amazon bestellt und noch verpackt vor mir im Blister liegen.
Beide haben ein Kabel dabei ... Allerdings der Adapter selbst ist
unterschiedlich ..
Einziger äußerlicher Unterschied ist, dass der 61425 Rändelschrauben und
der 61460 Muttern hat ... was für den 61425 späche !
Sind die Chips inside ident ???
Hi,
die Chips sind beide gleich, das ist der FT232R von FTDI.
Einen anderen Unterschied als das Gehäuse kann ich von den Datenblättern
auch nicht erkennen.
Guter Punkt, es muss kein FT232R sein.
Aber er ist von FTDI (Vendor ID 0x0403) und es ist einer aus der
FT232-Gruppe, die haben alle die gleiche Product ID (0x6001).
Soll das so sein ?? Eine DAU Frage ....
Wenn ich mit dem AVR studio den .elf file flashen möchte, muss ich jedes
Mal vorher die EESAVE fuse löschen. Nach dem Flashen ist sie dann wieder
gesetzt.
Is das sinnvoll ?
Kann die Software trotzdem noch Daten ins EEprom schreiben (z.B.
Kalibrationsdaten) ?
Wo wird denn fest gelegt, dass mit dem .elf auch die Fuses so gesetzt
sind ?
Hi,
ja, das ist sinnvoll.
Die EESAVE fuse wird gesetzt, damit Du beim erneuten Programmieren nicht
dein EEPROM überschreibst. Falls Du über das Menü etwas im EEPROM
geändert hast, bleibt es damit erhalten (zB die RFM-ID).
Wenn Du das EEPROM Layout geändert hast oder die Standardwerte
wiederhaben möchtest, musst Du vorher EESAVE löschen und das ELF
programmieren.
Wenn nicht, kannst Du entweder nur das hex-File für das Flash
programmieren oder den Fehler beim Verifizieren des EEPROMs ignorieren.
Wo die Fuses definiert werden weiß ich nicht, vielleicht im Makefile
oder im Project?
Hallo,
ich meine das ich mir alles durchgelesen habe, aber eine Sache habe ich
nicht gefunden:
- An meinen PC ist ja nur eine serielle Schnittstelle, durch USB->
Seriell max 5 vielleicht, jetzt will ich aber 15 Thermometer über meinen
PC Steuern können. Und jeder soll einen anderen Sollwert bekommen. Wie
ist das denn überhaupt möglich, ich meine Ihr wollt doch auch mehr als
einen steuern können, oder?
Vielen Dank
an und für sich hat jedes Ventil seine eigenen Zeiten/Tempvorgaben am
Verntil programmiert. Zentrale Vorgaben per PC gehen über
Funkerweiterungen die sich einige User selbst gebaut haben ... der
sogenannte RFM Zweig des Opensource projekts ... ich glaube du musst
noch weiter lesen ;-)
Ich habe nun 4 HR20 Style, das Öffnen finde ich nicht so einfach.
1. Muss man das große Stellrad entfernen. Geht recht einfach wenn man
einen Kabelbinder unter das Stellrad schiebt.
Die Platine sieht man nun, aber man kann sie leider noch nicht
entfernen, da sie mit einer Schraube befestigt ist. Daher muss der Teil
mit dem LCD abgebaut werden.
2. Der Haltebügel, welcher genutz wird um das Bedienteil vom
Ventilaufsatz zu trennen (siehe Bedienungsanleitung) muss aus dem HR20
gezogen werden.
3. Einige Häkchen müssen (je zwei große Vorne und Hinten und die kleinen
an der Seite) herausgedrückt werden, dann kann man das LCD/Bedienteil
abnehmen.
4. Schräubchen lösen und Platine herausziehen.
Ich besitzte ein Handyöffnungs Werkzeug aus Plastik, das hätte sicher
geholfen, wenn ich es gefunden hätte. Ich habe Kabelbinder benutzt um
die kleinen Häkchen zu lösen, da man mit Kunstoff das Gehäuse von Außen
nicht beschädigt. Bei den Häkchen vorne und hinten habe ich zwei
Schraubendreher genutzt.
Hallo zusammen,
ich bin beim googeln auf dieses Projekt gestoßen und finde es extrem
spannend. Ich bin kein Elektroniker, versuche aber trotzdem das
USB-Verbindungskabel nachzubauen. Ich habe mir ein HR20 und ein
USB-Handykabel auf PL2303 Basis besorgt und die 3 (GND, TXD und TXR)
Leitungen verbunden (siehe Dario's HR20.doc) . Ich kann Daten vom HR20
empfangen aber keine Senden. Kann mir jemand weiterhelfen ? Bei meinem
Gerät ist eine 2.04 FW drauf, nur das das Datum von 2010 ist.
Gruß
wes
Hallo wes, mit der 2.04 kann man sich nicht gut unterhalten. Bei der 1.x
konnte man ein paar Werte setzen.
Wenn du OpenHR20 drauf hast geht das Unterhalten wieder besser. Nur
OpenHR20 bekommt man nicht über die serielle Schnittstelle geflasht, da
der HR20 keinen Bootloader besitzt. Das geht nur mit einem AVR_ISP und
da muss man ein paar Leitungen anlöten. Besser ist es beim HR20 mit
einem JTAG/ISP da dort alle Leitungen von außen zur Verfügung stehen.
Mein JTAG/ISP lag zwar Heute in der Post, nur sieht es so aus dass die
Pinbelegung nicht passt und man da herumfrickeln muss.
PIN JTAG HR20
1 TCK Reset
2 GND PE2
3 TDO TMS
4 VTref TCK
5 TMS TDO
6 nSRST TxD
7 Vsupply RxD
8 nTRST TDI
9 TDI +Bat
10 GND GND
Wenn ich hier richtig gelesen habe muss ich TCK, TDO, TMS, TDI, VTref
(+Batt) und GND miteinander verbinden damit es klappt. nSRST werde ich
auch mit Reset verbinden.
TxD und RxD nutzt du wohl für die serielle Schnittstelle, die darf ich
wohl offen lassen, wie auch PE2 (HR20) und Vsupply (JTag). Siehe
http://www.mikrocontroller.net/articles/JTAG#Pinout_AVR-JTAG.
Mein JTAG ist so ein Ebay Teil hier:
http://www.ebay.de/sch/i.html?LH_PrefLoc=2&LH_BIN=1&_trkparms=65%253A12%257C66%253A2%257C39%253A1%257C72%253A5024&rt=nc&_nkw=AVR+USB+JTAG+emulator&_trksid=p3286.c0.m14&_sop=15&_sc=1
Das von Olimex ist wohl besser, da es einen FTDI Chip hat. Mein JTAG mit
PL2303 wird aber von AVR Studio4.19 erkannt.
Hi,
da sich meine Lust diesen (mal-wider, so wie beim VIP1710) Endlosthread
durchzulesen in Grenzen hält, hier kurz die Frage:
Kann man egal welche Thermostatversion man hat, diese per UART steuern,
ohne Modifikationen (JTAG) vornehmen zu müssen?
Gruß,
Tobias
Hallo,
könnte mir jemand meine 2 HR20 auf die openHR20-Firmware flashen? Ich
finde es sehr umständlich, mir selbst so eine "Entwicklungsumgebung"
aufzubauen, es ist doch vieles an Hardware und Software nötig um das
hinzubekommen.
Angebote bitte an shaper[at]web.de
Danke im Voraus!
Hallo zusammen,
ich bin dabei meine eigene Firmware für den HR20zu entwickeln und bin
mittlerweile dabei, dem Ding abzugewöhnen so viel Strom zu vernichten.
und dazu hätte ich ein paar fragen an die entwickler, vielleicht wärt
ihr ja so nett und könntet mir diese fragen beantworten, und zwar:
1) In welchen stromsparmode betreibt ihr die HR20? powerdown ist ja der
sparsamste, da ist aber auch das LCD mit abgeschaltet. bei powersave
läuft zwar das LCD, aber er saugt immer noch ca 330uA.
2) hättet ihr vll sonst noch ein paar tips zum strom sparen? die ganzen
Sensoren und alles schalte ich auch schon ab. ich würde gerne mit LCD
auf max 150uA kommen. habe schon mal beim originalen HR20 gemessen, der
kommt auf ca 50uA.
3) ich betreibe den HR20 mit einem RFM12-funkmodul, schaltet ihr das
Funkmodul komplett ab? oder wird das dauerhaft versorgt?
es wäre echt super wenn ich ein paar Antworten bekommen könnte.
vielen dank schon mal,
Jan
Hallo,
ich habe noch nicht konkret mit dem Aufbau automatischen
Heizungssteuerungen beschaeftigt, aber schon einige Ansaetze durchdacht.
Ich versuche nun erst einmal alles von der theoretischen Seite fuer mich
zu klaeren.
Als Messgroessen koennen wir die Temperatursensoren benutzen,
zusaetzlich sind aber auch andere Einfluesse, z.B. aktuelle und
voraussichtliche Sonneneinstrahlung, oder Aussentemperatur zu
beruecksichten. Sensoren in Fenstern und Tueren koennten bei richtiger
Programmierung Ueberschwinger beim Regeln verhindern.
Aber auch andere, nicht so leicht messbare Faktoren beeinflussen das
subjektive Waermeempfinden (welches fuer uns am Ende die entscheidende
Kenngroesse sein sollte)
Eine Sache, auf die ich gestossen bin ist der "Hitzeindex", also die
Abhaengigkeit der gefuehlten Temperatur von der Luftfeuchtigkeit. Diese
ist allerdings nach wikipedia unter 20 Grad C (genau unser Regelbereich)
vernachlaessigbar. Gegenlaeufige Meinungen habe ich schon von vielen
Seiten gehoert, aber mir nie physikalisch erklaeren koennen. Wurde auch
schon in diesem Thread angesprochen. Hat hier jemand weiter infos?
Meine Vision ist ein Geraet, welches die Luftfeuchtigkeit, Temperaturen,
Sonneneinstrahlung, mit Hilfe des Stromverbrauchs auch z.B. die
Inbetriebnahme der Kaffeemaschine, des Herds oder des Wasserkochers
erfasst (wenn ich eine Tasse Kaffee trinke wird mir warm) und darauf
aufbauend regelt bzw. zum Regeln animiert. Bsp.: "Jetzt Fenster
aufmachen zum Lueften", "Jetzt Sport machen, mindestens 20 Minuten".
Habt ihr noch andere Ideen, Erfahrungen wie sich hier unser
"subjektives" Empfinden vorbestimmen lassen koennte bzw. wovon es noch
abhaengig ist?
Was sollte man beruecksichtigen, was kann man vernachlaessigen - Was
meint ihr?
Kurze Frage zur geheimen Programmierung.
Die Geheimeinstellungen für den HR20 mit Firmware 2.04 sind ja anders
als für die Vorgänger.
Gehe ich da recht in der Annahme dass die hier geposteten Settings
stimmen?
01:00 blink
00 Standard (Sommer/Winder)
01 Keine Umstellung
02:00 blinkt
00 Standard (Solltemperatur)
01 Stellungsanzeige
02 Ist und Sollwert
03:00 blinkt
00 Standardempfindlichkeit
01 Feinfühliger
Im Netz wird nämlich oft auch für den 2.04 eine Menüstruktur angegeben
die so nicht stimmen kann, eher das oben genannte.
Zu 03:00 habe ich die Frage, sind bei 00 sowie 01 trotzdem die 30min als
Wert angegeben? Kann man diesen beim 2.04 nicht ändern wie beim
Vorgänger?
Ach eins noch, bei der 2.94 Firmware würde mich auch noch interessieren
ob man durch das geheime Menü noch an die Funktion kommt um die
Solltemperatur so anzupassen dass 21C auch 21C sind, in kleinen Zimmern
kommt es nämlich ohne schnell zu einer Überheizung (21 eingestellt, real
fast 23C).
Danke
Hallo zusammen,
ich habe es hinbekommen openhr20 (Fenster offen Softwareerkennug) auf
meine Thermostate zu flashen. Bei der Variante der Hardwareerkennung
bricht das flashen mit Timeoutfehler ab. Kann mir jemand weiterhelfen ?
Ich benutze jeweils die openhr20 Version ohne Hardwareänderungen.
Gruß
wes
Hallo Heizungsbastler,
ich hab hier auch einige HR20E. Mit der Originalfirmware hab ich das
Problem, dass die manchmal volle Kanne aufdreht und dabei über den
"Ende"-Zacken dreht. Zurückdrehen klappt dann nicht mehr automatisch,
das Ding bleibt hängen und heizt volle Pulle.
Hat das noch jemand? Bzw. kann mir jmd. sagen ob sich das Problem mit
der offenen Firmware irgendwie lösen lässt?
Erkennt der µC überhaupt irgendwie in welcher Position das Rad gerade
ist, bzw. wenn es am Limit anstößt?
Das hört sich nach einem Mechanischem defekt an.
Die Elektronik fährt auf Anschlag und stellt das fest.
Dein Mechanischer Anschlag geht also nicht.
Gruss
JSachs
Danke Marco,
natürlich habe ich diese Analyse bereits gelesen. Jedoch finde ich
nirgends einen Hinweis auf den Wert des NTC. Im Schaltplan ist der NTC
ohne Wert eingezeichnet. Von den ADC-Werten in Tabelle 9 zurückzurechnen
übersteigt meine Kenntnisse. Deshalb die Bitte um Hilfe ...
LG,
Roland
Hier hat schon mal jemand gerechnet:
http://embdev.net/topic/118781?page=5#2442470
Allerdings hat er nicht geschrieben welchen Typ er schließlich benutzt
hat. Vielleicht kannst du ihn direkt anschreiben?
Hallo zusammen,
nachdem ich in den letzten Wochen diesen und auch die anderen Threads
über den HR20 gelesen habe, und mir auch mal ein paar von den
Thermostaten zugelegt habe, bin ich nun an dem Punkt an dem ich die
Software kompilieren und auf den Thermostat einspielen möchte.
Da ich das JTAGIce3 benutze, wollte ich versuchen die Software mit dem
Atmel Studio 6 zu kompilieren. Aus dam SVN habe ich mir bereits das
komplette Repository heruntergeladen und konnte auch nach einigen
Änderungen den Quelltext kompilieren und mit dem JTAGIce3 auf den
Thermostat flashen.
Jetzt stellen sich mir nur folgende Fragen, die ich nach stundenlanger
Suche in allen Threads nicht beantworten konnte:
Zur OpenHR20-Software:
1. Ist die OpenHR20 Software im Stand-Alone-Betrieb funktionsfähig, also
nur über die Bedientasten einstellbar?
2. Gibt es inzwischen eine Dokumentation über die Funktionen und
Einstellmöglichkeiten der Software?
Zum Atmel Studio 6:
3. Hat schon jemand die Software mit dem Atmel Studio 6 und dem externen
Makefile kompiliert?
4. Gibt es beim Flashen der Firmware eine bestimmte Reihenfolge, die
beachtet werden muss? Oder einfach nur flashen?
5. Wie müssen die Fuses gesetzt werden? Ist die Einstellung in
Repository noch aktuell??
Wenn ihr mir ein paar Informationen geben könntet wäre ich euch sehr
dankbar.
Viele Grüße
Benjamin
Hallo Benjamin,
ich bin eben über Deinen letzten Eintrag gestolpert.
Ist es noch aktuell bzw. hast Du das Projekt mittlerweile am Laufen ?
Ich habe die Thermostate mit OpenHR20 im Einsatz.
Gruß,
Alex
Alex M. schrieb:> Hallo Benjamin,>> ich bin eben über Deinen letzten Eintrag gestolpert.>> Ist es noch aktuell bzw. hast Du das Projekt mittlerweile am Laufen ?>> Ich habe die Thermostate mit OpenHR20 im Einsatz.>> Gruß,> Alex
Für mich wäre es interessant! Ich werde den HR20 vermutlich auch bald
einsetzen. Nutze auch den ice3, allerdings eclipse/avrdude unter linux.
Gruß Max
Hallo,
trifft sich ganz gut, dass der Thread zufällig gerade oben schwimmt.
Ziehe auch in den nächsten Tagen um und werde die neue Wohnung auch mit
HR20-Thermostaten ausstatten.
Ich will mittelfristig auch die Funkanbindung mittels RFM12-Modulen
umsetzen.
Hallo,
gibt es eine Möglichkeit, den HR20 mit Firmware 2.04 mit einem
Fensterkontakt zu betreiben? Leider funktioniert die Fenster-Offen
Erkennung nicht sehr zuverlässig bis gar nicht. Daher hatte ich die Idee
den HR20 mit einem Fensterkontakt nachzurüsten.
Falls jemand hierzu schon Erfahrungen gemacht hat, wäre ich für Hinweise
sehr dankbar.
Ist es möglich dem HR20 mit der Firmware 2.04 über die serielle
Schnittstelle einen Temperatursollwert zu übergeben? Im Moment werden
mir nur Werte die der HR20 ausgibt angezeigt ein Senden jeglichen
Befehls bleibt jedoch erfolglos.
Wie muss ich einen Befehl senden, damit er vom HR-20 erkannt wird?
Baudrate Datenbits Party und Stopbits sind bereits korrekt eingestellt.
Wie gesagt empfangen funktioniert senden jedoch nicht :(
Hallo,
ich hätte noch eine kleine Ergänzung zu der Doku am Anfang dieses
Threads, bzgl. des HR20 mit der V1 Firmware Version.
Beim überschreiben der Speicherzelle 0x136 wird lediglich die
Solltemperatur auf dem Display geändert. Der Motor verfährt jedoch erst,
wenn die Solltemperatur in die Speicherzelle 0x20c geschrieben wird.
Bsp. um die Temperatur zu setzen:
W20C100F = OFF (Antwort: M20C1000)
W20C1014 = 8.0°
W20C1019 = 8.5°
W20C101E = 9.0°
...
W20C10DC = 28.0°
W20C10FF = ON
Antwort:
M20C10xx
Grüße
Fese
Hallo Bastlerkollegen,
ich hab meine HR20 2011 mit Unterstützung von Jiri, Marco G und vielen
Anderen etwas gepimpt. Nachdem ich nun immer im Homeoffice sitze hab ich
nochmal Hand angelegt.
Vorab, ich bin so ein typischer Halbwissender ;-)
Nun bekomme ich beim Verify nach dem Flashen des eeprom per AVRstudio
immer folgende Fehlermeldung:
address 0x016D is 0x08 (should be 0x28).. FAILED!
Laut .map startet das EE bei 0x00810000 und im .lst steht
.eeprom 0000019c 00810000 00810000 000039f4
Nachdem ich die idente Meldung u. Adresse auf allen 3 HR20 bekomme
schließe ich einen HW Defekt eher aus und frag mich
1 was könnte die Ursache ein
2 im .eep existiert kein Wert x28. In welchem File finde ich die Adr.
x16D mit welchem Offset dann ?
(.elf, .hex, oder ... und an welcher Adr. ?)
Im .elf steht an Adr. 3B61 = 39f4+16D jedenfalls x28 ...
Thread beobachten
Seitenaufteilung abschalten
