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.

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.

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.

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.

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

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

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.

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));
}

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.

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.

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

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.

Got offset wrong way

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.

That's much improved, I hope you get round to live streaming this cam.

Thank you   Yes, I'm hoping to.

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.

These are the Astroberry Board GPIO connections :-

1. #define IN1 RPI_BPLUS_GPIO_J8_29    // GPIOO5   Nano pin 2
2. #define IN2 RPI_BPLUS_GPIO_J8_31    // GPIO06    Dew Heater
3. #define IN3 RPI_BPLUS_GPIO_J8_33    // GPIO13    Camera Cooler

And these are the Arduino Nano connections :-

1. TX1
2. RX0
3. RST
4. Gnd to RPI Gnd
5. D2 Input from RPi GPIO 5
6. D3 Stepper Driver 1
7. D4 Stepper Driver 2
8. D5 Stepper Driver 3
9. D6 Stepper Driver 4
10. 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.

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.

Pretty much full cloud cover now.

Connector for Hall switch :-

1. Power
2. Gnd
3. Output

Hall sensor device A3144

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

Making progress

Lens has misted up now so I'll bring it all back indoors.  Needs that dew heater!

EDIT... A bit later - brought kit indoors and it's not just the lens that's misted up - the sky is too