Barndoor Tracking Mount Part 4

I have been having some problems with the stepper motor and the Sparkfun stepper driver and have finally gotten it all straightened out. The motor was having periods when it would sputter, misstep, and sometimes not even run at all. I finally reached the conclusion that the motor or the controller was bad. Since the motor was from surplus, I decided to replace it. It was not very expensive and I was able to find an exact replacement online so I did it. The new one seemed to work better, for a while, but then I started having similar problems. I was looking into replacing the controller but, in doing this, I found some documentation on the board that I had not seen before. In the margin notes, I found the recommendation that some of the inputs that were not being used in control be either connected to ground on Vcc (+5vdc). The ones that were listed included one to put the controller to sleep and another that was a reset. The third was called PFD and I did not examine its function closely but, I had not seen anything in the sample hookup documentation about these pins. However, I tied all three to Vcc and now everything is working fine.

Now I have a nearly completed mount. I just have to put on the part that will hold the camera and I will be ready for some field testing. However, first some more bench testing was in order. I attached a limit switch to allow the door to have a seekable home position. This ties to one of the Arduino inputs and, by doing a little testing. I found this to be a highly repeatable location even though the button I used seemed to have a lot of play to it. A second button was attached to be a command switch. The command button switches the program between the different modes: STANDBY, which is the default start mode and where the controller is just waiting for input, RETRACT, where the door is seeking the home position, READY, where the door is home and waiting to start tracking, and TRACKING mode.

After installing the home position switch, I had to repeat some of my measurements to determine the lead screw leg distance for the home position (see the last installment to see where this measurement is used in the calculations). I then went back and ran the test to measure the angles of individual steps that should each open the door in one degree increments. I got much better measurements, although still not as perfect as I would expect. More testing and measuring might be in order.

Next, I created a test for the command button. The button throws an interrupt to the Arduino board. This sets a flag that is then detected and reset in the program. Everything checked out fine so I incorporated the command button into the final Barndoor program and implemented each of the modes of operation. Finally, I was able to run the door through its paces. The flowchart follows. Click on it for a bigger view.

Next, I will have to finish up the packaging for moving to the field. I think I will mount the circuitry on the bottom of the mount and then route the cabling so it does not get snagged. I will likely also mount the lighting where it is easily viewable. My power supply for the field will be an automotive jump starter and tire inflator which has both a USB power port and a 12V power port. The USB port will power the Arduino through its USB port and 12V will power the stepping motor circuit. I have already tested the door using this power source and it is robust enough for use in the field.

Barndoor Tracking Mount Part 3

So I had to back up on something I posted last time. I showed the stepper motor with an 8mm screw and two intervening shaft couplers. Well, after ruminating on it a bit I realized that the shaft coupler that was flexible would not work with my design. I needed one that was ridged, otherwise too much play would be added into the system and accuracy would suffer. I knew that the motor shaft is 1/4 inch and the lead screw is 8mm so I looked for a coupler that would match those sizes and, surprise, there is such a thing. $6 later I have one. So now I was ready to start building the mount. The two “doors” are 3/4 inch oak and there are three hinged areas that hold the two doors together and also allow the motor and lead screw nut to stay aligned as the door is opened and closed. I showed a picture of this design in the last post so I took to building. The RV resort where we live in the winter has a nice woodworking shop so I had everything I needed.

I started cutting and shaping and, with a couple of restarts due to misplaced components and the purchase of another piece of wood to make the hinges, I was able in a few days to have put together the mount. Here are some pictures of the components and the final assembly.

Next came a test of this set up. I created a program for the Arduino to move the door in one degree increments from the closed position to the maximum open position. I immediately found a problem. Measurements showed it to be opening too far, about 1.3 degrees per increment. I did some modeling of my code in an Excel spreadsheet and it looked good. After some more testing I finally discovered that the lead screw, which I could have sworn was a three-start thread, was actually a four-start thread. This meant that instead of moving 6mm per revolution, it was really moving 8mm per revolution. This made a big difference and I was able to just change a variable in the program to correct it.

I forgot to mention that a crucial part of getting the door to open correctly was making accurate measurements of the finished device. I need to know the exact dimensions from the main door hinge center to the motor block hinge and the lead screw nut hinge. I also need to know the distance from the lead screw hinge center to the center of the screw and the same from the motor hinge to the center of the motor shaft. With all of those dimensions I can there create a formula that gives me the angle between the two door halves and can compute how far the lead screw nut has to be pushed out to open that angle by a specific amount. The same formula then can be used to determine the rate at which to step the motor to get the door to match the sidereal angle of the earth.

Now, examine this diagram:

If the vertex of a-b is the main door hinge, the vertex of a-c is the lead screw nut hinge, and the vertex of b-c is the hinge of the motor block, then the angle C is defined by the formula:

So “a” and “b” are measured constants and “c” is variable as the lead screw moves. However, the screw does not pass thru these points so there is another formula to find “c” for different steps on the lead screw. The geometry of the lead screw with respect to “c” is described in the following diagram and formula:

The lead screw nut (“n”) leg and the motor base (“m”) leg are always at right angles to the lead screw (“L”). Note: this is the reason the flexible motor shaft coupler was not appropriate. So the Pythagorean Theorem is used to determine the length of “c” depending on the position of the nut on the lead screw. By combining these two formulas the angle “C” can be determined for any particular step of the motor and can be matched then to the sidereal angle of the earth starting at the home or closed position of the door.

Next, I have to attach a switch to mark the home position and program the tracking algorithm for the Arduino. More on that in the next installment.

Barndoor Tracking Mount Part 2

Ok, the lead screw and nut I ordered has arrived. The good news is it looks like it will work just fine for what I am doing although the shaft connector that came with it to go from the 8 mm shaft to the motor is too small for the motor, which has a 1/4 inch shaft. But, the shaft coupler I already had for the old lead screw is just the right size to match up with the other coupler so, with a cut off 3/16 inch screw, I was able to get it all together.

The screw turns out to have 3 starts and a 2mm pitch which results in 6mm travel per revolution. I will probably drive it in 1/4 steps from the EasyDriver so it will result in 800 steps per rev and so 0.0075mm per step. The step interval should be around 300 milliseconds, depending on what the actual final dimensions of the door are.

I should now be able to begin fabricating the door itself. I have a piece of 3/4 inch oak for that purpose. The working drawing is below. I will hinge the door on one side and will also hinge both the nut on the top and the motor on the bottom. I believe I have the formulas worked out correctly to compute the step interval to get it to follow the sidereal angle of the earth. I will do some testing after I have the structure built to see how accurate I am. The final proof will of course be in the pictures I take.

Barndoor Tracking Mount, Part 1

So in my last post, I mentioned I was going to build this DIY equatorial mount for photography and general viewing of the skies. I am using an Arduino UNO board as the controller for the device, which will drive a stepper motor to open and close the “door”. I purchased an EasyDriver card to interface between the Arduino and the stepper motor. I attached it to a shield card I already had for prototyping with the UNO and brought power and motor connections out to pins. The power for the motor and the Arduino will both come from a car starter/air compressor that has a 12VDC auxiliary port. The stepper motor came for the surplus house I mentioned before and is by Oriental Motor in Japan. So far, I have gotten all three parts connected together and have run the motor through some operations that show that I should be able to do the job with it.

I had also obtained a lead screw at the surplus store but have not been able to find a source for a lead screw nut to travel on it. The best source I could find for parts like I want to use for driving the door is parts that are designed for 3D printers. I took a chance and ordered some parts that should be able to work and they should arrive in the next week or two, so I should know how they will work when I write the next installment.

I will probably fabricate the hinging parts for the door since standard hinges may have too much play for the stability I will want. I think I can make some fairly accurate parts in the wood shop we have here, where I can use a drill press to make some nice, tight parts using wood and metal. The base door parts will be made with oak for a nice, hard surface and I have an old, sturdy tripod that should be able to hold the whole apparatus securely.

I have been running some spreadsheets looking at the calculation of the stepping timing for the door to make it match the sidereal angle of the earth. The geometry of the device determines that the speed of the stepping motor needs to vary as the door opens so as to maintain a constant platform. A formula can be easily derived for the stepping frequency and other implementations I have read about have used formulas and tables to minimize the error in the angle. However, I have come to realize that the computational speed of the Arduino processor is fast enough to be able to compute the next step interval well before the interval needs to occur, so accuracy should not be a problem assuming that my formula is correct and that I accurately position the device lined up on Polaris.

Next time I will show you the geometry of the device I am building, the formula I am using to determine the step intervals and, hopefully will know if the hardware I am getting for the stepper will work. Then I can get busy fabricating the platform

Back Again

It has been a long time since I have posted here. Sorry but life has had other things for me to do. However, I have been playing around with Arduino microcontrollers for a while and have just found a new application.

With the All American Solar Eclipse coming next August 21st, I have started thinking about filming it and have also been interested in filming other astral phenomena so I figure building a polar axis tracker for my camera and telescope needs might be interesting.

I found a design for a DIY Polar Axis Tracker based on the Barn Door design and started looking into the math used to determine how to drive it and the hardware. I was in Portland Oregon this passed Summer and was directed to Surplus Gizmos by my son. They have all kinds of electronic, electric and mechanical hardware for sale.

I was able to get a couple of stepper motors (which may or may not work), a lead screw with an 0.1 inch pitch and a 3/8 inch diameter. These were my first pieces of hardware for the device.

Let me drop back a little and describe the device. A Barn Door Tracker is essentially two pieces of wood with a hinge connecting them. The hinge allows the two parts to swing through an angle as a barn door might when it is opened with respect to the door frame. By anchoring one side of the door to a tripod as a “ground” plane and then moving the other side at a controlled rate, the moving side will remain relatively fixed from a cosmic standpoint as the other side moves through an arc as the earth turns below it.

So the trick is to make the “door” open at a rate consistent with the rotation of the earth (360 degrees in 23.9344696 hours). I will be posting the steps I go through here to make this thing work so stay tuned.

Notes on Arduino Programming

I recently had an epiphany regarding programming the Arduino (see my previous post "The Automenorah Quest" regarding my use of the Arduino board). The first board I acquired used the older Atmel Atmega168 chip, which has 16K of program RAM and 1K of SRAM for variables. I knew that, but did not take into account how little space I had available for modifiable variables, especially for strings. In my programming trials using this platform, I would have some unexpected problems, usually when I was trying to display information through the serial monitor, usually for debugging purposes. The symptom was that suddenly, after adding some new information to be displayed, the display would show gibberish, or at least would display some characters incorrectly. In the most extreme cases, the program would appear to totally fail. I was unable to get it to happen reliably enough to figure out the cause and spent some time doing different trials to try and figure it out.

Eventually, I acquired a new board which had the newer Atmega328, with 32K of program space and 2K of SRAM. This board did not have the same problems with the same code sketches. I finally purchased a new 328 chip for the old board and the problems with that board seemed to be solved.

It was not until recently that the epiphany occurred and it dawned on me that the differences in SRAM were the reason for the failures. As I added more and more character strings to the variables to be displayed on the serial monitor, the failure would eventually happen. I was overrunning the SRAM space with the string variables and causing the crashes. I went looking for information on this and found the method for causing character strings, or any variables, which do not require run-time modification, to be stored in the program space and the code for fetching these variables at run-time.

This solved a whole lot of problems I had been having. Interested parties can find more on the solution here.

The Automenorah Quest

Well, it has been a long time but I have been doing some traveling. Lately, I returned to an electronics project I had been away from for a while and, well, things took off. I want to document my experience so I an posting here. Not sure if anyone will ever read this but I want to get it down while things are fresh in my mind. Also, this project has been running through my mind for a while like an ear-worm and hopefully this will get it out and onto (virtual) paper so I can concentrate on other things.

So this started many years ago when we were still living in a stick-built house in Connecticut (for the record we have been full-time RVers since 2009 and now have a vacation home in Sarasota Florida as our only residence other than the motorhome we still own). Back then, during the Jewish festival of Hannukah, we would be out fo the house until after sundown and, in celebration, would put an electric Menorah in our front window (it has nine lights on it and the lights are lit one per night plus one that is always lit, to commemorate the eight days of the festival). We would put the Menorah on a timer and would loosen all but the lights to be lit for the specific night so that the right number would come on and shine starting at sundown.

This worked well enough, but we always had to remember to tighten another light down each evening after the Menorah turned off (with the timer) or in the morning before leaving for the day. As an electrical engineer and as avid electronic hobbyist, I realized there may be a better, automatic way to get the lights to come on in order at the right times. Thus began my quest for the "Automenorah".

I sat down and started doing a little designing and realized several things. First, I would need a stable, fairly accurate timing pulse. One based on the 60 Hertz signal in household current might work, if I reduced the voltage, rectified it, and generated a square wave from it to give me a 60/second clock. Also, I would need to have a way to control lights operating on household current with a logic circuit. I considered some sort of FET circuit or perhaps a relay circuit. Besides those hurdles, I had to design the logic circuit which would turn the lights on in the right order and off at the end of the festival and turn them on and off at the right times as well.

My vision was a fairly simple design, where the menorah would be placed on a timer to come on with a single candle lit at sundown on the first night of the festival and then the timing circuit would turn all fo the lights off a few hours later and turn on more lights each night 24 hours after the first lighting, adding to the number of lights, until the end of the festival, when all would be turned off and not come on again. A simple switch could be used to adjust the length of time the lights stayed on and a push button could be used to light more lights as necessary (in case the menorah was plugged in later in the festival than the first night). My initial designs were based on discrete logic circuits (NAND, NOR, counters, shift registers, etc.) and was proceeding but nothing of substance was being completed.

At one point I showed what I was working on to my youngest son, who was studying computer engineering in college, and he asked if I had considered replacing all of my discrete logic with a programmable microcontroller. I said no and asked him for some suggestions (this shows how long I had been out of engineering, since I had not looked into them to see what might be available, how they worked, or how to use them). He put me onto the ATMEL line and I purchased a few ATMEGA32 controllers for some experimentation. It was eye opening and fun to be going down this new path. One thing it did was allow me to solve the timing aspect because the microcontroller uses a crystal controlled signal generator for its internal processing needs and all the timing I needed could be performed in software.

Eventually I was able to create working automenorah based on this microcontroller. It used a small power supply and digitally controlled reed switches to direct line current to the lights. It worked using my original design except that it was hardcoded to be on for 7 hours. This worked well but eventually I was able to find LED lights that I liked instead of the 120V lights. I also found some discounted electric menorahs on sale after the holiday and bought up two of them. I went to work on one modifying it to fit the LED lights and to also individually wire each light (except the Shamus, which was wired to light #1. They are always on together). I had also found the Arduino line of microcontroller boards, which have an on-board programmer and plug right into the computer USB port. This made programming much simpler because I did not have to mount the microcontroller chip in a different place to program and then move it to the circuit board for testing.

The Arduino board allowed me to build everything on a separate board and then plug it into the Arduino for operation. Programming is written in C++ and the USB connection allows for printing information back to the computer for debugging purposes. I was also able to program in the length of lights-on time and make changes as I desired. This was good and I set out this year to create a second one (mainly because I had kind of haked up the menorah to mount the lights and wanted to see if I could start over and do a better job of modifying the lights. I also found some new LED lights I wanted to use).

As I was working on this new menorah, I discovered a real-time clock circuit based on the DS3231RTC chip that could be used with the Arduino board. I did some experimenting with one and liked the results. This allowed me to modify the program to use real time keeping to determine lights on and lights off times. Once I had that capability, I though "why not program in a perpetual calendar so the menorah will always know when Hannukah starts from one year to the next"? Before this, I had hardcoded 12 years of Hannukah starting dates. Once I had a Hebrew calendar built into the code, I realized I could add another feature to the menorah to make it double as a 7-candle menorah to mark Shabbat. I had the day of the week available from the clock so this was somewhat trivial. However, this meant I had to make the menorah work around the calendar year, not only within the narrow time frame of Hannukah (which is right around the solstice and sunset does not change significantly from day to day.

So the next hurdle was finding code to compute sunset times. This worked out pretty well, but I also had to add code to adjust around the calendar for daylight saving time. The DS3231RTC does not have this capability. I was able to generate some code myself to detect when DST is in effect and adjust the sunset times accordingly around the calendar year.I had also found that the ATMEGA chip used on the Arduino boards had EEPROM built in. I was able then to store flags to indicate whether DST was in effect and whether to light the menorah on Shabbat or not. Sunset time is computed and the lights-off time is stored in one of the alarm locations on the DS3231RTC chip.

The code had grown to the point where it would no longer fit on the older Arduino board I had, which used the atmega168 chip. Also, this card had a problem with its serial printing capability that made it miss print when trying to generate long lines of print out (I am doing that with the automenorah code so as to monitor the RTC clock settings and the lights-on/off times). I was just going to give up on that card and had purchased two newer cards for use in future projects, but then I thought of perhaps buying just a new atmega328 chip to replace the older chip on the board. This fixed the serial print problem and also gave me enough storage on the board to go ahead and use it in the older automenorah it was in previously (with all the new code including the Shabbat code after I modified the wiring to divorce the Shamus light from light #1, since they are not used together in Shabbat mode).

I am happy with how this project has turned out. I am considering building two more and sending them to my sons for their use. The only difference I will have to make in their's is the hardcoded latitude, longitude and time zone in the code used to compute the sunset times. The only way I could get away with eliminating this would be to embed a GPS chip (which would be possible except for making sure the antenna could find the satellites) but this might be a bit of overkill. As it is, mine are coded for Sarasota, FL and their's would have to be set for Boston, MA and Portland, OR.