[How to do instruction] DIY USB Consumer Controller

[wdyn1]

This is a How To guide on making a USB Consumer Controller for Moode Audio (or any other purpose) using CircuitPython >= 7.1.0 , framework, and a compatible microcontroller board. This guide assumes that you have some working knowledge of CircuitPython. At the end of this How To, you will have a USB volume and playback control device working with Moode Audio.

This has been tested on RP2040, SAMD51, and SAMD21 based microcontroller boards. It may work on other microcontrollers, but I don't have the hardware to test. It also has not been tried on SBC Linux computers (eg. RPi zero, 4B, etc., again I don't have any laying around right now...) but in theory could work with some effort.

---

Step 1:

Download or clone the USB Consumer Controller project repo and copy the contents of the 'CIRCUITPY' folder to your CIRCUITPY drive.

Step 2:

Edit 'CIRCUITPY/usb_cc/usb_cc.json' configurations file on your CIRCUITPY drive to reflect your desired functionality and pin connections.

For example:

Code:

"buttons": {
    "peripheral_type": "Buttons",
    "value_when_pressed": true,
    "pull": true,
       "pins": {
       ### EDIT THESE MESSAGES AND PIN NAMES ###
           "SCAN_PREVIOUS_TRACK": "GP0",
           "PLAY_PAUSE": "GP1",
           "SCAN_NEXT_TRACK": "GP2",
           "STOP": "GP3",
           "MUTE": "GP4"
       }
   },

The messages are derived from these consumer control messages and the pin names are the pin names that you have connected pushbuttons to on your board (eg. "GP0", "D0", etc).

There are also options for a rotary encoder and led. Connect the encoder and LED to your board as desired and edit those pin names as well. There are also a number of settings that can be changed. For example, you may find that your rotary encoder operates in reverse. In that case, set the "reverse" option to true.

If you want to change the functionality of the rotary encoder, change the messages in the 'volume_up' and 'volume_down' callback functions in 'CIRCUITPY/usb_cc/usb_cc.py'

Code:

def volume_up():
   usb_cc.message = 'VOLUME_INCREMENT'

def volume_down():
   usb_cc.message = 'VOLUME_DECREMENT'

Step 3:

Set up triggerhappy. There are several guides to setting up triggerhappy on this forum. If you need help, let me know.

Step 4:

Determine and edit the boot delay. 

When using this with my Moode setup, I found that I needed to get the timing right to be automatically recognized as a consumer control device. It seems to be after RPi boot starts but before triggerhappy starts. 10 seconds works for me, but you may need a different delay. Power off your Raspberry Pi and plug in your microcontroller board. Power up your RPi and wait for Moode to start. Try the controls. If it works, great!

If the controls do not work, try adjusting the delay value in 'CIRCUITPY/boot.py'

Code:

import time

# CHANGE THIS VALUE TO CHANGE THE BOOT DELAY
time.sleep(10)

Optional:

The default consumer control library provides only the very basic CC messages to get started. There is an extended CC module available and usable by this project. Download the consumer_control_extended module and copy it to your 'CIRCUITPY/lib' folder. This will override the default library and only use the extended module.

Note that consumer_control_extended is not an exact superset of the default library. For example, "VOLUME_DOWN" vs "VOLUME_DECREMENT" and "VOLUME_UP" vs "VOLUME_INCREMENT". I haven't done a full inventory of differences, so refer to the appropriate documentation for the library/module you are using.

[Tim Curtis]

Cool. Is this an alternative to the GPIO Button Handler?

[wdyn1]

Cool. Is this an alternative to the GPIO Button Handler?

Something like that. I guess it depends on what your question is. It's more of an alternative to those USB volume controls I've seen people buying as this is a completely configurable USB consumer control device. My RPi header pins are all blocked by my amp hat but I like the tactile feel of buttons and knobs and I happened to have a couple of extra RPi Pico laying around... Bob's your uncle. Arguably, the real magic is in the underlying app framework.

[DRONE7]

This is installed and configured on another board (such as a Zero) which is then connected via usb to the Pi running Moode and acts as a controller using the buttons connected to the Zero ???   Do  I have that right ?

[wdyn1]

This is installed and configured on another board (such as a Zero) which is then connected via usb to the Pi running Moode and acts as a controller using the buttons connected to the Zero ???   Do  I have that right ?

Installed and configured on another board, yes. But not like a Zero et al. Load the project on a microcontroller board capable of running CircuitPython such as these.

For example, I've tested on RP2040 based boards, SAMD51 based boards, and SAMD21 based boards.

Edit: It may be possible to run this on a Zero as they can run CircuitPython. I haven't tried TBH. I'm doubtful about the USB connectivity from a Zero. I know it's theoretically possible to do, but I don't think CircuitPython for *nix is that advanced.

[DRONE7]

Great !   got the concept....though when I click through your link it surely shows Pi Zero, Zero W, Zero 2 W, and Pi 4 ....bit confused as to which board that I have would work here...:-)

This would be an excellent 'cabled' remote if I read it right :-) and could be run from a listening chair to a RPi in a cupboard or another room...

I will see if I can find a Pico here (at the ends of the earth .. )

Pico found and ordered....looking forward to trialing this !

[wdyn1]

shows Pi Zero, Zero W, Zero 2 W, and Pi 4

Ah... yep. They're on there.

I'll have to be more explicit. I haven't done any development or testing with this on the SBC Linux RPi stuff and this guide is not for them.

However, that gives me an idea. When I can scrounge up a Zero W, I'll see what I can do about a small Bluetooth or WIFI remote.

'cabled' remote

That's a great way of putting it. My eventual plan, though, is to mount the microcontroller board inside my Moode case and just expose the pushbuttons and rotary encoder along with the LCD so it would be a standalone player for my desktop.

I had been developing an IR remote control sensor peripheral but couldn't get it to be reliable enough for release. I feel like it's a hardware issue I'm having as it would work fine one minute then flake out and come back on occasion. I'll order a new sensor and get back to it eventually maybe. But a Bluetooth remote sounds more enticing now that I'm thinking about it.

at the ends of the earth

Which end? Lol.

[TheOldPresbyope]

Yeah, once you break away from the GPIO-verse you find yourself immersed in the world of message protocols. The hardware communication medium chosen—USB, Bluetooth, WiFi, Ethernet—gets abstracted into the OS and fades into the background. I’ve played mostly with Bluetooth for wireless control (ab)using preexisting HID protocols but I’ve recently spun up Home Assistant (for environmental monitoring) and it has rekindled my interest in MQTT messaging over WiFi.

The good news is, there’s plenty of choices for us hackers. The bad news is, there’s plenty of choices. I’ve got boxes full of past triumphs and…erm…interesting efforts?

Party on!

Regards,
Kent

[wdyn1]

gets abstracted into the OS and fades into the background

That's what I've tried (and I think succeeded at) here. This project is more a side-effect of creating the underlying framework that abstracts the hardware and multi-tasking away as much as possible. If you're into this sort of thing, I might encourage you to take a look at the app framework I've developed. I think it's cool at least :-)

I'm taking a short break from this project to work on something else, but Bluetooth and WIFI peripheral drivers are in the works!