[Part 2] Prototyping

"Now that the project has started, proving the concept by building a prototype is absolutely crucial since the most fundamental idea behind the operation is based on the unproven assumption that the CPUs will synchronize under the proposed rules of operation."

I apologize for not uploading step-by-step pictures unlike my previous projects. This happened due to complications from my schedule and I simply did not have time to waste my time on taking pictures and stuff. In the pictures, one can see a Parallax BS2 Module, two solid state relays (black chips), and two mechanical relays (blue chips), one ambient light sensor (between the two mechanical relays), and an external array of six ambient light sensors. One operational assumption has been made.

"The light measurement from the ambient light sensor is assumed to measure incident light that is free from any obstructions in its path by dust, etc."

This assumption guarantees that the "differential readings" between the ambient reading and all the other photoreadings measure only the effect of obstruction by dusts on the surface of the panel independent of incident light conditions. To test this hypothesis, if I let all the sensors (including the ambient) be exposed under an identical incident light condition, the light readings from the external array should be zero since the differential readings are zero (due to the identical light measurements from the ambient and the array sensors). However, if I start to cast a shadow on the array (and not on the ambient), then the readings should slowly sway away from the zero reading indicating that there is some inconsistency between the true ambient light condition and the detected light condition. I have measured and verified the performance of this setup and it came out to be very satisfactory, as always.

Now, remember that the system consists of two CPUs, one master and one slave. The CPU that controls sensors and actuating mechanisms - therefore the one that does all the dirty works - is a slave which gets controlled by the master CPU. The one shown in the picture is only the slave part of the circuit. The relay chips above will be connected to electro-mechanical parts.

This picture now shows the master and the slave. This time they are fully connected. The master CPU does more of a "fancy" job, which is to display the status of what the slave has reported to it to the user, us. Therefore it is hooked up to four digit 7-segment display. In addition, it is hooked up to a relay for controlling the slave as discussed. The master and slave communicate via 3-bit data channel as shown in the picture by three black wires in the middle of the two boards. The data channel uses the following communication convention.

1. Slave-to-master direction
000 - Null, Request to turn off the transmission stand-by mode
111 - (short pulse) Request to turn on the transmission stand-by mode
111 - (long pulse) Request to terminate itself at the end of one full operation cycle
001 - Not dirty
010 - Not so dirty
011 - A little dirty, minor cleaning required
100 - Dirty, regular cleaning required
101 - More dirty, intensive cleaning required
110 - Very dirty, extreme cleaning required

2. Master 
000 - Null
111 - Send confirmation of successful transmission to the slave CPU

Although, in principle, the use of 3-bit channel constraints the available types of signals down to eight, here I got around the issue and was able to transmit nine different signals by differing the pulse width of a signal (specifically, "111"). The initialization of the transmission stand-by mode before any actual data transmission is critical because this CPU cannot simultaneously report the status of its pins while it is running other processes.

No comments: