_____                   _                  _____            _____       _ 
  |     |___ _____ ___ _ _| |_ ___ ___ ___   |  _  |___ ___   | __  |___ _| |
  |   --| . |     | . | | |  _| -_|  _|_ -|  |     |  _| -_|  | __ -| .'| . |
  |_____|___|_|_|_|  _|___|_| |___|_| |___|  |__|__|_| |___|  |_____|__,|___|
  a newsletter by |_| j. b. crawford                       home subscribe rss

>>> 2020-12-30 I trained a computer to do math

Here's an experiment: a briefer message about something of interest to me that's a little different from my normal fare.

A day or two ago I was reading about something that lead me to remember the existence of this BuzzFeed news artice, entitled "We Trained A Computer To Search For Hidden Spy Planes. This Is What It Found."

I have several naggles about this article, but the thing that really got me in a foul mood about is their means of "training a computer." To wit:

Then we turned to an algorithm called the random forest, training it to distinguish between the characteristics of two groups of planes: almost 100 previously identified FBI and DHS planes, and 500 randomly selected aircraft.

The random forest algorithm makes its own decisions about which aspects of the data are most important. But not surprisingly, given that spy planes tend to fly in tight circles, it put most weight on the planes turning rates. We then used its model to assess all of the planes, calculating a probability that each aircraft was a match for those flown by the FBI and DHS.

To describe this uncharitably: They wanted to identify aircraft that circle a lot, so they used machine learning, which determined that airplanes that circle a lot can be identified by how much they circle.

I try not to be entirely negative about so-called "artificial intelligence," but the article strikes me as a pretty depressing misapplication of machine learning techniques. They went into the situation knowing what they were looking for, and then used ML techniques to develop an over-complicated and not especially reliable way to run the heuristic they'd already come up with.

Anyway, this is an interesting problem for other reasons as well. The article Police helicopters circling a city are environmental terrorism makes a case for the harm caused by persistent use of aerial surveillance by police. Moreover, If you'd seen NextDoor around here, you'd know that the constant sound of the Albuquerque Police Department's helicopters is one of the greatest menaces facing our society. This increasingly common complaint has got some press, and although they're no longer keeping me up at night with loudspeaker announcements the frequency with which helicopters circle over my house has been notably high.

Moreover, late last night I went for a walk and there was an APD helicopter circling over me the entire time. You know, being constantly followed by government helicopters used to be a delusion.

So, I decided to explore the issue a bit. I dropped a few dollars on FlightAware's API, which they excitedly call "FlightXML" even though it returns JSON by default[1], in order to retrieve the last week or so of flights made by all three of APD's aircraft[2]. I then trained a computer to identify circling.

No, actually, I wrote a very messy Python script that essentially follows the aircraft's flight track dragging a 1.5nm x 1.5nm square around as the aircraft bumps into the edges. Any time the aircraft spends more than six minutes in this moving bounding rectangle, it deems the situation probable circling. Experimentally I have found that these threshold values work well, although it depends somewhat on your definition of circling (I chose to tune it so that situations where the aircraft makes a single or only two revolutions are generally excluded). I plan to put this code up on GitHub but I need to significantly clean it up first or no one will ever hire me to do work on computers ever again.

On the upside, maybe recruiters will stop emailing me because they "loved what they saw on GitHub." Actually, maybe I should put it up right now, with a readme which declares it to be my best work and a specimen of what I can achieve for any employer who cold-calls me ever.

You can see the result here. Incidents of circling actually seem more evenly distributed through the city than I had expected, although there is a notable concentration in the international district (which would be unsurprising to any Burqueño on account of longstanding economic and justice challenges in this area). Also interesting are the odd outliers in the far northwest, almost Rio Rancho, and the total lack of activity in the South Valley. I suspect this is just a result of where mutual aid agreements are in place, Bernalillo County has its own aviation department but I don't think the Rio Rancho police do.

This is all sort of interesting, and I plan to collect more data over time (I only seem to be able to get the last week or so of tracks from FlightAware, so I'm just going to re-query every day for a few weeks to accumulate more). Maybe the result will be informative as to what areas are most affected, but I think it will match up with people's expectations.

On the other hand, it doesn't quite provide a full picture, as I've noticed that APD aircraft often seem to fly up and down Central or other major streets (e.g. Tramway to PdN) when not otherwise tasked. This may further complaints of low-flying helicopters from residents of the downtown area, but isn't quite circling. Maybe I need to train a computer to recognize aircraft flying in a straight line as well.

It would also be interesting to apply this same algorithm to aircraft in general and take frequent circling as an indicator of an aircraft being owned by a law enforcement or intelligence agency, which is essentially what BuzzFeed as actually doing. I made a slight foray into this, the problem is just that, as you would expect, it mostly identified student pilots. I need to add some junk to exclude any detections near an airport or practice area.

Anyway, just a little tangent about something I've been up to (combined with, of course, some complaining about machine learning). Keep using computers to answer interesting questions, just please don't write a frustrating puff piece about how you've "trained a computer" to do arithmetic and branching logic[3].

With complete honesty, I hear a helicopter right now, and sure enough, it's APD's N120PD circling over my house. I need to go outside to shake my fist at the sky.

[1] I would have preferred to use ADSBExchange, but their API does not seem to offer any historical tracks. FlightAware has one of those business models that is "collect data from volunteers and then sell it," which I have always found distasteful.

[2] Some context here is that APD recently purchased a second helicopter (N125PD). This seems to have originally been positioned as a replacement to their older helicopter (N120PD), but in practice they're just using both now. This has furthered complaints since it feels a little but like they pulled a ruse on the taxpayers by not selling the old one and instead just having more black helicopters on the horizon. This is all in addition to their fixed-wing Skylane (N9958H).

[3] I will, from here on, be proclaiming in work meetings that I have "trained a computer to rearrange the fields in this CSV file."

--------------------------------------------------------------------------------

>>> 2020-12-27 mainframe pos

One of the most entertaining acronyms in the world of specialty computing equipment is POS. Let's all get the chuckle out of the way now, in this discussion we will be talking about Point of Sale.

For those not familiar with the term, POS refers to the equipment which is used "at the point of sale" in retail and other businesses to track sales, handle payment, and other business functions. In essence, a POS computer is a more entitled cash register, and there is a very direct line of evolution from the mechanical cash registers of days past (that made that pleasant cha-ching sound) to the multi-iPad abominations of today.

I would like to talk a bit about how we got from there to here, and, in my opinion, just how bad here is.

As with most things I discuss, IBM is an important component of POS history. However, I will start by introducing yet another three-letter acronym into the fray. We'll start with a company that is somewhat, but not radically, older than IBM, and was focused on POS while IBM was busy tabulating census cards: NCR.

NCR is one of those companies where the acronym officially no longer stands for anything, but before they tried to modernize their branding it stood for National Cash Register. As the name implies, NCR was an early giant in the world of POS, and many of the old-timey mechanical cash registers you might think of were actually manufactured by NCR or its predecessors, going back to the late 19th century.

NCR entered the computing business around the same time as IBM, but with a decidedly cash-register twist. Many of their computer products were systems intended for banks and other large cash-handling institutions that handled totally transactions, since computers of the day were largely too expensive to be placed in retail stores. They did, however, make general-purpose computers as well, mostly as a result of an acquisition of a computer builder.

NCR's early machines like the Post-Tronic are actually interesting in that they were basically overbuilt electromechanical calculators designed to allow a banker to post transactions to accounts very quickly, by keying in transactions and getting a report of the account's new state. This sped up the end-of-day process for banks appreciably. I like these kinds of machines since they take me back to my youthful education in double-entry accounting, but unfortunately it's not that easy to find detailed information about them since their lifespan was generally fairly short.

I hope to one day write about the posting machines used by hotels, electromechanical calculators that at the late stage read punched cards reflecting various charges to a person's account (room, restaurant, etc) and updated the room folio so that, when the customer checked out, a report of all of their charges was ready. This greatly accelerated the work of the hotel clerks and the night auditor who checked their work; in fact, it accelerated the work of the night auditor so much that I understand that in many hotels today the title "night auditor" is almost purely historic, and that staff member simply runs the front desk at night and has no particular accounting duties. The problem is that these wondrous hospitality calculators were niche and had a short lifespan so there's not really a lot out there about them.

Anyway, back to the point of this whole thing. NCR racked up a number of interesting achievements and firsts in computing, including being a key developer of OCR and barcode reading and inventing the ATM. More relevant to my point though, NCR was also an early innovator in electronic cash registers.

It is also difficult to find especially detailed information about the very early generation of electronic cash registers, but they were essentially the same as the late-model mechanical cash registers but intended to be cheaper and more reliable. For an early electronic cash register, there was usually no networking of any sort. If central reporting was desired (as it very much was in larger businesses for accounting), it was common for the cash register to output a punched paper or magnetic tape which was later taken to a mainframe or midcomputer to be read. That computer would then totalize the numbers from all of the cash registers to produce a day-end closing report. This was an improvement on having to read and key in the totals from the cash registers by hand, but was not quite a revolutionary change to computer technology yet.

The situation becomes quite a bit more interesting with the introduction of networking. Now, what we tend to think of as computer networking today is quite a bit different from computer networking in the '80s when electronic cash registers really became predominant. In this era, "network" usually meant the connection between a terminal and a mainframe. Cash registers were not a whole lot different.

Reading patent 4068213 covering some very early plastic payment technology in the mid-'70s, we get some details. An NCR 255 cash register connected to an NCR 726 controller. Even within the patent text, the term cash register is somewhat flexibly interchanged with terminal. Indeed, the architecture of the system was terminal-and-mainframe: to a large extent, the actual POS system at the cashier's station was merely a thin terminal which had all of its functions remotely operated by the NCR 726, a minicomputer, which would be placed in the back office of the store. The POS terminals were connected to the minicomputer via a daisy-chained serial bus, and because the cash registers didn't really do any accounting locally, all of the store-wide totals were continuously available at the minicomputer.

As time passed, this made it possible to add extensive inventory control, lookup, and real-time accounting functions to the POS, which were really all performed at the central computer. This included things like looking up item prices based on barcodes, handling charge cards, and validating returns and exchanges.

This basic architecture for POS has persisted almost to the present day, although I would like to return somewhat to my comfort zone and transition from discussing NCR to IBM. In the mid-'80s, at perhaps peak computer POS, IBM introduced an operating system creatively named 4680. 4680 was a microcomputer operating system (based on a DOS written for the 286) that was specialized to run on a relatively "thick" POS computer, such that much of the computation and control was done locally. However, 4680 POS systems were intended to be in constant communication with a mini- or mid-computer which ran an application like IBM Supermarket Application to perform data lookup, accounting, and all of the POS functions which required access to external data and communications.

4680 was replaced by the even more creatively named 4690, and 4690 is perhaps one of the most influential POS systems ever designed. 4690 and its newer versions was massively successful, and is probably still in use in some places today. In a typical installation, a set of 4690 POS systems (running on hardware also provided by IBM) would be connected to an AS/400 or similar IBM midcomputer running in the back office. The AS/400 would often have a telephone or internet connection which allowed it to regularly report data up another level to a corporate mainframe, and retrieve updated stock information.

The architecture of 4690 systems is highly typical of POS in large retail environments to this day. A 4690 POS would be connected by multidrop serial bus (one of the various IBM pseudo-standard network protocols) to the store controller midcomputer. It would be connected via RS-232 serial to a thermal receipt printer. In an add twist, this RS-232 bus was also essentially multidrop, as the printer would have a passthrough connection to the pole display and the pole display was basically controlled by special-case messages to the printer. The printer also, incidentally, had a simple electrical connection to the cash drawer and triggered it opening. Details vary, but the credit card terminal was typically also connected to the 4690 by serial.

All of this is basically how conventional POS are cabled today, except ethernet is usually used for the back-office connection and sometimes also for the credit card terminal (which might also be USB). Serial is still dominant for the printer and pole display in conventional systems.

IBM sold off their retail division to Toshiba, and Toshiba continues to develop derivatives of the 4690 platform, although the POS side has essentially been rewritten as a Linux application. Whenever you go to WalMart or Kroger or another major retailer, check a look at the system the cashier operates. Not many IBM branded devices are still out there although you might catch one, more likely you will see a Toshiba microcomputer (usually under the desk) connected to an unusual peripheral that consists of a set of pleasantly clicky mechanical keys and a two-line matrix LCD display (although full on LCD touchscreens are becoming increasingly common at WalMart, and universal at for example Trader Joes. Note that these touchscreen LCD systems maintain the physical keys for numeric entry and common functions).

This whole system is, essentially, a modern 4690, using direct descendants of the original hardware. That said, many of these systems today either run more modern software from Toshiba (I believe still SuSE based although I am far from certain) or, in larger retailers, a custom application developed internally by the retailer. In fact, for large retailers, it is very common for nearly the entire POS stack to be running custom software, from the actual computer to the credit card terminal and even the printer. The vendors of this kind of hardware offer an SDK for developing custom applications, and this is the reason why physically identical credit card terminals made by Verifone or Ingenico often offer a frustratingly inconsistent user experience[1]. It doesn't help that some of the terminal vendors have decided that their products are nearly iPad-ish enough and introduced touchscreens of a size once reserved for televisions, that retailers clearly have no idea what to do with.

I am told that some major retails continue to use either an AS/400, a more modern System i, or an AS/400 emulator on x86 to run the back-office system. That said, there are now UNIX-based options (I mean all-caps UNIX, we are often talking HP UX or similar) that are presumably taking over.

So we've talked a bit about the technical history, which is likely striking you as painfully arcane... and it is. We live in the era of ubiquitous microcomputers and flexible, fast network protocols. These enable all kinds of simpler and yet more capable architectures for these devices. And yet... let's focus on the usability.

One thing you will likely have noticed is that retail POS are typically either very fast (in the case of an experienced cashier) or very slow (in the case of a new one)[3]. Interaction with a 4690-style POS is primarily through a barcode reading weighscale and a set of relegendable buttons. While large color screens are becoming more common, lots of retailers still stick to only a two-line text display. The learning curve to operate these systems, especially in less common cases, is fairly substantial.

And yet, they are very fast. For barcoded items any kind of interaction with the user interface is seldom necessary. For non-barcoded items like produce, once a lookup table is memorized it is a matter of keying in an item number and weighing. Often there are one-press functions provided for operations like repeating an item. There are few distractors, as there are little to no "system notifications" or other software to interfere with the POS operation.

The POS has the property of being built for purpose. It contains the features necessary for efficient POS operations, and no other features. It uses a physical keyboard for entry because these can be operated quickly and by feel. It expects the user to learn how to operate it, but pays out the benefit of seldom ever providing any kind of prompt the operator needs to read or context the operator needs to determine, allowing operation to become muscle-memory.

These are traits which are, today, thought of as archaic, obsolete, and perhaps worst of all, unfashionable.

Compare to the "modern" POS, which consists of an iPad in a chunky mount. If you are lucky, there is a customer-facing iPad Mini or even iPod touch, but more often it is necessary to physically rotate the iPad around to face the customer for customer interactions.

This is a system which is not built-for-purpose. It is based on commodity hardware not intended for POS or even business use. It has few or no physical peripherals, making even functionality as core as producing a printed receipt something that many businesses with "modern" technology are not able to do. Interaction with the system is physically clunky, with the iPad being spun around, finger-tip signatures, and a touchscreen which is not conducive to operation by touch or high-speed operation in general due to lack of a positive tactile response. The user interface is full of pop-ups, dialogs, and other modal situations which are confusingly not always directly triggered by the user, making it difficult to operate by rote sequence of interactions. Even worse, some of these distractors and confusers come from the operating system, outside the control of the POS software.

All of this because Square either cannot afford to or has made a strategic decision not to develop any meaningful hardware. It does keep prices down.

In many regards these iPad-based POS are inferior to the computer POS technology of the 1980s. At the same time, though, they are radically less expensive and more accessible to small businesses. Buying an iPad and using the largely free Square POS app is radically easier to reach than buying an AS/400 and a 4690 and hiring an expensive integration consultant to get any of it to work---not to mention the licensing on the back-office software.

I make a point of this whole thing because it is an example of this philosophy I have been harping on: the advancing of technology has lead to computers becoming highly commodified. This has the advantage of making computing less expensive, more accessible, and more flexible. The downside is that, in general, it also makes computers less fit for purpose, because more and more applications of computers consist of commodity, consumer hardware (specifically iPads) running applications on top of a general-purpose operating system.

The funny thing is that the user experience of these newer solutions is often viewed as being better, because they are far more discoverable and easier to learn. There is obviously some subjectivity here, but I would strongly argue that any system which a person interacts with continuously as a part of their job (e.g. POS) should be designed first for speed and efficiency, and second for learnability. Or at least this is what I repeat to myself every time the nice lady at the bakery struggles to enter a purchase of three items, and then I have to sign the screen with my finger.

I'm not necessarily saying that any of this has gotten worse. No, it's always been bad. But the landscape of business and special-purpose computing is slowly transforming from highly optimized, purpose-built devices (that cost a fortune and require training to use) to low-cost, consumer devices running rapidly developed software (that is slower to operate and lacks features that were formerly considered core).

This change is especially painful in the POS space, because key POS features like a cash drawer, printer, barcode reader, weighscale, and customer-facing display are difficult to implement by taping iPads to things and so are often absent from "modern" POS configurations, which has a significant deleterious impact on efficiency and customer assurance. Amusingly, many of these peripherals are completely available for iPad-based systems, but seldom used, I suspect in part due to uneven reliability considering the iPad's limited peripheral interface options.

There is technical progress occurring in the conventional POS space, with far more retailers adopting full-color LCD interfaces and taking advantage of the programmability of peripherals to offer features like emailed receipts. But as much as parts of silicon valley feel that they are disrupting the POS space... 4690's creaky decedents are likely to persist well into the future.

Postscript: I am trying out not eschewing all social media again, and I am using the new Pleroma instance at my janky computer operation waffle.tech. Topics will be diverse but usually obscure. If you're a fediperson, take a look: https://pub.waffle.tech/jesse.

[1] It is also usually painfully clear which retailers have invested in developing good UX for their payment terminals (McDonalds), vs made a half-assed effort (Walgreens), vs throwing their hands in the air and just adding a lot of red circles to an otherwise "my first Qt app" experience (Target).

[2] Receipt printers are only supported by Square on iOS for some reason, and Square is cagey about whether receipt printers not on their special list will work. It obviously does support the industry-standard ESC/POS protocol but I think the core issue is the lack of flexible USB support in iOS. Bluetooth devices frequently have reliability issues and are too often battery-based. IP-based peripherals are excessively expensive and can be painful to configure. Somehow, POS peripherals have gone from eccentric daisy-chained RS-232 to a worse situation.

[3] This also reflects a related shift in the computing industry I hope to focus on in the future, which is that often modern UX practices do not really do well with users being good at anything. Many modern user interfaces prioritize discoverability, ease of learning, and white space to such a degree that they are downright painful once you have more than two hours of experience with the product. I'm not very old at all and I remember using text-based interfaces that were extremely fast once you learned to use them... that were later replaced with webapps that make you want to pull your hair out by guiding you and hiding functions in menus. This is all part of the "consumerization" of business computing and increasing expectations that all software feel like an iOS app made for first-launch engagement, even if it's software that you will spend eight hours a day operating for the foreseeable future. A lot of software people really get this because they prefer the power and speed of command-line interfaces, but then assume professional users of their product to be idiots who cannot handle having more than four options at a time. But now I'm just ranting, aren't I? I'll talk about examples later.

--------------------------------------------------------------------------------

>>> 2020-12-22 Xerox brand network product

While I have more radio topics to talk about, I think it'd be good to take a break from the airwaves and get back to basics with computer topics. I've mentioned before that one of the things I really enjoy are pre-IP network protocols, from the era when the design of computer networks was still a competitive thing with a variety of different ideas. One of the most notable of the pre-IP protocols, as I've mentioned before, is the Xerox Network System or XNS.

It is an oversimplification, but not entirely wrong, to say that XNS was created by Bob Metcalfe, the creator of Ethernet, so that he had something to use Ethernet for. In fact, XNS is an evolution of an earlier protocol (called PUP but more adorably written Pup) which was designed by Metcalfe and David Boggs for use with Ethernet as a demonstration. For reasons that are difficult to understand now but tied to the context of the time, Xerox was not particularly enthusiastic about Ethernet as a technology and Metcalfe found himself fighting to gain traction for the technology, including by developing higher-level protocols which took advantage of its capability.

This bit of history tells us two important things:

  1. The widespread misunderstanding that IP and Ethernet are somehow designed for each other is quite incorrect---in fact, if Ethernet "naturally" goes with another protocol and vice versa, that stack is Ethernet and XNS.
  2. As has been seen many times in computer history, XNS's lack of popularity with its corporate sponsors was, ironically, a major factor in its success.

Xerox's roots in more academic research (Metcalfe and the Xerox PARC) and Xerox's lack of vigor in commercializing the technology essentially lead to it being openly published as a research paper and then Xerox not doing a whole lot else with it (using it only for a couple of less important projects). XNS was viewed as academic rather than commercial, and that's how it escaped.

Xerox's lack of motivation to pursue the project was not shared by the rest of the industry. After XNS was published, a number of other software vendors, and especially designers of Network Operating Systems, picked it up as the basis of their work. The result is that XNS was used in a variety of different network systems by different vendors (although not always by that name), and that it became quite influential in the design of later protocols because of its being a "common denominator" between many protocols based on it.

IP and XNS are largely contemporaries, the two having been under active development during the same span of a few years. Both appear to incorporate ideas from the other, in part because IP originated out of ARPANET which was one of the biggest network projects of the time and the designers of XNS were no doubt keeping an eye on it. There were also a couple of personal relationships between designers of XNS and designers of IP, so it's likely there were some notes exchanged. This is a powerful part of how these early standards form, people working in parallel and adopting similar ideas.

So let's talk about XNS. Wikipedia starts its explanation of XNS by saying that "In comparison to the OSI model's 7 layers, XNS is a five-layer system, like the later Internet protocol suite." The "later" here is a little odd and depends on where exactly you set the milestones, but I like this start to the design explanation because it emphasizes that both XNS and IP have little to do with the OSI model.

As I like to repeat to myself under my breath on a daily basis, the widespread use of the OSI model as a teaching device in computer networking is a mistake. It leads students and instructors of computing alike to act as if the IP stack is somehow defined by or even correlates to the OSI stack. This is not true. The OSI model defines the OSI network protocols, which are an independent network architecture that ultimately failed to gain the traction that IP did. IP is different from the OSI stack in a number of intentional and important ways, which makes attempts to describe the IP stack in terms of the OSI model intrinsically foolish, and worse, confusing and misleading to students.

Anyway, given that the XNS stack has five layers (and NOT seven like OSI adherents feel the need to tell you), what are those layers?

  1. Physical (not defined by XNS, generally Ethernet)
  2. Internal Transport
  3. Interprocess Communications
  4. Resource Control
  5. Application (not defined by XNS)

Layer 1 of XNS is the internet datagram protocol, or IDP. If this sounds kind of similar to IP, it is, and beyond just the naming. There are some important differences though, which are illuminating when we look at the eccentricities of IP.

To start with, IDP makes use of Ethernet addressing. Sparing the details of bits and offsets, IDP network addresses consist of the Ethernet (MAC) address of the interface, a network number (specified by the router), and a socket number. While the MAC address serves as a globally unique identifier, the network number is useful for routing (so that routers need not know the addresses of every host in every network). The socket number identifies services within a given host, replacing the ports that we use in the IP stack.

That difference is particularly interesting to highlight: IP chooses to identify only the host, leaving identification of specific services or sockets to higher-level network protocols like TCP. In contrast, XNS identifies individual sockets within IDP. As usual it's hard to say that either method is "better" or "worse," but the decision IP made certainly leads to some odd situations with regards to protocols like ICMP that do not provide socket-level addressing.

Another interesting difference is that, while IDP allows for checksums, it does not require them. This is an allowance for the fact that Ethernet provides checksums, making bit-errors on Ethernet networks exceedingly rare. In contrast, IP requires a checksum (but curiously only over the header), which is effectively wasted computation on media like Ethernet that already provide an integrity check.

To bring my grousing about IP full circle, these differences reflect two things: First, IP was designed with no awareness of the addressing scheme that is now virtually always used at a lower layer. Second, IP has a redundant integrity scheme. Both are simply results of IP having not been designed for a lower layer that provides these, while XNS was.

At the next layer, the interprocess communications layer, XNS provides us with options that will once again look fairly familiar. Sequenced packet protocol (SPP) provides reliable delivery, while packet exchange protocol (PEP) provides unreliable delivery. The design of these protocols is largely similar to TCP and UDP, respectively, but of course with the notable difference that there is no concept of port numbers since that differentiation is already provided by IDP.

As more of a special case, there is the XNS error protocol, which is used to deliver certain low-level network information in a way analogous to (but simpler than) ICMP. The error protocol enjoys the advantage, compared to ICMP, of being easily correlated to and delivered to specific sockets, since it has the socket number information from IDP. This means that, for example, an XNS implementation of "ping" on Linux would not require root (or rather raw socket) privileges.

The resource control layer in XNS is somewhat ill-defined, but was implemented for example by Novell as essentially a service-discovery scheme filling a similar role to UPnP, mDNS, etc. today. Resource control was not necessary for the operation of an XNS network, but was useful for autoconfiguration scenarios and implemented that way by many vendors. We can thus question whether or not resource control really counts as a "layer" since it was not, in practice, generally used to encapsulate the next layer, but everyone who teaches with the OSI model is guilty of far greater sins, so I will let that slide. Sometimes it is useful to view a protocol as occupying a "lower layer" even if it does not encapsulate traffic, if it fulfills a utility function used for connection setup. I am basically making excuses for ARP, here.

Application protocols are largely out of scope, but it is worth noting that Xerox did design application layer protocols over XNS, which consisted primarily of remote procedure call. This makes sense, as RPC was a very popular concept in networking at the time, likely because it was closely analogous to how terminals interacted with mainframes. Nowadays, of course, RPC tends to make everyone slightly nauseous. Instead we have REST, which is analogous to how something, uh, er, nevermind.

XNS is now largely forgotten, as all of the systems that implemented it failed to compete with IP's ARPANET-born takeover. That said, it does have one curious legacy still with us today. Routing Information Protocol (RIP), commonly used as a "lowest common denominator" interior gateway protocol, was apparently originally designed as part of XNS and later ported to IP.

--------------------------------------------------------------------------------

>>> 2020-12-18 og mobile data

I promised that I would say a bit about mobile data terminals, and now here we are. This is an interesting topic to me for two reasons: first, it involves weird old digital radio and network protocols. Second, MDTs have weird intersection with both paging and cellular data, such that I would present them as being a "middle step" in the evolution from early mobile telephony (e.g. IMTS car phones) to our modern concept of cellular networks as being data-first (particularly VoLTE where voice is "over the top" of the data network).

To start with, what is a mobile data terminal (MDT)? An MDT is a device installed in a vehicle and used by a field worker to interact with central information services. Perhaps the best-known users of MDTs are police agencies, which typically use MDTs to allow officers in their vehicles to retrieve motor vehicle and law enforcement records, and sometimes also to write citations and reports in an online manner (meaning that they are filed in a computer system immediately, rather than at the end of the shift).

MDTs are not restricted to law enforcement, though. MDTs are also commonly used by utility companies such as gas and electric, where GIS features are particularly important to allow service technicians to view system diagrams and maps. They are also commonly used by public transit agencies, taxis, and other transportation companies, although these tend to be somewhat more specialized devices with more limited capabilities---for example, a common MDT in public transit scenarios is a device which reports position to dispatch, displays the route schedule to the driver, and allows the driver to send a small number of preset messages (e.g. "off schedule") to dispatch and see the response.

I'm more interested in the more "general purpose" MDTs which may, but do not necessarily, run a desktop operating system such as Windows. Today, MDT typically refers to a Toughbook or similar laptop computer which is equipped with an LTE modem (sometimes external) and can be locked into a dock which is hard mounted to the vehicle. Since most modern MDTs are just laptops, they can typically also be removed from the vehicle and used in a portable fashion, but that's a fairly new development.

There is also some slight terminology confusion to address before I get into the backstory: the term "mobile data computer" or MDC is essentially synonymous with MDT, and you may see it used instead in some cases. Handheld devices, on the other hand, are largely a Whole Different Thing.

MDTs were, for the most part, invented by Motorola. Early MDTs had vacuum fluorescent character displays, although they fairly quickly progressed to CRTs. The classic Motorola MDT has a full keyboard, but is also equipped with a number of "preset" buttons which send a given message to dispatch with a single press. Early MDTs ran special-purpose operating systems which were presumably very simple, and applications for them were largely custom-developed by Motorola or an integrator.

So how did these things actually communicate? MDTs were a fairly common tool of various municipal and utility agencies by the end of the 1970s, well before any kind of cellular data network. Indeed, they may be the first instance of a wide-area radio data network with more flexible capabilities than paging systems, and in many ways they worked with infrastructure that was ahead of its time---and also excessively expensive.

Various MDT data protocols have come and gone, but perhaps the earliest to be significantly capable and widespread is a Motorola system called MDC-4800 (Motorola tended to prefer the term MDC), introduced in 1980. The "4800" in the name is for 4800 bits per second, and the protocol, at a low level, is frequency-shift keying.

Typically, a Motorola MDT would be connected to a "Vehicular Radio Modem," although in early MDTs the VRM was not necessarily viewed as a separate product but rather part of the system. The VRM is essentially a VHF or UHF two-way radio which has the discriminator output connected to a packet modem. True to this description, many Motorola VRMs were closely based on contemporary VHF/UHF radio models.

MDC-4800 moved 256-byte packets and the protocol had support for packet reassembly into larger messages, although the messages were still fairly constrained in length. In many ways it is a clear ancestor to modern cellular data systems, being a packet-based radio data system intended for general purpose computer applications.

Where MDC-4800 gets particularly interesting, though, is in its applications. MDC-4800 was directly used by proprietary, semi-custom systems developed for various MDT users. Much of MDC-4800's ubiquity, though, came from a collaboration of Motorola and IBM. At the time, being the late '70s into the early '80s, IBM was in possession of a large fleet of service technicians who worked out of trucks, a substantial budget, and a limitless lust for solving problems with their computers. IBM began a partnership with Motorola to develop a futuristic computerized dispatch and communications system for their service technicians, which would be based on Motorola MDTs.

In the course of developing a solution for IBM, Motorola developed an integrated network system called DataTAC. DataTAC expanded on MDC-4800 to build a multi-subscriber data network operating in the 800MHz band, and Motorola partnered with various other organizations (mostly telcos) to establish DataTAC as a generally available service. In the US, the DataTAC service was known as ARDIS. ARDIS was widely used by MDT users of all stripes including municipal governments and businesses, but it could also support pagers and in a clear bridge to the modern era, early BlackBerry devices actually used ARDIS for messaging and email. ARDIS continued to operate as a commercial service into the late '90s and was upgraded to subsequent protocols to improve its speed and reliability.

DataTAC is often recognized as a "1G" cellular technology, for example by the Wikipedia categories. This is a bit confusing, though, as for the large part "1G" is synonymous with AMPS which was an analog, voice-only system. I believe that it is only from a modern perspective that DataTAC would be put in the same category as AMPS---the perspective that mobile telephony and data would become a unified service, which was not nearly so obvious in the '80s or even '90s when these were separate technologies offered by separate vendors as separate product lines, and generally seen as having completely separate applications. In a full-circle to my last message, it was pagers that seemed to "bridge the gap," as relatively sophisticated pagers can and did operate on the ARDIS network while still feeling like a "phone-ish" item.

ARDIS was later transitioned to using a protocol called RD-LAP, which was also developed by Motorola for MDT use. RD-LAP was similar to MDC-4800 in many ways except being faster, and so represented an evolutionary step rather than revolutionary. However, RD-LAP stands out for having had an impressively long lifespan, and while largely obsolete it is still seen today in various municipal agencies that have not found the budget to modernize. RD-LAP is capable of an impressive 19.2 kbps, which doesn't sound like much but was impressive for the time.

ARDIS was not alone in being an odd data service in an era largely seen as before mobile data. ARDIS had a contemporary in Mobitex, which was developed in Europe but also seen in the US. Mobitex was a centralized network with very similar capabilities to ARDIS, and was particularly popular for two-way pagers. Mobitex was also used by BlackBerry, and the fact that BlackBerries used Mobitex and ARDIS in various models, perhaps the first wide-area radio data protocols to exist, is a reminder of just how revolutionary the product once was, considering RIM's total lack of relevance today.

Mobitex also saw significant use for MDTs, although in the US it was less popular than ARDIS for this purpose. Mobitex seems to have been particularly popular for in-the-field credit card processing, although I would not be the least bit surprised if ARDIS credit card terminals were also made.

ARDIS and Mobitex represent an important early stage of modern cellular networks, but also show some significant differences from the cellular networks of today. Both systems were available as commercial services with nationwide networks but were also often deployed on a local scale, especially by municipal governments and, in some areas, state governments, for public safety and municipal utility use. This remains surprisingly common today in the case of municipal LTE (significant spectrum reserved for government use makes it surprisingly easy for municipalities to launch private LTE networks and many do so), but for the most part isn't something we think about any more, at least in the business world. A large part of the popularity of MDC-4800 and RD-LAP in particular is the fact that they could be deployed on existing business or municipal band VHF or UHF allocations, making them fairly easy to fit into an existing public safety or land mobile radio infrastructure.

About those VRMs, by the way: when Motorola began to offer VRM data modems as independent products, they sported a serial interface so that they could essentially be used as typical data modems by any arbitrary computer. This was the transformation from MDTs as dedicated special-purpose devices to MDTs as general-purpose computers that happen to have a data radio capability. Motorola themselves made a series of MDTs which were really just Windows computers in ruggedized enclosures with a touchscreen and a VRM.

Architecturally, MDT systems strongly showed their origins in the early ear of computing and the involvement of IBM in their evolution. Most of the software used on MDTs historically and in many cases to this day really just amounted to a textmode terminal that exchanged messages with a mainframe application, and often with an IBM ISPF-type user interface full of function keys and a "screen as message" metaphor[1].

MDTs and the data networks they used are an important but largely forgotten development in mobile networks... are there others? Of course, quite a number of them. One that I find interesting and worth pointing out is a technology that also took an approach of merging telephony together with land mobile radio technology: iDEN. Also developed by Motorola, iDEN was a cellular standard ("2G"-ish) that was directly derived from trunking radio technology. First available in '93, iDEN could carry phone calls much like AMPS (or more like digital AMPS) but also inherited many of the features of a trunking radio system, meaning that a group of iDEN users could have an ongoing push-to-talk connection to a "channel" much like a two-way radio. This was particularly popular with small businesses, which gained the convenience of two-way radio dispatch without the cost of the equipment---it was built into their phones.

iDEN is, of course, recognized by most under the name Nextel, the carrier which deployed a wide-scale iDEN network in the US. Nextel heavily advertised its PTT functionality not just to businesses but also to chatty consumers. Nextel television commercials and the distinctive Motorola roger beep are deeply burned into my brain from many hours of childhood cable television, and even as a kid I was pretty amazed by the PTT capability.

Nextel was of course merged with Sprint, and while the iDEN service continued to exist for some time it was not of great interest to Sprint and was officially terminated in 2013. This is actually rather sad to me, because modern cellular networks are surprisingly incapable of offering the quality of PTT service achieved by Nextel---modern PTT services are generally IP based and suffer from significant latency and reliability problems.

So let's try to come back to the idea that I brought up in the previous post, that commodification of technology also tends to eliminate special-purpose technologies which ultimately reduces the utility of technology to many use-cases. iDEN seems to me actually an exceptionally clear case of this: iDEN solved a specific problem in a very effective way, making something akin to two-way radio significantly more accessible to three-person plumbing companies and teenagers alike. Ultimately, though, iDEN was not able to compete with the far larger market share and rapidly improving data services of the GSM and CDMA/IS-2000 family of standards, and it seems that simple market forces destroyed it. Because the problem that iDEN solved well is actually a rather hard problem (reliable, real-time delivery of voice with minimal or no connection setup required, guaranteed bandwidth via traffic engineering being the big part IP fails to deliver), it's one that has in a large way gone from solved to unsolved in the last ten years. We have witnessed a regression of cellular technology, which is particularly prominent to me since I've developed an odd fascination with "Android radios" that are really just Android phones in a handheld radio format (with push-to-talk button) and that there aren't really many good ways to actually use.

What about the decline of Mobitex and ARDIS, though? To my knowledge Mobitex actually remains available in the US to this day, but I believe ARDIS fizzled out after Motorola divested the operation. I have a hard time shedding too many tears for these services, because since they were basically just packet-switched radio networks, modern cellular networks can outdo them on essentially all metrics. Mobitex and ARDIS were generally more reliable than modern cellular data, part of the reason they survived so long, but a lot of this realistically is just due to their low data rates and low subscriber counts. A Mobitex weighed down by a city worth of Instagram users would presumably collapse just as much as LTE does at the state fair.

It is, however, notable that many of these older technologies were quite amenable to being stood up by a government or company as a private network. That's something that isn't especially easy for a private company to achieve today, even if they for reason wanted to (I want to). Most radio data protocols that are available on an unlicensed basis or that it's reasonably easy to obtain licenses for are either low-speed or require directional antennas and short ranges. This is even true in the amateur radio world, although it's fairly clear there that progress has been held back by the FCC's archaic rules regarding data rates. I think that this essentially comes down to the strong competition between cellular carriers meaning that any bandwidth freed for broadband data applications ends up going for a high value at auction, not to Joe Schmuck who put in a license application. Perhaps we're better off anyway as shared networks (the cellular carriers) are presumably always going to be more economical... but given the reliability and customer relationship issues that mobile carriers often face it's not clear to me that the business world wouldn't have more interest in private networks if they were reasonably achievable.

Low-power unlicensed LTE does present one opportunity, and I'll let you know when I one day give in and buy a low-power LTE base station for my roof.

[1] By "screen as message" I refer to the interface design common among IBM and other mainframe applications, and formalized in various standards such as ISPF, in which the interface is screen-oriented rather than line-oriented---meaning that the mainframe paints an entire screen on the terminal, the user "edits" the screen by filling in form fields and etc, and the terminal sends the entire screen back and waits for a new one. I actually find this UI paradigm to be remarkably intuitive even in textmode (it is a direct parallel to "documents" and "forms") and regret that, largely due to simple technical limitations, the microcomputers that took over in the '90s mostly discarded this design in favor of a line-oriented command shell. Web applications are (or at least were, before SPAs) based on a very similar model which I think shows that it has some enduring value, but it's very hard to find any significant implementation in textmode today outside of a few Newt-based Linux tools which suffer from Newt's UX being, frankly, an absolute mess compared to IBM's carefully planned and researched UX conventions. Besides, most of us still have 12 function keys, might as well actually use them.

--------------------------------------------------------------------------------

>>> 2020-12-15 weird wireless

To start with, as a result of a brief and uncomfortable brush with fame I have acquired a whole lot more readers. As a result, I pledge to make a sincere effort to 1) pay a little more attention when I mash my way through aspell check on each post, 2) post more regularly, and 3) modify my Enterprise Content Management System so that it is slightly more intelligent than cating text files in between other text files. Because it's a good idea to only make promises you can keep, I have already done the third and hopefully text now flows more coherently on mobile browsers and/or exceptionally narrow monitors. I am also going to start the process of migrating the mailing list to a service that doesn't, amusingly, repeatedly bungle its handling of plaintext messages (HTML is somehow easier for MailChimp), but rest assured I will move over the subscriber list when I do that. I am still recovering from years of trauma with Gnu Mailman as a mail server admin, so mass email sending is not something I can approach easily.

I will not, however, make the ASCII art heading represent properly at narrower than 80 characters. Some things are simply going too far.

So after the topic of odd scanner regulation around cellular phones, I wanted to talk a little more about cellular phones. The thing is, I have decided not to try to explain the evolution of current cellphone standards because it is not something I have any expertise in and frankly every time I try to read up on it I get confused. The short version is that there are two general lineages of cellular standards that are (mostly incorrectly) referred to as CDMA and GSM, but as of LTE the two more or less merged, differentiating CDMA and GSM phones by what they fall back to when LTE is not available. Then 5G happened which somehow made the situation much more complicated, and is probably a government conspiracy to control our minds anyway.

On a serious note, one of the legacy cold war communications systems I am very interested in is GWEN, the Ground Wave Emergency Network. GWEN was canceled for a variety of reasons, one of which was up-swell of public opposition founded primarily in conspiracy theories. The result is that it's hard to do much research on GWEN today because you keep finding blogs about how cell towers are actually just disguised GWEN sites being used to beam radiation into our homes. GWEN itself has a slightly interesting legacy, it was canceled before it achieved full capability but a number of sites had already been built. The more coastal of those sites ended up being transferred to the Coast Guard which reused them as stations for their new Differential GPS network[1], so a large portion of DGPS sites were just disused GWEN sites. DGPS was replaced with NDGPS which itself has recently been decommissioned, in part because the FAA's Wide Area Augmentation System (WAAS) is generally superior and can also be used for maritime purposes. So the GWEN sites have now died two deaths.

So we can all hopefully agree to call that tangent a segue to the topic I really want to discuss: less-well-known terrestrial mobile communications systems. Basically, I want to take the family tree of pagers and cellular phones and call out a few lesser known members of the order.

Let's talk first about pagers. Pagers have largely died out, but I had the fortune of working in a niche industry for a bit such that I carried one around with me. Serious '80s drug dealer vibes. The basic idea of the pager is very simple: there is a radio transmitter somewhere, and a bunch of people carry around belt-pack pagers that beep at them when the radio transmitter sends a message intended for them. In its late forms, it was essentially a dedicated text-messaging infrastructure, although early pagers delivered no payload at all (only the fact that a message existed) and later pagers, many into the '90s, only delivered the phone number of the caller.

By the '90s though not only had alphanumeric pagers come about with full text message capability, two-way alphanumeric pagers had been introduced where it was possible to respond. Two-way pagers basically represent a weird mutation on the way to modern cellphones and so I won't discuss them too much, I'm more interested in the "pager" as distinguished by being a strictly one-way device. This is, for example, the reason that I sometimes jokingly refer to my phone as my pager: I detest typing on it so much that I often use it was a one-way device, responding to messages I receive later when I'm at a computer.

Pagers have gone through a number of different technical evolutions, but most modern pagers run a protocol called POCSAG. One of the reasons for widespread standardization on POCSAG is that it is not uncommon for institutions to operate their own private paging transmitters, so standardization is more or less required to make a sale to any of these users (which today probably represent most of the paging market). Understanding this requires commenting a bit on another huge way that pagers are differentiated from cellular networks.

Modern cellular phones (and really all cellular phones if you use the term strictly) employ a "presence" or "registration" system. Essentially, as you walk the mean streets of suburban Des Moines your cellular phone is involved in an ongoing dialog with base stations, and central systems at your provider continuously keep track of which base station your cellphone is in contact with. This way, whenever you get a call or text message or push notification, the system knows which base station it should use to transmit directly to your phone---it knows where you are.

Pagers, excepting some weird late-model pager-ish things, don't have any such concept. The pager itself has no transmitter to advertise its whereabouts (this is a large portion of why pagers remain in use today). Instead, every page destined for a pager must be sent via every transmitter that that pager might be near.

You can imagine that this poses inherent scalability limitations on pagers. When you purchase pager service from a commercial provider, you generally have to specify if you want "city," "regional," or "nationwide" service. This really just determines whether they will transmit your pages in just your city, throughout a state or other regional area, or nationwide. Nationwide service is surprisingly expensive considering cellphone competition. Even then, paging transmitters tend to only be located in more urban areas and so coverage is poor compared to cellphones.

This limitation of pagers, though, is also an advantage. The simplicity of the total paging system (just encode messages and send them out a transmitter, no huge technology stack involved) encourages private paging systems. In my area, hospitals and universities operate private paging systems, and government facilities contract them out but still to a local, small-scale scheme that is effectively private. They're particularly popular with hospitals because an already-installed paging system is fairly cheap to maintain, it's guaranteed to work throughout your building if you put the transmitter on the roof (not something cellphones can always offer in large, byzantine hospitals), and as long as your staff live reasonably nearby their pagers will work at home as well[2].

So that's "what a pager is" at a bit of a technical level. More interesting to me are some pager-adjacent devices, such as the Motorola MINITOR. MINITORs are so popular with volunteer fire departments that you can pretty reliably identify volunteer firefighters by the MINITOR on their belts, although the nineteen bumper stickers and embroidered hat tend to give it away first.

So what is a MINITOR and how does it relate to a pager... this requires getting a little bit into radio systems and the concept of a coded squelch. Let's say that you are, example out of nowhere, a fire department. You have a VHF or UHF FM radio system that you use to communicate between dispatch and units. When dispatch receives an event they want to notify the units that should respond, but they don't want to wake up the entire department. One common way of achieving this is some manner of coded squelch. This is not the only application of coded squelches (they're often used just as a way to minimize false-positive squelch opens), but it's one of the most complex and interesting.

The idea is this: instead of a given radio just opening squelch (enabling the speaker basically) when it receives a carrier, the radio will only open the squelch when it receives a specific tone, series of tones, data packet, or other positive message that that radio is supposed to open squelch. By programming different tone sequences into different radios, the dispatcher can now "selective call" by transmitting only tone sequences to open squelch for the specific units they wish to contact.

There are two major coded squelch systems used in public safety (actually there are a ton but these are the two most widely seen on analog, non-trunking FM systems): two-tone, also called Selcall, and Motorola MDC. Two-tone is the format supported by MINITORs and probably the more common of the two because it has more cross-vendor support, but it's also much more primitive than MDC.

The concept of two-tone selective calling is very simple and you can probably guess from the name: Before a voice transmission, essentially as a preamble, the transmitter sends two tones in sequence, each for about a second. Yes, this takes a while, especially if calling multiple units, enough that it's not done on key-up like MDC or many other selective calling schemes. Instead, the dispatcher's radio console usually has a dedicated button that starts sending tones and they have to wait until it's good and ready before they talk. It's not uncommon to hear the dispatcher say something like "wait for tones" or "tones coming" to warn others that things will be tied up for a bit.

So how does this all relate to paging... the MINITOR and other devices like it are basically handheld radios with the entire transmit section removed. Instead, they are only receivers, and they are equipped with a two-tone decoder. So if you are, say, a volunteer firefighter, you can carry a MINITOR which continuously monitors the dispatch frequency but only opens squelch if it receives a two-tone sequence indicating that the dispatcher intends to activate a given group of volunteers. This is basically a paging system, but simply "built in" as a side feature of the two-way FM radio system.

I'll also mention MDC briefly. MDC is a more sophisticated system that uses a short FSK data packet as the selective calling preamble. This transmits quickly enough that the radios simply send it every time the PTT is pressed. This allows some more advanced features, for example, every time someone in the field transmits the dispatcher's console can tell them the ID of the radio that just transmitted. Auxiliary information in addition to addressing can also be send in the MDC preambles. MDC is also very popular in public safety and if you've spent much time with a scanner you'll probably recognize the sound of the MDC preamble. It's actually very common to mix-and-match these systems, for example, some fire departments use MDC but also send Selcall tones when dispatching, often specifically to trigger MINITORS.

Selective calling systems in public safety are often also used to trigger outdoor warning systems such as sirens, which are of course one of my favorite things. A surprising number of outdoor sirens used in tornado-prone areas, for college campus public safety, etc. are just equipped with a radio receiver monitoring a dispatch frequency for a specific selective call. This can interact in amusing ways with "mixed" selective calling. I used to work on an Air Force base with a fairly modern Federal Signal outdoor warning system. When it played Reveille and Retreat each day it sounded fine, but when they tested the emergency sirens one day a week you actually heard MDC and then Selcall tones over the speakers before the siren. My assumption is that regularly scheduled events like Reveille were played via a Federal Signal digital system while emergency alerts went out over some force protection dispatch frequency, and the "siren" speakers opened squelch in reaction to some Federal Signal-specific preamble that was sent before the preambles used for mobile radios. As another anecdote, the US military has the charming habit of referring to all outdoor warning systems as "Giant Voice," which was the brand name of a long-discontinued Altec Lansing system that had been very popular with DOD. Other siren systems are triggered using telephone leased-lines, and of course on modern systems there are options for cellular or other more advanced data radio protocols.

There are also a number of other selective calling systems in use. Another example I am aware of is a proposal among amateur radio groups called "long tone zero," which suggests that persons experiencing an emergency should tune to a nearby repeater and transmit a DTMF zero for several seconds. The idea is that other radio amateurs who wish to be helpful but not have their ears glued to their radios (or more likely be woken up at night) can set up a software or hardware detector for the zero digit and essentially use it as a selective-calling scheme, with their radio (presumably with the volume cranked to eleven) only opening squelch upon receiving a long-tone-zero. It's a clever idea but to my knowledge not one that is widely enough implemented to be particularly useful. Of course selective calling is also widely used to open the squelch on repeaters but I find that less interesting.

A similar scheme that is oddly well-known to the public ear is employed by the Emergency Alert System and NOAA All-Hazards Radio. Those "emergency weather radio" receivers you buy at the store from the likes of Midland monitor an All-Hazards Radio frequency but only open squelch when they receive a preamble indicating that there is an emergency notification. Historically this was based on a simple dual-tone scheme (the tones that are now used as the emergency alert ringtone on most cellphones), but nowadays a digital scheme is used that allows the radio to know the type of alert and area it applies to. This is actually how EAS messaging is triggered on many television and radio stations as well. I will devote a whole post some time to the history of the Emergency Alert System in its various outdated and modern versions, because it's really pretty interesting---and frankly I am amazed that incidents of unauthorized triggering of EAS are not more common, as the measures in place to prevent it are not particularly sophisticated.

So that's one pager-adjacent thing. Let's talk a bit about a different pager adjacent thing, and one that I know less about because it's more proprietary and less frequently heard in the modern world: taxi and freight dispatch.

Several manufacturers used to build taxi dispatch systems that allowed for individually addressed text messages to specific receivers installed in cabs. This is basically a pager system but using a larger display, and the systems were almost always two-way and allowed the cab driver to at least send a response that they were on the way. The system in use and its technical details tended to vary by area and it's hard for me to say too much in general about them, other than that they have been wholly replaced today by cellular systems.

A system similar to taxi dispatch systems is ubiquitous in the freight trucking industry, but is far more standardized. Qualcomm Omnitracs is an integrated hardware and service product that places a small computer in the cab of a truck which both reports telemetry and exchanges text messages between the driver and dispatcher. The system has been bought and sold (I don't think Qualcomm even owns it any more) and has been moved from technology to technology over years, but for most of its lifespan it has relied on a proprietary satellite network. This gives it the advantage of being more reliable in between urban areas than cellular, although the fact that the system is now available in a cellular variant shows that this advantage is getting slimmer. It's also the reason that a great many semi tractors feature a big goofy radome, usually mounted behind the roof fairing. You just don't see that kind of antenna on vehicles very often. Like most satellite communications networks, Omnitracs relies on the messages being small and infrequent (very low duty cycle) to make the service affordable to operate.

What I particularly like about the Omnitracs system (which seems to be widely referred to by truckers as Qualcomm regardless of who owns it now) is that the long near-monopoly it enjoyed, and probably its relationship to a big engineering operation in Qualcomm, lead to some very high quality hardware design compared to what we expect from communications devices today. The system was always designed to be usable on the road, and featured a dash-mounted remote control and speech synthesizer and recognition (to hear and reply to messages) long before these became highly usable on cellphones. The system also integrates secondary features like engine performance management and even guided pre-trip checklists. It's an example of what can be achieved if you really put hardware and software engineering expertise into solving a specific problem, which has become uncommon now that the software industry has realized it is cheaper (at the expense of user experience, productivity, etc) to solve all problems by taping iPads to things. And that's the direction that freight dispatch is increasingly going today, "integrated products" that consist of a low-end Android tablet in a dashboard mount running some barely stable app that is mostly just a WebView. And taxi dispatch barely even exists now because silicon valley replaced the entire taxi with an iPhone app, which if you think about it is kind of amazing and also depressing.

These two topics get very close to the world of mobile data terminals, and that's what I'll talk about next. MDTs are car-mounted computers often used by first responders and utility crews, and while nowadays "MDT" usually just means a Panasonic Toughbook with an LTE modem (maybe for a municipal LTE network), historically it referred to much more interesting systems that paired a Panasonic Toughbook with a VHF/UHF data modem that relied on some eccentric protocols and software stacks. One thing has never changed: Panasonic Toughbooks are way overpriced, even on the government surplus market, which is why I still don't have one to take apart.

So I'll talk a bit about MDTs and the protocols they use next, since in many ways they're more the ancestors of our modern smartphones than actual phones.

So, is there any big conclusion we can draw from looking at these largely "pre-cellular" (but still present today) wireless systems? I don't know. On the one hand, in some ways these confirm one of my theses that increasing commodification of software and hardware tends to make technology solutions less fit for purpose rather than more. That is, technology devices today are better only in a certain way, and worse in other ways in that increasing abstraction, complexity, and unification of design tends to eliminate features which are specific to a given application (everything is an iOS and/or Android app now, and half of those are really just websites) and increase complexity for users (what was once a truck dispatch system is now an Android tablet with all the ways that can go wrong).

At the same time, these effects tend to drive the cost of these devices down. So you might say that everything from semi-truck dispatch to restaurant POS (a favorite example of mine) is now more available but less fit for purpose. This is one of the big themes of my philosophy, and is basically what I mean when I say "computers are bad," so I hope to explore it more in this blog newsletter thing. So next time, let's try to look at mobile data terminals and dispatch systems under that framework---how is it that they have become cheaper and more available, but at the same time have gotten worse at the purpose they're intended for? But mostly we'll talk about some old radio data protocols, because those are what I love.

Postscript: now that I have 100+ email subscribers and probably as many as ten people who somehow still use RSS (I don't know, I don't really have any analytics because I'm both lazy and ethically concerned about delivering any Javascript whatsoever[3]), I'd love feedback. What do people find most interesting about my rambles? What do they want to hear more about? You can always email me at me@computer.rip, or hit me up on Matrix at @jesse:waffle.tech. If you send me an email I like enough I'll throw it in here sometime like an old-fashioned letter to the editor. Like The Economist, if you do not begin it "SIR -" I will edit it so that people think you did.

[1] Differential GPS is an interesting technique where a site with a known location (e.g. by conventional survey techniques) runs a GPS receiver and then broadcasts the error between the GPS fix and the known good location. The nature of GPS is that error tends to be somewhat consistent over a geographical region, e.g. due to orbital perturbations, so other GPS users in the area can apply the reverse of the error calculated by the DGPS site and cancel out a good portion of the systematic error. The FAA WAAS system was designed to enable RNAV GPS approaches, basically aircraft instrument operations by GPS. The main innovation of WAAS over DGPS/NDGPS is that the correction messages are actually sent back to orbit to be broadcast by satellites and so are available throughout North America.

[2] A huge downside to this is that POCSAG lacks any kind of security scheme. I have personally found more than one hospital campus transmitting patient name, DOB, clinical information, and occasionally SSN over an unencrypted POCSAG system. My understanding is that, from a legal and regulatory perspective, this is basically an accepted practice right now. Maybe congress will pass legislation against POCSAG decoders.

[3] I am not Richard M. Stallman, although I did once spend much more time than I am comfortable with in his presence. I'm more like Jaron Lanier, I guess. My ethical concern about delivering Javascript is not that it removes your control of your personal computer or whatever, but rather that it feels like the gateway drug to pivoting to a social network and creating a Data Science department. When it comes to modern webdev, "DARE To Say No to SPAs and Websockets." Oh god I'm going to design a T-shirt.

--------------------------------------------------------------------------------
<- newer                                                                older ->