I have the following problem at home: the balcony is small, the tube is big and I am lazy. This sums up to a constant problem of drifting, the planet or lunar surface being imaged slowly walks away. Though there are methods to polar align a mount even when there is no way to see the north pole, the small balcony part means frequent small bumps into the whole thing. The oversized scope is also prone to accidents. I also tried the feature tracker in Sharpcap, failed, and the autoguiding of PHD2, failed. So I came up with the soapbox ensemble. I call it noszogtató in Hungarian, for it means something like nagger-pusher-convincer. It got itself a soapbox, literally.
UPDATE 2019-09-30: I extended the hardware and the software.
- block diagram
- desktop app
- arduino code
- conclusions, photos
I wanted the program to be as simple as a stone. Obviously, the homunculus is the best analogy: when the little man sees a drift, compensate. When an input arrives, react.
Interval: compensate with fine tuned values at a preset time if the real human is the single source of feedback. This is what the big man did initially: push the buttons and push the object back to the center.
Grabbing the screen of the operating system, or that of a particular window, of a particular widget, is easier and more portable than writing driver interfaces, while allowing the recording software to connect to the camera at the same time.
For planetary imaging (planets and surfaces), the sampling rate is more than enough to not depend on a calibration and the prediction of commands. For deepsky, this solution is not viable.
No lengthy calibration, backlash counting, just a presumption: ra+ will move the object in the image left and dec+ will move the object downwards — so orient the camera accordingly and invert the axes as necessary. A future version may get a calibration and thus custom rotation-mirroring detection, but not now.
The device should stop pushing the mount on any technical failure.
The device should alert, if possible, that a failure has occurred.
In its default state, the device does nothing. The soapbox affects on a countdown basis: the desktop doesn’t set the state of the pins, but expresses a desire to add a value to the countdown associated with a certain movement, with a resolution of 10ms. The exclusive logic is done by the soapbox: if the latest command is dec+ add 500 and dec- is running, then make dec- zero and start dec+. This way, if the connection drops or the desktop program freezes etc, the device quickly consumes the values in the countdowns and becomes idle, leaving the mount alone.
The telescope has four (ra+, ra-, dec+, dec-) pulled up input pins and a ground exposed on the ST4, so the only thing that can be set on this port is the length of the pulling down. The autoguiding speed setting in the hand controller is certainly useful. Just make sure it doesn’t go into a ping-pong oscillation. At maximal resolution (Jupiter goes up to 240 pixels) I use it at 0.5x.
The device receives commands in the #command/ format, so many at a time can be strung together. In case of the ra dec commands, a command is, for example #rap,1500/ meaning stop ra minus if running and add 1500 milliseconds to ra plus. The device responds asap, but the capacity of the serial buffer (32 bytes or something) should be considered.
The device can be set to expect UART messages, and should those messages go missing for a few seconds, it starts beeping. This is useful when, for whatever reason, the desktop app becomes unresponsive, and is unable to beep. Similarly, the desktop app beeps if the device goes missing, on connection error for example.
I wrote it in Lazarus, because I still like it. Though the pascal syntax has fallen out of my muscle memory, mostly tailored now for the C syntax, I spent some great months programming stuff in imperative pascal, and then in Delphi. I still like it, and it’s my go to language for the desktop. Eff Microsoft.
However, the code is as is, to me it’s more important that it works, regardless of the state of the source code — much of the original code I wrote in very awkward and uncomfortable positions, while some clouds passed in front of Jupiter.
There would have been no need for a desktop app if an interval was the only thing needed. But the desktop makes the screen grabbing possible. So here’s the block diagram of the desktop app.
The interface is designed to stay on top and pull Sharpcap back to the top should it go minimized while starting to record. This is an awkward behavior, but it’s being handled.
Also, the application can be set to apply kicks to the file system, to prevent an external hard drive from spinning down. It does take a few seconds for an external HDD to spin up, and it causes the Sharpcap interface to freeze for those seconds.
The program tries to connect to the first CH340 chip (Arduino nano USB-serial adapter) it finds. This may change in the future. I’m also developing a fingerprint for the application to leave alone devices that don’t match the fingerprint the app is looking for.
Apparently it is not a good friend of eqmod, I use it with a hand controller.
The source code is in this zip here. It contains an exe too, don’t trust it, compile your own.
The arduino code started simple, but I added quite a few features.
The mount pins logic is still simple. It is based on a countdown logic. Each pin has its opposite, to drive ra+ is meaningless when driving ra-, for example. I use pins 9, 10, 11 and 12.
For the hardware this github repo gave me the needed inspiration. However, the first instance of the hardware was a raspberry pi listening for http get commands and closing/opening relays. So the first version of the board is not exactly professional. The second version got a bit better.
The ST4 port is in fact an RJ11 or RJ14 outlet with 6 pins, out of which five are used. Coincidentally, the form factor of the plug is compatible with the RJ45, but a four pin (6P4C) RJ11 telephone outlet can easily be extended by adding the two missing pins (to make it 6P6C) — and thanks to one of my colleagues, Adi, for giving me the idea and “making” me the first connector from two old, unused phone outlets, and giving me further ideas. The resistors near the ST4 outlet are for my spiritual peace.
I also built the focuser part and used an RJ45 for that. This part can obviously be omitted. Also note that the colors are not that of the Cat5 pairs, and may be in random order, as it came from an extension socket cut in half. Anyway, I mapped out this table, more for myself only, cause anyone reading this article can probably come up with something equally good or better.
|The focuser RJ45 as it turned out to be|
|1||In (pull-up): focus right||5||In (pull-up): focus faster|
|2||In (pull-up): focus left||6||GND|
|3||Out: enable||7||In (pull-up): focus slower|
|4||Out: left||8||Out: right|
It works, if the sky stays clear. It also has a blind drive mode, so one minute or two don’t matter.
The one drawback is the rotation of the field of view. Just as with the alt-az mount, an inaccurate equatorial alignment will yield a noticeable field rotation, of a few degrees perhaps, over the hours. Nothing big enough to render useless the stacking of a 30 Saturn video. The PIPP-AS!2/3-registax software stack does its job.