Okay in controls-> Resolution.

And I see the default for arm vs non-arm had changed since 1.8.9:Just confused myself real hard since I had a both script thas was getting the lower resolution and ekos was getting lower resolution, but not when on amd64. Really helped me see my error when I did git diff against 1.8.9 and saw default just for arm had changed.

Sorry to waste your time. Thank you for the help.


In Image Settings -> Frame?

If I try to change it to 1280x960 it says invalid width requested.


I currently suspect it isn't with the SDK itself. Sorry if my messages were confusing. My second message was trying to say that I swapped out the SDK and the issued remained. While this doesn't rule out a problem in the SDK it does seem to indicate that it was something that changed in indi that is causing this.

I am up for trying to debug this some more but would need some guidance on where to start.

This may or may not be helpful but the output of the lower resolution image still has color in raw format, so whatever is causing it to be scaled keeps the bayer pattern.


I also did try different libtoup debs. I was using libtoupcam_1.48.0-1_armhf.deb with 1.8.9 and libtoupcam_1.50.1_armhf.deb with 1.9.4

However extracting the .so file from 1.48.0 deb and copy it over onto 1.50.1 made no change.


Russell Valentine created a new topic ' indi_toupcam_ccd arm32' in the forum. 10 months ago

Hello. I having a RisingCam IMX224 that uses the indi_toupcam_ccd driver on a raspberry pi.

I've notice on indi versions 1.9.2 and 1.9.4 the maximum resolution is 640x480 even though it should be 1280x960. I also can't manually set it to the higher version it errors with it being invalid.

If I use 1.8.9 I get the full resolution (sorry I have not tried other versions besides these three).

I do not see this issue on amd64.

This happens if I build it myself, or if I use astroberry binaries for raspberry pi. Has anyone else noticed this or found a solution?


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.