wimvb

The problem isn't so much the server/client as it is the hardware connections. Suppose you have 2 mounts/scopes with 2 focusers and 2 cameras. In essence 2 completely independent systems. It wouldn't make sense to control these from one server and one client. It would just be messy. The easiest solution would be with each system its own server and client. The 2 clients could run on the same windows/linux computer. But the server has direct hardware connections, and connecting everything to the same box is just asking for trouble, imo. Otoh, if you have a dual rig with one mount and 2 scopes and cameras, one camera would be master (used for pointing and maybe oag) and the other slave. You could then probably use one server and two clients. Client A has the mount, guiding and one camera. The other client (B) just a camera (and focuser). In Ekos, you can select the camera in the sequencer. You just need to time exposures on both such that no exposures on B are unnecessarily lost due to dithering. The exposures can be of different length, but need to be in phase. The shorter exposure camera would need wait times in order to stay in phase. Or you would accept lost exposures. At the moment there's no functionality in Ekos for two cameras and imaging sequences in one client, afaIk. I don't know if it's possible to add this functionality through either python or scripting. As mentioned before: ask Jasem on the INDI forum.

In essence with a dual rig, you have two cameras, two focusers, (two wheels), but only one mount. So you could start one server with all these drivers. The problem is on the client side. In Ekos you can only have one imaging session going. You need two instances of Ekos, one for each camera. I think that I would set up two completely independent RPi's, and two independent Ekos sessions. One RPi with cameras etc and mount. The other without mount. Then two clients, one for each server. Set up a sequence on each client. Then start both sequences. Captures should only be seconds apart. If you use dithering, add a delay. Have exposure lengths the same on both systems.

Jasem Mutlaq (INDI) runs everything off a Raspberry Pi, afaIk. A Rock64 will even allow local platesolving. Do you have info on which linux distributions work with that firefly board?

Windows also has different flavours, just only one at a time. It seems that every time they release a new version, you have to re-learn things. Windows 3, CE, ME, NT, 95, Vista, XP, 7, 8, 10, etc, etc. What happened to 9, btw? In linux, at least you choose one and stick with it.

Yes, support of these boards is their weak point. The (only?) stable platform seems Raspberry Pi. I hope that usb3 is not too far off. I have 16.04 installed and working. Both my eq3-pro and az eq6 function. Also Moonlite compatible focuser, zwo filter wheel, and two zwo cameras. The only problems I have encountered are losing wifi on my laptop, or the Rocks being to far away and wifi getting slow (dlink dongle).

ZWO ASI174MM-Cool, 2.3 Mpixels, filesize 4.6 MB. I only do dso imaging, so I've never timed frame rate. But when I shoot flats at less than 1 s exposure time, it's quick fire. Download time to my Rock sbc is definitely less than half a second, I'd guess. http://indilib.org/forum/embedded-indi/2762-indi-on-the-rocks-a-rock64-to-be-exact.html?start=48#23165 During an imaging session I save frames locally to the server (Pi or Rock), including 25 flat frames/filter. I have no problem storing several sessions on the card (32 GB). I connect to the INDI server from kstars on windows. For PHD, I use windows remote desktop to open a desktop session. The rest is done "headless". Anyone wanting to use INDI but not the tinkering involved, either the new ASIAIR from ZWO or the StellarMate seem to be good plug-and-play alternatives.

I think it is. I'd rather lose a € 35 raspberry pi due to dew or frost, than my laptop. The raspberry pi can handle cold, but how does a laptop lcd screen handle -20 C? The raspberry pi hardware is quite adequate for controlling the scope and camera, including guiding. The bottleneck is usually the network speed (raspberry pi shares usb and ethernet on the same chip).

on which OS? ?

INDI/Kstars is software, but also equipment control, not just imaging. If you want a beginners thread, maybe the beginners' equipment subforum would be a good place. As Jasem Mutlaq remarked on the astro imaging channel, it's for those who don't mind a little tinkering. Imo, if you can set up the hardware, you can install the software. (Or buy a StellarMate.) Installing INDI under ubuntu isn't difficult, and there are guides. Some on this forum: And very similar on a Rock sbc

Welcome to the wonderful world of linux and indi. Most hardware is supported. The indi site has a list, and the forum is very helpful. http://indilib.org/ http://indilib.org/devices/telescopes/celestron.html http://indilib.org/devices/ccds/starlight-xpress-ccd.html

But the light that makes up the Bahtinov pattern all comes from the star, not from clouds.

A simple message "We do not ship overseas" would have been easier. I wonder how many domestic sales this nifty solution costs them.

I had to reread the post as well, just to make sure. From the full frame it seems that spacing is slightly off, but should that give the bent spikes on a star in the centre of a frame?

AfaIk, this was with a zwo camera, which doesn't have a mechanical shutter. But the suggestion to also look for other causes is a valid one. Spacing offset should be visible as elongated stars towards the corners. My first guess was actually seeing or turbulence. But then the curving would be different between frames.

I agree, service is excellent. Many a commercial business could learn from that. When I switched from raspberry pi (32 bit) to Rock (64 bit), it only took a few days before software was available in 64 b after I made the request.

Yes, found that out to. Indilib is linux based. Windi (indi server for windows) is only a wrapper that uses the ordinary windows ascom drivers, as @kens wrote. You can run indiserver and ekos/kstars on the same (linux) machine, and scrub windows completely. This works even with an ordinary raspberry pi. If you run the server on a Pi, and ekos/kstars on windows, you lose control if the connection is broken. But if you run everything on the same machine, and control that from a remote desktop such as windows remote desktop or Teamviewer, a lost connection will not stop a sequence. If you lose the connection, you simply set up a new one. I'm looking into this atm. I plan to use one Rock64 (raspberry clone with usb3) for mount control and guiding, and one for focusing, image acquisition and ekos/kstars. By using two computers, I can avoid having to use a usb hub.

This is from cloudmakers.eu, the developers of indi server for windows: INDI Server for Windows is a wrapper and INDI server for ASCOM drivers. Still only ascom. I thought they had come further with development. But I guess, for someone who doesn't want to leave windows, and still wants the functionality of ekos/kstars, this might be an alternative. As long as there are ascom drivers for the hardware.

Do you know if this supports the same drivers as the linux version? Btw, the windows version is called (surprise, surprise) windi. Actually it was, it's now called INDI Server for Windows. And I have no idea if support is at the same level as for the linux version.

Yep, indi/kstars is wonderful, because everything is "under the same roof". I use it on a raspberry pi clone, so I don't need to take my laptop outside. Support is also excellent, from the indilib forum. The only problem is that once you have it, you want to build a fully automated obsy, to use its full potential.

A very nice collection. Will you be adding colour next season?

Same here. I used a sw dc motor focuser for my electronic focuser sollution. I had to write a piece of arduino to make it compatible to the Moonlite protocol. The electronics and software may be the easier parts if you don't have a metal workshop. The dc motor sollution has a lot of backlash, and I want to redo it with a stepper motor. Getting the motor in place is the biggest challenge.

Gently bend it back, then recollimate. Image a bright star to see how it affects the diffraction spikes.

All this duscussion about mirror cleaning reminds me I must do mine. Dew or maybe frost has created stains on the mirror. And there's also a lot of dust. Fortunately a sw 6" is easy to dismantle. Btw 1, I would never wash a mirror that is still in its cell. Water can get trapped. And last time I removed the mirror from its cell, I saw that cork spacers are used as backing for clamps. Water and cork should never go into a long term relationship. Btw 2, I may replace the black plastic mirror clips with clear plexiglass clips (diy). I want to test if that changes the diffraction. Probably not, an edge is an edge.

Btw, after seeing @steppenwolf's video on youtube, there was another video. The guy in this vedeo didn't use a plastic basin. He used his hands to wash the mirror, which was not emerged in water. He didn't rinse with distilled water, and he placed the mirror to dry on a towel directly on the bench top. Best place to get pulled off by small hands not seeing what daddy put there. Needless to say, his mirror was chipped. Ouch.

Dust and grime on the mirror cause light scattering, decreasing contrast. Only you can judge when enough is enough. But as @Stargazer McCabe wrote, with a little help from youtube videos (astronomyshed in my case), it's not that difficult. Just be gentle, and try to avoid actually wiping it. Also, have a tidy and clean workplace before you start. Good luck