Are there any tests I could do to further improve the existing driver?

Clear Skies!
Thorsten

I'll check everything you reported tonight and let you know that new version is ready. Peter

The device we will be hooking up to has a mips32 processor, and doesn't use glibc. It's difficult to use a binary only blob that is compiled for x86 processor and dynamically linked to glibc in this environment. It wont run on the processor we are using.

Before we bought the usb-focus, I had asked the vendor for the protocol and got a document without any restrictions with the intent of putting a driver into the svn. We ended up moving shortly after that, and the astro gear has all spent a couple years in storage since then, so I haven't committed anything new for a couple of years. I'll track down the info I got back then, and put something together here over the winter.

As I said, it is up to you I asked and this is the answer, I have to respect it:

The document I sent is not public and will not be. Anyway I distribute it freely to any software developer who requires it.
It is a way for me to be aware of which software supports my controllers.
Thank you for respecting this.

It's a focusser, not a lot of complicated function, even if one decides to work it out from first principles. I did that a long time ago by snooping the usb bus for the FC-USB, it was rather trivial compared to devices I have done in the past.

I normally wouldn't do it the hard way, but, maybe to avoid any possible ill feelings, since it's a relatively simple device anyways, I'll do this one the hard way with a snooper on the usb bus, figure out the protocol, then I can write anything I want for it, and put it anywhere I want. When I did originally ask the folks there, they did say 'yes' to putting a driver into indi, and I had planned to do it a long time ago, but life got pre-empted here and we had to set all the astro stuff aside for a couple years, just getting back into it now.

I just hunted thru my old emails, from initial conversations about the device, here are the relavent snippets:-
===========================
Yes go ahead.


Best regards
Vincent


>
>

---

Original Message

---

>
> From: Gerry Rozema
>
> Sent: 01/07/13 05:29 PM
>
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
> Subject: xxxxxxxxxxxxxxx
>
> If we submit drivers to the indi repositories, ie, make them publicly available, the protocol is easily figure out from those drivers. All indi submissions are in source code form.
>
> Please clarify on this, do you want drivers made public, or not ?

======================================================

Hi Thorsten, I tried it (with Ekos) in INDI VM 1.3 and this driver: download.cloudmakers.eu/usbfocus-0.4-amd64.deb

Property saving is working as supposed, you have to click on Load button on Options tab to load saved values (in control panel).

Focuser can be controlled from control panel by setting relative position. How fast is focuser moving is controlled by Speed property. Is it what doesn't work for you?

The last issue is probably some Ekos issue, Jasem is working on it.

Peter

KStars options had selections for all telescope and focuser ports..etc. I actually removed that from INDI options and made all INDI devices load the port from configuration file on startup. So that resolves #1.

For #3 I resolved the issue when using relative focusers. The next kstars-bleeding should have the fix.

Something to keep in mind when using a focusser that takes its power from the usb port, is power requirements.

As an example, we have a few FC-USB gadgets here. If I have the FC-USB plugged into a port that doesnt give the full 500ma available on a usb port, which is the case with many hubs, and with all unpowered hubs, then it wont operate correctly.

We spent some considerable time hunting for a good 7 port hub that will fully power all 7 ports, for exactly this reason. The worst case for us, was with the QHY5 guide camera plugged into the same hub as the FC-USB. Both devices require FULL power from the usb port, and, no matter what I did, if we ran the focusser while the qhy5 was grabbing frames, the camera would get sick, and require an unplug/replug restart.

We eventually fixed our stuff so that programs enforced a separation. It would never allow the focusser to move while camera was active, and would never allow the camera to grab a frame while focusser was active.

The focusser in question for this discussion is powered by the usb plug, so, that's the first place I'd look for problems that show up in one location, but not in another. Is the focusser getting full power from the plug its plugged in to ? Very few usb hubs will deliver 500ma to all ports. I was walking down the aisle in walmart some number of years ago, and saw a 7 port hub that had a 3.5 amp power supply, so I bought one to check. Took it home, plugged everything in, and it all 'just worked'. I went back right away, and bought 2 more.

If you are using an unpowered 4 port hub, most of them work the same way. They take 500ma from the host, then divide it across the 4 available ports, so each port can only get 125ma tops. Then a lot of them come with a 1 amp supply for a 'powered' hub, and they are not smart enough to give one port 500, then another port only 125. On top of that, a lot of gadgets dont correctly negotiate power requirements on the usb port anyways, the end result is, with a 1 amp supply on a 4 port hub, each port still only gets 250 ma. If you want to be absolutely sure all ports have 500ma available, you need to source a powered 5 port hub, that comes with a 2 amp or higher power supply. Or, as in our case, a 7 port hub that came with a 3.5 amp supply.

You can eliminate this from the test situation, by plugging the gadget directly into the computer port, with no hubs in the equation. BUT, if you use extension cords to make it reach, they often bring in the same problem.

Quite some number of years back, I spent a lot of time fussing to get this problem licked. We were using a couple long active usb cable extensions to get from computer to telescope, then a powered 7 port hub at the scope. A 7 port hub is internally 2 4 ports daisy chained, and each active extension cable is in itself another hub. You can only daisy chain a maximum of 4 hubs in a system, and that's what ours ended up looking like. 2 'hubs' for the extension cables, then 2 more in the 7 port gadget. After going thru a considerable number of trial and error equipment swaps, we did end up with a configuration that worked, and worked well.

BUT, this is exactly the reason we are doing it all different now for our new setup. Small embedded computer at the telescope stand, with ethernet back to the hosts where all our software runs. the final configuration will use an embedded system that fully powers all the ports, and will have enough ports available to drive all of the telescope gadgets. With an indi server running there, all problems solved.

Yes, I have similar experience. But I found, that hubs can usually provide 500mA or more on all ports if better power supply is used.

Nevertheless I ended with small computer on the mount as well. I was trying small windows computer, couple of ARM microcomputers and finally the best and only reliably working solution was MacMini

Peter

I just did install the 0.4 version of the usbfocus driver as well as an update to the latest PPA packages (looks like build 227).

I must have installed some problematic packages, since I get:
As well as:
I think I will have to wait for another build of all the libraries, or is there anything else that could cause such errors?

Clear Skies!
Thorsten

Yes, looks like wrong dynamic library. I'll make statically linked executable... Peter

Please, can you try it again? Hopefully no dependence on INDI libraries now... Peter

download.cloudmakers.eu/usbfocus-0.4-amd64.deb
download.cloudmakers.eu/usbfocus-0.4-amd64.rpm
download.cloudmakers.eu/usbfocus-0.4-i386.deb
download.cloudmakers.eu/usbfocus-0.4-i386.rpm