Ramblings of an E-Geek
Moving on to another Blog Host

I’ve decided that it would be best to move the Ramblings of an E-Geek blog to another Blog Host.  So, I’ve reconstituted most of my posts on Blogger.  Please visit me there and subscribe to my RSS feed!

Thanks!

http://egeekrambling.blogspot.com/

Building Blocks: The UART

I know these posts aren’t in any kind of logical order, but I figure I should post about what I feel inspired to post about and, eventually, it’ll all be there.  So, today I’m going to talk about the UART code I use on the atMega328p to communicate with the WiFly GSX.  It is a bit more complex than the very basic tutorials out there, but I suspect it’s not up to professional grade either.  I use an interrupt driven transmit/receive with 256byte buffer for each.

The inspiration for this bit of code came from a couple sources.  There is a great and simple UART tutorial on Sparkfun that got me started when all other tutorials failed me.  Additionally, reading the AVR Freaks forums, I educated myself on more advanced UART techniques including a suggestion by Dean, I believe, to use ring buffers to store data and handle transmitting/receiving the data in interrupt routines.

In my library, I have the following data structures:

volatile char in[256];

volatile char out[256];

volatile uint8_t inptr;

volatile uint8_t outptr;

uint8_t curoutptr;

uint8_t curinptr;

and the following routines:

uart_init();

uart_tx(char c);

uart_send_string(const char* s);

uart_check();

ISR (USART_RX_vect);

ISR (USART_UDRE_vect);

In the next few paragraphs, I’ll show you how these are used, but first, let’s take a quick look at the data structures.

volatile char in[256];

volatile char out[256];

These are what I call my ring buffers.  They are called that because they wrap around to the beginning when they exceed 256 characters.  Why?  Because I am using an 8-bit integer for the index of the buffer.  The AVR is an 8-bit micro, so the integers are only 8 bits long, allowing a maximum value of 255.  If you add 1 to an 8-bit integer variable that contains the value of 255, the result is a value of 0.  Very cool!  It makes for a very convenient way of handling buffers for all kinds of things.  As with everything there are trade offs.  Two 256 byte buffers may be overkill for most UART applications.  Some AVR micros don’t have or can’t spare the 512 bytes of memory needed for this.  I used this library on a Tiny and had to drop the buffer size down to 16 bytes each.  It wasn’t too difficult, but it’s just some extra coding.

volatile uint8_t inptr;

volatile uint8_t outptr;

These are the pointers into the index of each of the buffers that lets me know where to put new data.  It also lets me figure out what data has not yet been sent.

uint8_t curoutptr;

uint8_t curinptr;

These are also pointers.  These point to the last character that was sent/received.  Using this pointer and the previous pointers, I can check to see if I need to send any data to the UART, or process any received data.

Now, on to the routines.

uart_init()

Let’s start with the uart_init() routine.  As you probably suspect, it is the routine you call at the beginning of your main program to initialize the UART so that you can use it.  Once this init routine is complete, you will be able to the other routines to send data out the UART.  Let’s take a look at the code:

void uart_init (void)
{

    DDRD &= ~(1«DDD0);
    DDRD |= (1«DDD1);
    PORTD |= (1«PORTD0);

    UCSR0B |= (1 « RXEN0) | (1 « TXEN0);
    UCSR0C |= (1 « UCSZ00) | (1 « UCSZ01);
    UCSR0C &= ~(1«UPM01);
    UCSR0C &= ~(1«UPM00);

    UBRR0H = (unsigned char)(BAUD_PRESCALE » 8);
    UBRR0L = (unsigned char)BAUD_PRESCALE;
    UCSR0B |= (1 « RXCIE0) | (1«UDRIE0);

    inptr = 0;
    outptr = 0;
    curoutptr = 0;
    curinptr = 0;

    uart_tx(‘o’);
    uart_tx(‘k’);
    uart_tx(‘\r’);
    uart_tx(‘\n’);

}

The code is split into five sections.  The first section is where the pins on the micro are initialized to “known” values.  I suppose that these pins have default values and that I am possibly wasting my time setting some of these values, but I feel that it’s best to KNOW that they are set correctly, rather than rely on supposed manufacturer default.  The first three lines accomplish the following:  set pin D0 (RX) to input, set pin D1 (TX) to output, enable pullup resistor on D0.  The last statement is very important.  I’ve not remembered to do this and it makes UART transmissions virtually impossible.

The second section sets up the parameters for the UART hardware itself.  The first line simply turns on the UART TX/RX circuitry in the micro.  The second line instructs the UART to use 8-bit characters.  The third and fourth lines set the UART hardware to use no parity.  This is a prime example of when defaults are not what they say they are.  For some reason, the micro prefers to boot with odd parity.  That is not what the datasheet from Atmel says.  I wasted a week of effort just on this one issue.  Word to the wise, if a bit needs to be set to zero, then set it to zero.  Don’t assume that it will be zero by default.

The third section sets the BAUD rate in the UART hardware.  The BAUD rate is either calculated by the following formula:

#define USART_BAUDRATE 9600
#define BAUD_PRESCALE (((F_CPU/(USART_BAUDRATE*16UL)))-1)

or you can simply set it manually to a specific value.  There are suggested values in the Atmel datasheets.  There is a lot to consider when setting the baudrate on an Atmel micro and I won’t really go into it, but I’ve typically just gone with 9600 baud at a micro clock rate of 8MHz.  It’s worth spending the time to read and understand this if you want to be successful at using the UART for your projects.  I suggest going over to AVR Freaks and doing some reading on the subject in their forums.

The fourth section just initializes the ring buffer pointers to zero.  Standard stuff.

The last section sends an “ok” to the UART letting me know that the UART was successfully initialized.  Clearly this is optional, but I prefer to have a little bit of interactivity here and there so that I know my micro is behaving.

uart_tx(char c)

This routine is very simple.  It inserts characters into the transmit ring buffer and increments the buffer pointer.

void uart_tx(char c) {
    out[outptr]=c;
    outptr++;
    UCSR0B |= (1«UDRIE0);
}

What it also does is enable the UART’s data register empty interrupt.  This setting causes the this interrupt to fire so that you know when to put more data out of your buffer into the UART.  As you will see later, the interrupt either sends data or turns off the interrupt (so that it doesn’t just continue to interrupt with no data to send…that’s bad), so this routine must turn on the interrupt again when there is data to send.  I think this is a confusing way to do it, but it is what it is.

uart_send_string(const char* s)

This routine is a simple wrapper around the uart_tx() routine.  As you can see in the uart_init() routine, it’s not exactly “code efficient” to send a string to the UART one character at a time.  In this routine, we are taking the string and simply iterating through the it and dumping the characters into the uart_tx() routine.

void uart_send_string(const char* s) {
    while (*s)
            uart_tx(*s++);
}

The observant will notice that there is no error checking here.  The ring buffers are only 256 characters long.  If you pass a 260 character string to this routine, the buffer will overlap and, at best, you will only get the last four characters sent to the UART.  This is because the routine packs the buffer so quickly that the UART can’t keep up.  This is an area of improvement for my code, but I haven’t done anything yet.  I think that a simple check of the buffer pointers will allow you to insert a small delay if you detect an potential overlap condition, allowing the UART to catch up.

uart_check()

This routine checks the receive buffer for characters and processes them.  I will publish a skeleton of my actual code because there is quite a few lines of code here.  This is where I implement the interactive part of the scoreboard (i.e. the H, h, I, i, G, g, b, s, o, d commands and others)

void uart_check()
{
    while (curinptr != inptr) {

        switch (in[curinptr]) {

            case ‘.’:

            default:
        }
    }
}

This routine is called from the tight loop in the main routine.  It checks the input buffer for new data and then parses the new data character by character using a simple switch structure.  It’s tight, fast, and restrictive enough to encourage me to KISS (keep it simple stupid).

ISR (USART_RX_vect)

This is an interrupt vector for when data has been received on the micro’s receive buffer.  It is important to service this routine and get out as quickly as possible.  There are only two lines and they simply add the data to the receive ring buffer and then increment the buffer pointer.

ISR (USART_RX_vect)
{
    in[inptr] = UDR0; // Fetch the recieved byte value into the variable “ByteReceived”
    inptr++;
}

ISR (USART_UDRE_vect)

This interrupt handles sending the data from the transmit ring buffer to the micro’s UART.  Again, it is always a good idea to take care of business and get out of your interrupt routines, so the code is intentionally short and to the point.

ISR (USART_UDRE_vect)
{
    if (curoutptr != outptr) {
        UDR0 = out[curoutptr];
        curoutptr++;
    } else {
        UCSR0B &= ~(1«UDRIE0);
    }
}

The first half of the IF statement checks to see if the current output pointer is not the same as the ring buffer pointer.  If they are not, that means that there is data in the buffer that has not been sent.  Put a byte on the output register and increment the current output pointer.  If the current output pointer and the transmit ring buffer pointer are the same, that means there’s nothing to do, so you simply disable the interrupt.  Remember, back in the uart_tx() routine, you enable the interrupt again when there is data to send.

Okay, I’m on a roll with the long blog posts.  Hopefully it was coherent enough to help you out.  As always, please feel free to comment and I will try to respond.

Building Blocks: The Microcontroller

As part of the building blocks series, I thought I would share a modular microcontroller design that I came up with over two years ago and that I am using for the scoreboard project.  The Arduino craze not yet peaked and I was not fully aware of what it was, however, I did see some value in what they were doing and couldn’t help but allow the Arduino influence my design.  Basically I took the shield concept, added a passthrough bus, and threw out the rest.  Arduino is beneficial to those that don’t have a Programmer or who are not familiar with C/C++ or assembly.  I had both, so I saw Arduino as having way too much circuitry for my tastes.  So, what did I do?  I built my own.  (This is a common theme with me, in case you haven’t noticed.)

What follows is an admittedly lengthy excerpt of a contribution that I made on the Society of Robots website back in 2008, where I first cut my teeth in all things electronics and mechanics.  It’s interesting for me to go back and read my thoughts back then.

A Modular PCB Layout

Introduction:

This project started as a result of my frustration and consternation with etching my own PCBs. Now, if I could draw out a board to perfection in Eagle on the first try, I probably wouldn’t have thought of doing this. However, my Eagle skills are somewhat lacking, as are my soldering skills. I needed a simple way for me to avoid having to build and debug large and complex boards for each project on my list. In addition to reducing the risk of me screwing up a large board, I found that it creates a bit of a “plug and play” environment where I can add and remove modules as needed for my various projects. Changing from a robot controller with motor driver and sensors to a temperature sensor with LCD display is as simple as swapping out the modules you need and reflashing the AVR. (I know, I don’t have an LCD module yet, but I will!)

As I took a look at some of the projects I wanted to create, I realized that there was a common basis for these projects; what I will call the AVR baseboard. There was always a socketed AVR (atMega168 for me), a reset button w/ resistor, and a decoupling capacitor. I wondered if I could build a VERY simple AVR baseboard and then just create modules for the functionality I wanted to add to it. Hey! While I’m at it, I could make them all stack together in a nice neat stacking bus arrangement. At first, I thought it was going to be a bit ambitious for someone of my skill level. Well, I did it, it seems to work pretty well, and I want to share it so that I can inspire others and also (selfishly) get some good feedback from the community on improvements, errors, etc. Here’s how it goes.

Form Factor:

First, I decided on a physical form factor. If I was going to connect multiple modules together, it would be nice if they were all of a “standard” size. I picked a 2” by 3” PCB dimension for the AVR baseboard and for a large module. I picked two other sizes for smaller modules, 2”x1.5” and 1”x1.5”. (see the first attached graphic “Module Sizes.png”)

This effectively gives me a full size, half size, and quarter sized modules. It also breaks the AVR baseboard into what I like to call “quadrants”. I’ve labeled the quadrants A, B, C and D.  Each of the modules that I’ve built are built specifically for one or more quadrants. You’ll see why when I go into detail on the ISP and Serial modules.

Read More

Building Blocks: Overview

Alright, I’ve hinted and even mentioned what all the components are in the scoreboard, but not really in much detail.  To supplement my building blocks series of posts, I thought I would put together a simple diagram of how all the different building blocks are connected and with some basic stats for each.

As you can see, there is quite a bit of power distribution throughout the design.  This was one of my main focus points because I wanted to make sure the power was distributed in a safe and maintainable manner.  The last thing I want is an epic failure during the middle of a game (i.e. flames…).

Let’s see…I’ve done building blocks post on the digits and the SMPS.  I think next I’ll discuss some of the code I used on the atMega328p and then perhaps a blog on the battery, battery safety, and power distribution.

Finished the scoreboard!!  I had a week of vacation, so I made a big push to finish.  Now I might have time to document the rest of the building blocks.

Building Blocks: Explosions are BAD!

Who says you can’t live on the edge as a geek?  This next building block is really in there for safety more than anything else.  What am I talking about?  LiPo batteries.

LiPo batteries have an excellent stored power to weight ratio, however, they are contentious beasts.  You can’t overcharge them, or they’ll explode.  You can’t drain them past a certain point or they’ll become damaged and will burst into flames the next time you charge them.  Check this out:

YouTube Video about LiPo Dangers

One of the most common things I’ve seen in my research about LiPo batteries is that people tend to forget to disconnect the batteries after use and the battery silently reaches the critical discharged state over time while no one is looking.  It’s safer to just toss the pack than try to revive it, although there are many accounts of folks doing just that.

Well, I plan on having an on/off switch on the scoreboard, so I don’t expect to run into any issues of discharge over time when I’m not using the battery, however, I do want to have some sort of protection from excessive discharge while I am using the scoreboard.  I’d rather not have my scoreboard burst into flames when it runs out of battery.  What I’d much rather do is warn me of a low battery, and then have it simply turn itself off if the voltage gets critically low.

Luckily, there are a number of IC companies that make chips that do just what I want.  I decided to go with an ICL7665 from Maxim because their datasheet was very detailed and included quite a bit of information relevant to my particular application.

The design concept is simple.  The chip, which runs off the full 12V, has a couple comparators internally.  These comparators monitor the voltage on their inputs and toggle an output when the voltage is less than the reference.  The first comparator will be used for the Low Battery Indication LED.  The second, with a bit of hysteresis built in, will drive a MOSFET on the 12V input.  When turned on, the MOSFET will allow 12V to enter the scoreboard from the battery.  When the voltage reaches a critical level, the ICL7665 will turn off the MOSFET and the scoreboard will go dark.

I’ve put the design into a schematic and laid out a SMD version of the board.  I’ve not tested this, but I’m expecting to have this built in the next few days.  I will report on my success or failure.  Here are some pictures of the design:

[Note:  I’ve removed the schematics and board layout because there was an error in how I had the MOSFET connected.  I don’t want to post things that don’t work, so hopefully I’ll build this thing, test it, and then be able to repost the design.  Sorry folks.]

An interesting concept that I thought of and that I will be testing on a prototype board is whether I can have the ICL7665 be powered AFTER the MOSFET.  Why would this be a good idea?  Well, the IC still takes power, even when it’s cut the power.  If you put the IC after the MOSFET, then it will be powered down when the power is cut.  The problem there is how do you power things up initially?  Well, I was thinking a momentary switch across the Source/Drain of the MOSFET will allow me to temporarily bypass the MOSFET to allow 12V into the circuits to turn them on.  Not sure if I explained this clearly, but if this works, it’ll be really cool and I’ll have to write about it in more detail.

Cheers!!

Building Blocks: Switch Mode Power Supply

I know what you’re thinking…”Wow!  This guy must be really smart because he designed a switch mode power supply for his project.”  Well, I hate to disappoint, but I’m not really that smart at electronics (that’s why I’m doing this project…to learn!)

The truth is, I was looking at building my own SMPS, but it looked like a chore even considering there are some really easy to use chips like the LM2575.  Picky PCB layout problems and the fact that I don’t own an inductor of any kind, really made me think twice about trying.  Oh, I designed a SMPS in Eagle, but I have yet to try it because I came up with a…how should I put this…dumb simple, solution.  That is, simple enough I can do it and it just works.  No fussing around with it.

First, I knew that I needed something to convert from my 11.1V (call it 12V) LiPo battery down to a useful 3.3V.  Looking at typical linear voltage regulators, I could see that I would be burning up lots of my battery as heat.  In fact, a 12V to 3.3V linear regulator is only about 28% efficient.  That’s a deal breaker.  This scoreboard needs to be as efficient as possible in the power department because it could be used for hours at a time.  Incidentally, during development I was using a 5V LDO regulator and just converting from 12V to 5V caused the regulator to heat up to where it will burn you if you touch it.  I don’t want that in my scoreboard box.  The LEDs are going to be warm enough.  My other option was to look at a SMPS.

Looking up SMPS online, I found that they tend to be about 80 to 90% efficient in the voltage and current ranges that I am expecting.  That’s a HUGE improvement.  This is when I made the decision to do a SMPS or bust.  Little did I know that I actually had a SMPS lurking in my desk drawer that would do the job perfectly.  While I was pondering SMPS datasheets, I noticed a car charger from a long defunct cell phone laying on my desk.  “Hey!” I said to myself, “that thing converts from 12V car voltage to 5V USB!”  My search for a SMPS was over.

Gutting the charger, I found a small circuit with a couple resistors, a diode, an 8 pin unmarked dip, and (the tell tale sign of a SMPS), an inductor.  But this SMPS outputs 5V, not 3.3V, which is what I need.  Having done a bit of research already, I knew that the voltage on a variable SMPS chip is set with a potential divider.  So I set out to recreate the schematic of this simple board.  Soon, I had identified the two resistors that create the voltage divider, figured out which one I needed to replace, calculated the new resistor value, and replaced the resistor with an appropriate value for 3.3V output.

Honestly, I didn’t think it could be this simple, but apparently it was.  When I powered on the circuit, it measured exactly 3.295V.  Sweet!!  I had concerns that perhaps this SMPS couldn’t handle the current required for running all my electronics, but now that I have it hooked up I can see that it’s not going to be an issue.  In a steady state, my electronics (minus the digits which run on 12V anyway) take anywhere from 30 to 50mA with peaks up to 200mA.  The SMPS can handle that, no problem, if it ever charged a phone.

Here’s a pic of my repurposed SMPS.

For those of you that are impeccably observant, you may have noticed that there are two resistors connected together.  That’s just me not being able to find a 1000 ohm resistor, so I made one with two 500 ohm resistors.  Yeah, okay, it’s not that clean, but it works and I’m all about things that just work.

That’s all for now!

I finally managed to get everything working together for a simple test.  Take a look!  Now, that’s progress.  I still need to build some more digits, but this is very encouraging!

These are a couple pictures of the two digits I have built so far.  They are mounted in a temporary piece of 1/4” plywood that I had laying around.  It just happened to be almost exactly the same size as the faceplate I have planned for the final scoreboard box.

Building Blocks: Anatomy of a Digit

Having already quite a bit of experience with microcontrollers, I decided to tackle the score digits first.  I figured that if I could build these, the rest (except for maybe the wireless) would be pretty straight forward.  Also, the digit design would be applicable for score digits, the inning digits, and also the balls/strikes/outs display.

My design criteria were as follows:

  1. The digits must be easily visible from a distance
  2. The digits must be visible in sunlight.
  3. I must have dimming control of the digits for night viewing.
  4. I need to control all of this from a single microcontroller (atMega168 or similar)

After much research, I found these wonderful chips from TI (TLC5916) and STMicro (STP08CP05).  Both are effectively identical.  They each have their own value added features (none of which I use), but the basics are the same.  They are a 8-bit, constant current, LED driver with cascadable latch registers.  Additionally, they work on 3.3V power, which is  something I didn’t consider before I started, but is convenient since I’m going to likely have to run the whole thing on 3.3V because of the wireless module I’ve chosen.

These chips are quite simple.  There is an SPI input and an SPI output on the chips.  From your microcontroller, you start by sending a byte on the SPI peripheral.  This shifts bits across the SPI bus and into the shift register on the TLC5916.  Then, if you take the Latch Enable pin low, up to 8 LED driver channels will be lit based on the position of the 1 bits in the byte you sent.  Cool!

If you send more than one byte, as the second byte is shifted into the first chip, the first byte gets shifted out of the chip to the input of the next chip.  This allows me to send an entire string of bytes that represent the values I want to display on the scoreboard.  Once I’ve shifted all the bytes, then I take the Latch Enable pin low and the LED driver channels light up all at once.  Double cool!

In order for this to work, you have to design your board so that you can easily cascade them.  Some pins, SPI in for example, terminate on the chip.  Others terminate on the TLC5916, but also are passed on to the next; Latch Enable, for example.  Also, the SPI out pins have to be connected to the next as well.

The LED segments are 10mm red ultrabright LEDs, four in series, and powered by a 11.1 LiPo 4000mAh battery (let’s call it 12V for now).  I’ve decided to use a bus bar power design for simplicity.  All 12V power and ground are derived from these bus bars and are connected to each digit with a 5mm dual screw terminal connector.  The electronics are powered by 3.3V coming in on the cascade connectors.

A picture is worth a thousand words (or more), so I’ve added a view of what the Score Digit schematic and layout look like.  The schematic is pretty straight forward.  I simply copied the sample schematic out of the data sheet and then added in my own values and LED design.  Then I added in a SPI/Power/Latch bus design that would enable me to easily cascade the digit modules.

The layout of the PCB is, even now, in a state of flux.  Each time I make one of these, I find something I can improve.  Mounting holes, copper fill to help with heat dissipation, layout so I can optionally use SMD resistors and capacitors, adjustments to tracks to allow for easier home etching and drilling, thermals on pads, then no thermals on pads (ended up being a bad idea).  Here’s the latest version of the layout, and I may yet change it because I have two more of these to make.  There is a variant of this module that I will be using for the inning and ball/strike/out display.  Essentially it will be the same.  I will post this once I’ve made it.

I hope you’ve enjoyed this segment.  More later!

Building Blocks: Introduction

It’s pretty funny how my neighbors view my different projects.  They’re always asking, “so…why don’t you just buy one of those on the internet?”, to which I reply, “none of those on the internet do exactly what I want them to do.” 

This project is no different.  I wanted an open scoreboard hardware platform that I can control from common wireless devices (mobile phones, netbooks, etc.)  I also wanted a scoreboard that didn’t cost me $1000 and that I could actually repair myself.  Well, I haven’t exceeded the $1000 mark, but it hasn’t been a cheap project either.  Subsequent versions (i.e. those made by fans of the blog) should be significantly cheaper without all the trial and error (and error, and error, etc.)

When I began to plan this project, in earnest, I quickly decided that the best way to pull this off would be to cut the project down into building blocks.  Mass produced products benefit from a single monolithic PCB that does everything.  For me, that simply isn’t the case.  This thing needs to be modular so that I can build the smaller building blocks, test them, and then move on to others.  I’m going to detail each building block in a series of posts along with the files I used to create them.

The building blocks I am working on now are score digits, inning digits, balls/strikes/outs, microcontroller, and finally the wireless interface.

I don’t need no stinking drill press!  That’s right.  I drill my holes by hand.  Yes, I even own a rather large drill press, but I find it easier to achieve the precision I’m looking for with a simple hand drill.
This is one of the 7 segment display boards for the scoreboard.  I did the layout in Eagle and then used the toner transfer method to put it on some 4”x6” copper clad I bought on Ebay.  I use a solution of diluted HCl and H2O2 as etchant.  It works great and is a bit greener than the Ferric Chloride method.  Do a search at Instructables.  There’s a couple instructables on this method of etching.

I don’t need no stinking drill press!  That’s right.  I drill my holes by hand.  Yes, I even own a rather large drill press, but I find it easier to achieve the precision I’m looking for with a simple hand drill.

This is one of the 7 segment display boards for the scoreboard.  I did the layout in Eagle and then used the toner transfer method to put it on some 4”x6” copper clad I bought on Ebay.  I use a solution of diluted HCl and H2O2 as etchant.  It works great and is a bit greener than the Ferric Chloride method.  Do a search at Instructables.  There’s a couple instructables on this method of etching.

Here’s a preview of where I am at right now with the scoreboard. Unfortunately I did not think of blogging my progress until now, so I’ve made some significant progress already. I will try to go back and document most things I have done so far. Stay tuned for that.

Let’s Get Started, Shall We?

A few years ago, I realized that there were many things I’ve always wanted to do and learn, but never took the time.  Some of these things come from as far back as when I was a kid, but I never had the time or the opportunity to pursue them.

So…I took up Snowboarding.  Now, a 38 year old on a snowboard for the first time is a comical thing to see.  After a few years and a couple mishaps where I smashed my knee real good and almost knocked myself out even though I was wearing a helmet (thankfully), I decided that I scratched that itch enough and should move on.

So…I decided to build a robot.  Oh yeah, it was going to do everything and I knew exactly what I wanted to do.  I realized that I knew bupkis about anything to do with electronics and mechanical engineering.  I did know that I have some significant skills as a programmer, so I hoped that would help compensate for my other deficiencies.

In programming, things are on and off, true or false; values are known and don’t deviate.  I came to find out that it is not the same in the real world of electronics and mechanics.  No amount of programming prowess was going to compensate for my electronics and mechanical newb-ness.  I was going to have to learn how to reign in an analog world into a digital format that I can work with.

So…I decided to learn electronics.  Digital electronics, at first, because it fits best into my digital view of the world.  I went through the whole breadboard , then toner transfer, etching, and building my own circuits.  I’ve learned a lot in this journey.

So…I decided to scrap the robot project.  Why?  Well, to be blunt, most robots I saw during my journey in electronics fell short of the expectations I would have for myself.  Some stood out, but it was clear that there was a significant amount of electronics, mechanics, and programming skill behind them that I felt I simply didn’t have at this point.  What to do then?

Well, I figured I should hone my electronics skills by building a project of significant complexity in electronics.  Next I should hone my mechanics skills by building a project of significant complexity in mechanics.  For my first project, I decided that I should build an electronic scoreboard for my daughter’s softball team.  The beauty of this project is that it involves almost no mechanics whatsoever.  That way my lack of experience with mechanics won’t stall the project.

This is where I am today.  Building the scoreboard.  And this blog is my attempt at documenting my successes and my failures.  Along the way, I expect to be able to post valuable information for others to use, and hopefully I can also see some feedback from the community for improvements to my project.

I have many other interests and projects going on, so you may see much more than just the scoreboard on here.  Feel free to enjoy my other ramblings as well.

Thanks for reading!

Ken.