David James replied to the topic 'Any news on QHY294C support?' in the forum. 1 week ago

So this is weird...

The above was on my desktop machine, which I figured I'd use initially to test out the camera, but I actually use a RPi3 Astroberry at the mount.

So after trying all sorts to get the camera working on my desktop machine, I gave up and said to myself "well, what it actually needs to work on is the Astroberry, not the desktop, so let's test that"... and it works just fine, as far as I can tell, pending a clear night.

But I note that Astroberry 2.0.0 runs KStars 3.3.8 Build 2019-11-23T17:12:05Z, not the more recent builds I was using on my desktop for initial testing.

So I think I'll refrain from updating the Astroberry

Read More...

Did you ever get this resolved?

I have a QHY294C and I got a bit further but INDI continues to not recognize that a QHY camera is attached, and that's with the SDK installed.

Read More...

David James replied to the topic 'Any news on QHY294C support?' in the forum. 2 weeks ago

I recently acquired a QHY294C and with both the most recent bleeding edge build (2020-01-31T22:44:11Z) and the current nightly build (2020-02-08T18:05:24Z) I'm getting the "No QHY cameras detected. Power on?" pop-up error with an "Unable to establish: +QHY CCD" message in the Ekos message pane.

I've tried it connected to both a USB 2.0 and USB 3.0 port on the computer.

lsusb shows:
Bus 001 Device 091: ID 1618:c294 Cypress WestBridge

dmesg (plugged into USB 2.0 port, but no difference other than usb# with 3.0 port):
[1059891.355798] usb 1-5: new high-speed USB device number 91 using xhci_hcd
[1059891.504400] usb 1-5: New USB device found, idVendor=1618, idProduct=c294, bcdDevice= 1.00
[1059891.504406] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1059891.504410] usb 1-5: Product: WestBridge
[1059891.504413] usb 1-5: Manufacturer: Cypress
[1059891.504416] usb 1-5: SerialNumber: 0000000004BE

Read More...

David James replied to the topic 'Running Kstars / ekos / INdI from SSD with rpi4' in the forum. 2 months ago

Megiddo wrote: Read an interesting article on network speeds with these RPi4's (thanks suvowner for pointing out the link). VNC is much better, not as good as directly connecting and not using VNC of course, but much better than wireless.

notenoughtech.com/raspberry-pi/2019-rasp...-network-speed-test/

I'm now using the ethernet choice. However I have the benefit of a pier.
RPI4-640x457.jpg


Ok, so here's a possibly dumb question: would we be better off running an external wifi router at the mount and just connecting the Pi to it with an ethernet cable, then connecting your computer to that router's wifi network? You can now get some pretty small wifi routers, small enough even to physically attach to the mount, say on top of the counterweight.

Or, alternately, especially if at home, setting up the router as a client on the home wifi network, thus in effect substituting the Pi's wireless interface with the router's - with OpenWRT this can be done fairly readily.

I've certainly noticed this lagginess with VNC, and that's with the Pi in client mode. It's even worse if the computer is on wifi as well.

I had actually had a notion a while back of compiling INDI for OpenWRT and running it on a decently-well specced wifi router with a USB interface and powered USB hub, but it was simpler to just use a Pi3B+ and run Ekos-KStars on it directly.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

sterne-jaeger wrote: Let' try to narrow it down step by step.

That said, the times reported in the log upon system initialization are correct, so KStars and Ekos are at least using the correct times. If there were a mismatch with the mount, how would I determine it and how would I correct it?

OK, so the time of KStars is correct. When you take your hand controller, what does the mount say? If you take a look a the INDI EQMod tab, do the time, date and location values match with KStars?


I'm using a direct connection cable from the Astroberry to the mount, so the hand controller is not attached. The EQ6 never held the time anyway; it always had to be reentered on the Synscan controller or taken from GPS. I do have a Skywatcher GPS dongle which gave accurate time info until about April this year when its up-to-1024-week offset means of counting dates ran out.

On the Site Management subtab of the EQMod tab, the UTC time was loaded with the correct time. I do note that it doesn't increment the time, unlike the Julian and Sidereal fields.

Given this ~13° initial targetting discrepancy, and given than I've tended to aim for objects fairly close to the meridian to plate solve (it's sort of a site constraint), I suppose there is a possibility that there is an erroneous determination post-plate solving that the mount has already been flipped, even though Ekos reports a countdown to a pending flip?

Sure, either the the mount was already on the eastern side of the pier before crossing the meridian or - vice versa - remained on the western side when the meridian flip function initiated a re-slew to the current target.


Physically, the mount has always been on the west side of the pier before carrying out meridian flip test runs.

I guess I could try to initially solve on objects well east of the meridian to remove any possibility of uncertainty as to what side of the pier the mount is on.

Don't think that this helps. More alignment points improve the model but it does not have an influence which pier side the mount selects. This is only dependent on date, time, location and target position.

But I'm trying to consider factors that might have an effect on creating flip failures.

But that would have to wait for another clear night, not until Thursday.

You do not need plate solving for testing it, it is sufficient if you have your mount running.


But it's only when there's a plate solve in the mix that I'm having problems with meridian flips. No plate solving and all works fine. So there's something about plate solving or having plate solved that is creating conditions for failed meridian flips.

As a next step it would be interesting on which pier side the mount is when a meridian flip fails (or finishes within seconds).


It's always on the west side.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

alacant wrote: Hi everyone
JTOL...

The eqmod side if pier was fixed here and has worked perfectly ever since:
github.com/indilib/indi/pull/658

Eqmod users are fortunate in that we have accurate side of pier reporting.

@OP. Is there any way you could get a physical imaging camera to test this with align and eqmod? A DSLR with a lens would be fine.
Is your computer set to receive Internet date and time?
Cheers and HTH
Steve


By physical imaging camera do you mean other than the ZWO ASI120MM I have attached? My imaging camera is a Fujifilm X-T1 which isn't functionally supported by gphoto and it crashes out whenever I've tried to tether it with INDI. In my tests, I did attach the ZWO as both Guider and CCD (separately, with INDI restarts) with no change in results.

The computer is a Raspberry Pi 3B+ running Astroberry. After a few minutes on wifi it gets the correct internet time so I tend to turn it on and let it sit there for a few minutes to allow it time to grab the correct time before connecting to it. The KStars version is 3.3.8, running directly on the Astroberry.

Now I could test this from a KStars installation running on another computer with the Astroberry limited to running INDI.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

ChrisRowland wrote: You are right Wolfgang, the meridian flip slew move does not involve a meridian flip. It's possible that the flip has already happened, or that a guide command has blocked it.


Hi Chris,

There was no active guiding taking place during either of the posted logs. The ZWO was attached as a guide camera and used only for plate solving in the events of the first log.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

Hi Wolfgang,

Well I'm open to the possibility of some sort of time/geo-based cause as the initial slews to targets well removed from the parking position are off by about 13° W in RA (typically ~47000" is reported in the plate solver). I don't really have a satisfactory idea of why this is. You can see it in the log I posted on slewing to M31 at 19:33:46 where the plate solving reports a location of 23h 51m 07s rather than the 00h 43m 49s of M31's actual position. Would clearing the mount model help?

That said, the times reported in the log upon system initialization are correct, so KStars and Ekos are at least using the correct times. If there were a mismatch with the mount, how would I determine it and how would I correct it?

With respect to location, I've set up KStars with the city of Ottawa, Canada as its location using its default coordinates in the KStars setup wizard. From my phone, it tells me I'm about 6' west and 1' south of those coordinates. Now if I understand the implications of that correctly, with no other data available, the mount would tend to aim slightly west of the true location of an object and thus it would tend to flip slightly *earlier* in time than it would were the precise coordinates known. So how would updating that with information from a plate solve affect it? I've already determined that an HA>0.2h has the same results, and that's more than the time difference introduced by my physical offset from the default Ottawa coordinates.

Given this ~13° initial targetting discrepancy, and given than I've tended to aim for objects fairly close to the meridian to plate solve (it's sort of a site constraint), I suppose there is a possibilty that there is an erroneous determination post-plate solving that the mount has already been flipped, even though Ekos reports a countdown to a pending flip? I guess I could try to initially solve on objects well east of the meridian to remove any possibility of uncertainty as to what side of the pier the mount is on.

But that would have to wait for another clear night, not until Thursday.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

Following the above, I parked the mount then disconnected Ekos and stopped INDI before restarting it all again.

19:43:04 - Ekos disconnection
19:43:05 - INDI disconnection
19:43:15 - INDI & Ekos restarted
19:43:44 - EQMOD instructed to goto star to the east of M31 via R-click in KStars
19:43:45 - Mount slewing
19:44:30 - Mount starts tracking
19:45:01 - Here I instruct Ekos to slew to another star closer to the meridian
19:45:02 - Mount slewing
19:45:10 - Mount starts tracking
19:45:46 - Here I instruct Ekos to slew to another star still closer to the meridian
19:45:47 - Mount slewing
19:45:49 - Mount starts tracking
19:47:40 - Meridian flip initiated
19:48:56/7 - Meridian flip completed

File Attachment:

File Name: EQMODZWO-SuccessfulFlip-20191207.txt
File Size: 618 KB



I continued carrying out tests for another 90 minutes or so in which I was able to establish that plate solving impeded all subsequent meridian flips in that INDI session.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

So I've excised the entire log from starting up to failed flip, which is just under 12 minutes. By luck M31 was approaching the meridian so I plate-solved on it and let it go. I've cut nothing from the log for this period.

Here's a brief time line:

19:30 - System turned on, EQMOD Mount + ZWO Guider
19:31:42 - EQMOD instructed to goto M31 via R-click menu in KStars
19:31:43 - Mount slewing
19:32:28/9 - Mount tracking M31
19:32:30+ - Ekos instructed to plate solve, but doesn't show up in the log as far as I can tell
19:33:46 - Some plate solving results come through (n.b. the mount is consistently about 13° off in RA for the initial targeting of objects near the meridian coming out of parked position)
19:33:47 - Slewing after plate solving
19:34:03 - Tracking reengaged
19:34:21 - More plate solving results
19:34:22 - Slewing after plate solving
19:34:23 - Tracking reengaged - appears to be the final alignment correction yet I don't see any more plate solving results after this showing the mount to be satisfactorily aligned
19:41:16 - Meridian flip initiated
19:41:18/9 - Meridian flip "completed"

File Attachment:

File Name: EQMODZWO-FailedFlip-M31-20191207.txt
File Size: 986 KB



Next I'll post from a successful flip.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

Well the results are interesting and kind of discouraging.

The main takeaway is that plate solving even once impedes the ability to properly meridian flip, so it's not even target-dependent. So, for example, if the mount is aimed at M33, plate solved on that and then moved to M31 which is approaching the meridian without actually plate solving on M31, the meridian flip will still be interrupted, so it's not like a plate solve on M33 only impedes the subsequent flip while tracking M33. So long as I don't plate solve, it flips as many times as I have patience to line up flips for, but once plate solving is carried out once, meridian flips are interrupted and INDI has to be restarted to reenable them. Parking and unparking is not sufficient to eliminate the interruptions and neither is disconnecting and reconnecting Ekos.

It doesn't matter whether the ZWO is attached as a CCD or as a Guider in the profile - the controlling variable is plate solving. And with respect to plate solving, it matters not whether it's set to Sync or Slew to target after solving - the effect is the same.

When I tested the effect of guiding, it opened up a whole new can of worms. Naturally I had to test it without plate solving first. Guiding didn't seem to impede a meridian flip from proceeding, but the one that was initiated during autoguiding never actually "completed". It was perpetually "Running" even when it had actually finished. That didn't stop the mount from being able to be parked, where it still maintained a status of "Running".


I have logs for this and since I recorded times of meridian flip [non-]events I'll go through and pull out a few segments where they were invoked. "Verbose" is an understatement to these logs...

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

I started working through things last night but it clouded over while I was doing tests.

I can say definitively that it is NOT the Scheduler, at all. I can create a no-flip scenario without the Scheduler.
I can also say definitively that it is NOT the HA offset - I was able to get a no-flip with an HA > 0.2.

My tentative conclusion is that it is weird. Like very weird.

There does seem to be a relationship between using plate solving on the guider device and interrupted meridian flips. Ironically, the clouding over further pointed the way towards such a relationship, one that I suspected from the start (it's in the thread name, after all).

Before it clouded over, for all of my tests with a guide camera attached I was also doing plate solving with the guide camera and ending up with no-flips. But once it clouded over, I couldn't plate solve any more so I didn't (just pointed it at objects approaching the meridian and let it do its thing), and all tests after it clouded over came through with successful flips - which is consistent with my daytime dummy runs where I also never had a failed flip.

Tonight is looking promising for clear skies, and with the possible problems narrowed down I should be able to come up with a definitive scenario for these failures.

So I'm looking at the following setups in my INDI device profile for my equipment, an EQ6 mount and a ZWO ASI120MM camera:
Mount: EQMOD
CCD: None or Simulated or ZWO
Guider: None or Simulated or ZWO

The key pair of tests will be with the ZWO camera as guider and then (1) plate solving and (2) not plate solving prior to a meridian flip. I'm expecting to get no-flips following a plate solve with the guide camera, and flips without having plate solved with the guide camera. I'll also test plate solving with the ZWO as the CCD to see if the issue is generalized to the ZWO or limited to when set to the Guider device alone. Given I suspect a role for plate solving, I'll be including that in the logging.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

Here again is what is - and is not - happening with emphasis on the differences between two scenarios where flips do and do not occur. It's all been nicely colour-coded to aid in following along. You can pretend I'm a dimwitted idiot who shouldn't be anywhere near an equatorial mount at all if it makes you feel better about being dismissive, but that still doesn't change what the logs say.


Scenario 1:
Live EQMOD mount, simulated camera, no guide camera real or simulated. Accordingly, in the Schedule tab, the 'Align' and 'Guide' boxes are UNCHECKED. Meridian flip set to >0.05h

When I set up a schedule that involves a meridian flip with this scenario and run it, the mount successfully carries out a meridian flip, as expected.

So, under this circumstance, I am able to get the mount to flip.

Fwiw, these dummy runs were carried out during the day, but I see no reason it wouldn't work under clear night skies either. I could test that out too on the next clear night.

Scenario 2:
Live EQMOD mount, simulated camera, live ZWO ASI guide camera on a real guidescope. So, in the Schedule tab, the 'Align' and 'Guide' boxes are now CHECKED. Meridian flip is set to >0.05h

As there is no live camera, alignment is being carried out by the guide camera on the guidescope. This run is also being carried out under clear night skies, so Ekos goes through an alignment routine after the mount has been aimed at the target.

When I set up a schedule that involves a meridian flip with this scenario and run it at night under clear skies, here's what happens:
-the mount is moved to the target, with the mount head on the west side
-once on target Ekos goes through an alignment routine to centre the target
-once the alignment routine is satisfied that the target is centred, a guide calibration is initiated
-once the guide calibration is successful, the guiding begins
-once guiding begins, the capture sequences are initiated
-at this point, on the Mount tab, I can see a count down to the meridian flip
-once the meridian flip countdown gets to 0, it goes into a waiting stage while the current capture finishes
-once the current capture finishes, a meridian flip *IS INITIATED*
-but almost instantly the meridian flip is INTERRUPTED or stopped
-Ekos then proceeds to carry out an alignment using and recentres back on the target
-on the Mount tab the meridian flip status is now Inactive


So just so we're clear, with a live mount and a live guide camera on the guidescope and the guide camera serving as the alignment device, with 'Align' and 'Guide' checked in the Schedule tab, under clear night skies, a meridian flip is initiated and then almost instantly stopped. That's in contrast to when it did fully carry out a flip when there was no guide camera set in the profile and the 'Align' and 'Guide' steps were unchecked in the Schedule tab.

And you can see for yourself in the logs I've attached. In my first post, i.e. 'Scenario 2':

[2019-12-02T21:19:22.226 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-02T21:19:22.232 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "01h 58m 47s" DEC= " 37° 55' 49\""
[2019-12-02T21:19:22.316 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Aborted"
[2019-12-02T21:19:22.316 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-02T21:19:22.826 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 752" startup 2 "02/12 20:59" state 3
[2019-12-02T21:19:22.828 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-02T21:19:22.830 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-02T21:19:22.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[...]
[2019-12-02T21:19:25.877 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-02T21:19:25.879 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5
[2019-12-02T21:19:25.923 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 3

That's 3 seconds.

Now take a look at the log from my second post, where it does carry out the flip fully, i.e. 'Scenario 1':

[2019-12-03T11:51:13.896 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 4
[2019-12-03T11:51:13.898 EST DEBG ][ org.kde.kstars.ekos.mount] - Slewing to RA= "16h 33m 37s" DEC= "-13° 05' 36\""
[2019-12-03T11:51:13.907 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:13.909 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:13.985 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Capture State "Meridian Flip"
[2019-12-03T11:51:14.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Tracking" to "Slewing"
[2019-12-03T11:51:14.840 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "M 107" startup 2 "03/12 11:46" state 3
[2019-12-03T11:51:14.843 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-12-03T11:51:14.862 EST DEBG ][ org.kde.kstars.ekos.scheduler] - Mount State changed to 2
[...]
[2019-12-03T11:52:38.828 EST DEBG ][ org.kde.kstars.ekos.mount] - Mount status changed from "Slewing" to "Tracking"
[2019-12-03T11:52:38.829 EST DEBG ][ org.kde.kstars.ekos.mount] - Setting meridian flip status to 5

That's a minute and twenty four seconds (1:24), i.e. the time it took for the mount to flip.


So, quite frankly, whether or not I understand how a meridian flip is supposed to work is a moot point given that under both scenarios the flip is initiated. It's just that it will complete the flip under a limited scenario but won't under a slightly more involved scenario with more equipment attached. For some reason, the meridian flip is initiated but it is stopped in the scenario where the guide camera is attached and operating. It's repeatable - I've run both scenarios thrice and get the same results each time, so it's not a one-off fluke.

I'll run them again with logging of the INDI messages as well to see if that turns up any more useful information.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

I've read through the Synscan manual - the only reference to meridian flipping is with respect to whether it's auto or, for the next goto movement only, forced or disabled. As far as I'm aware, the EQ6 doesn't have mount limits at all. Left to its own, it will eventually strike the tripod through normal tracking.


At any rate, none of this particularly explains the behaviour that far more concerns me, the interruption of a just-started meridian flip when there's a guide camera attached. Is it perhaps because I'm using the guide camera for both alignment and guiding, so when the guiding gets turned off by the meridian flip it's available to take an image for alignment? I would guess that under most use cases one would preferentially use the main imaging camera for alignment?

I still have to investigate Tim's suggestion of increasing the meridian offset but even if does that does seem like a workaround given that it *does* work with a minimal offset when there is no guide camera attached.

Read More...

David James replied to the topic 'Meridian flip interrupted on EQMOD mount - Alignment Module?' in the forum. 3 months ago

Sorry, which behaviour are you referring to?

The one I described in my last post of the mount head slewing to the west side for a just-west-of-meridian object?

Or the behaviour I described in my initial post whereby a dummy run successfully meridian flips but a night time run with a guide camera in the mix gets interrupted seconds after the flip starts?

Read More...