• GPRS (2G) Module

    Monday, January 27, 2014

    1/27/2014— Eric Kolker

    GPRS

    Hey Tesselators, Eric here.

    The GPRS module has been both a ton of fun to work on and prompted its fair share of headaches, so strap in: this post will feel a lot like the one I wrote a while back about debugging the RFID module.

    What’s that acronym?

    No shame, I had to Google it too. GPRS stands for “General Packet Radio Service,” but most people know it as a GSM (“2G”, if you will) cell connection. Devices with a GPRS radio can interact with the outside world via SMS, voice calls, and even TCP/IP. Besides enabling you to essentially build your own phone with a Tessel, the GPRS module keeps the Tessel connected outside the range of WiFi. It’s one of the Class B modules we added as a stretch goal during our crowdfunding campaign on Dragon Innovation.

    As with many of our modules, we borrowed much of the design of the GPRS module from an open source product sold by Seeed Studio. The first task, as usual, was to adapt the Arduino shield so it would play nicely with a Tessel. The biggest difference we had to overcome here had to do with the power requirements of the different components.

    Power work is never over

    Most devices you run into these days are either 5V or 3.3V. For instance, Tessel is a 3.3V device, most Arduinos are 5V devices, the RaspberryPi is a 3.3V device, etc. Taking a step back, when I say that something is an x V device, that usually means that it takes x V between its power in and ground to turn the thing on and that all of its I/O pins can tolerate a maximum of x V. In other words, if you don’t give it a high enough voltage on its power pins it likely won’t turn on (I/O may still work when driven at a lower voltage,, but check the datasheet and look for the term “logic high”), but if the voltages are too high then you run the risk of destroying the chip, or, in EE jargon, “letting out its magic smoke.”

    The chip at the center of the GPRS module, the SIM900, however is neither a 3.3V device, nor a 5V device, nor even a 1.8V device. Instead, it’s some weird hybrid of…most of those. In a nutshell:

    • The I/O for the chip is all 2.8V. This means that the pins don’t like anything higher than 2.8V coming in.
    • The chip will run off 3.2V to 4.1V. Anything higher or lower and it will try to protect itself by shutting down. As it turns out, these values play very nicely with LiPo batteries, which typically hover at around 3.6 V.
    • Last but not least, the module generally has a rather high current draw (on the order of 50mA when idle), but behaves more like a sinkhole when transmitting and can draw peak currents of up to 2A.

    The reason the last two bullet points are so important has to do with conservation of power (summarized poorly here). In so many words, the basic idea is that some devices, when pushed beyond their limit, will conserve power (in this case, P=IV) before they give up completely and shut down. In the context of the GPRS module, this means that when we transmit and the module’s current draw spikes, the voltage drops. SIMCOM, the part’s manufacturer, knows that this will happen; the graph below is from the datasheet:

    This is chart tells us a few things:

    • If the power supply rail for the GPRS drops below 3.2 V, even for some very short amount of time, then the module turns itself off.
    • If the total drop in voltage is more than 300 mV, then the module turns itself off.
    • We should expect peak current draw up to 2 A.

    If we’re running the GPRS module off the Tessel’s 3.3 V rail, then we only have 100 mV of wiggle room before the module shuts down.

    Bathtubs 101

    Before we go any further, here’s quick refresher on the E&M for capacitors, mostly in layman’s terms/in the context of household plumbing:

    • When electrons hang out on a node (the place where two or more electrical components meet), we say that charge has accumulated on that node. Charge has units of Coulombs ©, but is denoted with a “Q”. If you like, you can think of charge as a number of liters/gallons of water at a particular point.
    • Current, which is measured in Amperes (A) (or, equivalently Coulombs per second) but denoted with an “I”, is the flow of electric charge from one node to another through a component. You can think of it as the flow rate of water through a pipe.
    • Voltage, measured in Volts (V), is the difference in electric potential between two nodes, or the capacity of charge at a node to do useful work. Think of it as water pressure.
    • Capacitance, which has units of Farads (F), is the ability of a body to store electrical charge. Capacitors are the components we use when we want capacitance between two nodes. Within the hydraulic analogy, they behave like tanks with a stretchy, impermeable membrane down the middle.

    When a capacitor charges or discharges, it follows the formula:

    In English: current flow into a capacitor as a function of time is equal to the size of the capacitor multiplied by rate of change of the voltage across the capacitor with time.

    Where were we?

    Recall that we’re trying to be able to survive the theoretical worst-case scenario: a 577 microsecond, 2 A pulse, with a voltage drop less than 0.1 V. At first pass, a likely easy solution might be to simply add more capacitance to the power rail. We know I(t) and can calculate dV(t)/dt, so we can solve for the lower bound of acceptable capacitances:

    As it happens, a capacitor that size would have a lot in common with a T-Rex: it would be enormous, completely impractical, and ugly…not to mention hard to find and expensive to purchase. There must be a better way.

    Success!

    The best answer turns out to be 4-12 V of external power and a buck converter that turns the supplied voltage into a ~3.5 V rail for the SIM 900, instead of enormous capacitors. Buck converters are a subset of switching converters, which harness the properties of inductors, diodes, transistors, and capacitors to generate a higher or lower voltage.

    The buck regulator we threw on is good for 3 A and ~4 - 12 V in. The datasheet is here, if you’re curious.

    Alright. It’s time to stop talking about woes of EE land and show you the fruits of our labor! The modules for our Beta backers look like this (without headers or the antenna):

    And, of course, proof that this thing works:

    That’s me on the Tessel phone: a Tessel + GPRS module hooked up to my laptop sending me texts, receiving my texts, and making/receiving phone calls. It was a good day at the office.

    If you want to see (or hear) for yourself, send me an email with your number (US only, please) and a project you’d like to build with Tessel. I have a batch of 16 boards to test this morning; might as well make use of them.

    Thanks!

    ~e

    e@technical.io

    #tessel #technical machine #eric kolker #gprs #2g #electrical engineering #phone calls #tesselphone #tessel phone #tessel texts

  • Updates: Manufacturing and Testing

    Wednesday, January 22, 2014

    1/22/2014— Updates

    Tessel

    We got a batch of 50 Tessels from our manufacturer this week. We will test them before we give the go-ahead to start on the rest of the production run.

    Modules

    It is taking us longer than anticipated to finish up the test rigs and send the rest of the 5 modules into manufacturing. Unfortunately, this delay runs into the Chinese New Year, so our manufacturer will be taking the next week off. This will probably delay delivery beyond the amount mentioned in our last email. We’ll let everyone know by exactly how long when we get dates from our manufacturer.

    BLE

    Our BLE module is a system on a chip (SoC) that runs its own firmware, separate from Tessel. We were able to write a programmer for it so that Tessel will be able to update it without a proprietary debugger. This means you will be able to select different Bluetooth Profiles to load onto the module. If you have a Windows machine, you’ll even be able to completely customize your profile with BlueGiga’s development tools (look out for a tutorial on that topic!).

    GPRS

    We did another revision of the GPRS board to make it a bit smaller. Here it is sending us a text message:

    IR

    A few months ago we announced that we were splitting IR from the rest of the ambient module. The change took us longer than anticipated, but here’s the new IR module:

    And here’s Jon testing it with a tv remote. Earlier, he tested from across our shared coworking space– a distance of probably around 30 ft.

    Upcoming Events

    • 1/27 Cambridge, MA– Kelsey is speaking at Rough Draft Ventures’ sketch “Women in Technology, Now and Next”. Free tickets.
    • 1/28 Cambridge, MA– Tim is speaking at Cambridge Hackspace’s “Hacking your idea into a business”. Meetup link.
    • 5/28-30 Amelia Island, FL– Some or all of us will definitely be at JSConf. Tickets.

    One more thing…

    We were nominated for Postscapes’ Internet of Things awards– we’d appreciate if you’d vote for us!

    Here’s to our final push,

    Kelsey, Eric, Jia, Tim, Jon & Kevin

    #tessel #technical machine #updates #modules #infrared #gprs #text from tessel #bluetooth #ble #production #manufacturing #testing #update

  • 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

August 2018

January 2018

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