Tuesday, August 22, 2017

Old HP Printer New DLINK Router Problem Solved

So originally I thought this problem was an interaction between QoS (quality of service) capabilities of my new DLINK 890 Router and my old HP 7520 three-in-one printer because when I turned off QoS (resetting my router), the problem got resolved.  Actually, all that did was cut off connections to the printer and force the printer to retry getting a network connection, which it did.  And then it did the thing where it worked for a little while and so I thought the problem was truly solved.

But, in fact it wasn't, as proven to me by my children printing out homework (or failing to do so).  I finally traced it back to a new router capability whereby the router could do some fancy dancing to get twice the bandwidth on the 2.4Ghz channel with smarter hardware.  My printer is old and competely functional but not so smart.  Fortunately, I could turn off this feature just for the 2.4Ghz band which the printer needs, but nothing else in the house really uses, and now everything seems to be working again.

How does this relate to healthcare standards?  It goes back to Asynchronous bilateral cutover -- aka backwards compatibility mode.  My new router has a mode in which it works compatibly with old stuff, and a mode in which is simply leaves that stuff behind.  The default setting is to remain compatible, but of course I knew better and messed things up for a while.

After reading through various and sundry message forums for both my router and my printer, I found nothing that would help me identify or cure this problem.  Pure slogging and some knowledge of protocols and interfaces was all that really helped in the end.  In the end, I turned off 20/40Mhz coexistence, set channel width to 20Mhz (the original standard) and now my printer connects and seems to work just fine on the new router.

What does that mean in the realm of implementation healthcare IT standards?

  1. Backwards compatibility is good. Testing is better.  The 20/40 Mhz coexistence feature is supposed to detect and address the fact that when 20Mhz equipment is in use, the router should be able to configure itself to talk to it, but it doesn't quite work with the hardware I'm using.
  2. Negotiating interface levels is good, but if you didn't design an interface to negotiate in the first place, you are likely to have problems.  Consider HTTP 1.0 vs. 1.1, TLS 1.0 and later releases, et cetera. New protocols should be able to downgrade.
  3. Make it possible for systems to have deterministic behavior controlled by a human.  That way, when all else fails, an SME can tell the system exactly what to do.  This is basically what I had to do for my printer, and for what I'm doing, is a completely satisfactory solution.


Post a Comment