It would be a good idea to post a schematic for what you have built. Include any ground paths connected through any metal chassis parts. Ground paths for the motor and should be routed direct to the power supply/battery and should not allow any returns though the logic circuitry. If there is a metal chassis, the circuitry/PCB ground planes should not be touching any metal chassis. Use a separate ground return path to the power source direct from any metal chassis. It looks like your enclosure is PVC so the Prop is not in an ideal enclosure. You may want to put the Propeller in a metal chassis and route the chassis direct to GND at the power source, and route the PCB ground plane to GND at the power source over different wire. Put the relay circuitry in a separate metal enclosure and route the GND in the same way. Even a simple scope like a Propscope or other would be useful to look at all the signal lines during switching to see where your noise is. If the Prop is resetting, you could use an LED that turns on only right at bootup so that you can know if the Prop has reset. You could write some debug code to turn on and LED upon seeing noise above 3v3/2 on the sensor inputs. For the test code, don't try to read the sensors, just turn on an LED if any of the sensor inputs see a voltage above 3v3/2. Spin or even PASM may be too slow to catch a noise spike but if you don't have a scope then it costs you very little to try out some debug code with any LED as visual feedback. It is not easy to diagnose anything from your photos and lack of schematic. Where is the Prop? Where are the relays? Where are the sensors? Are you using shielded cable on all signals outside of the chassis?
A schematic would be extremely hard to draw up right now since I don't have anything drawn up in the first place. I do think that the relay coil and the controlled motor ground being on the same circuit is my problem even with a flyback diode across the coil. That is the only point that the Prop circuit has a direct ground back from the motor. I can draw up a basic diagram on how I have everything hooked up and maybe that will help?
The light sensor wire is a standard Cat5 cable for networking. I don't think it is shielded and I don't think the noise is coming from that since even with the light sensor disconnected from the Prop's circuit, it still picks up noise. I think this is a ground isolation issue.
I would pull it all out and start over with everything separated as mentioned. Otherwise you could be forever trying to diagnose this willy nilly with no scope.
Here is a rough drawing of how everything is connected. Please note there is no "chassis" ground and all battery negative connections are connected directly to the battery terminal except for the sensor ground which returns back to the Prop circuit board.
The second motor does not have the delta configuration and I am not turning it on during testing. I am only using the Up/down motor.
@T Chap : I do have a hand held O-Scope and was able to figure where some noise was coming from which was found at the output of the prop to the H-Bridge.
Here is a rough drawing of how everything is connected. Please note there is no "chassis" ground and all battery negative connections are connected directly to the battery terminal except for the sensor ground which returns back to the Prop circuit board.
The second motor does not have the delta configuration and I am not turning it on during testing. I am only using the Up/down motor.
@T Chap : I do have a hand held O-Scope and was able to figure where some noise was coming from which was found at the output of the prop to the H-Bridge.
More likely that noise is from the H bridge and motor than from the Prop
The noise is only present when the motor is running. If I disconnect the ground of the motor, the noise on that pin goes away. If I turn on another output from the prop, that signal is clean even with the motor running. I really think I am getting feedback from the motor through the h-bridge since the NPN transistor shares a common ground with the motor. I believe I need to get an opto-isolator for each relay contact.
You can hand sketch a drawing and take a pic with your cell phone. What is the H bridge circuit? If it is a set of relays, how are you connecting the Prop to the relay coil? NPN on one side of the coil to GND and other side of the coil to where? A drawing of the actual circuit for the H bridge would sure help people make sense of this else you could write up pages and pages trying to get and idea of what you are doing. The first step towards progress on a problem like this is to accurately show what you are doing.
I had a similar situation with a fuel injector tester driver - the Sparkfun device cavelamb referred to was instrumental in slaying my noise dragon. Nice, cheap, easy to use product that has been reliable for several thousand hours of steady use.
It's easy enough to test the effect of separate power supplies for the Prop and motor by connecting your 12V to the motors, and a small 9V battery to the Prop. Be sure to tie the grounds of the two batteries at a single point. If this works it'll help steer you to a better solution, even if you chose to not power the systems separately.
That said, using separate V+ for your electronics and motors, and then small/inexpensive optoisolators, will nearly always remove any noise carried via wiring. Little or no engineering has to go into it. It's often the easiest way to handle this situation if you not familiar with dealing with motor noise, and as you've found the trial and error method isn't very effective. Any glitches left are being radiated out, and there, things like distance, twisted motor wires, and a few other low-tech things are the simplest fixes.
... and all battery negative connections are connected directly to the battery terminal except for the sensor ground which returns back to the Prop circuit board.
Funnily, running multiple supply wires is probably amplifying the noise problem. The way you've got it at the moment the motor currents are likely causing ground bounce on the transistors with respect to the Prop. This in turn will be creating an oscillation as the emitter rises up enough to meet the base voltage, turns off, then returns back to normal only to turn straight back on again.
The advise to run separate supplies has a special caveat - The driver control voltage must be able to shift up and down along with the driver's reference. Optocouplers commonly get used to address this situation by allowing the control voltage to be referenced to the driver itself. Relays, of course, easily perform the same isolation function. So relays as per my schematic should work for you.
If you want to use the solid-state h-bridge then adding optocouplers is advised. The alternative is careful layout that involves putting the Prop right at the heart of the motor drive to remove the bounce effects of the high currents.
The diode direction on the H-Bridge is wrong with relation to the motors...
Ouch! Surely that's just a drawing error. He'd have smoke if it was really like that.
... I have not used a back to back zener approach, have you scoped that in action? it might cause inductive ringing. I was thinking something simpler like adding a bridge rectifier to each motor.
No, can't say I have looked. I've never built a motor driver circuit. With my method the clamping voltage is a little higher than rail clamps but the effect on the motor should be the same. Both methods have a sharp clamp effect.
EDIT: Eagle has the standard bridge fitted anyway, so my addition just cosmetic.
EDIT: EDIT: Possibly the biggest issue with using zenors like that is rapid switching, ie: PWM, will destroy the zenor through heat build up. Whereas the bridge regenerates instead.
Oops. i just noticed I did have the diodes facing the wrong way. I drew that really quickly since one of my goals this weekend was to get my kid's go-cart up and running....a bunch of metal fab work later, it runs
I will attempt to redo my h-bridge and get a second ground running from the prop circuit to the NPN transistor. Hopefully this will eliminate my problem or at least make it stop glitching! Off to unsoldering and changing up some things. Will post back with results.
I got one h-bridge done and it was still glitching I came to the conclusion that the 555 timers were outputting pulses and the glitches I am having is mainly due to the frequency changing rapidly while the motors were moving, so I needed more decoupling caps on the light sensor circuit. Five caps later, it appears the glitching has gone to a minimum! The last tests that I did, no glitches happened! I will be redoing the second h-bridge today and testing it out. Hope it has fixed my problem!
The 555's are generating a pulse based on the resistance from a 1m resistor and an led in reverse. That circuit outputs a 5v square wave that is picked up by the prop and used to determine which way to move the solar panels. I am actually using 2 556's, one for east and west, and the other for up and down. This light sensor board is 4 feet from the prop circuit.
I tried using a photocell but the ones I have on hand were no where close to being uniform. The values for the ADC were all over the place even with several decoupling caps. Temperature even changed the reading. I am using SMD 0.1uF caps on the 556's to reduce temperature from changing the frequency. When I was using disc caps, the frequency would change just by holding my finger on the cap for a few seconds.
To use photocells, I would have to have 4 of them that are of equal resistance at the same light level. I have found LED's seem to be best at this and don't peak in resistance even when in full direct sunlight. Maybe the RadioShack photocells are just not accurate enough for what I am doing?
This entire solar tracker system is built from salvaged components, items I have on hand, or a few things from RadioShack since I can stop by there on the way from work. I prefer not to buy things online if I have something here that will work because I am cheap and will go out of my way to make something I have on hand work than buy components that do the same thing.
This sensor will let you read using I2C, You can connect 3 devices on one I2C buss so you would need 2 sets of I2C wires to ready the 4 devices like you are doing now. I2C will be fine for your distances, but shielded wire would help.
That would probably work, but too expensive for me Like I said in my previous post.... "I prefer not to buy things online if I have something here that will work because I am cheap and will go out of my way to make something I have on hand work than buy components that do the same thing."
Ceramic capacitors are known to be variable with both temperature and voltage, eg: Capacitance decreases as the DC voltage increases but not in a linear fashion. Ceramics are cheap and have very wide spectral performance so are used for general noise suppression rather than timing.
If you want stable timing capacitors then use polys/mylars/tantalums.
PS: I like that you have found LEDs to work this way. I can't say I would have even thought of it. It makes sense though, ordinary diodes make for excellent linear temperature sensors.
I commend you on the novel way you used the green LEDs to alter the frequency of a timer, nicely done!
However, some food for thought.
Have you considered eliminating the sun-seeking device and using a time base for moving the the solar panel? In an earlier post you mentioned that the motor(s) turn on nearly every minute, how much energy is that consuming, realizing that motor startups require considerably more energy than running? How much effort are you expending on dealing with all the variables that the sun, sky, clouds, sun dogs, temperature, and silver linings will throw at you?
Consider for a moment, if you will, that the Earth rotates at 15 degrees per hour. Would it not be more efficient to move the panel East to West 5 degrees every 20 minutes rather than have the motor start every minute? I don't think that a 5 degree error in perfect alignment will significantly reduce the panel output. In fact, the constant motor start ups will instead be quite a drain on the system.
I envision a system where every night the panel is moved to the sunrise position, defined by a limit switch. Stored in an EEPROM will be 365 sunrise times and an elevation offset for your location. The sunrise time for the next day will become the alarm time for a real time clock. When the alarm occurs the system will then start counting down a 20 minute timer which will then move the panel 5 degrees to the West, and repeat this throughout the day until the panel encounters the sunset switch. Another table in the EEPROM will hold elevation information for all 20 minute intervals throughout the day and, with the daily elevation offset, adjust the panel elevation every 20 minutes.
This way everything is determined in software. No more dealing with sensor arrays that get rather twitchy if the sun isn't shining brightly all the time or if a bird drops a load on a couple of the sensors. What about large bugs crawling over the sensors? Snow and ice?
All the information you need about the position of the sun at any time on any given day is freely available on the internet.
By the way, how well will that pinion drive for East-West positioning hold up to strong winds? I would think a worm drive would provide better resistance to wind loads.
The code is changeable to allow for motor movement frequency and it works off an "average" of the E/W and U/D pulses. It takes a reading of the difference after X number of loops and puts it into an array. I set how large the array is and that sets the time between changes. I can also change the sample rate as well which will adjust the rate of movement.
The drive for the east and west is actually a worm gear setup now. It is a right angle drive motor that draws ~500mA when running. The gear is a starter gear pressed onto a hollow steel shaft which I drilled out a bit more to fit onto the right angle drive motor. It is held on with a copper pin that will shear in the event it gets under too much stress. It takes a BUNCH of force to shear it, but it protects the motor from being damaged.
This system also has a "Park" mode and a "Wake" mode for night time or stormy days. Since I do get some pretty good winds in my area, the panels need to not be flat against the wind. When the light level is below a certain threshold, the park mode trigger begins a count down and when it has been below the threshold for X number of loops, it moves the panels directly south and lays them almost flat. We very very rarely get hail out here so I think I will be safe in that aspect. For the Wake mode, once the light level goes above the threshold for X amount of time, the panel moves facing east and then relies on the sun to adjust the up and down angle. I may change this to adjust the panels half way between up and down to get a better angle to start from in the morning.
As for the sensor getting dirty... That is part of the maintenance I guess
Using green LED to find were the sun is for mcu-less systems.
With a mcu and a back-up battery I would set time and date and the mcu would track the sun in software based on known angles of the date in question.
No problems with clouds and motor over-compensations etc.
That sounds complicated. I just wanted this thing to point to the sun where it picks up the most light It seems to work quite well with the new modifications to the power filtering / ground isolation. I don't think I will use EEPROM tables to have it track since that is more than I really need. What I have now is way better than just stationary panels.
Maybe in the future I will add something like that, but it will probably be quite awhile for that. I am also out of cogs due to the frequency calculation functions, movement control functions, and average and stop switch reading. May have to do something different for that. This has been an add as I go project. Now that I have everything added, I may be able to go back and redo the code a little better and cleaner.
The strange thing is the motors turn on and off just fine with no noise issue at the time they switch between the states. The strange readings happen while the motors are on for at least 2 to 3 seconds.
My gut feeling is that's RF noise, but I'd be hard pressed to justify it. ceramic 0.1uF across each motor at the terminals, ferrite
toroid over the motor cables at the driver end? Twisted pair in-between.
add some type of RTC, you set the date and then you move stepper motor between the two angles below depending what month it is.
You should also add a table of hour and minute the sunrise starts for each day.
Nashville:
21st December, the sun will rise 73° east of due south and set 73° west of due south.
21st March and 21st September, the sun will rise 91° east of due south and set 91° west of due south.
21st June, the sun will rise 110° east of due south and set 110° west of due south.
None of the motors are steppers. They are either on or off. There are 2 switches on the east to west range that tell when to stop the rotation if it goes too far. When it is time for a motor to turn on, it will turn on until the 2 frequencies match or are greater. It works pretty well I think. I have no way to do a 5 degree rotation unless I add an encoder which is something I would have to buy.
What I said before still applies: you should really first simplify your setup before you make so many wholesale changes. As your first post pointed out, the problem is when the motors are simply running; therefore your choice of bridge has little or no influence on the noise you are seeing. I lost track of what circuit you're actually using, but if you isolate the power supplies between the motors and the Propeller that usually resolves this kind of issue.
Personally, I'd invest a dollar in a 2-channel optoisolator IC, and use that to connect either a solid state or relay H-bridge. Used this way you do not need to share any grounds. Power your motors from one battery, your Prop from a wall wart or other supply.
Essentially you replace the two transistors in your circuit in post 42 with the opto isolators. You should be sure to use the small caps across the motor terminals as noted in previous posts. They can't hurt, but currently you may have so much noise from your motors they don't appear to be doing anything.
If your problem is RF noise -- that is noise going through the air and picked up by the wiring acting as antennas -- that's a lot harder to correct without rebuilding your whole system. So avoid that for now until you first try the simpler task of separating your motors and logic.
Comments
The light sensor wire is a standard Cat5 cable for networking. I don't think it is shielded and I don't think the noise is coming from that since even with the light sensor disconnected from the Prop's circuit, it still picks up noise. I think this is a ground isolation issue.
The second motor does not have the delta configuration and I am not turning it on during testing. I am only using the Up/down motor.
@T Chap : I do have a hand held O-Scope and was able to figure where some noise was coming from which was found at the output of the prop to the H-Bridge.
More likely that noise is from the H bridge and motor than from the Prop
That said, using separate V+ for your electronics and motors, and then small/inexpensive optoisolators, will nearly always remove any noise carried via wiring. Little or no engineering has to go into it. It's often the easiest way to handle this situation if you not familiar with dealing with motor noise, and as you've found the trial and error method isn't very effective. Any glitches left are being radiated out, and there, things like distance, twisted motor wires, and a few other low-tech things are the simplest fixes.
Funnily, running multiple supply wires is probably amplifying the noise problem. The way you've got it at the moment the motor currents are likely causing ground bounce on the transistors with respect to the Prop. This in turn will be creating an oscillation as the emitter rises up enough to meet the base voltage, turns off, then returns back to normal only to turn straight back on again.
The advise to run separate supplies has a special caveat - The driver control voltage must be able to shift up and down along with the driver's reference. Optocouplers commonly get used to address this situation by allowing the control voltage to be referenced to the driver itself. Relays, of course, easily perform the same isolation function. So relays as per my schematic should work for you.
If you want to use the solid-state h-bridge then adding optocouplers is advised. The alternative is careful layout that involves putting the Prop right at the heart of the motor drive to remove the bounce effects of the high currents.
Move the coil/transistor section over to the Prop supply and you'll be away and racing.
No, can't say I have looked. I've never built a motor driver circuit. With my method the clamping voltage is a little higher than rail clamps but the effect on the motor should be the same. Both methods have a sharp clamp effect.
EDIT: Eagle has the standard bridge fitted anyway, so my addition just cosmetic.
EDIT: EDIT: Possibly the biggest issue with using zenors like that is rapid switching, ie: PWM, will destroy the zenor through heat build up. Whereas the bridge regenerates instead.
I will attempt to redo my h-bridge and get a second ground running from the prop circuit to the NPN transistor. Hopefully this will eliminate my problem or at least make it stop glitching! Off to unsoldering and changing up some things. Will post back with results.
To use photocells, I would have to have 4 of them that are of equal resistance at the same light level. I have found LED's seem to be best at this and don't peak in resistance even when in full direct sunlight. Maybe the RadioShack photocells are just not accurate enough for what I am doing?
This entire solar tracker system is built from salvaged components, items I have on hand, or a few things from RadioShack since I can stop by there on the way from work. I prefer not to buy things online if I have something here that will work because I am cheap and will go out of my way to make something I have on hand work than buy components that do the same thing.
This sensor will let you read using I2C, You can connect 3 devices on one I2C buss so you would need 2 sets of I2C wires to ready the 4 devices like you are doing now. I2C will be fine for your distances, but shielded wire would help.
If you want stable timing capacitors then use polys/mylars/tantalums.
PS: I like that you have found LEDs to work this way. I can't say I would have even thought of it. It makes sense though, ordinary diodes make for excellent linear temperature sensors.
However, some food for thought.
Have you considered eliminating the sun-seeking device and using a time base for moving the the solar panel? In an earlier post you mentioned that the motor(s) turn on nearly every minute, how much energy is that consuming, realizing that motor startups require considerably more energy than running? How much effort are you expending on dealing with all the variables that the sun, sky, clouds, sun dogs, temperature, and silver linings will throw at you?
Consider for a moment, if you will, that the Earth rotates at 15 degrees per hour. Would it not be more efficient to move the panel East to West 5 degrees every 20 minutes rather than have the motor start every minute? I don't think that a 5 degree error in perfect alignment will significantly reduce the panel output. In fact, the constant motor start ups will instead be quite a drain on the system.
I envision a system where every night the panel is moved to the sunrise position, defined by a limit switch. Stored in an EEPROM will be 365 sunrise times and an elevation offset for your location. The sunrise time for the next day will become the alarm time for a real time clock. When the alarm occurs the system will then start counting down a 20 minute timer which will then move the panel 5 degrees to the West, and repeat this throughout the day until the panel encounters the sunset switch. Another table in the EEPROM will hold elevation information for all 20 minute intervals throughout the day and, with the daily elevation offset, adjust the panel elevation every 20 minutes.
This way everything is determined in software. No more dealing with sensor arrays that get rather twitchy if the sun isn't shining brightly all the time or if a bird drops a load on a couple of the sensors. What about large bugs crawling over the sensors? Snow and ice?
All the information you need about the position of the sun at any time on any given day is freely available on the internet.
By the way, how well will that pinion drive for East-West positioning hold up to strong winds? I would think a worm drive would provide better resistance to wind loads.
Just my two cents worth.
Hal
The drive for the east and west is actually a worm gear setup now. It is a right angle drive motor that draws ~500mA when running. The gear is a starter gear pressed onto a hollow steel shaft which I drilled out a bit more to fit onto the right angle drive motor. It is held on with a copper pin that will shear in the event it gets under too much stress. It takes a BUNCH of force to shear it, but it protects the motor from being damaged.
This system also has a "Park" mode and a "Wake" mode for night time or stormy days. Since I do get some pretty good winds in my area, the panels need to not be flat against the wind. When the light level is below a certain threshold, the park mode trigger begins a count down and when it has been below the threshold for X number of loops, it moves the panels directly south and lays them almost flat. We very very rarely get hail out here so I think I will be safe in that aspect. For the Wake mode, once the light level goes above the threshold for X amount of time, the panel moves facing east and then relies on the sun to adjust the up and down angle. I may change this to adjust the panels half way between up and down to get a better angle to start from in the morning.
As for the sensor getting dirty... That is part of the maintenance I guess
With a mcu and a back-up battery I would set time and date and the mcu would track the sun in software based on known angles of the date in question.
No problems with clouds and motor over-compensations etc.
Maybe in the future I will add something like that, but it will probably be quite awhile for that. I am also out of cogs due to the frequency calculation functions, movement control functions, and average and stop switch reading. May have to do something different for that. This has been an add as I go project. Now that I have everything added, I may be able to go back and redo the code a little better and cleaner.
My gut feeling is that's RF noise, but I'd be hard pressed to justify it. ceramic 0.1uF across each motor at the terminals, ferrite
toroid over the motor cables at the driver end? Twisted pair in-between.
You should also add a table of hour and minute the sunrise starts for each day.
Nashville:
21st December, the sun will rise 73° east of due south and set 73° west of due south.
21st March and 21st September, the sun will rise 91° east of due south and set 91° west of due south.
21st June, the sun will rise 110° east of due south and set 110° west of due south.
Personally, I'd invest a dollar in a 2-channel optoisolator IC, and use that to connect either a solid state or relay H-bridge. Used this way you do not need to share any grounds. Power your motors from one battery, your Prop from a wall wart or other supply.
Essentially you replace the two transistors in your circuit in post 42 with the opto isolators. You should be sure to use the small caps across the motor terminals as noted in previous posts. They can't hurt, but currently you may have so much noise from your motors they don't appear to be doing anything.
If your problem is RF noise -- that is noise going through the air and picked up by the wiring acting as antennas -- that's a lot harder to correct without rebuilding your whole system. So avoid that for now until you first try the simpler task of separating your motors and logic.