Gina

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 :-

Quote

// indicate GPIOs used - use P1_* pin numbers not gpio numbers (!!!)
#define IN1 RPI_BPLUS_GPIO_J8_29    // GPIOO5
#define IN2 RPI_BPLUS_GPIO_J8_31    // GPIO06
#define IN3 RPI_BPLUS_GPIO_J8_33    // GPIO13
#define IN4 RPI_BPLUS_GPIO_J8_37    // GPIO26

And these are for the Astroberry Focuser :-

Quote

#define DIR RPI_BPLUS_GPIO_J8_07    // GPIO4
#define STEP RPI_BPLUS_GPIO_J8_11    // GPIO17
#define M0 RPI_BPLUS_GPIO_J8_15        // GPIO22
#define M1 RPI_BPLUS_GPIO_J8_13        // GPIO27
#define SLEEP RPI_BPLUS_GPIO_J8_16    // GPIO23

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 :-

On 21/10/2016 at 11:34, Gina said:

Here is a new design for the circuit to control the dew heater.  NPN transistor and P-Channel power MOSFET.  The 10K resistor prevents killing the RPi if the MOSFET should burn out.  It also stops parasitic oscillation that can occur with a direct connection.  ATM I can't think of a simpler circuit.

Unusually the NPN transistor is being used in common-base mode.  In the ON state GPIO pin 5 is at 0v and the 2K7 emitter resistor produces about 1mA current which would produce a 1mA collector current in linear mode but in this case the 22K collector resistor means that the transistor saturates and just over 8v is dropped in the 22K resistor.  This is well above the "turn-on" -5v gate to source voltage but also well within the -20v max Vgs limit, so the MOSFET turns on, powering the dew heater.

In the OFF state GPIO-5 is above 3v and the NPN transistor receives no emitter current as the Vbe is less than 0.6v so the collector current is also zero, the Vgs on the MOSFET is 0v so the MOSFET is OFF and hence dew heater is off.

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) :-

Quote

GPIO05 - IN1
GPIO06 - IN2
GPIO13 - IN3
GPIO26 - IN4

For The Astroberry Focuser (if this were used for controlling the cover) :-

Quote

Wiring Raspberry Pi to the motor controller:
GPIO04 - DIR
GPIO17 - STEP
GPIO22 - M0
GPIO27 - M1
GPIO23 - SLEEP

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.

I can't dictate when my neighbours have their ultra-powerful floodlight on though I know I can complain if their light impinges on my property but I want to get on with them and not have friction of any sort.  That is more important to me than a good view from my ASC.  When I built my observatory the neighbours then were not very friendly and rather than brew up a storm I built the observatory to protect my imaging equipment - telescopes or lenses - from that light. 

I could arrange that my ASC also has some sort of protection from the light.  There are two ways I could shade the ASC from the light - arrange a shade attached to the ASC or position it in a shadow area.  The former method would be easier.  It can be a permanent feature as there are trees behind their house and I don't need the view.  When I had the dome on I was considering protecting it from other lights much further away but without the dome those are no problem.

The two images below show the present night-time situation and the daytime view.  The light is near the apex of the roof on the white building at about 4 o'clock in the daytime view.

Next door have switched on their flood light   When I had a dome this caused such reflections in the dome that no stars could be seen.  Without the dome there are still reflections in the lens but not as bad.  Next time I see either of them I'll try to remember to mention that their light interferes with my astronomy and get them to switch it off when they don't need it.  I might add a little screen to shade my ASC in that direction for when the light is on.  It would be easier to keep the light off the lens than a great big dome.

Looking dark outside now but it isn't really   Some lights coming on though - mainly house lights and the odd car.  Second image shows more lights including some distant street lights, the red lights in the tree at 7 o'clock are on the Stockland Hill TV and radio transmitting mast.  A few stars showing.

Readjusted the focus using the far horizon.  Put back out on guttering and captured image.  With the angle of the pole and hence ASC, the coverage is not horizontal showing the field in the foreground.  The shed at about 8 o'clock is my observatory.  The moon is just above it and rising.   The second image is with the bottom end of the pole positioned away from the window a bit.

Onto the electronics then...  Of the available INDI drivers, the Astroberry Focuser seems to be the only one that drives stepper motors so I shall probably use this for the cover motor to start with.  It's not ideal but will do until I manage to write my own INDI drivers.  Another possibility would be to use an Arduino Nano to drive the motor and control that with the Astroberry Board which has four ON/OFF controls.  I will already be using this to switch the cooler and dew heater and the another line could operate the cover.  OFF = Closed and ON = Open.  It should be relatively easy to edit the code for the Astroberry Board to show the correct labels.

Brought the rig back indoors and can see why the focus was wrong - the lens support wasn't properly on the camera - it was up a bit on one side.  Daft duffer!

Clear sky forecast for tonight until around midnight but the moon doesn't set until nearly 2am tomorrow so no chance of seeing any stars tonight!  The moon is 78% full, so very bright.

All this needs thinking about but the easiest option is to stick with the RPi and INDI and only use this ASC for lower light situations.  I guess it might be possible to use the one ASC for all light levels but it would need different software unless or until INDI match their minimum exposure to that of the camera.  It really does seem strange!  I'll have another go at trying to register with the indiserver forum - tried before but it didn't work.

I have an RPi camera with fish-eye lens attached, on order with deliver on a very slow boat from China, that might do me for daytime imaging.  I also have a couple of acrylic domes on order to look at and consider, due to arrive next month.

This morning the sun is out but with a bit of cloud to the east.  Again running SharpCap and this image was taken with gain set to 0 and Auto Exposure giving 0.4ms gamma 25. I believe this shows that this arrangement could by used for daytime imaging as well as night.  Unfortunately, not with the RPi and INDI driver though as that only goes down to 1ms exposure.

Left the ASC running overnight capturing PNG images with SharpCap, continuing after the moon had set.  These were 10s exposures at one per minute to keep the number down a bit with gain on Auto, gamma on 25.  As before, this is just the camera and lens mounted on aluminium pipe and hung on the guttering.  A couple of things are evident.  The lens is not straight (focus is fine top right but out at bottom left of image) and the camera needs cooling to reduce noise.  Surprisingly there was no sign of dew but maybe there was heat coming from the camera.

Clouds may be going...