Jarno Paananen replied to the topic 'How HID 'drivers' are communicate?' in the forum. 3 weeks ago

INDI uses hidapi library which is layered on top of libusb so it works pretty much everywhere now, even Windows. There is a fairly clear basic example in the SX wheel driver ( github.com/indilib/indi-3rdparty/blob/ma.../indi-sx/sxwheel.cpp ) First you connect to the device with hid_open() which takes the vendor and device ids as parameters (which identify the device) to get a handle and then send data to the device with hid_write() and read responses back with hid_read() with that handle and eventually close the connection with hid_close(). So the basic communication is very easy from user point of view, devil is in the details what to write and read :)

Read More...

I use sftp to transfer files myself so haven't tinkered with the FTP upload. It seems to be using TLS or SSL for the ftp connection and the common name of the certificate it receives from the server doesn't match "astrometeor.com" it's trying to connect to so it aborts the connection. The name could be "somehost.astrometeor.com" for example so it doesn't match. If you connect lftp manually from the PI to your server with FTP, does it give the same error? There seems to be a configure option in lftp to ignore the certificate error (ssl:check-hostname), but fixing it in the server end or connecting to the host name in the common name would probably be best anyway. Or use sftp, doesn't even need password if you have keys configured :)

Read More...

Good to hear you got it working. Yes, the settings are a bit spread around due to the way the system works. There is a main capture program (naturally called "capture" :) what is started by allsky.sh when the service is started. Capture then runs various shell scrips in /home/pi/allsky/scripts directory after each capture, at end of night and so on.

Main configuration file with paths to the others and options for shell scripts are in /home/pi/allsky/config.sh which you found. Camera settings and other parameters to the main capture program are in /etc/raspap/settings.json by default which is what the web gui modifies, the path is set in config.sh as well. Third file is /home/pi/allsky/scripts/ftp-settings.sh with settings for user name, password and so on used for uploading the files to remote server.

Unfortunately the installation location is hard coded in quite a few of the shell scripts so it's easiest to keep the install directory as /home/pi/allsky. Many of the options also require restarting the allsky service (sudo systemctl restart allsky or reboot of the Pi) to take effect as it only reads the configuration files once. So in case some change in options doesn't seem to have effect, reboot first before wondering about it more :)

Read More...

ZWO camera SDK is included in the allsky repo, so you don't need to download it separately, but only for ARM platforms which is why the warning is there. It should compile quite easily to other platforms too, but requires the ZWO SDK libraries and some modifications to the Makefile. Testing has been only done on Raspbian so anything else is wild west territory :)

Read More...

The standard Raspbian currently is buster, older ones don't support Pi 4 so you most probably have it so it's good to go. I've used 120MM-S and 178MC, hard to say which one is better. Mono camera is more sensitive, so it's easier to spot clouds, which is what I mostly use it for as it's monitoring my remote observatory. Color camera has its own charm as the images look nicer. Also depends on the lens you are going to use. Currently I have the mono camera installed with a 180 degree fish-eye. The 120MM-S, or MC-S if you want color, both fit in your budget, probably with a wider lens too. The standard lens for 120 is quite wide, about 150 degrees, but doesn't quite cover horizon at my site so I got this one for it www.aliexpress.com/item/32911136144.html Stock lens for 178 is a bit wider, but doesn't give quite 180 degrees view either.

Read More...

Noticed your controller has quite low azimuth resolution, mine has 3240 steps per revolution so it can point at almost 0.1 degree accuracy, yours can only with 2 degrees though it shouldn't matter if the position is accurate (no backlash etc).

My equipment is in the signature, dome syncing parameters are:
Dome radius 1.0m
Shutter width 0.6m
N displacement 0.04m
E displacement 0.0m
Up displacement 0.2m
OTA offset 0.33m
Auto sync threshold 3 degrees

Read More...

I used quite approximate value for slaving for a couple of years and they worked ok for the most part but had issues near zenith. When upgrading my mount, I decided to do a bit more systematic calibration of the values. I couldn't accurately measure RA/DE axis intersection distance from dome center so I entered rough estimates as the parameters and followed somewhat systematic trial-and-error method. My dome controller has encoder so the step count and thus dome azimuth control is accurate and mount pointing model was fairly accurate too.

First I pointed the OTA at north-ish horizon on both pier sides and adjusted OTA offset and W/E displacement until the dome opening was centered on both sides. Then I pointed the OTA at east horizon and adjusted N/S displacement until the OTA was again centered in the opening. At this point only the up/down displacement was left and I adjusted that by pointing the OTA at a aroud 45 degree angle south-east and again adjusted until OTA was centered. After this I haven't had issues pointing anywhere in the sky, including zenith.

Read More...

Not for this, this is a completely standalone project, you should have standard Raspbian buster installation and just run the install.sh script which installs some dependencies, compiles and installs the software and makes it run automatically on boot. There is also a script in gui/install.sh to install the web gui that makes it easier to configure and shows the live view and archives.

Read More...