I just put up a new page for a small side project: a Universal USB to I2S Interface Indicator.
Have a look here: https://www.dimdim.gr/arduino/universal-usb-to-i2s-interface-indicator/
I just put up a new page for a small side project: a Universal USB to I2S Interface Indicator.
Have a look here: https://www.dimdim.gr/arduino/universal-usb-to-i2s-interface-indicator/
I had been looking for a good ADC board for lab use as a measurement device.
At first I considered making my own, using something like the TI PCM4222 ADC chip, due to its excellent performance, good availability and relative ease of build.
But then I got lazy and purchased the PCM4222 EVM instead:
It is a 4-layer, well designed and implemented board.
Besides the necessary 2 clocks, it has a full set of digital outputs:
– Dual AES3 compatible outputs (both coaxial at 75Ω and XLR at 110Ω)
– I2S
– DSD
– Raw, directly from the modulators
Its analog inputs are balanced and very low noise.
Make no mistake, this is an evaluation module. As such, there are no mounting holes. Just four rubber “feet”:
Since I was in a hurry to get it to work, I set it up for operation with the least amount of power supplies (+/-15VDC and +5VDC) and set the DIP switches for I2S operation at 24bit and 96KHz.
I wanted to use one of its built-in AES3 outputs, but my sound card only had consumer level s/pdif inputs. After a short Google search, this came up: http://www.rane.com/note149.html
In other words, I had to make a 75Ω cable, with an XLR at one end, an RCA plug at the other and this circuit embedded in the XLR plug:
Surprisingly enough, it fit.
I hooked it up to the ‘scope to see if everything looked OK, and after being satisfied with what I saw I hooked it up to my X-Meridian’s coax s/pdif input. The sound mixer in Windows showed a full level signal coming out of it but it was heavily distorted. What was going on?
While troubleshooting, I tried the serial output port by connecting it to a WM8804 board that I had lying around. Sure enough, I got proper undistorted s/pdif output, so the PCM4222 was working as it should. So the problem had to be in the AES3 drivers.
After some more Googling I came across a post in some forum by someone who had a similar problem with me. He said that for some reason he had to set the ADC’s output to Left Justified (instead of I2S) in order to get the AES3 transmitters to output a proper signal. I made the necessary changes to the microswitches and lo and behold, it worked!
This is the configuration that I ended up with:
Next up is a proper input stage, since the ADC has balanced inputs but most of my equipment-under-test is single ended.
I bought this inexpensive (something like $3 delivered) Ethernet module a few years ago, only to discover that there really wasn’t a decent library to support it. So it got tossed into a drawer..A few days ago I realized that I needed a low cost Ethernet interface for one of my projects. It wouldn’t really need to do much, so I thought the ENC28J60 would probably be able to handle the task.
Doing the customary Google search for Arduino support turned out a full Ethernet library for it! 🙂
It’s called UIPEthernet and it is fully compatible with the original Ethernet library for the Arduino. What this means is that every piece of code written for the Ethernet library (in other words for the “classic” Arduino Ethernet Shield) can be made to work with a dirt-cheap ENC28J60 just by changing
#include <Ethernet.h>
to
#include <UIPEthernet.h>
This I had to see for myself, so I hooked it up.
The module that I have needs 3.3V power (not 5V!!) but its SPI pins are 5V tolerant so it will pair nicely with any Arduino.
The necessary hookup for the UNO, MEGA or DUE can be found in the library’s page: https://github.com/jcw/ethercard
I decided to try a classic Ethernet example sketch: The WebServer sketch. This one reads a few analog inputs on the Arduino and then serves them on a web page.
Sure enough, all I had to do to get it to work was just change the #include statement. It worked like a charm!
So, there you have it. You can add full wired Ethernet connectivity to your Arduino for less than $3.
A couple of days ago I took my DAM and headed out to a good friend of mine to do some listening tests.
My DAM at the moment is powered by a Salas BiB at 12VDC. It has a DIYINHK XMOS based USB to I2S interface powered by a Salas Reflektor-D at 3.3VDC. The same power supply powers the isolated side of the DAM.
(note that this picture is a bit old. I have since swapped the transformer for the one shown in the next picture plus I have used an IEC with a built-in filter)
The first objective was to assess the importance of a good DC power supply instead of a plain transformer. In order to do that I took with me an extra 50VA toroidal with 2 x 7V windings.
My friend’s system consists of Magnepan speakers, a DIY fet-based preamp and DIY power amp (solid state, 60KG monster). It is widely regarded as a very revealing and non-forgiving system. Any change in any of its components (or a component withing the components) is clearly heard.
The DAM was connected to the preamp through its unbuffered outputs.
We gave the system some time to warm up (it was probably a couple of hours) and then sat down to listen. We started with the DAM as it was, with the Salas BiB. We then unplugged the Salas and hooked up the plain transformer.
The change was immediately obvious. The sound thinned, it became more harsh in the high end. It also lost resolution and detail. Going back to the BiB made all the good qualities come back.
Thus, I can definitely recommend a proper DC power supply for the DAM. I cannot say whether it was the Salas that did the work or that any DC power supply would do the same, but the improvement was definitely there. Note that I have the BoM for the Salas BiB I built in the Soekris’ page.
The second objective was to assess the difference that could be made by using a “proper” output stage after the unbuffered outputs.
So I built a pair of AMB alpha20 line amplifiers. I set their gain to 2 and powered them temporarily by the same Salas BiB that powers the Soekris.
Note that my DAM outputs roughly 1V RMS at its output @ 0db since I’m using a filter that includes attenuation at FIR2 (I can’t really remember which one it is though..). This meant that the alpha20 brought its output to a nice 2V RMS.
Going back and forth between using the alpha20 and just the unbuffered outputs, the conclusion was that the alpha20 removed a small amount of the “magic” of the DAM while not really helping in anything besides output volume. I was hoping that it would help improve the dynamics of the DAM – its Achilles’ heel IMHO. In my friend’s system the DAM sounds “flat” compared to his other sources (a heavily modified Sony 50ES cdp, a Buffalo 3 DAC, and an Aune S16). However, this “flatness” is not particularly obvious in other more forgiving systems.
So, my assessment of the DAM so far is as such: It has great detail, exceptional mid-range, proper bass, it is a little soft on the highs, but its main problem is the dynamics. It can sound a bit “flat”, with this “quality” either accentuated or minimized, depending on the rest on the system.
If there was a way to improve its dynamics, to make it more “aggressive”, it would be a stellar performer (with a proper DC power supply of course). As is, it is just great VFM.
A few days ago I received the Pipo X7 that I had pre-ordered back in January.
It took so long to source & ship because it is immensely popular – after all, for less than 100€ I got:
– An Intel Baytrail Quad Core CPU @ 2.16GHz
– 2GB of low power DDR3 RAM
– A 32GB SSD drive (Samsung MBG4GC)
– An HDMI out
– WiFi b/g/n, 10/100Mbps Ethernet & Bluetooth connectivity
– 4 x USB 2.0 ports
All of that inside a slick aluminum box, not much larger than a CD, powered by a silent 12V/2.4A power supply.
But the best part is that it runs a fully activated copy of Windows 8.1 (32bit)!
Yes, Microsoft is essentially giving away Windows 8.1 for use in small devices (like set-top boxes, such as this one) with only one catch for the OEM: He is not allowed to set Google Search as the default search engine. However, this does not mean that you can not set Google as your preferred search engine if you wish (instead of the dreadful Bing).
Now, I must admit that this was largely an impulse buy for me, since I already have a full size HTPC and a Squeezebox Touch as an audio transport, but I just couldn’t resist the temptation. So, since I had it, I decided to run a series of audio-oriented tests on it.
My player of choice is Foobar, feeding a Buffalo III DAC through an Amanero Combo384. The files were stored on a file server on my LAN and the Pipo was connected to the LAN via 100Mbps Ethernet.
The first test included outputting DSD to the Amanero. All the necessary Foobar components were loaded, including of course the Super Audio CD Decoder and the necessary configuration was performed:
Note: There are several steps involved in getting Foobar to output DSD. It is not the purpose of this post to fully outline them. A Google search would turn up a number of guides / how-tos.
First up was a “plain” DSD64 file. The Pipo had no problem playing it back, with less than 1GB of RAM use and about ~13% CPU utilization:
Let’s make it more interesting. DSD128:
Still no problem. As a matter of fact, CPU load has actually decreased! That is probably because the DSD64 file was from a SACD ISO, so some CPU time was used in handling the big file.
Moving on to a worst case scenario: A DXD file:
Still, no sweat, with the CPU barely sweating at 16% load. RAM has not climbed above 800MBs.
Since the machine appeared to have some decent horsepower, I thought I would try the well-known SoX Resampler DSP for Foobar. I set it up as best I could, since I don’t really have much experience with the actual DSP:
I chose to go the “x4” upsampling way, with the “Best” quality setting. This meant that a 44.1KHz file would be upsampled to 176.4KHz and a 96KHz file would be upsampled to 384KHz, hitting the limits of the Amanero interface. A 192KHz file would not be supported, since that would mean that it would have to be upsampled to 768KHz. The idea was to do a benchmark, so I just played two versions of the same files, one at 44.1K and one at 96K. This was the result:
So, still no serious sweat, with the CPU averaging 29% load, with one of its cores (presumably the one doing the actual upsampling) getting about 50% usage.
At that point, I called it a day.
In conclusion, it seems that the Pipo X7 is perfectly capable of supporting audio playback, even with upsampling enabled. As a matter of fact, I might keep it as a music transport.
The Soekris dam1021 has a serial port (J10).
This serial port serves a number of purposes:
1) It is used for uploading firmware updates via the uManager prompt.
2) It is used for uploading filter values via a software utility (not yet released).
3) Outputting info on currently selected Input, Sampling Rate and Volume level.
4) Controlling things by receiving commands. Up to now, we can select Input and change the Volume. More commands might be added in the future (or already exist, but are not yet documented by Soren).
In order to do all those things, one has to interface to this serial port. In this post I detailed how to interface a computer to this port (so as to perform a firmware upgrade). Now it is time to do the same for a microcontroller, say an Arduino.
The problem is, microcontrollers use different voltage levels compared to the “classic” RS-232 serial protocol. In order to make these different things talk to each other, we need to use what is called an “RS-232 Receiver / Transmitter” IC. Such ICs are pretty commonplace, since they are found inside of most devices that come with RS-232 interfaces. The “classic” IC that is used is the Maxim MAX232. It is very low-cost but it is also an old design, requiring 5V (instead of 3.3) and 5 x 1μF capacitors. There is a much newer version of the chip, the MAX3232, operating with a voltage between 3V and 5V and requiring much smaller caps (0.1μF), but it is not as widely available as the MAX232. Since I was in a hurry to get things up and running, I chose what I could find locally in stock: a MAX232.
This meant that I had to power it with 5V and use 1μF tantalum or ceramic capacitors, but what the heck. I was in a hurry.
After reading the MAX323’s data sheet I ended up with this:
(click on the picture for a higher resolution version)
You will notice that I am using Serial3 of the DUE to talk to the DAM DAC. Any serial port could be used, but I chose Serial3 because it was practical – it will be easy to route these specific pins on the shield that I am designing.
Once I verified that the above circuit worked, I built it on perfboard to keep handy:
The above circuit works in general but has some trouble with the DAM DAC. It works just fine upon power up but at some point loses communication with the DAC. The only way to restore communication is to power cycle the DAC. I am not sure what the problem is, but I suspect that it has to do with the power management features of the ICL3221 chip used on the DAM. I have ordered an ICL3221 to use in place of the MAX232, in hope that everything will work fine when I use this (at least in theory) fully compatible IC.
Stay tuned.
The DAM1021 originally came with FPGA firmware 0.8. Since then Soren has released a new version of the firmware, Rev 0.9.
In order to upload it to the DAC one must connect the DAC to a computer using either a “classic” serial port, like the one found at the back of older computers, or a USB to Serial adapter. Then a cable must be made connecting three pins of the DB9 connector to the connector J10 on the DAC board.
These pictures illustrate the connections that are needed:
You use your new cable to connect the DAM to your computer’s serial port (or USB-to-serial adapter). You do not power on the DAM DAC just yet.
Once you are done with making the physical connection, you need to get your hands on some software that supports the XModem 1K data transfer protocol. This is a pretty old protocol, so your choices in software are pretty limited. One such choice is the “classic” HyperTerminal, but since it is no longer available with Windows I chose the more modern ExtraPUTTY. It is a fork of the classic PuTTY telnet/ssl client software that also supports “vintage” transfer protocols such as XModem.
Once you have it installed it is pretty easy to establish a serial connection at 115200, 8, n, 1, as specified by Soekris. You click on the “serial” tickbox and enter your computer’s serial port (in my case it’s COM5) along with the specified speed (115200bps):
You click on “open” and you get a black terminal screen. You now need to power on the DAC. Once you do that, you should get something like this:
This means that everything is fine. You might see an “I0” instead of an “I3”. That is OK.
Now you need to get to the uManager prompt. You type “+++” and wait for a second. You will not see the “+” characters as you type them. That is OK. You will get this:
Now type “download”, followed by Enter. You will see something like this:
This means that you have 30 seconds to begin sending your file. To do that you click on File Transfer -> Xmodem 1K -> Send. Select your firmware file and off you go!
When the transfer completes you will see something like this:
One thing – do not forget to give the “update” command once you have uploaded the code followed by a “y” and return.
Next you type “exit” (and Enter) to exit the uManager prompt and you are ready to power cycle the DAC. Once you have done that, you repeat the above steps to get to the uManager prompt and you verify that you have successfully updated the firmware. You should now be at FPGA firmware 0.9!
If are having problems connecting, such as getting garbage like this in your serial console:
chances are that your USB to serial adapter is not a “true” RS-232 interface, but outputs TTL levels instead. You can confirm that by measuring the voltages between GND and the RX & TX pins. You should be getting zero volts in one case and about -9V in the other. If you are getting 3.3 or 5 volts, your interface will not work with the DAM. You should try to find a proper RS-232 interface.
The UPS guy just dropped off my brand new Soekris R-2R DAC:
Also known by the very bland designation “DAM1021”.
It is a sign-magnitude R-2R DAC (a.k.a. “ladder” DAC), meaning that it is quite different in operation than the regular run-of-the-mill DACs.
It is more like a PCM1704-based DAC but with 192KHz+ support plus a bunch of high tech goodies, such as a built-in FIFO buffer.
It is available in three versions, with resistors of different tolerances (0,01% (high grade), 0,02% (mid), 0,05% (basic)). I got my hands on the 0,02% version.
It has three inputs:
1) I2S (electrically isolated)
2) Coax s/pdif
3) TTL for a Toslink receiver
It is powered directly by a 2 x 7-8V transformer, but may be powered by a bipolar DC power supply.
It outputs a single ended signal at 1.4V RMS and also has a buffer for balanced output at 4V RMS.
It has a serial port for firmware upgrades as well as control.
I have already began work on a Soekris R-2R version of my TFT HiFiDuino Arduino code, tailored to controlling this particular DAC via its serial port.
The board will of course get its own page pretty soon.. Edit: the board now has a page.
To do: hook the board up and actually listen to it play. Stay tuned.
I love TFTs because one can make with them professional looking project displays without necessarily breaking the bank.
I am particularly fond of the SPI interface because it uses a minimum number of I/O pins. This means that since even a minimal Arduino (one based on an ATmega328) can drive a low-cost TFT with I/O left for other tasks, the cost may be kept down. Nowadays, it is realistic to implement a basic Arduino with a 2.2″ TFT for less than 10€. An ATmega328 with an Arduino bootloader goes for 1,50€ on Ebay, a 2.2″ SPI TFT goes for about 3,50€, so “vintage” character LCDs are definitely on their way out.
So, let’s get down to business. What does one need in order to get one of these displays to work?
Obviously, you need the TFT display itself. I don’t care where you buy it from – you may get it from Adafruit or SparkFun or iTead or any one of the “big name” shops or you may get it from Ebay (a.k.a. “China”). In my experience, it doesn’t really matter as long as you know what you are purchasing. For example, on Ebay when you search for 2.4″ SPI TFT LCD you will come across this:
and this:
They are essentially the same TFTs, but the first one is ~1€ cheaper than the second one. The difference is the PCB that is included. Do not underestimate this PCB. If you go for the plain TFT you will have to solder it to a suitable PCB like this one:
Sure, it is no herculean task, but the TFT + adapter will most likely cost more than a TFT pre-mounted on a PCB.
Rolling your own PCB is indeed an option, but IMHO it is not worth it, not unless you are planning to go into mass production. For 1 or 2 pieces just do yourself a favor and shell out the extra €. You won’t regret it.
But let’s backtrack just a bit. How does one select a TFT? Surely, one would think that size and resolution are the most important factors. I say sure, as long as you have the software part covered. In order to actually show stuff on a TFT you need an appropriate library. You should not take for granted that such a library indeed exists for that gorgeous hi-res IPS TFT that you found for 10€ on Ebay. Many sellers on Ebay just write the word “arduino” on the TFT’s description without giving it much serious thought. Plus you should expect zero (0) support from most Ebay sellers. Most of them can’t and won’t help you if you run into trouble with your code.
So, you should always do a little research. Google is your friend. A good start is Karlsen Henning’s UTFT library. Being billed as a Universal TFT Library it does indeed support a large number of TFT controllers. If your display’s controller is included in UTFT’s compatibility list, you are somewhat covered. I say somewhat because UTFT is not always the best choice since it has a pretty heavy footprint. It will consume the better part of an ATmega328’s flash memory capacity. Fortunately, there are other libraries out there. I will go into more detail later on.
So, you got a TFT and are faced with the task of hooking it up to the Arduino. Relax, it’s simple. You only need to connect 4 or 5 wires, plus power and GND. Let’s start with the basics.
1) Power (Vcc). Most displays need 3.3V to function. This is a requirement of the TFT panel itself as well as of the driver IC that is always part of the assembly (it is an embedded part – you can not really see it). But as you probably know, most Arduinos run on 5V. Display manufacturers that make products for Arduino of course know that and usually include an on-board regulator that takes 5V as input and gives the necessary 3.3V. In most cases there is a selector on the PCB (jumper, solder bridge, or something) that lets you configure the board for 5 or 3.3 volt operation. Look out for that.
2) LED power. This pin controls the backlight of the TFT panel. It consists of a number of LEDs, depending on the size of the LCD panel. Bigger panel means more LEDs and thus more power consumption. It is usually connected to GND or to 5V/3.3V. Some times a current limiting resistor is also necessary. Other times the resistor is built-in and so is a mosfet that allows you to adjust the LED backlight’s brightness by connecting it to a pin that supports PWM (some of the more expensive TFTs support this). In any case, read the manual. You may come across a Chinese TFT that you had to have but then noticed that it has sparse if any documentation. If this happens, play it safe by connecting the LED pin to GND through a resistor (a few hundred ohms is usually a good starting point). If it lights, it means that the polarity is OK. If it does not, try applying 5 or 3.3V to it (through the resistor). If it lights but is too dim, use a smaller resistor. Usually each LED draws about 10-15mA, so if you know how many LEDs your TFT uses you can estimate its power draw and thus select a proper resistor.
3) Signalling. This is the nice part about using SPI: you only need 4 or 5 wires.
CLK (or SCLK / SCK): This is the clock input pin.
MOSI (or SDI / SDA): This is the Master Out Slave In pin. The actual raw data that is sent to the TFT passes through this wire.
CS (or TFT_CS or LCD-CS): This is the chip select pin.
D/C (or A0 or RS): This is the Data or Command selector pin.
We also have the Reset pin. Some times you can get away with connecting it to the Arduino’s reset pin, but it is better to connect it to a normal pin in order to have better control over it.
A special note here: Signalling is usually done at 3.3V unless the TFT’s manufacturer has implemented some kind of level shifting on board the PCB. This level shifting may be done by an IC (best case), or a bunch of transistors and resistors (fair enough..) or just 1.2K resistors (a bit of a kludge, but it usually works). It is important to be careful not to send 5V into a TFT that only supports 3.3V logic because in that case you will most likely damage the TFT.
At this point you need to take a break from the hardware and consider the software, since your choice of library will dictate the particulars of the next step, which is the connection of the signal wires to the Arduino.
Your main choices are two: the UTFT library and the Adafruit GFX library.
Each library has its strengths and weaknesses.
UTFT
Pros:
Cons:
Adafruit GFX
Pros:
Cons:
You really should become familiar with both of them since different projects will steer you towards one or the other.
Depending on your choice of library, you may need to use the hardware SPI pins for CLK and MOSI or you may be free to use any pins you like. It really just depends on the library.
Each of the libraries uses a slightly different notation for the signal pins. I will try to sum things up in this table:
[table “” not found /]You may notice that most libraries say that you can just connect the TFT Reset pin to the Arduino Reset Pin. If you do that, you should put 0 as the reset pin.
Good luck!
As is usually the case, a few bugs crept into the v2 release. So, here is v2.01: TFT_HiFiDuino_v2.xx (14637 downloads ) (Note: As always, the code on this page may not be the current one, i.e. there may be a newer version available. The latest version is always up at the project’s official page.)
Also, here is a video of the code in action: