Try again. If you're using the PPA, wait for tomorrow's update. If you compiling from svn, you can try now.

Awesome!! It seems to work!!
Now it connects, it tracks and reacts to slew commands.
It seems that there remains a problem with the detection of the slew finish.
In the log file I get:

SCOPE 949.667060 sec : <Slew>
SCOPE 949.667069 sec : CMD <:MS#>
SCOPE 949.789369 sec : RES <0>
DEBUG 950.446024 sec : CMD (#:YGi#)
DEBUG 950.554939 sec : RES (1)
SCOPE 950.555010 sec : CMD <#:GR#>
SCOPE 950.666042 sec : RES <19:35:40>
SCOPE 950.666161 sec : VAL [19.5944]
SCOPE 950.666175 sec : CMD <#:GD#>
....
But on the log screen I get "Slew is complete, tracking..." as soon as the slew command is issued (and the telescope just starts slewing). I suppose that there is an issue with the management of the answer of the :YGi command.
Once this is solved, I'll run a more extensive test on a clear night (possibly tomorrow).

Many many thanks!

Fixed now

Hi - testing again.
The problem of the "end of slew" is still (partially) there, and I probably know why.
Sometimes the mount acts normally, and the logged message sequence is:

SCOPE 429.770154 sec : <setObjectRA>
SCOPE 429.770209 sec : CMD <:Sr 19:52.4#>
SCOPE 429.874809 sec : CMD <:Sr 19:52.4#> successful.
SCOPE 429.874854 sec : <setObjectDEC>
SCOPE 429.874866 sec : CMD <:Sd +09*03#>
SCOPE 429.985703 sec : CMD <:Sd +09*03#> successful.
SCOPE 429.985768 sec : <Slew>
SCOPE 429.985785 sec : CMD <:MS#>
SCOPE 430.108067 sec : RES <0>
DEBUG 430.249621 sec : CMD (#:YGi#)
DEBUG 430.449771 sec : RES (1)
SCOPE 430.449819 sec : CMD <#:GR#>
SCOPE 430.560948 sec : RES <21:44:52>
SCOPE 430.561163 sec : VAL [21.7478]
SCOPE 430.561191 sec : CMD <#:GD#>
SCOPE 430.671922 sec : RES <+09:56:22>
SCOPE 430.671993 sec : VAL [9.93944]
DEBUG 431.672950 sec : CMD (#:YGi#)
DEBUG 431.781678 sec : RES (1)
....etc (YGi returning 1 = is slewing)

---

But more often, YGi returns '0' at the very beginning and so INDI thinks that the slew has finished when it still has to start:

SCOPE 936.023094 sec : <setObjectRA>
SCOPE 936.023200 sec : CMD <:Sr 21:48.0#>
SCOPE 936.125361 sec : CMD <:Sr 21:48.0#> successful.
SCOPE 936.125435 sec : <setObjectDEC>
SCOPE 936.125447 sec : CMD <:Sd +10*19#>
SCOPE 936.236343 sec : CMD <:Sd +10*19#> successful.
SCOPE 936.236395 sec : <Slew>
SCOPE 936.236409 sec : CMD <:MS#>
SCOPE 936.358700 sec : RES <0>
DEBUG 936.358779 sec : CMD (#:YGi#)
DEBUG 936.700466 sec : RES (0)
SCOPE 936.700539 sec : CMD <#:GR#>
SCOPE 936.811680 sec : RES <19:52:24>
SCOPE 936.811913 sec : VAL [19.8733]
SCOPE 936.811941 sec : CMD <#:GD#>
SCOPE 936.926659 sec : RES <+09:03:37>
SCOPE 936.926738 sec : VAL [9.06028]
....
Most probably, the Pulsar unit introduces a delay between the :MS command and the effect slew start (when :YGi is risen to 1). I think that allowing for a delay of a couple of seconds before querying YGi should solve the problem. Or, one should first check that YGi answers "true", and then falls back to "false"...

Another finding.

When I click on "Park" ...nothing happens. Should it stop tracking? It does not. If I then click on "unpark" I get a "command not supported" - and subsequent moves are refused ("...should first be unparked").
Note that this mount has a "home" Alt-Az position that can be set in memory (with ":YSW). The telescope can slew to it by (#:YH) and when the position is reached the motors stops. The "wake up home" (equivalent to unpark) restarts the tracking and the capability to slew.
I cannot find at present a command just stopping the tracking, without homing.

I re-implemented Goto function for Pulasr2 driver and introduced a 500ms delay. I'll leave the rest as an exercise to you since the code now is hopefully straight forward to you. You can re-implement Park()/UnPark() and even ReadScopeStatus()...etc in the LX200Puslar2 class.

Perfect, thank you again! It will certainly be much easier now to move on and test the other features. Your help was precious. You can now communicate that INDI supports (in beta version) one more mount, the Pulsar 2 driver (LX200 family).

Cheers
Paolo

Hello

I have resumed the development of the Pulsar 2 driver, and I find a source of possible conflicts.

Pulsar 2 has an internal clock and it also stores latitude and longitude of the observing site (note that it does not store a time zone). Its clock must be regulated on UTC, and advice is given that an external computer should also be synced to UTC.
If I don't follow that recommendation and I keep the PC on "local" time, I can disable in the INDI client the synchronization of time and location from the PC to the Pulsar (to avoid that Pulsar does not set its own time to local), but than the client PC clock won't have the same time. What are the consequences of that? Maybe none, but I am not 100% sure.
On the other hand if I follow the recommendation and put the PC time at UTC, I think that I cannot probably get the configuration of kstars right for my site/time-zone. By syncing to a star I can always point the telescope right, but all computations relying on altitude and hour angle (for instance, the position of the horizon) will be affected.

How would you solve this riddle?

Regards
Paolo

The INDI frameworks already sends the time in UTC so you can use that directly.

That's strange, then. When I switch on the Pulsar, it syncs by GPS to UTC. Then, when I connect it to kstars/ekos (in local time), the Pulsar clock switches to local time (as its displays jumps 2 hours later in my case)

If you're syncing to GPS, do not take KStars or INDI client time. Stick to one source. The LX200Pulsar in Subversion is not implementing updateTime(ln_date * utc, double utc_offset); function. It is implemented in LX200Generic but you should override it so you can decide exactly what to do with the time information. The LX200Generic just sets the local time in the controller.

GPS/time sync problem solved, thank you. But yesterday (in fact, after a svn update) my driver failed to load, with this log:

2016-05-30T20:34:35: startup: /usr/bin/indiserver -v -p 7626 -m 100 -f /tmp/indififo453e6ce3
2016-05-30T20:34:35: listening to port 7626 on fd 3
FIFO: start indi_lx200pulsar2 -n "Pulsar2"
With name:
FIFO: Starting driver indi_lx200pulsar2
2016-05-30T20:34:35: Driver indi_lx200pulsar2: pid=26709 rfd=4 wfd=7 efd=8
2016-05-30T20:34:35: Client 5: new arrival from 127.0.0.1:53888 - welcome!
2016-05-30T20:34:35: Driver indi_lx200pulsar2: initializing from pulsar2 device...
2016-05-30T20:34:35: Driver indi_lx200pulsar2: : symbol lookup error: undefined symbol: _ZN4INDI6Logger5printEPKcjRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiS2_z
2016-05-30T20:34:35: Driver indi_lx200pulsar2: stderr EOF
2016-05-30T20:34:35: Driver indi_lx200pulsar2: restart #1
2016-05-30T20:34:35: Driver indi_lx200pulsar2: pid=26711 rfd=4 wfd=8 efd=9
2016-05-30T20:34:35: Driver indi_lx200pulsar2: initializing from pulsar2 device...
(.... repeated 10 x...)

the update seems ok, followed by my "sudo make install" with my own pulsar 2 driver version...
Any clues?

Cheers
Paolo