Jean-Luc replied to the topic 'Issue Hunt: A New way to fund INDI Driver Development' in the forum. 6 days ago

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 "s/")
- 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 ;-)


Jean-Luc replied to the topic 'Issue Hunt: A New way to fund INDI Driver Development' in the forum. 6 days ago

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


Jean-Luc replied to the topic 'Issue Hunt: A New way to fund INDI Driver Development' in the forum. 1 week ago

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 ?


Jean-Luc replied to the topic 'Issue Hunt: A New way to fund INDI Driver Development' in the forum. 1 week ago

Is this compatible with GPL ? I'm not a lawyer...


Jean-Luc replied to the topic 'Issue Hunt: A New way to fund INDI Driver Development' in the forum. 1 week ago

Does that concern existing third-party drivers ?


Jean-Luc replied to the topic 'Guiding and PEC and PPEC and EQMod' in the forum. 3 weeks ago

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 there


Jean-Luc replied to the topic 'PPEC and EQMod crashing and general strangeness' in the forum. 3 weeks ago

Skywatcher has published the motor firmware protocol some years ago, it is still on their official site. I don't think they would sell so many mounts if you were not able to control the mount directly without using the hand controller. I believe they don't want to invest in software, because open source do that for them, customers may build the software they wish.


Jean-Luc replied to the topic 'Guiding and PEC and PPEC and EQMod' in the forum. 4 weeks ago

xthestreams wrote: HELP! How does PPEC win EQMod work?

Further to my earlier forum topic concerning a potential bug in PPEC with EQMod, I've obviously been trying to improve my guiding game.

Im getting pretty decent results from my EQ8-R but the peak-to-peak error seems quite high to me (for a mount of this $$$) and generally I like to switch on whatever smarts my technology has to see what impact is can have positively or negatively so that I understand where the limits are.

I've tried to train the PPEC whilst guiding and I have a few questions;
1). Why is DEC training an option when the SkyWatcher manual clearly states that RA training is the only available option?

indi-eqmod is a driver: it exposes everything from the motor controller boards. As RA and DEC boards have the same firmware, indi-eqmod just shows you DEC PPEC switches, which are unuseful in a normal situation.

2). What *is* Dec training? Why would we need it give the likelyhood of periodic error being a "thing" is low? Backlash training/compensation I can understand, but PE/PEC for Dec?
3). Has anyone tried enabling RA after training on an EQ8-R? My experience is that it sends the telescope into a crazy overdrive sidereal speed mode and crashes the mount (it's now also started making a police siren style noise while doing it, something that's not good for my poor little heart)

On previous mounts/firmwares, when you turn PPEC On, the motor controller reads period values form internal memory to adjust the speed of motor while tracking. Wrong values may explain this behavior.

4). A few people have referred to EQMod on ASCOM being able to log and create a "smoothed" PEC curve that can then be loaded into the mount. That is train EQMod's inbuilt PEC for 4-5 worm revolutions and I am guessing use an FFT to pull out the "known" PE versus the "seeing related" PE such that whilst guiding is still beneficial, the peak-to-peak error would be smoothed by the driver's PEC. A few bright folks then replay that PEC training into the mount to create a PPEC that's smoothed - seems like a brilliant idea, but I assume I would need to cross over to the dark-side of ASCOM to try that?

A few words about that: in Indi, drivers should have the minimal number of dependencies (that was the situation when I wrote the indi-eqmod driver at least, 8 years ago). ASCOM EQMOd does not have this restriction and may have its own User interface to implement other features. If I would like to do the same in Indi, I should restrict to the Indi control panel and write a bunch of code just to handle the UI part of new features. And I am too stupid for doing that.

Final question;
5). Is it better to guide "direct connect" (VNC) versus in client/server mode?

To explain - I've been running in client/server mode, RPi4 with hard wired Ethernet connection on my mount/camera outdoors and Mac kstar/EKOS client in my office.

My assumption is that guiding accuracy will be somewhat latency limited by the round-trip time from image capture (say 2 seconds), transmission to client (right now guiding full-frame with my OAG as anything smaller seems to lose my guide star during calibration - say 1-2 seconds), determining "drift", a millisecond or two and then responding to the mount - another msec or two.

All told, round trip time from initial image capture to mount control would be measured as 4-5 seconds. During which time the mount has continued to drift in whichever way it does - I guess my question is, how much does all of that matter? My instinct is that the only time is would really matter is if the mount is really awful or the seeing is really shitty - either way all the guiding in the world isn't going to help - but I that someone out there might have a more scientific answer.

Sorry for the long list of questions, but as much as guiding & PEC have been documented for INDI/EKOS, it's still something of a confusing black box to me. Oh and that's BEFORE I talk about using PHD2 - I assume this is something I really should be using, but would prefer to see kstars get better than rely on third party band-aids to solve what is a product "feature" shortcoming.

Phew, that took longer than expected.


Jean-Luc replied to the topic 'PPEC and EQMod crashing and general strangeness' in the forum. 4 weeks ago

The stupid guy who wrote the stupid indi-eqmod driver simply has no direct way to know if the mount has been trained or not. This may (and should) be stored in the motor controller memory but if ever it is, I do not know how to retrieve that information. Storing that info into the file system of what runs the driver is not really a solution, because as you said, what if you reflash the motor controller firmware ?
The reason why it crashes now is that the firmware returns a different code than before when starting PEC without training, which suggests that the info is now stored in the motor controller memory.
The same stupid guy would like to apologize that he has not thought that firmware may vary and has not enclosed that PEC On switch code with an appropriate try/catch clause. But is is well known here that this stupid driver is also highly unsafe. If I remember, this driver is even not capable to check if it is run against the right indi core dynamic library. What a pity...