MantisBT - Issues

0002950: Impossible de connecter Cache calibrateur Wanderer

Mon, 07 Sep 2026 14:27:37 +0200

CCDCiel refuse de connecter le Cache Calibrateur WandererCover V4-EC (240mm) de mon setup.

Erreur console:
22:50:05 Connexion de Cache calibrateur ASCOM "ASCOM.WandererCover1.CoverCalibrator" …
22:50:05 ASCOM.WandererCover1.CoverCalibrator: Connection error: Method 'Connect' is not supported by automation object

Les autres équipements du setup se connectent sans problème (ZWO533MM Pro, ZWO174MM mini, ZWO AM7, WandererBox Pro V3, focuser ESATTO 2'', roue à filtre ZWO) à CCD Ciel.

Le setup est contrôlé par un mini-PC GEEKOM sous Win11.
CCDciel
Version beta 0.9.97-4213-be54a24a 2026/07/15 10:43:0

Pour information cet accessoires peut être connecté sans problème sur NINA.

0002896: SVBony powerbox switch

Mon, 07 Sep 2026 14:23:25 +0200

I couldn't connect to the SVbony SV241Pro powerbox (https://www.svbony.com/products/sv241-remote-astro-power-controller) using ASCOM. It shows an error: "ASCOM.SVBONY.Switch: Connection error: Method 'Connect' is not supported by automation object"

The ASCOM driver is installed, and I can connect it from Astro Photography Tool (APT). Also, if I use INDI (running on Raspberry Pi), I can connect to it from CCDCiel running on Windows.
But I couldn't change values in the PWM fields in the switch window. They always immediately return to default values. The only option is to set it directly in the INDI server settings.

0002949: Cannot Connect to Telescope

Mon, 07 Sep 2026 14:19:14 +0200

I have an EQ6R-Pro, which I run remotely via PC through ASCOM and EQMOD (also installed). Unable to add EQMOD.Telescope to the telescope connection window in Cartes du Ciel. It always defaults to POTH.Telescope under the Telescope connect window. Even if I try to change the telescope, the drop down in the ASCOM telescope chooser window shows nothing. It is literally blank.

I can control the telescope successfully with NINA and Stellarium, and both are working flawlessly with ASCOM and EQMOD. But I want to stop using Stellarium due to its slower-than-molasses performance and permanently switch to Cartes du Ciel. However, I am unable to do so. I am attaching a couple of images to show what is happening. Not sure how to fix it.

0002951: VM 9.1 Coordinate grid tranparent.

Mon, 07 Sep 2026 14:18:27 +0200

Coordinate grid is transparent through to the far side of the Moon confusing when attempting to pick out the correct grid lines.

0002948: Offer to contribute a native macOS (Apple Silicon) port of Virtual Moon Atlas

Thu, 03 Sep 2026 09:05:40 +0200

Hello Patrick,

Thanks for Virtual Moon Atlas. I have completed a native macOS port of VMA (and all the helper apps) based on current git master (commit ba50db0, version 9.1a). It builds with Lazarus/FPC and runs 64-bit ARM native on an Apple M1 (macOS 26.6 build 25G72), no Rosetta, no emulation. The main new piece is a Cocoa OpenGL context backend for the GLScene view; the rest is small platform-guarded build fixes and a script that produces a self-contained .app / .dmg. Linux and Windows builds are unaffected.

Testing so far is limited to my own hardware, but it is stable in normal use.

Would you be interested in bringing this upstream? If so, I am happy to prepare it however suits you, one branch or a series of smaller patches, and to help maintain the macOS side.

Thanks,
William Henderson

0002946: Atlun - blank display with QT5

Thu, 03 Sep 2026 09:02:24 +0200

Hello,

First of all, congratulations on Virtualmoonatlas, it's very neat.

There's an Archlinux AUR package that compiles virtualmoonatlas' master branch, and it uses gtk2.
Since gtk2's deprecated and not even in the main Arch repositories anymore, I tried building with LCL_PLATFORM=qt5 make instead.

It built and installed fine, yet when launched, neither the moon nor the black background appeared.
I have attached a screenshot of that. On the otherhand, photlun, for instance, worked fine. With GTK2, there weren't any problems.

I am not sure whether QT5 is actually supported. If not so, I'd be interested in having QT5 support so that I can modernize the Archlinux package. I am no Pascal programmer and hence don't know large an effort that would be, though.

Thanks for your help

0002947: Remplacer les espace par _ n'est pas pris en compte

Mon, 31 Aug 2026 16:47:23 +0200

Lorsque je modifie le choix de séparateur pour le nom des objets en passant de - à _ le séparateur ne change pas. Si je passe de - à . cela fonctionne.

0002945: Platesolving of control frame fails because mount is still moving

Thu, 20 Aug 2026 14:00:20 +0200

We got a crazy behavior mostly on large goto slews. CCDCiel is starting the control frame and the platesolving process but the scope is still on its way to target. Therefore platesolve fails.

ccdciel log says got is finished
2026-08-13T22:44:25.265 3: EQMod Mount: Schwenk ist abgeschlossen

but devices log stated it 20s later
2026-08-13T22:44:45.287 EQMod Mount: [INFO] Telescope slew is complete. Tracking TRACK_SIDEREAL...

What can I do?

Mount: Skywatcher EQ8
IndiLib, Indistarter, EQModGui
CCDCiel and Indilib on same pc, therefore timestamps in logs are in sync.

0002942: Indi, CCDCiel handling of Indi driver refusal connect

Mon, 17 Aug 2026 17:27:16 +0200

Noted the following:

Indi, CCDCiel handling of Indi driver refusal connect result in this in the log:

026-08-04T22:18:07.201 9: Sky Simulator: Connecting to INDI server "localhost:7624" for device "Sky Simulator"
2026-08-04T22:18:07.216 2: Connecting Mount INDI "Sky Simulator" …
2026-08-04T22:18:07.278 9: Sky Simulator: INDI server send new device: "Sky Simulator"
2026-08-04T22:18:07.278 9: Sky Simulator: Exec: indi_skysimulator, Version: 1.0, Interface: 1
2026-08-04T22:18:08.622 1: Sky Simulator: Server Disconnected
2026-08-04T22:18:09.279 1: Mount connected
2026-08-04T22:18:10.404 3: Sky Simulator: Mount capabilities:
2026-08-04T22:20:47.476 9: Disconnecting devices

A driver that refuses a connection is legal INDI, and the client should say so rather than dropping the server and claiming success.

0002944: CCDCiel opening port 0 for TCP/IP server

Mon, 17 Aug 2026 17:20:03 +0200

Hello,

I've been having a new problem for the past two days: CCDCiel seems to be trying to start the TCP/IP server on port 0, which of course fails. In the settings, the default port is actually set to 3277. Resetting it doesn't change anything. I've already reset the configuration files, but that didn't help.

I tried both the PPA and daily versions of CCDCiel, and both exhibited this behaviour.

CCDCiel log:

[...]

2026-08-13T11:35:41.007 1: TCP/IP server stopped

2026-08-13T11:35:44.059 1: Socket error 9: Bad file number.

2026-08-13T11:35:44.225 1: Socket error 9: Bad file number.

2026-08-13T11:35:44.257 2: TCP/IP server is listening on port: 0

[...]

2026-08-13T11:36:56.642 1: Socket error 9: Bad file number.

2026-08-13T11:36:56.645 1: Socket error 9: Invalid file number.

2026-08-13T11:36:56.656 2: TCP/IP server is listening on port: 0

[...]

0002943: Wrong Moon Rise and Set Times in Ephemeris, and Details

Mon, 10 Aug 2026 19:20:56 +0200

When checking the rise/set times in the Ephemeris Calendar, they are totally wrong when compared to rise/set times from other sources.

For example: https://www.timeanddate.com/moon/canada/toronto

The same error can be found when clicking on the moon, and selecting the object details, at the very bottom:

Rise: Local horizon 03h42m42s Azimuth: [...]
Transit: [...]
Set: Local horizon 14h06m33s Azimuth: [...]

0002941: CCDCiel discovery find only one of two Alpaca servers

Wed, 05 Aug 2026 11:30:12 +0200

My Sky simulator has Alpaca server address 127.0.0.1, port 11111. When I use a com device in Ascom 7 is starts a second Alpaca server 127.0.0.1, port 32323. CCDciel sees the only the Ascom7 server. Fix to discover both servers:

cu_alpacamanagement.pas:

Line 354
- if not f_loopback then Result.Add('127.0.0.1');

+ {A unicast datagram to 127.0.0.1 reaches only ONE of the sockets bound to
the discovery port, so a second Alpaca server on the same machine - ASCOM
7 starts one automatically - is silently invisible. The loopback
broadcast address is delivered to every socket bound with SO_REUSEADDR,
so all local servers answer.}
if not f_loopback then begin
Result.Add('127.255.255.255');
Result.Add('127.0.0.1');
end;

Keeping 127.0.0.1 as well costs one extra datagram and covers any server that binds the loopback address explicitly rather than 0.0.0.0; the duplicate check drops the second reply from a server that answers both.

0002940: Minor tweak in cu_tiff.pas

Wed, 29 Jul 2026 14:55:29 +0200

Minor tweak in cu_tiff.pas, remove the thefile.free in lines 370, 522, 661, 808

try
thefile := tfilestream.Create(filen2, fmcreate);
except
thefile.free; // <-- thefile is garbage here
exit;
end;

or use attached version

0002939: Le driver de Bresser ne veut pas s'installer

Sat, 25 Jul 2026 09:48:39 +0200

C'est un problème avec ASCOM j'aimerai savoir si d'autre ont eu le même problème ?

0002927: Camera cooling not fully stopped

Mon, 20 Jul 2026 22:04:47 +0200

Hello,

when selecting camera warmup as termination command of a planned sequence, CCDCiel just sets the target temperature to 20°C. This is in summer not ideal, since the ambient temperature can go higher. This leads to continued cooling at the end of the session (or during daytime, if CCDCiel not terminated until then).

I see the following as possible solutions:
- Set target temperature to really high values (e.g. 60°C)
- Disable cooling instead of increasing target temperature

Thank you

0002935: Fails to import CSV file for sequence

Mon, 20 Jul 2026 22:04:09 +0200

Using Sequence-> new and Import csv to pick the file, entire line appears in one column, even the commas.

0002938: New multi-theaded tiff unit

Mon, 20 Jul 2026 22:02:58 +0200

Attached an update for the unit cu_tiff.pas. It is now multi-threaded and twice as fast.

With reference to the other issue I raised, I have also an multi-threaded rice compression unit for fits.fz files. Works well and compression/decompression time is much smaller then the I/O processing time. Seems to me the way to go if you use compatible software like Sirl or ASTAP for stacking.

cs, Han

0002936: Rice compression in native Pascal code.

Mon, 20 Jul 2026 22:02:36 +0200

Hi Patrick,

I have just finished for my ASTAP program the reading and writing rice compressed files using native Pascal code. This makes the utility program fpack and funpack redundant. The implementation is as follows:

Read 16 bit and floating point fits files. Format rice only. Not gzip;
Write 16 bit fits files.

I skipped writing floating point fits files since rice is an compression for integer files and compression of floating point is always lossy. It is also not relevant for CCDCiel.

Compression for my 16 bit images is identical to fpack to about 40%. Compression is lossless so nothing is lost.

The question would you be interested in adding native rice compression/decompression to CCdCiel? If so I can start working on it.

cs, Han

0002937: Unable to install virtualmoon_9.1_amd64.deb on Ubuntu 26,04

Mon, 20 Jul 2026 21:50:20 +0200

I downloaded the last version but install stop for Package libgtk2.0-0 is not installed.

corrado@corrado-ns2-resolute:~$ inxi -SCGc
System:
Host: corrado-ns2-resolute Kernel: 7.0.0-27-generic arch: x86_64 bits: 64
Desktop: GNOME v: 50.1 Distro: Ubuntu 26.04 LTS (Resolute Raccoon)
CPU:
Info: quad core model: 12th Gen Intel Core i3-12100 bits: 64 type: MT MCP
cache: L2: 5 MiB
Speed (MHz): avg: 799 min/max: 800/5500 cores: 1: 799 2: 799 3: 799 4: 799
5: 799 6: 799 7: 799 8: 799
Graphics:
Device-1: Intel Alder Lake-S GT1 [UHD Graphics 730] driver: i915 v: kernel
Device-2: Logitech QuickCam Pro 9000 driver: snd-usb-audio,uvcvideo
type: USB
Display: wayland server: X.Org v: 24.1.10 with: Xwayland v: 24.1.10
compositor: gnome-shell driver: dri: iris gpu: i915
resolution: 1920x1080~60Hz
API: EGL v: 1.5 drivers: iris,swrast
platforms: gbm,wayland,x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 26.0.3-1ubuntu1
renderer: Mesa Intel UHD Graphics 730 (ADL-S GT1)
Info: Tools: api: eglinfo,glxinfo x11: xdriinfo, xdpyinfo, xprop, xrandr
corrado@corrado-ns2-resolute:~$

0002933: Ce n'est pas la bonne étoile qui est amenée sur la fente

Fri, 26 Jun 2026 17:52:32 +0200

Bonjour Patrick,

J'ai réussi à faire des scripts pour automatiser les acquisitions en spectro avec CCD Ciel. Parmi ceux-ci, celui qui permet d'amener la cible à l'endroit voulu sur la fente. Les positions sur la caméra chercheur et sur la caméra de guidage ont été synchronisées au préalable en cliquant puis en ajustant avec les valeurs.
Ca fonctionne le plus souvent, par exemple sur T Crb puis Ups CrB (étoile de référence) mais pour la séquence qui a suivi sur V1331 Cyg, ça n'a pas accroché la bonne étoile.. J'avais pris deux étoiles de référence pour comparer mon traitement, une des deux a été ratée également (Rho Cyg).

Je joins le log qui le montre, mon script dérivé de celui existant dans CCD Ciel (qui ne fonctionnait pas pour moi) et ma séquence. Les parties qui concerne l'arrêt du guuidage, calib et flats fonctionnent.

Mon setup est un newton 150/750, un Alpy 600 et une Player One IMX585, une ASI290M en guidage, une ASI678MC sur lunette 50/205 en chercheur le tout sur ZWO AM5.

Je ne sais pas comment améliorer la détection de la bonne étoile..
Merci d'avance pour votre aide !

0002931: The crosshair is randomly shift of the center in the preview image

Fri, 26 Jun 2026 17:52:09 +0200

CCDCiel version 0.9.94-4104-e6ad9b65

Sometimes the crosshair is wrongly displayed off center and have to be deactivated and reactivated again to be redrawn in the center of the preview image.

0002930: Auto guiding step 2 calibration error

Fri, 26 Jun 2026 17:51:46 +0200

CCDCiel Version: 0.9.94-4104-e6ad9b65

After doing the first step of the CCDCiel autoguider calibration when doing the second step I got several times the following error and then the auto guider was stuck until a CCDCiel relaunch :

telescope/0: Pulse guide error: duration -1293 must be between 1 and 10000 ms.

Telescope/0 is a Benro Polaris mount with Alapca v2.2beta driver (https://github.com/ogecko/alpaca-benro-polaris)

0002929: Type de fichier

Fri, 26 Jun 2026 17:50:50 +0200

Bonjour Patrick,
Serait-il possible d'ajouter un type de capture pour la spectro : Calibration (en plus de Light, Bias, Dark et Flat).
J'ai réussi à automatiser les captures (Alpy 600 + module de calibration/flats + bidouille arduino) mais pour mes fichiers de calibration, le nom donné est celui de la séquence puisqu'il n'y a pas ce type dans la liste, contrairement à Flat dans mon cas mis exemple.
Merci d'avance pour cette évolution.. ou solution de contournement.

Jean-Marc Moreau

0002928: Predefined histrogram settings for full 16 bit cameras

Fri, 26 Jun 2026 17:50:13 +0200

This is a follow-up of the discussion https://groups.io/g/ccdciel/topic/118169275#msg4158

For true 16 bit cameras with unity gain setting the output increase one ADU for each electron. Then in practise most histogram data is typically contained in a few hundred ADU. These cameras require in CCDCiel an presetting "Extreme" to get a good contrast.

This is different then for 12 bit cameras whitch unity gain setting where the output increases with 16 ADU for each electron. For those 12 bit cameras the histogram data is 16 times wider. The more moderate stretching settings are required.

So 12 bit camera there is an inherent gain of 16 build in the data.

Is there a way to adapt the stretching for this true 16 bit cameras to cope with this factor 16?

0002925: Gain and offset settings in sequence and camera tab

Fri, 26 Jun 2026 17:49:51 +0200

With the setup of Gerard I noted the following:

Setup with Windows, ASI1600 camera

1) Yesterday using the camera tab both the gain and offset values where not in the FITS header.

2) Today

1) Gain and offset are recorded in the header if a sequence is run.
2) Gain and offset are NOT recorded if images are made using the camera tab.

After a reset of CCDCiel both gain and offst where recorded. So the problem was fixed by a program reset

3) When I switched between profiles, it is possible that the offset setting is not visible. After a reset it is visible again. See attached screenshots.

4) The offset in CCDciel does not change the background of the ASI1600 image. But the camera driver offset setting does. So it looks like the offset in not transmitted to the ASI1600 driver.

Screenshots of the ASI1600 connected are attached. Note that the offset is missing in the second screenshot.