explorad

In case anyone was wondering: I'm still working on this, but a 12" telescope is watiting to be finished as well. When it's done I'll post more about explorad and try to finish it.

I've created a github repo, added a system design document (SDD) and added license information as required by the contest rules.

The github repo is linked to in the project's link section. It currently only contains the SDD. Code will be added once it is easier to handle (bugs aside). License information was added in the project description, but that's preliminary.

After a bit of fighting I can present this video. The annotation looked ok when I watched the video on youtube, but not here.

I've added the CC3000 module quite some time ago, but couldn't use it along with the SD card and my DMA display driver - all use the SPI. SD card and display cooperated, but the CC3000 did something the other drivers didn't like. So I created a small, almost brain-dead library that can save and restore SPI settings and voilá - all three are working.

The remaining huge problem is that the adafruit library for the CC3000 doesn't seem to support non-blocking operations. I cannot try to update my display 25 times per second, read data from the SD card between frame updates and wait for a ping response that takes 200 ms. A delay function that takes negative arguments would be cool now...

I admit it, breadboards are not really mobile even if battery powered, but I'm now working on the input device again. It served me well so far - providing 5 buttons - but it's still lacking a battery and a charger circuit. When I've done that, I'll get back to the main device.

Don't try to debug GPS code when you just can't get enough satellites into view. It will ruin your day.

I downloaded the Revised New General Catalogue and Index Catalogue by Wolfgang Steinicke, which contains 13957 objects (galaxies, nebulae, star clusters, and so on). It comes as an Excel spreadsheet, so I converted it to ascii (fixed column width) and converted that to a custom binary format. The catalogue contains cross identifications where applicable, such as those for the Messier objects.

The Messier IDs are included in my binary format as an alternative ID for on-screen display. For example, the Great Orion Nebula (NGC 1976) has the alternative ID M 43, which is the displayed ID. Other NGC/IC entries don't have a Messier ID, and are displayed with their NGC or IC number. Here's a display picture of the region around M 43:

When the mount orientation changes, new patches are loaded. That's the theory.

Some patches contain as many as 267 objects, and some are empty. I need to filter out most of them, otherwise the display would get far too crowded (apart from the fact that the CPU and memory couldn't handle that many). This is done by loading the objects in each patch, one by one, adding them to an array, while overwriting fainter ones. The resulting displayed objects are the 10 objects with the greatest visual magnitude. Still crowded, but I'm not too worried about that now.

In the above picture you can also see that the target name (lower right corner) is still the hard-coded "south" target. I need to implement an object search that can look for NGC, IC and Messier objects.

Compared to the main project picture: I'm getting closer!

The code is becoming more and more obfuscated, but that's normal I guess...

A minor detail, but it gave me quite a headache. If a target is not in view, you want to know where it roughly is, right? I've created a target hint that is drawn just outside the telrad circles.

In the picture below, the target is south, below left, and the hint points right at it:

The target hint follows azimuth, altitude and roll. I still have to test how it behaves for targets near the zenith, but I'm too lazy right now.

Special Thanks to the folks in the gamedev.stackexchange chat!

I've implemented all those coordinate conversions and added an "objects" widget that can be enabled in the on-screen menu. So far, this widget just displays the centroids of each sky patch as a little triangle. That a huge step forward, because the patches' centroids are stored in terms of right ascension and declination - just like the real objects I want to read from a database. Here's a typical picture:

At the top, you can see the menu with the "Telrad Circles", "Target" and "Objects" icons activated (the first three from left to right). The "S" marker near the center is an artificial marker I needed for debugging, and it marks the horizontal south. The Target is "south" as well, indicated by the small "x" just below the "S".

When I move the device (lift up one edge) or turn the artificial azimuth potentiometer, the screen shifts or tilts accordingly and new sky patches are reloaded on the fly. CPU load is about 55 % depending on what is displayed, and I still draw at 25 fps.

I've also built a small dummy dobson mount which will hold the accelerometer and the artificial azimuth pot as long as I don't have anything better. It's made of 30 x 30 mm L-shaped aluminium, a piece of wood and the usual nuts and bolts (M5 x 16 screw - washer - aluminium - aluminium - spring washer - washer - self-locking nut):

Coming up next: the third attempt at object databases or a battery plus charger circuit for the input device.

I'm currently implementing the conversion between equatorial coordinates (object positions in catalogues) and horizontal coordinates (positions in the observer's coordinate system) and back. I need the universal time (UTC might be sufficient as we don't need to be overly precise here) and the observer's position for that. Both can be obtained with GPS, but there's one problem with that: GPS doesn't work inside buildings and I'm writing and testing the code inside. I will add a menu that allows to set both to sensible defaults or to manually entered values.

My goal is to have an automatic startup procedure that tries to obtain a GPS fix and switches to the default/manual mode if that cannot be obtained within a reasonable time. That should be ok for the location as I'm usually observing from the same place, but the time must be set manually nonetheless if there's no GPS available.

There are some very helpful sites that on those conversions:

Wikipedia article on Julian Day

Approximate Sidereal Time - US Naval Observatory

Local Sideral Time clock - an online calculator that is very helpful during debugging

Wikipedia article on Astronomical Coordinate Systems

It's kinda cool when your coding problems boil down to the fact that earth rotates.