This is super Interesting because exactly the same thing has been happening to be this week.

AZGti Mount using EQMOD all running on an RPi 4, Kstars 3.5.4 stable, Nikon DSLR, time and position provided by GPS dongle, literally zero changes to the software side of the setup since it was used at the end of September.

However first night out this week I had exactly the same problem as you occurring, tried to troubleshoot for hours but it was the middle of the night and I was still quite jetlagged. Tried clearing mount data, parking position, checking GPS data, timezone etc etc - all the same as you, but it didn't matter - I'd plate solve at the NCP then as I started to slew away and take new solves to get the goto accuracy it just went the opposite direction constantly.

2nd night, setup, same software, kit etc, same workflow, works first time, slewing the right direction and everything, bring the kit in due to wind and then go back out later, problem is back with literally no changes from earlier.

3rd night, same problem, used guide camera instead of main camera to sync mount, works perfectly ... At one point it also told me that it would cross the meridian during polar alignment which seemed odd.

So random question - what latitude are you at ? The only difference for us between the last time we used the rig, without any of these issues, and now is latitude. Normally we live at approx 51.5 and the last trip was to Nevada at 36 degrees, but this time we're in Hawaii at 19 degrees and I'm wondering if being that close to the equator starts to cause issues as really it's the only variable in the whole rig that has changes beyond the miniscule tolerance differences in alignment and mounting points!

Sorry I could be more help to correct it, I haven't found a good solution but flipping between which camera I use to sync positions seems to help.

Read More...

I've sucessfully used EQMOD with a Star Adventurer Mini, the commandset is identical to the bigger EQ mounts but it just ignores/doesn't have a lot of the commands so things like goto don't work. You can turn tracking on/off, send guide pulses and rotate the RA axis with it if you really want to. The maximum rotation speed of the RA axis is so slow, however, that it was easier to rotate it manually for PA and I literally only used that driver as a method to turn on and off tracking without having to use the app and EKOS to control the camera/provide PA routines.

90% of the time we use the SAM with a widefield lens so it's easier to use the polar scope and it's own app to control it b I realise the older Star Adventurers don't have the app.

Jacqui

Read More...

I can't offer any more data at this point as I bgot stuck in a library mess after upgrading my pi so completely rebuilt it, however around the same time we acquired a guidescope with a QHY camera so we have been using that for polar alignment as it is one less USB cable to manage!

If we get some clear nights soon I'll do some testing with the ipolar and see if it's any better with my cleaner build of the libraries.

Jacqui

Read More...

Thought it might be useful to add my own update here - I was/am using a very old version of kstars/ekos (3.0.0) which I can make work with the iPolar for PAA happily. Recently I have been trying to upgrade to 3.5.2 and cannot make the iPolar work with it at all (the image it takes is deemed unsolvable). I know it's Ekos as I made sure every other driver was the same on the system (indi, kernel etc) but as yet don't know at what point between 3.0.0 and 3.5.2 it stops working.

Read More...

It's been a while so I thought I'd add an update. Have been using the iPolar to do alignment successfully over the last 6 months - on a clear night with the right gain settings it just sails through alignment with the caveats previously mentioned even in a light polluted UK city suburb.

However just recently I thought that the indi libraries and kstars version should really be upgraded from the default raspbian repos I used initially so cloned the PIs flash card and ran some upgrades to indi 1.8.9 and kstars 3.5.2 from the astroberry repos in order to get the new polar alignment features and stellarsolver and it's fair to say the results were not positive.

The image now coming through from the ipolar is noisey as hell and solving fails completely against it, can't even get it to acknowledge there are stars in the image regardless of gain settings (solving works fine and super rapidly against the main camera although the image displayed in the solving screen is noisey).

So I recloned the old card, left the old version of INDI in place and only upgrade kstars - same problem! I haven't had time yet to go back and step through versions of kstars to see exactly where the problem occurs (There were a number of other oddities with kstars including the slew rate it tries to use on the iexos-100 mount we have) but right now I'd have to say that in terms of using the iPolar then all my comments previously about getting it working relate to Kstars version 3.0.0 and nothing newer at this time!

Hope that helps others.

Jacqui

Read More...

Changing the exposure within the capture routine appeared to have an effect for myself and changing the gain under the V4L options certainly has an effect on the image captured. Having popped the back off the iPolar since I wrote in the thread you reference it's basically a Sonix SN9C camera controller coupled to a low light sensor, specifically an SN9C6287 which I don't seem to be able to find any data for but some code for earlier sonix drivers does reference registers that can be used for exposure control so it's reasonable to assume that it can be controlled to a point, if only coarsely, but without reading the V4L code for the drivers it's using couldn;t be sure but the maximum exposure definitely seems to be limited to 0.5.

We use the iPolar routinely (and sucessfully) with the Ekos PAA so it certainly does work. (typically a 0.25s or 0.5s exposure time with a gain of 288-384 works fine in my bortle 7 garden and much lower gain when in darker skies.

HTH

Jacqui

HTH

Jacqui

Read More...

Well, some more unexpected clear skies - did some more testing in the garden and definitely had dark frames in place and no change in the noise.

Even altering the gain had little impact on the noise tbh and I fiddled with various other settings in the driver but no real luck although changing the white balance seemed to be having some effect but fairly minimal.

However you can make out your target star from the noise (on the unit we have anyway) and I got the mount dialled in to what it told me was 1arcminute of alignment error so it is certainly viable to use the ipolar with the alignment module.

I can only throw wild guesses as to what is happening but it really looks like it's not subtracting the dark frame. Is it possible that because the refresh exposure has to be so low it doesn't have time to process it ?

Jacqui

Read More...

The frames I was solving definitely had a 0.25s exposure dark frame but thinking about it there may not have been a 0.5s dark frame in the library for the refresh/alignment portion. It definitely looked like the dark frame wasn't being subtracted but I thought I had tried it with a 0.25 refresh as well and got the same result - this may not be the case and I'll try again next window I get (might get lucky tonight looking at weather).

In terms of the noise it doesn't show up much at all in the live view which is why it surprised me to see it at that point and so I'm not sure the V4L settings beyond gain and image size had much impact on it. That said I will do furthur experimentation with them to see what I get. Even when using the iOptron provided software on windows we typically had to crank the gain up to 2-4x to get solving to happen (it goes up in half step increments on their software so that's functionally equivalent to 192-288 ish on the V4L driver which is why I first played with that parameter).

That said, looking at the dark frames I do have it seems to be a pretty noisy device - the ioptron software dark frame seems to be a custom format so I've not been able to open that on my desktop to look.

Jacqui

Read More...

just an update - had some unexpectedly cloud free skies this evening so was able to test again. By futzing with the low and high value settings in the solver settings it started solving and eventually landed on a low of about 570ish and a high of about 819ish. I was able to then run through the polar alignment process and complete it although there are a few snags to be wary of;

When you get to the actual alignment phase after the solving and you need to click refresh it defaults to a 1 second refresh and this seems to translate into a 1 second exposure (I imagine this isn't news to everyone more familiar with EKOS than I but it's not clear from the info on the screen screen) , this needs to be set to 0.5 or lower otherwise it crashes (and locks up) as I believe the V4L driver doesn't support beyond an exposure length beyond 0.5s. The other snag is that the image you use to align the star into the crosshairs has a _lot_ of noise on it (no idea if this is expected behaviour or not but the noise looks like what you see in the dark frame). It is, however, just about possible to make out the point you have selected although getting it super precise wouldn't be that easy.

In summary I had to ensure the following was set to make everything work;

Ensure in the indi control panel the iPolars image size is set to 1280x960 otherwise you will get strange images indeed.
Change the gain in the iPolars settings to a level suitable for your skies. This was in my back garden which is bortle 6/7 so I found I needed the gain at at least 160 to get solving to happen and right up at 192-288 to get it happening reliably.
I set the FOV in the alignment module to 780' x 585' and this seems to be happy.
I set the low and high values in the solver settings initially to around 400-900 and then it eventually homed in on about 571-819 after it solved the first image.
I used an exposure of 0.25s.
I used a refresh of 0.5 on the final screen.

With that in place it's then working for PA, with the noise issue mentioned above.

So I've successfully used it for alignment and I hope the info helps anyone else wanting to do the same.

Jacqui

Read More...