I too am waiting to have the tabbed view feature working on 3.5.2. I have kept using 3.5.0 as it was the last update that allowed working with the tabbed view (at least in MacOS).

I tried working with both 3.5.1 and 3.5.2 and found I kept getting random crashes, sometimes in the middle of observing sessions. Two days ago I updated my Astroberry, getting 3.5.2 in the process and last night I decided to use 3.5.2 on the Mac as well. (I really like the new view for Polar Alignment!) To my surprise, NO crashes all night. Maybe the secret was to keep the Pi updated too...?

But still no tabbed view, but I "made do".

Now to solve the problem of my first few exposure attempts failing and the exposure time not update immediately with my Fuji X-T3... (overall last night's session was the least frustrating session I've had so far since starting this journey last November)


Quick Update:  My trial using the FITS format as the "saved" one failed.  I was only getting greyscale images.  My processing software handles the RAF format just fine so I'm back to  just saving the "native" RAF format (to camera and to Pi).  Tried "compressed" RAF (in the camera, not in Kstars/Ekos/Indo setup) last night.  Seems to work and half the size. (Siril won't read the compressed file - or at least didn't last time I tried it, but PixInsight does).
Ran afoul of crashes last night - 3 hours outside and only 31m 2 minute exposures.  Hopefully tonight will be better (two clear nights in a row w/o moon, hasn't happened since last fall)


Here is he FITS header for the one image that did come through (Kstars 3.5.0) with proper RGGB Bayer filter pattern. (note 8 bits/pixel & 3 data axes vs. 16 bit/pixel & 2 data axes with GGGG pattern)



With Kstars 3.5.2 (downloaded today, Build: 2021-02-28T17:27:50Z)

In attempting to save a step in preprocessing I experimented with setting Ekos for FITS image transfers rather than RAW. It appeared to work but on examining the resulting images I find they all have a Bayer filter setting of GGGG rather than the RGGB I set in the Indi Control Panel "Image Info" tab. I get a pop-up window indicating a Debayer error of "Unsupported bayer pattern GGGG".  Upon Debayering in PixInsight I get three channels - all grey, no colour.

Resetting Indi Control Panel back to RGGB does nothing. As soon as the image is taken, the setting (in the left pane) changes back to GGGG.

Any suggestions as to why this is happening?

Quick Aside:  I just went back to Kstars 3.5.0 and tried the same thing - transferring file as FITS.  First image worked, resulted in properly Debayered RGB image. I notice the Indi CP setting was for 8 Bits per pixel.  I changed it to 14 (my camera's value) and the next capture resulted in a grey image with Bayer Pattern of "GBRR" rather than GGGG like 3.5.2 or the correct RGGB setting.  Even stopping the program and power cycling the camera would NOT get me back to a "correct" FITS image with colour.   



David Swinnard replied to the topic 'PbPi4 issues' in the forum. 2 months ago

Peculiar. I can't offer you any insights into this issue, but I am curious as to whether the issue persists if you connect via Ethernet rather than wifi?


I can see where this might be a useful feature. I struggled for a while with downloads (to my laptop from the camera attached to the Pi at the telescope) taking up to 70 seconds (via wifi) and ~22s over Ethernet. Regardless of the SD Image setting (save or don't save to SD card in camera) I had duplicate images (though named differently) saved by the camera. I decided I could live with the duplicates as I'm running the Pi from an SSD.

Eventually I hit upon setting Ekos Camera Module (on laptop) to Save: Remotely (remote as in, on the Pi's SSD, Remote meaning the location of the Indi server) while the Indi server tab Options: Upload setting was set to Local (i.e. on the Pi SSD) This results in minimal time lag with the drawback being that I'm not able to review the captured images. If I want to see the images (in non-real time) I ssh to connect to the Pi and download the file(s) using my laptop file browser which sees the Pi as a member of the local network (Ethernet connection makes the image transfer quick enough)

Perhaps if I had the option to NOT download the images and just have them live on the camera's SD card I would use it. I tend to delete on set of the duplicate images anyway to save space.


In the document on the page: indilib.org/devices/ccds/gphoto.html, regarding image formats it states:Image Format... Raw images from the camera will be in whatever mode your camera is set to (normally either RAW or JPEG). When using RAW images, it is the client software's responsibility to convert these to a usable format via libraw or equivalent. You cannot use RAW+JPG mode it is not supported by the driver, you must pick a single format.

This is in keeping with what @knro states about only one file going back to the client. Not a camera issue, but a driver issue.  I've run across other situations too where the not all the features a particular camera is capable of is supported by the driver(s) required. (a major one that got me was the shutter speeds.  The Ca;pture Module in Ekos has a much bigger set of choices than my camera actually supports. By digging through the log files I was able to see that my camera (Fuji x-T3) supported only a subset of the exposures on the list.O)

This is much more a" try it an see" learning situation than a turn-key one. Give where I live, there is a lot more opportunity to "play" with the system in a non-imaging learning environment than to engage in actual imaging.  (make notes...)


...and the last few: (now all I need is some clear nights - only had 3 since mid-December)


And now more of the screen captures:


I will get the rest of the screen shots posted after this...

Regarding all exposures being the same: The camera must be on "B" and use the "electronic shutter" (ES) otherwise it can't be controlled remotely. AND as timopro mentions you can only use a subset of the shutter speeds that Ekos shows in it's drop down list of shutter speeds. The list of "acceptable" shutter speeds is shown in the log files and is as timopro shows in his post.

I change exposures only in Ekos Capture Module and not in any of the Indi screens (the Main Control tab shows "Preset" of 1/32000 but is not green lighted. This is the max. shutter speed of the electronic shutter on the Fuji X-T3 (and likely others.)

@timopro... Yes I now use FITS files for processing (as Siril and other processing programs use this format natively) but have the RAF files available on the camera's SD card if I need them. I like the fact that Ekos will name the files saved on the Pi with object, exposure time, date and sequence number while the camera uses it's normal numbering scheme.

The point about Indi not being hot-pluggable is great. I learned that through trial and error, hence the power-up ritual.

Using the 12V powered USB hub I find the camera drains it's battery very slowly and to this point I have not needed to change the batter during an imaging session (if I start with a freshly charged battery). The camera uses the USB power to charge the battery if the camera is off and when the camera is on and in use, seems to keep the battery from draining quickly. The hub came as solution to my low voltage warnings on the Pi and the fact that Ekos wouldn't always see my Fuji and the ZWO ASI120mm mono guide camera if they were on the same device - so ASI on the Pi and Fuji on the hub works fine. My boot SSD is also on the hub - no more undervoltage issues on the Pi (and it's on a 10A rated 5V supply of it's very own via my power-box).

A few other random observations. Camera USB set to proper mode (previous posts), I have camera power off time set to NO so it won't shut down during any time I spend troubleshooting or just setting up. JPEGS work, but why use them, but RAW+JPG apparently doesn't (I haven't tried it as I don't shoot that way).

No real progress on using "video" for focussing in Ekos but using the camera back and a Bahtinov mask make focusing very easy (as long as I can bend around enough to see the screen).


Here are some screen captures from Ekos & Indi related to my Fuji X-T3 settings, these work for me - Kstars 3.5.0 running on my MacBook Pro (2016) with the imaging equipment attached to a Raspberry Pi 4B (4GB) running Astroberry (current). Captured on a running system.

First a few of the Ekos Camera Module:

NOTE: I save "Remotely", that is to the Pi running the Indi server so the large file doesn't need to be transferred to laptop. (which is quite time consuming and delays next image while transfer occurs.)

Now most relevant Indi tabs (others where I made minimal or no changes to will be in next post)
I started saving the raw (RAF) files but switched to FITS to save a conversion step in later processing.


Steve, I will capture some screen shots of my setup in Ekos and Indi for the relevant tabs when time allows (today or tomorrow).

I am using the internal guider rather than PHD2 for no reason other than I wanted to keep it all "in house" in my learner phase. I have found that I need to follow a set sequence to ensure things work as expected - the biggest "gotcha" is the Fuji not working due to some sort of directory error or communication timeout. Getting an external, powered USB hub made the system more reliable as I think the Fuji was trying to draw too much power from the Raspberry Pi (to keep the battery topped up).

Despite following my setup ritual (devices connected appropriately, Fuji switched ON before connecting with Ekos, etc.) I still get frequent image capture failure for the first exposure attempted. I ALWAYS make a short exposure time test with at least TWO shots in the sequence. >90% of the time the first exposure fails on the first attempt but if I've remember to check the image save location settings are "correct" the second attempt works, (and as I'm still new to this I'm often forgetting one step or the other...)

Even so, with everything "perfect" I still get random, unexplained Kstar crashes (3.5.0, 3.5.1 and 3.5.2). Not in the middle of an exposure sequence that I can recall but while I'm attempting to do something else (can't make any correlations here).

I also figured out how to save FITS images to the Pi while the RAF files go to the camera's card. (One less step in later processing, though I've yet to have a clear night to try it with actual astro images.)


Every now and then I find Kstars (3.5.0 & 3.5.1) will crash, seemingly randomly, but so far not during an actual imaging session, just during testing and fiddling about. (Which is good considering how few clear nights we get around here in the winter.)