radon199 replied to the topic 'Stellar Mate tablets' in the forum. 1 month ago

I do not know how the live stacking is performed, and so I can't be confident of that.

I can say that most processes such as image capture, plate solving, etc are run entirely from the PI, and only their status and control are synced to the app, so the quality of the tablet has no bearing on that. It will effect the upload speed and display of images on the tablet, but I suspect that doesn't put too much strain on even a cheap tablet, and it doesn't stop the PI from starting the next frame or doing it's work.

Read More...

For the record, this post is about the original Star Adventurer and the 2i variant.

To reiterate the support. I have been using the 2i variant with both the EQMod driver, and the new specific 2i driver ( which only handles connection via wifi or usb ), for a number of months now. I am able to perform most of the actions that you can do with a EQMod mount ( only in RA ) such as GoTo, Manual slew, dithering, turning tracking on and off, controlling the tracking rate, and parking the mount. I use it in APP mode with a USB connection.

As of this post date, I do not think the GTi is out in any market, as it was only announced a couple days ago. I know some reviewers have received production examples, but that doesn't mean that it is out in the wild.

I suspect however, given that the GTi works with the SyncScan app, that it will more then likely work out of the box with the EQMod driver and INDI. I know of at least one reviewer which had no issues using EQMod with ASCOM, so I suspect it will be a similar story as it responds to the same USB commands.

youtu.be/OzmloQA-K7I?t=873

Read More...

There was some recent commits to the INDI 3rd party github that appear to allow for both usb and wifi connections to the 2i, not sure if that has made it into StellarMate yet.

Here is what I have :

Raspberry Pi4 with StellarMate OS
SA 2i connected via USB-A to mini USB-B ( not into the ST4 jack )
ASI120mm mini connected via USB-A to USB-C

I then use the EQMOD driver with a baud rate of 115200 . Guide commands are sent via the EQMOD driver. I can guide, dither, do RA GoTos, manually move the mount in RA, and also Park and unpark the mount ( return to vertical position ). I did have some issues with plate solving because the mount returns a DEC of 0.0 always, and this confuses some aspects of EKOS.

You cannot use the SA specific profile that derives from the AltAz base profile, this does not work.

There, however, should now ( or soon ) be two new StarAdventurer specific profiles included with the EQMOD driver that are called USB and WIFI that preset the baud rate and set up the wifi connection, and those are probably preferred going forward.

This worked fine for me as of a week or so ago.

Read More...

Forgot to say I was using the 2i wifi version. I can't be sure but it could be something was added to the firmware of the 2i to allow the app to control it and therefor allow EQMOD to actually communicate.

Read More...

In the mean time, I think the dither is working as far as the RA component is concerned. So what I will do is set the dither retries to 0 or 1 and it should abort after the first failed attempt ( which is actually correct as far as what we can do is concerned ).

It would still be nice if there was an option for this. PHD2 has a checkbox for RA only dither, as these mounts are fairly popular in the community. It would be great if we could either have a RA only dither option, or take into account the guiding controls as I have suggested above.

Read More...

FYI, I have been using EQMOD with the Star Adventurer and am able to guide via this instead of the ST4 cable.

There was an issue related to dithering however with EKOS, but that would happen regardless of EQMOD or the ST4 cable.

Read More...

Pardon my suggestion, but it seems like this could solve the issue. Basically not considering deltaRA and deltaDEC if that part of guiding is disabled:

if ((!Options::rAGuideEnabled() || fabs(driftRA) < 1) && (!Options::dECGuideEnabled() || fabs(driftDEC) < 1))

There might be other code paths related to manual dithering that I did not check. Also feel free to ignore as I am not super familiar with the codebase haha.

Read More...

In the log it is sending 0ms DEC pulses. I had RA guiding only on, and the two axis calibration was off, so RA only guiding was working fine. Manual dithers failed as well.

[2021-12-30T22:26:25.208 PST DEBG ][     org.kde.kstars.ekos.guide] - Dithering in progress. Current 112.23 310.043 Target 122.317 310.523 Diff star X: -0.152848 Y: -10.0973
[2021-12-30T22:26:25.208 PST INFO ][     org.kde.kstars.ekos.guide] - "Warning: Dithering failed. Autoguiding shall continue as set in the options in case of dither failure."

Checking the log it is reporting an offset in X before failure.

Looking at the code leads me to this line here :
github.com/KDE/kstars/blob/master/kstars...ernalguider.cpp#L277

So X and Y offset must be under 1 for the dither to complete. That can't happen if we are only guiding in RA.

The internal guider should be checking the RA and DEC settings to determine the directional vector, and/or it should ignore discrepancies in an axis for which guiding is disabled.

Let me know if this should be a support ticket. Dithering was one of the 2 big reasons I wanted to start guiding.

Read More...

Hey,

I am new to autoguiding and EKOS. I was testing things out tonight and was able to get guiding working as expected for my mount. However I was having issues with dithering. It would hang and then fail during the dither.

I am not exactly sure why it is failing. Looking at the logs I can see it start the dither, try a number of times capturing a image and sending a command to EQMod, print that it failed, and then print that it succeeded. Can anyone make heads or tails of what is happening? As I mentioned guiding corrections seem to go through no problem.

I have a RA only tracker, fyi.

Read More...

The sequence tab in Ekos allows saving and loading of a predefined list of sequences. This will store any set values, custom parameters and scripts.

These sequences however do not appear to be readable from the mobile Apps. Instead each app will store a set of presets to run, which define a similar set of options to the more feature rich sequences in the actual ekos application.

It would be nice if saved sequences in the Ekos main application could be loadable as presets in the Apps. Maybe they are read only, except for options exposed to the App, but this would allow you to define a set of sequences while not imaging using the full VNC connection, and then run only them via the app.

Read More...

Yes, the OS will prefer a wifi network it can connect to over the hotspot if available.

You should be able to forget your home network via the app or by vpn'ing into StellarMate via the local interface. I think you can also switch to the hotspot via vpn, not 100% sure.

Read More...

So, some updates.

I did discover the fast exposure option, and so that does solve 50% of the problem. For 30 second exposures with fast exposure on I have a delay of around 3 seconds between exposures, some of which is mirror actions. All in all that is totally fine for delay.

It however does not work for things like flats. The fast exposure requires that download times take less then the exposure time. For me that means anything less then 25 seconds will error. I think for flats we still need something like a don't download option. That will just take the N flats and leave them on the SD card.

I do have some additional questions about fast exposures. Is there a reason for there being a fast exposure amount that is different from the sequence length? If I try and take a 10 count with 10 fast exposures kstars will crash. If I set it to more fast exposures then sequence length it works. I also can set the fast exposure count from the app, but I am unable to put it in the preset in the app. I do see the option to autoset that via the sequence when using VNC.

I also need to disable the fast exposure when doing preview captures, as otherwise it throws an error if the download time is longer then the exposure, even if it does seem to take the image.

Read More...

Yes. The Gphoto INDI driver offers two options. Ram and SDcard. If set to Ram, images are downloaded and deleted from memory. However if set to SDcard, images will end up saved to both the card and downloaded to the raspberry pi.

Looking at the CLI options for what is supported it should be possible to trigger a capture and keep the image without downloading.

Read More...