×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Pulsar2 connection fails

  • Posts: 105
  • Thank you received: 23
Since I use my own development version, I have just checked that the driver from the repository also works with my setup. Slewing, parking, enabling/disabling PEC, pole crossing, refraction correction all work. Do you have a log file?
7 years 3 months ago #13774

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

  • Posts: 66
  • Thank you received: 2

Replied by Paolo on topic Pulsar2 connection fails

Hi Camiel

please find here below an excerpt of different communication attempts with mount. It is pretty strange that it does not work for me, while it works for you. Can you check if the firmware version is the same? (this should not matter much but who knows...).

I comment by blocks, for an easier interpretation.

So, first, connection:
DEBUG	58.127398 sec	: Testing telescope connection using ACK...
DEBUG	58.129876 sec	: Testing successful!
DEBUG	58.129933 sec	: Checking Pulsar version ...
SCOPE	58.129951 sec	: CMD <:YV#>
SCOPE	58.241288 sec	: RES <PULSAR V5.60a   ,2016.01.04.     > (1 attempts)
INFO	58.241354 sec	: 5.60a 2016.01.04
INFO	58.241364 sec	: Pulsar2 is online. Retrieving basic data...
DEBUG	58.241375 sec	: The mount is already tracking.
SCOPE	58.241653 sec	: CMD <#:GR#>
SCOPE	58.352025 sec	: RES <00:00:01> (1 attempts)
SCOPE	58.352065 sec	: CMD <#:GR#>
SCOPE	58.463023 sec	: RES <00:00:01> (1 attempts)
SCOPE	58.463081 sec	: VAL [0.000277778]
SCOPE	58.463090 sec	: CMD <#:GD#>
SCOPE	58.573946 sec	: RES <+00:00:00> (1 attempts)
SCOPE	58.574021 sec	: VAL [0]
SCOPE	58.574033 sec	: CMD <#:YGN#>
SCOPE	58.684952 sec	: RES <0> (1 attempts)
SCOPE	58.685016 sec	: VAL [0]
SCOPE	58.685042 sec	: CMD <#:YGP#>
SCOPE	58.795951 sec	: RES <0,0> (1 attempts)
SCOPE	58.796015 sec	: CMD <#:YGQ#>
SCOPE	58.906827 sec	: RES <1> (1 attempts)
SCOPE	58.906889 sec	: VAL [1]
SCOPE	58.906905 sec	: CMD <#:YGR#>
SCOPE	59.017800 sec	: RES <1,1> (1 attempts)
SCOPE	59.017907 sec	: CMD <#:Gt#>
SCOPE	59.128828 sec	: RES <+43?41:59> (1 attempts)
SCOPE	59.128876 sec	: VAL [+43:41]
SCOPE	59.128892 sec	: CMD <#:Gg#>
SCOPE	59.239824 sec	: RES <352?44:12> (1 attempts)
SCOPE	59.239886 sec	: VAL [+352:44]
SCOPE	59.239923 sec	: CMD <#:GL#>
SCOPE	59.351051 sec	: RES <13:35:32> (1 attempts)
SCOPE	59.351105 sec	: VAL [13:35:32]
SCOPE	59.351114 sec	: CMD <#:GC#>
...

note a few "?" in the displayed (or received) values.

Then, setting UT and coordinates both fail:
...
SCOPE	60.793681 sec	: CMD <#:GD#>
SCOPE	60.904585 sec	: RES <+00:00:00> (1 attempts)
SCOPE	60.904650 sec	: VAL [0]
DEBUG	60.904700 sec	: New JD is 2457769.000000
SCOPE	60.904715 sec	: CMD <#:SL 13:35:33#>
SCOPE	61.015565 sec	: RES <1>
SCOPE	61.015625 sec	: CMD <:SC 01/15/17#>
SCOPE	61.015649 sec	: RES <#>
ERROR	61.015661 sec	: Error setting UTC date.
SCOPE	61.015734 sec	: CMD <#:Sl 352:39#>
SCOPE	61.126824 sec	: RES <1>
SCOPE	61.126872 sec	: CMD <#:St 043:42#>
SCOPE	61.126893 sec	: RES <#>
ERROR	61.126903 sec	: Error setting site coordinates
SCOPE	61.905481 sec	: CMD <#:GR#>
SCOPE	62.014246 sec	: RES <1100:00:01> (1 attempts)
SCOPE	62.014317 sec	: VAL [1100]
SCOPE	62.014335 sec	: CMD <#:GD#>
SCOPE	62.126989 sec	: RES <+00:00:00> (1 attempts)
SCOPE	62.127053 sec	: VAL [0]
SCOPE	63.128142 sec	: CMD <#:GR#>
SCOPE	63.235202 sec	: RES <00:00:01> (1 attempts)
SCOPE	63.235288 sec	: VAL [0.000277778]
....

(It also fails to set site coordinates from the control panel)
By clicking in the panel with motion control buttons, I managed to move the mount south. This seems to be working ok:
SCOPE	106.076407 sec	: CMD <#:GD#>
SCOPE	106.185024 sec	: RES <00:00:01> (1 attempts)
SCOPE	106.185100 sec	: VAL [0.000277778]
SCOPE	106.972137 sec	: CMD <#:Ms#>
INFO	106.972214 sec	: Moving toward South.
SCOPE	107.185376 sec	: CMD <#:GR#>
SCOPE	107.185470 sec	: RES <+00:00:00> (1 attempts)
SCOPE	107.185508 sec	: VAL [0]
SCOPE	107.185524 sec	: CMD <#:GD#>
SCOPE	107.294600 sec	: RES <00:00:01> (1 attempts)
SCOPE	107.294676 sec	: VAL [0.000277778]
SCOPE	108.295727 sec	: CMD <#:GR#>
SCOPE	108.295823 sec	: RES <-00:00:03> (1 attempts)
SCOPE	108.295862 sec	: VAL [-0.000833333]
SCOPE	108.295879 sec	: CMD <#:GD#>
SCOPE	108.404508 sec	: RES <00:00:01> (1 attempts)
SCOPE	108.404577 sec	: VAL [0.000277778]
SCOPE	109.405662 sec	: CMD <#:GR#>
SCOPE	109.405772 sec	: RES <-00:05:24> (1 attempts)
SCOPE	109.405837 sec	: VAL [-0.09]
SCOPE	109.405858 sec	: CMD <#:GD#>
SCOPE	109.514373 sec	: RES <00:00:01> (1 attempts)
SCOPE	109.514454 sec	: VAL [0.000277778]
SCOPE	110.383090 sec	: CMD <#:Qs#>
INFO	110.383151 sec	: Movement toward South halted.
SCOPE	110.514648 sec	: CMD <#:GR#>
SCOPE	110.514744 sec	: RES <-00:19:25> (1 attempts)
SCOPE	110.514782 sec	: VAL [-0.323611]
SCOPE	110.514792 sec	: CMD <#:GD#>
SCOPE	110.624111 sec	: RES <00:00:01> (1 attempts)
SCOPE	110.624173 sec	: VAL [0.000277778]

...note the here the "?" have disappeared.
Then, I try a couple of times to sync coordinates to another value. It does not work (a single attempt shown here):
...
SCOPE	141.590384 sec	: CMD <#:GD#>
SCOPE	141.698906 sec	: RES <00:00:01> (1 attempts)
SCOPE	141.698966 sec	: VAL [0.000277778]
SCOPE	142.205177 sec	: CMD <#:Sr 21:54:56#>
SCOPE	142.205235 sec	: RES <->
SCOPE	142.699509 sec	: CMD <#:GR#>
SCOPE	142.699604 sec	: RES <00:38:57> (1 attempts)
SCOPE	142.699642 sec	: VAL [0.649167]
SCOPE	142.699652 sec	: CMD <#:GD#>
SCOPE	142.699668 sec	: RES <1> (1 attempts)
SCOPE	142.699680 sec	: VAL [1]
SCOPE	143.700748 sec	: CMD <#:GR#>
SCOPE	143.700827 sec	: RES <00:00:01> (1 attempts)
SCOPE	143.700852 sec	: VAL [0.000277778]
SCOPE	143.700857 sec	: CMD <#:GD#>
...
Attempt to set side of pier, pole crossing, PEC off. When testing, I had the impression that this did not work, but here I see that it should be ok (RES 0 received). So maybe I'm wrong but I had the impression that the light on the control panel did not turn green. Anyway, I see that there is a :Q command in the middle (slew stop?) I don't know if it's normal:
...
SCOPE	154.716609 sec	: RES <-00:38:57> (1 attempts)
SCOPE	154.716629 sec	: VAL [-0.649167]
SCOPE	154.796307 sec	: CMD <#:YSN0#>
SCOPE	154.905513 sec	: RES <0>
SCOPE	155.717487 sec	: CMD <#:GR#>
SCOPE	155.717593 sec	: RES <0:00:01> (1 attempts)
SCOPE	155.717654 sec	: VAL [0.000277778]
SCOPE	155.717673 sec	: CMD <#:GD#>
SCOPE	155.717722 sec	: RES <-00:38:57> (1 attempts)
SCOPE	155.717750 sec	: VAL [-0.649167]
SCOPE	156.718819 sec	: CMD <#:GR#>
SCOPE	156.718927 sec	: RES <100:00:01> (1 attempts)
SCOPE	156.718972 sec	: VAL [100]
SCOPE	156.718990 sec	: CMD <#:GD#>
SCOPE	156.719038 sec	: RES <-00:38:57> (1 attempts)
SCOPE	156.719067 sec	: VAL [-0.649167]
SCOPE	157.231323 sec	: CMD <#:Q#>
SCOPE	157.719648 sec	: CMD <#:GR#>
SCOPE	157.719733 sec	: RES <00:00:01> (1 attempts)
SCOPE	157.719762 sec	: VAL [0.000277778]
SCOPE	157.719770 sec	: CMD <#:GD#>
SCOPE	157.719806 sec	: RES <-00:38:57> (1 attempts)
SCOPE	157.719823 sec	: VAL [-0.649167]
SCOPE	158.720876 sec	: CMD <#:GR#>
SCOPE	158.720970 sec	: RES <00:00:01> (1 attempts)
SCOPE	158.721008 sec	: VAL [0.000277778]
SCOPE	158.721017 sec	: CMD <#:GD#>
SCOPE	158.721064 sec	: RES <-00:38:57> (1 attempts)
SCOPE	158.721083 sec	: VAL [-0.649167]
SCOPE	159.722149 sec	: CMD <#:GR#>
SCOPE	159.722250 sec	: RES <00:00:01> (1 attempts)
SCOPE	159.724295 sec	: VAL [0.000277778]
SCOPE	159.724325 sec	: CMD <#:GD#>
SCOPE	159.724382 sec	: RES <-00:38:57> (1 attempts)
SCOPE	159.724412 sec	: VAL [-0.649167]
SCOPE	160.725482 sec	: CMD <#:GR#>
SCOPE	160.725584 sec	: RES <00:00:01> (1 attempts)
SCOPE	160.725626 sec	: VAL [0.000277778]
SCOPE	160.725644 sec	: CMD <#:GD#>
SCOPE	160.725693 sec	: RES <-00:38:57> (1 attempts)
SCOPE	160.725722 sec	: VAL [-0.649167]
SCOPE	161.180398 sec	: CMD <#:YSP0,0#>
SCOPE	161.180487 sec	: RES <0>
SCOPE	161.726331 sec	: CMD <#:GR#>
...

That's all.... I hope that the above tells you something meaningful, for a quick and easy correction.

Best regards
Paolo
7 years 2 months ago #13837

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

  • Posts: 105
  • Thank you received: 23
Hi Paolo,

My Pulsar is the original one not the Pulsar2. The LX200 commands supported should be the same except for the pulse guiding commands that Pulsar2 supports.

What is shown in the lines containing RES is the literal response from the Pulsar. The ? character corresponds to the degree character. That this character changes later on is the way it is implemented in the Pulsar. Anyways this character is ignored when parsing R.A. and Decl. values.

From the remaining parts of the logs I get the impression that some commands are not responding in the same way as with my old Pulsar. E.g., setting the time works fine but while setting the date the response is RES<#> which seems to be the closing '#' of the previous command. My Pulsar doesn't send this character. To test this I'll modify the driver so that it will ignore these extra characters.

Let me know whether that solves your problems.

Regards,
Camiel
7 years 2 months ago #13838

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

  • Posts: 66
  • Thank you received: 2

Replied by Paolo on topic Pulsar2 connection fails

Hi Camiel

thank you, that's very helpful! I'm not at all a technical programmer (I program more for science work and numerical analysis) so I'm quickly lost with the drivers.

It might well be that some spurious characters are appearing in the answers, and the fact that we are on different versions of the hardware could explain the problem.

Paolo
7 years 2 months ago #13842

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

  • Posts: 66
  • Thank you received: 2

Replied by Paolo on topic Pulsar2 connection fails

see also private message with some reserved documents...
7 years 2 months ago #13844

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

  • Posts: 66
  • Thank you received: 2

Replied by Paolo on topic Pulsar2 connection fails

To say the truth, I did not use much filtering for my first driver version.
So the situation is:
- we had a Pulsar 2 driver which was working, but not implementing all options
- we now have a full Pulsar 1 driver (incorrectly called Pulsar 2), implementing most useful features, but not working with Pulsar 2

I see only two options:
- recover the previous driver for Pulsar 2 and keep the present one, renamed Pulsar 1 (but it seems not optimal to duplicate them)
- have a single driver, but recover somewhat the old behavior if the detected device is Pulsar 2

How to proceed? Camiel, can you explain why the driver should now communicate differently with respect to the original ?
7 years 2 months ago #13944

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

  • Posts: 105
  • Thank you received: 23
Hi Paolo,

Did you try the modification?
The reason for the changes is that I kept having problems with the communicatoin between my PC and the Pulsar module. The driver is working fine for my setup now which it wasn't in the past. From the documentation (unless it is out of date) and from the ASCOM driver code, I make up that it should work for both Pulsar vesions. Reverting to the previous version is fine with me.

Regards,
Camiel
7 years 2 months ago #13948

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

  • Posts: 66
  • Thank you received: 2

Replied by Paolo on topic Pulsar2 connection fails

Oh sorry there was it seems another modification? I did not check. Probably I missed it. I update by ppa and test tonight.
Thank you!
Paolo
7 years 2 months ago #13954

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

  • Posts: 66
  • Thank you received: 2

Replied by Paolo on topic Pulsar2 connection fails

Camiel

I don't know what you modified, but the effect is now very positive!!!!! I made just a short test as it is totally cloudy, but the driver seems now to behave correctly, and communicate with the Pulsar with nearly no glitches.
Did you introduce delays?

I just found a small issue when slewing and at least once (over 3-4 attempts) the slew failed. I found in the log that nearly always the RES to the slew command is not valid at the first attempt. See below. Probably a small detail to tune.
Thank you so much for the good job and the support!

Paolo
SCOPE	177.343233 sec	: CMD <#:GR#>
SCOPE	177.451890 sec	: RES <00:00:00> (1 attempts)
SCOPE	177.451947 sec	: VAL [0]
SCOPE	177.451954 sec	: CMD <#:GD#>
SCOPE	177.562886 sec	: RES <+00:29:59> (1 attempts)
SCOPE	177.562936 sec	: VAL [0.499722]
SCOPE	177.562972 sec	: CMD <#:Sr 00:00:00#>
SCOPE	177.673865 sec	: RES <1> (attempt 0)
SCOPE	177.673926 sec	: CMD <#:Sd -01:00:00#>
SCOPE	177.673952 sec	: RES <#> (attempt 0)
SCOPE	177.784853 sec	: RES <1> (attempt 1)
SCOPE	177.784913 sec	: CMD <#:MS#>
SCOPE	178.456254 sec	: RES <0> (2 attempts)
INFO	178.456317 sec	: Slewing to RA:  0:00:00 - DEC: -1:00:00
SCOPE	178.563086 sec	: CMD <#:YGi#>
SCOPE	178.895871 sec	: RES <1> (1 attempts)
SCOPE	178.895933 sec	: VAL [1]
SCOPE	178.895946 sec	: CMD <#:GR#>
SCOPE	179.005681 sec	: RES <23:59:59> (1 attempts)
SCOPE	179.005758 sec	: VAL [23.9997]
SCOPE	179.005775 sec	: CMD <#:GD#>
SCOPE	179.116608 sec	: RES <+00:29:47> (1 attempts)
SCOPE	179.116666 sec	: VAL [0.496389]
 
7 years 2 months ago #13995

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

  • Posts: 105
  • Thank you received: 23
Hi Paolo,

Good that its working again. I think that I read a comment about the :MS# command. I'll have a look at that.
There is one problem that remains to be solved: I have noticed that at some occasions (typically once in an hour but very irregularly) time out errors occur while the driver is reading the RA/DEC coordinates. Since there were some remarks in the ASCOM code about this I wander whether you see this problem too? If so the fix is (for the time being) to disconnect and reconnect the driver. It would be useful if you could provide a log file too.

Regards,
Camiel
7 years 2 months ago #14006

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

  • Posts: 105
  • Thank you received: 23
I checked the Pulsar documentation on the ":MS#" command: it is supposed to return 0 on success and 1 on failure. So, the slew should have been started according to the logging output. Did it?
The info on the number of attempts is maybe confusing you too. Once I get the time out problem solved, I'll clean up the code so that it silently ignores extra '#' characters in the response strings send by the Pulsar.
7 years 2 months ago #14007

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

  • Posts: 105
  • Thank you received: 23
I've finally found a reliable solution to the time out problems I was having with the Pulsar controller. Investigation of the input and output streams to the controller showed that the Pulsar is sometimes late by several seconds sending a response to a command. The delay varies in size so that simply flushing the input stream does not always work: in many cases it flushes nothing or only the first part of the delayed response. The remaining delayed response is than ready as the response of the following command send to the Pulsar. Thus commands and responses become out of sync.

In order to establish reliable communication with the Pulsar after a time out, one must resynchronize the commands and responses. This can be done by sending ACK characters until two subsequent positive responses to the ACK are received. In that way we can be sure that after the next command we can read the response to that command.

I've updated the lx200pulsar2 driver in the repository with this fix. Give it a try and let me know whether it works on the Pulsar2.
The following user(s) said Thank You: Jasem Mutlaq, Paolo
7 years 2 months ago #14152

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

Time to create page: 1.092 seconds