I've only used INDI with KStars/EKOS since I started digital astrophotography several years ago. I first want to thank Jasem and others who have put so much work into KStars/Ekos and INDI drivers, and helped me save many problems. But now that I am running a remote observatory, I have found that I need to see what else is out there. I have a Nexdome observatory and they upgraded their firmware and solved a major issue with the slaving going out of sync after an hour or so. But there is no INDI driver for the new firmware and so I have not been able to use the observatory since. So this is a good time to try other software, Windows ASCOM software that I have never used before.

I bought my very first ever Windows PC for this endeavor (I have only used Macs and Linux since 1996). This first foray into Windows has not been fun. But I am making headway. I did waste three hours today before I learned that you need Windows drivers for my cameras and other gear. My Macs never needed such things. The second thing that I learned is that ASCOM is messy. So many tools and apps just to connect one dome. I ended up trying NINA to see if it works with all my gear and the dome.

Today I have finally got everything connected, and will test it out on the next clear night. But I have been reading about NINA and its polar alignment routine is not nearly as nice as EKOS's. And I am forced to use an external guider like PHD2 and that will be a real test. I tried PHD2 last year and it would not play well with my CEM120 EC2 mount. I never could get it to work, as it fights with the encoders. But EKOS's multistar worked like a charm. If I can't get PHD2 to work, then my experiment with NINA and ASCOM will be over.

And then there's the lack of a planetarium. I will have to find an external one that works. But I will miss the seamless connection between KStars and EKOS.

But the biggest thing I learned today is that I can't run all my gear at home while controlling all that equipment remotely out in the observatory via INDI. VNC is sluggish.

If anyone ever gets time to write the new INDI driver for Nexdome 4.0, please let me know! I can't wait to come back.

I have switched among many astroinmaging software suites and OSs over a decade, and I feel your pain!

One thing I've found in common among Windows, Mac, linux, Pi, StellarMate, KStars/Ekos, TheSkyX, SequenceGeneratorPro, CCD AutoPilot, etc is that they all take a lot of tweaking to get right. For me we're talking weeks to months, not hours to days. There are so many interacting components and it's NEVER easy to make a switch like that.

There was a thread on here awhile ago about the need for "total commitment" to be successful with INDI and Ekos, and I agree. But it really applies to all of these other options as well.

I wish you luck with your adventures in Windows and ASCOM. If you seek an integrated Planetarium solution you might consider TheSkyX, Stellarium, or CCDCiel.

A quick read of the release notes for v4.0.0 inicates that the changes are in the formatting of the commands/responses. So if there is no required new functionality, it should not be that hard to create a new driver to suit.
I'm willing to at least have a look at what's needed first.

It looks to me like the issue is with the Low battery functionaiity introduced in 3.4.0.
There is a new command B to read/write the battery low voltage threshold and a new event :Volts
As a guess, I think the :Volts event is being received but cannot be handled or even ignored. But it is pretty easy to add it to the events map in nex_dome_constants.h.
Adding code to read/write the thresholds is a bit more work.

Thanks Kengs! Keep updating this thread, and I will be happy to test any changes to the dome driver you make, with regards to Nexdome 4.0.
As I mentioned above - the dome driver is the only issue that is keeping me from using KStars/EKOS now. It's a show stopper for me.

Peter

Made some small changes and raised a PR. @PK we may need you to test it as I don't have a Nexdome
Hopefully Jasem or someone else can advise how to make that work

github.com/indilib/indi-3rdparty/compare...elf:nexdome?expand=1

@PK The PR has been accepted so should show up in the nightly build. I'm not 100% sure it will fix the issue but it wont do any harm.
Can you supply an INDI log that shows where it fails and/or describe what fails?
Meantime I'm going over the Nexdome firmware code itself. Based on the documentation the protocol change going to 4.0.0 is minimal but the code may show something else.
Also note the first bullet in the release note:I made a change based on the second bullet but in fact, as far as I can tell, the formatting did not change at all. They just added a new command and response.

I downloaded the latest Nightly, but I can't unlock my dome to test it right now as the winds are gusting to 40 MPH (64kph)

Peter

The wind died down a bit, so I gave the update a shot.

After a bit of a struggle to get the mount to load (USB issues again) I finally got everything connected. The mount's slave, rotator and shutter settings were all zero again. I re-entered them, and saved them to eprom. I tested the dome to slave to various parts of the sky, and it all worked. The shutter didn't disconnect, and the dome rotated appropriately.

When I moved the mount to home (000 az.) the dome slewed to 000, then onto 090, and back to 360. Once it git back to 360, it stopped appropriately. Some reason that "000" sends it 090. Not sure why, since the mount was at 000, it's park ing position is 000, and the dome's home/park position is 264. Nothing is set to 090. But it sopped after that one iteration, so I'm not too bothered by it.

I then turned everything off and tried again, This time I turned on the debug logging.

INDI again failed to connect my mount. I tried rebooted three times, turned off the mount and back on, and it failed to connect.
It is supposed to connecting at USB0 - but it won't. And when I try to SCAN for ports in EKOS - it only shows USB0 as an option.
So I was not able to test the slaving again.

Also - while the slaving and dome rotator motor settings were still saved in the EPROM and loaded up, the SHUTTER settings reset back to ZERO.
I tried saving them several times, and INDI said all was written to EPROM, but when I rebooted and checked, the shutter settings were back to zero.

I didn't have this issue with the ASCOM driver, so its not the shutter firmware.

So he attached debug should show the CEM120 not connecting, and the shutter saving to EPROM several times - but which was either never saved, or the settings are reset back to zero upon loading.

This all looks odd so a few questions:
Are you running INDI on the same computer hardware as ASCOM
Did you need a new ASCOM driver
Do you have the INDI logs /home/astro/.indi/logs/2021-01-25/indi_nexdome/indi_nexdome_01:06:15.log and /home/astro/.indi/logs/2021-01-25/indi_ioptronv3_telescope/indi_ioptronv3_telescope_01:06:15.log
(not that I expect to see anything different but just in case. There is not much in the Kstars log for the mount)
Can you just confirm that is was a short session - about 3 minutes

As far as I could find out there was no new ASCOM driver with the firmware release so it would not be a protocol change
The comms issues with the mount could be a factor in your problems. It looks like the mount was disconnected from INDI the whole time.
from the log what it shows is:
At 18:06:27 INDI tried to connect to the mount but failed handshake
At 18:06:55 INDI tried again and failed handshake
At 18:07:04 INDI tried to connect to the dome and failed (this looks like a possible driver issue with an unexpected response)
At 18:07:10 INDI tried to connect to the dome and succeeded

At 18:07:12 Tried to update dome Acceleration and velocity and failed
At 18:07:12 Tried to update dome Acceleration and velocity and failed
At 18:07:36 Tried to update dome Acceleration and velocity and succeeded
At 18:07:36 Tried to update dome Acceleration and velocity and succeeded

At 18:07:38 tried to save to EEPROM but no response (but other event inputs were received)

At 18:08:30 INDI tried to connect to the mount and failed handshake

At 18:08:51 shut down INDI drivers

The X2 drivers for TSX broke with v4.0 and also needed to be updated as a result of Tim’s changes, they’re open source so the solution is probably in there.

I’ve been trying out Voyager recently for similar reasons (remote, just need it to work, funky Paramount/INDI bugs and the one things that I would lobe most - a ‘’suspend/resume on cloudy” option) and while it has a few nice features it’s neither that much better (worse in places) it doesn’t come close to what the team here have and continue to build, for the love it it.

Agree that ASCOM is a clunky old mess (as you’d expect from something that’s got a ton of tech debt) and INDI/Indigo show clearly how it should be done. I’m running Windows, but not through choice, the sooner I cam get back to INDI/Ekos the better.

P.s. I’m a huge fan of spending money with people like Jassem and others who offer supported, paid products, they help me focus on the hobby of AP and not try to rebuild my long forgotten coding skills.

Looking through the Kstars log again I see a couple of things:
After the "ZWS" command to update the EEPROM for the shutter there is no response to the command - but events are received about 8 seconds later
There is no "ZWR" command to update the EEPROM for the rotator. I'll look into those a bit more.

@PK you might want to change the thread title to avoid unrelated posts