I’ve been thinking for some time now that the smartphone has achieved a kind of singularity, becoming a black hole that sucks all portable electronics into itself. PDAs – absorbed. Music players – consumed. Handset GPSes – eaten. Travel-alarm clocks, not to mention ordinary watches – subsumed. Calculators – history. E-readers under serious pressure, and surviving only because e-paper displays have lower battery drain and are a bit larger. Compasses – munched. Pocket flashlights – crunched. Fobs for keyless locks – being scarfed down as we speak, though not gone yet.
This raises an interesting question: what else is natural prey for the smartphones of the future? Given my software interests, one low-hanging fruit that seems obvious to me is marine AIS receivers. If the frequency of any of the RF receiver stages in a phone were tunable, writing an app that would pull AIS data out of the air wouldn’t be very difficult. I’ve written a lot of the required code myself, and I know where to find most of the rest.
But in an entertaining inversion, one device of the future actually works on smartphones now. Because I thought it would be funny, I searched for “tricorder” in the Android market. For those of you who have been living in a hole since 1965, a tricorder is a fictional gadget from the Star Trek universe, an all-purpose sensor package carried by planetary survey parties. I expected a geek joke, a fancy mock-up with mildly impressive visuals and no actual function. I was utterly gobsmacked to discover instead that I had an arguably real tricorder in my hand.
Consider. My Nexus One includes a GPS, an accelerometer, a microphone, and a magnetometer. That is, sensors for location, magnetic field, gravitational fields, and acoustic energy. Hook a bit of visualization and spectral analysis to these sensors, and bugger me with a chainsaw if you don’t have a tricorder. A quad- or quintcorder, actually.
And these sensors are already completely stock on smartphones because sensor electronics is like any other kind; amortized over a large enough production run, their incremental cost approaches epsilon because most of their content is actually design information (cue the shade of Bucky Fuller talking about ephemeralization). Which in turn points at the fundamental reason the smartphone is Eater-of-Gadgets; because, as the tricorder app deftly illustrates, the sum of a computer and a bunch of sensors costing epsilon is so synergistically powerful that it can emulate not just real single-purpose gadgets but gadgets that previously existed only as science fiction!
So I think the tunable-RF capability I want for my AIS receiver app won’t be long in coming to a smartphone near me. At which point, of course the smartphone will eat not just AIS receivers but personal radios – and another two segments of the consumer-electronic industry will disappear down the singularity’s maw. But this is a good thing; it’s even, dare I say it, environmentally sound. My cellphone is smaller and lighter than the shelf-full of gadgets it replaces; fewer atoms serving more of my needs means lower impact from manufacturing and less stuff going into landfills.
I specified “personal” radios because radios have something in common with personal computers; their main design constraints are actually constraints on a peripheral stage. For a computer you’ll be using for hours at a time you really want a full-sized hard keyboard and a display bigger than a smartphone’s; for a really good radio, the kind you supply sound for a party with, you need speakers with resonant cavities that won’t fit in a smartphone enclosure.
Digital cameras are another diagnostic case. The low-end camera with small lenses is already looking like a goner; the survivors will be DSLRs and more generally those with precision optics too large and too expensive to fit in a phone case.
These two examples suggest Raymond’s Rule of Smartphone Subsumption: if neither the physics nor the ergonomics of a gadget’s function require peripherals larger than will fit in a smartphone case, the smartphone will eat it!
UPDATE: Added calculators and cameras to the hit list.
UPDATE2: More: Flashlights! Fobs for keyless locks.
I think the next low-hanging fruit is your wallet. My family pictures are already on my smartphone. There are already application that allow for (supposedly) secure financial transactions. Now I just need my smartphone to include a quality pocket knife, pliers, and some projectile self defense mechanism, and my _pockets_ will become obsolete.
Additional gadgets already eaten: dictophone, low-end point-and-click cameras (Raymond’s rule applicaton: pro cameras requiring bug sized optics won’t fit into smartphone), spy cameras, post-it-notes.
Next low hanging (partially eaten) fruit: Remotes of all sorts and sizes. Car key fobs.
In the spirit of Eric’s post, recievers for baby monitors. Which are just over-specialized overly cute low quality radios or poor video recievers :)
I worked for a company named Steinbrecher in the 90s. Steinbrecher was one of George Gilder’s darling companies, and we actually had field trialed a cellular Base Station that used a SDR (Software Defined Radio). I’m surprised that 15+ years later the technology has not become more universal. Apple is to be commended for pushing the envelope on their latest product, but it demonstrates the complexity involved in supporting multiple RF frequencies, antennae and ‘ugly bags of mostly water’.
I’ve been using a programming language called LabVIEW written by National Instruments for over ten years now. One of NIs directors named Hall T. Martin follows and blogs about SDR. I read his blog just so I can stay up to date on the progress of SDR and technology related to LabVIEW and NI.
His blog is definitely worth following if you are interested in the research and development of SDR and CR (Cognitive Radio). His blog is named “Emerging Technologies for Virtual Instrumentation” ( http://emertech.blogspot.com/ )
Bring on the Octocorder!
Keys (car keys, house keys, office keys, terminal login keys).
RSA SecurID fobs
Monitor (by adding pico projector)
Keyboard (by adding laser surface projection/IR touch detection)
Car telemetry (post accident fault analysis)
Car dashboard (or an enhancement of, I use a GPS speedo already)
Id card/Driving licence/etc
Given that these things are generally more security sensitive, they need a model where:
a) All data can be remotely disabled when device is lost
b) All data is immediately restored when a new device is recovered
Not sure where iPhone stands on that, but the android model is already pretty close there.
I’d have to disagree when it comes to watches. Sure, I see plenty of people doing without a watch these days. But for me, the glance down and quarter turn of the forearm is enough of an efficiency win that a smartphone will never replace the wristwatch for me.
A buddy of mine had a private RSA algorithm on his Palm V to access his home computer remotely, back in 2001.
Hm. Bluetooth is a standard on smartphones these days, and the Nexus one allows more than just headset connection.
So any kind of metering or sensor device that can transfer data via bluetooth would be able to hook into it. An “All in one” device is great for curiosity, but dedicated sensor devices will be superior, and always need a way to get data back to the user quickly and easily.
An idea… what about adding an IR sensor? Technically, the camera chip extends into the IR range, but they put IR filters over it to block that. An in-ear temp. probe costs 20$ off of Amazon. And adding that sensor/capability to the smartphone would be cool.
Adding a second camera with a filter that only lets IR wavelengths through would be cooler. Toss up an IR picture that’s been color mapped to temperature on the screen.
Jim T, I like the idea of car telemetry, and really, it should be possible. They have kits for displaying what the car computer is seeing, change that to a blutooth and have your phone do the translating instead.
I’m slightly horrified by Greg’s suggestion that your phone become an e-wallet. I’m very suspicious as to the robustness of the security in any electronic device (Spaff’s dictum that the only “secure” computer is one that’s turned off – and possibly buried in concrete – absolutely, positively applies here).
That said, Europeans have been playing around with using cell phones as e-cash for years, for example using your phone to buy a soda from a machine. Wave your phone, get a coke. With bluetooth and the right software, this would be trivial.
But back to security – how hard would it be to turn your Android phone into a cash collector? Just walk down a crowded street, taking $1 of e-Cash from each person walking past you.
The only problem with this is that for some environments, smart phones are too smart.
As an example, I stopped carrying or wearing a watch when I got a Motorola RAZR phone, because the outside LCD displayed the time (and the phone itself had alarms). The problem with this is that the phone also has bluetooth and a camera, which means that there are secure areas where I cannot carry the phone, leaving me without a watch. I’m going to have to go back to carrying a pocket watch…
It would be very hard, because an e-Cash app isn’t going to just give up money to any Tom, Dick, or Hank that asks for it. It is going to require you to confirm the transaction in some way.
I’m not saying there isn’t room for shenanigans here, just that before I trust Aunt Tillie with an e-Wallet app on a phone, I want the security to be thoroughly vetted. I want Bruce Schneier to say he likes the protocols, which must be open to allow lots of researchers to test different attacks on them.
For starters, a vending machine that accepts e-Cash should be designed to visually display (aurally for visually-impaired) a string (most likely including the vendor’s e-Cash account info, machine serial number, YYYYMMDD-hhmmss, transaction amount, and a hash of the preceding) that is also sent to the e-Wallet via Bluetooth/WiFi (or whatever short range wireless protocol emerges as a standard for such things) so that it can be displayed by the e-Wallet app on the confirmation screen. That way, I know that I am authorizing the $1 for that bottle of ice-cold Snapple in the machine in front of me, and not for J. Random Cracker’s benefit.
Come to think of it, all the information in that string could easily be encoded, along with quite a bit more, into a 2-D barcode that your smart phone would simply scan via its camera, then it would display the transaction info on the screen and ask if you wished to authorize it. That way you’d have to have line-of-sight to the vending machine, literally making MitM far more difficult. Your scenario completely collapses if the smart phone has to see the barcode before the transaction is allowed to proceed.
Your personal security settings would determine how many hoops you’d have to jump through to perform the auth. I might have mine set to let me buy that Snapple just by pressing the [YES] on the screen, but if the purchase price is over $5, I have to put in a short password. If it’s over $50, I need a medium-sized password….
And that’s just someone who isn’t a security expert spitballing. By the time the Schneiers of the world have had a chance to address it, I’m sure I’d be cool with Aunt Tillie having the app on her phone.
Yep. I made the same observation about the same time my wife got her phone and remarked about it to her. The reason was I was going to eventually get her a new point and shoot digital camera to replace her old 4 megapixel Fuji Finepix, but I had no longer needed to do that because the camera on her phone was better than the dedicated camera she’s been carrying for 3 years.
We discussed that and the conversation went towards GPSes — we had planned on buying an in-car GPS like a TomTom, but that didn’t turn out to be necessary either, because the EVO is pretty good at that, too. The more I kept thinking about it, the more I realized that dedicated devices weren’t necessary for anything that will work in smartphone-sized device. Other things that should be obvious:
* digital voice recorder (someone else said “dictophone”, which is not quite the same thing)
* etch-a-sketch (don’t laugh — I know at least some of you have spent hours with one of those!)
* compass
* flashlight (yes, there’s an app for that)
* video game console (given enough graphics capabilities)
* walkie-talkies (there’s an Android Market app for that, I think)
* someone mentioned keys: blackberries already do this; they have an IR transmitter in them and real estate agents are using them to open lock boxes. I have a friend who’s a real estate agent and needs her Blackberry for that reason. I could see this becoming used in hotel rooms — a revocable key for your smartphone.
* newspapers (obvious!)
* coffee maker (just kidding!)
Assuming the smartphone is small enough then you can add the “fitness GPS” to the list of gadgets. You just need a way to attach it somewhere where you can see it while running/cycling and the right app that uses the existing GPS and timers to display speed, elevation, distance etc.
You can also add the video cam to the list of gadgets as well. Though, as with still cameras, it will depend heavily on the smart phone. The HTC Hero I had for a while had terrible optics even though it claimed to be good.
Software radios are currently (as I understand it) a bit too bog to fit right now – but that’s not a problem that will last once someone decides it is worth doing for a mass market
I have the flashlight app in my phone and it’s surprising how often I use it. Sure, it’s harder to hold and aim the light source than a real flashlight, and not nearly as bright, but the advantage of already being in my pocket is huge.
Can’t find the light switch? Trying quietly do something (find your keys, undress for bed) near a sleeping person? Want to briefly look at something in a dark movie theater or under a desk? Your phone is usually more convenient than going to find a real flashlight, and with the flashlight app I have, you can even change the color to say red to avoid night blindness.
I may have to get one of these smart phone gadgets sometime. AT&T despairs of me ever using my phone upgrades. Perhaps by 2012 data plans will be reasonable in price, or reception good enough that I can replace my cable modem with a tethered ‘droid.
I’m not so sure that the manufacturers are going to be handing you general-coverage RF receivers anytime soon. If anything, the RF front-end chipsets are getting more monolithic, and they’ve been getting more, rather than less narrow on their frequency design ranges. This allows for good performance in the ranges they’re supposed to operate in, and often there’s bandpass filters for those ranges, helping prevent front-end overload and whatnot.
Additionally, for a device that small, for a general coverage receiver, you’ll be able to fit almost no filtering inside the case. Before the SDR fanboys jump down my throat, those wunderkind DSP routines for filtering are great, assuming your ADCs aren’t getting swamped due to RF overload. Physical filtering and selectivity helps get you that, and you let the SDR stuff handle the rest. I suppose if you want to head back in the direction of brickphones, we can do this. :)
It’s not in the best interests of the carriers or the manufacturers to design a RF front end that’s non-specific or not optimized for the job at hand. Apple’s recent fiasco with the stupid antenna design of the iPhone 4G should be proof of that.
As someone who has carried around plenty of small radios over the years that have large receive ranges, and plenty of small radios with specific frequency ranges and missions, I’ll take the specific ones.
> I’m slightly horrified by Greg’s suggestion that your phone become an e-wallet.
They’ve been doing this for years in Asia. Japan and the Philippines, especially.
Here’s three I’ve already used this morning: thermometer, barometer, ohmmeter.
And how about a voice recorder that not only records the present conversation but simultaneously uploads it to a secure location?
We should stop calling them “smartphones”, and start calling them “jeejahs”, a term from Neal Stephenson’s novel “Anathem” used as a catch-all for personal electronics.
In other smartphone news…
Apple announced today that they are going to give a free bumper for people who bought the IPhone 4.
There’s an iPhone app that (badly, but it’s a start) measures distance sonically – sends a clickstream from the speaker and charts the time it takes for the echoes to come back. There’s also one for colorblind people (me) that helps you tell what colors you’re looking at. Both of those seem pretty sci-fi to me.
BTW the iPhone has come with a “Voice Memos” app for a long time now. Seems to work OK the few times I’ve played with it.
I must disagree with the statements about watches and (the possibility of) e-book readers being consumed by smartphones.
On watches, there’s already the mentioned convenience of being able to simply glance down to tell the time rather that pulling out your phone. I must add though, smartphones could be a possible advantage due to automatic clock synchronization (including timezone and DST settings), but this only really hurts the market for _really_ cheap watches. I’ve got a Casio Wave Ceptor which automatically syncs the time with the United States’ WWVB radio signal; I’ve got to manually set my timezone, which often happens automatically with phones, but this isn’t a very common occurrence to really make a good case to use a phone instead for telling time.
As for e-book readers, the lower power consumption and larger display definately come into play, but I believe you missed out that e-paper is simply easier on the eyes to read on. It simulates real paper to a large enough extent that rather than projecting any light directly into your eyes, it just uses natural light around, reflected like normal paper, and I personally find it much more pleasant than staring into a smartphone for long periods of time. You may disagree but until smartphones come dual equipped with OLED and e-paper, I doubt they’ll ever have a serious chance of overtaking them.
E-readers can be read in sunlight, on the beach, etc. That’s why I have one. And the Kindle platform will sync last page read and so on between the Kindle and my iPhone anyway, so I needn’t always carry the E-reader around, unless I plan on doing lots of reading.
What if the back of the iPhone is made of eInk?
OBD II Bluetooth dongles are sub-$100.
SDRs are still pretty battery intensive.
And Spaf spells it with one F. :-)
Eric, you are thinking like Russ McGuire.
McGuire’s Law: The value of any product or service increases with its mobility.
Combine this with Raymond’s Rule of Smartphone Subsumption and the smartphone starts to eat even faster.
BTW: Monitor (by adding pico projector) already exists.
Yours,
Tom
What will eat the smart phone?
DVK Said:
>Next low hanging (partially eaten) fruit: Remotes of all sorts and sizes.
The Nokia N900 has an IR receiver/transmitter and a neat remote control app, qtirreco…
http://maemo.org/packages/view/qtirreco/
> What will eat the smart phone?
Smartphones will morph into a more generic portable device (in name; at this point they are already that). At handheld they are already at or very close to the limit of size to usability ratio. Next step: neural implants! Where do I sign up?
I find it unlikely anything will eat the smart phone. It may incrementally move into a position on our belt and communicate to effectively-permanent IO in glasses/contacts and on our hands, but it won’t be a quantum leap like computer to phone has been. (The quantum leap being rather more apt than usual, since there are no viable intermediate states.) The next step after that would be “jewelry”, but… as fantastic as future tech may be it will still conform to the laws of physics (unless it doesn’t in which case all bets are off) and it will need some amount of on-board battery no matter what clever things we may do with wireless power, which may yet turn out to be impractical.
Frankly, even if we do start implanting computers into ourselves it will probably still be recognizable as the “smart-phones” of the day for quite a while, just with yet better IO.
ESR says: I concur 100% with all of this…couldn’t have put it better myself.
> @Jim T.: “RSA SecurID fobs”
Already done. My BlackBerry at work has an RSA app installed after my last SecurID fob expired.
> @Morgan Greywolf: “* digital voice recorder (someone else said “dictophoneâ€, which is not quite the same thing)”
I am not quite sure I see the distinction between a voice recorder and a dictaphone separated from a companion transcription device (matter of fact, in Russian, ‘dictaphone’ is a literally a translation of “voice recorder”, with no transcription connotation that seems present in English dictionary definition.
> @TC Forest: “The Nokia N900 has an IR receiver/transmitter and a neat remote control app, qtirreco…”
Yep… PalmOS had a similar app for many years whose name escapes me at the moment
It would be nice if you had as much clue about radio as you do about open source software.
AIS uses two frequencies in the Marine VHF band: 161.975 and 162.025 MHz.
There are fourteen bands defined in 3GPP TS 45.005 (from http://en.wikipedia.org/wiki/GSM_frequency_bands):
System Band Uplink (MHz) Downlink (MHz) Channel number
T-GSM-380 380 380.2–389.8 390.2–399.8 dynamic
T-GSM-410 410 410.2–419.8 420.2–429.8 dynamic
GSM-450 450 450.4–457.6 460.4–467.6 259–293
GSM-480 480 478.8–486.0 488.8–496.0 306–340
GSM-710 710 698.0–716.0 728.0–746.0 dynamic
GSM-750 750 747.0–762.0 777.0–792.0 438–511
T-GSM-810 810 806.0–821.0 851.0–866.0 dynamic
GSM-850 850 824.0–849.0 869.0–894.0 128–251
P-GSM-900 900 890.2–914.8 935.2–959.8 1–124
E-GSM-900 900 880.0–914.8 925.0–959.8 975–1023, 0-124
R-GSM-900 900 876.0–914.8 921.0–959.8 955–1023, 0-124
T-GSM-900 900 870.4–876.0 915.4–921.0 dynamic
DCS-1800 1800 1710.2–1784.8 1805.2–1879.8 512–885
PCS-1900 1900 1850.0–1910.0 1930.0–1990.0 512–810
But the reality is that no commonly-used GSM smartphone will use a frequency below 824MHz.
This is a problem for your receiver architecture, because you need a resonant circuit. Before you
counter with SDR (software-defined radio) you need to understand that the RF Frontend is the critical component
for what you want to do. (We’ll assume that a future smartphone has enough computational resource to accomplish
all the demodulation.
But you’re going to be constrained by the frontend for the next 10-20 years. You’ll need:
A matching circuit to allow all the received energy from the antenna to get to the next stage;
A band-pass filter (BPF) to knock down out-of-band jammers;
Another matching circuit at the input of the low-noise amplifier (LNA);
The LNA itself
Another matching network between the LNA output and the receive (RX) mixer (downconverter);
The RX mixer itself.
None of these components can be made particularly wide-band.
Bluetooth, ANT+ and WiFi all run in 2400-2483.5MHz (WiFi gets a little more in Japan), no help there.
So when you make statements like:
“So I think the tunable-RF capability I want for my AIS receiver app won’t be long in coming to a smartphone near me.”
I think you’re dead nuts wrong. There is some research available on software-defined antennas, but I’m unaware of what you’re going
to do to get a broadband LNA in the receiver chain that can hear both AIS and GSM.
That being the case, your quest for an AIS receiver is limited to external accessories, ala the ones already available for iPhones, as well as the USB things that are being modified for use on Android phones.
Note that you could, for example, take a really small VHF radio and connect it to a smart-phone without too much trouble. If you’re on a boat (where AIS currently matters, except for some specialty applications) you probably already have a VHF transceiver nearby. Now you need a sound-card, but these should be trivial to furnish via either the ‘accessory’ connection (30-pin on iPhone, mini USB on Android) or potentially via the headset. If you’re only interested in receiving APRS, then you could build something a lot like one of these: http://www.qslnet.de/member/la3za/dokumenter/CheapVHF_SPRATWinter04.pdf
Some Android phones (such as the HTC Legend) have TI’s WiLink chipset in them, and the Android community has recently been able to enable the FM (88-108MHz) FM receiver on these. (This didn’t make your sensor list, btw.) You would need to convince the other parts on the chipset to decode the GSMK (but this is nearly the same as what a GSM receiver has to do.) Still, it might be possible to do either on-chip or via software decode.
Incidentally, the Legend has been modified (by HTC and Google) to enable ANT+, so you can add these sensors:
heart rate
cadence (both foot-fall and bicycle, given appropriate sensors)
bicycle power
bicycle speed (rotational velocity (actually rotational period)), given appropriate external sensors
bicycle power (really torque), given appropriate external sensors
blood pressure (given appropriate external sensors)
blood glucose (given appropriate external sensors)
blood oxygen level (given appropriate external sensors)
better (more precise) elevation (via a real altimeter (barometer + thermometer) than GPS can provide, yielding %gradient
wind velocity and aerodynamics (see Andy Froncioni’s “chung-on-a-stick” project andyfroncioni.com)
etc.
The modification is really just new firmware for the WiLink chip inside the Legend.
I could also see a specialty Android phone being made with a VHF transceiver on-board, to sell into the recreational marine market.
> “for a really good radio, the kind you supply sound for a party with, you need speakers with resonant cavities that won’t fit in a smartphone enclosure.”
You’re so amusing at times. For a really good radio, you need a really good receiver architecture (including the front-end.) Speakers? What a joke.
> amortized over a large enough production run, their incremental cost approaches epsilon because most of their content is actually design information
Wrong again. The incremental cost becomes packaging cost. Patents expire.
> “If the frequency of any of the RF receiver stages in a phone were tunable, writing an app that would pull AIS data out of the air wouldn’t be very difficult. I’ve written a lot of the required code myself, and I know where to find most of the rest.”
I don’t believe you. Oh, I believe that you know quite a bit about the AIS protocol, but I don’t believe you know enough about demodulating GSMK to be effective, and I also don’t believe you know enough about radio design to make it happen. Hell’s Bells, didn’t someone here call you out for having to quote Wikipedia on the subject of AIS not too long ago? (early Feb and again in early June?)
Maybe the GNU radio folks would help you, and maybe they wouldn’t (I doubt you get much assist from the Free Software crowd, but even if you could borrow their code, you’re not going to make it run in your phone anytime soon, and (yar!) its going to be GPL.
But I do think you could make it happen via a small AIS receiver and a Bluetooth serial port dongle on-board a ship, and over the Internet (cellular data or WiFI) when you’re on dry-land.
>It would be nice if you had as much clue about radio as you do about open source software.
Yes, it would. I don’t mind you educating me about this.
>Before you counter with SDR (software-defined radio) you need to understand that the RF Frontend is the critical component for what you want to do
Yup, I get that part. Some years back I became intrigued by a project to support SDRs written in Python, and learned a bit about SDRs and SDR front ends.
>“So I think the tunable-RF capability I want for my AIS receiver app won’t be long in coming to a smartphone near me.†I think you’re dead nuts wrong.
Possibly. But if building multiband antenna/receiver hardware is so difficult, how did my dad’s old Zenith radio have it circa 1965? I loved that thing…conventional U.S. AM/FM plus 5 international shortwave bands. I learned about timezones from the foldout map that came with it. Is there some intrinsic physical reason that whatever it did can’t be miniaturized?
>You’re so amusing at times. For a really good radio, you need a really good receiver architecture (including the front-end.) Speakers? What a joke.
I’m going to stand by this one. Really good receiver architectures are cheap and easy nowadays. I can remember when they weren’t; my dad was an early hi-fi hobbyist from the days of semi-custom equipment. But my own experience confirms what my audiophile friends tell me – nowadays, even low-end antennas and receiver electronics are so good that the place to spend money is on your speakers.
>Wrong again. The incremental cost becomes packaging cost. Patents expire.
I don’t think that’s responsive to what I said. You have a good point about packaging cost remaining an issue, though I suggest that “systems integration” is probably a more fruitful way of thinking about it. But the fact that patents expire actually contributes to my argument rather than refuting it; most of what goes to make a sensor is design information that eventually becomes freely replicable.
>I don’t believe you. Oh, I believe that you know quite a bit about the AIS protocol, but I don’t believe you know enough about demodulating GSMK to be effective, and I also don’t believe you know enough about radio design to make it happen.
I don’t have to; I had a specific source in mind. There’s a GNU-AIS project that seems to have done the GSMK work already. Their protocol decoder is kind of lame (only handled a few message types last time I looked, and I found a bug in their code for un-armoring AIVDM) but that’s exactly the part I know like the back of my hand. Mash their stuff up with mine and I think we’d have it.
>Hell’s Bells, didn’t someone here call you out for having to quote Wikipedia on the subject of AIS not too long ago?
Dude, that was a troll – and I didn’t have to call him on it, because someone else did.
One of my collaborators (Kurt Schwehr) is also working with the ExactEarth microsat AIS project, and he tells me even those guys (with 30 million $CDN investment behind ’em) are using my AIS decoder. Because, basically, there isn’t a better one anywhere. Also, I wrote the best public documentation there is on on AIS/AIVDM decoding. Those two facts should tell you all you need to know about my domain knowledge.
> Assuming the smartphone is small enough then you can add the “fitness GPS†to the list of gadgets. You just need a way to attach it somewhere where you can see it while running/cycling and the right app that uses the existing GPS and timers to display speed, elevation, distance etc.
Already happening. See Google’s MyTracks project/app I’m coding similar for the iPhone as I type this.
(Yes, it will be open source.)
> But if building multiband antenna/receiver hardware is so difficult, how did my dad’s old Zenith radio have it circa 1965?
Because it had more than one RF front-end, which all mixed down to a common I/F, and then it was straight-forward.
Assuming your father had something like a Bomber or Trans-Ocean, you can read the schematics here: http://www.mbzponton.org/n2awa/zenith.html
> Really good receiver architectures are cheap and easy nowadays.
No. They’re not. The receiver is the difficult part in any radio. Quick rule-of-thumb is that a receiver is at least 10X the complexity of a transmitter.
> (Kurt Schwehr)
Yeah, I know Kurt too. Notice how NOAAdata is still being updated?
> and I didn’t have to call him on it, because someone else did.
Seems to me you immediately fessed up. Do I have it wrong?
> There’s a GNU-AIS project that seems to have done the GSMK work already.
I was already aware of GNU-AIS (which is just a port of AISmon.)
Quoting : “You will need a VHF receiver with discriminator output to get it to work.”
and now you’re back to square one.
If you want to play with an SDR to do it, you need to look here: http://www.funwithelectronics.com/?id=9
Though this http://rl.se/ais_eng or this http://www.discriminator.nl/index-en.html is a more likely source for getting something to work.
And isn’t it interesting that the GNU-AIS guy won’t point to your decoder or documentation on AIS?
The protocol documents are on-line here: http://www.uais.org/DownloadLibrary.htm
I know you’ve been active in dropping AIS support into GPSD, and thats a good thing. I’ve been considering writing an iPhone/iPad app to display AIS information when plugged into a regular AIS receiver, taking the code back out of GPSD (which I have near zero use for.)
but your skills, as I understand them, are a long way from being able to build a radio.
>Because it had more than one RF front-end, which all mixed down to a common I/F, and then it was straight-forward.
That’s the answer I was expecting; I’m not completely ignorant in this area. So, is there any reason the multiple RF front tends couldn’t be scaled down to size and cost epsilon and put on a chip, just like the (minimum of two) RF stages in a smartphone now? Is there some hard physical limit that I’m missing here?
(BTW, I did some Googling and I’m pretty sure my dad’s radio was a Trans-Oceanic of either the 1000 or 3000 marque.)
>No. They’re not. The receiver is the difficult part in any radio. Quick rule-of-thumb is that a receiver is at least 10X the complexity of a transmitter.
I’m sure you’re correct, but this is not responsive – you’re thinking too much like a design engineer and not enough like an economist or business analyst. I do know enough about RF electronics to be certain that the cost of producing a good receiver is mainly front-loaded NRE, with unit cost dropping very fast after the tooling is in place. Speakers have a different cost curve; proportionally, they have more atoms in them and fewer bits, so the floor under the unit cost is higher than it is for the electronics. This will be reflected in the unit price once the fixed capital costs have been amortized out, which is why a good pair of speakers is still more expensive than a good receiver.
>Yeah, I know Kurt too. Notice how NOAAdata is still being updated?
Yes. I know why, too. Kurt is well aware that my code is better than his; his documentation includes my critique of his design, at his insistence. NOAADATA lives because it’s his proof of concept for automated generation of an AIS parser from a declarative specification. But there’s a research group in Australia that’s gotten ahead of him on this, so the purely AIS parts of NOAADATA are now fairly pointless and I’m not expecting them to survive much longer. He’s got better uses for his time, and the people in his research group have moved to the GPSD decoder.
>Seems to me you immediately fessed up. Do I have it wrong?
You do, but no blame attaches. My fessup was incorrect; it turns out Wikipedia had the international SOLAS rules right, but the troll was uttering a jurisdictional quibble about U.S. carrier requirements. There was really no point to it at all other than to fling feces at me – the chapter and verse of the requirements is completely irrelevant to any design issue about the decoder or the protocol. The annoying part is that I should have been more confident that Wikipedia hadn’t goofed; I had read both series of requirements in a USCG document. Ah, well. Even Homer nods…
>Quoting : “You will need a VHF receiver with discriminator output to get it to work.†and now you’re back to square one.
In what sense? I don’t expect to have to build the radio hardware; that’s the smartphone-maker’s job. What I expect to have to do is read signal off a port in the smartphone, GSMK-decode it with the GNU-AIS routines, and then unpack it with my software.
>I’ve been considering writing an iPhone/iPad app to display AIS information when plugged into a regular AIS receiver, taking the code back out of GPSD (which I have near zero use for.)
I’ve been thinking about backing the decoder out of gpsd’s AIS driver into a linkable library. You just moved that up a notch on the priority list.
M. Smith Says:
We should stop calling them “smartphonesâ€, and start calling them “jeejahsâ€, a term from Neal Stephenson’s novel “Anathem†used as a catch-all for personal electronics.
Nah….”Joymaker” should be the preferred term. See en.wikipedia.org/wiki/Joymaker
So how long does anyone thinks it will be before smartphones have a built-in phaser?
Man that would be soooo cool.
Or perhaps more realistically a taser?
This may sound outlandish but I bet it will be here before too many years go by.
Obligatory XKCD reference:
http://xkcd.com/548/
> Is there some hard physical limit that I’m missing here?
its spelled economics. (Cue Russ Nelson.) Most everyone has gotten away from super-het receivers, and now does direct conversion (allows you to eliminate a number of pricey components. Now you’re back to atoms .vs bits. You can’t have it both ways.
> with unit cost dropping very fast after the tooling is in place.
depends on the rx architecture, of course. With a direct-conversion receiver, you’re on the curve. With super-het (which is what you were hoping for), you are not. Ever wonder ‘why’ the cost of receivers has gone down? Moore’s law. That doesn’t mean you get the flexibility of the old analog chains and their (sometimes multiple) I/F chains. Nor the expense. Nature (physics) giveth, and taketh away.
> is proof of concept for automated generation of an AIS parser from a declarative specification.
I have similar for ANT+ (python DSL, generates ‘C’, (and xml, and sql) Its how real programmers think, I think. ;-)
> What I expect to have to do is read signal off a port in the smartphone, GSMK-decode it with the GNU-AIS routines, and then unpack it with my software.
You want a smartphone with a discriminator output? I think you’ll be waiting a long time for that.
Calculators, even graphing/scientific/financial, might be the next thing smartphones eat totally.
My Droid Incredible has a 1 GHz processor, while the TI-89 Titanium is about 16 MHz if that.
TI, be very very scared.
> its spelled economics. (Cue Russ Nelson.)
Hehe. No, Eric is fairly knowledgable about economics. He (and I) just didn’t realize that modern radios don’t have a SuperHet stage. Makes me wonder why radios are still banned on airplanes if they don’t have a local oscillator in the range of the frequency of concern.
Jim T Says:
RSA SecurID fobs
Are you familiar with the phrase “Living in a state of Sin”?
I would love for this to happen, but I have yet to find a calculator app for my iPod Touch that comes close to matching my HP graphing calculator. The issues are mostly lack of useful features (programming, for instance, which Apple will never allow, and other things like all the trig functions) and lack of a navigable history or at least an Ans variable. Note to someone: there’s a money-making opportunity here.
Looks like another reason to use android not apple then – http://droidfreeapps.com/2010/01/android-calculator-apps/
No such constraint for Android-powered phones. I wonder if the ergonomics of lack of hardware keyboard (which calculators have) would be overcome with easy changing visible layout of software touchscreen keyboard. Also calculators are usually a bit larger than smartphones, perhaps also because of ergonomics (but it might be because of need to fit large hardware keyboard, even with three functions to one key).
Just today my smartphone ate the smartcard that I had previously used for the Zipcar rent-an-unattended-car-by-the-hour service. I can make a reservation on my phone, and use the same app to unlock the car when I get there.
I don’t think it’d be too expensive to add to cellphones a really crummy receiver at AIS frequencies. That’s crummy as in: (1) no tuned antenna; (2) implementation entirely on-chip, to avoid the cost of discrete components; (3) hooked on to the rest of the RF section as a second-class citizen, which has to not reduce even slightly the performance of the phone whose antenna it’d be sharing, while accepting any interference it gets. Each of those points represents a serious performance decrement — but try to change any of them, and you’d be adding significant costs, unsupportable in a mass-market device which might only have a thousandth of its users even mildly interested in AIS reception. And even adding that sort of crummy receiver would represent a significant engineering effort, which might or might not be justified by sales.
A receiver of that sort could never receive AIS signals from orbit (as the just-launched AISSat-1 is planned to do), but it’d probably be adequate for detecting that there’s a supertanker a mile away in the fog, headed straight at you. Speaking of AISSat-1, though, if the operators of that satellite (and/or future sister satellites) were to make their data available on the Internet, a smartphone could get it that way. That seems to me to be a far likelier path for future smartphones to get AIS information than adding a receiver to the phone itself would be.
>Speaking of AISSat-1, though, if the operators of that satellite (and/or future sister satellites) were to make their data available on the Internet, a smartphone could get it that way
Nice idea, but I don’t see any market incentive for them to do that. Then again, I don’t know what ExactEarth’s business plan is.
I doubt that TI scientific calculators will go away entirely, particularly in the US late middle- and high-school markets. They provide a stable, verifiable platform for standardized testing officials to benchmark all others against, and without significant monkeying and/or buying a more capable (and easily identifiable) unit, have no capabilities for in-test communications. A calculator app running on a smartphone? Not so much. I suppose it’d be possible to hardwire a small radio in place of the serial cable, but I think that’d fall outside the time/money/attention budget of most school-age attackers. Their parents, on the other hand…
I can’t wait to see the day when testing officials have handheld e-warfare suites.
“The problem with this is that the phone also has bluetooth and a camera, which means that there are secure areas where I cannot carry the phone, leaving me without a watch. I’m going to have to go back to carrying a pocket watch…”
or get a second, cheap phone without the offending features, and sim-swap (assuming you’re on a network where this is possible.)
The “thermometer” one, not all that great. I had a Nokia dumbphone with a thermometer in it, and when I was curious as to the temperature it would reliably tell me the temperature in my pocket was 30°C …
Oh, the same dumbphone (a Nokia 5140i) had a spirit level in it. A physical one! This was so you could set up the compass, apparently. I hadn’t realised how useful it would be until it was right there …
So yeah. A phone with a Swiss army knife in it! Not so good for flying with, of course …
There’s a Taiwanese news agency that’s achieved some notoriety by using — ahem — creative dramatizations in its reporting of stories, created with what appears to be off-the-shelf 3D animation software like Poser. They made headlines for playing fast and loose with actual events, for instance: showing two parties engaged in acrimonious debate as punching or strangling one another, when no such violence actually occurred.
Watch their take on the iPhone 4 debacle. Marvel as Steve engages in a light saber duel with Darth Gates — and then takes his Sith Lord helmet away. Recoil in horror as Darth Jobs severs the fingers of an iPhone customer (who is held fast with an AT&T ball and chain) and laughs as their iPhone reception problems are brutally and bloodily solved. And then there’s the signage: “iCrap on sale — Line starts here”.
Yorick:
Speaking of which, if TI graphing calcs won’t be sucked into the singularity, at the very least, the smartphone black hole might make TI adjust their prices downward. My Droid Incredible was $200, for 1 GHz, 800×480, 16-bit color depth (the display is 32-bit c.d. capable, the OS limits it to 16-bit), 512 MB RAM, 8 GB onboard flash storage. The TI-89 Titanium, preferred for high level college math, is $140-ish generally, for 16 MHz, 160×100, 1-bit grayscale, 188 KB RAM, 2.7 MB onboard flash storage. The TI-84+SE, the preferred for HS math, is 10-15 bucks less, 15 MHz, 96×64, 1-bit grayscale, 128 KB RAM (24 KB OS-limited), 1.5 MB onboard flash storage.
Is OS development at TI really that costly? Or are they just relying on scholastic mindshare?
>Is OS development at TI really that costly? Or are they just relying on scholastic mindshare?
The latter. Bet on it. :-)
Is there any good reason not to simply make the smartphone’s display out of kindle style e-paper? (Of course, this is coming from someone whose current cellphone is in no way a smartphone, and, in fact, still has a B&W display.) Does e-paper do color? Are there reasons (beyond economics) why e-paper can’t do color?
@perlhaqr: OLPC display was/is, if I remember correctly, dual mode: energy conserving reflective e-paper, and energy consuming color light-emitting ordinary LCD. I’m not sure if there is some matter of scale to use the same solution for (smart)phones (e.g. to display time in e-ink mode).
@perlhaqr: About color e-paper / e-ink – I think that it is only recently being available, but I might be mistaken.
Perhaps this is one of the real reasons AAPL developed the iPhone, b/c they were worried about the iPod being sucked into someone else’s smartphone singularity. So they created their own singularity.
perlhaqr:
Refresh rates on e-paper are very, very long (actual mechanical elements have to move!); common types today take a good chunk of a second to update. An appropriate interface to this is an interesting challenge – standard GUI mechanisms like pointers and scrolling don’t work very well.
Color displays are starting to be available, and the refresh rates are improving, but it’s still a very immature technology.
I thought several commenters here claiming out that Google has intentionally crippled android security for their own benefit (ads and or mining) was interesting.
A bit, er, late here, but why should precision optics require large size? How big is the eye of a hawk?
Organic-like optics + AI => camera of the future.
Sell your Leicas!
Thank you so much. Its enough efficient that a smartphone will never replace any other item.