Temperature changes inside the box
6 January, 2011 - 11:25
Having put the pcb board and display inside the box - I temporarily left the temperature sensor inside (in a plastic bag to avoid possible shorts!).
The graph below shows the temperature changes - it seems to go up and down once an hour. So presumably the hardware is
working harder and then resting (cooling). Any ideas? - just curious. Note the sensor works fine - and I have moved the box around to prove that it is not location. The general rise and fall aligns with house temperature as shown on nearby currentcost meter.
My feed is at http://www.pachube.com/feeds/13194 if you wish to see the days prior to the changeover.
6 January, 2011 - 14:17
#2
That's a wild graph
I've never put a sensor inside the HAH to see what its internal temperatures is like.
Off the top of my head I can't think of anything that we are doing every hour that would induce a load sufficient to push up the CPU temp. A very curious finding indeed. Hay at least its working. Love that graph!
Brett
7 January, 2011 - 00:06
#4
Pachube vs Realtime
Well I know the temperate sensor code in the firmware is good as if you watch the data realtime you see 0.1 degree movements. Now do recall that the xap-pachube gateway only pushes data every minute and it only does so it the value last sent has changed. So in a minute period its possible to swing more than 0.1 of a degree giving these larger quantum jumps in temperature. Still that doesn't explain the irregular readings. It would be interesting to graph the xap packet data directly, ie not via pachube, to get a better understanding.
I little bit of python code would do the trick.
http://www.dbzoo.com/livebox/hah_xap_python
Perhaps using some idea's from an RRDTOOL blog I wrote up a while back.
7 January, 2011 - 11:25
#5
The plot thickens
Yes you are correct about the 0.1 accuracy because I had it working happily at room temperatures for several days.
I shall have a go at the python code - new learning for me.
Meanwhile I took the sensor out and put it in my tea (!!)
The resulting graph shows the same pattern but I also had a look at xfx viewer and observed the following:
1) As the temperature fell it would jump UP from say 65.0 degrees to 65.9 degrees - always after the .0
2) At say 36.4 degrees it jumps DOWN to 35.2 degrees - always after the 0.4
So there is something funny going on. I don't seem to be able to copy and paste the xfx messages. Although I have also discovered while playing that the graph on my first message has updated - so it will confuse some readers!!
I am going to see what happens as the tea cools to room temperature. Meanwhle here's what it looks like at present - hopefully
8 January, 2011 - 13:08
#7
Looks suspicious
Looking at my temperature readings, as the temp rises, I never see a .4 ... goes straight from .3 to .5
Same deal for .9 ... never see this.
Might well be an issue with the AVR code that implements the .1 degree piece. I'll get to looking at this once the current rush of orders is handled. It's been so busy that I've run out of PCBs. More on the way.
9 January, 2011 - 01:04
#9
All source code is published
All source code for the project is hosted on google projects
The firmware for the AVR is written in BASCOM. Oh yes another language you need to learn! You'll find it in the path userapps/hah/xap-livebox/ It is possible that by default the 18b20 isn't initialized to 12bit as I dont' do this explicitly perhaps I should be, might be an AVR firmware bug. If so I'll fix this in the up and coming ATmega328P revision that I'm working on.
Brett
10 January, 2011 - 00:18
#11
Now there is something unexpected
With your code in mind, and especially those two number 25.6 and 51.2, which look just like a Byte overflow, I immediately saw what the problem is.
Consider the following code fragment.
Dim Bb As Byte
Dim Bi As Word
Dim Imeas As Word
Imeas = 256
Bi = Imeas Mod 10
Imeas = Imeas / 10
Print Imeas ; "." ; Bi
Imeas = 256
Bb = Imeas Mod 10
Imeas = Imeas / 10
Print Imeas ; "." ; Bb
End
And the result from running it in the simulator.
25.6
25.0
The Problem is that BASCOM is down casting its operands before performing the action. Not on the assignment.
(256 mod 10) = 6
But bascom is screwing up and we get
(0 mod 10) = 0
As the 256 in the WORD is 1st cast back to a Byte BEFORE applying the MODULUS operator. This is DUMB and totally unexpected which is why I've never noticed this before.
Thanks - Great detective work. You get a gold star and a free 328 when we get this sorted.
Brett
Kim,
Thanks for this interesting info. I can't think of any 'cron' type behaviour that would cause this effect. It would be interesting to see if the load average goes up during these periods of raised temperature.
The box does run quite warm. When designing the HAH PCB, I was initially concerned that the 5V regulator on the Livebox PCB might be overloaded. However, months of soak testing convinced me that the extra load wasn't upsetting the stability of the unit.
Good to see those pachube feeds.
Derek.