François Meyer replied to the topic 'problem atik efw v2' in the forum. 1 month ago

it may be not an indi problem, at this point it could be anything (except hardware, it works under windows). What really puzzles me is why this code is not open : come on atik, we are talking about a basic stepper motor software driver, there are gazillions of these things hanging around !

Read More...

François Meyer created a new topic ' problem atik efw v2' in the forum. 1 month ago

Is there some configuration (udev rules...) to tweak with to use an atik filter wheel (see output of dmeg below) ?
I tried it on 3 machines to no avail using
atikccd-1.24-amd64.deb
and/or
atikccd-1.24-armhf.deb

on my x64 laptop :
dmesg :
[ 3712.909208] usb 1-3: new full-speed USB device number 13 using xhci_hcd
[ 3713.056562] usb 1-3: New USB device found, idVendor=0403, idProduct=af01
[ 3713.056568] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3713.056571] usb 1-3: Product: Atik Filter Wheel
[ 3713.056574] usb 1-3: Manufacturer: Atik Instruments
[ 3713.056576] usb 1-3: SerialNumber: FWSJGFO9

Then, on Connect from kstars :

[ 3759.240388] indi_atik_wheel[2707]: segfault at c ip 000000000040ea8b sp 00007ffdbf4cd240 error 4 in indi_atik_wheel[400000+55000]

I had to symlink cftsio.so.2 to cfitsio.so.5 and linova 14 to libnova16 to have it starting so
the segfault might be related.

on my raspberry :

dmesg |grep -i atik :
[nothing]

of course, on Connect from kstars nothing happened.

On an oid xu4 :
after connectingthe wheel on usb : dmesg :
[ 42.136722] [c0] usb 3-1.2: new full-speed USB device number 5 using xhci-hcd

and thats all. Of course on Connect from kstars nothing happened.

Thanks for any help.
Regards

Read More...

François Meyer replied to the topic 'custom eqmod (was: eqmod pierside management)' in the forum. 1 month ago

Ok, just to put a final word to this thread :

I am finally through with all my firmware issues : most were related to uncertainties about
when the eqmod driver does or does not command motor start and stop. In particular, at the end of
a goto, the eqmod driver waits for the motor to stop while my firmware automatically resumed tracking...
And some other issues of the same kind...
It took some time to track down but I'm finally there. Pfew...

Now I need to figure out how sync/align/horizon tabs should be used : are there any docs/links
describing their proper use ?
(an example of question : how do I tell the driver that my mount can track ~ 2 hours around meridian without flipping ?)

thanks.
--
fm

Read More...

François Meyer replied to the topic 'eqmod pierside management' in the forum. 2 months ago

> Hope this helps.
It certainly does ; I can see the light at the end of the tunnel :)
Stay tuned.

Read More...

François Meyer replied to the topic 'eqmod pierside management' in the forum. 2 months ago

Hi, thanks for the insights. Ive been out for a while, sorry for the late answer :

Concerning parking : I think the problem is in my management of encoders value ; my mount "encoders" value are just microstep counts from
the origin ; at power on, these encoders are (currently) initialized to a hardcoded value ; I set that value at half its (24 bit) range (0x800000) which
is enough to encode 360° each direction without overflow (I have 0x753000 usteps per rev).
From what you wrote, I think that at power on, I have to initialize them at the same value that is stored in park data ? Or does the indi driver
tell the mount the initial value of its encoder when it is parked ? I am still a bit lost, I must admit.
Concerning pier side, I think its closely related to the problem above, so I need to first settle concerning the first point and then
rethink the pier side problem accordingly.
Concerning goto not terminating, I think there is a problem in my firmware ; I am investigating. and I cannot follow the procedure you suggested me
unless I first solve point 1.
So I really need to understand how encoders value are initialized/set/exchanged between the mount firmware and the driver.

Thank you again.

Read More...

François Meyer created a new topic ' eqmod pierside management' in the forum. 3 months ago

I have a custom MC (aiming at being) eqmod-compatible.
I am -mostly- completely lost in the tabs of the driver, confused with 2 align tabs, unable to understand the logic of parking,
nor the management of pierside and so on :)
Lets start slowly:

1. how does parking work (I am confused with this so probably I am misunderstanding something) ?
I see parking data as a couple of encoder values, a couple of alt/az values (plus maybe a pierside) and that
completely defines parking position. Due to my obs configuration, I need to park in the meridian and 0 alt, west of pier ; how do I tell that to the driver ?

2. my gotos do not complete : scope moves to the right coordinates, tracking resumes, but the driver does not get out of slew mode.
Here is a test drive :
sync is set to standard sync, align is set to no alignment (there are 2 tabs, 1 called "align", the other called "alignment"... what is the link ?), horizon is disabled,
scope is unparked, tracking, synced, horiz coordinates are correctly updated, eq coords dont move.
From kstars I goto (more or less 2 deg each dir) ; attached is a log, and 2 screen shots before/after goto.
the mount pointer has disappeared, because coordinates have gone wild after the driver decided that the scope has jumped
on the other side of the pier, while the mount correctly performed the desired goto, without flipping whatsoever ;
but the main question is why the goto is not complete according to the driver.

any help will be highly appreciated :)
ty in advance.

File Attachment:

File Name: indi_eqmod_telescope_094446.log
File Size: 194 KB


Read More...

François Meyer replied to the topic 'EQMod storing config values for sync/align/horizon.. tabs' in the forum. 3 months ago

Ok, that does not seem to work ; custom speed values do appear in .indi/EQMod Mount_config.xml but they do not seem to get loaded neither
startup, nor after an explicit options/configuration/load click.
ALIGNMODE also appears in that file, but is not loaded at startup ; the correct value needs an explicit options/configuration/load click to show up.
Let me know if you need more specific tests.
best.

Read More...

François Meyer replied to the topic 'EQMod storing config values for sync/align/horizon.. tabs' in the forum. 3 months ago

Great!
I am debugging my controller firmware, so I experiment far more start/restart than usually needed, but still it might be useful to every one.
Thanks again.

Read More...

François Meyer created a new topic ' EQMod storing config values for sync/align/horizon.. tabs' in the forum. 3 months ago

Hello,
its all in the title, I must be missing something obvious, sorry but I cant
find an answer (setup is a raspi running eqmod, client is laptop connecting to it) :
how (or where ) to strore these values (such as "alignment mode", "limit goto", "on limit", "custom speeds"),
so that I dont have to check all of this boxes at each restart ?
thank you in advance.
best.

Read More...

François Meyer replied to the topic 'Skywatcher protocol' in the forum. 7 months ago

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 ?

(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).

Bon Courage


Grazie mille :)

Read More...

François Meyer replied to the topic 'Skywatcher protocol' in the forum. 7 months ago

Great, thanks.
I have here the pdf output of a spreadsheet I used to compute my configuration ;

perso.utinam.cnrs.fr/~fmeyer/pas_moteur.pdf
or its gnumeric source :
perso.utinam.cnrs.fr/~fmeyer/pas_moteur.gnumeric

it might help making sure we are talking of the same things (I just realized it's half french/half english, but
neither should be a problem :)
The controller timer frequency is 80 MHz (these are microchip uno32, one per axis), period 0.125 us.
This gives me a period of 0x0000db206 at sidereal speed, and 0x00703 at 500x.
One difference is that (at least in its current config) the mcmt32 setup cannot alternate between ustep and full step (this limits the maximum speed, but its not a problem) ; so I think I have to set that HighSpeedRatio ratio to 1.
Unless mistaken, that seems all clear.
at least for now... I'll probably be back with additional questions, if you dont mind hanging around this thread for a few days...
thanks again.
Oh, while I am here, it seems you have followed that very same path, ending in creating a GEEHALEL mount type in eqmod.
Could/should there be (once I am done with fixing the firmware) an MCMT32 type in eqmod ?
--
F. Meyer

Read More...

François Meyer created a new topic ' Skywatcher protocol' in the forum. 7 months ago

Hi,

I want to make my mount controller skywatcher-compatible. I am currently rewriting the controller firmware and have some questions regarding some details of the skywatcher protocol ; variable names are those of indi-eqmod/skywatcher.[h|cpp].

InquireGridPerRevolution requests number of microsteps required for a full 360° revolution (correct me if wrong) ;
Following 2 are less clear to me :
What does InquireTimerInterruptFreq expect in return and what is the unit ?
What does InquireHighSpeedRatio expect in return and what is the unit ?

Do periods (in minperiod, maxperiod, setspeed...) refer to the delay between successive microsteps sent to the motor ? What is the unit ?

Thank you in advance,
best
--
fm

Read More...

François Meyer replied to the topic 'Skywatcher protocol, need some hints.' in the forum. 7 months ago

Hi,

I finally went to the solution of making my mcmt32 mount controller skywatcher-compatible. I am currently rewriting the controller firmware and have some questions regarding some details of the skywatcher protocol ; variable names are those of indi-eqmod/skywatcher.[h|cpp].

InquireGridPerRevolution requests number of microsteps required for a full 360° revolution (correct me if wrong) ;
Following 2 are less clear to me :
What does InquireTimerInterruptFreq expect in return and what is the unit ?
What does InquireHighSpeedRatio expect in return and what is the unit ?

Thank you in advance,
best
--
fm

Read More...

François Meyer created a new topic ' EqMod emulation/implementation (mcmt32)' in the forum. 7 months ago

Hi,
Still progressing with the indi implementation of my mcmt32 controller. I have the vital functions up and running (sync, slew, ..). now I am considering implementing additional functions (parking, meridian flip management etc...) but I am rebutted by spending a lot of time reinventing the wheel, since :
1. this has already been done (eg in eqmod)
2. its not completely trivial (at least to my eyes).
3. the highest level functions can be abstracted from the underlying, low-level, mount-specific communication protocol.
4. the number of users of mcmt32 is rather small overall, and among those, linux users are...well... maybe I am the only one :)

So I am wondering if the best thing I could do at that point, would not consist in rendering mcmt32 eqmod compatible. This could be done by either :
1. emulating the skywatcher protocol in software in the driver (a kind of on-the-fly translation of the serial i/o messages between indi and the mount controller,
2. rewrite the controller's software (firmware, 2 uc32 units, 1per axis), so that it is skywatcher compatible.
At first glance, my feeling is that 1 is more straightforward (and less risky) than 2, I am still wandering in the skywatcher code at the time.

Before engaging in one of these, I'd like to collect expert advices on this issue, and maybe gather some information about the skywatcher protocol and the minimum subset of commands that must be emulated to work with eqmod.

(Should anyone be interested, the codes for the current library, indi driver and firmware are accessible here :
sourceforge.net/p/mcmt32/svn/HEAD/tree/
and those wondering "wtf is mcmt32", a description is here (french only...)
www.astrosurf.com/mcmtii/m32realisat.htm )

Thank you in advance for valuable advices.
Clear skies...

Read More...

François Meyer replied to the topic 'Steps to adding a custom driver to my git copy' in the forum. 8 months ago

> Hope this helps.
I bet it does :)
I had exactly #1 in mind. I will check that soon (and might well be back for some details).
Thanks again.

Read More...

François Meyer replied to the topic 'Steps to adding a custom driver to my git copy' in the forum. 8 months ago

Ok. Lets get pragmatic, I have a libmcmt32 that comes with a few C files, a Makefile and some requirements :
and an indi_mcmt32 driver that comes with pretty much the same things.
In the 3rdparty directory, I create a libmcmt32 directory with the related code in it ; then I do the same
with indi-mcmt32 and the driver code. My question is, from here what do I need to modify/create so
that those two (lib and driver) are known and built by the cmake standard build procedure.

Read More...

François Meyer replied to the topic 'Steps to adding a custom driver to my git copy' in the forum. 8 months ago

> I'm not sure I exactly follow what you're trying to do here.
> You want to create a 3rd party driver
yep. It already exists.
> and host it in your own git repo?
Not really (I never understood the philosophy of git... I'm too old, I'm afraid :) ) ;
what I want to achieve is to be able to build the driver inside the indi tree, to make
updates easier.
> and what do you mean INDI standard build procedure? CMake stuff?
yes.

Read More...

François Meyer created a new topic ' Steps to adding a custom driver to my git copy' in the forum. 8 months ago

Hi,
Steps to adding a custom driver to my git copy.
all in the title. I already have it compiled and tested, but I probably messed up with a bunch of files from the indi tree
to get things working...
So I'd like to make that cleanly from a brand new and unspoiled git tree.
The code comes in two parts, one for a (relatively small) dedicated library, and the code for the driver itself.
I'd like to add that to the tree so that the standard indi build procedure also takes care of my lib and driver.
Is there a guide describing the proper way to do that ?

Thank you in advance
best regards

Read More...

François Meyer created a new topic ' Indi driver for DIY stepper-driven focuser' in the forum. 1 year ago

Hi,

I have built a diy stepper-motor driven focuser ; it is controlled through a python script running on a raspberry (script attached). Basically, it uses 4 arrow keys (up/down to set speed, left/right to move) ; its very efficient on the field ; I mostly run it remotely through ssh and screen (see video for a small demo).
It is very basic, inputs are key strokes, outputs are step and dir to gpio pins and the step counter that is displayed.
I am considering integrating it as an indi driver, but I dont want to reinvent the wheel. Is there such thing as an existing indi driver for that kind of gpio + keyboard focuser ?

Thanks,
best
--
fm

Read More...

François Meyer replied to the topic 'Odroid C1 - Ubuntu 16.04 LTS support' in the forum. 1 year ago

I lack real feedback "from the field". Clearly its powerful, completes compiles in reasonable delays (phd2 for example), in this sense its incomparably more comfortable than a RaspPi. I did not test gpio for now. All my gpios (2 focusers, some relays) are still handledby a raspi2, and I probably wont switch those to the oDroid at least not right now.

It has USB3 so it would be interesting to see how it behaves with latest zwo cams like the 1600mm for example. But I dont have any usb3 cam right now.

Probably the main concern regarding the raspi vs odroid dilemma is the huge number of users/testers of the raspi
compared to the odroid. When encountering unusual problems, solving them might probably be
more complicated with the odroid. Right now, it does not display anything on the hdmi output...
Not a big deal for what I intend to do with it, it is mainly supposed to be network operated,
vnc server runs flawlessly ; but still, a display might sometimes help :). I did not bother to try
and solved the issue, maybe its easy, but I have other priorities right now.

Still the xu4 is a very nice piece of hardware, and probably able to handle the whole stuff needed
to operate a small observatory...

Best
--
fm

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!