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.

More updates -- 1913 Lighting Journal has multiple plug types, and the June 1916 Lighting Journal has two interesting articles: one about the attempt to create a single plug standard.  

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

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

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.

1913 Electrical Record, February

The Hubbell company may have started the trend, but eventually other companies jumped on the bandwagon. The C-H plug from Cutler-Hammer is one such plug.

This Cutler-Hammer ad shows that a variety of interchangeable sockets for their "double lug" plug. Note that the plug has either dimples or holes.

The April issue of the Electrical Record has this competing ad from the Hubbell company:

There are also companies that try to make plugs that fit into the existing E26 and E27 screw-base sockets (that it, that can just be put into a standard light socket without having to screw and unscrew the cord). This ad is from the Trumbull company.

Or look at this from the Electrical Review and Western Electrician, vol 64--No 3, (Jan--June, 1914) page 153. The Trumble plug is kind of wavy in-and-out and there's a better view of the Cutler-Hammer double-lug plug.

More Hubble! National Electrical Contractor, November 1914!

It's kind of faint, but the diagram here shows that the parallel-blade (more modern style) plug seems to have either a hole or dimple

More Hubbell, this time with a nice blow-up image The parallel-blade plug doesn't seen to have any dimples or holes, although the in-line older style ones do. This image is page 31 of the Electrical Contractor.


The end result of all of the work? The "standard" plug (from the Electrical Record, May 1916, page 34). Frustratingly, the plugs are seen head-on. Also frustratingly, apparently the company published a 4-page folder with details on exactly how the plug works.

Ha! There's a better view here:

And look here!

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. 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


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:


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)


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