https://forum.iota-es.de/ Sun, 17 May 2026 05:56:36 +0000 MyBB https://forum.iota-es.de/showthread.php?tid=494 Thu, 26 Jun 2025 15:02:44 +0000 saci]]> https://forum.iota-es.de/showthread.php?tid=494 I'm linking this GPS module. It works perfectly. I use it with the Meinberg NTP monitor; it supports PPS.
Just set the offset with SharpCap (0.090 ms).
You also need a USB/RS232 serial cable.
See you soon.
Karim Saci

  ntp monitor.jpg (Size: 207.39 KB / Downloads: 5)
https://www.topgnss.store/en-fr/collecti...1-5-meters]]> I'm linking this GPS module. It works perfectly. I use it with the Meinberg NTP monitor; it supports PPS.
Just set the offset with SharpCap (0.090 ms).
You also need a USB/RS232 serial cable.
See you soon.
Karim Saci

  ntp monitor.jpg (Size: 207.39 KB / Downloads: 5)
https://www.topgnss.store/en-fr/collecti...1-5-meters]]> https://forum.iota-es.de/showthread.php?tid=301 Tue, 28 Mar 2023 19:54:31 +0000 C.Weber]]> https://forum.iota-es.de/showthread.php?tid=301
The right format is the astronomy standard FITS. Sometimes I heard it would be slow in comparison with SER - from a lot of tests I cannot confirm this. For archiving, the single FITS can be easily compressed into one file using 7zip (better compressing) or zip.

Also ADV I can recommend, QHY174, SC, Tangra, AOTA, PyMovie and PyOTE can work with ADV,

Some background: https://forums.sharpcap.co.uk/viewtopic.php?f=8&t=2237, https://www.iota-es.de/JOA/JOA2020_3.pdf.

An example for SER issues you will find in JOA 2023-2 p. 5, https://iota-es.de/JOA/joa2023_2.pdf.


Christian Weber]]>
The right format is the astronomy standard FITS. Sometimes I heard it would be slow in comparison with SER - from a lot of tests I cannot confirm this. For archiving, the single FITS can be easily compressed into one file using 7zip (better compressing) or zip.

Also ADV I can recommend, QHY174, SC, Tangra, AOTA, PyMovie and PyOTE can work with ADV,

Some background: https://forums.sharpcap.co.uk/viewtopic.php?f=8&t=2237, https://www.iota-es.de/JOA/JOA2020_3.pdf.

An example for SER issues you will find in JOA 2023-2 p. 5, https://iota-es.de/JOA/joa2023_2.pdf.


Christian Weber]]> https://forum.iota-es.de/showthread.php?tid=294 Thu, 23 Mar 2023 15:25:05 +0000 C.Weber]]> https://forum.iota-es.de/showthread.php?tid=294 https://iopscience.iop.org/article/10.10...873/acacc8

Largely identical in content but not in the final layout:
https://arxiv.org/abs/2301.06378v1

Christian Weber]]> https://iopscience.iop.org/article/10.10...873/acacc8

Largely identical in content but not in the final layout:
https://arxiv.org/abs/2301.06378v1

Christian Weber]]> https://forum.iota-es.de/showthread.php?tid=170 Thu, 12 Jan 2023 12:36:18 +0000 S D Kidd]]> https://forum.iota-es.de/showthread.php?tid=170 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.]]> https://forum.iota-es.de/showthread.php?tid=72 Mon, 28 Nov 2022 21:52:00 +0000 C.Weber]]> https://forum.iota-es.de/showthread.php?tid=72
Christian Weber

Hi all,

the version 5.4.0 of the control software is available for download from the support web page:
https://dvticam.com/support

The main new feature of this version is the integration with SODIS. You can now create a pre-filled SODIS report from the occultation event dialog. Download the report_template_sodis.txt from the support page, rename it to report_template.txt and place it in the program directory of the camera control tool (normally c:\program files (x86)\DvtiCamControl). You can also generate the traditional report form - in this case, download the file report_template_euraster.txt from the support page, rename it to report_template.txt and place it in the program directory.

Some other changes and fixes in this version (for a complete list, please see the releasenotes.txt file):
- The tool now ignores the configured dark offset if dark subtraction is disabled.
- The preview mode "no preview" has been removed. This caused some people to think that the camera is not working.
- Sometimes the streaming could stop after a few hours. This has been fixed.
- The program had a memory leak when recording FITS series that led to a crash after a short time. This has been fixed.

Greetings and clear skies!
Andreas]]>
Christian Weber

Hi all,

the version 5.4.0 of the control software is available for download from the support web page:
https://dvticam.com/support

The main new feature of this version is the integration with SODIS. You can now create a pre-filled SODIS report from the occultation event dialog. Download the report_template_sodis.txt from the support page, rename it to report_template.txt and place it in the program directory of the camera control tool (normally c:\program files (x86)\DvtiCamControl). You can also generate the traditional report form - in this case, download the file report_template_euraster.txt from the support page, rename it to report_template.txt and place it in the program directory.

Some other changes and fixes in this version (for a complete list, please see the releasenotes.txt file):
- The tool now ignores the configured dark offset if dark subtraction is disabled.
- The preview mode "no preview" has been removed. This caused some people to think that the camera is not working.
- Sometimes the streaming could stop after a few hours. This has been fixed.
- The program had a memory leak when recording FITS series that led to a crash after a short time. This has been fixed.

Greetings and clear skies!
Andreas]]>