Phantom Powered Bass Buffer Box Part 3

We're already up to part 3 for such a simple device.  That's engineering though.  A thousand little interconnected details and considerations so that a design can work all the time, every time.  Without even realizing it, we have very high expectations of the products we use.  As the complexity of a device increases, so does the work necessary to make sure all the pieces work together over a broad range of conditions.  Moving on....

Click to enlarge.

The new and improved buffer box requires no external power but the sound sucks.  And hardly unexpected.  That 100nF output cap just doesn't cut it.  We have a first order high pass RC filter when plugged into the mixer.

For those familiar with RC circuits, the cutoff frequency is determined by Fc = 1/(2*PI*R*C).  Just by observation we can see that as R or C get smaller, the cutoff frequency goes up.  Plugging R_Out, R_In, and C_Out (ignore C_In for now) into the equation gives us 578Hz.  The low E on a bass is about 41Hz.  The series combination of C_In and C_Out will yield an overall smaller capacitance meaning that the actual cutoff frequency will be higher.  So I did some empirical tests using different output capacitor values:

The solid lines are of most interest as they show the frequency response thru the mixer.  It took a 100uF cap to get that flat green line.  With both the 100nF and 4.7uF caps, the cutoff was above 1000Hz.  That explains the bright sound.  It is kind of interesting that the no load response wasn't flat like the green line, considering the large input resistance of the scope probes,  Perhaps the AC coupling cap inside the oscilloscope in series with the output cap had an effect?  Not entirely sure, nor is it as critical as the loaded response.

So why did this circuit work prior to the phantom power modification?  As it turns out, the original design still had to go thru a 1/4" to XLR adapter.  And the particular adapter being used was more than just a couple of point to point wires, it had a transformer inside.  The transformer presented a higher impedance (something like 40K ohm) which brought that cutoff frequency down quite a bit.  Not enough impedance for a bass or guitar to drive directly, but a keyboard, effect pedal, or even buffer box would have no problem.  By adding the XLR connector directly to my buffer box, I removed the adapter and exposed a design flaw.  With a 100uF cap in there, things are sounding good with very low noise.

Measuring sin waves

I would have done a little more tweaking, but they don't have a lot of down time (the bass is used twice a week).  This was a scenario where the details mattered in a very obvious way.  Engineers have to learn to recognize the causes for certain outcomes, and sometimes it's only one component that makes for all the problems.

Added a piece of an iron spike to give it a little weight.  Otherwise
it felt like an empty box.  I wanted people to take it seriously....

Phantom Powered Bass Buffer Box Part 2

The buffer amp I built up from the last post served well for awhile, but I never liked having a power supply involved.  After the addition of a few parts I was able to take advantage of the phantom power supplied by the mixing console.

A couple of things to note in this design.  First, there is that middle contact on J1 that I connected to ground.  This keeps things nice and quiet when nothing is hooked up.  When a cable is inserted, the plug physically breaks the connection between the grounded contact and the signal contact.

The next item to look at is the signal output.  The audio is being carried over pin 2 of the XLR connector, but what's is with the stuff connected on pin 3?  If we look at the mixer side, we see that whatever signals are carried on pins 2 & 3 will be subtracted from each other via an op amp.  When a microphone is used, it will actually present a differential signal to the mixer input.  Any signals present on both pins will cancel out, and the difference between the signals becomes the amp output.  But I only have one signal, right?  Ideally yes.  However, the cable carrying the two signal lines will be subject to all sorts of noise.  So pin 2 will carry the desired audio signal plus some noise, while pin 3 will only carry the same noise as pin 2.  When they get subtracted, all that is left is the audio.  C4 & R7 are chose to match the frequency response of the JFET buffer output, which essentially makes a high pass filter (this ensures that the noise on both lines is filtered similarly).  C4 can just be made equal to C2, but R7 has to be calculated.  I did this by running a 1KHz tone through the buffer with no load and with a dummy load to determine the voltage drop internal to the buffer.  I took the measurement prior to C2 so that I would not get any reactive component to my values.

Simplified circuit showing only power related parts.

Lastly, there is the phantom power circuit.  It's pretty simple and ingenious.  The mixer applies a DC bias to both audio carrying conductors, which the device just has to tap off thru a pair of equal resistors.  Capacitors at the inputs and outputs block that DC from the signal drivers and receivers, making the rest of the circuit none the wiser.  You do have to be careful though, as the more current you draw, the less voltage you will have to bias your circuitry.  That's where the zener diode comes in.  It will draw whatever current is needed to get the voltage drop across the 6.8K and 10K resistors to leave us with 12V.  As long as the current thru the zener is greater than any current your device needs, we'll have a steady enough voltage rail.

So after the solder smoke cleared I plugged the buffer amp into the mixer and happily watched the LED light up.  I hooked up an electric guitar and..... well..... it was punchy enough, but piercingly bright as well.  This wasn't a huge surprise, but I had gotten away with the circuit up until now so wasn't going to change it at first.  C2 is the problem.  It's too small.  It was creating a high pass filter with the mixer input that didn't include any of the bass.  Or mid tones.  But it had worked well for years right?  Yes, and I found out why, and I'll tell you all about it in the next post.

Phantom Powered Bass Buffer Box

It may seem like a lot a lot of projects going in parallel, and that is partially cause I do, and partially cause it takes a lot of time to do a write up.  I'm hoping this project doesn't go more than one or two posts as it's already completed and pretty small.

Backstory:
A few years ago I made a little signal buffer for a church as I saw that they were plugging their bass guitar directly into their mixing console (almost directly, but more on that later).  And to make it worse, they were using the XLR mic inputs instead of the line inputs.  To be fair, they didn't have much choice.  A cable snake ran from the sound booth in the back of the room under the floor and to the stage, where several panels of XLR connectors at the stage allowed for the connecting of mic's and instruments.  The problem here is that the bass is a single ended high impedance output, and the mixer mic inputs are quite low impedance.  The result is a weak and unenthusiastic tone, susceptible to noise (the passive pickups are pushing a signal over about 100 feet of cable).

A simplified model.

As a rule of thumb (at least for guitars), the input impedance of a device should be at least 10 times greater than the output impedance of the thing driving it.  This will ensure that the audio signal is preserved with little or no effect on tone.  As an example, a guitar might have around a 10K$\Omega$ output impedance, and a mixer line input is often around 10K$\Omega$ as well.  That's a 1:1 ratio.  The XLR mic inputs go down closer to 1K to 2K$\Omega$.  If we look at this as a voltage divider, we can see that much of the signal seen by the mixer is attenuated.  By half if using the line input, and only around 20% or so of the voltage appears over the mic inputs.  There are also reactive elements in the guitar too; ultimately, the larger the input resistance, the less impact there will be on the guitar circuit.

So what can be done?  Well generally you'd use a direct box.  These passive devices(though there are active ones too) use a transformer to well.... transform the impedance.  These things can range in price and performance.  Also, pretty much any guitar effect pedal or amplifier with a preamp output solves the problem too.  But what fun would that be?  So I built them a JFET based source follower out of parts I had and called it a day.  It has high input impedance, and low output impedance, problem solved.

JFET Q1 as well as R1 & R2 all present high impedance paths for incoming signals.  J3 plugs into a 9V wall transformer.

And despite an inherent design flaw, it worked well.  But recently I was designing phantom power into a headphone amplifier and that got me thinking: why not do the same for this project.  So I did, and I'll continue this in another post.

Daylight Logger for Gardening Part 2

Previously we established (loosely) the need for a sunlight logging device.  We came up with a basic design plan and the requirements of each necessary element.  And here is what I built:

It's a bit more complicated than I may have led you to believe, but not all that much so.  Let's take a look at the blocks.

Memory:

The memory is nearly as expected straight off the data sheet.  I have the address and write protect lines wired low to make life simpler.  R7 & R8 provide the expected pull up resistors for the I2C protocol but there is an LED in parallel with the SCL signal.  D2 is basically my status LED and the only means by which I can communicate with a user.  The SCL signal is used because the memory chip will not respond to "spurious" changes on that line.  An I2C start condition requires the SDA line to go low while the SCL line stays high.  So as long as the SDA signal stays high, the memory chip will ignore changes on the SCL line.

Communication:

Q1 & Q4 are setup so that no current flows while not sending or receiving data.  Since the device will spend most of the time logging, it's prudent not to have any excess idle current draw.  Q1 didn't have to be a FET, but it just made it easier to deal with inputs that could range something like +/-12 volts.  The TX pin of the MCU is combined with another feature of the circuit, so Q4 will turn on during normal operation for small amounts of time, but R3 was sized to reduce power consumption.

Detector:

The first major change to the detector is the addition of Q3.  It takes only small amount of time to measure a light sample, so the circuit really spends most of its time idle.  The amplifier has a quiescent current of  230uA which isn't half bad, but not as good as zero.  The ambient light sensor is much worse, drawing several mA in full sunlight.  So Q3 is only turned on just prior to reading sample, which in turn supplies power to the light sensor and amplifier.  As a side effect, Q3 also turns on, but hey, I only had so many I/O pins to work with.  I also added a pot to adjust the sensitivity of the sensor.  The sensor will try to allow a current proportional to the amount of light (voltage source permitting) so the amount of resistance will directly have an effect on the voltage seen by the ADC.  A lower resistance will provide less sensitivity, and a wider input range, while a higher resistance will max out and clip quite quickly.  R2 is included only so that while programming the PIC12F1572, the amplifier output and data line of the programming tool don't drive each other directly.  You may have noticed that the memory is never powered off; it has a standby current of only 1uA, and more importantly, the signal for Q3 cannot be used to turn it off and on while also being used as the TX line for communications.

Nearly finished design

Microcontroller:

As stated before, the PIC12F1572 doesn't have a ton to do, but it does make this whole thing work, and keeps the batteries alive.  When power is turned on, LED D2 lights up and the device sits in a "ready" state.  At this point it will accept requests from a PC to dump previous logging data, and assists in calibration.  By exposing the light to full sunlight, the potentiometer can be adjusted by a watching the LED.  Steady on means that the ADC is maxed out, and a rhythmic blink indicates that the ADC is reading between max and min values.  So ideally, one would adjust the pot until the LED is steady, then back off slightly until it blinks.  A slow blink indicates the battery is low.

How does the micro know that battery is low?  Well I think the solution is rather ingenious, but I strongly doubt I'm the only person to come up with it.  I already discussed the fixed voltage reference used to ensure consistent ADC results over varying levels of battery.  So why not measure the voltage reference using the battery as the upper ADC voltage.  As the voltage of the batteries drops, the measured value of the fixed reference gets larger.  Consider an 8-bit ADC result (0-255) with the voltage reference set tot 2.048 and the battery supply at a nominal 3V.  We can come up with the equation Vref/Vbat*resolution = result.  By substitution we get 2.048/3*255 = 174.  That means a reading of 174 indicates a full battery.  Our low end is unfortunately only 2.7V (that's the minimum input supply of our op amp, I would/will change op amps for future revisions, but it was one that I had on hand), but we can calculate that value too.  2.048/2.7*255 = 193.  If we reada value larger than 193, we cannot assume that our op amp is properly biased.  And that is all there is to it, just periodically make the measurement and blink the LED if necessary.

Now that covers the "ready" state of the device. but how do we get it to take light readings?  By pushing reset button S1.  Yes, the reset button.  And yes, it does reset the device.  This is another clever trick that I will pat myself on the back for.  The PIC12F1572 has a control register that keeps track of the cause of a reset.  Early in the code, that register is read to determine whether power was just supplied or the button was pushed.  If the button was pushed, the device skips the "ready" state and starts a 16 second timer to allow a user to place the sensor.  Then, for the next 24 hours, the circuit takes sunlight readings at approximately two minute intervals, after which it goes into a permanent sleep state.

Here is a screenshot of the program I made to accompany the project.  It lets you connect to the device via a serial port and download the light data, as well as save or import the data as a CSV file.  You can see that this particular data set is for a rather sunny day with little shade (though I hadn't calibrated it before running this test).  It should also be noticeable that I began logging on the latter part of sunset as the beginning of the graph is mostly nighttime.  Sunrise should be pretty obvious by that dramatic ramp up in recorded light.  I'm actually quite proud of my background that I drew up.

Although it's an embarrassingly ugly construction, I'll show the working prototype anyway.  There was definitely a lot of design after the fact leading to a bit of chaos.  But I temporarily stuck it to the lid of a salsa jar (my "weatherproofing") using a little putty and it works just fine.  We can look into a few of the design hurdles in the next post.

Daylight Logger for Gardening

While I don't much like to garden personally, a certain someone really wanted to improve my landscaping as well as grow a variety of vegetables and herbs and whatnot.  As we shopped for various plants and seeds I took note of the sunlight requirements listed on each.  Generally it was a qualitative statement such as "Full Sun" or "Partial Shade".....  Well what does that really even mean?   Being the engineery kind of guy that I am I needed something more quantitative.  So a quick internet search while at the store yielded answers as such:

Full Sun = 6 or more hours of direct sunlight daily
Partial Sun/Partial Shade = Between 3 and 6 hours of direct sunlight daily
Full Shade = Less than 2 hours of direct sunlight daily

However, the more reading you do on certain plants you find that while six hours may constitute the minimum requirement if you will, many plants will do better with even more sunlight.  And all of this kind of begs more questions: what about the variations in amount of shade?    Are these aggregate amounts of sun daily? (and from what I've figured out, yes)  Is sunlight at certain times better than others?  But most importantly, what kind of sun do I get in my yard?

I live in a neighborhood with many old and massive oaks.  While the neighborhood is by no means new, when built they did a good job of leaving many of the existing trees.  So areas of the yard that may be next to the sidewalk and nowhere near a tree might get lots of morning shade due to the oaks behind the neighbor across the street.  Then late morning and afternoon sun.  Then late afternoon shade.  Then early evening sun.  Just from observation working outside or mowing the lawn I've noticed that the amount of sun can swing both directions several times throughout the day.  It'd be interesting to find out how much.....  Especially if I want optimize my planting (and yes, normal people don't "optimize" their gardens, nor is the effort likely worth it).

The Project:
Where to start.  Basically, we need to measure the sunlight a bunch of times over an interval, say one complete day.  We then must store those measurements and then be able to recall them for consumption later.  This will also have to run off of batteries and be resilient to weather.  That should pretty much cover it.

Sunlight Detection:
Measuring the sunlight won't be all that much different than the IR detector used in the Virtual Whammy Bar.  Instead of a narrow spectrum detector though, we'll use an ambient light sensor.  This is more or less the same idea as an IR photo sensor except its response resembles our ability to see light.  I believe such devices are used to automatically turn on the head lights in newer cars when it gets dark.

That's the fundamental circuit.  It'll have to evolve going forward, but functionally it will remain the same.  I probably could do away with the buffer on this one,  Our ambient light sensor sources quite a bit of current.

Memory:
The memory chip will be a Microchip 24AA08.  Why?  Because I had a couple.  It's a whopping 1KB, though marketed as 8Kb (B = bytes, b = bits).  At least the 1K actually equals 1,024.  I had larger memory, but it was SRAM instead of EEPROM.  It does have a 1uA standby current, which is convenient for our battery powered circuit.  The I2C interface is handy too as I have to manually bit-bang the protocol.

ADC/Microcontroller:
We'll actually be using the internal ADC of the microcontroller, which is a Microchip PIC12F1572.  I showed it separately only be cause it needs a little consideration.  Since our circuit will be battery powered, the circuit voltage will vary over the life of the batteries, which means we can't use our circuit power as the ADC's positive voltage reference.  Fortunately the micro contains a fixed voltage reference module.  By manipulating the appropriate registers you can get a 2.048V reference, which can also be connected to the ADC module.  I'm taking a guess that the light sensor is less dependent on the applied voltage as it is to the applied light, as its response is to allow current flow.  Truthfully, I don't know the actual part number of the ambient light sensor, but some datasheets I've looked into support my conclusion.  But regardless of the voltage from the batteries, the ADC will always measure the incoming light based on a 0 to 2.048V scale.

Our microcontroller does all of our grunt work.  It will schedule when to take light measurements, store the results in the memory, and communicates via a serial port with a PC.  It'll perform a few other functions we'll discuss later, but these are it's core responsibilities.

In the next post I'll show the resulting circuit and discuss more details of the design.

USB-to-Serial Mod for Sort of an Embedded Guy

I was first introduced to embedded design back in college where we had two classes based on the Motorola 6800 and 68000 series microcontrollers.  One class focused on the architecture and the other on assembly and the instruction set.  I immediately wanted to make a project of my own.  Unfortunately the classes were a little too theoretical and didn't detail the necessary steps to actually get a circuit up and running.  But even so, I managed to order myself a Microchip ICD2 decently cheap and a couple of DIP packages (and oops, a QFN chip) as samples.  It was all very exciting, until I unboxed it realized I needed a serial COM port, and my computer didn't have one.  Off to the electronics store to buy a USB to Serial adapter.

So that is all well and good until you get comfortable blinking lights and such, and want your little circuit to talk to a computer.  I actually used a MIDI port as my first serial interface because I had musical devices in mind.  A fun learning experience, but in the end I did end up getting a USB ICD2 down the road freeing up the serial adapter.  Then started a different set of issues.

To comply with RS-232 standards, the adapter not only inverts the signal, it bumps it up to 12V.  Your garden variety embedded circuit will be 3.3V or 5V.  Inverting the signals and dealing with the voltage difference can be handled easily enough though, with a 74x04 Hex Inverter or a couple of transistors.  It just crowds the bread board and is one more thing to assembly to get a circuit up and running.  Also, that DB9 connector is a pain and you're stuck tethered about 12 inches from the USB port.

Possible Solutions:

1. Make a breakout board.  Seems easy at first, except the DB9 headers I have don't fit into a .100" grid due to offset rows.  The target circuit would also have to power the circuitry needed to invert and convert the voltages.  You could remove the DB9 and solder direct or use a different connector, but still not the best idea.
2. Remove the DB9 and add a .100" header or solder pins directly to the PCB of the adapter.  I actually did this, it made hooking it up easier, but destroying the plastic housing of the adapter made things kinda hairy.  There was pretty much no more strain relief, and everything was exposed and unprotected.  It just wasn't a comforting setup.
3. Buy a breakout module off the internet.  This is actually probably the best idea.  They're small, cheap, and self contained.  As a matter of fact, I could just take an Arduino Nano and blank the program of the chip (it'd probably be cheaper than a breakout module).  Then I'd get a 3.3V and 5V supply with it as well.  But then I'd always be tempted to make something else out of it....  And what fun is that?  I already have this adapter, let's make something out of it.
4. Build a module based around the PCB of the adapter.  The 5V from the USB bus can power any extra circuitry, and even the target device if needed.  And, it uses up stuff I already have!

Shown above is my resulting device.  As an afterthought I added J4 to support the original function of the adapter.  It turned out that after I built this, the one thing I wanted to test it on already had circuitry built in to invert and level shift the voltages.... Oops.  I had to include jumper J3 so that the output of my hex 74ALS04 wouldn't fight against the output of from a RS-232 device.  The output of U2.6 would be unpredictable with nothing plugged into J2, resulting in a situation where it could try to drive +5V while a RS-232 device tries to drive -7V or even lower.  I don't know if there is enough short circuit protection in these IC's for a 12V differential, but I don't want to find out.  De-soldering chips is a huge hassle.  The jumper also makes the circuit look like it has more features!

Speaking of short circuits, I added a few resistors in places to protect stuff.  The 120R resistors take the brunt of improper connections, though probably survive too long.  But they are easier to replace.  In retrospect, I should have gone larger, but I won't fix that issue until something starts on fire.  We'll just pretend they're fuses.

The 4.7K resistor essentially handles my "level shifting".  While the datasheet says the 74ALS04 can handle up to +7V, that may be dependent upon the supply voltage.  I'm showing my estimation of the input circuit.  Protection diodes D1 & D2 may or may not exist.  If they don't, a +7V input is no big deal as the emitter of Q1 won't take any current.  On the other hand, a -7V input will likely draw excessive current.  R3 of my circuit above limits that to a safe amount.  Now if the diodes do exist, the positive input could present an issue.  Any voltage above Vcc (+5V) plus the diode drop (typically spec'd at .3V from what I've seen from datasheets) will be seen as a short across D1.  Again, the 4.7K resistor limits the current.  The same also goes D2 with negative input voltages.  Anything below -.3V starts to short across the diode.  There are likely some small resistors (or perhaps just inherent resistances) in series with D1 & D2, but they may not be up to par.

I could probably just use the diode check of my multimeter across the input of a 74ALS04 with respect to the supply pins to determine the presence of the protection diodes; but at the time of writing this I'm sitting in a coffee shop.  And besides, I've already soldered it all together.  Better safe than sorry.

Photo taken from USBGEAR.com

Above is a similar adapter to what I started with.  The little box in the middle of the cord houses the PCB and a ton of potting material.  Below is my finished little module.  Not the greatest piece of workmanship, but I did get to use my router table.  My skills with the hot snot need improvement, but overall I'm happy with the result.  It's heavy enough that attached cables don't force it to move or twist, and the solder side is protected from any incidental contact with parts lying on my desk.  And best of all, I made it.

Not pretty, a bit messy with the hot glue, but it's worked really well so far.

Use an Arduino with Atmel Studio

The Arduino line of embedded platforms have become pretty popular among hobbyists and for prototyping or quick proof of concept.  Depending on the type of news you follow on the internet, you've probably heard about all sorts of projects people have done using them.  I've even seen them for sale in electronics stores.  And for good reason, Arduinos have a lot to offer.

The Setup:

All said and done, Arduino really comes down to being a combination of a custom compiler, a bootloader, and a minimum set of hardware so as to require nothing more than a USB cable.  The compiler reminds me of the pairing of C# and .NET: the language syntax is clean and easy to use, and the API abstracts you from all the granular detail.  Everything is handled thru wrapper functions that makes the hardware nearly invisible.  No digging around in datasheets for esoteric bit settings and flags to get peripherals to work, they take care of it for you.  The bootloader removes the need for a programming tool, and thus external hardware.  And finally, the hardware consists of an Atmel Atmega328 with enough components to power, communicate serially over USB, reset, and access the I/O of the microcontroller.  But what's really nice is that the initial investment is only the cost of the Arduino board itself.  The IDE is provided free of charge and loaded with example programs to get you started.

So I purchased a Nano (one of the several flavors offered), plugged it in, and got started.  The first thing I noticed is that it just shows up as a generic COM port in Windows.  This will be helpful later.  But I did what most people would do, the proverbial "Hello, World!" of embedded systems: blinking an LED.  And behold!  My will was manifest upon the physical world.... in the form of a small little light... turning on and off at one second intervals....  Well hey, it only took 2 minutes, and that's the power of the Arduino.  (and the IDE actually has code for a Blink program included which kinda takes the fun out of it, but it can be modified as I did to do things like blink at different rates based on input)

However, I found myself feeling rather constricted by the platform.  I wanted to have full control over that Atmega chip!  I guess the Arduino isn't meant for me....

The Solution:

Atmel provides their own IDE, Atmel Studio, intended for C/C++ development on their microcontrollers.  It's actually built in top of Microsoft Visual Studio and inherits many if the features.  The problem is that it requires specific programming tools.  So even if I write a program, I can't get it into the chip.  This is where understanding what the Arduino is came in helpful.

At the end of the day the Arduino isn't dumping Arduino code to the microcontroller.  It's sending a compiled binary the same as Atmel Studio would.  But how?  Turns out the Arduino IDE has an option for verbose output when compiling and loading a program.  The IDE uses a command line tool called AVRDUDE which supports programming Atmel chips using a myriad of tools (including the Arduino bootloader).  I can just copy the command line arguments to write any .hex file I want.  AVRDUDE can be downloaded or comes with the Arduino IDE.

So problem solved.  Build the program in Atmel Studio, copy the binary into the AVRDUDE directotry (or type the whole build path in the command line), open a console window and away we go.

Well actually, this kinda sucks.  It's a bit of a hassle.  You gotta move around between a few windows and manually do a bunch of stuff.  It gets old.  Fast.  But there is a better way.  Visual Studio (again, the underlying software for Atmel Studio) allows for custom commands.  In the image below you can see that I've created a tool using AVRDUDE and just copied all the command line arguments that I used above.  The important pieces to note are that the initial directory is set to the build directory of whatever project is open so that the path to the .hex file is unnecessary, and the same goes for the name of the .hex file.  I've also checked the box for "Use Output window" as it's nice to see any messages from AVRDUDE.  The only caveat is that you need to manually change the COM port argument if you use a different USB port.  Otherwise, assign the tool to the button and the process becomes quick and easy.

But wait!  There's more!  We have ourselves a programmer, but not a debugger.  Truthfully, that's a bigger hurdle, but we can at least come up with a way to easily get feedback from the Atmega328.  Since we're using an Arduino, we've already got ourselves a convenient COM port by default.  We can just have our code spit out info over the UART to allow for visibility into its operation.  I went ahead and wrote myself a simple console application in C# that takes a COM port and baud rate as arguments and will run in Atmel Studio the same as AVRDUDE.  Not nearly as powerful as a debugger, but still useful enough.

The Finish:

Well there we have it.  With only an Arduino board (and not just the Nano I'm using) and a USB cable we have a simple Atmega development platform.  We can use the Atmel software with a somewhat seamless workflow by only adding some command tools.  This may not be for everyone, as the Arduino platform in and of itslef provides a lot of functionality, but for some, this may give you extra flexibility with the Atmel chip to do what you want.  Alright, I've typed Arduino way too many times....