or The ultimate Telrad / QuInsight USB Power / Blinker Mod
I had that "blinker mod" implemented over a decade ago using the trivial LM555 timer IC for my Telrad (you can easily google for that circuit and Telrad integration guides, there are plenty online). But as I have recently acquired the more advanced collimator sight the QuInsight I decided to make a more advanced blinker as well. But it turned out so advanced that I see it frankly opening the IoT era in amateur astronomy!
PrefaceFor several years by now I rarely using my Telrad with its stock power supply (two AA batteries). As simply adding a larger resistor and a micro-USB port-holding PCB I'm powering it from the general USB power bank which is always on the OTA powering my Smartphone and also passively serving as a part of the moving counterweight on the magnet I'm sliding along my Zhumell 12. Having all power consumption standardized to USB 5V is very convenient as power supplies and cables are totally interchangeable can provide plenty of power and there is no need to stock on batteries as you can recharge power banks from a smallish solar panel during day or from the car while driving or at home overnight. Try to find two AAs in the middle of a Chiley desert...
Approaching this mod I've realized that with that much power at hand I can use for the blinker a real SoC circuit (a microcomputer) instead of the dumb timer as I had several former circuits laying around for my GoogleHome IoT projects and none of the latter left in my IC cach anyway. A SoC solution is also much simpler to build as most of the blinking hardware can be implemented programmatically on the chip.
Mechanical designThe QuInsight has quite a roomy battery compartment base with a separate AA batteries holder wired to the LED and the pot body in one corner. It is covered from the bottom with the thin slide-in "drawer" cover. It has four walls available for locating the USB port opening. Ideal enclosure for a microcomputer!
Initially, I had an idea to cut the hole for the micro USB port in the wall of the drawer, so the cable would go straight down along he OTA. That means the SoC PCB need to be mounted on the bottom of the drawer so the USB port at the bottom of its back wall. That means having moving wires going from PCB to the LED and the PCB potentially interfering with the pot body and wires just 4 mm above. Also, I have later designed a very unique scope mount shoe for QuInsight, which is quite close to the focuser (stay tuned for that project blog-post soon) and has a hard stop at the bottom of the shoe which leaves very little room for the USB cable connector casing. These issues are indeed fixable, but seems really sub-optimal.
After some fiddling with the cable and QuInsight in the new shoe on the OTA, I've realized that the side port opening could be much more beneficial, as I can route the cable behind the optical finder shoe above the focuser and completely out of the observer's way behind the OTA. In addition, that would help to avoid any parts interference on the inside and on outside of the battery compartment.
To do that the SoC PCB must be mounted on the "ceiling" of the battery compartment. But the vast majority of the space there is occupied by the rotating "puck" of the reticle module with LED wires coming from the middle. Fortunately, there is enough vertical space there to just rise the PCB above the puck high enough to avoid any interference and alloe free rotation of the module.
After multiple redesigns of the PCB holder targeting the tight fit and minimal excess space occupancy I have been satisfied with this one:
Fig.1 3D design of the SoC PCB cradle (orange on Fig. 2).
This "cradle" has 3 "legs" rising it above the "puck" for about 4mm which is plenty for free rotation with twisting wires. The shape of the leg is pyramidal to minimize the footprint near the walls as the "puck"s well is almost touching walls. There are multiple 1mm screw holes to attach it to side walls with tiny flat-head wood-screws as I want it easily removable and replaceable if the need arises, but I'm using only two of them on the USB port side to keep the board tight against the right (top on the OTA) wall so the USB port is rock solid when accepting the connector.
Printed (in my favorite orange PETG), cleaned the print, slid in the SoC PCB in tight, cut holes for the port and screws in the QuInsight wall using printed template. Assembled. Looks and holds great!
Fig 2. The QuInsight battery compartment with the PCB installed and wired.
Soldered the proper digital out pins to power the LED over 450 Ohm current limiting resistor (blue heatshrink), the Analog Input pin to the potentiometer for manual input commands (yellow). On the image you can see the row of pins bent in to the left. That's just for the ease of soldering wires and to avoid them propping up too much (I had to ditch the idea of making disconnectable joints, too much a hassle, less reliable, and also too close to the vertical space limit). Just 11 solder joints total. The cradle is deep enough to avoid anything getting in over the board and shallow enough to reach out for the in/out soldering points with the iron without removing the board.
On the side it's a bit ugly looking with the screws and the hole:
Fig 3. Usb port and mouting screws on the outside wall of QuInsight
But see what I have in the port:
Fig 4. Magnetic connector and USB cable with magnetic head.
That is the magnetic USB power cord head (the matching magnetic head on the 7' cord you can see nearby is already sensing the mating magnetic field and has 540 degrees of freedom to rotate around for best cable placing). That's an ultimate power connector to deal with in the dark!
Simple, easy, quick, and totally adequate to the task physical mod.
Simple, easy, quick, and totally adequate to the task physical mod.
I have plenty of ideas for the blinker hardware improvement and extension recorded in my GitHub flowchart already. The top five are:
- Add the weather chip (already on the ship from China) to measure temperature, humidity, and air pressure to calculate the dew point conditions notify about them and even control the dew heater (controlled with same PWM as the LED from the SoC) to maintain QuInsight above the dew point.
- Add the LiPO Cell circuit for autonomous controller powering. A typical 2Ah 18650 cell is totally adequate to power the controller for ~30 hours with WiFi On and ~30 days without (with the potentiometer control only, see below).
- Add "the user approaching" sensor (IR radar) to turn on the LED only when I'm near the reticle (along with the "shallow sleep" mode available on the device that could prolong the battery life 2-3 times easily).
- Add the gyro-accelerometer-compass chip. The TPM with QuInsight does wonders for pointing, but I could leverage the Virtual DSC pointing in the day-light in a snap.
- The chip is capable of supporting TFT/OLED screens. I have one amazing but very secret idea for that too.
The brain of the "Uber-Blinker" is a cheap (~$5 shipped) ESP8266 SoC on ESP-12 hat which in a nutshell is a microcomputer with the micro USB port (for power and wired communication), WiFi radio (Access point and infrastructure connectivity), one analog input (to connect a variable potentiometer for example), and several digital in/out multipurpose ports (to connect external digital sensors, LEDs, and sub-controllers as desired). It has some flash storage and some RAM. An extremely capable system, not very power hungry, and very compact (see detailed specs).
But most importantly it has plenty of community support with myriads of interesting projects implemented with it floating around in the Open Domain. My goal was to have a system I could easily tweak in the field all the way to repurposing it from a simple blinker into anything even not astronomy related if I wish, e.g. a connected security perimeter system, a weather station, an EQ platform controller, dew heater controller, etc, right from the observing chair. And that's not just a wish. For several years I've been leveraging the great ESP Basic project for such things development on the go.
The Onboard ESP Basic is a very simple set of instructions following the BASIC language structure (with subroutines and Goto steps) custom-tailored to issue commands to ESP8266 microcontroller from a plain text file saved in the flash memory of the chip. But most importantly, this firmware also creating a simple web server right on the chip which you can access from ANY web browser over WiFi connection (having the chip connected to your home network or directly to your computer/smartphone/tablet/chromebook). Can't you feel opening perspectives yet? They are simply insanely enormous...
My BASIC app for the blinker is just 214 rather short text lines of code total but already implementing the following:
- The fine-tuned for smartphone screens Web server page, with:
- The sophisticated Night Mode CSS color scheme preventing the UI ruining my darkness adaptation (can be reused with any BASIC code drawing the user interface).
- With the link to the microcontroller configuration and programming interface pages for quick access (however they have no Night Mode).
- Simple fully functional user interface BASIC code for the following functions:
- The LED brightness smart controller code, utilizing the PWM to go very low, which:
- Sets the minimal brightness on power connected.
- Provides a slider and two buttons on the screen to control the brightness on the custom non-linear brightness ramp (like 4 minimal brightness levels steps first, then a warning step with no light, then 4 maximum brightness levels) designed to be easily changeable in the code within a single line of values from 0 to 1023 (the PWM modulation ratio).
- The LED blinking smart controller code, which:
- Provides 4 buttons and 2 sliders on the phone screen to control the light pulse parameters:
- Pulse duration time.
- Pulse delay time.
- Setting any slider to 0 disables the blinker.
- The brightness of the pulse is controlled by the above LED brightness feature.
- Calculator-like 9 buttons at the bottom of the screen which allow to launch subroutines with a couple lines of code each, setting the LED brightness and blinking parameters to any combination you might prefer to have one tap of the screen away.
- The code reading the onboard potentiometer position to input data into the controller without the use of the smartphone (reserved for the future smart user input controller implementation which would allow to set modes without the smartphone) for now it can be used to control the brightness same as the slider control on the screen, stepping over the brightness ramp, but on a bit weird tactile ramp, as the pot in the QuInsight has a logarithmic scale).
Fig 5. Smartphone screens of the remote controller. On the right all 9 presets buttons scrolled up.
The user interface (Fig. 5) could be even more minimalist to minimize the amount of light you need to deal with to preserve the eyes darkness adaptation. Buttons are (b / B) to change brightness of the LED, less / more by the non-linear ramp. (d / D) to change the pulse duration, less / more, from 50 ms to 1 sec. (p / P) change blinking period, shorter / longer from 100 ms to 2 sec. 1 ... 9 buttons are for user presets. 1 2 3 are most used visible without the scroll. At the very top you see settings button (will be moved to the bottom below the scroll as it's too bright and better be less accessible). All the buttons are much larger than marking their centers digits/letters so it's hard to miss them (except for "setup" which is hard to tap accidentally). Sliders are good to have to show the current state of the control, but I plan to remove the pulse duration as the shortest pulse seem to work best from my practical experience, any odd pulse durations can be coded in presets. I have the remote code text organized in a way that allows quick removal of any control by simply commenting out a line or two without ruining the rest of the screen layout (the grey bar on the left is the Samsung side-panel drawer handle, sure thing I'm disabling it at night).
Everything works supper stable for days in a row. No overheating or anything. The code is rather trivial and easy to modify on the fly for improvements or changing the blinker behavior as I might all of a sudden see fit in the field. The only issue is that it takes about 30 seconds for the SoC to boot up, connect to the home WiFi hotspot, rise the web server, and start my app which finally brings up the LED On. It's about 10 seconds faster with direct WiFi connection from the phone, still bearable enough as I don't plan turning its power off through the course of the night anyway. Connect and forget.
It took around 10 hours total to build and test the app from scratch (consulting with the ESP BASIC docs often) to my complete satisfaction. The most challenging part was the CSS code for the Night Mode so it would look good on the phone screen.
There are still some ideas to implement for the blinker app though, the top 5 are:
- Add a module saving the last settings of the blinker and presets (see 2) so when turned on it restores what I have been entered / using the last time (good for accidental power failure handling).
- A button to save current manual settings of the blinker under one of the 9 buttons and to add/remove then on the fly, so there is no need to open the code for that, which is a no-no for eyes darkness adaptation (see 5).
- Make a setting to switch the page from night to day mode, as the Night Mode is uber-dark red on black, thus barely visible in the daylight.
- Make a separate Settings page for all settings not needed on the main screen with the option to move them there if needed.
- Modify the ESP BASIC code to allow Day and Night mode switching of the integrated programming/setup interface based on my Night Mode CSS.
My dedicated astronomy smartphone Galaxy Note 4 is always on me when I'm observing with the telescope or without. So it's the obvious remote controller for the "Uber Blinker". But even though you can control it from any browser on your smartphone/tablet most of the browsers have some user interface around the page or popping up here and there as your interacting with the screen to navigate your regular World Wide Web Internet and show you ads. They know nothing about the Darkness Adaptation Religion we are worshiping.
So as a part of this project I have designed a simple Android Web page Viewer app which shows any web page full screen, disabling even system status and navigation bars and with several crucial for Darkness Adaptation preservation options. It works really great already to show the interface of my Uber-Blinker on the phone. As soon as have it polished for the general use I'll be offering it as a part of our DSO Planner app (as the app has the possibility of creating user databases with items having the web link field) and possibly as a separate product on the Android Play Store. Imagine being able to save web pages on your phone and then viewing them without immediately ruining your darkness adaptation at the telescope. Stay tuned!
In addition to that, on all my smartphones I have the Ultimate Android Smartphone Automation App the Tasker. One of the features on its enormous list of features allows drawing a graphical interface of any complexity and binding it to URL calls (web commands). Another Tasker feature allows binding these interfaces to voice commands... So I'm definitely thinking about a set of dedicated controls in my BASIC blinker app convenient to use by voice.