The ides of DEFCON: An Unofficial Electronic Badge

A wearable hardware badge, featuring blinky lights, sound, a sub-1Ghz radio, games, and more. Based on the Freescale KW01.

Similar projects worth following
UPDATE: We're doing a badge for DC27 (2019) - Follow that project here:

Thank you to all of our Kickstarter Backers, we're now sold out on presales but some badges will be available for sale at DEFCON.

We are currently in production manufacturing of our badge. Expected completion July 1.

It will be a wearable game badge and development platform for DEF CON 25 based on the ChibiOS and Orchard (NXP Kinetis/Arm Cortex M0) platform. We are entering the production run soon for DC25 and very excited to

The badge will feature a Roman-based battle game to play

WHO: We're a handful of engineers, artists, and makers from San Francisco, working in security, hardware, software, gaming, and embedded systems.

WHAT: We are building a hackable, open electronic badge for use at DEFCON 25 in Las Vegas. We want to showcase the Freescale platform + ChibiOS, experiment with wireless technologies, and make a fun game for people to play.

WHY: Because we've never done an embedded hardware project in this quantity on our own, and want to learn electronics manufacturing and work more on MCUs.

WHERE: Caseser's Palace, Las Vegas. DEFCON25.

WHEN: July 2017

EXTRAS: We're spending our own time and money to develop this.

We are definitely open and encourage feedback, suggestions, and features.

If you like what we're building and/or have suggestions, let us know.

All of the software, PCB design, and schematics will be open sourced during DEFCON25.

  • 1 × NXP/Freescale MKW01Z128 SOC Arm Cortex-M0+ and sub-1 Ghz Radio SOC
  • 1 × 320x240 TFT Full Color Display with SD Card reader
  • 12 × WS2812 RGB LEDs
  • 1 × 17mm Speaker
  • 1 × 1GB SD card

View all 11 components

  • We're nearly done.

    John Adams06/21/2017 at 23:58 0 comments

    We'd like to share a video with you of Macrofab programming the badges.

    PCBs are done, everything's come off the pick and place machines, and we're doing really well on our schedule. I think we're going to make it.

  • On writing network code

    John Adams05/14/2017 at 06:00 0 comments

    Hello! It's been a couple of months since we've posted here, but here's some fun technical tidbits for you to think about. Our generic postings have moved to out Kickstarter Updates, but I'll try to keep the more technical ones here.

    I've written and rewritten the networking code about five times for the fight game.

    The last attempt, which I am still on now has taken about three weeks of off and on, but very serious critical thinking. What have we learned?

    Well, first off, you should be very grateful that you get to use TCP/IP on the Internet every day. It is a remarkably well designed protocol and has served us well for many years. When you are attempting to recreate the same protocol on a tiny 48Mhz system with barely any stack space or RAM (16KB, OMFG.) you learn to appreciate what you have in your average TCP/IP stack.

    Currently the protocol on the badge could be described much like TCP/IP, minus, well, the good stuff in TCP/IP. We don't have the RAM for sliding window ACKs and generally our protocol is closer to Stop and Wait ARQ. As you may know from your college networking textbooks (I had to go back and read mine), SaW ARQ is very inefficient but can be written with a very small memory footprint.

    Our protocol is "Stop and Wait ARQ, with Time Outs (TO), and a small (four packet deep) Circular TXQueue."

    Writing that was hard, but writing a version that played nice with our graphics was harder.

    Things I would have done differently;

    1) Move packet handling to a different thread. I did it in the game thread, this was stupid.

    2) Written my animations in a way that didn't impact networking.

    Okay, this right here is the #1 reason our badge had problems. Because to do animations I would paint a frame and then do a chThreadSleep() -- Nothing in your device should go to sleep if the same thread is processing the damn network. DO NOT put your thread to sleep, you will drop packets and life will suck.

    3) Written in the txqueue ring buffer in from day one. Only being able to have one packet in the queue was killing us, but needing the queue at all was an indication that Stop and Wait really wasn't Stop and Wait. We needed the txqueue, because sometimes we have to tell one badge more than one thing in a row (i.e. "I have moved, and after you get that understood this game round is over.")

    In any event, we now have some very nice radio networking code that works well on ARM machines. The fight sequences are fast and tight, and for the most part the badge doesn't deadlock anymore waiting for moves. We're still torture-testing the badge though and will probably have a few more sets of changes before DEF CON.

    *Crosses fingers* I think I got it this time.

  • Many problems, but we're getting there.

    John Adams03/23/2017 at 20:06 0 comments

    Our Kickstarter has been incredibly successful, and now that we're sold out, I've got this long, long spreadsheet with about thirty items on it that need finishing. Fortunately, on the hardware side of things, we're about 90% there.

    I spent nearly three days not writing software and revising the PCB. I believe that I've fixed the chip mounting issue, repaired the faulty power switch issue, and rerouted audio and grounds enough to eliminate the popping issue on RF transmit. Hopefully.

    The KW01 is a ridiculous chip. It has non-matching solder and paste layers, via requirements, ground requirements, and all of that is down to four decimal places in mm. Our translation of that data from NXP's Altrium files to KiCad was a disaster, causing bad foot placement and a number of failed connections in production. So, we have to do one more spin. That takes us from 3/23 to April or May, which is not where I want to be production-wise.

    We'll probably engage Macrofab to do most of the programming and assembly work, if we can get parts to them on time and such. At least then if our boards are DOA they can help with rework.

    It is frustrating and unfortunate that I have to do a 3rd prototype this late in the schedule, but it is necessary to ensure a proper final product. At least we will be able to expedite this through Macrofab and possibly get a board back in a couple weeks.

    More updates as I get them.

  • Updates, and our Kickstarter!

    John Adams03/16/2017 at 18:34 0 comments

    The last week has been pretty amazing, and while I haven't been updating here, I have been updating a few other places.

    Rev2 boards came back. one works 100%, the other works

    There appears to be an audio issue on all boards. I am not sure how this happened by I had a cap from the audio amplifier, C42, on the far left of the board over by the RF circuit. That cap should not have been there. When we transmit, we get a digital click in our speaker. Now, you're never going to hear this at DEFCON but it is damn annoying.

    I've moved C42 back to the right side of the board and tore up a pile of vias and traces that were along that path in the hopes that it fixes this issue.

    On the second board, we had a few bad/melted WS2812B's. One was so dead it couldn't pass any signal through DOUT. The other, well, it was just dead. Using the hot air station to rework those parts restored function on the second board.

    However, the second board's pin 49 (DIO) which we use as an RF Interrupt wasn't connected at all, making it impossible to receive packets. I had an excellent phone call with Macrofab earlier today to discuss why the KW01 isn't mounting to the board correctly, and their engineers are going to take a look at the footprint today.

    I cannot recommend Macrofab enough. They have been giving me stellar customer service!

    In funding news...

    I spent quite a few hours making a video and created a Kickstarter with it. That's online now, and KS has approved our page so you can actually preorder the badge on kickstarter now!

    Funding has been incredible. 50% of our funding goal in under three hours.

    Now, obviously, $6,000 is not enough to make this project happen. But, I expect that the badge will sell out and we made the goal purposely low. That's just what you have to do to make Kickstarter go. Low expectations, High rewards.

    This project is actually around $18,000 - $20,000 to make at quantity 225. We'll get there. I know it.

    Thank you all for your support.

  • A delay, and some mechanical things.

    John Adams03/03/2017 at 00:40 0 comments

    Rev2 Update

    It looks like there's been some sort of problem at Macrofab and their pick and place machine (they only have one?!) isn't working.

    We expected to have rev2 of the prototype on it's way to us today but unfortunately it looks as if we will not have our boards on the pick and place until March 10th, which possibly puts our prototype shipping out on March 15th after the fab does some hand soldering on our through-hole parts.

    It's a delay, one that we've padded our schedule for but a delay nonetheless!

    I've tried to reduce the through hole parts as much as I could but they're still on the board. I only recently discovered that I could order 40-pin SMD connectors, so maybe that's an option for another revision. Moving to that means only the speaker would require hand soldering and this could improve the time to produce a board.

    Chinese parts are starting to come in

    We've also received another batch of East Rising screens from Shenzen. I'm very pleased with these screens as they are sharper and have a far more responsive touchscreen than the MCU Friend screens we were using. The best part is that they don't require another set of pins to support the SD card, and(!), they use microSD instead of standard SD. The finished appearance is much more professional and clean.

    Compare the MCU friend (top) with the East Rising (bottom). ER is much nicer.

    MCU Friend (top) vs East Rising (bottom). East Rising is so much nicer . Also notice the EFF supporter logo, activated by secret unlock code!

    Speaking of "ordering parts from China": Batteries have been ordered (ETA 3/28), Standoffs have been measured and a sample has been ordered (ETA Friday), Screens and MicroSD cards remain to be ordered. Mostly, I'm ordering based on a build of 300 units on these parts, assuming that some percentage will fail. Our final unit count will be in the 200-300 range depending on pricing, sponsorships, and part availably. We still need more sponsors. Please help!

    We sort of got screwed on the batteries as the minimum order was 500, so if you get to DC25 and want an extra battery for your board, we will absolutely sell you one if you'd like to buy one.

    How's the game coming along?

    On the software side, I think I've repaired the last deadlock/hanging bug in the fight network code. It's very hard to get the fight to deadlock now, but it still deadlocks once in awhile. I need to sort that out and it's very hard to debug.

    I wrote a new command line interface to edit the system preferences, as well as an unlock screen to unlock special things via secret codes.

    Matt has just about finished the artwork, and it looks really, really good. Now it's up to me to incorporate all of the characters and their respective animations into the game.

    UI Detail for the default badge application. I'm Caesar. Deal!

    What's left on the game now is the leveling system, code cleanups, some UI tweaks, and implementation of all of the magic unlock codes. The UI is there for unlocking, but it doesn't do much yet.

    Bill has also managed to get some very amazing video surprises working, but I'm not going to spoil that just yet.

    I'll have a new update around 3/10 and I hope to have boards by 3/15!

    Thanks for your interest, you're awesome!

  • Spin #2: Electric Boogaloo...

    John Adams01/30/2017 at 07:45 0 comments

    Most of my weekend was spent laying out version two of the badge and working out issues with the USB battery charging circuit. The battery charger works now, and we have a new layout which will probably be much closer to the final version. I like it a lot, it feels nice in your hands, and the shape is modeled on a roman bath, which is entirely appropriate.

    Here it is, minus the screen:

    We've added some buttons for development work (they're only about 8 cents on Macrofab's house part list) and greatly reduced the size of the badge. It looks and feels a bit more like a PS Vita, but who's counting. I consolidated the LEDs as well; On the right side of the screen is a full system debug window, showing status of the charger, UART, Radio, and SD card.

    We also won't be populating those test pins. They're going to be empty for the people in the hardware hacking village to experiment with the device.

    We also discovered that one of the Macrofab boards was NG. An important SPI line was dead on an inner layer of the board, rendering it useless. Oh well. We learned what we needed to learn from our boards and the screen worked well on the other prototype.

    At this point, our goal is to have a new prototype in hand with all of our issues repaired by March 1st. From there, we can make the go-no-go decision for the main production run.

    Bill is still working on a better audio system for this board, possibly with a real speaker instead of the three-channel piezo hack we've got right now. More when we get that working!

  • Prototype: One.

    John Adams01/25/2017 at 06:49 0 comments

    This morning UPS dropped off our first two prototype boards. they're in good shape!

    Initial observation:

    The badge is way too big.

    If we release these things everyone is going to look like Flava-Flav with huge clocks around their necks. Unacceptable. We will redesign. and reduce the size at least 50% from 6.5" down to a respectable 3.5" or so. I drew this thing on a piece of paper and thought it would be fine, but now that it's in my hands I don't like it at all.

    We got most of the badge right (!)

    Nearly all of our subsystems are working:

    • LDO - but maybe we don’t have enough power from USB to run off USB alone. right now the battery has to be there, or we will enter a crazy reboot loop with all LEDs on.
    • JTAG header and programming -- I was really sweating this one but it works.
    • FTDI chip and serial UART console.
    • Power LEDs
    • RESET
    • SD CARD ACT light OK
    • LEDs
    • Buzzer
    • MAYBE: Charging seems to work, but it's very, very hard to tell. I'm going to let it sit for the evening and see if it charges. The status LEDs may actually be backwards.

    What's not working?

    • The external radio clock (Y1) is the wrong part, it should have been a crystal. Instead, we ended up with a powered resonator which will not work at all.
    • The radio circuit is a disaster (but we knew that.)
    • Display, SD, and Touch - Wiring error on PTE19 has caused a massive failure on the display, which is probably not easily fixable. Marking that as not-connected on the board seems to fix our issue for now
    • SCLK - One board is fine, the other board has a dead SCLK line. There is a break, somewhere between the KW01 and the rest of the system. I think Macrofab does continuity testing of their PCBs but I cannot explain this issue at the moment.

    In all, about 18 mistakes to resolve in the next month or so. We'll get there. We even have some audio surprises in store (if we can get them to work.)


  • Spin #1: Mistakes, and bugs.

    John Adams01/19/2017 at 00:43 0 comments

    Macrofab has produced our PCBs and pick-and-place has finished up on the boards. They're now completing some hand soldering, and I have a list of the things that didn't work right on our first spin.

    The tale of woe goes a bit like this...

    1. P2 we got a 20 pin instead of a 40 pin (TODO: New part selection)
      1. For P2, I misread the data sheet, believing that "2 x 20" meant "40 pins". It actually meant "Two rows of ten pins, totaling 20 pins total."
        The data sheet was mostly in Chinese. Ooops.
    2. P1 orientation - need indicator on board for manufacturing
      1. Less of a failure and more of a "Damn, why didn't I think of that." P1 is a tilt-switch, and will work regardless of orientation. However, since the fab house didn't know what to do, this halted production until I could email them with a proper orientation for the switch.
    3. Forgot path for VR_PA
      1. This effectively made the radio dead. No VR_PA, no output voltage.
    4. All Inductors Wrong footprint (1206 vs 0805)
      1. This one, oh, what a massive fail here. All of the radio inductors didn't fit! Since VR_PA was disconnected anyway, I gave up on this and told them to not populate any of the inductors, further ensuring that the radio really would not work when it came back from the fab.
    5. Hashed copper fill problem (on board rev2)

    This last one was probably the most interesting bug of them all. I did the copper pours as hashed-outline fills, tickling a bug in the SVG generation at Macrofab and apparently breaking the PCB preview process. The system "tried to create an SVG file with thousands of lines combined to fill a region." and that's an expensive operation. This was apparently bad enough that Macrofab had to update their KiCad docs.

    I'm glad I could help everyone else with my dumb mistake.

    I expect that I might actually have boards in hand by Friday or Monday. We'll see what else is broken when they show up.

    I also expect that the LED layout will not be to my liking, but I'll verify that when the boards come back.

  • State machine hell.

    John Adams01/05/2017 at 06:55 0 comments

    Our boards are still being manufactured at Macrofab so the last week or so has been an intense pile of work to get the game itself up and running. Our combat system is pretty nice (on paper) and the boards are mostly cooperating.

    Unfortunately, synchronizing two devices on a hostile RF network like the one we will encounter at DEFCON isn't that easy.

    At first our game was working but we'd see the occasional signal loss event, where we would drop a critical message and then suddenly lose track of the entire game. It turns out that the radios, even while sitting next to each other are not 100% reliable. After a ton of back and forth in the code I realized that I was going to have to construct a highly reliably radio protocol in very little memory space.

    This code takes concepts from TCP/IP and works well for automatic retransmission of packets.

    While we don't have the memory to implement something like TCP/IP or lwIP, we do have a limited amount of space to roll our own networking code. The code, on the sending side implements a primitive version of ARQ (the same thing TCP/IP does).

    In a sentence, ARQ is "Keep retransmitting the data until the TTL expires on the packet, or, you get an ACK, or, you get a RST."

    My version is a bit ugly, but it looks something like...

    current_fight_state = WAITACK
    // loop... 
    while (1) { ... 
    if (current_fight_state == WAITACK) {
          // transmit/retry logic                                                                                                                                                           
          if ( (chVTGetSystemTime() - last_tick_time) > MAX_ACKWAIT ) {
            if (packet.ttl > 0)  {
            } else {
              orchardAppTimer(context, 0, false); // shut down the timer                                                                                                                    
              screen_alert_draw("OTHER PLAYER WENT AWAY");
    /* in the radio loop, if we get an ACK, we advance state */
    case WAITACK:
      if (u->opcode == OP_ACK) {
         // if we are waiting for an ack, advance our state.                                      // however, if we have no next-state to go to, then we will timeout                                                                                                             
         if (next_fight_state != NONE) {
            chprintf(stream, "\r\n%08x --> moving to state %d from state %d due to ACK\n",                 
    u->netid, next_fight_state, current_fight_state, next_fight_state);        
            current_fight_state = next_fight_state;     
    On the recipient's end, we ACK inbound requests and advance our state machine, if we have something to do.

    Needless to say, this sort of thing is ridiculously complex and filled with contention, deadlocks, and all of the things you'd expect in a massively concurrent system. It is severely headache inducing and makes me want to break things.

    I hope to have these issues fixed this week.

  • Spin, Spun.

    John Adams12/31/2016 at 11:09 0 comments

    Forgive me Macrofab, it is been a week since my last spin...

    I don't have the rev1 boards back yet, but a careful analysis of our schematic tells me that I blew the entire RF section.

    RF is, well, hard. I misread the reference schematic and didn't realize I'd forgotten to connect VR_PA to the inductors/matching circuit, so I will just assume that any chance of RF output is now lost.

    I also did a few dumb things. I didn't let the autorouter finish correctly and the boards that I manufactured were four layer (2x price) when they could have been a 2-layer board with proper vias and would have been far, far less money.

    Moving a number of our inductors to 0603 and rerouting parts to the back of the boards made 2-layer possible for far less money.

    I'd also forgotten one of the ground fills, our logos, and a bunch of other crap.

    The per-board prototype price is down around $140 now, and our bulk price is in the $30-60 a board range before screens and batteries, so that's great.

    I might even go ahead and try to repurpose our battery as a phone charger, but we'll see!

    At least our boards are looking better, and much more together now.

View all 21 project logs

Enjoy this project?



Vincent wrote 07/20/2018 at 07:12 point

Hi there, it is probably "dead", but is there any chance to grab one?

Missed the campaign unfortunately :( Thanks!

  Are you sure? yes | no

carlfugate wrote 02/09/2017 at 17:59 point

Are you doing any type of preorder for this?

  Are you sure? yes | no

John Adams wrote 03/03/2017 at 03:50 point

Yes, we will post the pre-order as soon as our rev2 prototype is back, within a week or two!

  Are you sure? yes | no

charliex wrote 01/23/2017 at 18:54 point

I'm be interested to hear what your failure rate is with those LCD boards, i'm using them for the prototype badge, and i've got a stack of them that have failed, they're cheap but the seem to break really easily at the bond. some of the alternatives i've found at the cost lack the ability to easily do fast DMA since they're 8 bit parallel with control lines (or at least that i can think up) so i'm sticking with the various ili9341/25/28/8080 variants of these boards that are SPI enabled, i think we're going to go bare LCD, but its nice to have the SDCARD and its tough to find pricing to match the pre mades.

this year will be the first year we're looking to have someone manufacturer the boards rather than hand build 400 boards, so be curious to see how it goes with macrofab, though L1 is for memorial day.

good luck!

  Are you sure? yes | no

John Adams wrote 02/03/2017 at 23:37 point

Quick question, are you using the MCU Friend boards (the red ones, above) or are you using the East Rising boards? It seems like the East Rising boards are much more put together than these ones, which we have already had four of them break or fail after buying 8 or so. 

Your photos seem to show the MCUFriend board. I recommend switching over to these instead (same driver, different pin out, no need to solder the right hand SD card connector)

They have cap touch and resisistive touch, cap is a bit more expensive.

  Are you sure? yes | no

charliex wrote 02/04/2017 at 03:46 point

yeah i get the mcufriends boards for $3.3 each and they are a bit flakey, i'm currently using the 3" $3 board which is meant for the RPI, still working on making it work with the stm32f4

I do have some of the East rising OLEDs and they're great, i ordered one and its got my name written on the board on both halves!

Since i'm building 400 of the boards, cost is  big factor, but these new 3" ones are much better put together.


  Are you sure? yes | no

zaphodbeeblebrox5 wrote 01/05/2017 at 19:30 point

Great stuff, thanks for sharing your experience!

Some notes that might be helpful:
-For most manufacturers, you don't need to merge your drill files...just be sure to provide both files when sending them off for fabrication.
-Not all manufacturers provide house parts, but, it's definitely a question worth asking.  The manufacturer buys those parts at greater volumes, and gets a better price-break, and can then offer them to you at the higher price breaks when you're using less parts.  Most will still not give you the 10,000 piece price when you're only using 10, but, some will give you a bit of price cut.  
-0603 sized parts are generally the best priced on the market at the moment, and have the highest utilization.  0805's are definitely easier to rework, though, if your'e doing it yourself.
-While BGA rework does require customized tools (especially higher pin-counts), it can be done by hand.  There are a couple dozen videos of people reflowing them in toaster ovens on Youtube :)  Also, a good manufacturing partner will let you send the board back to them for reworking if necessary, rather than leaving you out in the cold to do it yourself.
-1206 pricing should be in line with 0805's, mostly.  Unless you're using some strange value parts...avaialbility is generally the same, too.  Of course, YMMV, it all depends on what the part is.  You can use Digikey or Mouser to select parts by package/value, and allow you to compare different prices/availability.  Just because the Panasonic part is expensive and not available, doesn't mean there isn't an AVX part that meets your needs.
-These days, the price of discreet ROHS components has come down to normal levels.  If you see a bunch of available inventory at major distributors that isn't ROHS compliant, it's more than likely end of life product.  Sometimes, the prices will be marked way down in an attempt to move the inventory.  If you're just building a small quantity of prototypes, it's probably ok, but, as you scale into higher quantities, ROHS is going to be the way you want to go.  Most manufacturers can handle both types of processes in their facilities, but, the majority are going to want to stick to one solder/flux chemistry as much as they can.  If you're selling anywhere outside of the US, too, you're going to need to meet ROHS standards.
-Conisgning parts generally gives the illusion of saving money.  Most shops will mark up labor a little more for consigned parts, as they never know what state the parts will be in that you provide to them.  In the case of surface mount parts, most machines want tape to be at least five-six inches long, providing exact quantities means that the assembly house will need to hand install your parts.  This doesn't allow them to take advantage of the economy of scale for machine placement, as well as increases the potential for quality issues.  Hand soldered parts will experience more heat, potentially contributing to reliability issues down stream.  Finally, while shops will markup material that they have to purchase for you (to cover their own overhead involved in doing so), that cost should be less than your time investment to manage your own inventory.  All of that said, sometimes, it is still in your best interest to consign inventory (last time buys, high minimum quantities, contracted parts with manufacturers, etc).
-On the WS2812 that you mentioned specifically...good luck with this part.  There's a note on Adafruit's website that says that the parts "may not be suitable for pick and place and reflow.  We recommend these for careful hand soldering only!"  I've had issues with these parts not functioning after reflow due to explosive outgassing.  Buying parts in China yourself tends to lead you to getting parts that are not properly handled/stored.  In the case of these parts, they are moisture sensitive devices that are regularly not stored in dry-boxes, etc.  Of course, YMMV, I've had very small sets of success with them, and large quantities of issues.
-Keep in mind that when buying parts from China (I'm assuming AliExpress), there's always a chance for failing or counterfeit parts to be sold.  Sometimes, the risk is worth it (I used 10k of an LCD screen one time with no issues), but, be aware that the possibility exists, and that you'll probably want some method of capturing that issue before it's installed into boards.
-Four layer boards are more expensive than two layer boards because they require more material, more copper, and a bit more process control when fabricating the PCB.  However, there are some great sources out there for reasonably priced four-layer boards when the design calls for it.  MacroFab's four-layer price seems a bit high to me, in general, but, it's likely tied to how they manage their assembly process.
-Custom color solder mask is not a cost adder for most board shops, as long as they have the color that you want to use (if they have to order a special color, there may be a bump).  If your'e paying for an adder, someone is taking advantage of people thinking all PCB's must be green.
-I've rarely heard good reviews of KiCad.  Most people that I know who continue to use it do so because they've invested the time into learning it, and don't want to move away.  Eagle is, generally, a much better CAD tool.

Continued luck with your project!  I'm interested in checking back on the due date for your boards from MacroFab to see how things go!

  Are you sure? yes | no

John Adams wrote 01/05/2017 at 09:18 point

A few points here -- 

I do agree with you that the auto-router is full of lies, but what I find is easiest is to manually route the critical sections, mark no-go areas on the board, and then let the auto-router deal with all of the power, ground, and signal lines that I don't care much about where they end up (i.e. digital lines.)

Blue LEDs: I didn't see any in Macrofab's house parts list, but I certainly know they exist in the world and can be purchased. We are tending to use parts on Macrofab's house list so I don't have to pay labor fees for pick+place reconfiguration.

I can solder 0603 but 0402 is going to require that I have some sort of microscope. My eyes are far too old I'm afraid. 

  Are you sure? yes | no

Martin wrote 01/05/2017 at 08:35 point

I consider 0603 perfectly hand solderable, 0402 are possible, but take too long. 1206 wastes too much space :-) I use them only if necessary (higher power, bigger caps). 

But what about the 0603 blue LEDs? I have already used them (bought from DigiKey), so I know they exist, and that was something like 2011 or 2012. Thinking about that I already modified my Nokia Phone with blue LEDs in 0603 and that was well before 2005 (but I got them from old phone PCBs in that case, so I do not know if they were available in small quantities at that time.

Of course place everything before routing :-) 

And regarding your comment about the auto-router. Seriously: Don't use it, especially not in RF circuitry. Of course it is hard work to route >=6 layer boards by hand, but you (or at least an experienced layouter) know much better about the signals and there requirements and criticality levels than an autorouter.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates