×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Indiserver WiFi option for Synscan Goto?

  • Posts: 90
  • Thank you received: 12
It is not easy to analize WPA protected WiFi traffic, the sniffer must run on one end of the conversation. In this case you cannot run it on the mount, so it must be the device running the synscan app. The traffic is definitely there, I was able to monitor it, running both the wireshark and synscan on windows.
3 years 9 months ago #55768

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 16
Yep, that's my issue. I don't run Windows...haven't since 1990. I did manage to see a bit of it running a sniffer on the tablet running the SynScan App, but it was a pretty limited sniffer. Enought to see there was traffic, but not enough to catalog. I am excited to try the new indi drivers for Alt/Az. Thank you once again!
3 years 9 months ago #55785

Please Log in or Create an account to join the conversation.

  • Posts: 7
  • Thank you received: 0
Hello,

Note: I solved my issue - I found the UI through KStars and was able to get things going.
Plus, I figured out how to get the server setup in the UI - took a bit of fiddling but I got it going.

Thanks,
Brett

=== older post ===
Hello,

I am doing a little digging on how to setup my AZ GTI over WIFI with astroberry (if possible).

When I look here:
AZ GTi
It seems that I should be able to set this up.

What I am unclear on with the astroberry system is:
1) What UI do I use to setup the connection?
2) When looking at the astroberry UI through the web interface that says: "Remote Driver" and shows a sample string of "driver1@removehost1" - do I need to fill something in there?

A few notes on my overall goals:
1) To have the RPi4 do guiding, and image acquisition
2) Use a PC in the house to
a) run Stellarium to find and target items
b) to do stacking of images as they come in
(i'm open to having the RPi4 do this... but figured maybe a PC would handle the load better...)

Notes on my configuration:
1) RPI 4
2) Latest astroberry setup as of yesterday
3) AS GTi running on my network - I can connect to it via my iPhone and my Windows setups with the app

Other thoughts:
1) Some good news I thought was:
a) I've got my camera working with the capture software --- so that is super cool!
b) I am able to connect up to the RPi4 and everything seems to be running well on the software side
2) I have done work with SharpCap Pro on and have had the system running in the past on that setup, but would like to have the system guide and do it's thing without the need to have my PC connected all the time... and... I happen to have an RPi4 - so what the heck - thought i'd try it out. :)

Any thoughts, suggestions, pointers to tutorials/walkthrough I missed are all greatly appreciated!

Thank you for your time and help,
Brett
Last edit: 3 years 9 months ago by Brett Humphrey.
3 years 9 months ago #55881

Please Log in or Create an account to join the conversation.

  • Posts: 90
  • Thank you received: 12
There are grreat tutorials on youtube: www.youtube.com/playlist?list=PLn_g58xBk...P34aR5midrDXx2TBbFPg
It is about StellarMate, but it is useful for Astroberry too.
The following user(s) said Thank You: Jon Carleton, Brett Humphrey
3 years 9 months ago #55885

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 16
I was able to test the updated indi_skywatcherAltAzMount and indi_skywatcherAltAzSimple on my SkyWatcher 250P Dobsonian GOTO yesterday. Both communicated flawlessly for connectivity over the WiFi UDP connection. For my mount, both had some issues with control and operation that I will describe. However, the AltAzSimple seemed to be nearly serviceable if I am correct about the problem.

AltAzMount:
I preferred the features in this, but it didn't point the scope properly. Upon unpark, it would immediately slew 180 degrees clockwise and 25 degrees up. Afterward, slew to any position was low (Alt), sometimes to the point of hitting the mount if not aborted. I could not find the reason for this initial slew nor could I correct the inaccuracy. There was also a mismatch between the SkyWatcher position indicator on the kstars display and actual position. I tried various methods of syncing, but never had reliable results. There was also a bug in the status reporting on the main Ekos panel in kstars. It didn't update properly and frequently showed the scope as parked when it was not and when the Indi panel showed unparked.

AltAzSimple:
This worked "out of the box" more or less as expected. No real surprises. The only issue I had was that the actual scope Alt position seemed to increase slightly with each Goto. For example, moving from Polaris to Capella, Sirius and finally back to Polaris, the scope was actually pointing 5 degrees higher than the target, though the kstars Skywatcher position indicator showed it centered on the star and reported the correct position. I use a very accurate level indicator and a compass with my scope for initial setup and testing and am confident in these results and their repeatability. The increase in Alt was not from a single move, but cumulative, adding a small increase with each move. Azmuth seemed to be reliable through all the positioning.

Is it possible that the motor values for the Alt motor are slightly incorrect for my mount, or is that queried from the mount on startup? For that matter, if you have a solution for the AltAzMount issues I mentioned, I do prefer that version.

Either way, THANK YOU! I am up and running without the evil, despicable, nasty, awful Synscan hand unit. I can live with a few degrees of adjustment and resync if I must.
Last edit: 3 years 9 months ago by Jon Carleton.
3 years 9 months ago #55940

Please Log in or Create an account to join the conversation.

  • Posts: 447
  • Thank you received: 30
Try the following with the ALTAZMount driver.
(This driver should have been developed with an API that can be used with all SkyWacherALT-AZMount, but there is a bug that does not fix it at all.)

1. Turn your home position to the North Pole.

2. View mount controller from Ekos mount module

3. Press the park release button on the Ekos mount controller

4. Press the stop button on the Ekos mount controller to stop the mount.
(It's a bug.)

5. Move the lens barrel appropriately in the east direction with the mount controller

6. Perform Solver → Sync with the alignment module

If you perform steps 5 and 6 multiple times, the alignment points will be registered in the alignment subsystem so that they will move correctly.
(In the case of the INDI driver, the home position is North Pole even with the ALTAZ mount.)
Last edit: 3 years 9 months ago by T-Studio.
3 years 9 months ago #55942

Please Log in or Create an account to join the conversation.

  • Posts: 447
  • Thank you received: 30
If you use Sky Watcher SynScan USB instead of a hand controller, you should be able to control it with the SkyWacher ALT-AZ driver.
3 years 9 months ago #55943

Please Log in or Create an account to join the conversation.

  • Posts: 90
  • Thank you received: 12
Most probably the AltAzMount identifies your mount as Virtuoso mount (as it does with my 10" Dob), and the driver expect Virtuoso mounts to be turned on pointing to the Polaris instead of horizontal/north. The AltAzSimple expects the mount to be horizontal/north at the time of connecting the driver.
So if you have connected the AltAzMount driver in a horizontal position (as one would do normally), that cause a big initial error in the mount model in the driver, which explains your inability to correct it with sync operations.
I see reason for both starting from pointing to the Polaris, and pointing horizontal. IMHO there should be an option for that somewhere for that, let the user choose. It does not sound too difficult to implement, maybe I will do that soon.

The AltAzMount driver has a built in procedure for unparking, only the original author of the driver knows why. There is an option on a "motion control" or "mount cotnrol" (I cant check now, as my mount is not with me now), where you can choose the unpark position (North, Shouth, etc...). The default is South, I have no idea, why. If you set that to North, the mount will not turn in azimuth after unpark. It will still raise in Alt, as far as I can tell, this is hard coded in the driver. What I do is I hit "abort motion" immediatelly after unpark, to stop this built in thing. Also there is an option, on the same panel for "silent"/"normal" slew mode. You can choose as you wish, silent mode is slow, normal mode is as fast as the mount can do.

The motor microstep per rew values are read from from the mount, it should be correct. It seems to be correct both for my little Virtuoso mount and the big Dobsonian one too. It is on the "Version" tab, i think.
3 years 9 months ago #55945

Please Log in or Create an account to join the conversation.

  • Posts: 90
  • Thank you received: 12
Most probably the AltAzMount identifies your mount as Virtuoso mount (as it does with my 10" Dob), and the driver expect Virtuoso mounts to be turned on pointing to the Polaris instead of horizontal/north. The AltAzSimple expects the mount to be horizontal/north at the time of connecting the driver.
So if you have connected the AltAzMount driver in a horizontal position (as one would do normally), that cause a big initial error in the mount model in the driver, which explains your inability to correct it with sync operations.
I see reason for both starting from pointing to the Polaris, and pointing horizontal. IMHO there should be an option for that somewhere for that, let the user choose. It does not sound too difficult to implement, maybe I will do that soon.

The AltAzMount driver has a built in procedure for unparking, only the original author of the driver knows why. There is an option on a "motion control" or "mount cotnrol" (I cant check now, as my mount is not with me now), where you can choose the unpark position (North, Shouth, etc...). The default is South, I have no idea, why. If you set that to North, the mount will not turn in azimuth after unpark. It will still raise in Alt, as far as I can tell, this is hard coded in the driver. What I do is I hit "abort motion" immediatelly after unpark, to stop this built in thing. Also there is an option, on the same panel for "silent"/"normal" slew mode. You can choose as you wish, silent mode is slow, normal mode is as fast as the mount can do.

The motor microstep per rew values are read from from the mount, it should be correct. It seems to be correct both for my little Virtuoso mount and the big Dobsonian one too. It is on the "Version" tab, i think.
3 years 9 months ago #55946

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 16
OK, today I tried some of your suggestions with good success using the SkywatcherAltAzMount driver. I started the scope pointed at Polaris instead of horizontal/North and changed the Park Direction to North from the default South. Only two issues in indi:
1. The scope moves up quite a bit on unpark. No big deal, as it does the GOTO and tracking perfectly after that. I didn't measure how far up it goes, as it is merely an annoyance.
2. For some reason, the Site Management tab wants my Longitude to be 275:00:00 degrees (Kstars Geographic infomation is accurate and correct). The actual value for here is -85:00:00. I have tried changing it, and it stays for the session, but 275 occasionally reappears. I even edited the .xml on the indiserver Raspberry Pi4 that is running the scope, but 275 degrees still appears on startup. Oddly enough, it doesn't seem to affect Tracking or GOTO with the wrong value.

Neither of the above problems would stop me from using SkywatcherAltAzMount over SkywatcherAltAzSimple. Also, I experienced better GOTO accuracy.

The only other issue I noticed was with the Kstars Toggle-on Mount Control Panel. The buttons for left-right-up-down and all diagonals work fine. However, the GOTO heads left (display screenwise). I tried the checkbox for reverse on both axes with no change in the GOTO operation. Both the dropdown menu for focused object->SkywatcherAltAz->GOTO and Toolbar GOTO work correctly, so once again, this is merely an annoyance.

Thank you for all your hard work and assistance in this matter.....now....can you fix my weather? Raining like I need to call Noah here!!
3 years 9 months ago #55961

Please Log in or Create an account to join the conversation.

  • Posts: 215
  • Thank you received: 16
Duplicate post (sorry)
Last edit: 3 years 9 months ago by Jon Carleton. Reason: Fat Fingers
3 years 9 months ago #55962

Please Log in or Create an account to join the conversation.

  • Posts: 90
  • Thank you received: 12
The only reason I can imagine for slewing up the mount upon unpark is that after that one can immediately take a plate solve to sync the mount. It can be made a configurable option though. At least to know about that. For now, it is hard coded into the code.
    // Altitude 3360 points the telescope upwards
    DeltaAlt = CurrentAltAz.alt - 3360;

I have no idea about your coordinate problem.
3 years 9 months ago #55963

Please Log in or Create an account to join the conversation.

Time to create page: 0.461 seconds