Anyone have a Xagyl filter wheel?

[JamesF]

I'm after finding out what USB vendor ID and product ID are reported to the OS when it is plugged in, and also what serial number the FTDI chipset reports.  Hopefully it should be easy to find out in Windows from the Device Mangler or from dmesg in Linux.

I was under the impression these were the same for all their filter wheels, but I've just replaced the PCB in mine and they're completely different, which means more research is required so I stand a chance of being able to support them with my capture application.

As soon as I can find a Windows machine to plug mine into i'll find out exactly where the details show up.

James

[stoffe]

Hello, I got a Xagyl 5-pos filterwheel that is unmodified. I can check my vendor ID and product ID when I am home after my working day. But JamesF, you are running Linux right? It should appear when you run lsusb command or dmesg | grep usb. I know that the earlier motherboard on the Xagyl wheels do not have the FTDI USB->RS232 converter implemented. I would be glad if I can get rid of all USB->RS232 converters. I got many free real comports on my telescope computer

[rwg]

Hi James,

I write the ASCOM drivers for the xagyl wheels, so have some inside information

There are probably several different VID/PID combinations as the wheels have gone through different revisions - the very early ones had a special USB like cable that had the USB/serial built in - can't find that cable at the moment, but will try to dig it out.

My 525 wheel with latest PCB has this ID :  FTDIBUS\COMPORT&VID_0403&PID_6015

I have a 2" wheel around the place somewhere - will look this out too.

cheers,

Robin

[rwg]

Ok, found the 2" wheel, which has ID

FTDIBUS\VID_0403+PID_6015+DA00BT4MA\0000

so the VID and PID are the same, but this one has a serial number too by the look of things.

Still haven't located the cable, sadly it looks like any other USB cable except the plug is about 1cm longer, so it hides very well!

cheers,

Robin
 

[JamesF]

I am running Linux, yes.  What I have discovered thus far is:

As I originally had it, with the FTDI USB->serial converter in the cable (what Xagyl call the V1 5125), the FTDI converter gave a VID/PID of 0403:6001 and also a serial number of A4008T44.  I'm told the serial number may not be unique, but may be set by FTDI on a per-application basis (eg. all V5125 wheels may have the same serial number).

When my V1 PCB died I replaced it with a V2 PCB.  In the V2 model Xagyl moved the FTDI chip inside the wheel so it can use a standard USB cable.  At the same time the VID/PID has changed to 0403:6015 and the serial number to DA001CEZ.

I gather there's also a V3 5125 PCB as well, so I'm half-expecting the details for that to have changed and perhaps there's no reason for the 8125 and the 5200 wheels to have the same values either.

James

[stoffe]

Could it be your FTDI adapter to your V1 PCB that died? I am just guessing. Why do you need the vendor and product ID? Your filterwheel should be accessable trough /dev/ttyUSB0 or similar if the kernel module loads correctly.

[JamesF]

I think it was the motor driver circuitry that died.  I can still connect to the FTDI part using my old cable and send it commands that don't involve the carousel, but the motor wouldn't turn at all even under zero load.

I want the VID/PID because I can then make a half-decent attempt at identifying exactly which device node is the serial interface for the wheel.  It's possible that an astro-imaging pc may have a number of devices with USB->serial converters connected and if I can scan the USB bus and find the one which is a filter wheel then I know exactly which device to open without relying on the user configuring it, or even on it being the same device node each time.

James

[JamesF]

Aha!  Just found some documentation on the FTDI website saying that hardware manufacturers should either obtain a device-specific PID for their product from FTDI, or use the default FTDI VID/PID of 0403:6001 with a unique serial number for each device (though the wording leaves it unclear as to whether that means each individual device or each different type of device).

So it may be that all 0403:6015 devices can be relied upon to be Xagyl filter wheels and i'll just have to see how it goes with the V1 wheels with the USB->serial converter in the cable.  Perhaps there's some sort of common range of serial numbers for that version even if they're not the same.

James

[JamesF]

I want the VID/PID because I can then make a half-decent attempt at identifying exactly which device node is the serial interface for the wheel.  It's possible that an astro-imaging pc may have a number of devices with USB->serial converters connected

Just come across an example where this might happen.  The Atik 16-series cameras use an FTDI serial interface, so they would also appear as /dev/ttyUSBx.  If such a camera and a Xagyl filter wheel were connected you'd not know which device node was which device, other than by scanning the USB device tree or asking the user.  And each time they plug them in it might change.

James

[rwg]

You don't fancy just sending 'I0' (get hardware ID) then 'I1' (get firmware version) at 9600N8 and seeing if you get a valid response to each. That's how I detect a wheel on a particular port in the ASCOM driver.

cheers,

Robin

ps. my 5125 wheel is V2 PCB, so can't give you a specific on whether the V3 is different.

[JamesF]

You don't fancy just sending 'I0' (get hardware ID) then 'I1' (get firmware version) at 9600N8 and seeing if you get a valid response to each. That's how I detect a wheel on a particular port in the ASCOM driver.

That's a bit unkind if it happens to be some other device that the user doesn't want you fiddling with

I'm tempted by the argument that if a device should not be messed about with then some other application should have it exclusively locked, but wilfully sending data that might be regarded as invalid to an unknown device goes against the grain a bit.  None of which means I won't resort to that option if all else fails

James

[JamesF]

Bah

It seems that 0403:6015 is another generic FTDI VID/PID, not specific to Xagyl.

Your 525 wheel doesn't have a serial number at all, Robin?

James

[rwg]

No serial number on my 525, but it's a bit of a frankenwheel - the case is a prototype and the PCB and motor have been updated at least once, maybe twice. It's quite likely that my V2 PCB is a very early pre-production one and that real production ones all have a serial number.

cheers,

Robin

[JamesF]

Ah, fair enough.  I think there has to be some sort of associated EEPROM for a serial number to be present.  If you have a pre-production model then I guess it's entirely possible the EEPROM isn't there.

James

[michaelmorris]

I have one of the very early Xagyl wheels which appears to no longer work. I've been told by the manufacturer to try uploading the latest firmware from their website, but this just points to a text file with a long string of letters and numbers on it. I guess this is the firmware. It gives one no idea how to load it or what the risks are if you get it wrong.

The manufacturer said they would get back to me about my problem, but that was months ago and I've heard nothing since. My experience of their customer support is very poor to date and at the moment I would find it very difficult recommending these to anyone.

[JamesF]

That's a shame, MIchael.  They've been quite helpful to me, though they have been a little vague about some details which may be down to language issues.  Hence my digging for a few more details here.

If it's a very early model then I don't think the latest firmware would work anyhow.  I seem to recall that the latest version I could upgrade my V1 wheel to was v2.2.0 whereas the latest firmware release is 3.3.0.  The description of the firmware file sounds as I'd expect though.  I believe the (downloadable) user manual explains how to do the upgrade.  I think there is some weird thing where you have to upgrade to v1.9.9 first if you don't already have v2.0.0 or later, but other than that it was straightforward.

Should it still not work, Ian King may still have some of the replacement V2 PCBs in stock which I'd expect to fix it unless the motor has failed.   Mine wasn't expensive and just required the two motor wires unsoldering from the original board and soldering back to the new one.  It's a bit fiddly because they're very close together, but otherwise ok.  If you're not sure about doing it yourself then perhaps we can sort something out by talking to Ian and posting the bits to me.  Just don't expect it back next day  Or perhaps there's someone closer who could do the soldering job.

The V2 upgrade has the bonus of moving all the electronics inside the wheel, so you don't need the specific Xagyl cable -- any standard USB to mini USB cable will do.

James

[rwg]

I have one of the very early Xagyl wheels which appears to no longer work. I've been told by the manufacturer to try uploading the latest firmware from their website, but this just points to a text file with a long string of letters and numbers on it. I guess this is the firmware. It gives one no idea how to load it or what the risks are if you get it wrong.

The ASCOM driver contains a firmware update function that you need to point at this file. Having developed the firmware update functionality - and therefore 'updated' my wheel many times - I can say there is no real risk as long as you don't do anything silly like unplug the wheel while an update is in progress. Even then, the wheel firmware is in two blocks, a bootloader (which does the updating) and the main firmware. If the update fails then the wheel won't operate normally, but the bootloader will still be there to allow you to retry the update.

If you have a very early wheel it is likely that you have the version with the special USB-serial cable. If this cable has failed then obviously a firmware update will do no good, similarly if the microprocessor on the PCB has failed completely then there will be nothing for either the driver or the firmware update to talk to. If the wheel moves or twitches when plugged in, that's a good sign that the microprocessor (I think it's a PIC of some sort) is working. If it doesn't move but responds to the serial port then it may just be a motor wire come loose.

Do feel free to PM me with more details of the symptoms of your broken wheel and I will do my best to help work out what is going wrong.

Robin

[rwg]

Having had a bit of a dig through the bits box, I seem to have 3 spare V1 PCBs for Xagyl wheels. One I am fairly sure I have killed, one seems fine and the third can very likely be brought back to working order with a touch of soldering. I also have one of the Xagyl USB/serial cables spare too. I can't see that I've got any future need for these, so I'm happy to pass them on as spares to anyone who can use them. As James mentioned, the PCB transplant operation is very simple - just de-solder the motor connections from the old PCB and solder to the new.

cheers

Robin

[JamesF]

You do have to make sure the wires go back into the right holes, too  Replacing like with like is clearly no bother.  It turns out however that whilst the screen-printing on the V2 PCB suggests (with a little box in one corner of the marker for the connections) that the orientation may need to change, it doesn't.

James

[JamesF]

Well, bad news to report.  The new PCB seems to have failed in exactly the same way as the old one.  It was working happily last night, but tonight will no longer drive the motor

I've just emailed Xagyl, but at the moment I am not a happy bunny.

James

[rwg]

Oh no!

Does the wheel spit out any text over the serial port (either at 9600 8N1 or 115200 8N1) as it powers up? If it's reporting an error it might just be that it's a soft fail that can be fixed by tweaking the parameters or re-flashing the firmware.

cheers,

Robin

[JamesF]

Sending a cold reset (R0) command to the wheel I get:

Restart

Xagyl FW5125V2

FW 2.1.7

Initializing

Calibrating

ERROR 3 - Wheel stalled

ERROR 1 - Initialize failed to complete

I'm going to have a go at a firmware update after dinner.

James

[rwg]

Ok,

so that ties in with the wheel not spinning - as part of the setup it rotates until it detects the #1 filter position and then centers on that. After a while it gives up if it hasn't detected any positions go past.

Worth checking the wires to the motor - I had one snap off just above the PCB (this was after I had replaced the PCB and re-soldered myself, so probably just that my soldering whas shoddy).

Also do the firmware update as 2.1.7 is quite old - mine is on 3.2.7. It's just possible that some config option has got to an odd value and an upgrade might fix it (in particular the wheel can have the movement speed lowered using the 'S' command - In the ASCOM driver I limit the minimum value to 5 (50%), but the raw command will go lower - too low and the wheel doesn't move at all).

cheers,

Robin

[JamesF]

Aha!  You star, Robin

I upgraded the firmware, but no change.  So I started fiddling with what I could in the non-ASCOM control program.  The "Recalibrate" button moved the wheel.  Doesn't look like a hardware fault.  But it still wouldn't move on a reset.  From the manual it looks like the "movement" button should pop up a dialog box  that allows me to check the speed, but, oh dear!  It's crashed.

So I switched back to Linux and connected to the serial port directly and entered "SA" to set the speed to 100%.  Then "R0" to reset the wheel and it works!

Weird problem.  I wonder if there's some sort of noise when the cable is disconnected that causes the speed to be set to zero?

I did try to read the current speed in Linux, but before I could do a proper reset the firmware seemed to be giving odd results to commands and I couldn't get it.

James

[rwg]

Glad you've got it sorted now!

I know what caused the crash when you tried the movement dialog too - I was trying to set the slider to the current value for the wheel speed, but the slider only goes from 5 to 10, so if the value was out of that range it wasn't happy Better get fixing that...

cheers,

Robin