Tuesday, November 3, 2015

When Lightning Strkes ...

This summer was sort of OK for me in terms of Thunderstorm activity in my area except for one particular storm ... I don't remember exactly when it was  - sometime in May or June. There were some frequent lightning strikes in the area and one particular hit was very close to my house. It wasn't a direct hit - I would say it was about a few hundred yards away from the house. We lost power briefly and when it came back - my home network was gone.
Upon a close inspection, the first casualty was a 10-port Linksys ethernet switch - there was charring and obvious damage to the components, with chips blown into pieces, Then, I discovered 2 graphics cards were also gone - a Nvidia GeForce 8800 Ultra on the FlightSim machine and the graphics card on the Ham Shack computer - a Quadro4 NVS280. Finally, the built-in network adapter on the HamShack HP machine was also dead, alongside of a dead USB to RS-232 converter connected to the SteppIR Fluidmotion controller.
I started wondering how the lightning discharge came into the house? ...everything in my lab is grounded - I have a huge copper ground bus, attached with an 8 inch wide solid copper strap to the ground rods and every single piece of equipment in the Ham shack is attached to this bus with  solid copper straps.
For sure it wasn't thru the power lines - otherwise I would have had a lot more damage. It wasn't thru the cable either - TVs, Cable boxes and Cable Modem were all good. All antenna coaxial feed lines were disconnected at the time of the storm so - no damaged radios.
It was a mystery until last week when I powered up my SteppIR controller (it was disconnected from the power supply)  just to be greeted by a dead display and all control LEDs lit up.

This is what the Fluidmotion controller looks on the inside. The thing is a total toss. It absorbed a lot of energy. A lot of the "soot" on the PCBs is in actuality re-deposited metal vapors from the vaporized PCB traces. Even the metallized plastic shell of the male DB-25 control cable connector had some of the metallization vaporized and deposited on the outside of the box.
The controller was grounded via the ground post on the back of the chassis to the main ground bus.

 The transceiver interface board  (top-left) was not spared by the lightning strike - one of the chips was blown to pieces.

It is now obvious that the hit came in thru the control cable. (Continuity checks show both stepper motors - EHU and 80m coil to be OK but I need to test them with a functioning controller.)
 My guess is that the ground wave of lightning strike energy bridged the insulation of the control cable lying on the ground near the antenna. The cable is shielded so it traveled down the shielding of the cable and it found path to the ground via the controller.
Since the controller was connected to the computer, some of the energy traveled thru the serial cable, killing the RS232-to-USB adapter on its path, and down the network CAT5 cable to the switch, killing the switch and the second graphics card in the Flight Sim computer.
The severe damage seen in the photos is due to the poor (other adjectives come to my mind) design of the controller (Thank you for this SteppIR :-( - the outer shield of the female DB-25 connector is not directly connected to the ground lug!!! Instead, the chassis is connected to the board via 2 small posts, supporting the front PCBs. The top cover is all powder-coated, therefore insulated  so no direct path is established from the the DB-25 shell studs to the ground post either. The lightning just traveled thru the main PCB, then thru the connectors to the front PCBs to get to the chassis and ground lug!
This sort of design and execution is rather moronic (and I am being gentle here). Come on SteppIR! If you are in the antenna business, make sure the equipment is properly designed and grounded. Powder-coating and tiny PCB traces are not really "low resistance" for lightning energy - and this was not even a direct hit!!!
They sell a $270 relay option  as a "lightning protection" for the SDA100 (which would be a total waste of money if the new SDA100 controller is grounded internally the same way!)

UPDATE: I just received the SDA100 controller. Honestly, I have mixed feelings about it - while there are a few improvements, I really liked the "one button band selection" mode of the old controller. The user interface remains rather poor and definitely nowhere near the excellent Ultrabeam controller UI. The grounding is improved - they didn't powder-coat the inside on the back wall, thus allowing a direct path between the ground post and the shield of the DB-25 connector.
A couple of tips: The ALP driver board, as I thought is pretty useless - just a bunch of relays disconnecting the driver chips. This will protect the chips from static and over-current but that's about it. At $4.87 per L6219 driver chip (DigiKey) - I need to destroy both of my driver chips 20+ times in order to make it worth the money. I didn't get the ALP driver board and would not recommend it to anyone. The controller is shipped with 4 chips installed, while my BigIR requires only 2 - EHU and 80m Coil so I have 2 spares inside already (the chips are on sockets this time around).
Tip 2: If you really want the ALP driver board and you are buying a new antenna, or controller, don't buy it with the ALP board from the get go - get first the standard board and then later buy the ALP driver board - this way for only $64 more (the difference between the new option price and the upgrade price) you are getting another driver board to have as a spare part.
In this regard, I don't think it is fairly priced - 8 relays and a few more components for $185??!?
Final thoughts after 6 years  - if I had to do my BigIR Vertical all-over. i'd go with the Ultrabeam vertical for sure - the SteppIR design is just executed too half-baked and sloppy for my taste.

Friday, May 1, 2015

StarGate SG-1 Advanced Arduino Neopixel Clock

My fascination with clocks and watches always has been pretty hard to control.
Of course, when I saw the Adafruit Neopixel 60 LED Circle this was the first and most logical thing to come through anyone's mind. I wanted to check out what other have done with the Neopixel and found the  "Stargate LED Clock" project by David Hopkins (hopo28) on GitHub. It is a really well done clock and has some very cool visual effects. The enclosure is fantastic too - exactly as the clock is named - a Stargate. While David's clock is great, I felt that it lacked some features - it is just too uncomplicated for my taste. The ATMega chip has plenty of performance overhead and more than enough memory so I decided the load the clock with as many features as I could come up with and fit in the 32K flash memory.
I started with David's code as a foundation, made a list of enhancements and started implementing the features one by one. In the process I updated the hardware configuration as well. The clock now uses ChronoDot V2.1 as RTC and Adafruit TSL2561 Digital Light Sensor. To add audio output I added a simple piezzo speaker driven with PWM. To implement a menu system and keep it simple enough to control with only 3 buttons I need to use double-click and long-press button actions. The entire de-bounce routine was replaced.
Just to list a few of the features I have added : Menu System for setting all parameters (including the RTC calendar), using color patterns feedback and only 3 buttons, Advanced Brightness Control system, 6 programmable alarm modes, SunRise Alarm, triggered by the level of the ambient light in the room, Audio Volume control with 10 levels and automatic "Quiet Hours" mode, Westminster Quarterly Chimes and hourly beeps, 10 Alarm Songs, Full Calendar display, Custom User-Programmable Color Set (stored in the EEPROM, requires an USB computer connection).
My development platform is an Arduino Uno board but I'll migrate the clock to one of the smaller boards.
David has done  a really good job putting together the base of the clock (Thanks so much!) and it was easy for me to understand his functions and  add all these features, even when I needed to re-organize the program flow.
 Just completed the final revision  of SG-1 V2 (I had to optimize a lot of things and move some stuff to PROGMEM - as expected first I ran out of RAM and then out of program memory (blame is on the 10 alarm songs),

The development platform / prototype: Arduino Uno board, Neopixel 60 LED Circle, ChronoDot v2.1, TSL2561 Digital Light sensor, 3 buttons, piezzo speaker and a resistor.

The Main Color Set - Time is 11:14am (22 sec)

Main Color Set - Time is 1:19pm (37 sec). The Hour color changes to indicate PM.

Custom Color Set - The color of  each element of the display can be configured independently with a serial console and a text menu, displayed by the firmware. This Color Set has 2 modes and can be configured as either Dark (display off) or Custom Colors (User-defined). All colors and clock parameters, including alarm times, modes, sun Rise trigger level, etc are saved in the EEPROM.

Simple Mode - Hour, Minute and Second  - Time is 11:14am (33 sec)

 Calendar Mode : Date is May (orange) 1st (blue), 2015 (white) Friday (green). The day of the week color changes to red for the weekends. The inner part of clock's face helps to quickly determine the date. The hour dots are used for the month, and the date and year are displayed only in-between the dots. It is a bit awkward at first because of the 4 day increments per segment, but one can quickly get used to it. Only the next 32 years are displayed in two runs - each is 16 years, then a new clock face is needed to reflect the next 16 year segment.

 Alarm OFF (left) and Alarm (ON). Alarm for Week days only. Alarm time 7:00am.
One of the color sets displays the Alarm time and mode. If a dual mode is selected - for instance Alarm on Weekdays and Weekends. the display will alternate between the two alarm times.

Alarm ON on Weekdays and Weekends. Alarm Time for the Weekends is 9:55pm (a favorite TV show starts :-). Hour, Minutes and Modes are all set with  the 3 buttons.

Sun Rise Alarm Modes - triggered only once a day! It can be triggered between 4am and 9am and the actual trigger is the level of ambient light in the room (when the Sun raises). The trigger level is sampled beforehand, using a menu item and it is stored in the EEPROM. Some  of the configurable Alarm modes left-to-right: Weekdays Time Alarm + SunRise Alarm on the Weekends, Weekends only SunRise Alarm (no weekdays alarm), Every Day SunRise Alarm

Display Brightness Selector - 59 adjustable levels (left) and Auto mode (right) when the display brightness is controlled by the Ambient Room Light Level. The brighter is in the room, the brighter the clock display will be.

Volume Control (goes to 10 only, not 11:-). Left - Hourly Chime - plays Westminster quarter chimes + Bells for each hour, Right - Hourly Beep mode - beeps on top of each hour. This selector sets also the volume for the button clicks in menu mode. A special Chime Night Mode can be selected - it disables any chimes during the night time quiet hours (23:00 to 05:00)

Calendar Set Mode. All functions, modes, times and calendar can be set using 3 buttons and the menu system (using single, double-clicks and long-press actions)
The only function which requires computer is to set the Custom Colors and Mode for the Custom Color Set.

Part of the menu system - Yes / No selector for Calendar Setup. 

Yes / No selector for Sampling Ambient Light Level trigger threshold for the SunRise Alarm

 Every hour the clock does a random Star Gate visual effect- I didn't change anything in this part of the code - its all hopo28. The effects and animations are pretty cool!
The alarm song selection is a rather geeky (Star Wars, Indiana Jones Theme, etc), but the clock has a RTTTL Player routine so any Rtttl formated song from the web can be added - the only limit is the available PROGMEM space - currently 200 bytes are left from  the 32K.

The Text Menu was enhanced a bit to allow setting of the additional parameters and to provide more detailed status. I also added a separate color element for 3/6/9/12 hour dots.

Now I am working on the enclosure - thinking of something like a picture frame, but will explore other options as well. The clock face needs some improvements as well.
Toying with the idea to use the Light Sensor as sort of  a "Shift register" for the Menu. The user can simply cover with one hand the light sensor and this will change the meaning of the button functions - for instance advancing minutes with one button and when the light sensor is dark (covered), the same button decrements the minutes instead. Another feature I would like to add is an automatic DST but I doubt that ill be able to free up enough program memory for this.

Tuesday, April 28, 2015

Canon EF-S vs. EF Lens shaprness when shooting with APS-C

Since Canon EF-S (S for Small image circle) are the main lenses used with APS-C format cameras, I was wondering what is their quality. There are no L lenses in the EF-S format and I wanted to put them against a similar, kit-grade lens.. I did very simple and un-scientific test and compared 3 lenses - Canon EF-S 18-55mm 3.5-5.6 IS STM, Canon EF-S 55-250mm 4-5.6 IS STM and Canon EF (Full Frame) 28-105 3.5-4.5 USM. These are very inexpensive lenses - both EF-S lenses are often sold as part of the Canon DSLR kits and the Canon EF 28-105mm which was an average (not too shabby but nothing spectacular) lens from the 35mm film days - the one I used was the "better" mark II version (f/1:3.5-4.5, 7 blade, made in Japan). It was a good. well built all-around lens and and a step up from"kit grade" econo zoom lenses at the time (as the EF 35-80mm - a really cheap lens).
All shots were taken with Canon EOS 70D set on manual mode, ISO 500, fully open aperture. The idea was to compare the details in the image thus the lens sharpness. All images are a 100% crop - 1200 x 1000 px  from the original pictures. I chose a subject with a lot of dust particles and imperfections rendering small details.

 EF-S 18-55mm @ 55 mm

 EF 28-105mm @55 mm

EF-S 55-250mm @55mm

Now, this comparison is not quite fair as both EF-S lenes were tested at their very limits where performance is not usually very hot. Still the 28-105mm is the worst of them all even almost in the middle of the zoom range.

Canon EF-S 18-55mm @ ~26mm

Canon EF 28-105mm @28mm
By far - the worst case!

Canon EF 28-105 in "Macro" mode @105mm as close as it will focus.

Canon EF-S 55-250mm did not have such close focus range so I brought the zoom to 166mm to get similar framing, Again it did outperform the EF 28-105mm

So as it turns out - the lenses, bundled nowadays with the Canon DSLR kits are of a much better quality then what you'll get in yester years and will outperform what was considered "an average" lens 15 years ago.

Monday, August 11, 2014

Pebble Steel - the best digital watch I could wish for

In the early 80s, I built my first digital clock using exclusively TTL ICs. I had a crystal oscillator driven by 7400 NAND, a cascaded frequency divider using 7493 Binary counters to get the 1Hz clock and 16Hz for time adjust, cascaded counters for the clock itself, and a multiplexed display using 6x7-segment LEDs (VQB71) decoded with 7447. For a 14 year old geek, it was an amazing journey to build it and see that it actually works. Later I changed the LED display indicators to Russian Nixie tubes but had to re-work the whole display part.
Ever since, I was always inclined to wear a digital watch and especially liked the ones with unusual display but never liked their build design. In the 80s and even today all digital watches had / have the typical shiny metal Timex look or the rubberized Cassio look but they always felt very plastic, cheap and unattractive, so I found myself reverting to the classic analog watches because of the huge variety of designs. When it comes to modern digital watches for the average Geek, I must mention TokyoFlash. They have some pretty cool and unusual designs.
There is another problem I had - one looks at the watch a number of times a day, every day, every month and if you are like me - I'd get tired of the same watch after a month or two and would like to see something else on the display but then it means owning and maintaining a bunch of these watches and who has time and money for that.
That's until I discovered the Pebble Steel - IMHO this is the best digital watch hands down. Note that I am not saying it is the best Smart Watch, which probably it is too. But the ability to use thousands of watchfaces is amazing and the simple yet classic stainless steel look is amazing.

 It has a touch of a "retro" with the rectangular face and the geekiness of the Marvin Malton 160 Flying Hour. It might sound like an oxymoron but it has a stylish look for the geeks. The buttons, which actually stick pretty far out are another very nice touch. The thickness and overall size are just  about right for my hand. There are a two types of finishes and two watchband options - I personally prefer the metal band (although the leather band is pretty nice too) and the stainless steel look. I only wished they didn't display the "Pebble" branding so prominently on the face of the watch - it is somewhat distracting. It just needs 2/3 of this font size IMHO.

What is even better, one can easily build a watchface - after releasing SDK 2.0, pebbles brings the programming side more in-line with the conventional C++. Writing code for Pebble requires some getting used to but it is not that complicated and the SDK is well documented! Here is a version of the Text Watch I wrote (reusing an existing conversion routine for numbers to text out of sheer laziness), but this watchface displays the time using Cyrillic alphabet in my native Bulgarian Language. It can be found in the Pebble Appstore as Bul Watch. The words for "eleven" and "twelve" in Bulgarian language are pretty long, so the font size changes to smaller one when the animation will fly in these words and go back to large when any other word is displayed for the hours text.
Even if you don't care about the Smart Watch capability and Smart Phone connectivity - Pebble Steel works fantastic as plain old watch and you can load some pretty awesome watchfaces. The major drawback is the need to charge it every 7 days, but the magnetic charging cable makes it very easy.
"Major" drawback is when compared to a classic digital watch. It is actually a  major advantage compared to other smart watches. No other smart watch on the market has such battery life! I am a guy who works long hours and I need something that will last for days between charges ! I don't want a useless chunk of metal of my wrist by mid-day! So battery life is fantastic for what it does! The display is great too - black and white but perfect under direct sun light!

Thursday, January 23, 2014

The Intelligent Telescope Dew Shield - iDewShield

Dew has always been a problem during telescope observation, especially so in the summer. The front lens of the telescope cools down rapidly due to emission cooling - the telescope points to the clear sky which readily absorbs any emitted heat by the front lens with nothing to reflect the IR radiation back - the deep-space literally sucks out the heat. As a result, the temperature of the lens drops past the dew point and then humidity in the air forms condensate on the glass.
Dew not only spoils the observation sessions but also dissolves contaminants in the air thus causing deterioration of the anti-reflective coatings. No matter how you slice it - it is a bad thing.
Dew Shields help marginally and they are big and clunky - this adds more weight on the mount too. Heater strips work but they need big marine batteries to haul around and you don't want to over-heat the lens assembly or SCT corrector plate/secondary mirror nor you want to be in the need to jump-start your car. After all, the telescope OTA should stay as close as possible to the ambient temperature to avoid internal air turbulence too.
So, here is the idea I have and it is what I have been working on lately - an Intelligent Dew Shield - iDewShield (again, the dreaded Apple Computers naming convention) based on the Arduino Controller.

The idea is rather simple but should be very effective. Relative Humidity and Ambient  Temperature sensors collect air data and the controller calculates the Dew Point. Then a few degrees of difference are added to the dew point temperature in order to makeup for acquisition inaccuracy and to introduce thermal "inertia". An angled Infra-Red Temperature sensor takes sample of the front lens temperature through a hole in the dew shield - no obstruction of the lens and safe way to sample the temperature from a distance. This data is fed to a comparator which controls a Pulse-Width Modulation circuit for the Heater Strip.
Knowing the exact Dew Point allows the system to heat just a few degrees above it to prevent condensation.
The main advantage of iDewShiled is that - there is no danger of excessively heating the lens and it will be a tremendous energy-saver when operated on battery. Because the lens temperature will be just what is needed to prevent dew from forming and not more, internal air movement due to convection will be minimized in the OTA. Finally, no modification to the telescope is needed - the iDewShield attached to the front with a Velcro strip just like a regular flexible Dew Shield. Adjusting the distance between the IR sensor opening and the front edge of the OTA allows for a precise "spot" measuring of the lens temperature as the sensor has a tight directional pick-up pattern.

A red LCD display with variable brightness, will allow the user to monitor lens temperature, air temperature, air humidity and calculated dew point. The controller will also include low voltage alarm and a voltage shut-down threshold. Calibration constants for all 3 sensors can be entered using a simple 3-button interface.
I am also toying with the idea to include a "dumb" mode - the ambient temperature sensor will be removable from the main sensor unit and can be inserted under the Heating Strip or attached the lens retaining ring with tape/magnet. In the "dumb" mode the controller will operate just as a regular thermostat following a preset temperature.

Monday, October 21, 2013

Laser Collimation of a Newtonian Telescope

There are endless articles on Newtonian telescope collimation all over the Internet. A recurring theme is that plain laser collimation is not the best option since Laser Collimators should be collimated first and most have poor collimation out of the box to begin with. This is probably true and I am not arguing with although my Baader Planetarium Colli SC actually was near perfect out of the box.
Here are a few thoughts on the subject while I was toying with collimation methods on my 8" Meade Schmidt-Newtonian LXD75 SN-8. This articles is intended to explain why the SCA Laser collimators (Self-Centering type) are not the answer and IMHO are over-hyped.
Collimation is the process of aligning the optical axis of each optical component in a common optical axis for the entire instrument. In a Newtonian telescope this means that the Primary Mirror optical axis should align with the eyepiece optical axis perfectly. The secondary mirror which is on the light's path has to be angled properly to match both axises. The tilt angle of the secondary serves to position the eyepiece's optical axis in the physical center of the primary. Then the primary is angled to align the direction of the optical axis so it will match the one of the eyepiece The eyepiece is the reference point since the position and angle of  its optical axis is not adjustable, but the other two components - both mirrors can be angled  and moved in the case of the secondary. Each component in the system - human eye, lenses in eyepiece, secondary, primary mirror and the light from an  object should be treated as vectors - they have XYZ position and direction!

For a laser collimator, collimation means that laser beam should be perfectly centered and parallel with the collimator's mating barrel axis. When inserted in the focuser, it mimics an eyepiece, and its the reference for the entire collimation process - again, a vector connecting and starting from laser LED, located in the XY center of the barrel and exiting the barrel at zero degrees from both X and Y. If there is a slight angular error, it will manifest as much larger linear value after it travels thru the entire OTA system.
An eyepiece is secured in the focuser by either a thumb screw(s) or a compression ring. In both cases, the eyepiece's barrel OD is a tad smaller than the focuser's insertion tube ID to facilitate easy insertion. When secured, the thumb screws push onto the barrel, pressing it against the opposite wall of the focuser, thus offsetting the optical center of the eyepiece inside the fouser tube. (same goes true for the compression ring btw, contrary to the believe that the compression ring grabs the barrel with the same force all around).
Here is the main problem with Self-Centering Collimators - they do work as stated - rubber rings around the barrel are compressed and expand evenly, centering the barrel inside the focuser tube which is fine, except for the fact that your eyepieces does not employ the same self-centering technique. When you collimate the telescope with a SCA collimator, you reference the entire optical system to a perfectly centered eyepiece, but when you use an actual eyepiece, the compression ring or thumb screws will push it to the side and create miss-alignment. Here is an article by Hotech USA describing the issues addressed by the SCA collimator. In fact, while they do solve the centering problem, they create another one by creating an optical axis which, while perfectly centered in the focuser will never match the one of the normal eyepiece when placed and secured by normal means.
What is the answer to the problem with securing and using a laser colimator, besides having the laser collimator collimated - make sure that the OTA is horizontal, the focuser is pointing straight up (90 degrees from the level OTA), place the collimator in the focuser tube and let it rest with its shoulder flush with the top surface of the focuser, tighten carefully but firmly the thumb screws (if two thumb screws are used by the focuser, tighten the first screw until it makes contact with the eyepiece / collimator but its not too tight, tighten the second screw at 100% force and go back and re-tighten the first screw again - this will re-position the eyepiece properly) and lastly, dont touch or wiggle the collimator or move the OTA during collimation.

 Collimator should emulate an eyepiece, including the way it is positioned and secured in the focuser, not introduce a completely new method for centering, which can not be ever achieved with an actual eyepiece. Who cares about repeatability between collimator insertions when it can not be repeated with an eyepiece?
The best is to incorporate the self-centering mechanics in the focuser itself - hear that Moonlite? Or instead of using thumb screws / brass compression ring - use a deep/long wedge with 120 degrees of eyepiece barrel curvature and two angled radial thumb screws near the edges of the wedge.

Friday, July 19, 2013

Using smartphone as a tire toe angle gauge - E-Revo VXL

Here is one quick tip for the RC Cars crowd.
I don't like "eyeballing" things that can be easily measured. For example, the tire's toe angle on many RC cars is often adjusted by drivers just by looking at the tires from the top and estimating the angle - hardly a precise method.
Nowadays, almost everyone is sporting some type of a smartphone and every smartphone has built-in an accelerometer and/or gyroscope sensors. There is a galore of apps using these sensors to turn the smartphones into "spirit levels"and as added bonus, they can be calibrated for relative measurements as well (automatically subtracting the angle measured during the calibration process from the current reading). Just to name a few such apps (all Android OS btw) - Smart Tools, Spirit Level Plus, Precision Bubble Level, Gravitometer, etc...

Step 1 - Place the E-Revo VXL on the corner of the table, laying the car body only on the battery compartment door (bottom tires hanging free in the air). Calibration of the software is done on the flat work surface or even better - placing the phone onto the top battery compartment door - exactly parallel with the length of the car. This is the axis that needs to be calibrated - the other (perpendicular) axis is not important for toe angle adjustment and it is OK to be angled (Revo's battery door is angled in such way). The back of the phone should be laying flat over the surface of the door and the phone should be pressed and held firmly when calibrating it. The picture shows almost zeroed X axis - this is the axis running with the car's length.

Step 2 - Place the phone on top of the wheel (even better if you have only a rim with no tire installed), managing phone's orientation strictly parallel to the length of the car and read / adjust the tire toe angle. (in this case - axis X reads 3.1 degrees toe-in a little too much).

Step 3 - After adjusting the desired toe angle, take off the toe push rod on the adjusted side and use it to adjust the length of the other toe push rod. 

That's all - no need for an expensive specialized gauge.

Tuesday, July 16, 2013

Spektrum Telemetry on E-Revo VXL

My 3 year old son tends to over-steer and over-throttle his E-Revo (he has somewhat fuzzy understanding of the word "gentle" :) so to make the vehicle more kid-friendly I needed an "Exponential control" (Expo) feature and Dual-Rates - something  not available on the cheap stock Traxxas remote control. Naturally, I turned to Spektrum and their DX3S surface radio in particular. The kit came with telemetry capable SR3300T receiver and sensors - such nice functionality should not go to waste.
The SR3300T has inputs for a temperature sensor, a RPM sensor and a LAP sensor. The voltage sensor is internal to the receiver (more on this later...)

 Installing the temperature sensor is a very straight-forward process. I just attached the sensor to the under side of the motor housing using self-adhesive Kapton tape (high-temperature silicone based adhesive).
The RPM sensor install turned out to be a bit more involved. The stock spur gear cover has a mount for RPM sensor but Traxxas telemetry is using magnetic sensor - a small magnet is placed in the spur gear and the sensor on the cover picks up the magnet's rotation. Spektrum, on the other hand is using optical (infra-red) sensor. IMHO this is a more universal solution - a reflective or non-reflective sticker (depending on the situation) can be placed on almost every spinning part and it will not cause off-balance issue like the heavy magnet will.
This picture shows the optical sensor mounted on the spur-gear cover. I drilled a small hole for the opto-couple and secured the little sensor PCB inside the magnetic sensor bed, using the screws provided by Spektrum. A word of caution - the clearance between the inside wall of the spur-gear cover and the spur gear is very small - I had to shorten the screws so they are now flush with the inside wall and don't catch on the spur gear.

This is the outside of the spur-gear cover. The PCB is mounted with two screws inside the "bed" designed for the Traxxas magnetic sensor. I sealed the Spektrum RPM sensor board with black UV resistant silicone sealant for water/dust-proofing and mechanical protection. In addition, by keeping the sensor in the dark, I eliminate the chance for "confusion" in bright sun light. There is very little clearance on the outside of the spur-gear cover too. One should be careful to place the PCB close to the cover and not put too much sealant on the back so when the cover is installed in place, it doesn't get pressed on by the radio receiver box.

The RPM sensor uses either reflective stickers (placed on non-reflective surface) or non-reflective stickers if the rotating object is reflective (bare metal). The spur-gear surface is not smooth and I wasn't sure how well the sticker will adhere. Instead of using the provided stickers, I made my own reflectors.
I used a thin aluminum sheet (roof flashing), which I polished with polishing compound to a mirror surface and covered the polished side with transparent Scotch(tm) tape for weather protection. Then I cut a few "pizza slice" pieces - different sizes to fit on the 3 different spur gears I might use. I epoxy glued the metal slice to the spur gear as shown on the picture. To minimize any potential balancing issues caused by the added eccentric weight, I selected a spot opposite of the magnet's cavity to glue the reflector and filled the cavity with a mixture of epoxy and metal shavings - approximately the same weight of my mirror + glue combo used (I used very precise micro-gram scale). This is probably not needed at all and it is just me, obsessing with accuracy. The spur gear is small enough and light enough that balancing is not a concern - Traxxas certainly didn't provide a way to balance the much heavier magnet in their setup.

The Spektrum DX3S has a nice calibration feature which allows for the RPM reading to be converted and displayed on-screen as an actual speed (either Km/h or MPH are options besides just the raw spur gear RPM count). Maybe I am nitpicking here, but why you have to input the Roll Radius calibration in inches even when using km/h readout - centimeters is the logical unit to be used.
Speaking of Spektrum shortcomings - why on Earth there is no external voltage sensor input? The voltage reported by the Telemetry module is the internal receiver / servo voltage and not the actual battery pack voltage. On electric models, the ESC supplies power to the receiver and it is usually 6v regulated. Only explanation is that it probably never occurred to the designer that the receiver might be used with electric models too.
Too bad that Spektrum never thought of this! I'd take battery pack telemetry reading on any day instead of the stupid LAP timer. What good is lap time for if you don't know that you should be preserving power just to finish?
A possible work-around is to power only the servos from the regulated ESC and have the receiver powered directly by the battery pack. The price to pay is when the setup is used with 3S or 4S LiPo packs or dual NiMH packs connected in series  -  such solution needs a proper preset voltage drop circuit at the input as the receiver can not handle more than 9.6V. Going that route, one needs to mentally add the amount of the voltage drop to the displayed value to get an actual reading.
I might try to open up the receiver and see if I can hack into the internal voltage sense input. Then I can re-purpose the useless LAP sensor connector as a external voltage sensor. Not sure if it is possible - wish I could find the schematics. If successful, I'll eliminate extra wiring and connectors to separate receiver and servo power and can have just a couple of voltage sensor pigtails for different power sources.

All of the Telemetry sensor wires were tucked in the receiver box and in the space under the motor, making for a pretty clean look.

Monday, July 15, 2013

Installing lights on Traxxas E-Revo VXL

My son really wanted his RC car to have lights "just like on the real cars". The Spektrum SR3300T receiver is a 3 channel receiver and the AUX channel can be used to control lights - so why not? Turning the head and tail lights by flipping the AUX switch on the remote control was an extra feature, I thought would be pretty cool. 
Our design goal was : 2 high-intensity white head lights, 2 red (light red / deep orange) position (tail) lights, 1 red/blue flashing ("dash mounted, "police strobe mode" light) - all switched remotely. 2 dual-step intensity, combined break lights / position lights (deep red color, bright - break, dim - tail) - switched on/off at the model, automatic break signal detection and intensity control.
Parts used: rc-lights.com kits - RCL5004E, RCL5090 and miscellaneous connectors, wires, resistors

Front View - head lights - high-intensity cool-white LEDs in chrome "reflector" fixtures providing great level of illumination. The flashing blue/red  strobe light is seen just behind the windshield. This light improves the model's visibility during the twilight hours.

 I made two elongated holes in the Lexan body (using Unibit drill bit) in order to properly align the head lights - parallel to the body, almost level (very slightly tilted forward for maximum illumination of the road ahead of the vehicle). Adjustments were made based on the current suspension settings.

 The head lights wiring harness. The chrome reflector fixtures were glued at the specific angle / position in the elongated openings using hot melt glue. It was a bit tricky to keep them properly oriented while the glue cools down.

 Rear light bar - the black plastic plate with the 6 holes came off the Spektrum DX3S packaging (used to secure the remote control to the cardboard retail box with wire ties. It is the perfect size for the tail light bar. All I need to do is to enlarge 4 of the holes  to accommodate the black plastic bezels and to drill two more mounting holes. The bar is secured to the Revo's wing mount with 3 zip-ties for easy installation/removal.

The outside two LEDs are the dual-intensity, deep red color, tail / brake lights. The inside two LEDs are a second set of tail lights - slightly different red color (deep orange). The LEDs are wired in parallel (on the back side) in two separate pairs and all connections are water-proofed using black UV resistant silicone sealant.

This picture shows the water-proof receiver box with the Spektrum SR3300T receiver mounted, the Y-split wire harness for the dual-servo steering, EBS (electronic break-detection switch) connected in-line with the THR (Throttle) signal going to the ESC (EBS is the clear heat-shrink covered  unit at the top). Pictured also is the RPS (Remote Power Switch) connected between the LED controller and the AUX output of the receiver. It got really tight in the small receiver box but I was able to fit everything inside.

This is my DIY "LED Controller". The RCL5004E comes with a "LED Controller" but it is too bulky and the connector placement didn't work for me. It is not water-resistant too. What they actually call a "LED Controller" in this case is nothing more than a combo of two "power strips" with built-in current limiting resistors.
 I made my own "LED Controller" except I used a single connector, soldered the current-limiting resistors on one side and covered it with silicone and heat-shrink tubing for water-proofing. The wire lead from EBS+RPS plugs in the center of the power strip - left side is RPS controlled for head lights, tail lights and emergency light, the right side is EBS controlled for the dual-intensity brake/tail lights. It could have been even smaller but I left a couple of positions for future expansion and for extra configuration flexibility provided direct power outputs (in case the current limiting takes place at (or near) the LEDs and it is part of the wire harness. In addition, I incorporated two different sets of current limiting resistors with different values per channel - 82 Ohms and 150 Ohms as options for different current (brightness) levels.

The "LED Controller" is positioned between the receiver box and the heatsink of the motor and it is held in place with Velcro. The wire harness for the rear light bar is place in a braided polyamide sleeve. Visible, just in front of the motor between the two servos  is the "emergency light" LED  - it is a special high-intensity dual color (red-blue) fast flashing LED and it is directly plugged in one of the current limited ports of the LED power distributor (on the RPS controlled side).
My goal was to have the wiring look neat - probably this is as good as it will get.

One reason I was trying to avoid the "wire-salad" look is because sometimes, we drive the car with a clear Lexan body that shows off the beautiful vehicle internals (no headlights on the unpainted body).

This is how the complete model looks like. We went with the dark blue/bright yellow color scheme for an improved visibility. The windows were masked as well as the most of the car body, leaving exposed only the areas to be painted blue. Then the yellow paint was applied. All of the painting is done on the under side to protect it from scratches during roll-overs and crashes.

Monday, June 24, 2013

Dual steering servos for E-Revo VXL

Installing a second steering servo on the Traxxas Mini Revo (1/16) VXL is an easy and fairly inexpensive upgrade (about $30 in parts). The E-Revo VXL has already second servo mounting position on the chassis - it is just closed off with a blank cover.
Parts needed - Traxxas 2080 Mini Servo, Traxxas #7043 steering arm kit, link ends and some screws.
There are a few advantages to dual servo steering - the steering is more precise and it holds on better at high speeds, the extra torque provided by the second servo allows you to run much bigger tires, which could otherwise overload  and possibly damage a single servo. Additionally, this setup decreases the wear-and-tear of the servos as the steering load is evenly distributed across both servos.
The main challenge with mounting a second servo is to make sure that both servos are mechanically linked to the bell crank steering arms in such a way that their center (zero) positions (radio: 0 trim, 0 sub-trim) will match perfectly - otherwise they will work against each other!
If their center position is not exactly the same, when linked with the standard, fixed, non-adjustable links, they will "fight" for the center position "ownership", each pulling its side of the bell crank to its own center (zero) and this will cause a premature failure from the constant load (not to mention the increased electrical current).
Some drivers, who use aftermarket 3-channel radios (like the Spektrum DX3S) suggest the use of the AUX channel for the second servo control and then enable the steering (STR) channel mix to the AUX. Doing so brings some serious limitations due to the poorly designed firmware in DX3S - the steering trim on DX3S does not affect the mixed AUX channel - same thing goes for the sub-trim adjustment! If trim is added to the steering channel, AUX will still stay fixed on its own position causing servo binding. Mixing works only during steering wheel commands but not with any of the trims adjustments. AUX channel has its own servo trim function but using it means that one should adjust the steering trim first until the car drives straight with only main servo (STR) linked to the bell crank arm, then adjust AUX trim until spacing between the steering arm and the second servo horn is exactly as the fixed linked and then install the link between that servo and steering arm. This is a severe limitation - no steering trim will be possible on-the-fly without removing a mechanical linkage from one of the servos and going through this procedure again. It turns trimming of the steering into a rather slow and painful process - forget about quick trims when suspension or wheel alignment is adjusted. In addition, the "fighting servos" condition will still exist if the car (ESC) is powered on with no radio turned on to apply trims.

The other way (better IMHO) to do it is to drive both servos from the same steering channel - the original Traxxas receiver has two ports for CH1 or if using a Spektrum receiver one can use a Y-split for the steering channel. Then, the difference between servo's centers is compensated by using an adjustable length mechanical link - turnbuckle or regular screw type adjustable link will do the job. Things are never simple tho - the spacing between the steering arm and the servo horn is very small and a custom adjustable link must be fabricated to fit.

I just used two plastic toe link ends (GPM toe links), trimmed them short enough so their combined length when put back-to-back is just a tiny bit less than the original Traxxas steering link and used a M3 screw as a push rod between them (screw head removed of course)
This approach worked perfectly. I connected both servos to the STR channel on my Spektrum receiver and set the radio to 0 trim, 0 sub trim. Using the original Traxxas fixed link, I linked the servo with the best 90-degrees-servo-horn-to-body position to the steering arm and then connected the other servo with the adjustable link so there was no binding (no buzzing or humming from any of the servos). Using steering sub-trim,  I made the bell crank arm exactly perpendicular to chassis.
I also set the radio for servo travel adjustment of 116% and it seems to give me a little more steering range.
That's all there is to it - steering trim is now available as usual. Adjustable link is not needed if you are really lucky to have both servos matching their center positions, but this is very unlikely due to the way the splines are made in the servo horn - normally, the servo will take the horn exactly at 90 deg. on one side but it will be off when placed 180 degrees from that position (which is actually required for dual servo setup).
I installed metal servo horns but they have exactly the same splines as the plastic ones.
Another mod  I made to the steering system is to replace the plastic bushings in the bell crank with real bearings - Traxxas #5114 - 5mm x 8mm x 2.5mm / sealed which made movement absolutely smooth.