Gina

Making progress

Moon is up and lighting the clouds but the clouds are showing signs of gaps. 5s exposure. gain on auto and at 172. Looking forward to when the moon is out of the way and I can get an idea of what this combination of lens and camera is like for dark nights. Meanwhile I'm continuing work on the electronics...

Connector for Hall switch :- Power Gnd Output Hall sensor device A3144

Pretty much full cloud cover now.

After total cloud coverage the sky partly cleared and showed some nice red clouds in the setting sum. Bunged my ASC on it's pole and stuck it out on the guttering and captured an image. Unfortunately the imaging was set to RAW8 so some posterisation. But yer 'tis anyway. Captured a second image a bit later having set imaging to RGB24.

These are the Astroberry Board GPIO connections :- #define IN1 RPI_BPLUS_GPIO_J8_29 // GPIOO5 Nano pin 2 #define IN2 RPI_BPLUS_GPIO_J8_31 // GPIO06 Dew Heater #define IN3 RPI_BPLUS_GPIO_J8_33 // GPIO13 Camera Cooler And these are the Arduino Nano connections :- TX1 RX0 RST Gnd to RPI Gnd D2 Input from RPi GPIO 5 D3 Stepper Driver 1 D4 Stepper Driver 2 D5 Stepper Driver 3 D6 Stepper Driver 4 D7 Hall Switch I'll probably power the Nano from the USB connector with 5v from the RPi. Looking at the HAT photo, I may use A0 for the Hall switch input as it's next to the Gnd and +5v rails and I could use a 3 pin connector for it.

Been working on the electronics. Here is a photo of the HAT with most of the components and links. MOSFETs omitted to show the resistors.

Thank you Yes, I'm hoping to.

Redesigned and printed a new lens support. Definitely better Focused on a distant light. Focus not perfect but not too bad - I think I'm learning a new skill The moon is 98% full and about as bright as it gets yet it is possible to see a few of the brighter stars - it was hopeless with the dome! Mind you a new non-yellow and clear dome should be better than the one I was using. I can see two red hot pixels and maybe a green one 0 blue ones might not show. A dark would eliminate those. I think I can make out about a dozen stars Here's an image taken with the ASI178MM to show the difference in coverage and the trees that can be cut out of the image without loosing any part of the sky.

Got offset wrong way

This is with the aluminium lens support. Clearly shows the offset! Better alignment but no better for focussing. So I need the printed version to get the offset corrected and maybe if I get the inside hole right it might work better.

Clear sky forecast by the BBC for tonight but Clear Outside says solid cloud. ATM the BBC are right. I've focused the lens and put the ASC outdoors on the guttering. The focus is hopeless - I need to find a better system for focussing than moving the lens in the tube by hand. If I get the focus reasonable in one place it's off in another. What it needs is two independent controls - one for getting the lens straight and another for moving it in and out to focus. Looks like I need to do some lateral thinking...

I've been thinking. It seems rather daft to use two microprocessors where one should do The Arduino and RPi both use C++ code so you would think that anything written for the Arduino should work with the RPi provided the pin numbers are changed to suit. So If I can find out how input is handled by the RPi I should be able to read the Hall sensor just as with the Arduino. OTOH further research on INDI drivers makes it seem almost impenetrable. Most examples I can find seem unreasonably complicated. The Astroberry Board and Focuser are relatively simple but still use lots of complicated calls. I'm not exactly giving up but it still seems that the quickest way to get the ASC working would be to use the Arduino Nano mounted on the HAT and driving the stepper motor via ULN2003A module. I think that's that way I'm going for now.

There are two possible ways of operating the cover :- 1. Run the motor until the appropriate end limit is sensed or 2. do away with the open sensor and rely on step count to achieve the right angle when opening the cover. The close cover operation could provide a warning if the count exceeded the normal by a certain amount, indicating that the motor or gearing had failed. But I don't know how to implement this in an INDI driver as yet. I can tell if the cover doesn't open properly by the camera image so an open sensor isn't really needed. Always nice to save a bit of hardware This indicates that the second option above will be fine. The code can poll the input line and if there's a change it can run either the code to open the cover or the code to close it. The opening code would turn the motor anti-clockwise for 425 counts, whereas the closing code would turn the motor clockwise until the cover closed condition was sensed.

Here's an Arduino code example which I shall modify to do what I want :- // This Arduino example demonstrates bidirectional operation of a // 28BYJ-48, which is readily available on eBay, using a ULN2003 // interface board to drive the stepper. The 28BYJ-48 motor is a 4- // phase, 8-beat motor, geared down by a factor of 64. One bipolar // winding is on motor pins 1 & 3 and the other on motor pins 2 & 4. // Refer to the manufacturer's documentation of Changzhou Fulling // Motor Co., Ltd., among others. The step angle is 5.625/64 and the // operating Frequency is 100pps. Current draw is 92mA. //////////////////////////////////////////////// //declare variables for the motor pins int motorPin1 = 2; // Blue - 28BYJ48 pin 1 int motorPin2 = 3; // Pink - 28BYJ48 pin 2 int motorPin3 = 4; // Yellow - 28BYJ48 pin 3 int motorPin4 = 5; // Orange - 28BYJ48 pin 4 // Red - 28BYJ48 pin 5 (VCC) int motorSpeed = 1200; //variable to set stepper speed int count = 0; // count of steps made int countsperrev = 512; // number of steps per full revolution int lookup[8] = {B01000, B01100, B00100, B00110, B00010, B00011, B00001, B01001}; ////////////////////////////////////////////////////////////////////////////// void setup() { //declare the motor pins as outputs pinMode(motorPin1, OUTPUT); pinMode(motorPin2, OUTPUT); pinMode(motorPin3, OUTPUT); pinMode(motorPin4, OUTPUT); Serial.begin(9600); } ////////////////////////////////////////////////////////////////////////////// void loop(){ if(count < countsperrev ) clockwise(); else if (count == countsperrev * 2) count = 0; else anticlockwise(); count++; } ////////////////////////////////////////////////////////////////////////////// //set pins to ULN2003 high in sequence from 1 to 4 //delay "motorSpeed" between each pin setting (to determine speed) void anticlockwise() { for(int i = 0; i < 8; i++) { setOutput(i); delayMicroseconds(motorSpeed); } } void clockwise() { for(int i = 7; i >= 0; i--) { setOutput(i); delayMicroseconds(motorSpeed); } } void setOutput(int out) { digitalWrite(motorPin1, bitRead(lookup[out], 0)); digitalWrite(motorPin2, bitRead(lookup[out], 1)); digitalWrite(motorPin3, bitRead(lookup[out], 2)); digitalWrite(motorPin4, bitRead(lookup[out], 3)); }

I'll calculate roughly how many steps will be required to open the cover. The gears are 15 and 20 teeth so ratio of 3:4. I estimate the angle to turn the cover as about 225° so the angle wanted on the motor shaft is 225x4/3 = 300°. Stride angle quoted for the motor is about 5.625°/64 so we'll want 300x64/5.625 = 3413.3 steps. Think I'll call it 3400 and see how well that works. I can always alter it later if wanted. For clean operation of the stepper motor I propose starting and finishing with the same phase. This means making the inner loop rotate the motor by 8 steps. The count applied in the outer loop therefore wants to be a quarter of the total steps = 3400/8 = 425.

I thought I would see if an Arduino Nano would fit on the RPi HAT - and it does - perfectly Maybe that's an omen telling me to go the Arduino route That would be much easier until I get up to speed with IND driver development. Rather than using a modified 5v 28BYJ-48 and A4988 driver module I can use a 12v version with the ULN2003A driver module with full stepping driven from the Arduino. I have several spare 12v stepper motors and several ULN2003A driver modules and I can keep the micro-stepping motors and drivers for higher resolution applications such as focusers. These photos show an Arduino Nano plus the transistors and MOSFETs fitted onto the HAT. It all fits on rather nicely

Whichever way I implement the stepper motor control, it will need sensors for the cover and best would be Hall switches and magnets which I have in stock. These are better than micro-switches as weatherproofing is easy.

I've been thinking about possible things that could go wrong. If power is lost while the cover is open the system will reset to default state when power resumes and assume the cover is closed - the default state. Then if the Cover Open operation is started the stepper motor will try to open the cover further until it hits the casing and the possibly strip the plastic gears in the stepper motor. Even if a micro-switch were used to cut power when fully open, the system would still assume the cover was closed and there would be no close operation available. Therefore, it needs sensors to detect when the cover is fully open and also when it is fully closed. These must be signals sent to the electronics for the system to recognise and take notice of. This is much more important than the hardware and software used in the implementation. I shall see if I can do this in an INDI driver but I don't really want this to take too long and if it looks very difficult I may use an Arduino instead. I know how to do it this way and the control interface will look the same. The Astroberry Board driver will simply set a control line to ON or OFF and only the labels would need setting in the driver. The Arduino would compare the input control with the cover state as sensed by the limit sensors and then drive the stepper motor as required. All this is standard stuff that I've done before with the Arduino. In either event, the Astroberry Board driver code would look like this :- IUFillSwitch(&Switch1S[0], "SW1ON", "Open Cover", ISS_OFF); IUFillSwitch(&Switch1S[1], "SW1OFF", "Close Cover", ISS_ON); IUFillSwitchVector(&Switch1SP, Switch1S, 2, getDeviceName(), "SWITCH_1", "Cover", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); IUFillSwitch(&Switch2S[0], "SW2ON", "DewHeater ON", ISS_OFF); IUFillSwitch(&Switch2S[1], "SW2OFF", "DewHeater OFF", ISS_ON); IUFillSwitchVector(&Switch2SP, Switch2S, 2, getDeviceName(), "SWITCH_2", "Dew Heater", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); IUFillSwitch(&Switch3S[0], "SW3ON", "Cooling ON", ISS_OFF); IUFillSwitch(&Switch3S[1], "SW3OFF", "Cooling OFF", ISS_ON); IUFillSwitchVector(&Switch3SP, Switch3S, 2, getDeviceName(), "SWITCH_3", "Camera Cooling", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); IUFillSwitch(&Switch4S[0], "SW4ON", "Power ON", ISS_OFF); IUFillSwitch(&Switch4S[1], "SW4OFF", "Power OFF", ISS_ON); IUFillSwitchVector(&Switch4SP, Switch4S, 2, getDeviceName(), "SWITCH_4", "Not Used", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

This section of code determines the text for the labels and log that will be displayed in KStars/Ekos (or other client software) :- IUFillSwitch(&Switch1S[0], "SW1ON", "Power ON", ISS_OFF); IUFillSwitch(&Switch1S[1], "SW1OFF", "Power OFF", ISS_ON); IUFillSwitchVector(&Switch1SP, Switch1S, 2, getDeviceName(), "SWITCH_1", "Line A: 5V", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); IUFillSwitch(&Switch2S[0], "SW2ON", "Power ON", ISS_OFF); IUFillSwitch(&Switch2S[1], "SW2OFF", "Power OFF", ISS_ON); IUFillSwitchVector(&Switch2SP, Switch2S, 2, getDeviceName(), "SWITCH_2", "Line B: 5V", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); IUFillSwitch(&Switch3S[0], "SW3ON", "Power ON", ISS_OFF); IUFillSwitch(&Switch3S[1], "SW3OFF", "Power OFF", ISS_ON); IUFillSwitchVector(&Switch3SP, Switch3S, 2, getDeviceName(), "SWITCH_3", "Line C: 0-12V", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); IUFillSwitch(&Switch4S[0], "SW4ON", "Power ON", ISS_OFF); IUFillSwitch(&Switch4S[1], "SW4OFF", "Power OFF", ISS_ON); IUFillSwitchVector(&Switch4SP, Switch4S, 2, getDeviceName(), "SWITCH_4", "Line D: 12V", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); Without implementing stepper motor code within this driver I could change this to provide dew heater and cooler control by changing the code to :- IUFillSwitch(&Switch1S[0], "SW1ON", "DewHeater ON", ISS_OFF); IUFillSwitch(&Switch1S[1], "SW1OFF", "DewHeater OFF", ISS_ON); IUFillSwitchVector(&Switch1SP, Switch1S, 2, getDeviceName(), "SWITCH_1", "Dew Heater", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); IUFillSwitch(&Switch2S[0], "SW2ON", "Cooling ON", ISS_OFF); IUFillSwitch(&Switch2S[1], "SW2OFF", "Cooling OFF", ISS_ON); IUFillSwitchVector(&Switch2SP, Switch2S, 2, getDeviceName(), "SWITCH_2", "Camera Cooling", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); IUFillSwitch(&Switch3S[0], "SW3ON", "Power ON", ISS_OFF); IUFillSwitch(&Switch3S[1], "SW3OFF", "Power OFF", ISS_ON); IUFillSwitchVector(&Switch3SP, Switch3S, 2, getDeviceName(), "SWITCH_3", "Not Used", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); IUFillSwitch(&Switch4S[0], "SW4ON", "Power ON", ISS_OFF); IUFillSwitch(&Switch4S[1], "SW4OFF", "Power OFF", ISS_ON); IUFillSwitchVector(&Switch4SP, Switch4S, 2, getDeviceName(), "SWITCH_4", "Not Used", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE); I may be able to work out how to remove the unused controls completely.

The code uses pin numbers rather than GPIO numbers so this lists the correspondence for the Astroberry Board :- And these are for the Astroberry Focuser :- I shall only need DIR, STEP and SLEEP. SLEEP turns the driver module off when not moving the stepper motor. I can use the Astroberry Focuser to determine the number of steps required to open the cover then if I add stepper code to the Astroberry Board I shall know how many steps I want. This would apply for the simple case of no feedback assuming the stepper motor will always work properly and produce the correct rotation angle. I would like feedback but this might be more difficult to code. I am now registered with the indiserver forum so can ask questions if I have problems with the coding.

Back to the electronics - from an earlier ASC version :- A modification of the dew heater circuit is used to switch the cooling on/off. By rearranging the transistor connections the collector can be made to go down to nearly 0v in the ON state and should be enough to switch the MOSFET which needs -4v Vgs minimum to turn on fully. I expect the GPIO connections will change for this latest ASC as I would prefer to use Line A as cover control, with Line B for Dew Heater and Line C for Camera Cooler if/when I change the code for Line A. These are the default connections for the Astroberry Board (though they be changed in the code) :- For The Astroberry Focuser (if this were used for controlling the cover) :- For this application micro-stepping is not required so the M0 and M1 connections can be left unconnected for full stepping. I may use this initially for testing but eventually I want to use the Astroberry Board driver only, modified to control the stepper motor for the cover.

Something strange happening with SharpCap. First of all it wouldn't connect to either ZWO camera even if restarted so I rebooted and tried again. Working now but getting different camera controls! No Auto Exposure but still has Auto Gain. Weird!! Had a little problem with the Peltier TEC too - a wire broken off. Anyway, managed to resolder it on then added hot melt glue to stop the wires breaking off again. Put everything back together and tried imaging. Out of focus so redid the focussing but the lens isn't straight.

I've been reading up on the INDI protocols and how to write and modify INDI drivers. I think I can probably take code snippets from the Astroberry Focuser board driver and incorporate them into the Astroberry Board driver such that turning LINE A ON (will be labelled "Open Cover") will send the appropriate number of steps to the stepper motor to open the cover. Once that has been done the driver can report OK to the client software. The associated light would show yellow while the operation is being carried out and go green once the client receives OK from the driver. A similar process would occur when the "Close Cover" button is clicked but closing the cover. I would like some sort of feedback from the cover mechanism to confirm that the action has indeed happened. Physically this could be achieved with a microswitch or Hall sensor and magnet. This would feed a digital signal into the GPIO of the RPi. I would need to add code to detect these inputs viz. cover open or cover closed. I'm gradually getting my head round the way INDI works and the associated code. The control protocol is a version of XML but the working code is written in C++ with which I'm familiar. (Arduino code is C++). The alternative to quite a lot of INDI driver coding would be to use an Arduino and just a slightly modified Astroberry Board (labels only) and feed a digital signal to the Arduino - logic "1" for Open and logic "0" for Close. But with this system there would be no feedback. It is a far less satisfactory solution in many respects. I don't like "bodged" solutions! If I can get my aging head round INDI driver development, there are all manner of possibilities

Lens has now misted up. It didn't mist up at all last night and I captured images every minute all night but tonight it has misted up already. So a dew heater is definitely needed as I expected. I have already planned for this in the form of six 10ohm resistors from the set I used before with the dome. These will sit between the lens support and the conical underside of the lens. I shall probably improve heat transfer to the lens with thermal paste. 6x10ohms totals 300ohms which when running off 13.8 volts will dissipate just over half a watt. Just have to see if this is enough.