problem with light sensor ??

[davidwf]

Heres one for you clever people to ponder......
My curtain and lights controller has recently started playing up...it reads the light level from a TAOS TSL250R (into #w0) and sends a signal to an external RF remote controller to turn lights on at a preset darkness then when it gets darker it sends another signal to close electrically operated curtains, the lights are turned off at a preset time by a separate controller with it's own clock, not part of this project.
For the past few weeks I have noticed that the lights are on in the morning, I added some tracking commands and managed to log the program overnight and it seems that the curtains open when it gets light (correct) then after a 5 min delay when the light level is read again it is reported to have dropped so the lights turn on again !

Have attached the relevant part of the log file showing date, time and light level (#w0) and also the main program in case someone could offer any ideas.
At 04.25.31 curtains open (#w0=98)
At 04.31.25 light has continued to increase (#w0=104)
At 04.31.27 lights turn back on (#w0=76)
At 04.32.03 curtains close (#w0=70)
At 04.37.57 light read again and has dropped (#w0=67)
At 04.43.08 curtains open again (#w0=107)

So, it appears from reading #w0 that the light level falls from 104 to 76 between 04.31.25 and 04.31.27 i.e. in just 2 seconds and continues to drop slightly but surely this cannot be the case ?

I have tried varying the trigger points and also increased the read delay to 15 mins to no avail.

Thanks in advance

 

[davidwf]

cct diagram attached

cct diagram attached

 

[BeanieBots]

A very quick scan of your code doesn't show anything obviously wrong.

Without knowing (ie personally seeing) what light levels create LDR values of 104 and 76 it's hard to say if that could be real or not. It's certainly very possible for light to drop quite quickly. Also, double check that there is no interaction between the curtain movement and the light falling on the sensor.

As for a solution, add in some more logic.
You know the time of day and you know the curtains have been opened.
Therefore, don't turn on the lights until after some preset time of day.
An easier logic to implement would be don't put lights on if curtains open.

It's also worth taking several readings of the sensor and averaging.
Maybe a bird flew past at the instant you read it!

 

[hippy]

I haven't studied the code but the first thing is to determine if it is a natural occurrence that light rises then dims and your system is responding correctly or there's some fault. It could be someone has taken to driving past in an articulated lorry around 04:30 which causes the light level to appear to drop. I have IR-remote controlled lights and I sometimes find them on for no reason. It only happens when very sunny so I presume it's a flash of sunlight bouncing off something, enough to fool the sensors into thinking they are to be switched on.

Perhaps re-program your PICAXE to only report light levels throughout the night then look at the log ?

 

[davidwf]

wow, such a quick response.....
The curtains will not affect the sensor, it is outside the house, recessed and pointing downwards which will also shield it from passing birds, likewise we are 50ft+ from the road so I think we can also rule out passing traffic.
I have (at least I think I have) averaged the readings, it is read once, read again 5 minutes later and if lighter (or darker) than first reading AND above (or below) the trigger thresholds then it continues to the next action.
Looking at the log again the light level does appear to drop significantly.....unless something is causing an incorrect return of value.
I have also extended the delay between reads (up to 15 mins) and altered the trigger thresholds quite a lot but the problem remains.

hippy : your IR problem is quite a well known one, the sun chucks out so miuch IR radiation that a sensor receiving a reflected image will often report rubbish, we had a TV that would constantly turn off at certain times in the afternoon but ONLY in spring and autumn when the sun was at a certain angle !

One thing I can't understand though is that the lights on trigger point is #w0=460..... and they appear to be coming back on at around 76, likewise the curtains close again........?

 

[Buzby]

Another source of interference could be automatic IR floodlighting for a CCTV security camera nearby. I have seen the picture go dim at early dawn when the floodlight turns off, then brighten as the sun rises higher.

 

[davidwf]

Is there a problem with line 87 I wonder
if w4<= w3 and w0< lights_on_lev and b10=0 then lights_on
or line 88
if w4>= w3 and w0> first_light and man_open = 0 then wait_for_curtains_open

......it is as though the program is ignoring the "and" statements...I am presuming I can use them here ?

 

[davidwf]

Another source of interference could be automatic IR floodlighting for a CCTV security camera nearby. I have seen the picture go dim at early dawn when the floodlight turns off, then brighten as the sun rises higher.

nope, no CCTV here...no streetlamps, no floodlights in fact no nothing !

 

[hippy]

The curtains will not affect the sensor, it is outside the house, recessed and pointing downwards which will also shield it from passing birds, likewise we are 50ft+ from the road so I think we can also rule out passing traffic.

It could be something bizarre like some bird / insect taking to perching in the sensor at a certain time or maybe some secondary effect; vehicle drives past, reflects sun onto the sensor, passes on, the was saturated AGC in the sensor causes the light level to dip. Could it be light reflecting from a pool of water or dew causing light to be higher than it is and then drop again ? Has condensation got into the sensor ?

I think I'd get into logging what's happening, and with quite short intervals. It may then be a case of putting audible alerts on significant drops and rises, getting up early and watching what happens. Seeing if you can correlate the drop to something.

As Beaniebots suggests some additional logic may help, lock-out reverse changes until such a time as they would be sensible to occur. Just altering sampling intervals won't really achieve that.

 

[Dippy]

No. 1 are your tests reproducible?
If so, it is highly unlikely that an insect lands on your sensor at the same time

Is there any chance that the voltage is drooping when any of the relays are switched on ?
This could affect ADC reference and TAOS output.
Sorry, no time to check your code.

 

[hippy]

Is there a problem with line 87 I wonder
if w4<= w3 and w0< lights_on_lev and b10=0 then lights_on
or line 88
if w4>= w3 and w0> first_light and man_open = 0 then wait_for_curtains_open

......it is as though the program is ignoring the "and" statements...I am presuming I can use them here ?

Shouldn't be a problem there, it's only with mixed AND and OR there can be issues. If that's where things are going wrong it's likely one of the variables is not as expected, or there's a deeper problem with the program logic.

 

[davidwf]

am pretty confident that voltages remain OK, 18V main supply is stabilised at 5A, cct only draws max of about 3/4A with the curtain motor running, 5V is stabilised from that so it should be super stable.
As a point of interest the output from the TAOS is a digital signal so surely that wouldn't change anyway ?
more investigation will certainly follow.......

So, if we rule out a problem with multiple and statements I still can't see why the lights are switching at 70 odd when their set point is 460......hmmmmm

 

[MartinM57]

As a point of interest the output from the TAOS is a digital signal so surely that wouldn't change anyway ?

If you mean that inside your code (i.e. w0) then it won't change between readadc10 commands. Or do you mean something else?

(The LDR reference threw me a bit at first - the TAOS is not a LDR - it's a light to voltage converter)

For piece of mind, instead of

readldr:
sertxd ("read ldr  ",#w0,cr,lf)
	readadc10 2,w0						' read ldr ADC10 value on i/p 2 (PIC pin 1) into w0
	pause 2000							' wait 2 seconds
	return

..I'd be using that 2 seconds to do several/many reads and doing some averaging, rather than just taking a snapshot once.

 

[davidwf]

(The LDR reference threw me a bit at first - the TAOS is not a LDR - it's a light to voltage converter)

Yes, apologies for that I didn't have the cct diagram to hand this morning......I AM using the TAOS and will update the cct diagram when I get home !

 

[hippy]

So, if we rule out a problem with multiple and statements I still can't see why the lights are switching at 70 odd when their set point is 460......hmmmmm

That's probably the best approach to take if that's what's happening. Work out why that is happening, what could cause or allow that, then work back to how such a situation could arise.

I haven't really studied the code, don't have the time to work through it, but if you had "If w0 > 460 then" and it's executing the "then" the w0 must be greater than 460. Most debugging is about finding why a program goes somewhere it shouldn't or goes there at the wrong time, tracing back to find the cause.

Always check it is "70" and not some larger value you're only showing the LSB of.

Debugging is much easier when the bug can be replicated; does it happen regularly, at a certain time, a certain time after something else ? Could it be the curtains are opening, the current limit isn't performing as well as it could, causing an effect on the light sensor ?

Unfortunately, where we currently are suggests it could be "anything".

One option which I've taken is to use what you've learned, and rewrite the code in some other way. One usually gets a much nicer and better program on the second or later attempts and it's often quicker than debugging. That may cure, possibly reveal, a subtle bug in the existing code though it might not overcome the problems, behave just the same. At least that should narrow down what isn't a problem.

One thing I would suggest if you need help with code is to make that code as clear as possible, in particular give variables meaningful names; "If w4 <= w3" is meaningless to me and I don't have any compelling reason to investigate what it could mean ... other than I'm a nice guy

Looking at ...

if w4<= w3 and w0< lights_on_lev and b10=0 then lights_on

where 'w4' is the latest light reading, 'w3' is the reading five minutes ago, 'w0' is also the current light reading and 'lights_on_lev' is 460, while you question why the lights are switching at 70 and not 460 it seems obvious to me that will happen, say the five minutes ago reading was 100, it's now 70, the light level has dropped (w4<w3), 70 is below the trip point (w0<460) and if b10=0 then it will turn the lights on. 'b10' is set to '0' in 'reset_if_light', which is called when powered up and it's light.

So that's one combination which will turn the lights on, and apparently even if it is already light ( b10=0, via reset_if_light ). Perhaps that's a logical error ? Perhaps it points to a power outage which caused the program to reset and restart ? Perhaps I've misunderstood the code or its intent ?

Now looking at your log - Light increases (04:25:27), curtains open, light increases again (04:31:25) and lights come on (04:31:27) - Huh?

It's a good idea to put your logging of what the LDR reading is after reading the LDR

Rewrite the logging, run it again and it will be easier to see what's actually happening, what the LDR readings are and why things are going where they do.

 

[davidwf]

OK, wrists slapped....I will add a log entry after every line and see what happens

Now looking at your log - Light increases (04:25:27), curtains open, light increases again (04:31:25) and lights come on (04:31:27) - Huh?

yes, my point exactly, I couldn't see why there was an entry 2 seconds later either....should be a minimum of 5 minutes !

 

[hippy]

That two seconds is probably the two second delay after the LDR reading is taken. Not sure why that's there.

It's usually best to take out delays which are not absolutely unnecessary as it's then easier to group logged actions together and see what immediately followed from another and where there was some delay. It's a bit of an art working out what to log and how to display that but you've got a good start there. Perhaps put a line before the IF which shows all values used in the IF then you can see exactly why what happens next happens.

The log is good because you can work backwards, follow the "how did we get here" trail.

 

[axeman22]

what a neat idea.. I have been thinking of something like this for a while.. can you post some pics? and details of the motor etc that you used.. How does it know when the curtains are fully open and closed..?

 

[davidwf]

Correct diagram now uploaded

 

[Dippy]

axeman, instead of causing a tangent in this thread have a search for David's project
e.g. http://www.picaxeforum.co.uk/showthread.php?t=9980&highlight=david+curtains
and
http://www.picaxeforum.co.uk/showthread.php?t=9909&highlight=david+curtains

 

[davidwf]

That two seconds is probably the two second delay after the LDR reading is taken. Not sure why that's there.

hmmm....neither am I now, must have done it for a reason though ....suffice to say it is now gone !


update....Just read comment from Dippy about hijacking the thread....apologies but I already uploaded the required photos.
I will also update the original thread

 

[davidwf]

OK, am going to take your advice and re-write (at least part of) the program......is it possible to do the following

read adc into variable 1 (am OK with that)
wait 1 minute (OK with that)
read adc into variable 2 (OK with that)
compare the two and do something if the difference is greater than (say) 200
.....how ???
Presumably it would look something like this
read adc10 2, w0
w1=w0
pause 60000
read adc10 2, w0
w2=w0
......all OK to here......
if w2 > < w1 by 200 then do something
....this is where I am stuck as it obviously don't work

thanks

 

[MartinM57]

if w2 >= w1 then
    w3 = w2 - w1
else
    w3 = w1 - w2
endif
if w3 > 200 then...

?

Still think you should be taking multiple readings each time - say 5 readings every second and averaging then...then pausing 55 seconds - rather than just relying on a single reading. Or even

Take a reading every second for 60 seconds
Average them
Take a readings every second for 60 seconds
Average them
Compare last average with previous average
If appropriate, do something
Repeat

It seems such a shame to have the PICAXE doing nothing at all for 60 seconds - might as well use it

 

[davidwf]

thanks as always for the prompt reply !

I am not relying on one reading, my plan (as if there was one) is to read now, wait 5 minutes and read again then if it is getting darker go to wait till dark area and read twice with a 5 min delay before actioning something (likewise if it is getting lighter)
The reason for the delay is to prevent possible operation by car headlights or passing clouds etc.

I have found by experimenting that the TAOS output changes a LOT with only a few lux of light level, I think my original values were too close together which was the main problem

 

[hippy]

I am not relying on one reading, my plan (as if there was one) is to read now, wait 5 minutes and read again

I believe the suggestion is not to read, wait then read again, but to fill the 5 minutes with continuous readings then at the end of five minutes pop-out with an average of all those readings.

 

[davidwf]

OK point taken........so how does one average the readings without storing them in (and therefore using up) loads of variables ?

 

[papaof2]

Something like this? (untested)

'for the first minute (or whatever interval)
ThisAverage = 0
w3 = 0
for Counter = 1 to MaxReads
readadc MyPin, CurrentReading
w3 = w3 + CurrentReading
wait for next time to read
next Counter
ThisAverage = w3/MaxReads

'for the next minute
ThatAverage = 0
w3 = 0
for Counter = 1 to MaxReads
readadc MyPin, CurrentReading
w3 = w3 + CurrentReading
wait for next time to read
next Counter
ThatAverage = w3/MaxReads

Compare ThisAverage and ThatAverage to determine amount and direction of change.

John

 

[davidwf]

I decided to re-write the code as suggested and have added more comments to make it a bit easier to follow.
I have also "directed" the chain of events a bit better (I think) so it has to progress from one operation to the next in order.........thankfully it all seems to be working OK at last !

Complete code attached and I have also updated the main thread
http://www.picaxeforum.co.uk/showthread.php?p=136269#post136269
with latest details, photos of the completed project and code

Thanks once again to all who contributed and also for the super quick replies