12-01-2023, 12:36
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.
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.