Monday, May 25, 2015

Nixie Tube Clock




If you've poked around the internets where electronics hobbyists collect, it is likely that you are acutely aware of our incontrovertible affinity for building timekeeping clocks.  It is similarly unlikely that you have been able to evade the plenitude of nixie tube based projects.  There is a reason for this.

Nixie tubes are cool.  They have great aesthetic appeal with their difficult-to-photograph, warm orange glow, and dem curvy numerals.  They add an organic je ne sais quoi to a hobby with ostensibly digital design cues.  Further, they pose technical challenges in the way of producing and switching the ~175 V DC needed to light each tube element.  And as far as I am aware, there are no new nixie tubes being produced; as such, procurement can be a challenge unto itself.  My N.O.S. nixies came from Russia thru Ebay, and only 3 were duds.  Incidentally the seller replaced those 3, FOC.

Nixie Tubes and HV Driver
From Russia with love

K155ID1's are shipped in stacks bound by rubber bands

Fortunately, not all nixie tube clocks are implemented the same.  In fact, look around at all the schematics for nixie clocks, and you will realize there are more permutations in methodology than there are models of nixie tubes.  This is how it should be.  We ( DIY electronics people ) like to put our own spin on things.

My version of the Nixie Clock has a few of its own nifty features.  The list includes:
  • Single microcontroller design.
  • Software based RTC.
  • Software driven boost converter for ~175 V DC supply.
  • Time, Date, and behavior configuration via USB
  • Windows application for clock configuration.
  • Time, Date, Temperature, and AC Power line frequency display.

The Name

I was working on the PCB layout and thought it would be cool to write "Nixie Tube Clock" in Cyrillic script, so I did a google translate.  You can see the translation on the top right of the PCB.  Well, it turns out that "Nixie" translates to something of a shapeshifting water-woman.  So, I call this the mermaid clock now.  Thanks to the native language speakers that pointed this out to me.



Downloads

The clock firmware can be found on GitHub here: https://github.com/pilotingpete/Nixie-Tube-Clock

The Nixie Clock Communicator code can be found on GitHub here: https://github.com/pilotingpete/nixieClockCommunicator

An Electronics BOM - Please notify me of any errors:     https://docs.google.com/spreadsheets/d/1ZhO8OGlxGMYI7I5BOQ9BeYuwDf4MAAcQkCAm8IlP1JA/edit?usp=sharing

The KiCad schematic and board files.  Also, a collection of datasheets, and some logfiles from when I calibrated my prototype clock.  Perhaps there are some other files in this archive that I thought were useful while I was working on this project too:  https://docs.google.com/file/d/0B1CPUkh94AtmMmM5Y1NmeGttLWs/edit?usp=drive_web

RTC

Four short years ago I posted about a method for building your own microcontroller based realtime clock.  This is essentially a method to calibrate your xtal to more closely match real time, and some code to keep track of the time and date.  The benefits of a uC based RTC include a reduction in components and everything that comes with that; increased reliability, cost reduction, real estate savings, &c.  We can also achieve accuracy in timekeeping greater than that specified in stand alone IC RTC's datasheets.

In the aforementioned post, we only discussed the theory and showed a proof of concept example.  There were no software provisions for calendar with leap year, 12/24 hr format, etc.  That is, the finishing touches to make a useful RTC for a clock were left out.  This nixie clock builds upon the methods for coding your own RTC and shows the implementation to make a useful clock.  This code could easily be recycled into any number of clock projects with LED, LCD, OLED, displays too.

The core RTC code can keep track of the time and date, account for leap years, and report the day of the week.  One could expand this to take care of DST, but I go into detail about why I don't in the previous post.

While designing the hardware for the clock I added a "zero cross detector" to the incoming AC power line.  We can use this in lieu of the calibrated xtal to keep time - users choice.

All those nixies controlled with just 3 uC lines.  Thanks, shift registers!

USB Interface

Using the ATMega328's built in UART we are able to communicate with the firmware via an FTDI USB cable to configure clock settings and behavior parameters.  These parameters can also be read back out of the clock and/or stored to the internal eeprom of the ATMega328.  Parameters stored to eeprom are read into memory at boot up, so that the clock's configuration is persistent thru total power loss.

For example, open a terminal to 56700 baud and type "celsius=1" and hit enter.  This will set the clock to display the temperature on the Celsius scale.  Setting this parameter to 0 would result in the Fahrenheit scale i.e. "celsius=0".

If you were to type "hours?" the clock would reply with "Hours: nn" where nn is the currently displayed hours.  There are also parameters for "showFreq", "showDate", showTherm; each of which are set to display its unique parameter value at the top of each minute or not.  i.e. if you type "showtherm=1" then at the top of each minute the temperature will be displayed - in Celsius or Fahrenheit as previously discussed.

Below is a screenshot of the available commands.  At the terminal type "help" and hit enter.  The column labeled "command" shows you the available parameters to configure.  "Set/Read" column suggests that you may set a value with '=' and read the value with '?'.  The "Low Lim" and "High Lim" columns show the range of acceptable values to input.

USB Terminal Interface

  • "getall" returns a csv line of all current parameter values.  The order can be verified in the firmware.
  • "ramtoeeprom" will store all current parameters to eeprom so that they are recalled after a total power removal.  Time and date are excluded - view the firmware to confirm all parameters that get stored.
  • "poke" returns the clock serial number - mine is S/N: 100; what will yours be?
  • "pwrok", "hvfeedback", "battvoltage", and "rectifiedac" return system voltages.  Refer to the schematic for voltage points.
  • "doecho" is a UART echo and is useful for typing at a terminal; it lets you see what you are typing.  It is not so useful when using the NCC app and should probably be turned off i.e. "doecho=0"
  • "nixiesleepstart" and "nixiesleepend" set the time that the nixies turn off and on at night.  We dont need to burn up valueable nixie time while we are sleeping.  If nixiesleepstart is 0, then they will never sleep and nixiesleepend is necessarily ignored.
  • "toggleled" if set to 1 then the LED on PD7 will toggle at 1 Hz.  Set to 0 and no more toggling - the LED will remain in its current state.  It is neat, although power wasteful, if toggleled=1 and a power outage occurs.  The LED continues to toggle letting you know the clock is still running.  

Wouldn't it be cool if we had a PC app to handle all the communication?  So that we can just click a button and the app would send the current PC time to the clock, for instance?  I think so too, and more on that below.


Boost Converter

The boost converter utilizes one PWM channel and one ADC channel on the ATMega328.  A function is called at 1 kHz to check the voltage coming out of the boost converter and thru a voltage divider.  If the voltage is higher than a setpoint, then the PWM duty cycle is reduced.  If the voltage is too low, the duty cycle is increased.  The resultant ~175 V DC is quite stable.

*I discovered that stopping the timer is not a suitable method of turning the boost converter off.  The state of the output pin can sometimes come to rest at ON.  The result is a direct short thru the boost converters inductor.  Many fuses gave indication to a problem here.  The solution is to disconnect the pin from the PWM timer in software and then set the output low.  Check the firmware and code comments for more information.

Reflow soldering the SMD components

Kapton Solder Paste Screen

Hardware

There were/are a couple of mistakes made when I designed the PCB.

First, the datasheet I have for the nixie tubes was incorrect.  I used the datasheet to make PCB footprints in KiCad and never checked the physical tube before sending the PCB to manufacture.  They were in the mail at the time.  The physical tubes are a full 180 degrees upside down compared to the datasheet.  I corrected this in KiCad and sent the new gerbers to be manufactured again.

The new boards came back ready to go.  Or as it would turn out, ready for me to find more mistakes.  Like R8, which is supposed to be a pullup resistor for the DS18B20 temperature sensor, not a pulldown as I drew originally.  I discovered this one when I couldn't get any temperature readings.  Rather than remake the boards I drilled out R8's via to GND and added a wire jumper to VCC.  You can see this fix below.

Drilled out VIA to disconnect R8 from GND

Red Jumper for R8 to VCC

The R8 pullup/pulldown error has been fixed in KiCad and included in V1.1 as REV A.

Prior to discovering the pullup/pulldown mix up on the DS18B20, I had discovered that my linear voltage regulator supplying VCC was overheating.  I had underestimated how much current the HV driver IC's would consume - they doubled the circuit total.  I also underestimated the voltage that would be coming out of my 12 V AC adapter.  It is approaching 18 V DC after rectification.

To salvage this embarrassingly obvious oversight I ordered 10 premade buck converters from ebay for about $10 total.  They are based on the LM2596 IC and are voltage output adjustable.  Now, I feed that ~18 V DC into the buck converter and send ~6.5 V DC out to the linear regulator.   Hopefully, I will remember this lesson and incorporate buck converters appropriately in the future.

Below are some pictures showing the repair/mistake.  Since this photo was taken I have potted the linear regulator and wires to prevent shorts or strain failures.


LM2596 Buck Converter

Buck Converter Wiring

I currently have several of these nixie clock boards as spare.  If you would like one, send me an email and I can figure out how much they cost.  Although I did drill out R8's VIA on all boards they are subject to needing the R8 jumper to VCC fix still, and the buck regulator fix described above.

SW1

There is an unpopulated tactile switch on my PCB.  I put it there "just in case" but I don't have a need for it.  Perhaps it could be used to cancel an alarm or put the nixies to sleep/wake them up?  Let me know if you end up coding anything for it!

 Battery Backup

In the picture below you can see the battery backup schematic.  BATT-4.5V is just a 3x AAA battery holder.  I resisted the urge to use a CR2032 battery or similar in lieu of the larger AAA batteries.  My reasoning being that I have plenty of real estate inside the clock case, and weight was not a concern.  Also, I always have AAA batteries on hand, and they are cheap.

So, this battery pack is connected to VCC via a schottky diode such that the battery is not a source so long as VCC is at a greater potential.  When power is lost, and VCC is at a lower potential than BATT_VOLTAGE, the diode allows the battery backup to conduct and keep the circuit alive seamlessly.

Here, BATT_VOLTAGE goes to the ADC on the ATMega328 and allows us to measure the voltage of the battery pack.  Presumably, we could work out a way to determine when battery replacement is necessary.  For now, we just read the voltage.



AC Frequency Measurement

Below you can see a schematic showing the method of digitizing the AC input waveform.  There is a nominal 12 V AC on L1 and L2.  AC_FREQ goes to a pin with internal pullup on the ATMega328.  Therefore, this pin is normally high and pulled low once per positive AC cycle.  Say, for an AC sine wave input somewhere between 0 and Pi there is a square pulse output. 

I included this part of the circuit mainly because I wanted to measure the ac frequency of the power line.  I have never done his before, and thought it would be a good opportunity to do so.  There is the added benefit that you could use this AC input to drive the clock if you were so inclined.  The software would just need to count up 60 cycles ( or 50 in some countries ) and tick over the seconds.

EDIT: As I wrote the previous paragraph I realized that I should just take a break and code the AC frequency as a timekeeping source.   To run the clock in this mode, you can now type "acclock=1" at the terminal.

I am partial to the xtal calibration method described in the RTC section above ("acclock=0") , but I do recognize that method takes some level of commitment to implement.  Certainly, both timekeeping methods have their merit based on the expected usage environment of the finished product.

When a power outage occurs and acclock=1 the xtal will step in and keep time.  Yet another good reason to run the calibration procedure anyway...


I tried to get a scope cap of what this looks like in operation, but it didn't come out very well because the AC and DC sides of the circuit don't share a ground.  Anyway here it is.  You can see blue half of the AC sine wave and the digitized red trace that we can feed to the input of the uC. 

Counting up the rising edges of the red trace until we get to our nominal AC frequency ( 60 Hz in the USA ) then ticking over our seconds.  So far this has been quite acceptable for accuracy although I have not run this mode for more than a week or so.



The AC/AC Transformer

Clock Case

Functionally, a clock case is very important.  It needs to provide thermal stability for the clock innards, mechanical protection from bumps and dings, light splash protection from water, and protection from dust, or rather a surface to collect dust that is easier to clean than the populated PCB alone.

Putting on my humility hat I attempt to create a clock case from wood.  Sycamore; locally harvested to be precise.  It is a work in progress, but my vision for the case involves dovetails, radii, and a glass front panel - possibly etched.  I hope to continue on the case soon - I imagine the wood quipping that it could have grow itself into a clock case faster.

Local Sycamore
Table sawing the 1-1/8" thick boards to half thickness for case sides.
Marking and cutting out dovetails

Admiring the Sycamore grain

Windows Application

The purpose of the Nixie Clock Communicator app ( NCC ) is to simplify the setting, and calibrating of this nixie clock.  It is not required for use, but is handy - particularly during development and debug. 

For instance, to set the time I could open a terminal and connect.  Then type "hours=12" [ENTER], "minutes=55" [ENTER], "seconds=13" [ENTER] and the nixie clock would be set to 12:55:13.  

No problem.  But with the NCC app, I can click the "Send PC Time" button and the app will look at the current system time, wait for a new second to tick over ( mS = 0 ), and then immediately send the seconds, minutes and then hours. 

Additionally, the app can datalog the time and date that the clock thinks it is, concatenate this with the PC time and date, and log this to a text file.  Using this information we can derive a calibration value such that the long term accuracy of the XTAL is compensated to drive the clock very near to real time.  More on this in the "Calibration" section below.

The app is written in C# using Microsoft Visual Studio 2013.  Although the code compiles, runs and does it's job, it is very much a work in progress - I am currently trying to work out some bugs where there seem to be some phantom characters triggering my serialRead event handler.  I am sure there is a logical explanation, but I have not sorted it out just yet.  If you do, please let me know!

Nixie Clock Communicator ( NCC ) app for Windows.


Calibration

Before you attempt to calibrate the clock it should be placed in a suitable enclosure.  One that is vented yet free from drafts.  The idea being that you want to keep ambient thermal excursions from affecting the temperature of the xtal case.  Direct sunlight might be desirable to avoid.

It does not greatly matter what the temperature of the xtal is, so long as it is stable over the long term. Having said that, if one were to have a choice of temperatures to put the xtal near, it would be wise to select one nearest to 25 C, however do not neglect the benefit inherent to a stable temperature.

It might save you some frustration to have tested out the battery backup before now.  However, if power outages do occur during calibration, the outcome may be an improper calibration value.  It occurs to me now that there should be a firmware counter that keeps track of the number of times the clock enters battery backup mode.  If that number is > 0 while calibrating, a new calibration should be performed.

Steps:
  • With the clock in its case, and the case with the clock placed in its preferred place of use, set "mscal = 0" and set the time and date precisely and accurately.  Use time.gov or something similar.
  • Allow the clock to run continuously for at least 1 week.  Longer calibration periods get a greater average of environmental changes and potentially a higher degree of calibration precision.  Allow the clock to experience all environmental changes expected during normal operation - if you have a programmable thermostat let it run its course etc.  
  • Optional - use the NCC app to data log the nixie clock time, and host PC time/date to a log file.  I set my logfile up in a google drive folder so I can check the progress anywhere.
  • When the clock has run for a week or more, compare the current real world time to that of your nixie clock.  This is particularly easy if you've been using the NCC app.
  • If the nixie clock is running faster than the real world time, set "xtalisfast=1", otherwise "xtalisfast=0".
  • Compute the time error in Parts Per Million by (realWorldTime / nixieTime)^-1
  • Compute the mS Calibration value by mscal = F_CPU / (F_CPU * PPM_ERROR)
  • Set "mscal=nnnn" where nnnn is the calibration value calculated above
  • Read back your values to be sure you set them right: "mscal?" and "xtalisfast?"
  • Store the values to EEPROM so they will be remembered even thru a total power loss by typing "ramtoeeprom" and hit [ENTER]
  • Optional - remove power, reapply power and check that mscal and xtalisfast have been stored properly.
Below is a screen cap from some notes I took while calibrating my prototype clock.  The first 2 lines were generated by the NCC app and serial nixie data.  The nixie clock sends out the time/date that it thinks it is on the right at the top of a minute.  The NCC app prepends the current system time/date on the left then logs this to a file.  The last value on each of the first 2 lines is the current temperature.  In the example below, you can see my mscal value is 21180 and xtalisfast should be set to 1.

To be more explicit, the format of the top 2 lines in the screen cap below is as follows.  PC Date, PC Time, Nixie Clock Date, Nixie Clock Time, Clock Temperature in Celsius.


Miscellaneous

If you're thinking about skipping the fuse in the circuit, please don't.  It is remarkably important.  I once thought of using a PTC, but even that is a bad idea here.  You really want total separation from the power source and a deliberate reapplication.  To that end, do not move past a burned fuse until you fully understand why it blew.  Read the section on the boost converter and look at the schematic if you need further convincing.

This project has taken somewhere around 6 months to date.  I have to admit that I am a little surprised by how challenging this project has been.  It has also been a lot of fun.  If you have any questions, please feel free to email me or leave a comment.    

Friday, October 10, 2014

Mobile Radio Power Controller ( MRPC )


Before I began the installation of my Yaesu FT-8800 in my car I knew I wanted automatic power ON / OFF.  This is a feature that I have always felt was lacking in my other mobile rigs as I am forever leaving my ham radio on long after I have departed the car.

Let's start with an action packed video of the finished product, then we can talk about how we got there.




First, I set out to determine if my radio has such a feature natively, and I found the following.  Per the FT-8800 user manual, there is an Automatic Power Off ( APO ) feature.  Below is a screen cap from the manual describing this operation.

As you will read, this feature can be used to turn OFF the radio, but not back ON.  And for the APO to turn the radio OFF there are several specific requirements including leaving the radio in a non-scanning mode - not necessarily something I can commit to.  In the end, I determined this APO is not helpful to me in its current form.


Recalling that my radio will return to its last known power state meant that I only have to apply power to the radio when the car is ON and disconnect the power when the car is OFF to achieve my goal.

Having ruled out the APO feature on the FT-8800 I set out to see what products already exist on the market to automatically toggle my radio power.  Surely there should be something for <$50.

Wrong.  I did find this for ~$100 and this for ~$60, but these prices made me bristle with antagonism.  I was quickly learning that this would be a DIY project.  ( As a point of reference I ended up shelling out $8.23 in parts for my MRPC. )

And so began what I hope to be my very last PCB design using Eagle CAD.  I have several specific opinions related to my disappointment with Eagle, but I won't go into it today. ( ok, I recently learned the hard way that Eagle uses proportional fonts.  They look good in Eagle, but send your board to fab and they are converted to fixed-width vector fonts.  The result is the word "controller" is partially cut off my silk screen layer. )

So, as I was saying, I won't go into my issues with Eagle today, but after designing a board in KiCad and having it manufactured, I can say what a massive improvement.  I am probably still a bit slow with KiCad, but I imagine my proficiency will improve as I move to exclusive use of KiCad over Eagle.

Ok, back to business.  Below is a screen cap of the schematic drawn in Eagle.  VBATT_IN is the 12 V DC car battery power.  It is fed into D2 for reverse polarity protection before heading to a 5 V DC regulator.  Prior to D1, the VBATT_IN voltage is also feeding a voltage divider of R1 and R2 and 48 Hz LPF with R2 & C2.  The resulting voltage is an attenuated analog of VBATT_IN fed to the ATTiny85 microcontroller ADC.

With the ATTiny85 able to measure system voltage, it can now determine when the car is running ~14 V DC with the alternator running, ~12 with the engine off.  We will talk about the program some more later on.

R4 feeds the base of Q2 which pulls down the gate of U1, which is otherwise held high by R3.  U1 is an IPD90P03P4 mosfet.  It has an RdsON of only 4.5 mOhms which; in testing, allowed me to comfortably pass about 200 watts at ~13.5 V with no heat sink.




Further down is a link to the Mobile Radio Power Controller ( MRPC ) Bill of Materials ( BOM ).   The  voltage regulator I used is an obsolete part.  You should select a new one if you decide to build a MRPC board.  Another reason to select a different regulator would be because the one I use draws a shameful 5 mA quiescent current.  I might recommend something like an LD1117. 

I had these boards fabbed thru the OSH Park service.  It was my first time using OSH Park, and at the time of this writing, 50% of of my OSH Park orders have been for MRPC boards. 

If you would like to order one of the boards, well you can't, you have to order 3.  It's the OSH Park rules.  The good news is that those 3 boards will only cost you $9.05, at the time of this writing, for each multiple of 3.  For the record, I am not affiliated with OSH Park and no money goes to me if you do purchase a board thru them.  Here is a link to the PCB order page https://oshpark.com/shared_projects/jAyTdKon

The circuit board is housed in a custom enclosure I designed in AutoCad.  The *.stl was exported, sliced in Slic3r and printed on my Prusa 3D printer.  The material I used is Red PLA.  I have uploaded the *.stl files so you can print your own at http://www.thingiverse.com/thing:495167







The software is pretty straight forward.  Basically, the code tells the processor to sleep forever.  This is to reduce power.  The watchdog timer will wake the processor up once per second.  At this time an ADC conversion is initiated.  If the system ( car ) voltage is above a threshold, the event is logged.  If the voltage exceeds the threshold for a period of time, the mosfet is switched ON.  If neither threshold is met, the mosfet stays OFF appropriately.  Everything should be commented, but if you have any questions, feel free to email me.

Downloads:

Here you can download the code
Here you can download the Eagle PCB files
Here is the link to order a PCB
Here you can download the enclosure files
Here you can download the BOM

I think that's about it.  Let me know if you end up building one for yourself!

Sunday, July 6, 2014

blueShift - An OpenXC LED Tachometer

An Arduino, some addressable LED's, a bluetooth module, code and a 3D printer come together to make blueShift - An OpenXC LED Tachometer.  blueShift is so named for the Bluetooth protocol used for data communication, and the use of a tachometer to indicate when to shift your car.  It may be amusing to note that the driver and passengers traveling in this car would observe Blueshift when peering thru the windscreen, provided their velocity was sufficient.







About a month ago I picked up a new car.  It's a Ford Fiesta with a 1 liter, turbo, eco-boost engine.  It achieves roughly 2.5 times greater fuel efficiency than my Jeep.  This fuel efficiency was my primary impetus to purchase, but the new tech in automotive electronics is a pretty cool bonus.

It took a couple days driving around to figure out all the bells, whistles, and electronic gizmos in the Fiesta, and just that quickly, I was looking for something more.  What that turned out to be was Ford's OpenXC API.  OpenXC is part hardware, part software.  It is open source, as the name suggests and aims to ease us into integrating vehicle data into our android apps, and in case of blueShift, embedded hardware.

Let's take a brief, but closer look at OpenXC and the potential it provides.  For quite some time now, auto manufacturers have provided an OnBoard Diagnostics port.  This OBD2 port, as it is sometimes called, is a digital interface to engine management parameters and chassis/body status.  To the typical hobbyist, an OBD2 ports data is relatively inaccessible.  You would need to know manufacturer proprietary PID's for the CAN messages you were viewing to discern "air intake temperature" from "outside air temperature" for instance.  Likely, the information you were able to decode is specific to one vehicle make/model or worse, ECM batch.

Under the OpenXC umbrella, Ford has developed a hardware module called a Vehicle Interface or VI.  This VI plugs into your OBD2 port, and interprets engine parameters and chassis/body info.  These data are then packaged into JSON format, and relayed out over Bluetooth SPP.  If you were to look at the OpenXC Data set you would discover that listening to this Bluetooth connection provides you with a plethora of vehicle specific information in real time.  For instance, you can read your accelerator pedal position, fuel level, odometer, brake pedal status, and of course engine speed.  The list goes on.

blueShift aims to utilize these engine speed data to drive a set of LED's in an easy to interpret, graphical manner.  The circular nature of an off-the-shelf LED strip lends itself to this project nicely.  What's more, these LED's are individually addressable, RGB LED's.  This means that we can set any LED on the ring to just about any color we like, at any time we like.  blueShift takes advantage of these addressable WS2812B LED's to create an interesting and informative display.

At first glance it may seem a second tachometer in my car is superfluous.  I can say after having used blueShift, quite the opposite is true.  The LED's are much easier to read with peripheral vision than the stock tachometer needle.  Likewise, blueShift would be very useful for someone who races Ford automobiles.  Additionally, blinky LED things are just plain cool, and no further justification for this project is therefore necessary.

The only wired connection to blueShift is for power.  All data transfer is accomplished over Bluetooth SPP.  Presently, this power is derived from my vehicles on-board USB power.  I have plans to derive power from the OpenXC VI power port in the future.  This will require a small regulator to convert the vehicle ~14 V DC to a microcontroller compatible, regulated 5 V DC supply.  This supply will also need to supply power for the LED ring, so current consumption should be considered.


3D Printed Enclosure:

Sometimes a project will take you to unanticipated places.  In the case of blueShift, that ended up being the land of 3D printing.  Typically when I make a new project I am left to drilling and milling existing enclosures, and sometimes tupperware.  What I am left with is a finished product that looks less than finished.  When I was envisioning how I wanted blueShift to look, it deviated rather drastically from the prototype seen below.




Once it was decided to build a 3D printer to print blueShift's housing, I started down the path of designing a 3D printer of my own.  I had a basic layout and construction method in mind when I started looking for approximate pricing on parts.  I soon discovered that the constituent parts of my 3D printer design were approaching the cost of a 3D printer kit.  This led me to purchase a Prusa i3v from Maker Farm, and I am glad I did.  Together with my girlfriend Miriam, we assembled the kit in a few evenings.  The decision to build a kit saved substantial time over designing a printer.  Our first prints were the requisite calibration cubes and then jewelry as seen below.  There is probably still some fiddling to do with the printer setup, but I am pretty pleased with the print quality so far.





Here is a photo of the partially finished 3D printer.




I designed the 3D models for blueShift in AutoCad 2014.  I then exported the models as *.stl files and uploaded them to Thingiverse for sharing.  You can download the *.stl files to print your your own blueShift enclosure, or I think companies like Shapeways may print them out for you if you don't have a printer ( yet ).  I have no experience with that.

Below are some photos of the enclosure in various states of printing, and drawing revisions.  The portions of the print that have large gaps and look like a lattice are intentional.  This makes up supporting structure for parts with overhangs while printing.  It is designed to break off easily, and in practice this is sometimes true.







I am really enjoying 3D printing.  Even with it's obvious limitations, I feel that I will make good use out of this tool.  I see many opportunities to print things that may or may not be necessary, but ultimately I am having a great time with it.


Electronics:

Part List:

  1. NeoPixel Ring w/ 24 WS2812 RGB LED
  2. Arduino Pro Mini
  3. BlueSMiRF Bluetooth Module
  4. NPN transistor + 1k0 base resistor
  5. Pushbutton Switch ( optional )
  6. FTDI cable for programming and power
  7. A Ford OpenXC VI

I am using an RN-42 Bluetooth module from Sparkfun called a BlueSMiRF .  One of the first things to do is connect to the modem and configure it for Auto-Connect Master Mode (SM,3).  The AT Command sheet will walk you thru this process.  For more detailed information on how to connect the Bluetooth module, and enter into command mode, refer to the Sparkfun tutorial.

With the Bluetooth module configured, we can wire up the rest of the circuit and tuck it into the blueShift housing.  Here are a few pictures that show this process.  Great care should be taken to avoid short circuits.  Currently I power the blueShift from an FTDI USB cable.









The little tactile switch will perform a function in future software revisions.  For now, it does nothing in software.




The two red wires with header pins are for the bluetooth modem power.  This is represented as a SPST switch on the schematic labeled "HEADER".  It is necessary to unpower the modem when uploading new firmware to the Arduino.  This should be shorted out while operating blueShift to power the Bluetooth Module, and disconnected for uploading new firmware to the arduino.




This would be a good time to install the software and verify everything works.  If you need to re-solder anything, it is better to find out now.  The author may have experience that lead to this warning.

In the picture below, this semi-opaque, 5mm thick disk is possibly polypropylene.  I purchased the stock from an unknown bin at a shop and belt sanded it into shape.  There are 3 equally spaced clearance holes drilled into this lens to accommodate the M3 mounting bolts which we are about to install.  Drop the lens into the outer housing and line up the holes.




Insert the assembled and tested inner housing into the outer.  Line the three M3 bolts up and screw the entire assembly together.




Screw the Ram Mount to the back of blueShift.  This will now suction cup to your windshield and plug the FTDI USB cable into a USB port in your car.  If you don't have a USB port onboard,  there are 12 volt outlet to USB adapters available.






Software:


You can download the Arduino code here.

When blueShift first turns on, there is a brief pause.  During this time, we are waiting for the Ford OpenXC VI to boot up, and for blueShift to establish a connection to the VI.  For a bit of fun, we display the "Waiting for Bluetooth Throbber" that you can see below.




Once a connection is established and valid RPM data is coming thru, the display changes to "Run Mode".  In this state, RPM is displayed as a green LED trail.  It grows clockwise as RPM increases, with the final LED being displayed in red for a bit of visual interest.

This final LED, the highest LED displayed, is "sticky".  That is to say, as your RPM begins to decay, the peak RPM read will continue to be displayed as a single red LED.  This will either persist until 3 seconds have elapsed since the peak measurement or once a positive rate RPM is detected.

Since OpenXC provides with boolean headlamp status on the same bluetooth connection, we can implement auto-dimming of blueShift.  As soon as your headlamps come on, blueShift will dim.  When your headlamps return to the off state, blueShift will regain full brightness.  This is not just a nicety - it is rather important.  These LED are quite bright and without dimming at night the result is a well lit car interior.

The sticky LED telltale can be seen in the video below.  You can also see the auto-dimming feature towards the end of the video.  It's a little hard to see when the headlights turn on because its still light out, but you can see blueShift get dimmer.  You can also hear the headlight knob click on.




At the time of this writing, blueShift is hard coded to a specific RPM span.  That is to say, if you wanted the first LED to light at 500 RPM and the final LED to light at 6000 RPM, you would need to reflash the firmware.  After I get a few more miles on my car I will want to change that so, I will probably use that tactile switch as a way to program the RPM span without reflashing firmware.

To implement this I think it would be good to have a "programming mode" where say you enter program mode and blueShift will keep track of the highest RPM read.  You press the button once to set this as the lower RPM span.  Now, rev your engine and blueShift will remember the highest RPM achieved.  Press the button to store this as the high RPM span.  These new values will be saved to EEPROM and recalled at the next power on cycle.

Additional firmware upgrades include moving to JSON parsing.  Right now I just read the full JSON line and manually parse the string for the values I want.  If something were to change in the VI firmware, it is possible to break my code.

Are you making a blueShift?  Send me a message, I would love to hear how it's going.  Happy making!