Where should I connect the USB Connector Shield, or should I not?

I’m about to start wiring USB socket to experiment MIDI USB. But first, I wonder where I should connect the connector shield to. Should I connect the case to GND or should I do otherwise?

I found a good thread in Electrical Engineering Stack Exchange.

tl;dr: Never connect to GND. Leave it unconnected or connect to the shield of the rig. I should take the former in my current project.

Although it’s long, this thread is pretty interesting so is worth reading.

DC-DC Booster Design using MC34063

DR-110 that I am modifying currently takes 6V power supply from 4 AA batteries or 9V from an AC adapter. But since I’m thinking of connecting to USB, it’s convenient if we can draw power from it. From the device circuit diagram, I found the device requires at least 6V supply although USB supply power is 5V. It’s a good opportunity to learn how to use DC-DC booster since more project that uses USB will come.

I live near Jameco. It’s the best to use one they carry. It’s even better if the package is DIP since I often use breadboards. I checked their catalog and found a switching regulator called MC34063 is cheap and has plenty of inventory. It is versatile, too, that supports boosting, busting, and negating the power supply. I think this is a good choice for my regular switching regulator.

For DR-110, I decided to put 7V that is slightly higher than battery power. The circuit has a simple linear regulator. I expect it removes noise in the switching regulator output as long as it is small. The current supply probably is good enough with 50mA.

Collecting document is necessary first. Jameco provides MC34063 manufactured by STMicro, but their datasheet is simplified and vague. I cannot understand how to use it for lack of knowledge of switching regulator fundamentals. I also found decent application notes from ON Semiconductor and TI sites. They looked to have the same source and the contents look the same.

Following is an example circuit diagram of boost regulator. The circuit has a n oscillator that drives switch Q1 and Q2 that draws current from L to accumulate energy to boost power supply. The output voltage is determined by comparator that listens on output and adapts duty cycle of the switch in negative feedback manner. Well, it’s a smart design.

First, I used this circuit as is with modifying only R2 to make 7V output, but it generates a lot of audible ripple noises in the output. This approach was useless. I should took proper way that is to calculate circuit parameters by reading and understanding application notes. The application notes has enough information to design the circuit.

The frequency of the oscillator is determined by CT, and other parts hardly affect it. I decided the frequency first (a little lower than 100 kHz that is highest possible frequency). Then decided the switching duty cycle. Finally decided minimum L value. Tried the circuit using simulator and tweaked the parameters. The diagram below is the designed parameters. The resistor R4 is a load.

I found one difficulty in designing a switching regulator is that the behavior changes significantly when the load changes. Analog circuit usually does not change its circuit current drastically, so it might be better to figure it out when attaching a switching regulator. Following picture shows the behavior change when the load is very light (100 kΩ). Switching timings are much slower. Slow ripples are clearly visible, which must be so bad to an analog audio circuit. It’s better to experiment with real circuit to proceed further. But I don’t have a 10 μH inductor right now. So that’s it for today.

DR-110 Driving Pulses

The schematic of DR-110 is:

For this circuit, each percussion element seems to sound when you put a negative pulse of width 1 ms. I’ve put oscilloscope to observe the pulses come as expected.

Here are the pulses to the bass drum and output:

Blue: Input pulse, Red: Output
Blue: Input pulse, Red: Output

The pulse width looks to be around 1.3 ms.

These are the pulses to the snare drum and output:

Blue: Input pulse: Red: Output
Blue: Input pulse, Red: Output

For the hand clap, I only took pulses:

Blue: CP I, Red: CP II

This is a simulated output of the bass drum circuit:

The output would be weaker when the pulse is narrower:

A wider pulse gives a stronger output, but the waveform starts distorting significantly at certain point.

Started Modifying DR-110

It’s been a while since I stopped building things. But it’s a new year, I’ll try restarting it. For not making things for long, I cannot do anything aggressive yet. I would start with picking up an old DR-110 from my toy box to modify it.

This device is half-dead. Upper half of the display is not functioning. Membrane switches are not working well, too. The case is nice looking, so it may be fun to keep it and make it work. But it’s an old device and what can be done is pretty limited compared to contemporary feature rich devices. I would go simply with replacing the control by MIDI to make it done quickly.

DR-110 has four banks of memorable rhythm patterns from A to D. C and D out of them are preset so you can play these patterns without programming. But banks A and B are not usable since I cannot punch the patterns in because of the broken display. These banks C, and D, still plays nicely:

DR-110 Patterns (Bank C)
DR-110 Patterns (Bank D)

The sound is a bit old school, but I love it.

This is the starting point. I begin with investigating internals of the device.

Building DPDK on Raspberry Pi 3

I’m trying to build DPDK on Raspberry Pi 3 but couldn’t do it on Raspbian since it’s a 32-bit OS. DPDK uses several assembler instructions for ARM 8 that are only valid on 64-bit OS. So my effort starts with installing a 64-bit OS.

I found SUSE has released 64-bit Linux for Raspberry Pi 3:

I started with this OS image.

Choosing the Image

Three versions of distributions are avalable for Raspberry Pi 3:

  • openSUSE Leap
  • openSUSE Tumbleweed
  • non-upstream openSUSE Tumbleweed

I tried openSUSE Leap first, but could not zypper update. Then I tried openSUSE Tumbleweed. This worked fine.

There are four variations of images:

  • JeOS image (Just Enough OS)
  • E20 image
  • XFCE image
  • LXQT image
  • X11 image

I wanted to save disk space, so took JeOS.

Installation was done flawlessly. I’m using wired network to avoid spending time for WiFi setup.

Build Preparation

The system is missing compiler and so on. I first needed to install development tools. After logging in as root, I executed following.

# zypper refresh
# zypper update
# zypper install -t pattern devel_C_C++
# zypper install emacs libnuma-devel ncurses-devel kernel-source man

Then the system is ready for building DPDK.

Building DPDK

# see http://dpdk.org/dev
# and http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html
$ git clone git://dpdk.org/dpdk
$ cd dpdk
$ make install T=arm64-armv8a-linuxapp-gcc

Then compiler has passed, but…

Test Run

localhost:/home/naoki/workspace/dpdk/arm64-armv8a-linuxapp-gcc/app # ./testpmd 
ERROR: This system does not support "AES".
Please check that RTE_MACHINE is set correctly.
EAL: FATAL: unsupported cpu type.
EAL: unsupported cpu type.
PANIC in main():
Cannot init EAL
1: [./testpmd(rte_dump_stack+0x1c) [0x4c1854]]
Aborted (core dumped)

The CPU does not seem to support AES (Advanced Encryption Standard) instructions:

localhost:/home/naoki/workspace/dpdk/arm64-armv8a-linuxapp-gcc/app # lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Model:               4
BogoMIPS:            38.40
NUMA node0 CPU(s):   0-3
Flags:               fp asimd evtstrm crc32 cpuid

The CPU of Raspberry Pi 3 is Cortex-A53. The Wikipedia page for Arm architecture sounds like Cortex-A53 supports AES instructions, but according to Arm documentation, it seems to be up to implementation. So, I think AES instructions are unsupported by Raspberry Pi 3. How does DPDK think it’s supported then?

I found following code snippet in part of makefiles:

AUTO_CPUFLAGS := $(shell $(CC) $(MACHINE_CFLAGS) $(WERROR_FLAGS) $(EXTRA_CFLAGS) -dM -E - < /dev/null)


ifneq ($(filter $(AUTO_CPUFLAGS),__ARM_FEATURE_CRYPTO),)

So, gcc returns flag __ARM_FEATURE_CRYPTO that indicates encryption instructions support. But as seen in the previous lscpu output, the CPU does not support it. I guess the compiler gives wrong information because it’s a binary install via zypper. The compiler probably would return correct flags if built from source code, but it’s time consuming. Instead of building gcc, I put a quick workaround to DPDK as follows and rebuilt DPDK.

diff --git a/mk/machine/armv8a/rte.vars.mk b/mk/machine/armv8a/rte.vars.mk
index 500421a20..c83045b84 100644
--- a/mk/machine/armv8a/rte.vars.mk
+++ b/mk/machine/armv8a/rte.vars.mk
@@ -55,4 +55,4 @@
-MACHINE_CFLAGS += -march=armv8-a+crc+crypto
+MACHINE_CFLAGS += -march=armv8-a+crc
diff --git a/mk/rte.cpuflags.mk b/mk/rte.cpuflags.mk
index a813c91f4..cb899e86c 100644
--- a/mk/rte.cpuflags.mk
+++ b/mk/rte.cpuflags.mk
@@ -125,12 +125,12 @@ ifneq ($(filter $(AUTO_CPUFLAGS),__ARM_FEATURE_CRC32),)
-ifneq ($(filter $(AUTO_CPUFLAGS),__ARM_FEATURE_CRYPTO),)
+# ifneq ($(filter $(AUTO_CPUFLAGS),__ARM_FEATURE_CRYPTO),)
+# endif

In this time, execution looks better, although it failed again.

localhost:/home/naoki/workspace/dpdk/arm64-armv8a-linuxapp-gcc/app # ./testpmd 
EAL: Detected 4 lcore(s)
EAL: Probing VFIO support...
EAL: No probed ethernet devices
USER1: create a new mbuf pool <mbuf_pool_socket_0>: n=171456, size=2176, socket=0
EAL: Error - exiting with code: 1
  Cause: Creation of mbuf pool for socket 0 failed: Cannot allocate memory

I think this is because I haven’t setup huge TLB fs yet.

(To be continued)

PS: This may be helpful later:


BeagleBone Green: Enable CAN on Startup

Three steps:

  1. Enable CAN overlay by configuring cape manager
  2. Configure network interface
  3. Install startup program

1. Enable CAN overlay

Add following line in /etc/default/capemgr


2. Configure network interface

Add following lines in /etc/network/interfaces

auto can0
iface can0 inet manual
    pre-up /sbin/ip link set $IFACE type can bitrate 1000000 listen-only off
    up /sbin/ifconfig $IFACE up
    down /sbin/ifconfig $IFACE down

3. Install startup program

Setting the CAN interface to /etc/network/interface does not enable the CAN interface on startup for some reason. In order to workaround this problem, I installed a startup program as follows.

Following link was helpful:

Running a script on Beaglebone Black boot/ startup

The startup script to run on startup is as follows. This script also turns off wi-fi power management, thus I removed a cron entry I added before to disable the power management.

naoki@beaglebone:~$ cat /usr/bin/startup.sh

ifup -a
/sbin/iwconfig wlan0 power off

Following are the steps to create and enable a service that runs on startup.

  • Create the service
    vi /lib/systemd/startup.service
  • Edit the above file as necessary to invoke the different functionalities like network. Enable these only if the code needs that particular service. Disable unwanted ones to decrease boot time.
    Description=runs startup script after startup
    After=syslog.target network.target
  • Create a symbolic link to let the device know the location of the service.
    cd /etc/systemd/system/
    ln -s /lib/systemd/startup.service startup.service
  • Make systemd reload the configuration file, start the service immediately (helps to see if the service is functioning properly) and enable the unit files specified in the command line.
    systemctl daemon-reload
    systemctl start scriptname.service
    systemctl enable scriptname.service
  • Restart BBB immediately to see if it runs as intended.


BeagleBoneGreen: Disabling Wi-Fi Power Management Permanently

The operating system is Debian. This is a dirty solution but it does work anyway.

root@beaglebone:~# cat /etc/pm/power.d/wlan0_pm_off

[ -x /sbin/iwconfig ] || exit 0
[ -n "`/sbin/iwconfig 2>/dev/null | grep wlan0`" ] || exit 0

/sbin/iwconfig wlan0 power off
root@beaglebone:~# crontab -l | grep -v "^#"
*/1 * * * * /etc/pm/power.d/wlan0_pm_off
root@beaglebone:~# iwconfig wlan0
wlan0     IEEE 802.11abgn  ESSID:"*****"  
          Power Management:off

Test CAN connection between BeagleBone and MIDI/CAN converter

1. Enabled CAN at 1Mbps on BeagleBone:

Following operations seem to be necessary every BeagleBone boot. TBD to setup auto configuration on startup.

root@beaglebone:~# echo BB-DCAN1 > /sys/devices/platform/bone_capemgr/slots
root@beaglebone:~# ip link set can0 up type can bitrate 500000
root@beaglebone:~# ip link set can0 up type can bitrate 1000000
root@beaglebone:~# ifconfig can0
can0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          UP RUNNING NOARP  MTU:16  Metric:1
          RX packets:2 errors:0 dropped:2 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10 
          RX bytes:16 (16.0 B)  TX bytes:0 (0.0 B)
root@beaglebone:~# ip -d -s link show can0
4: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
    link/can  promiscuity 0 
    can state ERROR-ACTIVE (berr-counter tx 0 rx 127) restart-ms 0 
	  bitrate 1000000 sample-point 0.750 
	  tq 83 prop-seg 4 phase-seg1 4 phase-seg2 3 sjw 1
	  c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
	  clock 24000000
	  re-started bus-errors arbit-lost error-warn error-pass bus-off
	  0          0          0          1          1          0         
    RX: bytes  packets  errors  dropped overrun mcast   
    16         2        0       2       0       0      
    TX: bytes  packets  errors  dropped carrier collsns 
    0          0        0       0       0       0      

2. Wired CAN ports

Used MCP2551 for CAN transceiver.

Pin 24 -> CAN RX
Pin 26 -> CAN TX
Pin 2 -> GND
Pin 6 -> VDD 5V

3. Connected with MIDI/CAN converter via CAN bus

See the picture above.

4. Monitor MIDI/CAN converter via serial interface

naoki-macbook:~ naoki$ screen /dev/tty.usbmodem14244421

5. Monitor packets on BeagleBone and play

root@beaglebone:~# candump can0
can0 100 [3] 09 4A 46
can0 100 [3] 08 4A 00

Serial port monitor:

note on  [ 01 00] 4a
note off [ 01 00] 4a