NexDome has contracted someone to write a new firmware for their controller.
The new 3.0.0 (and up) firmware is not compatible with my X2 plugin (only works with the 2.x firmware) as all the commands have changed.
For those who need a X2 plugin for a NexDome 3.x.x firmware, let me know as I have a beta version of a new NexDomeV3 X2 plugin that I've been testing on my desk dome test rig.
Rodolphe
Midland Van Lines is your premier choice for both local and long-distance moves, offering reliable services across various locations, including Aurora, Springfield, IL, movers naperville, Joliet moving companies, Elgin, and cities in Florida such as Port St. Lucie, moving companies tallahassee, Tampa, St. Pete, and Miami. As one of the leading long-distance moving companies, we specialize in residential and commercial relocations with a full range of services, including packing, unpacking, and office moving. Our expert long distance movers in tampa flĀ and long distance movers miamiĀ ensure a smooth and secure move for all your belongings. Trust Midland Van Lines for a stress-free moving experience from start to finish.
I can connect with Nexdome V3 X2 plug in through The Sky X, but the status of the shutter will not display and I have to abort the (open/close) command to do something else with the dome. Is there a reson for this? I just move over to an Eagle 5 STM running Windows 11. (it works fine on my old system)
I am swithing over to the Eagle 5 telescope controller and porting my software over, but I loaded the wrong drivers from this website (Lanatico beaver V1.4). The Nexdome 3 V 1.6 are the ones that work, but I can remmber where I got them. Can anyone direct me as where I can get these drivers? I am running The SkyX to control the dome.
The V3 firmware is in the auto-extractable windows exe.
once extracted it will install the ASCOM stuff but also extract the firmware for both controllers on C:\
There is also a firmware updater for them. On my Mac I used the command line to update the firmware using avrdude. You can also find the firmware in the github repo :
https://github.com/nexdome/ASCOM/tree/master/Firmware
The new plugin is not yet on my website as I only got it working this weekend and until it's been tested on a real dome I'd rather not publish it. So ping me by email and let me know what platform version you want for the plugin (Windows if I remember well , but OS X, Linux X86_64, Linux ARM 32 (R-PI), ... are also available).
I had also come to think it was a TSX issue.
My best guess is the initial dome slew is correct but by the time the dome gets there, stops and reports that it's tracking, it's already time for a dome-position correction which messes things up somehow.
I haven't taken a look at the V3 firmware because it was "ASCOM only," but I have read that the interrupt driven stepper provides much quieter and smoother motor control than the software-driven version. If it also creates faster dome slews (does it?) it might help solve my TPoint problem.
Since you have already developed an X2 plugin, I think it might be worth it to try the new firmware just to see how it compares to V2.X. Also, I really don't have much else to do because the skies have been cloudy around Denver CO every night for the past three months -- I've never seen anything like it in the 20 years I've lived here!
That said, I'm not even sure where to find the latest NexDome firmware. All I see on the NexDome site is an .exe file for the V3 control software which I assume is either a self-extracting zip file or an ASCOM driver? Also, is your V3 plugin on your website?
Steve
I believe the expected default is 8 microsteps (hence the divide the current steps/rev by 8 for the new firmware :) ).
The issue at the zenith is not the firmware or even the plugin as it only execute GoTo as received from the application (TheSkyX in the X2 plugin case). So if the application says got to X and then go to Y on the next move and X and Y are far apart the X2 plugin and/or dome firmware will just do as instructed.
The slit altitude > 90 is already something I brought the the attention of Software Bisque but this was ignored.. As far as I know they also do not recommend taking tpoint samples that are close to the zenith.
You should bring all of this to the Software Bisque forum so that other people can add their experience to yours and may be this will make them do something about this.
As said, moving to firmware 3.0 might help in term of support and what not, but I don't think it'll solve that issue as TSX is the one issuing the GoTo (unless there is yet another bug in firmware 2.12 :) ).
Rodolphe
Thanks Rodolphe,
I suspect the new firmware also requires "default" DIP-switch settings as well? I have been running my rotator and shutter controllers at 8 micro steps to speed things up.
The only problem I continue to have is that the dome and mount get "out of sync" on 200-300 point automated TPoint runs when the run gets to multiple adjacent target points near zenith. As you know, near zenith, a very small mount slew can result in a large dome rotation. For some reason the dome will slew to about half the distance and stop for a couple of seconds and then will start slewing again like it is making a correcting slew; the only problem is the "correction" can be many degrees which can take quite a while; in the meantime, the mount thinks it is on target and tracking after the first time the dome stopped and starts to take an image. After that, things get weird because the image link usually succeeds (because the upper altitude of the slit is >90deg) and the mount moves on to the next point while the dome is still slewing to the previous point which throws a "dome command in progress" error and from that point on in the run, TPoint thinks it is a point behind which really messes up the model :-)!
Unfortunately, TSX wont accept a slit upper altitude of >90 deg which I think could help correct the problem. I've tried different image-delay settings in TSX (up to 10 sec) but the TPoint run then takes forever and usually still gets lost on some target near zenith. I have also set the max altitude to 80deg in the automated TPoint target selection dialogue which has helped some.
Steve
The new firmware works differently. But, if your config is working .. no need to fix it (if it ain't broken don't fix it).
The new V3 firmware move more smoothly as the stepping of the motor is done under interrupts.
There is no calibration option so if you have a custom dome with a NexDome rotation kit on it, the default won't work for you (probably) and you'll need to figure out how to set the new values (if you're in that case, copy your current step per revolution value, and then in the new firmware take that value divided by 8 as the new value for the number of steps per revolution).
The Xbee code allows multiple dome to work next to each other without issues (so far).
There is no more watchdog as far as I know (the new firmware code is open source but somewhat hard to follow in some cases).
So this new X2 plugin is really for people that got the recent firmware as the default and need a X2 Dome plugin as they don't want to use ASCOM or are on another platform than Windows.
The "old" 2.12 firmware will not be maintained by NexDome and the 3.x is the new official firmware.
I agree X2 has been pretty good. I think the only problem with my 2.x firmware was using the software time-out was buggy so you made a version for me that did something I canāt remember. i also sometimes get a lost connection to the xbee but most of the time it is working.
Hi Rodolphe,
Is the new v3 firmware an improvement over the v2.x that you modified? If so, I would be happy to test your beta V3 X2 plugin. However, I have to say your V2 has been working well.
Steve