• Building Mono on a BeagleBone Black (Hard Float) posted on 03 Jan 2014

    I performed this on Ubuntu Saucy 13.10 from ARMhf (running from an 8Gb SD card)

    1. Launch a terminal window/ssh into your BBB
    2. sudo apt-get update
    3. sudo apt-get install mono-complete git automake libtool
    4. Wait a long time (hours)
    5. git clone git://github.com/mono/mono.git
    6. cd mono
    7. git submodule init
    8. git submodule update
    9. ./autogen.sh --prefix=/usr/local --enable-nls=no --with-sgen=yes --with-xen-opt=no --with-ikvm-native=no
    10. make
    11. Wait a long time (hours again)
    12. Ignore the errors and hope they don’t mean anything
    13. sudo make install
    14. Wait some more
    15. Ignore the errors and hope they don’t mean anything

    Post based off of: http://neildanson.wordpress.com/2013/12/10/building-mono-on-a-raspberry-pi-hard-float/


  • RAZR HD Maxx Teardown posted on 10 Oct 2013

    A friend accidentally ran over his RAZR HD Maxx, so I rescued the motherboard and tore it down!

    I wasn't too kind when removing the RF shielding, so the copper is torn off in a few places.

    View image for full resolution.


  • Why the PhoneBloks phone will never happen posted on 13 Sep 2013

    It's a physics issue. Signals in modern devices are extremely high speed; the easiest and cheapest way to combat this is to bring components closer together. For example, the wireless radios, RAM, and processor in all modern phones exist as one chip. They essentially put the CPU and wireless magic on the same silicon die (or on a separate die in the same package) and pop a RAM chip on top ("Package on Package").

    It's a communication issue. All of the ICs in a phone don't communicate over a single bus - almost every one ties directly into specific processor pins. This would restrict block size and placement.

    If we aim a little lower and try for a modular design, the interconnects needed to ensure signal integrity at high speed are still very expensive. This project would require serious economies of scale to succeed. Each high speed component - CPU, RAM, storage, modem - would need an expensive socket.

    Technically, the storage could be put on a socket pretty easily. It's not fast enough to warrant a very expensive socket, but would still add ~$2-5 to the final design. (Keep in mind, that means the consumer would be paying $4-20 extra, just to have the option to upgrade the storage.)

    It's an interoperability issue. Going a little further, even if the device could be built in some fashion - there isn't much standardization in this area. I've spent days wrestling with a display peripheral on a processor to get it to interface with a specific display or video input IC - and that's with the benefit of thousands of pages of documentation, a field application engineer on call, and a ~$15000 oscilloscope. The amount of effort in testing and debugging that would be required to ensure the compatibility of each component would be absolutely enormous.


    All of that said, I think the modular idea is excellent and could be done right - maybe not with blocks as described and - optimally - not with electrical signals. I could see it happening with optical interconnects, but we're a few years out from that. On chip optical interconnects are still in research, but there's a lot of money being put into them. Intel has demonstrated some very impressive optical tech that should come to market within the next five years. Eventually, we may be able to tie ICs together through optical traces for extreme high speed communication.

    Finally, the stated motivation for this design is to reduce electrical waste. The best way to do that in the short term is to ensure devices are more repairable. An emphasis on user-serviceable batteries would make a significant difference in how long our devices remain useful without adversely impacting their cost or limiting their design.

    It's worth noting that the smartphone market is starting to mature. Phones aren't improving by the massive leaps and bounds that they were. The technological differences are trivial - few people notice the difference between a 1GHz and 1.2GHz processor or 1GB and 2GB of RAM. Now, the main thing that separates generations of phones are millimeters of extra display space, grams of saved space, and milliamphours of extra battery life.

    One major driver of phone sales right now is software. This is where the problem lies, not in hardware. Users need the right to unlock our phone modems and bootloaders. Unlocking the modems to allow use on different carriers would give used phones a wider market. Unlocking bootloaders would let users completely replace the original software, adding improvements and features to otherwise uninteresting devices.

    We definitely have an e-waste problem - and I give this person credit for thinking outside the box - but this isn't the solution we need.


    One source, because I'm lazy: IFIXIT


  • Abandoning the EFM32G210F128 Breakout posted on 28 Aug 2013

    I'm officially abandoning my Energy Micro EFM32G210F128 breakout. The design files are all on Upverter and are released into the public domain.

    Energy Micro has microprocessors with native USB, so there's no reason for me to continue working on a design that needs an expensive USB-UART converter. This is a straightforward case of subpar research and some flawed reasoning coming to bite after the design work has been completed.


  • Personal Development posted on 13 Jul 2013

    Earlier this week, I returned from an eight day visit to Toronto, Ontario. I'm from rural New Jersey and, though there are some 'population centers' near me, there isn't anything like a three million person city.

    In some ways, the visit was scary - this was the first time I've ever heard someone get mugged. We ran outside to see what was going on, but there wasn't anyone around. We didn't know what had happened until the police stopped by later to ask questions. Yikes, that's new.

    At the same time, the visit was an amazing experience. The amount of things going on in the city is outstanding. I've never seen a spectacle quite like the Pride parade, nor have I slept in a house so close to a city block full of shops, coffeehouses and interesting people.

    Alright, so I didn't meet many people outside Upverter and friends. I plan to though! That's where my apprehension comes in - I'm a quiet, introverted guy. I stumble over my words sometimes, and I get pretty nervous when more than two people I don't know are listening to me. Giving knowledge, opinions, and speculations to others - using your voice - is one of the most profound facets of the human experience, but it scares the hell out of me.

    I can't say why. Maybe it's because my smoker voice sounds funny. Perhaps it's that I get too distracted trying to pick the right words to keep speaking. I don't really know, but I really don't care. I don't need to understand why I'm bad at socializing to become better at it. Not really.

    I'm going to become a better socializer by tour-de-force. I'm usually the type to grab a book and analyze every passage in an effort to absorb every last bit of information. Not this time - sure, I've done some reading about socializing and such, but I know enough to know I need to approach this problem from a different angle - I need to put myself right in the middle of situations I know I won't be comfortable in, because that's what it's going to take. Sure, I could read all about my problems, but no amount of reading is going to teach me to think on my feet. Nothing I read will help me remember the helpful little facts I wish I could contribute to a conversation. Nothing at all, except for braving the weather and surviving the storm.



    George Hahn.



  • Why I Want to be an Engineer posted on 08 May 2013

    Term paper for a generic Intro to Engineering class.

    Should I be an engineer? Surely this is a question every student wrestles with at some point. Many who ask it may decide not to become engineers. While it may be a tough decision for some, it's a given for me. I love designing, analyzing, building, and testing systems. I thrive on tough situations – there's nothing that gets my brain going quite like a malfunctioning circuit or a buggy piece of software.

    I embarked on the path to becoming an engineer early in life. It began with taking things apart – as a child, I would disassemble anything I was given the chance to. At eleven, I completely disassembled the old laptop my dad had given me so I could replace a noisy fan. When I put it back together, the fan had been silenced and my laptop was lighter by a couple of screws – but it still worked!

    I owe much of my inspiration in recent years to my past – and only – employer. An entrepreneur and engineer himself, he once told me that he used to have a keen interest in bird watching. Once he knew all of the birds in his area, he got bored and moved on to electronics. He hasn't gotten bored yet. I have never had an interest in bird watching, but I certainly have never gotten bored with engineering.

    My boss also taught me the importance of moving the status quo. When I started working at his company, I was given the freedom to work on a number of extremely interesting projects. As time went on, rather than working on important projects that would have an impact on our industry, my time was spent on menial projects that were barely related to my area of interest. When I proposed new projects that would move the company forward and set them up to have products to sell in ten years, they were shot down for being too ambitious, too complicated, or too expensive. When I quit four months ago, the company was scrambling to piece together a prototype that was strikingly similar to something I proposed almost two years before. They were hopelessly behind the industry and will release one or two product iterations that are painfully expensive and time consuming. Even then, they'll probably never catch up. The lesson I learned: move early. If you wait for the market to tell you what to do, you'll always be behind. Sometimes you can succeed by fulfilling a market's obvious demands, but to truly make a difference you have to be the one who reads the cards and takes the market to the next level.

    A desire to move the status quo is why I'm hoping to intern at Upverter in the coming months. They're a small Candadian startup doing work in the electronic design automation (EDA) space. While the product they're creating isn't essential yet, it has the potential to change how we design and test electronic systems. This is no easy goal, but for something that could transform the EDA market before this decade is out, it's worth the effort.

    Engineering is not for everyone, but it is everything for me. I find engineering intriguing, exciting and fulfilling. If I have changed the world by the time I die, I will rest easily. I do not ask to be remembered and I care little if my name stays around, but I want to leave the world a better place than it was when I entered it.


  • How We Can Fix Intro to Engineering Courses posted on 02 May 2013

    Intro to Engineering courses are a necessity.

    Most Intro to Engineering courses are useless.

    Intro to Engineering courses exist to help engineering students get a job after college; to help students bridge the gap between academia and a career. The problem with these intro courses is that they can't evolve quickly enough. Engineering is changing, but the courses haven't caught up.

    Now, here's how we can fix them:

    • Stop using the old textbooks. I don't care who wrote it or when it was written, an Intro to Engineering course shouldn't focus on one text.
    • Start using social media. Assignment idea: Have students contact someone in the industry that they respect with as many questions as they can fit within a tweet. Of course, allow those without Twitter accounts to attempt an email contact.
      • Contacts are everything, right? Teach students how contacts are made in the modern world.
    • Industry mags and blog posts from experts are important. If a class must contain 'summarize and respond' assignments, let students pick articles or posts they care about. The quality of their responses will instantly improve.
    • Presentations are important, powerpoint is not. Don't put artificial slide count requirements on presentations, this only reduces the number of good slides in a presentation.
    • Focus on solo presentations. There are times when presentations must be given as a group. Even so, when learning public speaking, working as a group can be extremely stressful and provides little return. Don't force students to work with a group, especially on their first few presentations.

    PS: I'll write a post detailing what was wrong with the Intro to Engineering course that I took later on. I am publishing this post first because I'd rather focus on things that can be improved rather than rag on things that are broken.


  • Converting LMDE into Debian Testing: Results posted on 25 Apr 2013

    Yesterday, I replaced the LMDE entries in my sources.list with entries for Debian Testing. Then I ran a dist-upgrade.

    685 upgraded, 10 newly installed, 1 to remove and 0 not upgraded.
    Need to get 581 MB of archives.
    After this operation, 32.8 MB disk space will be freed.

    I'm not sure exactly how long the process took, but it was done within a couple hours. When I came back to my laptop, all text was invisible. This problem went away after a reboot.

    I haven't removed all installed mint packages yet, and I plan to stay with Cinnamon. As such, everything feels quite the same. In fact, I'd have a hard time pointing out any changes at all. The only significant thing I've gained from this endeavor is the knowledge that my packages will now be more up to date.


  • Converting Linux Mint Debian Edition (LMDE) into Debian Testing posted on 24 Apr 2013

    Linux Mint Debian Edition is built on Debian Testing. After months of dealing with flaky mirrors and a not-so-impressive distro, I decided it was time to flip the switch. (Other than Cinnamon and/or MATE, Mint doesn't offer much.)

    I am going to attempt to perform an in-place switch by modifying my sources.list. We'll see how it turns out - either it will work, or I'll be installing Debian Testing later tonight.

    I generated a new sources.list from http://debgen.simplylinux.ch/.

    Old sources.list:

    deb http://packages.linuxmint.com/ debian main upstream import
    deb http://mirror.metrocast.net/linuxmint-debian/latest testing main contrib non-free
    deb http://mirror.metrocast.net/linuxmint-debian/latest/security testing/updates main contrib non-free
    deb http://mirror.metrocast.net/linuxmint-debian/latest/multimedia testing main non-free

    New sources.list (for x86-64)

    deb http://ftp.us.debian.org/debian testing main contrib non-free
    deb http://ftp.debian.org/debian/ wheezy-updates main contrib non-free
    deb http://security.debian.org/ wheezy/updates main contrib non-free
    # Third Parties Repos
    # deb-multimedia.org
    deb http://www.deb-multimedia.org squeeze main non-free
    # Oracle VM VirtualBox # Don't care to have right now.
    # deb http://download.virtualbox.org/virtualbox/debian wheezy contrib non-free

    I'll check in later and let you know how it goes!


  • Bridging Upverter and OSHPark posted on 14 Mar 2013

    Upverter is the best online circuit creation platform, and OSHPark is one of the best circuit board production services. Put the two together, and you should find bliss - but you won't. Anyone who has had an Upverter-designed board built by OSHPark will be familiar with this problem. When you download gerbers from Upverter, you get a zip full of files like bottomcopper.ger and toppaste.ger. OSHPark, on the other hand, wants names like Bottom Layer.ger and Board Outline.ger.

    Here are the name transformations - each pair consists of the Upverter name followed by the OSHPark name. If a file isn't listed here, it should not be uploaded to OSHPark.

    var filepairs = new TupleList<string, string>
     { "layers.cfg", "layers.cfg" },
     { "hole.ger", "Drills.xln" },
     { "mechanical_details.ger", "Board Outline.ger" },
     { "top_copper.ger", "Top Layer.ger" },
     { "top_silkscreen.ger", "Top Silk Screen.ger" },
     { "top_solder_mask.ger", "Top Solder Mask.ger" },
     { "bottom_copper.ger", "Bottom Layer.ger" },
     { "bottom_silkscreen.ger", "Bottom Silk Screen.ger" },
     { "bottom_solder_mask.ger", "Bottom Solder Mask.ger" }

    I wrote a quick C# command line app to do the transformation automatically. If you drop a Upverter zip onto the app, it will create an osh_ zipfile using the OSHPark naming conventions.

    You can find the source and the binary at https://bitbucket.org/George_Hahn/upvertertooshpark.

    BONUS: Create a shortcut to the binary in the %APPDATA%\Microsoft\Windows\SendTo directory! This will allow you to right click on an Upverter zip and choose Send to: OSHPark!