Shacktopus – Paleo Smartphone and Shack-to-Go

by Steven K. Roberts, N4RVE
Camano Island, WA – 2004-5

A decade after this project, while giving a talk at Google for an audience of engineers and executives, I was explaining the architecture of the 2005 Shacktopus system. The drawing below was sprawled across the two screens, and suddenly I heard a gasp from the back of the hall. “Hey, that was the first smartphone!” someone cried. Indeed, with a network of communications and data collection tools, the micro always on with a flexible graphic user interface, it was a precursor to what is now in my pocket… although sadly, it never reached the point of becoming an actual product. (The “first” label is highly subjective, and could go all the way back to PDA/voice hybrids and other pioneering tech from the nineties depending on the definition… so don’t take it too seriously. But this was way ahead of the curve when it comes to communication tools with embedded sensors and opportunistic connection capabilities.)

(It was notably not the first camera phone – that distinction goes to my friend Philippe Kahn, who cobbled together his digital camera and a cellphone to share photos of his daughter’s birth in 1997.)

Anyway, Shacktopus emerged from my simple desire to take the tools that I had been building into the Microship, and integrate them all into a minimal substrate-independent package… not a computerized bicycle or geeky trimaran, but a kit that could always be with me, however I happened to be traveling.

Inevitably, other people got excited about this. Soon Shacktopus was a total-immersion obsession in my Camano Island lab, gobbling a year of focused development work including a display at the SEA-PAC convention in 2005. I started taking tentative reservations and doing spreadsheets to help scale production. An übergeek friend helped with the software, and I was playing with front-end tools built in a PDA. Emergency services were getting excited about the implications for field deployment, hams wanted them, and yikes… it was starting to look like a product might happen. I got the shacktogo and related domains in addition to the primary name, and built a beautiful prototype in polycarbonate and acrylic, designed to slip into a Tom Bihn pack.

But in July of that year, my father died. I hopped into my creaky Isuzu and drove home to Jeffersontown, Kentucky… and the day I arrived, the Shacktopus site got slashdotted after somebody wrote about it. I couldn’t keep up. It took six months to shut down the old family home, and I never got back to this project. I started fantasizing about sailboat-scale nautical geekery, and technology moved on.

This page is a brief historical snapshot of the Shacktopus project (not to be confused with my later use of the same name for a portable power cart that had absolutely nothing to do with this system). I recently stumbled across a PDF of a story in an amateur radio newsletter that explained where we were in mid-2005, and that text follows along with a front-page image for time-stamping goodness.

The “Shacktopus” — a new concept in portable operations

published in “The Blurb” – August, 2005

Steve Roberts, N4RVE, has a long history of pioneering new frontiers in amateur radio mobile and portable operations. His Winnebiko and BEHEMOTH projects (under the banner of Nomadic Research Labs) attracted significant press attention (and vendor/supplier support) in the 1980s and 1990s.

Now Steve has a new project: the “Shacktopus”, and unlike his previous projects this is intended to result in a product useful to (and ultimately buyable by) “the rest of us”: amateurs that don’t get to spend our entire lives playing with cool toys.

Let’s let him tell the story in some of his own words…

Imagine trying to assemble a full suite of communication tools:

• When you need extreme mobility today…
• When an emergency severs your ties to home base…
• When you set off on an expedition or a world cruise…
• When you decide the night before to operate Field Day…
• When your life suddenly depends on what you can pack…
• When you are moving to an RV, boat, or bicycle…
• When there’s no more AC power, no cellular phone, and no Internet…
• When it’s time to grab your stuff and GO!

Those are not the times to start cobbling together a laptop, some batteries, a bag of wall-warts, an ethernet cable, random dongles, and whatever radios you have lying around. When mobility is key (whether for adventure or survival) you need a grab-and-go toolset… not just camping gear and a Leatherman tool, but all the complex systems that have become essential to daily life.

We are talking about extreme technomadics. I have spent over two decades wandering the US on computer-laden bicycles, embedding systems into amphibian micro-trimarans and geeked-out kayaks, and otherwise building a career around the tools of high- tech adventure. But all those systems, despite their utility in opening doors wherever I wandered and rendering my physical location irrelevant, had one fundamental flaw: they physically incorporated the essential electronics. It’s not like there was a choice, of course… the BEHEMOTH bicycle weighed 580 pounds, about ten times more than I could imagine carrying around in a pack. It was cool to have satellite email while pedaling across Iowa in 1991, but if I was more than a few hundred feet from the bike, that $1.2 million package of custom gizmology was essentially useless.

Things have changed. Lithium-Ion batteries, power-miserly microprocessors with kick-ass performance, tiny Wi-Fi beam antennas with ten-mile range, ultraminiature all-mode DC-to-daylight transceivers, gigabytes on flash, Linux on a tiny PC board… suddenly, one can pack a LOT of communication systems, computing tools, and electrical power into a shockingly small enclosure. The engineering problems are daunting, with a variety of protocols, signal levels, and serious noise issues, but with care, enough gear for open-ended untethered information survival can fit in a shoulder pack.

And that’s what Shacktopus is all about. Named in honor of its ham-radio roots coupled with its multi- pronged design, this is a complete Shack-to-Go with added Internet access, adaptable power system, remote control, environmental sniffing and data logging, tracking and telemetry, multiple audio options, on-board security system, robot-operator and logging capability, universal audio filter, synthesized speech response and event notification, and, well, the list goes on for quite a while. It’s BEHEMOTH in a pack, only more so.

After two decades of building and traveling the US aboard geeked-out “technomadic systems” (Winnebiko, BEHEMOTH, Microship, & Bubba), Steve Roberts, N4RVE, decided to build a suite of essential communication and data collection tools into something small enough to throw into a backpack or sea bag… the ultimate in portable gizmology, not tied to a specific platform.

The result is Shacktopus, a fully integrated, remote-controlled ultra- portable communication system: a self-powered and network-enabled “Shack To Go” with HF/VHF/UHF transceiver, automatic tuner, “sound card modes,” rig control and contact logging, robot operator, headset and retractable CW key, Packet/APRS with internal GPS, environmental telemetry, Internet access and Wi-Fi bridging, intelligent Li-Ion power system with solar/auto/AC charging, speech synthesis, audio recording from any source, DTMF control from HT with voice response, laptop & PDA front end via Bluetooth, field-deployable free-standing antenna array from HF to 2.4 GHz, and an on-board security system with 3-axis accelerometer and audio/video monitoring…all in a sexy over-the-shoulder Tom Bihn messenger bag, with a separate lightweight pack for the free-standing antenna array and solar panel!

This is essentially a collection of high-performance products from a variety of vendors, all interfaced to the RigNexus control system that includes:

• Always-on ATmega128 microcotroller for resource management and control
• ARM Linux board for Wi-Fi, archiving, full rig interface, and LAN access
• Local LCD and navigation control for on-board user interface
• DTMF command decoding from embedded HT… or via cellular phone
• Bluetooth wireless link to PDA or Laptop for graphic front end
• 8-channel audio matrix mixer with on-board speaker, ambient mic, and headset
• Synthesized speech or CW responses to commands (local, via HT, or over the phone)
• Universal audio filter (high, low, band, or notch)
• 6 serial channels for GPS, HF rig control, TNC, and sensors
• SMBUS communication with power system
• Highly responsive active-object software architecture

Shacktopus blends a huge range of resources into a single control environment that can be accessed locally, remotely via HT or cell phone with DTMF and voice response, through a Bluetooth connection from a PDA, or even using a browser. The system takes care of all the dirty work… audio routing and level control, power conservation by switching resources on only when needed, data collection, keeping track of the battery subsystem, managing serial channels including HF rig control and packet, and monitoring security and system status.

This translates into ease of use, despite some surprisingly complex behavior that results from anything being able to talk to anything under software control. Among other things, Shacktopus lets you:

• Send a command from your HT via simplex or repeater, and receive a clear synthesized voice report of environmental, power, and security sensors… or tell it to begin sending APRS tracking/telemetry.
• Plug in any available power source (solar, automotive, or AC), and the 95 watt-hour Lithium-Ion battery will make use of it… with the system able to report fuel gauge and over 30 other parameters.
• Log sensor variations while driving, bicycling, or kayaking… then produce a plot that shows everything from elevation changes to the worst moments of shock and vibration.
• Quickly set up an untethered “field day” station and enjoy automated voice or CW CQ, push-button contact logging, flexible audio filtering, instant recording of an interesting QSO, and relaxed operation with a graphic rig-control panel on your PDA instead of the complex multi-level menus on most HF rigs.
• Stuff it into a sealed enclosure at sea and operate remotely, log in via Wi-Fi and peek out through a webcam or listen to live audio around the unit, or point the 2.4 GHz yagi at a distant hot spot and surf the web.
• Run Airmail, PSK31, or other computer-supported modes without the usual clutter of a ham shack and full-size PC.

As this system flickered to life on the bench, we came to realize that there is nothing on the market even remotely like it… there’s not even a product category for gear of this scale! The initial plan was to strike out on another adventure with this highly mobile technomadic pack, but then we started getting inquiries… and realized that this needed to become a product.

One-Act Plays

This is a sort of playful use-case analysis technique that I employ when trying to stabilize a system design… a series of scenarios describing internal actions that take place for imagined events. This was written in April, 2005.

“Shacktopus Contemplates Quietly, Perhaps Charging”

In this minimalist existential masterpiece, the system does exactly nothing other than sit and wait, ready for whatever may occur. The Shakespeare board is getting power from the external supply and keeping the Li-Ion tamed. Simon (Shacktopus Internal MONitor) is periodically polling the DTMF decoder (which is listening to the VX-2R on some UHF frequency), the Bluetooth/serial interface (which might hear from a Zodiac or connected terminal), and the little buttons next to the LCD. Every now and then, Simon looks at the lid switch, battery voltage, and any environmental sensors, stuffing the analog values into buffers that allow some other scenario to take occur (hail the human, say something, send telemetry, etc.) In general, this scenario should be as power-efficient as possible (as a minor variant removes the charge source and begins draining the battery).

To be slightly less inscrutable, we may display the charge state on the Monitor LCD along with the temperature or other randomly amusing data.

“Shacktopus Gets Asked for Status Via HT”

In this gripping saga, one of the external events being awaited in the Zen state occurs: a DTMF character arrives. A state machine in Simon discovers this, processes it, and, if all goes well, some number of characters eventually become buffered into a command to report general status back over the UHF link.

Simon assembles a text string that looks something like this: “This is N4RVE-1 reporting system status. My battery is at [BATLEV] percent and is [CHARGESTATUS], internal temperature is [INTERNALTEMP] degrees, you [MAILHAVEORNOT] packet mail waiting, and I have not been activated in [LASTACTIVE] hours.” The audio matrix is then set to connect the V-Stamp to the VX-2 microphone input, the PTT bit is pulled, and the string is sent to the synthesizer. Upon completion (Talk Status bit goes inactive), PTT is released and the matrix connection broken.

Similar events take place for a variety of requests, which include: report current location, time-of-day, all sensors, last n log entries, detailed battery status, and so on.

“Shacktopus Gets Asked for Status via Local UI”

There is a 1:1 mapping between remote status commands and those accessible through a list on the LCD. Some combination of button presses allows browsing this list and selecting any one, whereupon a less verbose string containing the requested data is constructed and displayed or spoken via the on-board speaker, depending on the command hierarchy in the local UI (5-button keypad: U, D, L, R, C).

U, L – move up and down through menu pages
L, R – move left and right within menu
C – execute selected item
no activity for 15 seconds – return to home display (status/time/name)

Presumably, this LCD navigation is a state machine.

“Shacktopus Plays Radio”

Here, all we want to do is pretend that none of this stuff exists, and simply use the FT-817. To do this, we accept a command from the local UI to “Play Radio,” whereupon the FT-817 is connected through the matrix to the speaker/mic port (or headset). An additional command lets us route the speaker audio through the filter, and allows a special menu to manipulate the configuration and setpoints. Presumably, a more interesting user interface to this can be created in the PDA or Laptop, perhaps with a graphic representation of the filter performance.

Note that the CW key is directly connected to the radio and can be used without any software involvement. This should in all respects feel like Shacktopus doesn’t exist.

“Shacktopus, the Tireless Operator”

A useful utility is for Simon to generate, upon request, a stored voice or CW CQ… this can get very tedious. For the voice version, the user navigates to “Store Audio Snippet” via the local UI, whereupon Simon says “Begin speaking at the tone; hit the center button when finished.” via the local speaker… then beeps. It makes a matrix connection from ambient or headset mic to the V-stamp, then sends it a record command. When the button is pressed, the snippet is saved (on the V-Stamp) and labeled. At this point, a different menu selection can play it into the FT-817 whenever the execute button is pressed.

For CW, the best approach is to generate a saved text string in software, toggling a bit that has a FET across the normal CW keyer input (or two bits that mimic iambic, to avoid having to change radio mode… though that can probably be done over the CAT interface). Again, send CQ on any C button press when in this state.

“Sensor Sweeps”

Here, we want to collect and do something useful with the various sensor channels. These are:

Internal enclosure temperature
TS-7200 temperature
Battery data (fuel gauge, V, I, temp, etc)
Lid switch (reed)
Pressure transducer (0-5V)
Radiation monitor (pulses per minute)
3-axis accelerometer (MMA7260Q eval board)
Humidity
Light level
GPS coordinates

Not all of these will be installed initially, but are planned. During Zen mode, Simon should occasionally (?) copy the states of these into variables, allowing query for real-time sensor data, scheduled additions to a database in Sparky, or scheduled telemetry via packet or other means. Most of these are analog inputs that can just be read, though the TS-7200 temp is local to Linux, radiation is a pulse counter, and GPS is serial data that must be parsed.

“Yo… Sparky…”

This is where we wake up the TS-7200 board by toggling a bit on a power-control circuit mounted on the power board, in response to a menu command, remote via Bluetooth, or a connected terminal. (Where does the Sparky console port appear? Should it be routed “through” Simon or be a completely separate Bluetooth/Serial channel?)

“Looking Around”

Once Linux is running, we should, presumably, be able to use a webcam and serve it via HTTP to another device on the LAN… PDA or Laptop connected via Wi-Fi or through Ethernet. Until I know for sure that the Technologic board can do this, no further details on this one…

“Tracker”

This sets up the APRS tracking function, which is mostly handled by the TNC. Turn on the TNC with a power-control bit, turn on the GPS (output hardwired to the TNC aux GPS input), and let ‘er rip. Of course, there are a couple of other details… rig connection and PTT.

To use the FT-817, the user first makes sure an antenna is connected, then specifies this as the APRS device. Simon sends CAT commands to set the rig to 144.39 MHz FM Simplex, and sets the matrix for a bidirectional link between TNC and rig. PTT is then gated from the TNC to the 817 via an enable bit.

Since this is rather power-inefficient for such a long-running application, we have the option of using the embedded VX-2R for APRS. This requires manual frequency selection on the little radio (pre-stored in a memory, of course), followed by a similar setup to the above: connection through matrix and PTT enabling.

Shack To Go
preliminary white paper
by Steven K. Roberts
Nomadic Research Labs
Apr 8, 2005

––––––– COMPANY CONFIDENTIAL ––––––––

The notion that sparked this project was a simple one, though it took years to emerge from the Microship design concept that kept me focused for so long on system integration into the boat. Why should I build all this first-class communications capability into something I’m not likely to use except for relatively short adventures? For a while, I worked on a compromise solution: integrate systems into the boat, but provide myself with a wireless GUI that would allow me to access it from anywhere.

However it’s implemented, a Microship-centric design overlooks the reality… I’m not really on the boat all that much, and even on an expedition would spend a lot of time away from it. And what about migrating to another platform, like a yacht? I’d have to either start over or harvest components from the micro-trimaran.

So the real question is: what tools do I want to have potentially at hand all the time, whether or not I happen to be engaged in an expedition or even thinking in terms of geek goodies? In other words, if there were some emergency that thrust me into a survival situation, what would it take to have a full suite of tools that I could just grab and go? What is the gizmological equivalent of the Leatherman tool?

And if I build one, can I make it interesting and general enough that other people will want one too.

Productization is relatively new to me; other than publications and a few very minor spinoffs, I have never made any attempt to reproduce and sell any of the systems that have been developed to support my technomadic adventures. But priorities have changed… a couple of decades ago, I could make a living pedaling around the US and writing/speaking about it, surviving on the media buzz of an exciting convergence of new technologies and exploratory lifestyles. But the world has changed, as have I: I’m not likely to repeat the old formula by heading out on a multi-year Microship expedition.

So. Let’s look at what we need in order to build a Shack To Go, including enough generality to support the real or imagined needs of a sufficiently large user population to be of business interest. (For non-hams reading this, shack is amateur radio jargon for the room full of communications gear.)

Basic Principles

We should first look at the very broad situations in which such a system would be useful (without going into operating modes or speculating about hardware components). In general, I want to be able to use a wide range of amateur radio resources including HF, VHF, and UHF bands and multiple modulation types (voice, Morse code, LEO satellites, and various digital modes such as PSK31, APRS, and PACTOR). I want to have Internet access whenever possible, extending Wi-Fi range with a directional antenna as well as supporting direct ethernet connection if it’s available. I might as well have cellular phone capability, as it’s pretty much an appliance these days… though I don’t want to depend on it as it’s expensive, trackable, not available everywhere, and likely to go away in a catastrophic emergency.

The system needs to have a substantial battery with flexible opportunistic charging options (our Anyverter): AC power, automotive or marine 12V systems, photovoltaic panel.

This should be easy to carry (over the shoulder or backpack), with at least the basic operations such as amateur radio repeaters and cellular phone usable while walking (as well as “HFpack,” given a suitable antenna). It must be easy to use all the system’s features when the pack is resting on a surface, and removal of the unit for less cluttered operation on a desktop should not require much in the way of cable-fiddling.

We need a few types of “remote access” in addition to simple front-panel control and the wired microphone. This falls into four categories:

1. Access to internal microcontroller via Bluetooth from a Palm device (Zodiac in my case), with simple serial terminal and perhaps a slightly more graceful client app on the PDA to control the rig and bootstrap other modes… buttons that can be tapped to send strings and fields that can be filled in.
2. WiFi connection from the Zodiac or laptop to an internal AP, allowing browser-level interaction with available services as well as bridging out to a Wi-Fi client port with a beam antenna.
3. More distant remote control from an HT, using DTMF and Voice/CW response to query the machine regarding security or sensor data… or to start/stop various autonomous functions.
4. Remote desktop, VNC, and SSH logins to the pack if it has a stable net connection on a LAN somewhere.

To maximize scalability as a product, the design must be modular: we should be able to create versions for mobile (automotive or marine) use as well as fixed-base operation. The fundamental tools of audio routing, resource management, rig control, and networking are fairly universal and should work in any case. Rig control should use the “hamlib” libraries so we don’t become tied to a particular brand of radio, and similar flexibility should be designed in at other levels.

To utilize the excellent existing packs of laptop scale, the box should occupy the general volume of a Brain Cell, allowing maximum modularity and choice of pack styles. The initial unit (mine) is a shoulder-carried briefcase (Empire Builder from Tom Bihn), which can accommodate a thin-slice RigNexus as well as a thin laptop in a cell. In any case, designing it to fit into a standard space will allow such decisions to be postponed somewhat. In the mobile environment, more conventional packaging can be used.

At this point, I want to change perspective slightly. Speculation about hardware trade-offs becomes more and more abstract if we don’t nail down some real requirements, expressed as a list of things I want to be able to do…

Wannado List

* requires “application level” computer
o requires microcontroller

— Operate the ham radio in the field, while walking, or anywhere
o- Control the radio from Zodiac PDA while it’s in the pack
— Pull the unit out and use it on a desk or operating table
— Hook up to car power, roof antenna, and car audio system
— Use the cellular phone under any of these conditions
o- Become an APRS tracker with internal GPS
o* Run APRS software to see other stations on the map
o* Get a net connection from distant hotspot, or local ethernet
o* Get a net connection via cellular phone
o* Get a net connection via TCP/IP packet radio
o* Do email
o* Do Airmail (HF)
o* Do PSK31 and other “sound card modes”
o* Use Echolink or other VOIP via WiFi, Cellular, or local ethernet
?o Use in a boat or on mass transit (Train, bus, etc)
o- Operate remotely, closed into sealed Microship/kayak compartment
— Run off AC power when in a building (and opportunity charge)
— Plug in a solar panel to charge/operate when outdoors
— Charge from vehicle cigarette lighter
o- Use wireless audio to interact with any audio mode
o- Run a packet radio PBBS
o- Query system status (sensors, power, security) from Zodiac
o* Power up computer from Zodiac and initiate Wi-Fi browser session
o- Automatically hail HT on a call channel upon security alert
o* View sensor and event logs with browser
o* Carry substantial documentation libraries and software tools
o* Program and backup rig libraries
o* Use for software development without additional PC
o- Add additional sensors (radiation, etc)
o- Allow scheduled telemetry of sensor/location data via APRS, HF, net, etc
o* Opportunistic mail relay while moving about
o- Log contacts easily
o* Act as webcam server when net available
o* Park system on a net connection and access remotely
o* Do all normal “laptop stuff” – personal apps, mail, archives, etc
o* Basic wardriving to find hotspots
— Use pack as daily utility, with support for random gear

In addition to the integral functions listed above, I also want room to carry a number of related loose objects that support survival, communications, and general utility. Some of these involve power, and suggest an integrated battery charging system for AA as well as (perhaps) some configurable ports for charging picky handheld units. Other packable gadgets are:

• ACR Personal Locator Beacon
• Mini-binoculars
• GPS, a bit redundant with integral unit (but with cartography)
• Leatherman tool
• Digital camera
• Lumbar pack basics: wallet, water, HT, flashlight, Zodiac, etc

This whole design presupposes that there is a class of components that are simply too bulky to carry in the same pack… antennas, cables, and solar panel. While the pack system should work fine by itself, setting up a true field station requires the contents of the “Tennabag”:

• Buddipole Package
• UHF/VHF crossed-yagi
• Wi-Fi yagi
• Solar Panel
• Wire antennas and cables

What’s Inside?

Since anything that purports to be a general solution set for a variety of communication problems is, by nature, a complex and open-ended thing, the key issue at this point is to nail down a stable definition of what is included lest we end up with endless mission creep. In brainstorming this, the biggest source of confusion has so far resulted from the attempt to nail down the on-board computing capability. And that makes it difficult to fully define the pack’s functions.

The needs here fall into two broad categories:

1. The “Monitor,” providing low-level control of internal resources, including audio routing, power management and load switching, security, and dealing with a few basic sensors. Whatever is running this level should also have a small LCD and some minimal UI to allow manual control (even if it’s just stepping through modes). A somewhat more interesting UI should be available over a serial/bluetooth port, allowing the PDA to connect, query for status, and invoke basic operations. Since this is probably on all the time, it needs to be a very low-power and extremely quiet (from an RFI perspective).
2. The “Big Iron,” which takes care of PC-scale applications, rig programming, sound-card modes, Internet access, VOIP, mailbox functions, and so on. It would be ideal if this capability were internal and remotely invokable (yanking a chain via Bluetooth or a DTMF sequence from a hand-held rig). This would allow internet-flavored operations like accessing the on-board server without having to be AT the pack, potentially very useful.

The counter-argument here is that most of the “advanced” functionality is something that will only be interesting when a human is actually using the pack up close and personal, so setting it up from remote logins and autonomous operation may be overkill. There are also power/weight/noise/complexity issues, not to mention the fact that an on-board computer of this scale then needs a substantial display, keyboard, and mouse. Decent LCDs are cheap in the form of laptops (which most users already have), but expensive as stand-alone devices.

If a user can be assumed to have a laptop associated with this, then we’re not getting into the computer business… just providing a set of hooks for interfacing some communications gear. As tempting as it is to provide lots of on-board autonomous smarts, I suspect it is more sane to leave it out. The problem is that we then lose some of the more interesting capabilities, as well as the substantial interface capability of a mini-ITX system.

The problem is that when I go back and tag the wannado list with * for big-iron functions, about half of them call for a general purpose computer.

Maybe the way to resolve this is to go more modular. One unit has all the comm gear, audio switching, the monitor, Bluetooth remote, TNC, the power block, and so on. The other, designed to nest with the first, adds the computer, Wi-Fi stuff, and cellular phone support. The only compromise here is that the assumed batch of USB ports only exists if the computer is there, so all the low-level I/O and rig control needs to be done by the monitor, but it can be pretty lightweight.

Interestingly, the issue that keeps driving the “Big Iron” question is the display… either a $commercial$ LCD or a laptop (redundant). How many of the asterisk’d apps above can be adequately handled with VNC or a browser window via the Zodiac or a nearby laptop? If most, then that objection goes away.
(I know, this has turned from an authoritative white paper into another brainstorming document, but it’s necessary.)

Anyway, if we get substantial benefit from an X86-ish PC in here most of the time, then there is no major objection to occasionally using a laptop to derive additional value (like for local software development or a full-screen “user experience”)

Back to philosophy. I need to establish exactly why this is cool… why I want it. If it turns me on, I can be sure that it will also resonate with some geek subset of humanity — the same folks who have patiently waited through my years of Microship-wankin’ for another technomadic system to emerge.

Ham radio is a hobby, and any attempt to overlay a bunch of serious NEEDS on it quickly starts to sound a bit hollow. It’s fun. But there are other kinds of communication that are solid tools… and during emergencies, so is ham radio. So we have a sort of crossover condition here: a device that is supremely fun to play with, but which can also be justified on the basis of its practicality now and its value during some unspecified future survival situation. Those are three pretty irresistible buttons.

If I am to carry something around most of the time (and be willing to put thousands of dollars into it), it has to be both intrinsically cool and very useful.