Trickery with the Propeller..how to sample 4 a/d converters in 1 COG simultaneo

OzStamp

Dear Ladies and gents..

Talking to a customer here locally in OZ just last week.
This customer is pushing the Propeller to its absolute limits..
No more than 1 COG left and now they suddenly want to add the sampling of 4 separate
8 BIT a/d converters to it.. only 1 COG left and 8 I/O pins.
The Propeller needs to sample ( take a snapshot of 4 separate a/d's) them simultaneously..
also it needed to sample very rapid and send serially to an external controller..via serial
port coms rate as fast as possible..( all done in asm)

The external controller that receives the data is a supercomputer with amazing computing power.
It can do trillions of operations on incoming data but cannot do a/d sampling on external hardware
without having to spend 5K on harware.. so the Propeller is used to do various other collecting taks
and it just simply sends the data to this super computer...

Anyway to get stuff to happen we provided the full duplex object to customer..
They disected this and used the necessary bits from it to create a small send routine only
Basically·we are sending just 1 LONG at 112K (serial) so all the buffers and receive routine were stripped..

Anyway to share what I can share ( as approved by the customer) we wrote a little routine that
clocks and samples 4 ADC0831· A/D chips totally simutaneoulsy..
The clk + CS signals are together... but the data from the 4 separate ADC0831 chips to 4 separate inputs
on the Propeller... so the clk and shifting all operates on 4 incoming bits that are sampled .. stored and shifted
by 4 locations ( shl 4) each time after a single clk signal...)
So after 8 samples ( after the initial wake up pulse for the adc0831) we end up with 1 LONG value that has
4· off 8bit values in it.. this is transmitted to the super PC and this PC disects the data from that LONG.
( It can do this 1000 quicker than the Propeller so make my day.. you do it...)

Have attached a PDF file that we did to get going with the concept of it all.
Hopefully it is self explanatory...added more detail to the PDF file 16/1/2008 Jan 16..
Enjoy

Cheers· Ronald Nollet Melbourne OZ







Post Edited (OzStamp) : 1/16/2008 2:59:12 AM GMT

stevenmess2004

So you can sample 4 ADCs and send the data back to a PC all in one cog? At 112K. That is very impressive. Now, all we need is some more pins and we will be able to sample 32 channels. How about a 32 channel sound recorder I guess the many ADCs would be getting fairly expensive.

Good to hear of someone in Australia leading the way with the Prop

Steven

deSilva

Good work OzSTamp - it seems your customer has attended his computer science classes, as this is "standard procedure"

The bandwidth is determined - by the limited serial transmission - to 3k (8 bit) samples per channel per second = 1500 Hz per channel.

As I estimate < 100 instructions per complete handling of one channel byte (= 20µs for all) you should be able to increase the throughput (and the transmission speed) by a factor of 15 if needed.

I think most of this idle time is wasted with waiting inside the bit cells (=10µs) now.
From your descriptiuon I get the impression that this bottleneck - if any any at all - has been created by the separation of sampling and sending; they rather should be interleaved...

Such problems you describe (synchronious multiplexing) are generally solved by a small FPGA for very high speed.

Post Edited (deSilva) : 1/12/2008 11:39:09 AM GMT

OzStamp

Hi DeSilva.

We loop 8 times thru a very tight loop. Once that is done all data from the 4 separate ADC chips is collected..
No more no less..

The loop executes >> adds + stores + masks(4ins) + shl 4 ..after 8 loops we are done.
Data ie the 1 long ( 4 bits( 4ad data) * 8 =32 bits) value is send and we start again as above..

There is no time wasted anywhere.. we could send faster ( 200K + ) but it is not really an issue.

cheers Ron.

deSilva

There is terribly much time wasted, see my posting above
But if you need not more than 1500 Hz, why bother?

OzStamp

Hi DeSilva.

I am not going to pretend to be an absolute guru at assembly here.
But as I understand the only time wasted here is the time when it is sending the 1 LONG variable
that contains all the data from the 4 ADC chips...

There is no other time wasted..

Do I understand that correctly ?

remember we only had 1 COG left· and only 8 pins ( 6 for sample and 1 for sending)

Have not seen the final thru put of the system but will ask the customer that next week.
I just knocked up the asm code for the sampling of the adc
The customer pasted my asm code into his "Send routine" and it runs that task
totally simultaneous to all the other stuff the Prop is doing·as well..

cheers Ron

deSilva

Yes Oz, it does well ,and its absolutely standard, and all is really well if the customer is satisfied with 1500 Hz!

I just wanted to point out that the bottleneck is not where sometimes looked for Sorry if I had not been so clear as I thought I was...

Serializing sampling and transmitting is a sub-optimal strategy! If sampling takes S and transmission T ticks you will end up with S+T ticks. As S<<T all efforts in improving the sampling are vain!

By just doubling the transmission speed you will get a 3 kHz sampling without any change in your code...
The tricky thing is to come to 15 kHz...
Interleaving sampling and transmission is most likely not necessary if you could transmit @ 1 Mbit/sec
Interleaving will also require locked clocks which might not be feasible, though I understand you can flexibly provide the clock for the ADCs...

My insertion concerned the theoretical limits of the COG for this problem of yours. I just pointed out that you are far, far away from those limits

Post Edited (deSilva) : 1/12/2008 1:41:04 PM GMT

Mike Green

Another way to say what deSilva has said is that one can certainly overlap the reading of the ADCs with the transmission of the previous set of data (double buffering) to make this work even faster and this can all be done using only one cog, parricularly easily if you could use the serial timing for the ADC clock, i.e. sample a bit from the 4 ADCs at the same time as a bit is being transmitted to the supercomputer. If you need to slow down the ADCs, you could sample a bit with every 2 or 3 bits being transmitted.

112K is pretty slow for one cog to do. If the ADCs could handle it, you could easily double (230KBps) the transmission speed and, with the overlapped sampling, quadruple the data rate.

Tracy Allen

Ron, nice work with the interleaved conversion. The ADC0831 data sheet specs a minimum conversion time of 32 microseconds with a 400khz clock. So I guess you have it fine tuned to close to that but with 4 chips simultaneously?

The way I figure it, it takes 357 microseconds to transmit the four bytes at 112kbaud, so that is the S<<T "bottleneck", but from what you say the requirements are well met at that rate anyway.

Since this has become a wider discussion, another possibility would be an ADC like the MAX1037 or MAX1039, which has a MUX for multiple channels, but most importantly, also a mode where all the channels can be scanned in a round robin sequence and delivered to the serial output without further channel addressing. That is with external clocking, so a scheme where the data output is interleaved with the serial transmission would be feasible with very little processor oversight. What is more, the data bytes do in fact come out justified, not interleaved. The minimum conversion time is 8 microseconds per channel, so it is commensurate with the 32 microseconds for ADC0831 (with four at once). The MAX103x has an internal T/H, and the data sheets are not too clear on where it samples during multichannel conversions. But I think the ADC0831 does not have a T/H, so its input would have to be relatively stable during the 32 µs conversion anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

OzStamp

Hi to all Mike G , De Silva and Tracey..

Thanks for all the indepth info on the matter..
I think you all understood our constraints and limits.. ( only 1 COG space left) and the only method that I could
come up with quickly ( my humble brain) was to do it they way as explained..
Sending the collected data serially while still sampling the a/d chips sounds like a interesting concept and certainly
could speed things up ... I imagine keeping the timing correct ( RS232 protocol) would be tricky...

Anyway I learned from doing this and thought we share it.
As usual it also showed me that there is still soo much too learn as well... and being here in the presence of all you people willing to share +
offer your contructive comments and suggestions is really very cool..

cheers and rgds from Australia Ronald Nollet Mel OZ

OzStamp

Hi Fellow Proppers.

Was getting a few PM's re my original post.. people wnated to clarify a few things.
So to make my it all a bit clearer as to what we did .. we added some more detail to the original
PDF file attached in the first post..
So for those that enquired about it.. download it from there..

cheers Ron Nollet Mel OZ

Javalin

Hi Ron,

Would (and I assume it would) that work with 1 x COG and 2 x MCP3208 (8 channel) ADC's?

I assume you'd have one cog and tie the CS and CLK as you have already done.· I use seperate DI / DO lines - so I assume you'd tie the DI's together so each ADC gets the same commands etc.· Seperate DO's etc.

Both ADC's then would recieve the same commands at almost the same time to get ADC1-CH1, ADC2-CH1, ADC1-CH2, ADC2-CH2,...., etc...

Picture attached - for clarity....

Cheers,

James

OzStamp

Hi James.

I think that should work.
Each long would end up with 24 bits data ( 2 channels with 12bits res) the data is interleaved..

Just like our setup.. we have 8 bit a/d converters (adc0831) so we could use 4 off them ( 4* 8 =32bits)
There is already an object for the mcp3208 in the parallax object library.
So what I would do is download that ...disect it and adapt it ..

The interesting thing that really came out of this whole exercise( for me anyway) is that the data ( 1 long) can be transmitted
via 1 HUB access.. then it can it can be transmitted raw and analyzed by external pc.
I am even considering setting up a test to send the data raw .. collect it and pasted it into Excel and Un-interleave the data
Plot it in a graph...

Still teaching myself Prop asm in my spare time and now also trying to UN_interleave the data in another COG
have not yet got it all sorted but have it all graphically in my mind what needs to be done..


Just thought of something .. maybe you should also write the channel number in the LONG as well.
Since you do have 8 bits left ... ( 32-24 = 8)
So when you pull it out of the HUB not only does it have the 2 channels of 12bit data .. it will also have the
sampled channel number in it...and since both channels are the same this could be usefull..


cheers ron mel oz..

Javalin

Hi Ron,

I already have an ASM object for the MCP3208 so thats easy. I log the data to a memory card - so id parallally take the values into 16 (2 x 8 channels) seperate variables, then math & log as required.

The data on the ADC's is Acclerometer on one and gyro's on the other - so ideally i'd want as nearly simultanious as possible.

Thanks for the reply and the post - I hadn't thought of doing it this way....

James

OzStamp

Hi James.

Keep me posted with it .. sounds like an interesting project.
Writing to a card is something on my list of "need to learn that " as well.
What card do you use ? an SD card with SPI interface ?

cheers ron

Javalin

Hiya

Yes - last year was a MMC/RS card but this is a MicroSD card (yet to be tested) - both via SPI

James

OzStamp

Hi to all

The code attached here unwraps the 4off · 8BIT data that is interleaved in the ONE long
(4 separate 8 bit values from adc0831 chips) sampled simultaneously..
All relevant to the initial post that started this thread..

Commented as much as possible
Hope it all makes sense...has been tested and works well.

If anybody can improve· on the speed·please·share it with us all.

Post edited 19/1/2008 (jan) removed the code that I just marked "rol nr"
this is really not needed..( so has been removed) updated file also posted

So conversion rate is now 244KHZ·· not 175KHZ..

Cheers·· Ron Nollet· Melbourne OZ

Post Edited (OzStamp) : 1/19/2008 12:26:58 AM GMT