DeLock 61114 uses a NEC Corporation uPD72873 (µPD72873) Chipset (Cardbus Firewire Interface)

I got myself a Cardbus FireWire card, namely a DeLock 61114. As it's always very hard to find the Chipset used for a particular card, I'd want to post it here, so that it may be found by neighbors also interested in this information.

→ DeLock 61114 uses a NEC Corporation (Renesas) uPD72873 (µPD72873) with vid 0x1033 and pid 0x00e7 [1033:00e7].

If you want to use the card for Audio applications I can attest that it does not work at all with either an Echo AudioFire 4 and a Focusrite Saffire Pro 26 I/O with ffado/jackd under Linux, which is not surprising as the NEC chipset if often classified as "problematic". I bought it for a different purpose and did not know the chipset in advanced, let's hope it will turn out to be usable.

lspci -tv

-[0000:00]-+-00.0  Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller
(...)

           +-1e.0-[02-06]--+-[0000:03]---00.0  NEC Corporation uPD72873 [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller

lspci -v

$ sudo lspci -s 03:00.0 -v -v -nn
03:00.0 FireWire (IEEE 1394) [0c00]: NEC Corporation uPD72873 [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller [1033:00e7] (rev 01) (prog-if 10 [OHCI])
Subsystem: NEC Corporation uPD72873 [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller [1033:00e7]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 64 (5000ns min, 11000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 8c000000 (32-bit, non-prefetchable) [size=4K]
Region 1: Memory at 8c001000 (32-bit, non-prefetchable) [size=256]
Region 2: Memory at 8c001100 (32-bit, non-prefetchable) [size=256]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
Kernel driver in use: firewire_ohci
Kernel modules: firewire_ohci

dmesg on insert

[ 4893.716245] pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0

[ 4893.716285] pci 0000:03:00.0: [1033:00e7] type 00 class 0x0c0010

[ 4893.716330] pci 0000:03:00.0: reg 0x10: [mem 0x00000000-0x00000fff]

[ 4893.716353] pci 0000:03:00.0: reg 0x14: [mem 0x00000000-0x000000ff]

[ 4893.716377] pci 0000:03:00.0: reg 0x18: [mem 0x00000000-0x000000ff]

[ 4893.716504] pci 0000:03:00.0: supports D1 D2

[ 4893.716511] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot

[ 4893.716732] pci 0000:03:00.0: BAR 0: assigned [mem 0x8c000000-0x8c000fff]

[ 4893.716747] pci 0000:03:00.0: BAR 1: assigned [mem 0x8c001000-0x8c0010ff]

[ 4893.716760] pci 0000:03:00.0: BAR 2: assigned [mem 0x8c001100-0x8c0011ff]

[ 4893.716868] firewire_ohci 0000:03:00.0: enabling device (0000 -> 0002)

[ 4893.717115] firewire_ohci 0000:03:00.0: setting latency timer to 64

[ 4893.776285] firewire_ohci 0000:03:00.0: added OHCI v1.10 device as card 2, 4 IR + 4 IT contexts, quirks 0x1

[ 4894.276463] firewire_core 0000:03:00.0: created device fw0: GUID 00004c020001af59, S400

Platform for Test

Dell Latitude D410, Intel(R) Pentium(R) M processor 1.60GHz, 2 GByte RAM, Kernel 3.11.6-1-ARCH, Archlinux x86 (32bit)

$ ffado-diag 
FFADO diagnostic utility 2.1.0-Unversioned directory
============================
(C) 2008 Pieter Palmers
    2009-2010 Arnold Krille


=== CHECK ===
 Base system...
  kernel version............ 3.11.6-1-ARCH
    Preempt (low latency)... True
    RT patched.............. False
  old 1394 stack present.... False
  old 1394 stack loaded..... False
  old 1394 stack active..... False
  new 1394 stack present.... False
  new 1394 stack loaded..... True
  new 1394 stack active..... True
  /dev/raw1394 node present. False
  /dev/fw* permissions:
crw------- 1 root root 248, 0 Oct 25 20:08 /dev/fw0
  User IDs:
uid=1000(chris) gid=100(users) groups=100(users),4(adm),10(wheel),14(uucp),92(audio),190(systemd-journal)
 Prerequisites (dynamic at run-time)...
   gcc ............... gcc (GCC) 4.8.2
   g++ ............... g++ (GCC) 4.8.2
   PyQt4 (by pyuic4) . Python User Interface Compiler 4.10.3 for Qt version 4.8.5
   jackd ............. jackd version 0.121.3 tmpdir /dev/shm protocol 24
     path ............ /usr/bin/jackd
     flags ........... -ljack -lpthread -lrt 
   libraw1394 ........ 2.1.0
     flags ........... -lraw1394 
   libavc1394 ........ 0.5.4
     flags ........... -lavc1394 -lrom1394 -lraw1394 
   libiec61883 ....... 1.2.0
     flags ........... -liec61883 -lraw1394 
   libxml++-2.6 ...... 2.36.0
     flags ........... -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lglib-2.0 -lsigc-2.0 
   dbus-1 ............ 1.6.16
     flags ........... -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -ldbus-1 
 Prerequisites (static at compile-time)...
   gcc ............... gcc (GCC) 4.8.1 20130725 (prerelease)
   g++ ............... g++ (GCC) 4.8.1 20130725 (prerelease)
   PyQt4 (by pyuic4) . Python User Interface Compiler 4.10.3 for Qt version 4.8.5
   jackd ............. sh: jackd: command not found
     path ............ 
     flags ........... Package jack was not found in the pkg-config search path.
   libraw1394 ........ 2.1.0
     flags ........... -lraw1394 
   libavc1394 ........ 0.5.4
     flags ........... -lavc1394 -lrom1394 -lraw1394 
   libiec61883 ....... 1.2.0
     flags ........... -liec61883 -lraw1394 
   libxml++-2.6 ...... 2.36.0
     flags ........... -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lglib-2.0 -lsigc-2.0 
   dbus-1 ............ 1.6.14
     flags ........... -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -ldbus-1 
 uname -a...
   Linux latitude-d410 3.11.6-1-ARCH #1 SMP PREEMPT Sat Oct 19 00:29:46 CEST 2013 i686 GNU/Linux
 Hardware...
   Host controllers:
03:00.0 FireWire (IEEE 1394) [0c00]: NEC Corporation uPD72873 [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller [1033:00e7] (rev 01) (prog-if 10 [OHCI])
Subsystem: NEC Corporation uPD72873 [Firewarden] IEEE1394a OHCI 1.1 Link/2-port PHY Controller [1033:00e7]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-
Latency: 64 (5000ns min, 11000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at 8c000000 (32-bit, non-prefetchable) [size=4K]
Region 1: Memory at 8c001000 (32-bit, non-prefetchable) [size=256]
Region 2: Memory at 8c001100 (32-bit, non-prefetchable) [size=256]
Capabilities:
Kernel driver in use: firewire_ohci
Kernel modules: firewire_ohci

   CPU info:
Architecture:          i686
CPU op-mode(s):        32-bit
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 13
Model name:            Intel(R) Pentium(R) M processor 1.60GHz
Stepping:              8
CPU MHz:               1600.000
BogoMIPS:              3193.49
 Configuration...
  IRQ information
Hardware Interrupts:
--------------------
 IRQ    0: PID:  None, count:           [906109], Sched None (priority None), drivers: ['timer']
 IRQ    1: PID:  None, count:            [10837], Sched None (priority None), drivers: ['i8042']
 IRQ    8: PID:  None, count:                [1], Sched None (priority None), drivers: ['rtc0']
 IRQ    9: PID:  None, count:                [1], Sched None (priority None), drivers: ['acpi']
 IRQ   12: PID:  None, count:              [755], Sched None (priority None), drivers: ['i8042']
 IRQ   14: PID:  None, count:           [112126], Sched None (priority None), drivers: ['ata_piix']
 IRQ   15: PID:  None, count:                [0], Sched None (priority None), drivers: ['ata_piix']
 IRQ   16: PID:  None, count:             [6925], Sched None (priority None), drivers: ['uhci_hcd:usb1', 'ehci_hcd:usb5', 'i915', 'snd_intel8x0']
 IRQ   17: PID:  None, count:           [608140], Sched None (priority None), drivers: ['uhci_hcd:usb2', 'b43']
 IRQ   18: PID:  None, count:                [0], Sched None (priority None), drivers: ['uhci_hcd:usb3']
 IRQ   19: PID:  None, count:            [47980], Sched None (priority None), drivers: ['uhci_hcd:usb4', 'yenta', 'firewire_ohci']

Software Interrupts:
--------------------


=== REPORT ===
FireWire kernel drivers:

The new FireWire kernel stack is loaded. 
If running a kernel earlier than 2.6.37 and problems are experienced, either 
try with the old Firewire kernel stack or upgrade to a newer kernel 
(preferrably 2.6.37 or later).

ffado output (on EchoFire 4)

05803339228: Warning (StreamProcessor.cpp)[1708] updateState: ignoring identity state update from/to ePS_Created
05803339616: Warning (StreamProcessor.cpp)[1708] updateState: ignoring identity state update from/to ePS_Created
05804389908: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 425.80881) more that 10% off nominal (rate= 512.00000, diff=      3406.470, update_period=8)
05804390013: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 422.66907) more that 10% off nominal (rate= 512.00000, diff=      3381.352, update_period=8)
05804397825: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 426.40921) more that 10% off nominal (rate= 512.00000, diff=      3411.274, update_period=8)
05804397982: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 422.66876) more that 10% off nominal (rate= 512.00000, diff=      3381.350, update_period=8)
05804405797: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 422.66907) more that 10% off nominal (rate= 512.00000, diff=      3381.352, update_period=8)
05804405903: Warning (TimestampedBuffer.cpp)[ 251] calculateRate: (0x952cf08) rate ( 424.58093) more that 10% off nominal (rate= 512.00000, diff=      3396.648, update_period=8)

(...)

05805685889: Warning (IsoHandlerManager.cpp)[ 292] Execute: Timeout while waiting for activity

05808703126: Fatal (IsoHandlerManager.cpp)[ 348] Execute: (0x95005f0, Transmit) Handler died: now: 1750DB1D, last: 134FD732, diff: 49202155 (max: 49152000)

05808703167: Warning (StreamProcessor.cpp)[ 173] handlerDied: Handler died for 0x952d360

jackd watchdog: timeout - killing jackd

no message buffer overruns

Notes: More Toradex-T20 Stuff...

So, I've wasted (again) too much time on the Toradex T20 I've written about earlier. It was collecting dust all of the time, but it's actually quite a nice toy, albeit not receiving nearly as much attention from developers, here are some random notes for myself, blogged so that I don't loose them.

USB

Switch the micro USB-on-the-go-connector (usable as a “normal” port, e.g. for connecting a Wireless LAN card or a USB thumbdrive) to host-mode:

# echo 1 >/sys/bus/platform/drivers/tegra-otg/tegra-otg/enable_host

Devices connected to the micro-usb with a OTG cable will now appear as usual, on the new “usb3” port.

Flash/Boot

Linux-Images to be run by the stock u-boot should look like this:

# mkimage -l /mnt/linux.img 
Image Name:   Linux_3_1_10+
Created:      Sun Oct 20 03:14:16 2013
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    6198328 Bytes = 6053.05 kB = 5.91 MB
Load Address: 00008000  ← !
Entry Point:  00008000  ← !

These are “legacy” images. The newer .its-based images work, too, but only with newer kernels (I tried 3.10 and 3.11) and those are broken in different ways, see below.

Copy the linux-images to the “default location” in internal NAND flash where 0x00800000 is the mtd device size (must be a multiple of the “erase block size” and 6198392 is your image file size). “/dev/mtd6” is the “LNX” partition when using the stock mtdparts command line option.

# mtd_debug erase /dev/mtd6 0 0x00800000
Erased 8388608 bytes from address 0x00000000 in flash
# mtd_debug write /dev/mtd6 0 6198392 /mnt/linux.img
Copied 6198392 bytes from /mnt/linux.img to address 0x00000000 in flash

“mtd_debug” is part of the “mtd-utils” package.

To find the correct flash block, have a look at /proc/mtd:

# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 3de80000 00080000 "USR"
mtd1: 00300000 00080000 "BCT"
mtd2: 00080000 00080000 "PT"
mtd3: 00200000 00080000 "EBT"
mtd4: 00080000 00080000 "BMP"
mtd5: 00200000 00080000 "ENV"
mtd6: 00800000 00080000 "LNX" ← !
mtd7: 00080000 00080000 "ARG"

The partitions are shown in proper (NAND-flash) order in u-boot's mtdparts command (even though this also only parses the mtdparts variable):

Tegra2 # mtdparts  (note: u-boot prompt, not Linux!)
device nand0 , # parts = 8
 #: name size offset mask_flags
 0: BCT                 0x00300000 0x00000000 0
 1: PT                  0x00080000 0x00500000 0
 2: EBT                 0x00200000 0x00780000 0
 3: BMP                 0x00080000 0x00b80000 0
 4: ENV                 0x00200000 0x00e00000 0
 5: LNX                 0x00800000 0x01200000 0
 6: ARG                 0x00080000 0x01c80000 0
 7: USR                 0x3de80000 0x01f80000 0

ENV is the u-boot environment, LNX is the default location for the linux kernel, USR the root-filesystem if running from internal flash. For the other partitions, I'm not sure. There's a “lnx_nand.cfg” in Toradex' T20_LinuxImageV2.0 which might shed a light on the exact purpose of all the unexplained partitions, unfortunately this seems to be handled by NVidias binary-only nvflash utility.

Booting with your root-fs on a sd-card (use no cards slower than class 10):

(u-boot environment variables)
myargs=root=/dev/mmcblk0p1 rootfstype=ext4 rootflags=data=writeback,commit=15 rootdelay=5,noatime,nodiratime
myboot=run setup; setenv bootargs ${defargs} ${myargs} ${mtdparts} ${setupargs} ; run myload ; bootm
myload=nboot ${loadaddr} 0 ${lnxoffset}

In principle, the kernel could also be started of a mmc drive:

Tegra2 # fatload mmc 0:1 $loadaddr linux.img

reading linux.img

mmc_send_cmd: MMC Timeout

    Interrupt status        0x00000001

    Interrupt status enable 0xfbff003b

    Interrupt signal enable 0xfbff0002

    Present status          0x01e70206

6198392 bytes read

But I always get this MMC Timeout error, and the loaded data is corrupt.

If you want to test a new kernel, booting over TFTP/Network (wired ethernet) or from a USB-disk works as expected (example below uses the same sd-card not working above, in a cheap and crappy usb card-reader):.

Tegra2 # fatload usb 0:1 $loadaddr linux.img
reading linux.img

6198392 bytes read

Tegra2 # bootm

## Booting kernel from Legacy Image at 00408000 ...

   Image Name:   Linux_3_1_10+

   Created:      2013-10-20   9:14:16 UTC

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    6198328 Bytes = 5.9 MiB

   Load Address: 00008000

   Entry Point:  00008000

   Verifying Checksum ... OK

   Loading Kernel Image ... OK

OK

Starting kernel ...

Kernel and Distribution

I didn't have much luck with a more-recent stock-kernel, the most serious problem in those kernel being a misconfiguration of the voltage regulators. My board became very hot and was pretty unstable. So I'm sticking with the antiquated vendor supplied kernel (3.1.10) right now with a config based on the Toradex shipped one.

I'm running ArchLinux based on the root-filesystem for the compact TrimSlice computer which also runs on a NVidia Tegra.

DCF77 via GPIO on the Raspberry Pi (patched radioclkd2)

Update 2015-02-15, see below.
Update 2016-02-14, see even farther below.

After replacing my old linux-PC based router with a Telco-supplied plastic-box, I no longer have a usable NTP server at home. As a first measure, I’ve put a small DCF77 module on a raspberry-pi. It seems that most people add a serial to usb converter for that, but the raspberry has perfectly fine GPIOs that are capable of generating an interrupt for low CPU load -- and that’s all one needs. You can find my very lightly patched radioclkd2 for parsing the pulses on github.
I’ve added an additional filtering capacitor to the back of the module (be careful, inrush current will crash your Pi when connecting the leads!) a long time ago when it was still connected to the old PC, and there’s a pullup from the pulse output (which typically is open-drain/open-collector) to Vcc (3.3V). In my case, on a Rev. A Raspberry, I use GPIO0 (probably a bad choice, because it’s also one of the two accessible i2c pins, but easily changed).
Unfortunately it turned out that at its current location, reception is pretty bad, but easily solved by repositioning the Pi.


Update:I got a few emails regarding this project (which I hadn't had running for quite some time) recently, so I'll try to add this information on the old blog-post.

First, if you get a lot of pulses with bad, and very short, lengths (<10ms)

• Reposition the DCF77 receiver with a long cable, away from all your computer stuff and switch-mode power supplies.
• Wrap a huge ferrite core around this cable, to attenuate wire-conducted noise to the DCF77 receiver.
• Add additional filtering caps at both sides of the cable (near the Rpi and DCF77 receiver module).

That way, I could get reliable reception again.

Second, if your ntpd doesn't seem to register any time from radioclkd2, even if it seems to receive properly: If you enable debug mode in radioclkd2, it will *not* update the shared memory. So after you've verified proper operation, put radioclkd2 in the background without -d.

Update 2016-02-14: Here are two pictures showing radioclkd2 acquiring time from a DCF77 module.

From Chris’ Miscellanea

From Chris’ Miscellanea

Webmail Notifer, Linux Kernel Module

This is an update on the Webmail Notifier, a cheap chinese gadget that's nothing more than a RGB LED connected via USB. In this case, it's an especially cheap version that can only display 7 distinct colours, plus black (off).

Finally I was sufficiently annoyed to put the code into a “proper” kernel module (original module on kernel.org). Here's my patch that adds this particular LED gadget.

Here's the thing cycling through random colours:

Repairing an Alesis IO26

There's a really common way to kill your firewire-devices, which is to forcefully plug in the 6-pin connector, carrying both supply power and data signals, rotated by 180 degrees (which normally should be prevented by the asymmetrical shape of the connector). That way you'll send +12V, the most common supply voltage, into the chip that connects to the cable. This kills the chip pretty reliably.

This audio-interface (Alesis IO26) was damaged using this method:

From Chris’ Miscellanea

Thankfully the internal layout of the device is pretty clean. There's a stack of two PCBs (only the lower one shown) on the left side inside. The lower one has the DSP, Firewire controller and a ARM based controller. It connects with flat cables to the "analog" boards. On top, it carries a switching power supply generating the internal voltages (+3.3V, +5V, +/-15V and +48V from a single, galvanically isolated 9..30V input) which is missing in the photo.

From Chris’ Miscellanea

A good way to diagnose these kind of errors (according to some forums and FAQs) is to look at the idle-voltage on the firewire-bus lines (TPA0+...TPA0-...). They are supposed to be biased to a internally generated 1/2 Vcc (~1.8V) via 56 Ohm resistors from the twisted-pair lines to a bias pin (TBIAS0/1). It's described in the data sheet of the chip, here it's a TSB41AB2 from TexasInstruments In my case one bias-voltage-regulator spat out 3.3V, the other 0V (there's one for each of the two firewire ports). One of the ports had one receiver line stuck at 0V (chip-internal short to GND).

The only way to repair it is to desolder the chip, and replace it with a new one. Then the interface should be functioning again (I did not populate the mechanically damaged connector and associated terminating resistors, one port is enough for me).

From Chris’ Miscellanea

From Chris’ Miscellanea

The two shorted pins #1 and #2 are both GND, so I did not bother to clean up the blob.

Audix APS 910 - Inline Phantom Adapter

This adapter allows you to connect "normal" electret-type microphones to differential, phantom-powered inputs, like the ones to be found on sound mixing desks. I got one of those, but as the pinout was not mentioned anywhere, I made these photographs.

http://www.audixusa.com/docs_12/units/APS910.shtml

Mini-XLR pinout is supposed to be: 1: GND, 2: Signal, 3: Vbias. Even though the supply pin (3) is quite susceptible to noise coupling into the adapter output, Firther more, the signal pin (2) itself has a 1k or so pullup to Vbias. So to connect to a 2-pin electret microphone, just connect only pin 2. If you need more bias current, also connect pin 3, but then your signal will be slightly attenuated.

Phantom supply current is preetty high, at around 5mA each on "Hot" and "Cold" pins. (P48 on my mixing desk goes down to 13V when the adapter is connected)

From Chris’ Miscellanea

From Chris’ Miscellanea

From Chris’ Miscellanea

From Chris’ Miscellanea

Reboot your Arch-linux running computer early, in case some vital component failed to initialize (a.k.a. e1000e_fsckup_initcpio)

Ok, so this is embarrassingly primitive, but so that I don't loose it (again), I put this small script on github. Maybe someone else having a problem with things not initializing properly on every boot can find the concept useful: I have a computer based on a “DFI LanParty Mini-ITX P55-T36” motherboard with an integrated Intel Gigabit interface. Which works fine so far, but always fails to initialize networking on the first bootup after power-on. This is obviously inconvenient for unattended operation.

To fix this once and for all and reboot the computer early, feel free to use the code at https://github.com/vogelchr/e1000e_fsckup_initcpio.

From Chris’ Miscellanea

Antlers (May 2013 edition)

I was on vacation again, so here's the obligatory antlers picture. I already posted another one elsewhere, but that was taken with the (a little bit) crappy phone camera and doesn't do the wallpaper and the antlers justice.

From Chris’ Miscellanea

Wireless on Raspberry π, Power Issues

I'm playing with a Accellerometer/Gyroscope/Magnetometer board (ebay, link probably stale soon), and to have it somewhat mobile, I've connected it to the ole' trusty Raspberry π.

Unfortunately I have problems with a lot of WiFi adapters because of the many fuses inside of the π dropping voltages (starting with 4,5V from my Notebook/USB hub, it goes down to 3,8V on the USB connector). But adding a short wire bridging all those fuses helps ;-).

The dongle used is really old, it's a 

Bus 001 Device 005: ID 07b8:b21d AboCom Systems Inc RT2573

and gets quite warm (correlates well with the high power consumption and hence voltage drop on the fuses), also looses contact with my (just nearby) access point frequently.

[ 2140.585617] ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:5e:42:ff after 500ms, disconnecting.

[ 2140.607093] cfg80211: All devices are disconnected, going to restore regulatory settings

[ 2140.607132] cfg80211: Restoring regulatory settings

[ 2140.607420] cfg80211: Calling CRDA to update world regulatory domain

[ 2141.948125] wlan0: authenticate with 68:7f:74:5e:42:ff

[ 2141.996396] wlan0: send auth to 68:7f:74:5e:42:ff (try 1/3)

[ 2141.998072] wlan0: authenticated

[ 2141.998877] rt73usb 1-1.2:1.0: wlan0: disabling HT due to WEP/TKIP use

[ 2141.998912] rt73usb 1-1.2:1.0: wlan0: disabling HT as WMM/QoS is not supported

[ 2142.035630] wlan0: associate with 68:7f:74:5e:42:ff (try 1/3)

[ 2142.037914] wlan0: RX AssocResp from 68:7f:74:5e:42:ff (capab=0x431 status=0 aid=20)

[ 2142.037943] wlan0: invalid AID value 0x14; bits 15:14 not set

[ 2142.057687] wlan0: associated

Happy Easter

And remember: As long as the eggs aren't completely covered in snow, it's spring enough.

From 2013-03-31

Webmail Notifier - Linux Hidraw

I got myself a plastic toy: A small box with a controlable LED that can be turned on- or off, with the intention of notifying the user of unread emails.

https://www.google.de/search?q=webmail+notifier&tbm=isch

My incarnation of this relatively simple concept identifies itself with a USB VID/PID of 0x1294:0x1320:


# lsusb -s 1:14
Bus 001 Device 014: ID 1294:1320 RISO KAGAKU CORP.


And it shows itself in the kernel log as follows:


[10772.855386] usb 1-1.6: new low-speed USB device number 15 using ehci-pci
[10772.949641] hid-generic 0003:1294:1320.000D: hiddev0,hidraw2: USB HID v1.10 Device [MAIL MAIL ] on usb-0000:00:1a.0-1.6/input0


As it registers itself with the HID subsystem, we can use the resulting hidraw device to talk to it without using any script or tool, just make a convenience symlink with useable permissions using a small udev rule:


$ cat /etc/udev/rules.d/99_webmail_notifier.rules
# USB Webmail Notifier (RGB LED)
SUBSYSTEM=="hidraw" SUBSYSTEMS=="usb", ATTRS{idVendor}=="1294", ATTRS{idProduct}=="1320", GROUP="users", MODE="0660", SYMLINK="webmailnotify"


Then you can make it change its colour with a simple echo-command in any script:


$ echo -en '\001\0\0\0\0' >/dev/webmailnotify


The only ugly thing about it: It seems to send back some HID report which confuses and angers the kernel routines, but this shall be dealt with at some later point.


[11170.163495] hid-generic 0003:1294:1320.000D: extract() called with n (56) > 32! (swapper/0)


AES/EBU to ‘SPDIF’ - ghetto style

For interfacing AES/EBU to S/PDIF, I've built a simple transformer out of a small ferrite core, I was planning to convert the 110Ω symmetric AES/EBU signal coming out of a surplus ADC/DAC (I love you, eBay ;-) ...) to the S/PDIF of my computer interfaces (and vice-versa).

There's a nice text about all this over at RANE, but normal people just shell out the 100€ for two of Neutrik's transformers in a box.

The screenshots below show the output of the transformer, terminated by 75 Ohm (or by the audio-interface S/PDIF input, looks identical) when driven by the AES output. I wanted to hide everything in the XLR connector shell, and hence the ferrite beads are pretty small. Therefore they saturate visibly at 32kHz f_s, but it works fine for this signal direction. At 96kHz everything looks perfect.

From Chris’ Miscellanea

From Chris’ Miscellanea

From Chris’ Miscellanea

The other direction works not as nicely: All of my audio-gear has a pretty high output impedance on the S/PDIF outputs! With a open output, I get something like 3-5V_PP of signal swing, but terminated it goes down to 500mV (just as the spec says). With the saturating ferrite beads, the high-impedance outputs cannot provide the additional current, and the ideally square-shaped output degenerates to tiny spikes of both polarities and is completely unusable. The not-very-pretty-but-working-solution: Just connect the SPDIF to AES 1:1, but keep cable lengths short. (no scope, screenshots, sorry).

M-Audio Fast-Track Pro PCB Pictures

I'm a little annoyed by the limitations of the M-Audio Fast-Track Pro, so I'm thinking about how to mod it. My main grief is the abysmally bad windows drivers that bluescreen constantly under Win7. Then there is the limitation of USB1.1, which does not have enough bandwidth for anything more than 2x24/96 streams. My plan is to make a normal standalone S/PDIF ADC/DAC (2in, 2out, 24/96) out of it.

First, I took a few pictures of the two PCBs inside the unit, and traced a few signals. You can see immediately that the electronic layout of the unit is very tidy!

Main integrated components:

• Texas Instruments TUSB 3200 USB Streaming Controller
• Asahi Kasei AK4114 S/PDIF Transceiver
• Asahi Kasei AK5381 24bit 96kHz ADC
• Asahi Kasei AK4381 24bit 192kHz DAC (compatible successor AK4385)

Misc. Digital

• 74LVC157A, Quad 2-Input Multiplexer
• AT24C64 Atmel 64kBit I2C EEPROM

The phantom voltage generator has a venerable NE555!

OP-Amps

• NJM2115 NRC Dual Operational Amplifier
• NJM3414 NRC Single Supply Dual High Current Operational Amplifier (Headphone Out)

From M-Audio Fast Track Pro

From M-Audio Fast Track Pro

From M-Audio Fast Track Pro

From M-Audio Fast Track Pro

From M-Audio Fast Track Pro

Note: Archlinux and Xorg Keyboard Layout

Archlinux for me seems to miss any magic that takes care of automatically providing the correct keymap to xorg's input driver. To make udev provide the correct settings to xorg, this small udev-rule works.

[root@fbsd ~]# cat /etc/udev/rules.d/99_keyboard_keymap.rules
SUBSYSTEM=="input", ENV{ID_INPUT_KEYBOARD}=="1", ENV{XKBMODEL}="pc105", ENV{XKBLAYOUT}="de", ENV{XKBVARIANT}="nodeadkeys"

So far it's understood by xorg just fine.

[  2888.705] (II) XINPUT: Adding extended input device "Das Keyboard" (type: KEYBOARD, id 8)
[  2888.705] (**) Option "xkb_rules" "evdev"
[  2888.705] (**) Option "xkb_model" "pc105"
[  2888.705] (**) Option "xkb_layout" "de"
[  2888.705] (**) Option "xkb_variant" "nodeadkeys"