Come and join our community. Expand your network and get to know new people!
Then this is likely some serial issue. Does it work fine on armhf?
I attached a ZWO ASI 120MM-C to a William Optics Spacecat (F4.9) with a 40 mm extension tube in between. The Spacecat has 77.7 mm back focus, excluding 24 mm of rings behind the point indicated in a diagram, and the sensor sits 12.5 mm inside the camera, so I thought I could compensate for the remaining 1,2 mm by adjusting the focus on the Spacecat.
However, when I turn on Ekos during daylight, all I see is a white image, which turns dark when I cover the lens with my hand. At night it is completely black, no matter how I adjust the focus.
Did I understand this wrong, or do I need to change some settings in Ekos?
I am very grateful you put that tutorial together. It helped clear up many points for me
I would say the most important documentation to start with would be a very detailed account of how to set up the development environment. Especially with the removal of KDESudo and the new look QTCreator. Also a look at what the difference is between native and 3rd party drivers. Am I developing a 3rd party or a native driver ? I have no idea. And which should I produce ?
Then for both client and driver developers a detailed look at how the messaging between them occurs. I don't mean at the protocol level that indiserver implements but at what that means for developers. For a driver what functions get called by a client and when. Can a driver send a message to the client at any time etc etc. So some practical examples with diagrams as to how this all works. For example a diagram of what the server sends to a driver when it connects. When does the does the driver creator function get called ? When does the initproperties function get called etc etc. So a timeline drawing of how the client, indiserver and driver interact during the initial connection, for the interactions during normal operation and finally during shutdown.
I know that the project is very focussed on error free communication, that is obvious from the sample code. However it does not make the sample code easy to read when a large part of the functionality is built into the condition statement of an If Else. Much more readable would be to separate that out. So the functionality sets a local variable to true or false which is then tested. The conditions that have double negatives in them are even words. I know this makes for elegant code that shows off the skill of the programmer as to how much he can get done in a single line, but for a C++ newbie it means 10 minutes deciphering a single line of code !
I would suggest some code with no error checking is published. Not for operational use of course but to make the basic program flow easier to understand. Then a version with error checking included but in the simple manner I describe above, and then the preferred final version. Only then can the student get their head around the flashy code that the best programmers can write
All this could be done in a simple driver that just talks to an arduino or some such device to get and set a single value and display it. Maybe with a switch element as well. Then the student can play with everything they need to know. It's all very well having tutorials that don't talk to a real device but that leaves a steep learning curve as to how to actually do serial communications with the hardware for which it seems Indi has some useful functions.
I was also very confused about where everything gets put in the development environment. I wound up with the source code, a build folder and I was never sure where the installed code I was writing got run from. I wound up with multiple binaries of my driver and didn't have a clue which one was actually being used when I invoked them from EKos to try and debug. I would up always changing a bit of text in my code, like the name of the driver, so I could see from the client what was being actually run.
And that's before we get onto XML files, where they go and if I need one for my driver for Indi to see it.
So a map of where all the files go during the development process on a standard Linux machine and what are being run when would really really help.
Hope this helps, if it sounds confused it's because I am
I'm trying to get my NiteCrawler up and running using a self-compiled indi installation from git. This is on a raspberry pi 4 running debian arm64 rather than the stock 32-bit packages. I can see from the dmesg log that the serial port gets created at ttyUSB0 with the ftdi_sio driver but no combo of trickery lets me connect – I always receive a timeout when the driver tries to query the firmware version. The same cable and focuser work fine from Windows through ASCOM but I have to power cycle the focuser or else ASCOM also refuses to the connect to the port. I
Using the the version of indi bundled with Kstars 3.5 on my Mac works just fine. I suspect it's a low-level serial issue related to the FTDI driver. Has anyone else bumped in these problems? For the matter, would someone be so kind as to send me their indi config for the NiteCrawler?
Thanks in advance,
Is the Ekos-Debugger still available, I tried to install it and got nothing.
Hey Tim, thanks for the really good and detailed feedback. We can't get better as a project and community without knowing what we need to fix. I can talk to at least one of the points. The reason it took you so long to get to that information is that I didn't create it until you voiced your issues with the existing documentation. I threw that together basically overnight to try to fill in the gaps, trying to remember my pain points when initially getting into INDI development. Obviously I didn't quite fill in enough of them, but if you are willing, I'd like to work with you make it better. I've been doing C++ development for a long time, so I forget the learning curve of someone new, and having your perspective would be nice as I'm updating the docs.
I'll send it this asap (I'm at work). Thank you for your message.
Well, I have the same error - running on a Raspberry Pi 4B with 2GB. I installed it on Raspbian/buster with the latest release just yesterday and tried to follow the instructions for installing the Raspi HQ Cam.
But the command
sudo add-apt-repository ppa:mutlaqja/ppa
Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 95, in <module> sp = SoftwareProperties(options=options) File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 109, in __init__ self.reload_sourceslist() File "/usr/lib/python3/dist-packages/softwareproperties/SoftwareProperties.py", line 599, in reload_sourceslist self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 93, in get_sources (self.id, self.codename)) aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Raspbian/buster
If the crashing occurred before applying the Phonon common libraries and QT5 upgrade, normal use is back. To me, that says that while not INDI related, the Phonon isn’t catastrophic in crashing PH2D.
In Linux, a package can be checked for dependencies. It isn’t unrealistic to think LIBINDI 1.8.8 has missing support packages. I have had to augment multiple packages in my past use. Whatever a developer has installed at build time, can creep into a package.
Keeping verbose logging on fills up space quickly when deducing a problem. Be sure verbose and to a file are enabled before each session. INDI, KSTARS, and Drivers used. One of them changed.
I look forward to seeing the results of your documentation project, it's definitely the right thing to do.
I just had a long chat on the phone with one of my professional programmer friends. He had looked at the documentation in an effort to help me but also found it somewhat sparse and confusing. I really think that once this is sorted the uptake of Indi will be much stronger and that uptake could be exponential. I would also imagine that even more device manufacturers would then be in the position of having to write Indi drivers much as in the past they had to write ASCOM drivers for their product to be accepted into the astronomy community.
I had this issue only once, now though ever since after a meridian flip it can no longer plate solve. Personally I am creating a new profile at the moment to try and see if it something I did in the set up.
Thank you Tim for the great detailed feedback. I'm going to put aside $500 to any of the existing developers to work on re-writing the documentation again (for both drivers + clients) using detailed & clear to use instructions with images + text + examples...etc. If anyone is interested in taking this task, please let me know.
I have this same thing, but on Astroberry, but hopefully see this fix. I also have another problem with the solver I have posted elsewhere, still trying to resolve where it is. Essentially after solving first time when I do a Meridian Flip is never solves the same place. I shift to a different nearby star that is fixed distance away. At the end of the session when it automatically parks is shows 177 deg AZ and 77 deg ALT. When i shutdown the server and restart it come back to the correct 180/90.
I looked at all of these and all match. This issue has only started in the most recent release of Indi, prior to this I had nothing like this at all. Wouldn't have a clue how to report a bug.
It's only fair that I should let you all know what I found so difficult.
Setting up the debugging environment. This page indilib.org/develop/developer-manual/163...ent-environment.html is the only one I found on the topic. There are two videos where the action runs at a pace I could barely keep up with. Some explanation of what each step does would have been useful as well. I've never used QTCreator before for example and the mouse flashing around the screen, presumably to point things out is just confusing. It took a while to understand when the mouse stopped and was clicked. Worse, it's not an up to date version of QTCreator and the new version has those buttons in very different places. Add in that on the latest versions of Ubuntu there is no KDESudo command as the page acknowledges, but it puts in a cryptic note that to install I have to run
sudo make -j8 install
Why not to select/recommend a (mock?) device (i.e arduino-based) easily accesible to everybody and build and document an example driver for it ?
This will allow people like me, with programming background but having difficulty swallowing the whole syst linux-indi-c++-hardware-Qt development ecosystem in the short time I have left to live, to get in business faster.
That could by a nice toy to play and learn.
Does something like this already exist?