tekkydave

I've ordered one to have a play with http://www.ebay.co.uk/itm/401020862739

Can't argue with that. BT is the obvious choice for ptp.

Thanks, I'll look into that. I bought the xbee a while back out of curiosity so decided to do something with it. They are a bit pricey though.

Thanks, I'll do some testing with that.

Thanks, that looks really useful. The com2tcp and tcp2com utilities I used for the wifi project allows you to define a virtual com port of a set number. I was using COM10 just as an arbitrary value. Do you have a BT dongle that presents itself as a COM port? Mine appears in the device manager as a network adapter.

Thanks Gina. I was prompted to do this by the prospect of all the cables I would have to run from my obsy/shed to the pier. If I can get the Celestron mount Wi-Fi working the only cables I will need is 12V power and USB for the camera (ZWO ASI120MC or Canon 1100D). If I get the Wi-Fi working I'll start a separate topic for it.

I decided to have a go at interfacing the focuser using bluetooth. I bought a couple of HC05 modules and set them up as master & slave devices and paired them to each other. When powered on they will now auto-connect to each other. Then I breadboarded up the focuser as it exists at the moment and added the HC05s. The master is connected on 2 spare pins and accessed from the sketch using the SoftwareSerial library. The slave is just connected to another COM port via a USB to serial converter. I modified the sketch to enable it to use the native USB port or the HC05 for its serial connection to Ascom. Tested with my FocusAAF2 utility and it all works beautifully. I now need to decide how to package it all up. I need to make a few further changes to the sketch to make it backward-compatible with the existing focusers then I'll release it on the SF site. I also want to look at using a USB bluetooth dongle plugged directly into the PC rather than using 2 HC05s but it needs some testing as a virtual COM port will need to be used. I have been playing with a utility called TCP2COM/COM2TCP that creates virtual COM ports and routes them to a TCP connection (e.g. 10.20.30.40 port 8000). I have it working with a WiFi XBEE device Im trying to interface to my mount but bluetooth is a different kettle of fish.

That's a neat job. Thanks for posting.

Can you post a picture. I'm interested in how it is mounted to the scope. Thanks.

Ha ha. Easily done mate

Just for clarity then, the last release on my Sourceforge page at https://sourceforge.net/projects/arduinoascomfocuser was V2.4.0 on 19th April 2015. I haven't made any changes since then. At the moment I'm not planning to enhance it further but obviously anything added by others here is all welcome. My SF project has been downloaded 4,157 times and I know at least 25 SGLers have built one which is amazing really. I never though anyone would be interested

Don't feel guilty. I want people to use and experiment with my code and build on it. I was just concerned that anyone reading this in the future might get confused about which bits were part of my original SF project and which were your wonderful improvements. I remember looking at the SGL focuser project when I first started looking at building a focuser and how confused the project had become. I never managed to work it out so built my own. I don't mind if you want to carry on posting in this topic

Good work. Are you using my sf sketch or a modified version? I'm a bit nervous that these 2 projects are becoming confused. Maybe the latest bluetooth aspects should be in a different topic to avoid confusing other readers.

That explains it. Mine has a separate ring which tightens the tube against the end of the threaded part on the OTA. I'll have to come up with a more fiendish design I think.

Thats a nice print calli. One question - when you tighten the central optical section (cant remember the correct name for it) down on your printed part does the tube section still turn. I tried a similar method to mount my focuser and it wont tighten even if the print is only 2mm thick. The tube section that the diagonal fits in is still loose and flopping about.

I did buy them when I was working so cost wasn't an issue - it would be today

I've used these http://www.homechip.com/1-wire-controllers/sensors/ms-th-temperature-and-humidity-sensor.html from Homechip for temp & humidity both outside and in our greenhouse. Nice but at £40.52 a bit pricey. They have an RJ45 at each end for easy daisy-chaining.

The ascom driver acts mainly as an interface between the client (eg ByeOS) and the hardware/controller (eg arduino). If the client doesnt have the facility to do the backlash comp then the best place is to add it is the arduino sketch. Simplest is to set up a variable with how many steps to take then at the point where the target position is reached just step that many steps in the opposite direction. Hope that helps.

I have Tim's book aswell. From memory his code is all Java using the Maxim libraries. You can certainly re-use the algorithms though.

I think a couple of others have asked the same question before. I don't know if anyone succeeded but a search of the topic may find an answer. I think the easystepper uses step/direction pins rather than driving the coils individually. It should be possible using my sketch if you modify the clockwise() and anticlockwise() functions to pulse the correct pins on the nano. Maybe you could steal the relevant routines from the SGL sketch and substitute them for the clockwise() and anticlockwise() function calls.

The temperature compensation is normally done by the client application so you will need to find an algorithm and build it into your app.

Could your app set a target using the T# command then call M# in a loop until it responds M0 indicating it has reached target position. Or even call P# to check the current position until it matches the target. This would avoid breaking the way the existing driver & sketch work. The Ascom drivers are designed to be async. I don't have a a version that uses async it was just a method I used when I started the project which was discarded.

Hi calli, That's all looking great to me. I originally had the move (Tnnnn) command waiting for the focuser to get to the position before returning to the calling program. The problem is it blocks the driver from any other comms with the nano. I suppose for short moves it doesn't matter but I decided to just send target positions and let the nano do the work asynchronously. I like your motor mount - it might be worth uploading it to Thingiverse as I'm sure others would find it useful. I have yet to design & print a bracket/mount I am happy with. Also, don't worry about being compatible with any of my code. I did the project as an experiment in Arduino and Ascom programming to get to know the environments so please feel free to borrow or steal any parts of it you find useful. If you think it's useful to others put it up on Sourceforge as a project. I have had mine downloaded by people all over the world, not just SGLers.

Hi Dan, Glad you like it.

I bought a selection to cover all eventualities. Make sure they match the pulleys you get