The board provides the required interface but leaves off just short of a "full" product. The component designations of the resistors are covered by the parts. Seeing how there is plenty of room on the board, the designators (R1, R2, D1, ...) should be put somewhere you can see them when the parts are installed. Sometimes you're working in a 3.3V system and the resistor values for that environment (47 ohm) for the series resistors on the MIDI output would be a nice-to-have. I don't know that this could hurt performance, but there is a pull down resistor sometimes used in circuits for the provided opt-isolator pulling down that unused pin; I added a 10K pull down to pin that for good measure. Some of the resistors, with a fairly sharp bend in the leads, don't fit easily into the PCB. Again, with room on the board, the spacing should be ample for the insertion of the parts and not cramped for no reason.

I've been able to get the TrueRNG installed and working with rng-tools on Debian 8.2.

user@host:~$ uname -a
Linux host 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) i686 GNU/Linux

user@host:~$ cat /etc/debian_version
8.2

user@host:~$ sudo /usr/sbin/rngd -V
rngd 2-unofficial-mt.14

Now I'm not having the entropy pool exhaustion that was causing my SFTP jobs to fail on my headless system with SSD (therefore low entropy from traditional interactive sources). Hooray!

user@host:~$ echo $(cat /proc/sys/kernel/random/entropy_avail)/$(cat /proc/sys/kernel/random/poolsize)
996/4096

I am currently trying to determine why the udev rule that I downloaded isn't working. It is not creating the symlink, which doesn't bother me too much (just set HRNGDEVICE=/dev/ttyACM0 in /etc/default/rng-tools). But because the rule does not appear to be firing, it isn't running the stty command, so the speed is very low.

user@host:~$ sudo dd iflag=fullblock if=/dev/ttyACM0 of=/dev/zero bs=64 count=4096
2340+46 records in
2340+46 records out
151223 bytes (151 kB) copied, 11.4995 s, 13.2 kB/s

user@host:~$ sudo stty -F /dev/ttyACM0
speed 9600 baud; line = 0;
-brkint -imaxbel

To fix this, I've just been running this after reboot:

user@host:~$ sudo /bin/stty raw -echo -ixoff -F /dev/ttyACM0 speed 3000000
9600

user@host:~$ sudo stty -F /dev/ttyACM0
speed 3000000 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost
-isig -icanon -echo

user@host:~$ sudo dd iflag=fullblock if=/dev/ttyACM0 of=/dev/zero bs=64 count=4096
4096+0 records in
4096+0 records out
262144 bytes (262 kB) copied, 5.74209 s, 45.7 kB/s

I used udevadm test to discover that one source of the problem was ^M at the end of lines in the rule file. I fixed that.

Here's my current rule file:

SUBSYSTEM=="tty", ATTRS{product}=="TrueRNG", RUN+="/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000"
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="f5fe", ENV{ID_MM_DEVICE_IGNORE}="1", MODE="0444"

You can see I took out the SYMLINK and I added MODE because of a suggestion by atoponce in the ubld.it forum. I thought it might help to remove this "Couldn't open device" in my lsusb output, as well as for some future work, but it didn't help with lsusb.

user@host:~$ ls -lsa /dev/ttyACM0
0 cr--r--r-- 1 root dialout 166, 0 Jan 20 10:07 /dev/ttyACM0

Here's the relevant part of my LSUSB -v output.

Bus 002 Device 002: ID 04d8:f5fe Microchip Technology, Inc.
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x04d8 Microchip Technology, Inc.
idProduct 0xf5fe
bcdDevice 3.02
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 67
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0

It works ok... I've tried it on Ubuntu, Centos and Windows 7 and it's fine... I didn't try it on my mac yet.
People from the support are nice.

This device works perfectly once you make your computer see it. That's the problem. One requires a .inf file for Windows to know what to do with it, but although you can find a reference to such a file hidden in the depths of the "manual," the file itself is not included. I obtained one from from the company that makes the device when I complained about it. They were very quick to respond, and most of my troubles were, in fact, "pilot error," but they were kind about it.

I recommend this product without reservation. You do to need to know what you are doing, though, or be willing to find out.

Kenneth Turner