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

myFP2ESP DIY focuser with wifi control - by: petarm

$
0
0
Hi all, i have started this tread as a follow on to the last few threads on the serial version of the my Focuser Pro 2 DIY project (see www.indilib.org/forum/focusers-filter-wh...html?start=144#46741 ). My understanding is that the serial version now works and a full Wifi version is close but needs some testing.

I am building the Wifi version based on the WEMOS ESP32 board (still waiting for parts to arrive). I have the Arduino code compiling. So hopefully ill have a working focuser soon ready.

If testing is required let me know.

QHY Driver: Testing required - by: Schwarze

$
0
0
Hello,
some time ago, I noticed that the temperature regulation for cooled QHY cameras is broken. It starts cooling, until the temperature is reached, and then stops measuring and regulating the temperature for the rest of the night.
Now I have build a patch, which does fix the issue, which works fine with my QHY8L camera. Before I submit a pull request, some more testing is needed. I think, following should be tested:
1. Does the change have any effect on non cooled why cameras?
2. Does the change have any effect on cooled, non regulated why cameras?
3. Does this issues exist on other cooled regulated QHY cameras, and if so, does the patch fix this too?

If you own a QHY camera and are willing to test, your help would be appreciated.


I can provide the compiled binary for 32 Bit ARM compiled on Astroberry 2.0 (Debian Buster...). It should run on raspberry 3 and 4 32 Bit, but I am not sure if it works on Ubuntu based distributions. But I could build one on a Raspberry Pi 3 running StellarMate if required.
For other architectures, I do not yet have a build environment, but at least amd64 and maybe i386 could be arranged.


For those who compile their INDI Library themselves here is the patch:

diff --git a/indi-qhy/qhy_ccd.cpp b/indi-qhy/qhy_ccd.cpp

index eeaef0dd..84fa1149 100644
--- a/indi-qhy/qhy_ccd.cpp
+++ b/indi-qhy/qhy_ccd.cpp
@@ -27,7 +27,7 @@
#include <algorithm>
#include <math.h>

-#define TEMP_THRESHOLD 0.2 /* Differential temperature threshold (C)*/
+#define TEMP_THRESHOLD 0.05 /* Differential temperature threshold (C)*/
#define MAX_DEVICES 4 /* Max device cameraCount */

//NB Disable for real driver
@@ -1778,6 +1778,12 @@ void QHYCCD::updateTemperature()
{
SetQHYCCDParam(m_CameraHandle, CONTROL_MANULPWM, m_PWMRequest);
}
+ // Temperature Readout does not work, if we do not set "something"
+ else if (TemperatureNP.s == IPS_OK)
+ {
+ SetQHYCCDParam(m_CameraHandle, CONTROL_MANULPWM, CoolerN[0].value * 255.0 /100 );
+ }
+

ccdtemp = GetQHYCCDParam(m_CameraHandle, CONTROL_CURTEMP);
coolpower = GetQHYCCDParam(m_CameraHandle, CONTROL_CURPWM);
@@ -1803,9 +1809,21 @@ void QHYCCD::updateTemperature()

if (TemperatureNP.s == IPS_BUSY && fabs(TemperatureN[0].value - m_TemperatureRequest) <= TEMP_THRESHOLD)
{
- TemperatureN[0].value = m_TemperatureRequest;
+ TemperatureN[0].value = ccdtemp;
TemperatureNP.s = IPS_OK;
}
+ // Restart regulation if needed.
+ if (TemperatureNP.s == IPS_OK && fabs(TemperatureN[0].value - m_TemperatureRequest) > TEMP_THRESHOLD)
+ {
+ TemperatureN[0].value = ccdtemp;
+ TemperatureNP.s = IPS_BUSY;
+ }
+
+
+
+
+
+

IDSetNumber(&TemperatureNP, nullptr);
IDSetNumber(&CoolerNP, nullptr);


Regards

Dirk

Re:HitecAstro DC Focus - by: gilesco

$
0
0
I posted before under another topic about a patch I had written for the HitecAstroDC Focuser: indilib.org/forum/general/6167-for-those....html?start=60#51148

I've made some changes to that patch, haven't tested it as yet. But main changes are:

1. Reverted to SlewSpeed rather than ISlewSpeed and OSlewSpeed
2. Brought In OutFocusFactor property, which is a multiplier that should correspond to correct the speed if the imaging train is at 90 degrees.
3. Brought in a Telescope Altitude, which will adjust that factor so that if the Altitude is 0, then the In and Out Focus speeds should be the same.

Obviously the Telescope Altitude should probably be snooped from the HORIZONTAL_COORD on the telescope, but this is getting beyond my capabilities with C++.

Any comments welcome.

EDIT: Added 2 decimal accuracy display for OctFocusFactor, 1 decimal accuracy to TelescopeAltitude.
EDIT2 : Fixed my maths

Re:Kstars v3.4.2 bombing while drivers loading on Ubuntu 18.0.4 - by: jerry

$
0
0
Note sure what the issue is,
When a profile is loaded, e.g. Simulators it crashes as shown below.
Build: 2020-04-03T19:08:19Z
Installation was originally via AstroPi3 setupUbuntuSBC.sh



Under some conditions (which don't seem consistent yet) with a preloaded profile of my own (or Simulator) via the Indi Web Manager app, I can get to to load the profile, and then things proceed normally.

Any suggestions?

Thanks
Jerry

Newbie question: for guider scope, internal ekos vs PHD2?!! - by: mhammady

$
0
0
Hello,

I'm new to ekos and the whole astrography. I wonder if someone can advise me which guider app is better to use with ekos, internal or PHD2?

I'm new to both but I have seen more videos about PHD2 and only one for the internal...

Thank you...

Re:Guiding remains suspended - by: sterne-jaeger

$
0
0
I stepped into a problem last night where PHD2 remains suspended after focusing finished. The Guide module assumed PHD2 would be in state GUIDING while PHD2 remained suspended. Here is the extract from the logs:
<code>[2020-04-09T01:04:27.017 CEST DEBG ][ org.kde.kstars.ekos.guide] - PHD2: request: "{\"id\":5783,\"jsonrpc\":\"2.0\",\"method\":\"set_paused\",\"params\":[true,\"full\"]}"
[2020-04-09T01:04:27.018 CEST DEBG ][ org.kde.kstars.ekos.capture] - setFocusStatus: 5
[2020-04-09T01:04:27.018 CEST INFO ][ org.kde.kstars.ekos.focus] - "Capturing image..."
[2020-04-09T01:04:27.243 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Focus State "In Progress"
[2020-04-09T01:04:27.285 CEST DEBG ][ org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"Paused\",\"Timestamp\":1586387067.284,\"Host\":\"star-hunter\",\"Inst\":1}\r\n"
[2020-04-09T01:04:27.285 CEST INFO ][ org.kde.kstars.ekos.guide] - "PHD2: Guiding Paused."
[2020-04-09T01:04:27.288 CEST DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Guiding" to "Suspended"
[2020-04-09T01:04:27.288 CEST INFO ][ org.kde.kstars.ekos.guide] - "Guiding suspended."
[2020-04-09T01:04:27.291 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Suspended"
[2020-04-09T01:04:27.294 CEST DEBG ][ org.kde.kstars.ekos.guide] - PHD2: response: "{\"jsonrpc\":\"2.0\",\"result\":0,\"id\":5783}\r\n"
[2020-04-09T01:04:27.436 CEST DEBG ][ org.kde.kstars.ekos.guide] - PHD2: event: "{\"Event\":\"GuideStep\",\"Timestamp\":1586387067.435,\"Host\":\"star-hunter\",\"Inst\":1,\"Frame\":1987,\"Time\":4304.212,\"Mount\":\"INDI Mount [Avalon StarGo]\",\"dx\":-0.044,\"dy\":0.088,\"RADistanceRaw\":0.025,\"DECDistanceRaw\":0.096,\"RADistanceGuide\":0.025,\"DECDistanceGuide\":0.096,\"RADuration\":23,\"RADirection\":\"West\",\"DECDuration\":29,\"DECDirection\":\"South\",\"StarMass\":127352,\"SNR\":237.03,\"HFD\":4.64,\"AvgDist\":0.12}\r\n"
[2020-04-09T01:04:27.436 CEST DEBG ][ org.kde.kstars.ekos.capture] - Guiding state changed from "Suspended" to "Guiding"
[2020-04-09T01:04:27.437 CEST INFO ][ org.kde.kstars.ekos.guide] - "Guiding resumed."
</code>

The critical point is at 01:04:27.436 where PHD2 reports a guiding step although it is suspended. This has the consequence that the EKOS guiding module thinks PHD2 is in the guiding mode and sets the status to GUIDING. Here is the code snippet:
<code>void Guide::setAxisDelta(double ra, double de)
{
//If PHD2 starts guiding because somebody pusted the button remotely, we want to set the state to guiding.
//If guide pulses start coming in, it must be guiding.
if(guiderType == GUIDE_PHD2 && state != GUIDE_GUIDING)
setStatus(GUIDE_GUIDING);
</code>

As mentioned in the comments the intention behind this is that PHD2 has changed its state, but I think this assumption is at least too general. I personally tend to remove this statement, since from my point of view this is at least the wrong place to change the state.

Any thoughts about this?

As a workaround, I suggest avoiding to suspend guiding during focussing, until this problem is fixed.

- Wolfgang

Error build source - by: pcxz

$
0
0
Hi.

[ 97%] Built target test_skypoint [ 98%] Built target kstars CMakeFiles/testfitsdata.dir/testfitsdata.cpp.o: in the function "TestFitsData::testLoadFits()": /opt/Astronomia/indi_ekos_build/Projects/kstars/Tests/fitsviewer/testfitsdata.cpp:62: undefined reference a "bool QTest::qCompare<double, int>(double const&, int const&, char const*, char const*, char const*, int)" /opt/Astronomia/indi_ekos_build/Projects/kstars/Tests/fitsviewer/testfitsdata.cpp:63: undefined reference a "bool QTest::qCompare<double, int>(double const&, int const&, char const*, char const*, char const*, int)" /opt/Astronomia/indi_ekos_build/Projects/kstars/Tests/fitsviewer/testfitsdata.cpp:66: undefined reference a "bool QTest::qCompare<double, int>(double const&, int const&, char const*, char const*, char const*, int)" collect2: error: ld returned 1 exit status Tests/fitsviewer/CMakeFiles/testfitsdata.dir/build.make:133: recipe for target 'Tests/fitsviewer/testfitsdata' failed make[2]: *** [Tests/fitsviewer/testfitsdata] Error 1 CMakeFiles/Makefile2:1795: recipe for target 'Tests/fitsviewer/CMakeFiles/testfitsdata.dir/all' failed make[1]: *** [Tests/fitsviewer/CMakeFiles/testfitsdata.dir/all] Error 2 make[1]: *** Waiting for unfinished processes .... [ 99%] Built target kstars_ui_tests Makefile:140: recipe for target 'all' failed make: *** [all] Error 2 [code] Thanks.[code]
[ 97%] Built target test_skypoint
[ 98%] Built target kstars
CMakeFiles/testfitsdata.dir/testfitsdata.cpp.o: in the function "TestFitsData::testLoadFits()":
/opt/Astronomia/indi_ekos_build/Projects/kstars/Tests/fitsviewer/testfitsdata.cpp:62: undefined reference a "bool QTest::qCompare<double, int>(double const&, int const&, char const*, char const*, char const*, int)"
/opt/Astronomia/indi_ekos_build/Projects/kstars/Tests/fitsviewer/testfitsdata.cpp:63: undefined reference a "bool QTest::qCompare<double, int>(double const&, int const&, char const*, char const*, char const*, int)"
/opt/Astronomia/indi_ekos_build/Projects/kstars/Tests/fitsviewer/testfitsdata.cpp:66: undefined reference a "bool QTest::qCompare<double, int>(double const&, int const&, char const*, char const*, char const*, int)"
collect2: error: ld returned 1 exit status
Tests/fitsviewer/CMakeFiles/testfitsdata.dir/build.make:133: recipe for target 'Tests/fitsviewer/testfitsdata' failed
make[2]: *** [Tests/fitsviewer/testfitsdata] Error 1
CMakeFiles/Makefile2:1795: recipe for target 'Tests/fitsviewer/CMakeFiles/testfitsdata.dir/all' failed
make[1]: *** [Tests/fitsviewer/CMakeFiles/testfitsdata.dir/all] Error 2
make[1]: *** Waiting for unfinished processes ....
[ 99%] Built target kstars_ui_tests
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
Thanks.[code]

Thanks.

scheduler: capture fails after 2 captures - by: alacant

$
0
0
Hi everyone
At 03:00 I started to capture M57 via the scheduler. Guiding started but capture didn't. I aborted the schedule and restarted it. It then only captured 2 frames of 40.

Questions
1. Why did capture not start without my intervention?
2. Why did subsequent captures then fail?

TIA, clear skies and stay safe.
Steve

log: drive.google.com/open?id=1zHQV_2YU5B4Kz7bYO-T8z0T0ccShp0W8

Help understanding how scheduler evaluates and prioritizes jobs - by: mlarsson

$
0
0
Hi!

I'm using a rather complex job file, imaging around 20 variables, and adding and removing some on and off. And I do have some problems in understanding how Scheduler really evaluates the jobs, and if I have the correct settings.

Right now, I am adjusting my job list (attached). Loading it into the scheduler, I get the following result:



Here the third job, RR Tau, is schedulet for....tomorrow night. Further down the list is another such leap - this job list should not be finished until midnight two nights from now..

Why is it like this? Why, for instance, is not RR Tau the FIRST job, if it now needs to be executed at 22.00? Why does the job list wait until 23.48 to start tonight?

Maybe I've configured something the wrong way. But I really like the way the scheduler filters out jobs that are invalid, so I could in principle have a long list, year around, and let scheduler choos which to work on. But to do that, the prioritization needs to be different from this.

My job list is attached.

Magnus

running multiple Astroberry systems in the same area - by: stevet

$
0
0
Hi there, so I have been trying for the last few hours to change the default host name, the SSID name as well as the default WIFI address as we're going to have Astroberry installs on multiple scopes all within wifi range

can anybody provide some illumination on the way this is configured here as there is limited in the way of normal files eg hostapd etc

Steve

Ekos 3.3.6 : No summary screen preview on MacOSX - by: nmac

$
0
0
I still have this problem on my Mojave Mac:
indilib.org/forum/general/5462-new-mac-k....html?start=36#41572

Fits images are still not displaying on summary screen preview during the capture session.
I have confirmed and I have this option selected, so it should work. It only works on independent fits viewer window.

Since I have reported this for the first time it never worked again, either building from sources or downloading from KStars website.

Nobody has this problem???

FITS viewer - by: Acapulco Rolf

$
0
0
Hi
Is there some setting that needs to be invoked in order for the ekos FITS viewer to show the HFR value for a given capture during an imaging session?

All images appear to show -1 for the HFR value

Missing Meade DSI entry in dropdown list - by: SteveBz

$
0
0
Hi Guys,

First I have to say what an amazing labour of love. I am over-whelmed by the scope of this project.

I am a Kubuntu 18.04 user and I have the same problem as described here for windows:

www.mail-archive.com/kde-bugs-dist@kde.org/msg239811.html

As it was registered in May 2018, the month after my 18.04, can I assume it will be fixed in Kubutu 20.04, later this month? I'm planning to upgrade when it comes out. Alternatively, I suppose I could download and compile the source.

What do you think?

Same problem for Orion SSAG.

Regards

Steve.

Some pics obtained with Kstars/Ekos/INDIN and a light setup - by: patdut

$
0
0
Hello all,
This is a modest result obtained using a 300mm F/D 4 ED Nikon lens and a Nikon D5300 . The camera was in piggy back on a 80/480 ED AT refractor with ASI120MMS.
I tried to do polar alignment with the Nikon but the camera hangs up after the first or second capture. According Jasem, and to my understanding, this is a known problem that can't be easily reproduced and don't have solution today.
So I made the polar alignment using the 120MM which gives a field very close to the 30' required. I had to do it twice because the target was out of field and hopefully I succeeded because my manual polar alignment was precise enough.

https://drive.google.com/open?id=1rhBDyEXubdr8typWR35u4gclGC1gDZLU

https://drive.google.com/open?id=11V7r4-SuP77bG8rjVmdaNMtJ9djnPXuJ

ThankStellarMate/EKOS - EQM-35 Pro guiding issues (brilliant start but then...) - by: naugustin

$
0
0
Hi together,
I tried to find solutions in the forum but arrived at the end of my knowledge or rather out of ideas what to try next...

I´m running a EQM-35 Pro mount via WiFi remoted StellarMate (RasPi 3). Main camera is a ASI294MC Pro and guide camera is a QHY 5L-IIc. All cameras and scope configurations are loaded fine and all gear is reacting as it should be. The mount is connected via the StellarMAte and I have no ST4 cable connected and use pulse guiding. Polar alignment was made with the EKOS alignment tool. After slewing and plate solving to my target, I see some good guide stars in the QHY 5L-IIc frames (gain 8-10, 2 sec, 2x2 bin) but I have some issues with the reliability of the guiding. Maybe someone here faced similar or comparable issues and can give some advice.

After running the calibration and guiding started it looks all very good. Guiding in both axes is "spot on" with very little corrections made. So basically the moment you would smile, start imaging and lean back.
However, after a little while and out of the sudden the guiding is completely off, the little dots in the drift plot jump from the green/center area right into the yellow or even red and it takes a little while in recovering from that. The images of course get double stars or trails.
I tried many many different settings but nothing really stopped this behavior. Sometimes the message comes up saying "Delta RMS threshold value exceeded" - what I tried to google but could not really find any explanation. Then a new star gets picked (even if I deactivated Auto Star) annd guiding continues well for a wile again. Same problem often occurs after dithering quite often so that I have to stop guiding manually and just restart).

I have the feeling it maybe has something to do with the way the guide star but my options are limited. I tried to play with the camera settings to get better stars (gain, darks) and the box sizes but that did not solve it. Also it seems to be unpredictable - sometimes its fine for 10-15 min including dithering, and then it´s just good for a couple of minutes. Also tried alternatively the SEP algotythm instead of SMART but in general that made no difference.

The gude module main settings I´m using are:
Exposure 2s
Bin 2x2
Box 32 (tried 16 and 64 too)
Guiding Rate 0.5 (tried 1.0 too)

Calibration I do with Pulse 3000, Iterations 3 (with lower pulse the DEC calibration fails)

Guide settings:
Algorithm SMART or SEP (not much difference seen)
Lost Star Timeout 60 s
Max Delta RMS 10.00 arc sec (tried 15 arc sec too but did not change on the problem)

Dither 2.5 pixels
Frequency 1-3 frames
Threshold 2 pixels
Settle 20 s
Timeout 180 s
Max Iterations 10

Control Parameters (next to the drift plot) are on default:
Proportional gain 133.3/133.3
Integral gain 0.0/0.0
Maximum pulse 5000/5000
Minimum pulse 100/100


I would be happy about any ideas what to do/try.
One idea is to alternatively try PHD2 guiding once and see if the same behavior comes up - but I rather like to use the internal guider.

I have a second setup with a CEM25P and a (non remotely controlled) RasPi 4 and StellarMate OS. There I dont face any guiding problems at all. Guiding and dithering runs stable for hours. This new EQM-35 Pro slightly drives me nuts...

Thanks in advance!
Nico

EQDIRECT connection for EQMOD - by: rajahruncorn

$
0
0
Hi

I normally connect to my NEQ6 mount using EQMOD over bluetooth with Astroberry. This works OK but I have experienced the occasional random disconnection. I have decided therefore to go back to the good old reliable method of using a wired connection to the mount using USB to TTL conversion. I made up a cable using a FTDI chip a while back and it worked fine on the ASCOM based windows system I was using then. I now want to use the same cable on an INDI connected system using Astroberry. However it doesn't want to connect when I simply plug the cable in and try and connect the EQMOD mount. The default port setting is /dev/rfcomm0 and if I try to scan for other ports on the connection tab I get a message saying "no candidate ports found on the system for EQMOD connection". I notice however you get this message even if nothing is connected ! It may be therefore that the RPi is not sensing the connection at all and there is a physical problem with the cable. I seemed to remember when using the said cable with Ascom there was a FTDI driver that I needed to download.

Am I expecting too much to expect a connection simply by connecting the cable and trying to connect using the existing EQMOD Indi dirver in Astroberry ? Or is there a setting I am missing or another driver. ? The EQMOD Indi driver works ok using Bluetooth as the medium and I would have though this was more complex.

Thanks for any Info

Cheers
Ian

Problem with indi_getprop - by: iooo

$
0
0
Hi, look at this session:



indi_getprop appears to have a problem with the device name that contains either a period or a parenthesis, in this case device "Toupcam EP3CMOS02300KPC(USB2.0)". Is there any workaround, how to use indi_getprop/indi_setprop with this device?

Keep me right on taking FLATS. - by: mpaul73

$
0
0
It seems like a pretty straightforward routine to take flats with Ekos. But being new to this there is always a niggling feeling that I might be doing it wrong or could be doing it better. Here is how I am taking my flats:

1. White t-shirt flat and stretched over end of OTA.
2. In Ekos I select "flat" and in customize I leave it at "manual". I leave ISO the same but on my 6D select AV (rather than BULB setting).
3. I start capturing while using my iPad on full brightness holding it pressed up against the white t-shirt.

My flats look good I think. On the histogram they are about half way exposed.

Am I doing the right thing for good flats?

[SOLVED] Error compiling - by: pcxz

$
0
0
For several days kstars has not been compiled,
fails with this error:

<code>
[ 99%] Built target kstars
CMakeFiles/kstars_ui_tests.dir/test_ekos.cpp.o: in the function "KStarsUiTests::manipulateEkosProfiles()::{lambda()#3}::operator()() const":
/opt/Astronomia/indi_ekos_build/Projects/kstars/Tests/kstars_ui/test_ekos.cpp:198: undefined reference a "bool QTest::qCompare<QString, char [20]>(QString const&, char const (&) [20], char const*, char const*, char const*, int)"
/opt/Astronomia/indi_ekos_build/Projects/kstars/Tests/kstars_ui/test_ekos.cpp:202: undefined reference a "bool QTest::qCompare<QString, char [14]>(QString const&, char const (&) [14], char const*, char const*, char const*, int)"
collect2: error: ld returned 1 exit status
Tests/kstars_ui/CMakeFiles/kstars_ui_tests.dir/build.make:258: recipe for target 'Tests/kstars_ui/kstars_ui_tests' failed
make[2]: *** [Tests/kstars_ui/kstars_ui_tests] Error 1
CMakeFiles/Makefile2:1407: recipe for target 'Tests/kstars_ui/CMakeFiles/kstars_ui_tests.dir/all' failed
make[1]: *** [Tests/kstars_ui/CMakeFiles/kstars_ui_tests.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
[pcxz@kstars]$
</code>

GPS from mobile phone - by: Highkamp

$
0
0
I have seen some videos of using the mobile phone to send gps info to Kstars/Ekos using mobile apps such as Share GPS, etc. I see the drivers for connecting to GPS show up under auxiliary equipment but I am able to make it work. The youtube video of it shows a bunch of terminal commands that I am hoping are not needed if the drivers are already in the indi library. Anyone done this successfully and able to share how its done?

Thanks
Viewing all 15748 articles
Browse latest View live