Category: electronics

HDMI-CEC to Onkyo RI Bridge

Published September 2, 2024

ESPHome device, a Seeed Studio XIAO ESP32S3 and level shifter with 3.5mm TS and HDMI connectors.

After getting the Onkyo RI support for ESPHome and Home Assistant in place, it was neat that I could turn my Onkyo A-9050 amplifier on and off remotely, but it wasn’t actually very useful; it didn’t save me any time/hassle. This iteration, adding HDMI-CEC support, brings it all together.

Back when I started this project, my main goal was to find a nice way to deal with toggling the power on the amplifier. Because I only use a single input on the amplifier and volume is already handled by the Apple TV remote, I don’t use the remote and it’s stored away in the basement. Normal practice was to manually press the power button on the front before using it, but this was irritating so I went looking for a better way, and the result was this project.

Initially I was looking at a way to use Home Assistant to coordinate powering the Apple TV and amplifier on, but it turns out there’s no good way to power up an Apple TV remotely; or at least not from anything that’s not an Apple device. I thought about going down the path of figuring out how the iOS / iPadOS does it, but the results of that would need to be incorporated into pyatv and chasing Apple’s changes was not a path I wanted to go down.

I then began thinking about it inversely: What if I could tell when the Apple TV woke and slept, and then take action based on that? After all, it’s already using the well-established Consumer Electronics Control (HDMI-CEC) to wake the TV… What if I could listen for that? And we’re always using the Apple TV remote when watching content and there’s no need to wake it while out of the room, so pressing a button on the remote to get things started is just fine.

Well, it turns out that was easier than I thought. Using Palakis/esphome-native-hdmi-cec, a HDMI-CEC component for ESPHome, and then doing a little protocol analysis I now have a device that:

Listens for the Apple TV to wake up and sends and sends a Power On to the receiver.
Listens for the Apple TV to go into standby and sends a Power Off to the receiver.
Sends events to Home Assistant whenever a broadcasted HDMI-CEC Standby (0x36) or Report Power Status (0x90) are received.
Exposes controls in Home Assistant for a variety of Onkyo remote control commands and broadcasting an HDMI-CEC Standby (0x36). The latter puts my TV and the Apple TV to sleep, and also gets heard by ESPHome (loopback) and results in the amplifier being powered off.
Exposes a service in Home Assistant allowing arbitrary HDMI-CEC commands to be sent.

The result is that when I press a button on the Apple TV remote to wake it up the amplifier powers on, the TV wakes up (as before), and all is ready to go with one button press. This satisfies my original goal, and also allows some lights to be turned on automatically.

I’ve still got some lingering architectural questions and may be digging further into the HDMI-CEC stuff to see if I can make it work better, but for now I’m happy. If/when I take this further, the big questions to answer are:

Currently ESPHome powers on the amplifier without Home Assistant. This feels rational for a device bridging the two protocols and makes the amplifier work more like a modern HDMI soundbar, but is it the best way to go? Running it all through HA would be a lot more complicated and network (and HA) dependent, but I could instead use the notification in HA trigger a Power On at the receiver. Are there ever situations where I’d want this device to not power on the amplifier?
The HDMI-CEC implementation is very simple, solely listening for two messages I saw the Apple TV send and taking action on them. One of these, Report Power Status, is per-spec used to send more than notifications of power being on. Should this be changed or further built out? (Note: Because the library doesn’t implement DDC for device discovery and addressing and such, it can’t be a full-fledged implementation. But that much is likely not needed; there’s more I can do.)
Is it possible to wake the Apple TV via HDMI-CEC? It’s not immediately obvious how, but perhaps with a bit of probing…?

Hardware-wise, this was simple to do. All it required was getting an HDMI connector (I used this one), connecting pin 13 (CEC) to a GPIO, pin 17 to ground, and pin 18 to 5v (VUSB) as per the readme at Palakis/esphome-native-hdmi-cec. Since CEC uses 3.3v there was no need for a level shifter as with Onkyo RI. I was able to add this on to the previous adapter without a problem and everything just worked.

With this ESPHome configuration I changed things around a bit, both to simplify and secure the device and make things better overall. As I learned more about ESPHome and started thinking about securing IoT devices, I wanted to minimize the ability to do OTA updates, including via the web UI, and access the API. I also wanted to pull credentials out of my .yaml file so I could more easily share it. Changes to support this, and some other nifty things, are:

Setting up a secrets.yaml to hold wifi_ssid, wifi_password, ota_password, and api_encryption_key.
- Tip: All this involves is creating a secrets.yaml file in the same directory as the configuration .yaml and putting lines such as wifi_ssid: "IoT" or api_encryption_key: "YWwyaUNpc29vdGg3ZG9oazdvaGo2YWhtZWlOZ2llNGk=" in it. Then in the main .yaml reference this with ssid: !secret wifi_ssid or key: !secret api_encryption_key or so.
- Generating an API key can easily be done with something like: echo -n `pwgen -n 32 1` | openssl base64
Setting a password for OTA updates.
- Note: Once this password is set, changing it can be a bit complicated (see ESPHome OTA Updates for more information). I suggest picking one password from the get-go and sticking with that.
To further minimize unapproved access, I did not enable the fallback access point mode, the captive portal, and disabled the web server component (because it’s unauthenticated and allows firmware uploads). I’m still thinking about disabling safe mode.
Set name_add_mac_suffix: true to add the MAC address suffix to the device name. This makes it easier to use one config on multiple devices on the same network, such as when doing development work with multiple boards. (See Adding the MAC address as a suffix to the device name.)
Because my Onkyo RI PR has not been merged (as of 2024-Sep-01), I had been manually patching to add it. It turns out that some PRs can automatically be incorporated into the config via external_components, and this works great for my needs until this gets merged:

external_components:
  # Add the HDMI-CEC stuff for ESPHome
  - source: github://Palakis/esphome-hdmi-cec
  # Add PR7117, which is my changes to add Onkyo RI. Had not been merged as of 2024-Sep-01.
  - source: github://pr#7117
    components:
      - remote_base

Despite stripping the configuration back a bit to secure it better, which in turn removes on-device overhead, I still have problems with the OTA update on the Seeed Studio XIAO ESP32S3. This is irritating because it means any changes require connecting a cable to flash it via USB, but I can also keep using the breadboarded SparkFun ESP32 Thing Plus for any future development.

The configuration I’m using can be found here: hdmi-cec-onkyo-ri-bridge_2024-sep-02.yaml

Note that this includes some development HDMI-CEC buttons, such as sending EF:90:00 and EF:90:01. This is part of some experimenting in attempts to wake up the Apple TV via CEC, but thus far doesn’t do anything. However, they serve as good examples of how to send multiple bytes to the bus. It also includes commented sections for the different ESP32 boards I’ve used and will likely need to be changed for your purposes.

Update on November 2, 2024

After using this for a while I ran into a couple quirks, so I’ve some updates to both the device config and ensuring it builds under the current dev version (ESPHome 2024.11.0-dev, as of about 10am EDT on 2024-Nov-02). Unfortunately this hasn’t solved the problem of uploading a new version via OTA on the Seeed Studio XIAO ESP32S3.

The current version of the device config can be found here: onkyo-a-9050_seeed_xiao_esp32c3_v1.2.0.yaml

The main changes here are the ESPHome device no longer takes action based on the received HDMI-CEC commands (via Onkyo RI), and I cleaned up and clarified the events. There are three distinct events that can be acted upon:

HDMI-CEC: Report Power Status: On: Something reported its power status as On.
HDMI-CEC: Report Power Status: Standby: Something reported it’s power status as Standby.
HDMI-CEC: Standby Command: Something sent a Standby command.

I now use Home Assist to trigger on HDMI-CEC: Report Power Status: On and turn on some lights and press Onkyo RI: On button, turning the amplifier on. For shutting things down I trigger on HDMI-CEC: Report Power Status: Standby and turn the amplifier and lights off. This is more dependent on HA, but it also gives me more flexibility.

(I’ve not (yet) started looking into waking the Apple TV via HDMI-CEC.)

Comments closed

Onkyo RI for ESPHome / Home Assistant

Published August 19, 2024

ESPHome Devices for Onkyo RI output; final and prototype.

Our living room has a very simple setup: a non-networked TV, an Apple TV, and an older Onkyo A-9050 amplifier that drives two small speakers and a subwoofer. It’s a great sounding yet simple setup for two channel audio, perfect for the basic streaming video watching we do.

Being older the amplifier doesn’t have any of the modern (eg: HDMI CEC) mechanisms for controlling it, but it does have a 3.5mm tip sleeve input on the back for Onkyo RI. This old, proprietary system uses a wired connection creating a bus that allows different Onkyo components to be controlled from one central component and thus one IR remote control.

This protocol is well documented, both via the LIRC project and some other sites (ref: LIRC documentation, Onkyo RI Protocol, docbender/Onkyo-RI) so this got me thinking it’d be pretty easy to implement in ESPHome and thus make the receiver controllable from Home Assistant. While this is only one-way control (since it’s basically a wired version of an IR remote), it would still allow for remote power on/off, input changing, etc.

After a few false starts, it turns out it was easy. Thanks to some pointers from folks in the ESPHome Discord I realized the best way was adding support for the protocol to the existing Remote Transmitter integration. Since this integration already had other protocols which used similarly timed protocols it was pretty easy for me to add Onkyo RI by copying the structure from another and modifying it for this protocol. (For reference, it’s not standard serial and requires specific timings, so it wasn’t as simple as just using a UART.)

I’ve since submitted PR #7117 to the ESPHome project to contribute this back, but despite passing all tests I’m still waiting for it to be accepted. (I looked into creating a custom component that could be included from another GitHub repo, but since this was best implemented by modifying an existing component, that didn’t make sense to me.) Until this gets accepted, I’ll just have to build esphome locally or if others want to do it, patching things based on the files in the PR.

Getting it all wired up was pretty simple with the only thing needed was getting electrical levels right, as the ESP32 microcontrollers use 3.3V logic and RI uses 5V. Thankfully a simple level shifter based around a FET can handle this. I first prototyped it with a SparkFun ESP32 Thing Plus and an Adafruit BSS138 on a breadboard and this worked great.

I really don’t like the idea of having a fragile and ugly breadboard sitting in the living room so I made plans to replace it with something smaller. After ordering parts and letting them sit for a few weeks, I finally got around to it one rainy Sunday afternoon.

This smaller, final implementation uses a Seeed Studio XIAO ESP32S3, a cheap level shifter board from Amazon (electrically identical to the Adafruit BSS138), and a 3.5mm TS cable. This was all wired up then bundled, along with the ESP32’s external 2.4 GHz antenna, into the a single blob inside of some heatshrink tubing making for a simple, streamlined final package. This works great, and now I have a single thumb-sized module with a USB-C connector (for power input and reprogramming) on one end and a 3.5mm plug on the other for the receiver. And it shows up wonderfully in HA and works as a remote control.

While the initial prototyping went great, I did run into two problems worth mentioning:

First, the one of the super-cheap level shifters I got from Amazon seemed to be bad. After hooking it up levels seemed all wrong, and I was seeing 3.3V at the ESP32 end and a solid 5V at the plug. Turned out to be a bad level shifter (or perhaps bad PCB) but by moving to the second shifter on the same board things were fine.

Second, when attempting to do an OTA update after the Onkyo RI firmware on the ESP32 S3 is running, it fails, indicating that Component esphome.ota took a long time for an operation (7339 ms)..

If I flash it back via USB with a default ESPHome config (via ESPHome web), it then OTA updates fine. This only happens on the ESP32 S3 and didn’t happen on the ESP32 WROOM, and seems related to how long the OTA takes on this module or maybe something caused by wireless transmission speeds? I didn’t try a serial upload nor troubleshoot any further as I both have a good workaround and see no need to reprogram the device any time soon.

The ESPHome configuration used for the final version can be found here: onkyo-a-9050_seeed_xiao_esp32c3.yaml. This uses a handful of commands that I tested to work on the A-9050. For other Onyko RI receivers there may be different commands needed; I suggest consulting the protocol docs mentioned above to discover others. I made a point of adding rational icons to each so that once added to Home Assistant things look good.

Using these is then nice and straightforward in HA, such as a basic button here on my dashboard which sends the Toggle On/Off (power) command:

type: button
show_name: true
show_icon: true
tap_action:
  action: toggle
entity: button.onkyo_a_9050_toggle_on_off
name: Onkyo A-9050
hold_action:
  action: none
icon_height: 40px

I’m not sure where I’ll go next with this. Toggling power on the receiver from a dashboard is neat, but not that important. Ideally I’d like to have a single automation that will change a couple of lights, turn on the receiver, and result in the Apple TV and television itself being turned on, but there’s still pieces missing to allow this.

It seems an Apple TV can’t be woken over the network when sleeping, the TV is not network accessible, and the receiver does not transmit status. So, I can’t do this with my current setup. I believe that it may be possible to build an ESPHome HDMI CEC device and connect it to another input on the TV to wake things up using something like Palakis/esphome-native-hdmi-cec, but that’ll be another project… At least now I’ve got a spare breadboarded ESP32 to start down that path. Time to order some HDMI breakout connectors, I guess.

Comments closed

DIY-ish Under Cabinet Lighting

Published December 23, 2023

After the kitchen was redone in our new house, the under-cabinet space (where lights would go) was intentionally left unpopulated; something for me to finish later. The electrician had fitted an outlet per cabinet grouping, and a switch on the wall that toggles those outlets, but I’d asked him to skip the lights because I really wasn’t sure what style or color we wanted, nor how I wanted to wire things. Being low voltage with the outlets and switch already fitted, it would be fairly straightforward later on.

This winter, looking for a project, I decided to finally get this done. After talking with my friend Dan and some investigating, I finally got a solution together.

What I ended up doing was sourcing a handful of parts, flexible PCB LED strips, aluminum enclosures, wire, and wall wart power supplies on Amazon, assembling it, and sticking it to the underside of the cabinets. This has worked out well, so I wanted to share what I did.

Our kitchen has three overhead cabinet groupings, the left-most has 22″ of face, the corner has 37″ of face (2x 10″ side cabinets and 1x 17″ center cabinet), and the right-most is a single 10″ cabinet. I had originally thought of ringing the underside of each cabinet with LED strip lights, but after some consideration I decided to do a single light assembly along the front edge of each cabinet, pointing down, with a wide-angle diffuser.

In the kitchen we have daylight (5000K) colored lights, but as the under-cabinet lighting is likely to be used as more of a night or secondary light, I figured on ~4000K lights. After buying strips of both 4000K and 6000K of to test, we ended up with some strips listed as Cool White 6000K. This matches pretty well whenever the overhead lights are on and it’s bright to cloudy day outside, and likely because of the grey-ish countertops it still looks fine when they are the only lights on.

It would have been possible to use a different type of strip that has multiple color temperature white LEDs and selectable color temperature, but doing this requires a controller external to adjust the light strips, which would have added around $60 just for the controllers, plus another $10 or so in LEDs, a remote control, more space taken up in the cabinets. This setup, with fixed color strips, is just AC-DC adapters plugged into the existing mains outlets, and the LED strips connected to the adapters. If we find that this isn’t good I may eventually go to controllers, but for now this is working nicely.

For the LED strips I chose FCOB LED strips from BTF-LIGHTING, 528 LEDs per meter, in 12V. With the heavy silicone coating over the LED chips it makes for a fairly even light. I chose the 12V variant of the lights because they have cut-points 22.83mm, which made it easy to make maximize the amount of LED strip under each cabinet. If the runs were longer it would have been wise to choose 24V to decrease the amperage, but at 14 watts per meter (W/m), the longest light segment will only take ~1.1 amps (A) so this should be fine. (Amazon Link)

For hookup wire I bought a simple coil of white 20 gauge copper clad aluminum (CCA) wire, again from Amazon. I already had some hookup wire, but I wanted white to blend in nicely with the cabinets. (Amazon Link)

For power supplies I picked up a basic five-pack of 12VDC / 2A wall warts. While I only needed three, the cost for five was $7 more than buying three, and since I’ll have LED strip left over and will likely build some more arrays for elsewhere in the house, I wanted spares. They also happened to come with (very cheap) barrel to screw terminal adapters that worked well enough. (Amazon Link)

Initially I was going to mount the LED strips directly to the cabinets, but Dan convinced me that even while out of sight it would look much better in an enclosure, and he was right. The project feels properly finished this way and it looks tidy. The enclosures also add additional diffusion, making the light look smoother and more even and overall better. For this I chose some 1m long pieces of aluminum channel with a 60° milky white domed cover, then cut it to width for each cabinet section. (Amazon Link)

The light enclosures include screws and mounting clips, but I instead opted for tape, and picked up a 5 yard roll of 3M VHB 4910, which is specifically described as being good for Polycarbonate, Aluminum, and Acrylic/Polyurethane Paint; perfect for sticking these housings to the underside of cabinets. (Amazon Link)

Assembly was done by first determining the width of the housings, so I went with even-inch sizes that are just slightly narrower than the underside of the cabinet. This resulted in five pieces: 1x 22″, 1x 16-1/2″, and 3x 10-1/4″. With the cover snapped into the aluminum channel it all cut clean and easily using a circular miter saw with a fine tooth carbide blade.

I then cut LED strip to the next step shorter than the housing, soldered the supply wire, stuck the strip into the housing via it’s self-adhesive backing, fitted the endcaps, added hot-melt glue for strain relief at the solder area, and snapped the face on. For the corner cabinet lights I wired it in a T arrangement, with the two sides being fed from the center, and then a wire out of the center to head up to the cabinet. This arrangement was because the corner cabinet holds the outlet near the back left side and it minimizes wire distance. It may have also helped with voltage drop on a long-ish strip of LEDs, but I’m not sure the ~30″ total would be enough to actually cause a problem.

A small hole (3/16″) was drilled in the underside of the cabinet to run the wire up to the supply, cabinet undersides cleaned and strips stuck in place with VHB tape, wire was tacked in place with hot melt glue, and screw terminal to barrel adjuster adapters (which came with the power supplies) fitted. A bit of cable tying to tidy the cables in the cabinets and it’s all done.

Total cost for this project was $122.83, and that includes the unused 4000K strip that I bought as a test. There is enough extra left over to do at least another 10′ of enclosed light somewhere else in the house, so I might build some light strips for under my workbench shelves or perhaps where I have music gear in my closet.

Kristen and I are both really happy with how it came out. More than just filling in the room and serving as a night light it actually offers usable additional light when working on the counters, especially when cooking at the stove.

Comments closed

HOWTO: Apple TV Volume Control of Bose Solo Soundbar Series II

Published November 22, 2022

After moving into our new house I we switched our trainer TV’s audio setup to a Bose Solo Soundbar Series II from Costco for $159.99. It’s a cheaper, basic soundbar that connects via TOSLINK, but sounds plenty good for TV/movie watching while pedaling away during the winter.

One of the really nifty features of the Apple TV is its ability to learn the infrared (IR) remote control signals of a another device so its remote can control the volume of receivers and such. This works out wonderfully, as with HDMI ARC, from the one Apple remote we can wake up the Apple TV, wake up the TV (and have it switch to the correct input), and control the volume of the soundbar.

Unfortunately, the learning process just didn’t work with the IR remote that comes with the soundbar. For whatever reason the Apple TV wouldn’t detect the IR signal being sent and the learning would fail.

Our previous setup — an old Yamaha home theater receiver and some Energy surround sound speakers — had no problems with the Apple TV. Once set up it was super convenient, so I wanted this in the new house.

I was able to solve this by buying a cheap universal remote, setting it up to control the soundbar, and then using it to the Apple TV. A bit of hoop jumping, and it cost an extra $10, but to me that’s worth the convenience.

Specifically, I bought this Philips SRP3249B/27 via Amazon, programmed the AUD button with code 2706 (Sound Bar, Bose), then used that to program the Apple TV via Settings → Remotes and Devices → Volume Control → Learn New Device….

When going through the learning process on the Apple TV I noticed an interesting quirk: If I followed the on-screen instructions exactly and held the remote button until the progress bar filled up, I would have to press and release the button on the Apple TV remote repeatedly to keep changing the volume. That is, each press/release turned it up or down just one notch on the soundbar.

By repeatedly pressing the button during the learn process the Apple TV learned something slightly different and then holding the button on its remote resulted in the soundbar continually increasing/decreasing the volume as the button is held.

Either way, it’s now working all from the Apple TV remote and all is good again. It just took an intermediate “universal” remote to bridge the gap.

Comments closed

Garmin Edge 130 (vs Edge 520) First Impressions

Published May 11, 2018

Back in 2011, when I was thinking about trying Lumberjack 100 for the first time, I bought a Garmin Edge 500 so I could log data and use heart rate zones for training. This worked out very well, and over the years I’ve iterated through of other Garmin units, including the Edge 510, 520, and now the new Edge 130. After years of acquiring increasingly complex units I recently switched to the less-featured unit (the Edge 130), finding that it covers everything I need, with some nice upsides over the 520. It’s a great computer for my mixed mountain / gravel / dirt / road riding, including the same, basic, line-following breadcrump route support that’s gotten me through self-navigated events like Barry-Roubaix and Marji Gesick.

First, the upsides. This unit has a higher resolution black and white screen which looks remarkably good in direct sunlight; much better than the color 520. The unit itself is quite a bit smaller (41 x 63 x 16 mm) than the Edge 520 (49 x 73 x 21 mm) which fits better on my stem mounts. I think the all-dark-grey color of the housing blends in with a bike better. The unit also feels like it responds faster to button presses. While this may just be the faster-updating display, it’s nicer when flipping through data pages.

Now, the downsides. While there are fewer features (no base map, can’t have as many data fields on screen at once — all well covered elsewhere), none affect my general use of the unit, but are worth mentioning. All are as of v2.20 firmware, and the software quirks will be changed:

Zones (heart rate and power) must be defined using Garmin Connect; they cannot be configured in the unit itself.
It is not possible to rename sensors. This means I can’t name a bike’s speed/cadence senors after the bike, which can make things a bit confusing if I have multiple sensors active in an area and I want to be sure the unit is currently listening to the right one.
The rubber cover for the microUSB connector feels a little flimsy. It effectively rotates on a small piece of rubber and as someone who plugs in my Garmin after every use I have concerns for how long it’ll last.
Some of the fonts seem a bit small, leaving a bunch of extra white space (particularly Heading as seen above). They are still readable, just small.
The unit prompts for ride type (Mountain, Road, etc) after each ride. You can’t select a ride type by default, although it does default to the last option. (Just something more to choose when saving.)

Outside of the display and size, the biggest difference between the 130 and 520 is the data fields each can display. While both units will record from the usual speed/power/heart rate sensors, they vary quite a bit in what each will display. Here are the data fields that the 130 and 520 will display (some names edited from official Edge 130 documentation so they’d align with the Edge 520 names):

Battery Level · Battery Status · Beam Angle Status · Cadence · Cadence – Avg. · Cadence – Lap · Calories · Dist. – Lap · Dist. to Dest. · Dist. to Next · Distance · ETA at Destination · ETA at Next · Elevation · Grade · HR – %Max. · HR – Avg. · HR – Lap · HR Zone · Heading · Heart Rate · Laps · Location at Dest. · Location at Next · Odometer · Power – 3s Avg. · Power – Avg. · Power – Lap · Power – Max. · Power – kJ · Power Zone · Speed · Speed – Avg. · Speed – Lap · Speed – Max. · Sunrise · Sunset · Time · Time – Avg. Lap · Time – Elapsed · Time – Lap · Time of Day · Time to Dest. · Time to Next · Total Ascent · Total Descent

Here’s the additional fields the Edge 520 will display:

Balance · Balance – 10s Avg. · Balance – 30s Avg. · Balance – 3s Avg. · Balance – Avg. · Balance – Lap · Course Pt. Dist. · Dist. – Last Lap · Dist. to Go · Front Gear · GPS Accuracy · GPS Signal Strength · Gear Battery · Gear Combo · Gear Ratio · Gears · HR – %HRR · HR – Last Lap · HR Graph · HR to Go · Light Mode · Lights Connected · PCO · PCO – Avg. · PCO – Lap · Pedal Smoothness · Power · Power – %FTP · Power – 10s Avg. · Power – 30s Avg. · Power – IF · Power – Last Lap · Power – NP · Power – NP Lap · Power – NP Last Lap · Power – TSS · Power – watts/kg · Power Phase – L. · Power Phase – L. Avg. · Power Phase – L. Lap · Power Phase – L. Peak · Power Phase – L. Peak Avg. · Power Phase – L. Peak Lap · Power Phase – R. · Power Phase – R. Avg. · Power Phase – R. Lap · Power Phase – R. Peak · Power Phase – R. Peak Avg. · Power Phase – R. Peak Lap · Rear Gear · Reps to Go · Target Power · Temperature · Torque Effectiveness · Trainer Resistance · VS – 30s Avg. · Workout Step

Most of these are around in-depth training with power, leg balance, support for electronic shifting, and other metrics that I don’t use. Therefore, nothing is lost moving away from the 520. Temperature — which is still recorded — is the only one that might be handy, but in my experience Garmin’s temperature readings seemed to be a bit off and didn’t really map to how it feels, and I definitely didn’t need it as an on-device data point during rides. (See the Edge 130 Manual Appendix and Edge 520 Manual Appendix for more information on what each field means.)

All said, I’ve had no problem configuring the Edge 130 to display the same screens as my Edge 520, resulting in the same functionality. Even nicer, on the 130 I can choose to not show the elevation chart; something that I’ve never found myself using and had to flip past on previous units. Here’s how I have the different display pages set up:

Page 1: / Six Fields: Timer, Speed, Distance, Time of Day, HR Zone, Heading

Page 2: / Four Fields: HR Zone, Cadence, Timer, Heading

Page 3 / Three Fields: Timer, Time of Day, Sunset

Page 4 / Map: No Fields (Map only, shows breadcrumb / loaded course.)

Thus far I’m happy with the unit; happy enough that I’ve sold my Edge 520.

For more specifics on the Edge 130, please check out both the excellent Garmin Edge 130 In-Depot Review by DC Rainmaker and the Garmin Edge 130 product page.

Leave a Comment

Titanium Frame Caused Garmin Speed Sensor Issues?

Published May 9, 2018

For a couple of years my main XC bike (2014 Salsa El Mariachi Ti) has had issues with my Garmin bike computers (Edge 510, 520, and 130) pausing mid-ride when I wasn’t actually stopped. This shows up as the head unit briefly flipping to a paused symbol (⏸), before returning to recording. Post-ride, when reviewing data in rubiTrack, the red callouts on the route indicate the pause locations and show they’d last for a couple of seconds. While I couldn’t reliably reproduce the pauses, they seemed to happen whenever I’d stop pedaling. It seemed to be more common when on tight/twisty trails where GPS positioning is spotty, but it’d also happen while moving at 10-20 MPH on straight, clear-sky areas. It almost seemed like the Garmin was choosing to pause when I stopped pedaling, an indicator that maybe the computer wasn’t aware the speed sensor was still moving.

On all of my bikes I have the Garmin Bike Speed Sensor fit around the rear hub and computer set to autopause when stopped, but the problem only happened on the El Mariachi Ti. It did not happen when using the older Garmin GSC 10 magnet/reed switch speed sensor which mounts to a chainstay. It also doesn’t happen on either of the steel (El Mariachi SS or Vaya) or carbon fiber (Mukluk or Camber) bikes, so I accepted it and figured the problem to be the wheel speed sensor. After acquiring an Edge 130 bundle I tried the new wheel speed sensor, but the problem persisted and got me thinking…

The solution ended up being simple: move the speed sensor to the front wheel. On an A/B test at River Bends Park where I did one lap with the sensor on the rear wheel, then another two with it on the front, the issue didn’t stopped appearing when the sensor was on the front.

Thinking it through I can only conclude that the problem was caused by the frame material. The sensor is detected by the head unit and seems to work fine the time, but perhaps the signal is sufficiently degraded that connectivity is sometimes lost. I suspect that then the unit falls back to pausing based on GPS signal + pedaling.

Leave a Comment

2017-2018 Trainer Setup: CycleOps Hammer

Published December 28, 2017

For winter 2017-2018 I’ve put together a revamped, and much improved, trainer setup in my basement. Since the last setup with a Kurt Kinetic Road Machine things have been changed pretty significantly. I had previously set things up in front of a CRT HDTV which I’d previously used as a gaming / home theater setup but over the years I didn’t really use it for anything other than movies while on the trainer and basement music; just kind of a waste. This fall I sold the CRT HDTV and stands, picked up a cheap LCD TV (with built-in Netflix and Amazon apps), and put the whole setup on a metal stand in front of the trainer.

The result is a nice setup where a movie plays at eyes-on-the-road level and TrainerRoad is just a glance below. A CycleOps Hammer smart trainer provides resistance when riding, a nice step up from using a power meter, fluid trainer, and shifting to reach power targets. Four speakers (plus two over the workbench) are connected to a home theater receiver / amp, making for great audio from movies, or music via the AppleTV (and iTunes), although I tend to have subtitles on while watching movies to keep the audio at a reasonable level. A squirrel cage fan blows from a distance to keep me cool while riding. To ensure good ANT+ connectivity I’ve located the Garmin USB adaptor to a table next to the bike where it has a short path to the trainer, power meter, and my heart rate strap.

Since I have a Stages power meter on the Vaya, I have the option of using TrainerRoad’s PowerMatch. This uses the on-bike power meter and adjusts the smart trainer so that everything matches. I understand how this will benefit those wanting the same power numbers indoors and out (since no two units match exactly), but I’m still undecided if it’s a good setup for me. I’ll be working that out over the next few rides.

So far this setup is working out very nicely. While expensive initially (almost the cost of a bike) I vastly prefer the feel of a direct drive smart trainer to the fluid trainer with power meter. Both are effective, but I’m really enjoying not having to shift and chase power targets. Both Kristen (she also bought a Hammer) and I are following TrainerRoad plans over the winter, and as it moves into more over-under workouts, especially those with very short high intensity intervals, having a smart trainer is a huge bonus. It’s very difficult to effect radical changes in power and stay on target when shifting and matching speed to a power target. A smart trainer eliminates that need.

Leave a Comment

Wahoo KICKR Customer Service Disappointment

Published December 21, 2017

Planning to follow a TrainerRoad plan with Kristen all winter, and a little irked at the quirkyness of shifting to hit power targets on my current setup, I became interested in a smart trainer. My buddy Mike let me borrow his Wahoo KICKR, something I’d been itching to try after hearing so many good reviews of them. In short, I really liked the experience and was quite impressed by how much easier it made riding indoors. I focused more on putting out effort and selecting my cadence and less on staying on target, and large swings (say, over/unders) were MUCH easier to do when I didn’t have to seek the moving power target. I really wanted one. A few days later I noticed that Wahoo was selling NOS (new old stock) 2016 model for $899, which seemed perfect! The $1199 retail price is a bit more than I can afford, but this was doable for both Kristen and I. Orders were placed and we got ready to sell our fluid trainers.

Not hearing anything on the order after four days we sent notes to Wahoo’s customer service department. The responses indicated the units had accidentally been oversold, so we were offered refurbished 2016 units for $100 less. Having the same warranty and being even cheaper, that sounded great! We both accepted the offer and waited. A day later we were informed that the warehouse had found more stock of the new 2016 units and those were on the way, with the refurb offer rescinded. Not as good of a deal, but still, great! Because of this back and forth Melinda, the customer service person, tossed in a 142×12 Thru Axle Adapter for me and a TICKR X Heart Rate Monitor for Kristen; both things we could use and a really nice gesture.

Unfortunately, when the KICKRs arrived, we found that Wahoo had screwed up. These were not new units, nor refurbished, but instead returns which likely hadn’t been opened since the customers packed them up. Mine was scraped and the end caps were chewed up as if the previous owner didn’t clamp it down properly and had the bike come off while riding. The cassette was slightly greasy, it had a bunch of non-Wahoo stuff (Garmin manual and packaging, Monoprice packaging) in the box, and fine plastic dust from the expanded foam packaging was spread all over, including in the resistance unit. Kristen’s was arguably worse, with a heavily scuffed flywheel area (as if the owner had it resting against something), an empty through axle adapter box, and the previous owner’s personal info: the RMA from Clever Training and — inexplicably — a copy of his vehicle inspection report from Volkswagen Credit.

My KICKR:

Kristen’s KICKR:

Separately we both immediately contacted Wahoo, but being Saturday didn’t hear back until Monday afternoon. (They’re open M-F, 10am – 7pm, and email responses seem to take about a day.) The first responses offered $100 refunds claiming the units were refurbished. After pushing back indicating that they are simply used and don’t seem like it’d be up to their standards, the refund offer was upped to $200 with the opportunity to test them out before accepting. While $699 is an even better price, neither of us were keen on paying so much for used trainers with plastic dust in sensitive electronics.

Since it’s often easier to work things out over the phone I decided to call Wahoo. I spoke with Micah, who explained that the original customer service person I’d contacted via email, Melinda, was best suited to help me. (I got the impression she’s a lead or manager.) Indicating that what I really wanted was a new trainer, and that I was hoping they could sort this all out, he informed me that the 2016 units are gone, so that’s no longer possible, but he’d get in touch with Melinda and let her know that we had talked. A short while later I heard back from Melinda, offering to return the used trainer and give a 10% discount on a new 2017 KICKR. I replied asking for the RMA, declining to purchase the 2017 model. (In the mean time Kristen had called and set up an RMA for hers, but did not receive a discount offer.)

I understand that things go wrong with warehousing and shipping, especially when winter (trainer time!) is coupled with the busy holiday season, but I can’t help but be left quite soured by this experience. Almost two weeks after making the purchase, with time sunk into a back and forth via email and visiting FedEx, we’re both back where we started… without smart trainers. And waiting on refunds.

Good thing we’ve still got fluid trainers to ride… Because the CycleOps Hammers that we ordered are still en route.

Leave a Comment

(SOLD) For Sale: MAME Cabinet

Published January 3, 2017

Up for sale is my MAME Cabinet. As documented on this wiki article I built this cabinet from a pile of lumber in the style of a late 1980s Data East cabinet, then outfitted it to be an extremely solid, quality MAME cabinet. Over the past few years I haven’t found the interest to keep working on it and now it’s time to sell.

Price is US$700, to be picked up at my house in Shelby Township.

Purchasing just the keyboard encoder, controls, coin door, and supplies for finishing the control panel would cost nearly this much.

Click on the photo above (or here) for more photos of the cabinet taken in early 2017. Please take a look at this article for information on exactly what went into the cabinet, and this photo gallery for some photos of it throughout the years.

This cabinet currently does not have a monitor installed, and the PC is a bit outdated (it was last powered on ~3 years ago), but all of the arcade-specific parts of the cabinet are in great shape. All controls feel good and are connected to a Hagstrom KE72-T encoder (no ghosting), the control panel can quickly disconnect from the main cabinet for ease of transport, and the monitor support bracket will make it easy to install a new display. Prior to listing this for sale I was planning to install a ~24″ widescreen LCD. Proper arcade game-type T-molding is installed along all edges and the cabinet has numerous handles, leveling feet, and roller wheels to make moving it easy.

Part specifics can be found on the wiki article; almost everything was purchased from Happ Controls and thus is full arcade quality. The control panel is topped with Formica and features eight buttons per player, some MAME-specific buttons for adjusting in-game controls (DIP switches, volume, etc), and there are three hidden buttons on the sides to act as coin inputs. The Millipede-sized real-arcade trackball serves as a normal mouse, and a wireless Logitech keyboard is included.

The cabinet features a temperature-controlled vent fan, internal power strip, speaker amplifier, remote bezel light switch, remote power and reset buttons, and quick-disconnects for all internal connections. PC-mounting points inside are ATX-spec to make installing a bare motherboard easy. The control panel is removable, held in place with thumb screws making transportation even easier.

Please contact me at steve@nuxx.net if you are interested in buying my MAME Cabinet. It was built with extreme care and well loved, but it’s time for me to let it go.

EDIT: This has been sold. Thanks, Luke!

Leave a Comment

Canon 20D Err 99 Resolved by New Battery

Published December 29, 2015

I’ve been using my reliable Canon 20D for a while (11 years?), frequently employing a Tokina AF 100mm F2.8 macro lens for detail work. This is one of my favorite lenses and is great for bringing out detail I wouldn’t be able to see with the naked eye, but around six months ago I began occasionally receiving the generic “Err 99” when trying to use the lens. My other lenses (a Canon EF 24-70mm f/2.8L and EF 50mm f/1.8 II both worked fine, so I figured the problem was with the lens.

Turns out it had a surprising (and cheap) solution: the batteries.

When the problem originally manifested itself as a simple error that’d only occasionally happen, I would then turn the camera off and on and try again, and usually the lens would work. It also appeared correlated with the aperture used, so I figured the lens was failing; perhaps the iris was binding at some point. Last week I found that the error was occurring more frequently, and would be coupled with a low battery indicator that only appeared after turning the camera back on.

Since I was using the original two batteries I ordered two new ones via Amazon (STK’s Canon BP-511 2200mAh Battery, 2 Pack for $24.99) and they arrived today. Once charged up I tried them with the Tokina lens and it’s now working great. I’m still able to reliably reproduce the issue with the older batteries, so a solution has been found.

Apparently the Canon lenses use a bit less power, or perhaps are more tolerant of lower voltages. Either way, I’m glad everything is working well. I might even think about getting a new camera body… Although I’ll probably wait until this one dies. I must have balanced use pretty evenly across the batteries too, because they both show the issue to the same degree… What’d normally be good just confused things.

Leave a Comment