Gina

Been looking into the arrangement of parts in the ASC and concluded that the focus motors stick up too high making a lens cover and the casing, difficult. I'm therefore thinking of mounting the motors underneath the plate. The casing will have to be a couple of mm larger but that hardly matters. Might need to be a bit higher too but not sure yet. As can be seen in the photo below, the motors will fit below the plate. This will mean there will be more room for the lens cover and the casing could have a conical top for better draining and less windage. Thought I had some stripboard but can't find any so ordered some more. Means I can't construct the focus motor driver board though I have be progressing on the lens cover motor driver connections on the HAT.

Interesting I shall be interested to see if you find the 32bit processor any better. I find the induction Z probes quite adequate - bed levelling works very well. I too found servo arm and microswitch very unreliable too and gave up on that ages ago.

Been studying the arrangement of pins and easiest way to wire the HAT and also the RPi interfacing book. Here is the result. The Lens Cover motor driver will be on the HAT and the Focus Motor drivers on a separate piece of stripboard (Veroboard). One little change for the latter is that I shall separate the data and motor power Gnd lines. They will be commoned at the power input only. // Lens Cover Motor #define DIR RPI_BPLUS_GPIO_J8_07 // GPIO4 DIR #define STEP RPI_BPLUS_GPIO_J8_11 // GPIO17 STEP #define STEP RPI_BPLUS_GPIO_J8_12 // GPIO18 SLEEP #define IN1 RPI_BPLUS_GPIO_J8_29 // GPIOO5 Lens Cover Hall Switch // Power lines #define IN2 RPI_BPLUS_GPIO_J8_31 // GPIO06 Dew Heater #define IN3 RPI_BPLUS_GPIO_J8_33 // GPIO13 Camera Cooler // Focus Motors #define IN1 RPI_BPLUS_GPIO_J8_13 // GPIO27 DIR #define IN1 RPI_BPLUS_GPIO_J8_15 // GPIO22 STEP #define SLEEP RPI_BPLUS_GPIO_J8_16 // GPIO23 SLEEP #define M0 RPI_BPLUS_GPIO_J8_35 // GPIO19 Motor A #define M1 RPI_BPLUS_GPIO_J8_37 // GPIO20 Motor B #define M2 RPI_BPLUS_GPIO_J8_40 // GPIO21 Motor C

ATM I have just one GPIO pin allocated to the lens cover but I'm now planning to use a stepper motor driver connected directly to the RPi so will need more. I don't see this as being a problem. I could piggy back the lens cover motor onto the focus motors but I'm not sure I want to do that, I'd rather keep them separate. I need at least one pin with pull-up for the Hall switch. Then three pins for DIR, STEP and SLEEP. Best to have pull-down on the SLEEP to ensure the motor is off when the power is applied. DIR and STEP don't matter.

This diagram shows the connections for the three focus motor drivers.

With the clear nights we're getting currently I feel the need to get on with the hardware then I can make a first stab at the software to get something working and tidy up later. I shall be controlling all the motors directly from the RPi and not use the Arduino Nano. That's the three focus motors and the lens cover. So all 5v versions of the 28BYJ-48 modified for bipolar connection and A4988 driver modules. The diagram below show a basic circuit for the A4988 module but I shall be using ENABLE, SLEEP, STEP and DIR with the RESET and VDD connected to the +3.3v rail.

From trying to get focus manually by turning the gears, it seems one tooth of the 12 tooth gear makes quite a significant change in focus - in fact from way out one side of focus to way out the other side. So 30° rotation of the motor shaft is actually quite coarse and I could allocate this as the size of the coarse step. The stride angle of the motor is 5.625°/64 approx (64:1 is the approximate gearbox ratio). So 30° corresponds to 30x64/5.625 = 341.3r steps. So we could make coarse movements say 400 steps and fine movements 40 steps as a first try. The basic code for controlling the motors is :- for ( int i = 0; i < ticks; i++ ) { // step on bcm2835_gpio_write(STEP, HIGH); // wait bcm2835_delay(STEP_DELAY/2); // step off bcm2835_gpio_write(STEP, LOW); // wait bcm2835_delay(STEP_DELAY/2); // INWARD - count down if ( bcm2835_gpio_lev(DIR) == HIGH ) FocusAbsPosN[0].value -= 1; // OUTWARD - count up if ( bcm2835_gpio_lev(DIR) == LOW ) FocusAbsPosN[0].value += 1; } This counts steps but to make the numbers smaller and more suitable for a meaningful display it would be better to work in units of 40 steps per tick and using an inner loop with a count of 40.

Here are the GPIO pin assignments :- #define IN1 RPI_BPLUS_GPIO_J8_29 // GPIOO5 Lens Cover #define IN2 RPI_BPLUS_GPIO_J8_31 // GPIO06 Dew Heater #define IN3 RPI_BPLUS_GPIO_J8_33 // GPIO13 Camera Cooler #define M0 RPI_BPLUS_GPIO_J8_15 // GPIO22 Motor A #define M1 RPI_BPLUS_GPIO_J8_13 // GPIO27 Motor B #define M2 RPI_BPLUS_GPIO_J8_37 // GPIO26 Motor C #define DIR RPI_BPLUS_GPIO_J8_07 // GPIO4 #define STEP RPI_BPLUS_GPIO_J8_11 // GPIO17 #define SLEEP RPI_BPLUS_GPIO_J8_16 // GPIO23

Think I would prefer the buttons in a different order. ie. CLOSE, OPEN - OFF, ON and IN Coarse, IN Fine, OUT Fine, OUT Coarse. That's easy

Moved the focus motor controls to the Options tab.

A bit less clutter

Here's the way it looks - still have function to add. Actually, there's still a lot there that I don't want

Regarding focussing, I think buttons for coarse and fine, in and out would suffice. So 4 buttons - Coarse IN - Fine IN - Fine OUT - Coarse OUT. Each click of the button moves the focus by a certain amount (to be determined by trial). Then, the 4 motor enable buttons - ALL - A - B - C. I could also have an overall control of ON/OFF - a "safety catch".

Back to INDI drivers :- I've sorted out why the labels on the buttons were wrong Also, if more than 4 switches are set up the control transforms into a drop down list. I've been thinking about the whole control system too. I think the Astroberry Focuser is overkill for this application - I don't really need auto-focus and I've found it's usually ineffective for such a wide FOV anyway (it works fine with standard lenses and telescopes). Also, I can take better control of the limits if I control the motors rather than using the standard INDI focuser. Here's an image with the camera just pointed out of the window - it shows that with gain at zero and exposure at the minimum of 32µs the ASC will work in daytime (I know it's out of focus.)

As a bit of an aside I'm wondering about possibly combining my ASC with my weather station wind instruments - putting both on the same mast. Problem might be the windage of the ASC.

Installing 3rd Party Drivers To be continued...

Posted about it on the INDI forum and had a reply from the author of INDI Just asking for details - I've replied.

Followed all the instructions for Simple Device but it doesn't work That's just it as published - no editing or extra code.

Returning to where things at least compiled and the driver connected :- Four buttons in the Board driver still with a couple of wrong labels and the Focuser driver returned to original. The screenshot below shows the appearance at start-up with all buttons unselected. Next I plan to edit the "Simple Device" driver code to add buttons.

I was hoping that if I transferred the motor control buttons to the focuser driver that I might get a clue as to why some of the button labels are wrong. Maybe I can teach myself something by adding buttons to "simple device" in the tutorials.

Well that didn't work! Surprise, surprise Seems to be to do with scope rather than just a silly mistake and could take some resolving. Might go back to having the motor control in the Board driver rather than in the Focuser where it logically belongs. Oh well, it was worth a try. It's only for me to use anyway - I doubt anyone else will copy this project though they are welcome to

The code for four buttons can be arranged that the motors are all off (disabled) until a button is pressed (clicked on) and with the focus driver putting the motors in SLEEP mode, there is the "safety catch" - motor(s) have to be ENABLED before the focuser will operate Problem solved. Now I shall try copying the code lines to the focuser driver. Great care needed

I guess 4 buttons will suffice as the Focuser can be disconnected so shouldn't operate. It's just that I like interlocks and "safety catches" Of course, I could always provide an interlock another way.

Going up to 5 buttons stops it connecting. Only a few extra lines of code are involved and I can't see anything wrong with these so I must conclude that the buttons are limited to 4. I'll investigate further tomorrow but if I can't find any error I'll ask on the INDI forum.

OK four buttons connects...