tekkydave

Hi does the  temperature compensating work in  any software or is it just showing a read out of the temperature?

The focuser just returns the current temperature to the Ascom driver when queried by the driver. The driver makes it available to the client software. It is up to the client software to carry out the compensation, if it is capable. HTH

Hi All,

Here is my AAF2 focuser. Thanks for the code, everything works fine.

150/750 SW, EQ5 GT-Pro

And a short video of operate:

and cooperate with APT:

Regards,

Golyo

A very professional build. Well done. I'm glad so many people are getting the benefit of my humble efforts. Now I have my 3D printer working I am planning to create a custom case for the Celestron 127 ota. This will replace my cork mat effort you see at the start of the topic.

When you say it contains basic ascom fuctionality, I presume it's not as refined as the Mark 2 code. I hate to to think I modded something that already did what I wanted.

I have basically taken the manual bits and added them into the Mark 2 sketch and it works! Well pleased. It's not pretty I'm sure but it works.

So eventually, I hope to have a permanently fixed electric focus controller which I can use manually with a control box that I plug in and also with ascom when I need to.

Thanks again.

The Mark 1 sketch only had some very basic commands I put in when I was first toying with the idea of an Ascom driver. I never wrote an actual driver at this stage, I just added the code to test sending commands via the usb connection. It only responded to an 'A' or 'C' to move the motor Anticlockwise or Clockwise. It also only responded when the switch was in the centre position and the motor was not moving. The Mark2 sketch is much more sophisticated and works with the Mark 2 Ascom driver.

I have uploaded the Mark1 code and a schematic to SF https://sourceforge.net/projects/arduinoascomfocuser/files/Mark1

The sketch contains a basic ascom serial functionality. This can be ignored or removed if you dont want to connect the usb cable.

The 5-way switch I used is commonly used on electric guitars.

Hi Dave

Not to sound like a backwards step but I would like to integerate your original manual control (Mk1) so that the focuser could be used without a laptop for quick observing sessions.

It would be useful to have both options available. It should be doable no?

If you can supply the Mk1 arduino sketch I could probably integrate it, I usually do VB6 but I could probably get my head round it. I thought I saw the MK1 stuff on your sourceforge page but I can't see it now.

Pretty please

I'll upload it to the SF site as soon as I can find the original code :-)

Ok, got all the bits connected and working on the bench.

For simplicity power wise I'm going to eventually go with a 12v stepper, 2 on their way on a very slow boat. Really loving how cheap these bits are.

When I get it boxed and coupled up I'll post some pics.

One thing, I noticed the sketch controls the motor in high and low speeds. Is there a reason for this? What am I missing?

The high and low speeds was just a feature I added to speed things up if you were moving the motor a long distance. It should be easy enough to change the speeds or the threshold value where it changes from hi to lo to suit your situation. In normal use doing small focus movements it will usually move at the lo speed. Looking forward to some pics in due course.

Hi

You've inspired me to give this a go. Thanks for sharing this project, an excellent DIY!

I'm going to give the direct drive a go on my 10:1 crayford.

Parts ordered, and they are so cheap.

Cheers

Thanks, Rich. Good luck with your build. Post some pics when you get it going.

Dave

Yes, the problem of EEPROM failure can be delayed for several years be judicious use of the EEPROM addressing but if you are really worried the data could be stored on a separate device such as a memory card (like I am doing with my weather station). But in this application I think an SD card would be overkill.

I thought about storing the position in the windows registery but a nano only costs a few quid and has lots of spare eeprom locations so decided it wasnt worth the effort.

It means that once the eeprom limit is reached, the eeprom will not be able to store the data correctly, this may result in incorrect readings of focuser position on power up. Its more than likely once the limit approaches that some bits within the storage location fail first, so that storing something like a position of 1024 might then be read back as 513. In other words, unreliable. What effect this might have on the focuser operation is best answered by the author.

There are many ways to overcome this issue. For example, only write to eeprom after a move operation, and after a time delayed (so that it is not triggered by autofocusing), and to cycle locations within the eeprom. These approaches I have taken in my own code, such that if one imaged every night of the year, yes, every night of the year, it would take over 9 continous years for the eeprom to reach the limit.  

Cheers

Robert

Im working on a version that will store to EEPROM only when a new position is reached rather than every step, which it does at the moment. I'll try and get it out soon. If you have any problems with EEPROM you can change the location used in the sketch to start using fresh memory locations if necessary. There is no way of avoiding this effect just minimising the chances and delaying the inevitable, even though it might take a long time (years). It wont stop the focuser working - it just wont remember where it was positioned the last time you used it.

Just got this on the scope, been waiting for the Sun to go too low as it's on the Quark scope and didn't want to disturb it 'till now.

Only running on the AAF2 app ATM, need to remount the scope and see if I can get it to work with Maxim.

Dave

Very nice job. Love the mounting.

Finished my focusers for the rc and mak 127.Got a stainless pipe clamp from work and lined it with neoprene.Welded on a bracket.

I then got a few parts made at work for the clutch and drive.

Nice work - very neat job.

The reason I had the 9V supplying the nano via Vin is that my Mark I focuser was manual only and did not have the usb connection during operation so no 5V supply. You should be ok supplying the stepper separately.

I an not sure that temp comp should be in the imaging app. It is better to have it in the driver as temperatures can change quite rapidly during a long sub. The amounts of change are small - in the microns - and a good focuser doesn't shift the image during focusing.

/per

I agree. The driver is there to hide the hardware's real physical operation from the client application. Putting the temp-comp in the driver will make it work with any ascom-compliant application. However if you have written a great app and none of you customers drivers support it you might want to build it into your app instead. If I was writing an imaging app I might be tempted to put it there so all my users can benefit, but I would also allow them to use their focuser drivers built-in temp-comp if they prefer.

Updated Roll of Honour

Here is an updated list of SGLers who have built the AAF2 focuser. Well done to all. Hope I haven't missed anyone.

Dave_D

Baffa

wuthton

Mick J

russellhq

mindburner

Davey-T

iwannabswiss

silios

SUNJiaLin

blackdragon72

redtail

SnakeyJ

Thanks everyone for their input especially re the eeprom lifetime issue. I'll fix the issue asap but it may be a couple of weeks. I have some other improvements to the sketch that I have already mentioned and some fixes to the driver in development so watch this space

I had a look at your eeprom code but believe you have some serious issues.

EEPROM in the controller is somewhat limited to 10,000 writes.

The way the code is written, this could be very quickly reached?

As example, put a little counter in that increments each time the eeprom is written, then do an imaging session and at the end of the night just print out/dump how many times it was written (might need another serial command) - then divide 10,000 by that number and what do you get? The number of sessions before the eeprom will likely fail?

Cheers

Robert

Is it the whole EEPROM that will fail or just the memory addresses I am using?

Suggest the following code snippets for the eeprom

#include <EEPROM.h>                   // needed for EEPROM

#include "eepromanything.h"           // needed for EEPROM

// #define EEPROMSIZE 500              // ATMEGA168 512 EEPROM

#define EEPROMSIZE 1000               // ATMEGA328P 1024 EEPROM

// these are stored in EEPROM - all variables in a structure

struct config_t {

  int validdata;       // if this is 99 then data is valid

  int fposition;       // last focuser position

  int maxstep;         // max steps

} myfocuser;

int datasize;      // will hold size of the struct myfocuser - 6 bytes

int nlocations;    // number of storage locations available in EEPROM

int currentaddr;   // will be address in eeprom of the data stored

bool writenow;     // should we update values in eeprom

bool found;        // did we find any stored values?

long previousMillis = 0;   // used as a delay whenever the EEPROM settings need to be updated

long interval = 10000;     // interval in milliseconds to wait after a move before writing settings to EEPROM, 10s

long numwrites = 0;        // number of eeprom writes this session

// Default initial positions if not set/overriden by Ascom Driver or Winapp

int currentPosition = 5000;   // current position

int targetPosition = 5000;    // target position

int maxFocuserLimit = 32000;  // arbitary focuser limit

int maxSteps = 10000;         // maximum position of focuser

int maxIncrement = 1000;      // maximum number of steps permitted in one move

int minimumPosition = 0;      // minimum position to avoid focuser damage

boolean isMoving = false;        // is the motor currently moving

// Setup

void setup() {

  // initialize serial for ASCOM

  ...............

  found = false;

  writenow = false;

  datasize = sizeof( myfocuser );    // should be 6

  nlocations = EEPROMSIZE / datasize;  // for AT328P = 1000 / 6 = 166 locations

  numwrites = 0;

  

  for (int lp1 = 0; lp1 < nlocations; lp1++ ) {

    int addr = lp1 * datasize;

    EEPROM_readAnything( addr, myfocuser );

    // check to see if the data is valid

    if ( myfocuser.validdata == 99 ) {

      // data was erased so write some default values

      currentaddr = addr;

      found = true;

    }

  }

  if ( found == true ) {

    // set the focuser back to the previous settings

    // done after this in one hit

    // mark current eeprom address as invalid and use next one

    // each time focuser starts it will read current storage, set it to invalid, goto next location and

    // write values to there and set it to valid - so it doesnt always try to use same locations over and

    // over and destroy the eeprom

    // using it like an array of [0-nlocations], ie 100 storage locations for 1k EEPROM

    EEPROM_readAnything( currentaddr, myfocuser );

    myfocuser.validdata = 0;

    EEPROM_writeAnything(currentaddr, myfocuser);    // update values in EEPROM

    numwrites++;

    

    // goto next free address and write data

    currentaddr += datasize;

    // bound check the eeprom storage and if greater than last index [0-EEPROMSIZE-1] then set to 0

    if ( currentaddr >= (nlocations * datasize) ) currentaddr = 0;

    myfocuser.validdata = 99;

    EEPROM_writeAnything(currentaddr, myfocuser);    // update values in EEPROM

    numwrites++;

  }

  else {

    // set defaults because not found

    myfocuser.validdata = 99;

    myfocuser.maxstep = 10000;

    myfocuser.fposition = 5000;

    // now write the data to EEPROM

    EEPROM_writeAnything(currentaddr, myfocuser);    // update values in EEPROM

    numwrites++;

  }

  // Set focuser defaults from saved values in EEPROM.

  currentPosition = myfocuser.fposition;

  targetPosition = myfocuser.fposition;

  maxSteps = myfocuser.maxstep;

  .......

}

// Main Loop

void loop() {

  // Move the position by a single step if target is different to current position

  if (targetPosition != currentPosition) {

    isMoving = true;

    writenow = true;             // updating of EEPROM ON

    previousMillis = millis();    // keep updating previousMillis whilst focuser is moving

  } 

  else {

    // focuser is NOT moving now, move is completed

    isMoving = false;

    if ( writenow == true ) {    // time to update eeprom

      // decide if we have waited 10s after the last move, if so, update the EEPROM

      unsigned long currentMillis = millis();

      if ( (currentMillis - previousMillis > interval) && (writenow == true) ) {

        previousMillis = currentMillis;    // update the timestamp

        // copy current settings and write the data to EEPROM

        myfocuser.validdata = 99;

        myfocuser.fposition = currentPosition;

        myfocuser.maxstep = maxSteps;

        EEPROM_writeAnything(currentaddr, myfocuser);    // update values in EEPROM

        numwrites++;

        writenow = false;

      }

    }

    clearOutput(); // release the stepper coils to save power

  }

}

Thanks for pointing that out. I'll sort it out in the next release.

Dave

I was kinda wondering if the ASCOM focuser could be extended to work with more than one scope at a time but I think this is probably asking too much

I think the issue is that you can only have one instance of each ascom driver running at once. You would need to create a copy of the AAF2 driver with a different name (e.g. AAF2b) to connect the second focuser to. I think that's correct. Ascom experts please comment

I think some commercial focusers do just that.

Dave - many thanks for providing the ascom driver and this great resource and tutorial.     After finally borrowing a replacement soldering iron, I finally completed this last night and now have it working via Ascom with Firecapture.     I still need to do another revision of the mount to fit my OO OC1 focuser and will probably upgrade to the 12V version of the 28BYJ48 to cope with the weight of the imaging train.

I'll need to find a 4K7 resistor to complete the 1wire temp enhancement, but otherwise ready to roll when the clouds part

Great news - well done. Glad you can make use of it.

Thats mainly why I used a 9V battery to power the nano and stepper. I may switch to 12V in the future - the controller board will take 5 to 12V according to the spec.

But will it still work with the .AAF2.Focuser ?

Have a go. You will only need to change the nano sketch. I'm ok with the motor I'm using so I don't plan to make any other changes at the moment.

There is a 4k7 pullup on my circuit diagram on SF http://sourceforge.net/p/arduinoascomfocuser/wiki/Schematic/attachment/AAF2_V2.2_crop.png. The schematic in the wiki section is the latest version.

I have also uploaded the v2.2 schematic to the Files/Drawings section on SF as there was only the original drawing without the temperature sensor.

To support this feature, does the driver need to read temperature periodically and adjust focus accordingly?

I'm not sure how temperature compensation works - whether it is a function of the driver or client application. It would be easy to change the driver to return true but that may not be enough to make it work.

I don't understand the MOSFET in Figure 4.  I use a digital pin on the Arduino connected to the DQ line with parasitic power.  No MOSFET.  I use this arrangement on my weather station to save wires going up the mast.  One twisted pair is all that's required

I've never seen a discrete MOSFET used like that on the 1-wire data line. Maybe it is denoting an active pullup for a large number of devices or long runs but the 4k7 resistor is fine for a few devices. My weather station uses a usb 1-wire interface (DS9490R) which contains an active pullup internally.

When I connect the focuser in Nebulosity and FocusMax, both grey out temp.compensation option. FocusMax says Temp.compensation available=False. Is it supposed to be supported?

No its not supported in the driver.