My Beep-BRRR notes

New 2Apr2021. Updated 6May021. This is not in group Technology yet, but it is in Just started refs.

Icon download: PDF

Beep-BRRR is supposed to listen to alarm sounds of any kind and then vibrate into a bed’s structure to wake a sleeping person. A sleep that might not, due to some degree of hearing loss, have been interrupted without this remedy.

Thanks, Kenny in Scotland, for suggesting it to be three R’s in the BRRR, so that the English reader sees that all those R’s are rolling. Or feels them in the body. .

Yes, I know that there exist a lot of boxes that would do this. May plan was to let go with one.


Apart from the real intro (discovering the need) this started with me asking some xCORE Microphone Array board questions on the XCore Exchange Forum. I then bought two boards DEV KIT FOR MICROPHONE ARRAY of type XK-USB-MIC-UF216 from XMOS. Let’s just call it MIC_ARRAY.

Now I’ve made a box for one of them and mounted it on my desk. The other board will, if I succeed, end up at a bedside table, inside a wooden box. I have the box design also planned. So I’d better succeed!

Getting started log

  1. xTIMEcomposer 14.4.1 Makefile: TARGET = XUF212-512-TQ128-C20. No entry for the generic board type. Don’t follow this one. Go directly to point 3:
  2. Analysing debug_printf.c .././XUF212-512-TQ128-C20.xn:27 Warning: XN11206 Oscillator is not specified for USB node.
    • Update: Simon Gapp pointed put that adding
      <Node Id="1" InPackageId="1" Type="periph:XS1-SU" Reference="usb_tile" Oscillator="24MHz“> will work, see his full XUF216-256-TQ128-C20.xn at GitHub, here. This is part of his Master’s thesis [5]
  3. Instead of trying to find out what’s missing I’d rather see what XMOS has for me. I will now  try the AN00220 application note Microphone array phase-aligned capture example.  Download from (more below). It depends on the microphone array library lib_mic_array, see 141:[XMOS libraries] or LIBRARIES
  4. Now ImportExisting project into workspace with Copy projects into workspace ticked, from the download location. I am offline from the xmos server
  5. The AN00220 uses
    TARGET = MIC-ARRAY-1V0 together with a file called MIC-ARRAY-1V0.xn.
    But then, there is a newer called MIC-ARRAY-1V3.xn that I found with the lib_mic_array_board_support v.2.2.0 according to its index.pdf  documnet XM009805, 2017. I also found it here.  It adds names for the expansion header J5. Plus the name “XS2 MC Audio2 for the AN002020 is now “Microphone Array Reference Hardware (XUF216)” for the lib_mic_array_board_support. Finally, I expanded it myself to TARGET = MIC-ARRAY-1V0-MODand MIC-ARRAY-1V3.xn to MIC-ARRAY-1V3-MOD.xn See point 9 (below)
  6. My question is why XMOS didn’t build this in as an option in xTIMEcomposer? Why do I have to download the AN00220 or lib_mic_array_board_support to discover this?

7. Code space left for me

The AN00220 compiled to the below HW usage. They say that “This demo application shows the minimum code to interface to the microphone array.” Fair enough, I shouldn’t be worried at all, I guess:

Creating app_phase_aligned_example.xe
Constraint check for tile[0]:
  Cores available:            8,   used:          4 .  OKAY
  Timers available:          10,   used:          4 .  OKAY
  Chanends available:        32,   used:          8 .  OKAY
  Memory available:       262144,   used:      20680 .  OKAY
    (Stack: 2252, Code: 7160, Data: 11268)
Constraints checks PASSED.
Constraint check for tile[1]:
  Cores available:            8,   used:          1 .  OKAY
  Timers available:          10,   used:          1 .  OKAY
  Chanends available:        32,   used:          0 .  OKAY
  Memory available:       262144,   used:       1232 .  OKAY
    (Stack: 348, Code: 624, Data: 260)
Constraints checks PASSED.

8. Adafruit 128×64 OLED display

Getting the Adafruit 128×64 OLED display up and running was not easy at all.

In my other boxes (aquarium controller, radio client  and bass/treble unit) I had used the smaller 128×32, product 931 (here) with zero problem getting it up and running for the first time. The flora of displays based on the SSD1306 chip from Univision Technology Inc was perhaps smaller then. I have used I2C address 0x3C for them all.

But the 128×64 hardware ref. v2.1, product 326 (here) was harder. Or maybe I didn’t pay enough attention to the right detail from the beginning. I could have stumbled upon the correct solution immediately, but Murphy’s law prohibited it. My road became maximum bumpy.

The boards from Univision UG-2832HSWEG02 for the 128×32 (here) and the 128×64 UG-2864HSWEG01 (here) say little about I2C address. The first says nothing, the second says that pin 15 D/C# “In I2C mode, this pin acts as SA0 for slave address selection.” My problem was that I went to the circuit diagram. Don’t do that! The page for 128×32 says right there that “This board/chip uses I2C 7-bit address 0x3C”. Correct. The page for the larger 128×64 says “This board/chip uses I2C 7-bit address between 0x3C-0x3D, selectable with jumpers”. Also 100% correct! But the diagram says 0x7A/0x78 (here). If you download the fresh code via the Arduino system the I2C addresses should be fine. But I ported the Adafruit code to XC some years ago, and have cut that update branch. .

It says “v2.1” and “5V ready” in the print on my 128×64 board. There is a long single page document for all of these display boards (here, updated 2012!) where I finally picked up the address: “128 x 64 size OLEDs (or changing the I2C address). If you are using a 128×64 display, the I2C address is probably different (0x3d), unless you’ve changed it by soldering some jumpers“. Had my attention span down the initial page for the 128×64 been longer, I’d saved a lot. Like this:

Then there is header pin 7 VIN (3V3 ok or 5V required?). My128x64 board as mentioned says “5V ready” in the print and it contains an AP2112K-3.3 regulator (here) according to another diagram. On my proper diagram it’s just drawn anonymously. Since my XMOS MIC_ARRAY board outputs 3V3 only and the AP211K-3.3 according to the data sheet must (?) have 4.3V to get the 3.3V out (even if the dropout is very low) I simply soldered it out and connected VIN and 3.3V internally. This was close to stupid, but was a shot in the dark since I hadn’t found the correct I2C address – the display was so dark. Because, when I got the I2C address correct I saw that the one board that I had not modified (I have two) and the one I did modify worked almost equally well – even if I think my removal got me the voltage drop more “3.3V” for the display, and I think it looked brighter. The AP2112K-3.3 takes 3.3V in quite well! I think this can be read from the single page document (above) as well, but there are so many ifs and buts there that it’s hard to get the cards shuffled correctly.

Adafruit has (as I do) written a lot of words, which is better than few words – provided they all point in the same direction or are able to point in a certain direction at all. I think that Adafruit would need to iterate and read again and then update non consistent information. Much doesn’t always mean correct.

By the way, I also had to add fresher pull-ups on the I2C SCL and SDA lines of 1k. The built-in 10k isn’t for much speed. I use 100 or 333 kbits/sec. Here is the connection diagram (drawn in iCircuit which has a global view of header pin numbering).

Fig.1 – Cable connection diagram (30 kB) here)

9. Target and .xn file for xflash

See my xCore Exchange community question (14Apr2021) at xCORE Microphone Array .xn file and xflash.

14Apr2021: my .xn file is here: MIC-ARRAY-1V3-MOD.xn. This goes with TARGET = MIC-ARRAY-1V3-MOD in Makefile.

Observe 141:[XFLASH from Terminal].

10. Serial number, processor and internal QSPI FLASH

See ref above. The 2MByte QSPI FLASH is internal (on chip) is integrated on this processor, opposite to the xCORE-200 Explorer board, which has an external 1MByte QSPI FLASH.

Serial number Processor type Internal (on chip) QSPI FLASH
1827-00193 Type: XUF216-512-TQ128
Printed: U11692C20 GT183302 PKKY15.00
(2018 week 33)
IS25LP016D (if newer than 2020.10.05,  [3])
IS25LQ016B (is older, manual)

11. Serial output to 3.5 mm jack

I probably hijacked this one on Tue Apr 27, 2021 9:12 pm: I2S Ports synchronized by same clock in two parallel tasks. Plus, see AN00219 (below).


See 141:[XMOS libraries] and 141:[Importing (a source code) library when xTIMEcomposer is offline].

Some of the below have been mentioned above. I assume this is the  the most relevant list. I have experience with those in red:

  • APPLICATION NOTES – just to remind myself of those that may be of interest
    • AN01008 – Adding DSP to the USB Audio 2.0 L1 Reference Design
    • AN00103 – Enabling DSD256 in the USB Audio 2.0 Device Reference Design Software
    • AN00209 – xCORE-200 DSP Elements Library
    • AN00218 – High Resolution Delay and Sum
    • AN00217 – High Resolution Delay Example
    • AN00219 – Low Resolution Delay and Sum (PDF, SW). Should output to the 3.5 mm sound output jack
    • AN00220 – Microphone array phase-aligned capture example (above and below)
    • AN01009 – Optimizing USB Audio for stereo output, battery powered devices
    • AN01027 – Porting the XMOS USB 2.0 Audio Reference Software onto XU208 custom hardware
    • AN00162 – Using the |I2S| library
    • USB Audio Design Guide also covers the xCORE-200 Microphone Array Board. 110 pages! See [4]
  • Microphone array library lib_mic_arraycode githubuserguide
    • AN?? = separate application note not needed
    • AN00220 uses it
  • xCORE-200 DSP Library lib_dsp
    • AN00209 describes it
  • S/PDIF library lib_spdif
  • Sample Rate Conversion Library lib_src
  • Microphone array board support library lib_mic_array_board_support (latest PDF)
  • I2C Library lib_i2c
  • SPI Library lib_spi


Wiki-refs: …

  1. MICROPHONE AGGREGATION SOLUTIONS by XMOS, with ref to software tools, software libraries, application notes, hardware manual (below), design files and advisories & notices, see
  2. xCORE Microphone Array Hardware Manual (XMOS XM009730A 2018/6/14), download from [1] or –
    There is a small fault in it , with the errata here: On page 14 the pin X0D39 is called LED_OEN when it in fact goes to the expansion header J5 pin 10 (this is ok documented). The LEDs are always output enabled (OE) by all the hardware buffer chips 74LVC125A and 74LVC1G125 all have their OE control pins tied to GND, ie. always enabling all LEDs.
    Update: in lib_mic_array_board_support there is an #if defined PORT_LED_OEN which indicates that this output has at some stage been connected to the LED OE control pins
  3. XUF216-512-TQ128 Datasheet, 2020/10/05 XMOS Document Number: X007542, see 1.17.pdf. This document is not for my processors, but it’s only the QSPI flash that has changed. But it has a much nicer layout then the older documents, by which [1] on 15Apr2021 is referring to the older document 1.16. There is a “latest” url here:
  4. USB Audio Design Guide by XMOS, 2016/5/12 (XM0088546.1). Also covers the xCORE-200 Microphone Array Board and not only USB. 110 pages. See[design-guide](6.16.1alpha1).pdf. XMOS helped me find it, even if it didn’t show up on any search: “This design guide can be found on our website on usb multichannel audio page here If you scroll down to the quick links section at the bottom of the page you will find the document linked under the ‘software design guide’ link.
  5. XMOS USB – MEMS microphone array audio interface by Simon Gapp (2021). Part of master thesis at TU Berlin, Department of Engineering Acoustics. See
  6. USB Audio 2.0 Device Software – source code by XMOS. See which downloads sw_usb_audio-[sw]_6 with directories lib_logging, sc_i2c, sc_usb_device, lib_mic_array, sc_spdif, sc_util, lib_xassert, sc_usb, sc_xud, sc_adat, sc_usb_audio, sw_usb_audio

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.