Greg Jones replied to the topic 'Raspberry Pi based Observatory Controller' in the forum. 3 days ago


I made a lot of progress then work heated up. I don't need the magnetometer for my tilt off roof but am planning on adding it for Dome use. The plan is to use either a Bluetooth or WiFi dongle (I have a SparkFun ESP8266 Thing and 3 axis compass for the task). I think I'll need to use a compass and gyro to get the needed precision/repeatability but the slow movement and averaging may be enough. The module above has a LiPo battery charger built in so it should be possible to solar charge it meaning no wired connections.

I also have a DC motor controller that's intended for dome control. I have a small (low current) model but the interface is the same as their larger versions which should be enough for most domes. Of course simple AC/DC motor control (ie. via relays with reversible motors) can be handled that way with the accompanying clicky-clack and greater maintenance



Greg Jones replied to the topic 'Raspberry Pi based Observatory Controller' in the forum. 3 months ago

Looks like weewx works on top of both mysql or SQLite3.

As it turns out, writing the data out in any of these formats is really simple. The analysis part is a little more difficult, but just a little. I've been conversing with one of the engineers that does these things for a living at some of the professional observatories. He's suggesting I log events as that will in the long run minimize the size of the data log. That also means I can compress the log interaction to a single common procedure call within my code making a later change really easy.

For the first few turns, I think I'm going to use the .csv files. .csv files can be pulled into a database, but are also easy to read in calc. Should save a lot of time during debug.

I will look more at weewx and SQLite3 going forward. Less overhead than mysql would be good and segmenting the weather data out would have benefits too.


Greg Jones replied to the topic 'Raspberry Pi based Observatory Controller' in the forum. 3 months ago

Quick question on log files. There seem to be two reasonable options: 1) .csv files or 2) an actual database (mySQL (?)).

Seems like there are about 3 things to log, all would be settable but for data allocation and time stamped -
a) Overall Status - hourly to daily
b) Environmental Data - temp and sky data might be every 10 minutes during operation, and maybe 30minutes otherwise.
c) Events- open roof, close roof, heat on, Dew system on/off and so forth.

Option 1 would probably be a directory with a .csv file for each if the above. I suspect this option would be easier for the casual observer with Excel or Calc.
Option 2 would probably be a mysql database with a table for each. Power users might prefer this,especially if the data
can be exported to the cloud or to a facilities server.

Implementation seems about the same for both but a bit more work to get useful data out of option 2.



Greg Jones replied to the topic 'Raspberry Pi based Observatory Controller' in the forum. 4 months ago

Jasem, thank you. Hopefully it will be of use over time.

Rain detection is a tough one. I have a switch input now, but the way it's set up, it could be anything including a file read. The biggest issue with rain it that you want to close up BEFORE it rains, not after it's rained for 10 minutes. Drop detector is cheap and easy, of questionable reliability, so you probably want to trip on the cloud detector if you can and panic if you see drops. The optical rain sensors are getting some play and heating the sensor plate to dry it out a little faster is also used by some.

The server is intended to run all the time, so would monitor connections and shut down if all connections are dropped for say 15 minutes. Will also have the watchdog set so a crashed or hung program will restart the system. I live in western Oregon, winters like this one can be real wet. I want the option for some level of heat or humidity control to be available inside the observatory. That and remote control of the roof are the primary impetus for the project. As long as I am at it, though I would add the cool stuff for robotic/remote operation.

I have about $115US into the controller right now, RP3, Piface-D2, Pi-EzConnect, 4 channel mechanical relay board, 4 channel SS relay board, 2 current/voltage sense boards and the sensors. These are all off the shelf, I have built no hardware, no boards. The intent is off the shelf, cheap available hardware. The Ez-connect is just a way to connect wires so could be replaces by a connector and piece of perf board. Once done, i would also be easy to roll a dedicated board (not planned)- optio Isolated 16x 16 I/O, 1-wire driver, RS232 and RS485 channels w/ drivers, I2C buffered output would probably do it. No reason to put the relays on this board or any of the sensors unless you want Temp for the Pi.

Planned functions- Roof open/closed, Mount up/down, Park (request and sense), Observatory "heat", dew heaters, Mount power, Observatory Computer power, lights. Alarms to my cell via text/email. Blue tooth and WIFI are available of course.
Monitors for- rain, clouds, sense temp/humidity and calculate dew point, drive current (and maybe temp), Roof motor current (mine is DC with linear actuators tilt-off), Motor temp an option.

Requests for- Stratum 1 (GPS) clock (will probably add but as a stand alone process not part of the code I am writing, some concern about interrupts). Vibration/earthquake monitoring (easy to add, probably at a later date). Satellite link back door (probably add as an additional interface process like INDI, very do-able). Davis Pro input (again, easy to add but I don't have one, so later), RS485 for industrial sensors.

I will have at least one more PC class computer in the observatory. That one will be connected to the mount/telescope and camera. I hope to have it's data storage setup as a RAID 1 for data capture, but will have to see how that goes. The Pi will control the power to that computer. Overall control and scheduling will probably come from inside the house, at least that's the plan. I don't actually do video bit might as well be. Lots of data if this gets going, ~1TB/week... More than I think a Pi can handle and lot's of reason for a bigger machine that can do some of the data reduction.

Sorry, a little more musing than I had planned... :-)



Greg Jones created a new topic ' Raspberry Pi based Observatory Controller' in the forum. 4 months ago

I’ve hinted a couple of places that I’m working on a Raspberry Pi based ROR Observatory controller. While not where I would like it, it’s taking shape and time to solicit some input. I've also posed on Cloudy Nights under observatories an will try to watch both and have shortened this post a bit.

So the question as you read this is: what else should the infrastructure controller do?

The controller is intended to run 24/7 keeping the observatory safe. That means heat if cold or wet, close the roof if raining or the users drop their link for a prescribed length of time. Before closing the roof, signal the telescope to move to its park position(s) and so on. EKOS would make a request to open, but the server would check it operational criteria before opening.

Current sensors and I/O include-
- Switches (8) from the Piface2 board, more can be added
- Outputs (8) Piface 2 plus four channels of AC SS-relays and four additional mechanical relays I plan to drive from the Piface D2.
- 1w thermal sensors DS18S20 or similar. I have 2 but many more can be added
- INA226 voltage/current sense boards, I have 2 coming
- MLX90614 for a cloud sensor (wide version I think, will almost certainly add a second, probably on the scope.
- AM2301 temp and humidity with dew point available
- I am using a Pi-EzConnect board as a breakout for the I2c and 1wire. Expect to add a max332 level shifter for RS232

- should add a light sensor, which should be easy and also redundant (clock time and timeouts also work).
- Next addition is probably a couple of Pololu Simple Motor Controllers. I can use them for my roof open/close
and mount up/down and they look like just the thing for a dome (thanks stmguy!). That would free up 4
relays, which I could use as it turns out.
- GPS/Stratum-1 clock sever would also be a nice addition but not explicitly part of this software.
- plan to include email and/or text alerts on alarms, but haven’t looked into that yet.
- have a web cam, might add it’s input to the web interface.
- would like to interface to a home automation technology to use those outlets. All I can find so far are
hacks or discontinued interface, but that is being tracked.

Pretty much any on/off function can be controlled-- dew heaters, roof motors, lights and so on. Almost anything can be monitored-- temp, humidity, current, voltage and anything with a switch including motion or intrusion alarms. There is no intent to control the telescope or cameras but you could with INDI. I like the Pi, but for scope and camera control with plate solving I’ll probably use something a little more powerful, but that’s me.

Last, this will go into public domain. Not sure if it will end up on git or one of the yahoo groups or here,
but will be posted “someplace” :-).

Any big “wants” out there? Anything come to mind?

More details a bit later….


Greg Jones replied to the topic 'Add a planner to Kstars and/or EKOS' in the forum. 4 months ago


I see the chooser... but how do I get a list of-

1) all galaxies in Ursa Major brighter then m15 and dimer than m9?
2) all double stars (no catalog or object type "double") with magnitudes between m8 and m14 with separations between 0.6 and 1.5 arc sec in Orion ?
3) I need a comp star so need am m12 type A7V in Orion

I can do this with DeepSky and the other tools mentioned look like they do too. I can export a CVS file form DS if I have an import function (already listed for EKOS). I can even bring the WDS catalog into KStars, but can't call them doubles and cant even list them. Chooser is fine for the common and popular items, but not so much for once off the beaten path of if the target list is long.

I don't expect this BTW, just getting the request on the "wish list".


Greg Jones created a new topic ' Add a planner to Kstars and/or EKOS' in the forum. 4 months ago

Add a parameter driven search and planning function based on the available catalogs (mag, constellation, separation, start type and so on). Allow the list to be sorted and tagged, then imported into EKOS. See DeepSky (I use this one now), Deep-Sky planner or maybe Astro Planner.


Thank you...


Greg Jones created a new topic ' Add target input function to EKOS' in the forum. 4 months ago

Add the ability to import a (large >500, >1000 would be better) target list from a file (CSV or spreadsheet format preferred). Is OK to use the same imaging parameter but those could also be imported. Some level of choosing columns would be good as well (say choose 4 columns out of a 10 column file with the columns is an arbitrary order).
If not specified, camera setting should default to one specified is say the input form.
If not specified, output file(s) could/should go into a folder with the target name (i.e. NGC281 or 22061+2034AB (if needed 22061p2034AB)...). Higher level folder could be a concatenation of the input file name and date (???).

DoKeeffe posted this that is a potential start, though I don't have it working yet-


Greg Jones replied to the topic 'Dome control driver' in the forum. 4 months ago

Helge, we've been exploring along similar paths and I do understand. I downloaded the trial SGP but didn't have time to understand it and the trial period is I'm sure over. RTS2 and/or SGL are on my fall back path from KStars/EKOS. I'm pretty optimistic at the moment though. Once I get the hardware up (rebuilding the scope mount too, I will revisit if needed.

For all the talk on all sides, cross platform operation just doesn't seem to be there yet. If you want to run INDI/EKOs, I would personally use a Linux system. If you have to have ASCOM, then Windows based computers. I know people are doing the mixed platform thing, I just don't have the patience nor see the need (computers are sooooo cheap).

For now, I need an observatory controller that will protect the equipment. Here, that really means some heat when it's cold or damp. The heater will probably be a light bulb, won't take much, but would help a lot. As long as I can talk to it with INDI, ASCOM and across the network I should be covered.


Greg Jones replied to the topic 'Dome control driver' in the forum. 4 months ago

Helge, I also like your solution, at least for now.

As an FYI, I am working on a Raspberry Pi3 /Piface Digital 2 controller. For the first rendition it will be for a ROR but hope to expand to a dome a bit later. One-Wire, and other relay/IO cards should be easy to support, at least I am trying to make it so.

I started one last year based on an IoT framework, but that turned out to be to limiting both for long term support and to get connections into the various client software packages. I have just started coding the new version, so nothing right away. The Server is in "C" and won't know about ASCOM, INDI or the Web...

The current vision to to have a configured server that runs 24/7 to keep the observatory "safe" and "ready". The server will be responsible for keeping the observatory safe: closed if raining, closes if no activity, turn on heat/cooling if cold, damp or hot and so on. At some point the server will be able to send an email or text "FIRE".. well, hope not that one.

Separate processes (communication through IPC) will handle the INDI interface, and serial (?) interface to Ascom and a Web interface. This way if an interface fails, the server still operates. I'll start a thread once the system has a heart beat. These interfaces will issue "requests" not commands, the server will in most cases be able to ignore requests that put the system in danger. There may be an over ride that is password protected via the web interface... TBD.

Well, that's enough for now. Hopefully it will be workable and worth the wait... For those with a ROR, especially one with a garage door opener, AstroBerry-Piface and some scripting in EKOS should get you started. That's my plan if the mechanics are done before my controller.


Greg Jones replied to the topic 'Astroberry PiFace' in the forum. 5 months ago

Not to reply to myself... ;) but with a little wacking and hacking,I have full access to the PiFace Digital2. (Relay driver only).

Kaczorek, pretty easy to work on... THX.



Greg Jones replied to the topic 'What would you like to see in Ekos in 2017?' in the forum. 5 months ago

dokeeffe, looks like a good start, will take a look. Import function is still IMHO needed as a basic part of Ekos at some point.


Greg Jones replied to the topic 'Astroberry PiFace' in the forum. 5 months ago

Well it winter again and may make some headway on an Pi-observatory controller. Upgraded to a Pi3, unfortunately got the PiFace digital 2 instead of the Relay plus. Just loaded up, the first 4 outputs work and all go on and if with the all-on/all-off buttons (for those that might find themselves in the same boat). No worries, fine for now.

Anyway, all else seems to work. I would like to use the Astroberry-Piface_relay as the initial controller. Does anyone have an Ekos startup script that toggles something via the astroberry-piface/indi server connection? Will figure it out if not, but would save a lot of time.




Greg Jones replied to the topic 'What would you like to see in Ekos in 2017?' in the forum. 5 months ago

I'll also add my thanks for a nice application. I just set up AstroBerry-Piface and have been playing with it as part of a remote/local combination to get things going. Hope to turn the Pi into an Observatory controller, but more on that in another thread at another time.

For Ekos, I would really like the ability to import a target list. Ideally from a spreadsheet (look at how Word does it for mail merge), but a comma/tab/other delimited text file is OK. In my case, the same camera controls could be used for all targets and the output file could be named in the input file or one could use a directory/target_name method

We are imaging double stars for Speckle/autocorrelation, as such wee often have a list of 200-2000 targets. The 16 12 27 file is what we use for capture and automated reduction. The other two are from DeepSky. "planning" function in KStars and CDC are not options. The " on every cell of the text file can be scrubbed as needed (python?). I haven't found a good Linux based planning tool with parametric searches so a generic file format is probably the most flexible.

So an import function, but think 1000 plus objects.

Great question, thank you again. Not sure the forum liked the excel files... trying again


Greg Jones replied to the topic 'Astroberry PiFace' in the forum. 9 months ago

Thank you, the changes did the trick for now. I can install the Binaries as well as compile.

I haven't gotten Indi server to run and haven't tried controlling the Piface (1) yet, but hope to this weekend.


Greg Jones thanked Radek Kaczorek in topic Astroberry PiFace 10 months ago
Greg Jones replied to the topic 'Astroberry PiFace' in the forum. 10 months ago

Playing the part of a Noob here, sorry.

Trying to get Astroberry-piface loaded onto an old Raspberry Pi-B with Piface 1. Is Astroberry Piface compatable? Any hope?

Compiles but chokes linking. Focuser, can't find -lmcp23s17



Greg Jones replied to the topic 'Double Stars in KStars, Ekos plan format?' in the forum. 10 months ago


Thank you and great work on Ekos. I've been going through the Youtube videos... quite nice.

Yes, Ekos Scheduler List (.esl) file format.

We often get a target list from USNO that may have from 300-5000 targets. We match those with comp stars and image. Typical data set is 10,000 frames of the target (~30ms each) and 1000-3000 of the comp star. These may be in sets of 1000, depends a little. The frames are generally a 512 x 512 ROI to save disk space but we can eat a Terabyte drive pretty fast. The data reduction is pretty well automated now, directed by a formatted spreadsheet listing targets, comps and file locations. The task lends itself to automation, but is also more complex than image Vaga for 2 minutes. Anyway, Ekos looks like a good option for us to start with for automation.




3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!