SharpSky ASCOM compliant digital focuser project

[ernesto]

Hello, this is my first post here. My name is Ernesto and I live in Buenos Aires, Argentina.

First of all, I would like to say thanks to Dave for this very, very nice project (the best project I saw at this point related with my astro gear….) and all of this forum members for share your experiences.

I have built a controller based on the PIC18F4550 schematic found in the http://www.dt-space.co.uk/SharpSky/ page.
It is working very well, running with my setup (by the way: GSO 200 F4 OTA, Cooled Canon 400 XTi with IR filter removed, Lodestar for OAG guiding, NEQ6 mount with EQmod, MaximDL for acquisition).
I’m using a very cheap stepper motor attached to the reduction shaft of the focuser (shaft adapter made on a piece of aluminum) and it is working (unexpectedly for me!) very well, even autofocus and temperature compensation.

The only problem I have is with the PIC Bootloader function: when I follow the instructions (power up the controller with the pushbutton pressed) the PIC doesn't go to the bootloader state.
The LED attached to the PIN 20 lights and remains steady, and the controller is recognized as a HID device.

I noticed there are two .HEX codes on the page: one named ShapSky_4550.hex and other named SharpSky_3.1.hex (the last one from the ShapSky.zip file).
I tried with both hex codes on my board, but both of them are showing the same behavior.
I have also noted that the ShapSky_4550.hex code apparently starts at position 1000, while the SharpSky_3.1.hex code apparently starts at position 0800 (both addresses are related with the bootloader function…).

Other concern I have is that when I compile the project SharpSky.mcp, I don’t obtain neither the ShapSky_4550.hex nor the SharpSky_3.1.hex codes, but other different hex code.
My intention is to work with the right .mcp project and have the bootloader function working OK because I would like to introduce some additional features to the PIC code to control some of the functions of my camera cooler and the usb bootloader feature makes things easier.

It is important to say that I’m not an expert programmer, I’m not a young guy and this is my first try with PIC programming, but all of that is part of the fun for me…..

I’m sure that I’m doing something stupidly wrong, but I have tried different things and, so far, the bootloader function doesn't work.
Despite of this, everything is working very well.

Once again: thank you for this great project and thank you in advanced for your help.

My best regards,
Ernesto.

[Garbz]

I don't have any specific knowledge of this project but the PIC18F4550 has a protected boot address from 0000-07FF if the code you are writing starts at 0800 then you're not writing anything to the bootloader. You will need a program that runs in the 0000-07FF space if you currently don't have a working bootloader, and that's kind of the point, 2 programs running on the same chip where one can program the other.

Also of note is that it is incredibly difficult to get the same hex output when compiling code on a different platform. Different versions of the compiler or different compile time flags will product very different code which may still work exactly the same.

[alistairsam]

Thanks Brendan, Dave, I havent used the spray. that must be it. Got it from jaycar, will give it a go.

Cheers
Alistair

[mill]

I have just finished making the sharpsky focusser so it can handle 6Amps instead of 500mA by using 4 tip 41C's and 4 4001 diodes as spike protection.
The tip41 base of each is connected to the respective output of the uln2003.
All four emitters are connected to ground and the collectors to the coils of the motor.
See picture below.
just use the right bit of the schematic so only the transistors and diodes are necessary.

[Garbz]

What's the benefit of that? Are you maxing out the torque on the stepper?

[mill]

I am running nema17 steppers and they pull 1Amp per coil, the ULN2003 can only have 500mAmp and will fail when doing a focusing run.
Also this way i can take any stepper without problems.
The steppers that are sold with autofocus systems are normally pulling about 300-400mAmp max.
I also have changed my GC-usb stepper controller so it now controls a L298N board and can deliver 2Amps continuously.
By using about $10.00 in parts i will save two focus controllers in case something goes wrong with the motors.
To use the L298N board, i had to make the unipolar stepper into a bipolar stepper.
See here for the board --->>> http://www.ebay.com.au/itm/161340669008?ssPageName=STRK:MEWNX: IT&_trksid=p3984.m1439.l2649

[ernesto]

Hello Chris, thank you for your comments.
You are right about how the bootloader and the protected boot addresses work.

It is also correct that two different versions of the same compiler (even the same compiler, because some things like the optimization features can be enabled or not) will produce different hex codes and both of them will work as intended. My initial doubt was about if the mcp project was the source used to build the SharpSky_4550.hex or if it was used for other firmware release.
I believe that this .mcp doesn’t correspond to the SharpSky_4550.hex, because compiling that project doesn’t produce (at least for me) a .hex code that works properly with my board, as the SharpSky_4550.hex does.

Anyway, before going to do any modification to the code (that job will be a long trip for me…), my first two problems are that I can’t make the bootloader function works as intended (pressing the pushbutton and turning on the controller) and that I’m not sure if the .mcp file reflects the current firmware code or not.

When I program the PIC 18F4550 with the SharpSky_4550.hex file, all things work perfectly (manual control, usb communication to an ASCOM enabled program like MaximDL and Focusmax, temperature compensation) and only the bootloader function doesn’t work.
I’m not sure if the SharpSky_4550.hex supports the usb bootloader or not or if I’m doing something wrong.

So, summarizing my very long (and surely confusing comment, remember that I don’t speak English…) my two questions are:
_ Does the SharpSky_4550.hex support the usb bootloader feature?
_ Was the .mcp file the project file used to build that .hex code?

My best regards,
Ernesto.

[Garbz]

I don't know enough about the project to say anything conclusively but it appears as though the SharpSky_4550.hex file is designed to be flashed via the bootloader software. If this is the case then it can not possibly include a bootloader itself because the entire principle of a bootloader is that it can write program memory not assigned to itself.

Anyway a bit of searching and it looks like you need to get MCHPUSB flashed on your chip first. What I don't know is if there was any customisation done to MCHPUSB or if you can simply follow any of the online guides of how to do it. It would depend on the hardware (specifically the pushbutton to fire up the bootloader). Then once the bootloader is working you should be able to use the bootloader software to flash SharpSky_4550.hex

Hopefully someone more familiar with the project can chime in. This is about where my knowledge with PIC comes to an end.

[wasyoungonce]

Yep this. I believe the PIC18F2550 uses a HID boot loader and the PIC 18F4550 used MCHPUSB boot loader. I believe the MCHPUSB is the generic Microchip one.

Dave Trewren (http://ukastroimaging.co.uk/forums/index.php?topic=55287.0) might be best to ask about this.

[ernesto]

Yes, you and Garbz are right.
Last weekend I was able to make the bootloader works and load a simple program that I wrote. But, when I try loading the SharpSky code something fail. I believe that I'm missing some details with the configuration bits or something similar....I need to study a bit more :).

My best regards,
Ernesto.

[Garbz]

Again I'm not sure about the the PIC architecture, but I know typical AVRs have a bootloader reserved memory which is customisable in size using fusebits. If the program memory starts at the wrong location or is the wrong size compared to the bootloader then it will fail. It's easier on the AVR since the bootloader is at the end of the memory not at the start but it could very well be that the code is jumping to the wrong starting memory address.

In any case nearly every bootloader I've worked with can be configured in various ways and you'll find one specific way that is needed to work.

[jwoody]

Hello everyone
Is it possible to use my sharpsky kit control box on a moonlite high resolution motor? Or is the pin out of the 9 pin plug different.

Thank you
Jeremy

[wasyoungonce]

Jeremy

Sharpsky pin configuration is exactly the same as Moonlite and robofocus systems. This I know I worked with Dave (the designer) testing this.

I use a sharpsky with a ML hi-res clutched stepper...works a treat.

Brendan

[jwoody]

Thank you Brendan, I suspected it did (the pro version does ) but wasn't sure about the kit version.
Cheers for that
Jeremy

[dtrewren]

Hello Jeremy,

Brendan is 100% correct.

SharpSky is pin compatible with MoonLite focus motors.

I decided early on in the design to make the D-type connection pin compatible. You may need to adjust the period per step setting in ASCOM setup window. I would start at a value of 8ms/step and then adjust to taste. If the value is too low the motor may skip steps and if the value is too large the motor will simply be slow. You may also need to tweak the backlash value to suit the MoonLite motor.

Brendan do you have some suitable values for Jeremy ?

Let us/me know how you get on.

Cheers,

Dave

[Shiraz]

I just switched over to a Moonlite - currently using 40ms steps and 10 for backlash and it works fine if any help. On an f4 scope, I am using 9x6-step increments with the SGpro focusing software.

must say Dave that you did an excellent job designing this gear - mine has worked flawlessly since I got it and being able to use the controller with a Moonlite mechanism is icing on the cake. thank you.

[wasyoungonce]

I found at the initial period per step, 35ms, that the ML motor is-stepped. I had to adjust this to 50~60ms, for period per step.

Backlash...sorry not at lappy atm but ~10 steps is about right...although, this is a guess I suppose I should actually use a dial test meter and measure this.....Meh...no!

Edit:
Should also say that +5V is routed out unused pins on the DB9 connector so you can hook up a temp sensor near the motor, if you want. Of course the temp signal is also routed thu the DB9 as well. But these are unused pins on the ML system so this will not interfere.

[dtrewren]

Evening guys,

Thanks for the positive feedback Ray, always nice to hear guys are enjoying the design and it is working well :)

As an aside if anyone would like to perform a SharpSky self build I am still more than happy to supply pre-programmed PIC microcontrollers. The beauty of microcontroller design is that the hardware is generally quite straightforward to build (see the schematic) - the days of complex discrete digital are long gone.

Cheers for the info Brendan ! The temperature sensor used for the SharpSky kit version is the DS18B20 single wire Dallas interface sensor. so if you are using a MoonLite motor a temperature sensor can be added in if you wish (quote Brendan). Power, ground & data is all you need - the SharpSky firmware will detect the temp sensor automatically and inform the client.

Cheers,

Dave

[Shiraz]

thanks for the info Brendan - have upped the pulses to 50ms.

if of any interest, the step size on this Moonlite Newtonian focuser is 4.1 microns, which is perfect for the 40 micron focal zone in my f4 scope. At 6 steps per focus unit (ie 25 microns), the SGpro software generates very nice v curves and focuses as well as I can.

[wasyoungonce]

Hi Ray, yep that's pretty good, but might be a little short on steps in CFZ when using filters. We know that shorter FL scopes require more steps in the CFZ simply because they have tighter CFZ's.

If this becomes an issue, the ML stepper is as Hurst motor. The std Hurst fitted to ML's is the LSG35012F76P , 3600 steps per rev. You can increase to steps in the CFZ by replacing the motor with either of these Hurst units:
A Hurst LSG35012E84P, 5400 steps per rev.
A Hurst LSG35012E90P , 7200 steps per rev.
A Hurst LSG35012E98P, 1440 steps per rev.

You would have to do the math on step size and steps per CFZ but suffice to say, if you have 40 in the CFZ using the std motor then you would double this with the 7200 step motor.

Of course, too small a step and it will become slow and probably unmanageable.

[jwoody]

Sorry for the tardy reply but thank you all for the info, the moonlite works a treat with the Sharpsky kit.

A little off topic but.....could you make a DIY rotator using sharpsky kit? Perhaps some sort of belt drive system. Just thinking out loud incase you are wondering what the noise is.

[dtrewren]

Evening Jeremy,

Excellent, very pleased you got everything working with the MoonLite - a very nice piece of kit beautifully made.

You could use SharpSky as a DIY rotator after all it is essentially a computer controller motor. The hardware could stay basically as it is. However, at the moment the driver exposes itself as an ASCOM focuser not a rotator so the driver would need re-work to expose itself as a rotator. Currently, the SharpSky focuser driver is only designed to operate as a single instance and having two focuser drivers operating simultaneously would cause some software confusion. So the options are to make a simple mod to the driver to allow two driver instances to operate together or re-work the driver more extensively to expose itself as a proper rotator instance.

Hope that makes sense ?

Cheers,

Dave

SharpSky Innovations

[jwoody]

Hello Dave, thanks for the information.
I suspected that having two controllers would cause problems but thought there might be a simple way around it.
I shall do some more research......
Cheers
Jeremy

[Shiraz]

Really grateful for any help. Had the kit SSF running fine under Win8.1 and then accepted the Win10 upgrade. Still went perfectly. However, Win10 fell over for other reasons and had to be "reset" which reloads the OS and turfs out all the apps (keeps data files though). Am in the process now of rebuilding the automated astro stuff and have everything running fine, except for the SSF. I have Ascom driver 3.15, client 1.17 and have loaded everything with admin priv. A DLL appears in the right place and the client says it is connected to the focuser, but the focuser just does not move - works alright with the rotary encoder though. Nothing doing with SGPro either. One thing I did notice was that the max step length is now 30ms -my vague recollection is that the original system allowed longer steps.

Can anyone think of anything I might do next or can anyone see what I have done wrong? - do I need to reflash the PIC to get it to work with the current software? Looks like I might be putting my old Vista system back into service if it turns out to be Win10 fussiness.. Thanks in advance. Ray

[dtrewren]

Morning Ray,

Dave here (SharpSky designer).

That is an interesting problem, however all sorts of crazy stuff can happen when an operating system goes over.

You don't need to re-flash the PIC microprocessor - it has no concept of being connected to Windows or any other operating system for that matter. The PIC only sees the USB connection and only sees the driver and ASCOM interface.

First of all when you plug in the SharpSky controller do you get the characteristic noise (ding-dong) from the PC and the Link LED goes out ? This indicates the PC has identified the SharpSky controller as a generic HID device and subsequently enumerated.

Assuming the above :
Following a re-boot uninstall the driver via the windows control panel. Check the .DLL has been removed and if not delete the .DLL

Now re-install the driver as normal.

Try connecting using SGP - does SGP actually say that it is connected ?

Let me know how you get on and we will go from there.

Cheers & clear skies,

Dave

[Shiraz]

thanks for the quick response Dave - really appreciated.
. I will not reflash the PIC - that's good
- get the "boing" on connection - it sees it as a USB peripheral (family something?) not actually in the HID list. I didn't wire up the link led.
- have done the uninstall - reinstall, reboot a few times to no effect. It seems to clear the DLL from the uninstall region OK
- SGP says it is connected to the focuser - seems quite happy, but just doesn't do anything
- I just fresh installed ASCOM 6.1 and SS software on my old Vista system with the same result
- also bypassed the USB HUB and connected a (brand new) USB lead straight into the SS box with no result.

I don't know enough to make sense of this, but it seems to me that everything ASCOM is working OK (the filter wheel, cameras, mount etc) and the box is working OK (heartbeat and via encoder) - there just does not seem to be any comms between the two. Just so I am clear, the ASCOM driver does everything necessary to interface between ASCOM6.1 and the box - there is no other lower level driver? If of any help, a while ago I tried using the latest software, but had to revert to an earlier driver to get it to work. However, that was two operating systems ago and those versions of the software are long gone. The current driver is not the software that I was running before it all went pearshaped - the max step size definitely was larger than the current 30ms.

another observation that may be significant is that after a fresh install, the first try to move causes the screen to flicker slightly as it does when working. thereafter it remains dead - as though the software is dormant and waiting for the box to tell it that the original move is finished maybe?

Anyway, don't sweat too much on this Dave - I have well and truly had my money's worth from this great bit of kit. Regards Ray

[dtrewren]

Hi Ray,

Thanks for the analysis.

Sounds like there maybe something else not correct. As you have now tried on a Vista machine and are getting the result I suspect the issue is not with the new Windows 10 OS but something else.

As a matter of interest which PIC firmware version so you have installed ?

If you want to return the controller to me I am more than happy to have a look and sort out any issue.

Cheers,

Dave

[dtrewren]

Hi Ray,

Looking back at my spreadsheet I see that your SharpSky unit goes back to 2012. Depending on whether you have updated the PIC firmware since 2012 there is possibly a driver dependency. This is not an operating system issue but a dependency between the driver and the PIC firmware.

I would re-flash the PIC firmware to the latest version from the website. From memory the latest version is V4.1, I will check when I go out to my workshop. I have a hunch this maybe the problem.

Cheers,

Dave

[Shiraz]

its still the original:thumbsup: - I will try reflashing it.
Thanks so much Dave. regards ray

[Shiraz]

:thumbsup: woohoo!! You are a legend Dave. The reflash fixed the problem and the moon will set in a couple of hours.

Thank you very much.

[dtrewren]

Fantastic !

About eighteen months ago I increased the bit width over the USB interface for maximum focuser excursion from 16 bits to 24 bits and I think that would be the incompatibility. I think I sent an email out recommending an upgrade - if I missed you off I apologise !

Good job,

Dave

[Shiraz]

Thanks Dave - I probably got the email, but ignored it because my system was working fine and I didn't need more focuser extension.

Should anyone else need to do it, the following is a summary of what (I think) is the procedure/links for upgrading the whole software suite when using a box with an old version of the firmware - grateful if you would correct if wrong.

If you have previously used an old version of the ASCOM driver, uninstall it using the uninstaller that should be on your PC in:
\Program Files (x86)\Common Files\ASCOM\Uninstall\Focuser\Sharp Sky

The ASCOM driver software, and also the firmware bootloader + hex file, along with installation instructions, are at http://www.dt-space.co.uk/SharpSky_Kit/. You will need the rotary encoder to activate the bootloader.

The client software is at http://dt-space.co.uk/SharpSkyClient/