2/23/16, PEC:
Here's another image to help clarify what OnStep's PEC playback performance looks like. The blue line is playback rate data captured from the Mega2560 OnStep RA step pin. The red line is graphed from OnStep's PEC buffer (data intended to be played back.) The images are stretched to a matching scale (vertical +/-15 arc-sec, horizontal 0 to 45 seconds.)



I did some more testing of the -Alpha's PEC today. I have a separate Teensy3.1 with monitoring firmware that counts RA axis steps taken (step/dir) and acts like a PEC index too. It even measures the timing of the step pulses to keep track of the exact rate that OnStep (running on a Mega2560) is running the RA drive at. You can see PEC working in the attached image. You'll possible need to download/open it up to see the figures. In the image the data at the right (arcsec/sec) shows what the Teensy3.1 detected happening at the step pin of the Mega2560. The index detect happened at the top and about the first 46 seconds of playback (1 sec/line) are shown with the most current reading at the bottom. The graph playback started at the left and the vertical red line is a bit less than 1/4 (46 sec) of the way through the worm-cycle. If you start at the right-hand data top "arc/sec" and work your way down you'll see the agreement with the first part of the PEC curve in the graph. The correspondence of the figures is very strong evidence for PEC working properly. For example, the top 3 readings are 2.266 and 5.663 and 1.417 = 9.3 arc-sec over the first 3 seconds. The first peak is of similar magnitude and time. The curve then drops for 12 seconds by about -24.3" which leaves us at -15.0", etc.




12/7/15, Tracking/Timing:
This shows what the step pulses from OnStep look like while running on a Mega2560, on a Teensy3.x these would be square waves (RA sidereal tracking and Dec doing a slow guide.) Notice the precise timing between the about 10Hz and 15Hz step pulses.




12/6/14, G11 Guided performance:
I finally got around to putting a guide-scope on my 10" Newtonian. I used an old Stellarvue AT1010 with my Meade DSI Pro camera. The screen shot below shows OnStep's PHD2 guiding performance in pixels. This 'scope/camera combination is about 4.1 arc-sec/px in RA x 3.2 arc-sec/px in Dec. So, the stats shown below work out to about 0.66 arc-secs RMS for RA and 0.51 arc-secs RMS for DEC (Tot=0.83 arc-secs RMS.) Also, GPS PPS and refraction rate tracking (both new features) were enabled and guiding was still performing well. I believe a slight tracking rate issue might exist and I'll need to take a look at that. Possibly, better results could be had by backing off of the aggressiveness since I seem to be seeing limited:



And here's a center crop of an stack of eight one minute exposures captured while the above guiding was in progress. No registration, just stacked, so tracking errors are evident just as if this were a single exposure. E/W is vertical and this is at 1.8 arc-sec/px...




11/1/14, G11 Alignment:
One final round of testing, the G11 mount in my obs. is very accurately polar aligned and did a three star align (with my Android cell phone/Hand Controller App.) Again correcting for four geometrical effects. This location has lots of sky, except to the North-East mostly. About 30 gotos were done over as much sky as possible (some images were blocked by trees/etc.), maximum error was about 6'. Close enough to put most objects near the center of an 8mm eyepiece (w/my 10" F/4 scope.) The collage below is composed of exact center crops about 50 arc-min sq. (similar to a mid to low power eyepiece fov), these images were automatically sequenced by Sky Planetarium and gathering the data took about a fourty minutes. The gotos were all blind, no plate-solving or manual centering. Still better pointing performace is available in Sky Planetarium (Goto Assist) which models additional effects and can use many more alignment stars.



10/16/14, Alignment:
For this round of testing I polar aligned the mount moderately well and did a three star align. Again correcting for four geometrical effects. My values for DO/PD were both about 1/2 of what they were before, probably due to a combination of the prior large polar misalignment and not being exactly on the celestial equator/meridian/etc. during the align - the closer the better.
This shows that my moderately well aligned mount will now place objects in the center of mid to low power eyepieces. Everything would have been, essentially, in the center of a dslr chip and most were closer to the center than the edges of the little Meade DSI-II CCD. I say good enough for now.

The results:
PE=-00*03:53# (4' below the pole)
PZ=-00*02:14# (2' to the right)
DO=+00*11:52#
PD=+00*06:17#

Again over as much sky as I can from my testing location (min. Altitude is about 30° except S/SW which is worse.)
In minutes, the greater of RA or Dec offset for each target:
1', 1.5', 10', 2'
(Meridian Flip)
2', 2', 1.5', 1', 5', 8'


10/10/14, Alignment:
For this round of testing I misaligned the mount to the right of the pole (instead of above), by about the same amount as before, and did an align on all three stars. I'm now trying to correct for four geometrical effects. Two for polar misalignment and two for mount geometry.

The results:
PE=-00*04:01# (4' below the pole)
PZ=-00*57:01# (57' to the right)
DO=+00*20:59#
PD=+00*12:12#

After the align I did about eight goto's, four on each side of the Meridian over as much sky as possible from my fairly well obstructed location. Max pointing error was +/-15', average was around +/-8'. Not quite as good as I was hoping for, but I had the polar/declination axis correction term incorrectly applied (now fixed, wasn't negated on meridian flip.) The largest errors were in RA, which is consistant with the PD term being misapplied. With just a one-star align, and the mount this far off the pole, pointing errors would have been about 3x as bad. I used a CCD camera during testing, but if a low-power eyepiece had been used all stars would have been in the middle 1/4 of the FOV.

10/09/14, Alignment:
Three-star align is coded but untested with real stars. The method used should attempt to correct for polar misalignment and cone error along with Dec/RA axis non-orthogonality. I'm optamistic about this working, the Polar Elevation correction code really seems to work well and gives me consistantly accurate estimates of my intentional polar misalignment.

10/07/14, Performance:
I recently made many changes to speed up OnStep, but I suspect that changes to alignment related code had slowed it down once again. So I made changes to the GetEqu() function that now allow it to return recent values instead of doing the calculations each and every time. During gotos this limits the frequency that the underlying (resource intensive) code runs to once a second. This cuts the workload in half as Sky Planetarium polls the RA and Dec. seperately to update the telescope position on the map. This change is even better for other software that polls faster since it imposes a limit on how much processing is spent on this task. Still, after much testing 24-28uS MaxRate has problems once in a while so it looks like 32uS is as fast as the Mega2560 version will go.

10/06/14, Alignment:
Had my first successful test of two star align tonight. First I polar aligned the mount and visual estimated it at 1°24' above the pole. The first two star align didn't work, but with recently added code I was able to see what's going wrong inside the controller (it showed 1°20' below the pole) and made a small change. Then, I did another two star align and OnStep reported 1°19' above the pole (a good sign) and was on the target star. Once aligned I did a goto to the other side of the sky (meridian flip) and the star was on the edge of the fov (29'x23' ccd fov.) Several additional gotos all found their stars, not bad for a seriously poor polar alignment!

9/19/14 (progress update 10/6), OnStep Refinement and Testing leading up to version 1:
1. Operation beneath the celestial pole✔.
2. Two and three star align. The two✔ and three star align works (hopefully) by using the alignment stars to determine how far the 'scope's RA axis is displaced from the pole and doing some spherical coordinate conversion to compensate for it. I plan to deliberately offset the polar axis by a known amount, first in azimuth and then only in altitude and compare what the calibration routine comes up with vs. reality. I need to update the hand-controller's method of selecting alignment stars too before I start this, it's not really correct. Should pick a star East of meridian overhead, then West overhead, then one in the southern sky near the meridian. (see my notes http://www.stellarjourney.com/index.php?r=site/software_telescope.)
The above apply to the Stable and Dev branch on GitHub.
3. Confirm tracking✔, guiding✔, PEC✔ work as expected in my experimental version, it has big changes that are not yet on GitHub. These changes reduce the motor step timing jitter during tracking, guiding, and PEC playback. The benefits probably run from very slight to none at all and I really debated on whether to bother.
4. Confirm that safety code works, stops tracking at MinutesPastMeridian Limit✔, stops tracking at Horizon Limit✔, stops tracking at Overhead Limit✔.
Applies to the Dev branch on GitHub.
5. Try to do some basic testing to determine how it operates in southern Latitudes. I could pretend that I'm at 40S instead of 40N... set my Latitude to a negative... Kick it around in my Planetarium program to make sure it operates as expected✔. If I get my 'scope polar aligned (on Polaris) then reverse the position to point at the SCP I think it should be almost like being in Santiago Chile for example (vs. Philadelphia, PA.) Then do an align with a star near the celestial equator and see how Goto's and meridian flips behave.
Above applies to my Experimental branch (not on GitHub.)
[✔Operation under the pole only partially worked. Meridian flipping problems and index offset declination (ID) problems are now fixed.]
[✔Two star align didn't work as-is. Fixed and initial testing looked promising (see above.)]
[✔Tracking was wonderfully accurate on recent 2 and 3 minute images on the G11 mount]
[✔Guiding looked nice on the bench and the Tak em10b autoguides nicely]
[✔PEC was broken at first, issue was with resuming PEC playback and has been fixed. Tak em10b went from +/-16 to +/-8 arc-sec.]
[✔Meridian limits worked, horizon and overhead limits were broken due to bugs in the on-the-fly altitude calc routine. This is fixed and all work now.]
[✔Southern latitude operation looks ok in my planetarium program.]

1/10/14, New design performance at 24VDC:
I revisited these tests, but with serial communications code replaced with a faster design and 16uS* is now stable with just a little vibration. 12us* would be pushing it a bit but is probably doable.
*= more like 24uS with the current design (10/1/14) and both motors running at full speed (the Teensy3.1 is good for 12-16uS now most likely.)

12/11/13, New design performance at 24VDC:
I revisited these tests with the same stepper motor/setup at 24VDC instead of 12VDC. Again, goto rates listed are based on my G11 at 11520 steps/deg.:
20uS: OnStep seems stable. 4.5 deg./sec. speed. Stepper running at 937 RPM. Serial comms interrupts create noticable vibration of motor.
16uS: Some OnStep problems. 5.4 deg./sec. speed. Stepper running at 1171 RPM. Serial comms interrupts too severe to run without disconnecting. Motor vibration more noticable in general, probably due to timing jitter from the ISRs competing for time on the MPU.

I'd say that 24uS is about the limit of the new design as-is. Mainly due to the Serial comms jitter problem, this is almost certainly fixable by writting my own polling serial communication routines. Another way around this would be to switch from 16X microstepping to 8X or 4X on-the-fly during GoTo's. Still, this is a hugh improvement as is and just about good enough that it doesn't even matter at this point. I'll exercise the design and get the bugs out, this will be release 1.0a1

11/26/13, Performance Part II:
I solved most, if not all, of the bugs so I tested the new design's performance. "MaxRate" is no longer used so the motors step each time the ISRs are called, instead of every 2nd, 3rd, or 4th time. I expect OnStep to function properly at 10 or 12uS rates, since it's still responsive to commands at 8uS rates (I didn't test faster.) It now seems fast enough that with the right motors/voltages I should be able to use higher ratio gears to track more smoothly and still slew fast since the range of speeds is so great. I need to add in the backlash compensation code again and that might slow it down a bit, probably not enough to notice. These are my observations (while 16x micro-stepping with a Sanyo NEMA17 hybrid stepper) other settings are the same as I use on my G11. The goto rates are based on my G11 at 11520 steps/deg:
24uS: OnStep seems stable. 3.6 deg./sec. speed. Motor runs very fast (781 RPM), acceleration was very smooth.
16uS: OnStep seems stable. 5.4 deg./sec. speed. Motor stalls. Command processing still looks fine.
8uS : OnStep seems stable. 10.8 deg./sec. speed. Motor stalls. Command processing still looks fine.

11/22/13, OnStep improvements:
I made the first attempt at redesigning OnStep to enable higher speed operation. I kept the interrupt Timer1 for sidereal time keeping (only.) Timer3 and Timer4 now handle the HA and Dec axis (Mega2560 only). The rate these timers operate at is now programmed on-the-fly and I can achieve a more precise control of the step-rate at high-speed to overcome the sudden accelleration problem that OnStep had. This technique also has an advantage in that the ISR processing load is at it's worst when OnStep isn't doing timing critical tasks in the main loop. Still buggy, but my initial impression is that it will be an more elegant and powerful technique to control the steppers. My speed increments are based on the clock-rate at 0.062uS instead of about 16-32uS as previously implemented. Just how fast it should go gets complicated and I'll need to test to really know. But, I believe this should pave the way for a 4-6x speed increase (with the right motors) which is getting fast enough to have both fine 1/8 or 3/16 arc-second steps when tracking and multi-deg/second goto's.

11/22/13, Performance:
I tested high speed operation by setting the InterruptRate to various values (while 16x micro-stepping with a Sanyo NEMA17 hybrid stepper) other settings as the same as I use on my G11 unless noted. The speeds listed are goto rates if it were used with my G11:
16uS(64uS): Seems stable. 1.4 deg./sec. speed.
12uS(48uS): Seems stable. 1.8 deg./sec. speed. Commands possibly show a bit of lag.
12uS(36uS): As above. 2.4 deg./sec. speed (MaxRate=3) motor still has torque and I bet it would work fine at this speed.
12uS(24uS): As above. 3.6 deg./sec. speed (MaxRate=2) motor stalls. MaxRate=2 just isn't practical.
10uS(30uS): Unstable. OnStep becomes unresponsive (too many cycles devoted to Timer1.)
I think OnStep will work at 16uS, 12uS might be pushing it. Due to it's design, timing critical operations happen in the main loop and the code must run fast enough to catch certain events every time.

4/22/13, Goto: Now that testing shows the firmware tracking rate changes seem to have done the trick, I'm moving on to testing (and implementing) features that improve the goto accuracy. I have added a few features to my planetarium software to geometrically model the telescope/mount and to correct for some commonly known deficiencies in their components' alignment. This awaits testing, if it appears to be working I'll move the code into the OnStep firmware for further testing.


4/9/13, OnStep improvements: I still have a nagging concern that the tracking accuracy of the OnStep isn't what it could be. I know that Serial communications with the MCU cause missed interrupts. I believe that this is due to the very high speed and longish execution time of my ISR that spins the stepper motors. These factors are hard to get around and I've dealt with them up to now by disabling the Arduino's Timer0. This improves tracking, but the built in Arduino Serial communications code keeps the interrupts disabled for too long and my ISR still misses running once in a while. Now, maybe the effect is too small to change the tracking enough to matter and maybe not. I'll try to eliminate it and see what happens...

I see three ways forward:
1. Move the serial communications code into my ISR. This would have to cover both serial channels and would need to use a polling method instead of the Arduino's built-in interrupt driven method. At 9600 baud characters are comming in at about one per millisecond so my ISR could scale to some fairly high baud rates and I'd bet that it would work well. This would be fairly involved and isn't my first choice.
2. Keep accurate time with another slower ISR that doesn't suffer from the above missed interrupt problems. The higher-speed ISR's sidereal clock can then be synchronized (by adjusting it's rate up/down slightly) to an accurate time signal and everything else should fall into place.
3. Another major change I had in mind (someday?) goes something like this... Currently sidereal tracking/guiding/etc. work with a constant rate (fast) ISR and several counters within that speed up or slow down the rate of stepping. A better way (on the Mega2560) would be to switch to using two 16bit timers, one for each axis and programming the timer's rate directly. This would eliminate having the seperate counters within the ISR and all of the logic for adding and subtracting steps for guiding/PEC rate control, ie. a complete change from the way it's done now. The very fine rate control would smooth out the motor's motion which might make sidereal tracking a bit smoother. Guiding and PEC corrections could be played by simply doing a Timer rate change. Two other advantages also exist. First with the ISR code, each timer would only be about half the size so it would run faster (helps with missed interrupts.) The other advantage has to do with how fast the ISR's run. I currently run the (single, larger) ISR four times faster (to avoid large accellerations during goto's) than would be needed if implemented this way, which would again help keep from missing interrupts. Hopefully this would be enough to allow serial communications code to not cause missed interrupts otherwise i'm back to using a reference timer to tweek the drive rate to maintain accuracy. I'm really not sure if I'll ever do the above depending on how well things work as is (Method 2); this is more likely kicking around ideas for OnStep Version 2.

Method 2 has been implemented and I await a clear night to test things out. If it's working properly I shouldn't need to adjust the tracking rate (from it's calculated value) since the crystal accuracy alone will get it close enough.


4/5/13 - OnStep Hardware. To help some of those who are implementing their own OnStep's here's a photo of my testing setup. This has only one motor (RA) plugged into pins Gnd,13,12, and 11. The other motor (Dec) plugs into Pins 7,6,5, and 4 (7 is Gnd and wiring is identical.) The breadboard is not really necessary, just there to bring the +12v supply to the big easy driver. The small board on top of the Arduino Mega2560 is a HC05 bluetooth module with wiring for +5v/Gnd on one pair and Serial Tx1/Rx1 on the other.




3/26/13 - Firmware 0.99a2. A while back I branched off a development version of the OnStep firmware to add features and bring compatibility with the Arduino Mega 2560. I've gained enough confidence through testing to move on to actively using this firmware version with the OnStep in my observatory for further testing. This version has numerious improvements... including PEC that starts recording immediately (before it took up to four minutes to start), PEC plays back evenly over each one-second sample (instead of bursts), and a adjustment is performed on the samples after recording is finished so we're not pushing the sidereal rate up/down with PEC. PEC is also now added into the tracking in such a way as to not effect the coordinates retrieved from the OnStep. The other big improvements have to do with timing and avoiding missed interrupts. All features are available on the Atmega2560, but some are disabled on the less capable Atmega328 (in the observatory.)

3/22/13 - I know of a couple of bug-fixes/additions for this app and OnStep that still need to be dealt with:
Fix - Site setup connection problem, fails on first try.
Fix - Messier catalog positions need to be converted to J2000.0
Fix - Emergency stop doesn't work!
Add - Setup menu item to configure the horizon and overhead goto limits.
Other than that, everything is working AFAIK. Testing has been done "on the bench" with a stepper motor attached to the OnStep so I could visually confirm all actions. Additionally, Sky Planetarium was also connected to the OnStep which provides feedback and confirms the ability to have two command channels working together simultaneously.


3/22/13 - The Android app now has four catalogs of objects/stars: The Messier, Herschel 400, NGC2000, and the BSC (catalog of 250 named bright stars). The catalogs all use a common file format (csv) - this allows for future changes to bring the ability to work with arbitrary catalogs. When a catalog is selected, a list of objects is displayed (those above the horizon) and selecting an object brings up detailed info. and the ability to send the goto command to the OnStep. You might notice the exclusion of solar-system objects, predicting the positions of those requires a fair amount of code and that will have to wait until I have a few other projects behind me.
To give everyone an idea of the level of functionality at this point, here's a list of features...
1. Location - Select four locations with Name/Latitude/Longitude/Timezone. Remembers the current location setting (#1..4). This is done.
2. Home/Date/Time - Simple button presses send the Home command, sets the Date, or sets the Time. This is done and works well.
3. Align - The process works as follows:
    a) Initialize the OnStep... Set the Location, Date, and Time. The location and date are remembered between power cycles.
    b) With the mount in the CWD position, select Home (Reset).
    c) Select 1, 2, or 3 Star Align.
    d) Select the first(second, etc.) star and do a GOTO, wait for the GOTO to complete.
    e) In the Guide control (with n/s/e/w/etc) center the Star then press the "Align" button.
    f) Go back to step d) and select another star (if necessary, when done the "Align" button becomes "Sync").
I'll probably add a routine to identify the best stars for each align step from the BSC when in align mode. Other than that, this is done.
4. Park - Again, simple button presses send the Park, Un-Park, and Set-Park commands. No status feedback, other than success/failure are provided for. OnStep does all of the state checking and simply won't accept the command if it doesn't make sense. This is done.
5. PEC - Buttons allow record/play/write/etc. Clear the data buffer, kick on record and go to the guide buttons... guide the mount for one worm period* and you should be set. *=OnStep starts recording values immediately, a worm period is four minutes on my mount. Additional recording sessions w/o clearing the buffer will average the data improving accuracy. This is done.
6. Goto Objects and Stars from the catalogs. Proper motion (for stars), precession, and refraction are applied to the RA/Dec, this should bring the apparent coordinates to within about 0.5' of their actual values. I'll probably add the ability to sort the catalogs based on object type and constellation. Status feedback is provided for, including below horizon limit, too close to zenith, mount is parked, or already slewing (which then cancels that slew for emergency stop functionality). This is done.
7. Some screen shots from my phone:




3/6/13 - Nearly all aspects of controlling an OnStep from the Android App are working. I can access/change the Sites (1-4: Lat/Long/TZ), Reset/Home the mount, Park, Align, PEC, Slew around with the Guide commands, etc. I've now moved on to writing an astronomical methods class for Android to provide support for Equ/Hor coordinate conversion, proper motion, precession, and refraction. These then will allow me to determine which objects from the catalogs are visible and to allow fairly accurate goto's.


3/5/13 - The Android App is coming along. I can new do slews and configure about most of the settings of the OnStep. Took quite some time to get the bidirectional checksum and numerious little hiccups worked out (like the Timer0 problem below).


3/4/13 - I noticed timing anomalies in OnStep as a result of speeding up the ATmega2560's ISR to 16uS. I guessed, apparently correctly, that another (hardware) timer was interfearing with the one that I use to issue the pulses to the stepper drivers. So I disabled the Arduino's Timer0 and moved it's associated millis() and delay() functions into Timer1. This made a substantial improvement to the agreement between the calculated timing rates and those that are actually used. I also implemented (optional) checksum i/o for each serial channel and made changes to handle differing gear ratios between the axis of the mount. This is pushing the project away from being able to run on the ATmega328 since I now have to disable three star align to fit on that MCU. I don't see this as being a major problem, since even the 2560 based Arduino's are relatively inexpensive and there just isn't any compelling reason to stay with the ATmega328 for new builds.


2/22/13 - Turns out that developing the Android app wasn't too hard. I already have things working pretty well, about a week or two's worth of work is needed to have a "Beta" quality product.
Getting the Arduino Mega working with a bluetooth adapter was a bit more difficult than I expected. Two problems crept up. First, the command processing and result return routines needed some fairly extensive overhauling to make them play nicely with two serial port command channels. The other problem was with the ATmega2560's speed... writing to "Pins" on the 2560 (DigitalOut) in the Arduino programming enviroment seems to be slower than on the ATmega328. This is a real problem since those DigitalOuts are called in a ISR that runs every 32uS and the ATmega2560 wasn't getting through it before the timer fired again. I re-coded the routine to write directly to the port registers to speed things up and this solved the problem, in-fact it looks like it might be ok at 16uS which can help with reaching higher slew speeds.
All changes to the OnStep firmware are tested on both the Arduino Mega and the UNO; I'm providing #define's to switch on/off features to enable support for both devices.