Tarun thanked Jean-Luc in topic Skywatcher protocol 3 months ago
Jean-Luc replied to the topic 'Internal Guider not calibrating' in the forum. 7 months 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. 7 months 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...

Helge thanked Jean-Luc in topic Internal Guider not calibrating 7 months ago
Jean-Luc replied to the topic 'Internal Guider not calibrating' in the forum. 7 months 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. 8 months 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. 8 months 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 8 months ago
Jean-Luc replied to the topic 'Re:trouble with eqmod mount disconnecting' in the forum. 8 months 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. 8 months 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. 8 months 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...
Jean-Luc replied to the topic 'Eqmod: prevent meridian flip when triggering a goto' in the forum. 9 months ago

Hi Klaus,

That would be nice, moreover you may add what you really need.
Furthermore I was trying to sync my fork repo yesterday, but was unable to push back on github my local merges, it seems there are large packets (no sync since 3 months) that curl does not handle correctly. Will have to make a new fork I think.
Anyway, Thanks for your help.
Jean-Luc.

Read More...

Jean-Luc replied to the topic 'Eqmod: prevent meridian flip when triggering a goto' in the forum. 9 months ago

Hi,
Not much to say, a switch property may be added easily to drive forcecwup. There are also two numbers limiting the amplitude.
I don't remember how I tested that part of the code some years ago, I'll have a look in the next weeks.
Unless you have already made a try and can confirm that's ok.

Jean-Luc.

Read More...

Jean-Luc replied to the topic 'EQMOD questions' in the forum. 9 months ago

Ihoujin wrote: I have never seen PEC training in INDI EQMOD either. I just assumed it was either never implemented or wasn't possible. It certainly would be nice if I could do that, and maybe use PecPrep with it.
My HEQ5 Pro should support it.


PEC/PEC training is enabled in INDI EQMod for mounts which supports it, EQ8, AZEQ5/6, EQ6R too apparently. It is a motor controller firmware feature, the INDI driver just sends the corresponding commands to start/stop PEC/PEC training and don't then bother about it. It makes me think that this firmware PEC+guiding may not be a good idea as the firmware changes the motor speed unconditionnally, so some guide commands may be lost. There may have been some discussions already here.

Read More...
Jean-Luc replied to the topic 'EQMOD questions' in the forum. 9 months ago

Hi,

ElevatedG wrote: I'm fairly new to AP and INDI as well with just a few questions...

How does PEC training in EQMOD work? I've tried to enable training but without any result. Also, will it help smooth out guiding? Guiding error is averaging 0.5" per night.

PEC training works the same way as with the handcontroller. Guide on a star, engage PEC training and the firmware will wait for the mount pass the worm indexer and then records the resulting speeds in the EEPROM of the motor microcontroller. When it has finished (worm indexer) it toggles a status bit and you can see in the INDI Control panel the status of PEC training becoming green (whereas it remains busy/yellow while training). I've never tried myself however.

Also, is there a how-to for setting horizon limits correctly?

I'm using the Sky-Watcher EQ6-R Pro mount

Thanks for the help guys!
Alan

For horizon limit just slew to the points along the horizon you want to set and hit the Add current button. The order of points is significant as Horizon uses a linear approximation between them. When you have finished hit the Write File button (saved in ~/.indi/HorizonData.txt which you can manually edit also).

Jean-Luc.

Read More...

Login

3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!