[S D Kidd]

Hi All,
There is a thread on this forum  about the suitability of rolling shutter cameras for occultations, and the possible timing corrections needed. A while ago I was in touch with the engineers at ZWO, concerning this question for the ASI224 camera I was using at the time. The forum may be interested in the information that Chad Cao kindly provided. This from his reply....I asked specifically if the delay for each line was affected by the exposure time:     (I have corrected some words for clarity)

 Hi Simon,
I Got your meaning.
Exposure time does not affect the time correction you need.
If you use USB3.0 and run at 100% , the row time should be 15.73 μS. Then you can simply estimate any time.
In full size, it has 976 line, 15.73*976=15 mS.
When you use ROI, the row time will not change. But the line will affect the full time. Like 640*480, 480*15.73=7.5 mS.
This is just an estimate, the true time usually need more 250 (extra?) μS, because the Sensor always has some invalid rows and calibration rows and so on.
Best Regards
Chad


 Hi Simon,
We had a meeting yestoday, About you needs, we think we can offer more information.
For the last email, the data is 16bit. If the 8bit data is enough for your needs, the speed could fast.
In 8 bit mode, the row time is 6.71μS, it has the same calculation like the 16bit. Like full size, it is about 6.7mS.
Best Regards
Chad


So from the above,  and for the ASI224 1304x976 chip,  say you have a 50msec exposure (8 bit) each line would start exposing 6.71 usec after the previous line and it would take 6.7msec to read out the whole chip then wait 43.3msec then start at the top again (in 8 bit mode). Using an ROI of half the height would halve that delay (ie 3.35ms difference between the top and bottom lines). Not so sure what would happen where the exposure time is less than this delay figure (unusual !?). I assume that other cameras using similar technology will have similar delays, maybe there are members with more expertise in this area.
Chad also suggested a practical way to actually measure the total delay, top to bottom:


Hi Simon,

There is a easy way to calculate, Use Sharpcap, Set the exposure time to a minimum, and sets the USB bandwidth to the maximum. Then you can find the current fps at the bottom of the image:
(say for 201.2 fps as shown in Sharpcap)
Then you can calculate the current frame time: (1*1000*1000)/201.2=4975μS

For your other needs, sorry, we have not the right global camera now, And add the GPS, we now also have no plan for this.
Of course, if you want to customize this kind of camera in the future, we can discuss again.
Best Regards
Chad

I just tried this again on my old ASI224 (which I dont use for occultations any more)  for 640x480 ROI, with 2X binning ( effectively 320x240....to match better with my C14)....the total delay turns out to be 4ms, in 8 bit mode. This agrees very well with the theoretical value, as above.

It looks like the delays are quite small, especially if you use an ROI with a low 'height'.
Interesting note on 'GPS' at the end of Chad's message....they seem to have thought of it, I wonder if they might reconsider!
Sorry this post is so long, I thought it better to put all my info on this in one place.

All the best
Simon Kidd









Got your means.
Exposure time does not affect the time you need.
If you use USB3.0 and run at 100% , the row time should be 15.73 μS. Then you can simply estimate any time.
In full size, it has 976 line, 15.73*976=15 mS.
When you use ROI, the row time will not change. But the line will affect the full time. Like 640*480, 480*15.73=7.5 mS.
This is just an estimate, the true time usually need more 250 μS, because the Sensor always has some invalid rows and calibration rows and so on.
Best Regards
Chad



Hi Simon,
Got your means.
Exposure time does not affect the time you need.
If you use USB3.0 and run at 100% , the row time should be 15.73 μS. Then you can simply estimate any time.

[C.Weber]

Hi Simon,

Very interesting, thanks for sharing this and also for your questions to ZWO, especially regarding GPS.

Maybe I understand something wrong. But I think you need to calculate where a star is vertically on the chip (ROI). If you have a line readout time of say 16 µs, then when the star is on the hundredth line, you would have a delay of 1.6 ms?

But you are right, depending on the settings, the effects are often negligible.

Christian

[S D Kidd]

Hi Simon,

Very interesting, thanks for sharing this and also for your questions to ZWO, especially regarding GPS.

Maybe I understand something wrong. But I think you need to calculate where a star is vertically on the chip (ROI). If you have a line readout time of say 16 µs, then when the star is on the hundredth line, you would have a delay of 1.6 ms?

But you are right, depending on the settings, the effects are often negligible.

Christian

Thanks Christian,
Yes, you are right.....I forgot to say, these would be maximum errors; the delay for a particular line would be calculated individually as you show. Then of course whether it was start- or end-stamped would be important.

All the best
Simon

[C.Weber]

Thanks, Simon.
Christian

[Midavaine]

Hi Simon and Christian,

We discussed on this topic in our French team reviewer las week.
Yes I confirm here the assumption related to Rolling Shutter mode for CMOS cameras. To help observers in resolving the latency they are meeting, if they don't perform a real test on a led driven by an accurate PPS output we should ask them this two questions :
FPS max : What is the maximum frame per second rate the camera is able to deliver for a full frame output with a very short exposure time. This data is given by ZWO or any camera manufacturer. Keep in mind that Sharpcap with the free version is limiting this maximum rate.
Y N° lines : And what is the size of the matrix in vertical or how many lines the chip is delivering. This number could be a little more larger than the vertical size of the picture due to additional blanking lines and occulted lines.
In inverting the product of the two figures :
1/(FPS x Y N°lines)
you get the delay of the exposure start per line.
Therefore when you process an occultation, if the time stamping is driving the start of the exposure of the first line you get your recording latency in getting the Y line number where the occulted star image is falling on. With the poduct of this number with the delay of the exposure start per line you get the latency to add on your report. This work also in ROI mode.
Astroregards
Thierry