Viv asked me to look into the Diabetes Sentry, a $500 FDA-approved non-invasive perspiration-based wristband glucometer intended for night wear by diabetics and oriented to catching nighttime lows and highs, so I am gathering links in this post. This technology has been in development for years and has always proven challenging to implement, the ideal end-deployment scenario being that diabetics could wear a non-invasive continuous-monitoring glucometer and that device would then feed adjustment data to an automated invasive (or implanted, eventually) insulin pump, establishing what would effectively be a replacement for the diabetic’s damaged organs.


University of Florida Clinical Trial, 2014. Clinical Evaluation of a Non-Invasive Hypoglycemia Detector in a Glycogen Storage Disease Population “The device often failed to detect hypoglycemic episodes in glycogen storage disease patients and the rate of false positive alarms was high.” 


Journal of Diabetes Science and Technology, September 2015. Hypo- and Hyperglycemic Alarms – Devices and Algorithms. Daniel Howsmon, BS and B. Wayne Bequette, PhD. 

Article includes noninvasive and invasive monitoring devices and concentrates on invasive continuous glucose monitoring technology as demonstrably most effective, noting an approximate 1-in-3 false positive rate over several noninvasive devices. I did not note if the article cites the UofF study linked above, whose results are in line with the studies of other, older noninvasive monitors cited. The article does note that trial users of earlier systems did not want to stop using them despite the rate of false positives and cites “quality of life,” presumably deriving from the better-safe-than-sorry thesis combined with the diabetic user’s response to the alarm, which would require awakening and testing prior to adjusting insulin dosages.

This is interesting from another perspective in that it is well established that a key to long term healthy adjustment to living with diabetes is frequency of testing. Presumably the false overnight alarms drive up frequency of testing and therefore increase the diabetic’s data set, resulting in better glucose control. This is a powerful argument in favor of the device.

Health Central, Will the Diabetes Sentry Prevent Hypos?, David Mendosa, November 2013. 

A consumer-oriented review in which the writer obtains an early review unit and enlists the help of an insulin-dependent diabetic friend to assess the device’s performance. Interestingly, the writer notes that the Diabetes Sentry does not use the infrared perspiration analysis that other similar devices such as the GlucoWatch did in the past, but rather uses changes in skin temperature and skin humidity to invoke its alert. Mendosa’s user reported both false positives and failed detection, in one case citing a low that reached 40 without triggering an alarm. The user also appeared to be primarily testing the device in daytime and active conditions, which is not necessarily our visualized use case. The article also notes that the Diabetes Sentry is the second to-market iteration of the device, the prior incarnation having been marketed as the Sleep Sentry apparently under the mistaken impression by the manufacturer that the device had recieved FDA approval, which it had not.

All together, I would say that while $500 seems expensive for a device whose primary benefit appears to be increasing randomized overnight blood-sugar testing and insulin dosage adjustment – a result which could be obtained by setting randomized alarms on one’s cell phone or digital information device such as an Apple Watch or other fitness band – if Viv remains inclined to this purchase after understanding the projected limitations of the device, I am in favor of the pirchase simply because it has the potential to increase overnight testing frequency.


For many years I have run an antiquated virtual answering machine on one of my Macs using the long-unsupported and discontinued Parliant PhoneValet software and dongle combo. Sometime about midyear I noticed that the software was no longer picking up and doing the various things it was supposed to, such as presenting a phone tree to callers and forwarding messages via email and calling our cell phones and so forth.

After some troubleshooting I concluded that my housewide move to OS X 10.x Yosemite around June had finally done in the software. I have a very elderly pre-Intel Mini that I keep around as a print server for some older printers and figured at some point I would move the dongle and software to that machine, still a possibility.

However, at some point well after that, date uncertain, I noticed that there had been no messages left on the traditional handset-base answering machine either, which seemed strange, especially in an election year. Sometime around then, my parents mentioned in a conversation that they had tried to call our land line but been unable to leave a message.

I thought that was strange, so I called the number from my cell. It rang in the handset but not in the hardware attached to the line, even though our DSL was working fine. When I picked up the landline handset, there was no dial tone.

After looking into it, I concluded that the likely course of events was that our cat had knocked a handset off a cradle at some point and we had not noticed it until after the emergency tone had been cut off and the POTS voice line disabled, probably in telco software, and would likely need to be reinitialized. I did not expect that there was a hardware or wiring issue because our DSL service remained fine.

We traveled a great deal in the second half of the year, on the road an average of a week a month through November, and that, plus the definite bonus of not even receiving any of the electioneering robo calls that plague election years, meant that I was in no hurry to get the line back up at all. 

Yesterday I finally filed a ticket and CenturyLink sent a truck. The technician was friendly and informative and although surprised to hear that the DSL remained functional and concurring that the infrastructure was likely fine, determined that his best reccomendation was to replace the line-drop to the node. 

So now we have landline POTS again for the first time in at least six months. Minutes after the hookup, we received our first call, from a scammy travel-offer telemarketer! We had qualified for a week of free travel, food, and lodging in Florida!


We really did not miss the line at all. I suppose I should look into seeing if we can keep just the DSL portion of the service and cut our rates by about $25. I’d like to keep the number, though. I wonder, can I port it to a virtual service or VOIP that would enable screening and phone tree forwarding for, oh, $5 or so? I sure wouldn’t be interested in paying any more than half the current cost and honestly any more than five bucks doesn’t generate enough savings annually to motivate me at all.

The Hard Drive Shuffle

On December 23, the boot drive in my MBP failed and I had to interweave backups and recovery and troubleshooting through the additional activities of the holidays. As I usually do when experiencing hardware issues, I journaled it. However, for reasons unknown even to me, I kept the journal on Facebook rather than here. 

Today, with the removal of the failing drive and its’ replacement with a 1TB SSD, I am done with the portion of tasks associated with resolving this issue that have to do with physically troubleshooting and replacing hard drives. There is a longer-term set of tasks upcoming involving the machine-by-machine deployment of outboard backup volumes, signaling the definitive end of my five years of desultory seeking to create a LAN-based backup system, but that’s a series of blog posts for another day.

Here’s all the stuff I posted on Facebook regarding this issue from December 23, 2016 until today, January 3, 2017. I have removed posts that were from friends and observers here; they can still be seen on the original FB thread.



December 23, 2016 at 12:38am ·

Arrgh, the boot volume on my MPB failed! The data I need, all my working files, are safely mirrored and I can just go work on one of my other machines, but geez, I won’t have time to fix the damn thing until next week!
December 23, 2016 at 9:17am
I was awakened this morning by my parents urgently calling to ask if I could locate some financial information, one of their HDs having failed, I think, although it was somewhat hard to follow their explanation of the issue.

December 23, 2016 at 12:00pm
I was able to mount the MPB as an external drive and am now ‘imaging’* the data over to another outboard. Roughly 600gb to sling, running at 16gb/hr give or take. The process ought to complete in 37 hours or so. Aargh.I cloned a 1TB SSD to a 2TB last night, coincidentally. A mere 12 hour process with today’s blazing transfer speeds. At least we don’t have to sit with the damn machine rotating floppies or swapping DVDs out any more.Oh, wait, hold on: SuperDuper just choked! Damn data integrity shinola!

*not actual, you know, bitwise imaging

December 23, 2016 at 12:57pm

hm, might be well fucked. I’ll look at CCC after I run an errand or two. I moved to SD! after CCC for some reason I now forget.

After SD! choked I went back to recovery mode and told DU to image the bad volume to the external and that failed too with an i/o error. SD! gave me a diagnostic on an individual file and halted instead of skipping and moving forward with a log, which would have been my preferred option.

I think my next best options here are directory-tree restricted copies and after that manual copies. I don’t actually think there’s anything unique or mission critical on the machine that’s not already mirrored, I just didn’t want to have to do a hand rummage and compare if I didn’t have to.

I set up the drive after the last machine failed this summer days before a revenue gig and I had to source this axe right quicklike. That machine was still on Mavericks and I migrated everything to Yosemite after I wrapped that gig. The old Mavericks boot drive is still viable and in the old machine, and I know it can reboot this machine, so I do have a known-good outboard boot solution.

All this fucking travel this year has prevented me committing the week or so of sustained effort to get that last-mile stuff set up. Bummer. At least the local mirroring stuff seems bulletproof, it’s twice this year that’s saved my bacon.

December 23, 2016 at 4:01pm
Well, disconcertingly, the Pro just self-booted in the middle of various tasks including running a CCC copy. CCC was able to pick up and move forward, though. CCC also reports physical read errors and, thankfully, does NOT abort the copy.

December 24, 2016 at 1:03am · Edited
Well, good news, and although I can’t match CCC’s bad file report with the size of the uncopied data, there’s nothing here that should prevent the cloned drive from booting. Trying tomorrow. Still probably best to wipe and bump to Sierra and then migrate. Man, I HATE running the current version of an OS release, it just offends my sensibilities. Maybe I can rig a work around to run that Yosemite clean install again. There’s nothing that makes me happier than defeating installer restrictions.

December 24, 2016 at 11:19am
Cloned drive boots. Now to ponder whether ’tis nobler in the eyes of man to clone and clone again, to a drive week-wiped free of foul corruptions’ stink, or to take up arms, and by opposing the screwdriver’s lance to the helices of steel that bind the shield, expose the innermost parts of that foe and servant, thereby to effect a transplant?

December 24, 2016 at 11:27am · Edited
I had actually planned on a drive swap to an SSD on this machine after Xmas. I still need the machine to work on a couple things before then. Opening and swapping drives two times in rapid succession increases the chances of zapping the mobo. Recloning it it is, because what s a day between friends?

December 24, 2016 at 11:55am
hm, I just had a thought – I think my old-style cloning of bootable volumes as a backup and migration strategy is probably not viable longterm any more because it won’t migrate the recovery partition. so even when I get this back in working shape I will need to do an install/migrate route for the SSD later on.

December 24, 2016 at 3:58pm
CCC has a Recovery HD creation function, cool. But it requires an extant recovery volume, and I have just noticed that my current primary boot vols were all stood up as clones, and thus lack the partition.
I will direct a squinty-eyed gaze at the one volume that did have said partition, the MPB drive that failed, kicking off this tech struggle journal.
Normally I keep a technical journal of these incidents on ye olde blogge, and these will migrate there in time.
I think the thesis is that I may record my mistakes, and learn from them.

December 28, 2016 at 12:42pm
Status update: internal drive reformatted and restored from successful CCC backup clone. No recovery partition in place yet. That requires a clean install of Yosemite to some machine or other, something that will require another hour or so of supervision and drive swapping, then CCC can clone those volumes as needed.Next steps: transfer this set of tech logs to the blog, finish deferred production tasks on the MPB, begin the SSD migration on the Pro, finalize SSD install to this machine. I’ll give myself a calendar week for each of these.

December 30, 2016 at 12:34pm
In working toward getting a clean install of Yosemite on an outboard drive so that CCC can harvest and distribute the recovery partition I ran afoul of a driver conflict on the Mac Pro – that machine has had an NVIDIA GTX 970 as its primary video card for a couple of years now, and running late-model NVIDIA cards in post OS X 10.7 systems requires custom drivers, without which the machine goes into a boot-looped kernel panic. Naturally, the temporary installer volumes created when you run an OS X installer lack this driver, and boom, a day of wondering where the heck the right web forum was again.Anyway, clean volume created. Next challenge is migrating the 1TB SSD to the 2TB SSD and re-merging the 2TB vol with the old Mavericks 2TB vol document directory that went from primary to offline when I moved to the SSD.

I guess I could hand merge, since the local Yosemite docs dir is intentionally thin and all the applications and licenses are on the SSD. What really want is a tiered local torrent cloud sync, where the current solution I use mixes with a longer-term storage solution for older files and docs. just figuring out the ruleset is time consuming enough that I doubt I’d ever try to set something like that up though.

December 30, 2016 at 4:21pm
Alrighty, both SSDs boot and have recovery partitions on ’em. Now to research folder-based one-off sync tools. Seems like CCC or Super Duper should just have that as a core feetch.

January 3, 2017 at 4pm
Closing in on winding this up. The initial drive failure appears to have recurred on the same drive, so it’s likely an unrecoverable hardware fault, although I haven’t traced that down to the bare iron yet. I was anticipating this as a possibility and had prepped to swap in the 1TB SSD in that event, which has now been done.

The last little cleanup bits are re-merging the various disaporan Documents folders, something that, as hoped, CCC can handle, but which will require a written plan and a couple of afternoons. Once that’s been done, I need to distribute local backup drives to all the machines and get that set up and I should be hard-drive circus complete for another year or more. I fucking hope.