Brian Carrigan

Dreadbot

Mon, 28 Oct 2019 12:00:00 +0000

There is a wonderful Magic: The Gathering scene here in Durham, NC. Unfortunately, Magic often deserves the trope that it gets of being an expensive hobby. In order to enjoy the game on a budget, myself and a group of locals created a new format: Paper Dreadful. The format is simple: create a 60 card deck with a maximum of 4 of any card (other than basic lands) and the total cost must be $20 or less on that day. The same rule applies with the sideboard, except it must by $5 or less.

The problem here is that Magic cards change in price all the time. What happens if I build a deck and then a card skyrockets in price?

Proposed Solution

What our group essentially needs is a way to cement the price for a deck list in place so that we know that it was $20 at the time it was built. The initial way we did this was by taking a screenshot of the deck and post it in a discord. This was cumbersome though and it did not split the price out into mainboard and sideboard cards.

Our proposed solution was to make a discord bot where you paste a link to your deck and it stamps it with an approval or rejection based on the price that day. Such a bot would need to interact with three services: the deck list provider, a pricing provider, and Discord.

I have been playing around with Rust a lot recently and decided that this would be a good place to try it out on a larger project. If you want to follow along in the code, the source can be found at https://github.com/Carrigan/dreadbot.

Consuming APIs

In order to build a price list for a given deck, we need to work with at least two resources: the deck lists on mtggoldfish.com and pricing info from scryfall.com.

The MTGGoldfish connection is quite simple: all we are doing is downloading a text file formatted with one card per line and the quantity of that card. There are two parts of a deck, the main deck and the sideboard, and they are separated by an empty line. We consume this file by creating two data types: a Deck object that has many Card objects.

let mut mainboard: Vec<Card> = Vec::new();
let mut sideboard: Vec<Card> = Vec::new();

for line in block.split("\r\n") {
  match Card::from_goldfish_line(line) {
    Some(card) => {
      if sideboard_flag { sideboard.push(card) } else { mainboard.push(card) }
    },
    None => sideboard_flag = true
  };
}

Now that we have the Deck parsed, our next goal is to pair this info with pricing info. The Card object is capable of holding pricing information, but at this point that information is None. Our Scryfall API takes the Deck object and builds a query based on the cards in it. It then finds the cheapest version a given card and returns a vector of pricing information. This vector can be passed back to the Deck object’s update_pricing(&mut self, scryfall_entries: Vec<PricingSource>) function to fill in pricing. We now have a Deck object with a list of fully filled Card objects.

Interacting with Discord

Now that we have a way of fetching populated Deck objects, we need a way for users to work with them. There are three important things we need to do: verify that a new deck’s main deck is under $20 and that its sideboard is under $5, give pricing info about a deck to guide users to meet these limits, and verify that a list has not changed.

Our group was already using Discord to do these things manually, so it seemed like a natural extension to provide discord bindings to do them. I found the Serenity crate which allows you to do this quite easily by implementing a trait with callbacks for message and connection events. For our handler, I started with a root level regex that defines whether the bot should respond to a message and then if so, attempts to see if the contents of the message inside the package are a valid command. If so, the bot performs the action; otherwise the bot will return a message telling the user what the available commands are.

impl EventHandler for Handler {
    fn message(&self, ctx: Context, msg: Message) {
        let regex = Regex::new(DREADBOT_PREFIX).unwrap();

        if let Some(captures) = regex.captures(&msg.content) {
            if let Some(remaining_message) = captures.get(1) {
                if dreadbot_verify(&ctx, &msg, remaining_message.as_str()) { return }
                if dreadbot_info(&ctx, &msg, remaining_message.as_str()) { return }
                if dreadbot_hash(&ctx, &msg, remaining_message.as_str()) { return }

                // Fallback to the help message
                dreadbot_help(&ctx, &msg);
            };
        }
    }

    fn ready(&self, _: Context, ready: Ready) {
        println!("{} is connected!", ready.user.name);
    }
}

All of the functions take an argument in the form of a MTGGoldfish link. The verify function will retrieve the deck and pricing and give the deck a stamp of approval/disapproval and also give it a hash based on its contents so that people cannot change the cards in the deck list after it received a stamp of approval.

The info function retrieves the cards and pricing, but instead of applying any of our format’s logic to it, it simply returns the deck contents and how it priced the deck. This is useful for when you are at $20.05 and need to shave that remaining 5 cents.

Finally, the hash function retrieves just the deck contents and runs our hash algorithm on them to verify that they are the same as when they were initially submitted.

Conclusion

This bot has been in production for over a month now and our format is currently running its first league using the bot. I run the production version on a cheap server and it has had no outages or problems to date.

This was my first medium sized project in Rust, and I really enjoyed working with it. I worked with C as an embedded engineer for 4 years and it amazes me that a language exists that can output machine code as efficient as that while having all the conveniences of modern languages. I loved being able to perform test-driven design in the same file that I created new functions in. Between this and Elixir, I have also fallen in love with pattern matching. I have been working on several smaller embedded projects in Rust and hope that I get to work with it more in the future!

Project link: https://github.com/Carrigan/dreadbot

Wunderscan

Fri, 20 Apr 2018 12:00:00 +0000

I didn’t actually plan this project, but rather it found me. I was at the Scrap Exchange, a local reuse center, when I found a very nice looking scanner that you might find at a grocery store kiosk. It had been ripped from its connectors and had unlabeled wires hanging from it; a bit of hardware gore if such a thing exists. It was labelled on sale for $6.25, and a quick search revealed that it originally retailed at over $500. I thought a great use of this would be to keep near our pantry so that when we are out of a spice or snack, we could just scan the item and it would get posted to our shopping list. I figured I would try to reverse engineer it, and if all else fails, scrap it for the laser and motor. This is a longer post that goes through the entire process, so strap in!

Reverse Engineering

I was able to locate the datasheet for the scanner and find that it uses an RS232 serial connection to send data, and that normally there would be a DB9 connector where the frayed ends were. Having no wiring diagram, I had to start by finding the power connections.

This part of reverse engineering is really more luck than anything. You run the risk of frying your part when you connect the power improperly. I set my power supply for 5V and tried the following things to find the power cables:

Using the BBROYGBVGW color scheme used for resistors to match wires to their DB9 pinouts. This did not work.
Start trying wires based on likely color codes; for instance black and brown for ground, and red or orange for power. This wound up working, though who knows if it was for any of the logic that I thought. It turned out that orange was the 5V line and brown was ground.

Now that the part was powered and working, all that was left was finding the RS232 transmit line. I used my oscilloscope to do this part and found it by scanning items and looking for the signal. It was not long before this wire was found and I was able to receive UPC codes. The scanner simply sends the ASCII representation of the UPC code followed by the \r\n characters. This would make parsing the messages easy.

Posting to Wunderlist

My wife and I use Wunderlist for our grocery shopping, so the next step for this project was to figure out how to post the item information to a shared grocery list. This consists of two parts: converting the UPC number to an item name, such as “16 Oz Almonds” and then making a request to Wunderlist with this information.

UPC Lookup

For UPC lookup, the UPC Database looked like the best choice since its free tier would work for a low lookup count and because you can add your own UPC labels for items they don’t have. The service is also very easy to use; simply sign up for an account, and then you can search using the following URL scheme:

GET https://api.upcdatabase.org/product/:upc_code/:api_token

This will return a product or an error if none could be found.

Wunderlist Post

Next up was posting to Wunderlist. As with above, our first step is getting an API token. This can be done right in their developer web interface by creating a new application to use with Wunderlist and then creating an OAuth 2 token for your own account. Once you have an OAuth2 token and a client ID for your application, you can start making requests.

In order to create an item, we first need to find the ID of the list that the item will be added to. We can do this using the following API point:

GET https://a.wunderlist.com/api/v1/lists
  X-Access-Token: <your access token>
  X-Client-Id: <your client id>

This returns a list of lists, at which point you can find the one you want by searching through the results looking for the desired title. Grab the ID of the desired list, and then posts can be made using:

POST https://a.wunderlist.com/api/v1/tasks
  X-Access-Token: <your access token>
  X-Client-Id: <your client id>
  Body: {
	   "list_id": <id from the last step>,
	   "title": "<title from UPC lookup>"
  }

Feeding our Pi

To tie this all together, we need a program that does the following:

Listens for UPC codes coming over the Serial connection.
Upon receipt of a UPC code, query the UPC database as shown above.
Once a product name (or error) is determined, post this to Wunderlist.

While we could have potentially used a Particle or other low-power embedded device, I wanted to try out Elixir’s Nerves project, a way to write embedded software using Elixir. So, a Raspberry Pi Zero W was chosen as the compute module so that the scanner could be placed anywhere in the house and still connect.

Building the Hardware

The hardware for this project was pretty simple: we feed 5V in through a barrel connector to the scanner and Raspberry Pi, then connect the Raspberry Pi to an MAX3232 level converter for the serial line conversion. This needs to happen because RS232 uses different voltages than the Raspberry Pi for its serial communication; see the oscilloscope screenshot below for the 3.3V serial signal versus the RS232 signal:

Writing the Software

The software side and working with Nerves in general I think deserves its own post. For this article, lets do a high level overview of the project and code. First, the code can be found at the following link:

Wunderscan Github Link

I will talk about the code in three sections: the project level, the supporting code, and the main loop.

Project Level

The project level is where we import the required libraries, setup system variables, and tell Nerves how to build our software. Unlike working with the standard Raspberry Pi environment with Raspbian and Python/C/C++ where you flash an operating system on your Raspberry Pi and then copy your program files over, Nerves builds a root image that boots into your application. You can even set your project up to allow SSH firmware pushes, allowing you to compile everything on your PC and push a new copy of the entire root system over SSH to your device. This takes all of the manual Raspberry Pi configuration out of the picture; all of the sudo raspi-config commands, wpa_supplicant.conf placement, and manually changing files to set up your pi is replaced by the Nerves configuration. This is wonderful for setting up a new Raspberry Pi to run your application.

One of my other favorite things about working with Nerves has been how you can feed your secrets into the software at compile time using the config files. Consider the following, where we pass in our API keys using environmental variables on the computer that is compiling the code:

config :nerves_network, :default, wlan0: [
    ssid: System.get_env("NERVES_NETWORK_SSID"),
    psk: System.get_env("NERVES_NETWORK_PSK"),
    key_mgmt: String.to_atom(key_mgmt)
  ]

config :scanner,
  wunderlist_access_key: System.get_env("WUNDERLIST_ACCESS_KEY"),
  wunderlist_client_id: System.get_env("WUNDERLIST_CLIENT_ID"),
  upcdatabase_access_key: System.get_env("UPCDATABASE_ACCESS_KEY"),
  list_name: "Scanned Groceries"

In a normal Raspberry Pi project running Raspbian and your language of choice, you would likely need to manually SSH in and send the keys or manually type them in using the keyboard. With Nerves, simply compile them in and flash your image. Done.

Supporting Code

What I call the supporting code is simply some high level APIs written to abstract the UPC database queries and Wunderlist interactions. I used HTTPoison to make the requests and Poison to decode the JSON. As an example, the below code shows a request to find the ID of a list on Wunderlist given the title of the list.

def find_list_id(title) do
  "https://a.wunderlist.com/api/v1/lists"
  |> HTTPoison.get(auth_headers())
  |> process_response(title)
end

def process_response({:ok, %HTTPoison.Response{body: body}}, title) do
  Poison.decode!(body)
  |> Enum.find(%{}, fn list_item -> Map.get(list_item, "title") == title end)
  |> Map.fetch("id")
end

def process_response(error, _), do: error

defp auth_headers() do
  [
    "X-Access-Token": Application.get_env(:scanner, :wunderlist_access_key),
    "X-Client-Id": Application.get_env(:scanner, :wunderlist_client_id)
  ]
end

In Elixir, it is idiomatic to return a tuple or error code instead of raising errors. Thus, this API returns one of three ways:

{:ok, <id>}
{:error, %HTTPoison.Error{}}
:error

This lets us match on the return in the calling code, making handling errors a natural part of program writing.

response = Application.get_env(:scanner, :list_name)
  |> Scanner.WunderlistApi.find_list_id()

case response do
  {:ok, id} -> id
  {:error, error} ->
    Logger.error error.reason
    nil
  :error ->
    Logger.error "Key not found"
    nil
end

Main Loop

Unlike a while loop or for loop in other languages, Elixir and Erlang use processes which are supervised by the system for very high levels of system robustness. If a piece of python code crashes, the application will exit and you will likely need your operating system to restart it. If an Elixir process crashes, the supervisor will automatically restart the relevant processes without OS intervention. This makes the style of writing programs very different, but its a style I’ve grown to really enjoy.

For our main loop, we will be using Elixir’s GenServer behavior to implement the steps shown above in the “Feeding Our Pi” section. We start by initializing our serial port, HTTP client, and polling to see if the internet has connected yet.

def init(port) do
  #Start the NERVES port
  begin_serial(port)

  # Start httpoison
  HTTPoison.start()

  # Start polling for the ethernet being available
  send(self(), :ethernet_check)

  {:ok, %{ id: nil }}
end

defp begin_serial(port) do
  {:ok, pid} = Nerves.UART.start_link
  Nerves.UART.open(pid, port, speed: 9600, active: true)
  Nerves.UART.configure(pid, framing: {Nerves.UART.Framing.Line, separator: "\r\n"})

  pid
end

Starting the serial port in active mode will cause it to send a message every time it receives a string. We can setup a callback on our GenServer that fires every time we receive data. This is where we can write the code to query the UPC code and post to Wunderlist.

def handle_info({:nerves_uart, _pid, barcode}, %{id: id}) do
  # Check the barcode
  todo_title = case Scanner.UpcDatabaseApi.lookup(barcode) do
    {:ok, product_map} -> get_best_name(product_map, barcode)
    _ -> "Barcode error: #{barcode}"
  end

  # Post the item
  Scanner.WunderlistApi.create_todo(id, todo_title)
  Logger.info "Got info: #{barcode}. Posted item: #{todo_title}"

  # Keep the state constant
  {:noreply, %{ id: id }}
end

As can be seen here, if there are any problems during the UPC retrieval, we simply post a “Barcode error: " message instead of the product name.

Project Enclosure

While I’ve printed some simple 3D designs before, this was my first one with features that held multiple parts together in an assembly. I used Fusion 360 for my modeling, and began by modeling all of the individual components or finding the common ones like the Raspberry Pi online. From there, I moved the components around until they had ample space to be wired and then figured out how to secure them in place. The Raspberry Pi is screwed into some posts using heat-set inserts.

The power connector has a very small clearance and will simply be glued in place:

The scanner itself sits on an inner wall and is held in place by the outer wall. It is high enough up that the cavity beneath it can easily fit all of the wires.

The whole thing includes some fillets and cutouts to neatly display the scanner:

Not having a 3D Printer myself, I went on 3D Hubs to get this design printed. The final result looks great and was just $11!

Summary

This was a fun project where I got to learn more about Nerves and designing 3D printed enclosures. It was also inexpensive, with the parts list totaling less than $40 for a very complex design. It is unlikely that others will find this particular scanner, but it should be possible to use any scanner with a serial protocol. The device has already come in handy several times to remind us to pick up more spices that we have run out of. I hope you enjoyed this post, and as always feel free to contact me with any questions you have if you are looking to build something similar!

If your company could use help launching an embedded product like this, I run a full-stack connected device consulting firm that builds great products for clients. For more information, please check out my Services page.

Moogfest 2017 Project

Thu, 25 May 2017 12:00:00 +0000

For Moogfest this year, Smashing Boxes put on an event for festival-goers that showcased our recent labs projects. We wanted to give attendees something to bring home and hack on, so I set out to design a programmable synthesizer for $20 or less.

Check out the project writeup, complete with schematics, code, and build instructions, at the Moogfest 2017 Synth repository on Github.

Coffeebot

Tue, 14 Feb 2017 12:00:00 +0000

Video of Coffeebot In Action

Imagine this tragedy: you get into work in the morning and go to get a cup of coffee, only to finally sip it and find that it is yesterday’s luke-warm spoils. A simple paper solution for this would be to add a post-it to the coffee with the time that it was brewed, but this requires buy-in from the team. A digital solution for this would be an internet connected button that alerts the office when the coffee was brewed, but this does not help people who are physically at the machine. We set out to build a hybrid of these two ideas; a device that would both give immediate information at the coffee pot and also have a digital alert system for anyone waiting for a new pot to be brewed. We call our creation Coffeebot.

Take One

For our first take on this project, we wanted to use our LABS TIME to build a minimum viable product in a few hours or less. Luckily, we had a PARTICLE board in the office which allowed us to move quickly and have both a physical product as well as an internet connected tie-in. Coffeebot’s entire user interface is a screen and two buttons; whenever a new pot of coffee is made, the brewer simply presses a button that corresponds to that type of coffee.

When a button is pressed, it restarts the timer that is shown on the screen and uses IFTTT to post a message to our company’s Slack app. The first iteration was not pretty or polished, but it was adopted immediately thanks to how easy and friendly it was to use.

Refining the Design

The Coffeebot prototype quickly became one of the most used Labs projects in the office. There was only one problem: the mess of prototype wires was unruly and prone to disconnecting. We decided to solve this using our 3D printer and a custom Printed Circuit Board (PCB). We started by designing a simple PCB that would hold the Particle, a couple of buttons, and the LCD. We got 3 copies of this made at OSHPARK for $30.

Next, we designed and 3D printed an enclosure that would hold the finished board. One cool feature of this enclosure is that the buttons are cut out of the case itself. The entire enclosure can be printed as a single piece and can press the buttons on the PCB without needing any additional parts.

While we use this project for tracking coffee, the general concept of an internet-connected screen with four buttons can be used for all kinds of things: a time tracker for work, a Slack responder, or even an automatic Pizza ordering system. If you have any questions feel free to drop them in the Github issue tracker. Happy brewing!

Originally posted at the Smashing Boxes’ blog: link

Opensource.com Article

Thu, 06 Oct 2016 12:00:00 +0000

With my talk coming up at All Things Open, I recently wrote an article about why and how I got started in doing digital art. In retrospect, it is amazing how learning the tools discussed in this article changed the way that I approach software. Huge thanks to Processing, Arduino, and the entire open source community for what they do; I am honored to be a small part of such a wonderful community.

You can check out my article How Open Soure is Enabling the Digital Art Age at https://opensource.com/life/16/10/how-open-source-enabling-digital-art-age.

Elixir Lunch and Learn

Tue, 20 Sep 2016 12:00:00 +0000

I have recently been working on Smashing Boxes’ first Elixir project, and it has been fantastic. As a primarily Ruby shop, I wanted to create a presentation about what the experience has been like so far. Just like my blog, I’ve wanted my presentations to be focused on content over style and tedium, so I’ve switched over to remark.js for my slide decks. A nice side effect of this is that I can share them to a larger audience.

If you use Ruby for web development and are interested in the tradeoffs that Elixir and Phoenix bring, check out the full presentation here and let me know what you think.

Shipping Fraqture

Fri, 20 May 2016 12:00:00 +0000

At SB, we’ve been working hard on shipping Fraqture, our open source art platform. We are happy to announce that it will be on display in the 21C storefront window on Main St. in downtown Durham for the next few months.

Check out my recent post about why and how we built Fraqture, and see our splash page for more info on what will be on display and how you can get involved.

2015 In Review

Fri, 01 Jan 2016 12:00:00 +0000

My 2015 brought a ton of change, and I am very happy with all of it. Using a format similar to Michael Fogus’s, I thought it would be cool to do a roundup of this year using my favorite things produced and consumed. While I don’t track blog reading

2015 In Pictures

The single biggest event this year was getting married to my wonderful partner of over 5 years, Jennifer.

My work situation churned a lot this year, but am happy to say that it was worth it to get to my current position at SB.

After things settled down, we expanded our family with our first cat, Pancake.

Languages Used

Working in three environments this year, I probably used more languages in a single year for production code than I will ever use again. In order from most to least used, they are:

C
Ruby
Javascript
Python
Clojure
Typescript

The winner of favorite language this year goes to Clojure. Right now, I am using it for an art project for downtown Durham and it is a blast.

Favorite Books Read

Mistborn Series. This is definitely top of the list. Mistborn is a fantasy series by Brandon Sanderson in a world where some are born with the ability to turn metals into superpowers. The main characters are wonderful and the story is great.
Shadow of the Wind. Another novel, this is somewhat of a meta-book, a book about how powerful books can be.
Structure and Interpretation of Computer Programs. I’ll admit to only being in Chapter 3 at the moment, but this is where I began learning Clojure. It is a great book to open up and work through a problem or two while having coffee on a weekend morning.

Places Travelled

Istanbul, Turkey. Visited on our honeymoon, and loved it. A great blend between Western and Islamic culture with great food and tons to see.
Santorini, Greece. The more romantic place we visited on our honeymoon. Santorini has beautiful views, sunsets, hikes, and towns. The seafood and white wine here was superb.
Athens, Greece. Athens has a lot to offer in historical terms, but we found that our 4 day stay there was a bit too long. We found Athens to be quite hectic and run down. On the last day we took a ferry to Hydra, which was more relaxing and scenic.
Busan, South Korea. Traveled to Busan for 3 days for the IEEE Sensors conference. It was my first time in Asia, and I really enjoyed it. The city itself was beautiful, with parks and beaches right in the downtown. The food was good enough to where I started fermenting my own Kimchi when I got back!
Nashville, Tennessee. Did a three day trip here for the Fourth of July. We went out two nights in the downtown area, which is a sprawl of bars, each with a different band playing in them. Really great city if you enjoy live music.
Asheville, North Carolina. My favorite area in North Carolina since it reminds me of where I grew up. We went here several times for getaways and with friends.

Conferences Attended

Council for Entrepreneurial Development Tech Ventures 2015 September 15 & 16, Raleigh NC. Presented on a lunchtime panel about data management for the Internet of Things.
All Things Open October 19 & 20, Raleigh, NC. A great celebration of all things open source, from data to organizations. Would definitely recommend folks who are interested in the Open Source community to check this out.
IEEE Sensors 2015 November 4th, Busan, South Korea. Presented on a lunchtime panel about sensor challenges for the Internet of Things.

Favorite Games Played

Heroes of the Storm. As a long time DotA player, this game was really refreshing. Using talents instead of items and having multiple maps where certain characters have more or less of an advantage makes for a much more dynamic game.
Rocket League. I only picked this up at the end of the year, but wish I had sooner. This game feels like what I remember Mario Kart 64’s battle mode felt like when I was a kid: a fast paced, competitive yet fun driving action game.
Puerto Rico. A 2-5 person board game that uses building and economy tactics. Random elements make every game feel different, but do so in a more subtle way that makes it feel more fair than Catan or other games.
Hearthstone. Always need two blizzard games in the list! I played a lot of Magic growing up, and Hearthstone is perfect for playing a quick strategy card game when in a crunch.
Undertale A fantastic little RPG with witty dialog and a battle system that feels like an old platform game. Definitely recommend this one.

Goals For 2016

Keep better track of blog posts and books read
Get one piece of art in a public display
Make a single full-stack site using Clojure
Read Escher, Godel, Bach
Travel to Hawaii

New Blog

Thu, 31 Dec 2015 12:00:00 +0000

New Message, New Medium

I’ve wanted to start a new blog for a while now, and decided to use part of my holiday break to do so. There were a lot of really cool projects on my old site that still get quite a bit of traffic, but I wanted to move from a site where there are 2-3 project posts per year to a site with more frequent smaller posts. I envision it being small tips or resolutions to problems that we as programmers run into on a daily basis.

I also wanted it to be much simpler. The old site looked pretty crowded (there is a search bar?!), whereas the new one uses the clean-blog template to make a very simple but elegant site. I plan on adding more static pages, but love the uncrowded look of the large header and then the article to follow.

The way that I edit content is simpler now too. Originally my old site used pure HTML, but this got tiresome to edit, so I moved over to Wordpress. Wordpress is fine, but when I sit down to write I like looking at a text editor more than a complex interface. For these reasons, I switched over to using Github pages with Jekyll so that I could template in HTML and then write articles in Markdown. It is also nice to work with the full site locally, make changes, and then push those changes to Github when I am ready to deploy. A big thanks to Github for making this so easy!

Before

After

Simplicity is beauty.

USB Business Card Part 2

Mon, 01 Jul 2013 12:00:00 +0000

Link to the source code, schematic, layout, and BOM can be found at this project’s Github page: https://github.com/Carrigan/USBBusinessCard.

Introduction

Since there is already a write-up on why and how I made the business card project, this post will only detail the changes made since the first version. If you would like more information on how this project was made and how it works, please visit the original write-up.

The initial USB business card was a success in the fact that it worked as a functioning mass storage device in a business card form factor. However, it had a few minor problems which were discussed in the first article, as well as some areas that I thought could use improvement.

Changelog

The first and probably most obvious change is that the Molex USB connector was replaced by a few exposed traces on the circuit-board itself. I was against doing this in the original board because of the low quality finish on the boards I was buying. In addition, I had contacted a company which makes a USB connector directly on board to ask about the board thickness they use and was told that a snug fit requires a 2.4mm thick board. It is difficult to find inexpensive 2.0mm boards, let along 2.4mm. Since the board house I used for this batch was a higher quality board though, I decided to try the on-board connector and just use some thickening material on the back to make up for the thickness. I’m currently using three strips of electrical tape on the back of the boards and am happy to report that they have fit every USB port that I’ve tried them on.

Traditionally, the Cortex M3 uses a 10 pin .05″ pitch connector for programming and debugging. This connector can be seen on the original board- it was by far the tallest component on the board. If somebody received this business card, they might be weary about actually putting it in their pocket since the sharp pins could scratch or tear at clothing. While browsing Dangerous Prototypes one day, I stumbled upon a connector-less programming port which had a Cortex SWD flavor, and decided to try it. Using the legless connector allows for very quick programming with a secure connection, and it uses even less board real estate. I would only recommend using this type of connector for proven boards though since you have to hold the pins in place manually while programming or debugging.

Finally, a few minor connection changes were made. In the previous version, you can see a jumper going from one of the resistors to a pin on the microcontroller. I did not fully read the datasheet the first time through, and thus didn’t notice that there was a pin which was sampled at boot-up to determine if the micro would go into an In System Programming (ISP) routine. Because this pin was floating in the original, the micro would boot up into a USB bootloader every time instead of running the program I loaded onto it. A simple pull-up resistor in the new version solves this.

While this project works exactly as intended now, I’m not sure that I want to call it finished yet. The problem is that while this is a nice novelty card, it loses its value to the owner after they have used it since 1MB flash drives aren’t exactly cutting edge technology. I made a smaller project that I didn’t do a write-up on that used the LPC1343 to emulate a keyboard. This keyboard project would randomly send out a caps lock keypress roughly once every two minutes, and then a second caps lock press within a second of the first. The idea was that you plug this device into a friend or coworker’s computer, and they get frustrated with random capitalizations that happen infrequently enough that they wouldn’t expect foul play. In order to integrate this into the next business card, all that would have to be added is a switch or pushbutton that can be sampled on power-up to determine what the board should emulate. I’ve got enough of the current batch to last a while, but look for these in the future.

I hope that this post helps you in whatever USB adventures you go on- I’ve had several people email me saying that they’ve made their own versions since the first post went live. Please let me know if you make (or need help making) your own!