I had this exact problem with the QHY5LII-M. First, the timeout message, and then with exposure happening, and ending successfully (or so it seems), but nothing was being downloaded nor shown in the FITS viewer.
The solution was to exit Ekos and KStars, then unplug the cable, and plug it into another USB port on the same laptop. They are marked the same, and none of them are USB 3.0. But it did solve the problem for some reason.
Thanks for the clarification. These are all great changes.
james_lan wrote: Now if I can just find what the hell is with that bug in the alignment routine. (I've somewhat narrowed it down bringing out things like wireshark, but whatever the issue is, it seems to defy my finding it. Though I've narrowed it down some as to what gets called, but that shouldn't as far as I can tell. Somehow kstars thinks that the EqNP.s is busy when as per wireshark it's not, so it goes into the case of IPS_BUSY (== Slewing) when it's actually another status, but I don't see HOW. At least I know it's not the OnStep INDI driver side (or the INDI side, or the OnStep side... I think anyway ). )
This bug is merely an annoyance.
I found it easier to just point and slew to each star, and repeat 6 times.
The reason is that populating the Mount Model tool takes a lot of time, so in the end, both methods work out to the same time.
Also: If anything breaks that was working before, PLEASE LET ME KNOW.
I will. Although I will not get the changes until they make it all the way to Jasem's PPA, then him building packages. So it will be a while.
There were a bunch of stupid spacing things that git decided a whole function constituted a change, some of which had actual changes in them, and I think I decoupled the spacing changes from actual changes, but... I'm only human, and a little bit more persistent than git.
Maybe it is something more mundane? Such as tabs vs spaces?
Thank you for the pointer. This looks like exactly what I am thinking about: stacking automatically without user intervention.
This may be all the EAA folk need. Perhaps not well know because not much in English is available on it (just guessing).
Let us hear from users before re-assessing whether to integrate it somehow (proper Debian package with dependencies will help with the install), or write something new ...
Thanks a lot.
I found some focus stacking stuff, which people who take macro photos use. It can probably be repurposed for a rudimentary command line tool.
Basically it is like so:
# Convert Canon RAW to TIFF dcraw -T something*.cr2 # Align the images align_image_stack -v -m -a aligned something*.tiff # Stack them enfuse --exposure-weight=0 --saturation-weight=0 --contrast-weight=1 --hard-mask -o result.tiff aligned*
I have yet to try it. Need a clear night to take say 10 x 1 minute exposures, and try to stack those.
But since what you will write will be integrated right there from Ekos, then here is my suggestion: start with a very simple scheme. Perhaps just stacking and stretching. Put it out in the field to get it tested a bit. Then based on the feedback you can choose to refine it or declare that 'perfect is the enemy of good enough'. Inspiration from SharpCap would be nice, since it has some following.
Although I have been developing software for almost 35 years, these areas (image processing, GUIs, ...) are not something I enjoy.
On the other hand, if there are utilities that I can script into a command line interface, I am happy to do it.
For example, I wrote a time lapse script, and used it for Comet 46/P Wirtanen , and Comet Iwamoto last winter.
Obviously, stacking is not that simple.
I am wondering if there is any progress on Ekos for EAA like features.
By "EAA like", I mean that there are many definitions, and the one a few comments up from here is just one of them.
For me, "EAA like" means that I mainly observe from a desktop remoting into a laptop that is connected to my AP capable mount. However, I don't do any post-processing or stacking of the images I take. I don't have the skill for this, nor the time. I am happy with observing images as they come. I don't guide, and am able to take 3 or 5 minute images that way (the key is OnStep as a mount controller. Check it out, it is worth the effort. Also, check my album of unprocessed images ).
My setup is built with KStars/Ekos/INDI at its core.
If Ekos can do some stacking, and stretching to get better images, that would be a welcome addition to the tool kit. Something like what SharpCap does.
Any progress on this, without the need to do it on the internet?
- Changed align so the last step isn't the (Optional) Write to EEPROM
Do you mean the text of the instructions change, or there is a functionality change somewhere? If the latter, please elaborate more.
- Added support for polar adjustments, without having to redo the entire model. (:MP# command)
If you have a polar alignment that has significant errors (say > 3'), and you do the RefinePA (:MP), then you are better off re-doing the polar alignment since your gotos will off if you don't.
So now we have a Single and Dual button next to each of Full and Refr?
- Support for Full Compensation/Refraction only, and 1/2 Axis tracking
One more thing: the units for the polar error in the Align tab are wrong. They are ' but should be ". I am sure I reported this to Alain way back when, and it was fixed. Perhaps overwritten by some other change.
Thanks for your continued work on this ...
james_lan wrote: There is one bug, but it's an Ekos one from what I can tell related to the mount model alignment tool, which is if there's a delay changing to slew, and it gets checked too quickly then Ekos/Kstars assumes it's done with a slew before the command even gets sent.
I've filed a bug for kstars. bugs.kde.org/show_bug.cgi?id=410094 as I believe that's where the issue lies.
And since I left this post up overnight, before hitting submit, it's already fixed (or at least looks like it) in kstars git, and if I do observing tonight, I'll see if I have any issues. <strong>Thanks Jasem!</strong>
This bug is still there. Very annoying ...
Mount Model will slew and solve a star, then go to the next, then solve and slew too fast. The image is a streak and not a point.
I am using the latest Ubuntu 18.04 packages from Jasem's repositories, built a couple of days ago.
So, the rules files in /lib/udev/rules that are installed by the default packages should be all that is needed. In other words, no need for any qhy related files under /etc/udev/rules.
I am considering buying a QHY5L-II as an autoguiding camera.
For example, this mono version .
From reading the thread, it seems to work, but requires some custom udev rules.
I installed the indi-qhy package, and the rules are in /lib/udev/rules.d/85-qhyccd.rules, which is installed by libqhy. Package fxload is also installed as a dependency.
Any concerns still?
For the sleew problem (Kstars/sychart remains in sleewing mode instead of return in tacking mode after weak goto (plate solving...), i have made a quick and dirty workaround:
I launch this script: github.com/plop3/WatchdogOnStep/blob/master/WatchdogOnStep.sh
It monitor the state of tracking and if mount is blocked in sleewing state (sleew but coordinates dont't change), the script send a track order to resynchronize Indi.
Does not work
The 'KStars remains in Slewing mode, and never goes back to tracking' problem has been solved in OnStep master for some time now. Basically there are a lot of code that went into the 'end of slew' logic that Howard added after earlier complaints from KStars users.
If you use the latest master, you should never see the problem.
I use Jasem's INDI packages, and his KStars Bleeding.
james_lan wrote: Interface is two buttons, button 1 prints this to INFO.
2019-07-04T05:19:20: [INFO] Optional: Start a new alignment.
2019-07-04T05:19:20: [INFO] Step 4: Using the mount's Alt and Az screws manually recenter the star. (Video mode if your camera supports it will be helpful.)
2019-07-04T05:19:20: [INFO] Step 3: Press Refine Polar Alignment.
2019-07-04T05:19:20: [INFO] Step 2: Make sure it is centered.
2019-07-04T05:19:20: [INFO] Step 1: Goto a bright star between 50 and 80 degrees N/S from the pole. Preferably on the Meridian.
Button two issues the :MP# command.
Any suggested wording changes?
The steps are displayed in reverse order. That confused me for a few minutes.
As for wording, the Android app is constrained in screen space, but we can expand the text a bit:
Step 5: Optional: Repeat the alignment.
Step 4: Using the mount's Alt and Az screws, manually recenter the star. Use the camera's LCD and grid, if available.
Step 4: Press the Refine Polar Alignment button.
Step 3: Center the star perfectly. You can use Plate Solving and Slew To Target for this.
Step 2: Goto a bright star due north, or due south, but having a Declination of more than 50 and less than 80 degrees. Preferably near the Meridian.
Step 1: Start and alignment on 3 or more stars.
If we are using the info area, then for the rest of the alignment, we should use that too. Or, change the new Refine PA to use the scheme that is already in use on the Align tab (all text shown). Point is: consistency of the UI. I don't have a specific preference, but the info area tends to scroll and only 3 lines show up at most on my older astro laptop.
james_lan wrote: Yeah, I've done that with the wifi, but no luck it always goes back to acting as an AP. I seem to have annoying luck with esp8266s. (And esp32s work just fine, so maybe it's the router or something.)
For what its worth ... I have two WeMos D1 Minis on two separate STM32 PCBs, and they both work flawlessly.
Thanks for all the fixes ...
I've seen you mention :MP, and I'll probably add that soon, but I wanted to verify the workflow:
Align as normal
Go to a bright star or other target
Telescope should move off the target, so you can center it via manual adjustment.
Non-ideally: Do another align which should have massively reduced or eliminated polar alignment error.
If so, would just having an :MP/Manually Clear Polar Align button available on the align tab be good, or would something else be needed? (Aside from taking pictures, and operating screws?)
The way I do it is:
1. Start an align 3 (or more) stars
2. For each star, right click and slew, then do a Capture and Solve with Sync as the action
3. Now OnStep calculates the offset in Azimuth and Altitude, and uses that for go tos
4. Slew to a star that is due north (or south in the southern hemisphere) and on the same side of the meridian. I used Kocab/Kochab which happens to be above Polaris these days, and not obstructed by the trees and houses. I did use Cassiopeia before.
5. Do a Capture and Solve on it, but with Slew to Target as the action
6. OnStep will try until the star is perfectly centered, with only 10 arc second error (in my case)
7. I then issue the :MP from a Python program over WiFi. OnStep then moves to where the star should be without the alt/az corrections
8. Using only the Alt and Az knobs, center the star the best you can
9. The program then does a Return Home
10. Another 3 or more star align is needed
So, it can be done in two ways:
a. A button that issues an :MP
b. A walk through that includes the manual steps and instructions into account.
My vote is on simple, so you can proceed with (a) above. On the page, there can be text describing the steps needed before (n-star align, then Slew to Target) and after (using only alt/az knobs center the star, then Return home and repeat the align), but nothing else from a programming point of view.
KISS: Keep it Simple ...
Also Asking people to weigh in: I have thought about, but have mixed feelings about adding a manual command interface, and return value?
It's something that could work well, but could also mess it up unintentionally. The bugs above with alignment thought to be done already were due to a simple not checking if one command was done before another, so because it was still in the buffer, it was giving things like 1616 when the response should always have been 3 digits.
That would be handy and very dangerous too.
Here is another idea: can we connect to OnStep over WiFi? I know it can be done from my Python program, using the IP address and 9999 port. Can INDI do the same? If so, then it is one less cable (provided the WiFi is reliable).
kbahey wrote: One reason is that if I try more than 6 stars, INDI messes up and acts weird re: total stars, current star, ...etc.
Can you describe this a bit better, it should work the same*. Though it might be good to define which UI is being talked about. The INDI Control panel Align tab, the Ekos Align Module?
There is a relatively new feature in OnStep, and it is undocumented. It allows you to change the number of maximum align stars. To do this, you need to add this in your config file:
#define MAX_NUM_ALIGN_STARS '9'
MaxPCB already supports 9, so this is mainly for my STM32 which by default has a maximum of 6 stars only.
When I add this, and then from INDI issue an align for more than 6 stars, you will see things go wrong, and the result of :A?# not being what you expect 919, but something else.
As I said, I just start the align from the Android App.
The Android App became much easier to use after Howard added the ability for OnStep to join your home WiFi network, and fall back to its own AP if it can't.
I have such an issue with the wireless, that I've given up on it multiple times. (I tend to use Serial as there's already the computer next to the telescope for camera control.) I tried it a few days ago, but still had an issue. I may try again at some point, but it's somewhat frustrating.
Open the web page, go to WiFi, enter your password (or see the Wiki on how to reset it from the IDE).
Then enter your WiFi network's SSID and password, and check Station Mode. Uncheck Access-Point mode.
Doing this makes OnStep connect to your home network if it finds it, but if it cannot connect, it will fallback automatically to the Acess Point mode (i.e. ONSTEP). Very convenient, and allows me to control the mount from inside using the phone.