Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
Mbed design of analog part
Paulo Marques.
48
replies
Hi all, Hello Mario,
I am also having difficulties with the AnalogIn. As a simplest test I could think of, I connected the D/A output, pin 18, to an A/D input. Inputs AD0.2 and AD0.4 are really close by (pin 17 and 19) and can be conveniently connected using a jumper, like this:
(Here it is pin 18 & pin19.)
The jumper can be pushed all the way down onto the pins. This makes for a very short connection, minimizing capacitive or inductive coupling to other sources besides the analog output. It also avoids connecting to digital ground or supply voltages.
It is then a simple matter to scan through all the 1024 D/A values and for each one of these acquire a set of A/D readings, for instance with a program like this:
The resulting binary file can be analyzed in various ways, for instance, using matlab:
fh=fopen('d:\out.txt','r');
d=fread(fh,[200,1024],'uint16');
fclose(fh);
d=floor(d/16)';
plot(d,'b.'); axis tight
The last line plots all the data points. For pin 17 on my mbed, the result looks as follows:
Most of the values are on the line y=4x, as one would expect for a 10 bit D/A and a 12 bit A/D, but unfortunately, there are quite a few points that do not seem to have been converted well by the A/D. And the bad news is that these are not just all 0x000 or 0xFFF, so it is hard to reject them programmatically.
Interestingly, the 'misconversions' do not seem to come completely randomly, as can be shown using the following:
m=0:1023; m=repmat(m'*4,1,size(d,2)); imagesc(d'-m',[-30 30]) colorbarThis shows the difference between the measured and expected A/D value as colors:
Clearly the misconversions come at more or less regular intervals.
I would be very interested to hear if other people get similar results...
Best regards,
Mischa
Hi Igor, Hello Christopher,
Yes, the files are binary, to save some space on the USB, but I forgot to change the file extension to something more suitable (and '.bin' might not be a very good idea ;)
As promised, here are the graphs. The first one contains all the data with the short (1ms) wait (after writing to the DAC), the second graph contains all the data with the long wait (10 ms):
The legend: files are in the order red/green/blue/magenta, that means: red: power from USB, green: power from power supply; blue: power from USB, other ADC channels grounded; magenta: power from power supply, other channels grounded.
Comparing the graphs and the colors, it becomes clear that using the power supply or grounding the other A/D inputs does not solve our problem right away: there are points of all colors everywhere. It is striking that the upper left triangle appears more densely populated than the lower right triangle in both graphs. Somewhat surprisingly (to me at least) is that the extra waiting time seems to help, in the sense that the second graph appears to have less 'off' points than the first. But the differences are not overwhelming (indeed the green points seem more populous in the lower right triangle of the second graph).
To facilitate a comparison of the various cases, I have made a bar graph, counting the outliers:
From top to bottom: red: A/D values above 4090; yellow: A/D values more than 50 above the expected value (and not red or black); cyan: A/D values more then 50 below the expected value (and not blue or black); blue: A/D values below 6. It is said a picture is worth a thousand words, so here goes:
The matlab script to make these plots is now included withdacadctodiskshort
The bars in the graph above are numbered 0 to 7, again in the order of the files; interpreting the number as 3 bits, this means that bit 2: long wait; bit 1: other inputs grounded; bit 0: power supply.
Comparing the various categories, it seems that the use of a power supply instead of USB has a slightly detrimental rather than a beneficial effect (except in bar 7); similarly, the grounding of the unused A/D inputs does not appear to bring significant relief from outliers. On closer examination, it turns out that grounding the other inputs does have a beneficial effect on the noise (i.e., the width of the line y=4x). I have also found that pin 17 is very different from pin 19. But I'll save the details for next time.
Best,
Mischa
Hi all,
I checked the scope settings, horizontal settings are .05 uSec/div, so the image shows the clock frequency (second picture in first post).
I took another approach. Since I build the electronics on an experiment breed-board, I tried to put it on a "normal" experiment board.
As suggested in the post above, I put in a resistor from 6k8 (couldn't find 7k5 in my collection) and a capacitor of 10 nF on the output opamp. Schematics:
The output goes with 2 twisted wires to pin 20 and ground from the mbed.
I did 1000 samples and wrote the values to a text file on the mbed, and inserted them into an Excell sheet.
Result:
The values on the left are the floats that the AnalogIn function returns. Not bad.
Looking at the values returned, I discovered that 1 step in the ADC was equivalent to a number of 0.000244. That was helpfull in calculating the digital steps from the float. The biggest variance in the digitizing proces was 16 steps, or 0.4% (16 / 4096 * 100%).
mario raats wrote:
Hi all,
I checked the scope settings, horizontal settings are .05 uSec/div, so the image shows the clock frequency (second picture in first post).
Hi Mario,
The clock frequency?
Measuring from your oscilloscope image:
I'd say the sharp peaks appear to coincide with the grid lines to better than 1/5 of a minor grid division, i.e., ±0.04 divisions. From this, the observed frequency is
1/((7 ±0.04 div)*0.05us/div /17) = 48.6 ±0.3 MHz, or
1/((9 ±0.04 div)*0.05us/div /22) = 48.9 ±0.2 MHz,
with the assumption that the 0.05us/div is accurate. Perhaps it is time to recalibrate the horizontal scale, if it is 2% out of calibration, then the frequency could be 48.0 MHz.
The mbed crystal frequency is 12 MHz; it uses a PLL to upconvert to 96 MHz (or 72 MHz if you have older firmware; the PLL is programmable). So the frequency that we observe is close to the CPU clock frequency divided by two, or 48 MHz. This is also the USB clock frequency. That the USB might have something to do with it is consistent with the observation that connecting the USB of the mbed influences the analog signal.
The CPU clock can be programmed independently from the USB clock - that would be a way to independently verify that it is not just the CPU clock divided by two that we are seeing.
Best,
Mischa
Hi all,
Christopher Hasler wrote:
from the datasheet, http://ics.nxp.com/products/lpc1000/datasheet/lpc1763.lpc1764.lpc1765.lpc1766.lpc1767.lpc1768.lpc1769.pdf pages 61 to 64. table 18 recomends a resistor between the source and pin of 7.5 Kohm,
Christopher,
That specification means that the maximum source impedences is not to exceed 7.5 Kohm.
There is no minimum source impedence, so zero ohms is O.K.It does not imply to insert a series resistance. The series resistance and capacitance to ground shown in the diagram is just the model for the equivalent circuit inside a source
I would agree with Thomas that an extra resistor is not required.
Best,
Mischa
Just want to be clear that is the not the lower 4LSB of the 16bit value that needs to be ignored. Is the LPC or mbed calibrated at the factory? I don't know. If not, is there a calibration procedure? I know we can do our own calibration table in our program if needed.
Hi Thomas,
The 4 lsb of the 16 bit value can be ignored. They are a copy of the 4 msb. It is the mbed analogin.read_u16() library routine that copies these bits. It has nothing to do with the information in the datasheet whatsoever. It just ensures that the values from the ADC are in the range 0x0-0xFFFF instead of 0x0-0xFFF0, in compliance with the documentation in the handbook at http://mbed.org/handbook/AnalogIn, I suppose.
If you don't like the calibration of your ADC, then you can adjust the value of the ADCOFFS (bits 7:4) in the ADTRIM register, see section 29.5.6 in the LPC17xx user manual. It promises that the register will be set by the bootcode on start-up. It also says that the reset value is 0. The data sheet (above) table18, note 5 says that ADCOFFS should be 2. It appears that changing the ADCOFFS value just shifts he A/D results, as if adding a number proportional to ADCOFFS, where ADCOFFS is a 4 bit binary number in two's complement (i.e., -8 gives lower readings, 0 gives about the right readings, +7 gives too high readings). You can set is as follows:
short trim = 2; LPC_ADC->ADTRM&=~0x00F0; LPC_ADC->ADTRM|=(trim<<4) & 0x00F0; //set the trimBest,
Mischa
Hi all,
One of the main reasons I started with the Mbed is the availlability of the on-board AD converter. I already posted another topic about this. My experiences show that the analog part of the mbed design is not one of the best.
Today I started to experiment a little bit with it.
First I made a low pass filter with a buffer, so I wouldn't influence the output signal with the input impedance of the Mbed. Simple design, nothing fancy. Power source external +5V.
On the input is a pressure sensor MPXS 4100 connected. Yes I know, there are digital sensors with A/D conversion in it. But I want to connect more analog signals.
Resistors are 15k, capacitors are 10 nF, cutoff frequency is 1 kHz.
I checked the output signal of the second OpAmp with an oscilloscope, 2 mV/div, looks normal:
After that I connected the output of the second opamp to pin 20 of the Mbed and started to sample the signal. Variance > 10% in the measurements.
I connected the scope again on the output signal of the second OpAmpl with this result, still 2 mV/div:
After disconnecting pin 20 of the mbed the signal is again like the first image from the scope. So I connected the scope to pin 20 without anything else (open pin). Result (5 mV/div):
Since it is an open pin, this can happen. So I pulled it down to ground with a 1k resistor. Same signal as in the second scope image.
The resolution of the AD converter is 3.3 / 2^12, so appr. 0.8 mV. The signal I measured is 8 mV, or appr. 10% of the resolution, which is consistent with my measurements.
So mbed guys, is there a design error in the analog part of the board?