kamisan wrote: Has anyone had any experience using an Altair camera on Astroberry or StellarMate?
After several successful image captures my Altair 290M hangs with "0.00 seconds to go" and then times out after 3 minutes in Ekos Capture (i.e. ESQ).
I've tried adjusting the "speed" control in INDI control panel but it doesn't have any detectable effect.
To reduce the possibility that it is a power-to-the-Pi issue I unplugged all non-essential USB devices (e.g. U-Blox GPS, ASI EFW, and Flip Flat.) No discernible effect on the outcome.
I've had the camera for a year and a half. It works flawlessly using INDI/Ekos on my Linux laptop and in SharpCap on a Win7 laptop. This problem appears to be related to the Pi Model B.
I am using a standard length USB2 cable between the Pi and the camera. I have on order a 1.5 foot long cable. The camera is a USB2 device.
From INDI control panel I found the INDI driver version and firmware version. I compared versions on the Pi and Linux laptop. They look to be identical.
Any recommendations on how I can proceed with debugging this?
knro wrote: So this is a power issue after all? With StellarMate we started shipping 3A adapters recently due to low-voltage issues with the standard 2.5A 5v adapters.
kamisan wrote: All right, after more testing I discovered that...
Fixing the power supply issue significantly reduced the failure rate yet I still had the occasional hang.
The next big improvement came after I applied a heat sink to the CPU.
That lowered the failure rate to nearly zero but still not zero -- nevertheless a major improvement. Plus this is with running all of my USB devices connected to the Pi: (1) UBlox GPS, (2) ASI EFW, (3) Altair 290M, (4) Flip Flat.
I think what I will do next is upgrade from the Pi Model B to the Model B+ with the "official" heat sink. This seems to be the configuration that you guys are running. I'll also purchase that 3A power supply.
kamisan wrote: All right, complete total success!!
The key is KStars -- setting it up to use no more than 30% CPU utilization.
I hadn't mentioned it before but it bothered me that KStars used 60% CPU just for launching it. I figured that was the price I had to pay in order to gain access to Ekos but it seemed unfair, for lack of a better word. It turns out that 60% utilization was affecting the camera but also the timing of Ekos sequences. If you have been following my posts over the past couple of days you may have read that my Flip Flat was acting strangely. The sequence told it to park; it did but then immediately unparked itself. Bizarre stuff.
Back to KStars. I discovered this effect when I zoomed into a rich star field and 2 degree FOV. CPU utilization was running higher than 60% and network utilization was very high due to all of the stars panning across the FOV each second. I switched to the Ekos window and tried to open another sequence that I created earlier. This normally causes an Open File modal window to open. But this time the window did not fully render. There wasn't anything I could do except X it out. Well, to the best of my knowledge, modal windows are controlled by the parent, in this case KStars. Since it was so overwhelmed with calculating star positions and rendering them that it could not devote any time to the Open File window. Perhaps eventually it could steal enough CPU cycles but not within my lifetime.
So I thought to myself, why do I need to see all of these stars? I don't. I would be happy with 12th magnitude or brighter. I launched the KStars settings dialog and discovered that it was showing everything down to 16th magnitude! I changed it to 12m. The CPU immediately fell to 20%. But when I searched for NGC 4565, I got the label but not the ellipse, so I increased it to 14th magnitude. Now I have the ellipse at 30% CPU. I followed up by running a Ekos capture sequence that used to fail. I ran it multiple times, again and again. Perfection!
I do know that I can minimize KStars and still have access to Ekos and INDI windows. This could work for me if the modal dialogs were not controlled by KStars. I like my solution better. This way I don't have to worry about accidentally harming a running capture sequence if I bring up KStars to see what's up.
You guys with your fancy Pi Model B+ probably don't have to worry about this because your CPU is a couple hundred megahertz faster than my Model B. This coming Tuesday looks to be clear. I'm going to give it a try!
Thanks for listening to me ramble on.