Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
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
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.
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…
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.
Those aren’t alarm pushbuttons. These are alarm pushbuttons:
Submarine Albacore – alarm pushbuttons
They’re in the USS Albacore and obviously intended for use by someone in a hurry: the tactile shapes tell your fingers everything they need to know. If I understand the ship’s history, the Collision Alarm switch contacts closed only during tests, although they did have a close call with the sub towing the (unpowered) Albacore from the Philly boneyard to its final resting site.
According to the information we saw, the control board was refitted / replaced / redone to remove classified hardware, so the woodgrain Formica background may not be original. On the other hand, this was a sub intended for extensive experimentation, so maybe they used a cheap and easily machined material.
We toured the USS Albacore (AGSS 569) in Portland NH and found this placard in the forward Escape Trunk (which doubled as the normal hatch during the sub’s nautical lifetime):
Escape Trunk Operating Procedure
One of my relatives is a submariner who seems calm & collected enough to remember that entire checklist in an emergency.
The camera lens they used for their virtual tour pictures would lead you to believe there was actually enough space inside the sub to inhale. That was not the case and I was very glad to have only half a dozen other people touring the sub with us.
The long pipe leading around the corner to the left-front riser drains the test valve. The honkin’ big supply pipe stands to the rear of the regulators and valves. You can’t quite see it from here, but those water pressure gauges showed about 180 psi.
The bathroom fixtures had the usual pressure and instant hot water, so there’s complex plumbing inside the walls, too.