Hi all,

I am looking to buy a fast and cheap CCD camera (preferably monochrome) that works well with INDI (and Linux in general) for occultation timings.
For now I have found this which looks like it might work: astronomy-imaging-camera.com/products/usb-2-0/asi120mm/
1280X960@35FPS ... 800X512@102FPS ... 320X240@215FPS

The important thing is I have to record from Linux at high frame rate>100FPS.
Do you have any recommendations?

Many thanks,

Why don't you get a USB 3.0 camera? At any rate, I don't think you can record with INDI at 100 FPS using the SER recorder. You can try though!

For stellar occultations you don't need to go at 100 fps! At that pace, you'll never see a single star (except 1st magnitude maybe) with anything less than 1 m aperture.
Rather, you should target 10-20 fps as a more typical range. So, this is not so demanding.
On the other hand, the critical issue is the absolute UTC timing of the frames, as one should target 10-50 ms accuracy. This is an important factor in the choice of the camera. Here, a couple solutions are possible.

1 - The first one does not require additional hardware, can be applied to any camera, but is less reliable: one has to calibrate the delay between the start of an image sequence - as recorded by the PC clock - with respect to a precise external reference. It has to be done in all possible configurations (= frame rates) that can be used. The PC clock has to be synchronized very frequently via NTP. However, not all applications read the PC clock at the exact start of the sequence (I don't know how INDI proceeds) and variable delays can be present, depending on the software (however, Linux is much better than windows in this respect).

2 - The most reliable, software-independent approach, consists in using a camera with an auxiliary connector allowing to access an electric impulse that is issued at the start of each frame. Such cameras are, for instance, Point Grey or Basler. The shutter signal can be fed to a GPS box where the timing with respect to the 1 pps GPS signal is reconstructed, and sent via USB to the PC, where it is recorded in a text file.

Unfortunately INDI does not offer - at present - Point Grey or Basler (GigE cameras) drivers. I would really be interested in that... In the meantime, you could try method 1 with an Imaging Source (choose the most sensitive CCD) or - better - with a PointGrey Chamaleon3 (USB3, with shutter signal) which should be supported by Video4Linux (so by INDI - but I don't have the camera, so I can't test).

This gives some interesting food for thought, but, there is yet another way to deal with accurate timing. Use a camera that is not buffered, and does not end up feeding a stream, but instead requires a 'start frame' signal from the pc. If it's an interline unit there are ways and means this can all be accomplished within the driver.

I'll use an example of hardware I have here. The all-sky is just an sx superstar under the covers. With minor changes to the driver, it would be easy to introduce a mode where end of one frame, becomes start of next frame. Sequence goes like this at the very low level. At the start of sequence, flush all accumulators and trigger start of exposure. At the end of exposure time, latch the data and download it. When the next frame time is complete, latch again. This works with an interline sensor, and creates back to back frames with zero time loss between frames. To address sensetivity bin the camera, and to address frame rates, after on target, only take the small piece of the sensor where the target star exists.

When running in this mode with an interline sensor, you do not get any time loss due to data download, and it's possible to get very accurate frame times from the host clock because each and every frame is fetched from the sensor with no buffers creating internal lags and the host is generating the data latch timing. We know the exact start and end times for each exposure cycle, because the host triggered it directly by latching the data in the sensor. Frame start and end times should be accurate to on the order of 1ms, and we also know, because it's an interline sensor, the end time for frame one, is the start time for frame 2, etc. The only potential bottlenecks in this scenario are the ability of the host program to consume the data as fast as the driver delivers it.

It would only take a small bit of code change in the driver to create the 'back to back' mode so that once the sequence is triggered, the driver delivers the frames continually, and the end of frame one becomes the start of frame 2, without any external triggers required. It's essentially adding a streaming mode to the core ccd driver code.

I currently manipulate the all-sky over a wifi link, so there is considerable lag between the client program on the computer in the house, and the one out at the all-sky. This isn't a big deal in our case, because I'm using 10 second exposures. I dont remember the exact numbers, but when I was working on stuff directly connected to the development computer, I believe frame download time for a full unbinned frame was on the order of just over a half second. That would cut by a factor of 4 if it was binned, and another factor of 4 if one was only grabbing 1/4 of the sensor. It should be able to keep up handily grabbing 1/4 of the sensor binned, with very accurate timing at 10hz frame rates. Timing accuracy will be limited only by your ability to keep the host clock synchronized.

It's difficult for me to experiment with some of this right now, because I dont have a hardwire link to the all sky yet, but it should be in place any day now, electrician was scheduled to put the fiber in last week, but got pre-empted on another job. Once the gigabit connection is in place, it'll be pretty strait forward to experiment with this a bit, and see how well it can be made to work. If it works well in that scenario, then to do an actual occultation timing is just a case of putting a similar camera onto a different optical setup. 1.8mm focal length is not really conducive to this project

Interesting. This might be a possibility, but I'm always skeptic about software solutions, requiring the OS to query the system clock, etc. The problem, is not that the delay has to be small, but rather constant, and known. However, if the measurements show that your approach works fine, it can open an approach for a whole set of cameras...

Thank you knro, paolot and gerryr for your replies.

First concerning the timing problem my plan was actually to use an external light source:
a small laser with impulses triggered by PPS signals of a GPS is placed in the camera-telescope adaptor such that it lights a small region of a few pixels on the camera. But if I can find a cheap Linux-friendly camera with a dedicated timing signal input, I might consider that too.

Concerning the USB3 cameras, if I can get 100 FPS on some USB2 camera (such as ASI 120), I don't need a much more expensive USB3 camera.
I don't really need INDI for recording at high rate. What I need is probably a camera with V4L2 support at 100 FPS when the camera is used for timing and optionally INDI support when the camera is used for alignment, guiding.

Concerning the high frame rate, I am not just interested in asteroids and faint stars, but also in moon occultations of planets/bright stars, sun transits (Mercury transit is next year), jupiter moon transits/occultations and so on. I have not checked it but I guess I can go much higher than the usual 24fps for some of them. I would go at least for a 60 FPS camera ( example: www.astronomycameras.com/products/usb/dmk21au04as/ ).

Clear skies.