Manjaro Linux vs. Dell Latitude E7250 Bluetooth

Although the Dell Latitude E7250 allegedly had Bluetooth capability and the Blueman applet tried connecting to my Bluetooth headsets, the connection aways failed and nothing worked. There’s a WLAN module stuck in an M.2 socket inside the laptop providing both WiFi and Bluetooth:

Dell E7250 - DW1560 card in place
Dell E7250 – DW1560 card in place

A bit of searching suggested the driver wasn’t loading properly, which became obvious after I knew where to look:

dmesg | grep -i blue
… snippage …
[    5.678610] Bluetooth: hci0: BCM20702A1 (001.002.014) build 1572
[    5.678851] bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0a5c-216f.hcd failed with error -2
[    5.678853] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0a5c-216f.hcd not found
[   10.854607] Bluetooth: RFCOMM TTY layer initialized
[   10.854613] Bluetooth: RFCOMM socket layer initialized
[   10.854619] Bluetooth: RFCOMM ver 1.11

Without having the proper firmware / patch loaded, the module won’t work, even though the TTY / socket layers know it’s present, which explains why Blueman did everything except actually connect to the headsets.

More searching suggested you must extract the firmware HEX file from the Windows driver. Feeding the Service Tag into the Dell support site, then feeding “Bluetooth” and “Windows 8.1, 64-bit” (preinstalled on the laptop) into the Drivers & Downloads tab gets you the relevant EXE file: Dell Wireless 1550/1560 Wi-Fi and Bluetooth Driver. It turns out to be a self-extracting ZIP file (in Windows, anyway), so unzip it all by yourself:

unzip Network_Driver_5DFVH_WN32_6.30.223.262_A03.EXE

This produces a blizzard of HEX files in the newly created Drivers/production/Windows8.1-x64 directory. Each firmware HEX file is keyed to the USB Product Code identifying the unique USB gadget, found with lsusb:

… snippage …
Bus 002 Device 003: ID 0a5c:216f Broadcom Corp. BCM20702A0 Bluetooth
… snippage …

The DW1560 apparently has a USB RAM interface, with the specific HEX file identified in the CopyList stanza of the INF file corresponding to that USB Product Code:

grep -i -A 5  ramusb216f.copylist Drivers/production/Windows8.1-x64/bcbtums-win8x64-brcm.inf
… snippage …

However, the Linux firmware loader needs a different file format with a different name, mashed together from the HEX file, USB Vendor, and USB Product codes:

hex2hcd -o BCM20702A1-0a5c-216f.hcd BCM20702A1_001.002.014.1443.1572.hex

The converted firmware file goes where the loader expected to find it:

sudo cp BCM20702A1-0a5c-216f.hcd /lib/firmware/brcm/

Whereupon next reboot sorted things out:

dmesg | grep -i blue
[    6.024838] Bluetooth: Core ver 2.22
[    6.024868] Bluetooth: HCI device and connection manager initialized
[    6.024872] Bluetooth: HCI socket layer initialized
[    6.024874] Bluetooth: L2CAP socket layer initialized
[    6.024881] Bluetooth: SCO socket layer initialized
[    6.100796] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    6.100800] Bluetooth: BNEP filters: protocol multicast
[    6.100804] Bluetooth: BNEP socket layer initialized
[    6.157114] Bluetooth: hci0: BCM: chip id 63
[    6.158125] Bluetooth: hci0: BCM: features 0x07
[    6.176119] Bluetooth: hci0: BCM20702A
[    6.177114] Bluetooth: hci0: BCM20702A1 (001.002.014) build 0000
[    7.031228] Bluetooth: hci0: BCM20702A1 (001.002.014) build 1572
[    7.047177] Bluetooth: hci0: DW1560 Bluetooth 4.0 LE
[   13.141854] Bluetooth: RFCOMM TTY layer initialized
[   13.141865] Bluetooth: RFCOMM socket layer initialized
[   13.141872] Bluetooth: RFCOMM ver 1.11

The firmware may be in one of the myriad Bluetooth packages not installed by default, so perhaps identifying & installing the proper package would sidestep the hocus-pocus.

Maybe next time?

Now I can wear my Bose Hearphones in Zoom sessions with the E7250, because my Pixel 3a phone heats up almost to the gets-bendy level while thrashing its battery to death.

Alead Telecoil Receiver: Magnetic Field Check

I got an Alead / Nolan HearLinks (many adjectives) Telecoil receiver to boost my ability to hear music & presentations at Vassar, because they recently slotted telecoil loops into the floors of their public venues. It took a few concerts to get the appropriate volume setting, after which I wondered how sensitive the receiver was:

Alead T-coil receiver - test setup
Alead T-coil receiver – test setup

The small T in the upper right corner marks the receiving coil location, with the coil oriented parallel to the body’s long axis. It’s the secondary winding of an air-core transformer with a single-turn (perhaps using Litz wire) primary embedded in the floor, with the induced voltage obeying the usual transformer equation:

V = 2π µ₀ µr N A f H cos θ


  • µ₀ – vacuum permeability = 4π×10-7 H/m
  • µr – relative permeability
  • N – number of turns
  • A – receiver loop area, m²
  • f – signal frequency, Hz
  • H – magnetomotive force, A/m
  • θ – angle between windings

For a given installation and receiver position, pretty much everything is fixed, with the voltage depending only on the H field caused by the primary winding current.

The induced voltage is linearly dependent on the frequency, but the transmitter equalization filters apparently flatten the spectrum to get equal receiver amplitude between about 100 Hz and 5 kHz.

The coil in that picture has nine turns, with four passing through the Tek current probe. Applying 10 mVpp to the winding produces a corresponding current:

JDS6600 10mVpp 1 kHz - 4 turns - 1 mA-div
JDS6600 10mVpp 1 kHz – 4 turns – 1 mA-div

The scope sees 14 mVpp = 1.4 div at 1 mA/div = 1.4 mA. Dividing by 4 turns means the coil actually carryes 350 µA. The signal generator has a 50 Ω output impedance, so 10 mV should produce about 200 µA, which seems a bit low. On the other paw, the signal generator sees the coil as a dead short at 1 kHz, so I don’t trust the numbers.

Whatever magnetic flux it may be produces a 1 kHz tone at a somewhat higher volume (for the same receiver setting) than the fancy Vassar loops, so the flux is in the right ballpark. With a bit more attention to detail, perhaps I can tinker up a current-mode loop drive amplifier.

The Alead receiver has an internally generated tick audible at the audio volume I need for the Vassar loops, which is 5 to 7 steps down from the maximum volume at 15 steps. It seems related to the internal Bluetooth hardware, although it’s present even when the receiver is not paired with my Pixel phone and, in fact, is unchanged even when 100 feet from the nearest electronic device.

When I reported the problem, they said:

Yes, you can hear very minor tick sound on telecoil mode. It is caused by some electronic and current to make those tick sound. Sorry for this defective on the design.

It had one job that it doesn’t do well, so it’s on the way back for a refund.

Evidently, I must build an audio loop receiver to get what I want …

Lenovo Headset Volume Control Lube

The volume control wart pod on the cable of my old and longsuffering Lenovo headset had been dropping out the right channel for a while, eventually prompting me to discover it comes apart by simply pulling on the halves:

Lenovo Headset - control pod
Lenovo Headset – control pod

There being no way to get closer to the open-frame volume pot’s innards, I eased a drop of DeoxIT Red along its edge (upper in the photo), slipped another drop into what’s presumably the wiper opening in the knob, and ran it through enough cycles to spread the juice evenly.

Reassemble in reverse order and It Just Works™ again.

Baofeng UV-5: Squelch Pop Suppression

Our first ride with the Baofeng UV-5 radios subjected us to loud pops around each transmission. Back on the bench, this is the signal applied to the earbud during a no-audio simplex kerchunk:

Baofeng - squelch pops
Baofeng – squelch pops

The small noise burst to the right of the center, just before the downward pulse, happens after the carrier drops and before the squelch closes; it’s familiar to all HT users.

The huge pulses, upward at the start and downward at the end, cause the pops. They’re nearly 3 V tall, compared with the 300-ish mV squelch noise, and absolutely deafening through an earbud jammed in my ear. Mary refused to listen, so we finished the first ride in companionable silence.

I think the radio switches the audio amp power supply on and off to reduce battery drain. It’s obviously a single-supply design, so we’re looking at a hefty DC blocking capacitor charging and discharging through the earbud resistance. I suppose that’s to be expected in a $25 radio.

The obvious solution: clamp the audio signal to something reasonable, perhaps with a pair of nose-to-tail Schottky diodes across the earbud. Rather than using axial diodes, along the lines of the 1N5819 diodes in the WWVB preamp, I used a BAT54S dual SMD diode as a tiny clamp:

BAT54S dual-Shottky diode - SMD package
BAT54S dual-Shottky diode – SMD package

No pix of the final result, but it’s basically two wires soldered alongside the SMD package, surrounded by a snippet of heatstink tubing to stabilize the wires and protect the SMD leads. It might actually survive for a while, even without the obligatory epoxy blob.

The BAT54S clamps the pops to 200-ish mV, as you’d expect:

Baofeng - squelch pops - clamped - 500mV-div
Baofeng – squelch pops – clamped – 500mV-div

That’s a kerchunk at twice the vertical scale. The very thin spike at the start of each pop isn’t audible, as nearly as we can tell, and I’ve cranked up the audio gain to make the squelch noise more prominent. Your ears will determine your knob setting.

With the audio amp applying 3 V to the diodes at the start of each pop, you’re looking at an absurdly high pulse current. I’m sure the radio exceeds the BAT54 datasheet’s 600 mA surge current limit by a considerable margin, but I’m hoping the short duration compensates for some serious silicon abuse.

Tamping those pops down made the radios listenable.

I’ve often observed that Baofeng radios are the worst HTs you’d be willing to use.

Audio Direction Finding

Given a point source of audio (or RF, for that matter) that’s far enough away to produce more-or-less plane wavefronts, the range difference between two microphones (or ears) is:

ΔR = (mic separation) x sin Θ

The angle lies between the perpendicular to the line from the midpoint between the mics counterclockwise to the source source: + for sounds to your left, – for sounds to your right. That’s the trig convention for angular measurement with 0° directly ahead, not the compass convention, but you can argue for either sign if you keep track of what’s going on.

The time delay between the mics, given c = speed of sound:

ΔT = ΔR / c

For microphones 300 mm apart and c = 344 m/s:

ΔT = 872 µs = 0.3 m / 344 m/s

If you delay the sound from the mic closest to the source by that amount, then add the mic signals, you get a monaural result that emphasizes, at least a little bit, sounds from that source in relation to all other sounds.

In principle, you could find the angle by listening for the loudest sound, but that’s a fool’s game.

There’s an obvious symmetry for a source on the same side, at the same angle, toward the rear.

A GNU Radio data flow diagram that lets you set the angle and listen to / watch the results:

Audio Direction Finding.grc
Audio Direction Finding.grc

The original doodles show it takes me a while to work around to the answer:

Audio direction finding doodles
Audio direction finding doodles

SoundTech CM-1000 USB Channel Layout

Although microphones intended for conference tables aren’t suitable for inconspicuous hearing aids, they go a long way toward working out algorithms (*). This is a SoundTech CM-1000 USB mic:

SoundTech CM-1000USB microphone
SoundTech CM-1000USB microphone

It produces noise-canceled stereo output and a quick test shows impulse sounds produce reasonable left and right responses responses; I can’t vouch for the noise cancelling part.

A click to the right side:

CM-1000USB mic - Right pulse
CM-1000USB mic – Right pulse

And to the left:

CM-1000USB mic - Left pulse
CM-1000USB mic – Left pulse

The green trace (Channel 2) is obviously the Right channel, which corresponds to in1 on the Scope Sink block and out1 of the Audio Source in the GNU Radio data flow diagram:

Microphone Time Delay.grc
Microphone Time Delay.grc

There’s an irreconciliable clash between 0-index and 1-index numbering in there, but the microphone’s “Left” and “Right” channels appear in the proper places when you look at the mic from the conference room side of the label as shown in the top photo.

Figuring the speed of sound at 344 m/s, that 100 µs delay means the mic capsules sit 34 mm apart, which looks to be about right, as the flat part of the housing under the label spans 22 mm.

That’s a tad skimpy for things like beamforming and direction finding, so I actually bought a set with a separate CM-1000 mic that plugs into the USB mic:

SoundTech CM-1000USB and CM-1000 microphones
SoundTech CM-1000USB and CM-1000 microphones

The channel layout diagram explains what’s supposed to happen:

Soundtouch CM-1000USB microphone channel layout
Soundtouch CM-1000USB microphone channel layout

The additional mic changes the response, so that the USB unit becomes the Left channel and the analog mic provides the Right channel. I don’t know what happens to the “noise canceling” part of the story.

With the mics positioned 200 mm on center, a click to the right side:

SoundTech CM-1000 mics - 200 mm OC - Right pulse
SoundTech CM-1000 mics – 200 mm OC – Right pulse


The eyeballometrically precise 600 µs delay corresponds to 206 mm at 344 m/s, which might actually be close: they’re 200 mm on center, but the Right-channel mic is 10 mm smaller and the mic might be half that much further away from the other one. Not that that makes any difference.

(*) And, frankly, slapping a mic on the table won’t bother me much at all…

Monthly Science: Audiograms

The audio test CD I used to measure my hearing for a Circuit Cellar project back in 2007 came to light, so I ran some tests:


I don’t have an absolute level calibration for any of those curves, so they can be shifted up or down by probably 10 dB without any loss of accuracy. The overall shape matters here, not the absolute level.

The brown curve shows my hearing as of nine years ago. I built and (of course) wrote about a rather chunky low-pass shelving filter that matched the 20-ish dB difference between my midrange and treble responses, then boosted the flattened result enough for me to hear what I was missing:

Board Top
Board Top

Surprisingly, it worked fairly well. That, however, was then and this is now.

The two red curves show my current response, under slightly different conditions: the “buds” curve uses the same earbuds as the 2007 curve and the “phones” curve uses over-the-ear headphones. Perhaps:

  • The previous (lack of) bass sensitivity came from the circuitry of the day
  • My bass has mysteriously improved
  • More likely, my midrange has gotten that much worse

The blue curve shows the response of a reference set of silver ears; the golden ears I used in 2007 were unavailable on short notice.

Given my limited bandwidth and the steep slope of that curve out toward the high end, simply fixing my (lack of) treble won’t suffice any longer: 50 dB is a lot of amplification. Compressing the bandwidth between, say, 200 Hz and 4 kHz to fit into 200 Hz to 2 kHz, then equalizing the result, might give me enough treble to get by, but it’d require re-learning how to hear.

That’s different from the straightforward frequency translation you get from a mixer. I don’t have enough audible bandwidth around 1 kHz to hear a 4 kHz slice of audio spectrum.

Back in 2007-ish, a real audiologist determined that I wasn’t “aid-able”. Maybe that’s changed.

The economics seem daunting. Michael Chorost gave a talk at Vassar lamenting the cost and terrible UX of his cochlear implants that reinforced my prejudices in that area. The discussion following my post on my Bose QC20 earphones includes useful links and rants.

The GNURadio project has enough signal-processing mojo for a nontrivial hearing aid, modulo having enough CPU power at audio frequencies. Battery power density remains the limiting factor, but I’m not nearly as fussy about appearances as most folks and some full-frontal cyborg wearables might be in order.