my youngest daughter was no longer using the CRD-King night light i bought her before. rather than naka tambak lang sa room niya and dagdag lang sa mga abubot niya, binaklas ko na last week at kinahoy ang mga parts 🙂 ha ha ha ... i cannot find an LDR part in any of the 4 electronic stores here in marbel 🙂 ...

to have an idea of the actual scenario in our place, i tested this LDR (i cannot identify the manufacturer from the part so that i can search the internet for the datasheet) on the roof deck using a breadboard and a multimeter. i'll use the info as a starting point for the photosensor circuit i'm doing. the results that i got are below:
- during day time (high noon), the resistance was about 380-420 ohms ...
- at dusk, the reading was around 70K-80K ohms ... for me, this is the ideal time to turn-on the outdoor lights that will be controlled by the HAS ...
- @ 100K reading, it was already quite dark in our place although the horizon is still a little bright. FYI, this is the value that most people are mentioning in the internet for the night sensor circuit that they made.
- @ 150K reading, it's already quite dark and the horizon is dim ...
- @ 200K reading, it's night already 🙂 he he he ...

it's good practise to actually test the critical part/s your going to use in your project even if you have the datasheet info of the part ... cheers

Boo!

Voltage Divder - LDR Analog Read Testing.jpg ... Part 1

this was the first testing i did a few months ago for my HAS project. i manage to document it now based on my old notes 🙂 ... the schematic, i just made it today based on my recollection of what i was doing then when i was doing this test program to understand what is happening when reading an analog data coming from a hardware sensor 🙂 ...

the core of any HAS system is to be able to accurately read sensor data from a hardware and understand what it means. if you don't have a good understanding of this, then your in big trouble with your project 🙂 ... this happened to me at the early stages of my program development as i'm not really familiar with basic electronics 🙂 he he he ...

for someone with very little knowledge on electronics, it was critical for me to understand what goes on at the hardware side of reading a sensor data. understanding what's happening on the hardware will give you the input in making a good program that reads sensor data. a voltage divider setup was the most common hardware setup i read in the internet for a sensor (not only LDR) which is a good place to start in relating hardware to the software ...

why it's important?
- all arduino MCU are based on the Atmel AVR chip, if it works for one (e.g. UNO using ATmega328), it should also work for all the other Atmel AVR chips
- understand the limitations of arduino (Atmel) and manage your program to work with it and not against it
- come-up with a workable program/s that can fit an 8KB and 16KB chips

as shown in the photo, the one on the right shows a basic voltage divider circuit using 2 resistors, R1 and LDR (Circuit-2). the one on the left, is a similar setup using 2 resistors R1 and R2 (Circuit-1). think of the left side circuit as a snapshot of the LDR circuit at any point in time. so if your able to make a program to read the left circuit, that same program can read the right circuit any time.

to make manual computation (you need to do this to validate the logic of your program) simple for Circuit-1, i have setup the circuit before on a breadboard with R1=150 ohms and R2=100 ohms. BTW, there are a lot of online calculators available in the internet for voltage dividers that you can use to know what's expected from the resistors you will use in the hardware. with the 2 resistors, output voltage is expected to be 2V using a source voltage of 5V. typical current for this 5V source is 1A. Don't assume, get an actual measurement of your source voltage and it's amphere using a multimeter, so that your manual computation will also be accurate.

why start making your test program using Circuit-1 instead of jumping to Circuit-2 at once? simple, Circuit-1 does not change - it's reading at A-PIN (connected to A0 of arduino UNO) will always be a certain value which you can always verify by doing manual calaculation to get Voltage, Current, and Resistance at each point of the circuit ... it's easier to debug your program if the output does not change based on the input 🙂 he he he ...

for Circuit-1 to be like Circuit-2 in process, the following are the only info that your test program should work with ...
- voltage source=5V
- current source in amphere=1A
- R1=150 ohms ... in Circuit-2 this is 8.2K (8200 Ohms)
R2=100 ohms in Circuit-1 is only there so that you know that when you read A0 pin, the voltage that you should get should be 2V which will be the starting point of your program in getting all of the other information - voltage, current, resistance in all of the items in the circuit ... in Circuit-2, the resistance value of the LDR will be constantly changing, which means that your voltage reading will also be changing at any point in time.

i will not go into the details of programming it in arduino as it's really dependent on your style. it's much better for the person who plans to do this, to understand the concept and principles behind it so that programming it will be a simple task of merely coding what you have in mind.

below is the result of the testing i did before using an arduino UNO and the Circuit-1 in a breadboard ... the goal is not just to get an accurate reading from the hardware, but more important, is to understand why (the concept and principle) you got that reading from that hardware circuit in the first place 🙂 ... i numbered the results from 1 to n to show the basic logic of the test program ... as you can see in the results below, you can get all the info of each of the units in this basic circuit ...

New Analog Reading ...
(1) analog read data is 412
(2) Voltage @ R1 (V1) = 2.0136852264
( 8 ) Current @ R1 (I1) = 13.4245681762
Resistance @ R1 (O) = 150.0000000000 ... this is a constant so no need to compute ...
**
(5) Current @ A0 pin (mA) = 19.9087657928
**
(6) Voltage @ R2 LDR (V2) = 2.9863147735
(9) Current @ R2 (I2) = 29.5248928070
(4) Resistance @ R2 LDR (O) = 101.1456604003
**
(12) Total Voltage (Vt) = 5.0000000000
(7) Total Resistance @ time of Analog Read (Rt) = 251.1456604003
(10) Total Current in use (It) = 62.8582305908
(11) Available Current (I) = 37.1417694092
**
(3) R1 ratio to R2 = 1.4830097198
*****
next reading after 5 seconds ...

this post is getting too long 🙂 he he he ... i'll post the continuation in another posting 🙂 ... cheers

Boo!

Voltage Divder - LDR Analog Read Testing.jpg ... Part 2 (last part) ...

below is a short explanation for each item from my earlier post today ... based on my understanding of basic electronics 🙂 ... note that your manual computation may not be exactly the same as the computation based on the analog reading taken from the sensor. the reason for this is that resistors in general has some accepted standard percentage (e.g. 1%, 5%, 10%) for error depending on the type of resistor that you use.

(1) analog read data is 412 ... the analog pins of arduino was designed primarily to read voltage. it can convert analog input (e.g. 0V to 5V) into digital value to a range of 0-1023. so, every increment = 5/1023 = 0.0048875855327468 millivolts ... and 1023/5 = 204.6 means that 1V = 204 units ...

(2) Voltage @ R1 (V1) = 2.0136852264 ... analog read of 442 * (5/1023) = 2.0136852264 ... let your program work with the limitation of arduino ... multiply first before you divide ... (412 * 5) / 1023 ... and you'll still get the same result ... as you can see, the value of V1 after R1 is 2.01 which is the same as what we expected to be 2V

(8) Current @ R1 (I1) = 13.4245681762 ... using ohms law I=V/R, you can compute this as V1/R1 ...

Resistance @ R1 (O) = 150.0000000000 ... this is a constant so no need to compute ... think of R1 as the amount of resistance needed to reduce 5V to 2V given a certain current ...

**
(5) Current @ A0 pin (mA) = 19.9087657928 ... now that we have total resistance, value of R1 and R2, you can easily compute current using ohms law I=V/R ... 5 / (R1 + R2) ...
**

(6) Voltage @ R2 LDR (V2) = 2.9863147735 ... this will be = to current @ A0 * R1 ... with ohms law, V=IR ... the current after R1 multiplied with the R1 value give you the voltage at R2 ... to verify, V1 + V2 = 4.9999999999 which is 5V, the total voltage we have in the circuit ...

(9) Current @ R2 (I2) = 29.5248928070 ... using ohms law I=V/R, you can compute this as V2/R2 ...

(4) Resistance @ R2 LDR (O) = 101.1456604003 ... since R1=150, then you can easily compute for R2 using R1/ratio of R1 to R2 ... the value of R2 is almost the same as what we expected as 100 ohmns ...
**
(12) Total Voltage (Vt) = 5.0000000000 ... sum of V1 + V2 as explained earlier in (6) ...

(7) Total Resistance @ time of Analog Read (Rt) = 251.1456604003 ... this is just the sum of R1 + R2 ... which is what we are also expecting ... 250 Ohms total resistance ...

(10) Total Current in use (It) = 62.8582305908 ... this is just the sum of all the current use in the circuit ... I1 + current @ A0 + I2 ...

(11) Available Current (I) = 37.1417694092 ... difference between total current of 1A and the total current use in the circuit ...
**

(3) R1 ratio to R2 = 1.4830097198 ... the 611 difference of 1023 - 412 is the resistance ratio (R1 ratio to R2) of the amount of resistance applied to the voltage divider. so (1023 - 412) / 412 gives you the ratio of R1 to R2 ...
*****
next reading after 5 seconds ...

as i mentioned earlier, if your program is correct in getting all the info in Circuit-1, then it will also be able to process the analog reading in Circuit-2. you just need to change R1 to the value you use in Circuit-2. for my case, i use 8.2K because at the time i was testing this, i don't have a 10K resistor on hand 🙂 he he he ... if you review the specs (datasheet) of an LDR resistor (e.g. GL5528), it mentions that at Lux 10 (normally bright area), the resistance of the unit is between 10K-20K ...
- voltage source=5V
- current source in amphere=1A
- R1=8200 ohms ; 8.2K

when your running the program for Circuit-2, try to do the following and see what happens:
- cover the LDR with your fingertip ...
- shine a flashlight on the LDR ...
- bring your laptop, arduino, and breadboard outside and inside the house (brightest and darkness area) 🙂 ...
- reverse the (+) and the (-) wires to the circuit. this makes a voltage divider with the LDR as R1 instead of R2. the sensor becomes a light sensor instead of a dark sensor when LDR is treated as R2. do not do this with a breakout board as you don't know the circuit of the board and it may damage your breakout board.

below is the result of one of the testing i did with circuit 2 before ... basically the same explanation as in Circuit-1 except that now, the analog read is different every time as the resistance in the LDR is constantly changing depending on the amount of light the the sensor gets ...

New Analog Reading ...
analog read data is 622 ... to get V1 ... analog data * (5 / 1023) = 622 * 0.0048875855327468 = 3.040078201368524 ... voltage drop @ R1
Voltage @ R1 (V1) = 3.0400781631 ... voltage drop from the 8.2K resistor in the circuit ...
Current @ R1 (I1) = 0.3707412481 ... ohms law computed as (V1 / R1) * 1000 ... multiply by 1000 to get milliamps value ...
Resistance @ R1 (O) = 8200.0000000000 ... this is a constant R1 value use in the setup of the circuit ...
**
Current @ A0 pin (mA) = 0.2390148401 ... 5 / 20919.2031250000 = 0.2390148401 ... voltage divider computation using 5V and total resistance value at time of reading of 20919.2021484375
**
Voltage @ R2 LDR (V2) = 1.9599217414 ... computed with 5V source - voltage drop @ R1 of 3.0400781631 = 1.9599217414
Current @ R2 (I2) = 0.1540915489 ... ohms law computed as (V2 / R2) * 1000 ... multiply by 1000 to get milliamps value ...
Resistance @ R2 LDR (O) = 12719.2021484375 ... LDR resistance at the time of analog reading ...
**
Total Voltage (Vt) = 5.0000000000 ... V1 + V2 ... 3.0400781631 + 1.9599217414 = 4.9999999045 ... 5V ...
Total Resistance (Rt) = 20919.2031250000 ... 8200.0000000000 + 12719.2021484375 = 20919.2021484375
Total Current in use (It) = 0.7638476371 ... 0.3707412481 + 0.2390148401 + 0.1540915489 = 0.7638476371 ... current use from the 3 items in the circuit ...
Available Current (I) = 0.2361523628 ... 1 - 0.7638476371 = 0.2361523629
**
R1 ratio to R2 = 0.6446945190 ... if LDR resistance @ point of analog read = 12719.2021484375, then R1 value should be 0.6446945190 * 12719.2021484375 = 8199.999911150681 ... since 8.2K is a constant, this info is some sort of validation that the value you are getting for R2 is correct at any point in time ...
*****
next reading after 5 seconds ...

about current usage, since current is constant in a circuit and moves from (-) to (+) of a DC circuit ... 1A - 0.1540915489 (current use @ R2) = 0.8459084511 ... again less 0.2390148401 (current use @ A0 pin) = 0.606893611 ... again less 0.3707412481 (current use @ R1) = 0.2361523629 which is the excess current in the circuit that was not used ...

cheers

Boo!

Hi Boo,

Pwede din po kayo magdagdag ng RTC (realtime clock) sa HAS nyo. Para hindi lang si photosensor and magsasabi kung night or day. Naka logical AND po si RTC at photosensor. Maagamit ng HAS nyo ang RTC assist during rainy season kung saan madilim na kahit hindi pa naman hapon or gabi.

And suggest ko po gawa din kayo algorithm ng averaging sa reading ng photosensor. For example, and refresh rate ng reading sa sensor ay 1 read per 1 sec (1hz). tapos halimbawa lang magsave kayo sa buffer ng 60 sec worth of readings. thats 60 reads. iaverage nyo po yung 60 readings na iyon. then sa next reading isave nyo ulit yung bagong value sa head ng buffer, and omit the oldest value on the tail of the buffer, then do averaging again. for every avarageing na ginagawa nyo, icompare nyo naman sa threshold value na napili nyo for night or day. pwede din po kayo mag average every 5 minutes or every 30sec. its up to you po. siguro pag nasa testing stage na kyo pwede nyo ibahin yung algo sa pag average. malikot po kasi ang reading na makukuha nyo lalo na kung dusk or dawn na. so para maiwasan ang false triggering, try to average your readings for a particular time duration.

'Pwede din po kayo magdagdag ng RTC (realtime clock) sa HAS nyo. Para hindi lang si photosensor and magsasabi kung night or day. Naka logical AND po si RTC at photosensor. Maagamit ng HAS nyo ang RTC assist during rainy season kung saan madilim na kahit hindi pa naman hapon or gabi.'

, yes it's possible to include an RTC clock to an end-node (MCU) where the sensors are connected. i have also studied that option before as the base arduino has no built-in RTC. since the HAS i'm building consist of multiple nodes (e.g. main-host, mid-host, and end-nodes) downside will be added cost to the hardware unit due to the RTC and the problem of time synchronization due to the possibility of some unit being turned off/on accidentally for one reason or another.

a much better (cheaper) solution which is part of my design is to have one node (e.g. main-host connected to a computer for data logging) get the time info and then send it to all the nodes via the network at a pre-determined interval process (e.g. housekeeping routine say every 6 or 12 hours) to synchronize the time of the all MCUs in the network. no added hardware to the MCU as the time will be taken by the main-host from the computer. for mid-host and end-node that was turned off accidentally, during power-on/start-up process, the first thing an MCU will do is to connect to a valid HAS network. included in the hand-shake process is the time info being sent to the new MCU that just connected to the HAS network. hopefully with these process, the whole HAS network will only have 1 time reference while it's running which is very critical to it's operation.
added benifit of this design is that the system will be able to check/identify the network for MCU that are not working properly - do not respond to the time synchronization request from the main-host ... cheers

Boo!

'And suggest ko po gawa din kayo algorithm ng averaging sa reading ng photosensor. For example, and refresh rate ng reading sa sensor ay 1 read per 1 sec (1hz). tapos halimbawa lang magsave kayo sa buffer ng 60 sec worth of readings. thats 60 reads. iaverage nyo po yung 60 readings na iyon. then sa next reading isave nyo ulit yung bagong value sa head ng buffer, and omit the oldest value on the tail of the buffer, then do averaging again. for every avarageing na ginagawa nyo, icompare nyo naman sa threshold value na napili nyo for night or day. pwede din po kayo mag average every 5 minutes or every 30sec. its up to you po. siguro pag nasa testing stage na kyo pwede nyo ibahin yung algo sa pag average. malikot po kasi ang reading na makukuha nyo lalo na kung dusk or dawn na. so para maiwasan ang false triggering, try to average your readings for a particular time duration.'

, i'm glad to see that you know your programming well, especially the logic formulation :-). i also notice that your very familiar with electronic hardware and that is really a good combination in this day and age - you immediately notice the problem of this simple LDR schematic which is hysteresis :-). your 100% correct as to how to program the end-node MCU that controls this LDR sensor. for a stand-alone MCU, what you mentioned is the right way to go.

for my case, to simplify the program logic of the end-node MCU that controls the LDR and handle the hysteresis problem of a simple hardware setup, this is what i have done in the design/programming of the HAS system:
1. day/night flag was setup as a global parameter in HAS as this info is also used by a lot of scenarios controlled by other end-nodes around the house for home automation.
2. the plan is to have only 2 LDR sensors (installed at different location) to determine day/night flag for the whole house - one primary and the other one as a secondary backup. a single reading is taken every minute for each of the 2 sensors which is then sent to the mid-host for rules processing.
3. mid-host performs 3 simple task (1) send the reading to the main-host for logging, (2) compare the 2 readings and check if they are the same - close to each other based on some percentage, (3) if (2) is YES, compare average reading of the 2 sensors + current time to the average reading + time of the global day/night parameter to determine if night condition is TRUE. if yes, set the night condition to TRUE for the whole HAS network.
4. the main-host, as part of it's daily (batch) housekeeping, process the sensor data and updates the global parameter average (1-week) reading and time of the night condition. the updated info is then relayed to all MCU in the network for their use.
the logic you mentioned is basically this module which is now done in offline mode by the main-host instead of in an online mode by the end-node - the data is also minimize as you only log 1 reading per minute per sensor.
the goal was to minimize the online task of each MCU to only those things that are really critical to the process and have the non-critical task done in offline (batch) mode ... cheers

Boo!

Hi Boo,

If you have host computer then thats great. all you have to do is create GUI for data logging, node monitoring, systems diagnostics, etc. Ok din kung handled ni GUI na magaccept at magperform ng sets of operations na gusto nyo ipagawa halimbawang nag out of town kayo or matagal na walang maiiwang tao sa bahay. Pero halimbawa nagbreakdown/crash si pc or during power outage, mas mainam na meron pa rin timekeeping si main host. may coin cell battery naman po si RTC kaya deretso lang ang takbo ng oras kahit walang power. Deretso lang din po ang operation ng HAS, ang mawawala lang ay data logging dahil down ang pc. Si end node naman po ay magquery na lang kay main host kung kailangan nya ng TOD sa operation nya.

you can place your LDRs one pointing slightly angled to the east and one to the west hehehe. however you can add more in the future if would like to intall smart solar panels. those solar panels that adjust their orientation to the sun's direction (astig). so design your system so that it can accomodate additional sensors. sa firmware naman, design it in a way na few parameters lang po ang babaguhin in case magdadagdag ng sensor like sensor type parameter (y type) or number of sensors (x identical sensors). you will still be restless kahit "system is up and running"... the urge to add more feature is still there, always hehehe.

kung gusto nyo naman po iinclude sa HAS kung meron kayo greenhouse or you want to automate your garden sprinklers, you can use also morning/afternoon flags. hay andaming pwedeng iautomate :). my wife and i are staying in makati most of the times kaya naiiwang walang tao ang bahay namin sa batangas. my in-laws takes care of our ornamentsl plants pag wala kami at medyo nakakahiya na rin dahil naaabala pa sila sa pagdidilig ng mga halaman. so balak ko pag hindi na masyado busy sa woodworking, balak ko naman gawan ng auto-sprinklers ang mini garden namin.

, see my replies below ...
1. it is indeed a good alternative to simply install an RTC on just the main host which can then serve as the source of the time info for the whole HAS.
2. the borloloy functionalities of a GUI interface is not a priority to me right now :-). i simply use a text file input to a program that converts it into a rules file for the event processing module. to test special condition, i use a backdoor end-node to send msgs to the main host to trigger the condition/s.
3. yes, the HAS was designed to be expandable. the base setup can handle 90 nodes with 1350 sensors controlled by 1 main host in a single comms line. expansion is done by increasing the comms line use by the main host.
4. yes, the sensors are group in a class/type setup that controls the conversion of the raw data into a meaningful information (e.g. lux, temp, on/off, day/night, etc.) to minimize changes to the sensor validation module.
5. yes, my initial list is quite huge already based on 16 global scenario/parameters that are triggered by a single or multiple events. the garden sprinkler is in my wife wish list 🙂 ... cheers

Boo!