Tarun thanked Jean-Luc in topic Skywatcher protocol 1 year ago

Jean-Luc replied to the topic 'Internal Guider not calibrating' in the forum. 1 year ago

Don't use backlash, I made that for a home made mount hardware, I will disable it. The calibration process takes care of that.
Select the ASI120 in the menu to use its ST4 port.
And try again using the default settings. That should work, I use the same setup ;-)
Anyway your last log file was almost empty.

Read More...

Jean-Luc replied to the topic 'Internal Guider not calibrating' in the forum. 1 year ago

I think you did not select your ASI120MM as guiding interface, but EQMod Mount. If you use a ST4 cable between your ASI and the mount, guiding commands should be sent to the ASI camera, so select your camera as guiding interface in Ekos. I don't have it under the hand so can't precisely say how, but this is set in your Ekos profile before starting.

Read More...

Jean-Luc replied to the topic 'Internal Guider not calibrating' in the forum. 1 year ago

Hi,
I looked at the log and considered a guide pulse (line 38858) 1000ms@0,5x):
- it starts at 22:20:50:556, and the actual track speed modification occurs at 22:20:50:656. There is a 47ms delay between the two first log messages, 0ms between all the others, but the last, with a 53ms delay which may be due to the real serial comm occuring here.
- the end of the pulse occurs at 22:20:51:715 (line 38897) after the end of a mount probe started at 22:20:51:372, The actual speed modification occurs at 22:20:51:832.
I have thought serial comm could be the problem but in the first part, a ':f1' serial command gets its response in the same millisecond, but the same command in the second part took 50ms. I believe the timestamps in log messages are added by the indi framework and thus we see when they have been processed, not when they have been queued. Furthermore the indi-eqmod driver uses the timer callback mechanism of the indi framework too, that explains why they may be delayed by the normal mount probe processing. I think we have to look at the eventloop of the indi framework as the timer callbacks are managed with select timeouts. Anyway a first idea would be to delay the ReadscopeStatus callback while pulse guiding.
Now none of this happens when you use ST4 guiding, you could do that with your ASI120MM and your AZ-EQ5.
Jean-Luc.

Read More...

Jean-Luc replied to the topic 'Re:trouble with eqmod mount disconnecting' in the forum. 1 year ago

Ok, let's see if that resolves the issue. I think that the controllers would have time to reboot/reset during the retries. I wonder how will the driver behave after a motor controller reset and if this could be useful to make it recover from that situation.

Read More...

Jean-Luc replied to the topic 'Re:trouble with eqmod mount disconnecting' in the forum. 1 year ago

Hi,
I'm not sure that performing retries after a disconnection is a good idea. I did not look at the driver update but having a clear disconnection in Indi is a good thing (thanks Jasem). Now I believe that the reconnection should be manual. The logs before the disconnection are not very helpful, from the driver point of view this happens in the kernel space (tty_read, tty_write). The reason may be either between the computer and the serial adapter (usb/bluetootth), between the adapter and the mount motor controllers, or in the motor controllers if there is a power glitch and they reboot. I believe that in the first case the kernel will reassign a device at the reconnection (from ttyUSB0 to ttyUSB1 for instance), in the second case there will be either read/write faliures or bad characters, and in the latter case, there will only be write failures or maybe a read timeout while the controllers are rebooting. The problem in the latter case if you automatically reconnect, is that the driver will think that the mount is uninitialized, and it will consider that it points to the Celestial Pole. The next goto may be risky in that case...
So it may be a good idea to make automatic reconnection optional, so you may disable it if you are in an automated sequence for instance. Also people reporting disconnections may try to investigate by looking the status after the disconnection: do motor controllers have rebooted? where is the serial adapter ? maybe try to speak directly with the mount using picocom to test the connectivity.
Lastly I'm thinking that power issues may eventually come from the mount capacitors, if you think that your power connection is correct. But I'm not an expert here.
Jean-Luc.

Read More...

Alan Mason thanked Jean-Luc in topic EQMOD questions 1 year ago

Jean-Luc replied to the topic 'Re:trouble with eqmod mount disconnecting' in the forum. 1 year ago

Ok, I understand what you mean now, Concerning the indi-eqmod crash, did you use alignment ? A sequence of capture/solve/sync on the same target as ekos does may cause an issue in some circumstances. Besides I've seen in a preceding post that you leave your mount parked and powered a day long: be warned that parking the mount does not stop motor powering, there is no (direct) way to disable the driver ICs but using the power switch.

Read More...

Jean-Luc replied to the topic 'Re:trouble with eqmod mount disconnecting' in the forum. 1 year ago

TallFurryMan wrote: Thanks. My setup has been running for three weeks without power interruption. During these two weeks, there have been three indiserver crashes induced by indi_eqmod_telescope, always while slewing or tracking. None of these crashes had the disconnection messages. All crashes did damage the functioning of the camera driver, which was used during the tests. The focuser and guider drivers were connected but not actively used, and never suffered from the driver crash (except that they died along).

Hi,
Can you be more precise in what has happened?
Writing that a process (indi_eqmod_telescope) may damage the functioning of another process (the camera driver) is somewhat surprising.
Hopefully it did not kill the camera itself!
Jean-Luc.

Read More...

Jean-Luc replied to the topic 'Using PyIndi client with a simple GUI' in the forum. 1 year ago

Lagreeni wrote: Hi,

I imported the IndiClient class from the script to my GUI and am trying to call newProperty, but I hit an issue with the arguments. I don't know how to call the functions ie: newProperty(self, p) because of the "p", property, parameter. I'm not very well versed with Python, so I imagine I'm missing something very obvious, but its doing a dang good job of eluding me. I'm not even sure if just calling the function newProperty or even nd18 would work.

Hi,
You don't have to call newproperty yourself, the IndiClient runs in its own thread and will call that function for every new property. You just have to define that function.
In your case, if every other aspects are managed from another client, you just need to remember the property and reuse it in your function:
class IndiClient(PyIndi.BaseClient):
    def __init__(self):
        super(IndiClient, self).__init__()
        self.dwheel = None
   def newDevice(self, d):
        pass #connecting the filter wheel via a basic client
   def newProperty(self, p):
        if p.getName() == "FILTER_SLOT":
             self.dwheel = p
    # you shoul define all other virtual functions and I would suggest also
    def removeProperty(self, p):
        if p.getName() == "FILTER_SLOT":
             self.dwheel = None

    def nd18(self):
        if self.dwheel:
            slot=self.dwheel.getNumber("FILTER_SLOT")
            slot[0].value=1
            self.sendNewNumber(slot)
I did not test but here is the idea.

tltr: How do you connect a GUI to a PyIndi client? Can you call one of the PyIndi functions such as newProperty(self, p) and if so, how?

As the Indiclient has its own thread, calling indi client from the gui should be ok, but calling the gui from the client (refreshing a value for instance) won't work without some sort of synchronization (queue, or use a Qthread for the indi client if you're in Qt).
Jean-Luc.

Read More...