Solving during model building fails, v. 1.1.0b9

[Ginge70]

Hi again!

Last night's agenda was to try model building for the first time now that MW4 is speaking with ASTAP and solving fits saved on my disk. In the beginning of the night I posted a question to the 10Micron forum as the solving bit of model building kept failing, however there were other things going wrong at the same time so I couldn't be sure what was what. Later the same night though, I had a new opportunity as clouds disappeared and tried another model build, but MW4 keep giving me error messages saying solving failed. I stopped the procedure and manually solved the picture in the MW4 imaging window that had just failed and it solved without problem. In another attempt that went pretty much the same way, I let the process run and when the solve failed I immediately solved the image manually in MW4 just to check that ASTAP was working. I might be reading the log incorrectly but to me it looks like ASTAP actually solves the image, but MW4 still considers it a failed attempt. Can you help? I was using INDIGO server in the beginning of the night, but after experiencing dropouts with connection to the ASI1600 I tried switching to INDI Server which worked better. Regarding the connection to the camera: I use USB2 because I have to transfer the signal over ethernet to the building next to the observatory. I normally have no connection dropouts, but trying to use high speed transfer from the camera doesn't work (in case this is a connection speed issue). I'm attaching the log of my last couple of model building attempts that also includes my manual solving checks mid-process. mw4-2021-03-17.log

Best regards, Ginge

[mworion]

Ginge, sorry to hear, I will have a look to it tonight Michel

[mworion]

Ging, hard to tackle. First: I see many timeouts to the mount. Do you use a wired connection ? I would recommend doing so and MW4 causes some traffic for the mount. I uploaded v1.1.0b10 with some more logging as my test did not trigger the same topics as in your environment. Michel

[Ginge70]

That is also my thought. I'm connected to the mount via wifi and it is stretched to its limits, I'm afraid. The connection is sufficient for normal operation, but I can imagine it is not good enough when the signals start queueing up. I'll try moving closer and if that does'nt work, I'll connect to the mount by wire. Just a thought, would it help to extend the timeout setting for the ASTAP device if the wifi signal is weak?

I'll update to b10 now.

Thanks!! Ginge

[Ginge70]

So something went haywire with the last update last night. I wanted to check if the solving procedure went through if I moved tha mac closer to the wifi signal. It came back with a solving error when I ran the model building routine, so I moved even closer thinking I'd use a wired connection as a last resort as that means bringing the computer outside in sub zero temperatures. It is fine, but I avoid it if I can. Now, however, MW4 got hung up in the solving routine, - I left it alone until I figured it is truly stuck and forced a quit, restarted the mac and retried. I did this a number of times disconnecting more and more equipment until I basically concluded it was likely due to the updated version of MW4. I also tried solving images I new were unproblematic in the previous version with the same hanging result and was watching for the ASTAP.app to open and do its thing, which it didn't after a while. Trying ASTAP alone without restarting the mac showed it hanging to, but once I'd restarted the mac, ASTAP would be working again. No such thing with MW4. Here's the log: mw4-2021-03-18.log

[Ginge70]

I've read that USBc devices can sometimes interfere with wifi-connection. I have a USBc drive connected and sometimes I also have my phone connected to charge it. I suppose this is also an argument for trying the modelling while connected with a wire instead, just to be on the safe side.

g

[mworion]

Hi Ginge, I have an idea how to improve the ASTAP solution. In my environment (actually due to bad weather) EKOS Simulators, real mount I could see your fault under certain conditions ans solve it with the change. This has no impact to the situation of connectivity (wired, wireless) I will upload a next beta (v1.1.0b11) this afternoon. Michel

[mworion]

In addition, could you tell me a little bit more about your system setup to be able to test MW4 in such a condition ?

[Ginge70]

Absolutely. I connect to the ASI1600MM Pro with a USB3 cable going to a USB2 hub that in turn connects to a Startech USB Extender (https://www.startech.com/en-us/cards-adapters/usb2004ext2). On the other end I've hooked up my MacBook Pro (15 inch, 2017 running OSX 10.13.6) to the extrender with a Satechi usb-c multiport adapter (https://www.netonnet.no/art/lyd-bilde/kabler/usbhubadapter/satechi-usb-c-multi-port-adapter-4k-gigabit-ethernet-v2/1016782.11442/?gclid=Cj0KCQjwl9GCBhDvARIsAFunhsljXnbB6v0pjgC5MyvaohYJr-4tSqVmkfJYx499lXhB2AhpykAWa30aApRlEALw_wcB). My Robofocus is also connected through the extender and a Keyspan serial adapter on the other end. The firmware on the GM2000 HPS is 2.15.1. After I got it working with the MGBox that is connected directly to the mount, I haven't dared updating the firmware to a newer version. I was about to update to v3.0 last night, but I need to read a bit more about it first so I don't mess up a perfectly good system. My Mac talks to the mount via a Airport, can't remember wether it is an extreme or an express as it sits in a waterproof box high on the outriggers of my ro/ro-roof outriggers. It is one of the flat square ones, - nothing fancy. Tell me if you need to know anything else. Oh yeah, I'm storing files on a LaCie Portable SSD USB-c disk, but the images taken by MW4 is of course stored in the Work folder residing on the desktop. I'm using TheSkyX for everything, have been sniffing out EKOS but the lack of many catalogues I often use has me sitting on the fence for now. Changing between TheSkyX and MW4 leads to certain things and I try to make sure not to have them both open at once, at least I quit INDI Server as that will result in strangeness together with TheSkyX. ANother weird thing is that the mount often switch slew speed to 03 when I switch between applications. Haven't pinpointed exactly when it happens or for what reasons. I cannot access the slew speed parameter from MW4 either so I need to change it back to faster rate from the hand control. I suppose this might be due to the fact that I'm hanging on to an older firmware. I'll update to a newer one if you tell me it is safe. Is v3 good, for instance? I've noticed someone complaining about DEC drift, but haven't read up on it yet.

Thanks for helping out! Ginge

[Ginge70]

And I'm sure you got a lot more information than you needed there, sorry about that :)

[mworion]

Hi Ginge, I added my setup in the docs: https://mountwizzard4.readthedocs.io/en/latest/install/setup.html as explanation for all. This might help sometimes. Regarding FW3.0: I already updated some weeks and I had since then no issues and some successful imaging sessions. I hardly could see any difference, but it is your choice! The USB-C extender I use as will if I test for ASCOM as I run a virtual Windows Machine on my Mac. I think that's working fine even through VM plus extender. I do not own a ZWO ASI with larger scales, but I hear often topic about USB2/3 speeds. But if that works on TSX, it should be OK Indi Server and TSX might "fight" for the drivers. This was the reason I finally went to INDI, because then you have a server, where you could link many clients the same time. Slew Speed setting should work from MW4, I could set this. As MW4 only reads this if there is no interaction, it should be OK. There might be an issue when connection does not work well. Please also have a look to the number on top of the time widget, this is the number of parallel threads running. If numbers increase over time and do not stabilize -> connection and performance problem in the setup. In my environment I don't see a number beyond 2. I also uploaded the v1.1.0b11 version which should address the ASTAP issue. Michel

[Ginge70]

Thanks a lot, Michel! I'll try it out on the first clear night. Your setup looks quite smooth. I'll have to look into that Pegasus-solution 'cause my cable arrangment can hardly be called an arrangement after I added three dew straps to the mix. More like a cable salad.

The fitlet also looks quite nice. Especially the one that handles -40C.

g

[Ginge70]

Ok, so now I’ve thoroughly tested 0b11 with wired connection to the mount and whenever MW4 tries to solve during a modeling sequence it fails. If I pause and click the solve button on the image that just failed, it solves without problem. I’ve slowed the mount down to a crawl to give astap time to work, but that doesn’t help. It will fail well before the mount reaches the next point. The queue count number never goes above 4, most of the time it will stay on 2 or 3, it seems.

Here’s the log.

Best regards, Ginge mw4-2021-03-24.log

[mworion]

Hi Ginge, what I see from the log (at thew beginning)

• you start / connect
• you took an image manually
• you tried to solve -> no success
• you change settings for ASTAP
• you managed to solve
• you selected build points
• you started modeling
• ASTAP timed out and did not solve

etc.

From what I could see: Still the header entries for ra / dec are zero. This made the first attempt fail you adjusted to broader search Therefore it did solve, but with an extreme large error (which was zero to the solved position) Next image had again zero in header for ra / dec because of a position more far away, ATASP would search even longer, but was time out.

To explain the MW4 way of model build. slewing and imaging is done async to solve and model build. As extreme it could happen (never does, because solvers are quick nowadays) that you did all images, and solver has to work through afterwards.

So we have to find out, why your images in header show ra / dec zero.

Recap: You test image we talked at the beginning of this thread was done with TSX. TSX does not write RA / DEC as keywords in the header (this would be float values), but is does OBJCTRA / OBJCTDEC keywords, which describe the coordinates in hexadecimal string. I had not implemented this reading. With the last update, MW4 does read this -> your test image worked from this point on.

Now: you do imaging with INDI. So INDI has to write the coordinates in the header. For some reason these values are 0 / 0. First: could you post on of the not solved images, that I could check the entries ?

My first recommendation with your test image at the beginning (when I though you are using Indi, but used TSX) was that Indi needs to access the mount coordinates in indi driver. So the 10micron telescope driver has to be enabled (I don't see this, but I could not check this from the log) and configured right (this I also cannot check from the log) and connected. I see that the ccd driver tries to connect to the telescope driver (INDI device snoop), but no 10micron driver is enabled during the session.

This would explain, why INDI writes 0 / 0 in the header of the images and ASTAP could not solve it. So please have a look to the 10micron telescope driver in INDI. You could enable it in MW4 as well. If so I see if it is working also from MW4 in the logs.

Other topic which I have seen in the log recently (sorry I did not notice it before): you are using a pre2012 hardware. I do not have any test to it. I know one other user asked if that works (it should, but has limited capabilities) and you are using a very old firmware (2.15.1). Not all functions are supported by 2.15.1 as some mount commands were implemented from 10micron later.

I also found out that if I use a not know command from the mount, it will not respond to any of the commands in a row. To change that I have to change MW4 architecture or you have to upgrade the firmware at least to 2.16.x. You don't need the newest one (3.0.x as there were no new commands offered), but for MW4 I recommend 2.16.x or later (2.16.13 fine). To upgrade or not I can't judge as I don't own a pre2012 HW. I have to leave that description with you.

Good: I don't so these timeout to the mount anymore.

Hope this helps us moving forward.

Michel

[Ginge70]

Great stuff, we're narrowing things down. I wasn't aware I as supposed to also connect the mount to INDI, will certainly do that. As for the pre 2012 mount, that may explain why I'm not able to adjust slew speed from MW4. I'll upgrade to FW 2.16.something on the next clear night and make sure the mount is connected to INDI as well.

Thanks so much again for helping, Michel!

g

[Ginge70]

Here are the six images that failed to solve on the 24th. I'm neither used to INDI nor working with 8bit images like these. I set the camera to offset 21, Gain 76 and RAW16 via TheSkyX before moving over to INDI and MW4, but I see this has been changed. I tried to move over to INDIGO as I thought the INDIGO control panel were only for INDIGO server. I didn't know that until now and for some reason INDIGO only gave me a spinning umbrella last night, so I couldn't change the camera settings while it was connected to the camera. I suppose the settings are made there and not in MW4? I'll try changing the camera settings via INDIGO control panel next time if it will help with the solving if this cannot be done from MW4. I also see the filters are named incorrectly, filter 4 says H-alpha while it actually is Lum. I wanted to change this as well but didn't as it really doesn't matter how the filter position is named for now, as long as it is shooting through position 4. I was actually wondering if the images were truly shot through filter 4 as they had so little information compared to what I'm used to seeing, but I guess RAW8 readout explains some of that?

Sorry for being no good with INDI/INDIGO stuff, I'm just not familiar with that environment. Ginge

m-2021-03-24-23-06-07-med.zip

[mworion]

Hi Ginge, I checked the images: No coordinates available. So enable 10micron driver is necessary. Normally You should do the settings in INDI / INDIGO server. If you set there, MW4 just reads them and uses them. For some I offer the change also in MW4, but these do a remote change of the settings in INDI / INDIGO server. So you will see whenever a property is available in MW4 (always has only a subset) and INDI Server, and changed in MW4, it is also immediately changed on INDI side as well. You only have to take care to persist the settings on INDI side, as INDI loads the values on the server side, MW4 can't set the default / persistent settings on the server. Michel

[Ginge70]

Still not working. I’ll upload the log as soon as I get home as connection is too weak out here. But I’ve successfully updated to firmware 2.16.3, I’ve connected the LX200 10Micron device in INDI and I’ve also connected MW4 to indi-10Micron under Telescope in Core devices. The fits header in the imaging window still shows no RA or DEC coordinates. The Coordinates are showing correctly in the INDIGO Control Panel app. I’m thinking there are some settings in the Control Panel I have to set differently. For instance I have no idea what the snoop you mentioned is or how it needs a to be set. Can you give me a hint before I send you the log so I can test it while I have the clear sky?

thanks! Ginge

[Ginge70]

Hehe, never mind, I think I fixed it. I noticed the “embed data” button in the Imaging window was unchecked. Running model now via wifi and it is screaming through the model points and solving without problem. This is looking very good.

Best regards, Ginge

[mworion]

So you have a INDIGO server running on your Mac right? I downloaded the last one and looked for the settings. To be honest: I did not find a „Snoop“ for the camera. If you enable the mount simulator for example and go under main

If you could find one, the 10micron driver should be in.

But I have another way I will try for you tomorrow: I change the handling of coordinates from INDIGO and write the header data myself in the file. I have to do some programming, but I should be ready tomorrow evening. Michel

Am 27.03.2021 um 21:48 schrieb Ginge70 @.***>:

Still not working. I’ll upload the log as soon as I get home as connection is too weak out here. But I’ve successfully updated to firmware 2.16.3, I’ve connected the LX200 10Micron device in INDI and I’ve also connected MW4 to indi-10Micron under Telescope in Core devices. The fits header in the imaging window still shows no RA or DEC coordinates. The Coordinates are showing correctly in the INDIGO Control Panel app. I’m thinking there are some settings in the Control Panel I have to set differently. For instance I have no idea what the snoop you mentioned is or how it needs a to be set. Can you give me a hint before I send you the log so I can test it while I have the clear sky?

thanks! Ginge

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/mworion/MountWizzard4/issues/133#issuecomment-808800434, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSTMFBTLY4N55B37G3C4X3TFZACHANCNFSM4ZKCYTUA.

[mworion]

Good to hear. Hope it work nicely now

Von meinem iPad gesendet

Am 27.03.2021 um 22:15 schrieb Ginge70 @.***>:

 Hehe, never mind no think I fixed it. I noticed the “embed data” button in the Imaging window was unchecked. Running model now via wifi and it is screaming through the model points and solving without problem. This is looking very good.

Best regards, Ginge

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Ginge70]

It sure did, Michel. I'm so relieved we finally figured it out. Feel silly that I didn't spot that "embed data" button before. Thanks so much for your patience. The model build went flawlessly and provided a really nice working model in record time so I could shoot Ha exposures for the rest of the night, all of which are keepers. I love it when things just work.

Again, thanks a huge lot! Ginge

[mworion]

Ginge, good to know it works, have fun. I close the issue now. Michel