Quantcast
Channel: Recent Topics - INDI Forum
Viewing all 14131 articles
Browse latest View live

At an impasse with CGEM/NexStar USB - by: edh

$
0
0
Has anyone been successful using the Stellarmate with a CGEM or any other Celestron mount with a NexStar hand controller with a USB port connection to the Stellarmate?

The core issue that is blocking operation at this point is what appears to be a conflict in the NexStar hand controller with the USB connection to the Stellarmate or a USB hub.

My equipment:
Raspberry PI 4B, 3B, 3B+
Stellarmate 1.4.4
USB Hubs: D-Link DUB 1340, Sabrent HB-U390, Amazon Basics 4 Port USB 3.0 HUB, High Power Supply System USB3.0 HUB
Mount: Celestron CGEM with NexStar USB hand controller with the latest firmware versions
Operating in local mode with 15 inch 1080P display, wireless keyboard, USB mouse connected
Using 3.5 amp power supply supplied with the RPI4 and the USB hub supplies provided with the hubs

The latest testing has been primarily with the RPI4. It boots very inconsistently and sometimes boots then restarts multiple times before stabilizing. Frequently the USB devices must be disconnected to reboot successfully.

After it has rebooted successfully, it often takes many attempts to connect with the CGEM mount.

The CGEM + NexStar hand controller operate consistently with the hand controller not connected to the Stellarmate/USB hub. When the hand controller is connected to a USB hub or the RPI directly, it does not operate correctly. Commanding motion from the hand controller always results in "No Response 16 or 17" errors, indicating failure communicating with the motor controller. If the hand controller is not used for commanding motion after the USB connection is made, and if the PC connection is made successfully, then the Stellarmate sometimes controls the mount correctly until the "No Response 16 or 17" error is displayed. On one occasion operation was successful for an extended period of time until the Stellarmate was shut down to try another configuration. I have not been able to repeat that success. Testing has been done with multiple USB cables to rule out the possibility of a faulty cable. With one of the cables I cut the 5V wire since that appeared to be connected directly to the 5V power in the NexStar hand controller that was supplied from the mount head. Testing has also been done with a 12vV to 5V converter capable of supplying 5 amps. The supply voltage was monitored with a digital voltmeter.

I have discussed this issue with Celestron technical support. They concluded the problem must be in the Stellarmate. I have requested to be connected with a contact in the NexStar hand controller design team to ask for assistance in diagnosing the problem. If the cause of the problem can be found, I may be able to devise a solution that could be implemented outside the hand controller. I have not received a response yet.

The core problem is that something in the USB hub or the RPI interferes with the communication from the motor controller to the NexStar hand controller. I really want to make this work and am willing to spend some time and effort resolving the issues. All suggestions would be appreciated.

Ed

Celestron NexStar Evolution Driver on CGEM/SkyPortal Equatorial Mount - by: cao14

$
0
0
Hi,

I am using the Celestron NexStar Evolution driver on a Celestron CGEM mount using the SkyPortal WiFi module. The other Celestron NexStar driver does not support WiFi.

I am successfully connected to the mount using the access point mode (port 2000) and can even control the mount (slew, goto, park).

The only problem, the driver thinks the mount is in Alt/Az mode.

Is there any way to switch the driver to the CGEM's equatorial (Eq North) configuration?

Thanks in advance for any help.

Unexpected shut down of KStars and Ekos, but not Indi server - by: Avocette

$
0
0
Running KStars/Ekos/Indi on my Raspberry Pi 4 headless as a WiFi hotspot, and linking in through VNC Viewer on an iPad. Most of the things I want to do work well (better not say ‘perfectly’!) but there are occasional crashes. Specifically in Polar Alignment I have been struggling to better see the reference star against the cross hairs at the end of the correction vector. I tried the ‘zoom to fit’ button in the Alignment Vector window, and this shut down KStars and Ekos, leaving behind ‘an Indi Server’ still running. Of course this means Parking the mount and running the process again.
I subsequently located the ‘full screen’ button in the main Alignment window, and found that this does change the size of the Alignment Vector window, but not the size of the image within it, although tapping a couple of times on the ‘zoom in’ button makes the Alignment Vector window content a good size for the adjustment operation.

I’m not sure if there’s a further bug in the way the Ekos ‘minimise window’ button also minimises the main KStars window?

Many thanks to the authors for this great software!

Opening FITS from file manager opens new instance of KStars - by: freiform

$
0
0
Hi,

I am sure this is a trivial one, but when I open a fits from the file manager (Dolphin, KDE, Manjaro), a new instance of Kstars is started from which a FITS Viewer is displaying the image. Any ideas where to configure this properly so an already running KStars/Viewer is utilized?

Thanks
Sven

macOS 10.15 and KStart/Ekos Distribution and Notarisation - by: Psamathe

$
0
0
As I understand it, imminent macOS release 10.15 will require all apps are "notarized" in order to be installed.

Is KStars/Ekos for Mac currently notarised or plans to make it notarized (or are there ways round it)?

I'm uncertain what notarization involves and to me it sounds like a retrograde step. There are rumours that the requirement might be slipping and wont be introduced immediately on 10.15 release but I've no idea as to the reliability of these rumours.

LX200 GPS custom tracking - by: Kaban

$
0
0
Hello.

I am using INDI with a LX200GPS. When i choose the driver, i select LX200 GPS.
I INDI here is an option to choose the tracking between sidereal, lunar or custom.
I want to choose custom as my mount is tracking a bit slowly, but once chosen i have no idea on where do i write down the desired tracking rate.
I can do it in the Autostar hand pad, but of course i do not want to have the Autostar hand pad connected as i will be using the telescope remotely.

Any help on this one?

Also, i have another question. I did not find any way to do a PEC training with Kstars or PH2. As in the previous issue, i can do PEC training through the Autostar hand pad.
Is there another way to do it apart from the Autostar hand pad?

Thanks.

David Cejudo.
Observatorio El Gallinero.
El Berrueco, Spain.

Ekos restarts exposure sequence after meridian flip? - by: El Corazon

$
0
0
Last night I had an issue I have never experienced before.

I programmed the scheduler to image M31 in Ha, S2 and O3.

Meridian flip occurred automatically after the 28th exposure of the S2 sequence. However, the frame counter went back to 0 for the S2 sequence, i.e. the exposure sequence started all over again for S2 only (it did not restart Ha, which had already completed).

I have always had 'Remember Job Progress' unchecked in the past and this has never happened before. I wonder whether during one of the most recent revisions of the scheduler something got changed there and now the currently running exposure sequence restarts.

Has anyone else seen this?

Using KStars 3.3.6 on Ubuntu Mate and a mini-PC.

Jo

Autofill in mosaic job creator - by: jnowat

$
0
0
Maybe this is already functional, and I only haven't had enough experience with it- personally, clouds and rain have taken over twice when getting started with the tool over the past few nights.

We have to add scope focal length, field rotation/ position angle, camera pixels, and pixel size- since this is all acquired from the first capture and solve, is it possible to auto fill this data into the Mosaic Job Creator window?

It feels simple in theory, but I'm no coder by nature.

Best,
Jacob

QHY174M-GPS - GPS support - by: paotg

$
0
0
Dear all,

I have now a QHY174 with GPS receiver included, but there is only a single Windows software (SharpCap) that appears to support the GPS insertion in the SER file.
I tested the camera successfully with INDI, but of course there is no GPS support for the camera. Of course this feature is very specific, but it would make INDI a very powerful tool for time-critical applications (such as stellar occultations).

I am ready to offer my collaboration for testing, if somebody can take some time to include the required feature in the driver.

The only description available about how to decode/use the GPS data is provided here (about half-way through the page, "Programming with the API"): https://www.qhyccd.com/index.php?m=content&c=index&a=show&catid=30&id=190

I hope that the authors of the QHY driver will be able to help. Please let me know.

best regards
Paolo

Ultimate Powerbox v2 - connectivity issues? - by: cl330b

$
0
0
Hello,

Ubuntu 18.04
indi 1.8.0

Has anybody purchased the UPBv2 yet? If so, has anybody been able to successfully connect to the device through Ekos? I can connect to it through another open source piece of software. Please let me know if you have been able to connect to this new device. Thanks.\


cl330b

EOS 1/4000 shuuter speed - by: rishigarrod

$
0
0
I would like to be able to take my bias frames using Ekos.
My EOS 6D has a max shutter speed of 1/4000th which would be 0.00025 but the UI won't let me fill this value in. After the third zero after the decimal I cannot enter any more.

Am I missing a setting where I can set the max shutter speed?

KStars: overlay your own finished images - by: jnowat

$
0
0
This is a stretch, and would likely be difficult to implement, but by no means impossible. I think it needs to be mentioned in detail as a matter of the record on this wishlist.

As an astrophotographer (I don't feel privileged enough to call myself an astronomer, using all of this automation for images, like I do), my personal goal is to capture the sky, and edit the images to my liking, forever preserving my project(s) and the memories of the obstacles, work, and time spent it took to achieve them.

I've found some programs which allow one to overlay their own images, but they are far from intuitive, and they aren't programs which I would use to control my setup. Maybe this is doable in Kstars already, but it certainly isn't straightforward.

What I envision is an addition to KStars that allows the program to look to a folder which contains 1) a finished image which will be overlayed, in TIFF or jpg or whichever format is most applicable, and if necessary, 2) a corresponding FITS image of the same field which allows KStars to assign the correct position of the image and align it as perfectly as possible against the planetarium (I've noticed that with DSS overlay, there is often stars slightly mismatched.

Naturally, this would be a project to write, but could likely be fashioned using existing code which is currently used to implement DSS overlay and the like.

To me, this option would be useful because I could look at KStars and decide, without hesitation, what non-overlayed portion of the sky I wanted to image tonight, or even what portion I though might need more exposure.

I think, also, that such a function- when easily handled by the average user- would set KStars apart even further from other planetarium softwares. I think others would quickly work to implement their own overlay functions as a results of seeing just how awesome it is in KStars. Even if I wasn't using KStars, a function that allowed me to overlay my own images in a simple manner would cause me to download KStars and give it a try myself.


I'm going to feel somewhat embarrassed if this topic has been brought up before, or is already achievable with a little know-how, but I couldn't find much by searching and, like I said, I think it needs mentioning.

General thoughts? How would you make use of this function, if at all?


Best,
Jacob

Stellarmate vnc black screen problem - by: khobar

$
0
0
I have Stellarmate on a Raspberry Pi4 I've been building up, and now something has gone amiss. I was trying to set the Stellarmate up so it would be on my home network and thus see the Internet and get updates, etc. I was in Stellermate app and changed the setting from "Hotspot" to "Infrastructure" but was confounded by the device's refusal to scan for SSID's to join. I tried it inside where it's closer, and same thing. But I made the mistake of closing the VNC session in that mode.

Today, I connected the Stellarmate to the wired network, and checked my router, and there it is - twice. But while I can "connect" to either the wired or wireless IP, I get nothing but a black screen. I tried the other IP and same result.

Is there anything I can do?

Thanks!

Ekos/INDI ports over port forwarding - by: jnowat

$
0
0
Today I found time to set up port-forwarding instances on the router to which my SM on RPi3 is connected. I used X (obviously not posting the IP and port) as the external-facing port for port 7642 on the Pi3 in one instance, and the second instance I used Y for port 8624.

I connected a couple times, on a Windows10 laptop using this address while I was connected to internet at the site; in Ekos, I chose the IP, listed X where 7624 is normally, and Y where 8624 is normally. It worked more than once.

When connecting in the same way, using two, both different from the first, Windows10 machines- one from a wired internet connection, and another from a mobile hotspot connection- KStars give me the error "Connection to INDI server at host IP with port X failed."

Going to the indiweb manager with IP:Y opens up the web server, where it has filled in the port text box with "X", instead of 7624. I then edit this field to read 7624, stop indiserver, and start it again. I then can connect to indiserver on the SM through Ekos.


So... is this business as I will handle it always, or is this an issue I'm not attempting to use correctly? I realize it's not the most secure method to connect, but I honestly couldn't find very much in regards to port-forwarding specifically for Ekos, INDI, SM, etc.

Might anyone have suggestions for me? I don't necessarily mind connecting in this manner, but 1) the workaround leaves me guessing that I have gone about the process wrongly, and 2) it worked on my laptop at the site (I am sure it was not on LAN) and I don't think it should be any different if I'm still using the public IP at the site, though I'm obviously no IT wizard.

Thanks for any help in resolving and/or simply understanding the matter.

Best,
Jacob

Helpful Info when Having Astrometry (local Platesolving) problems - by: stash

$
0
0
Here I was doing the normal Platesolving when things started to go a bit wrong and Platesolving (any type - ASTAP,Astrometry local etc) starting failing - some weird errors and even core dumps from segmentation failures.

Anyway after pulling all of the little hair left out I found the problem - on 1 Index Platesolving gave some saying "Invalid Star ID" - trouble is unless you scroll through the whole log you wouldn't necessarily see it as you get the segmentation fault or iotclt fault info. It appears the index had become corrupted ( I did have a lock up once - but reading ! ) so replacing that single index cured the problem.

Still perplexed / worried why reading should corrupt files on a newish SSD .

So if you have a weird set of errors (think I had error 139 and error 256) and /or segmentation fault / core dumps when running platesolving - check the log closely for any "Invalid ID" it might help :-)

Perhaps this might help others !

RAMDisk with the Pi4 4GB - by: kaydubbed

$
0
0
I utilize less than a quarter of my RAM during imaging with my Rpi4 using SM-OS and was thinking I could use that unused RAM for a RAM Disk to give me more speed for some applications. I know it is a 'temporary drive' but I wanted to brainstorm ways to utilize that extra RAM. A 2GB RAM disk that held all temporary frames would be nice to start, so platesolving, image preview, focusing frames, would happen on the RAM drive and be exponentially faster than using the SD card. I could also use the RAM drive for lucky imaging with smaller sensors, although it would certainly fill up quickly. I suppose I could script the RAM drive to tail and copy to a slower flash drive or external SSD drive. A smart enough script could allow full-frame lucky imaging on a humble Pi4 that would take the exposure, save it to the RAM disk, and then copy the FITS/RAW to an external flash/SSD/NAS in the background.

This is really just a question of tinkering and not a feature request. Ideas?

Losmandy Gemini fails to connect properly - by: jnowat

$
0
0
It connects, fails, tries to reconnect, then flashes and disappears completely from the panel. When it wasn't even connected, the panel would still show it there. Now it's just putters out.

[2019-09-30T11:33:56.770 Pacific Daylight Time INFO ][ org.kde.kstars.ekos] - Ekos received a new device: Losmandy Gemini
[2019-09-30T11:33:56.785 Pacific Daylight Time DEBG ][ org.kde.kstars.indi] - < Losmandy Gemini >: < CONNECTION >
[2019-09-30T11:33:56.785 Pacific Daylight Time DEBG ][ org.kde.kstars.indi] - Removing device Losmandy Gemini
[2019-09-30T11:33:56.801 Pacific Daylight Time DEBG ][ org.kde.kstars.indi] - INDIListener: Removing device Losmandy Gemini with unique label ""
[2019-09-30T11:33:56.801 Pacific Daylight Time INFO ][ org.kde.kstars.ekos] - "Losmandy Gemini is offline."
[2019-09-30T11:33:56.817 Pacific Daylight Time DEBG ][ org.kde.kstars.indi] - Received new device Losmandy Gemini
[2019-09-30T11:33:56.832 Pacific Daylight Time DEBG ][ org.kde.kstars.indi] - INDIListener: New device Losmandy Gemini
[2019-09-30T11:33:56.832 Pacific Daylight Time INFO ][ org.kde.kstars.ekos] - Ekos received a new device: Losmandy Gemini
[2019-09-30T11:33:56.848 Pacific Daylight Time DEBG ][ org.kde.kstars.indi] - < Losmandy Gemini >: < CONNECTION >
[2019-09-30T11:33:56.848 Pacific Daylight Time DEBG ][ org.kde.kstars.indi] - Removing device Losmandy Gemini
[2019-09-30T11:33:56.864 Pacific Daylight Time DEBG ][ org.kde.kstars.indi] - INDIListener: Removing device Losmandy Gemini with unique label ""
[2019-09-30T11:33:56.864 Pacific Daylight Time INFO ][ org.kde.kstars.ekos] - "Losmandy Gemini is offline."


I'm so close, here!!


Using latest builds on both SM with Pi3 and KStars remotely.

Poor focusing results with lacerta MFoc - by: the.cakemaker

$
0
0
Learning how to use my new Lacerta Mfoc-System. This time no problems with getting it to run. It worked from the first day on.
But i am not sure about my settings in the focusing module.

the system works and tells me that focusing was succesful in eather 3 or 4 or whatever iterations. But it is just NOT in focus.
So i am trying around some time with different settings.

I thin i am right that in the beginning i have to set it ALMOST in focus postition manually, to give the system a chance to find a star by its own, right?
OK, after done so i set the maximum steps to 500, tolerance 0,1 step size 100.
System works and ends somewhere, telling me its in fokus, but its naturally not, just NEARER than before.
The i reduce the maximum steps and the step size down a bit like to 50 and 10 steps.
This causes the system to work in a smaller "path"
I did this yesterday until maximum working distance of 50 steps an da step size from one.

After that i hit AF. The system starts to move in a bit, out a bit, like it should, and told me its in focus.
So i started a testrun on m34, whole night by scheduler including refocusing after 60minutes.

I did not check the focus on a debayered picture because its full moon anyway, its only testing...

But too bad, like i was afraid of, the system was far from focus...

So has somebody an idea? Another setting maybe? anything?

You can see the defocusing easy by looking on the spikes on this screenshots from the center. This is a debayered singleframe made with my Moravian G2-8300 color.

cheers, Niki

[Solved]Ekos/INDI ports over port forwarding - by: jnowat

$
0
0
Today I found time to set up port-forwarding instances on the router to which my SM on RPi3 is connected. I used X (obviously not posting the IP and port) as the external-facing port for port 7642 on the Pi3 in one instance, and the second instance I used Y for port 8624.

I connected a couple times, on a Windows10 laptop using this address while I was connected to internet at the site; in Ekos, I chose the IP, listed X where 7624 is normally, and Y where 8624 is normally. It worked more than once.

When connecting in the same way, using two, both different from the first, Windows10 machines- one from a wired internet connection, and another from a mobile hotspot connection- KStars give me the error "Connection to INDI server at host IP with port X failed."

Going to the indiweb manager with IP:Y opens up the web server, where it has filled in the port text box with "X", instead of 7624. I then edit this field to read 7624, stop indiserver, and start it again. I then can connect to indiserver on the SM through Ekos.


So... is this business as I will handle it always, or is this an issue I'm not attempting to use correctly? I realize it's not the most secure method to connect, but I honestly couldn't find very much in regards to port-forwarding specifically for Ekos, INDI, SM, etc.

Might anyone have suggestions for me? I don't necessarily mind connecting in this manner, but 1) the workaround leaves me guessing that I have gone about the process wrongly, and 2) it worked on my laptop at the site (I am sure it was not on LAN) and I don't think it should be any different if I'm still using the public IP at the site, though I'm obviously no IT wizard.

Thanks for any help in resolving and/or simply understanding the matter.

Best,
Jacob

When autofocus pick a galaxy... - by: jnowat

$
0
0
How in the world should I proceed? It's in the scheduler workflow... so, would I normally abort? I'm going to let it do it's thing, as we say, and see the first Luminance frame, but wow, I had already brought everything to a fairly decent focus- I just though it reasonable to make sure that autofocus would work with the entire flow, which is sort of necessary for long(er) sessions and/or multiple targets and/or refocusing, generally. I realize there might not be a method to avoid this per se, but how would you proceed? I'm just curious, when it comes down to it. It came within 10 steps of my actual "manual" autofocus, so I guess it was acceptable for NGC 7331.

This is my first schedule/sequence with my entire setup, running completely remote. I couldn't be more excited about it- sort of shocked that I'm at this point. Clouds will be here within 1-2hrs, however, but hey, I made it! ....so far :)
Viewing all 14131 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>