Sunday, October 11, 2020

 

Why do (American) plugs have holes?

American-style electrical plugs are special in that the prongs “always” have little holes in them:

The question that’s never been answered is why. There have been attempts at answers (and some have some good research). This post is going to evolve over time: my goal is to find as many images of plugs as possible, organized by date.

Right now, it looks like there aren’t any plugs at all in 1916, but there are plugs in 1920.

Update: the funny-looking Hubbell Attachment Plug is listed in the 1906 Hubbell catalog! (page 36)

Another update: Hubbell has a modern looking plug in the January 1916 Electrical Age.


1906 Hubbell Catalog

The 1906 Hubbell Catalog, page 34, includes the somewhat oddly shaped Hubbell Attachment Plug. The plug is a user-applied thing: they rewire their device to use the plug, and then screw the socket into a standard Edison-type (or T.H type) screw base.

It's claimed to have been patented August 16, 1892 and also on November 8, 1904.

They call the top thing the "cap" or "plug cap" and the unit as a whole a "plug" 


Note that the image does no include any holes in the blades.

1915 Gernsback Electrical Experimenter

There’s nothing quite like the 1910’s era electrical magazine. Among the puff pieces are popular accounts of up-to-date science, alongside ads for cheap pistols, motorcycles, and electrical surplus equipment.

World War I had already started by 1915, but America hadn’t yet joined. It surprised me how many German articles are included, including this little piece (page 47 of the June edition) on a novelty cigar lighter:

Unfortunately, the shape of plugs is entirely unremarked. The only plug shown in the entire years set is this bad image of what appears to be a battery charging that’s “plugged” into a ceiling lamp (back cover of the July and other months).

This is a really common setup: almost all picture of things plugged in are plugged into a screw-type light fixture. Here’s a phonograph that can be “plugged in” via a screw-plug: (September 1915, page 186)

Often cartoons show the latest devices the most clearly. This one, from the July 1915 issue, page 117, manages to show an enormous amount of detail without a single plug anywhere (everything is wired directly to a panel which includes some frightening and non-OSHA-compliant switches).

(The July 1915 issue of Electrical Experimenter included reviews of scientific movies, including ‘The Exploits of Elaine’ which I had only read in book form).

In the terrifying department: a lamp doesn’t need a plug if it’s violently radioactive! (September 1915, page 181)

A very unsatisfying picture of plugged-in equipment at a dentists office in the November 1915 Electrical Experimenter, page 332. The nurse on the left is controlling an electrical respirator; that respirator is plugged into a wall socket. Not shown, of course, is what the plug looks like.

In the same issue: Lionel trains advertises this transformer for their toy trains. Note that it has the old-fashioned screw ‘plug’

1916 Electrical Age (January)

The Hubbell company comes through! Here's a short article from the January 1916 Electrical Age magazine, page 62:



Earlier Hubbell plugs were in-line, not parallel, and had a sort of wavy shape. This plug, in contrast, looks like it would work in one of today's sockets!

The text: Very often both alternating and direct current is used in the same building, requiring some distinctive means of differentiating between the two for certain types of apparatus. This is very ingeniously done by means of the polarized attachment plug show in the illustration which is being brought out by an enterprising manufacturer.

...one knife blade contact has been made smaller than the other in both width and length (different from modern polarized plugs which are different in width only, and often only at the tip) and the slot in the base reduced proportionately. As the opposite blade is the standard size it cannot be inserted in the small slot...

1916 Electrical Age, February


After the surprising modern Hubbell socket in the January issue, here's a notice in the February issue. Note that the blades are the classic Hubbell wavy in-line blades. Unlike past images, there are holes in the blades!













1916 Gernsback Electrical Experimenter

This is almost a plug, but it’s not. It’s a picture of a high-intensity lamp from the February 1916 edition, page 553. What looks like a plug is actually the lamp directly wired to an incredibly dangerous knife switch. As a young’un, I had always assumed that knife switches were used when dealing with lots of current; I was surprised when I started to read the specs and discovered that knife switches are simultaneously dangerous, expensive, and have low current ratings.

I think this is also not a plug (March 1916, page 620)

1916 Electrical Age

The November 1916 Electrical Age, page 59 has this picture! Its a heater control. It's described as having a "indicating switch, a concealed receptacle and in parallel with it an Edison receptacle for a pilot lamp ... By means of a standard cap which fits into the receptacle, current can be supplied for the electric iron, washing machine, and other current consuming devices. The standard caps for use with this outfit have two parallel blades for making connection with phosphor bronze spring contacts located well below the surface of the receptacle."
 











Looking very closely at the scan, it looks like the maker is Bryant and it's seemingly a type BA 260

1920 Patent 1341468

1341468

This 1920 patent shows the little holes in the plug.

Sunday, May 24, 2020

Your bluetooth is bad (continued)

More example of how to make bad Bluetooth devices

What format is my number?

Bluetooth developers continue to create a bewildering variety of undocumented data formats. Indeed, it's a race between them and the bizarrely incompetent "Distributed Ledger" teams for the worse numerical formats.

  • Nordic Thingy -- you can't just describe a value as a "uint_16"! Specifically, you can't do it because I don't know if you mean a big-endian or little-endian value (as it turns out, the Nordic Thingy is little-endian)
  • Also Nordic Thingy -- describing a temperature as a signed value and an unsigned fraction only works if you tell me the denominator of the fraction. Some devices might reasonably make the "fraction" part be out-of-10 to get a degrees in a tenth of a degree (which is just fine for a weather station), or it might be out-of-100 or even out-of-256. 


Your Bluetooth is Bad, continued

Very silly Bluetooth protocols, continued

Bluetooth devices continue to astound me: there are clearly capable programmers who manage to completely misunderstand what they're doing. In this episode: the Elegoo Mini-Car kit.

The actual kit is pretty decent: it's got a lot of parts and polish for something so inexpensive (I think I paid about $30 for mine). Up on the Elegoo downloads site there's a 400+ megabyte (!) download with a bunch of well-written instructions and even a Windows 7 driver program.

Clearly the Elegoo people are doing well in terms of creating a complete package.

But then there's the Bluetooth. They obviously switched at some point from a purely serial connection to a BLE connection; this always causes weird issues. 

How should you interpret a command description like this: {RGB[R][G][B][N][T][M]} ?

A smart person would start to figure that it's a weird combination of text and hex, and would kind of wonder how the command RGB is separate from the obviously hex parameters. But no, that's not it. You're supposed to literally type in the "{" and the square brackets. The parameters are in text mode, and they really do have all of the [ and ]. A complete command looks like this:

{RGB[255][0][0][2][0][1]}

A smart person will also realize that because of the insane overhead of the command, it no longer fits into a 20-byte send; you have to split it into two sends!

Let's analyze. Each parameter when sent in binary would be one byte; in fact they will be between 3 and 5 bytes. The command code, instead of being a nice simple byte (there are only about 12 commands actually supported) is instead up to 5 bytes (the MOVES command).

Wait, it's worse. What happens with {BEEP[0]}? Answer: the beeper should stop beeping. What about {BEEP[00]} -- a 00 should be parsed as a zero, right? Wrong; zero is a special case. Only a 0 counts as a zero; 00 is not a zero. This is unlike some of the other commands.

The programmer has managed to make a language that's hard to parse, inconsistent, and wildly inefficient. 


Sunday, May 10, 2020

Entity Framework (EF), SQLite and UWP

What I learned by using Entity Framework (EF) in a UWP application

I'm writing a super nifty e-book reader program (because, why not?). Along the way I discovered
that Entity Framework (EF), the easy-to-use object-relation manager layer, is in fact a poor match to UWP.

How so? Let me count the ways!

Bundled and non-bundled SQLite

Let's start with this page: Getting Started with EF Core.  In it, we discover that there's two ways to use SQLite: we can either use the SQLite that's bundled in with Windows. Or we can, for no good reason, bundle in a copy of SQLite into our app.

Except: using the bundled SQLite, is actually a terrible, terrible idea. Why? Because thanks to other libraries, chances are you'll already have a Sqlite in your app. And using the NuGet package to use the bundled Sqlite in fact just causes validation errors down the line when you switch to Release mode to make an actual release.

Tracking and Non-Tracking


Moving on to tracking: when you build an EF query, you can be either tracking or non-tracking. The value to non-tracking is described here: a non-tracking query is faster. Except that it really, really isn't, especially in my scenario.

Here's the scoop: I'm building a book database. There's a list of books; each book has some "flat" per-book information (like a string for the title) and also has both embedded information (like an entire class with the book's current download status) and lists of embedded information (like the set of people associated with the book aka the author, publisher, illustrator).

When you make a query for books, you only get the "flat" data. If you want the embedded classes like the download data, you have to include that in the query with a ".Include(DownloadData)" in the query.

When I search, I want the search query to be as slim as possible. Every embedded thing that's added just makes the search slower (and it's already too slow!). But EF has a hidden saving grace: you can do a query with a "slim" search, and then for individual specific items, do a thicker query. EF will automatically return the same actual object for the thin and thick queries, just with most stuff filled in.

That's a total win! I can slim down my queries as much as possible to find books for the user, and then plump them back up when I'm displaying specific individual books.

Yeah, but remember that advice about tracking and no-tracking? Turns out no-tracking queries don't do any of the above. And they aren't actually any faster (at least as far as I can tell).

Release Mode is Really slow

This took a long time to figure out: for a while in my e-book app, pressing the "next page" button was slow. And it was 100% my fault; I did a little bit of investigation (following several red herrings along the way!), and made it totally zippy.

Then I compiled in Release mode. Release mode is normally much faster than Debug mode, but (surprise!), that's now how EF rolls. Release mode is very much significantly slower than Debug mode.

There's tons of information about this on-line, most of it too old to be useful.

And then I discovered that my next page button was taking 15 seconds and spiking the CPU to 25% usage. That's completely unacceptable for an e-book reader; next page should be 0.1 seconds at most. My assumption, of course, is that my fixes (see earlier) were the cause, but they weren't.

All of the slowdown was simply saving the current book position. It turns out that one of the things that really slow in Release mode is saving database changes to the database. Like, 15 seconds slow.

Change Tracking (INotifyPropertyChanged) is fast

The SaveChanges advice is a real winner. It turns out that SaveChanges is super slow in release mode even though it's blink-of-an-eye in debug mode.

Using the default SaveChanges strategy, AFAICT EF has to keep a shadow copy of all object, and then when you do a SaveChanges it has to traverse everything to see what's changed. Then it can write out just the changes.

I don't know why this is fast in Debug mode and slow in Release mode.

With the change, EF can track all of your object changes; database updates are then super fast.

The only downside is that the advice doesn't actually say how to set the ChangeTrackingStrategy. You do that by created an override of the OnModelCreating method in you DbContext class.

   protected override void OnModelCreating(ModelBuilder mb)
   {

     mb.HasChangeTrackingStrategy
         (ChangeTrackingStrategy.ChangingAndChangedNotifications);
   }


Understanding that there's queries and there's queries

A surprise (to me) in EF is despite this not being documented, it's really important to know where a query is happening. EF is an abstraction layer on a database; you have to know what is happening on the database (an .AsQueryable()) versus what's happening in the EF layer (an .AsEnumerable()).

Need to make sure that your search is returning a "plump" object? That has to happen on the Database side, not the EF side. But need to do a complex search (like people do!)? That's strictly on the EF side of the house. Searches are faster on the Database side, but on the other hand, they are also super flaky.

But wait, it's just a little harder. EF converts queries at run-time. It's easy to make a LINQ query that looks right, and matches a simple, intuitive understanding of how everything is working, but will fail at run time.

What's all this about a flaky search?

Sometimes people want to find stuff by an author ("Dickens"). To do that, you make a search string ("%Dickens%") and then use EF.Functions.Like(b.Title, likeSearch) for the compare. Unless, of course, your search string is blank; if you do that, then the likeSearch string is plain "%%" and for some reason, EF (or maybe SQLite) really, really hates search strings like that.

As matching for "%%" is hard to understand. Yes, in general you shouldn't do weird searches. But this one is pretty simple and unambiguous.

How big is my database?

The main book database starts off with 60K entries (because I'm including the entire Project Gutenberg catalog! It's awesome!). Each entry has 6 sub-entries (list of People, list of Files, Review, DownloadData, NavigationData and a list of Notes).

A typical book has about 4 People and 12 Files associated with it. The database when compressed is 32 megabytes and expands to 158 megabytes when installed.

Getting started: making the database

To make your first database, EF needs to scan your app, looking for the data context so it can build a bunch of scaffolding. This doesn't work with a UWP app. Your solution needs a second project which exists only to be a regular .NET app that EF can figure out.

Yes, this sucks.

Things to avoid: splitting the database


My e-book program has a big, read-only database of all Project Gutenberg books. First thought: use two database files, one for stuff that really is read-only, and then use a different database file for everything that the user enters.

So a book title, and the files that can be download is database #1, and the notes the user wrote is database #2.

Don't do this. EF has no support for it, and it will only make your life more complex without being actually useful. Stick with a single database.

TL/DR: things to watch for with EF, SQLite and UWP

  1. Run in Release mode early; it will catch surprise performance issues
  2. Track which things are Queryable (database) and which are Enumerable (EF)
  3.  Use the embedded database, not the built-in database
  4. Don't bother with .NoTracking
  5. Absolutely use INotifyPropertyChanged and ..Changing to go fast
  6. Complex searches and queries should be run on the EF side

Saturday, September 21, 2019

GOPHER and the Internet for Dummies Quick Reference 1994

Another trip down the memory lane (aka, the latest find in a used book store).  The Internet For Dummies, 1994 edition has this to say about Gopher

If you're looking for a particular file or piece of information, like a copy of The Wonderful Wizard of Oz or the current weather in Key West, Gopher is the quickest way to find it. If yo goal is something obscure, WAIS is your best bet because -- unlike the other two -- WAIS doesn't depend on someone already having indexed the information. If you just want to browse in a general topic area, WWW is the quickest way to have a look around.

Times have sure changed. Of the Gopher URLS in the text (page 79 to 90), here's the current status for each of the gopher servers listed: 100% of them are no longer functional.

US public Gopher servers
infoslug.ucsc.edu
infopath.ucsc.edu
grits.valdosta.peachnet.edu
ux1.cso.uiuc.edu
gopher.netsys.edu
panda.uiowa.edu
inform.umd.edu
seymour.md.gov
gopher.ora.com
wsuaix.csc.wsu.edu
gopher.msu.edu
consultant.micro.umn.edu
nicol.jvnc.net
sunsite.unc.edu
twosocks.ces.ncsu.edu
cat.ohiolink.edu
envirolink.hss.cmu.edu
ecosys.drdr.viginia.edu
telnet.wiscinfo.wisc.edu


International public Gopher servers
info.anu.edu.au
finfo.tu-graz.ac.at
nstn.ns.ca
camsrv.camosun.bc.ca
tolten.puc.cl
gopher.denet.dk
ecnet.ec
gopher.th-darmstadt.de
gopher.isnet.is
siam.mi.cnr.it
gopher.torun.edu.pl
gopher.uv.es
info.sunet.se
gopher.chalmers.se
huni.ub2.lu.se
gopher.brad.ac.uk

None of these gopher servers is still existing. The common return value is "no such host", with a very small number returning a connection actively refused or even started to read, but no data was sent.

And just for fun, here's the list of Gopher programs:
Unix Gopher program "gopher"
Commands are
  • Enter to select
  • + - (or u) m = go to the next/previous/main menu pages
  •   = go to the selected menu item
  •  / = search menu for a string
  •  n = search for next item
  • q = quit
  •  = = describe current item
There are some bookmark commands: a=add item A=add menu v=view d=delete
And there are some file commands m=mail s=save p=print D=download

Also mentioned is hgopher for MS Windows, xgopher for X Windows.

Saturday, September 7, 2019

A Network Reading List

I get to be  mentor to an incoming program manager where I work. Most newcomers aren't super familiar with networking, and many people aren't familiar with the actual history of our part of computer technology.

Here's a hopefully useful curated list of useful links to source material on the creation of the internet.

The first internet was created for ARPA by BBN

The American Deparment of Defense "Advanced Research Projects Agency" (ARPA) asked for the internet in this original request. The winning proposal was from Bolt, Beranek and Newman (BBN). About a decade later, BBN wrote the Completion Report.


Ton of BBN history is online.

RFCs and Protocols everyone should know

The internet is governed (as much as it is governed) by a set of "Request for Comments" (RFCs). There's also this handy list for all 8649 current RFCs. These are all numbered; there's a society that curates them. However, anyone can be part of the RFC process. In addition to RFCs, there are also "IEN" paper with their own numbering

One of the most accessible papers (and a great way to start) is the Endian RFC, published by Danny Cohen of the Internet Engineering Task Force (IETF) as IEN 137. A good introduction to network humor is RFC 1149.

As you might guess, creating an RFC can be a long, slow slog, starting with basic proposals in a proposed state, getting consensus from experts, and converging on a draft standard and finally being voted in as an official internet standard. You might also guess that that many important protocols have gone all the way through the entire process, but here you would be wrong. The IMAP Email standrd 3501 (from 2003) is still "proposed".

You might also think that conforming to the official standards is critical. Actually, not so much. 

Internet Mail

EMail was one of the earliest super-popular uses of the Internet. There are two main ways to read email: the Post Office Protocol (POP) formats POP (RFC 918) , POP2 (RFC 937) and the current and most popular POP3 (RFC 1939) and the much more powerful / complex IMAP (currently IMAP 4.1 RFC 3501 from 2003). Sending email is via SMTP, which is a different protocol, and calendars use CALDAV (or other)

The Internet before HTTP

Telnet (RFC 318) lets you type into a computer here and have it be accepted over there. Now replaced with SSH

Gopher (RFC 1436) is kind of like HTTP/HTML, but is more of a "menu" oriented system. There still exist Gopher servers, and there's even a yearly conference. Amazingly, there's only one Gopher program for Windows in the Windows Store (and I wrote it)

Usenet News (RFC 977) is like a distributed Reddit but without reputation points.

FTP (RFC 2065) is how we used to download files. Unlike many other protocols, two sockets are used: one is for sending commands, and the other is for getting a response. This actually works really badly with firewalls. FTP is also a great example of RFCs being updated: the original RFC is 114 and then runs up to 172 265 354 542 765 959. After that there are merely a string of updates. Also notice that the orignal email protocols were handled by FTP.

Finger (RFC 742) is what was facebook. People would write information in their .plan file and it would be retrieved.

Internet Relay Chat (IRC) (RFC 1459) is like Teams (or text messages). Unlike some of these other protocols, plenty of people still use IRC.

The internet and HTTP + HTML

HTML is the markup language; HTTP is the protocol for sending HTML over the internet. It's HTML plus a bunch of headers. HTTP and HTML was first created in 1991 by Tim Berners-Lee. The NeXT computer he used when creating it is on display at the Science Museum in London. 

HTTP is defined originally in RFC 1945 which also defines Uniform Resource Locators (URLs)
HTML is defined in RFC 1866 and heavily updated since then.

Security and the internet

A common thread through all of the original RFCs is a complete lack of care about security. For example, RFC 475 says:

It has been suggested that FTP specification should require that mail
   function (for receiving mail) should be "free", i.e., FTP servers
   should not require the user to "login" (send the USER, PASS, and ACCT
   commands).

Furthermore, note that all communications are send in the clear with no encryption whatsoever. Amazingly, a recent Senate proposal for all states to email a number of sensitive documents to a senate committe proposed using a completely in-clear mail system!

Reading the Transport Layer Security (TLS) RFCs is not recommended. They are very complex, and won't help you understand the protocol. You should know that the current common TLS version is 1.2 and the new one is 1.3 (but it's not in common use yet). TLS 1.0 is barely acceptable for security and is expected to be completely broken before long. The old Secure Sockets Layer (SSL) is completely broken and must never be used if you want security.

VPN and WiFi access points often used RADIUS (RFC 2059) for authentication and authorization. One neat thing about RADIUS is that it's designed to be secure, but thanks to advances in breaking encryption, it's not at all secure on the internet.

You'll see tons of stuff about X.509 certificates. The most important thing to know is that all certificates are X.509. Other than that:
  1. A certificate is just a thin wrapper for a security key with some extra goo
  2. People handled their certificates incorrectly so often (e.g., using the code signing cert for TLS) that they are now marked with the intended purpose.
  3. The Public Key Infrastructure (PKI) is a way to 'chain' from one certificate to the next. This is always done so that there are just a few super-trusted certs and everything else flows down from there.
  4. There are custom mechanisms for trusting a certificate. Azure uses a custom mechanism inside the datacenter; for their purposes it's much faster, more robust and more secure than using the standard PKI
  5. Combining #3 and #4: the bar for inventing a new scheme to validate certificates is spending three month with the security experts. 
  6. "Browser level" certificate checking is pretty secure. The entire chain is examined; each cert along the chain is validate for expiration and to make sure that each cert correctly signed its part of the chain.
  7. Adding to browser-level certificate check is safe (security-wise). 
  8. Bypassing the browser-level certificate check is not safe. People screw this up constantly.
Read The Most Dangerous Code in the World for how common security mess-ups are.


Monday, May 20, 2019

INLINE elements and GOPHER for the gopher-of-things

INLINE Gopher links and the Gopher of things!

INLINE links are a simple but powerful Gopher addition that I've implemented in my "Simple Gopher Client" program. This was a small change, but it makes a giant improvement when using the Gopher protocol to control devices as part of the "Gopher-of-things". Here's a screenshot:



The little array of buttons are all commands for a Skoobot device (left, right, etc.). It's all Unicode, which is why the "rover" mode is a little picture of a satellite. When I press a button on the client, the Gopher command goes to a simple 70-line custom gateway program that can both display a Gopher page for the Skoobot and also can control a Skoobot robot using Bluetooth.

A common IOT configuration is that you have some set of Bluetooth (or similar) sensors connected to a hub, and then you want to have a control program that can access the hub. Often you want to make a quick, simple prototype before you go to the trouble of making a full. If only there was some widely-used very simple protocol that could make a simple UI...

Hey wait! That perfectly described Gopher! And that's why my Best Calculator, IOT edition now supports Gopher-of-things: you can make a simple "gateway" program that controls your sensor and still make a nice little user interface!

But there's something missing. Gopher works page-by-page: when you click a link (a menu entry, in Gopher terms), you get an entire new menu back (or a file or an image). There's no proviso for simply updating some existing page.

That's where my INLINE extension comes in. When a link (directory entry type '1') is seen, if the fifth column includes the word INLINE, then the link is turned into a button! And when pressed the resulting Gopher menu (directory) is returned, the first element of the returned menu replaces the first non-button item.

You can see that in the image. When a press the STOP button, it sends a command to the gateway, which does the command, and sends back just a little Gopher menu (directory) with the results of the command ("stop").

Technical details of the INLINE

1. Links (Gopher menu entry type 1) can be set to be INLINE, at which point they are called BUTTONS
2. The INLINE style is added to column 5 (which is also where the Gopher-plus "+" is added).
3. The INLINE style is part of a list of styles (e.g., "BLUE;INLINE") where styles are split with a semicolon (;). Never put a space in (it's "BLUE;INLINE" not "BLUE; INLINE")
4. Multiple BUTTON items can be placed on the same line if the client wants to.
5. The first menu entry from a button result will replace the first non-button item in the original menu. This means that you can have a block of buttons followed by a single data element.