Glad to be of service! I haven’t tried naming my port connections but it’s on my list so that will definitely be helpful. For the moment I am still having to ‘dmesg | grep ttyUSB’ after every reboot!
Sorry if this doesn't help you but I just spent alot of time trying to work out why my new sesto senso 2 focuser was enabling debug when connecting (only when autoconnect was enabled). It was the setting in Kstars -> EKOS -> Options -> Advanced - in the log section there was a number of items - all greyed out - but the focuser item was checked. I was messing about with the settings yesterday and enabled debugging and then turned it off (Verbosity: Disable). The setting for focuser was still persisted and was overriding the debug setting to be enabled -> On each time I autoconnected. To fix I had to set Verbosity to Verbose, and only then I could disable the Focuser, and set the verbosity back to Disable.
Strangely now when I go into the tab none of those tick boxes are displayed at all even if I up the debug level to Verbose. I suppose this is because none of the drivers loaded into indiserver have debug enabled?
Sorry if this is just noise but I thought it might be helpful to someone as I couldn't find anything similar on the forum.
If it’s any help First Light Optics have them in stock and got mine to me in 2 days via DHL. I paid £6 for UK shipping which is their base charge.
Thanks - I got a working version of the SestoSenso2 driver now. The limiting factor for me at the moment appears to be my knowledge of the Linux build/distro system. I tried to pull master for the git repo indilib:
git clone github.com/indilib/indi.git --depth=1
I was getting wierd curl errors without the --depth=1 param - probably because I am running the pi on a sketchy wifi link. Once I got the source I could compile/install fine but indiserver would just die on launch.
astroberry@astroberry:~/Projects/master/build/indi $ indiserver -p 7624 -l .indi/logs -vvv -f /tmp/indiFIFO
2020-04-18T22:53:20: startup: indiserver -p 7624 -l .indi/logs -vvv -f /tmp/indiFIFO
2020-04-18T22:53:20: listening to port 7624 on fd 3
Eventually I resorted to updating the astroberry distribution via apt-get:
sudo apt update
sudo apt install libindi1 indi-bin
ls -latr /usr/bin/indi_sestosenso2_focus
-rwxr-xr-x 1 root root 42504 Mar 7 16:00 /usr/bin/indi_sestosenso2_focus
Obviously this is quite an old version and I think I probably lost the fixes that Jasem applied for the trutech wheel recently. I would really have liked to have just installed the sestosenso2 driver.
Why couldn't I build / install from the git sources I wonder? There was no log for the crashed indiserver.
Anyway at least now I know there is a driver for my focuser that works - I confirmed by running the calibration just now. Will see how it performs once fitted to the scope - I noticed it seemed to home itself on disconnect.
No, not yet - I see it was added very recently - now do I have to pull the whole indi distribution for nightly builds to get this or can I selectively pull just the driver and edit the INDI driver XML config file? I'll have a look around for some instructions on this as well.
Thanks for the quick reply! That looks like the issue.
I just purchased a Sesto Senso 2 autofocuser. I reviewed a lengthy thread detailing the development process of the driver and to my knowledge version 1.4 (which I have) should support it - although it was not mentioned in the original thread if this was for the first or second gen of the SS focuser.
Upon connecting to the Pi I saw in dmesg that some other process (pps) was picking up the port:
[ 11.052246] pps pps0: new PPS source usbserial1 [ 11.052377] pps pps0: source "/dev/ttyUSB1" added
In INDI, seemed as though the port was not available and reported that some other process was using the port - I assumed this was due to the above message and did some searching. I found a couple of threads suggesting that gpsd could be grabbing the port (seems pps is a timing service). I tried killing gpsd with:
sudo killall gpsd
[ 1106.059726] pps pps0: removed
Thinking I was onto a winner I then go ahead and test the connection using a profile with CCD simulator, Guide Simulator, Telescope Simulator and the Sesto.
indiserver -p 7624 -m 100 -l .indi/logs -vv -f /tmp/indiFIFO indi_sestosenso_focus indi_simulator_ccd indi_simulator_guide indi_simulator_telescope
I am still getting the same error - actually I just checked and the error is slightly different with gpsd disabled: Previously the error stated the port was in use, now it says:
2020-04-18T20:45:29: [WARNING] Communication with /dev/ttyUSB1 @ 9600 failed. Starting Auto Search... 2020-04-18T20:45:29: [INFO] Error retrieving data from SestoSenso, please ensure SestoSenso controller is powered and the port is correct. 2020-04-18T20:45:29: [ERROR] Serial read error: Timeout error.
I went further and fully disabled gpsd by editing /etc/default/gpsd as below:
# Default settings for the gpsd init script and the hotplug wrapper. # Start the gpsd daemon automatically at boot time START_DAEMON="false" # Use USB hotplugging to add new USB devices automatically to the daemon USBAUTO="false" # Devices gpsd should collect to at boot time. # They need to be read/writeable, either by user gpsd or the group dialout. DEVICES="" # Other options you want to pass to gpsd GPSD_OPTIONS="-n"
Reboot, check dmesg - pps is still not grabbing the port - retest - same result. I don't know how to find out which process, if any, might be holding the port, or whether the hardware is just not answering as is suggested in the logs attached. What about the name of the hardware - could it be reporting itself differently (being 2nd gen) and being ignored? I'm sure there might be others using 2nd Gen Sesto Senso and I'd like to hear from you please?
Also is there a better way to test the drivers standalone? I thought I read somewhere of a way to start the drivers up in a standalone configuration for testing but I could not find the resource. I am connecting from a Mac client and set the logging up to the highest (bearable) level both on the server (-vv) and the client. Both logs are attached showing the commands being sent and no response. For this test the device was connected to ttyUSB1 and that's the setting that I started the connection with although EKOS hunts the other available ports.
[ 4.735511] usb 1-220.127.116.11: cp210x converter now attached to ttyUSB1
I did connect to a windows machine and ran through the calibration (and updated the firmware) - the hardware is functioning as expected on Windoze.
Sorry for the long post - there's alot of information here - I do hope someone can help!
Cool that you are still monitoring the group and thanks for your update. I am connecting to my router on the 2G network but I think that’s still n right? With 2G I can just about get enough reach to run the indi server from my Mac client in the house and pull images but my old windoze lappy just doesn’t have the punch to round trip to the router and back again. I haven’t tried lugging the Mac outside for focussing - guess I am just too lazy! I’m quite happy to wire the old obsy laptop to the pi and run a VNC session in the obsy to focus then disconnect and go back inside and reconnect with my Mac client but it looks like it’s pretty much confirmed that Ekos / indi was not designed with multicasting to multiple clients which is I suppose what I was after.
Once I have Ethernet to the obsy all these problems will go away. I’ve also got an autofocusser on my birthday list (next month)! Still using my old bhartinov mask for now.
All the best and Clear Skies
Just to add to this old thread - I would like to run two clients - one in the obsy and one in the house. 2 reasons - no autofocusser so I need a large-ish screen outside to focus on (same as OP). I also have a dome with a shutter aperture which is not motorised so I have to rotate it when first setting up or changing targets. My wifi is not quite good enough to vnc from the obsy to the router and back again and running the client (Mac) inside the house is great although sometimes the image downloads take 10's of seconds - I'm fine with that and plan is to run ethernet to house eventually. I also like not having to run kstars etc on the pi which keeps the load down. I've done a comparison running htop on the pi with kstars running there and vnc'ing in to control and using the remote client on the mac the difference in cpu load is huge.
So if I connect the laptop outside as a remote client to the pi (ethernet), slew, set up and focus then go inside and try to connect I have to basically kill indi server and restart the whole shebang from indoors, during which the mount will stop tracking etc.. It would be really nice to set up on the laptop outside (which is ethernet wired to the pi) focus, slew to a target, set up guiding maybe and then come in and connect to the same INDI server from inside as a second remote client which would then also receive images.
I have tried this multple times including last night when I found I had problems receiving images while plate solving from inside. What I found when I vnc'd to the pi this morning was a load of FITS viewer screens open on the pi, so what in fact happened was - I think - the pi was running kstars (I must have left it running) and INDI server was started for this kstars instance. The laptop connected to this INDI in client mode, while I slewed and moved the dome etc. then I connected the mac in client mode and although I could control - in the sense of issuing commands to the indi server - from my remote client on the mac, the images were being sent to the original (first) connection. I suppose INDI maintained the original pi client connection as the target for the images, which kind of makes sense if only one client connection is supported. Otherwise the server would have to multicast images to all clients.
Obviously I am not using as intended but you can see my use case requirement? I need a screen (client) outside connecting to the pi (or an autofocusser!) and a client running inside the house.
I think I might be able to achieve a half-way house solution by disconnecting the laptop ekos client outside (but leaving the indi server running) once done with focussing then re-connecting from the house thereby maintaining just one client connection and not interrupting tracking. Otherwise I just kill the server remotely and start a new instance and plate solve again (which all happens on the pi) from inside the house but that takes a few minutes.
I would just be interested to hear from others who maybe do not have autofocussers and need a screen in the obsy to work from and then control remotely from elsewhere.
Works perfectly - thank you! I see what you did - the buffer size was incorrectly allocated.
Chris - I totally agree with you - very hard to know how the software will behave without the hardware connected, that's why I offered to do some live connected testing with Jasem. I am setting up TeamViewer to enable this in case we should need to do so in the future.
Very impressed with both the software and the level of support provided - by Jasem and by the community as a whole. I am still keen to become involved in this project in whatever capacity I can.
All the best and enjoy your weekend! Cloudy weather is on the way here in the UK but I have a load of data to process from the last week thanks to Ekos/Kstars and my fantastic new RaspberryPi which is handling my observatory brilliantly.
Reverted locally by d-loading the repo pre your last commit on the trutech cpp and h files and replacing those rebuilding and installing. I'd still be interested in developments.
Thanks Jasem for your looking at this anyway - I'm happy to test for you if you want to send me code versions to run against my wheel! Just glad to be back up and running tonight...
I cloned the git repo, rebuilt locally and installed everything.
git clone --depth 1 github.com/indilib/indi.git
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug ~/Projects/libindi/indi
sudo make install
ls -latr /usr/bin/indi_trutech_wheel
Confirms just built version - maybe I messed up by installing everything from master?
Now the filter wheel tab throws an error on startup as attached. I had a good look around for more detailed and accessible log files on my pi (I'm running a Raspberry Pi btw). I'll go back to the manual to see if any locations are listed but if you can point me to where they might be?
Everything else seems to still work. The good news is that the problematic filter size parameter is now gone from the Options tab!
File Attachment:File Name: filter_wheel_error_console.txt
File Size: 2 KB