I can’t tell if this feature request has already been submitted or nixed. Searching for “indi” brings up a lot of “indicat*” words, and the only valid mention I found was about SGP on Linux.
Although support for INDI is primarily found on Linux and OSX, it’s by no means relegated to those platforms. A small smattering of Windows-enabled apps do support it including PixInsight and Carte du Ciel.
It would be tremendous to be able to have SGP connect to a remote (or local) INDI server. I’m currently connecting to an INDI server running on a Raspberry Pi and it’s terrific being able to connect to an ultra cheap device through the network. It would be even better if something like SGP was on the other side!
A little off topic, I am running SGP, ASCOM, and all my imaging capture and plate solving sw on a small (deck of cards sized) Windows10 PC called a Kangaroo. It is only 2GB RAM and 32GB SSD. but has an internal battery, and cost me $129 including the windows operating system, and expansion dock, for the USB ports, external 12V supply. I velcro it to the OTA, with a micro USB hub and connect to the camera, guider, mount, and focuser with short (18") usb cables. The Kangaroo has built in wifi, so I just connect to it with VNC from my laptop in the comfort of the Tent, RV, or Home. It also has an external SD card slot, where I store my captured images, and mount that disc over the network to access the files from the main PC. SGP works great with that device. Granted, indi support with a Pi would be a little cheaper solution, and you can have the processing power of the main PC , relying on the indi server for local device control only. But in the mean time…
SGPRO would be a good front end to an INDI server like EKOS. I’ve looked into a complete INDI based system but I’m struggling getting all the LINUX drivers for my devices. I looked into a KANGEROO running Windows so that I could remote desktop which is what I do at the moment. There is a Windows Wrapper for ASCOM called WINDI but you still need an INDI client to do the scheduling.
Actually, I think there is a more expedient solution. All you need to do is support the INDI client/server interface (XML) to speak to a remote indi server that is running the drivers. There should be no other driver issues, and a bimodal SGP (INDI or Local Ascom) would be a killer solution.
In fact, while the INDI drivers are pretty mature for most devices now, there is also the INDI server for Windows, that is an INDI Server installed on a Windows system that is running ASCOM, and just bridges to the ASCOM drivers on that machine.
By doing this, the remote (scope side) system can be anything that is running an indi server, like a small widows/ascom laptop, NUC, or proprietary HW like a Kangaroo (ust for example). SGP can be ANYWHERE, connected via TCP/IP.
By Anywhere, this could mean at the end of a ethernet cable in ad hoc mode, that would provide far greater distances than the USB method most imagers use. Also, by using a small access point or router, the user can connect via wifi, or even the internet for connection ANYWHERE IN THE WORLD.
I own SGP and really like the tight integration, but if you compare this client server support to the new open source KSTARS/EKOS implementation, it would illustrate the proposed implementation.
Would be really cool, today the only software that will allow me to use Nikon FW hack is trough INDI … I’ve looked at Ekos but setting up a Linux box + learning a new capture software is not something I look forward to, so a PI running only the INDI part for my camera and then SGP do the control is really something I would use.
(That’s why I started to look at the Pixinsight implementation of INDI)
/Yves
I’m assuming the driver here is cost, rather than function.
PC sticks are coming down in price and when one thinks of the total cost of our equipment with a stick that costs the same as a reasonable eyepiece, I’m struggling to understand why one would spend the effort, when it could be on additional functionality. I know its fun and cool - but given the choice - I would prefer the effort spent on more functions that just the same on an alternative platform.
The stick computers are very nice. I would suggest that keeping SGP module based so you can take just a stick computer with you in the field. Or, if you have an observatory with a full computer, you can use all the modules.
Wel the INDI driver is using gphoto to communicate with all types of DSLR camera’s and not using Nikons’s SDK that crashes with the fFW hack (the SDK crashes as it receives a frame that is larger, it includes overscan area).
So INDI works …
(the permanent Hack which is not available for my camera apparently sends the normal file resolution and reports seem to indicate that works with BYN for example …)
A big driver is undoubtedly cost – and the cool/fun factor is through the roof – but I think there’s also a separation of concerns, a new level of flexibility, and a (subjective) level of effort in maintenance.
From a cost perspective, a computing unit like the RPi is difficult to beat both in terms of hardware and software.
For those of us, me included, that have to lug our stuff outside, I don’t mind having a relatively disposable $35 RPi next to the scope. More specifically, I really don’t want to leave a laptop or NUC/PC-stick out in the field for overnight imaging. If the RPi’s board or memory card dies, it’s a piece of cake to replace and restore. The effort to replace the NUC is generally far greater in both cost and re-setting up software. If I take a trip to a remote dark site, having a redundant RPi and memory card is a no-brainer and is still less costly than a single PC stick.
For those of us lucky enough to have a permanent covered installation, the exposure to humidity and dirt and other things isn’t as much of a concern. However, getting the stuff in place to connect disparate pieces of equipment (like dome control, weather cams, etc.) gets much cheaper and, arguably, more reliable using good ol’ TCP than stringing together active USB cables or getting a good USB extender device. I wish I was in this position.
In the end, you sum it up neatly as being a choice. For my particular use case, SGP already does way more than I expect to ever take advantage of… except in how I would like to connect to my devices .
INDI shows tremendous potential. I just about wet my pants when PixInsight introduced some early modules showcasing INDI functionality. I had my rig outside in the terrible heat and humidity and mosquitoes while I was inside in the A/C, wirelessly slewing all over the sky, plate solving, and snapping images.
Exciting times! And I’d love it if SGP could adopt INDI in the future!
Sorry - still don’t get it. I use a plastic food box for the NUC/Stick - works a treat.
I get the ‘wouldn’t it be great to poke the big boys in the eye appeal’ Lets have a reality check though. When I think of the effort of getting the current device drivers to work and badger the OEM’s to deliver ASCOM etc, why would I want to throw that up in the air and get a bunch of fervent folks (ranging from software amateurs to professionals) to come up with a replacement. That just divides the effort and outlay. To what end? I only need one working system.
I also get the appeal of designing stuff - I have done hardware and software myself, but only to fill a hole that is not covered by something else. If someone could demonstrate it would be more robust and more future proof than existing systems, then fair-enough. I want to spend my time imaging, not debugging cool stuff.
You sure don’t get it, and guess what, that’s totally fine! I don’t get why you wouldn’t want it, and that’s fine too! That’s why it’s a choice.
What INDI fills is the massive hole in ASCOM related to distributed connectivity. ASCOM was a godsend and unified the control and behavior of all our gadgets and devices and made everything easy!.. until we wanted to do it across the network. INDI was designed from the ground up with that in mind.
It sounds like you have your working system, so you’re set, and as a bonus you don’t have to throw the current progress up in the air! But suggesting that exploring alternate methodologies and technologies is a waste of time because it “divides the effort and outlay” is depressingly short sighted. Consider INDI to be healthy competition for ASCOM, addressing a need that hasn’t been met. Perhaps this’ll spur the ASCOM working group to design in transparent network distribution for the next major release!
If the SGP devs choose to disregard INDI support as a potential new feature, oh well… it was worth a shot and it doesn’t hurt to suggest a feature request! When future software is inevitably released that does support it, myself and others may choose to use that instead (if it’s a worthy replacement for SGP). Yay, competition!
I can totally appreciate you want to spend more time imaging. I do to. At the same – and I suspect I’m in the tiny minority – I enjoy the instrumentation just as much as capturing photons. Getting all this stuff working together smoothly and in the way I want is just as interesting!
I look at INDI as a benefit; kindof like when SGP came around and stirred the pot with regards to the older imaging programs. INDI will force ASCOM to remain relevant. I like using smaller/cheaper devices for my imaging computer because inevitably they fail due to exposure and need to be replaced.
But, I can appreciate having a full computer too. I dislike having to move all my files from one computer to another.
Anyways , nice job on keeping the thread on topic. It’s awesome when we can discuss these things and have differing points of view.
Sorry - I thought ASCOM Web delivered the same interoperability between PC and mobile platforms over the web using JSON.
I did not suggest that. Many astro companies are small and do not have huge resources. They are dependent upon a few individuals to do their coding. SGP is one of them. With a list of feature requests just gone through a poll, I was suggesting that it might divide those resources. I also went on to say that if it demonstrates an operational advantage, other than saving a few quid on a processor board, then fine. I have four patents to my name. I know about innovation but I also know about the hard reality of making a business with those bright ideas. I am one of those to love playing with new hardware and up for a challenge. The biggest challenge of all is getting astrophotography to the masses, with less customer operational error and improved ease of use.
Does INDI achieve that? or does it create a different set of (interesting) issues for some and frustration for others.
Hmm… What’s ASCOM Web? Do you have a link or two I can check out? Google gives back a lot of references to the ASCOM web site, but nothing related to what you seem to be referring to. Does it go by a different name?
I apologize for suggesting that I thought you were being short sighted, that was my lousy interpretation of the comment. I do recognize that SGP and virtually all the other astro companies are tiny and can’t fulfill all their users whims. This particular forum is a place to give voice to our whims no matter how whimsical others may find them.
In regards to the feature request poll (unless I’ve missed one), I’m fairly certain that INDI integration wasn’t anywhere on the list. That clearly shows that INDI isn’t anywhere on the radar (yet) for Main Sequence Software because it’s not (yet) seen as relevant for its users. So, I wouldn’t worry to much about getting resources divided up. If at some point INDI makes it onto the feature list for a future release, I’ll gladly take advantage of it!
It’s my belief that there’s a clear operational advantage to INDI as well as a major cost benefit, which is what got me so interested in it in the first place. It very definitely also creates a set of issues and frustrations, but that’s normal. ASCOM does, too. This forum is filled with issues related to interoperability between ASCOM and SGP. Whether those are issues with ASCOM or SGP doesn’t matter. It’s not all smooth sailing, and probably never will be no matter how mature the software is.
Unless I’m pulling what you said above out of context (and I probably am), INDI gives the option of where you’d like your captured images to be stored: The device hosting the INDI server software, the client (full computer), or both!
