In June 2011, Perceptive Development sponsored a Cal Poly Computer engineering robotics course. The students developed mobile applications for their robots and used the Arroyo development board designed by Perceptive Development.
Perceptive Development sponsored a table at the annual Cal Poly Computer Engineering banquet held on June 3, 2011. The Cal Poly, San Luis Obispo Computer Engineering program is highly regarded for the quality of the education and demand for the program’s graduates. Performance Technologies’ Jim Medeiros serves as the Chair of the Industrial Advisory Board (IAB) for the CPE program and is a graduate of Cal Poly. The event includes recognition of student academic excellence as well as student recognition of excellence within the CPE faculty. Held at the scenic Inn at Morro Bay, the banquet is a relaxed and fun event that celebrates the conclusion of the academic year. Earlier in the day, the Spring meeting for the IAB was held on campus. IAB members listened to the progress within the program for the 2010-2011 year, met with new incoming Cal Poly president, Jeffrey Armstrong, and provided feedback on the curriculum. The IAB is composed of a variety of companies, including Intel, Microsoft, Boeing, Xilinx, Cisco, St. Jude Medical, Second Site Systems, UCSB, Swedish Royal Institute of Tech, Chevron, Raytheon, Hitachi, Agilent, Lockheed Martin, Western Digital and JPL.
I have a philosophic theory I have been testing out for some years in my attempts to detect technology trends.
My theory is simple: Anything that makes communication more “telepathic” and instantaneous will be wildly successful. Cases in point are mobile phones (call anyone any time), and more recently Twitter and Facebook, tracking the minutiae of our lives and sharing them to all those who care, in real time. It was only recently while trying to grok the contours of the current mobile payment revolution that I decided to try this theory out on commerce.
Payments still have too much “friction”, too many steps. In a hypothetical world, the ideal commerce transaction would be you think “I want an ice cream” and you’re suddenly holding one, the flavor you wanted. Whatever you owed for that would also be instantly exchanged as well, i.e. your accounts would be debited.
Low-Friction Transactions
App stores, virtual goods stores in general, have reduced the “ooh I’d like an app/song/whatever” to a couple of clicks, maybe a password.
Paypal has done a pretty good job of making *online* payments seamless. Still too many clicks for me (always making me re-log in, asking me in a 3 page wizard if I really really want to buy this) but for the most part, it’s seamless; I want it, I click it.
Amazon’s one-click, as ‘obvious’ as some people try to make it out, was quite an inspiration – I want it, let me indicate my desire and be done with it.
Cash vs. Credit vs. Online Currency
Here’s where some worlds need to meet. I work in an office and often times my colleagues will grab me lunch. I then of course owe them $10 or so. I rarely have cash on me, because I believe that it is the 2nd decade of the 21st century and that the future where I can just carry a card should be here already. Alas, taxicabs and split tabs have convinced me that I can’t get away from cash.
I’ve often thought “Oh I should just pay my friend back with Paypal.” But I don’t. Why?
1) For small transactions, they will literally nickel and dime me or my friend. I don’t feel like paying percentage points to hand someone $10. Have you ever played PayPal ping-pong? It’s a cynical game where you and someone else can send money between each other, back and forth, until PayPal fees destroy all the value. Try sending someone $0.10 cents (I haven’t recently, but last time I did it swallowed the money). It was worse than playing the slots.
2) My friend can’t spend the PayPal money on lunch the next day! There’s a difference between money in your pocket and money online.
Online currency is not as flexible.
It’s not like cash is better because we’re a nation of tax dodgers and we’re trying to keep the IRS from knowing about our under-the-table garage sale transactions. The problem is that digital, token-based ‘e-cash’ only works in the rarefied online universe. Sure, you can get a PayPal debit card that links to your account – I have one, but I don’t carry it around so I can buy my lunch.
Smartphones to the Rescue
Mobile phones are already making almost everything instantaneous and telepathic. The next logical step is exchange, the ability to instantly own things, and the ability to instantly exchange for things.
Here are some use-cases I’m looking forward to on my phone:
1) No-fee monetary exchange between individuals who are proximal: I can hand you $10 by pressing 1-0-0-0-send and holding my phone near yours. Poof, money’s yours. End of story.
2) Cross-vendor money exchange between individuals remotely: I can send you $10 without money handler fees. I send it from my phone number to yours.
3) Paying vendors with my phone. This is the hard-fought evolution we’re hearing so much about – near field communication – that will remove just a few more steps from the purchase process.
Being able to accept credit card payments with a mobile phone is the most popular stopgap solution and will continue to expand until NFC and other effortless mobile payment techniques are fully deployed. Plastic will be around for some time.
Closing the sale
Instantaneous, minimal effort transactions have a lot to do with increasing sales.
Exchanging money with the phone is not something that we want just because it’s cool, or because technologists want to put everything into a phone (even though those reasons are probably why it’s happening.) The reason it’s important is because anything you can do to remove the friction, the steps, the chances for the person to change their mind or do it another way, removes barriers to their (trans)action.
People change their mind. People are inertial. And when it comes to spending money, people aren’t always that rational. From a sales perspective, if you can get people to literally wave their hand (with a cell phone) and “poof, it’s theirs!”, you’ve solved a key part of the problem of sales.
Exchange of goods and services is really a form of communication, a basic form of human interchange. So anything that reduces the barriers to that exchange should take off like wildfire.
Lots to do!
Well we managed to get our blogs back over from the old blog system into WordPress along with our site refresh. Several people have been looking for the links related to the iPhone Hacks book and have no fear – we’ve mostly restored them. We’ve re-posted the blog entries, and now we just need to fix the relevant landing page.
Thanks for your patience. Here’s a graphic that perhaps somehow will make it all right…
-damien
I’ve had several questions about this – there’s a nice page under “Apps” that lets you directly manage the documents loaded into individual applications on the iPad.
I hope the new version of iBooks does it this way as well, because you can add PDFs without doing a full iPhone sync.
You’ve downloaded Tin Can and got it running on your iPhone (or iPod touch 2G). Works great. But maybe you’ve had the sneaking thought (or perhaps more like a bright idea) that Tin Can might be able to talk to more than just another iPhone. But how would one go about this?
Tin Can uses a fairly simple modulation and coding scheme with a few different modes. If you’ve been following this blog, you’ll know that Tin Can uses frequency-shift keying (FSK) to modulate an audio signal. This means that it uses a sine wave that alternates between two frequencies to represent a binary signal, one frequency representing a ’0′ (LOW) and the other representing a ’1′ (HIGH).
(Image courtesy of Wikipedia, distributed under the GNU Free Documentation License.)
On top of the FSK-modulated signal, Tin Can uses a standard serial protocol, with a start bit, a series of data bits and finally a stop bit. One LOW bit indicates the start of a byte, then follow eight bits of data, an optional parity bit and then a HIGH bit to indicate the end of the byte. It uses a HIGH carrier signal in between bytes to indicate that no transmission is taking place.
In addition, the standard data transmission protocol uses an initial byte 0xFF to initiate a transfer. That is, to transmit the sequence “Hello”, you would send 0xFF, then ‘H’ (0×48), ‘e’ (0×65), ‘l’ (0x6C), etc.
There are two basic speed modes that Tin Can uses: high speed and low speed. The specs for each are:
Low speed
LOW frequency: 800Hz
HIGH frequency: 1600Hz
Data transfer rate: 100 baud
Brief carrier tone before each transmission (HIGH)
1 start bit (LOW)
8 data bits, LSB first
1 even parity bit
1 stop bit (HIGH)
High speed
LOW frequency: 2666Hz
HIGH frequency: 4000Hz
Data transfer rate: 600 baud
Brief carrier tone before each transmission (HIGH)
1 start bit (LOW)
8 data bits, LSB first
1 even parity bit
1 stop bit (HIGH)
So how would one use all this data?
To receive data transmitted from Tin Can (for example, with a computer or another type of device), you will need to begin by demodulating the signal. There are a number of ways to do this, from as quick and dirty as simply counting zero-crossings to as refined as a full signal analysis. However, the best method — if you have the processing power — is probably to use a DFT (discrete Fourier transform), most efficiently implemented on a computer as an FFT (fast Fourier transform). These techniques can be found in any basic text on signal processing. Signals and Systems by Oppenheim, Willsky and Nawab is a good starter text. A full FFT gives you a full spectral analysis of the signal, which is overkill since you are only interested in two frequencies (the HIGH and LOW frequencies). (A custom DFT optimized to measure the strength of the two frequencies only could be designed for this application, saving processing power.) The basic technique is to establish which frequency is coming in without picking up noise, so the reading at a particular frequency must be sufficiently strong that it is certainly a signal and not just background noise or a fluke. There are a few methods of determining whether you have an actual signal:
Once you have your frequency analysis working you can move on to reading bits. The idea here is to sample the signal with a period equal to the data rate (for example, if you are reading a signal transmitted at 100 baud you would sample a bit every 1/100 of a second). You should measure enough data each period to be able to perform the analysis listed above and thus be certain of the frequency you are receiving.
When reading the serial data you will need to watch the signal and look for the carrier tone, which will be a longish period in the HIGH state. When you receive a start bit (LOW for one period), you then read eight data bits, one parity bit and, finally, a stop bit (HIGH for one period) to indicate the end of the byte and confirm that you are synced with the signal. (If you are not synced you will need to discard the byte and start again, as something has gone wrong — possibly a noisy signal.)
The parity bit exists to evaluate if there has been data corruption. Even parity means that the number of ’1′ (HIGH) bits in the data (including the parity bit) is even. If you count the ’1′ bits and it comes out odd, you have a data error. If you have a data error you should drop the byte (and if your custom protocol is sophisticated enough, ask that it be resent).
Since the protocol used by Tin Can always sends 0xFF as the first byte in a transmission, you must wait for this byte to come across before beginning receipt of the transmission data.
Sending data is somewhat simpler than receiving data. The same principles apply, but you don’t need to deal with the complexities of signal analysis and establishing whether you are reading a real signal — or just noise.
The first thing you will need to send data is a sine wave generator. These are fairly simple to design if you are a proficient programmer or engineer, and there are numerous standard libraries that will do it for you.
To send bits, you simply set up two sine wave generators, one at each frequency, and alternate them on the signal output. You should make sure, by adjusting the phase of the generated sine waves, that the boundaries are smooth where you switch from one frequency to the other. Otherwise you will end up with glitches in your signal that add noise and can result in data corruption.
Once you’ve got bits transmitting properly, simply follow the protocol specification given above and you’re home free. Precede each byte with a longish carrier tone (HIGH) for synchronization, then pulse LOW for one bit period to initiate the byte, send the eight data bits followed by the parity bit, then pulse the signal HIGH to end the byte.
To calculate the parity bit, count up the number of ’1′ (HIGH) bits in the byte you are sending. If it is odd, set the parity bit to ’1′. If it is even, set the parity bit to ’0′. The idea is to make the total number of HIGH bits, including the parity bit, even.
And be sure to precede each transmission (a block of data bytes) with the byte 0xFF.
This concise summary should give you enough information to talk to Tin Can. I hope you come up with some great uses for it!
If you haven’t already signed up, it’s not too late! Friday, May 15, at 10AM we’re doing a webcast (using WebEx) where we answer questions from the audience on advanced hacking.
Click here for more info: http://broadcast.oreilly.com/2009/05/oreilly-week-in-review-2009-05-25.html
Hi there.
Have you checked out Tin Can yet? If not, you should head over to our main site for the iPhone App here:
Well, for those of you that do have Tin Can, but don’t necessarily have another phone available right now, we’ve created some test files for you to use with your home computer. You can get those here:
We recommend you plug in some headphones to your computer and use these files similar to how we describe in the Setting Up the iPhones section on the site.
This file also includes both high speed and low speed mp3 files, so make sure you check the settings properly in Tin Can while testing them. You can read more about the different features at the Tin Can site.
Note: For those of you who have also picked up the book iPhone Hacks, these files are NOT compatible with the app described in the book. When working on Tin Can, we decided to change the operating frequencies.
The iPhone Hacks book is available in bookstores everywhere as of April 2009. Click on the image to go the O’Reilly website.
This page contains links to source code, addendums, and other materials related to the book.
Download the full hack materials here:
Book Content in single archive
If you would prefer to just grab a specific hack, here are the files.
Individual hacks:
Hack 12.16 – Control the Physical World with an iPhone
You’ll also want:
iPhone Source code (with both the Serial Modem code and Keyboard code):
If you’re planning to modify the firmware for the Serial modem and keyboard hacks, you’ll want the project files that are used with the Cypress PSOC Developer Studio:
Serial modem firmware project files
Keyboard firmware project files
April 4, 2009 – We also created a second, improved schematic after the release of the book that includes the IR hack, the serial modem, and the keyboard hacks:
