The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: Oddities

Who’d’a thunk it?

  • Tea Ball Revivial: Bleaching

    As promised, pix of the tea ball bleaching process (it’s plant pot bleaching time again). Before:

    Tea ball – before bleaching

    And After a few minutes in a 10% bleach solution:

    Tea ball – after bleaching

    The pix don’t do it justice; the thing comes out looking like new. Every half-year, like clockwork!

    Of course, one could argue that tea does even worse things to my interior, but …

  • Body Modification: Magnetic Sensor

    Our Larval Engineer reports that the current techie-thing-to-do involves having a tattoo artist or other unlicensed medical technician implant a tiny bar magnet in one’s finger, a process that adds a sixth sense to one’s built-in repertoire after the anesthetic shot of whiskey wears off. Evidently, converting magnetic field variations into mechanical force tweaks those little nerve endings wonderfully well, provided that your finger doesn’t subsequently rot off.

    I point out that a magnet epoxied to a fingernail would probably get you within a few dB of the same result, minus the back-alley surgery thing. She counters that’s tacky and lacks style.

    I point out that her medical insurance (for which, harumph, we are currently paying) probably doesn’t cover self-inflicted damage. She counters that most victims people have no problems at all.

    I point out that a steampunk-style wristband incorporating a Hall effect sensor, LEDs, and maybe a vibrating pager motor would be at least as cool and probably marketable, to boot. She returns broadside fire by observing such a device requires power and she knows how I feel about batteries.

    Game, set, and match.

    In the interest of science and so as to not be rendered completely obsolete, I’ve epoxied a small neodymium magnet to my left little finger to discover what the world feels like. It’s surrounded by epoxy, which ought to prevent corrosion & deterioration until it eventually falls off or the nail grows out. It came with a white ceramic layer on one pole, which means it’s completely encapsulated:

    Neodymium magnet on fingernail
    Neodymium magnet on fingernail

    She’s absolutely right: it’s tacky and lacks style.

    I used JB KwikWeld fast-setting epoxy. The magnet attracted a tendril of uncured epoxy, so the “steel filled” part of the description seems accurate, and the magnetic field produced a nice smooth coat over the entire side of the disk.

    It buzzes gently inside a Sonicare toothbrush handle, snaps firmly to steel surfaces. and is otherwise inoffensive. I must run some calibration tests to figure out what sort of magnetic field intensity a fingernail can detect. I’m certain it’s less sensitive than an implanted magnet, but I’m down with that.

    Memo to Self: If you should occasionally use your little finger to ream out your ear or nose, that’s just not going to work any more…

  • Kindle Fire Security: Burn Them. Burn Them All.

    My Kindle Fire automagically updates itself whenever Amazon decides it should. Sometimes an update produces a notice that an app (why don’t we call them “programs” these days?) needs more permissions, but the process generally goes unremarked.

    This one wasn’t subtle at all:

    Kindle Fire - File Expert Trojan warning
    Kindle Fire – File Expert Trojan warning

    I had just fired up File Expert, which immediately dimmed the screen and presented a dialog box with only two unpalatable choices. Here’s a closeup:

    Kindle Fire - File Expert Trojan warning - detail
    Kindle Fire – File Expert Trojan warning – detail

    Well, what would you do?

    Needless to say, I didn’t press the Download Now button; it probably wouldn’t have worked anyway, because I turned off the Allow Installation of Applications from Unknown Sources option a long time ago. Pressing Exit bails out of the program app and returns to the Home screen.

    Some questions immediately spring to mind:

    • If the app has been compromised, exactly how did it regain control and complain about the situation?
    • If this is truly a compromised app, why wouldn’t the Trojan just download malware without asking?
    • How did this pass the ahem QC and auditing that allegedly justifies having a sole-source Amazon App Store? After all, I can load random crap from the Interweb onto a PC all by myself.
    • How does one validate the origin of those random security questions that regularly appear on various computer screens? Why wouldn’t malware just pop up a random dialog box asking for the password, any password, and gleefully use whatever you type?

    This appears to be a false positive, as explained there. I assume that any malware worth its salt would also kill off any built-in integrity checking, but what do I know? It’s gone missing from the storefront, probably cast forth into the outer darkness away from the light of Kindle Fires…

  • Please Use the Water Fountain for Drinking Purposes Only

    Please Use the Water Fountain for Drinking Purposes Only
    Please Use the Water Fountain for Drinking Purposes Only

    OK, I need some help on this one…

    I understand the English wording and suppose that the Hebrew version says roughly the same thing. What I flat-out don’t understand is why such signs appear over the water fountains in the hallways outside the toilet rooms (which have, FWIW, the expected, perfectly serviceable, sinks with hot & cold running water and soap dispensers).

    We were northbound on I-90 at the Clifton Park rest stop. Given the location, I’d pick French as the second language and maybe Spanish would be reasonable, but Hebrew?

    Is there some mysterious ritual involving water fountain misuse that happens only in upstate New York?

    Obviously, I don’t get out nearly enough…

    [Update: I will ruthlessly squash ethic & religious jokes, snide remarks, and off-point speculation. Selah.]

  • Kindle Fire NTP: Timing Channel Attack

    I’ve completely offloaded remembering my appointments to the Kindle Fire, which now lives in the right thigh pocket of my cargo pants (it’s a sartorial thing). While waiting for a meeting (which it had correctly reminded me of) to start, I did my usual “What do we find in the way of open WiFi networks?” scan, found one, and connected to it. Unfortunately, it was one of those open WiFi networks that subsequently requires a password, but … then I noticed something odd with the time displayed at the top of the screen.

    A bit of tapping produced the Date & Time settings screen:

    Kindle Fire - 0503 1 Jan 1970
    Kindle Fire – 0503 1 Jan 1970

    Evidently, that not-exactly-open WiFi network also features a defunct time server that’s happy to clobber any device asking for a time update. As you might expect, snapping back forty years does horrible things to many Kindle fire apps. The crash handler can only suggest re-downloading the app from the online store, which turns out to not be necessary after a complete shutdown / reboot.

    Ah, if I knew then what I know now… I’d certainly get into much more trouble. Not surprisingly, there’s a book about that; maybe it’s better not to know how things will work out.

    Memo to Self: watch the time!

  • Electrical Grounding: Not Like This

     Corroded Grounding Strap - Walkway Over the Hudson
    Corroded Grounding Strap – Walkway Over the Hudson

    Spotted this through the railing on the north side of the Walkway Over the Hudson:

    I’m not sure what it’s bonding to the bridge structure, but the corrosion where the braid touches the I-beam suggests an electrical potential drives the reaction. There’s stout bonding braid connecting all the railing sections together, but this braid wanders off below the decking and seems too casual / flimsy for lightning protection.

    The rivets date back to the late 1800s. I suspect that bolt won’t last nearly as long…

  • APRS Position Error

    So there I was, riding along Thornwood Drive in Poughkeepsie, minding my own business, when I teleported into Vassar Farm… and back!

    APRS data error - 2012-10-21 15:20:20
    APRS data error – 2012-10-21 15:20:20

    The aprs.fi database shows these packets around that glitch:

    2012-10-21 15:43:55 EDT: KE4ZNU-9>T1TP3T,WA2YSM-15,WIDE1*,WIDE2-1,qAR,WB2ZII-15:`eSllA=b/"4Q}
    2012-10-21 15:48:41 EDT: KE4ZNU-9>T1TP4U,WA2YSM-15,WIDE1,W2VER-15,WIDE2*,qAR,WB2ZII-15:`eS0mAQb/"4X}
    2012-10-21 15:49:53 EDT: KE4ZNU-9>T1TP5W,WA2YSM-15,WIDE1*,WIDE2,qAR,WB2ZII-15:`eS$l{1b"4U}
    2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,WB2ZII-15:`eR lzlb/"4V}
    2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,KC2DHU:`eR<0x7f>lzlb/"4V} [Rate limited (< 5 sec)]
    2012-10-21 15:52:31 EDT: KE4ZNU-9>T1TP8T,W2LW-15,W2LV,WIDE2*,qAR,W2GSA:`eR|lz:b/"4T}
    2012-10-21 15:52:53 EDT: KE4ZNU-9>T1TP8S,WA2YSM-15,WIDE1*,WIDE2,qAR,N2MH-12:`eRsm*ub/"4S}
    2012-10-21 15:59:52 EDT: KE4ZNU-9>T1TQ3X,WA2YSM-15,WIDE1*,WIDE2,qAR,K2DLS:`eQ}lz\b/"4N}
    

    The two packets at 15:50:20 represent two different paths from the WA2YSM-15 digipeater to the APRS database: one through WB2ZII-15 and the other through KC2DHU. The “Rate limited” message indicates that the database regarded the two as different packets, which they are: the position data differs by one character. The database discards identical packets without comment, because the network must handle all the packets generated by a single RF transmission from one GPS tracker to multiple receivers, but rejects what it sees as deliberate (or inadvertent) attempts to overwhelm it.

    Decoding the packets provides a bit more information:

    2012-10-21 15:49:53 EDT: KE4ZNU-9>T1TP5W,WA2YSM-15,WIDE1*,WIDE2,qAR,WB2ZII-15:`eS$l{1b/"4U}
       type: location
       format: mice
       srccallsign: KE4ZNU-9
       dstcallsign: T1TP5W
       latitude: 41.67616666666667 °
       longitude: -73.91800000000001 °
       course: 121 °
       speed: 16.668 km/h
       altitude: 62 m
       symboltable: /
       symbolcode: b
       mbits: 101
       posresolution: 18.52 m
       posambiguity: 0
    
    2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,WB2ZII-15:`eR lzlb/"4V}
       type: location
       format: mice
       srccallsign: KE4ZNU-9
       dstcallsign: T1TP5V
       latitude: 41.676 °
       longitude: -73.90066666666667 °
       course: 80 °
       speed: 16.668 km/h
       altitude: 63 m
       symboltable: /
       symbolcode: b
       mbits: 101
       posresolution: 18.52 m
       posambiguity: 0
    
    2012-10-21 15:50:20 EDT: KE4ZNU-9>T1TP5V,WA2YSM-15,WIDE1,K2PUT-15*,WIDE2,qAR,KC2DHU:`eR<0x7f>lzlb/"4V} [Rate limited (< 5 sec)]
       type: location
       format: mice
       srccallsign: KE4ZNU-9
       dstcallsign: T1TP5V
       latitude: 41.676 °
       longitude: -73.9165 °
       course: 80 °
       speed: 16.668 km/h
       altitude: 63 m
       symboltable: /
       symbolcode: b
       mbits: 101
       posresolution: 18.52 m
       posambiguity: 0
    
    2012-10-21 15:52:31 EDT: KE4ZNU-9>T1TP8T,W2LW-15,W2LV,WIDE2*,qAR,W2GSA:`eR|lz:b/<4T}
       type: location
       format: mice
       srccallsign: KE4ZNU-9
       dstcallsign: T1TP8T
       latitude: 41.68066666666667 °
       longitude: -73.916 °
       course: 30 °
       speed: 16.668 km/h
       altitude: 61 m
       symboltable: /
       symbolcode: b
       mbits: 101
       posresolution: 18.52 m
       posambiguity: 0
    
    

    Feeding the coordinates into Google Maps shows that the first packet (to WB2ZII-15) at 15:50:20 carries the damaged data. The second (to KC2DHU) has the correct position, but was rejected because it arrived just after the first and wasn’t an exact duplicate.

    AX.25 packets carry a checksum and it’s a convolutional code, not a simple XOR, so I think it’s safe to say the packets were received as transmitted; you’ll find an intro to that whole topic, with further references, in the N1VG OpenTracker project. The database doesn’t store complete AX.25 packets, so we can’t run their headers and data through the checksum algorithm to see if they both produce good results. Here’s the raw packet payload:

    2012-10-21 15:50:20 EDT KE4ZNU-9: 75 bytes
    0x00 K E 4 Z N U - 9 > T 1 T P 5 V , W A 2 Y S M - 1 5 , W I D E 1 ,
         4b45345a4e552d393e5431545035562c57413259534d2d31352c57494445312c
    0x20 K 2 P U T - 1 5 * , W I D E 2 , q A R , W B 2 Z I I - 1 5 : ` e
         4b325055542d31352a2c57494445322c7141522c5742325a49492d31353a6065
    0x40 R   l z l b / " 4 V }
         52206c7a6c622f2234567d
    
    2012-10-21 15:50:20 EDT KE4ZNU-9: 72 bytes [Rate limited (< 5 sec)]
    0x00 K E 4 Z N U - 9 > T 1 T P 5 V , W A 2 Y S M - 1 5 , W I D E 1 ,
         4b45345a4e552d393e5431545035562c57413259534d2d31352c57494445312c
    0x20 K 2 P U T - 1 5 * , W I D E 2 , q A R , K C 2 D H U : ` e R 7fl
         4b325055542d31352a2c57494445322c7141522c4b43324448553a6065527f6c
    0x40 z l b / " 4 V }
         7a6c622f2234567d
    

    So it seems the TinyTrak3+ sent out a packet containing bad position data, wrapped with a correct checksum.

    The NMEA-format 4800 baud 8N1 serial data from the GPS receiver puck to the TT3+ has no parity error detection, so I suspect a character or two got clobbered (by RFI?) and produced a bad position. NMEA messages have a simple XOR checksum that’s susceptible to that kind of error. Note that the Mic-E encoded message shown above is not passed from the GPS receiver to the TT3+; we never see the raw GPS data.

    Our TinyTraks use SmartBeaconing to transmit only on significant course changes, so the sequence of events probably went like this:

    • The TT3+ decodes a damaged NMEA message from the GPS receiver
    • It notices an abrupt position change and sends that incorrect position
    • The next NMEA message arrives correctly
    • The TT3+ sees another abrupt jump and sends that position
    • The aprs.fi database rejects the message due to rate limiting
    • The TT3+ remains silent until the next turn

    The map doesn’t show all the turns, because that’s a hilly area and not all RF packets make their way from my bike to an APRS receiver.

    For what it’s worth, although we were riding at a fairly steady pace, I don’t believe the five-significant-figure accuracy of those speeds, either.