Greg Jones replied to the topic 'EKOS imaging pipeline?' in the forum. 7 months ago


That may be the best option. In fact the more I think about it, running the scheduler on the observatory hardware seems like a more robust solution (WAN disconnect). Nice thing about INDI is there are a number of options here. The local file processor was the initial plan, but for several reasons, doing it as part of the capture process looks like a better option.

I have some homework to do... Thank you again.


Greg Jones replied to the topic 'EKOS imaging pipeline?' in the forum. 7 months ago

knro, I can make that work in theory, but it dosn't do what I am looking for.

Think remote observatory with slow data connection. We shoot about 5000 frames per target and 10+ targets an hour. We can fill a terabyte drive in 3 nights. So the goal is to collect the raw frames in the observatory and do the Speckle reduction (Fourier based) on the fly (GPU) returning just the Speckle results. That will give us close to a 5000 to 1 reduction in data needing to be transferred. We also need to put the files into a reasonable directory structure and Ideally store each target in a FITs cube instead of a frame per file.

I know that's a lot and I'll take a shot at it. Since the first note I've looked at the code and have an idea what to do.

TIt looks like EKOS does the actual file save, correct? That means that EKOS would need to be running on the observatory computer. If all that is correct, then splitting the scheduler from the capture module would be the Ideal way forward. That is, let the capture module run under the server, and direct it with the scheduler via the server.

Hope that makes sense?

I'm hoping to get the cuda/GPU portion working, probably with Open Astro, but CCDCiel is also a possibility as it uses INDI for the cameras from what I can tell.

Thank you,


Greg Jones created a new topic ' EKOS imaging pipeline?' in the forum. 7 months ago

I'm looking at setting up a pipeline for Speckle Interferometry. In a nutshell, I would like to pre-process images as the frames are taken. Conceptually this would be from a remote site. We take as many as 10,000 frames per target and while small, that's a lot of data.

Not sure how to even search for what I am asking for, but want the save to disk function in the observatory and the scheduling to be done in my office. That is EKOS scheduler is running on my system in the office, but the data is being collected and reduced at the observatory. Once processed the result is about the size of a single frame. This is of interest to anyone ding high cadence imaging.

Can this be done now? If so a hint on how would be nice. Also a pointer to where you would recommend hacking in the cuda code for the processing :-)

Thank you,


Helge thanked Greg Jones in topic Astroberry PiFace 1 year ago
Greg Jones replied to the topic 'Astroberry PiFace' in the forum. 1 year ago

Motor is has a spindle with an O-ring around it for friction drive to the filter wheel. Small 1/16" diameter magnets are glued into holes in the filter wheel using a home made jig for location. Hall sensors sense magnetic fields so no physical connection between wheel and sensors.

Motor can slip under the posts and the spring fixed to the fixed posts supplies tension/force on the friction drive.

The wheel portion (that holds the filters) is actually flipped upside down from it's original configuration and the detente balls and springs removed so wheel is free to spin.

The 2 boards are screw mounted to the case using tapped holes in the case (small holes, like #1 screws ). Sensors are mounted over holes in the case (holes probably not needed in the aluminum) with slots milled to allow the sensor to get closer to the wheel (may also not be needed. Once working I'll "pot" the sensors in epoxy or similar.

Connection to the RPI (or other) is via USB to the Arduino Nano (skinny board shown).


Greg Jones replied to the topic 'Astroberry PiFace' in the forum. 1 year ago


You can run a step based system, but they tend to not be robust. Best with hard slip proof connections (gears or timing belts or mounted to the motor shaft). Biggest issue is the wheel will need to be at a "home" position each time you turn it on or you'll have the re-calibrate it (tell it where it is).

For a couple of bucks a hall sensor can give you a "Home position" and for a couple of more you can get a full closed loop readout. You can even use a DC motor then, though it needs to run slow enough to sense. Feed hall output to an ADC pin and will read mid scale for blank and 0 or full scale for a magnet depending on polarity (bi-polar hall sensor). Watch for max absolute value |A |+|B| from the 2 sensors after adjusting each for the 0 offset. This also should give repeatable positioning of the filter for flat field cal.

IMHO no real difference between GPIO and SPI/GPIO except some loss of high speed over SPI that will not matter on a motor. Programming is different, but not with the right library.

Here's mine- Knockoff Arduino nano.... Second sensor not yet in place but would be covered anyway.


Greg Jones replied to the topic 'Astroberry PiFace' in the forum. 1 year ago

Kaczorek, No real difference in the computer based DIY aspect that I can see. Plug in the stepper drivers or wire us 3 wires per, so some. The hard part is doing the mechanicals. 2 advantages for the Arduino option are: 1) more stepper driver options at a lower cost and; 2) electronic package is much smaller and lighter. There's no reason the focuser and a filter wheel can't be run from either a Pi or Arduino (nano for instance). I would with the PI, not so with an Arduino with the decision based on size. Once the DIY hat is on... :-)

On the filter wheel, a couple of bi-polar hall sensors (IE. A1309KUA-9) and a 6 magnets can do 8 filter slots with position and filter encoding ( if I did it right: NNSSN-S- adjacent sensors, several options for 5, I'm using SN-NS, full feedback). Magnets give N, S and none with 2 sense positions 1 slot apart.


Greg Jones replied to the topic 'Astroberry PiFace' in the forum. 1 year ago


I know this is the PiFace thread, but this may be of interest. It Arduino based with some INDI and ASCOM support. Works with the small motors as well as larger ones and many stepper drivers. Attach to the Pi via USB and put the INDI server on the PI.... my plan anyway. Pi is then the mount "hub" with power and WIFI (or Ethernet) connection minimizing trip hazards.

If you want to omit the Arduino, you may find the example code for your setup useful.

I also have a 28byj48 in my filter wheel that I "borrowed" from someplace. A bit slow, but faster than I am.

BTW the 28byj48 is pretty supposed to be minimal for a focuser unless there's a good gear ration or it's light (eyepiece only??)..


Greg Jones replied to the topic 'Raspberry Pi based Observatory Controller' in the forum. 1 year 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. 2 years 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. 2 years 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. 2 years 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. 2 years 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. 2 years 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. 2 years 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. 2 years 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. 2 years 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. 2 years 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.



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!