Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

November 18 2011

Top Stories: November 14-18, 2011

Here's a look at the top stories published across O'Reilly sites this week.

Steve Jobs, the Unabomber, and America's love/hate relationship with technology
Steve Jobs and Ted Kaczynski represent the extreme poles of a deep-seated ambivalence in our attitudes toward technology. It's an ambivalence that's been a part of American history, and part of the American psyche, since the beginning.

Understanding Apple fans
AT&T and other carriers are not helping Android, or themselves, by turning a great product into a second-rate one. And maybe I'm getting soft in my old age, but I now understand what Apple fans hate about Android.


Embedded systems are "terrifyingly important"
Author and embedded systems engineer Elecia White discusses the state of embedded systems and what lies ahead (hint: distributed intelligence and microdots).

HTML5 for publishers: Drawing on the screen
This excerpt from "HTML5 for Publishers" shows how a simple finger-painting canvas can be added to an HTML5-based children's book


Why we needed EPUB 3
EPUB3 is more than just bug fixes and tweaks from the last version. It represents a major change in what an ebook can be.



Tools of Change for Publishing, being held February 13-15 in New York, is where the publishing and tech industries converge. Register to attend TOC 2012.

November 16 2011

Why embedded systems are "terrifyingly important"

Engineering embedded systems is an increasingly interesting, disruptive — and lucrative — field for designs ranging from bicycles to firearms to airplanes and beyond.

In the following interview, "Making Embedded Systems" author Elecia White (@logicalelegance) describes how she came to write a defining book on the subject, how she came to learn the practice, and why she came to realize that the future is just around the corner.

Why are embedded systems important right now?

Elecia WhiteElecia White: Embedded systems are where the software meets the physical world. As we put tiny computers into all sorts of systems (door locks, airplanes, pacemakers), how we implement the software is truly, terrifyingly important. Writing software for these things is more difficult than computer software because the systems have so few resources. Instead of building better software, the trend has been to allow a cowboy mentality of just getting it done. We can do better than that. We must do better than that.

What made you write the book?

Elecia White: Years ago at a conference, I sat with several academics as they discussed how to draw more women into advanced computer science (CS) degrees. As I was the only non-Ph.D at the table, they tried out their ideas on me. However, nothing could stand up to the education (and fun) I'd had in my career: making a gunshot location, building DNA scanners, seeing my toys on Target's shelves, and working on race cars. I had seen how projects worked, done some hard math, published some neat papers, and written a few patents. When I said all of this, one of the professors said it sounded like I had a Ph.D. and all I needed was to write a dissertation. My book represents the things I've discovered on my path through embedded systems.

Can you expand on some of your past projects?

Elecia White: People often think that writing software means staring at a computer screen all day. I've seldom found that to be the case with embedded software. Sure, I do get to program code. But there is also hardware, so I get to spend time making the software work on the board as it senses and/or changes its environment. The system is typically in something else (like an inertial measurement device in a race car), so I often get to see how application meets the road.

As an embedded software engineer, I am often in the middle of the system, working closely with both application software and hardware engineers. I get a unique perspective of the whole product. I work with electrical, mechanical, and application software engineers to create a complete system. It makes for a fun, interactive job.

One of my favorite jobs was at Leapfrog, making educational toys. There is more to it than writing software that says, "C is for cat." The software controls the game play, getting inputs from buttons and playing the correct audio. However, if the same responses happen to the same inputs each time, the interaction is awkward. Then we got to add touchpads, motors, screens, and RFID tags to make each toy an interesting, unique product. There — and in the book — I have enjoyed thinking about how to make something fun as well as educational.

Making Embedded Systems — Written by Elecia White, an expert who's created embedded systems ranging from urban surveillance and DNA scanners to children's toys, this book is ideal for intermediate and experienced programmers, no matter what platform you use.

Was being an embedded software engineer even a job when you began?

Elecia White: My degree was a combination of applied CS and theoretical systems engineering. I was just shy of double majoring and designed my degree because those two seemingly different fields interested me. It ended up being the perfect embedded systems major, giving me plenty of software engineering experience as well as a little bit of electrical engineering.

I started my career doing pure software. It was a job, and it paid well. I was kind of bored, but I kept getting deeper into the operating system, writing drivers and getting closer to the hardware. Then I was hired to work on a DNA scanner at Hewlett-Packard (at a division that is now part of Agilent). The manager there was so excited to introduce me to his embedded software team, and he was right. The first time a motor moved because of my software, I was completely hooked. My software could touch the physical world.

However, I was ignorant of electrical engineering. I had no common sense where handling boards was concerned. I could barely read a schematic and then only the analog parts, laboriously working out equations I hadn't used since college (and didn't really need to write the software). I didn't understand how to read a datasheet without getting buried in minutiae. And despite my enjoyment of pyrotechnics, there is something quite horrifying about destroying valuable equipment. (Always know where the fire extinguisher is!) I was extremely fortunate to have some hardware engineers who were willing to be patient with the new kid. Without their support and friendship, it would have been far easier to return to pure software and into the very interesting biomedical software the company was also working on.

Without naming names, can you give some examples of bad embedded systems?

Elecia White: Embedded system software is a cross-disciplinary field, requiring an engineer to have the attributes of both a hardware engineer and a software engineer. However, most of us come at it from computer science or electrical engineering, so we have to learn the other half of the job on the fly. It makes for some interesting compromises.

I was at a company with really smart people who could do amazing things with their algorithm. But they didn't know how to use version control, copying the code to a new directory each time it was modified, proliferating different code bases for various clients. As a software engineer, that memory makes me cringe, but I've seen it more than once.

At one neat little company, when the hardware came back, they couldn't figure out why it didn't work. The board had noise in the data acquisition system. But nothing was built into the software (or hardware) to let them see the data directly. Weeks were spent trying to figure out how the algorithms were broken when they were correct; it was just a simple error on the board. A little bit of good embedded software would have verified the peripherals as soon as the board came back. A better design would have let them record the acquired data so they could see the errors.

The real world is a harsh place. Often, systems will work in a lab, but when they get into the wild, things go wrong. But for one outdoor system, the salt fogs of Boston ate away the electromechanics, leaving only a rusted shell. Needless to say, the software didn't perform as well as it had in sunny, dry Los Angeles.

What's on the horizon for embedded systems?

Elecia White: Jewelry that monitors vital signs. Credit cards that only work when we touch them. Smart dust and nanobots. Personalized learning. Self-driving cars. Science fiction isn't so far away from fact.

Imagine 1991, 20 years ago: almost no one had a cell phone; we used Walkmans (and cassettes!) to listen to music; the Internet was tiny and text-based. A lucky few had big desktop computers, game-playing consoles, or electric typewriters.

No one can deny that computers — and the Internet — have changed the world. But there are lots of things we don't have: flying cars, robot butlers, faster-than-light travel, transporter beams, and cities on the moon. This doesn't feel like the future I signed up for! But if you are one of the more than 100 million people with an iPhone, you have more computing power in your pocket than any 1991-era computer, at a 10th of the cost.

If this is progress, what will 2031 be like? The very goal of embedded systems is to distribute the intelligence from a centralized computer to a smaller widget that can live in your home, on a satellite, in a car, or in your pocket. If a big desktop computer from 2011 can fit in our 2031 pockets, does that mean our smartphones will fit into an earring or disposable microdot?

We may not have our cities on the moon yet, but what we have is amazing. And it just keeps getting better. Who really needs a robot butler to make coffee when you can already buy one that does the far more useful job of cleaning the floors?

This piece was assembled from two separate interviews. The Q&A was condensed and edited.

Related:

Sponsored post
feedback2020-admin

May 13 2011

The secret is to bang the rocks together

"We'll be saying a big hello to all intelligent lifeforms everywhere and to everyone else out there, the secret is to bang the rocks together, guys." — "The Hitchhiker's Guide to the Galaxy," Douglas Adams


Every so often a piece of technology can become a lever that lets people move the world, just a little bit. The Arduino is one of those levers.

It started off as a project to give artists access to embedded micro-processors for interaction design projects, but I think it's going to end up in a museum as one of the building blocks of the modern world. It allows rapid, cheap, prototyping for embedded systems. It turns what used to be fairly tough hardware problems into simpler software problems.

The Arduino UNO
The Arduino UNO.

The Arduino, and the open hardware movement that has grown up with it, and at least to certain extent around it, is enabling a generation of high-tech tinkerers both to break the seals on proprietary technology, and prototype new ideas with fairly minimal hardware knowledge. This maker renaissance has led to an interesting growth in innovation. People aren't just having ideas, they're doing something with them.

Goodbye desktop

The underlying trend is clear. The general purpose computer is a dead end. Most people just want gadgets that work, and that do the things they want them to do. They never really wanted computers. They wanted what computers could do for them.

While general purpose computers will live on, like the horse after the arrival of the automobile, these systems will be relegated to two small niches. Those of us that build the embedded systems people are using elsewhere will still have a need for general purpose computers, as will those who can't resist tinkering. But that's the extent of it. Nobody else will need them. Quite frankly, nobody else will want them.

The humble Arduino is the start of that. The board has multiple-form factors, but a single-programming interface. Sizes range from the "standard" palm of your hand for prototyping, down to the size of your thumb for the almost-professional almost-products now starting to come out of the maker renaissance. Arduino, and its relatives, will be part of everything from wearable versions like the Lilypad, sized and customized to be stitched into clothing, to mobile phone hardware accessories, to specially built boards launched into space on the new generation of nano-satellites built on a shoe-string budget by hobbyists.

Every interesting hardware prototype to come along seems to boast that it is Arduino-compatible, or just plain built on top of an Arduino. It's everywhere.



Maker Faire Bay Area will be held May 21-22 in San Mateo, Calif. Event details, exhibitor profiles, and ticket information can be found at the Maker Faire site.

Things are still open. They're just different things.

There has been a great deal of fear-mongering about the demise of the general purpose computer and the emergence of a new generation of consumption devices as more-or-less closed platforms. When the iPad made its debut, Cory Doctorow argued that closed platforms send the wrong signal:

Buying an iPad for your kids isn't a means of jump-starting the realization that the world is yours to take apart and reassemble; it's a way of telling your offspring that even changing the batteries is something you have to leave to the professionals.

I'm philosophical about the passing of the computer. What we're seeing here is a transition from one model of computing to another. We've seen that before and there were similar outcries for the death of the mainframe, as there has been for the death of the desktop. There is plenty of room for closed platforms, but the underlying trend is toward more openness, not less. It's just the things that are open and the things that are closed are changing. The skills needed to work with the technology are changing as well.

What the Arduino and the open hardware movement have done is made hard things easy, and impossible things merely hard. Before now, getting to the prototype stage for a hardware project was hard, at least for most people, and going beyond a crude prototype was impossible for many. Now it's the next big thing.



Related:


November 19 2010

Complete real-time sleep feedback loop: Zeo device provides raw data

In a radical application of modern health philosophies--feedback
loops, patient empowerment, open data--the
Zeo company
has recently added a new feature to their consumer-priced sleep device
that puts out sleep phase and brain wave data every 30 seconds,
allowing a program to collect the data and act on it to alter your
sleep experience.
One hacker wrote about his program to

wake him during light sleep

in the hope of producing more RPM sleep.
Zeo CTO Ben Rubin told me that other promising applications provide
the sleeper with some audio or tactile stimulus in particular sleep
phases to help the sleeper enter another phase.

The Zeo is a small box priced at $199, which thousands of people have
been using to collect data on their sleep. At the back of the device
is a serial port that was unused up until recently, but that now
outputs the raw data that the Zeo has been using to calculate, store,
and display sleep patterns. Zeo also provides an API that stores and
manipulates data in simple, standard formats such as JSON, and that
lets people derive useful information without even uploading the data
to the web site. But the web site has its value too: the data that
individuals upload each night not only helps them figure out what
might be impeding their rest, but has become a major source of useful
information for sleep researchers.

Rubin recognizes that the Zeo company can't create all the useful
applications people would like to use with their device. Between the
raw data feed and the APIs, he expects to see hackers as well as
professional developers jump into the breach. "In the new wave of
personal biometric devices," Rubin says, "Zeo is the first to really
open up the data and the platform."

October 19 2010

Four short links: 19 October 2010

  1. YIMBY -- Swedish site for "Yes, In My Back Yard". Provides an opportunity for the net to aggregate positive desires ("please put a bus stop on my street", "we want wind power") rather than simply aggregating complaints. (via cityofsound on Twitter)
  2. Getting People in the Door -- a summary of some findings about people's approaches to the physical layout of shopping space. People like to walk in a loop. They avoid "cul de sacs" that they can see are dead-ends, because they don't want to get bored walking through the same merchandise twice. Apply these to your next office space.
  3. OpenBricks -- embedded Linux framework that provides easy creation of custom distributions for industrial embedded devices. It features a complete embedded development kit for rapid deployment on x86, ARM, PowerPC and MIPS systems.
  4. Dilbert on Data -- pay attention, data miners. (via Kevin Marks)

October 07 2010

Health Care 2.0 Challenge announces winners: focus on access to Practice Fusion

In the set of programming
challenges
announced by Health 2.0 a little over two months ago,
Practice Fusion unveiled plans for the first open test of their API.
In fact, according to Matthew Douglass, VP of Engineering of Practice
Fusion, the Practice Fusion API challenge was one of the top
challenges in the series, with over 30 participating teams. The Health
2.0 challenge was partly sponsored by O'Reilly Media and I covered it
in href="http://radar.oreilly.com/2010/07/health-care-challenge-combines.html">blog
last July.

Practice Fusion is one of a growing number of software companies who
attack the appalling lack of electronic medical systems in medicine by
letting doctors log into an EMR online. In other words, this is EMR in
the form of Software as a Service. One key enhancement that
distinguishes Practice Fusion from its competition is an API they
started to offer last summer. One could easily see why this would
interest health care geeks and potential value-added resellers, but
why would this be a competitive selling point to doctors? We will see
in the course of this blog.

The challenge and the response

As I reported in my blog on the Health 2.0 challenge, Practice Fusion
challenged developers not to code up a routine data exchange
application, but to find a way to draw the patient into his own
care--a beacon for progressive health care practitioners, who believe
that patients hold the keys to their own health and need to be won
over to treat themselves. Furthermore, Practice Fusion called for
real-time data entry, which raises the reliability of what patients
report and allow instant gratification.

Developers responded with a plethora of applications with clear uses:

  • An application that lets a user type in his current blood pressure,
    valuable for anyone with heart problems or other risks related to
    blood pressure

  • A mood tracker mobile application that presents a list of possible
    words to describe a patient's mood, useful for people with affective
    disorders

  • An app that lets a patient signal the doctor's office each time he or
    she takes a medication, useful to track compliance and prompt people
    who are disoriented or forgetful (especially useful because a side
    effect of many meds is to make you disoriented or forgetful)

  • An app that hooks into a scale that can instantly transmit the weight
    registered, and sends the weight back to the doctor's office, which
    may well be useful for most of us living in America

And the winner is...

Health 2.0 can't be faulted for lacking a sense of fun, because one of
the six winning applications was a hack in the style of href="http://makezine.com/">MAKE Magazine. Well, being fair, the
submission consisted of two parts, one of which upheld the lofty and
arcane software quest of interconnecting systems, while the other was
a hack in the style of MAKE Magazine.

I know which one you want to hear about, but I'll start with the
interconnection project. Practice Fusion has a patient center called
Patient Fusion to which
patients can get accounts if their doctors use Practice Fusion. But
many people prefer another site such as href="http://www.healthvault.com/">Microsoft HealthVault or href="http://www.google.com/health/">Google Health.


Pete Gordon and his staff at Critical
Systems
wrote a .NET web application to sync data between
Microsoft HealthVault and Patient Fusion. Anyone with accounts on
those two systems will be able to login and synchronize data between
the two PHRs at the application
site
. Authentication is through OAuth for Patient Fusion and
OpenID can be used for HealthVault.

Pete, and the Critical Systems team, will register the application as
a full HealthVault production application by the end of the year; it
is now using HealthVault test servers. But for those so inclined and
unable to wait, they can download the source code and web application
from the project's development
web site on CodePlex
and install the application on their own web
server.

Partly to test the connection and partly just to satisfy an itch Pete
had ever since he started using HealthVault, they then went on to the
hack: hooking up a low-budget body scale to a device that could
transmit the patient's weight to a computer and on to HealthVault. Of
course, sending your weight to the Internet is already possible with
high-end scales, including BodyTrace eScale (another of the Health 2.0
challenge finalists) and Withings. But Pete liked the idea of
providing this capability to people who don't want to purchase the
premium scales.

It's worth mentioning a bit about the winner's background here. Pete
got his degree from Ohio State University in 1997 and was a Java and
.NET developer for many years before happening upon a health care
company in 2007. Deciding that more and more software jobs would
require specialized domain knowledge, he decided to specialize in
health care IT and started a new company two years ago in that field.

Regardless of the motivation for his Escali monitor, the result is not
something most heart patients will wire up on a weekend. Pete chose an
Escali scale he bought for $45, which contains just barely enough
electronics to pick up the information he wanted on a microprocessor.
You can see the results in a video on the href="http://pfsync.codeplex.com">project's web site.

Unable to get the weight directly from the scale's processor, Pete and
his team reverse engineered the scale to figure out the format in
which the processor sent information for display on the custom LCD,
and to detect when the LCD was turned on. A serial port connection
connects their processor to a PC.

With this hack, Pete attracted the attention not only of the Health
2.0 team but of the Escali company, which is considering an upgrade
that will incorporate the functionality into their scales through a
more conventional combination of a Zigbee device and a low-power
802.15 wireless connection.

In the set of programming
challenges
announced by Health 2.0 a little over two months ago,
Practice Fusion unveiled plans for the first open test of their API.
In fact, according to Matthew Douglass, VP of Engineering of Practice
Fusion, their API challenge was one of the top challenges in the
series, with over 30 teams working on submissions.

Another finalist of note

Practice Fusion's Patient Fusion API was also the platform for href="http://www.bodytrace.com/">BodyTrace, another of the Health
2.0 finalists. I talked to Gyula Borbely of BodyTrace about their app
to feed user's weight into the system.

BodyTrace created the world's first GSM-enabled bathroom scale. When
the user steps on the scale, it sends out information instantly over
T-Mobile's network to the BodyTrace web site. No Wi-Fi or Internet
connection is needed, and therefore no technical knowledge or
configuration.

Users can view the course of their weight gain or loss through charts
on the BodyTrace site, or sign up with their account information to
have BodyTrace immediately forward the information to another service.
BodyTrace already has data exchange set up with about ten other
patient record sites, so adding Patient Fusion was fairly easy. Google
Health and Microsoft HealthVault connections are underway.

In addition to giving individuals the encouraging or cautionary data
about their weight over time, BodyTrace is used by health care
professionals, who prescribe the use of the eScale so they can see for
themselves how well their treatment is working. One interesting red
flag that the eScale can help with is a phenomenon that medical
researchers have noticed: people with heart problems tend to suddenly
gain weight in a way unrelated to their eating habits a few days
before a heart attack. BodyTrace is trying to work out a research
study with a major hospital to follow this lead and see what can be
done to intervene with the patient before catastrophe strikes.

It's interesting to note that BodyTrace talked to Practice Fusion for
some time before a partnership before Practice Fusion release its API.
At the beginning, it wasn't clear how they could work together. The
release of the API made the relationship almost obvious. It provided
all the technical answers to questions about merging their products.
And as the next section shows, the API creates a business model for
working together as well.

Distribution and payment

Getting an app out to users requires more than a nifty API; a search
and download function has to be built into the service to actually
distribute the apps. So Practice Fusion has added a function like the
Facebook or Apple iPhone store, allowing doctors to download apps and
then, in turn, prescribe them to patients. The doctor may say, for
instance, "You've been acting a little more manic lately, so I want
you to install this mood tracker and report your mood every day."

The contract Practice Fusion signs with the people offering apps
contains requirements for auditing to make sure the developer respects
patient privacy and tests the app for quality. In addition, a rating
service lets doctors indicate which apps they've found helpful. Apps
have access only to data that they put into the system for that
particular patient.

Practice Fusion is a free service, supported by advertising. Although
developers can charge for apps, Practice Fusion is encouraging them to
offer the apps cost-free. One way to pay for development is to serve
ads on the app, as iPhone developers now can do. So long as patient
privacy is strictly respected, advertising may be a rich revenue
source because the patient indicates the presence of something within
a range of medical conditions merely by downloading the app.

Other potential sources of payment include the sale of accompanying
devices (such as a scale that transmits the patient's weight) and
insurance companies who might see the real-time data feeds as a way to
avoid more expensive interventions down the line.

Real-time data from data living that can stave off crises and lower
costs--that's a pretty good selling point or an API. So while creating
an after-market for their service, Practice Fusion is harnessing
creativity from the field to provide many more features than they
could ever code up themselves, as well as interfaces to devices from
other companies.

Other challenge winners

Six development teams won awards during the Health 2.0 challenge.

Team Videntity won the award for href="http://health2challenge.org/blog/accelerating-wireless-health-adoption-through-a-standardized-social-network-platform/">Accelerating
Wireless Health Adoption through a Standardized Social Network
Platform, sponsored by West Wireless Health Institute. Team
Videntity created a blood pressure meter meeting the challenge to
integrate sensor-derived data with social networks to construct a
personalized wireless health ecosystem.

Team Pain Care @Ringful Health won the href="http://health2challenge.org/blog/team-pain-care-ringful-health/">Project
HealthDesign Developer Challenge, sponsored by Robert Wood Johnson
Foundation Pioneer Portfolio and California HealthCare Foundation. The
team developed a mobile app that allows people with chronic diseases
such as diabetes href="http://www.projecthealthdesign.org/projects/overview-2006_2008/405516c">report
and manage their conditions by sharing data with doctors and
getting real-time advice.

Team Acsys Healthcare won the award for href="http://health2challenge.org/blog/the-health-factor-%E2%80%93-using-the-county-health-rankings-to-make-smart-decisions/">Health
Factor--Using the County Health Rankings to Make Smart Decisions,
sponsored by Robert Wood Johnson Foundation and University of
Wisconsin Population Health Institute. The team built an augmented
reality mobile application that displays Health Rankings information
for the user's county based on a GPS reading.

Team Happy Feet from Stanford University won the href="http://health2challenge.org/blog/move-your-app-developer-challenge/">Move
Your App! Developer Challenge, sponsored by Catch and HopeLabs.
The team created an app that encouraged people to walk, jog, run,
cycle, or even ski, by providing inspiration through activity
tracking, sharing statistics with friends, and earning achievement
points.

The winner of the href="http://health2challenge.org/blog/blue-button-challenge/">Blue
Button Challenge, sponsored by Markle Foundation and the Robert
Wood Johnson Foundation, will be announced on stage at the Health 2.0
Conference. The challenge asked teams to develop a web-based tool
that uses sample data from Centers for Medicare & Medicaid
Services (CMS) or the VA to help patients stay healthy and manage
their care.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.
(PRO)
No Soup for you

Don't be the product, buy the product!

close
YES, I want to SOUP ●UP for ...