• The Tale of the Dreaded Infrared Module

    Tuesday, January 21, 2014

    1/21/2014— Jon McKay

    The Infrared Module was designed to be able to interact with the remotely controlled devices around us and has a sort of infamy amongst the team. It had a rough birth and an even rougher upbringing. Maybe one day I’ll be proud of what it becomes, but for now, it’s just the problem child.

    Several months ago, the team had to make a really tough decision. We had initially designed the Ambient Module to be able to transmit and receive infrared (IR) light as well as detect ambient light and sound. This presented two problems: our design was not very modular (infrared communication and ambient sensing are two very different needs) and it was spreading our hardware thin. By jamming all that functionality on to one module, we would have to perform some tricky software engineering feats to make it work, thus increasing the chance we would have bug-ridden firmware and potentially longer development time.

    After several heavy discussions, we decided to split the Ambient Module into two: an Ambient Module for light and sound, and a dedicated Infrared Module, at the risk of not shipping on time.

    This decision committed us to one more module to design, code, manufacture, test, and ship– which, at 14 modules, was starting to reach the capacity of our small team’s brainpower. It was especially upsetting because infrared is not likely to be a popular module and it was taking up more of our time than modules with higher expectations like Bluetooth Low Energy. But in the long term, by splitting the modules, we’ll have two stable modules instead of one (potentially) flaky one and we’re staying true to our mission of making each module with only one particular task that is done really well.

    By December, we were already a little grouchy about the Infrared Module because of time spent discussing its separation from the Ambient Module. I was tasked with writing the code for it and I hoped to complete it as efficiently as possible.

    Whoever designed the Infrared protocol made it rather complicated in an effort to avoid detectors receiving false positives from incoming sunlight (the sun also emits in the infrared band of light). At its simplest, the infrared protocol is turning on and off a modulated signal (see image below) for various amounts of time. An on is known as a “mark” and an off is known as a “gap”.

    source: electronics.stackexchange.com

    But of course, it’s not quite that simple. Every manufacturer (Phillips, Sony, Sharp, etc.) has their own definition for an on/off duration that constitutes a one or a zero. For example, Sharp defines a binary “1” as 315 microseconds of a mark followed by 1779 microseconds of a gap.

    To add to the complexity of all the minor timing tweaks in the protocol from all these different manufacturers, the signal can also be modulated at different frequencies. During a mark, it is actually modulating (switching between on and off) thousands of times a second. The most popular modulation frequency is 38 kHz (36 and 40 kHz are also quite common).

    Our IR module has its own tiny microprocessor, the attiny84, which is responsible for offloading all the infrared transmission logic from Tessel. The Tessel simply passes a modulation frequency and array of marks and gaps, and the microcontroller takes care of the managing the intricate timing required to transmit the signal (thus freeing up Tessel for more important things).

    Fortunately, Arduino has a great IR library written by Ken Shirriff that I was able to adapt for the module pretty quickly. However, testing out my implementation was tricky. The only IR activated device I had in my apartment was an old Sharp television. I needed to find the code that could be converted to its underlying binary representation of 1’s and 0’s, which in turn could be translated into the right on/off durations in order to turn on the TV. But where does one find IR codes? After a bit of Googling, I found a database of IR codes for each manufacturer.

    To my dismay, Sharp has dozens of different codes for different devices, and I couldn’t find a model number anywhere on my TV. The only identifier I could find was an obscure, white code I located on the bottom of the TV remote. I Googled that alphanumeric code, which took me to an Ebay auction item for the same remote, which happened to list a bunch of TV model codes that the remote works with. I found a fairly similar model code (“G1059J is pretty close to G1059SA, right?”) on the infrared code database, and found a power code of “0x00000000000041A2”. I ran the number through the Arduino library and it produced an array of on/off durations (negative numbers are gaps):

    [4011, -3875, 561, -1906, 561, -1906, 561, -1906, 561, -1906, 561, -921, 561, -921, 561, -1906, 561, -921, 561, -1906, 561, -921, 561, -1906, 561, -921, 561, -921, 561, -921, 561, -921, 561, -921, 561, -1906, 561, -921, 561, -1906, 561, -921, 561, -921, 561, -921, 561]

    I hardcoded the array into my module firmware and stood in front of the TV. I don’t think I’d ever felt more pessimistic about a test. I pointed the module at the TV, powered it up to send the signal and… my TV turned on! I really couldn’t believe that it worked. I stood there 5 minutes, rebooting the module over and over again, giggling as my TV turned on and off.

    [Warning: Things get [more] Technical]

    The happiness I felt about that success would soon be outweighed by a devious little bug that infested my code for days. After building out more of the firmware that allowed Tessel to send over the IR data to transmit, I stumbled across an issue when I sent arrays larger than 96 bytes. If I read the array back after sending, it started writing back inconsistent bytes after the 96th. It was always 96. My first thought was that I was out of RAM. I was using the attiny44, which had 256 bytes of RAM, but I was only using up 240 after compilation. Then I thought maybe it could have been an issue with the transmission from Tessel to the module (over SPI): Was I sending data too fast? Was I sending it in the wrong format? Was the interrupt handler infinitely recursing and causing the module to crash? I tested these theories out by saving the byte I was sending over to a temporary variable instead of my buffer and echoing it back in the same interrupt - there were no issues.

    Finally, Kevin was nice enough to put his work aside and give me a hand because he’s worked with the AVR microcontroller family extensively. Kevin was first alerted by how close I was to using up all the RAM with my transmit buffer (240/256 bytes). After poking around in the assembly code, he noticed that when the chip select line for SPI (which tells the microcontroller that data is about to come down the pipe) is pulled low and the corresponding interrupt is called, 19 different registers are pushed onto the stack. The stack grows down from the top of RAM so it was actually overwriting down into my buffer, causing the data to be corrupt (256 - 19 = 237 which overwrites bytes 97-100 of my buffer). To make the fix, we simply upgraded from the attiny44 to the attiny84, which boasts twice as much RAM.

    Now, I’m off to writing the test bench for the module so hopefully we can ship it out this week and I can wash my hands off this module forever knock on wood.

    -Jon

    @jonmckay

    #jon mckay #technical machine #tessel #infrared #ir #module #debugging

  • Costs & Benefits of Beta Testing

    Friday, January 17, 2014

    1/17/2014— Jia Huang

    It’s not uncommon to see “Beta Test” tiers on crowdfunded projects. Before we launched on Dragon, we tested Tessel with anyone we could find. We went back and forth about whether or not we should do a beta test tier. This was around mid August, and at this point Tessel wasn’t usable without a lot of hand-holding, so we were nervous about releasing it early. However, we knew that getting more beta testers would give us greater coverage across Tessel’s features.

    Specifically, with the beta tier we wanted to test:

    • Tessel usage across a longer period of time
    • How easily others can get setup and use Tessel without us being there
    • The way we handle issues
    • Setup experience on other computers/setups

    But we were also concerned about:

    • How much more expensive it would be to manufacture early runs
    • How difficult would it be for us to push breaking changes once Tessels were in the hands of users
    • How much bandwidth we had to support testers. We wanted to be able to resolve issues as they come up, and as a small team, there are only so many issues we can handle at once.

    This was in August and only about 3-4 modules were done at this point. We were on the 4th build of Tessel (we’re up to 14 modules and the 7th build of Tessel now). I was (and still am) afraid of people getting their hands on Tessel without it being fully “ready”.

    We ended up setting up a beta tier that included 3 Tessels and all 14 modules for 1k. Testers would get their Tessels in November or December and modules as we finished building them. We hoped that the price of 1k would be enough to solve most of our concerns.

    • 1k would cover the manufacturing costs of an early run
    • 1k also limits the amount of backers at that level, which means we can handle issues individually.

    Costs

    Now that we’re close to shipping all of our beta tier rewards, I’d like to show where this 1k estimate got us:

    Item Cost per tester
    Tessel v0 194.03
    Tessel v2 195.57
    Accelerometer 8.35
    Climate 13.93
    Servo 15.6
    Relay 14.22
    GPS 29.43
    BLE 29.98
    MicroSD v2 15.0
    Ambient 20.15
    Camera 23.33
    GPRS 25.1
    IR 19.0
    NRF24 9.96
    RFID 21.54
    Audio 13.56
    Shipping Nov 20
    Shipping Dec 40
    Shipping Jan 40
    bad MicroSD round* 10.47
    bad BLE round* 19.31
    bad Ambient round* 12.0
    bad IR round* 18.15
    total cost/tester 807.66

    *During module assembly, we caught a few design errors which resulted in us having to discard parts and PCBs.

    The averaged shipping costs are a little misleading; shipping in the USA is around ~$5-$10, but about $70-$90 internationally.

    I originally thought that a price tag of 1k would more than cover the costs, but it’s actually very close to the cost of running our beta program. And these prices are without paying for assembly, meaning that every time we ship to the testers, there are two of us who spend a day or two in a lab hand-assembling all the modules. The overall assembly time is probably around 70 hours in total.

    Here’s what our shipping setup looks like:

    Benefits

    So far we’ve had around 60 Github issues on Tessel, 20 of which were opened up by our testers, and we’ve closed about half of them. One beta tester even cleared some issues by themselves. Some of these issues were known before we shipped out Tessels to our testers, but having them opened up as an issue by someone other than the team helps us prioritize fixes.

    My biggest worry before doing the beta tier was how much it would sidetrack us from our main development track. As it turns out, all the issues that testers run into are critical issues that we need to fix. Stability is a huge concern, and while we test all builds on our computers before pushing, there are always edge cases out there that we fail to catch. The “nice to have” features we thought we needed to work on are of a much lower priority.

    Having live testers also forced us to put more effort on our debugging and test tools in general. While this takes up more of our time up front, it will allow us to iterate faster in the long run.

    Communication

    After we shipped out units to our first testers, we realized we didn’t really know how to run a beta program. We wanted feedback, but didn’t have many communication channels set up. Our code was on Github, and we just kind of assumed that it would be enough. Issues would just pop up and we’d resolve them on Github just like our normal workflow.

    This ended up being a frustrating experience for both us and our testers, so on the next round that we shipped out we tried to be as communicative as possible. We ended up setting up an IRC channel and being a lot more upfront about how much we wanted to talk with our testers.

    We’ve been getting more success with this approach, but there’s still a lot of room for improvement. If we run a beta program again, I would

    • put more diagnostic tools on the device up front. A lot of communication is just sending back and forth error messages until we figure out what’s happening, and since we have testers in Europe, the time-zone lag takes up a lot of time.
    • give testers an easier way to report issues.
    • have more permanent communication tools setup. Right now it’s a mix of IRC, email, Github and Skype which makes a lot of the information very transient and hard to capture for others that might be running into the same problems.
    • set up expectations of the beta program earlier. Tessel is still very much in beta, and as much as it pains me to say this, getting everything running smoothly is a an exception rather than the default.

    Overall, having a beta program has been beneficial to us, and has helped us reprioritize issues that we otherwise wouldn’t have found out about. This will in turn make Tessel a better product for all of our backers.

    @jia

    #jia huang #jialiya huang #beta testing #crowdfunding #tessel #technical machine #beta tier #beta program #beta #costs #pros and cons #kickstarter #dragon innovation

  • Meta-Post: The Blog

    Wednesday, January 15, 2014

    1/15/2014— Kelsey Breseman

    The value of a company blog

    Keeping a blog takes up a fair amount of time, and it’s not always top of the list when you’re worried about shipping a project. However, I think it’s worth the effort, and here’s why:

    Furthering the mission

    Every company has a mission, and the blog is great for expounding on company values. We’ve used it to discuss our takes on JavaScript, PRISM, and open source. This helps us engage with the people we hope to reach and spread our overall mission.

    Blogging is a particularly useful tool for us in this regard because part of our mission is to help web developers enter the hardware space and start hardware companies. As people with primarily web development backgrounds starting a hardware company, by blogging about what we’re doing and challenges we face, we’re directly furthering that aspect of what we, as a company, are trying to accomplish.

    Personality

    When people talk about companies, they often forget that the company is comprised of people. There are only six of us, and each of us has a different perspective, writing style, and set of interests. The blog gives us a place to speak to the public as individuals, humanizing the company and making us more approachable. A post from Eric looks different from a post by Jon, even on largely the same topic. Reading the blog, you can learn that Jia watches Adventure Time and Tim likes to throw things at her. That’s a really cool thing about startups: we’re not faceless. If you order something, we’ll smile. If you write a mean tweet about us, we’ll see it. If you email team@technical.io, we’ll read it and get back to you. We’re people; we want you to like us, and we want to know what you think we could do better. Keeping a blog helps us show that to you.

    Reflection

    When you’re heads-down shipping product, it can be really hard to poke your head up and look at the big picture. Writing is an excellent tool for reflection. Our blogging schedule is about once every two weeks per person, so every two weeks or so, we have to think deeply enough about something company-relevant to express a written opinion or account.

    Keeping to this post schedule can be challenging, but I’ve found that when I sit down with a teammate to help them figure out what to write, something worthwhile surfaces pretty quickly: “Well, I’ve been working on PCBs a lot.” “We haven’t really talked about our open source mission; most open source companies do.” “I’ve been getting a lot of emails about power management from people.” What are you doing? What are you thinking about? It doesn’t have to be deep, but you should probably have thought about something in the last two weeks.

    Record

    Since we regularly post updates to our blog, we can go back and look at what we were thinking or doing at specific points in time. By reading back through the blog, we can look again at why we were excited about the logo we picked, how we were feeling halfway through our crowdfunding campaign, and watch our ideas evolve over time.

    Consistent presence

    It’s important to communicate regularly with your audience. We email our backers every two weeks with updates so they know how their product is coming along. However, our audience is larger than just our backers, and we try to post to our blog more often than that, and with more varied content. This lets potential customers, investors, our parents, etc. know what our company has been up to recently, just by checking our website.

    Plus, if you don’t keep a consistent presence online (we barely blogged in December), your Klout score drops like a stone:

    Each post drives traffic, as well. Our pageviews spike for an hour or two after every blog post. Every single blog post we’ve published has had engagement on Twitter (sparking new Twitter followers), and gotten Facebook likes. We only use company Tumblr for the blog (it’s not listed on our contact page or anything) and we’re up to 169 Tumblr followers, with new likes, reblogs, and tumblr follows nearly every day. And occasionally, people even email us because they had something to say about something we put on the blog. That’s worth a lot.

    How we keep the blog

    • Editor in chief: I make the blog post schedule. I remind people when their blog posts are coming due, discuss ideas for new posts with them, go over their writing for proofreading and clarity, publish to the blog, and spread the link out to social media. I think it’s a good idea to have one person in charge of all this because it means someone has read all the posts, knows how long it’s been since the last one, and publishes consistently.

    • Team editing: I do the first pass of edits, but the author typically also sends out the google doc link to the rest of the team for fact- and am-I-missing-something checks. This way everybody on the team knows what has been said to the public.

    • Publishing: I publish our blog to our company’s Tumblr, Twitter, Facebook, Google+, and Pinterest. We get some click-throughs from each of these, but depending on the post, Twitter and Facebook pretty much always get the most traction. Tumblr’s reblogs, however, continue to generate traffic even weeks or months later.

    Our blog is now six months old! Here are some nostalgia-links.

    Thanks for reading! As always, please keep in touch.

    Kelsey

    kelsey@technical.io

    #kelsey breseman #technical machine #blog #company blog #company culture #startup

  • Musings on Tessel Two

    Monday, January 13, 2014

    1/13/2014— Eric Kolker

    As we wrap up the first wave of hardware design and push into production, we’ve turned our thoughts to what’s coming next. I’ll leave the discussion of the industry at large to the blogosphere, but continue the discussion Jon started about what comes next from Technical Machine, specifically on the hardware front.

    • Tessel 2 is an enormous opportunity space. We’ve tossed around the idea of
      • A simple update to the board, possibly baking some of the more common sensors (accelerometer/gyroscope, SD card, etc.) into the device
      • A smaller, low power version of the Tessel, probably with two module ports, a lower price point, more limited GPIO, and possibly a different wireless story (BLE, WiFi, cellular data of some kind, etc.). Just for kicks, here’s something we played around with (for the sake of R&D) a while back:
      • A ruggedized version of the board for our friends in industry, on boats, etc. who want to bake this into something highly reliable. We’re talking maybe as far as a waterproof case, dedicated battery, power in up to 48 V DC (AC wall power is a whole different animal), ethernet + POE support, etc.
      • Something for the roboticists out there… My guess is this would include a co-processor of some kind to handle control loops, high speed I/O, an IMU and communication with modern hobby radios. This kind of architecture is common in many robotic systems because pushing the robot’s “reflexes” down to a lower level processor frees up the main CPU to do computationally expensive mission planning while maintaining a more consistent system response to external forces. TLDR: deciding where to fly would take clock cycles away from subroutines that keep the quadcopter airborne if they shared the same CPU.
    • With a little help, many of our modules can be adapted to serve alternate functions. The best example is the Servo module, which can be converted into an LED driver (well, technically we convinced it to become a servo driver in the first place) or used to drive an external speed controller, thereby letting the Tessel control pretty much any kind of actuator you want. On a similar note, the NRF module can fake Bluetooth packets and the RFID module can also be used to transmit.
    • As an analog guy at heart, I’m itching to get some precision instrumentation out there, and a great opportunity just popped up with another project on Dragon Innovation. The Mooshimeter is a kick-ass multimeter that communicates over BLE and uses your phone as its display/controller. We’ll be working with their team to make sure that the Tessel can talk to the Mooshimeter, thereby opening up a whole slew of possibilities in the space of measuring hard to-reach electrical things (and normal-to-reach electrical things too). To give you a sense of the numbers here, the bare Tessel can measure voltage up to 3.3 V with 10 bits of resolution. The Mooshimeter would expand that to 600 V with 24 bits of resolution.
    • The next wave of modules will have to be better and more creative than ever. We’ve already covered most of the bases for “I/O you’d expect from something that talks to your phone,” which leaves, frankly, the more interesting things still on the table. Jon talked about the myoelectric sensor that Kelsey and I played with at Robots Conf, we’ve mentioned the possibility of an IMU and thermocouples, a more advanced camera, passive IR (motion detectors)…the list goes on. I’d love to see what people create with pressure and breakbeam sensors (think laser trip wire), magnetometers, and rangefinders. We’ve tossed around the idea of doing something with MIDI, too…
    • On a less physical level, I’d love to find new and improved ways for people to interact with and design hardware. I wrote a post a while back about my physical toolbox, but part of what I’ve come to appreciate in working on this project is just how far the software tools EEs use have to come. I’ve tried every once in a while to contribute to the growing effort, but there’s still a long way to go. Long story short, I believe that Technical Machine is in a good place to help with this movement.

    At the end of the day, what we do next depends a lot on what we hear from all of you. I’d love to build for the sake of building, and strive to keep my head up in the clouds, at least for a little while, but ultimately we can’t be successful if all we create are beutiful yet impractical tools. Let us know what you’re yearning for (team@technical.io), and we’ll do our best to keep up.

    Thanks!

    ~e

    #eric kolker #tessel #tessel 2 #technical machine #future directions #plans #modules

  • Delivery Schedule

    Friday, January 10, 2014

    1/10/2014— Updates

    A few weeks ago we gave an update that we had put 9 out of our 14 modules in production. Tessel is already in production at the moment, and is due to be done in February.

    We’ll be sending in the rest of the 5 modules into production at the end of this week/beginning of the next.

    Module manufacturing is delayed for a little over a week due to the upcoming Chinese New Year at the end of January (our modules are manufactured in China). This puts the delivery date from our manufacturer around mid-February for the 9 modules that we have already sent in.

    Depending on when we’re able to send in the rest of the 5 modules (audio, BLE, ambient, IR, and GPRS), the delivery date for our Dragon backers will be late February to early March. For pre-orders taken over our website (rather than crowdfunding), unless something unanticipated arises, we plan on shipping shortly thereafter.

    Once the modules are made, they will be shipped to our fulfillment partner Rush Order. Rush Order will begin shipping immediately as soon as they receive Tessels and modules.

    This is about two weeks later than we had originally anticipated shipping to Dragon backers: changed from mid-February to late February/early March. We underestimated how much of a delay Chinese New Year would have in our schedule, but we hope that this will be the last delay we run into.

    Oh, and here’s a picture of 1,500 unpopulated Tessel PCBs, sent to us this morning by our Tessel manufacturer Worthington Assembly:

    Cheers, and please reach out (team@technical.io) if you have any questions.

    Kelsey, Kevin, Jia, Jon, Eric, and Tim

    #tessel #technical machine #delivery #schedule #manufacturing #shipping schedule #backer update #update

July 2017

February 2017

November 2016

October 2016

September 2016

August 2016

July 2016

June 2016

April 2016

March 2016

February 2016

November 2015

September 2015

August 2015

July 2015

June 2015

May 2015

March 2015

February 2015

January 2015

December 2014

November 2014

October 2014

September 2014

August 2014

July 2014

June 2014

May 2014

April 2014

March 2014

February 2014

January 2014

December 2013

November 2013

October 2013

September 2013

August 2013

July 2013