<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title><![CDATA[SODIS by IOTA-ES - All Forums]]></title>
		<link>https://forum.iota-es.de/</link>
		<description><![CDATA[SODIS by IOTA-ES - https://forum.iota-es.de]]></description>
		<pubDate>Sun, 05 Apr 2026 00:35:08 +0000</pubDate>
		<generator>MyBB</generator>
		<item>
			<title><![CDATA[SharpCap: How to remove some of the previous ROI settings]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=501</link>
			<pubDate>Thu, 17 Jul 2025 08:05:22 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=4">C.Weber</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=501</guid>
			<description><![CDATA[<a href="https://forums.sharpcap.co.uk/viewtopic.php?t=8829" target="_blank" rel="noopener" class="mycode_url">https://forums.sharpcap.co.uk/viewtopic.php?t=8829</a>]]></description>
			<content:encoded><![CDATA[<a href="https://forums.sharpcap.co.uk/viewtopic.php?t=8829" target="_blank" rel="noopener" class="mycode_url">https://forums.sharpcap.co.uk/viewtopic.php?t=8829</a>]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Time GPS]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=494</link>
			<pubDate>Thu, 26 Jun 2025 15:02:44 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=64">saci</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=494</guid>
			<description><![CDATA[Hello,<br />
I'm linking this GPS module. It works perfectly. I use it with the Meinberg NTP monitor; it supports PPS.<br />
Just set the offset with SharpCap (0.090 ms).<br />
You also need a USB/RS232 serial cable.<br />
See you soon.<br />
Karim Saci<br />
<!-- start: postbit_attachments_attachment -->
<br /><!-- start: attachment_icon -->
<img src="https://forum.iota-es.de/images/attachtypes/image.png" title="JPG Image" border="0" alt=".jpg" />
<!-- end: attachment_icon -->&nbsp;&nbsp;<a href="attachment.php?aid=258" target="_blank" title="">ntp monitor.jpg</a> (Size: 207.39 KB / Downloads: 5)
<!-- end: postbit_attachments_attachment --><br />
<a href="https://www.topgnss.store/en-fr/collections/rs232gnss-module/products/nmea0183-gps-glonass-galileo-receiver-diy-connector-5v-rs232-9600-baud-rate-module-with-antenna-line-length-1-5-meters" target="_blank" rel="noopener" class="mycode_url">https://www.topgnss.store/en-fr/collecti...1-5-meters</a>]]></description>
			<content:encoded><![CDATA[Hello,<br />
I'm linking this GPS module. It works perfectly. I use it with the Meinberg NTP monitor; it supports PPS.<br />
Just set the offset with SharpCap (0.090 ms).<br />
You also need a USB/RS232 serial cable.<br />
See you soon.<br />
Karim Saci<br />
<!-- start: postbit_attachments_attachment -->
<br /><!-- start: attachment_icon -->
<img src="https://forum.iota-es.de/images/attachtypes/image.png" title="JPG Image" border="0" alt=".jpg" />
<!-- end: attachment_icon -->&nbsp;&nbsp;<a href="attachment.php?aid=258" target="_blank" title="">ntp monitor.jpg</a> (Size: 207.39 KB / Downloads: 5)
<!-- end: postbit_attachments_attachment --><br />
<a href="https://www.topgnss.store/en-fr/collections/rs232gnss-module/products/nmea0183-gps-glonass-galileo-receiver-diy-connector-5v-rs232-9600-baud-rate-module-with-antenna-line-length-1-5-meters" target="_blank" rel="noopener" class="mycode_url">https://www.topgnss.store/en-fr/collecti...1-5-meters</a>]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[PyOTE update to v 5.5.8 required]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=436</link>
			<pubDate>Wed, 23 Oct 2024 10:19:17 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=4">C.Weber</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=436</guid>
			<description><![CDATA[Hi all,<br />
<br />
There was a problem in PyOTE that led to different solutions depending on the method (‘Mark D/R region’ or ‘Min/Max’). This has been fixed with the current version 5.5.8. So, please update.<br />
<br />
Christian Weber]]></description>
			<content:encoded><![CDATA[Hi all,<br />
<br />
There was a problem in PyOTE that led to different solutions depending on the method (‘Mark D/R region’ or ‘Min/Max’). This has been fixed with the current version 5.5.8. So, please update.<br />
<br />
Christian Weber]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Show UCAC4 stars in the Deep Sky Annotation]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=410</link>
			<pubDate>Tue, 16 Apr 2024 19:02:51 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=74">Jean-Francois</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=410</guid>
			<description><![CDATA[Hello,<br />
<br />
I have a new script for SharpCap.<br />
<br />
It shows the UCAC4 stars visible in the field of the detector.<br />
<br />
For that, you need first to have the original UCAC4 stars catalogue.<br />
That is the 900 files from z001 to z900 with uncompressed size of 8.26 GB .<br />
<br />
Please read and download the files from the message:<br />
<a href="https://forums.sharpcap.co.uk/viewtopic.php?p=42146#p42146" target="_blank" rel="noopener" class="mycode_url">https://forums.sharpcap.co.uk/viewtopic....146#p42146</a><br />
<br />
The PDF document explains shortly the installation and settings of the script.<br />
<br />
Best regards,<br />
Jean-Francois]]></description>
			<content:encoded><![CDATA[Hello,<br />
<br />
I have a new script for SharpCap.<br />
<br />
It shows the UCAC4 stars visible in the field of the detector.<br />
<br />
For that, you need first to have the original UCAC4 stars catalogue.<br />
That is the 900 files from z001 to z900 with uncompressed size of 8.26 GB .<br />
<br />
Please read and download the files from the message:<br />
<a href="https://forums.sharpcap.co.uk/viewtopic.php?p=42146#p42146" target="_blank" rel="noopener" class="mycode_url">https://forums.sharpcap.co.uk/viewtopic....146#p42146</a><br />
<br />
The PDF document explains shortly the installation and settings of the script.<br />
<br />
Best regards,<br />
Jean-Francois]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[SharpCap avi issues]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=377</link>
			<pubDate>Thu, 18 Jan 2024 10:39:11 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=4">C.Weber</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=377</guid>
			<description><![CDATA[SharpCap avi recordings have a frame rate of 30 fps, leading to issues with Tangra and AOTA if camera is a PAL version (as mostly in Europe). <br />
This can be fixed by converting the frame rate using VirtualDub: "Video frame rate control" under "Video" &gt; "Frame Rate" (tested with vDub 1.10.4).<br />
<br />
Tests  showed further that there is no alternative approach in SC. Recording in SER is possible, however SC/SER cannot handle the integration feature of some video cameras (e.g several WATECs). It may run with no integration but with integration, it will not be possible to tell Tangra and/or Occult the integration setting of the camera.<br />
<br />
Also, ADV is no solution, SC does it not provide for this type of setup (ADV is for digital cameras only).<br />
<br />
The solution is to use a simple analog video capture/recording software as VideoView, Such software is also often shipped together with the frame grabbers.<br />
<br />
<br />
Christian Weber]]></description>
			<content:encoded><![CDATA[SharpCap avi recordings have a frame rate of 30 fps, leading to issues with Tangra and AOTA if camera is a PAL version (as mostly in Europe). <br />
This can be fixed by converting the frame rate using VirtualDub: "Video frame rate control" under "Video" &gt; "Frame Rate" (tested with vDub 1.10.4).<br />
<br />
Tests  showed further that there is no alternative approach in SC. Recording in SER is possible, however SC/SER cannot handle the integration feature of some video cameras (e.g several WATECs). It may run with no integration but with integration, it will not be possible to tell Tangra and/or Occult the integration setting of the camera.<br />
<br />
Also, ADV is no solution, SC does it not provide for this type of setup (ADV is for digital cameras only).<br />
<br />
The solution is to use a simple analog video capture/recording software as VideoView, Such software is also often shipped together with the frame grabbers.<br />
<br />
<br />
Christian Weber]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[New features announcement]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=359</link>
			<pubDate>Fri, 08 Dec 2023 14:40:00 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=30">mkretlow</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=359</guid>
			<description><![CDATA[Hi to all,<br />
<br />
<a href="https://astro.kretlow.de/cora/observations/" target="_blank" rel="noopener" class="mycode_url">CORA</a> now displays the observer names of SODIS reported observations instead of their numerical IDs.<br />
<br />
Cheers,<br />
Mike]]></description>
			<content:encoded><![CDATA[Hi to all,<br />
<br />
<a href="https://astro.kretlow.de/cora/observations/" target="_blank" rel="noopener" class="mycode_url">CORA</a> now displays the observer names of SODIS reported observations instead of their numerical IDs.<br />
<br />
Cheers,<br />
Mike]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Tangra and Aota Tutorials]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=328</link>
			<pubDate>Sun, 06 Aug 2023 10:37:00 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=2">astfu</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=328</guid>
			<description><![CDATA[A workshop on TANGRA and AOTA was held on the 5th of November 2022<br />
<br />
 In the following video recordings you can follow the workshop...<br />
<br />
<a href="https://iota-es.de/guidelines.html" target="_blank" rel="noopener" class="mycode_url">https://iota-es.de/guidelines.html</a>]]></description>
			<content:encoded><![CDATA[A workshop on TANGRA and AOTA was held on the 5th of November 2022<br />
<br />
 In the following video recordings you can follow the workshop...<br />
<br />
<a href="https://iota-es.de/guidelines.html" target="_blank" rel="noopener" class="mycode_url">https://iota-es.de/guidelines.html</a>]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Occult 4.2023.4.25 - An important update]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=315</link>
			<pubDate>Tue, 25 Apr 2023 22:08:09 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=4">C.Weber</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=315</guid>
			<description><![CDATA[Hi,<br />
<br />
Please update your Occult installation according to D. Herald's explanation below:<br />
<br />
<br />
<blockquote class="mycode_quote"><cite>Quote:</cite>This update is extremely important for anyone making use of the Shape Model capabilities in Occult. It is particularly important for all regional coordinators &amp; processers of observation reports.<br />
 <br />
<br />
********<br />
4.2023.4.25<br />
********<br />
*  A major revision to the handling of Shape Models. Recently<br />
    the models in the ISAM data base were renumbered in a<br />
    way that distinguished between models present in the<br />
    DAMIT system, and those that are only in the ISAM<br />
    system. Advantage has been taken of this to remove the<br />
    presence of duplicate models in the shape model solutions,<br />
    by only using ISAM models that are unique to the ISAM<br />
    system. [Such models have a model number of greater<br />
    than 100].<br />
    <br />
    The consequences of this change have been:<br />
    i. a reduction of around 6000 in the number of shape<br />
    models retained in Occult<br />
    ii. 43 ISAM models with model numbers greater than 100<br />
    iii. A revision of the Asteroid~Observations file to<br />
    remove all ISAM shape model solutions where the ISAM<br />
    model is in DAMIT, and to renumber the remaining ISAM model<br />
    numbers to their new number in ISAM.<br />
    iv. Listing of Observed Diameters, and Shape Model<br />
    Fits [accessed from the Asteroid Observations tab]<br />
    no longer have fit results to an ISAM model where<br />
    that model is also present in DAMIT. That is, all<br />
    fit results relate to different models.<br />
    <br />
    =====================================================<br />
              ****** VERY IMPORTANT ******<br />
    =====================================================<br />
    This update involves a change to the Occult program<br />
    the Asteroid~Observations file, and the collection of<br />
    ShapeModel files. The inter-relationship between the<br />
    Asteroid~Observations file and the ShapeModel files<br />
    creates a complication in updating. To avoid any<br />
    possible problems, please follow the next steps closely.<br />
    <br />
    1. Start with Occult not running. If you have multiple<br />
    instances of Occult running, close them all.  <br />
<br />
    2. With Occult not running, locate the folder<br />
    (subdirectory) called ShapeModels in the Occult 4<br />
    directory. Rename that folder to something else - for<br />
    example 'ShapeModels_toDelete'. [The update will<br />
    create a new ShapeModels folder, which will only<br />
    have about 6000 files - compared to about 12000 in<br />
    the folder to be deleted]<br />
<br />
    ====================================================<br />
      *** IMPORTANT**** The next three downloads can be<br />
      done in any order. But you MUST NOT USE any OCCULT<br />
      functions until all three downloads have been<br />
      completed. In particular, do not open the Asteroid<br />
      Observations Editor until these three downloads<br />
      have been completed<br />
    ==================================================== <br />
<br />
    3. Now run Occult. From the main menu, do the usual<br />
    update to Occult<br />
<br />
    4. After that update has finished, go straight to<br />
    the Download page, and Download #24 Shape models.<br />
<br />
    5. Finally, download #3 Asteroid observations.<br />
<br />
    Once you have done these three downloads, Occult<br />
    will be fully functional. You can also delete the<br />
    folder you renamed in step 2.<br />
<br />
Dave Herald<br />
Murrumbateman<br />
Australia</blockquote>
<br />
<span style="font-weight: bold;" class="mycode_b">Update to Occult 4.2023.4.28</span><br />
<br />
<blockquote class="mycode_quote"><cite>Quote:</cite>A minor but important fix<br />
 <br />
The last version of Occult had a major change in the handling of ISAM shape models.<br />
<br />
Unfortunately there was an oversight. The code has long included a check for whether new ISAM models might be available. After the revision in 4.2023.4.25, that check returned a wrong result. Furthermore, if you clicked the option to update the ISAM models, you would have downloaded all the shape models that had been deleted as part of that revision.<br />
<br />
This version removes that check. So you will not see any invitation to download ISAM models.<br />
<br />
<br />
Dave Herald<br />
Murrumbateman<br />
Australia<br />
 </blockquote>
<br />
<br />
Christian]]></description>
			<content:encoded><![CDATA[Hi,<br />
<br />
Please update your Occult installation according to D. Herald's explanation below:<br />
<br />
<br />
<blockquote class="mycode_quote"><cite>Quote:</cite>This update is extremely important for anyone making use of the Shape Model capabilities in Occult. It is particularly important for all regional coordinators &amp; processers of observation reports.<br />
 <br />
<br />
********<br />
4.2023.4.25<br />
********<br />
*  A major revision to the handling of Shape Models. Recently<br />
    the models in the ISAM data base were renumbered in a<br />
    way that distinguished between models present in the<br />
    DAMIT system, and those that are only in the ISAM<br />
    system. Advantage has been taken of this to remove the<br />
    presence of duplicate models in the shape model solutions,<br />
    by only using ISAM models that are unique to the ISAM<br />
    system. [Such models have a model number of greater<br />
    than 100].<br />
    <br />
    The consequences of this change have been:<br />
    i. a reduction of around 6000 in the number of shape<br />
    models retained in Occult<br />
    ii. 43 ISAM models with model numbers greater than 100<br />
    iii. A revision of the Asteroid~Observations file to<br />
    remove all ISAM shape model solutions where the ISAM<br />
    model is in DAMIT, and to renumber the remaining ISAM model<br />
    numbers to their new number in ISAM.<br />
    iv. Listing of Observed Diameters, and Shape Model<br />
    Fits [accessed from the Asteroid Observations tab]<br />
    no longer have fit results to an ISAM model where<br />
    that model is also present in DAMIT. That is, all<br />
    fit results relate to different models.<br />
    <br />
    =====================================================<br />
              ****** VERY IMPORTANT ******<br />
    =====================================================<br />
    This update involves a change to the Occult program<br />
    the Asteroid~Observations file, and the collection of<br />
    ShapeModel files. The inter-relationship between the<br />
    Asteroid~Observations file and the ShapeModel files<br />
    creates a complication in updating. To avoid any<br />
    possible problems, please follow the next steps closely.<br />
    <br />
    1. Start with Occult not running. If you have multiple<br />
    instances of Occult running, close them all.  <br />
<br />
    2. With Occult not running, locate the folder<br />
    (subdirectory) called ShapeModels in the Occult 4<br />
    directory. Rename that folder to something else - for<br />
    example 'ShapeModels_toDelete'. [The update will<br />
    create a new ShapeModels folder, which will only<br />
    have about 6000 files - compared to about 12000 in<br />
    the folder to be deleted]<br />
<br />
    ====================================================<br />
      *** IMPORTANT**** The next three downloads can be<br />
      done in any order. But you MUST NOT USE any OCCULT<br />
      functions until all three downloads have been<br />
      completed. In particular, do not open the Asteroid<br />
      Observations Editor until these three downloads<br />
      have been completed<br />
    ==================================================== <br />
<br />
    3. Now run Occult. From the main menu, do the usual<br />
    update to Occult<br />
<br />
    4. After that update has finished, go straight to<br />
    the Download page, and Download #24 Shape models.<br />
<br />
    5. Finally, download #3 Asteroid observations.<br />
<br />
    Once you have done these three downloads, Occult<br />
    will be fully functional. You can also delete the<br />
    folder you renamed in step 2.<br />
<br />
Dave Herald<br />
Murrumbateman<br />
Australia</blockquote>
<br />
<span style="font-weight: bold;" class="mycode_b">Update to Occult 4.2023.4.28</span><br />
<br />
<blockquote class="mycode_quote"><cite>Quote:</cite>A minor but important fix<br />
 <br />
The last version of Occult had a major change in the handling of ISAM shape models.<br />
<br />
Unfortunately there was an oversight. The code has long included a check for whether new ISAM models might be available. After the revision in 4.2023.4.25, that check returned a wrong result. Furthermore, if you clicked the option to update the ISAM models, you would have downloaded all the shape models that had been deleted as part of that revision.<br />
<br />
This version removes that check. So you will not see any invitation to download ISAM models.<br />
<br />
<br />
Dave Herald<br />
Murrumbateman<br />
Australia<br />
 </blockquote>
<br />
<br />
Christian]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Why should SER not be used?]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=301</link>
			<pubDate>Tue, 28 Mar 2023 19:54:31 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=4">C.Weber</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=301</guid>
			<description><![CDATA[Shortly said, SER (developed for planetary imaging) is simply not made for occultation recording because there are too many chances for issues (and I have seen several problematic SER occ. recordings ...).<br />
<br />
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.<br />
<br />
Also ADV I can recommend, QHY174, SC, Tangra, AOTA, PyMovie and PyOTE can work with ADV,<br />
<br />
Some background: <a href="https://forums.sharpcap.co.uk/viewtopic.php?f=8&amp;t=2237" target="_blank" rel="noopener" class="mycode_url">https://forums.sharpcap.co.uk/viewtopic.php?f=8&amp;t=2237</a>, <a href="https://www.iota-es.de/JOA/JOA2020_3.pdf" target="_blank" rel="noopener" class="mycode_url">https://www.iota-es.de/JOA/JOA2020_3.pdf</a>.<br />
<br />
An example for SER issues you will find in JOA 2023-2 p. 5, <a href="https://iota-es.de/JOA/joa2023_2.pdf" target="_blank" rel="noopener" class="mycode_url">https://iota-es.de/JOA/joa2023_2.pdf</a>.<br />
<br />
<br />
Christian Weber]]></description>
			<content:encoded><![CDATA[Shortly said, SER (developed for planetary imaging) is simply not made for occultation recording because there are too many chances for issues (and I have seen several problematic SER occ. recordings ...).<br />
<br />
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.<br />
<br />
Also ADV I can recommend, QHY174, SC, Tangra, AOTA, PyMovie and PyOTE can work with ADV,<br />
<br />
Some background: <a href="https://forums.sharpcap.co.uk/viewtopic.php?f=8&amp;t=2237" target="_blank" rel="noopener" class="mycode_url">https://forums.sharpcap.co.uk/viewtopic.php?f=8&amp;t=2237</a>, <a href="https://www.iota-es.de/JOA/JOA2020_3.pdf" target="_blank" rel="noopener" class="mycode_url">https://www.iota-es.de/JOA/JOA2020_3.pdf</a>.<br />
<br />
An example for SER issues you will find in JOA 2023-2 p. 5, <a href="https://iota-es.de/JOA/joa2023_2.pdf" target="_blank" rel="noopener" class="mycode_url">https://iota-es.de/JOA/joa2023_2.pdf</a>.<br />
<br />
<br />
Christian Weber]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[An easy-to-build timing test device for occultation equipment]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=294</link>
			<pubDate>Thu, 23 Mar 2023 15:25:05 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=4">C.Weber</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=294</guid>
			<description><![CDATA[<a href="https://iopscience.iop.org/article/10.1088/1538-3873/acacc8" target="_blank" rel="noopener" class="mycode_url">https://iopscience.iop.org/article/10.10...873/acacc8</a><br />
<br />
Largely identical in content but not in the final layout:<br />
<a href="https://arxiv.org/abs/2301.06378v1" target="_blank" rel="noopener" class="mycode_url">https://arxiv.org/abs/2301.06378v1</a><br />
<br />
Christian Weber]]></description>
			<content:encoded><![CDATA[<a href="https://iopscience.iop.org/article/10.1088/1538-3873/acacc8" target="_blank" rel="noopener" class="mycode_url">https://iopscience.iop.org/article/10.10...873/acacc8</a><br />
<br />
Largely identical in content but not in the final layout:<br />
<a href="https://arxiv.org/abs/2301.06378v1" target="_blank" rel="noopener" class="mycode_url">https://arxiv.org/abs/2301.06378v1</a><br />
<br />
Christian Weber]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Use Sharpcap4.1   20 March 2023]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=287</link>
			<pubDate>Tue, 21 Mar 2023 18:27:55 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=2">astfu</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=287</guid>
			<description><![CDATA[Please use Sharpcap 4.1 from 20 March 2023.<br />
<br />
The previous version, as well as Sharpcap 4.0, contains a bug that prevents usable ADV files from being written!]]></description>
			<content:encoded><![CDATA[Please use Sharpcap 4.1 from 20 March 2023.<br />
<br />
The previous version, as well as Sharpcap 4.0, contains a bug that prevents usable ADV files from being written!]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[New SORA release]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=207</link>
			<pubDate>Fri, 03 Feb 2023 20:20:37 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=4">C.Weber</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=207</guid>
			<description><![CDATA[<a href="https://sora.readthedocs.io/en/latest/releases.html#sora-v0-3-2023-jan-31" target="_blank" rel="noopener" class="mycode_url">https://sora.readthedocs.io/en/latest/re...023-jan-31</a>]]></description>
			<content:encoded><![CDATA[<a href="https://sora.readthedocs.io/en/latest/releases.html#sora-v0-3-2023-jan-31" target="_blank" rel="noopener" class="mycode_url">https://sora.readthedocs.io/en/latest/re...023-jan-31</a>]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[OW feature "Open event in Occult"]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=183</link>
			<pubDate>Thu, 19 Jan 2023 11:09:30 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=4">C.Weber</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=183</guid>
			<description><![CDATA[With this you can generate an event's Occult image as it is required during SODIS reporting.<br />
<br />
The image is generated by Occult, but called by OccultWatcher with a right click on the event.<br />
<br />
OW add-in “Occult Tools for OccultWatcher” required: get the DLL from <a href="http://www.hristopavlov.net/OccultWatcher/OccultWatcher.OccultTools.zip" target="_blank" rel="noopener" class="mycode_url">http://www.hristopavlov.net/OccultWatche...tTools.zip</a>, copy it to the OW folder - start OW, update OW as requested.<br />
<br />
Christian Weber]]></description>
			<content:encoded><![CDATA[With this you can generate an event's Occult image as it is required during SODIS reporting.<br />
<br />
The image is generated by Occult, but called by OccultWatcher with a right click on the event.<br />
<br />
OW add-in “Occult Tools for OccultWatcher” required: get the DLL from <a href="http://www.hristopavlov.net/OccultWatcher/OccultWatcher.OccultTools.zip" target="_blank" rel="noopener" class="mycode_url">http://www.hristopavlov.net/OccultWatche...tTools.zip</a>, copy it to the OW folder - start OW, update OW as requested.<br />
<br />
Christian Weber]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[Kleopatra occults 11mag star on Jan 21st 2023]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=173</link>
			<pubDate>Fri, 13 Jan 2023 15:56:33 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=4">C.Weber</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=173</guid>
			<description><![CDATA[Wolfgang Beisker posted this on Planoccult:<br />
<blockquote class="mycode_quote"><cite>Quote:</cite>Dear all, <br />
 <br />
(216) Kleopatra will occult an 11m star UCAC4 468-000711 on January 21st 2023 around 19h53m UTC for western Europe. <br />
<br />
Please observe this event, because it is important to verify a new theory for the satellites orbits Axelhelios and Cleoselene. <br />
<br />
More infos you find at <br />
<br />
<a href="https://www.iota-es.de/kleopatra2023-1.html" target="_blank" rel="noopener" class="mycode_url">https://www.iota-es.de/kleopatra2023-1.html</a> <br />
<br />
With best regards <br />
<br />
Wolfgang </blockquote>
<br />
<br />
Christian Weber]]></description>
			<content:encoded><![CDATA[Wolfgang Beisker posted this on Planoccult:<br />
<blockquote class="mycode_quote"><cite>Quote:</cite>Dear all, <br />
 <br />
(216) Kleopatra will occult an 11m star UCAC4 468-000711 on January 21st 2023 around 19h53m UTC for western Europe. <br />
<br />
Please observe this event, because it is important to verify a new theory for the satellites orbits Axelhelios and Cleoselene. <br />
<br />
More infos you find at <br />
<br />
<a href="https://www.iota-es.de/kleopatra2023-1.html" target="_blank" rel="noopener" class="mycode_url">https://www.iota-es.de/kleopatra2023-1.html</a> <br />
<br />
With best regards <br />
<br />
Wolfgang </blockquote>
<br />
<br />
Christian Weber]]></content:encoded>
		</item>
		<item>
			<title><![CDATA[ZWO Rolling shutter cameras]]></title>
			<link>https://forum.iota-es.de/showthread.php?tid=170</link>
			<pubDate>Thu, 12 Jan 2023 12:36:18 +0000</pubDate>
			<dc:creator><![CDATA[<a href="https://forum.iota-es.de/member.php?action=profile&uid=35">S D Kidd</a>]]></dc:creator>
			<guid isPermaLink="false">https://forum.iota-es.de/showthread.php?tid=170</guid>
			<description><![CDATA[Hi All, <br />
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)<br />
<br />
<span style="font-style: italic;" class="mycode_i"> <span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Hi Simon,</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">I Got your meaning.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Exposure time does not affect the time correction you need.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">If you use USB3.0 and run at 100% , the row time should be 15.73 μS. Then you can simply estimate any time.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">In full size, it has 976 line, 15.73*976=15 mS.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">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.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">This is just an estimate, the true time usually need more 250 (</span></span><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">extra?</span><span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">) μS, because the Sensor always has some invalid rows and calibration rows and so on.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Best Regards</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Chad</span></span><br />
<br />
<br />
 <span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Hi Simon,</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">We had a meeting yestoday, About you needs, we think we can offer more information.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">For the last email, the data is 16bit. If the 8bit data is enough for your needs, the speed could fast.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">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.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Best Regards</span></span><br />
<span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font"><span style="font-style: italic;" class="mycode_i">Chad</span></span><br />
<br />
<br />
<span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">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.</span><br />
<span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Chad also suggested a practical way to actually measure the total delay, top to bottom:</span><br />
<br />
<br />
<span style="font-style: italic;" class="mycode_i">Hi Simon,<br />
</span><br />
<span style="font-style: italic;" class="mycode_i">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:</span><br />
(say for 201.2 fps as shown in Sharpcap)<br />
<span style="font-style: italic;" class="mycode_i">Then you can calculate the current frame time: (1*1000*1000)/201.2=4975μS</span><br />
<br />
<span style="font-style: italic;" class="mycode_i">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. </span><br />
<span style="font-style: italic;" class="mycode_i">Of course, if you want to customize this kind of camera in the future, we can discuss again.</span><br />
<span style="font-style: italic;" class="mycode_i">Best Regards</span><br />
<span style="font-style: italic;" class="mycode_i">Chad</span><br />
<br />
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.<br />
<br />
It looks like the delays are quite small, especially if you use an ROI with a low 'height'.<br />
Interesting note on 'GPS' at the end of Chad's message....they seem to have thought of it, I wonder if they might reconsider!<br />
Sorry this post is so long, I thought it better to put all my info on this in one place.<br />
<br />
All the best<br />
Simon Kidd<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Got your means.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Exposure time does not affect the time you need.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">If you use USB3.0 and run at 100% , the row time should be 15.73 μS. Then you can simply estimate any time.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">In full size, it has 976 line, 15.73*976=15 mS.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">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.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">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.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Best Regards</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Chad</span></span><br />
<br />
<br />
<br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Hi Simon,</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Got your means.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Exposure time does not affect the time you need.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">If you use USB3.0 and run at 100% , the row time should be 15.73 μS. Then you can simply estimate any time.</span></span>]]></description>
			<content:encoded><![CDATA[Hi All, <br />
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)<br />
<br />
<span style="font-style: italic;" class="mycode_i"> <span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Hi Simon,</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">I Got your meaning.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Exposure time does not affect the time correction you need.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">If you use USB3.0 and run at 100% , the row time should be 15.73 μS. Then you can simply estimate any time.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">In full size, it has 976 line, 15.73*976=15 mS.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">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.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">This is just an estimate, the true time usually need more 250 (</span></span><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">extra?</span><span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">) μS, because the Sensor always has some invalid rows and calibration rows and so on.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Best Regards</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Chad</span></span><br />
<br />
<br />
 <span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Hi Simon,</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">We had a meeting yestoday, About you needs, we think we can offer more information.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">For the last email, the data is 16bit. If the 8bit data is enough for your needs, the speed could fast.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">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.</span></span><br />
<span style="font-style: italic;" class="mycode_i"><span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Best Regards</span></span><br />
<span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font"><span style="font-style: italic;" class="mycode_i">Chad</span></span><br />
<br />
<br />
<span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">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.</span><br />
<span style="font-family: Microsoft YaHei', 'sans-serif;" class="mycode_font">Chad also suggested a practical way to actually measure the total delay, top to bottom:</span><br />
<br />
<br />
<span style="font-style: italic;" class="mycode_i">Hi Simon,<br />
</span><br />
<span style="font-style: italic;" class="mycode_i">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:</span><br />
(say for 201.2 fps as shown in Sharpcap)<br />
<span style="font-style: italic;" class="mycode_i">Then you can calculate the current frame time: (1*1000*1000)/201.2=4975μS</span><br />
<br />
<span style="font-style: italic;" class="mycode_i">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. </span><br />
<span style="font-style: italic;" class="mycode_i">Of course, if you want to customize this kind of camera in the future, we can discuss again.</span><br />
<span style="font-style: italic;" class="mycode_i">Best Regards</span><br />
<span style="font-style: italic;" class="mycode_i">Chad</span><br />
<br />
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.<br />
<br />
It looks like the delays are quite small, especially if you use an ROI with a low 'height'.<br />
Interesting note on 'GPS' at the end of Chad's message....they seem to have thought of it, I wonder if they might reconsider!<br />
Sorry this post is so long, I thought it better to put all my info on this in one place.<br />
<br />
All the best<br />
Simon Kidd<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Got your means.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Exposure time does not affect the time you need.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">If you use USB3.0 and run at 100% , the row time should be 15.73 μS. Then you can simply estimate any time.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">In full size, it has 976 line, 15.73*976=15 mS.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">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.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">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.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Best Regards</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Chad</span></span><br />
<br />
<br />
<br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Hi Simon,</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Got your means.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">Exposure time does not affect the time you need.</span></span><br />
<span style="font-size: 1pt;" class="mycode_size"><span style="font-family: 'Microsoft YaHei', serif;" class="mycode_font">If you use USB3.0 and run at 100% , the row time should be 15.73 μS. Then you can simply estimate any time.</span></span>]]></content:encoded>
		</item>
	</channel>
</rss>