I have forgotten to share the good news with you: we were managed to fix UDP connection in indi_skywatcherAltAzMount and indi_skywatcherAltAzSimple drivers. The patch has been merged into the github tree. I have no idea when will it get it's way into the precompiled packages, but it is not hard to compile the github tree, just follow the instructions in the main README.
I spent a good deal of time fighting with WireShark and NOT seeing any UDP traffic between the SynScan App and my mount. I know it works, but I can't see the traffic. Very odd indeed. On top of that, I have always been suspicious of my SynScan App, and the other night, just as I got Bode's galaxy dialed in and shot the first 2 of 50 images, it went bonkers and sent the scope 10 degrees down and a few degrees right. No apparent reason, as the tablet wasn't even touched.
All that said, I'm anxious to say goodbye to the tablet and that app. I'll test the indi mount drivers as soon as I get a little time...perhaps this weekend. I am not great in C, but I can manage a simple compile. I'm old enough to have had to compile operating systems on each new computer with which I became involved (and load the initial program start address into the program counter, mash run and cross your fingers).
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.
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!
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.
=== older post ===
I am doing a little digging on how to setup my AZ GTI over WIFI with astroberry (if possible).
When I look here:
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
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!
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.
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.
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.
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.）
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.