Installation of the EQ3 SynScan Upgrade

I just got the Skywatcher EQ3 SynScan Goto Upgrade. It comes with lots of documentation. For example on how to wire up the controller boxes. However, it does not explain, how to mount the motors, that come with the upgrade box! And neither does the EQ3-2 manual.

Hence I will describe how I installed the motors. I don’t know if I did it correctly, but my SynScan seems to work, so I cannot be far off. If you use this description for assembling your own upgrade kit, you do it on your own risk! You have been warned… By the way, one screw was left over in the end. But isn’t it always?

So the first thing to do is to remove your telescope, your counterweights and the flexible tuning knobs. This leaves you with your tripod and your EQ3 mount. I am describing this for my EQ3-2 with aluminium tripod (rectangular legs).  If you have an EQ3, NEQ3 (round legged steel tripod) your mileage may vary. The manual first tells us to mount the holders for the motor controller and the SkyScan controller. The first one is a bugger: it’s made for the round legged tripod. But do not fear! We can use a rubber band to help it stay affixed to the aluminium legs. Make sure the ground plate has contact with the aluminium legs!

Next up are the gears for the motors. They are not labelled, so I had to figure them out myself. The big one is for the Dec motor, the small one for the RA motor. The motors themselves also were not labeled. The naked one is the RA motor, the boxed one is the Dec motor.

Ok, so we will begin with the RA motor. This is the place where it will be mounted:

There is already a screw here, and the axle for the gear. Mount the RA gear on the axle, so that it fits nicely with the end of the axle. This will be the right height for the RA motor gear. use the two small inset screws to firmly attach the gear. Make sure not to make it to loose, nor to tight! Then you can attach the RA motor as pictured on the mount point. The mounting plate will fit snugly into the corner of the mount, and will keep the motor in place. You can jiggle it around before fastening the screw, so that the two gears fit well together. Check the photos on how this should look from the front and behind.

You noticed that there is a cable hanging from the RA motor. Find the black casing with the two DIN sockets. It will have a fitting socket for the dangling cable. Attach both and put the casing on top of the motor and the gear assembly. Take good care to carefully wrap the coloured cables into one corner of the black box! They fit in there, without any trouble, but you have to find the right corner. If you managed to fit the box, you will see two screw holes ligning up on the front and top of the box.

Use the two tiny black screws to fixate the RA box. The top screw might be hard to reach, even with the small screwdriver that comes with the kit. I used a ratchet with a PH bit for this part.
Ok, that’s the RA assembly. Now for the Dec motor. The mounting point for this is on the other side of the EQ3. See the picture for details.

The mount point where the screw belongs is circled. first, attach the Dec gear. Leave about 1/2 mm space between the mount and the gear. Again, there are two small inset screws to fasten it. You can adjust the gear again later, if needed. Now attach the motor using a screw and a washer (they come with the upgrade kit). With both motors, test if the gears touch tightly enough, so they will not skip, and they will not have too much friction either. See the picture for a view of the mounted motor. Strangely, I could not get the Dec gear to be parallel with the motor gear. But still, the whole thing works. I might try to re-align it later.

That’s it! Now you only need to attach all the cables, as described in the manual, and you’re ready to go, or to go-to. 🙂 I still had one thing left: a black soft rubber thing. If anyone knows what it is for, please drop me a note. It was not described in the manual either.

Note to self: codesigning for OS X and iOS on the command line

As a reminder for myself, here is how you can codesign an OS X application for the AppStore on the command line:

codesign -f -s "3rd Party Mac Developer Application: Your Company" -v YourApp.app
productbuild --component YourApp.app /Applications --sign "3rd Party Mac Developer Installer: Your Company" YourApp.pkg

There is a lot more to do, of course, like having the correct bundle ID set, but this speeds up codesigning, if you do not use XCode to build your application.

For iOS it is pretty similar, except you don’t need the productbuild:

codesign -f -s "iPhone Distribution: Your Company" -v YourApp.app

Saving matplotlib plots as PDF

I recently started using matplotlib together with PyQt, and I love it. It’s awesome and has many more features compared to PyQWT. However, I needed to save the plots to a PDF file. Here is how you do that:

import matplotlib.backends.backend_pdf
...
   @QtCore.pyqtSlot()
   def printPlots(self):
      filename,_ = QtGui.QFileDialog.getSaveFileName(self, "Save plots as PDF file", "", "Portable Document File (*.pdf)")
      if filename == "":
         return
      pp = matplotlib.backends.backend_pdf.PdfPages(filename)
      pp.savefig(self.plotFigure)
      pp.close()

Assuming that your figure is called self.plotFigure. You can connect the above slot to a QAction and map it to some nice menu item or shortcut.

Is “not None” maybe “Something”?

I just had a funny thought. In Python you can write:

if not someObject is None:
    someObject.doSomething()
else:
    print "someObject is None!"

This reads a bit strange. So what if you could alias “not … is None” to “… is Something”?

if someObject is Something:
    someObject.doSomething()
else:
    print "someObject is None!"

It seems that this idea was thought of almost eight years ago already. This lead to some PEP 0326, which got rejected. If Python were a macro or functional language, you could probably hack something up to do the same thing, but it does not work like that:

>>> Something = not None
>>> Something
True
>>> A = [1,2,3]
>>> if A is Something:
...     print "This is something"
... else:
...     print "This is nothing"
... 
This is nothing
>>>

The problem here being, that “non None” is immediately evaluated to “True”, since “None” can be implicitly converted to “False” in a boolean sense. Was a funny thought, though.

Update: Turns out you can at least write “if someObject is not None:”, which is more readable.

Alignment of double values on ARM architectures

Consider the following code:

class C {
...
uint8_t *data;
size_t size;
...

void writeDouble(double v)
{
    ...
    reinterpret_cast<double*>(this->data)[this->size] = v;
    this->size += sizeof(double);
    ...
}

};

Looks harmless enough, doesn’t it? But here is the problem: It’s not necessarily portable or well behaving code. After debugging for about three hours, I found out something interesting. Namely that on ARM platforms, such as the iPhone, double values on the stack need to be stored at 8 byte aligned memory addresses. This was some existing code I was using, so it took me a while to get to this function and to its problem. Single precision float values have no such restriction, by the way. There are two workarounds in the above case. 1) Write a small for-loop that casts the double value to a uint8_t * and copy the double value byte-wise, or 2) use malloc to copy the value. I did the for-loop, since I thought that maybe the malloc call has too much overhead. I guess you could also cast the double to a uint32_t * pointing to two 32 bit words. Anyway, take care when doing such drastic casts. Some platforms might want alignment for some datatypes!

Valgrind checking of iOS programs

Well, this is awesome news. First, valgrind has been available for OS X for some time now. And second, you can use it to check your iOS programs on the simulator with it.

The idea here is to let your program spawn valgrind itself. Because you cannot tell the simulator to run the program through valgrind. Well, maybe you could build a funky bundle, but I think this works just fine. So here is the  code, taken from the above link:

#define VALGRIND "/usr/local/valgrind/bin/valgrind"
 
int main(int argc, char *argv[]) {
#ifdef VALGRIND_REXEC
    /* Using the valgrind build config, rexec ourself
     * in valgrind */
    if (argc < 2 || (argc >= 2 && strcmp(argv[1], "-valgrind") != 0)) {
        execl(VALGRIND, VALGRIND, "--leak-check=full", "--dsymutil=yes", argv[0], "-valgrind",
              NULL);
    }
#endif
  
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    int retVal = UIApplicationMain(argc, argv, nil, @"PeepsAppDelegate");
    [pool release];
    return retVal;
}

You will obviously want to define the VALGRIND_REXEC macro, if you need valgrind output. You can also pass different command line arguments to valgrind. E.g. you can switch to different valgrind tools this way, or pipe everything to a log-file.
Update: I finally got around to trying out this method. One problem here is that valgrind will fail to run, since it tries to open /dev/random, which I guess is not allowed for sandboxed applications. But one can fix this by patching and recompiling valgrind, which is not too hard. Especially when using MacPorts. Furthermore, I needed to add –dsymutil=yes to the valgrind options, or else the program would just crash.