I have been trying to get a friend of mine to move across to Voyager for some time and had finally had success, as his current imaging platform can be very frustrating. We got him a small windows PC (which bench tests fine over a period of days) We installed Voyager on it and he launched the trial.
I got all his gear set up, but the PC itself keeps blue screening, the crash dumps indicate that the mount driver is causing the crashes (Temma.exe, he has a Takahashi NJP, which is a real battleship of a mount, but the Temma 2 electronics are quite primitive) it is going to be very difficult to get him on to any more sophisticated platform if the Temma driver is going to keep crashing the PC and causing blue screens of death.
Is there anyone out there using a Tak Temma mount successfully, or have you had mount driver crashes and resolved it?
If he have Thesky6 or TheSkyX probably there is a Temma driver native. But a mount driver that generating blue screen I never heard … this mean really something weird in memory management or OS layer access.
Thanks Leonardo, I am looking in to if he could/should buy a license for TheSkyX, it does appear to have a native driver for the Temma equipped mounts so it might get him going for now. I believe he is saving up for a mount with more modern electronics to make automation easier as I plan to build a roll off observatory and he will be contributing to building it so he can house his setup with me (On site tech support!) but he will be using this mount for a while yet.
I can not recall the specific error causing the blue screen but it was memory related. The problem with that mount driver is it was written by a third party with a Takahashi mount, and he then sold that mount and the driver is unsupported now, it was probably written originally for windows 98 or earlier.
I found a bit of hopefully positive information today. Apparently Keyspan 19HD USB to serial devices tend to cause blue screens with the Temma driver. I have a spare adapter with a Prolific chip so we will try that out. The mount will still be fairly primitive automation wise but primitive and reliable would be acceptable.
Just posting this here in case it proves useful to anyone. Apparently it is mentioned in the driver documentation that it will bluescreen with a Keyspan adapter, but that part did not spring out at me when installing it.
I am heading to my friends place this weekend with my spare Prolific chip adapter to give that a run based on what I have read in the last few days. He is thinking seriously about a mount change in the future to one with homing sensors so spending more money on software to get the Temma working under Windows is a tough sell. If it works properly with the Prolific based adapter I reckon I have him sold on Voyager, and Viking to manage his Pegasus UPB.
He has a Voyager trial activated at the moment and the first thing he noted was focus runs are vastly faster than with his current software which is Ekos based. Ekos can not use high speed readout for his APS-H sensor during focus and plate solving, then high quality for lights, it is one or the other unless you intervene manually. Focus and plate solve downloads take 30 seconds just like lights and the single star focus mode with an ROI produces very unreliable results and lots of failures. Even when his current setup goes OK the focus result with Voyager is demonstrably better as well as faster. He is keen to move over if we can get his mount reliable under Windows without spending a great deal.
Just thought I would touch base here. We had the opportunity to test last night and using my Prolific based USB-Serial adapter appears to have cured the blue screen errors.
Now to work out what appears to be a very twitchy windows driver for his camera. I was using the current QSI driver via ASCOM as I have not had a chance yet to install the SDK to try using the native driver in Voyager (This is the QSI 6162 I have posted about before) and it occasionally throws errors where the camera reports wildly wrong temperature values and once it does that the only way to recover it is to power cycle the camera and re connect it. With all of the setup the same but using an Indi/Ekos based imaging suite it never throws that sort of error, which is leading me to suspect the windows driver rather than camera hardware.
Edit for a little more information just found in the log file. What you wrote previously Leonardo in response to me, about someone else having similar issues which were related to cooling, QSI indicated they did not think that was the case but the log from last night supports what you wrote. The camera failed early in the night last night and we power cycled it to get it going and it worked again until the end of the night. It failed again immediately on Voyager sending a warmup command as part of the “Goodnight” actions.
Yes, I remember you mentioning that, but when we approached QSI they did not think that should be an issue. I am remotely accessing my friends imaging PC tonight to set up a test dragsript which will send one temperature related command then spend about six hours shooting test exposures before changing to sending a temperature related command before each test exposure. I expect it to fail soon after Voyager begins sending lots of temperature related commands, then I can go back to QSI and ask again about firmware.
If it fails again once the test dragsript starts sending lots of cooling commands he can probably manage it in the short term (As you suggested last time Leonardo) by having Voyager cool the camera on connection and untick the cooling option in his sequences so the sensor temperature is ignored for the rest of the session and the camera is allowed to manage it. The image file names will say “no cooling” but that does not matter.
No problem thanks Leonardo. I know there is nothing you can do on Voyagers part to fix this issue as it is the cameras problem, not Voyagers.
We went to QSI about this previously and they did not think that firmware could be the issue but the evidence that it is a cooling related firmware problem keeps building up. I noted this weekend that every time we had a failure was immediately after a cooling command was sent. It works all night using Ekos where the cooling is set on connection and then left alone all night and I expect it will do the same with Voyager if we switch off cooling management in the sequences, I did not get the opportunity to test that properly when I borrowed this camera a couple of months ago.
The exercise tonight is intended to prove comprehensively that the camera is failing when cooling commands are sent so we can go back to QSI with that.
This is proving to be a hard fault to replicate. I set up a dragscript for my friend last night which cooled his camera to -25 degrees then shot 6 hours worth of 900 second test exposures, then changed to a second block which sent a cooling command then a 300 second exposure, then a cooling command etc and the camera behaved perfectly for another six hours, as it always has done on the bench!