ZWO EFW Decompile or java version

[powerlord]

Hi chaps, I could have sworn I downloaded a java driver for the mac for the ZWO EFW, but it now appears to be native - c code.

Can't find the java one anywhere - and annoyingly I seem to remember coming across the decompile of it I did last year a few weeks ago and thinking 'don't need that - delete'.

However I now do - I really want to make a basic 2 filter drawer for my asi533 (lextreme/uvir) and try to make it zwo compatible to work with asiair.

Before I start down this, I though I'd ask if this is a journey already walked ?

Ideally I'd love the java version again, as that can be decompiled much easier.

However if not, I'll have to try and decompile the c. And again, if someone has done that before all the better.

Ideally I'd love it to be compatible with asiair and for that it needs to look like a zwo efw.

If that's not a goer, I'll make it anyway, as it's still easier building something and making it controllable as a seperate iot device or 433mhz RF or summit.

Use case here is galaxies mainly - where I wanna shoot with my OSC asi533 - uvir, and alsoo Ha. And don't really want to have to use my zwo 8 position efw for this, because then I can't use it on the other mount with my asi1600.

stu

[vlaiv]

32 minutes ago, powerlord said:

I really want to make a basic 2 filter drawer for my asi533

I'm really interested in this part.

How do you plan on making filter drawer automatic?

In any case, since I can't help much with original query, I can only suggest alternative - which might be easiest way to reverse engineer zwo efw protocol (which I'm betting is some sort of a standard).

Look up linux / indi drivers for zwo electronic filter wheel - they have to communicate via USB with EFW itself and you will be able to read the code and figure out the protocol without the need to disassemble anything (which might be against terms of use anyway).

[powerlord]

nah, they just use the zwo SDK. i.e. the public bit. you can't see the driver code. And it's that bit that talks to the HW. i.e. checks it matches the relevant product IDs, etc.

the automatic bit would come from being zwo compatible as it'd just look like say an 8 filter wheel and you'd use first 2 slots. and my thing will be arduino, mimic zwo, and flip between 2 filters.

ignoring the interface, and looking at HW/electronics - it's a choice I reckon between either a cheap chinese 5 filter manual thing and modifying it, or building from scratch - seeing as chinese ones are 1.25 thread, etc and I'd really want a 42mm in/out - as i can't see a way of doing that easily with this sort of thing as it's not even clear if the ends screw in or not:

https://www.ebay.co.uk/itm/125044577130

If I was designing, was thinking some sort of slide with the 2 filters in, and then a wee rc servo to move between them. make it all contained so no light gets in. that sort of thing? as just two, it could be stop to stop, so not need for fancy positioning.

back to interface, if can't act like zwo, itd be easy to work like an ascom job, but that's of no use to me, so wouldn't bother - I'd just expose my API either as an http api and have the thing on my network, or maybe just basic 433mhz control as its just '1/2' commands and then wouldn't need anything else - but it would need me to trigger the filter move rather than asiair via autorun or plan - which is far less good, but still a lot easier than having to go out at 2am and change the filter.

Surprised there's not a market tbh - maybe the easier thing is to suggest it to ZWO - with the popularity now of OSCs it's crying out for a simple 2 position slide/wheel - that'd cover 99% of the use cases most of use need.

stu

[vlaiv]

From ZWO website:

Maybe you could use HID sniffing software to see what sort of communication driver has with device. It must be pretty generic for HID device.

[powerlord]

yeh they are HID, but that doesn't tell you much really. it's a pretty wide family.

HID sniffing wouldn't get you a compatible device I don't think. And it's very low level. I think, if there's not an easy way in via decompiling it's probably more hassle than it's worth.

it still needs an ascom driver, which is on that same page. And again, that is zwo code - basically the same thing as the C SDK I was looking at, but with the ascom interface in front of it.

 

[vlaiv]

1 minute ago, powerlord said:

HID sniffing wouldn't get you a compatible device I don't think

If it talks like a duck and walks like a duck ....

Just make sure you respond the same thing over USB as is expected from ZWO EFW

[powerlord]

I doubt it's that simple. your expecting record/playback to work. anything that is temporal - time data, temp variable, nonces, etc, etc would all screw that up. I think it's very unlikely that would work imho.

happy to be proved wrong, but it's not a direction I'm gonna go in - I think your best bet is to see one side of the conversation in code (the decompile), and what it is doing with the responses. and go from there. even then, I'm not sure if the HID idVendor/idProduct are controllable via software of any kind.. if not then yer on a hidin' to nothing as us scots say.

If it talks like a duck and walks like a duck.. . then it's probably one of the 166 different species of Anseriformes.

 

Edited March 21, 2022 by powerlord

[fireballxl5]

Same need here,  533MC + two filters, LP and NBZ so will follow.  Good luck!

[powerlord]

will do, I've disassembled it, and the protocol is pretty simple. what i need to work out now is what hw i can get that lets me spoof vendor ids. esp32 looks promising. I think this will be a back burner project though - not summit I'g gonna be knocking out in a few weeks if I'm honest - low priority.

stu