ckoos when the "temperature" falls from 25.2 to 17.7. Then again when the "temperature" rises from 16.3 to 22.8. Is that actually happening

The problem is that because of the cheap (undithered) DAC in the EAF, the EAF readings wil be oscillatory once you are in the 23ºC to 26ºC range (see original post by @SamoL). This will cause every frame to run through the autofocus routine if the delta is set less than 3ºC.

For what its worth, I need to refocus once every 0.5ºC on the FSQ-85 to take advantage of its very small spot diameter.

I also blind-refocus based on the actual temperature change. I.e., change the EAF step position based on temperature ∆, without trying to recompute a new V-curve (the ASIAIR has no provision for doing that, but most real programs do). It is practically impossible to do that in summer with ZWO's EAF without moving the bug out of the way (e.g., adding a 10 kΩ resistor).

Chen

SamoL @erossi

I just tested another way out of the dilemma last night, as long as all you need is ∆T, and not absolute temperature.

I ran a session last night comparing the temperature reading from the EAF internal on-chip sensor (the reading that you get from the EAF when you unplug the external probe).

The absolute temperature from the EAF microprocessor sensor is wrong (since it is measuring the die temperature of the microprocessor), reading about 8ºC higher than ambient .

However, as long as the air temperature is not changing too rapidly, the ∆T of ambient and ∆T of the internal sensor tracks to within 0.2ºC or so.

Chen

@tech@zwo#57338 We released the latest version EAF firmware, you can download it on this page.

How do your customers who use macOS and Linux fix this bug that was shipped by ZWO?

Can we send the camera back to ZWO to get the firmware updated at ZWO's expense? I currently have 8 defective EAF units that I would be glad to ship to you to get them repaired, if you would send me a prepaid UPS label.

There is also a question of why this was not tested before you started selling the devices? Are there other products that we should be aware of that also have not been tested?

Chen

P.S. If you open source the firmware updater, one of us could create a macOS version in very little time. @erossi : while the EAF commands and responses are USB HID (I see two different family of commands with WireShark), if they had not initailly done a good design, the firmware updater might not be HID based. But their code probably uses libusb -- if so, you should still be able to get a Linux build with an hour of work too.

erossi Anyway, let's see if the new tool is going to work.

At this point, I will let the other people be guinea pigs, and will apply the updater when they finally release it.

They can't expect us to help them test something, when they are placing road blocks along the way. It is not as if they are doing us a favor (although that seems to be their attitude). They don't appear to realize that they are asking us to do them a favor by being alpha testers.

As it is, this bug has been there (and reported) since the 12V EAF days. And they had never bothered to investigate it for years until a customer measured the behavior carefully and described the bug. And now they post a file to the Google drive (of all places) that nobody can read. Why are they expecting us to do their homework??

ZWO knows my email address for crying out loud (just this past week, I received email from one of their software team asking for some help related to spherical geometry -- it is not as if they have lost my email address).

If they had wanted me to help with the EAF bug, they could at least have the courtesy to email the firmware update package directly to me; or even better, the Xcode project for it since they know that I still write Cocoa applications in my retirement.

By the way, with just using ∆T readings, it looks like I can stretch the frequency of needing to do a full V-curve from every 0.5ºC to every 2ºC. But, I need to establish my own V curve, since the ASIAIR auto focus algorithm stops just as it enters the CFZ (often times even before it has reached inside the CFZ) and if the EAF movement is not reversed correctly, it gives you zero ∆T tolerance to maintain focus, or never be in real focus at any temperature.

Chen

w7ay You're absolutely right about the whole homework thing. This is unacceptable, @tech@zwo it's been two days and we still do not have any kind of access to the tool you've supposedly released. We're doing you a favour by testing it before an actual release, please be cooperative as we're willing to possibly brick one of our EAFs for "science" without asking anything back except a fix for a bug that has affected your device since day zero.

@w7ay as a side note, I'd like to thank you for everything you've been doing for the community here. Thank you so much. Had a chance to read up a bit of your background while checking other threads here and being a programmer myself I must say I am massively impressed. Congrats!

Another important topic that should be discussed is the absence of any recovery image for the ASIAIR Plus. I know there's a self healing script, but that does only reinstall and reconfigure the 8.83 deb packages for ZWO drivers, INDI, etc. There's no real recovery if something else breaks, i.e. the initrd image. Apart from the shady marketing of the self healing device, we just have a PI CM4 that can be easly booted into "eMMC rw mode" via the USB C port by running rpiboot from the CLI and powering up the ASIAIR while keeping the reset button pressed. Unix users can easly dump the eMMC image using dd (and writing it back too, making a backup was the first thing I did when I got mine), Windows users not so easily... @tech@zwo you should consider writing a tool to allow non tech savvy people to backup and restore the eMMC image, that would help quite a lot of community members.