×

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

Bi-monthly release with minor bug fixes and improvements

EQMod snoop "Site Management" from a GPS Driver

Besson, I meant that the GPS driver should use the same properties used currently for TIME_UTC and GEOGRAPHIC_COORD. They shall be read only. Another critical part is the GPS driver must also be able to update the system time of the device it is running on, otherwise, it is not very useful.
8 years 7 months ago #4808

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

  • Posts: 72
  • Thank you received: 21
Dear Jasem.
I fully agree, and I've to move my code is this way, to remove conversion from the Telescope for Time and Coord.First I should myke changes in my personnal driver. From that point I've few questions for communition inter drivers process.
The snoop function send the content of the vectors. If I want to display coord. in Sexagesimal format, and send it in degree how to proceed? Idem for time if I display two eay readable field one for time and one for date.
Could we hide a vector to not display it in any tabs and then work with these? Or Is there some functions to create the XML message and send to snoop to other device without using local vectors?
As the Time is update on the EQMod this way seems already good but what about INDI:TELESCOPE? and I appreciate personnaly a lot to be able to update KStars with this time setting, and I hope someone will find why the coord location doesn't do it!
Regards
Philippe Besson
Skywatcher HEQ5, Televue 101-IS, Takahashi FS-60CB
Focus Boss II with OptecInc TCF-S focuser and Starlight Instruments HSM20 handy stepper motor
Guiding camera ZWO ASI120MM
Filterwheel OptecInc IFW
Camera not set yet
Switzerland
8 years 7 months ago #4812

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

Ok, so here are some updates:

1. KStars now correctly update both time and location. There was an issue updating location which is now fixed. Next kstars-bleeding update should fix all these issues.
2. I created INDI::GPS which is the parent class for simple GPS devices. It's a very simple class with only 3 properties, GEOGRAPHIC_COORD, TIME_UTC, and GPS_REFRESH. A sample implementation is "GPS Simulator" which is now available under auxiliary drivers.
3. INDI::Telescope was updated to snoop on GEOGRAPHIC_COORD and TIME_UTC and call regular functions to update time and location values. There is no need at all to change any telescope driver code as the changes are handled on the INDI::Telescope side.

So Besson, please take a look the INDI::GPS class and "GPS Simulator" and see if you can adapt your driver to use that. It should be fairly straight forward. And no, we can't hide any vectors, everything that is sent gets displayed. For now, the "GPS Simulator" driver updates both the Telescope and KStars, so it shouldn't pose any issues. Please test and let me know if there are any issues I might have overlooked.
The following user(s) said Thank You: Radek Kaczorek, Philippe
8 years 7 months ago #4815

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

  • Posts: 983
  • Thank you received: 375
This is very good news! I'm going to look at it this week. These would resolve my issues with astroberry gps driver and utc time snooping.
I will post an update as soon as I reengineer the code to include the latest changes.
8 years 7 months ago #4824

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

  • Posts: 983
  • Thank you received: 375
As to share some experience... I spend some time on analysis of available options for getting time and location on Raspberry Pi from various gps modules and my final conclusions found their ways to astroberry gps driver architecture. It relies on two interconnected services: gpsd (for standardized gps data handling and device sharing) and ntpd (for system time synchronization with available network servers AND gps through memory shared with gpsd). Thanks to such an approach all gps data are handled by system wide service, the same for time. This would be good idea to stick to this to avoid any conflicts while accessing gps serial interface.
8 years 7 months ago #4844

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

  • Posts: 72
  • Thank you received: 21
INDI::GPS Works fine, and it quite easy to use.
The last remark from Kaczorek relative to GPS time or/and Network time is quite interresting.
Another point I've to involve about the implementation of snoop in INDI::Telescope. Maybe it would be good to add a check before update date received in the XML message. In my point of view the "state" value of the vector should be check to have "ok" on it. If not processLocationInfo nor processTimeInfo should be call as invalid data!

We could imaging to use different states for different information like:
- ok = Time and Localisation good
- busy = Only time is valid
- alert = Nothing valid
- idle = Don't know
but I agree this not the original meaning of the color! and could make some confusion!
That would give more control on GPS side to update telescope data (and KStars) only with valide values.

@Jasem: Did you never thing to extend the nombre of condition to 7 and use Rainbow colors, with some IPS_EXTRA1..3 to be more flexible (I've already thougt about it for my box controler).

Regards
Philippe Besson
Skywatcher HEQ5, Televue 101-IS, Takahashi FS-60CB
Focus Boss II with OptecInc TCF-S focuser and Starlight Instruments HSM20 handy stepper motor
Guiding camera ZWO ASI120MM
Filterwheel OptecInc IFW
Camera not set yet
Switzerland
8 years 7 months ago #4849

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

I think to keep it simple is better. So the GPS driver either sends time and/or location if they are correct, or sends NOTHING. If time is valid, send time only. If location is valid, send location only, if both are valid, send both. If none, don't send anything. This way it is simpler and there are no extra semantics. Also, IPSState cannot be extended because INDI library must conform to the INDI wire protocol v1.7
8 years 7 months ago #4852

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

  • Posts: 72
  • Thank you received: 21
Dear Jasem.

Thanks for you clear answer.
I've gone on in the changes done on INDI::Telescope related to the GSPSimulation, and found my mistake. In fact I've an unappropriate use of the IDSetText() and IDSetNumber(). It should be better now.
- Could you confirm this is not possible to refresh the Text or Number values displayed on the INDI interface without sending a snoop message the registred device?
- Is a snoop message is sent to the registred device when DefineNumber() or defineText() are calling by UpdateProperrties() ? It seems yes.

Regards
Philippe
Philippe Besson
Skywatcher HEQ5, Televue 101-IS, Takahashi FS-60CB
Focus Boss II with OptecInc TCF-S focuser and Starlight Instruments HSM20 handy stepper motor
Guiding camera ZWO ASI120MM
Filterwheel OptecInc IFW
Camera not set yet
Switzerland
8 years 7 months ago #4853

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

1. Yes, once the message leaves the driver, it goes to all clients & snooping drivers.
2. Yes, if the device is already snooping then it would receive it (in our case Telescope will receive it).

I added a condition in INDI::Telescope so that it would only accept the time and location properties if their state is IPS_OK only. So even in defineNumber().. it would only accept it if it was OK.
The following user(s) said Thank You: Philippe
8 years 7 months ago #4854

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

  • Posts: 117
  • Thank you received: 5
I am also going to integrate a GPS module in my setup, and I am surprised to see discussions about writing drivers.

After reading some doc of the gps module, I saw that the pps signal is disconnected when one reads position data. I would read some time position data just for averaging the noise on the position information. Once position is stable, and because I am not moving my setup, I do not need to measure the position anymore. I would at that moment switch to timing, so that the pps signal is again active.

For timing I would integrate the gps in a dedicated RPi, configured as stratum 1 ntp server. Via the OS and the ntp protocol, the clock of my machines on the network are synchronised, and also ekos and kstars will see and use this correct time or not?

As such my only problem is to read the position in Ekos. I was hoping to use the arduino integration for this.

May I have your views on this way of working?
7 years 7 months ago #9696

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

  • Posts: 983
  • Thank you received: 375
All you're talking about is right and feasible. I'm using such a setup on my Raspberry Pi.
You need GPSD server that's reading your PPS ready GPS receiver and NTPD server that integrates to GPSD over shared memory and can handle PPS signal. Beware that binary NTPD distributed with you system updates might not support handling PPS signal (this is the case for ubuntu). In such a case you need to compile NTPD from sources.
To keep it very short and simple:
1. Install GPSD and make it autorun on system boot
2. Install NTPD a configure it to read time and PPS signal from GPSD via shared memory
3. Configure GPIO pin in /boot/configure.txt for PPS signal handling by kernel interrupt

WIth such a setup I use GPS as a reliable time source with nanoseconds level precision.
The following user(s) said Thank You: Stefan Nonneman
7 years 7 months ago #9717

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

  • Posts: 117
  • Thank you received: 5
Thanks a lot for the info. Are you also reading GPS position information for updating the Geo-settings in KStars? I am a bit worried about the fact that positioning and timing use different settings of the GPS module and it seems that the positioning setup disables the PPS signal. As I already mentioned, during the observations the position does not change, and the GPS module can be put directly in timingmode.

You wrote that you are doing this on a Raspberry Pi! Not on a Pi 2 and without Arduino???
Regards,
Stefan
Last edit: 7 years 7 months ago by Stefan Nonneman.
7 years 7 months ago #9720

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

Time to create page: 1.050 seconds