QHY recently updated their driver, but the guiding is still NOT working. I simply connected QHY to my HEQ5 mount and manually issued 1000ms pulses from the INDI Control Panel. It moved in all directions (by watching the RA/DE from EQMod driver) but it wouldn't move a bit on SOUTH.

QHY claims that guiding pulses are working fine but it's not in my case. Can anyone with QHY perform a similar test and report their findings here?

Hi.

I have been having a go at the indi_qhy_ccd driver using my Orion Star Shoot Autoguider for testing.
I'm not on my dev machine now, so don't have all the spesifics, but i'll try to get all the details.

Test setup is:
In ekos guide tab i set Simulator-CCD-guider as the guider via QHY-CCD-5-M

In my setup it's east that is (normally) not moving.

So looking at the qhy_ccd.cpp code and comparing it with the ccd simulator code, then something is apperently different!
The simulator code seams to use position, as in where it wants the mount to point, while the qhy_ccd.cpp uses duration for the guide pulse.

So, kind of randomly i checked what would happen with fixed duration?
Changed theFor all the guide calls.

Still nothing in East. Tried 2000, and east was moving like the others.
Tried calibrating RA in guide tab in ekos, and RA calibration completed!

So i tried to start guiding, and fail. But i did learn something.
Looking at the guide control in indi control panel, i could see that guide pulses where being updated loong after guiding stopped.
At the end (east or west) and (north or south) ended at guide pulse 5000, witch is the limit in my setup.

Changed all the code back and added a duration += 2000 for east, and calibrated again. Same as above.

So i made a method in the qhy_ccd.ccp file that printed out guide direction, duration and time, before the ControlQHYCCDGuide(camhandle,x,duration) was called, and after.

What was clear was that the guide method was locked waiting for the guider to guide for duration, while to me it looked like the ekos guider was sending a lot of new guide commands that was executed when the previous returned.
One way that i could see this was when calibrating both ra and dec the star would be moving to the left in the image, then right (completing RA calib), then down (while continuing to move left), then up (while continuing to move left).

So i made an float array "pendingGuideDuration".
Each time Guide[east-sout-nort-..] was called i made them call the new method Guide(int direction, float duration)
If the pendingGuideDuration was > 0 for the direction that got a new guide call, i just returned IPS_OK, so it would not add to the direction.
During this the pending duration is kept up to date using chrono::time_since_epoch(chrono:time::milliseconds) or something close to that.

Tried calibrating guide in ekos "two-axis", and Calibration success! Tried many times and it works most of the times.
After the calibration is finished there are no new guide inputs in indi control panel, and the guide control is responsive if i add a input manually.

Unfortunately guiding fails within 5-10 seconds, and i can see new guide inputs being sent in indi control panel a quite a while after autoguiding has failed "and stopped"

All this has been a hackish way to test what is going on, and i might have made a lot of wrong assumptions, but the QHY5 / Orion SSAG is capable of moving the mount in all directions.

Not sure if it is, but hope some of this might be helpfull

Whoa! Let's take a step back ad make it simpler. In my case, I started Ekos with the following devices:

1. Mount: EQMod
2. CCD: QHY

So in your case, just select Celestron GPS for the mount.

Once connected, I then used the INDI control panel to issue pulses (1000 ms) and watch for RA/DEC changes in the Ekos mount module. These are direct pulses issued to the driver. When I used ZWO ASI or Lodestar, all the pulses result in expected changes in RA/DEC. Btw, I checked my QHY using PHD under Windows and it also couldn't guide south so it must be a hardware issue... and I haven't used the QHY in the field yet

Hi.

Have been installing and updating my new ONDROID C1+

I was going to test the new version of the qhy that you sad was out. Have not been using it for a few days, so i did a apt-get update and upgrade.
now i get the message
When i try to start indiserver. So i did a svn up on the indi-qhy source and libind. Rebuildt libindi, cmake on qhy. But when i try make i get

Not shure what has gone wrong. Probably user error! I did a make clean to be sure, and removed my edited files before svn up.

I did do the test with my edited code, before trying to update, and south did not do anything on one single 1000 pulse. But i have been able to move stars in all directions "simulated" using larger and multiple pulses. I will have a look at it when i get my ODROID up. Btw. My Orion SSAG has been used successsfully with windows + phd.

Any good threads about setting up the odroid?
triedand get
I guess buiding from source?

When I first started using indi, back in the 0.9x days, the qhy5 driver was a stand alone, the only binary it needed was camera firmware, so it woulda been easy to fix. Hope you didn't throw away all the old sources.

I see today, the qhy stuff seems to be full of binary blobs we cant recompile. If that's the case, then I guess it's time to junk our qhy cameras we have here as we update various pieces of equipment.

By the time we buy new cameras for two telescopes in the observatory, we'll have a rather large investment, that I dont want to go obsolete over time. I will NOT buy anything that requires vendor provided binaries to function, been there, done that, learned that lesson with a very expensive paperweight. Apply updates to the underlying os, and suddenly it all stops working, and one cannot recompile for the new setup. One ends up hostage to whatever comes out of the vendor.

I think the driver tree should be broken down into two separate trees. One for drivers that are complete, and a separate tree for those that require vendor provided binaries to run, ie incomplete sources. Device firmware that's just blindly loaded in, different story, as long as the host code is complete after device firmware has been loaded. I've already discovered in my work today, the new qhy stuff wont work on my target processor, there's no binaries for a mips based machine, so I'm left with either changing the target processor, or, changing the camera. Or ofc, I can go back to the older sources I have here, for a qhy5 driver that can be re-compiled.

I'm curious, is anybody packaging indi for Debian these days ? I would assume the qhy driver isn't included in any Debian packaging, as it wouldn't make the grade for 'free and open'.

QHY claimed that they will eventually open source their driver, but it seems now they retracted from this position. I don't know about Debian, but some packages for SBIG are available in Ubuntu. QHY is not alone however, you have ZWO/ATIK/MORAVIAN/SBIG in the same boat.

None of which are on our list to consider for camera upgrades here. I got an sbig as part of the telescope package we purchased a couple years ago, which I haven't used yet, and will likely sell off this winter. It's an ST10-XME with 10 position filter wheel, fully populated, lrgb, narrow band, and photometric filters. One of the problems I'm going to run into, as I have discovered this afternoon, I am compiling for an environment that doesn't include glibc, it uses uClibc instead. None of the stuff mentioned above will work in that environment.

Today's project is to get the latest indi building in an OpenWrt based build tree, targetting a mips based device which will be the new host for our all-sky camera after electrician is finished putting in power cables. In this case, I need to use that device for now, for a bunch of reasons I wont get into, but it'll be doing a lot more than just handling the all sky, that's just another task I'm putting on it. indiserver builds fine and the sx drivers build, so I think I'll be ok, and if not, there are sources, I can fix.

We do still have our qhy5 guide cameras kicking around, so after reading this, I think I'll haul out the old code for them, and re-create the driver that doesn't depend on broken vendor supplied binaries, just needs the firmware blob to go in with fxload. It used to work fine, so probably still does.

But this is a re-creation of an old wake up call. Once we have finished building the observatory, the next phase of the project will be to upgrade cameras for the telescopes. The sxv-h9 cameras were great for our older kit, but now we have substantially upgraded kit that can handle a much larger camera. I have to make sure my possible vendor list is whittled down to only those that dont depend on vendor provided binaries in the driver build. When we start looking at large form factor cameras, they can run north of $10K apiece, and we need two of them. I dont want to end up with another camera paperweight because a vendor stopped supporting the software farther down the road. I've been there before, thankfully it wasn't a $10K camera. When we buy these cameras, they are intended to be the 'retirement camera', ie, there wont be much budget to replace them farther down the road, so we want something that we can work with ourselves if need be. the bottom line for us, if they dont have full sources and info available, they dont make it onto the short list.

I second that and fully support Gerry's call for breaking down the driver tree. I own a QHY5 that today doesn't guide in Indi while the now unsupported driver qhy-old did work perfectly for me. Unfortunately it doesn't compile using current indi source anymore. BTW, indi_qhy_ccd + lin_guider DOES work, too. Shouldn't their code provide hints as to how the problem could be solved? But then, that thought might be naive. The last time that I put together a piece of code was back in the early 90s on an Amiga so I am afraid my ability to contribute in a meaningful way is awfully limited.

lin_guider uses its own driver for QHY, no indi_qhy_ccd. The current QHY SDK is closed-source so there is no way to investigate any problems. Can you please test the QHY guiding as I specified before and let me know how it goes? For me, it works fine in all directions (except SOUTH) but I found out that SOUTH doesn't work in lin_guider or even windows so it is a hardware issue.

You're right, lin_guider works standalone. Don't know where I've got that "info" from... Will test soon as I am currently recovering from a strange infection... Will let you know what happens.

The pulses work in all directions here using a CCD-Labs Q-Guide (QHY5 clone) running indi_qhy_ccd. Will try guiding as soon as weather allows.