I really appreciate the reply David.

I will look out for those messages, but I don't know that I saw the same last time I used it.

Sounds like maybe time to sniff serial messages with socat and tee or github.com/geoffmeyers/interceptty


More of an update. The LX200R is really just the optical tube. The base is just a LX200GPS. Playing with it a few more nights I've found the following:

  • Sync and Slews give the correct coordinates to the mount. The mount is really at those coordinates
  • The position that indi/ekos/kstars thinks the mount get an offset. This varies from 10' to 35' in both RA and DEC. So if I do a sync it syncs the telescope correct (as in the telescope itself on the handpad shows it correct), however the position in indi/ekos/kstars automatically jumps back off.
Not sure why this is, my first thought is some J2000 <-> JNOW conversion when it shouldn't but I currently do not know.

Has anyone else with a LX200GPS experience such an issue?


It is my guess that toupcam doesn't work on armv6l (raspberry pi zero w) maybe because of the binaries parts of libtoupcam.

I tried a orange pi zero lts(armv7l) and it seems to be working good there.



In the past I've successfully used indi_toupcam_ccd in raspberry pi 4. I was trying to use it on raspberry pi zero w and I get sigfaults. This is with the astroberry apt repository, or if I build from git repo source. Does anyone know if it just doesn't work on the zero w?

$ indiserver indi_toupcam_ccd  
2021-04-18T02:32:00: startup: indiserver indi_toupcam_ccd  
2021-04-18T02:32:01: Driver indi_toupcam_ccd: stderr EOF
2021-04-18T02:32:01: Driver indi_toupcam_ccd: restart #1
Child process 8073 died

$ indi_toupcam_ccd  
Segmentation fault



Our club has a 12" LX200R. I've been having a couple of issues.

1) When I sync there always seems to be a offset of 10minutes of RA. So if I sync to 12h40m12s after syncing it reports it is at 12h50m12s. This is after a manual sync or if a solver syncs it doesn't matter.

2) Sometimes when I connect it seems like the offset is even greater like 90 degrees. Usually I can park and reset a few times to get it to work normally but I still end up having issue #1. I thought it might be a time issues. I've never been able to have it use the GPS successfully from INDI. When just using the handpad it gets gps find and is able to goto objects fine. From INDI if I turn on GPS and have it use GPS I always get an error about not being able to process the time, like "2035-23-48T01:05:00"

Does anyone have any experiences with this. I originally was trying to capture the log just for #1 but I was in a hurry last night and just kept getting #2. So I only have the log for #2.

I feel like this is an operator error on my part, like I need to do some steps to make it works correctly, but I am not sure what. I am hoping that people can use this remotely so I hope the steps don't involving having to physically use the handpad first before connecting, but what to do would be good to know at least for when people are on site to use.

Thank you.

File Attachment:

File Name: log_23-46-50.txt
File Size: 47 KB


I posted this issue on github. I believe the issue is because the indi driver sets IDLE and not OK similar to what I've read in the below forum post regarding fcusb shoestring driver.



I've been trying to get autofocus to work using a Meade microfocuser on a Meade LX200R with INDI and Ekos/KStars. When running autofocus it says moving focus for 100ms and does nothing after that. Like it is waiting for some feedback. Has anyone had luck using autofocus with the microfocuser? The focus in and out buttons work (I can hear the focus motor turn), but autofocus seems to just wait for the focuser response or something. I've tried both GPS and Autostar versions of LX200 mount drivers with similar results.


Is there any support for the idea of incorporating what they had in their github repo into the 3rd-party repo of drivers that get built? Maybe with a warning that the driver is not self contained.

I know it requires a windows machine with their software running, but could be better than nothing and make it possible to still use very nice kstars/ekos/indi stack with it. I can understand if you are totally against the idea, but thought I'd ask.

I think I am about to try this next. I imagine it might need some modification since it hadn't been updated in a year, if I can fix it up, would a PR to include it be accepted?


My setup to help explain my issue:

Using KStars/Ekos on a windows machine
Sitech mount with it's ascom driver installed
windi ascom to indi bridge is running on the windows machine
RPi running indiwebwebmanager is installed
SBIG camera with built in guide/AO is connected to the RPI

I use Ekos to connect through indiwebmanager setting sbig as the camera and set remote url to the windows windi server.

Imaging from the main sbig and guide cam works, syncing and slewing the mount works.

Whenever I try to guide or solve I get an error. For example when trying to solve it just errors before doing anything "Telescope aperture and focal length are missing. Please check your driver settings and try again." When I try to guide I get a similar error and I notice none of the info is there for focal length, apature, etc on the guide tab.

On the telescope tab if I set a apature and focal length and hit "save telescope info" Nothing happens. There is nothing in the drop down under configurations. I am guessing that the issue might be there. Maybe the windi indi bridge doesn't support storing that info? I am not sure.

Does anyone have a workaround? It would be nice if I can just overwrite those setting and not require it to be in the mount itself or something. Or maybe I don't understand that part about INDI. In anycase I am hoping someone can help.



I originally thought I could use INDI with a Sitech controller in an LX200 compatible mode. However I notice that mode is just a layer in front of the windows app. And the driver on github still expects the windows driver to be running (maybe it can be done through wine if mono didn't work? It would still launch their UI, but maybe better than nothing.)

Last I heard you didn't have any of the hardware, would it help if you had the hardware? Maybe I can contribute in part to a fund to help in the cost of one of the controllers? If you are not interested going that route, it is okay, was just thinking.




Ok using 7cc5083cc152aeaa4edc9b6fd824771945a95f60 checkout in indi-3rdparty. Red is blue and the other colors look pretty gray in the KStars FITS Viewer.

The fits file:

I can look into what might be happening sometime tomorrow probably.


I took some images tonight and viewed them through the fits viewer. I took a picture of that same color chart with the pin hole setup. The colors for sure are off. I notice right off the bat red shows as green. I'll be able to look specifically what is going on with the bayer matrix Thursday evening and will reply with my findings.


I've maybe misunderstood your message. If your recent bayer change is in, I can try it next time I'm out.


I've had a hard time finding any good information of how the bayer matrix should be with these cameras. Some forums like on cloudy nights implied that each chip could possibly have a different one (I kind of find it hard to believe).

I did have good luck with color. I made a pinhole lens with foil and a color chart with construction paper. So if for example I force RGGB and up-bottom orientation in Siril(I believe this setting used to be called kstars-ekos/pixinsight compatibility) and some white balancing, I get the attached image.

I've also taken a test image of M33 and the colors seemed pretty good this way. I've had some set backs with my setup so that is as far as I got. I hope to get back on track after all these holidays.

I'm not an expert on maxim but maybe it has something to do with the up-bottom orientation?


So I've been able to take home the camera to try some more things. It really just is the timeout the whole time that was the issue. Unbinned it takes 14 seconds to transfer the image with the original chunk size. The timeout was 10s. I will make a pull request to increase the BULK_DATA_TIMEOUT to 20s.