Get Connected!
Come and join our community. Expand your network and get to know new people!
Hi everybody,
we are happy to announce that a new version of AstroArch is out, not big big things, but few improvements towards a better world!
Feel free to look at the release notes github.com/devDucks/astroarch/releases/tag/v1.9 - you don't need to re-flash this time!
Enjoy and clear skies to everyone!
Read More...
Same problem for me
I can't expose at a speed lower than 2 seconds.
I replaced libasi25 with libasi21 and it works again.
Read More...
Javier,
I think your changes are fine and on point for personal use. They have been requested more than once.
Since I do not agree that the driver is the place for these functions I do not plan to do the PR. I would prefer that the functions be tied to the Observatory. Or if too difficult put them in a new observatory oriented utility driver. That could be combined with any of the dome/rolloff drivers. If the developers think the changes should reside in this driver so be it.
I'll just list some of my objections to extending the rolloff driver which was intended to remain the same while any changes are restricted to the remote end. That keeps changes out of the INDI environment and keeps the driver ignorant of what is going on to operate the roof. It is defined by what it does not do as much as by what it does.
We have to imagine that any change to the driver will be running against old remotes
Adding implied functions to the driver might result in support issues. Hopefully not and the existing Arduino implementations out there reject the use of new functions. But we should not break existing installations with protocol conflicts or pin overloading. We can define the purpose of relays and assignment of pins in our own implementations but not in general, it is not under our control. Some years ago a person wrote their own implementation, no clue as to what that involved. The next auto update of INDI should not disturb that install.
With existing installs the driver interface will imply that the check boxes do something but there is nothing on the other end to act upon them.
In the same way the driver does not deal with switches, relays or pins, we do not know what the driver is talking to. It does not have to be an Arduino, it could just as well be a Python script. My own implementation is an Arduino but does not have any relays and most of the pins are covered by a TFT shield. All I'm interested in seeing come in is open close and are you done yet messages. At the present time we can provide for a turn key no coding required solution to a completely personalized implementation. But the driver remains the same by restricting its function.
While it is easy and convenient to drop things in I do not care for it.
Why somebody is having a problem with their camera, power supply or they are locked out of their observatory is not a core concern of the roof driver.
Regards
Tom
Read More...
I personally don't use PHD2 so I can't respond to any questions about it. I just use the internal guide functions from KStars native.
AS for the capture, have you tried new cables?
Have you tried hooking the ASI1660MC up to a Windows desktop and seeing if it will perform a 1s capture using the ZWO software?
The EAF should not be having anything to do with the time it takes your system to capture a frame.
Honestly... when I have issues like this I just copy my capture data off to external media and then blow out a new image of whatever version I want to use. I have 1.7.7, 1.7.8, 1.7.9, 1.8.1 and 1.8.2 kept on my computer and a thumb drive in case I want to install one of the older ones. Which reminds me.. I probably need to go ahead and download 1.8.3 also to add to the group.
Read More...
I updated my Stellarmate OS and noticed this change in the background colour to a pale blue. It used to be a dark background previously. My Theme is Default and Colour Scheme is Moonless night. Even if I change these the background doesnt change.
I notice the same change on Linux Mint as well. How can I set it back to the previous setting?
Read More...
Hi Wolfwang and wotaloka.I am not ready to create a new Pull Request, i don't feel safe to do it.
If any of you want to upload it, I'll give you the code and you can do it. I attachedlast updated files on this post.
There are 3 files:
To INDI Driver:
rolloffino.cpp
rolloffino.h
and for arduino board a new rolloff.ino based on standard but with some modifications like this:
PIN connexion:
// Define name to pin assignments
#define SWITCH_1 A0
#define SWITCH_2 A1
#define SWITCH_3 A2
#define SWITCH_4 A3
#define RELAY_1 4
#define RELAY_2 7
#define RELAY_3 8
#define RELAY_4 12
#define RELAY_5 9
#define RELAY_6 10
#define RELAY_7 11
RELAY MODE:
HIGH Normally Open (NO)
LOW Normally Closed (NC)
RELAY Functionality:
RELAY_1 -> OPEN Roof -> HOLD 0, HIGH MODE (NO)
RELAY_2 -> CLOSE Roof -> HOLD 0, HIGH MODE (NO)
RELAY_3 -> ABORT Roof movement -> HOLD 0, HIGH MODE (NO)
RELAY_3 -> LOCK Roof -> HOLD 1, HIGH MODE (NO)
RELAY_4 -> Auxiliary1 switch -> HOLD 1, HIGH MODE (NO) -> Activate to close Relay (LOW MODE) (NC)
RELAY_5 -> Auxiliary2 switch -> HOLD 1, HIGH MODE (NO) -> Activate to close Relay (LOW MODE) (NC)
RELAY_6 -> Auxiliary3 switch -> HOLD 1, HIGH MODE (NO) -> Activate to close Relay (LOW MODE) (NC)
RELAY_7 -> Auxiliary4 switch -> HOLD 1, LOW MODE (NC) -> Desactivate to open Relay (HIGH MODE) (NO)
NOTES:
RELAY_3 have two functions Abort and lock roof
RELAY_7 its a switcher for deactivate something, like for example a IR camera that normally its activated, but its needed to desactivate before you start to work.
RELAY 4,5,6 It is switcher to activate something that normally shold be desactivated, like mount, lights from observatory, etc..
Read More...
Yes that should be fine. The change was merged yesterday at 15:28 BST so a nightly build that started after that time should pick up the change (maybe pick up today's nightly build whenever that happens).
Read More...
Hi Magnus,
I don't use Stellarmate but I *believe* there's a way to get bleeding edge on it. Probably best to post on the Stellarmate Discord channel as there are plenty of folks on there who know about these things and the channel is quite active.
On the bad Fits header info, I'm afraid I don't know anything about this. Probably best to do a new thread and hopefully someone who knows this area can pick it up.
Read More...
Hi!
Good to hear you are making progress!! However, I do not have a build environment on my Raspberry - just a standard Stellarmate image. However, if you are able to give me instructions - if not too complicated - on how to set it up, I could try the next few days.
(the other issue with scope information keeps pestering me - guess I should open a separate thread on it)
Best,
Magnus
Read More...
Hi Dan,
I've been tracking down an issue recently that sounds very much like this one. The problem I've been having is that I can't reproduce the issue on the Simulators but a couple of folks have reported scheduler hanging on their equipment.
Anyway, I merged what I hope is a fix yesterday, so if you able to build from source, if you build the latest kstars, hopefully the issue is fixed. If you still get the error can you post up a log with verbose Align, Capture, Scheduler & Focus set and I'll do some more investigation.
Thanks.
Read More...
Hi Magnus,
I merged a fix for this yesterday. If you are able to build from source could you pull the latest and give it a go?
The issue I have with this is that I can't replicate the problem on the sims so I don't really know if I've fixed the exact issue you've been getting, but hopefully, I have.
John.
Read More...
If I understand this correctly, then all the dome control UI elements in the observatory panel are grayed out, because no dome driver is loaded.
Ekos does not know that the dome is attached to 10 micron mount and the 10 micron driver does not implement INDI::Dome. So the scheduler cannot open the dome and I fear opening the dome in the startup script might open the dome in bad weather conditions.
I could instead attach the dome to the PC running indilib and use the indi_baader_dome driver, but then the dome would not center the telescope inside the opening, at least not precise enough. The 10 micron mount, on the other hand, takes the exact size and position of the telescope into account. Neither the 10 micron nor the baader dome driver have similar parameters to specify the geometry. Also, using the telescope visually without computer is much easier, if the dome just follows the telescope.
So I wonder what the best solution is. Perhaps to implement INDI::Dome interface in the 10 micron driver will do the trick? I could also control dome flap and shutter with the driver. Above a certain altitude, closing the flap can reduce light from the nearby street. In the long run, I want to open and close it automatically.
The most simple solution for now might be to setup the mount to open the dome when unparked. This would work, as scheduler won't unpark unless weather is not safe.
I wonder how other people have set it up (assuming I am not the only one with both a 10 Micron mount and Baader dome).
Read More...
Yes, the NVME board + memory draw much more power than the SD-Card, that's a fact.
Another thing I forgot to mention : when starting with RPI 5, I often had problems like the PI not booting correctly.
Until I set the value that alolows it to boot even with not enough power.
OK, the PI is staated to need 5A to work. But in all my testings, I never reached 1A - so why set this upper limit as mandatory ?
@Keith, do you mean thaat you attach all 3 +5V pins to the +5V output of the converter ?
Read More...
Hello Tracy,
About my EAF (v1 ZWO). I need to have a capture of 3s or 4s (ASI1600MC) to generate a frame.
If I use a capture of 1s, the capture is done, but I don't see the frame. And so, the EAF can't solve the solution.
My second problem is the guiding. I use a ASI224MC with an OAG (Quattro 200/800 and EQ6).PHD2 move the star (so, the communication with the mouint is correct) but after a moment, PHD2 stop the process and says that the star has not moved enough.
Is it a problem with my optical trains ?
Frank
Read More...
I updated to the latest indi-drivers available in the repository, Installed kstars-bleeding and still see the same behavior. I have done another observing session and attempted to start he scheduler. Again, same issue. I've stop/started the drivers, rebooted the system and I am running out of ideas. I have attached a screen shot of the scheduler and a verbose log info file of the session.
Any ideas or suggestions would be greatly appreciated.
Thanks,
Chris
Read More...
That's easy. . . the NVME drive is drawing ALOT more power than the SD card. I assume that you're powering your Rpi thru the USB-C port on the Rpi? The Rpi-5 is already drawing alot of power and if it dips down below a certain voltage for a millisecond, then "things" can happen. It may not be enough of a brown-out to cause a total reboot of the Rpi, but it may be enough to cause individual chips or sub-systems to reboot.
.
Everything can be working along just fine for hours and then something happens where all 4 cores of the Rpi fire up to 100%, and the Ethernet system is working at 100%, and . . . and. . . brownout.
.
I went thru the exact same issue when I was setting up my Rpi-5/NVME system. The solution I came up with is to power the Rpi directly thru the 5VDC GPIO pins with a power supply that has alot of ass behind it maintain voltage no matter how many chips fire up.
.
I am currently getting ready to test an Rpi Hat that I've integrated a 5VDC@6A power supply feeding directly into the GPIO pins that should be able to handle anything the system throws at it, but that won't be ready for public consumption for a couple more months.
.
In the meantime, order one of these: a.co/d/1iQcW01 and power your Rpi directly to the 5VDC GPIO pins. The Rpi is specced to handle up to 5.2VDC on the GPIO pins, so hopefully you'll get one that gives you 5.1VDC. I've used several of these during my testing and it was the solution to all the little glitches I was having. Solid as a rock.
.
Read More...