TransSys Internetworking

April Fool's Prank of 1995

Louis Mamakos — Mon, 30 Dec 2024 04:43:49 GMT

In 1995, I was working for UUNET Technologies, running the network engineering group there. We were one of the very first large ISPs, growing rapidly and building a global backbone. The story of UUNET is long and glorious while were were inventing and building the early commercial Internet. That's a story for another day.

Historical Context

The Internet was new and there were many new hangers-on that had started to take notice of what was happening. This was still in the early dial-up Internet days (and UUNET had deploy hundreds of thousands of dial-up Internet access ports that we wholesales to the likes of MSN, AOL, WebTV and others that have long been forgotton..)

At the time, I had a little side-hustle where I had written some software for the fancy new NeXT computers that had arrived on the scene. Imagine! A UNIX computer that you could (almost) afford to buy for yourself! It enabled your NeXTStep computer to use a dial-up modem connection and communicate using SLIP and CSLIP for Internet access. Yeah, this seems both unfamiliar and mundane, but there was a time when operating systems didn't do dial-up Internet access out of the box..

The software was rather clever, if I say so myself. It was a modular and highly configurable system that did pretty much everything in userspace code, rather than in the kernel. Now, I had to write a UNIX tunnel interface for NeXTStep because it didn't do that out of the box.. All written in Objective-C, which was rather clever. And a good chunk of the NeXTStep OS ended up back at Apple when Steve Jobs returned and you can smell it inside of macOS even to this day.

It was flexible because units of functionality were modular and could be "stacked" to produce some behavior. So at one end was the module that talked to the kernel to get packets in and out of user space. Minimally, you would then have the SLIP/CSLIP module that took the packets and did the SLIP/CSLIP encapsulation which added framing characters (0xC0) and escaped the framing characters embedded in the packet.

Then you'd stack on the module that talked to the serial port and modem; this was more complicated than it appeared. It was the thing that also did dial-on-demand, knew what AT commands to send to the modem, configured the serial port for flow control and baud rate, etc.

Because of the modularity, you could stack other modules in the middle, such as one that would do DES encryption and decryption on the payload. This was mostly a proof-of-concept - I was pretty ignorant of things like replay attacks, chosen-plaintext attacks, etc. But it was really easy to plug in a module to do anything you wanted on the stream of packets or bytes going by.

Because I was enamoured by such things, it was all orchestrated and configured using TCL.

So what about this prank thing?

So early in 1995, I'm thinking that April Fool's day is approaching. In the early Internet days, it was a very small world; and a tight knit community of people building and growing this Internet thing, making it up as we go along. And trying hard to do the right thing. One tradition in the community was observing April Fool's day. If you look at the Internet RFC series, you'll see a number of "April Fool's Day" RFCs, including how to transport packets using Avian Carriers, etc. So I thought I'd do my own April Fool's Day prank.

I had my NeXT computer at home, running my software. I had at least a /24 of address space routed to me over the dial-up link. Because that's how we rolled in those days if you were in the Internet biz. Remember, this Internet stuff was pretty new. And one of our prime debugging tools in trying to figure out WTF was happening was the traceroute tool. We used that all the time.

Well, how does traceroute work? It sends packets toward a destination, but manipulates the TTL (time-to-live) header field, which is how many more forwarding hops this packet is allowed. This value is decremented by one each time the packet is forwarded, and this is how forwarding loops are broken. When the TTL is decremented to zero, and ICMP error message ("Destination Unreachable: Time Exceeded") is generated and sent back to the source address in the packet. So when the traceroute program is probing a path, it sends out messages with a TTL of 1, sees where that expires, increments it, sends another probe and continues with ever increasing TTLs to probe each router along the path.

Heck, I have this user-mode stack just lying about. And I've written an IP/TCP stack once or twice before; generating ICMP messages isn't that hard..

So I wrote a WORMHOLE module for my software. You could configure it to match on an IP address, and generate an ICMP message. The source of the IP address (the intermediate "router" where the packet TTL went to zero) could be selected. And my software allowed you to configure, for each destination IP address it matched, a list of IP addresses that would be chosen (indexed by the TTL of the package) as the reporting address.

You could also specify a delay before returning a response for each hop. Handy for making surprising behavior like responses from further hops away coming back faster than the first few hops. Or impossible delays due to speed-of-light for the purported sources. (Packets from "Japan" are not going to arrive in 20 milliseconds!)

The Thing

To: com-priv@psi.com, ietf@CNRI.Reston.VA.US
From: "Louis A. Mamakos" <louie@42.42.202.144.IN-ADDR.ARPA>
Reply-To: louie@202.144.IN-ADDR.ARPA
Subject: On hyper-spatial network links and wormholes on today's Internet
Date: Sat, 01 Apr 1995 20:23:17 -0500
Sender: louie@wa3ymh.transsys.com

Please pardon the wide distribution of this message, but considering
the timeliness of the issue at hand, I wanted to reach the right
audience as quickly as possible to explore the issue while it's still
in it's prime.  This has to do with both some research issues as well
as commercial use and provision of Internet services.

I've been doing some research on network paths, delay and propagation
on the Internet.  As many of you know, today's Internet isn't the
neat, simple thing that it was just 5 years ago.  That Internet could
be described as a mostly hierarchal system of networks, and used
relatively simple routing protocols, such as RIP and EGP to maintain
global connectivity.

The connectivity on the Internet today is much more complex and
considerably less easy to model.  There is no "backbone" network which
provides transit at the top level of any hierarchy.  The world isn't
just a simple tree.  Today's network is a complex, world-wide "web" of
connectivity between different providers of Internet connectivity and
service.  There are networks run by commercial concerns, non-profit
entities, government agencies and other interested parties.

I was attempting to characterize some of these connectivity paths
using the popular and familiar "traceroute" tool.  This is a handy
tool for investigating the routing which packets take on their way to
a specified destination.  This is done by transmitting "probe" packets
addressed to the destination, with varying TTL (Transit Time Limit)
values, and awaiting the response of ICMP (IP Control Message Pings)
responses.  (ICMP is normally used by the "PING" tools to measure
response times).

In the process of doing this investigation, I have encountered what
appears to be abnormal connectivity paths to destinations.  These
paths are *very* unusual in that the paths is highly dependent on the
destination address; even minor changes in the destination address
seem to have wildly different effects on the path.  It is as if there
is some effects on the path at the "quantum" level, where even minor
differences in the host path seem to have path warping effects.

My initial thought was that perhaps there was some experimental
deployment of new routing protocols causing difficulties, such as
S-DRIP, but further investigation reveals that the source of the
traceroute pings have no effect once the paths crosses a point which
seems to be a discontinuity in the routing fabric.

Further, some of the probed paths seems to cross normal paths on
well-known provider's networks.  That is, a path which would normally
proceed across (e.g.,) SprintLink would be intertwined with a path
across (e.g.,) ANS.  Consider this one:

$ traceroute 144.202.90.1
traceroute to 144.202.90.1 (144.202.90.1), 30 hops max, 38 byte packets
 1  en-0.ENSS136.t3.ANS.NET (192.41.177.253)  60 ms  29 ms  28 ms
 2  t3-0.cnss58.Washington-DC.t3.ans.net (140.222.58.1)  116 ms  73 ms  93 ms
 3  sl-mae-e-F0/0.sprintlink.net (192.41.177.241)  186 ms  164 ms  187 ms
 4  sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41)  280 ms  257 ms  279 ms
 5  t3-1.cnss72.Greensboro.t3.ans.net (140.222.72.2)  364 ms  351 ms  366 ms
 6  sl-dc-7-F0.sprintlink.net (144.228.20.7)  455 ms  445 ms  460 ms
 7  t3-0.cnss104.Atlanta.t3.ans.net (140.222.104.1)  561 ms  538 ms  553 ms
 8  t3-1.cnss16.Los-Angeles.t3.ans.net (140.222.16.2)  656 ms  633 ms  647 ms
 9  t3-2.cnss64.Houston.t3.ans.net (140.222.64.3)  735 ms  729 ms  742 ms
10  sl-starnet-1-S0-T1.sprintlink.net (144.228.27.6)  828 ms  808 ms  834 ms
11  t3-2.cnss8.San-Francisco.t3.ans.net (140.222.8.3)  937 ms  916 ms  931 ms
12  1.90.202.144.in-addr.arpa (144.202.90.1)  1030 ms  1006 ms  1021 ms

Could this be the case of some mutual cooperation between ANS and
SprintLink?  This seems highly unlikely, in that core backbone links
seem to be involved.  Could this be a problem with the underlying
transmission fabric?  This, too, seems unlikely given that the Cisco
routers on Sprintlink would likely have an incompatible link-level
protocol with the RS6000 routers used by ANS.  Besides, the
TOPS20-like operating system in the Ciscos are incompatible with the
AIX OS used on the IBM platforms.

Thinking that this was simply "one of those weird-ass Internet things",
I probed a different address:

$ traceroute 144.202.90.2
traceroute to 144.202.90.2 (144.202.90.2), 30 hops max, 38 byte packets
 1  Alternet-GW.TransSys.COM (144.202.42.1)  63 ms  28 ms  26 ms
 2  Falls-Church1.VA.ALTER.NET (137.39.3.33)  93 ms  99 ms  93 ms
 3  Falls-Church4.VA.ALTER.NET (137.39.8.1)  187 ms  165 ms  188 ms
 4  IBMpc01.UU.NET (153.39.1.1)  280 ms  257 ms  272 ms
 5  IBMpc02.UU.NET (153.39.1.2)  374 ms  352 ms  366 ms
 6  ftp.UU.NET (192.48.96.9)  455 ms  444 ms  461 ms
 7  ftp.microsoft.com (198.105.232.1)  561 ms  523 ms  554 ms
 8  hubbub.cisco.com (198.92.30.32)  641 ms  635 ms  648 ms
 9  149.20.64.4 (149.20.64.4)  749 ms  663 ms  740 ms
10  2.90.202.144.in-addr.arpa (144.202.90.2)  842 ms  818 ms  833 ms

Now this was weird!  The path to the destination seems to be diverted
by "ruts" in the Information Superhighway!  That is, the significant
traffic to some high-volume FTP servers seems to "steer" the traffic
off its normal "lane".  Note FTP.UU.NET, FTP.MICROSOFT.COM,
hubub.cisco.com which is also known as FTP.CISCO.COM.

Well, I was on to something now.  I tried to probe another address on this
network to see if I could further understand the problem:

$ traceroute 144.202.90.3
traceroute to 144.202.90.3 (144.202.90.3), 30 hops max, 38 byte packets
 1  Alternet-GW.TransSys.COM (144.202.42.1)  60 ms  28 ms  27 ms
 2  Falls-Church1.VA.ALTER.NET (137.39.3.33)  115 ms  70 ms  93 ms
 3  Falls-Church4.VA.ALTER.NET (137.39.8.1)  187 ms  164 ms  189 ms
 4  Vienna3.VA.ALTER.NET (137.39.11.4)  281 ms  259 ms  272 ms
 5  134.222.84.1 (134.222.84.1)  366 ms  304 ms  367 ms
 6  iij-gate.iij.net (192.244.176.209)  453 ms  444 ms  459 ms
 7  whitehouse.gov (198.137.241.30)  548 ms  539 ms  554 ms
 8  archie.iij.ad.jp (192.244.176.60)  641 ms  632 ms  647 ms
 9  jatz.aarnet.edu.au (139.130.204.4)  734 ms  878 ms  687 ms
10  DOCKMASTER.NCSC.MIL (26.1.0.172)  829 ms  806 ms  835 ms
11  ns.kreonet.re.kr (134.75.30.1)  929 ms  883 ms  930 ms
12  ard.FBI.GOV (192.108.246.6)  1010 ms  1009 ms  1030 ms
13  oxygen.house.gov (137.18.128.6)  1129 ms  1093 ms  1117 ms
14  3.90.202.144.in-addr.arpa (144.202.90.3)  1218 ms  1183 ms  1209 ms

Now, things are getting truly bizzare.  What originally seemed to be a
"local", US phenomenon seems to have broadened into something of truly
world-wide scope.  Here is also the first evidence of carriage of
traffic by governmental agencies, which claim to be out of the
business of subsidizing internet backbones.

Further, we see some very weird physical behavior manifesting itself
in the temporal domain.  Notice how the measured delta delay times
seems to be approximately 89 milliseconds per hop, regardless of the
distance between the two points.  It is as if there are hyper-spatial
paths with constant propagation times independent of the distance
which connect these sites.  This is much the same as hyperlinks on
HTML documents take readers from one document to another, anywhere on
the planet.

I made another probe to attempt to characterize this "tear" in the
routing fabric of the Internet:

$ traceroute 144.202.90.4
traceroute to 144.202.90.4 (144.202.90.4), 30 hops max, 38 byte packets
 1  en-0.ENSS136.t3.ANS.NET (192.41.177.253)  59 ms  28 ms  28 ms
 2  t3-0.cnss58.Washington-DC.t3.ans.net (140.222.58.1)  94 ms  71 ms  95 ms
 3  sl-mae-e-F0/0.sprintlink.net (192.41.177.241)  187 ms  162 ms  187 ms
 4  sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41)  281 ms  257 ms  272 ms
 5  border2-hssi4-0.Washington.mci.net (204.70.57.9)  370 ms  274 ms  366 ms
 6  t3-1.cnss72.Greensboro.t3.ans.net (140.222.72.2)  453 ms  447 ms  460 ms
 7  sl-dc-7-F0.sprintlink.net (144.228.20.7)  562 ms  539 ms  553 ms
 8  t3-0.cnss104.Atlanta.t3.ans.net (140.222.104.1)  656 ms  633 ms  647 ms
 9  core-hssi-3.SanFrancisco.mci.net (204.70.1.38)  735 ms  648 ms  742 ms
10  t3-2.cnss64.Houston.t3.ans.net (140.222.64.3)  829 ms  820 ms  835 ms
11  pacnap-e0/0.net99.net (204.157.38.2)  923 ms  915 ms  929 ms
12  sl-starnet-1-S0-T1.sprintlink.net (144.228.27.6)  1019 ms  995 ms  1027 ms
13  core-hssi-2.Seattle.mci.net (204.70.1.49)  1112 ms  1028 ms  1119 ms
14  t3-2.cnss8.San-Francisco.t3.ans.net (140.222.8.3)  1206 ms  1196 ms  1210 ms
15  4.90.202.144.in-addr.arpa (144.202.90.4)  1300 ms  1287 ms  1303 ms

Now, this is a very similar path to the first attempt.  But notice how
a slight change in the address, that of the last octet changing from 1
to 4 made?!  Notice that the total number of bits in the address did
not change, only the position of the last bit.  Yet this slight change
causes further anomalies in the path.  

It is as if the packet is caught in some wormhole-like discontinuity
in the link-space-time continuum of the Internet; the packet is on a
link, minding it's own business, when it suddenly experiences some
warp effect and is transported on to another link on the Internet.

These are the only addresses which I've discovered, to date, which
experience these bizzare effects.  Perhaps it's the pattern of the
address bits, when converted into symbols for transmission over common
transmission facilities which provokes this effect via some yet to be
understood or determined mechanism.

I invite you, the interested reader, to probe this stable phenomenon
with traceroute in further attempts to understand what's going on.

This is a strange time for this to be happening on the Internet, where
we have better routing protocols and technologies than at any other
time in the past.

Louis Mamakos

This resulted in a bunch of email messages, congratulating me on my funny message. Ha, ha, very funny! To these, I replied:

To: sgoldste@nsf.gov (Steve Goldstein)
From: "Louis A. Mamakos" <louie@TransSys.COM>
Subject: Re: On hyper-spatial network links and wormholes on today's Internet
Date: Sat, 01 Apr 1995 21:47:11 -0500
Sender: louie@wa3ymh.transsys.com

> Best damn April Fool story yet.  Much better than Petri's.  --SG

Thanks.

Did you try to do any of the traceroutes to those destinations?   They
all work.

That was the actual April Fool's hack..

Louis Mamakos

And people were variously amused and/or horrified.

What did we learn?

You can't believe the source address in an IP packet. These were trivially spoofable just for the purposes of an April Fool's prank; I wasn't even trying to steal your credit card number.

Appendix - if not removed yet

Configuration file

nk.net (192.41.177.241)  187 ms  75 ms  187 ms
#  4  sl-dc-8-H1/0-T3.sprintlink.net (144.228.10.41)  281 ms  91 ms  273 ms
#  5  t3-1.cnss72.Greensboro.t3.ans.net (140.222.72.2)  374 ms  265 ms  367 ms
#  6  sl-dc-7-F0.sprintlink.net (144.228.20.7)  453 ms  368 ms  460 ms
#  7  t3-0.cnss104.Atlanta.t3.ans.net (140.222.104.1)  561 ms  448 ms  555 ms
#  8  t3-1.cnss16.Los-Angeles.t3.ans.net (140.222.16.2)  655 ms  540 ms  647 ms
#  9  t3-2.cnss64.Houston.t3.ans.net (140.222.64.3)  736 ms  119 ms  742 ms
# 10  sl-starnet-1-S0-T1.sprintlink.net (144.228.27.6)  843 ms  743 ms  835 ms
# 11  t3-2.cnss8.San-Francisco.t3.ans.net (140.222.8.3)  936 ms  727 ms  929 ms
# 12  1.90.202.144.in-addr.arpa (144.202.90.1)  1018 ms  1008 ms  1022 ms

set list(144.202.90.1) { 192.41.177.253 140.222.58.1 192.41.177.241
    144.228.10.41 140.222.72.2 144.228.20.7 140.222.104.1 140.222.16.2
        140.222.64.3 144.228.27.6 140.222.8.3 }

# traceroute to 144.202.90.2 (144.202.90.2), 30 hops max, 38 byte packets
#  1  Alternet-GW.TransSys.COM (144.202.42.1)  198 ms  29 ms  26 ms
#  2  Falls-Church1.VA.ALTER.NET (137.39.3.33)  46 ms  23 ms  100 ms
#  3  Falls-Church4.VA.ALTER.NET (137.39.8.1)  187 ms  165 ms  187 ms
#  4  IBMpc01.UU.NET (153.39.1.1)  280 ms  87 ms  272 ms
#  5  IBMpc02.UU.NET (153.39.1.2)  361 ms  23 ms  366 ms
#  6  ftp.UU.NET (192.48.96.9)  467 ms  369 ms  460 ms
#  7  ftp.microsoft.com (198.105.232.1)  561 ms  523 ms  554 ms
#  8  hubbub.cisco.com (198.92.30.32)  655 ms  212 ms  647 ms
#  9  149.20.64.4 (149.20.64.4)  748 ms  508 ms  741 ms
# 10  2.90.202.144.in-addr.arpa (144.202.90.2)  841 ms  805 ms  834 ms

set list(144.202.90.2) { 144.202.42.1 137.39.3.33 137.39.8.1 153.39.1.1
    153.39.1.2 192.48.96.9 198.105.232.1 198.92.30.32 149.20.64.4 }

# traceroute to 144.202.90.3 (144.202.90.3), 30 hops max, 38 byte packets
#  1  Alternet-GW.TransSys.COM (144.202.42.1)  58 ms  27 ms  27 ms
#  2  Falls-Church1.VA.ALTER.NET (137.39.3.33)  47 ms  98 ms  93 ms
#  3  Falls-Church4.VA.ALTER.NET (137.39.8.1)  187 ms  165 ms  187 ms
#  4  Vienna3.VA.ALTER.NET (137.39.11.4)  281 ms  212 ms  276 ms
#  5  134.222.84.1 (134.222.84.1)  374 ms  198 ms  369 ms
#  6  iij-gate.iij.net (192.244.176.209)  468 ms  22 ms  460 ms
#  7  archie.iij.ad.jp (192.244.176.60)  561 ms  241 ms  554 ms
#  8  jatz.aarnet.edu.au (139.130.204.4)  640 ms  24 ms  648 ms
#  9  ns.kreonet.re.kr (134.75.30.1)  749 ms  218 ms  741 ms
# 10  DOCKMASTER.NCSC.MIL (26.1.0.172)  842 ms  479 ms  835 ms
# 11  whitehouse.gov (198.137.241.30)  937 ms  640 ms  932 ms
# 12  ard.FBI.GOV (192.108.246.6)  1017 ms  777 ms  1027 ms
# 13  oxygen.house.gov (137.18.128.6)  1111 ms  899 ms  1116 ms
# 14  3.90.202.144.in-addr.arpa (144.202.90.3)  1217 ms  1197 ms  1209 ms

set list(144.202.90.3) { 144.202.42.1
         137.39.3.33
     137.39.8.1
     137.39.11.4
    134.222.84.1
    192.244.176.209
    198.137.241.30
    192.244.176.60
    139.130.204.4
    26.1.0.172
    134.75.30.1
    192.108.246.6
    137.18.128.6 }

# happy april fool day
set list(144.202.90.5) { 144.202.9.31 144.202.9.32 144.202.9.33 144.202.9.34 }

# if you lived here you packet would be home by now
set list(144.202.90.6) { 144.202.9.0 144.202.9.1 144.202.9.2 144.202.9.3 \
    144.202.9.1 144.202.9.5 144.202.9.6 { 144.202.9.7 50 } { 144.202.9.8 30} \
            {144.202.9.9 40} {144.202.9.10 10} }

# you are trapped in a maze of twisty little passages all alike
set list(144.202.90.7) { 144.202.9.1 144.202.9.18 144.202.9.22 144.202.9.21 \
    144.202.9.23 144.202.9.25 144.202.9.26 144.202.9.24 144.202.9.27 \
             144.202.9.28 144.202.9.29 144.202.9.30 }

# you are trapped in a maze of little twisty passages all alike
set list(144.202.90.8) { 144.202.9.1 144.202.9.18 144.202.9.22 144.202.9.21 \
    144.202.9.23 144.202.9.25 144.202.9.26 144.202.9.27 144.202.9.24 \
             144.202.9.28 144.202.9.29 144.202.9.30 }

# you are trapped in a twisty maze of little passages all alike
set list(144.202.90.9) { 144.202.9.1 144.202.9.18 144.202.9.22 144.202.9.21 \
    144.202.9.23 144.202.9.24 144.202.9.25 144.202.9.26 144.202.9.27 \
             144.202.9.28 144.202.9.29 144.202.9.30 }

# you are trapped in a twisty little maze of passages all alike
set list(144.202.90.10) { 144.202.9.1 144.202.9.18 144.202.9.22 144.202.9.21 \
    144.202.9.23 144.202.9.24 144.202.9.27 144.202.9.25 144.202.9.26 \
             144.202.9.28 144.202.9.29 144.202.9.30 }

# are you dizzy yet
set list(144.202.90.11) { 144.202.9.18 144.202.9.1 144.202.9.19 144.202.9.20 }





proc LINK_start { encap } {
     global Config
     log "LINK $encap connected"
     catch {
        exec /usr/etc/route add net 144.202.90.0 $Config(pni:REMOTEADDRESS) 1
     }
}

proc LINK_stop { encap } {
     global Config
     log "LINK $encap disconnected"
     catch {
        exec /usr/etc/route delete net 144.202.90.0 $Config(pni:REMOTEADDRESS)
     }
}

# -- that's all

Fluke 8050A Display Use and Construction Notes

Louis Mamakos — Sun, 13 Nov 2022 18:58:20 GMT

So you want to build this yourself? And when you do, how do you use it? Here's some hints; this is a long way from the "Heathkit" experience, but ultimately, not that complex.

newRPL Keypad Overlay - v7

Louis Mamakos — Sun, 18 Apr 2021 01:42:27 GMT

I was slightly premature in declaring done before. Here's another version of the newRPL keypad overlay with a few minor tweaks in the button spacing.

Version 7 of keypad overlay

newRPL Keypad Overlay - v6

Louis Mamakos — Mon, 05 Apr 2021 03:46:58 GMT

The newRPL keypad overlay is done! (Well, done enough, at least for now!)

Just a few tweaks on the design: - Rounded the bottom of the openings for the keys on the keypad - Tweaked the position of a few keys for (maybe) better alignment. - Rounded some of the corners of the overlay background.

All the files are available for download if you'd like to print some for yourself.

New overlay

Here's what the overlay looks like now.

Version 6 of keypad overlay

newRPL keyboard overlay version 5

Louis Mamakos — Sun, 28 Mar 2021 22:05:16 GMT

Just an update on the newRPL keypad overlay.

Many mistakes have been made, much has been learned, there has been more progress than retreat. I feel as if I'm getting closer to the end of this process, rather than just further from the beginning of it.

I've incorporated some suggestions in the thread in the overlay. I've also added another label intended to be stuck on the back of the calculator, sized to fit in the shallow recess that has the serial number sticker. This mostly contains the various ON-hold key combinations that may not be used as frequently, but are helpful.

newRPL keyboard template for HP 39gs, 40gs and 50g

Louis Mamakos — Wed, 17 Mar 2021 02:23:40 GMT

I recently discovered newRPL, and before I knew it, I find that I own an HP 39gs, HP 40gs and (most recently) an HP 50g with newRPL installed! I can't explain how this happened, but I'm sure many of you understand how such a thing could happen.

After using newRPL with a handy printed mock-up of the keyboard nearby, I decided to design a keyboard overlay with updated legends to match how newRPL works. I used OpenSCAD to produce an outline with all of the keyboard holes in the right places (or at least pretty close!) I then imported that as a layer in Inkscape to add legends around each key for the left- and right-shifted functions as well as alpha characters. The key tops also have correct labels, too.

Fluke 8050A Multimeter LCD Display Project

Louis Mamakos — Sun, 25 Oct 2020 16:00:00 GMT

Fluke 8050A Multimeter LCD Display Project

This series of web pages attempts to document my project to replace the old monochromatic, 4½-digit, 7-segment LCD numeric display with a 320x240 color TFT graphical display.

more … (10 min remaining to read)

Fluke 3870 microcontroller pin functions

Louis Mamakos — Sun, 25 Oct 2020 03:20:50 GMT

This is a summary of the signals on the 40-pin 3870 "F8" CPU chip in the Fluke 8050A multimeter. It's intended primarily as a reference while wiring up the interconnects from this CPU to the STM32F103 microcontroller.

Fluke 8050A Credits

Louis Mamakos — Sun, 25 Oct 2020 03:20:50 GMT

Fluke 8050A software credits

Various software and resources have been incorporated into this project. Here's a list, hopefully complete. If you notice something missing, please let me know so that I might properly credit the work and update this list.

Forth

Mecrisp Forth is a core component of this project. It is the low-level software that animates the hardware, and a fast and elegant Forth interpreter/compiler that targets ARM Cortex-M3 based CPUs, such as is used in this project.

Fluke 8050A Displays

Louis Mamakos — Sun, 25 Oct 2020 03:20:50 GMT

Fluke 8050A Meter Displays

Here are some photos of typical meter displays on the modified Fluke 8050A multimeter with the graphical LCD replacement. Note that the basic functionality of the meter is not changed; it doesn't measure any more frequently, nor with any additional resolution or accuracy.

The fancy new display simply captures and manipulates whatever the Fluke 8050A was sending to it's 7-segment LCD display (and various annunciators). The new display also monitors the state of the various switches on the Fluke 8050A to discover the mode and scale the meter has been switched to, and uses that information to annotate the graphical display.