154 replies to this topic

[artik]

I also have some plate solving problem with astap to start with, but when I bin down to 2x2 things improved.

I don't use special settings - what is important is to define correct FOV, search radius (around the expected location) and to have a reasonable signal and it works.

[drcbweaver]

What is typical FOV of this Hestia?

 

Generally with FOV of 1 degree and above AstroHopper is more than sufficient (I use it with Celestron C8 with 2000mm FL)

 

Regarding plate solving and ASTAP I found that ASTAP generally requires better quality than astrometry.net - but it works locally on Android and very fast.

The Hestia is 1.8 degrees.
 

One more question on plate solving. Is there a way to replace the simulation image with my own so I can test it? I had seen the question in another thread but couldn't find where it was answered.

[UB_Astro]

Great, I want to report that OLS runs on my system.

 

I shut down the chromebook for a while and worked on something else and when I reboot it, the config.js file becomes config.json.  Anyhow I modify the content using a text editor and run ./build/ols_cmd config.json.  It works.  So for some reason the file name extension has to be .json not .js.

 

I manually dump a few dng subs to the watch directory and it stack successfully.   Weather is bad these few days so a field test might only come a few days later.

 

Big thanks for the support Artik.

[artik]

The Hestia is 1.8 degrees.
 

 

The Hestia is 1.8 degrees (note check both vertical and horizontal - to select a correct one). - it is decent FOV for AstroHopper and should be good for ASTAP.

Also I forgot to mention as point of optimization - there is a search radius for ASTAP - so you need to be somewhere near target.

 

One more question on plate solving. Is there a way to replace the simulation image with my own so I can test it? I had seen the question in another thread but couldn't find where it was answered.

 

No - it is complicated feature to implement: mostly because of permissions and file access that is "brain damaged" on latest Androids

[artik]

I manually dump a few dng subs to the watch directory and it stack successfully.   Weather is bad these few days so a field test might only come a few days later.

 

What camera do you use with chromebook? How are you planning to upload files there?

[UB_Astro]

What camera do you use with chromebook? How are you planning to upload files there?

The camera is an Arducam camera module with a SONY IMX462 sensor.  This module connects to the CSI interface of a Raspberry Pi 3B+.  A python script runs in the Pi to control and capture images from the camera.  The captured dng files are stored locally in the Pi as a base storage.

 

The Pi serves also as a WiFi hotspot and the chromebook connects to it.  Another python script will send the file via WiFi from the Pi to the chromebook whenever a new dng file is captured from the camera.

 

The dng files arrive at the chromebook and are stored in a parking directory first.  A watchdog python script runs on the chromebook will ensure that the complete dng file is transferred before it is finally moved to the watch directory for live stacking.  This watchdog is important as it can take a while for the dng file to be completely transferred from the Pi to chromebook via WiFi.  Without it there are chances where the live stacking software picks up an imcomplete file and stacking fails.

[artik]

  This watchdog is important as it can take a while for the dng file to be completely transferred from the Pi to chromebook via WiFi.  Without it there are chances where the live stacking software picks up an imcomplete file and stacking fails.

Note: OLS under Linux uses file system move or close write event to operate: https://github.com/a...rc/util.cpp#L54 - basically it means it wouldn't open file before write was completed and file closed - it is done on purpose to prevent triggers on partial writes. So you can try using wd directory directly.

[UB_Astro]

Note: OLS under Linux uses file system move or close write event to operate: https://github.com/a...rc/util.cpp#L54 - basically it means it wouldn't open file before write was completed and file closed - it is done on purpose to prevent triggers on partial writes. So you can try using wd directory directly.

Good info, I will try.

[UB_Astro]

Still, I am not clear about the risk of completely deleting the cppcms directory.  I am now left with 900M of disk space.

[artik]

Still, I am not clear about the risk of completely deleting the cppcms directory.  I am now left with 900M of disk space.

You can delete the directory you build cppcms in - you don't need it any more. As if you installed any 3rd part library - you don't need the sources.

[drcbweaver]

The Hestia is 1.8 degrees (note check both vertical and horizontal - to select a correct one). - it is decent FOV for AstroHopper and should be good for ASTAP.

Also I forgot to mention as point of optimization - there is a search radius for ASTAP - so you need to be somewhere near target.

 

No - it is complicated feature to implement: mostly because of permissions and file access that is "brain damaged" on latest Androids

Just an FYI...on my PC using the ASTAP software, if I click the "slow" option it solves it. If I leave that option unchecked I get the same "no solution found"

[UB_Astro]

It's getting late here so this is my last post for today.  Not a good news.

 

The success rate of stacking in OLS using sample dng files from previous EAA session is low.  This is not the problem of OLS.  My DIY tracker is very rough so shift between images can be large.  It seems that OLS use a very tight tolerance in shifting so many images failed.  Most of the failure as recorded in log file look like this:

 

2024-09-05 23:10:09; stacker, info: Real time video frame 7 arrived (video_stream.h:119)
2024-09-05 23:10:09; stacker, info: Gradient removal took 21.3578 ms (pre_processor.cpp:439)
2024-09-05 23:10:09; stacker, info: Preprocessing took 31.0861ms (pre_processor.cpp:43)
2024-09-05 23:10:09; stacker, info: Registration at 2:[40, 7]
(stacker.h:438)
2024-09-05 23:10:09; stacker, info: Step size 36.35 from (4.0,2.0) to (40.0,7.0) limit = 16.7 avg_step=  4.5
(stacker.h:514)
2024-09-05 23:10:09; stacker, info: Failed to stack frame (stacker_processor.cpp:120)
2024-09-05 23:10:09; stacker, info: Stacking took 212.045 ms (stacker_processor.cpp:123)
2024-09-05 23:10:31; stacker, info: Real time video frame 8 arrived (video_stream.h:119)
2024-09-05 23:10:31; stacker, info: Gradient removal took 19.9491 ms (pre_processor.cpp:439)
2024-09-05 23:10:31; stacker, info: Preprocessing took 28.9117ms (pre_processor.cpp:43)
2024-09-05 23:10:31; stacker, info: Registration at 2:[46, 9]
(stacker.h:438)
2024-09-05 23:10:31; stacker, info: Step size 42.58 from (4.0,2.0) to (46.0,9.0) limit = 17.9 avg_step=  4.5
(stacker.h:514)
2024-09-05 23:10:31; stacker, info: Failed to stack frame (stacker_processor.cpp:120)
2024-09-05 23:10:31; stacker, info: Stacking took 210.288 ms (stacker_processor.cpp:123)

 

The step size is larger than allowed.  I have been using Astro Live Stacker (ALS) in those session and they are very relaxed in this so the stack success rate can be close to 100%.

 

Maybe this is not a nice request but is there a way to adjust the step size limit by user to accomodate inferior tracking?

[artik]

It isn't about step size it is rather about consistency. If you start small steps and than step increased to a very large value I suspect a error and filter. It works even in non-tracking mode with very large steps.

But if step size increased more than previous (ie 36 pixels after 4.5) - it means something wrong. I suggest check on real setup.

 

Another option of step starts to be significant (but this is ok) you press pause and resume - I reset limit on the step.

[artik]

Just an FYI...on my PC using the ASTAP software, if I click the "slow" option it solves it. If I leave that option unchecked I get the same "no solution found"

Regarding slow - notice that ASTAP is used in correction context. And android device isn't powerful - I don't want to wait minutes for solving to be completed - rather few seconds.

[andriy_melnykov]

artik, what are your thoughts on using OpenLiveStacker to create a sort of open source version of the Pegasus Astro SmartEye? 

SoHo Enterprise has an IMX585 sensor for the RPi: https://soho-enterpr...rt-sample-sale/

 

It works with Pi Zero 2W: https://soho-enterpr...or-rpi-zero-2w/

Not sure if Zero 2W has enough power for live stacking? 

 

If not, there is a CM4 expansion board, which should keep the physical size of the “eyepiece” sort of small:  https://github.com/harlab/CM4Ext_Nano

CM4 offers 8gb RAM and faster eMMC. 

 

There is a high resolution 2.1 inch 480x480 MIPI touchscreen that can be the digital eyepiece: https://www.buydispl...h-circle-screen

 

I suppose the end result would be an eyepiece with the dimensions slightly larger than that of a large eyepiece like the largest Panoptics or Naglers. 

I still can’t figure out how Pegasus Astro managed to fit the electronics into their small eyepiece that can perform live stacking, they must have designed a custom CPU board. 

Hi Taylor!

Maybe you have already seen, I have built a digital binocular eyepiece, described here: https://www.cloudyni...cular-eyepiece/

It is not a compact solution at all, with external PC. But with this project I gained also some experience. I have experimented with resolution and AFOV, and in my opinion, 480x480 screen will be very disappointing. My display has ~1250x1250 per eye with relatively small AFOV of ~40°, and it is still not ideal.

Maybe you can try to find a display with better resolution? I have seen also many interesting displays here: https://www.displaymodule.com/

 

May I propose some other solutions for discussion, based also on OpenLiveStacker?

 

1. You can use a display I have used, https://www.waveshar...40x2560-lcd.htm or similar.

It is meant also for Raspberry Pi, but for a bigger 4B one. Still, it can be a compact all-in-one solution. For such project I could support and modify my mechanics to accommodate the Rasperry Pi and other components.

 

2. Maybe you can still use a smartphone? If app layout can be rearranged to have an image on one half of a screen, and controls on the other half, you can get a very convenient package with a battery, a lot of computing power, touch screen interface near your digital eyepiece and high resolution screen! You will still need external camera though, but it can be pretty compact. I can support with mechanics also.

[UB_Astro]

It isn't about step size it is rather about consistency. If you start small steps and than step increased to a very large value I suspect a error and filter. It works even in non-tracking mode with very large steps.

But if step size increased more than previous (ie 36 pixels after 4.5) - it means something wrong. I suggest check on real setup.

 

Another option of step starts to be significant (but this is ok) you press pause and resume - I reset limit on the step.

I fully agree with you that the tracking is not consistent.  Looking into the subs one by one like a slide show, I can see the target oscillate wildly along the RA line with net shift in RA/DEC also.  This is a result of a huge periodic error + poor polar alignment.  Currently I can't do too much about it as the hardware is rather locked.

 

I take your advice to try to simulate pause/resume to see the effect, and more importantly to learn your logic on how to reset the limits to avoid too many fail-to-stack.  I extract out the major lines from the debug file and paste below.  My observation is that whenever I do a pause/resume action, the next frame for certain can stack.  The lead me to make a short trial of having pause/resume for every sub, certainly this make every sub stackable.  But this is not practical. I also try to see if the limit and avg_step will be updated by these pause/resume actions.  I note that the limit do change a bit but the avg_step not.  But suddenly after 13 stacks (seen from the debug) the avg_step is updated and the limit increase (highlighted in bold).  So what trigger this update in avg_step and how can I bring in this update earlier?  Of course the root cause of the problem still lies with poor tracking, this I understand.  Following is the extract from debug:

 

2024-09-06 09:07:10; stacker, info: Real time video frame 2 arrived (video_stream.h:119)
2024-09-06 09:07:10; stacked, info: So far stacked 1
2024-09-06 09:07:34; stacker, info: Real time video frame 3 arrived (video_stream.h:119)
2024-09-06 09:07:34; stacker, info: Registration at 1:[4, 2]
2024-09-06 09:07:34; stacked, info: So far stacked 2
2024-09-06 09:08:05; stacker, info: Real time video frame 4 arrived (video_stream.h:119)
2024-09-06 09:08:05; stacker, info: Registration at 2:[13, 3]
2024-09-06 09:08:05; stacker, info: Step size  9.06 from (4.0,2.0) to (13.0,3.0) limit =  8.9 avg_step=  4.5
2024-09-06 09:08:05; stacker, info: Failed to stack frame (stacker_processor.cpp:120)
2024-09-06 09:08:31; stacker, info: Real time video frame 5 arrived (video_stream.h:119)
2024-09-06 09:08:31; stacker, info: Registration at 2:[22, 5]
2024-09-06 09:08:31; stacker, info: Step size 18.25 from (4.0,2.0) to (22.0,5.0) limit = 13.4 avg_step=  4.5
2024-09-06 09:08:31; stacker, info: Failed to stack frame (stacker_processor.cpp:120)
pause + resume
2024-09-06 09:09:01; stacker, info: Real time video frame 6 arrived (video_stream.h:119)
2024-09-06 09:09:01; stacker, info: Registration at 2:[32, 6]
2024-09-06 09:09:01; stacked, info: So far stacked 3
2024-09-06 09:09:22; stacker, info: Real time video frame 7 arrived (video_stream.h:119)
2024-09-06 09:09:22; stacker, info: Registration at 3:[40, 7]
2024-09-06 09:09:22; stacker, info: Step size 36.35 from (4.0,2.0) to (40.0,7.0) limit = 15.3 avg_step=  4.5
2024-09-06 09:09:22; stacker, info: Failed to stack frame (stacker_processor.cpp:120)
pause + resume
2024-09-06 09:09:55; stacker, info: Real time video frame 8 arrived (video_stream.h:119)
2024-09-06 09:09:55; stacker, info: Registration at 3:[46, 9]
2024-09-06 09:09:55; stacked, info: So far stacked 4
pause + resume
2024-09-06 09:10:13; stacker, info: Real time video frame 9 arrived (video_stream.h:119)
2024-09-06 09:10:13; stacker, info: Registration at 4:[49, 11]
2024-09-06 09:10:13; stacked, info: So far stacked 5
2024-09-06 09:10:43; stacker, info: Real time video frame 10 arrived (video_stream.h:119)
2024-09-06 09:10:43; stacker, info: Registration at 5:[51, 12]
2024-09-06 09:10:43; stacker, info: Step size 48.05 from (4.0,2.0) to (51.0,12.0) limit = 16.7 avg_step=  4.5
2024-09-06 09:10:43; stacker, info: Failed to stack frame (stacker_processor.cpp:120)
pause + resume
2024-09-06 09:11:13; stacker, info: Real time video frame 11 arrived (video_stream.h:119)
2024-09-06 09:11:13; stacker, info: Registration at 5:[50, 14]
2024-09-06 09:11:13; stacked, info: So far stacked 6
pause + resume
2024-09-06 09:11:32; stacker, info: Real time video frame 12 arrived (video_stream.h:119)
2024-09-06 09:11:32; stacker, info: Registration at 6:[51, 15]
2024-09-06 09:11:32; stacked, info: So far stacked 7
pause + resume
2024-09-06 09:12:03; stacker, info: Real time video frame 13 arrived (video_stream.h:119)
2024-09-06 09:12:03; stacker, info: Registration at 7:[47, 17]
2024-09-06 09:12:03; stacked, info: So far stacked 8
pause + resume
2024-09-06 09:12:28; stacker, info: Real time video frame 14 arrived (video_stream.h:119)
2024-09-06 09:12:28; stacker, info: Registration at 8:[32, 17]
2024-09-06 09:12:28; stacked, info: So far stacked 9
pause + resume
2024-09-06 09:12:51; stacker, info: Real time video frame 15 arrived (video_stream.h:119)
2024-09-06 09:12:51; stacker, info: Registration at 9:[17, 18]
2024-09-06 09:12:51; stacked, info: So far stacked 10
2024-09-06 09:13:09; stacker, info: Real time video frame 16 arrived (video_stream.h:119)
2024-09-06 09:13:09; stacker, info: Registration at 10:[6, 19]
2024-09-06 09:13:09; stacker, info: Step size 17.12 from (4.0,2.0) to (6.0,19.0) limit = 17.9 avg_step=  4.5
2024-09-06 09:13:09; stacked, info: So far stacked 11
pause + resume
2024-09-06 09:13:28; stacker, info: Real time video frame 17 arrived (video_stream.h:119)
2024-09-06 09:13:28; stacker, info: Registration at 11:[2, 21]
2024-09-06 09:13:28; stacked, info: So far stacked 12
pause + resume
2024-09-06 09:13:49; stacker, info: Real time video frame 18 arrived (video_stream.h:119)
2024-09-06 09:13:49; stacker, info: Registration at 12:[2, 22]
2024-09-06 09:13:49; stacked, info: So far stacked 13
2024-09-06 09:14:04; stacker, info: Real time video frame 19 arrived (video_stream.h:119)
2024-09-06 09:14:04; stacker, info: Registration at 13:[7, 24]
2024-09-06 09:14:04; stacker, info: Step size  5.10 from (6.0,19.0) to (7.0,24.0) limit = 25.0 avg_step= 12.5
2024-09-06 09:14:04; stacked, info: So far stacked 14
2024-09-06 09:14:42; stacker, info: Real time video frame 20 arrived (video_stream.h:119)
2024-09-06 09:14:43; stacker, info: Registration at 14:[14, 25]
2024-09-06 09:14:43; stacker, info: Step size  7.07 from (7.0,24.0) to (14.0,25.0) limit = 21.3 avg_step= 10.6
2024-09-06 09:14:43; stacked, info: So far stacked 15
2024-09-06 09:15:21; stacker, info: Real time video frame 21 arrived (video_stream.h:119)
2024-09-06 09:15:21; stacker, info: Registration at 15:[26, 26]
2024-09-06 09:15:21; stacker, info: Step size 12.04 from (14.0,25.0) to (26.0,26.0) limit = 19.7 avg_step=  9.9
2024-09-06 09:15:21; stacked, info: So far stacked 16
 

[artik]

There is one thing I don't understand.

 

In 8 minutes you got only ~20 frames?  Time frame to frame takes almost 20-30 s and step is in tens of pixels? What is the exposure time? Do you get trails in images?

 

It looks like you are fighting the wrong battle. You need to get better data flow - because it seems like most of the time you don't actually capturing frames

[artik]

I try to elaborate.

 

Generally there is an assumption that 1/frame_rate is close to exposure time. So if you have 1s exposure that you have 1 FPS or 1/2 FPS but not 1/10 FPS. There is built in threshold that allows movements of few pixels but frames should be adjecent.

 

The only case it isn't is when doing short exposure non-tracking imaging and in such a case data transfer can bottle neck: for example non-tracking DSE, solar, planetary - but in non tracking setup there is consistency - objects moving at constant speed and if it not happens and the shift is larger than few pixels than there is probably problem with wind or tracker stopped working.

 

In your case you have very large steps (i.e. tracking isn't very consistent) AND very low framerate. This is really corner case and I'd suggest think how to increase data acquisition speed. Can you stack on PI itself and use chromebook to show the UI (it is web UI anyway)?

[artik]

Hi Taylor!

Maybe you have already seen, I have built a digital binocular eyepiece, described here: https://www.cloudyni...cular-eyepiece/

It is not a compact solution at all, with external PC. But with this project I gained also some experience. I have experimented with resolution and AFOV, and in my opinion, 480x480 screen will be very disappointing. My display has ~1250x1250 per eye with relatively small AFOV of ~40°, and it is still not ideal.

Maybe you can try to find a display with better resolution? I have seen also many interesting displays here: https://www.displaymodule.com/

 

May I propose some other solutions for discussion, based also on OpenLiveStacker?

 

1. You can use a display I have used, https://www.waveshar...40x2560-lcd.htm or similar.

It is meant also for Raspberry Pi, but for a bigger 4B one. Still, it can be a compact all-in-one solution. For such project I could support and modify my mechanics to accommodate the Rasperry Pi and other components.

 

2. Maybe you can still use a smartphone? If app layout can be rearranged to have an image on one half of a screen, and controls on the other half, you can get a very convenient package with a battery, a lot of computing power, touch screen interface near your digital eyepiece and high resolution screen! You will still need external camera though, but it can be pretty compact. I can support with mechanics also.

 

 

I suggest do following experiment: take 20-25mm cheap eyepiece flip it (so you look at the barrel instead of eye part) and look at the smartphone's screen (like magnifying glass), preferably OLED but LCD is Ok as well. Typical smartphone display as at least 300 DPI - higher end go to 500-600dpi and even more. When you'll look through the eyepiece you'll see each and every pixel. It would be huge. Even with longer focal length eyepiece you'll have same problem.

 

Now you look at the screen from at least 11cm distance (that is considered a nearest point an adult eye can focus. So if you want to bring it closer - to have anything that looks like eyepiece you'll probably need something at least 40mm length (4cm) i.e. you need to increase screen DPI to at least 2.75 times. So to get lowest DPI for typical screen (300) you need to go to something like 800-1000dpi - which would cost quote a lot and add optics and high resolution. Something that more close to VR headset resolution than cheap display. I don't think you can get for anything affordable without mass manufacturing.

 

And all this to have fake eyepiece when you can just have a tablet screen to look onto. I suggest, take tablet put it on the scope, build a shroud around it an you are good to go. 

[artik]

Ok here the quote from the specs of Pegaus Eyepiece:

What is the resolution of the SmartEye display screen?
The screen resolution is 2560×2560.

Is the resolution high enough to prevent pixelation?
Absolutely. The SmartEye utilizes OLEDoS (OLED on Silicon) technology, meeting a remarkable resolution of 3500 ppi (iPhone 15 Pro screen is 460 ppi for comparison).

 

You see? There is a reason it costs $1500. And OLED on Silicon is VR class display (I worked in display industry for quite a long time recently)

 

So my DPI was still quite off by x3.5 but I got the problem correctly.

 

Edit: Look here: https://www.displaym...0nits-mipi-1010

It seems like exact the display type they are using in Pegasus - it on its own costs like the eyepiece itself :-) 

Edited by artik, 06 September 2024 - 08:54 AM.

[UB_Astro]

There is one thing I don't understand.

 

In 8 minutes you got only ~20 frames?  Time frame to frame takes almost 20-30 s and step is in tens of pixels? What is the exposure time? Do you get trails in images?

 

It looks like you are fighting the wrong battle. You need to get better data flow - because it seems like most of the time you don't actually capturing frames

Sorry I have not explained clearly.

 

I have not tested OLS in the field yet.  I took some dng files from previous EAA session which are stored in the hard drive.  Then manually 1 by 1 I dropped the dng files into the watch folder to let OLS to stack.  From time to time I checked the terminal for log messages etc so the time interval did not represent real life cycle time.  I normally use a 5s exposure time, the avg overall cycle time for 1 sub is about 10s in the field.  So effectively I am getting about 6 subs/minute at about 50% time efficiency. I do not see star trails normally.

 

I started EAA using only the Raspberry PI 3B+ without chromebook, but this Pi 3B+ does not have the capacity to handle so much and the speed is very slow.  I tested with ASTAP live stacking before on the Pi only and the speed is about 2-3 sub/minute at best.  That's the reason I get a chromebook to do the stacking to offload the Pi.

 

I fully understand that I am using very crude equipment (both the optics and electronics) to do EAA.  I am just trying to squeeze every drop of performance out.  For the time being I cannot spend any more dollars into this so I need to live with what I have.

 

Coming back to OLS, I really like it.  I tried before ASTAP live stacking, Siril experimental live stacking and ALS live stacking.  ALS is the best among the 3 in terms of ease of use and flexibility.  But OLS has far more feature than ALS and also very user friendly, the task for me is how to practically use it in the field with higher efficiency.

Edited by UB_Astro, 06 September 2024 - 08:12 PM.

[artik]

I normally use a 5s exposure time, the avg overall cycle time for 1 sub is about 10s in the field.  So effectively I am getting about 6 subs/minute at about 50% time efficiency. I do not see star trails normally.

 

See - if you have 5s subs each 10s and you have 5-10 pixels steps you WILL have star trails for sure. If your images have round stars than you probably mixed the order of images or your periods between captures are way higher than 10s.

 

Do a field test (even if you have clouds) just find a patch in the sky and record the session using Save All Frames to see the data. (Or alternatively keep the images)

Edited by artik, 06 September 2024 - 11:56 PM.

[UB_Astro]

See - if you have 5s subs each 10s and you have 5-10 pixels steps you WILL have star trails for sure. If your images have round stars than you probably mixed the order of images or your periods between captures are way higher than 10s.

 

Do a field test (even if you have clouds) just find a patch in the sky and record the session using Save All Frames to see the data. (Or alternatively keep the images)

Unfortunately I will not be able to go for any field test for the coming weeks due to other issues.

 

I enclosed below 5 subs from the EAA session and they are in actual order, with about 10s cycle time in avg.  Exposure is 5s.  Even if I am able to do a field test now I will get the same type of subs.  These are the first 5 subs I used to simulate the OLS live stacking with the log output file I posted above.

 

The OTA is a DIY 76mm f/4 reflector with a spherical primary mirror, and it is clear that there are many aberrations and artifacts in addition to tracking errors.  You might wonder if this is worthy of doing any astronomical work, nevertheless this is the best I have.

 

Certainly I cannot ask your software to solve my problem, I am looking to understand your logic of setting the limits and how I might take the chance to get the best efficiency out of it.

Attached Thumbnails

• 
• 
• 
• 
• 

[artik]

@UB_Astro

 

Hi, I fixed an issue that did reset step size tracking after pause. So you may pull and build once again latest main version.

 

It is a bug that was introduced with filters support and users reported me that after movement and pause the stacking fails to resume.

 

I'll release Android app with that fix in next few days.

[UB_Astro]

@UB_Astro

 

Hi, I fixed an issue that did reset step size tracking after pause. So you may pull and build once again latest main version.

 

It is a bug that was introduced with filters support and users reported me that after movement and pause the stacking fails to resume.

 

I'll release Android app with that fix in next few days.

Thanks, will do that in coming days.  And I assume there is no need to kind of "uninstall" the old one, just rebuild and the new files will overwrite the old ones?