Wrong numerotation/datation of images

comete83

Hello everyone,
I have encountered recently problems with the numerotation and datation of images for some Autorun sequences. The problem is not systematic, but I noticed it at least 5 times in the past months.
Here is an example :

Exposure time is 60s, so getting pose number 12 just 1s after pose number 10 is physically impossible...
So, the time written in the name if erroneous.

Problem is that the "DATE-OBS" in the FITS images are also a bit strange :
Pose 09 : 22:54:12
Pose 10 : 22:55:13
Pose 11 : 22:56:26
Pose 12 : 22:57:27
Pose 13 : 22:56:19
Pose 14 : 22:57:20
Pose 15 : 22:58:20
If it can help, I enclose the corresponding log file.

autorun-log-2024-11-01-182437.txt

73kB

For deep sky Object, this is not so serious, but for comets the datation is very important during the cometary compositage...

Thank you for any comment/solutions to this problem.

Regards,
Stephane

PMTeam@ZWO

comete83 Hello. What is your software version and phone model? We are very concerned about the issue you raised. Could you please upload the error log to us? The premise is that your ASIAIR is not turned off. If it is turned off, please upload the error log to us when you encounter this problem again. Thank you

comete83

Hello,
Thank you very much for your answer.
I use the last version of ASIAir app : v2.2.2.
Phone model is Samsung M23 5G (Android 14), with 4Go of RAM and 128 Go of storage.
ASIAIr was already turned off when I wrote the message report...
OK, If I encounter the same problem, I'll upload data via the "Bug report" inside the application.
Regards,
Stephane

PMTeam@ZWO

comete83 OK, thanks for your help.

comete83

I found on my notes the first time I encountered the problem : it was this summer (2024 July 10/11 night), just before updating the ASIAIr, from 10.74 to 11.08 firmware version.

comete83

Hello,
New observation session last Friday and I encountered again the wrong numbering/datation for one of my sequences...
All is OK for the 6 first sequences of the night, but something wrong occurred between images 60 and 70 of comet 333P/Linear field , as you can see below :

This time, images were still present on the ASIAir, and I have send the bug report from the application, as requested.
I don't know if it will appear here or not (?).

As a complement, please find attached :

the log files
phd2-guidelog-2024-11-22-181246.txt
2MB

autorun-log-2024-11-22-181336-chn.txt
89kB

autorun-log-2024-11-22-181336.txt
85kB

list-by-modification-time.txt
16kB

list.txt
17kB
the list of files of the sequence-folder as a classical view and ordered by date of modification

Very annoying bug for comets for which correct datation is vital, of course for astrometry but also for cometary stacks...

I have been using ASIAIr since april 2021, never noticed this problem before last summer.
I hope that you will soon identify the problem. Thank you very much,
Stephane

comete83

I have done some analysis on the 333P images sequence to better understand what is wrong.
In fact, the numbering is correct : it is very easy to check for this rapidly-moving comet, it if moves regularly with increasing numbers of not -)
I just renamed the files between frames #60 to #78, placing the number BEFORE the time indication :

and the comet moves always in the right direction (it was not the case when viewing the files classified by names with the date in filename present before the index !).

I then extracted the 'DATE-OBS' indication in the FITS headers to compute the time-step between two successive frames.

The sequence is composed of 30s guided frames with dithering every 3 frames. so time-step is always something like 31s, 31s, then 40 to 60s depending time required for guide star stability after dithering.

It clearly appears that the TIME-OBS indicated in the frames is going wrong for frame 71 and all successive images... -((

More info in the pdf file enclosed (see tab entitled "list_by_numbers") : the original .ods file was not allowed for uploading...
I can, of course, give more info and even the .ods file and the 333P frames if required by ZWO-team.
Thank you,
Stephane

333p-list-analysis.pdf

55kB

comete83

Hello everyone,
I have a good news : the origin of the problem is now clear !

Well, I was a little bit surprised to apparently be the only one to encounter a problem with images datation. The problem does exist but its origin is not in the code of the ASIAIr, sorry ZWO team if you get worried by my fault !
The bad datation (images were numbered in the correct order) simply arises from two concomitant facts :
1/ The weak WiFi reception of my Samsung M23 smartphone,
2/ And the lack of SIM card on my Lenovo digital tablet.

Here is the full (bad) story :

I use the M23 smartphone as the main device to send commands to the ASIAir, but due to the weakness of WiFi reception, the smartphone stays in the room near telescope.
To get an eye on the operations and enjoy the comfort of my living-room (more distant from the telescope and ASIAir…), I also use the Lenovo tablet for its larger screen and better WiFi reception. But the Lenovo tablet has no SIM card and the WiFi is connected to the ASIAIr, not the Internet Box. So the time provided by it may be not reliable...

I didn’t notice the problem until recently, but the time of my tablet was late by 5 to 6 minutes.

As soon as the M23 remains connected to the ASIAir, all is ok. But the reception is so bad, that even in the nearby room, it looses sometimes the connexion. Then, the ASIAir stays connected to the Lenovo Tablet and at some moment it takes the datation from the tablet and no more the smartphone.

Now, I carefully check the time on my Tablet several times during the night, and I didn’t encounter any problem since.