and what's the FPS when you stream?

The best I could get running the stream with Ekos was 3.9 FPS, actually, even after changing the exposure.
Is it a limitation due to the camera, or is there a property other than the exposure that can be changed to get a better speed ?

After checking on a stream I'd already captured, I found out that I could actually have a stream of up to 50 FPS.
I don't need that many FPS, a rate of 20 or 30 FPS would be perfectly fine if it made it possible for me to save the stream as fits files.

What exact problem are we trying to solve? Because SER already capture and save exact timing for each frame.

I did not know SER had the timing for all frames, thank you.
My problem here is that I need the exact timing (to the millisecond) for all frames, and I need the timing to be that of the camera's GPS, and not of the computer on which I launch the INDI client.
Is that the case for the timing given by the SER format? If so, problem solved!

Yes SER does contain timestamps for each frame. Looking at code QHY driver does decode GPS info from camera but this doesn't seems to be passed down when recording SER stream. Only current PC time is used. Maybe "StreamManager" class could be modified that it scoop up this GPS timestamp.

Are you doing asteroid occulatations timing? I was experimenting with that and when I recorded GPS LED blink with my camera I found out that timestamp in SER file was within 5ms of blink start. I used chrony NTP client to keep my clock in sync. Also doesn't that QHY camera burn timestamp into image? So maybe just read timestamp from image?

The more interesting question would be whether saving stuff as FITS would use that GPS time of the camera. My strong suspicion there is 'NO'.

I am in fact doing asteroid occultations, yes! Thanks for sharing what you did, I will see if it applies.
I saw from the QHYCCD SDK documentation that "the camera records the GPS information and insert into each frame's head." So it would seem that the images the camera sends to INDI contains the exact GPS timing, but INDI then overwrites it (or simply ignores it) in favor of the PC timestamp. If I understand correctly, when INDI saves the images, the GPS timing isn't saved with it because the header is changed to INDI's. So I don't think I could read the original timestamp on the image ://

I am not all that familiar with C++, unfortunately so I can't be trusted with modifying the StreamManager class.. If anyone were to look into it I'd be super grateful.

As for the FITS format having the same problem, I have no idea.
Since the problem could come from the fact that the StreamManager class does not include a part where the GPS timestamp is retrieved, it seems to be linked only to the stream. I could imagine it possible that that functionality was already included in the "one-time" pictures equivalent of StreamManager.

This line github.com/indilib/indi/blob/431869ffe40...serrecorder.cpp#L256 gets current computer time and write frame data to SER file.

On this line it is called new frame is pushed to Streamer github.com/indilib/indi-3rdparty/blob/da...hy/qhy_ccd.cpp#L2596
I think it would be quite straightforward put decodeGPSHeader() before call to Streamer->newFrame(buffer, w * h * bpp / 8 * channels, GPSHeader.start_sec + GPSHeader.start_us / 1000000.0);

Ok it was quite easy. I pushed changes that will now pass GPS start timestamp to SER recoder so if I didn't do any mistake it should work. So if you know how to compile INDI you can test it.

github.com/nouspiro/indi/tree/feature/qhy_gps_timestamp
github.com/nouspiro/indi-3rdparty/tree/f...re/qhy_gps_timestamp

I will try this asap, thank you so much for your help!