Simultaneous Dual External ADC Handling

Go To Last Post
23 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am working on a data acquisition of two simultaneous analog values using MAX1062 200ksps 14 bit chips. The SPI transfer takes place when the CS line is pulled low and 24 clock cycles moves out the data in 8 bit segments.

There are two SPI buffers in an ATXmega16A4U. Since I want both ADCs to move the data into the SPI buffers simultaneously should I set up one as a master connected to both ADC clock inputs and the second Xmega SPI (configured as slave) with the two ADC outputs connected to the two Xmega MISO inputs? Only the CS and CLK inputs are used on the ADCs (MOSI is not used).

I presume that I would write three bytes into the master SPI to receive each piece of the ADC output (reading the values in between each write)?

Does this appear to be a reasonable approach?

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

second Xmega SPI (configured as slave)

Disclaimer, I am neither an Xmega expert nor an SPI guru. 

 

That said, you lost me when you said you were going to make one of the Xmega SPI modules a Slave.

I'm not sure why you would do it that way.

 

What I envisioned was more along the (untested) lines of:

 

Xmega AU series has up to 4 hardware SPI modules, ( I didn't look at the specific 16A4U sheet), one on each of the Ports C, D, E, and F.

 

So to read the two ADC channels I'd configure two hardware SPI modules as Masters.

 

When you write to the Master's SPI Data register it will then start shifting out the data, and reading in the new data byte from the DAC.

The data transmission isn't buffered / queued in the hardware, so make sure you wait for the SPI data byte transmission / reception to complete before you read the incoming data, or initiate a new data byte transfer. 

Or trigger the read via interrupts.

Then transmit your next dummy data byte, and finally the third dummy data byte, to read in DAC data bytes two and three.

 

I'd interleave the two processes, (after I had one channel up and running correctly).

Write your Tx data byte to SPI Channel X, which starts its process.

Then immediately write your Tx data byte to SPI Channel Y, which starts its process.

Now both can be reading in their respective data channel's data.

 

Then either poll for completion, or use interrupts.

 

I'd start by getting the system working without interrupts, and then go back and set it up in an interrupt driven manner if that makes sense given the overall system design architecture, and how you are processing the data.

 

Anyway, that was my first thought on this...

 

JC 

 

Edit:

Note that the approach suggested above does not make use of the Xmega's Event System or its DMA System, which might conceivably either speed up the process or unload the processor, if either was necessary.

Note that there is a bit of a learning curve, (IMHO), for successfully implementing either of those.

 

Last Edited: Tue. Feb 26, 2019 - 09:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting ADC part...there is essentially nothing to write to the ADC, it is just a shift register.  Usually there are various control bits, mode, registers, etc to fiddle with. (and give a headache)....nothing here.

They mention the mysterious sub bits s1 & s0...betcha, these are also avail in higher-grade part numbers as 16 bit converters.  In your case, the last 2 subbits are probably scrap/junk.  The datasheet never says what these are!

 

If you use the 2nd spi as a slave (really just a shift register), just make sure that it is set to clock data in on rising edge, since  the master will clock data out of the adc on every falling edge.   The clock, of course, would need to go to the slave as well (master clk to two adcs & slave).  You must control the CS pin so that it stays low across all 24 bits (or the ADC "aborts"). 

 

Or, as mentioned, you could just set up 2 full spi connections and run them simultaneously.  This has the advantage that once 1 is debugged/working, the 2nd is a duplicate (so you might as well try this route for starters).

You can start number adc2 within a submicrosecond of adc1 using 2 spi's  (your slave idea could start them at the "exact" same time & save one clock wire--if running a cable to the adc's). 

 

The micro has a 12bit adc (0.025%)...maybe that's all you'll get from the 14 bitter anyhow, due to resistor tolerances, vref levels, etc.  So don't toss it into the trashcan. 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I could use both Xmega SPIs as master but they would be starting at different times because you have to write to each register to start transmission. If one is master and the other slave with both external ADCs and the Xmega slave connected to the master then the outputs to the SPI registers will be simultaneous.

The Xmega only has one ADC so the timing of the two analog values will be different. Yes, the data could be curve fit and syncronized but that also limits the data rate.

The Xmega ADC will be used for other data streams which can be a slow rate and not time sensitive.

The other problem will be where to put the data as it comes in. The 16 will not have enough memory but a 256 might. Otherwise it will be an external memory chip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The other problem will be where to put the data as it comes in

What do you mean---why do you need to save a lot of it?  How many samples do you need? How fast do you need to sample?

 

If you had a register-style ADC, with trigger pins, you could trigger both ADC's and then read the results whenever you want (even sequentially).  This ADC is different in that the data reading also clocks the conversion...it appears rather effective & efficient!

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I personally doubt that you will get data that is any more  "simultaneous" than when both SPI modules are masters. That way, you have complete control over them. The time skew CAN be as little as a couple of MCU clock cycles. 

 

Jim

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Wed. Feb 27, 2019 - 02:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Currently, one cycle is 1/6 second. If it is reading 100ksps then there are 100k bytes to be stored per cycle (100ksps / 6 * 3 bytes *2 ADCs). Since the cycle repeats I presume there would be averaging between cycles to reduce the variances in motor speed.

What is the advantage of having "complete control" over reading simultaneous data? There would be a wiring difference which would have to be accounted for in the board.

The data will be streamed to a PC by USB for display. Averaging or other manipulation can be done there.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The data will be streamed to a PC by USB for display

So why do you need to store a huge amount  in the AVR...can it be held to a small buffer that is then spit out the usb?  Take a 100 readings & then send them to the PC...repeat over & over.  You could also include a timer value, so the PC knows exactly when each block was recorded (relative to other blocks).

 

Currently, one cycle is 1/6 second

One cycle of what?   A single motor spin?  An acquisition rate? 

What do you hope to get?  Can you just average all of the readings together into one final number?  Are you thinking this is more like averaging a scope sweep?  Then, yes averaging multiple sweeps reduces the variance of the final sweep.

 

 to reduce the variances in motor speed

Does this mean you are controlling the speed, or just interested in measuring it  (& measuring it with lower variance)

 

How is the ADC value even related to the motor speed (do you have a sensor, tach, etc)--that is your first question to answer

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm pretty good at complicating a project, but the goal is really to try to keep it simple, when possible.

It is so much easier as the project grows in complexity when the individual components of the system are obvious and straightforward.

 

You asked if your Master & Slave approach was reasonable, and I suggested a dual Master approach as an alternative.

 

If you truly want signals that are sampled at exactly the same time, (and you did say simultaneously in your original post!), then the dual Master approach won't fit the bill.

 

I guess my next approach, for truly simultaneous sampling, would be to use an ADC that had an external pin to control its sample and hold circuit, (i.e. that triggers, exactly, the sample time).

Then I'd use one I/O pin to trigger two of the ADCs simultaneously.

Then between samples I'd read their data.

 

That said, I am intrigued by the desire to measure motor speed with that degree of synchronicity.

As a mechanical device what is its RPM, and just how much can it change its speed in a few nSec?

Are you dealing with a high speed rotor on an air bearing, a slow stepper motor on an electric window, or a system somewhere between the two extremes?

 

You mentioned USB data transmission, (data aggregation and delay in the buffer), followed by PC processing (averaging), which might further smear the data collection process.

 

When you first mentioned absolute synchronicity I thought you might be working on signal modulation where absolute phase relationships are critical.

I would not have thought such precise and synchronous timing was needed for (most) motor control systems.

 

In any event, I agree that Master / Master won't meet your absolutely synchronous sampling requirements.

 

If you are able to discuss it further, I'd be interested in learning more about the actual project.

It sounds interesting.

 

JC 

 

Edit:Typo

 

 

Last Edited: Wed. Feb 27, 2019 - 03:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The project is a dynamometer. It currently uses a Labjack board for data acquisition. We want to eliminate the expense of the Labjack board with a custom board. It has quite a lot of capability that is not needed.

An electric motor drives the load which has a potentiometer for position and load cell for force. The motor controller has a 0-10 volt input. It is not actively controlled during a run so the load can change the speed over a cycle. The speed has to be derived from the position and time.

The data over one revolution of the motor can be averaged with the next at each data point to reduce errors.

As to storing the data on the AVR or live streaming through the USB, I am not sure how fast it will handle 600k bytes per second. I do not know all the technicalities of USB, I presume it checks data accuracy and retransmits? Eventually we want to add wireless connection to the PC which will likely have drop-out which will restrict the pipeline so I was thinking of having the capability of storing the data locally until it can be sent through.

From what I have read previously, it is better to use a separate USB chip than to rely on the Xmega because of the overhead and retransmission requirements.

I am also looking into replacing the potentiometer with an encoder which is cheaper and eliminates the noise of that signal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First--why do you need such a high sample rate?  How fast is the motor spinning?  Note that you can get a better average speed by sampling slowly (since successive samples are taken over a longer mechanical interval). 

In an extreme example you could  measure the time it take to make 5 revolutions, say it took 20ms, now you have a nice long-term average (speed) number.  Of course, then you lose any instantaneous speed changes along the way (which is the point of averaging).  It boils down to how long you want the average speed averaged...1us, 1ms, 1 sec, etc, and how fine of an instantaneous result you may also want.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 600k bytes per second

That would be 4800 K Bits /Sec, 4.8 M Bits/Sec, without including any packetization overhead.

 

Wow, that's a lot of data points!

 

IIRC USB 1 is Low Speed, and is good for 1.5 M Bits/Sec, (in theory).

USB 2 is good for 480 M Bits/Sec, (in theory).

USB 3 is good for 5 G Bits/Sec. (And perhaps 10 and 20 G Bits/Sec as well)

 

So, Low Speed USB isn't going to cut it for your application, you'll likely be looking at USB 2 for real time data uploading.

(Obviously if you store the data and then upload it after the fact you can use whatever data rate you wish.)

 

Running an Xmega at 32 MHz you will have about 50 clock cycles / data byte to do whatever needs to be done if you wish to handle 600 K Bytes / Sec.

 

Time for me to bow out, as I'm a hack programmer, and the above will require some very careful system design and programming.

Likely the data sampling is ISR based, (although it wouldn't have to be..., separate discussion).

 

That means you have to handle the data in the ISR, as you don't want the overhead of multiple ISRs or you will likely miss data.

Although, that said, the Xmegas have a priority (3 tier) ISR system, so data collection could be the highest priority task, and restuffing a buffer to an upload chip could be a lower priority.

(You couldn't afford many register Push/Pops !)

Anyway, reading a couple of parallel ports for data input and then restuffng the data for uploading might be possible, but non-trivial.

 

Commercial product, or just something you need to get done in-house?

Reason for asking is that the Xmega is easily over-clockable as it has a clock PLL, so loading a 3 or 4 into a register instead of a 2 is trivial to bump up the speed.

The chip is known to work at room temperature, etc. (not tested over temperature and voltage), at 48 MHz, while Atomic Zombie has run the chip in the low 60's MHz range, IIRC.

That assumes that one is using just the digital logic within the uC, and no analog or EEPROM functions.

Even running at 40 MHz would increase the processing room to 66 clock cycles / data byte, a trivial increase for most projects, but perhaps important in this one.

 

One might wonder if a several hundred MHz clocked ARM processor with an integrated High Speed USB interface would make undertaking this project easier.

 

Of course if the project was trivial someone else would have already accomplished it!

 

JC

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am looking at the high end of what might be used. The result is plotted as force versus velocity. Velocity is derived from position. Since the motor load varies around the revolution the position points need to fine enough for calculating an accurate instantaneous velocity, not average over a cycle.

The motor is spinning a scotch yoke to produce linear motion. It has a 1" radius and the peak speed is 24"/second.

I had the impression that the data rate would be too high for a live stream so it would have to be stored locally and, actually, none of the Xmegas are going to have enough flash memory to store enough data.

Storing it to a memory chip might be more than an Xmega can handle. I was not going to a SAM right away as I am more familiar with megas and Xmegas are similar.

The SAM3S and 4S have quadrature decoders which would be useful if the potentiometer were changed to an encoder.

This a commercial product trying to keep ahead of the competition.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sounds like a shock dyno. Technically you don't need to sample simultaneously if you know the time between sampling you can remove this in software. Consider the angular error at,say, 10us difference?  Then there's the backlash in your scotch yoke.

 

Do you really need to sample at 200ksps? You could resolve the noise in the pot and load cell methinks. 

 

I would suggest you stop and consider what your requirements really are. At the sample rates you are talking about, will you pot and load cell actually give you measurements to 14 bit resolution? Will the adc give you useful 14 bit resolution? I've done load cell measurement with 24bit adcs but yet only 14 bits of that was useful. That was at 20 samples per second. 

 

Questions to ask yourself -

1. I'm assuming a linear pot. what is the stroke? Divide the stroke by 2^14. How many microns is this? Consider how noisy a pot is naturally.

2. What is the bandwidth of the loadcell? Remember, the higher the bandwidth, the greater the noise, so you want your bandwidth to suit the expected frequencies of your measurement.

 

 

At a guess, something like a SAMG51 would probably suit - a fair slab of ram and a fast adc. I really don't think you need simultaneous sampling or a 14 bit adc. Trying to do the shenanigans with master/slave spi is making a rod for your back. Figure out what you REALLY need, then choose a part with the required ram, adc etc. Your life we be much simpler and productive..

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If each spin is relatively similar (you were talking about averaging multiple sweeps/spins), could you simply report, say, every 4th spin?  Then the stream rate would be lower.  Or possibly build up a sweep using multiple passes, like some scopes do to increase apparent bandwidth. (sample/report points 1,5,9,13....  then 2,6,10,14... then 3,7,11,15..., etc) In that case, the sampling the can be slower, though there is no free lunch.  However, that requires very tight synchronization from spin-to-spin. How many plot points per spin are you looking for?  Seems like this begging for an encoder (then the spin-to-spin synch can be tighter).

 

You can also use an analog circuit to provide velocity information directly from the pot & set the bandwidth to what you desire...however that is a noise accentuating (derivative) process.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know potentiometers are noisy which is why I am looking into an encoder for position. The SAM4S has a quadrature decoder which would make this easier. The other reason is cost. The potentiometer costs about $250. The Broadcom Avago encoders are less than $50. The encoder output would trigger the ADC.

The simultaneous measurement was to eliminate the curve fitting and interpolation in the software with little expense.

The yoke is always loaded against the motor so there is no backlash.

If I go with a SAM4S or similar there is only one SPI so I could not go with the dual SPI arrangement that I originally started this post with. I will look at the SAMG51, thanks.

Interestingly, the Labjack board claims 12 bit resolution on the analog input but the chip they are using has an 8 bit ADC. I did not check all the chips on the board but they must have a separate ADC chip that is being used.

I do not need 200ksps, but I was looking for an ADC that would do the 14 bit with the simplest control and that is what came up.

The averaging is at each position, not over a cycle. Another thought, with each cycle the temperature is going to change which changes the load. The temperature is measured from the outside so the oil temperature will not be immediately transferred.

Last Edited: Thu. Feb 28, 2019 - 06:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do not need 200ksps, but I was looking for an ADC that would do the 14 bit with the simplest control and that is what came up.

Well, that is an important thing to mention.  The ADC might be able to do 200000samples/sec....but the AVR can use the same chip to do 1 sample per hour; 200K is just the upper limit. 

 

The averaging is at each position, not over a cycle

You could possibly take more samples at each spot (during one sweep)....so in effect each reading consists of 4 or 16 samples averaged right "then".  Of course that raises the sample rate, which we would rather lower. At least these could be averaged in the AVR, resulting in less data to be transmitted.

 

The potentiometer costs about $250.

Yikes!   How much for the leather carrying case?

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Feb 28, 2019 - 11:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why would you need a quadrature encoder? The motor only turns one way doesn’t it?
I still contend you could use only one adc for both readings and still have enough sample time. The difference in sample time probably equates to 1thou of movement. The loadcell would hardly have a chance of measuring the difference. You’ve most likely got greater phase lag elsewhere.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking up "encoder" on Mouser for a rotary, incremental, no detent, no switch gives quadrature encoders. If I use a magnetic or serial output encoder then I have to poll the position  or use a variable timer (when measuring at different rates) to find when to read the load cell and wait for the ADC to return a value. I suspect that will make it further out of sync with the position.

The single channel encoders are $360 compared to the quadrature HEDS encoders at $36. I do not need the fancy case and connector.

Using an encoder for position also requires another switch to indicate the zero or near zero position. So get rid of potentiometer noise but add complexity elsewhere unless the encoder is mounted on the output shaft then the index pulse can be used to find zero.

These are linear potentiometers. Ones that last cost that much. They also come from Brazil (?) and have to be ordered in lots.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use an absolute encoder...then no worries about a home position...you can get one for $45 from mouser with 1024 positions.  You simply get the position at all times.

 

https://www.mouser.com/datasheet/2/54/EMS22A-50229.pdf

 

If I use a magnetic or serial output encoder then I have to poll the position  or use a variable timer (when measuring at different rates) to find when to read the load cell and wait for the ADC to return a value.

You don't necessarily have to "poll"...read the position & load cell & store the loadcell & time info into the correct spot (or toss it, which arguably is a form of polling).  If you read fast enough, you'll never skip a position. If you read "too fast", you might simply read the "same" position more than once.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One problem with that encoder is that it has to be mounted on a board. The HEDS encodes are in a case with mounting and cable. The HEDS is available in 4098 PPR and the quadrature output is four times that.

If I keep reading the position and checking for a change that could be off more than starting both ADCs at the same time and reading both values as was my original premise. The position could change whilst it is reading the values or checking if the position has changed.

The HEDS has an index pulse output once per revolution. It is easy enough to count the pulses to bottom of the stroke from that and set it as a calibration value.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The position could change whilst it is reading the values or checking if the position has changed

Well of course that is true of any position sensor (even a pot)---if it is not stopped at the time of query.  Seems like you could start reading the encoder at the same time as reading the adc.  Read one bit of the encoder, to lock in the position, then start reading the adc to grab the voltage, then finish the bit either in in bulk or alternating fasion (read next bit from encoder, tten next bit from adc, etc) 

One problem with that encoder is that it has to be mounted on a board 

if you look, you shall find

 

https://www.ebay.com/itm/NEW-DC5V-Absolute-encoder-RS485-interface-15-bit-32768P/273654478503?hash=item3fb713f6a7:g:jGAAAOSwU0hcOt4j:rk:12:pf:0&LH_ItemCondition=3

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We decided to change from the potentiometer to an encoder for the position output. That eliminates the noise and wear and gives better resolution off the end stroke positions. I am looking at the CUI AMT11:

https://www.cui.com/product/reso...

which is programmable for resolution and index position. The data sheet does not give any information on delay on the output only the rise and fall times of the output. It is capacitive sensor with a PIC18F uC. Presumably it uses the PIC ADC to read the capacitance?

On the other end a SAM3S or 4S. Both have quadrature decoders and the 4S is available to 1M of flash so the data could be stored in an array rather than external memory.

The 12 bit ADC should be good enough for the load cell. The readout resolution is to one pound and 12 bit will give to 0.366 pound. Linearity is 0.15% which is a 2.25 pound error.

Just checked, going to a Class III NTEP load cell the combined error is 0.02% or 0.3lb on 1500 lb F.S. For that a 14 bit ADC might be needed.

Last Edited: Mon. Mar 4, 2019 - 07:05 PM