Dash & Dot made it to mass production just in time to ship all the pre-orders to our crowdfunding backers before Christmas 2014. The path to get there was quite a journey, as it's quite the complicated toy, but it was a great experience. The full electronics system of Dash consists of 11 PCBs and includes quite the variety of technologies such as Bluetooth LE, a smart battery charging solution (BC 1.2), IR sensing, MEMS inertial sensing, and audio sensing & playback. The brains consist of three ARM M0 devices.

The initial design of the robot was developed by contractors prior to Wonder Workshop (formerly Play-I) raising venture capital and hiring the engineering team (myself included). Two units of the intial design were built by hand for use in demos and promo videos, but by the time we were ready for production, almost every major component from the initial design had been replaced either for improved performance or lower cost.

One of the keys to getting the product into mass production in time for holiday shipments was to get units through all of the compliance testing. Sure, we had to pass FCC testing, and get the Bluetooth SIG stamp of approval, but we also had to get through all the additional testing required for toys. Surprisingly we breezed through FCC and the notoriously difficult tests, but got hung up with the brightness of the blue channel in our RGB LEDs -- that's a story for another time.

I've been purposely vague in hopes that this small teaser inspires a lot of questions and curiosity. Please ask me about my role in the NPI process and lessons learned while getting these robots to market. I promise it will be an interesting conversation.

While I'd never want anyone to believe that writing code for desktop applications is more fun than programming in low-level languages for embedded devices, it's actually not so bad. Far from the land of "branch", "jump", and "W registers", I developed two protocol analyzers which are shipping with our Saleae Logic desktop software. Developed in C++ using MS Visual Studio 2012, the PS/2 Analyzer is my delayed response to an otherwise traumatizing FPGA lab project I had to do as a junior at Penn State.

I was working on a project with a Xilinx Spartan 3E board to interface a PS/2 Keyboard with the FPGA board to accept user input. Unfortunately it wasn't going as smoothly as one would hope, and I spent all night in the lab trying to capture the signals with an old oscilloscope (green CRT display type, not the nice ones available now) and decode the signals by hand to figure out which characters were coming in and how the FSM I implemented was failing to decode all cases properly. I ended up getting it working at 6am, so I instead of sleeping I just went and ate a nice breakfast and then went to classes as usual. Now this was a story of hard-earned success, but the moment I started using the Saleae Logic, I couldn't help but think of how useful the device would have been in this situation, saving hours of my time. When I learned that they hadn't yet released a PS/2 Analyzer, I felt it was my calling to develop it so no student would ever struggle through the same situation as myself. Whether it's because of this analyzer or because PS/2 is pretty much an antiquated protocol, it's fair to say that engineering students are no longer suffering with this same project.

The second analyzer, which is currently in beta, is for the Modbus protocol, which is commonly used with PLCs in industrial control systems. Source code for the PS/2 Analyzer is freely available as part of the Saleae Analyzer SDK, and I anticipate that the Modbus code will arrive in the same place after it matures out of beta and into a production release.

AT GE Advanced Sensors, I was working on an RF embedded sensor product line which was developed in a partnership with Caterpillar. CAT developed and owned the IP (See US Patent #US20120158242 A1) however they were unable to successful develop a success hardware product that passed their own rigorous requirements, so they formed a relationship with GE to bring this idea to market. The RF Soot Sensor was essentially a Network Analyzer with a CAN interface that is able to survive being strapped to the exhaust system of bulldozers, dump trucks, and other heavy machinery for years at a time without affecting it's performance.

The demand for this product was huge, as this RF Soot Sensing technology is much more accurate than the currently used delta-P method. This translates to a 1 - 3% savings in diesel fuel consumption annually on each piece of equipment which has one of these sensors installed, which on commercial mining machinery that is running nearly 24/7, this can be upwards of $10k saved per year. Even the U.S. Department of Energy gave funding to further study this concept with the intent that it could even further tighten the emissions requirements by law since a technology had been developed making it possible. The images above are from one of these studies funded by the U.S. Department of Energy. It also reduces down-time by reducing the number of damaging "thermal events" inside the filter. Anyways, I could spend hours discussing just how useful and game-changing this sensor is, however I must be mindful of the level of detail that I can publish without crossing any lines. Let's just say that many equipment manufacturers knew that CAT had developed something that was big, and they were worried about it.

Three versions of this sensor were created. The first version was a bit rough around the edges and was released on a quick schedule to get CAT several thousand sensors to get out in the field and start proving their IP as well as demonstrate to them that we're able to ship them hardware which meets their requirements. It was at this point that I joined GE and began working on this project. While I came on board after the core product had been designed, I was heavily involved in testing and validation of the PCB. I also designed, built, and automated the test bench used to validate the product to the full CAT spec. I supported the entire assembly line with the automation of their testing and tracking equipment, and also implemented SPC on the production line to provide insightful trends to the engineering team. As GE was interested in learning more about the actual usage of this hardware in regards to engine performance (ie reverse engineering CAT's IP), I also spent significant time in diesel engine test cells and took a SAE's course on Advanced Diesel Aftertreatment Systems.

I hope the lack of specific details in this article will raise a lot of questions, so feel free to contact me so we can further discuss this project and my particular role and accomplishments.

This series of images reflects my work on the new family of products at Saleae. The product has been on the market for over a year now and some customers have posted teardowns in online forums, like this one. From concept validation to production ready form-factor PCB, I owned the PCB layouts from beginning to end. Some highlights of the designs include high-density double-sided placements, blind vias, and USB3.0 SuperSpeed support. I also supported production of the current products, but the real fun was working on the new stuff. The primary differentiator on these products is that they are outfitted with a full analog front end to support 1 to 16 simultaneously analog signals, depending on the model. Be sure to check out our website to see some high-quality images, tech specs, and even order one for your lab.

I also assembled several of the boards myself, depending on our tech's priorities on the day everything arrived. I may not have the hands of a surgeon, but I still somehow managed to place those 0201 components on the board without too much effort. The hot air gun is my weapon of choice when it comes to rework, although a soldering iron with a fine tip will make happy too.

A semester-long project which started with a bare PCB and surface mount components and each week was taken further and further. Week 1 of the project began with learning how to do SMT assembly by hand and reflowing the board on a hot plate, the following week we learned how to do board bring-up and resolve any issues from assembly. We also were able to load a test program to verify board functionality. Then we used the board each week for a new exercise in embedded system design. We wrote the functions needed for USART, then for the LCD, I2C, and for a few others. The board featured a PIC18F MCU but the catch was that we had to complete the project each week without using any of Microchips libraries, everything had to be coded from scratch. The course finished with a personalized project, where I chose to use an accelerometer and an 8x8 LED display to simulate a marble rolling on a platform. You can watch the video here and browse the presentation here.

As an elective, I took an RF/Microwave signals course my final semester. The professor had years of industry experience, working at RFMD before coming to teach at Penn State, and it really paid off. She was able to get RFMD to sponsor the course she was teaching by loaning the university some top-of-line test equipment and getting the department a few seats of Agilent's ADS software. Having access to such an incredible set up, we were able to design and verify our projects. I elected to build a 3-stage Wilkinson divider. This was designed using ADS and then routed using an LPKF mill and then was verified using a network analyzer. It's not often in university that a project is carried out in a manner so similar to that in industry so it was great to do something that was hands-on and with advanced equipment. Unfortunately all photos of this project have been lost over time, but that doesn't make it any less memorable to me.

Another course which fascinated me very much was an elective I took called Biomedical Signal Processing. In this course we focused on learning the various techniques and algorithms used to process common biomedical signals such as ECG (heart) or EEG (brain). For several weeks we focused on how to filter noisy ECG signals in order to accurately detect heart beats. Here's an old lab report from this course that shows exactly what I mean. Then we took that a step further and learned how to process this wave to detect the presence of particular heart problems, such as aortic insufficiency which present as a particular type of heart murmur. Click here to view a presentation I presented on this topic. The course was MATLAB intensive, it wasn't just the theory of how to do it, we were actually doing it, and it was great. And to top it all off, we also built our own ECG device on a breadboard to capture our own heartbeats and process them. This was done by creating an instrumentation amplifier to drive the an ADC input of a PIC microcontroller, which in turn pumped the data over a USART / Virtual COM Port directly into MATLAB for processing with code.

Lastly, Wireless Bike Shifter, which was the capstone project of my engineering degree, was nominated to represent Penn State at the 2010 IEEE Region2 Student Activities Conference being held at Temple University, Philadelphia. There we (myself and two colleagues) gave a formal presentation accompanied with a technical report of our project. We competed against presenters from 16 other top engineering schools and came out on top, taking home first place. This paved the way for my university to host the conference the following year. As a junior I also won a small prize from the Erie chapter of IEEE for my project "FPGA Color Detection".