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?

Thank you.

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?

Thank you.

There has been many ongoing issues regarding these cameras and INdI, the issues are down to the Altair camera SDK being problematic, and Jasem has worked hard to try and sort this.
The problem was mainly when trying to use two Altair cameras at the same time, one for imaging and the other for guiding...
I think in the end only one camera can be used and it has to be the newer ones, the older ones still have the issue...
BUT in saying all that your camera has worked ok, so my guess would be a power issue, is the power supply powerful enough for your PI as most people use powered hubs for the equipment and don’t plug it all into the PI directly, this helps a lot...so something g to check..

Thanks, Astronerd, your input prompted me to concentrate on the possibility of power issues. It paid off:

A little bit of history: Three years ago I purchased two Raspberry Pi Model B and two 5.25V 2.4A switching power supplies from Adafruit. (One of those two power supplies has since gone missing.) The remaining power supply I use on one of the Pi's that I made into a stepper motor controller using an Adafruit HAT for my telescope. It works flawlessly. The other Pi sat in a drawer for all these years until now when I installed Astroberry. Like I said I only had one power supply so I used it to test the Astroberry. That's the problem:

That three year old 5.25V 2.4A power supply sends 5.45V to my Altair camera. I measured it using this "USB Charger Doctor" from Adafruit:
www.adafruit.com/product/1852
Current fluctuates between 80mA and 140mA.

As I described in my original post the camera will capture a few frames and then hang for 3 minutes before timing out.

Last week I purchased a second power supply from Adafruit, this one advertised as 5.25V 2.5A:
www.adafruit.com/product/1995

This one outputs:
5.31V after booting
5.26V after launching KStars
5.23V after launching INDI/Ekos
5.23V while capturing frames

With this new power supply there is no hanging!

For comparison I hooked up the camera directly to my Linux laptop and ran the same tests. No hanging and voltage regulated perfectly at 5.23V.

Thanks for your help!

PS: I would have to dig into the specs but it looks to me as if the Pi simply routes the power from the power supply directly to the USB device. I guess it assumes that the device has its own voltage regulator. Apparently the Altair camera does not regulate it. It just uses it in its raw state.

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.

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.

He’s, I use a 3 amp adapter as the 2.5 Amp one I was using was giving issues...

I use a 3A supply I found on Amazon that has a power switch attached to it. I have never had an issue with it.

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.

Thanks everyone.

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.

Thanks everyone.

Hi, yes you have far too much running direct from the PI, you really should use a powered hub, that will eliminate the issue I suspect...

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.

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.

That’s great
But actually the reason many of us don’t have to worry about this is that we don’t run Kstars on the rpi, but on a seperate laptop, and the rpi is just the INdI driver server, the reason being that the rpi is not really powerful enough for the job in many cases...even the B+, especially when all kit is connected to the rpi.
I have the rpi on my mount and Kstars / Ekos running indoors on my Kubuntu laptop and connected to INdI server on rpi via WiFi... and all kit connected to a USB powered hub on the rpi....it’s called remote control as opposed in your case Local control....

I can't find Kaczorek's post right now where he talked about the pros and cons of running remote vs local. If I understand it correctly the problem with running INDI server on the Pi and Ekos on a laptop/desktop is that you are at the mercy of your connection. My understanding is that capture sequences and jobs are executed by Ekos. If your connection goes down then your Pi is just a bucket of bolts without a leader telling it what to do.

My objective is to travel to sites having skies better than Bortle 5 with no trees blocking my view. As it is now I just have a view of the east with no ability to meridian flip plus on top of that I get maybe 4 nights per month of clear skies. If I try what you do then I need to keep my laptop alive all night -- my battery won't last that long and I am not keen on buying a bunch of spares or relying on a DC/AC inverter.

Thanks for all your help and tips.

I've been trying to get an Altair GPCAM working with no success. It fails at startup with an INDI Server Message: No Altair detected: Power On?
This is shown twice. That's it, the camera isn't shown in the tabs showing the selected devices.

I've tried several versions of the driver, currently
indi-altaircam 0.2~201903091507~ubuntu16.04.1
indi-altaircam-dbg 0.2~201903091507~ubuntu16.04.1
libaltaircam 1.0.1~201902271744~ubuntu16.04.1

The camera is a little old, but only two or three years, it's exact type is GP-CAM MT9MO34MM MONO as written on the camera and GPCAMMT9M034M as written on the box.

Are there any clues for how to proceed?

lsusb and demsg both show the camera.