Help Needed with Solar Tracking Program

GA for a truly "good" comment.

Thanks for relpy...

here is the flowchart...

With Regards,

Thank you..

Equally as good as Del's comment, so a GA from me too.

Hopefully the OP understands, simplifies his code and puts full comments in for the future...

The debug/fault finding process is pretty similar for all applications.

Check each block of your flow chart to see if it works.
Presumably you have some sort of emulator which allows you to see what's going on in the processor? If not you will have to test more carefully.
Check that you are reading the phototransistors. Maybe just light a LED to indicate which is receiving more light as a simple first step.
Check that your software can drive the motor in either direction.
Basically test each block the put them tgether.

Add breakpoints or telltale indicators to show what the program is doing (eg turn a LED on everery time the phototransistors get read.
Or test the circuit using simple switch inputs rather than photo transistors.

The principal is always simplify, divide up the hardware and software functions and test them individually.

Your flow chart is ok-ish but doesn't show the complete flow (e.g the motor drive blocks don't go anywhere)...however there is nothing on your listing relating it back to the flow chart!

Test and debug is a neglected artform, rarely taught.
Del

Yeah, I will..

Thanks a tonne...

With Regards,

Thank you.

Can you consider a different procedure? Suppose only one photosensor is used with an opaque beam obstructor (any thin metal sheet will do) mounted vertically above the sensor. The size of this sheet will be decided by the accuracy required for tracking.

The aim is to keep the sensor always in the shade of the sheet. If the sensor is in llight the micro controller rotates the assembly till the sensor goes dark.

MIT researchers devised in the early 70s a system based on this concept, which used a coiled bimetal strip which twisted when exposed to sunlight aligning the shaft to which it was attached till the coil went into shadow using the mechanism described above. This needed no electronics at all.

Hi bioramani,

While a single photosensor works in principle, a differential photosensor greatly reduces the effects of common-mode variations in light levels due, for example, to clouds passing overhead, and so forth.

One of the simplest differential forms consists of a pair of closely matched photosensors separated by a thin, opaque barrier. So long as the signal levels from the photosensors are approximately the same, the system can assume 1) it is on-track, or 2) it is in shadow. If the system is equipped with an accurate timebase, it can return to an eastward-facing direction at dusk in preparation for the next day's tracking.

Our OP should seriously consider adding a small amount of hysteresis to his tracking algorithm so that the system won't sit "on the edge" and chatter. His tracking motor and its drive electronics will thank him dearly for this little kindness.

Best Regards,

SR

I don't have a clue about this sort of thing so just ignore me if I'm being stupid, but, is this right?

delay();
}
else if
{
stepper = 0x09;

It would make sense to me without the if, or, with another conditional.

Incidentally couldn't you do the whole thing with analogue. I know that microcontrollers cost very little nowadays but a few transistors is nearly nothing: and you could de-bug it with a DMM.

A couple of CdS cells, some resistors, a DC motor and, if the motor is small enough (or the opamps big enough),

1) one opamp and two batteries,

or

2) two opamps and one battery,

assuming you want the ability to drive the motor in either direction.

"Programming" the system consists in selecting the appropriate components and values for the given application and then assembling them together. Not Assembly "language" as such, but potentially every bit as messy. In a pinch the power switch (do we really need one?) can serve as the boot loader.

If you're prepared to reset it by hand every morning, can't it be done with one photovoltaic solar panel one DC motor and a gear train. No other power supply, electronics or storage required.

(I've never heard of the sun changing directions)

Yes, but I must confess that I simply cannot resist the urge to do other things with it. Fun things. Honestly, watching a unidirectional sun tracker at work is about as much fun as watching paint dry. Even beer doesn't help.

And besides, you know darned well we engineers can't leave well enough alone.

Either it's running through the big while loop or it's not. Can you put a scope on the pins corresponding to WRITE_1 or WRITE_2 to see if they are toggling. If they're not then I would be suspicious of the while loops where it is probably stuck:

while(INTR_1 == 1);
while(INTR_2 == 1);

Check to see if the pins for INTR_1 and INTR_2 are ever changing.

I've worked with microcontrollers and it's frustrating to not know where it is in the program or what it's doing. You need to look at the interface pins to deduce what is happening inside.

Yes, comments would help, but this is a trivial algorithm. What is essential to help solve the problem is clarifying what "kinda not working" means. Does the motor turn on at all? Does it run at the wrong times? Does it not turn off? Does it start and stop okay but rotate the unit to the wrong position?

My first suspicion is the motor control code:

stepper = 0x0C;
delay();
stepper = 0x06;
delay();
stepper = 0x03;
delay();
stepper = 0x09;
delay();

Without knowing the details of your device, it looks like it might be right. Have you tried a prototype program that turns the motor on for some time then turns it off? Or that pulses the motor repeatedly for some time then stops? (Substitute "while (counter < limit) do something and increment counter" for your "while (1)". The loop limit needs to be tested and tuned to provide a useful delay.) Obviously, you need to be aware that software that controls hardware might damage the hardware if it's broken in the wrong way, and then avoid writing such software...

Firstly, I have changed the logic in the flowchart to allow the solar cell to be more accurately positioned, look here:-

You could add a short delay into the bottom of where the two motor movements join back together again to stop "cycling" back and forwards, but really you need to catch that properly in the software and maybe allow a slight difference between A and B to be accepted as OK and to NOT move the motor. Experience will tell.......

You have also made no correction for the Sun's altitude. You could adjust say once per month by hand, but a similar system as to that for left and right would so the trick...

Also, I notice that you have made no provision for nights, at least no proper provision I find. If it stays pointing west in the evening, it may not pick up that the sun has reappeared in the east the next morning!!!

My suggestion is that you evaluate a level of darkness for A+B in some way, decide when its dark and drive the solar cell back to the east (say to a micro switch that positions slightly "east" of the awaited sunrise position say on midsummer's day morning! Or even just a specific number of stepper motor steps, in the right direction of course! But I personally prefer either a switch or some other position sensor).

Once its positioned back to the east, then give it a test only say once every 15 minutes for a usable A+B light level before starting to adjust the cell position again....thats already in the logic of my version of your flow chart, as both dark means they are also equal!!

You need a method of adjusting the sensors to account for slight differences in both being light or both being dark to make sure that no movement occurs due to that...

Mounting all this temporarily on a rotating table will allow easier/quicker testing than waiting for the sun to move......

Remember, that with the wrong sensors, street lighting and similar may become a problem at nights!!! IR or UV (with filters) would be better, do not use visible light.....but do test, test and test!!

Best wishes.

Don't think anyone else has pointed this out (sorry if they did), but in your code, you have

#define Stepper_motor P2

... and later ...

Stepper_motor = 0;

BUT

stepper = 0x0C;
stepper = 0x06;

... etc. refers to an undefined variable. The assembler may just assign a memory location (instead of port P2).

Ya thanks mate for that..

I ll rectify it..

With Regards,

Thank you.