I believe that it is not a good idea to run simultaneously the hand controller and the USB serial interface of your mount. The hand controller and the indi-eqmod driver may send serial messages at the same time, and I don't know if this is supported (I mean electrically, there is only one wire for the RX port on the microcontroller, thus there should be some multiplexing somewhere or some short circuit protection). And as suggested by Avocette, both the hand controller and the indi-eqmod driver will have their own idea of where the mount is pointing. I believe it may depend on the order of your actions, without speaking of the auxillary encoders and different alignment models. If you perform an alignment with the hand controller, indi-eqmod has no way to access this model, and obviously vice-versa.
May you try without running kstars at the same time ?
It seems the python client does not get the blob data (you may easily check that, there is a print in the newblob callback in the tutorial code).
If you see the print message, there may be something updated in the threading.Event python library which causes this issue.
You need a modded camera to control the long exposure (it sets a specific pin available on the internal connector of the cam).
Usually the control of the long exposure pin is made through a serial port (RTS if I remember) and this adds another cable in addtion to the USB camera port.
The LXLED mod consists in unsoldering the led on the board and using that wire to control the long exposure pin. And the LXLED also needs a modded version
of the pwc kernel driver (which does not expose the LED control).
Thus unfortunately, you would have to mod the cam if you want to use it with long exposure.
The initialization of both encoder values to 0x800000 comes from the skywatcher firmware, and particularly the hand controller: this is how it works, and it has been kept as is in case you start with the hand controller, unplug it and jump to serial port control. I don't think that the motor firmware performs any computations on each step to make a modulus or whatever, it just adds or substracts one to the microstep counter and eventually go to 0x000000 or 0xFFFFFF on overflow. These are 8bit PIC processors and this involves 3 operations/tests in the interrupt routine which is largely enough. All the modulus are made in the driver (eqmodbase) or the hand controller (which are PIC24 16 bit processors). Actually the encoder values are considered as unsigned int.
Is this kstars or indi-eqmod which is crashing ?
Concerning goto slew speeds, the period figures (6 or 18) are related to the motor firmware, this is explained in the motor firmware protocol on page 2 (compute T1 period). I believe the min period values may be obtained from the firmware with a specific command, but this is not implemented in the indi-eqmod driver. The low speed period have been determined from the EQ6 firmware directly and corresponds to the min period for which the controller starts and stops motors without using an acceleration/deceleration ramp. Lastly the comments concerned my homemade board and mount (the Dec axis did not have the same ratio than the RA axis, furthermore it could not achieve the same high speed), so don't care about it.
Concerning deltara/deencoders, I'm not sure to understand what you mean with "backward direction". The skywatcher.cpp driver will run the motor as it has been asked, you could check it with the motion buttons. It does not always go in the forward direction. In eqmodbase.cpp which receives the goto command with the astronomical coordinates, you should take care of performing some flip if you don't want to hit the pier, thus it sometimes takes the longest path.
Is this the point you were talking about ?
By the way, nice work to implement such a protocol on a FPGA, it is much easier on a PIC...
Thanks, this may be effectively somewhat complex. And I totally agree with you, Chris, and really hope some manufacturers will come support the Indi team.
There has been a very huge investment from many people here and that's great. And at that point, it becomes crucial to find developpers and ensures
good quality code production/revision (I note revision mainly for indi-eqmod as this is really not my first quality, if any).
Let me somewhat reword my preceding post:
- there is no personal attack in it, I won't never cite anyone, I notice one particular behavior from my point of view
- I consider that this behavior may eventually imply some problems involving me directly as long as funding/money is involved and I have no control over it.
Concerning indi-eqmod, my name is at the top of every files, that's a point.
- I actually suggest that the simple way to resolve this is that the ownership be somewhat formally transferred to Indi (sed -e "firstname.lastname@example.org/Indi/g")
- As manipulation is a very common technique, I don't want to get the feeling to have been fooled. In such a situation, you need "to know".
- And to not limit this transfer to a simple substitution, it would be nice if, for instance, it consists in some rewriting with code quality in mind,
made by an internship supervised by a QA manager, hopefully funded by a manufacturer (hmmm, "the" manufacturer, let's have a dream...)
Writings in social network may have great impact for other people. As you noticed in my case, I just now doubt, and this will remain permanent for me, regarding any open source project teams.
These words are somewhat moral, some people don't care morality, I do. And I also care software ownership. And I really dislike to have to write such things.
@Jasem We have been posting at the same time, I however leave this post here for posterity
Ok, thanks for your answer concerning GPL and availability of paid development for the community.
Now concerning "Owner", as you did not give an answer, let me specify some points.
And start with a short history concerning my 3rd party indi-eqmod driver:
- I started it in 2011, hosted on code.google.com as indi-skywatcherprotocol
- it has been hosted later on sourceforge together with indi as a 3rd party driver, mainly to avoid users compiling it separately
- indi grew up, the forum appeared
There I started to find completely fake affirmations about indi-eqmod. I specifically remember one: "it can flash your camera firmware".
And subsequently confused users asking "Is indi-eqmod the culprit of (my USB hub dysfunctionning or whatsoever)?". I took time
to give an answer and asked the author to correct his affirmation (which he did). One time, two times. I think I gave up with the third fake.
Afterwhile I realized that there was one single author of these fakes, and he was an Indi team member (he "optimized" a small part
of the v4l2 driver that I previously adapted to the Indi CCD interface, and he did that with a direct push).
And this has continued since, convincing users the driver is unsafe/bullshit.
I won't speak about the offensing/pedantic comments in his posts about indi-eqmod.
To sum up the situation is:
- I gently accept my work to be hosted in the indi github repository
- I then read fake affirmations on the forum originating from one indi team member.
- Never other indi team members refute his fakes (if they read them)
- I stopped contributing, being dispappointed by this behavior, just making some updates when you asked me
- I may suppose that my eviction was the goal (in such cases, just tell)
Now comes Issue Hunt: should I left the control of the indi-eqmod driver to a team whose one member has written
fake affirmations confusing non warned users ? As money is involved, this is not the same game.
Let's illustrate with a recent small example: 'Adding support for EQ8-R autohome'
- user comes on the newly created issue dashboard (as suggests a post above)
- 'Owner' creates an entry in issuehunt, 'hunters' wait for the 'bounty' to increase
- one or more of them decide to accept the 'job'
- 'Owner' selects one of these hunters (how ? FIFO, best rated, friend of mine...)
- in this particular case, the assigned developper suppresses the test restricting the autohome feature (1 minute including recompilation)
- user/'Owner' validates the job (how ? Maybe ask the original author)
Clearly I do not want this to happen for indi-eqmod.
I first consider there are other ways for team members to deal with authors who partly helped to build their reputation.
I also consider to still be the owner of the indi-eqmod driver. I don't want to make money with it (go give ascom eqmod) but don't want
others fool people with it. And if you want a situation to change, maybe just ask before bashing authors on forums.
This post will be automagically destroyed in 5 seconds...
PS: it makes me uncomfortable to write this. But things have to be clarified before involving money.
Also note that I'm not against funding open source development this or another way. Just against cheatings.
I suppose that, concerning existing third party drivers under GPL, the modified code will be made available to the community after "issue hunting".
Does the Indi development team consider to be the "owner" of third party code it is currently hosting on its github repository ?
Is this compatible with GPL ? I'm not a lawyer...
Does that concern existing third-party drivers ?
I agree that the control panel is confusing, it shows you directly the INDI properties that drivers define. And a driver has absolutely no control on how these properties are displayed/used. It only gives you their values and react when you change them. Now it is a very good way to learn how things work. There is effectively a lack of documentation but that would be another great amount of work to achieve. Concerning the different design model, think that you may run indiserver/drivers on a raspberry without a keyboard/mouse/screen attached and remote control all your setup. I'm not sure if you can run ASCOM EQMOD that way (it's a long time I have not looked at their work). With Indi there may be clients that would achieve the PEC control you're talking about: I remember that there is a replica of the ASCOM EQMOd pad for Indi, that may have been added there. EqmodGUI, It's