Solved, sorry : invoking indi_gphoto_ccd is not equivalent to invoking indi_canon_ccd though the latter is a symlink to the former.

So if owning a canon, invoke indi_canon_ccd

Still, it might be worth mentioning in the faq, though I should have tried it.

Thanks again, the sky is clear, roof is opened, I will attempt my first simultaneous acquisitions (wide field on a T80/760D, narrow field on the C14/Atik 4000), target will be m101
Best.
--
fm

Read More...

Thanks. I double checked all of these, tested that mirror lock is ok with a 2s settings. Checked forced bulb. Started well, the "shutter release port" field disappears, which sounds good.
Then tried a 1s exposure (with force bulb so should trigger what is needed) but ot no avail though it started well, invoking eosremoterelease, but insist on communicating to that
damned shutter port :

18:17:57.897: [INFO] Starting 1 seconds exposure (+1 seconds mirror lock).
18:17:57.897: [DEBUG] Starting exposure (exptime: 1 secs, mirror lock: 1, force bulb: true, exposure index: 0)
18:17:57.897: [DEBUG] Mutex locked
18:17:57.897: [DEBUG] Setting exposure widget bulb index: 0
18:17:57.897: [DEBUG] Setting radio/menu widget shutterspeed: 0 (bulb)
18:17:57.897: [DEBUG] Setting new configuration OK.
18:17:57.897: [DEBUG] eosremoterelease Mirror Lock for 1 secs
18:17:57.897: [DEBUG] Setting radio/menu widget eosremoterelease: 2 (Press Full)
18:17:57.897: [DEBUG] Setting new configuration OK.
18:17:57.897: [DEBUG] Setting radio/menu widget eosremoterelease: 4 (Release Full)
18:17:57.897: [DEBUG] Setting new configuration OK.
18:17:57.897: [DEBUG] End of mirror lock timer
18:17:57.897: [DEBUG] Opening remote serial shutter port: 7623 ...
18:17:57.897: [ERROR] Failed to open serial port: 7623
18:17:57.897: [ERROR] Error starting exposure

Read More...

If I understand correctly exposures longer than 30s can be made via either a connection of some sort to the remote connector or the camera or internally via eosremoterelease property.
gphoto2 --list-allconfig confirms that the eos 760D has that property so I expect the infi_gphoto_ccd driver to be able to manage aver 30s exposures directly via USB.

But it does not work on my 760D. The indi panel shows a "shutter release port" which is green and set by default to 7624.
So on requesting an exposure longer than 30s, the driver tries to trigger/communicate on that non existent port and of course fails.
Everything predefined works well up to 30s.
Any idea what I am missing ?
(I have compiled a freshly pulled version of indi-gphoto-ccd)
--
fm

Read More...

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

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

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

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

Read More...

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

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.

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

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

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

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

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

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