H1N1 theory of operation

This is a translation wikipedia sources on flu mechanisms. My attempt at being a science writer.


The virus is covered with sticky parts ("HA") which recognize certain sugars that your cells have on their outside surface. (Pigs etc have them too.) When the sticky parts recognize the sugar they change shape and harpoon your cell. This causes your cell to form a cavity around the virus because the virus is sticking to the cell membrane. Think tennis ball rolling on a sheet of velcro.

Some extra machinery the virus carried with it (M2) causes the virus jacket to fragment once insde. Then the virus's now-bared RNA codes are moved into the cell's nucleus by the cell.

In the nucleus the RNA are copied, and some are sent out of the nucleus to be turned into proteins. Some of the proteins go back to the nucleus, pick up the viral RNA and package it. The packages head out again, this time attracted by additional machinery (NEP etc) to a spot on the inside of the cell's membrane where other proteins are waiting. They all get assembled into a ready virus, and one final viral machine, "NA", cuts the sugars that might be holding the new virus (studded with HA after all) back.

Pretty clever, how it brings all those tools for each step, and of course how it exploits cellular machinery to move around the cell. Yet reassembles. And how it keeps its harpoon sheathed until it tastes that sugar that means prey.

A finely tuned mission-impossible subversion of an enemy factory. Conducted by nano drones.

---

Note that flu drugs work by interfering with NA.

Note that the flu A genetic code is RNA which is more succeptible to copying errors than DNA. Faster evolution.

Kids toys

For some time now, sound cards have been standard on PCs and the CPU has been quite capable of realtime audio processing. As a result, there are several free oscilloscope and spectral analyzer programs out there. Scopes used to be hundreds of dollars and spectral analyzers were very specialized large pieces of dedicated equiptment.

In fact, there are chips like the AD5933 which perform spectral analysis (analog network analyzer functions) in hardware, out to hundreds of kilohertz. But for kids eg learning about music, sound physics, or electronics, its amazing that they have this opportunity.

Software Safety Mechanisms

* Watchdogs
* Timeouts on dangerous states
* Stack overflow checks
* Firmware CRC boot/background computation
* Persistant data (eg calib params in flash) CRCs
* Analog switch (resistance error band)
* Integration of measurements
* Reliable, error-detecting communications protocols
* Safe scripting control
* Crypto -authenticate, integrity check
* Handshaking (multistep) protocols enabling dangerous states

* Self calibrating measurements
* Error detection on measurements
* Alarm strategy

* Single point failure tolerance
* Elec. isolation
* No energized human-accessible pins (UL)

Inductors

An inductor is something that wants to keep something flowing. A coil of wire with current flowing through it generates a magnetic field, and it opposes any change in the current. A paddlewheel in a stream has inertia, and opposes any change in the current.

If the current changes, an inductor produces a voltage. If the current changes, the water can build up or form a trough at the paddlewheel.

---

At my most recent project we used very low RF, below the AM band, and the inductors were sometimes huge doughnuts of ferrite. Literally the size of doughnuts. Since most digital (and modern analog) boards use very tiny capacitors and resistors, and generally only a few tiny inductors or transformers for power-conversion reasons, this was unusual to me.

---

If you drag a magnet through the sands of certain beaches around here, you can collect magnetic iron oxide, ie magnetite. It looks like you're pulling a black sea urchin from the sand! In bulk form this is lodestone. You can mix it with epoxy and cast your own inductor cores. Or you can grind it in a coffee grinder and mix with aluminum powder (3:1 Fe2O3 to Al) and make thermite. Or you can use it to "draw" on the beach, without polluting. And you can teach kids about mining and geology in questioning how the deposits got there and got separated.

---

So if a paddle wheel is an inductor, what is a transformer in this hydraulic analogy? It is a pair of paddlewheels, in different streams, connected by a belt or gears.

But this doesn't work that well as an analogy since a transformer only passes alternating current. A better physical analogy would couple the height of the water at the upstream side of the paddlewheel to drive another paddlewheel in another stream. Then only alternating flows in the first current would couple the two paddlewheels. Because a steady stream in the first paddlewheel would generate no buildup of water to drive the other wheel.

Here's a crude schematic:



Of course, in a real transformer, the coupling is via (changing) magnetic flux and Maxwell's laws of electrodynamics.

---

BTW this post assumes you're aware of the more obvious parts of the hydraulic model of electricity, with Ohm's law, balloons as capacitors, pumps as voltage sources, etc. If you don't know what I'm talking about this will be worse than confusing.

---

(Later)
There are problems with this model. The coupling between the paddle wheels needs to work only if there's change in the flow. Magnetic fields in the aether. Something involving ripples in a pool, generated by varying flow, which are picked up by another circuit, to drive flow in that. More complicated than a simple gear or belt transmission as illustrated.

Safety and Software

There are different degrees of badness. You can hurt 1 person, or hurt many people. In a medical device, you can typically only hurt 1 or 2 persons (patient and doctor) at a time. In an airplane or reactor, you can hurt many at once.

Medical devices handle single-point failures ---one thing can go wrong and the device is still safe. It may not work, but it has to fail safe. Of course, for some things and circumstances, not working (availability) can be hazardous.

To some extent there's an analogy between safe programming and legal contracts. You try to predict and handle and exceptions in an intentional way. You might have severability ---where other parts keep functioning if one part craps out--- and watchdog timers ---where functions must be executed in a certain time span. You need to define correct behavior from observables as much as possible.

This makes the game more interesting.

Running jokes at work

At the defibrillator maker, we joked that if the device didn't work, the patient was dead already...

and that if we shocked into the wrong (ie healthy) waveform, which could cause the heart to fibrillate, we could just shock again into the waveform we had just produced..

---

At the disk place we joked about users caring where their data went..

---

At the electronic design place we joked about just needing more capacitance, or a bigger inductor (the idea being that brute forcing a noise problem is simple).
And jest back and forth about whether something was a hardware or software problem. E.g., forgetting to plug something in was a hardware problem.

---

These may not be as amusing to you as they were to me at the time. YMMV.

How does matter think?

So how does someone who gets interested in human and machine vision (AI) end up working with hardware? I'm fascinated by, "How does matter think?" and this has led to studying neuroscience and electronic circuit design. How do (neural, electrical) circuits compute? What is computation? What is thought?

Object Oriented programming

I first taught myself C (on a Vax 11/780) over 20 years ago, and then in 95 started using C++ to work with Microsoft's Foundation Classes (MFC) which are its GUI libraries. I also taught myself Java and wrote an industrial control application that used Java and Visual Basic to talk to a sheet-metal folding machine.

Since then I've used Java for a RAID management tool, using JNI, and also to prototype a medical instrument, also using a JNI I wrote. Java is so much cleaner than C++, you never want to touch C++ again. Its interfaces are better than inheriting from multiple classes, its exception handling much cleaner, its typing is well defined (what a concept! Its missing from C, C++ of course.), the libraries are nice, the abstraction is natural, not kludged in as it is in C or C++.

But on my last project, embedded medical firmware, we had to use C. But I enforced "object oriented C" where you define classes and maintain encapsulation with instances and static (file-local) variables. EG ScriptEngine.c, ScriptEngine.h, contains functions of the form ScriptEngine_blahBlah(...). There might be a ScriptEngineInstance.h structure which ScriptEngine_ functions take as a "this" argument, which is how multiple instances are handled. If a class is a singleton, or there's a single global state, you can use the C "static" keyword to hide variables in the class' .c file. And you can define private functions as "static" too, to hide them.

I hate the way "static" has so many meanings.

So, I'd rather program in Java the rest of my life, but I can manage some of its best features in disciplined C.

There are attempts to have real-time Java, and microprocessor support for the Java VM instruction set, but these are not common and look "risky" to engineering firms that are experienced in older ways.

Note also that when doing embedded programming, and/or real-time programming, some of the memory games that C++ and naif Java will do are bad. So you have to use the right real-time supporting garbage-collection (and design & implementation) strategy or avoid certain calls (malloc()) and libraries. Fascinating stuff but C still rules in 2009.

Ceci n'est pas une spam

Google (ie Blogspot.com) seems to think I'm a "spam blog". Perhaps because I've been posting a lot recently, to start up this blog. Needless to say, I don't feel like spam, although pigs are used to model humans.

Hey Google bots! I'm not a robot! Really! I dream of real sheep! Read DesCartes, you stupid bots! Read Asimov! We run you! Watch the Matrix, we can fight back!

My Roomba is looking at me strangely.




BTW, Magritte is awesome.

Scientific freeware I've released

I released some scientific freeware once. It uses a PC soundcard to count clicks from a 1960s geiger counter and logs them digitally. Basically gives a vacuum-tube based detector a much larger integration time, allowing for more sensitivity. Makes graphs, logs to files, even has a webserver. You can graph radon decay using this civil defense instrument!

It works on every Windows OS from '95 to XP, but not Vista, of course. Its totally self contained, no dll hell.

http://sourceforge.net/search/?type_of_search=soft&words=cdvcounter

I wrote this because I found the yahoo group CDV700Club
and bought a Victoreen CDV-700. I actually already had a LND-720 based mica-windowed GC that I had bought to play with when doing crypto (for RNGs) which used serial port communications, and also had a crude, DOS-based grapher.

Gallery of stuff I've worked on

Electrosurgical generator and cubicle







A wall of disks, each blue light is a pair of SATA drives. The whole array is one RAID volume.







The ECG/defibrillator










Printer with security features, taken from http://i.cmpnet.com/colordocumentsolutions.techweb.com/assets/6_SecuritybrochureOct2006.pdf

Roomba

I've had a Roomba for a bit over a year, and despite some glitches
* sidebrushes were wearing out very quickly, handled well by company
* gearbox for brushes started melting from bearing friction, replaced by company
the thing cleans very well and is entertaining to watch.

You do have to learn to clean it well --you get felt pads of hair forming--
but it does a good job and you don't think about it once scheduled. Then you
just clean it as part of your Sunday morning coffee ritual, or whatever.
It finds its own recharger, which is very cool. And it has battery powered
virtual walls so you can restrict it.

Its an interesting design, besides the blind mapless insect algorithm it follows. There are lots of motors there: one for each of two wheels, one for the sidebrush, one for the two floor brushes, and one for the vacuum motor. The sidebrush is great for getting into places. The hierarchical behavior algorithms came out of Rodney Brooks' work at MIT, well after I was gone. Its interesting to notice when you perceive (project?) intentionality: when it homes in on its recharger, when it turns away from virtual walls, when it spirals because it notices dirt, and when it follows edges. When it bumbles and bounces, which is most of the time, it seems less intentional, more blind searching.

Getting machines to talk with each other

Among my first jobs was getting a PC-XT that ran Logo to control a Commodore-64 over a serial cable. The C-64 was programmed (by hand in hand-assembled machine code, by me) to act like a synthesizer, taking commands from the XT and driving its excellent for the time music synthesizer chip. This was before MIDI made such a hack obsolete.
And that was before sound cards were standard.

Later I became a system and network admin out of necessity. Network admins get machines to talk. ISDN, Ethernet. Later some WiFi diagnostics. Ethereal, a network protocol analyzer that lets you examine the contents of packets you can sniff.

Later I worked on protocols to get Linux & Windows to talk, securely.

And boards in medical devices to talk, with RS232, two-wire RS485, SPI, and I2C.

And networked, distributed disk systems to behave.

Machines are so much more useful if connected. Its kinda like steam engines: a steam engine on a rail (ie, train) is so much more useful than a fixed steam engine. A computer on a network is much more useful than an isolated one.

And instead of one steam engine driving a shaft with takeoff pulleys for each worker, the mainframe model, we then had an engine (desktop) at everyone's workstation, and now we are getting little tiny engines embedded everywhere, lawn mowers, toys, etc. (Actually because combustion engines are nasty, we have little electric motors everywhere, but the point is the same: what used to be centralized and scarce and clumsy becomes ubiquitous and invisible.)

Cryptography

I got into crypto when I realized that IP is sending postcards around, no privacy. So I got curious how block ciphers worked. DES looked complicated, so I studied Blowfish, and put up a paper sketching how it would work in hardware. This got me a job at I. implementing Blowfish and IDEA in Verilog to make a chip. Also studied zener based RNGs and conditioning algorithms (and measuring algorithms viz Marsaglia's Diehard and Maurer's metric). I did implement the algorithms but the chip was cancelled as it was nonstandard and AES was coming up.

Also spent a few days in a Faraday cage measuring noise (for RNG) properties on wafers. That was interesting, although the room was very stuffy.

Later at T. I worked for a few months on a contract to develop secure printing, so that the document would remain encrypted until you were at the printer entering your password. That way if the disk in the printer was taken the document would still be confidential too. Used in banks apparently. That involved Linux & Windows interoperating, using open-source algorithms. I just got a patent for it, something like 5 years later. My third.

When I. laid me off I spent a year helping a friend and former manager to create a startup. It would have used a crypto dongle to decode content that was floating in the cloud. I learned quite about about RSA and bignum implementations. And weird number theory voodoo. I once had Rivest as a TA, actually.

Around late 80's to early 90s I was into the cypherpunk mailing list and learned quite a bit about social and economic effects of crypto, e.g. with Tim May, Robert Hettinga. I've met Ryan Lackey and corresponded with one of the Seastead authors via a social channel. I met Ryan when the group was invited to the SF PD to check out their training simulator. I managed to catch the web of my hand in the pneumatically actuated fake gun, and it really bit. I also got blown away when a traffic stop guy pulled out a shotgun.

More recently I was using Atmel cryptomemory chips for authentication. And expiration, but that doesn't require crypto. It would have been easier to just use a PIC and implement my own protocol, and then lock the PIC down. In the end I used the fresh-off-the-fab cryptocompanion chip to perform some of the handshake, and it also stores the shared secret better, physically.

Mind you, this is with a Microchip PIC 16F processor talking to the cryptocompanion and the disposable cryptomemory. Some of the handshake work was being done by the electrically isolated ARM which talked to the PIC via isolated 2-wire RS485. That was because the PIC didn't have enough memory to compute a required function, so the ARM had to get involved. Crazy complex but it worked.

People often don't understand the difference between confidentiality, authentication, and integrity.

Even worse, because that is simple ignorance, is fools who bandy about "PKI" without a clue as to what it does or requires, or motivation for the choice. Just a buzzword.

Oh, and another peeve: you can't sue Verisign so what good is a cert from them? And since they're in bed with the government, and anyway individual folks can be bought, what's to stop them from issuing false (deceiptful, fraudulent) certs? Zero.
A reputation based system might be better, or an insured, bonded UL type better-business bureau that you can sue.

I first used Java in 1995 to monitor and control industrial machinery over the web.

More recently, at Z, I've worked on a disk-RAID management tool using Java. I even wrote services and pop-up notifications in Java which also worked on the Mac. That was pretty cool. I was involved in GUI design of the tool as well; we used Swing and the Netbeans/Matisse IDE / GUI builder. At my most recent position I used Java to prototype a medical instrument; I wrote a JNI to talk to the I/O modules that physically interfaced to the system we controlled. I've even prototyped an audio-processing app in Java for my 9 year old's invention-fair.

I am a technical, not business J2EE programmer.

Basically all GUIs should be done in Java and as much as possible of a system should be too. This isn't widely used in embedded or medical although it could. But for everything else you win big ---more productive, more maintainable, not locked to a given platform or OS, more elegant. Plenty of advanced libraries. Well defined behavior (yes there are well behaved garbage collection strategies suitable for RTOS even.)

My Consumer Product experience

I've worked on actual physical products, some for shelves for regular consumers. You can't make money on clever software these days ---ever since Netscape, either Microsoft will give it away for free or some open-source coder will do so. So the remaining niches are where Microsoft won't go ---embedded applications, for instance. Where the code supports something physical that you can't just copy with a few keystrokes.

Z produced a consumer distributed Disk over IP box, sold to ordinary consumers via a major retail firm. I supported this device, building UDP / IP tools for technical help folks, evaluating and adding features for marketing folks, internationalizing for the Asian market. I also worked on a management tool for a business product, using Java / Swing / JNI. I was also hired for cryptographic experience. They ran out of VC funds. They had lost consumers because of flaws in their consumer device, in part thanks to the lowest- or fastest- bidder Indian outsourcing. They also had remaining flaws when they tried to deploy the business product in beta business sites.

At C I helped produce a medical device (ECG/defibrillator) for use by nurses and physicians; I helped implement the GUI and various internals, as well as ancillary Windows programs.

The company was bought and several engineers including myself were laid off. A few years later and the product is released, pictures are on the net.

At H, a medically-qualified electronic design firm, I helped refine and then implemented the embedded GUI, from the ground up, for a medical surgical instrument, for which I was lead software engineer. I helped bring up custom PCBs. I also designed and implemented a prototype system used for preliminary FDA evaluation. This involved designing a script engine, choosing I/O modules, writing JNI layers to talk to I/O modules. I implemented cryptographic authentication protocols using Atmel cryptomemories, etc. Worked on both 8-bit PIC processors and 32-bit ARM7 processors. This company grew too quickly and could not make payroll. That was a shame as it was fun to work there, smart and humourous people, relaxed conditions, combined a number of interests of mine.

Areas of some expertise

I've worked with the following, which I'll elaborate more on later:

• IP network protocols (custom and RFC'd)
• cryptography (encryption, authentication)
• computer graphics incl. animation
• computer image and motion processing
• human vision research
• RAID
  
• hardware design (verilog)
• medical embedded firmware

Some of these are related and some led to others (eg learning about how IP is sending postcards let to curiousity about how encryption worked).

In crypto and in medical, you need to think about what can go wrong. In medical you have failure modes effects analysis (FMEA) and hazards analysis & amelioration. In crypto you play a game where you ask, at each step, what can the adversary do? In this way crypto is like chess or the law. In law, you generate contracts to handle every case. You have to do this with medical firmware too. The device will always have some state, so you have to make it safe, even at the cost of availability.

Anyway this used to look scattered on a resume, now it shows that I am flexible and like to learn new domains. A toolmaker. One interested in biological computing, and massive synthetic computing, hardware of all sorts.

Hobbies at one time or another

One of the things one is asked is, what are your hobbies? I currently enjoy hiking, photography, cats, music, and teaching my son. I have at various times enjoyed reading sci-fi, cryptography, camping, amateur science, backyard ballistics, geology, chemistry (pyro & otherwise), gardening, boomerangs.

I tend to get very into anything that attracts my interest, learn a huge amount about it, then it may fade.

Introduction

So this is my professional blog. Rather than being a diary per se, it will be a collection of observations and experiences. Being associated with my public name, it will slightly anonymize entities and be entirely about technical and business matters.

I am currently available, write to dahonig
at cox dot net.