David Dufres replied to the topic 'Compressed FITS capture?' in the forum. 1 month ago

Easy workaround in the meantime would be to use a post-capture script to use fpack on the new file. Uncompressed file would still be opened in KStars after downloading, but would sit side-by-side with the compressed one until a post-job script could get rid of the uncompressed files.

How would one pass over the most recently captured filename as a variable to the post-capture script?


David Dufres created a new topic ' Compressed FITS capture?' in the forum. 2 months ago

Is there a way to configure the EKOS capture module to use losslessly compressed FITS as a capture format? There is a compression option in the INDI config but thereafter the FITS viewer and other EKOS modules say they are not compatible with the format. As it is purely for storage and download purpose, I can always write a post-capture script to compress the picture and delete the original, but that seems unnecessarily convoluted.


David Dufres replied to the topic 'Indi 1.9.2 Ubuntu 21.10 Armf' in the forum. 3 months ago

Same for Ubuntu 21.04 - indi-playerone has not properly built for arm64, breaking the Indi-full metapackage.


David Dufres replied to the topic 'Raspberry Pi HQ Autoguiding?' in the forum. 6 months ago

Am revisiting the idea this weekend - had dropped it as my RPi4 died and I had moved to another SBC (NanoPC T4) that is hardly drop-in compatible to the Rpi camera lineup.

However, am currently having worse and worse performance from my T7C, I found a solution to both the NanoPC compatibility and inconsistent pi cam support in INDI:

It’ll use a 10$ Pi Zero to turn the Pi Cam HQ into a USB UVC webcam. From there, it should JustWork (TM). I gain almost 100% sensor size, going from 1/3.2" to 1/2.3", smaller pixel size even with 2x2 binning and faster bandwidth. Down the road, also possibility of bluetooth connection if needed (although then still need to power the Pi Zero which is powered via usb otg anyway) and to add other pi-compatible sensors (thinking GPS/temp/humidity). Funnily, Arducam sells a picam-to-uvc board, for 100$. Here total cost will be 12-13$ (board + small SD card).

To be continued soon ;)


David Dufres created a new topic ' dSLR-derived GPS data?' in the forum. 10 months ago

Sorry if this was addressed already, but I can't seem to find the answer.
I recently picked up a Nikon D5300 for pennies (lil' crack on the casing, works 100%, rapidly de-filtered).
D5300 has internal GPS, providing both location data, elevation and accurate local time. Is there any way EKOS/INDI can poll this information and use it for GPS/time data directly, thereafter updating the mount? Else I'll try to write a routine that queries the setting from the dSLR upon connecting the USB cable and update the data in the RPi setting, and from there use the virtual GPS settings, but that's more trouble for no good reason as EKOS should already query the dSLR settings and informations upon starting.


David Dufres replied to the topic 'Raspberry Pi HQ Autoguiding?' in the forum. 1 year ago

Just finally got my HQ cam in the mail. Still waiting for my c-to-t adapter before I can properly test.
12mp is excessive and, as someone mentioned, light sensitivity is not the best, so I was thinking of doing the following:
1. Mate it with a svbony guidescope (30mm aperture, 120mm focal; not the widest but better than the official rp hq cam lenses, and a solid fixed focuser).
2. Do pixel binning - dual advantage of reducing file size and increasing sensitivity. Still will have sufficient angle per pixel since I’m planning on using a aps-c sensor dslr with a 200-600mm focal as main imager

Will try and work out the software kinks waiting for the c-to-t adapter, and the guiding thereafter. Will let you know how that goes!


David Dufres replied to the topic 'Raspberry Pi HQ Autoguiding?' in the forum. 1 year ago

Thanks for the response!
How would you go about calculating this? I googled rapidly and didn’t find a satisfying answer. 25mm lens states a FoV of 19.6 deg, do I just go ahead and divide by the horizontal (or vertical?) resolution or is it more difficult? And what is an appropriate deg per pixel for a guide camera?


David Dufres created a new topic ' Raspberry Pi HQ Autoguiding?' in the forum. 1 year ago

I’m thinking of acquiring a Raspberry Pi HQ Camera for autoguiding using PHD2; it has (from specs) decent sensitivity, capacity for binning and raw output, 12mp resolution, possibility to remove the IR filter as well, better at long exposures than Pi Cams v1 and v2. It does gave a rolling shutter however.

With an aftermarket 25mm c lens, it’d be equivalent to a 350mm lens on my crop sensor Nikon, and the 25mm lens is pretty fast at f/1.6. Whole thing would cost about 75 USD.

Any thought about this setup? Beats acquiring a dedicated guide scope or guide scope+cam, although a c-to-t mount exists if it is felt a guide scope would be necessary, and it’s be pretty easy to mount on the scope (straight-up 1/4 screw mounted on the ring) or on my astro dSLR body (hot shoe to 1/4 adapter). It seems to be supported by PHD2, but any optical or indi-related reason not to go for this setup?


Already done and assigned to someone. D500 is a new-ish body (2017) and less popular due to price than other crop sensor bodies, therefore likely that less time was devoted sorting through its SDK (still puzzled why Nikon wouldn’t have just one SDK for all bodies)


Figured a fix:
Modding the libgphoto2/camlibs/ptp2/config.c and adding a D500 alias referring to the D850 image compression (ie:image format) table, then recompiling the whole thing and installing just the ptp2 driver fixes it.

Now on to fixing bulb capture...


Have been trying to have Ekos/INDI up and running for the longest time on my current setup (see below) using a pre-made image of Astroberry. Most of everything works great, but have not been able to capture images consistently using my Nikon D500 DSLR. Finally realized the issue - the Aliases from gphoto2 for this DSLR body are all screwed up.
From CLI command "gphoto2 --get-config imagequality" I get the following:

Label: Image Quality
Readonly: 0
Current: NEF+Fine
Choice: 0 JPEG Basic
Choice: 1 JPEG Normal
Choice: 2 JPEG Fine
Choice: 3 Unknown value 0003
Choice: 4 NEF (Raw)
Choice: 5 NEF+Basic
Choice: 6 NEF+Normal
Choice: 7 NEF+Fine
Choice: 8 Unknown value 0008
Choice: 9 Unknown value 0009
Choice: 10 Unknown value 000a
Choice: 11 Unknown value 000b
Choice: 12 Unknown value 000c
Choice: 13 Unknown value 000d

Now, by trial and error (ie: gphoto2 --set-config imagequality=0 && gphoto2 --capture-image-and-download && gphoto2 --set-config imagequality1 &&, all the way to imagequality 13), it appears it should be the following:

Label: Image Quality
Readonly: 0
Current: NEF+Fine
Choice: 0 JPEG Basic
Choice: 1 JPEG Basic*
Choice: 2 JPEG Normal
Choice: 3 JPEG Normal*
Choice: 4 JPEG Fine
Choice: 5 JPEG Fine*
Choice: 6 TIF
Choice: 7 NEF (Raw)
Choice: 8 NEF + JPEG Basic
Choice: 9 NEF + JPEG Basic*
Choice: 10 NEF + JPEG Normal
Choice: 11 NEF + JPEG Normal*
Choice: 12 NEF + JPEG Fine
Choice: 13 NEF + JPEG Fine*

Problem is, EKOS/INDI doesn't wanna see RAW/NEF+JPG as a file format. Any of the "stated" JPG/RAW are accepted as options, but I therefore get options 0-4 and 8-13, giving me JPGs (0-4) or NEF+JPEGs (8-13), with the latter randomly downloading JPG or RAW. Any one of you knows a way to do any of the following:
- Have EKOS/INDI accept arbitrary file formats in the drop down (least ideal)?
- Change aliases in the INDI Nikon driver (second best)?
- Change aliases in the gphoto library (ideally)?


Celestron AVX mount, older Hand Control with RS-232-to-usb converter
Raspberry Pi 4, 4GB, pre-cooked Astroberry install fully updated
Nikon D500, Nikkor 35mm f/1.8, Nikkor 50mm f/1.4, Nikkor 100mm f/2.8 , Nikkor 28-200mm f/3.5-5.6 AF-D
Celestron Powerseeker 127EQ (I know, beginner OTA but decent enough for my 4yo son to have fun looking at the moon and bigger objects)
Tacklife Li-Ion car booster 12V power source (66wh, about the same as the Celestron Powertank LT, and I can jumpstart my car; just need to put some red nail polish on the LEDs)