January 2018, I was corresponding with LIVALL over my failed LIVALL BH81H bicycle helmet. I really liked the helmet while it worked, but first its heart rate sensor failed and then the entire helmet stopped working. Remembering the BH81H’s good days, I quickly accepted LIVALL Support’s offer to purchase a new BH61S for $35, including shipping. The BH61S is essentially a BH81H, without the heart rate sensor and a bit of a different profile, but nearly identical in operation, even down to the front-mounted buttons.

I received the BH61S in February 2018 and it came with another BlingJet 100 that I left in the box, because I found little use for the first BlingJet 100 I received with my BH81H. After opening the package, I noticed the helmet was even lighter than the BH81H, so I weighed it in at 308 grams, nice! The BH61S had nearly identical construction to the BH81H , down to the straps and padding. Also identical to BH81H is the comfort, these helmets are barely noticeable compared to the comfort of a non-smart helmet.

The pairing setup for the BH61S is identical to the BH81H, just power on the helmet with the center round button and hold it down until a female voice announces over the helmet speakers “Pairing”. The pairing was quick and painless with my iPhone 6s+. I used the helmet for the ride to work the next day, which was near 0 and found that the helmet held its charge until I got to work, about a 1.5 hour ride due to the snowy conditions. The helmet continued to charge and operate like a champ until the spring, when it got pretty wet riding home one day. I tried to towel it off as soon as I got home, but it was a soaker of a rain and the helmet didn’t respond to button presses. I let it sit by the dehumidifier for a day and the helmet started working again – woohoo! Over the 1.5 years since I started using this helmet, I found that it is very sensitive to rain – don’t get it wet.

The helmet continued to work fine through the winter of 2019, which included a snowfall in the Twin Cities that bested the previous record by nearly 50% – yikes! All through this time weather, the BH61S worked, with wetter days requiring use of the dehumidifier mentioned above. In the spring of 2019, two issues developed with the helmet. The left speaker started to cut out. In September 2019, the left speaker stopped working and the center button has also started to fail, button presses only sporadically turn the helmet on or off.

Other notes: the audio quality from the speakers lacks bass and the microphone leaves plenty to be desired. While riding and making phone calls technically works, the quality of the BH61S’ microphone may drive your telephone call recipients crazy. I have to pretty much ride at less than 5 miles per hour for people to hear me on the helmet microphone.

Since buying into LIVALL helmets, Sena (motorcycle helmet company) has developed their X1 and R1 helmets, the latter includes a model with a front-facing camera, and other companies are offering smart helmets too, including Coros and Cosmo Connected. Still, the BH61S has been enough of a winner that I’m willing to triple down with LIVALL and pursue their latest helmets, the BH51M or BH51M Neo Range, whichever I can get my hands on for less. More on this in a future review, which will most likely note how much more the BH51M-series weigh and what that means to comfort over an hour plus commute.

** Update 11-7-2019 ** The helmet has officially died again. I heard rattling inside the plastic enclosure on the front of the helmet. Taking apart showed that R22 and R23 were literally blown off the board that is now a bit black in that area. If you have info on what the resistance should be for each of these resistors, please let me know! I haven’t found the board design files anywhere on the internet (yet).

This has come up for me a couple times and I can never seem to find a good source on the web.

For my Surly Big Dummy equipped with Surly Open Bar handlebars and Rohloff Speedhub, the shift cable housing length from the Rohloff grip shifters is 87 inches. This is for the largest Dummy frame, 22 inches, built in 2008.

This has come up, because I love my Yokozuna brake cable housing, so I decided to go with their shift cables this time around. To order long enough cables and housing, consider SKU 63640, Yokozuna’s Rohloff Cable kit, which includes the following:

• 2  pcs       2500mm x 4mm SIS black housing
• 2  pcs      SIS 1.1mm x 3000mm stainless steel shifter cable
• 6  pcs       4mm plastic housing end caps
• 2  pcs       Aluminum cable tips

Will report back on how it goes.

** UPDATE 11-9-2024 **

These shift cables have yet to be changed and I can say I’ve never experienced a better cable on my Rohloff-equipped Surly Big Dummy, it simply shifts like butter.

Two weeks ago I went over the handlebars on my Pugsley while riding Monarch in Carver Park Reserve. I twisted the handlebars pretty good and screwed up the Rohloff brand shift cables and housing, which has been too stiff since I started riding the Pugsley. I plan to dial up Merry Sales and order another set or two of Yokozuna’s Rohloff shift cables, could the Pugsley’s Rohloff start to shift better than it ever has? Also, I’m going to have to figure out something to do with the cable trays on the down tube, they’re too close to the front of the bike and force the cable housing into an odd position that I believe caused the stiff shifting the current housings and cables exhibit.

We have a couple high capacity drives attached to a Mac mini running macOS Server on High Sierra. Family Macs use Time Machine to back up to these drives. At some point, my wife’s password on her Mac (running Mojave) changed from what was on the mini and Time Machine began to error out. Some foreshadowing: she uses the same username on the mini and her Mac.

After her password on the mini changed, her Time Machine backups displayed the following error messages:

“There was a problem connecting to the server”
“Time Machine can’t connect to the backup disk”
“OSstatus error 65”

Basic troubleshooting called on me to make a manual connection using Finder (command K) from her Mac to the mini – mounting the drive was successful, so I went back to Time Machine and tried from there, but the same errors above barfed out. Frustrating.

From Terminal on my wife’s Mac, I pasted in the following line:

log show --predicate 'subsystem == "com.apple.TimeMachine"' --info | grep 'upd: (' | cut -c 1-19,140-999

I pasted output from the command into Google and came across this post on Apple’s site:

https://discussions.apple.com/thread/7898878

Yes, Satrop’s issue and fix is it! The username on my wife’s Mac is identical to the username on the mini and somehow this disturbs things if the password changes. To get around this issue, I decided to use the following workaround, which is essentially changing the credentials on her Mac for how it mounts the mini. From her Mac I had to:

1. Disable Time Machine by System Preferences->Time Machine->Select Disk…->(click the disk you’re trying to mount)->Remove Disk.

2. In Keychain.app, remove all instances of the saved password to your NAS, in my case the mini. I searched for “mini” and “10.0.1.125” and deleted those instances.

3. From Finder, mount the mini’s disk (Command K) using my own credentials, which obviously differ from hers.

4. After the disk mounts, go back to System Preferences->Time Machine->Select Disk…->(select the mounted disk – I used AFP to mount the disk, so when I hovered over it I could see its address had the AFP protocol).

5. Success! When you quit Time Machine preferences, it should automatically start a new backup (or continue an existing one).

I have posted on installing and removing Homebridge platforms and accessories, which is even easier with a Homebridge web user interface called “homebridge-config-ui-x”. I installed it with Terminal.app and the following command:

sudo npm install -g –unsafe-perm homebridge-config-ui-x

By installing this package, you’ll be able to install and uninstall packages and accessories and update Homebridge’s config.json file with a graphical user interface. Be sure to open port 8080 or whatever port you prefer from the outside so you can gain remote access (or just access it from inside your network for better security). If you open it to the outside, be sure to change the default username and password 🙂

** UPDATE 12-24-2020 **
To incorporate the homebridge.log file into the config-ui-x interface, open the config.json file (mine is here):

sudo pico /Users/bradschwie/.homebridge/config.json

and insert the following code (please note, your port number and file path will likely differ, this is what I used on a macOS Server machine):

{
"platform": "config",
"name": "Config",
"port": 8581,
"auth": "form",
"theme": "dark-mode",
"tempUnits": "f",
"lang": "auto",
"log": {
"method": "file",
"path": "/Users/bradschwie/.homebridge/homebridge.log"
}
},


Last summer, the plastic micro-USB covers snapped off my lovely Romanian Lumma Systems Grip Lights. I had plenty of time to find new covers, but of course didn’t and could have at least covered the port with a large rubber band, but I digress.

This spring, I carelessly rode through a few spring showers that seemingly shorted out my lights. The lights will still somewhat work when pressing the button, but they randomly turn on and off and cycle through modes all by themselves. Fortunately the laser still works. I happened to be one of the lucky backers who received all three sets of lights that I ordered, which means I still have a couple working sets to roll with, but I really want to fix up my broken left Grip Light.

I pulled two phillips screws out of the grip light and disconnected its power cable. The board slides out of the housing by gently prying up on the rubber fittings around each LED. Using my digital multimeter, I delicately poked around the PCB, which isn’t all that complicated. I soon found resistors R7, R8, and R14 to have given up their ghosts. R7 is marked 470, R8 is covered in rust and unreadable, and R14 is marked 220. I’ll try to verify R8 on another board, but it will probably be covered in dried hot glue unless I tear some away to expose it.

I don’t have the proper board level soldering gun to attempt this repair, but I may give it a shot with my pencil soldering iron and try to replace the blown resistors. Will post an update later if I can size and source the resistors.

I must be looking in the wrong place, but it felt difficult to figure out what to use for remove Testor’s Black Enamel from a paint brush. After reading a few sources, we decided to use a small container (wire nut) filled with Paint Thinner.

After inserting the brush, covered in black enamel, into the wire but, five the brush a several spins, pull the brush out, and wipe the brush with a paper towel. Allow it air.

Good to go!

If you are running Aruba VIA 3.1.3 (vpn), you might notice in Console.app that a previous version of Aruba is busy throwing out error messages:

Apr 18 13:59:24 BCS-MBP-2 com.apple.xpc.launchd[1] (com.arubanetworks.vpnservice[1428]): Service could not initialize: Unable to set current working directory. error = 2: No such file or directory, path = /Applications/Virtual Intranet Access.app/Contents/MacOS: 17G5019: xpcproxy + 10940 [1405][1FC7BF6A-6296-382C-913A-4FF8915953DC]: 0x2
Apr 18 13:59:24 BCS-MBP-2 com.apple.xpc.launchd[1] (com.arubanetworks.vpnservice): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.

This may be a previous version of Aruba VIA that I did not completely remove from my Mac. I had good luck leaving the current version installed and just deleting the remaining portion of the old version by running the old version’s uninstaller, saved here:

“/Users/(your username)/Library/Application\ Support/Virtual\ Intranet\ Access/Uninstaller.app”

Running this file seemed to delete files from the old version residing in Application Support and other places, but it doesn’t seem to delete anything relevant to the current (3.1.3) version of Aruba VIA installed in my Applications folder.

My Big Dummy needs a couple chains to work. I wanted to flip the drivetrain tonight and had a couple partial KMC chains laying around, a CN-HG53 and a CN-HG73. For anyone else trying this, I was able to join them together and they seem to work. I plan on rolling with these the rest of the winter and putting something more uniform back in play this spring. I can’t wait!

For over four years, I used Moves.app on my iPhone and loved how the data was freely exportable, easy to view, backed up, and best of all automatically collected without having to start and stop an app like Strava – I’m a Mac user, devices should work for us, not the other way around. Frustrated and disappointed, I wasn’t completely surprised when FaceBook shut down Moves on July 31, 2018. I was hoping Moves.app would continue to allow me to view previously recorded data after Moves’ servers were shut down, but sadly I was wrong, the app stopped working.

I had backed up Moves data through July 18, 2018, but my export and download on July 30 from Moves’ servers failed without me noticing until it was too late – darn it!

Looking ahead, I wanted a replacement for Moves.app for the above reasons. Happy to say I found a new developing app called “Move X“, which reproduces several of Moves’ features including the gorgeous user interface. I’ve been reporting bugs and feature requests to the Move X developers, who readily correspond via email. I don’t have a FaceBook account, but if you do, log in to it with Move X and the developers will be able to more closely work with you on identifying bugs with Move X.

For those who backed up and downloaded their Moves.app data, Move X directly imports your old data. Just move the .zip file containing your old Moves.app data to your iCloud Drive space and Move X should be able to find it.

The tracking algorithm Move X uses has a ways to go. It seems your movement data is uploaded to their server where it is crunched. I bike a lot and unfortunately, Move X always seems to think I’m driving a car as “Transport”. While Moves.app had a way to change the category for data incorrectly categorized, Move X does not – I hope they fix this soon or else figure out a better algorithm, because nearly all of my bike rides are being categorized generically as “Transport”.

Otherwise, I’m excited to be back up and running so soon. While Move X doesn’t have near the movement-type accuracy that Moves.app had, the developers seem eager to improve on it and for now, Move X accurately tracks where I was and when I was there, which is the other half of what I really wanted. Yes, Google Timeline does this too, but I find I much prefer the Moves.app/Move X interface for quick views of my data from a mobile device.

** Update **
I stopped using Move X for several reasons: the app is a little buggy, the app uses more power than Moves did, the app’s algorithm isn’t good at selecting your exercise/transport type, and the developer doesn’t let you download your own data generated through Move X. I’m now using the Google Maps app on my iPhone and using the integrated Timeline feature. You don’t even need to have the Google Maps app running on your iPhone for Timeline to track where you’ve been, which is the most elegant solution for me.

My son hopes we can host a Minecraft Server with lots of mods, but he wants our server based on the 1.8.x codebase, because of how it works with combat. I was concerned about security exploits on an older version of the software, but it seems that there aren’t too many well-published exploits in the wild. The current codebase for the server and client are up to 1.12 with 1.13 on the horizon, so our old server will need to allow folks with 1.9-1.12+ clients. Our server will also need to allow teleporting to other worlds, which we will accomplish with BungeeCord acting as a proxy and the Multiverse-Core plugin. We are opting to locally host the Minecraft Server from our Mac mini running High Sierra and macOS Server, so we also want Mac-specific startup scripts to automatically reboot the Minecraft Server suite any time after a reboot.

We considered running GlowStone, but for now, we decided  to use Spigot for the server software and BungeeCord as the proxy for multiple worlds. To get these software packages and Mac-specific startup scripts configured and installed, we followed Kyler Holland’s video:

https://www.youtube.com/watch?v=f7etfdVsNFw

We deviated from Kyler instructions with Spigot – we downloaded the latest 1.8.x version of Spigot (seemed to be 1.8.8), which we grabbed here:

https://getbukkit.org/download/spigot

And we also decided to run build 1303 of BungeeCord, which we nabbed here:

https://ci.md-5.net/job/BungeeCord/

We also modified the startup command for Spigot to give it 2 GB of memory using the following code:

#!/bin/bash

java -Xmx2G -XX:MaxPermSize=128m -jar spigot-1.8.8-R0.1-SNAPSHOT-latest.jar

To allow 1.9 and newer Minecraft clients to join our 1.8 server, we loaded the ViaVersion-1.3.0 plugin available here:

https://www.spigotmc.org/resources/viaversion.19254/

We also bumped the RAM requirements to 2.5GB, And everything seems to be running fine.

Since the original install, we’ve added plugins, including EssentialsX-2.0.1, Factions, Multiverse-Core-2.6.0, PermissionsEx-1.23.4, worldedit-bukkit-6.1.7.3, and worldguard-6.2.1. There are a few more that he wants, so I hope they don’t compromise stability.