Jean-Luc replied to the topic 'Meridian flip still working for people?' in the forum. 1 month ago

Hi,

mlarsson wrote: Hi!

I'm not sure whether I am connecting to the topic or not - I have a Losmandy G-11, so no EQMOD here. But I have problems with meridian flip.

My situation: I've set the safety limit to 5 degrees past the meridian. According to the people who know more about this mount than me, issuing a Goto within 2.5 degrees of the safety limit should cause the mount to flip. According to my manual tests - using the handcontrol, not Ekos - this seems to be correct.

Now I tested this by tracking a star across the meridian, with 60 sec exposures. I've set the HA to 0.2, so as to make it happen within the zone of between 2.5 and 5 degrees past the meridian. It tracks, approaches the limits, and then, at 185 degrees, it seems to issue a meridian flip command - according to the capture model. However, I cannot see anything in the Indi panel for the mount. Issuing a manual Goto (with the Handcontrol, not Ekos) to the star it is already pointing to, initiates a Meridian flip.

It seems to me that no Goto command was issued - or what is happening here? Log files attached - Kstars log, mount log, and CCD log.

Magnus

Looking at the log, it seems the goto command is performed as expected.
Now reading a document I've found here on pages 33 and 69, it seems the default goto limit is 122 degrees from east, and that you have to set it manually for goto commands perform a meridian flip. If I've understood there are some extensions to perform meridian flip in the gemini protocol, that the hand controller should use. For programs using only lx200 command set, you have to change this goto limit to 95 degrees if you want any goto commands perform a flip if target is 5 degrees past the meridian. I don't have such a mount so I can't help more, but you may start to look in that direction.

@Jasem
I wonder if you may not simply disable alignment during imaging in Ekos, so you would get the true coordinates. After all alignment is mainly used for goto accuracy.

Read More...

Jean-Luc replied to the topic 'Meridian flip still working for people?' in the forum. 1 month ago

knro wrote: I just finished the live testing for merdian flip and it worked fine using the Nearest Point align mode. WIth N-Star there were a few issues, not with the flip itself, but with post-flip realignment process.

I think that meridian flip should be initiated using true telescope coordinates, or alignment could be disabled when performing the flip.
In any case I would suggest you use more alignment points, the nearest model is quite simplistic.


How would clients know about true telescope coordinates? From Ekos, I just monitor HA and issue GOTO to the same place once HA threshold is exceeded.

indi-eqmod exposes true telescope coordinates in the align tab, and maybe every mount should expose them. Ekos monitors HA using aligned coordinates, and as said above, initiates the flip when HA is 0.06 above meridian. In the log the alignment process (be it Nearest or Nstar) reports a 0.08 difference in RA, thus the goto won't perform a flip. This is a feature, not a bug. Actually you may now use the Pier Side property as defined by Patrick (which uses true coordinates in the driver directly) to initiate the flip: there you will be sure the mount would perform a flip.
The other point was tthe number of sync points: using only one sync point is not very useful. And if you make your sync near the pole, a small error here is multipled by the inverse of the sinus of the declination. I wonder if this is not why some people get scope outside limts error sometimes.

Read More...

Jean-Luc replied to the topic 'Meridian flip still working for people?' in the forum. 1 month ago

Hi,
Concerning the log you gave above, all what I can say is:

  • you made a single point alignment, I suppose when you start your session, maybe 1h30 from the meridian, or near the pole, or else you check the Align Nearest mode
  • anyway, the delta_ra is 0.08, the meridian flip occurs at 0.06, so I think the goto, after alignment, does not perform a flip
I think that meridian flip should be initiated using true telescope coordinates, or alignment could be disabled when performing the flip.
In any case I would suggest you use more alignment points, the nearest model is quite simplistic.

Jean-Luc.

Read More...

Jean-Luc replied to the topic 'Skywatcher protocol' in the forum. 1 month ago

fm wrote: Ok, all this makes sense.

In the skywatcher code, what are Breaks, TargetBreaks BreaksIncrement and so on meant to achieve ? Are they somehow here to manage acceleration on motion start and deceleration on motion stop ? The current mcmt32 firmware has builtin acceleration/deceleration ramps, so my feelling is I could just ignore breaks. Am I right ?


Yes, this is used to specify the start of the deceleration, the deceleration itself is managed in the firmware. I use a constant value (these are microsteps, relative or absolute) so you may just ignore them.

(mcmt32 is not my design, its a collaborative project, but key people in the project are windows inclined. All I did was making some housework in the firmware and
trying to write an indi driver for it ; but finally I think it makes more sense to take advantage of the larger community of eqmod and try to convert the firmware to an eqmod-compatible one).


Great idea, this will allow you to remote control your mount with a raspberry afterward.

Read More...

Jean-Luc replied to the topic 'Skywatcher protocol' in the forum. 1 month ago

The skywatcher motor controller uses a hardware timer to generate interrupts, and the interrupt service routine simply decrements a running period counter. When this counter reaches zero, the isr generates the next step (i.e. sets PWMA, PWMB, phase A and Phase B pins which have been computed in the main loop outside the isr) and resets the running counter to the desired period (and also sets a flag for the main loop computes the next PWMs/Phases). The controller itself runs at 20Mhz but this only impacts how the timer period registers are configured.
Well, I've quickly looked at your firmware and the PIC32 datasheet, your approach is to program the 4-5 timer with the microstep period for the current desired speed. I've made the same thing with my so called geehalel mount. Now if you use 0.0125µsec for the Interrupt Timer Freq this will be 80000000=0x4C4B400 and that does not fit into a 24 bit number (a limit in the skywatcher protocol). So simply use a constant which at least corresponds to the max sustainable speed (1000x gives 0x4C4B400/0x381=0x15C62=89186), knowing that higher it is, finer will be the resolution in speed (you may also use 0xFFFFFF). You would only have to multiply the received periods by that constant to retrieve your 4-5 timer period.
If you don't use full step, I think setting highspeed ratio to 1 should be ok. The indi driver sets high speed mode if the desired speed is over 128x and thus multiplies the desired period by this ratio before sending it to the mount. It does not care if it is 1.
For sure there could be a MCMT32 type in indi-eqmod, I hope there will be.
Bon courage.

Read More...

Jean-Luc replied to the topic 'Skywatcher protocol' in the forum. 1 month ago

Hi,
I wanted to reply to your other thread as I had a look last week to your very interesting project, but have been busy.
InquireGridPerRevolution requests number of microsteps required for a full 360° revolution (correct me if wrong) ; yes
What does InquireTimerInterruptFreq expect in return and what is the unit ?
It is the frequency of the timer interrupt used to drive the stepper, so the unit is hertz. If I remember on the EQ6 it gives 64935Hz, which gives a timer period of 15.4 µsec. That is related to the way the motor controller works: it uses a fixed timer period and some counters to determine when to generate step pulses regarding the desired speed.
What does InquireHighSpeedRatio expect in return and what is the unit ?
This is the ratio of speed between low speed mode and high speed mode: in low speed mode the motor controller uses microstepping, in high speed mode it will use half or full stepping. So this is almost the number of microsteps and is used to compute speeds in high speed mode.
Do periods (in minperiod, maxperiod, setspeed...) refer to the delay between successive microsteps sent to the motor ? What is the unit ?
These periods simply refer to the above timer period. For instance the sidereal period on the eq6 is 0x26C=620, the microstep count (GridperRevolution) is 9024000, and if you make the product 9024000x620x1/64935 = 86161.2381sec which is near the sidereal day (86164.1sec). Now to go at 800x, supposing highspeed ratio=16, (86164/800)x64935x16 / 9024000=12.40, this gives 12 timer interrupt periods (0x0C) between each step pulse. So the "speed unit" is this timer interrupt period.
Hope this is clear enough.

Jean-Luc.

Read More...

Jean-Luc replied to the topic 'Second USB webcam doesn't work' in the forum. 1 month ago

Looking at the log it seems that you set the input to camera then toggle image format to 160x120 and back to 640x480. The framerate then appears correct at 1/30s, whereas it was still 383/1 at the connection. If you know how to compile libindi, you could try to reactivate the VIDIOC_TRY_FMT in the libs/webcam/v4l2_base.cpp file in the ioctl_set_format function at line 284 : replace if (false) with if (true). It may leave some time to the hardware for initializing.
Concerning the image corruption this may be due to the setup time of the camera: as we capture the very first frame it may be corrupted. There was an option to drop frames but it is no more present. Maybe you could have a look at the uvcvideo driver site and faq . And try qv4l2 which can take snapshots and trace V4L2 ioctls.

Read More...

Jean-Luc replied to the topic 'Second USB webcam doesn't work' in the forum. 1 month ago

I have a look at the driver code: it seems that the driver fails to read the correct framerate using the VIDIOC_G_PARM ioctl when it connects the device. May you have a look to the output of the server (or launch indiserver indi_v4l2_ccd from a terminal and look messages from here) ? It should display an error if the VIDIOC_G_PARM fails.
Otherwise did you play with the frame rate settings in the capture tab and then test streaming ? That may set it correctly. Or try to run a capture program (qv4l2 or guvcview) before running indi. That may also initialize things correctly.
The last option I think of is to debug the uvcvideo module: sudo echo 0xffff > /sys/module/uvcvideo/parameters/trace
Then look at the log with journalctl -f (don't make long captures, there will be a lot of stuff there...).

Read More...

Jean-Luc replied to the topic 'Second USB webcam doesn't work' in the forum. 1 month ago

Hi,
The Error number 22 messages are normal, this is the way the v4l2 API is working: ask until it responds something other than 0.
I just tested the driver and also got those inappropriate values for every integer items: I suspect the issue is that we should use the V4L2_ G_EXT_CTRLS instead of the V4L2_G_CTRL ioctl when the underlying v4L2 driver offers extended controls. Will test. Done. Actually no: the indi driver is just printing a double value as an integer. There remains the problem of the framerate. Will check that later.
Now I've used a C920 Logitech webcam using the uvcvideo driver too and everything is still working as usual, I can set every number items (brightness, contrast, ...) and the driver is able to take exposure up to 10000.0 (1 sec which is the max for the cam) using the Exposure manual mode.

Read More...

Jean-Luc replied to the topic 'Problems with installing Python wrappers for INDI' in the forum. 1 month ago

Nice that it is working now on your setup,
I don't think I should change the tutorial, but we may now define the right dependencies in libindi.pc for static linking. Actually maybe we should consider the client case and the driver case. Quickly looking at the built libs, there is now only one static libindiclient.a library (the qt version has gone?), and two static (libindidriver.a+libindiAlignmanetDriver.a) driver libraries plus their dynamic versions. Is there a reason to not make a dynamic client version ?
Anyway you have added the Libs.private item in libindi.pc so I may use a Python pkgconfig package to get the right flags. But that won't work for preceding libindi versions and will add a python dependency. I think I'll simply change the libraries line (and leave the preceding version as a comment) and change the pre version flag to avoid the use of the --pre flag in pip.

Read More...

Jean-Luc replied to the topic 'Problems with installing Python wrappers for INDI' in the forum. 1 month ago

I don't think making a fresh install is necessary. If you download the pyindi-client package, untar it, modify the line in setup.cfg

libraries= z nova cfitsio
and run python setup.py install --user, that should work if you don't have already installed the package.If setup finds it is already there it may not reinstall anything. In this case you should run python setup.py build --force and python setup.py install --user.
Give me the output of these setup build and install commands and what displays the PyIndi import.
Normally with the --user flag, the resulting package is installed in ~/.local/ so a good thing would be to test it with
ls -l ~/.local/lib/python3.5/site-packages/pyindi_client-0.1.0a1-py3.5-linux-x86_64.egg/
ldd -v ~/.local/lib/python3.5/site-packages/pyindi_client-0.1.0a1-py3.5-linux-x86_64.egg/_PyIndi.cpython-35m-x86_64-linux-gnu.so
Replace the python version with the one you use, and also the architecture name.
And the good idea is not to refresh the tutorial page, but modify the setup scripts for the new libindi version (and pip which tells you to use version numbers, but now consider that 0.1.0a1 is not enough a version number).

Read More...

Jean-Luc replied to the topic 'Problems with installing Python wrappers for INDI' in the forum. 1 month ago

It seems that it worked for me. Did you force rebuild and reinstall ?

python setup.py build --force
python setup.py install --user
It should recompile all the swig/c++ stuff. Anyway the libindi dependency is no more there in libindi 1.4.1, which is a good thing.
If you use libindi 1.3 the libindi dependency is still there, so the initial libraries=indi should be used (it loads libz, libnova and libcfitsio by the way of this dependency).

Read More...

Jean-Luc replied to the topic 'Problems with installing Python wrappers for INDI' in the forum. 1 month ago

I've tried on a old indi version, when I suppress lindi from libraries, the Python import lacks the crackDN function, which was lying in libindi.so.
So I think that for version prior to 1.4.1 of libindi, we should leave libraries = lindi.
Starting at version 1.4.1, we should use the dependencies of libindiclient.a, which should be libz, libnnova and libcfitsio. So I suggest to use

libraries= z nova cfitsio
in the setup.cfg file. I don't have time to test yet but I 'll try to confirm that point this evening.

Read More...

Jean-Luc replied to the topic 'Problems with installing Python wrappers for INDI' in the forum. 1 month ago

Concerning the pip issue, is the pyindi-client already installed ? It seems it found the 0.1.0a1 version but does not care. Maybe there has been some changes in pip itself. Which version of pip do you use ? Anyway just to be sure everything is rebuilt when upgrading libindi, you should run:

pip install --upgrade --user --force-reinstall pyindi-client # for python 2.7 if this is the default
python3 -m pip install --upgrade --user --force-reinstall pyindi-client # for python3 as my pip3 disappeared when I jump to pip 9.0.1
When you run setup manually, you should now change the libraries line in the setup.cfg file as stated above:
libraries =
This is why the compilation aborts. I will have to change that on pypi. But I wonder if this was not required in preceding releases of libindi due to some dependencies.

@Jasem: yes, you're right, Libs.private and Required.private may be useful as libz, libnova and libcfistio are required for libindiclient.a. And I may also use the --static flag when using pkg-config. I would have to rebuild a proper installation for testing all that, my current installs are full of existng thing.

Read More...

Jean-Luc replied to the topic 'Problems with installing Python wrappers for INDI' in the forum. 1 month ago

Hi,
I've just tested on a Fedora with the pip method and this is still working.
You do not have to change the libraries config item with indidriver, pyindi-client is a client, not an indi driver.
Now the libindi.so seems to have disappeared in version 1.4.1, but it seems the pkg-config libindi.pc still reports it as a link flag to use.
Maybe you could try with

libraries = 

Jean-Luc.

Read More...

Jean-Luc replied to the topic 'Can't change ISO of indi_v4l2_ccd device in EKOS' in the forum. 2 months ago

Nice, at least it displays something ;-) More seriously did you check if those intmenu controls are effectively working ?
I would like to be sure before making a pull request.
Concerning the maximum exposure time, it is effectively set in the v4l2 port of the bcm2835 driver :

	V4L2_CID_EXPOSURE_ABSOLUTE, MMAL_CONTROL_TYPE_STD,
		/* Units of 100usecs */
              1, 1*1000*10, 100*10, 1, NULL,
Values should be min, max, default, step on the last line here, so you may change the max value to 6*1000*10 and recompile a kernel.
Now I wonder if this max value is not only available in a still picture mode.
The Expose control in the Main control tab should normally set the v4l2 Auto Exposure mode to manual, and the v4l2 Exposure time absolute to the one you entered. So that should work for values less than the v4l2 max (1 second).

Thanks again for testing,
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!