SMD is easy. Clean the board and apply some flux. Put some solder on one pad on the board. Place the component with some tweezers and reflow the previously applied solder while aligning the part. Once the part is straight solder the other pad.
As you speak German, you might want to have a look here: http://www.mikrocontroller.net/articles/SMD_Löten.
Attached is a "quick" performance comparison of the RTX, fixed range (10Vout -> 10Vin) vs. my current auto ranging implementation.
The stereo balanced loopback test included 30 steps, logarithmically spaced, between 9.9mVrms and 9.9Vrms. 750Hz sinusodial test signal, 262144 pts FFT, 48kHz sample rate. One sweep takes roughly 4.4 minutes, 1.5sec settling time before each FFT-segment included.
Quite impressive
The stereo balanced loopback test included 30 steps, logarithmically spaced, between 9.9mVrms and 9.9Vrms. 750Hz sinusodial test signal, 262144 pts FFT, 48kHz sample rate. One sweep takes roughly 4.4 minutes, 1.5sec settling time before each FFT-segment included.
Quite impressive
Attachments
Last edited:
Hi Jens
just another thank you for your commitment and help providing us the best in class diy audio measurement system;
may I say this would be perfect if you advise us on how to extend the USB interface in order to have a clean spdif and I2S (lvds) output ?
in order to test external dacs
I m ready to draw a little pcb for me and the community that would fit on the rear side with 1 minixlr, 1 hdmi and a couple of components like a latch (spdif) a quad lvds driver, a pulse transformer and an adp151. I would also put an ISO1541 to provide the Xmos I2C over the hdmi for external extensions.
or you plan to develop a Version 2 of your usb board will all of that on it ?
just another thank you for your commitment and help providing us the best in class diy audio measurement system;
may I say this would be perfect if you advise us on how to extend the USB interface in order to have a clean spdif and I2S (lvds) output ?
in order to test external dacs
I m ready to draw a little pcb for me and the community that would fit on the rear side with 1 minixlr, 1 hdmi and a couple of components like a latch (spdif) a quad lvds driver, a pulse transformer and an adp151. I would also put an ISO1541 to provide the Xmos I2C over the hdmi for external extensions.
or you plan to develop a Version 2 of your usb board will all of that on it ?
I haven't planned to develop a PCB with all of that. I assume that the HDMI part is the most complicated to make.
I have developed a PCB with SPDIF, AES and Toslink I/O, but not HDMI or I2S. This may - or may not - find its way to an upgraded product. Still TBD.
Are you looking for output only? An SPDIF output is easy to make. The XMOS board has been prepared for that
I need to coordinate things with RTX, but perhaps we could work together on the HDMI etc.?
I have developed a PCB with SPDIF, AES and Toslink I/O, but not HDMI or I2S. This may - or may not - find its way to an upgraded product. Still TBD.
Are you looking for output only? An SPDIF output is easy to make. The XMOS board has been prepared for that
I need to coordinate things with RTX, but perhaps we could work together on the HDMI etc.?
I haven't planned to develop a PCB with all of that. I assume that the HDMI part is the most complicated to make.
I have developed a PCB with SPDIF, AES and Toslink I/O, but not HDMI or I2S. This may - or may not - find its way to an upgraded product. Still TBD.
Are you looking for output only? An SPDIF output is easy to make. The XMOS board has been prepared for that
I need to coordinate things with RTX, but perhaps we could work together on the HDMI etc.?
I'd love to have a SPDIF output, this way I could integrate the RTX as external ADC in a multichannel setup with my RME fireface. This feature gives the RTX a new dimension in terms of versatility.
The "HDMI" is really quite easy. Its an I2S format hatched by PS audio. If not lost in my disk crash I have all the details. in any case you use an LVDS driver to drive the TMDS pairs in the cable. For this you don't need to worry about intrapair or interpair skew. However I'm not aware of much use for it. Straight TTL outputs would connect to most demo boards.
It may be easier to just make the USB to Digital full duplex as a stand alone product.
It may be easier to just make the USB to Digital full duplex as a stand alone product.
Attached is a "quick" performance comparison of the RTX, fixed range (10Vout -> 10Vin) vs. my current auto ranging implementation.
The stereo balanced loopback test included 30 steps, logarithmically spaced, between 9.9mVrms and 9.9Vrms. 750Hz sinusodial test signal, 262144 pts FFT, 48kHz sample rate. One sweep takes roughly 4.4 minutes, 1.5sec settling time before each FFT-segment included.
Quite impressive
Nice!
In principle, the results are not surprising, but they do show that the auto ranging does the job. It substantially improves the SNR, and also THD is better with auto ranging at low signal levels. The THD curve of the fixed range test looks like it is dominated by noise (SNR) at low levels. However, I wonder why THD was quite a bit better with the fixed setting at 0.5 to 1 V(RMS)?
Also, I don't understand the third test ("amplitude shape"). Can you describe this a bit more?
This seems to come up again and again, and I don't understand the point of this. Why don't you just use any USB/SPDIF or USB/I2S infterface? Then just set this interface as the audio output and the RTX as audio input for your test software. What am I missing?
I haven't planned to develop a PCB with all of that. I assume that the HDMI part is the most complicated to make.
I have developed a PCB with SPDIF, AES and Toslink I/O, but not HDMI or I2S. This may - or may not - find its way to an upgraded product. Still TBD.
Are you looking for output only? An SPDIF output is easy to make. The XMOS board has been prepared for that
I need to coordinate things with RTX, but perhaps we could work together on the HDMI etc.?
I am interested to to the spdif pcb ...
About the HDMI, very often it is only used the hdmi connection to veicolate the I2S signal ...
hi
yes Demian, I was talking about using HDMI as a transport for I2S signal. but now I realize that these signal would be related to the USB-gnd which is not fantastic.
well mbrennwa, yes we can use a standard spdif output or an extra usb-i2s board and then the rtx as an input only. a bit less convenient but ok. also the fft can't use rectangular windowing. is it a concern at the end?
Jens about an SPDIF input, well, this is less usual to develop an ADC, right ? also, the xmos usb audio stack includes the spdif receiver code, but there would be a problem with the clocks. on the standard output you would be synced to your ref master clock (22/24mhz) but on the input side you would receive something totally async, needing also some sort of pll for the xmos to lock. you have not used the si5131 right ?
so to keep things simple, a basic spdif output would be already a good benefit.
remark/fyi, I m drawing a PCB with a SigmaDSP and 2 AK4497 so I m already wondering how I m gonna test it but I have tons of xmos breadboard around 
yes Demian, I was talking about using HDMI as a transport for I2S signal. but now I realize that these signal would be related to the USB-gnd which is not fantastic.
well mbrennwa, yes we can use a standard spdif output or an extra usb-i2s board and then the rtx as an input only. a bit less convenient but ok. also the fft can't use rectangular windowing. is it a concern at the end?
Jens about an SPDIF input, well, this is less usual to develop an ADC, right ? also, the xmos usb audio stack includes the spdif receiver code, but there would be a problem with the clocks. on the standard output you would be synced to your ref master clock (22/24mhz) but on the input side you would receive something totally async, needing also some sort of pll for the xmos to lock. you have not used the si5131 right ?
so to keep things simple, a basic spdif output would be already a good benefit.
remark/fyi, I m drawing a PCB with a SigmaDSP and 2 AK4497 so I m already wondering how I m gonna test it
but I have tons of xmos breadboard around
Last edited:
The third plot is the described test-signal in a graphical representation. The highlighted parts of the stepped sweep are the segments used for the post-processing. In this case: rms-amplitude, thd and snr analysis. Instead of a set of bursts, I wanted a smooth continuous signal in order to avoid step response issues and auto-ranging issues (range-choosing is better without huge steps, therefor linear ramps between steps). I will implement the burst-version as well, maybe the thermal load is to high for a power amplifier.
You are pointing at some interesting details of this measurement. First of all: At this time I still rely on the inbuilt functions "thd()" and "snr()". So, this is plain THD, not THD+N. I was also surprised of the fixed range performance around ~1Vrms. Further one can clearly see, that the autoranging algorithm is choosing a higher input attenuation at levels above 7.75Vrms leading to a compromised SNR (comparing to the fixed range approach).
The plot also reveals, that the output attenuator is the performance bottleneck. The transition-points are obvious. Though, I think Jens found a perfect cost/effort/performance ratio. Chapeau!
To conclude:
(1) auto-ranging is not always better, it is a compromise (*). Still, the average performance is better.
(2) there is room for refinement in the auto-ranging implementation
(*) one reason is the relatively small amount of attenuation steps provided by the RTX6001.
Last edited:
I am not quite sure if I understand your question correctly?
Currently, I am evaluating the signal amplitude after processing of each audio-frame (a buffer of 512 samples ... 8192 samples) and adjust the input and outut attenuators accordingly via the RTX remote control interface. This is done in the playback/recording software.
Obviously, this approach fails at some fs/framesize/input-Signal-frequency combinations. I am still tweaking the parameters to get this right in most conditions.