SharpSky ASCOM compliant digital focuser project

[hikerbob (Bob)]

My kit arrived last friday, got the board soldered together Saturday morning and then had to move onto other things. I got around to powering it up this evening and the heartbeat led worked first up.

I then soldered up the encoder and it's plug, connected the motor directly to the board and gave it another test. All working as expected.

I'll get on with the cut out's shortly and have a think about mounting the motor.

Bob

[dtrewren (Dave)]

Hi Bob,

Excellent news, good job - thanks for the progress report !

Any hints, tips or improvements I'm all ears. Also if you get chance to add a line or two on the forum that would be good.

Hope the mechanics go to plan

Cheers & clear skies,

Dave

[peter_4059 (Peter)]

Dave,

I have some questions about the client operation:

1. Should the absolute position indication change as temperature compensations are being made - the motor is changing position however the indicated absolute position remains constant.

If you click the "go" button for the reference position after temperature adjustments have been made it returns to the unadjusted position. I guess what this means is that a reference position is associated with a temperature. Under what circumstances would you use the "go" for the reference position - is it to get you in the ballpark at the start of the run?

2. It looks like the hand control works independent of the software interface - ie if adjustments are made to the focus position using the manual control the indicated absolute position does not change.

3. It looks like the temperature indication only updates if you click the temperature button - is the button doing some other function and why not update temperature indication automatically?

[dtrewren (Dave)]

Hi Peter et al,

Thanks for your observations. The client is working as originally intended but based on your comments and observations I could see room for improvement and the scope for some additional functionality.

To this end I have put my coding hat back on and have performed a few modifications which I hope you will like

Addressing points 1 & 2 :
The absolute position is now 'live'. Every second the position is updated and will reflect the absolute position including changes made using the manual control and/or temperature compensation. The manual control is intimately hooked into the software. When the manual control is used the PIC firmware moves the motor by the user selected number of steps. This information is also stored locally in EEPROM and reported to the PC driver via the USB connection. Once a second the client polls this information from the driver and the corrected position is reported to the client via the ASCOM API and subsequently displayed. Something similar occurs with temperature compensation but is quite a bit more involved.

API - Application Programming Interface.

Addressing point 3 :
The temperature window is now also 'live' and reports the temperature once per minute. If the 'Temp Now' button is pressed the current temperature will be displayed immediately.

The 'Go' buttons will take you to the value associated with that button irrespective of temperature compensation. The idea is you Go to a filter position, check & fine tune focus and then enable temperature compensation if required. I always use my luminance filter as the reference position and therefore would hit 'Go reference' if I wanted to return to the luminance filter.

New checkbox feature :
I have added a temperature compensation enable/disable checkbox. This checkbox is only available if 'temperature compensation available' has been checked in the driver. If you check/uncheck the enable/disable button on the client this state will be mirrored and remembered in the driver and visa/versa.

The new V1.6 version of the client is available for download via the website:
www.dt-space.co.uk/SharpSkyClient

I hope I have explained operation clearly ? If there are any questions, additional questions or bugs found (perish the thought ) please let me know.

Cheers & clear skies,

Dave

[peter_4059 (Peter)]

Cheers Dave. I'll check that out today.

I got the stepper installed on my Meade ED80 yesterday however the focuser isn't going to be adequate for the weight of the QSI. If I tighten the focuser tension so the drawtube doesn't slip the stepper can't overcome the friction and if I reduce the tension so the stepper is happy the drawtube slides out. I have a solution though and I've been looking for an excuse ...

http://www.focuser.com/cgi-bin/dman....cgi&product=CF

[dtrewren (Dave)]

Hi Peter,

Thanks for the feedback. I have a few questions regarding your focuser setup. Not had a problem with payload limit so far so would be nice to know the limiting factor.

- Roughly what is your payload weight ?
- It there significant focuser resistance even without the payload ?
- Is the motor coupled via the 10:1 fine focus ?

I do have another possible solution. I have another motor, same type as the supplied motor but it's big brother. The alternative motor on paper has about three times the pull in torque. I don't supply the bigger motor as standard just because it's usually over kill and is more expensive but still beer money (~£10) compared to the MoonLite.

I can send you the bigger motor to try out before going for the MoonLite ?

Cool, be interested to hear what you think regarding the software updates. I have had the updated client running all night with temperature compensation running and it's all very happy.

Clear skies,

Dave

[peter_4059 (Peter)]

Dave,

My Meade is one of the old ones and it only has 1:1 focus mechanism. This is probably the main issue. The camera is a QSI 683ws-8 and it weighs about 1.6 kg. I never had any issues with the QHY8 however the QSI camera is quite a bit heavier so I think the focuser is going to be an issue regardless of the stepper. The resistance is adjustable however it needs to be done up pretty tight to stop the draw tube sliding out under the weight of the QSI. I've got a Moonlite with a DC motor on my 10" Newt and I'm thinking about upgrading this to a stepper version in the near future. This focuser/DC motor handles the QSI without any issues.

I downloaded the new version of the client today and I'm planning to have a play with it tonight.

Peter

Originally Posted by dtrewren

Hi Peter,

Thanks for the feedback. I have a few questions regarding your focuser setup. Not had a problem with payload limit so far so would be nice to know the limiting factor.

- Roughly what is your payload weight ?
- It there significant focuser resistance even without the payload ?
- Is the motor coupled via the 10:1 fine focus ?

I do have another possible solution. I have another motor, same type as the supplied motor but it's big brother. The alternative motor on paper has about three times the pull in torque. I don't supply the bigger motor as standard just because it's usually over kill and is more expensive but still beer money (~£10) compared to the MoonLite.

I can send you the bigger motor to try out before going for the MoonLite ?

Cool, be interested to hear what you think regarding the software updates. I have had the updated client running all night with temperature compensation running and it's all very happy.

Clear skies,

Dave

[dtrewren (Dave)]

Hi Peter,

I had a similar issue with the stock focuser on my ED80 when I upgraded to a QHY9M+FW+TS FF. I could get the draw tube not to slip but had to nip up the tensioner quite a bit. This made the entire focuser movement quite tight. In the end I came to the conclusion that the focuser was operating at the limit (maybe a bit beyond) of it's payload capacity. So I upgraded the focuser of the ED80 & ED120 and this really solved the problem. The draw tube no longer slips but the travel is smooth and not tight. Also there is a 10:1 control which is coupled to the stock motor I have been supplying with the SharpSky kit.

Obviously, MoonLite focusers are in a different league but the budget wouldn't really stretch to two of these beasts. The motivation for making the SharpSky controller pin compatible with MoonLite was to permit an easy upgrade path from budget stepper motor and bracket to MoonLite/Robo. However, now I have motors and brackets fitted to my scopes the focusing performance is great so will stick with the current setup.

I think like many people I'm not sure how I managed before fitting remote focusing - for me it certainly makes the imaging experience more enjoyable

Cheers & clear skies,

Dave

[peter_4059 (Peter)]

The changes to the client are great Dave. Much more intuative now. Thanks.

[dtrewren (Dave)]

Hi Peter,

Excellent, thanks for testing it out and the feedback. Anything else that you think might make it easier to use or might be useful let me know.

Cheers,

Dave

[peter_4059 (Peter)]

The new tab layout looks good Dave.

I've been playing with the temperature compensation and with the filter presets tonight and have a question about how these interact.

I would have thought the desired behaviour would be to allow the temperature compensation to take care of the absolute position during the night and for the filter offset to look after the difference from one filter to the next ie:

1.I focus on the Lum filter at the start of the night at say absolute position 3500 and set this as reference. Offest for this filter (filter 1) = 0
2. Temperature compensation moves the absolute position as the temperature drops (in my case the absolute position is increasing=focuser in). Assume the absolute position drops by 20 steps to 3480.
3. I change to the next filter say red with an offset of 10 steps relative to the lum at constant temp by clicking go for that filter. I would expect the absolute position would move to 3480+10=3490.

I think what is actually happening is the focuser moves to ref+10=3510. This means I would now need to refocus for filter 2 as the reference position was set at a higher temperature. The same would apply for each filter change if the temperature changes.

Let me know if I've got this all wrong

[dtrewren (Dave)]

Morning Peter,

Yes the behaviour you have described is the current operation. So when you go to a new filter position you will lose the current temperature offset.

It's a tricky problem because there is no mechanism to pass back from the driver to the client the offset. It is only possible to pass the current absolute position. Therefore the client is going to have to work out keep track of the offset generated by temperature and then add the offset to any subsequent filter position. This new corrected position now becomes the new temperature reference point for the future calculation of accumulating temperature offsets.

I have had a bit of a think about it and come up with a mechanism. I think it might be a good idea to have a new metric on the client displaying current temperature correction as a +/- value. So this is the value that gets added to any 'Go' position the user selects. This value is reset to zero if temperature compensation is disabled or a new reference position is loaded. Also there can be a reset button allowing the user to reset or change the compensation value manually.

So essentially as long as compensation is running any change of position with respect to the reference position will have a temperature compensation offset added to it. I will write driver code to calculate and keep track of the offset over time, this will be transparent to the user.

It's still a bit tricky, I'll have a crack at it tonight might take a couple of hours to get it to fly

By the way your replacement main enclosure is heading south.

Cheers & clear skies,

Dave

[dtrewren (Dave)]

Hi Peter,

I have thought of one small problem ......

There currently no way of differentiating between a temperature driven movement and a movement generated by the user moving the manual control. So with the tracking system I proposed in the previous email if the user were to use the manual control this would be misinterpreted as temperature compensation and added to the offset.

There is a way to stop this but I would have to change the PIC code and all the PICs sent out would need reflashing - something I really wanted to avoid. So I think a message will have to be displayed when temperature compensation is running warning the user not to use the manual control.

Cheers,

Dave

[peter_4059 (Peter)]

Dave,

Would it be possible/correct for the client to calculate new motor position as current absolute position - current filter offset + new filter offset. This would then take into account the current temperature offset and any changes to the manual control?

Peter

[dtrewren (Dave)]

Hi Peter,

Yes indeed that's good solution if you want to keep all the temperature & motor movement in the equation.

So if you have your filter offsets as say L, R, G, B hitting go on any of these takes you to that offset + temp + manual control. Hitting reference Go always takes you to that absolute reference irrespective of temp/manual offsets.

Sound sensible ?

Cheers,

Dave

[dtrewren (Dave)]

Hi Peter et al,

I have made some further modifications based on Peter's suggestions.

- By default when a filter 'Go' button is pressed the focuser moves to that filter offset relative to the reference position. However, if temperature compensation or the the manual control has taken effect that offset will also be a part of the movement. This makes it possible to move from filter position to filter position and preserve the cumulative temperature offset and/or any manual adjustment.

- A new checkbox has been added called 'Ref Lock' once checked this causes the focuser to move to the filter offset with respect to the reference position regardless of any temperature or manual control activity.

- Hitting the 'Go' reference always returns the focuser to that absolute reference position.

The current V1.8 version is available for download.

Clear skies,

Dave

[garymck (Gary)]

Hi Dave,

is it possible to have two of the focusers operating at the same time. Imagine a situation where you had one scope taking color, and another taking mono of the same object. Both need to be focused and temp compensation possible provided.....maybe need separate usb id's????

just dreaming a bit at the moment as I'm about to construct a mini roof top observatory.....

cheers
Gary

[peter_4059 (Peter)]

Dave,

That new version is working well. One small thing I noticed is if you click any of the focus control buttons on the client it resets the colour on the filter "go" buttons back to grey so you can't see which filter you last selected. Was this intentional? The movement of the stepper is still correct when selecting a different filter despite this.

I also had a couple of thoughts regarding the client tab layout:
I think the ref position controls would be better on the focus control page as this is the page you are most likely to be on when the ref position is set. Also the reference position will most likely be the lum filter and the go button for this filter is already on the filter position tab.

Once the ref position is set I will most likely switch to and stay on the filter position tab. It would therefore be good to have the temperature comp controls and temp display on the filter positions tab. Finally I think it would be nice to have the absolute position indication replicated on the filter position tab so you can see what's going on.

Just my thoughts - please feel free to ignore if you've heard enough bright ideas from me!

Peter

[dtrewren (Dave)]

Hi Peter,

Not at all, good suggestions based on real usage

I have incorporated your suggestions into the client and have uploaded V1.9 onto the website.

See what you think and let me know.

Cheers & clear skies,

Dave

[dtrewren (Dave)]

Hi Gary,

Apologies for the delay .... that's a really good question regarding multiple focusers operating at the same time. I have been sketching stuff out trying to figure out how it might be best achieved, also spoken to the guys that designed the ASCOM platform to ask their advice and got some really helpful feedback (as is the norm).

The bottom line is .... it's not all that easy as I get the impression the platform was not really designed to support such a feature. However, just because it's hard and probably won't work is no reason not to do it anyway plenty of head shaped dents in the wall disprove that !

I think the simplest solution might end up essentially a duplication of resource. So two motors and two controllers with two separate USB connections. Each controller is running the same PIC firmware but has a hardware jumper to select controller 0 or 1. You would also have to install two drivers one for each controller. Finally you invoke two client programs and select 'SharpSky 0' on one and 'SharpSky 1' on the other.

It's not ideal but I think it could be made to work.

It would be possible to use a single controller but this would obviously result in a complete hardware re-design. I don't know of a commercial product that provides dual functionality (anyone know of one ?) this maybe because there is low demand for such a feature and it would increase cost.

It is a very interesting problem ... I'll look into how much work is involved.

Cheers,

Dave