I'm not seeing anything wrong here in my setup after running it overnight. It is an interesting display the way it adjusts with time and temperature. The Observatory information is matching the values seen from the Vantage driver. It is responsive to the unsafe status returned from the Weather Safety Proxy driver's curl requests and external park/unpark requests to the roll off roof driver. Looks good.
What is the correct git command to fetch the modified source?
I tried variations of the git command using git clone git://github.com/sterne-jaeger/kstars/tree/observatory_sensor_graphs/ as the base without success. Then clicked on the code tab and used the link shown in the dialog or clone box which did fetch kstars.
git clone git://github.com/sterne-jaeger/kstars.git.
After the build I am not seeing the graph so assume I fetched the wrong code.
Just a thank you. I used your cloud and rain sensor code to add the same to my obs. I did not use a Raspberry Pi, just the Arduino and ran the web server on the Ekos machine. Then instead of the driver, polled the web server from the Weather Safety Proxy driver as suggested here. The Observatory module took it from there detecting the unsafe condition when raining.
I use the daily build. KStars 3.3.6, INDI 1.8.1-2.6. Guide camera ASI 174.
Cable drag and balance might be a factor although neither were adjusted going from bad to good guiding.
Did the same image again last night with similar results, started badly and gradually became stable. In my
case I'm thinking it might be associated with the location in the sky which was directly overhead. Started
settup right after a meridian flip, combined perhaps with balance or cabling. As the target moved a little
westward things calmed down, just a thought.
I was having a hard time with guiding last night, took about 1.5 hours to get it going.
The swings were very high, going off scale and needing a restart. This was using settings
untouched from earlier nights when guiding was acceptable. Seeing was average and a nice
clear night better than most here. The last few things changed were:
- Disable dithering, didn't seem to be related but left it disabled
- Reduce pulse
- Algorithm changed from SMART
- Use of subframe (since this was the last thing changed before guiding worked for more than a few minutes)
After these changes the RMS error averaged 0.4 for the remaining 2 hours of time.
I do not know when the FOV became 5.6x5.6 but did not touch it since things were working.
Star: Manual select
FOV: 84x53 (5.6x5.6)
Guide Rate: x1 (Mach1)
Exposure: 3 seconds
Max pulse: 900ms
Min pulse: 30ms
Same here, commented on it in
Think restarting KStars was my way of getting going again.
Yes, I think the relationship between the Observatory and rolloff is working.
The mount did not park at the end because of:
2019-08-08T09:54:46 Telescope altitude is below minimum altitude limit of 0. Aborting motion...
Even though the rolloff simulator had the "Ignore Telescope" set it then failed to park.
Running the scheduler again with the telescope's altitude limits checkbox unchecked allowed it to park at the end, and then the roof would also park.
Perhaps the scheduler might have eventually stopped looping on the mount unparked message if a rain simulator was running?
That helped, I did a local build and tested it with all simulators including the rolloff-roof, If the simulator roof works then my variation will be okay, or I can make it so.
Your change fixed the relationship between the Observatory and rolloff-roof states. It work ed to park and unpark the roof just fine and kept them in sync.
I tested with a simple scheduler definition and there might still be an issue there. For me it opened the roof and went through the imaging steps. But when it came to closing the roof it did not and just kept repeating "Mount unparked." messages that I did not see the end of and just stopped the scheduler. This might be a problem local to my install due to mixing package manager daily updates with doing the local clone/build on the same machine. I need to sort out a better approach for doing the builds.
I have not progressed to the point of checking out code.
Tried a git clone github.com/indilib/indi.git but did not see any changes to roll_off.cpp if that is what I need.
Can you give me a pointer on locating the stream/release where the changed file(s) are?
Be glad to. I can't do it directly because my implementation is so different. But I'll do a diff between the previous rolloff files and your updated ones. Depending on what is there I might be able to change my version to incorporate those differences for testing.
In my case it is just a dyi home build, got general ideas from cloudynights observatory forum. Do not have plans but built it like a small shed 6'x8' with lumber from the local store. The motor and inverted V track is intended for a sliding gate opener, Aleko 1450. The motor comes with a remote control and has wired connection points for a open/close push button. It relies on magnetic switches positioned at either end of the run to turn off the motor.
When I was looking for a kick starter I saw there was the rolloff roof simulator code as an example and took that as a framework. If using a Raspberry Pi in the observatory there is a WiringPi interface that could be used directly. I am not using a pi and chose to interface via a Arduino controller. A simple text based protocol was used between the INDI driver code and the Arduino using the Arduino's default USB connection.
The question you asked about connections, The Arduino uses a relay to control the Aleko's push button on/off connection. There is a mechanical switch at both the opened and closed positions of the roof that the Arduino can pickup along with a switch that gets closed when the roof's tie downs are closed to stop me from forgetting. How to force a close, you would just use the normal Ekos interfaces, using the Observatory panel or the INDI properties interface, the Weather monitoring drivers will also work as for other Dome rolloff drivers. For the Aleko motor the remote also still works.
I have only a few images of the build if interested and of course you are welcome to the software if you can use it to get going. For Ekos software I think there are various approaches including script control examples. You might get more visibility starting a new thread requesting examples of what people have done.