There's some non-trivial background noise on the audio outputs, and it seems to be associated in some ways with the processor activity. Details:
* tested on OLINUXINO-imx233-MAXI and -MICRO
* I am aware of the requirement for DC blocking capacitors when connecting to a grounded source (such as a line-in or external amplifier). I have done testing with the -MICRO on an external base board which includes a 1.0uF blocking cap for this reason.
* Noise appears when using headphones (63 ohms) and when connected to the line-in of a PC.
* The nature of the noise changes depending on a) whether the DSP is open or not (i.e. headphone output buffers are enabled when DSP is open), and b) the processor activity, as detailed below. All captures/situations below are using the -MICRO unless otherwise noted. (I used the LiveSpectrum (http://www.ee.columbia.edu/~dpwe/resources/Processing/LiveSpectrum.pde) applet for Processing (http://processing.org/) to generate the captures below; it is not the most detailed but it is enough to illustrate the issue and compare between different situations. The "dB" levels are not calibrated to a specific source, they should just be used to show differences between one capture and the other.)
Background noise on my system for comparison (nothing plugged into Line In jack). Nothing out of the ordinary can be heard from the system.
(http://i.imgur.com/6tczl.png)
Case 1: System idle (command prompt). No background tasks, other than those included with the stock image. DSP is closed (output buffers off). Note the much higher noise floor all over the band, it comes through as a white-noise "hiss". (The peak just above 20kHz is related to a serial cable attached to the auxiliary UART; I do not know about the peak around 15.5kHz.)
(http://i.imgur.com/9yruP.png)
Case 2: System running custom application in idle loop. DSP buffer is OFF (/dev/dsp is closed.) The repeated peaks in the frequency domain are characteristic of a sawtooth wave - the application is idling waiting for serial input; when it does not see anything it calls usleep() to delay. In this case the usleep() period is 2000uS, and by experimentation I have found that the other tasks in the loop take ~175uS, so the overall period is ~2175uS, or 2.175mS, which corresponds to a frequency of ~460Hz - which would definitely explain the noise on the spectrum below. In fact, if I recompile the application to use a different delay for usleep(), the spectral peaks change accordingly. So this is definitely coming from the CPU activity and not some other outside source.
(http://i.imgur.com/OabOg.png)
Case 3: Same application, playing silent wave data (writing 0x0000 values to /dev/dsp). This holds the DSP open so the output buffers are on. The application is still performing the same loop with usleep(2000), with the additional difference that it is transferring chunks of wave data from the main application logic to /dev/dsp (the audio data could be anything, in this case I forced it to just write silence to get a good comparison graph.) Visually this is pretty similar to the "command line" case above - and it sounds about the same; there's no sawtooth "buzzing" but it's still an undesirable amount of background noise.
(http://i.imgur.com/TaBV3.png)
I rigged the system up with a MAX97220 amplifier/buffer, which has several features - by delaying the turn-on, I can avoid the click/pop from the audio buffer. And the 97220 includes a charge pump so it will output a AC signal centered around 0V instead of one around Vcc/2, which is better for use with grounded amplifier systems. And using the /SHDN input I can avoid the background noise while the DSP is closed. However the noise that gets through alongside the application audio is still very disruptive and I have not been able to eliminate it with filtering or additional bypassing etc. I have tried the experiments on the -MAXI as well and I get similar results, the exact nature of the spectrum is slightly different but the "sound" of the noise is the same. (This also tells me that the problem is not my custom base board, or the 5V regulator, since the -MAXI has a different regulator built in.)
Has anyone else noticed this? Any suggestions?
Trying to bring this to the attention of the Olimex design team as well. I understand the stated policy on FCC/CE compliance as explained on the mailing list a while ago - development boards are exempt, testing is expensive, so testing will not be done on these early versions, etc. But the sheer amount of noise that is coupling via the audio outputs makes me concerned that there is a lot more higher-frequency interference as well... uncertainty about this makes it difficult to feel OK with designing products using this hardware if they are going to have unavoidable CE/FCC problems :(
Did you disable video? Composite video (NTSC) HSYNC approx 15.75KHz, VSYNC approx 60Hz. The video will have high edge rates so the 60Hz will have a number of harmonics.
Quote from: davidjf2001 on September 25, 2012, 05:31:04 AM
Did you disable video? Composite video (NTSC) HSYNC approx 15.75KHz, VSYNC approx 60Hz. The video will have high edge rates so the 60Hz will have a number of harmonics.
I didn't explicitly
enable it (not using it for this project, just the two UARTS). Willing to try it, not sure how to disable it though.
I don't know which kernel you are using but I expect the framebuffer and video encoder drivers are built in. You would have to rebuild the kernel without these. If you do not use video I would rebuild to save the memory (& bus cycles) that would be consumed by the framebuffer. There may be another way to disable this via /sys etc, I am not sure. You may even be able to mmap to the lcd interface, disable its clock etc.