• The design blurb, part 2

    Gary Marsh • 02/16/2016 at 01:38 • 0 comments

    Here's the second half of the design notes on the card. I've hopefully covered most of the design decisions made, but if you've got any other questions, feel free to ask.

    Software

    Clock software is written in C using Atmel Studio 7.0, and compiled with the Atmel supplied compiler.

    The software running on the clock is pretty dumb. Almost everything runs off the Timer Counter 0 interrupt, which rolls over at a 256Hz rate and generates 3 interrupts:

    • TC overflow: turns off current tube anode
    • TC compare 1 - selects cathode for next tube
    • TC compare 2 - enables next anode, then does "clock stuff":
      • Detecting falling edges on the RTC /INT output, and counting the current time
      • Debouncing the buttons - done with simple up/down counters.
      • Handling button pushes for incrementing hours and minutes, and writing the new time to the RTC.

    Timer Counter 0 uses the SAM20's OSC32K internal oscillator as a clock source.

    In addition to the timer, the main() loop is used to provide a basic text menu for fiddling with the clock's internal bits.

    To allow calibration, Timer Counter 2 is clocked from GCLK1, which is sourced from the CAL input on the card. The 1PPS input from the RTC is fed through the external interrupt controller and event system on the SAM, and is used to capture the value of TC2. This basically makes a frequency counter.

    Layout

    The schematic and layout were done in Eagle. The combined PCB panel size (160x70mm) is too big for the freeware Eagle tools, but I have one of Cadsoft's non-profit licenses which allows 160x100mm dimensions and up to 6 layers. I've been using Eagle as long as I can remember for hobby projects and have a huge number of parts created.

    For safety reasons, no high voltage track is present on the bottom layer of the control PCB. This means I can leave the bottom of the PCB exposed, and make the base slightly thinner in the process.

    The PCBs were ordered from dirtypcbs.com - I've ordered from these folks several times now and they've never let me down. For some reason ENIG only ended up costing $2 more with this order, so I went with it - gotta say I love the look of ENIG and black solder mask together.

    Mechanicals

    I'm Canadian, which means I work in a bastardized combination of imperial and metric units. I apologize.

    Each card is 6.25" x 1.25" in size, or about 160x32mm. The distance between the two cards as 1/4" or 6.35mm. The two boards are 1.6mm (1/16") thick, which results in an overall sandwich thickness of 3/8". I could have used thinner PCBs but wanted the boards to be fairly rigid.

    Pin sockets are Harwin H3184-01. These are 6mm tall, with 5mm of that length extending into the PCB. Subtracting the 1.6mm PCB thickness, they protrude 3.8mm into the 6.35mm clearance between the two PCBs - this means that any parts on the bottom PCB must be at most 2.95mm tall. I set the rule that any parts underneath the pin sockets must be 2mm high at most.

    Finding pushbutton switches was a challenge. Typical right angle switches are too tall to fit between the boards, and I wanted a protruding activator that pokes through the side of the case so I wouldn't have to fabricate pushbuttons. I also wanted a through-hole switch for mechanical rigidity, which ruled out SMT options. Ultimately I ended up finding a TE branded switch with suitable dimensions and cut back the top PCB to clear the switches.

    To connect the two boards, I chose a 20-pin AMPMODU 50/50 connector with a 0.250" board-to-board stack height. This connector wasn't chosen for any real reason other than it fit.

    Case

    The case was designed in Sketchup. The eventual plan is to machine a case out of aluminum bar stock - I'm currently trying to figure out Sprutcam, however I may just manually machine it on the Bridgeport at work.

    For a mechanical prototype, to make sure everything fits together nicely and all my holes are in the right place, I had a case 3D printed. I used the 3dhubs.com service and had it 3D printed by a local guy with a 3D printer. The surface finish on the clock isn't perfect...

    Read more »

  • The design blurb, part 1

    Gary Marsh • 02/15/2016 at 01:04 • 0 comments

    Here's a bunch of design notes on the thIN-18 clock. This covers the electrical design, I'll make another post describing the mechanicals and the software.

    Microcontroller

    I'm running the clock with an Atmel SAMD20, ARM Cortex-M0+ controller. I used this exact chip to run a lighting system for a Burning Man art car last year, and was very happy with the chip for that role, and thanks to that project I've got a bunch of software written already for SERCOMs/TCs/etc. Plus the chip is fairly cheap (cheaper than an Atmel AVR with the same pin count, even), and I like the Atmel Studio tools, so why not?

    For in-circuit programming and debugging of the ARM, I'm using a Segger J-Link EDU debugger. I highly recommend buying genuine tools, for the simple reason that they work when you need them to and you can get help when they don't. The EDU costs $60, and its only limitations are some "you can't use this for profit" legalese and a nag screen that it displays every now and then when you fire up the thing.

    I've also got a FTDI FT230XS USB-to-UART bridge on the card, which I use to provide a simple text menu for messing around with the internals of the clock and code testing. The FT230XS comes in a small TSSOP, has a built-in oscillator, and you can configure its spare pins to do cool things like report that you're plugged into a dedicated charging port.

    Timekeeping

    I'm keeping track of time using an Intersil ISL12022 RTC, which connects to the ARM via I2C.

    This RTC is a bit spendy, but it has a bunch of features I like. It does temperature sensing/compensation, which makes it +-1ppm accurate over a wide temperature range. It does frequency control by changing the crystal load capacitance instead of adding/dropping 32K clocks, which helps with on-the-fly calibration. There is a ISL12022M part available which integrates the crystal already, however the wide SOIC package was too tall/wide to fit mechanically so I went with the separate-crystal part instead.

    To back up the RTC I'm using a BR1220 lithium cell, held in place with a Keystone coin cell clip. This cell has a 35mAh capacity, which at the 1uA typical discharge current of the RTC can keep the time backed up for 35,000 hours or about 4 years with the clock unplugged. Or about 40 years with it plugged in. It'll do.

    I originally stuffed an A5100 GPS receiver module and a MMCX antenna connector in the location where the backup battery currently sits, and had plans of the hour/minute buttons being time zone adjustment buttons and the clock being self-setting. But an external wired antenna is annoying and would have to be located near a window, so I decided to just yank the GPS and go to the "battery and decent RTC" solution instead. There's 31.6e6 seconds in a year, assuming I can maintain +-1ppm accuracy on the clock crystal that's +-31.6 seconds of error in a year; and since I'm setting the clock twice a year anyway for daylight savings, and the clock doesn't display seconds the error is worst case about 1/4 of a minute. That'll do.

    Calibration of the RTC is straightforward to do - apply an external 10MHz, CMOS level signal to the CAL input. This clocks one of the TC modules in the SAMD20, which is set up to capture on 1PPS edges coming out of the RTC chip. By capturing successive timer edges and subtracting, you can quickly figure out the frequency error and trim it accordingly - eg. if you get exactly 10M clocks, your error is 0ppm, if you get 10,000,005 clocks, the 32KHz oscillator is running half a ppm slow.

    Power supply

    I decided to use micro USB for the power supply input - the connector is low profile which suits what I'm trying to do here, and MicroUSB phone chargers are very easy to find.

    Nixie tubes require ~180V to light up, so I have to make 180V from 5V. This is pushing things for a conventional boost converter design, requiring either a very high duty cycle. So I went with a combination flyback/boost converter architecture which runs at a much lower duty cycle - I'm using a MCP1661 monolithic...

    Read more »