EmbDev.net

Forum: µC & Digital Electronics OpenHR20: Firmware for Honeywell Rondostat HR20E


Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
1. It is true on version 1.0, not in current code

2. you can increase P_factor, but major problem is that you not have 
final "sumError" and wrong valve_center. If you increase P factor, it 
will increase response of valve to error, but it will probably oscilate

If you really  need to know what happen, please use converter from 3v3 
to RS232 or usb and create log. Without log you know nothing and usualy 
have obly bad feeling.

3. it is 50%

4. It is normal after restart or battery change. Where is problem on 
normal continous functionality.

5. You made deductions, but you don't know facts. Make logs and you will 
see.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri: RS232 has been/ is on plan for this weekend ;-)

1 Rev.309 I-Part:
Allow integration = integration time set to 4 minmutes, if
error==0 OR sign of error changes OR direction of valve movement 
changes...
a) ==> so this means, that if there is a constant error, the error is 
added max 4 times (once a minute) to sumerror ?
b) The max impact on PI then is 4*error*I

2 Under which conditions would you change P3 and und when P factor

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard G: last SVN version 311 have completely another model of windup 
protection. Try it. You can enlarge P_factor to 6-12 ( default is 8 now 
)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri: I'm just trying 317. I have a problem with hyperterminal. It does 
not catch the CR (just LineFeed)...looks like this
V:OpenHR20 17.1 Mar  5 2011 20:02:26 $Rev$
                                          D: d5 01.01.10 12:34:23 - V: 58 I: 236
4 S: 2300 B: 2644 Is: fe00 X
                            D: d5 01.01.10 12:37:11 - V: 58 I: 2364 S: 2300 B: 2
644 Is: fe00
any idea ?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard G:
Correct, code using UNIX end of lines to save flash and communication 
size. Please use terminal which is able accept it. I recommend putty and 
set it.
PS: MS hyperterminal is piece of ..... except other problems it was many 
years unfixed bug, when you use bar to shift window contend, it change 
contend

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
NOTE: SVN rev 318 contain biggest change after more than year, it is not 
fully tested now. If you want to have rock stable code, please use 
release 1.0 (SVN rev 285)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Jiri; Here is the protokoll from last night. Params of my valve:
  /* 0a */  {52,         30,        0,      100},   //!< valve_min
  /* 0b */  {60,         45,        0,      100},   //!< valve_center
  /* 0c */  {90,         80,        0,      100},   //!< valve_max


- It took from 22:42 until 1:50 until I part starts.

- I part does not increase until 2:29, no impact on V so far
- next I increase 3:37, no impact on V
- next I increase 4:09, no impact on V
- next I increase 4:13, no impact on V
- next I increase 4:17, no impact on V

- 5:01 my encoder simulation is runnning and needs about 15s to reach 
the previous S=23,0"C again.

1.??? I thought that it takes 10s after wheel stops before PID is 
updated ???

- next I increase 5:05, no impact on V
...
- next I increase 6:49, 1% impact on V

Resumee:
2. It starts increasing V, neverthelsess room is 1,75°C higer then S
3. Impact of I param is week. It seems that sumerror is increasing to 
slow and I param is to low.
4. V on LCD is 1% less than on COM

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard G:

What is your P, P3, I factors ?
Why you change setting in code, you can use service menu or terminal
(commands G,S)

1) it take 10sec, because wait to final setting. It is mornal if human 
use wheel, that it not have machine precision. You ca see it in 
CTL_temp_change_inc

2) again, what is P, P3, I ?

3) normaly it my valve it take 12-24 hours to find sumerror (I impact). 
It must be slow, you can try in rfmsrc/doc/PI_tuning what happen on big 
gain. I hope that 318 is faster without impact to windup (do yyou know 
what is it?)

4) com show wanted valve, LCD show truncated real position. In real 
world, I want 29, com show 29, but real position after valve stop is 
28.99 -> LCD show 28. Reason is allow see motor movements on LCD in real 
time.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri: PI params are standard, yes I understand windup, but 24 hours to 
find error is to long, because setpoint is changed more often

- ad 1) This would help to prevent update during wheel action:
controller.c 150:
if (((PID_update_timeout == 0)
&& (PID_force_update==-1)
) ||(PID_force_update==0)) {

- How can we prevent 2 ?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
no 24 hours is not too long, it persist after change setpoint

for remove delay, please change in CTL_temp_change_inc

PID_force_update = 10;

to =>

PID_force_update = 1;

Author: Marco G. (stan)
Posted on:

Rate this post
0 useful
not useful
I recommend HTerm as terminal program for Windows:
http://www.der-hammer.info/terminal/

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Thanks Marco !

Thanks for the hints Jiri:
PID_force_update = 1; forces update
But we want prevent update during wheel move:
if (((PID_update_timeout == 0)
&& (PID_force_update==-1)

) ||(PID_force_update==0)) {

This prevents "normal" update (every 4 minutes) until 10s after wheel 
stops !

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi!
How do I find the "correct" values for minimum and maximum vent position 
(0x0A, 0X0C)?
Maybe a feature to "live-control" the valve would be nice.

Chris

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
- set Max=Center= Min+1, wait until heater is cool
- increase all params +1 until hater starts getting warm
- set Min e.g. 5 lower and center 10-20 higer. leave max at 80

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
You don't precision values for valve_min a valve_max. It is used only as 
protection to not move valve to hard limits.

Author: Marco G. (stan)
Posted on:

Rate this post
0 useful
not useful
Does the adaptation which is done after mounting have any influence on 
the min and max values?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri just did some redesign on that, but I think NO.
Calculation in controller.c works with center position. Only I part 
(sumerror) can't increase when MIN/MAX are reached ...
This is why I set the center closer to MIN ...

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri - do you simulate your PI ? Do you have an .xls maybe ??

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard G: simulation you can find here rfmsrc/doc/PI_tuning.ods

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Thanks Jiri, I saw that before, but there is no formula for the 
simulation in the Excel sheet ??

BTW: Where do I find Karims latest Version of his openHR20Suite. I only 
found Version 0.2.4.23954 posted on page 2 ??

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
@Richard,

the last released Version V 0.2.4.23954 of openHR20Suite can be found 
here http://embdev.net/topic/118781#1157863, but I think, it will not be 
completely data compatibel. It seemed to me, that no body was interested 
in this program and I had to do a lot of other stuff, so I had not the 
time and motivation to keep it uptodate. But since I am still interested 
in this project, I need to look, wether I am able to compile and flash 
the latest Version of OpenHR20 firmware an check, what has to be 
modified in the Suite SW. May be I can take a look at it on next 
weekend.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Hi Karim, I have this Version runnning since last weekend. Execpt the 
difference in the EEProm names it seams to work. But once I had a jam on 
COM - no more data transfer, which just could be released by using putty 
to send some manual commands...

The only thing, that bothers me a bit is, that I had to install .NET35. 
Usally nearly every PC has some .net version installed. Very often it is 
2.x ...

Would it be possible to parse the appropriate eeprom.h. This way one 
could only copy this file e.g. into the program dir and would be up to 
date. The second thing is that one has to configure which #defines were 
set ..

Author: Karim L. (louk)
Posted on:

Rate this post
0 useful
not useful
Since the program uses WPF technology, it requires .NET V>=3.0. If you 
want to see a flash movie, you have to install the appropriate flash 
player, same for Silverlight or here .NET. That is how it works and the 
installation is only once required. The installed .NET framework 
versions can be found here C:\WINDOWS\Microsoft.NET\Framework and 
generally you have anyway several versions on your PC.

It would be possible to read the eeprom.h file but it has a very 
processing unfriendly format, which is errorness. It would be better, to 
have an xml file, which contains the required definitions and on 
modifications in eeprom.h, everybody could edit the changes to this xml, 
which will be loaded by the Suite. Different versions of the eeprom 
data/HR20 firmware could be handled by this method as well. But I can't 
promise to program that one of these days.

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
@Karim: Would be nice ! Put your tool into trunk !!!

@Jiri:
My experience with 319 controller in a 15m² room during some nights with 
no persons in it and predifined Params (except MIN=52,CENTER=60):
1 I Part takes about 2 hours until reaction is seen on temp. Maybe I can 
be increased ??
2 I think it is important to set the MIN value close to the real CLOSE 
of the valve, beacuse this limits I part
3 I is still increasing/decreasing even if the temp gradient has already 
changed (from falling to increasing or vice versa) ...
4 suggestion:
Why don't we stop increasing/decreasing sumerror, as soon as the 
gradient of the real temp changes to the wanted direction ?
5 D part missing:
In my case, the Valve runs on accu with permanent charge of 5mA via data 
connection.
I need something, that reacts when e.g. a person enters the room or a 
heating source like a PC is started ... waht do xou suggest ?
6 I have no idea of what is the impact/aim of P3 - can you please 
explain ?
7 Regarding simulation: I saw the .ods before, but there is no formula 
for the simulation in the Excel sheet ?? Do you have something like that 
... how are you doing it ?
8 Am I right ? On COM we don't see every move of valve, because of 
integer value ? Why not put valve*10 to display and COM ?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
1. I thing not, you can just create oscilations
2. problem is that MIN value float after every calibration. And you need 
value below to insure close and prohibit unlimited heating
3. do you have better idea to protect to windup and allow integration if 
valve still in position and you have permanent offset ?
4. If you want it, please use version 1.0. Problem is, that it increase 
oscilations on some situations (in my case only in one room)
5. D is removed because usually we have only batteries, and it have 
problem with transport delay (it take more than 20 minutes till you are 
able to see effect when valve close)
6 regulation characteristic of valve is non linear with unknown 
"center". If you use big P you will get oscilations. If you use low P, 
you are not sufficient reaction if calculated "center" (I part) is too 
far for real. Therefore you need compromise, small reaction for small 
errors and big for big.
7. .ods contain simulation formulas, you can convert it into excel
8. COM show final position on every valve move start

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
add to 4) I was wrong. It is realy used on release 1.0. I remove it, 
because it not solve windup completely. Normaly you have more heat 
sources (ex: sun) and it can create any temperature profile independent 
to valve. It is replaced by another idea, but it is compatible. I plan 
to use longer temperature history than only previous.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
ad4) but you agree, that a further increase after temp gradient changed 
leads to a unnecessary high I part ?
ad6) what is the max P3 before oscillation starts, can it be increased 
???
ad7) I used excel2010 to open it, but did not see any formula. You say 
convert ?? How ?
ad8) I thought smallest move is 0,75%

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
4) right, but with side effect, it slow down integration if you have 
small offset to wanted temperature (ex 0.5-1 degree).

7) what is in rows P-V ? If just number please send compliment to 
Redmond and download OpenOffice

8) it move valve in 1% steps. You need hysteresis to inhibit move for ex 
from 40 to 41% if result of controller calculation is 40.49 and 40.51

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
4) but you inject one idea to my bain, thanks

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Welcome ;-) looking forward to it
ad6) what would be the max for P3 before oscillation will start ?
6a) why one doesnt use P^4 /5 then ?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri: R320 controller.c 151 ... still missing ... see: 2011-03-06 10:54

    if (((PID_update_timeout == 0)
&& (PID_force_update==-1))
 ||(PID_force_update==0)) {

Please quick explain the change 319>320 ??? THX

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard,

I made another (shorter in flash) solution for (PID_force_update==-1) 
now. It is in SVN

about 319>320

Basic idea is:
after wanted temperature change or after real temperature crossing wanted temperate (error from + to - and vice versa)
=> interator get some credit for not successful error curve direction

- if abs(error[t]) >= abs(error[t-2]) then credit=credit-1
- if credit == 0 then not allow update integrator

- temperature change must have same orientation like valve change in near history. Otherwise integrator is not updated.
- integrator is limited on valve_min and valve_max 
real code is litle bit more complicated, it must contain more boundary 
conditions and it is optimised for small flash, but idea is eqal

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
THX - I will try it
ad6) what would be the max for P3 before oscillation will start ?
6a) why one doesnt use P^4 /5 then ?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
R325: e.g. Temp is to high: Some time after temp is sinking it stops 
integrating = OK, but then sun shines into the room and temp is 
increasing agein. In this case it should continue integrating - it seems 
that credit was already=0 at this time ?!

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
controller line 315
    lastAbsError = absErr;
    last2AbsError = lastAbsError;
should'nt this be the other way round ?:
    last2AbsError = lastAbsError;
    lastAbsError = absErr;

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Example:
D: d5 01.01.10 12:00:17 A V: 52 I: 2380 S: 1700 B: 2459 Is: 0000
D: d5 01.01.10 12:04:17 A V: 52 I: 2390 S: 1700 B: 2459 Is: 0000
D: d5 01.01.10 12:06:37 M V: 56 I: 2384 S: 2300 B: 2459 Is: 0000
D: d5 01.01.10 12:10:37 M V: 56 I: 2384 S: 2300 B: 2459 Is: fd60
D: d5 01.01.10 12:14:37 M V: 56 I: 2384 S: 2300 B: 2459 Is: fac0
D: d5 01.01.10 12:18:37 M V: 56 I: 2384 S: 2300 B: 2459 Is: f820
D: d5 01.01.10 12:22:37 M V: 56 I: 2382 S: 2300 B: 2459 Is: f820
D: d5 01.01.10 12:26:37 M V: 56 I: 2384 S: 2300 B: 2459 Is: f580
D: d5 01.01.10 12:30:37 M V: 56 I: 2384 S: 2300 B: 2459 Is: f2e0
D: d5 01.01.10 12:34:37 M V: 55 I: 2384 S: 2300 B: 2459 Is: f040
D: d5 01.01.10 12:38:37 M V: 55 I: 2384 S: 2300 B: 2459 Is: eda0
D: d5 01.01.10 12:42:37 M V: 55 I: 2384 S: 2300 B: 2459 Is: eb00
D: d5 01.01.10 12:46:37 M V: 55 I: 2384 S: 2300 B: 2459 Is: eb00
D: d5 01.01.10 12:50:37 M V: 55 I: 2384 S: 2300 B: 2459 Is: eb00
D: d5 01.01.10 12:54:37 M V: 55 I: 2384 S: 2300 B: 2459 Is: eb00
D: d5 01.01.10 12:58:37 M V: 55 I: 2384 S: 2300 B: 2459 Is: eb00
D: d5 01.01.10 13:02:37 M V: 55 I: 2390 S: 2300 B: 2459 Is: eb00
 I think latest here credit should be set to max_credit
D: d5 01.01.10 13:06:37 M V: 55 I: 2390 S: 2300 B: 2459 Is: eb00
D: d5 01.01.10 13:10:37 M V: 55 I: 2390 S: 2300 B: 2459 Is: eb00
D: d5 01.01.10 13:14:37 M V: 55 I: 2390 S: 2300 B: 2459 Is: eb00

e.g. something like:
if (((lastErrorSign != ((uint8_t)(error16>>8)&0x80))) || (error16==0)
|| (absErr>last2AbsError))
 { //sign of last error16 != sign of current OR error16 == 0

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard G:
Thanks for  last2AbsError=>lastAbsError order problem. Fixed.

But I can't set credit to max_credit on (absErr>last2AbsError) 
condition. This is exactly condition which must be "pay" from credit. 
Otherwise we will see windup again.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Prob is, that the error persists right now. Is stops about e000. The 
influece of I&P is to low this way. Heater keeps on heating ... room is 
getting hotter  ... with last2error > error it would only wind up if the 
error is getting bigger and in this case we must do something about it 
!?
Is 327 just the copy prob or did you have a new idea ;-)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
maybe we can do something like
if ...|| (last2error>(error+hysteresis(optional))) { if 
credit<max.credit) credit+=1

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
on one valve since 2 day (since 321) I very often get E3 after flahing. 
In this situations the valve head (sitting on the heater) is fully open 
before installation.
If I set head valve manualy somewhere between open&close before 
installation, the error is gone ... any idea ???

old questions:
ad6) what would be the max for P3 before oscillation will start ?
6a) why one doesnt use P^4 ^5 instead of p^3 ?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard G:
Example1 for (absErr>last2AbsError) condition:
Wanted temperature is 18 real is 18.5 valve for this is 40% (just example)
Whats happen when sun shine directly into room? 
Temperature will grow. This mean, that error grows. In this case (absErr>last2AbsError) is true independently to valve.
You will integrate this error typicaly 2-3 hours and result is too low unreal value of integrator. Name for this is windup.

Example2 for (last2error>(error+hysteresis(optional)) condition:
You have wanted 21, real 21 and you will change wanted to 18.
Valve will closed to valve_min and temperature descends 0.3 degree/hour.
When temperature drop to 19 (just example) valve will compensate temperature drop.
Temperature will descent slowly because come warm air from other rooms (ex 0.1 degree/hour) 
But it unblock integrator limitation. 
Condition from example2 is true therefore integrator drops down, it will move valve back to limitation. 
And temperature descents more, therefore valve will compensate .... and cycle repeats. 
Result is unreal value of integrator, again.

Both example situations are from real life.

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi!
I'm using v1.0.

I too have the E3 problem in one room. I swapped the hr20 (but not the 
part which contains the blue wheel) without success. Now I swapped that 
part too. Tomorrow we will see if that helped.

Next problem is in the morning when the system heats up with water 
temperatures up to 80 celcius.
Wanted temperature is for example 16 celcius, but room temperature goes 
up to 19 celcius because the vent does not close fast enough.

In other rooms, wanted temperature is set to 21 celcius, the room goes 
up do 23-25 celcius.

If I change wanted temperature (even from 16 to 16,5 celcius) the vent 
starts to close.
Idea: Whatever is being reset when doing this, it perhaps should be done 
as soon real temperature crosses wanted temperature?


Other idea would be to add some kind of temperature prediction, so that 
openhr20 monitors if temperature rises and how fast it rises, and then 
calculate 30 minutes into the future to compensate inertia of the 
radiator.

Chris

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Chris:

If you have E3 problem on one valve, it probably have problem with 
"smooth" move. Solution is simple, set faster motor movement. It is more 
nosily, but safe. In version 1.0 its setting "14", change it in service 
menu.

Where you have valve and where you measure temperature? I was use 
controller same as in 1.0 over year, without problem.

Temperature prediction would be nice. Problem is that we don't know 
"transfer function" for all many different valves and it is imposible 
implement Laplace transform (flash is too small and space is almost 
gone).

If anybody have any idea, please feel free to do it. It is GPL code :-)

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
some update to motor speed setting info: for faster, you need LOWER 
number

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri I will think about it ... but my feeling is: It is better to accept 
windup in situations where Error grows and just block integration when 
error gets smaller ...

Do you have explanation for this E3 phenomenon ?
On one valve since 2 day (since 321) I always get E3 after flashing when reinstalling it.
In this situations the valve head (sitting on the heater) is fully open
before installation.
If I set head valve manualy somewhere between open&close before
installation, the error is gone ... any idea ???

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard

windup is not acceptable, integrator value outside reality make slow 
reaction of controler (hours to start heating). Too slow and resulting 
error is bigger compare to "permanet error". Please accept that less 
than 1 degree of error is nothing compare to measure precision 
(+-2degree, try compare 2 identical valves)

Except this you must compare it after may hour of operation when it 
stabilize.

Another way to solve it is reset integrator after any change like in 1.0 
release. But it need bigger I_factor (rel 1.0 use another scale than 
current SVN). Problem of this is oscilaton in some condition (real 
example from my one room:  t<-15 degree outside make oscilation 
+-1degree inside with 2 hours period. valve oscilate +- 5%)

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
OK: R327 see this log from last night - error stays ...

Please comment on my E3 situation. Sometimes ADJ 1 stays longer then 
usual ... on this valve

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard you have 0.37 degree difference ;-)
And it will be better after few changes of temperature, because you will 
have integrator more close to reality.

Calibration:

"Ad 1" is delay before real real calibration start
"Ad 2" open till motor slow down hard end. "Slow down" on this end in 
reality is almost impact.
"Ad 3" close till motor is not possible keep it on wanted speed and slow 
down over threshold (force to continue is too big)

Result is motor range in pulses. You can see it in service menu or Txx 
command (see to watch.c)

If measured volume of impulses is <100 or >1000 it create E3 error
Usual volume of pulses is around 500

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
THX:
1 but how come that ADJ 1 then sometimes stays longer in the display ??
2 that error disapppears, if head (part mounted on heater) is adjusted 
between open and close before installing valve

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri: In my case E3 typical comes under the following 3 conditions:

1. If I set the haed (blue wheel) to fully open and mount the valve. E3 
comes directly after ADJ_1. This sometimes also happens on other 
heaters/valves and seems to be a software prob.
It can be cured by setting the head somewhere between fully open & 
close...

2. It comes directly after calibration (after ADJ_3), when the valve 
should move to its 1st position.

3. It comes during operation ...
I wanted to find out the cause for my E3:
So I exchanged the motorunit (not the PCB) and the mounting head (blue 
wheel). E3 is still there.
Facts:
A. It looks like theese E3 only occure, when the valve wants to start.
B. It has nothing to to with "smooth move" of the motor unit, but maybe 
with the PCB.
C. The force needed to move the valve on this heater seems to be higher.
D. I am running on accu. So VCC is only 2,4-2,6V
Questions/Conclusions:
1. Is there a timeout after motor_start that can leed to E3?
2. Is there something like a torque_limit that can leed to E3 on 
startup?
3. Can we give the motor more torque (boost) during start up ?
4. which eeprom parameters (e.g. light eye) also can leed to this 
problem, please explain ?
5. I found a lot of E3(CTL_ERR_MOTOR) in the source code. It would be 
easier to determine what caused E3, when we sepearate E3 into different 
errors like E3a, E3b,....

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard G:
answers to Q:

1) yes, (motor.c line 241)

2) no, it not detect torque_limit. It detect stop or slow down.

3) yes, but it have compensation to battery voltage (motor.c line 253)

4)
- motor_pwm_min  - minimum PWM for motor
- motor_pwm_max  - maximum PWM for motor
- motor_end_detect_cal - define maximum time between two impulses to 
detect end in % of motor_speed - calibration (motor.c line 237)
- motor_end_detect_run - same as previous, but for normal run
- motor_speed - time between 2 impulses - simple controller keep motor 
in this speed
- motor_speed_ctl_gain - speed controller gain
- motor_pwm_max_step - speed controler max step on PWM

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
- what do you think could cause the prob ?
- what steps should I try next ?
- what about 5. ?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
You can try motor_pwm_max=0xff
you can try change line 241
you can try higher motor_end_detect_cal (default is 130 - you can try 
200, but "touch" on the end of range will be little bit strong)
you can speed up motor_speed (default is 168, you can try for ex 100)
You can in debug.h "#define DEBUG_PRINT_MOTOR 1" and see serial console 
(recommended, but it is just numbers because speed on this line is 
limited)

It is many choices. But I can't found where is problem because it works 
more than year for me without problem.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri THX for your hints !!!!!!!!!!!!!!!!!

I built in E31-E35: Usally it is this error:
    if ((MOTOR_calibration_step == 0) &&
        (MOTOR_PosMax<MOTOR_MIN_IMPULSES)) {
        MOTOR_calibration_step = -1;     // calibration error
        CTL_error |=  CTL_ERR_MOTOR;

The causes are:
week accu about 2,45V, new head which leeds to more torque needed
I suggest following solution:
1. Change back motor speed
 /* 15 */  {184,       184,       10,      255},   //!< motor_speed

2. Change battery compensation to 2,7V
                MOTOR_pwm_set((int16_t)(((uint16_t)config.motor_pwm_max 
* 256) / ((bat_average)/(2700/256))));

3. The cause for the longer adj_1 in the display could have something to 
do with bat calculation ...
Anyway, do we have enough time to calculate the bat average after boot 
to secure bat compensation before calibration starts ?? Sometimes I saw 
wrong values over COM like 4V... It also seems to be part of the problem 
...
Can we secure and validate bat calculation AND compensation

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Only one question: are you sure to slowdown motor? 184 is bigger time 
for one pulse = slower

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
yes, because it is OK as long as battery is fine. I think the prob has 
to be cured somewhere else ;-)

Just an example of wrong battery calc (accu has 2,4V):
#Connection opened @ COM1, 9600, 8N1, DTR:On, RTS:Off
>V
V:OpenHR20 (10*16+3).( 2*16+7) Mar 14 2011 20:21:46 101
>D
D: d5 01.01.10 12:13:56 A V: 52 I: 2524 S: 1700 B: 3969 Is: 0000 E:08 X
>D
D: d5 01.01.10 12:13:56 A V: 52 I: 2524 S: 1700 B: 3969 Is: 0000 E:08 X
_____________________________________________
V:OpenHR20 (10*16+3).( 2*16+7) Mar 14 2011 20:21:46 101
D: d5 01.01.10 12:00:17 A V: 80 I: 0000 S: 1700 B: 0000 Is: 0000
D: d5 01.01.10 12:04:17 A V: 52 I: 2530 S: 1700 B: 4207 Is: 0000 E:04

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
We have enough time to calculate the bat average after boot.
bat_average cant be > 0 till we have AVERAGE_LEN measures (adc.c line 
92)
and calibration can't start (main.c line 295)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
how come, that we have wrong voltage calculation then ? - accu=2,4V!!
V:OpenHR20 (10*16+3).( 2*16+7) Mar 14 2011 20:21:46 101
D: d5 01.01.10 12:00:17 A V: 80 I: 0000 S: 1700 B: 0000 Is: 0000
D: d5 01.01.10 12:04:17 A V: 52 I: 2530 S: 1700 B: 4207 Is: 0000 E:04
D: d5 01.01.10 12:08:17 A V: 52 I: 2530 S: 1700 B: 4203 Is: 0000 E:04
D: d5 01.01.10 12:12:17 A V: 52 I: 2530 S: 1700 B: 4198 Is: 0000 E:04
D: d5 01.01.10 12:13:05 M V: 52 I: 2530 S: 2300 B: 4240 Is: 0000 E:04
D: d5 01.01.10 12:17:05 M V: 52 I: 2529 S: 2300 B: 4292 Is: 0000 E:04

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
It must be something different. Are you sure that you don't have some 
parasite source of power? Usually it is 5V powered JTAG or serial 
converter.
It you have 5V powered serial, 5V come from RXD signal to CPU. Solution 
is simple, add one diode (example 1N4148 or any) anode to RXD on CPU, 
katode to serial convertor.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
JTAG is connected, but board has no power ... Serial comes from a 
MAX2232 ... I will check that ! But anyway can we validate the calculate 
voltage to sensible limits like 1-3,5V

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri: As most times - you were right. Seial and JTAG influence voltage 
calculation... BUT the situation stays confusing:

- I made 3 versions ... bat. compensation with 2,6/2,7/2,8V
- I flashed 2,6V = Revision 327,
- disconnected everything
- accu (2,45V) out, wait 10s, accu in
- mount on head (heater)
- AD1, E3, motor was quite slow when it tried to start

- I flashed 2,7V
- same procedure, E3, no acustical difference when it tried to start
- I flashed 2,8V
- same procedure, WORKS OK, motor faster

- I flashed back 2,6V
- same procedure, WORKS OK, motor as fast as at 2,8 ???????????
- I took accu out for abot 10min.
- AD1, E3, motor was quite slow when it tried to start  ???????

- I flashed back 2,8V
- same procedure, E3, no acustical difference when it tried to start 
???????
- I took accu out for about 10min.
- same procedure, WORKS OK, motor faster ???????

during this test, most times I just flashed the Programm and not the 
EEPROM (EEsave fuse is set).
- Are there any parameters stored in EEprom until calibration is done ?
- Are there any variables not initialised, that may stay in RAM ?
I am confused and frustrated now .. I need some fresh ideas .. pls help

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
voltage compensation is ONLY for motor start. After start it keep speed 
on config.motor_speed value (define time for 1 pulse)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri: I dont understand the connection to the prob from my last post ???

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
- Maybe 1 pulse is to short that motor reaches sensible speed ... ?
- but waht are your suggestions regarding the confusing E3 situation 
described in my post ?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri any idea ??

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri: The Prob comes to 99% from a wrong ADC bat value. Waht did I do:
Reboot over COM and imediately disconnect COM (Diode implemented) from 
valve:
D: d2 02.01.07 00:38:59 M V: 52 I: 2421 S: 2300 B: 3385 Is: e3f8 X
D: d2 02.01.07 00:39:05 M V: 52 I: 2423 S: 2300 B: 3386 Is: e3f8 X
D: d2 02.01.07 00:44:23 M V: 52 I: 2426 S: 2300 B: 3387 Is: e3f8 X
BD: d2 02.01.07 00:44:56 M V: 52 I: 2430 S: 2300 B: 3391 Is: e3f8
B1324
V:OpenHR20 (10*16+3).( 2*16+7) Mar 15 2011 07:05:51 101
D: d5 01.01.10 12:00:41 A V: 80 I: 2430 S: 1700 B: 4755 Is: 0000 E:08 X
D: d5 01.01.10 12:00:55 A V: 80 I: 2430 S: 1700 B: 4759 Is: 0000 E:08 X
V:OpenHR20 (10*16+3).( 2*16+7) Mar 15 2011 07:05:51 101
D: d5 01.01.10 12:00:17 A V: 80 I: 0000 S: 1700 B: 0000 Is: 0000
D: d5 01.01.10 12:00:41 A V: 80 I: 2435 S: 1700 B: 4596 Is: 0000 E:08 X
D: d5 01.01.10 12:01:07 A V: 80 I: 2437 S: 1700 B: 4596 Is: 0000 E:08 X
D: d5 01.01.10 12:01:08 A V: 80 I: 2437 S: 1700 B: 4596 Is: 0000 E:08 X
V:OpenHR20 (10*16+3).( 2*16+7) Mar 15 2011 07:05:51 101
D: d5 01.01.10 12:00:17 A V: 80 I: 0000 S: 1700 B: 0000 Is: 0000
D: d5 01.01.10 12:00:27 A V: 80 I: 2437 S: 1700 B: 3050 Is: 0000 X
D: d5 01.01.10 12:00:33 A V: 80 I: 2437 S: 1700 B: 3034 Is: 0000 X
D: d5 01.01.10 12:00:35 A V: 80 I: 2437 S: 1700 B: 3029 Is: 0000 X
V:OpenHR20 (10*16+3).( 2*16+7) Mar 15 2011 07:05:51 101
D: d5 01.01.10 12:00:53 A V: 80 I: 2437 S: 1700 B: 4705 Is: 0000 E:08 X
V:OpenHR20 (10*16+3).( 2*16+7) Mar 15 2011 07:05:51 101 IsB1324
D: d5 01.01.10 12:01:16 A V: 80 I: 2437 S: 1700 B: 4708 Is: 0000 E:08 X
As valve thinks it has more than 4V it reduces PWM at motor start and 
motor does not start ... what should I try next ??

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi!

Replacing the electronic part or the mechanical part of the hr20 was no 
solution for the e3 problem. I also changed batterys.
I'm now trying with lower and higher values for 14.

It only happens at one radiator, so I think it's moving to heavy.

Besides: It is the only rondostat which shows a voltage of 3,55V (or 
above, the output is limited by 8 bit + offset of 1V because I'm using 
my own systen to readout the serial data from the rondostats).

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi Jiri,

I can confirm this:
I have no external voltage at my rondostat, only the two internal 
batteries and I'm also reading too high voltages.
I do not provide any external power to the rondostates.

Richard, how old are your rondostates? I bought four new ones and used 
only one of them, which then showed the E3 error. Then I started 
replacing the rondostat, but always used the new ones... never tried one 
of the older ones.
Maybe they changed something with the hardware?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
1. Chris do you have the wrong voltage reading all the time ?
2. When does the error occure (after AD1 = ADJ2 ?)
In my case it sometimes is OK, but I did not find out the case for i so 
far. It might really be a Prob of the PCB. Because as I wrote I tried to 
exchange the motorunit, but the error stayed !
Got mine (I have 6)
http://www.amazon.de/gp/product/B003URRKP8/ref=ox_...
from amazon last month ... did you find a fabrication date somewhere ?
3. I attached You a Version ehich has implemented 4 different errors for 
E3 = E31-E34 which correspond with the different locations in the code, 
where E3 comes from !

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
3. I attached You a Version which has implemented 4 different errors for 
E3 = E31-E34 that correspond with the different locations in the code, 
where E3 comes from ! All my changes in code are marked //jr
Most times I get E34.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
It looks that we have problem with motor start you can try:

- change "#define MOTOR_IGNORE_IMPULSES 2" to bigger. It define number 
of motor pulses ignored on start to control speed.

- change motor.c line "motor_timer = motor_max_time_for_impulse<<2;" to 
multiply by more than 4. Ex "motor_timer = 
motor_max_time_for_impulse<<3;" multiplies by 8

- enable "DEBUG_PRINT_MOTOR"

Richard G: battery voltage measurement is one of oldest part of code. 
(more than 2 years) and I have not any problem with this. Please found 
where is problem, it can be useful for others.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Ex "motor_timer = motor_max_time_for_impulse<<3;" I tried that some time 
ago. It did not help.

Prob is wrong voltage and this PWM calc:
MOTOR_pwm_set (config.motor_pwm_max * 256) / ((bat_average)/(2800/256))
If valve thinks it has 4V: PWM=175, 2,4V: PWM=291(will lead to 255)

Is voltage calculated with the same adc like temp ? It must have 
something to with the adc or something is wrong with pcb.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
PWM value will not lead 255, see too MOTOR_pwm_set function

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
will lead to pwm_max of cause ... ;-)
How many pulses are needed for 0,5% move (can be max ignored), so that 
we dont drive to far ?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
typical 100% is 500-550pulses

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
1. so we should not ignore more than 5 (MOTOR_IGNORE_IMPULSES ) pulses ~ 
0,5%... right ?
2. Can you pls quick explain the 6 states of task_ADC. Is noise 
cancelation only done for temp (  case 3: 
update_ring(BAT_RING_TYPE,ADC_Get_Bat_Voltage(ADCW)))

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
you can use bigger value for MOTOR_IGNORE_IMPULSES. It is only for motor 
speed controller, motor will be stopped on wanted position independent 
to this.

Tip for test: use config.motor_pwm_max=config.motor_pwm_min=0xff and see 
whats happen

AD steps:
1) (start_task_ADC) not used, just start ADC
2) battery, not used
3) battery, prepare for temperature
4) first temperature for compare
5) temperature, used only when result is same as previous, or repeat 5)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
THX, so no noise canceling for bat.
Jiri do you have any further idea (except external power) where theese 
wrong bat measurements can come from ...

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Is there any chance to read the voltage directly an the valve ? (like 
watch...)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
I built it into watch.c.voltage is defenitly measured wrong on this 
valve = same values as when connected to COM
D: d5 01.01.10 22:55:16 - V: 56 I: 2534 S: 2450 B: 3255 Is: 0000 E:04

Motor when error occures:
+ 0aeb ae
+ 0767 ae
+ 075f ae
+ 0764 ae
- 0a7f ae
 07db ae

AND of course no error when setting pwm_min=max
+ 029f fa
+ 05bb fa
+ 04c4 fa
+ 04aa fa
+ 04a0 fa
+ 049c fa
+ 04a0 fa
+ 049d fa
+ 0498 fa
...
+ 04b4 fa
+ 04b2 fa
+ 04b7 fa
+ 06d0 fa
- 054d fa
- 04ae fa
- 049c fa
- 04d3 fa
- 04f1 fa
- 0504 fa
- 0502 fa
- 0509 fa
- 0501 fa
- 050a fa
...

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
another error situation:
V:OpenHR20 (10*16+3).( 2*16+7) Mar 16 2011 17:55:45 101
D: d5 01.01.10 12:00:17 A V: 80 I: 0000 S: 1700 B: 0000 Is: 0000
+ 08b7 96
- 0fcd 96

and after connecting and disconnecting JTAG voltage is measured OK ????:
V:OpenHR20 (10*16+3).( 2*16+7) Mar 16 2011 17:55:45 101
D: d5 01.01.10 12:00:17 A V: 80 I: 0000 S: 1700 B: 0000 Is: 0000
+ 076e fa
+ 0501 fa
+ 05db fa
- 0515 fa
- 04b6 fa
....
D: d5 01.01.10 12:00:56 A V: 80 I: 2457 S: 1700 B: 2529 Is: 0000 E:04 X

After taking accus out/in voltage on valve (nothing connected) is wrong 
again - valve starts but stops short after:
D: d5 01.01.10 12:01:17 A V: 80 I: 2457 S: 1700 B: 3428 Is: 0000 E:08 X
+ 05aa b9
+ 0760 b9
+ 06f2 b9
+ 0722 b9
+ 0727 c3
+ 06c5 cd
+ 063f d5
+ 05e2 d7
+ 05ab d6
+ 0598 d4
+ 05a1 d2
+ 05b7 d2
+ 05c5 d2
+ 05ca d2
+ 05d0 d3
+ 05ce d4
+ 05ba d4
+ 05b6 d4
+ 05c2 d4
+ 05c7 d4
+ 05ba d4
+ 05b9 d4
+ 05cb d4
- 099e ba
- 074f ba
 080d ba

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
nice, it is definitely compensation to wrong battery voltage.
I remember correct that you have Dragon? If yes, try it manualy.
Without start SW: Set AD reference to VCC, input channel to BadGap 
reference and start measure. Result will be number representing known 
voltage (1.1 badgap) on unknown scale (VCC). Calculate is easy. You can 
compare this value to VREF pin on MCU (ADMUX must be switched to "AVCC 
with external capacitor at AREF pin")

But this make one idea. VREF is "AVCC with external capacitor at AREF 
pin" If you have different (bigger capacity) on VCC, it can create 
problem with charge this capacitance after AD switch on (normally it is 
in power down state). You can try add one or more "dummy" measures 
before real or use code like for thermometer.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
I repeated accu out/in noe several times and sometimes V is OK. 
Interesting is, that the wrong measurements also differ .... Offest is 
0,5-1,5V. I did not find this phenomenon on another valve .. but I just 
tried reboot 5 -10 times....
1. Jiri can you please integrate a voltage display into menu (middle 
button)
2. Do You have any idea to diagnose this wrong measurement and display 
an error ???
3. Of Courese we could always start with MAX_PWM and it would work ... 
but this way the users wont find out that they might have a defect valve 
...

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
you can disable battery compensation completly and use simple:
MOTOR_pwm_set(config.motor_pwm_max);

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
same thinking, but error stays hidden this way...
@Jiri please enter voltage display at least with a #ifdef for me and the 
novice software guys ;-) with middle button
@Chris: here is my "hack version" with voltage display on first watch 
variable and , E31-34, 5 Ignore Pulses, motor_timeout*8

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri why did you or the others implement this bat compensation ?
What about 1 & 2 from last post ???

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Battery voltage on LCD can be enabled on rev 330.
change #define MENU_SHOW_BATTERY 0
to #define MENU_SHOW_BATTERY 1

I am not able detect wrong battery measurement. How? We are not known 
reason.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Good guy - THX !!!!!!!!!!!!!
Jiri why did you or the others implement this bat compensation ?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Reason for battery voltage compensation was external power.
For debug and somebody for normal functionality use 5V power. With this 
power it works, but motor is too strong on start.
With "normal" batteries one reason is bigger noise on motor start. We 
can remove it or create option for this.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
let us keep it for the moment and wait what Chrisis results are ... see 
you  tommorow ;-)
@chris: please read/answer from post 9:44 on ...

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
@Chris: this is rev.330 with bat display (last Param on middle button) 
including differentiation of E3 into E31-34

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
@Jiri: It would be quite usefull, if one could choose, that the 
parameter menue (middle button) and the watch menues do not return 
automatically to main menue. This way one could watch a specific 
parameter without warming up the valve (by pressing the buttons all the 
time) ... and it would be a lot easier during testing or valve setup ...
I hope to confice you ;-)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
means .. something more professional than my quick hack:
if (( kb_events & KB_EVENT_NONE_LONG ) && (menu_state<menu_home2 || 
menu_state>menu_home5))

BTW: A little prob i have not figured out in menue is:
if I set a manual temp and enter menu_home2..5 and press AUTO/MANU 
button to leave this menue ... sometimes my manual set temp is back to 
auto again and sometimes it stays on manu - I think this has nothing to 
do with my change !!???

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri:
1. Regarding my prob with changing to AUTO TEMP from last post (As I am 
simulating the wheel with PLC, I am always on manual)

Why do we change_mode in menue_homeX keyboard.c ~260 ? Is this the cause 
why temp is set to AUTO when pressing AUTO in this menue (sometimes) ?
if ( kb_events & KB_EVENT_AUTO ) {
                    CTL_change_mode(CTL_CHANGE_MODE); // change mode
                    menu_state=menu_home_no_alter;
                    ret=true; 
                } else if ( kb_events & KB_EVENT_AUTO_REWOKE ) {
                    CTL_change_mode(CTL_CHANGE_MODE_REWOKE); // change mode
                    menu_state=menu_home_no_alter;
                    ret=true;
 why not just: menu_state = menu_home;

2. integratorBlock=6; means blocking for 6x4 minutes ?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
1. Why not?  It is just alternate content of main screen
2. agree

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
mistunderstandig?!: If I want to exit alternate menue by pressing AUTO, 
the wanted temp should not change, also the Mode should not change ... 
in my case from "23,0 MANU" to "17,0 AUTO"... in some other menues AUTO 
is also for EXIT without SAVE ! This is also bad for testing, because 
integrator start all over again ;-)

BTW: The more I look into it, the more I am fascinated from the work 
sticking in this source code !!!

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi Jiri and Richard,

I'm sorry but I do not have my jtag programmer at the moment so I can't 
flash the rondostates right now.

I just connected a logic analyzer to tx of the rondostat to see the 
serial output and I get this: "B: 4446". Real voltage is 2,88V...

At the other rondostates, they report 2,62V to 3,34V. The one which 
shows 3,34V is aprox. at 2,8V too in reality.

Interesting: When I used a multimeter to meassure the voltage, I caused 
a short circuit between vcc and ground, so the rondostat did a reset. 
Back in my room, where my laptop shows all rondostates, it says 255 
which is <=3,55V. And: The rondostat sowed e3 after the reset.

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
ups, the last line should be:
which is >=3,55V. And: The rondostat showed e3 after the reset.

Btw: This is one of the newer rondostats, it still has the foil on it 
which protects the display against scratches...

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
Out of 4 rondostates, only one showed a voltage of 2,8V as expected.
The others showed something between 3,5 to 4,4 volts....
The one with 4,4V shows E3.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Chris: Are you sure that you don't have other power source than 
batteries? (Ex: serial cable powered by 5V, JTAG, anything)

You can try code from SVN. It contain EXPERIMENTAL improvement on 
battery measure.

PS: it is strange that you measure invalid battery value. This 
functionality need only MCU and capacitor on VREF pin.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Chris an I measure the same symptoms... I have just one valve that 
behaves like this. Chris, when wiil you programm new code ??

Jiri:
1 mistunderstandig?!: If I want to exit alternate menue by pressing 
AUTO, the wanted temp should not change, also the Mode should not change 
... in my case from "23,0 MANU" to "17,0 AUTO" (I am always on MANU 
because of my wheel simulation;-) ... in some other menues AUTO is also 
for EXIT without SAVE ! This is also bad for testing, because
integrator start all over again ;-)

BTW: The more I look into it, the more I am fascinated from the work
sticking in this source code !!!

2. What about putting integrator_credit on "D" line for COM ... at least 
during our testings ??

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
ad2) OK?
#if DEBUG_PRINT_I_SUM
  print_s_p(PSTR(" Is: "));
  print_hexXXXX(sumError);
  print_s_p(PSTR(" Ic: ")); //jr
  print_decXXXX(CTL_interatorCredit);
#endif

3. How can I set Is after reboot manually to a certain value (necessary 
during testing). Do we have a COM command or any other way ... ? Can we 
use the EEprom edit mechanisem some how ??

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard,
I almost accept your notices. Only one difference is hex output for 
CTL_interatorCredit, reason is missing support for decimal numbers<0.

Jiri

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri did you accept 1 & 2 ???!!!
(I thought credit is only poistive ...)

How can I achieve 3 ??

4. How come - see sumerror
D: d6 19.03.11 09:41:08 M V: 56 I: 2317 S: 2300 B: 2707 Is: e1f0
D: d6 19.03.11 09:45:08 M V: 56 I: 2317 S: 2300 B: 2706 Is: e168
D: d6 19.03.11 09:49:08 M V: 56 I: 2317 S: 2300 B: 2705 Is: e0e0
D: d6 19.03.11 09:53:08 M V: 55 I: 2324 S: 2300 B: 2702 Is: e020
D: d6 19.03.11 09:57:08 M V: 55 I: 2324 S: 2300 B: 2701 Is: df60
D: d6 19.03.11 10:01:08 M V: 59 I: 2324 S: 2300 B: 2694 Is: ff40
D: d6 19.03.11 10:05:08 M V: 59 I: 2330 S: 2300 B: 2701 Is: fe50
D: d6 19.03.11 10:09:08 M V: 59 I: 2330 S: 2300 B: 2701 Is: fd60
around 10:05 valve started calibration ??? why ? today is saturday

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
THX: just verified the changes ;-)
bat voltage display has a prob = shows only 2. instead of 2.123
        LCD_Print
Char
(bat_average/1000, 2, LCD_MODE_ON);

        LCD_PrintDec(bat_average/100, 2, LCD_MODE_ON);
        LCD_PrintDec(bat_average%100, 0, LCD_MODE_ON);

Jiri please stay with /100, because this way I see wether accu is 
charging or discharging earlier (I charge them from PLC) THX

pls comment on 3 & 4

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Regarding alternate and service watch from one of the last posts should 
no be left automatically (because we want to watch a certain parameter 
for a longer time ;-) menu.c 125:
        } else if (( kb_events & KB_EVENT_NONE_LONG ) && 
           ! (menu_state>=menu_home2 || menu_state<=menu_home5 || menu_state==menu_service_watch)) {

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
@Richard: I have to wait until I get my jtag programmer back.... don't 
know how long it will take....

BTW: The rondostat at which I caused the short circuit keeps running 
into E3 error.
Question: When is battery voltage meassured? For me it looks as if it is 
read only at startup, because that coult perhaps explain the wrong 
voltage (?)

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
@Jiri: There is no other power source:

- At the other rondostats which are mounted at the radiators, there is 
an external circuit connected which captures the serial data and sends 
values using rfm12. It gets its power from the rondostat. So it will 
perhaps add capacity, but it definitly is no power source ;)

- The logic analyzer is connected to gnd and tx pin, but it has high 
impedance inputs, no pullups and so on.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
battery is measured quite often (<10s)...wait until you have your 
programmer back. there is a bat display in alternate menue already ;-)

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
batt voltage show only 2. ? For me it is correct, show 2.55.

You don't need 3) it is almost equal to config.valve_center. Difference 
is only in units. Problem is that we don't have free flash for any 
useful idea.

Every Sat on 10:00 is automatic recalibration. It is useful also for 
keep valve heath.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
I change battery voltage in LCD back to mV without decimal point.

battery voltage is measured every second. Presented value is average 
from last AVERAGE_LEN (= default 15) values

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
men you are fast THX "mV"

Regarding alternate and service watch from one of the last posts should
no be left automatically (because we want to watch a certain parameter
for a longer time ;-) menu.c 125:        } else if (( kb_events & 
KB_EVENT_NONE_LONG ) &&
           ! (menu_state>=menu_home2 || menu_state<=menu_home5 || 
menu_state==menu_service_watch)) {

ad3) in my case different heaters have quite different valves, so for 
testing purposes it would be great to start with manual set Is by COM or 
LCD. I thought during debuggin it would be quite helpfull to be able to 
manipulate static variables or variables from service_watch

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard,

add to your sumErr log (4): I down know why, it looks strange.

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
here it is. around 7pm, 9pm, and today 5am and 7:40 there is a temp 
update with same temp=23.0

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Jiri Bat display does not work for me with CHAR. I press middle button 
right after version string and DATE skip define is set ! Display shows 
10:00 (no clear screen) and when first bat calc is done the left 0 looks 
like this
-
-

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
                    if (((CTL_error &  (CTL_ERR_BATT_LOW | CTL_ERR_BATT_WARNING)) == 0)
                  && (RTC_GetDayOfWeek()==6)
                && (RTC_GetHour()==10)
                && (RTC_GetMinute()==0)) {
                        // every sunday 10:00AM
                        // TODO: improve this code!
                        // valve protection / CyCL
6 .. then is saturday and not sunday as stated in comment ???

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
I connected a rondostat to a variable power source. When it callibrates 
and I change power, the motor of the rondostat gets slower or faster, 
but it returns to its normal speed after a very short time (a second or 
so).
So the voltage messurment seems to work.

Strange1:
I set it to 3.0V, but it displays "batt". Why? Is this condition cleard 
automatically when voltage rises, or only at reset or button-event?

Strange2:
Serial Output reports a voltage of 3,06V now.
Multimeter says 3,06V too (hm, very precise, it was rather cheap....)
Power-Supply is set to 3,0V.
=> All correct.
But when it was on batteries, the same rondostat showed 3,2V (serial) 
while real voltage was 2,8V.

I set power supply to 2,8V now. Serial reports 2,87V now.
I set power supplay to 3,5V, serial reports 3,5V.

Connected batterys while power supply is still connected to prevent 
reset, then disconnected power supply. Serial shows 2,8V, real voltage 
is 2,8V. Still shows batt.

Removed and reinserted batteries to do a reset. Real voltage is still 
2,8V
. Batt-Message is gone, serial output reports 3,55 or more volts. Motor 
speed seems to be lower and when it starts the boost is barely there.

Switched on power supply (3V), batteries still in the rondostate. Serial 
still shows 3,55V or greater.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
bat displays are not reversible (except reboot or #define). Once voltage 
droped below 2,4 bat warning comes on. Low bat is 2.0.
On my defect valve I also could not reproduce the situation ... I gues 
if you try it several times (powerless in between each time!!) with 
powersupply you will get wrong readings there as well

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
- battery warning and error is not reversible by good reason. Battery on 
end of life usually refresh voltage without stress. In this situation is 
show low voltage information only when motor runs.  I want to keep this 
information.

- I fix "char" problem on voltage on LCD.

Richard: You are right about mistake in comment about Saturday automatic 
recalibrate.

Chris: I don't have any idea why batteries is measured wrong and 
external power supply is OK. I am not able repeat this problem. Maybe 
some difference on PCB? Just idea, can you compare your PCB with photos 
and other documentation?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri: 339 bat display OK, but we have a : in display (before we had a .)

a) Do we realy need the Highword of summerror .. it is FFFF or 0 and if 
it is ffff the lowword will start with f..a anyway ?? But it is cleaner 
code of course ;-)

b) It would be quite usefull, if one could choose, that
alternate menue (middle button) and watch menue do not return
automatically to main menue. This way one could watch a specific
parameter without warming up the valve (by pressing the buttons all the
time) ... and it would be a lot easier during testing our valve setup 
...
I hope to convice you ;-) menu.c 125:
        } else if (( kb_events & KB_EVENT_NONE_LONG ) && 
           ! (menu_state>=menu_home2 || menu_state<=menu_home5 || menu_state==menu_service_watch)) {
c) did you find anything in my log ?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
":" in voltage fixed

a) it could be 0x00012345 or 0xffff2345. Low word is same, but meaning 
is different

b) I want to have automatic return to main_menu. You can create change 
on your sources and it will kept after "svn update" command.

c) what is wrong on this log? PS: create chart in OpenOffice or Excel is 
sometimes useful.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
a) What was your maxsumerror so far ? mine typ. stops at ffff a/9

b) I tried snv commands some time ago, but it doesnt work in some of my 
network surroundings (proxy,firewall,...), so I have to patch al my 
changes all the time

hope to convince you at least to:
        } else if (( kb_events & KB_EVENT_NONE_LONG ) 
#if NO_AUTORETURN_FROM_ALT_MENUES 
           && ! (menu_state>=menu_home2 || menu_state<=menu_home5 || menu_state==menu_service_watch)) 
#endif  {

c) I dont understand, thought you mentioned something strange  ...

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
strange is this part:
D: d6 19.03.11 09:57:08 M V: 55 I: 2324 S: 2300 B: 2701 Is: df60
D: d6 19.03.11 10:01:08 M V: 59 I: 2324 S: 2300 B: 2694 Is: ff40

what happen at this time?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
I thought sat 10:00 auto_calibration, main.c 241
                    if (((CTL_error &  (CTL_ERR_BATT_LOW | 
CTL_ERR_BATT_WARNING)) == 0)
                  && (RTC_GetDayOfWeek()==6)
                && (RTC_GetHour()==10)
                && (RTC_GetMinute()==0)) {
                        // every saturday 10:00AM
                        // TODO: improve this code!
                        // valve protection / CyCL
                       sumError=0;
sumerror=0 should not happen here ! right ? should only happen if valve 
is taken from head (E2)

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard: right, I must fix it

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
1a ... I hope I may be looking forward to my bonus ;-)
"#if NO_AUTORETURN_FROM_ALT_MENUES"

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
R341: Jiri, why should autocalib need new sumerror. 99 times out of 100 
;-) calib stays about the same ! This way every saturday it gets to hot 
or to cold at 10:00. I think giving credit is good enough !!
Only if valve is taken from head (E2) we should reset sumerror ...

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
max sumError if defined on controller.c line +-319 (max inpact to valve 
is 50%)

option NO_AUTORETURN_FROM_ALT_MENUES is added

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard,

Calibration is same only on same conditions. But normally last 
calibration is 1 week old. And it depend to battery, heater tempterature 
atc.
But you are right, last value can be better than 0. I will create option 
for it.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
THX and a beer for R342:

Yes regarding impact of max 50%, but you agree that most times autocalib 
will bring about the same results ... so we do not need sumerror=0 here 
!! giving credit to adapt little changes will be good enough. (in my 
case 5% change mean 1-2°C more/less in the room. min/max/center are 
quite different on my heaters; they also have different valvetypes)

Only if valve is taken from heater (E2) we should start all over again 
with sumerror=0

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
R343: Why not ?
#if CyCL_RESETS_sumError
sumError=0; // new calibration need found new sumError
CTL_interatorCredit=config.I_max_credit;
integratorBlock= DEFINE_INTEGRATOR_BLOCK (or eeprom)
#else
CTL_interatorCredit=config.I_max_credit;
integratorBlock= DEFINE_INTEGRATOR_BLOCK (or eeprom)
#endif

When do we need the block ? Also here ?:
    if (mont_contact & KBI_MONT) {
        CTL_error |=  CTL_ERR_MONTAGE;
    sumError=0;

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
suggestion:
#if CyCL_RESETS_sumError
  sumError=0; // new calibration need found new sumError
#endif
  CTL_interatorCredit=config.I_max_credit;

______controller.c
   if (CTL_interatorCredit==config.I_max_credit) {
      integratorBlock=DEFINE_INTEGRATOR_BLOCK (or eeprom)

   if (updateNow) {

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Try R327

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
you mean 344 ;-) ... tommorow ... my girls are waiting ... see you

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri, I verified all the changes compared to 339:
!!! VERY VERY  WELL DONE !!!

Suggestion regarding controller:
1.Your new idea from last weeks regarding I part works well. But 
sometimes an offset 0,1-0,2 stays. I know that is not much ;-). My 
suggestion is to give credit, if error is around 0 (instead=0). Existing 
code
     if (absErr >= last2AbsError) { // error can grow only limited time
will prevent growth of sumerror anyway.
An Option could be to give the "tollerance credit" just once. But this 
would produce more code ;-). This is why we should try this first:
      if ((error16 >= 0) ? (v0 < config.valve_max) : (v0 > config.valve_min)) {
        if (((lastErrorSign != ((uint8_t)(error16>>8)&0x80))) || 
            ((absErr==last2AbsError) && (absErr<=I_0_TOLLERANCE))) { //sign of last error16 != sign of current OR abserror around 0
          CTL_interatorCredit=config.I_max_credit; // give credit

#define I_ERR_TOLLERANCE_AROUND_0 15 // unit 0,01°C. Set it quite 
restrictive !


2. I suggest a define in controll.c 303:
            CTL_interatorCredit-=(absErr/I_ERR_WEIGHT)+1; // max is 
1200/25+1 = 49 impact of error on I part

#define I_ERR_WEIGHT 25 //impact of error on I part

Author: Chris (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Hi Jiri,

I logged temperature and vent position in one room to see the 
overheating in the morning. Here it is.

Any idea what causes the wrong battery messurements? Why is is it after 
reset and not before with the same rondostat? Strange.

Chris

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
btw: The "own sensor ic2" does not messure room temperature. You can 
ignore it.

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi,

I got my jtag programmer back and flashed rev 344 (without rfm12).

I hear the initial boost of the motor (I see you disabled compensation 
in config.h, so wrong battery messurements should not be a problem any 
more?)

Bat on lcd shows 3281, multimeter shows 2,89V.

Csn I use rev 344 as "productive" version, or won't it work?

Chris

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
I also use it with the mods from above - no prob so far

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
I took the batteries in and out several times. There was nothing else 
connected to the rondostat and I did not mount it. Here is the batt 
output:

2,8V (ok)
3,5V
4,4V
5,4V
2,8
2,9
2,9
3,1
2,9
2,9
2,9
2,9
2,9

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
same on my defect one

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
Could it be a bug somewhere in the firmware (ad-init?) or a bug of the 
atmega itself?

I don't think it is a "defect" in hardware because it occurs only 
sometimes and changes only on reset (not sure about this... I never 
watched a rondostat whith wrong messurements correct itself without 
reset... did you?)

I habe 6 rondostats with openhr20 that work like a charm (except for the 
overheating problem in the morning which is in all rooms).

And I have 4 rondostates which are not mounted because auf E3 problem / 
wrong voltage problem or wrong callibration byte so serial data is not 
working. (how can I correct this?)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
I agree but have no idea how to get closer to the reason

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Chris, comments to your values:
You have externaly disabled heating and SW wan't to fix this error. 
Mechanism to do it is integrator (old name was "zero error 
compensation")
Problem is that current version of windup protection not help in this 
situation (I will improve it later).
Soloution for you is set I_Factor to 0 and set valve_center very precise 
manualy.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Chris, I have idea how to solve your problem. Please wait till tomorrow.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
I thing that problem with regulator windup on "central heating off" can 
be solved on Rev345. It need tests.

I have NO idea where is problem with bad battery measure. But I create 
some debug, please enable DEBUG_BATT_ADC in debug.h and report me 
result. (need SVN rev 346)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri, men you are fast - when I was ready with patching 349, you were at 
350 already. I take this for the night ;-)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri add this to com.c ?!
#if DEBUG_PRINT_I_SUM
  print_s_p(PSTR(" Is: "));
  print_hexXXXX(sumError>>16);
  print_hexXXXX(sumError);
  print_s_p(PSTR(" Ib: ")); //jr
  print_hexXX(CTL_integratorBlock);
  print_s_p(PSTR(" Ic: ")); //jr
  print_hexXX(CTL_interatorCredit);
  print_s_p(PSTR(" Ie: ")); //jr
  print_hexXX(CTL_creditExpiration);
#endif

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri could you please explain the changes regarding controller since 344

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
It s simple:

- when integrator credit is empty or temperature change I compare 
current error with error on last change. If it isn't smaller than 1/2 
change on integrator is reverted.
- integrator credit have limited lifetime

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
1. OK. Isnt the aim of CTL_interatorCredit and CTL_creditExpiration the 
same. Both expire. The 3rd function is revert (I think its a good idea).
All 3 mechanisems have the same goal = prevent windup = right ?

This is why I dont understand why we need CTL_creditExpiration - pls 
explain?

2. When do I have to change I_ERR_WEIGHT and when I_Factor ?

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
ad2) log from last night: Impact on I at errors <0,5°C is to low / to 
slow ...

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
too slow? Try create chart in excel. I can't be better. :-)

We need 2 different
CTL_interatorCredit - allow maximum change volume, depend to integrator 
change size
CTL_creditExpiration - allow maximum time

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri, I nearly expected your answer ;-) ... I am perfectionist ...
as you know ...

But right now I have the prob, that Summeroor, Ic and Ib in bathroom is 
= 0 (I dont know Ie). Instead of 24 I have 26° = just P part active .. I 
have no log and no idea so far ... maybe the gap is too big, as that it 
is closed during credit/expiretime

2. When do I have to reduce I_ERR_WEIGHT and when increase I_Factor ?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri:
a. if (absErr>=(lastTempChangeErrorAbs/2)) reverts too often ...

If just by chance the error is quite small we freeze wrong I part value 
"forever". E.g. in some of my rooms (e.g.bathroom) I have a floor 
heating as well. So it is not valve on its own who tries its best, doors 
to other rooms sometimes stay open the whole day,...). In R351 valve 
reverted quite often and ended up beeing controlled by P part close to 
center. Bathrooom has 26 instead of 24 this way. So this "one time small 
error" might be quite wrong, because it was produced by external 
influences !!

Generell revert aim is to prevent wrong summerror produced by external 
influences (shorten the time to correct I part). So aim is, to just 
revert if really necessary ...

Suggetsion: revert if:
(absErr>=lastTempChangeErrorAbs) && (absErr>=I_REVERT_TEMP_THRESHOLD) && 
(lastTempChangeSumError>=I_REVERT_ERR_TRESHOLD)

#define I_REVERT_TEMP_THRESHOLD 50  //unit 0,01°C, revert only if error 
is larger than e.g. 0,5°C. Dont go for small errors that by chance might 
have been produced by external influece and will be stored "forever" !

#define I_REVERT_ERR_THRESHOLD 0x1000 //revert only if sumerror has 
impact on valve move = do not revert on small values that have no impact 
on valve position. This way even wrong sumerrors will be corrected 
during the first periode, where external influence is gone.

b. expiration credit: do we relly need this ?
I understand, that aim is to stop valve during non heating periodes: If 
no temp change occures, I part should be frozen to stop valve from 
moving.
This is why I would like to set it to 24hours (no tempchange a whole 
day) =24x60/4=360 but max is 255 ;-)

c) please answer 2. from last post...

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
a) must be:
.. && .. && (abs(lastTempChangeSumError)>=I_REVERT_ERR_TRESHOLD)

Author: Jiri Dobry (jdobry)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Idea for "revert" is solve 2 situations:

Ex1: you want to heat more, but central heating is switched off. 
Integrator will move valve. And we need detect this situation: we are 
not able to heat up, valve position have no effect

Ex2: you need lower temperature, but temperature declines too slowly 
(open door, external heat source) Situation is same, any change on valve 
can't help. See too attachment

I both situation: any integrated change of valve is invalid, because it 
can't have any effect
------------------------
expiration - Lets this situation:
22degrre in room, wanted temperature is 18. It take many hours to pass 
20degrre and it leave valve_min position. Now valve slowly grow and 
follow temperature decline. Without expiration, integrator will decline 
valve without reason again to valve_min.

expiration in other words: If valve change have not effect in defined 
time (default 2 hours!!!) we can't believe that measured error depend to 
valve position. We must have impact from another source. Maximum 
expiration is (255*4/60) = 17 hours Do you believe that measured effect 
after 17 hours is caused by valve change?

------------------------

But you are right, condition (absErr>=(lastTempChangeErrorAbs/2)) can be 
too strong. I will change it.

(absErr>=I_REVERT_TEMP_THRESHOLD) <= bad idea, compare it mainly with 
Ex2, it will not work in this situation

(abs(lastTempChangeSumError)>=I_REVERT_ERR_TRESHOLD) <= tell me why? 
What is a goal?

------------------------

"When do I have to reduce I_ERR_WEIGHT and when increase I_Factor?"
A: Anytime, and see whats happen. Frankly spoken, I don't know ideal 
setting for this. It is too new, I have only limited data (only my 
valves, only short time).

------------------------
Ideal solution for enable/disable integrator update is put all magic 
like "credit" to trash and use "regression analysis" to determine rate 
of valve change to temperature. It is perfect clear solution. But we 
have limited resources in MCU. If you enable all options on code, free 
space in flash is less than 0.5kB (less than 250 assembler 
instructions!!) This is reason why I disable program/time settings by 
valve wheel on wireless case. Now I have 1432bytes free flash. It make 
it possible.
I will try create better mathematical model of valve (not just 
calc/excel sheet) and try press some "regression analysis" into code.
But I am sure that end of heating season will be faster.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
also today bathroom was reverted the whole day ....

idea a) and b) work togehter !

ad (abs(lastTempChangeSumError)>=I_REVERT_ERR_TRESHOLD) <= tell me why?

This way we just do a revert if the sumerror which we take for revert 
has an impact on valve (the effect should be >= 1% ...)

e.g. we have stored a lastTempChangeSumError=0x050 at a 
lastTempChangeErrorAbs=0,1°C. But those values were influenced by 
externel source.
R351 will revert all the time 0x050 because abserr will be > 
lastTempChangeErrorAbs=0,1°C most time. And when the ext. source is gone 
abserror will get larger all the time ... As I is small 0x050 it has no 
impact ... and I part is OFF "forever".

(abs(lastTempChangeSumError)>=I_REVERT_ERR_TRESHOLD) secures that we 
just revert sumerrors that have a real influence (e.g. >=1%) on valve.

And if this lastTempChangeSumError was wrong (because of ext. influence) 
it will lead to a larger error, which will not be reverted again because 
of my condition a) !!!!!!!

I think A&B together will work for both examples, because we revert on 
large errors.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
my explanation was not quite OK.
b) on its own secures: Only revert values (e.g >0x1000) that have real 
impact. So if stored values were wrong, the error will get worse and I 
part will start working

a) if stored values were wrong, one of the next periodes for sure will 
be able to reduce the error below 0,5°C(I_REVERT_TEMP_THRESHOLD) ... and 
reverting will stop

I gave a&b a try for tommorow in bathroom

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
ad b) when I say "I part eill start working" I mean this part !
          if (absErr >= last2AbsError) { 
CTL_interatorCredit-=(absErr/I_ERR_WEIGHT)+1; // max is 1200/20+1 = 61

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard
but you compare integrated value, not change from last temperature 
change. It can't work.
Or I understood wrong. Any chart ?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
no chart ... log will come tommorow ....

goal of a)
Do not revert on small errors, this way valve can get out of REVERTING 
by itself (it gets out of the trap if controller controls the error to < 
0,5°)
If we dont limit the error REVERTING will last "forever" (e.g. if 
lastTempChangeErrorAbs=0), because controller cant do any better. But if 
the sumerror stored is wrong controller is in the trap!!)

b) only revert if I part has influence on controller. small summerrors 
have no effect on valve position. Only P part works. Large values have 
real influece on position. So if wrong (large) summerror will be 
reverted, position will be worse then before (when the ext. source was 
active). This way I part "if (absErr >= last2AbsError)" will start 
working on this error and next time abserror will be <0,5 and reverting 
will stop....

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
(absErr>=lastTempChangeErrorAbs) && (absErr>=I_REVERT_TEMP_THRESHOLD) &&
(abs(lastTempChangeSumError)>=I_REVERT_ERR_TRESHOLD)

1. V starts with 43 (center= 58, Min=42) through P part
23.03.11 23:41:42 Ic is used up but V is 44 now:
So I_Factor should be increased to at least compensate the loss on P. We 
should have V<42 there.

Jiri we should increase I to 35

2. 24.03.11 04:03:03 Tempchange to 2300:
summerror stays as Vmin is reached. room is heated up by floor heating, 
...

no revert was necessary > no revert done > OK

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
another room: Vmin=52 Center=58 I set Vmin at 18:02:03 and Ifactor to 35 
around 17:38

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
bathroom during last night: Vmin=40, Center=58, I=35
heater stops heating about V=41
At the beginning valve was warmed up from my hands... I think I is still 
to low ?!

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard, why do you set Vmin too close? This result is not surprise, 
controller disable integration if valve is out of range and in your case 
it usual situation. Except this, valve calibration depends to battery 
status, and with this setting is easy to see valve on Vmin and heating 
warming.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri, I thought battery should not interfear, beacause we count pulses 
... ?
Actually I set Vmin = VheaterOFF - 4. This way I part cant "wind down". 
-4 was good enough so far to compensate the calibration tollerances 
which usally are not more than 2.
If you read the bathroom logs, be aware that bathromm has floor heating, 
hand towel hater (with normal valve, shuts down about 26°C) and the 
heater controlled by hr20. And if door is opened temp slowly goes down 
to 24. This room is perfect for testing the reverting prob I had with 
R351 ;-).

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Valve calibration depend to battery because maximum force depend too.
It is simple, motor controller try to keep same speed till slow down on 
"close end" (Ad3 state). Problem is that maximum force depend to battery 
state (maximum PWM is constant). I my valves valve range is ~600pulses 
end to end with fresh batteries and ~480pulses with end of live 
batteries.
(if you need exact position of valve, try to find "manual calibration" 
in this thread)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri,
- #define WATCH_N (10) should be (11) (values 0..0a)

- why dont we start autocalibration with searching CLOSE first. This way 
one could manually set head to CLOSE, mount valve, valve checks that it 
cant go any further and store this manually set CLOSE, then valve goes 
to OPEN. This way we could reproduce the CLOSE position in automatic as 
well .. ?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
- why dont we store the positions found during automatic calib in eeprom 
?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
- e.g. by setting MOTOR_ManuCalibration |= 0x8000
0 ... no calib, >0 ... auto, <0 ... manu

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
WATCH_N you are right, fixed

Calibration starts to "OPEN" direction by few reasons:
- when valve is on "CLOSE" side, force to start closing depend to valve 
position. I will create calibration depend to position on start 
salibration.
- when valve is "CLOSE" side, it can be on position, where motor have 
not force to reach. In another word, manually you can brace stronger 
than motor.

Where is benefit if you store automatic calibration in EEPROM? If you 
remove had from valve you must calibrate it anyway.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
THX for explanation regarding calib start direction

Benefit - what I am looking for:
a) one would like to see, wether position ater valve install is about 
the same like last time. So we can be sure everything is fine.

b) right now I always look at MOTOR_PosMax to see wether the number of 
pulses are about the same (the gap so far always was < 10 pulses, this 
is about 2% from 0x200 to 0x2d0 pulses on my valves.

c) one thing could be to set calibration data manually

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Jiri,
1 I think we should give integrator credit when valve starts moving 
because of p part e.g.:
D: d7 27.03.11 00:13:57 M V: 41 I: 2520 S: 2450 B: 2491 Is: ffffc900 Ib: 
00 Ic: fd Ie: e2
D: d7 27.03.11 00:17:57 M V: 41 I: 2520 S: 2450 B: 2489 Is: ffffc900 Ib: 
00 Ic: fd Ie: e1
D: d7 27.03.11 00:21:57 M V: 41 I: 2520 S: 2450 B: 2488 Is: ffffc900 Ib: 
00 Ic: fd Ie: e0
D: d7 27.03.11 00:25:57 M V: 42 I: 2516 S: 2450 B: 2490 Is: ffffc900 Ib: 
00 Ic: fd Ie: df
D: d7 27.03.11 00:29:57 M V: 42 I: 2514 S: 2450 B: 2490 Is: ffffc900 Ib: 
00 Ic: fd Ie: de
D: d7 27.03.11 00:33:57 M V: 42 I: 2514 S: 2450 B: 2492 Is: ffffc900 Ib: 
00 Ic: fd Ie: dd
D: d7 27.03.11 00:37:57 M V: 42 I: 2514 S: 2450 B: 2488 Is: ffffc900 Ib: 
00 Ic: fd Ie: dc

controller.c 399:
  if ((lastCTL_interatorCredit<=0) && (pi_term16!=(uint8_t)processValue)) {  //give credit if p part moves valve
                CTL_interatorCredit=config.I_max_credit; 
                CTL_creditExpiration=config.I_credit_expiration;
  }            
  return (uint8_t)pi_term16;
    last2AbsError = lastAbsError;
    lastAbsError = absErr;
    lastErrorSign = (uint8_t)(error16>>8)&0x80;
    lastCTL_interatorCredit = CTL_interatorCredit;

2. REVERT http://embdev.net/topic/118781?goto=2120075#2116213
(absErr>=lastTempChangeErrorAbs) && (absErr>=I_REVERT_TEMP_THRESHOLD) &&
(abs(lastTempChangeSumError)>=I_REVERT_ERR_TRESHOLD)

works OK. see log D: d6 26.03.11 21:34:12

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
ad1) integrator_block was missing:
  if ((lastCTL_interatorCredit<=0) && (pi_term16!=(uint8_t)processValue)) {  //give credit if p part moves valve
                CTL_interatorCredit=config.I_max_credit; 
                CTL_creditExpiration=config.I_credit_expiration;
                CTL_integratorBlock=DEFINE_INTEGRATOR_BLOCK;       //block to wait for p part impact
  }            
  return (uint8_t)pi_term16;

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
ad1)
   if ((lastCTL_interatorCredit<=0) && ((uint8_t)pi_term16!=(uint8_t)processValue)) {  //give credit if p part moves valve
                CTL_interatorCredit=config.I_max_credit; 
                CTL_creditExpiration=config.I_credit_expiration;
                CTL_integratorBlock=DEFINE_INTEGRATOR_BLOCK;       //block to wait for p part impact
  }            
  lastCTL_interatorCredit = CTL_interatorCredit;
  return (uint8_t)pi_term16;

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
I think its even better to block integrator after any change of valve 
position caused by p part
  if ((lastCTL_interatorCredit==CTL_interatorCredit) && (uint8_t)pi_term16!=(uint8_t)processValue) {  
    CTL_integratorBlock=DEFINE_INTEGRATOR_BLOCK;       //block Integrator if only p moves valve
    if (lastCTL_interatorCredit<=0) {  // if credit is expired
      CTL_interatorCredit = config.I_max_credit; //give new credit if p part moves valve
      CTL_creditExpiration = config.I_credit_expiration;
    }
  }            
  lastCTL_interatorCredit = CTL_interatorCredit;
  return (uint8_t)pi_term16;
a better position to implement blocking after P change could be line 
175, but then we need something like lastSumError ...

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
I took wrong variable: instead of process_value we have to use 
old_result of course ...
   if ((lastCTL_interatorCredit==CTL_interatorCredit) && (uint8_t)pi_term16!=old_result) {  
    CTL_integratorBlock=DEFINE_INTEGRATOR_BLOCK;       //block Integrator if only p moves valve
    if (lastCTL_interatorCredit<=0) {  // if credit is expired
      CTL_interatorCredit = config.I_max_credit; //give new credit if p part moves valve
      CTL_creditExpiration = config.I_credit_expiration;
    }
  }            
  lastCTL_interatorCredit = CTL_interatorCredit;
  return (uint8_t)pi_term16;

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
controller.c 312 uint8_t v0 = valveHistory[0];
why dont we use old_result here ?

my changes did well over the night ...also revert ... see LAST PART of 
log: Vmin=36
PS: I set blocking to 3 to get faster results during testing phase. 
credit_expiration=FF

PPS: Maybe we could give credit on each P Move instead of just if credit 
is expired ...

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
log from normal room (16m²) Vmin=52/54

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri, did you or others ever think about or try replacing the thick 
wires of the temp sensor by very thin ones to get faster temp respons 
???

BTW: I am blocking integrator now after any move of valve

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
did someone ever try to move in smaller steps - is it possible to count 
and stop 0,5% ?

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
hu hu ... any anwsers to my last posts would be very welcome ...

the attached jpg shows R354, reverting deactivated and integrator 
blocked after any move of valve... as one could see in small rooms 
(16m²) with outside temps >10°C our actual 1% valve step is too big for 
me...

Heating was deactivatetd in the afternoon, because of sun ..

blocking I: controller.c 396
  
  } 
  if ((uint8_t)pi_term16!=old_result) {  
    CTL_integratorBlock=DEFINE_INTEGRATOR_BLOCK;       //block Integrator on any valve move
  }            
  return (uint8_t)pi_term16;

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
1. did you or others ever think about or try replacing the thick
wires of the temp sensor by very thin ones to get faster temp response
???

2. did someone ever try to move valve in smaller steps - is it possible 
to count
and stop 0,5% ?
2a what do I have to change  to try it ?

3. in the morning I want to boost temp 1-2° as fast as possible. The 
actual controller is way to slow to get the childs room warm in the 
morning. We need something like:
if the new wanted temp differs by more than e.g. 1°C from the actual 
setpoint we have to open/or close the valve with another algorithm and 
hand over to the actual controller one some time or if temp is within 
0,3°C to the new temp wanted ...

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
1. Why? You don't need faster response. Frankly spoken, compare to 
heating response it is fast enough.

2. motor.c function MOTOR_Goto replace 100->200. But you need check all 
valve calculation, because after this same values can be overloaded. You 
must also update LCD and COM functions for correct reports.

3. It if exactly reason for P3_Factor. It is "boost" for big temperature 
difference.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard G, about "blocking I: controller.c 396":
It is interesting idea, I will test it too.

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
1. As heater heats up valve. the temp sensor is heated up via its wires. 
With thin wires, see chart 06:30 
hr20_1354_110401a_thin_wire_blocking_I.jpg the impact on sensor is less. 
Sensor is still heated up, but just by air. This way we are closer to 
real room temp. Newer valves from other manufacturers have smd sensors 
with 0,2mm lines...

3. I implemented a boost function...quite preliminary still... just 
using max and min positions of valve. This is the fastest way to heat up 
or cool down... in the next step I will calculate boost_time depending 
on error.. see chart 6:10 hr20_2354_110402a_thin_wire_boost.jpg

Description:
if setpoint is changed and gap is larger than setpoint_diff (50=0,5°) 
and actual error is large enough (boost_error 30=0,3°) we start boost 
funtion. boost sets valve to max or min position depending on error. 
boost lasts for boost_time in minutes (15). boost ends earlier if actual 
error is less than boost_error - boost_hystereses (30-10=0,2°). During 
boost PID controller only calculates errors (no PID values) and 
integrator is blocked.

eeprom.h
  /*    */  {50,           0,        0,      255},   //!< temp_boost_setpoint_diff, unit 0,01°C
  /*    */  {10,           0,        0,      255},   //!< temp_boost_hystereses, unit 0,01°C 
  /*    */  {30,           0,        0,      255},   //!< temp_boost_error, unit 0,01°C
  /*    */  {15,           0,        0,      255},   //!< temp_boost_time, minutes


controller.c 150
    if ( minute_ch && (PID_boost_timeout>0)) {  //timeout in minutes (15)
    PID_boost_timeout--;
      if (PID_boost_timeout==0) {
      PID_force_update = 0;
      }
    }
        if (updateNow) {
//jr needed in PID update, so set it later      CTL_temp_wanted_last=temp;
      goto UPDATE_NOW; // optimize
        valveHistory[0]=new_valve;
      }
      CTL_temp_wanted_last=temp;  //jr was after line "if (updateNow) {" before
        }
       COM_print_debug(0);


controller.c ~310:
    if (updateNow) {
      CTL_interatorCredit=config.I_max_credit;
      CTL_creditExpiration=config.I_credit_expiration;
      CTL_integratorBlock=DEFINE_INTEGRATOR_BLOCK; // do not allow 
update integrator immediately after temp change
      testIntegratorRevert(lastAbsError);
      lastTempChangeErrorAbs = absErr;
      lastTempChangeSumError = sumError;
      if ((PID_boost_timeout==0) && (abs(setPoint-CTL_temp_wanted_last)>=config.temp_boost_setpoint_diff) // change of wanted temp large enough to start boost (0,5°C)
        && (absErr>=(int16_t)config.temp_boost_error)) {  // error large enough to start boost (0,3°C)
        PID_boost_timeout = config.temp_boost_time; // temp_boost_time in minutes
      }
    } else {

controller.c ~360:
  }
  lastProcessValue = processValue;
  if ((PID_boost_timeout > 0) && //choose position of code, because parameters like error are calculated above
    (abs(error16)<=(int16_t)(config.temp_boost_error-config.temp_boost_hystereses))) {  // error <= temp_boost_error-temp_boost_hystereses
    PID_boost_timeout=0; // end boost earlier, if error got to small (0,2°)
  }
  if (PID_boost_timeout > 0) {  // boost active
  CTL_integratorBlock=DEFINE_INTEGRATOR_BLOCK;       //block Integrator
    if (error16>0) {
      return config.valve_max;   //boost to max, no PID calculation
    } else {
      return config.valve_min;   //boost to min, no PID calculation
  }
  }

  if (config.I_Factor > 0) {

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
@Chris any new ideas about bat ADCprob ?? I am having it again ...

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
looks like adc meaeures x01bb all the time. But after reset (just by 
programming fuses) the same value is interpreted differently:
batAD x01bb
batAD x01bb
D: d5 01.01.10 12:00:22 A V: 30 I: 2274 S: 1700 B: 2542 Is: 00000000 Ib: 06 Ic: 28 bo: ff E
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
D V:OpenHR20 (3*16+3).( 5*16+4) Apr  3 2011 12:33:06 101
V:OpenHR20 (3*16+3).( 5*16+4) Apr  3 2011 12:33:06 101
V:OpenHR20 (3*16+3).( 5*16+4) Apr  3 2011 12:33:06 101
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD x01bb
batAD xbat
batAD x01bb
D
batAD x01bb
batAD x01bb
batAD x01bb
D: d5 01.01.10 12:00:21 A V: 80 I: 0000 S: 1700 B: 0000 Is: 00000000 Ib: 06 Ic: 28 bo: ff X
batAD x01bb
batAD x01bb
batAD x01bb
D
batAD x01bb
D: d5 01.01.10 12:00:25 A V: 80 I: 2267 S: 1700 B: 3728 Is: 00000000 Ib: 06 Ic: 28 bo: ff E:04 X
batAD x01bb

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
@Jiri: still dont look through the ring buffer secrets ... but is it 
possible that this
static void shift_ring(void) {
#if ! HW_WINDOW_DETECTION
  ring_pos = (ring_pos+1) % AVERAGE_LEN;

should look like that ????
static void shift_ring(void) {
  ring_pos = (ring_pos+1) % AVERAGE_LEN;
#if ! HW_WINDOW_DETECTION

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
deleted

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
average is definitely miscalculated: istead of 9b6 we get ee4
AV is calculated average, followed by the 15 values aof ring buffer

AV0ee4

009b6
109b6
209b6
309bc
409b6
509b6
609b6
709b6
809b6
909b6
A09b6
B09b6
C09b6
D09b6
E09b6

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Should this:
static void update_ring(uint8_t type, int16_t value) {
  ring_sum[type]+=value;

better look like that:
static void update_ring(uint8_t type, int16_t value) {
  ring_sum[type]+=(int32_t)value;

It looks like sum is calculated wrong.. SUm is e910  this is 18 * 09b6
SUe910
AV0f89
009b6
109b6
209b6
309b6
409b6
509b6
609b6
709b6
809b6
909b6
A09b6
B09b6
C09b6
D09b6
E09b6

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
OK so the bugs are = corrected bugs look like:
a) static uint8_t ring_used=0;

b)
static void shift_ring(void) {
  ring_pos = (ring_pos+1) % AVERAGE_LEN;
#if ! HW_WINDOW_DETECTION


c)
  ring_sum[type]+=(int32_t)value;
  ring_sum[type]-=(int32_t)ring_buf[type][ring_pos];
  if (ring_used>=AVERAGE_LEN) {


The main reason is that update_ring is called more often than shif_ring 
during the phase were ring_used is less than average_len

d) Another question:
switch (++state_ADC) means präfix ++

is this OK then for noise protection:
 state_ADC=3;
 state_ADC=5;

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
my preliminary adc.c - see attachement

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
in attachement find next step preliminary boost function with time 
calculation.
description http://embdev.net/topic/118781?goto=2130451#2129904

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
I found, where was battery measurement problem. Normally it call 
update_ring twice (one for battery, one for temperature). And shift_ring 
only once after measure finish. But noise cancellation loop can cause, 
that measurement repeats many time and next second pulse come earlier. 
It restart measures. It repeat update_ring without shift_ring and this 
situation with (ring_used<AVERAGE_LEN) create this problem.
Fixed in rev 355, change is here: 
http://openhr20.svn.sourceforge.net/viewvc/openhr2...

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Option BLOCK_INTEGRATOR_AFTER_VALVE_CHANGE added 
http://openhr20.svn.sourceforge.net/viewvc/openhr2...

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Option BOOST_CONTROLER_AFTER_CHANGE added.
Richard, please check it (contain one small difference to your code)

http://openhr20.svn.sourceforge.net/viewvc/openhr2...

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri, THX
d) Another question:
switch (++state_ADC) ..... ++ here means increment before operation !!
is this OK then for noise protection:
 state_ADC=3;
 state_ADC=5;

I will check the new code tommorow ...

BTW: After 10-15 hours I had this error today .. what is the typical 
reason for ir ?
    if (motor_timer>0) { // normal stop on wanted position 
            if (MOTOR_calibration_step != 0) {
                MOTOR_calibration_step = -1;     // calibration error
                CTL_error |=  CTL_ERR_MOTOR;
                CTL_error_jr =  1; //jr CTL_ERR_MOTOR;

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
(++state_ADC) is correct, next call not execute step 3(5) but 4(6)

Reason for your error is overload maximum volume of pulses during 
calibration. (see to MOTOR_MAX_IMPULSES)

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Battery voltage error fix was not complete. Updated.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
"Reason for your error is overload maximum volume of pulses during
calibration. (see to MOTOR_MAX_IMPULSES)"

Can it be another reason, because there was no clalib sceduled after 
valve was installed ????
- Maybe it started calib for another reason (not saturday 10:00) - why 
would it do that ???
- It might have something to do with the boostfunction. It moves valve 
to MAX and later back to MIN ????

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
R359 THX Jiri:
1.adc I dont understand the -1, because we want to fill all 15 
positions(0-14) before we calc average. ring_used runs as ring_pos from 
0 to 15 !!!
With -1 we start calculating after 14 (pos=0-13) entries. So pos[14] is 
still=0. This way the first calculated average will be wrong ???
if (ring_used>=AVERAGE_LEN-1) { // note for "-1", last measurement can 
update ring_average

2.controller line 171 has to be moved after line 200, because 
boostdedection needs temp_wanted last see line ~334
        valveHistory[0]=new_valve;
line 200      }
      CTL_temp_wanted_last=temp;  //jr was after line "if (updateNow) {" before
        }
       COM_print_debug(0);

3. See last post. I still dont understand where my E3 can come from. As 
I marked the different E3 errors with E31-E34, it must be the one I 
posted... Why should it calibrate ? why should this gi wrong then ? Low 
Voltage on a long valve move ???

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
1. It is simple. In this case, we have 15 complete measurement. In table 
(0-14), ring_pos=ring_used=14. But ring_used will be incremented later. 
It is reason to compare with 14, not 15.

2. Changed in Rev 360

3. calibration is not start after set position to min or max. I start 
after valve mount  reboot  every Sat 10:00 Never else. And see to 
condition for this error (MOTOR_calibration_step != 0) it means 
calibration on progress or calibration error before this.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
New idea for reverting:
Build a moving average of sumerror from max. n(should last for a week or 
so...e.g. 255) values. Only use an sumerror for average, if error is 
small (<0,3) and stable.
Average is built only after update (typ. 1-4x per day). I need your help 
on a simple idea to handle it like the temp_ring_average !!

    if (updateNow) {
      CTL_interatorCredit=config.I_max_credit;
      CTL_creditExpiration=config.I_credit_expiration;
      CTL_integratorBlock=DEFINE_INTEGRATOR_BLOCK; // do not allow 
update integrator immediately after temp change
      testIntegratorRevert(lastAbsError);
      if ((absErr==lastAbsError) && (absErr<(I_ERR_TOLLERANCE_AROUND_0<<1)) //stable error & error < 0,3°C)
        && (average_sumerr_count<=255) ) {
      average_sumerr_count++;
      lastTempChangeSumError += (sumError-lastTempChangeSumError)/average_sumerr_count; //average of sumerrors
      }
      lastTempChangeErrorAbs = absErr;


Revert only is done, if the error could not be reduced by 25% and the 
error is larger than 3.g. 0,3°C
static void testIntegratorRevert(uint16_t absErr) {
  if (absErr>=(lastTempChangeErrorAbs>>2*3) && absErr > (I_ERR_TOLLERANCE_AROUND_0<<1)) {
  // if error could not be reduced to 3/4 and Error is larger than 0,3°C
  // if (absErr>=(lastTempChangeErrorAbs/2)) {
    // revert Integrator to previous state if current error is not smaller than 1/2  of original
    sumError=lastTempChangeSumError;
  }
  lastTempChangeErrorAbs = 0xffff; // function can be called more time but only first is valid
}

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Richard:
first - we don't have space for average buffer (used 685 bytes (66.9% 
Full) but without unknown stack size on top)

second - something like "stable" error not exist. See here to real data 
http://embdev.net/attachment/102842/1.png

third - exist only one correct way. This mean make model function and 
use regression analysis to find unknown parameters on real time.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
testIntegratorRevert is updated

note: price of this change is 80bytes in flash (0.5% of size)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
OK,
1. of course I am looking forward to your math model !!
I know that there is no real stable error....
Actually  the posted version works without ringbuffer anyway (less 
code). But I have to think about a better moving of the average... right 
now moving stops after 255 values...


2. in line 308 it was (I_ERR_TOLLERANCE_AROUND_0<<1). This way it only 
revert on errors >= 0,3°C ...


3. Jiri why did you solve that with so many #if #else ?? is it less code 
? Because this simple change based on 359 was easier to undestand (for 
me;-) ...
        if (updateNow) {
//jr needed in PID update, so set it later      CTL_temp_wanted_last=temp;
      goto UPDATE_NOW; // optimize
    }
        if ((PID_update_timeout == 0)) {
      UPDATE_NOW:
            PID_update_timeout = (config.PID_interval * 5); // new PID pooling
      uint8_t new_valve;
                new_valve = config.valve_max;
            } else {
                new_valve = pid_Controller(calc_temp(temp),temp_average,valveHistory[0],updateNow);
            }
      {  
        int8_t i;
        #if BLOCK_INTEGRATOR_AFTER_VALVE_CHANGE
          if (valveHistory[0]!=new_valve) {  
            CTL_integratorBlock=DEFINE_INTEGRATOR_BLOCK;       //block Integrator if valve moves
          }
        #endif

        for(i=VALVE_HISTORY_LEN-1; i>0; i--) {
          if (updateNow || (new_valve <= config.valve_max) || (new_valve >= config.valve_min)) {
            // condition inside loop is stupid, but produce shorter code
            valveHistory[i]=new_valve;
          } else  {
            valveHistory[i]=valveHistory[i-1];
          }
        }
        valveHistory[0]=new_valve;
      }
      CTL_temp_wanted_last=temp;  //jr was after line "if (updateNow) {" before

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
2. ???? Where is problem ?

3. I know that it is little bit complicated. But try it and you will see 
difference in code size. This code is significantly smaller for 
BLOCK_INTEGRATOR_AFTER_VALVE_CHANGE = 0

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
ad2) I_ERR_TOLLERANCE_AROUND_0
<<1
 missing

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
<<1 why?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
"<<1" opps, I see, fixed

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
a) I am curious why you used *2: Does <<1 not work with constants ?
another C thing:
b) When do we declare variables "static" in HR20
c) is an "extern" declared variable automatically "static" ? example is 
"lastTempChangeSumError" is static, but as I wanted it beeing sent over 
COM I had to declare it extern ...

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
deleted

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
a) *2 is better for reading. Because is is constant, it is not need 
optimize it for execution.

b) "static" is for local only variables and function. "static" function 
have one more benefit, it can be linked into call point and it is nice 
for compiler optimization.

c) if you need use variable or function outside "C" file it can't be 
static.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
THX:
     #if ! BOOST_CONTROLER_AFTER_CHANGE
      if (updateNow) {
172 CTL_temp_wanted_last=temp;
     ...
    #else
      if (updateNow||(PID_update_timeout == 0)) {
    #endif
            PID_update_timeout = (config.PID_interval * 5);
            uint8_t new_valve;
            if (temp>TEMP_MAX) {
                new_valve = config.valve_max;
            } else {
                new_valve = 
pid_Controller(calc_temp(temp),temp_average,valveHistory[0],updateNow);
            }
187 #if BOOST_CONTROLER_AFTER_CHANGE
188 if (updateNow) {
189  CTL_temp_wanted_last=temp;
        }
     #endif

Jiri,
a) I think line 172 (CTL_temp_wanted_last=temp;) can be at the end 
=line189 in both cases... (I checked that already)

b) so we can also forget the #if from 187

c) and the if in 188 is not needed. It does not matter if 
CTL_temp_wanted_last is set under any condition more often...

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
OK I clean up this code.
note: price of moving "CTL_temp_wanted_last=temp;" line is 8 bytes. We 
has code bigger than flash already. Current code uses MANY hack to 
optimization.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri you can also keep it, your decision, I can live with it,

Then just delete the if from line 188...

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
THX Jiri

R362:
Program:   13398 bytes (81.8% Full)
Data:        485 bytes (47.4% Full)
EEPROM:      392 bytes (76.6% Full)

R363:
Program:   13392 bytes (81.7% Full)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri, I had this E31 error again - please comment on this

When I mounted the valve it was nearly fully open (12 pulses) .. when 
the error came up it was fully closed (i nearly could not move it any 
further by hand)
Values when E31 came up:
MOTOR_PosMax=12
MOTOR_PosAct=fde9
MOTOR_PosOvershoot=1
MOTOR_counter=23b

The next time calib was OK:
MOTOR_PosMax=2c6

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
R363 with RFM and normal "wheel" settings
Program:   16022 bytes (97.8% Full)
Data:        690 bytes (67.4% Full)
EEPROM:      400 bytes (78.1% Full)

but with CTL_temp_wanted_last=temp; like previous versions
Program:   16014 bytes (97.7% Full)

16022 means 362bytes free and it is less than 181 AVR machine 
instructions.
Not nice.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
I think we could save some bytes, because with I_ERR_TOLLERANCE_AROUND_0 
we have covered this good enough ...
if ((error16 >= 0) ? (old_result < config.valve_max) : (old_result > 
config.valve_min)) {
        if (  // ((lastErrorSign != ((uint8_t)(error16>>8)&0x80)))
||  //sign of last error16 != sign of current
        ((absErr==lastAbsError) && (absErr<=I_ERR_TOLLERANCE_AROUND_0))) 
{  //abserror around 0

and please set the error variables to an invalid value and they have to 
be different

please comment on my E31 from above

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
the post timed out...  and please set the error variables to an invalid 
value and they have to be different:
static uint16_t lastAbsError = 0xFF;  //set invalid
static uint16_t last2AbsError= 0xFE;  //set invalid and different to 
lastAbsError

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
E31 means here ?
   if (motor_timer>0) { // normal stop on wanted position 
            if (MOTOR_calibration_step != 0) {
                MOTOR_calibration_step = -1;     // calibration error
                CTL_error |=  CTL_ERR_MOTOR;
            }
 

Strange. MOTOR_PosMax-MOTOR_PosAct = 552[dec]
But mininum posion for this error is  (MOTOR_PosMax-MOTOR_MAX_IMPULSES) 
= -982 = 0xFC2A And this position was not reach.

Motor stops in 2 conditions:
- reach to final positon (not happen)
- motor slow down or stop mechanicaly, but in this condition is 
motor_timer==0

This mean, that it can't be this error, or we have some bug in code.
what was in motor_diag (trace variable 0x05)

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
if (motor_timer>0) { // normal stop on wanted position
            if (MOTOR_calibration_step != 0) {
                MOTOR_calibration_step = -1;     // calibration error
                CTL_error |=  CTL_ERR_MOTOR;
                CTL_error_jr =  1; //jr CTL_ERR_MOTOR;
menu.c ...E35 is spare
                } else if (CTL_error & CTL_ERR_MOTOR) {
                    if      (CTL_error_jr==1) { 
            LCD_PrintStringID(LCD_STRING_E31,LCD_MODE_ON); 
           } else if (CTL_error_jr==2) { 
             LCD_PrintStringID(LCD_STRING_E32,LCD_MODE_ON); 
           } else if (CTL_error_jr==3) { 
             LCD_PrintStringID(LCD_STRING_E33,LCD_MODE_ON); 
           } else if (CTL_error_jr==4) { 
             LCD_PrintStringID(LCD_STRING_E34,LCD_MODE_ON); 
           } else if (CTL_error_jr==5) { 
             LCD_PrintStringID(LCD_STRING_E35,LCD_MODE_ON);
           } 
                } else if (CTL_error & CTL_ERR_BATT_WARNING) {
LCD.c... in any language
      {32,14, 3, 1},    //!<  " E31"    LCD_STRING_E31
      {32,14, 3, 2},    //!<  " E32"    LCD_STRING_E32
      {32,14, 3, 3},    //!<  " E33"    LCD_STRING_E33
      {32,14, 3, 4},    //!<  " E34"    LCD_STRING_E34
      {32,14, 3, 5},    //!<  " E35"    LCD_STRING_E35
      {32,14, 4,32},    //!<  " E4 "    LCD_STRING_E4

it is this code position for sure 99,99% ... I used the motor diag watch 
for something else ;-)

it seems like it happens only after I flashed a new programm and had the 
batteries out ... can this be a trace ??

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
I just tried to dismount, batteries out/in, remount 5 times ... no error

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
when calib goes OK. motor_diag on this valve runs typ at 5c0 and at the 
close position it is 784

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
OK. But what is E31?

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
I have 4 different error messsages for the 4 different code lines of E3 
(E31-E34  see last posts)

E31:
if (motor_timer>0) { // normal stop on wanted position
            if (MOTOR_calibration_step != 0) {
                MOTOR_calibration_step = -1;     // calibration error
                CTL_error |=  CTL_ERR_MOTOR;
                CTL_error_jr =  1; //jr CTL_ERR_MOTOR E3(1)
...menu.c
                } else if (CTL_error & CTL_ERR_MOTOR) {
                    if      (CTL_error_jr==1) {
            LCD_PrintStringID(LCD_STRING_E31,LCD_MODE_ON);

Any idea how I can reproduce the prob. ??

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
see to my post from 2011-04-08 16:51

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
1. I think we could save some bytes, because with 
I_ERR_TOLLERANCE_AROUND_0
we have covered the sign change as well ... delete highlighted line
if ((error16 >= 0) ? (old_result < config.valve_max) : (old_result >
config.valve_min)) {
  if (
 // ((lastErrorSign != ((uint8_t)(error16>>8)&0x80))) ||  
         //sign of   last error16 != sign of current
     ((absErr==lastAbsError) && (absErr<=I_ERR_TOLLERANCE_AROUND_0))) { 
//abserror around 0

2. please initialize the error variables with an invalid
value and they have to be different:
static uint16_t lastAbsError = 0xFF;  //set invalid
static uint16_t last2AbsError= 0xFE;  //set invalid and different to
lastAbsError

3. I use a moving average for reverting ... this way the problem of 
short periodes (some days, depending on I_SUMERR_CHANGE_WEIGHT ) with no 
heating looks quite well ...

    if (updateNow) {
      CTL_interatorCredit=config.I_max_credit;
      CTL_creditExpiration=config.I_credit_expiration;
      CTL_integratorBlock=DEFINE_INTEGRATOR_BLOCK; // do not allow 
update integrator immediately after temp change
      testIntegratorRevert(lastAbsError);
      if ((lastAbsError==last2AbsError) && 
(lastAbsError<(I_ERR_TOLLERANCE_AROUND_0*2))) {//stable error & error < 
0,3°C)
      lastTempChangeSumError += (sumError-lastTempChangeSumError)/I_SUMERR_CHANGE_WEIGHT; 
      //imapct of SumErr changes on lastSummError, averaging for integrator revert
      }
      lastTempChangeErrorAbs = absErr;
      // lastTempChangeSumError = sumError;

#define I_SUMERR_CHANGE_WEIGHT 10  // impact on lastSumError which is 
used for reverting

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
1) I thing that it is not covered, this is reason : 
(absErr==last2AbsError). See here 
http://embdev.net/attachment/102842/1.png
Except this I thing that zero cross is better than something 
with(absErr==last2AbsError)

2) You are right, it is best practice. But because situation in flash 
space is critical, I will use it only if it really needed. I thing, that 
0 not make any problem.

3) Why? You don't need make any average from stable value. If this value 
is not almost stable, something is wrong. We need solve causation, not 
mask result.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
ad1) (absErr==last2AbsError) this prevents, that we give credit, if 
temperature rushes up/down = ext. influence. In your example I guess it 
was P part and not integrator moving the valve. So a fast change of sign 
should not be handled by I-part and a slow change is covered by 
"dedection around 0"... I live quite well for a while without the sign 
dedection, but loosened the restriction (absErr==last2AbsError) to 
(absErr==lastAbsError)...

ad2) well, directly after boot, temp is updated and comparisons like 
this go wrong then.. but I can live with that ... your decison...
if ((lastAbsError==last2AbsError) && 
(lastAbsError<(I_ERR_TOLLERANCE_AROUND_0*2))) {//stable error & error < 
0,3°C)
        // && (average_sumerr_count<255) ) {

ad3) Because right now - in times where heating is deactivated temporary 
by high outside temps during day or night ... the actual code
lastTempChangeSumError = sumError;

produces more wrong reactions (I-parts) than a continous averaging:
lastTempChangeSumError += 
(sumError-lastTempChangeSumError)/I_SUMERR_CHANGE_WEIGHT;  // weight 
e.g.=10

I thik this is a compromise (with liitle code) until we find a better 
(math) solution for revert

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
here is a quick status from my side which includes:
NO_AUTORETURN_FROM_ALT_MENUES=-DNO_AUTORETURN_FROM_ALT_MENUES=1
BLOCK_INTEGRATOR_AFTER_VALVE_CHANGE=-DBLOCK_INTEGRATOR_AFTER_VALVE_CHANG 
E=1
BOOST_CONTROLER_AFTER_CHANGE=-DBOOST_CONTROLER_AFTER_CHANGE=1
and a modified code for reverting (posted above, value Isl in the chart)
Valve MAX=80, MIN=CENTER=52, Credit_expiration=255

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
I changed MAX to 96 around 13:00, 80% did not open the valve wide 
enough. This way boost function works more effective.. room gets warmer 
about 0,7° within 1 hour ... during this valve reverted SumError=Is 
(vlack line) to lastSumError=Isl (moving average with 10% impact of 
SumError ... see black dotted line)
Heating was OFF from 22:00-4:30..

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
@Jiri:
I found some bugs in my code (BOOST) and deleted unnecessary EEprom 
variables ...
Could you please integrate the changes from OpenHR20_R363_mod110417.zip 
in a new revision ... THX

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Jiri:
I mailed the changes to you... as your mailbox seems to be full I add 
the .zip here ...

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Also my last MAil returned .. so I post the changes here: The files are 
zipped in my last post ;-)
com.c 309
 print_s_p(PSTR(" bo: ")); //jr
 print_hexXX(PID_boost_timeout);
 print_s_p(PSTR(" Iac ")); //jr
 print_hexXX(average_sumerr_count);
 print_s_p(PSTR(" Isl "));
 print_hexXXXX(lastTempChangeSumError>>16); //jr
 print_hexXXXX(lastTempChangeSumError); //jr

controller.c:
60:
#if BOOST_CONTROLER_AFTER_CHANGE
 uint8_t PID_boost_timeout;  //boost timout in minutes
 uint8_t PID_boost;  //boost value, either valve max or min
#endif

183: cosmetic:
      CTL_integratorBlock=CTL_INTEGRATOR_BLOCK;       //block Integrator if valve moves

 
248:
   PID_boost_timeout = 0; //to disable boost change mode, then change setpoint and change back mode

271:
static uint16_t lastAbsError = 0xFF;  //set invalid
static uint16_t last2AbsError= 0xFE;  //set invalid and different to lastAbsError

290:
static uint16_t lastTempChangeErrorAbs=0xffff;
int32_t lastTempChangeSumError=0;
uint8_t average_sumerr_count=0; // counting # of averages, just for diagnosis purposes

296: just comment:
  // if error could not be reduced to 3/4 and Error is larger than I_ERR_TOLLERANCE_AROUND_0*2 °C

320:
    CTL_integratorBlock=CTL_INTEGRATOR_BLOCK; // do not allow update integrator immediately after temp change
    testIntegratorRevert(lastAbsError);
    if ((lastAbsError==last2AbsError) && (lastAbsError<(I_ERR_TOLLERANCE_AROUND_0*2))) {//stable error & error < 0,3°C)
     average_sumerr_count++;  //just for diagnosis, how often do we average
   lastTempChangeSumError += (sumError-lastTempChangeSumError)/I_SUMERR_CHANGE_WEIGHT; 
   //imapct of SumErr changes on lastSummError, averaging for integrator revert
    }
    lastTempChangeErrorAbs = absErr;
    // lastTempChangeSumError = sumError;
    #if BOOST_CONTROLER_AFTER_CHANGE
       PID_boost_timeout = 0;
     if (absErr>=(int16_t)config.temp_boost_error) {  // error large enough to start boost (0,3°C)
    if (error16 >= 0) {
     PID_boost = config.valve_max;
     PID_boost_timeout = config.temp_boost_time_heat;
    } else {
     PID_boost = config.valve_min;
     PID_boost_timeout = config.temp_boost_time_cool;
    }
    PID_boost_timeout = (uint8_t)(MIN(255,abs(error16)/10*(int16_t)PID_boost_timeout/CTL_BOOST_TEMPCHANGE)); //boosttime=error/10(0,1°C)*time/CTL_BOOST_TEMPCHANGE(0,5°C)
     }       

340:
 this prevents, that we give credit, if temperature rushes up/down = ext. influence. In your posted example I guess it was P part and not integrator moving the valve. So a fast change of sign should not be handled by I-part and a slow change is covered by "dedection around 0"... I live quite well for a while without the sign
dedection
    if (  // ((lastErrorSign != ((uint8_t)(error16>>8)&0x80))) ||  //sign of last error16 != sign of current
    ((absErr==last2AbsError) && (absErr<=I_ERR_TOLLERANCE_AROUND_0))) {  //abserror around 0 with slow change
      CTL_interatorCredit=config.I_max_credit; 

370:
  #if BOOST_CONTROLER_AFTER_CHANGE
 if (PID_boost_timeout > 0) {
  CTL_integratorBlock=CTL_INTEGRATOR_BLOCK;       //block Integrator
  CTL_creditExpiration=config.I_credit_expiration;
  return PID_boost;  //return valve_MAX or MIN
 }
  #endif

 
 
eeprom.h:
~100:
#if BOOST_CONTROLER_AFTER_CHANGE
 /*    */ uint8_t  temp_boost_error;
 /*    */ uint8_t  temp_boost_time_cool;
 /*    */ uint8_t  temp_boost_time_heat;
#endif
 
~250:
#if BOOST_CONTROLER_AFTER_CHANGE
  /*    */  {30,          30,       10,      255},   //!< temp_boost_error,start boost if error to new setpoint is larger than this,unit0,01°C
  /*    */  {64,          64,        0,      255},   //!< temp_boost_time_cool, minutes boost should last during heat up, if error = CTL_BOOST_TEMP_CHANGE(0,5°C)
  /*    */  {48,          48,        0,      255},   //!< temp_boost_time_heat, minutes boost should last during cool down, if error = CTL_BOOST_TEMP_CHANGE(0,5°C)
#endif

controller.h 
~63:
#define CTL_INTEGRATOR_BLOCK 6    //jr was=6
#define I_ERR_TOLLERANCE_AROUND_0 15 // unit 0,01°C. Set it quite restrictive !
#define I_ERR_WEIGHT 25 //impact of error on I part
#define I_SUMERR_CHANGE_WEIGHT 10 //imapct of SumErr changes on lastSummError, averaging for integrator revert
#define CTL_BOOST_TEMPCHANGE 5 //unit 0,1°C, estimated change of temp during boosttime, for calculating boost time

80:
extern uint8_t PID_boost_timeout;
extern uint8_t CTL_creditExpiration;
extern int32_t lastTempChangeSumError;
extern uint8_t average_sumerr_count;

motor.c: 111
        CTL_integratorBlock=CTL_INTEGRATOR_BLOCK;

watch.c:
    /* 00 */ ((uint16_t) &sumError) + B16,
    /* 01 */ ((uint16_t) &CTL_integratorBlock) + B8,
    /* 02 */ ((uint16_t) &CTL_interatorCredit)+ B8,
    /* 03 */ ((uint16_t) &PID_boost_timeout)+ B8,
 /* 04 */ ((uint16_t) &average_sumerr_count) + B8,
    /* 05 */ ((uint16_t) &lastTempChangeSumError) + B16,
 /* 06 */ ((uint16_t) &MOTOR_PosMax) + B16,  //12  az:2c6 bad:22c 
 /* 07 */ ((uint16_t) &MOTOR_PosAct) + B16,  //fde9  az:18d bad:c4
 /* 08 */ ((uint16_t) &MOTOR_PosOvershoot) + B8, //1
#if DEBUG_MOTOR_COUNTER
 /* 09 */ ((uint16_t) &MOTOR_counter) + B16,  //23b
 /* 04 */ ((uint16_t) &motor_diag) + B16,
// /* 0a */ ((uint16_t) &MOTOR_counter)+ 2 + B16, //0
#endif

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Hi Jiri - are you still there ? - I would like to finish up, before the 
summer comes and I forget everything .... ;-)
RE: "Can you generate "diff" file? (for ex in TortoiseSVN)"
Sorry, no know how in those things ...
a) either you instruct me or
b) I could also edit the changes into R363 files and send you those ..

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I am still here. But I am too busy on another tasks till end of may.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Ok .. then we'll clean up end of May/June ... BR .. Richard

Author: transis (Guest)
Posted on:

Rate this post
0 useful
not useful
Need some help. I receive following error msg during compiling:

**** Build of configuration Debug for project HR20 ****

make all
Building file: ../src/lcd.c
Invoking: AVR Compiler
avr-gcc -Wall -g2 -gstabs -O0 -fpack-struct -fshort-enums -std=gnu99 
-funsigned-char -funsigned-bitfields -mmcu=atmega169p -DF_CPU=1000000UL 
-MMD -MP -MF"src/lcd.d" -MT"src/lcd.d" -c -o "src/lcd.o" "../src/lcd.c"
../src/lcd.c: In function 'LCD_HourBarBitmap':
../src/lcd.c:627: error: r28 cannot be used in asm here
../src/lcd.c:627: error: r29 cannot be used in asm here
make: *** [src/lcd.o] Error 1

**** Build Finished ****

lcd.c revison: 192
how can i fix this error(s)?

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
transis: Which compiler? Please try WinAVR-20100110.

Author: transis (Guest)
Posted on:

Rate this post
0 useful
not useful
it is already the compiler: WinAVR-20100110 !

Author: transis (Guest)
Posted on:

Rate this post
0 useful
not useful
I've also tried to compile it with AVR-Studio 5 => same compiler 
error(s):

Error 1 r28 cannot be used in asm here ...\lcd.c 627 1  OpenHR20
Error 2  r29 cannot be used in asm here ...\lcd.c 627 1  OpenHR20

Author: transis (Guest)
Posted on:

Rate this post
0 useful
not useful
Error:
   ../src/lcd.c:627: error: r28 cannot be used in asm here
   ../src/lcd.c:627: error: r29 cannot be used in asm here

Fix-Proposal:
   modify line in lcd.c
   from:
     : "r14", "r15", "r16", "r28","r29", "r30", "r31"
   to:
     : "r14", "r15", "r16", "r30", "r31"

after this modification the compilaton will pass.

What are the side-effects of this fix?
(I'm not so experienced with assembler coding ...)

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Problem is that this line not create any code. It just inform compiler 
optimizer about used registers. If you remove it, ASM code rewrite this 
registers and compiler will not know it. It will fail.
Are you sure that in compilation you use  WinAVR-20100110 ? It is tested 
with this without problem.

Author: transis (Guest)
Posted on:

Rate this post
0 useful
not useful
yes, i am sure. It is the compiler "WinAVR-20100110"! But this errors 
was also reported by AVR-Studio5. I think it is not a compiler specific 
problem.

Author: transis (Guest)
Posted on:

Rate this post
0 useful
not useful
Hello again,

I've tried to compile it with "release" setup, and it is 
compiling.(Before, it was in the "debug" setup => with this setup i got 
the above mentioned errors.)

are the compiling options wrong?
release-setup:
   avr-gcc -Wall -Os  ...
debug-setup:
   avr-gcc -Wall -g2 -gstabs -O0 ...

Author: transis (Guest)
Posted on:

Rate this post
0 useful
not useful
After some further testing....
The parameter/option "-O0" raise this errors. When i am select one of 
the other optimization levels "-O1..3" the errors are not occured.

Can someone explain me this crazy behavior?

Author: Marco G. (stan)
Posted on:

Rate this post
0 useful
not useful
Hi,
-O0 means no optimization, so it seems that without optimization these 
two registers are necessary for the C code and then the compiler 
complains.

Author: transis __ (Company: manmen) (transis)
Posted on:

Rate this post
0 useful
not useful
sounds plausible. ;-)

What will be the workaround/fix (is it a bug?)
Why this error was only reported/seen by me (i think the compilers with 
same options should report same errors...)?

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I any way, compile it for debug with -O0 have not solution. Simply 
before code will be too big for only 16kB flash.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
jdobry wrote:
> I am still here. But I am too busy on another tasks till end of may.

Hi Jiri, hope you have/had a good summer ... can we continue to 
integrate the changes from post http://embdev.net/topic/118781#2153401
BR Richard

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@ Richard G.:
I review this changes, and it is not possible use as is. It contain many 
other changes that only core. It is not encapsulated into ifdef. And I 
has not time to rewrite it.
Please send me it as "patch", or I must say sorry for this moment. I 
have some urgent concern to solve.

Jiri

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri, what you mean with patch ? example please

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi!

I flashed 7 rondostates with the firmware of 29.8.2011. It seems to me 
that the vent does not open, even if the room is too cold.
Example: Temperature is 18,7, wantet temperature is 20, Vent is about 
55-60%. (max vent position 96, min position 30).

Maybe I have to set min position to a higher value, because the vent 
closes at about 45%?

Chris

Author: Holger T. (holgert)
Posted on:

Rate this post
0 useful
not useful
Hi,
I plan to buy RFM12(x) modules to use with HR20E. What are the correct 
types to use?

Currently I prefer:
RFM12 for MASTER (because it is specified for 5V)
RFM12B for all (Rondostat-) slaves  (because it is specified for 3,3V).

What frequency should be used: 433MHz vs. 868MHz?

What types are supported by current existing SW? (I didn't find any 
switch in source code to choose B-Type or 433/868MHz)

Thank you for some useful suggestions.
-Holger

Author: Frank (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
I want use some HR20 as central control. Temperatures are measured 
externally. To to this i have extended the firmware:

1. Improved input operation in com.c

2. Serial Bus mode Ixx enables the communication with ID=xx all other 
devices are silent.

3. Override measured themperature via Oxxxx

4. Debug prints free RAM

With 2. i have an problem. Variable 0x27 holds the bus id but i cannot 
change this. 0x27 is allays set to 0xff

By the way:

5. i can communicate only with 1200 baud when i set COM_BAUD_RATE to 
1140 on higher speed i receive no correct characters.

6. the hr20 prints 22.6°C while an DS1820 messures 24.87°C

7. i have changed the boot loader to fastboot. With lboot i can flash 
with 115200 baud

Author: jdobry (Guest)
Posted on:

Rate this post
0 useful
not useful
@Holger T.: I use 868MHz modules. RFM12B is improved version of RFM12. I 
recomend new.

@Frank: Thanks for patch I will try it later.
add 5) see to http://atmel.com/dyn/resources/prod_documents/doc2555.pdf

add 6) HR20 use only cheap thermistor. But you can calibrate it in 
EEPROM

add 7) I don't use bootloader. Reason is some temporary problems with 
flash space and in this case, every byte is needed.

Author: Richard G. (gggggg)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Hi Jiri, as wanted here is the Tortoise SVN patch...
Only those chenges are relevant: 
http://embdev.net/topic/118781?page=4#2153401
Explanations start here http://embdev.net/topic/118781?page=4#2140184

Author: Frank (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
I have written an r/c clock calibration code. I uses no timers other 
than rtc and no interrupts. I thin this code is good enough to call it 
periodically to avoid communication problems while voltage or 
temperature is changing.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri, you remember I also had calibration errors last year.... again 
this year on different valve..
It is the error from the else part (my ident CTL_error_jr =  2)
                    if (MOTOR_ManuCalibration==0) {
                        if (a >= MOTOR_MIN_IMPULSES) {
                            MOTOR_ManuCalibration = a;
                            eeprom_config_save((uint16_t)(&config.MOTOR_ManuCalibration_L)-(uint16_t)(&config));
                            eeprom_config_save((uint16_t)(&config.MOTOR_ManuCalibration_H)-(uint16_t)(&config));
                            MOTOR_calibration_step = 0;
                        } else {
                            MOTOR_calibration_step = -1;     // calibration error
                            CTL_error |=  CTL_ERR_MOTOR;
                      CTL_error_jr =  2; //jr CTL_ERR_MOTOR;

MOTOR_PosMax 47, MOTOR_PosAct 47, MOTOR_PosOvershoot 2,
MOTOR_counter 5E6, motor_diag 779

How it happens:
1 I pressed a button and got E2 (valve not mounted, maybe I pressed to 
hard ;-)
2 I took valve off
3 I set the heater valve head manually near full open
4 put valve back on
5 valve starts adapting and stops with the error on full open position

I took it off again and repeated from 3. Same error again ...
Then I took battery out and repeated from 3. No more error !

Author: Chris (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi Jiri,

I too experienced a E3 error and could not find any reason for it, but 
it could be because I used empty batteries.

With current version, I have 2 main problems:

1: The window open function still triggers randomly, for example if the 
central heating goes out for a few minutes and there is a slight drop in 
temperature. I tried different eeprom settings to disable the window 
open detection, but it still triggers.

2: With default settings, valve is always around 50%. Our water 
temperature is only high enough to reach wanted temperatures, but only 
if vents are at about 90%. So I increased the value for valve-center.

Problem is that valve is opend or closed with a too flat curve. For 
example, when wanted temperature is 20 and real temperature is 21, valve 
only closes a little bit, which is not enough.
I think I have to change impact of P-Part of the controller?

Chris

Author: Bernard K. (bernard_k)
Posted on:

Rate this post
0 useful
not useful
Hi all,

I've been reading this, and the other German thread (through google 
translate), along with the documents referenced in those, but still have 
some questions.

I currently have one HR20 and one HomExpert HR20Style. As soon as I get 
everything working I will purchase 7 more HR20Style (since they're 
cheaper than the original HR20.)

My goal is to power and control the thermostats over wiring already 
present for this purpose.
What I need to do is to set the desired temperature, and read the actual 
temperature. Reading the valve state would be a plus.

I now have the HR20 hooked up (it's SW 204), and can read the 
information it sends me (fe.: "K: 0b1 [0x0D][0x0A]>")
I cannot successfully send it any commands, I always get the message 
"Error in command[0x0D][0x0A]>"
After a while any commands I send it are ignored. (I assume the device 
has gone to sleep.) I have not found a way to wake it up.
Apparently all this is because the information I'm using concerns the 
protocol of an earlier hardware version (with a NEC chip instead of the 
Atmel AVR mine has?)
I have not found a protocol specification for the SW 204 specifically.

Is it possible to control the SW 204 in the same way as the earlier 
edition? If so, could someone point me to the correct protocol 
specification?

If not, then I assume I will need to flash the HR20 with OpenHR20? I 
have a ICSP programmer, but as I understand it I cannot use this unless 
I actually open up the HR20 and solder some extra wires to it?
So I've ordered a cheap AVR JTAG ICE from ebay (I figure I'll be able to 
use it later for other purposes anyway, even if I don't need it after 
all.)

If I'm correct so far, these would be the steps required to flash the 
HR20?
* I will not be able to connect the JTAG connector directly to the HR20 
and will need to make some wires to connect the right pins to the JTAG 
connector.
* I will then use avrdude (I do not have any Windows) to upload the file 
hr20.bin to the HR20 using the AVR JTAG ICE.
* Afterwards, I can use the OpenHR20 protocol to accomplish my goal.

I've checked out the svn repo, and have also downloaded the v1.0 
zipfile.
I see no .bin files inside the svn repo.
Is the zipfile's original_sww/hr20.bin the file I need, or would you 
recommend (considering my goal) to compile one from the latest svn 
source instead?
If I need to compile a bin file, could you tell me how to do this? My C 
knowledge is very limited, so the correct avr-gcc (if that is the 
correct application?) command line would be very helpful.

All the thanks,
Bernard Kerckenaere

Author: Jiri Dobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Bernard K:
- serial protocol for original SW 204 is unknown.
- I don't known if HR20 style contain same HW as HR20. Please check it 
ane tell us results.
- You are right ICSP can't be used without open valve and soldering.
- connector on HR20 have't same layout like AVR JTAG, you will need 
special cable.
- I am not using Windows too. You need "avr-gcc" package. On actual 
source directory simple start "make". I recommend do it in "rfmsrc" 
directory and result hex files will be on "bin"
- Here is TESTED avrdude commands. You will probably need both in same 
order. Without first is impossible rewrite EEPROM.
avrdude -p m169 -c jtag1 -P /dev/ttyUSB0 -U hfuse:w:0x19:m
avrdude -p m169 -c jtag1 -P /dev/ttyUSB0 -e -U flash:w:hr20.hex -U eeprom:w:hr20.eep -U hfuse:w:0x11:m

Author: Jiri Dobry (Guest)
Posted on:

Rate this post
0 useful
not useful
update: for compile under linux you need "gcc-avr" and "avr-libc"

Author: Frank (Guest)
Posted on:
Attached files:

Rate this post
0 useful
not useful
@Jiri, @Bernard
I have flashd without soldering. All ISP pins are on the connector and 
under the tree keys. The display can be easy removed from battery side.

With fastboot 
http://www.mikrocontroller.net/articles/AVR_Bootlo... 
the new firmware can be flashd via serial cable.

This is my modified Makefile:
--- Makefile.orig    2011-09-29 10:50:21.000000000 +0200
+++ Makefile    2011-09-29 11:02:07.015224003 +0200
@@ -37,7 +37,7 @@
 # MCU = attiny85
 # MCU = atmega2560
 # MCU = atmega1281
-MCU = atmega8
+MCU = atmega169p
 
 # Name of the Atmel defs file for the actual MCU.
 #
@@ -50,16 +50,16 @@
 # files" and unzip it in the same directory as this Makefile.
 #
 # Examples (select one of them or add your own):
-# ATMEL_INC = m168def.inc
+ATMEL_INC = m169def.inc
 # ATMEL_INC=m64def.inc
 # ATMEL_INC=tn85def.inc
 # ATMEL_INC = m2560def.inc
 # ATMEL_INC = m1281def.inc
-ATMEL_INC = m8def.inc
+#ATMEL_INC = m8def.inc
 
 # Processor frequency.  The value is not critical:
 #F_CPU = 14745600
-F_CPU = 8000000
+F_CPU = 4000000
 
 #     AVR Studio 4.10 requires dwarf-2.
 #     gdb runs better with stabs
@@ -68,11 +68,11 @@
 
 # Define the Tx and Rx lines here.  Set both groups to the same for
 # one wire mode:
-STX_PORT = PORTD
-STX = PD1
+STX_PORT = PORTE
+STX = PE1
 
-SRX_PORT = PORTD
-SRX = PD0
+SRX_PORT = PORTE
+SRX = PE0
 
 ####### End user presets ######################

This is my avrdude call. You need the EEPROM image from OpenHR20
sudo avrdude -c usbtiny -p m169 -u \
        -U flash:w:bootload.hex \
        -U eeprom:w:../OpenHR20/openhr20/trunk/source/hr20.eep \
        -U efuse:w:0xfd:m \
        -U hfuse:w:0x94:m \
        -U lfuse:w:0xe2:m

Author: Jiri Dobry (Guest)
Posted on:

Rate this post
0 useful
not useful
I am sorry, in avrdude commands I write invalid hfuse. Here is correct:
avrdude -p m169 -c jtag1 -P /dev/ttyUSB0 -U hfuse:w:0x99:m
avrdude -p m169 -c jtag1 -P /dev/ttyUSB0 -e -U flash:w:hr20.hex -U eeprom:w:hr20.eep -U hfuse:w:0x91:m

Author: Bernard K. (bernard_k)
Posted on:

Rate this post
0 useful
not useful
Thank you very much for all the information, I really appreciate it!

I'll wait for my JTAG programmer to arrive (it's on its way, and looks 
to be a bit easier to use than ISP), and will then try and verify 
whether I can flash and get the sought after results on both the HR20 
and the HR20Style.

Again thank you!

Author: Jiri Dobry (Guest)
Posted on:

Rate this post
0 useful
not useful
Richard G: your patch file "richard363_111008.patch" is not possible 
apply to fresh 363 revision. You probably made same mistake.

Author: Richard G. (gggggg)
Posted on:

Rate this post
0 useful
not useful
Jiri: I thought it might be a good idea to just include the files with 
major changes. Otherwise you will also get beautifiing stuff ... do you 
want them all ?

Author: rps (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi!

Did anybody consider adding 1-wire connectivity yet?
(Axel_5 mentioned something in other threads but no details.)

This could use the one free pin in the connector (PE2 I think). No need 
for Hardware adaptions.

The device could mimic multiple "standard" 1-wire devices:
- a temperature sensor (RTC value)
- ADC (valve target position)
- EEPROM (non-volatile config)
- RAM (current state)
perhaps even:
- switch/PIO (for buttons) but this would possibly be missed when 
polling is intentionally slow.

User interface would need the possibility to configure the address.

I'm thinking of semi-autonomous operation - current target mode and 
timetable are uploaded regularly, temperature values are centrally 
logged.

Full "slave mode", just using the temperature sensor, the valve actor 
and the wheel and buttons for user requests and doing the rest centrally 
would also be possible.

I plan to implement this, but would like to hear your thoughts.

Author: Bruce A. (bruce_a)
Posted on:

Rate this post
0 useful
not useful
I got the first HR20-E flashed with JTAG last night. I'm very impressed. 
So thanks. Now, my question, assuming this is the right forum for 
this...

I also got an HR-25 
(http://www.homexpertbyhoneywell.com/en-DE/Products...) 
which has a very, very similar PCB to the HR-20. It has a MEGA329P on 
board and a fancier LCD and only a couple of extra tracks/vias that I 
can spot. I'm tempted to get more of these instead for the nicer LCD and 
bigger code space.

Before I go reinventing wheels, has the OpenHR20 code been ported to 
this, the LCD mapped out etc.? i.e. has anyone done work already on 
supporting the HR25?

Author: Axel Laufenberg (axel_5)
Posted on:

Rate this post
0 useful
not useful
>Did anybody consider adding 1-wire connectivity yet?

I can upload my code tonight.

However I have forked this a long time ago, so maybe it is quite 
difficult to merge this in the current branch.

Basically the temperature can be read as a simple 1-wire temperature 
sensor, target temperature can be set. The value of the valve can also 
be read.

However power consumption is quite high as I have removed all sleep 
modes as the device is always powered through the cable. Also the 
timetable is removed as this is now done by the central controller.

Best regards
Axel

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
@Axel Laufenberg:
If you want store your code into repository please contact me on 
jdobry-at-centrum-dot-cz and send me your account name from sourceforge.
Is it based on trunk(I will not make improvements) or rfmsrc 
(recomended)?
If it is encapsulated to "ifdef" preprocessor you can add this into 
current code. Otherwise please create new branch in repository.

Author: Axel Laufenberg (axel_5)
Posted on:
Attached files:

Rate this post
0 useful
not useful
Sorry, I do not have time right now to add to the repository, I just 
spent some time to translate most of the stuff into English. And I 
recognized that I used a version from 2008, so I guess this does not 
have too much in common with the current version.

Actually only the attached files are affected. The main.c only gets the 
additional function to assign the values received and transmitted 
from/to the onewire interface and gets the sleep mode disabled.

motor.c is changed because the external interrupt is used. This now has 
to handle also the 1-wire edge handling. The file onewire.c handles the 
timing for the onewire. I just recognised that the ISR is in the code 
twice, once within the motor.c and once in the onewire.c. Actually it is 
only used in motor.c as otherwise the interrupt routine may be too slow.

Actually you should be aware that the AVR needs to be clocked at 8 Mhz, 
otherwise it is too slow to handle the onewire timing.

I tried to document as good as possible, so it should be no problem to 
add this to the code.

If I find the time I can try to make this all a bit nicer and merge it 
with the repository, but ....

So I hope this is in any case helpful to somebody, if you have questions 
please feel free to ask.

Axel

Author: Rupert Schlick (rps)
Posted on:

Rate this post
0 useful
not useful
@Axel:

Wow, thanks a lot - mostly what I hoped for. It's a pity that it will 
need to run on 8MHz.
The code looks good and well documented too (and I have no problem with 
the german parts ;-) ).

@Axel&Jiri:
When I have this running (which still might take me a few weeks), I'll 
try to integrate it with the current version and into the repository. 
Maybe I can even invest some of the effort saved into thinking a bit 
more about the 1-wire-bootloader :-).

Rupert

Author: Bruce A. (bruce_a)
Posted on:
Attached files:

Rate this post
0 useful
not useful
I have got the LCD working on the HR25. It seems to work fine. I'll have 
to wait until the RFM12s arrive before testing further. See 
https://sites.google.com/site/slangey/misc/honeywell-hr25 for some more 
details including pictures of the board.

I've done the changes against rfmsrc and it touches the Makefile, 
lcd.c/.h and rs232_485.c/.h. I would appreciate if someone could please 
review and give comments before (hopefully) getting this in to svn?

Bruce.

Author: Jiri Dobry (jdobry)
Posted on:

Rate this post
0 useful
not useful
Bruce_a:
I made fast review and looks OK. Committed into revision 364.
PS: I made only small fix (compilation need remove one space in 
rfmsrc/OpenHR20/Makefile) and modify rfmsrc/Makefile to create new 
target platform files.
It looks that it can support hardware window detection and RFM without 
any additional changes. But I am not create target files for this 
because I can't test it.

Author: Knut Schwichtenberg (kschwi)
Posted on:

Rate this post
0 useful
not useful
Is there any technical difference between HR20 and HR25 than CPU and 
display? There is at least little space left in the 169 flash so it 
might make sense to replace the CPU and take the HR25 SW-version.
Cheers,
Knut

Author: Bruce A. (bruce_a)
Posted on:

Rate this post
0 useful
not useful
Hi Knut,

It would appear just to be a CPU/LCD difference. Amtel's migration docs 
suggest not much interesting has changed. The code would need just one 
more target to specify the new cpu correctly. Be aware that the cheap 
JTAG programmer I got off ebay doesn't program the 329 :( (see the link 
in previous post). So I'm thinking RFM12b & serial bootloader... and/or 
replacing the JTAG pins on the side with ISP ones.

Author: StuartP (Guest)
Posted on:

Rate this post
0 useful
not useful
Hi All,

I've been watching this thread for a while now, and have taken the 
plunge and purchased an HR20.

Could someone advise what is the best lowcost JTAG programmer to get 
started with for the HR20.

Cheers

Stuart

Author: Bernard Kerckenaere (Guest)
Posted on:

Rate this post
0 useful
not useful
I ordered this one:

New AVR USB Emulator debugger programmer JTAG ICE+Protecter for US 
$10,90

Ebay-Artikel Nr. 200667489423

Author: StuartP (Guest)
Posted on:

Rate this post
0 useful
not useful
Thanks for the info.

Is anyone using linux to do development work & program