In a private message user Alfred asked me to put my experience with FS2 and the INDI FS2 driver. I answer here because it may be useful to other FS2 users:
I have version 1.25 EEPROM in the FS2. All versions from 1.19 and above must work OK with the FS2 driver and other basic LX200 drivers.
Previous versions don't support the ACK LX200 command. This was a problem because most LX200 drivers need ACK command in order to check the connection. Because my original FS2 has version 1.18 it didn't work properly with standard LX200 drivers, I programed the first version of FS2 driver for INDI to solve this problem. In this driver you can specify the FS2 version you use and overcome the ACK command for versions below 1.19. However seems Jassem rewrited the driver later in some INDI version upgrade
and the functionality to support versions below 1.19 was lost. and instead of sending ACK command it always behave as connection is OK. I don't blame him. He does a great work and I have no time to program and debug the driver any more. This can lead to problems if connectivity is lost and the driver needs to reconnect in order to recover.
Before that, I already bought an replace the FS2 EEPROM chip with a 1.25 version (see www.astro-electronic.de/version.htm )
Looking at the FS2 driver code, it seems it is the same of LX200 generic with some small changes:
- On checking connection, return always OK.
- Check accuracy after slew => No sense for me, but can be related to the coordinates format configuration in the FS2 unit discused in the earlier FS2 thread.
- Park procedure => I never used it.
- Returns fake GPS position
Also take into account the FS2 has a limited set of commands implemented:
The FS2 supports the most important LX200 commands:
:GR, :GD, :Sr, :Sd, :MS, :Q, :Qn, :Qs, :Qe, :Qw, :Mn, :Ms, :Me, :Mw, :RS, :RM, :RC, :RG, :CM, :U, ACK
If any other command is send it can lead to no response at all and the driver can understand there is a communication problem.
If someone have any communication problems with the FS2, It must activate the debug mode and send the output and I may can help.
Watch out also "active" USB cables. They have a 1 to 1 hub embeded in order to extend length, but can be troublesome.
USB has a limit of hubs in cascade it can handle and I think the best practice is to limit using a "computer <-> hub <-> devices" configuration.
Some years ago I tried to use 2 active USB cables to comunicate my computer to my telescope, camera, etc. It had a random behavior.
Now I has the configuration "computer <-> ethernet <-> old laptop <-> hub <-> 4 devices (ST8, FS2, MaxDome, Robofocus)" working ok.
Just two warnings.
- When you use the control pad and the telescope arrive to North Pole, it stops and starts moving in the reverse direction, because FS2 changes his internal state and North is in the other direction. So, you must be alert to stop pushing the N button once +90 was passed.
- Side pier is in the Dome driver because Dome need to know pier side in order to positioning right. If you have no Dome, you don't need to inform.
Future improvements if someone wants/have time to implement it in FS2 driver:
- Detect when FS2 croses North (South) Pole and register the pier side change.
- Add to the FS2 driver a function to flip meridian. If the movement to North was done by software I think the FS2 internal state with change also, but not sure.
- Add functionality for avoid colisions with the mount.
I'm the author of the FS2 driver for INDI.
The problem with FS2 is it doesn't provide a pier side status in the LX200 protocol, so the driver can't know which side it is. On the other hand, in the Dome drivers, you can manually inform which side the telescope is, in order to solve this issue.
By the way, you can flip the pier side of the telescope with FS2 without turning off or realigning. Just "simply" use the pad to move the tube to north until it crosses the north pole (south if you are down under). At that point FS2 flips his internal state of the pier side and you can slew normally and it will go to the other side of the pier. And don't remember to inform to the dome driver the new pier side.
I'm trying to slave the dome with the most recent version and I get this message:
2017-09-10T20:17:02: GetTargetAz failed 0
2017-09-10T20:17:02: Geographic coordinates are not yet defined, triggering snoop...
2017-09-10T20:17:02: Active Snoop, driver: Astro-Electronic FS-2, property: GEOGRAPHIC_COORD
2017-09-10T20:17:02: Dome will now be synced to mount azimuth position.
2017-09-10T20:16:54: Calling Update mount to anticipate goto target: 297.911 - DEC: 8.91504
So, for some reason, my mount driver don't return geographic coordinates. I think this issue appeared some time ago and Jaseem solved it.
Dome driver also has a property to specify pier side manually.
It would be nice, if pier side is not provided by the mount driver, use de dome property instead.
One possible implementation is when snooping for mount side of pier and a value is get, modify dome side of pier, and then use the last one for calculations.