I am designing a system where

Analog Signal ---> (ADC- Digital Data )---> UWB chip mostly WSR601 or AL6301/AL5100 Chipset

Note (1): UWB is an abbrieviation for Ultra Wide Band wireless communication technology. Wireless USB chips which are being used here make use of this technology. So, in short the data is transmitted at 5 Mbps to the UWB (wireless usb) chips using SPI or USB 2.0. These wireless chips then transmit data to the receiver.

Note (2): The data sampled through the ADC just directly needs to be passed on to the UWB chip through whatever interface (USB , SPI etc). Data does not need to be processed in any manner.

I am looking for a microcontroller to perform the function of ADC and interface with the UWB chip. Both (WSR601 and AL6301/AL5100) support various options like USB 2.0 , SPI, SDIO 2.0 , UART etc.

1) The ADC that I need is 10 bit and the data rate resulting from that which I need to transmit to the UWB chip is around 5 Mb/sec. ADC sampling rate required would be around 5 * 10^5 times per second.

2) It needs to be as low power as possible

3) Would SPI be the best choice for this considering the data rate and the low power or do you think some other communication interface would be better?

4) Any uC suggestions having sufficient processing power for the ADC and SPI to work simultaneously?

I was suggested PIC32MX250F128D by someone who claimed that it consumes 14.5mA at 40MHz, 3.3V. But again this uC has a LOT of interfacing options available which I think is unnecessary and also this uC doesn't seem to be available on the microchip website.

So I hope someone can suggest uC with a little lesser functionality and hopefully lower power consumption than one under consideration.

  • 1
    \$\begingroup\$ This question is overly broad, lacks important information, and can not be reasonably answered in its current form. \$\endgroup\$ Dec 24 '11 at 17:54
  • \$\begingroup\$ A major issue to contemplate is how regular the sampling interval needs to be, and how you would go about ensuring that. For example, can you sample in response to an interrupt (which will have some latency), or must you have the ADC generate data under direct hardware timing, and use the interrupt to catch the resulting data. Also consider the tradeoffs of FPGAs vs. software. You must also consider buffering requirements for the UWB, and if you are going to resend failed/lost data or just continue and hope for a usefully high success rate. \$\endgroup\$ Dec 24 '11 at 19:16
  • \$\begingroup\$ @ChrisStratton I guess I will just go with hoping for a usefully high success rate since data to be transmitted are low end images or video. Since the control signals for the camera (whose output is to be sampled by the adc) are going to be passed from the microcontroller only, I guess sampling with interrupts is the natural option (the latency is acceptable). \$\endgroup\$
    – gururaj
    Dec 25 '11 at 17:54
  • \$\begingroup\$ @gururaj - Is this some kind of very unique camera? Because there are established schemes for image transmission - both analog, and over wifi networks, etc which would be a lot less trouble to set up. \$\endgroup\$ Dec 25 '11 at 19:26
  • 1
    \$\begingroup\$ @ChrisStratton - Yes this is a camera developed (not by me) in a university to be implanted on a rat's brain. So the entire transmitter module needs to be somewhat low power. Could you direct me to the established schemes that you speak of? There must be some kind of fixed protocol that the camera must follow for these schemes to work i guess? \$\endgroup\$
    – gururaj
    Dec 26 '11 at 8:49

I don't know what you mean by "UWB" (use standard or common abbreviations, no I'm not going to look it up, it's your job to explain), but many many micros have 10 bit A/Ds and SPI hardware. Even without the SPI hardware, SPI is simple to do in firmware by controlling the I/O lines directly.

In the Microchip line, there is a wide spectrum that meet these requirements. A low end PIC 16 can be small, cheap, and very low power. A fast dsPIC33 can run up to 40 MIPS but of course will use more power. There are various PIC 18 and PIC 24 in between.

What you need to explain is how fast you need to sample the 10 bit A/D and what the micro needs to do to these 10 bit values before passing them on via SPI.

This "answer" is more of a comment because too much important information is lacking. It can be turned into a answer if you cooperate and answer the specific questions asked, not what you feel like answering or or you think is important. As it stands, this question is too vague to be reasonably answered and should be closed. People will come by and close it as they encounter it. When 5 close votes are cast, it's over. The clock is ticking. You may have only minutes to a few hours. Do what I said exactly as I said quickly and you may get your answer. Ignore it and not cooperate and you'll be sent home without a cookie.


You have now added that the A/D sample rate is 500 kHz and that this raw A/D data is to be passed on via SPI. Since the A/D is 10 bits, this is apparently where you got the 5 Mb/s SPI data requirement from.

This is doable, but will require a reasonably high end micro. The limiting factor is the 10 bit A/D at 500 kHz sample rate. That's quite fast for a micro, so that limits the available options. Another thing to consider is that there is more to SPI than just sending the bits. Bytes may need to be transferred in chunks with chip select asserted and de-asserted per chunk. For example, how will this 10 bit data be packed into 8 bit bytes, or will it at all?

The main operating loop of the firmware will be quite simple. You probably set up the A/D to do automatic periodic conversions and interrupt every 2µs with a new value. Now you've got most of 2µs to send it out the SPI. If the device really can just accept a stream of bits, then it might be easier to do the SPI in firmware. Most SPI hardware wants to send 8 or 16 bits at a time. You'd have to buffer bits and send a 16 bit word 5 out of every 8 interrupts. It might be easier to just send 10 bits each interrupt in firmware.

Sending SPI bits in firmware if you only need to control clock and data out is pretty easy. Per bit, you have to:

  1. Write bit value to data line.

  2. Raise clock

  3. Lower clock

It would make sense to unroll this loop with preprocessor logic or something. A PIC 24H can run at up to 40 MIPS, so you have 80 instructions per interrupt. Obviously you can't use 8 instructions to send each bit. If you can do it in 6 it should work. There is some overhead to get into and out of each interrupt, so you might make the whole thing a polling loop waiting for the A/D, but then the processor can't do anything else. I'd probably try to cram this into the A/D interrupt routine using every possible trick so that at least a few forground cycles are left over for background tasks like knowing when to stop, etc.

Check out the Microchip PIC 24H line. I think most if not all have A/Ds that can do 500 kbit/s, and they can all run at least up to 40 MIPS. The new E series is even faster, but I'm not sure how real that is yet.

  • 2
    \$\begingroup\$ Sorry if my question lacked information. I am newbie please bear with me. UWB is an abbreviation for Ultra Wide Band. It is a technology for wireless communication. I did not think the workings of that chip were relevant here and hence did not elaborate on it. The UWB chip needs data (the data that I want to send further on wirelessly. The chips mentioned above support data rates upto 480Mbps) to be sent to it through either SPI or USB 2.0 . The 10 bit ADC would need to sample around 5 * 10^5 times per second. Hope this answers your questions. \$\endgroup\$
    – gururaj
    Dec 24 '11 at 18:05
  • 2
    \$\begingroup\$ @Olin: While everything below "Added:" is helpful, the text above is not. One must dig through 4 paragraphs of noise to get to the actual information. Please edit and delete instead of just adding more (yet better) text. When things (question and answer) start out poor, there is no need to keep the poor stuff after improving. It seems like you just left it there to make a point, which is useless and annoying for future readers of this thread. Please remember that some of the greatness about SE is in its wiki nature, i.e. editing and improvement instead of flame wars. \$\endgroup\$
    – zebonaut
    Jun 7 '12 at 11:53
  • 1
    \$\begingroup\$ -1 because the fact you don't know what UWB stands for is irrelevant to answering the question. \$\endgroup\$
    – The Photon
    May 27 '13 at 4:06
  • 1
    \$\begingroup\$ @OlinLathrop UWB communications is a well-known thing, just like CMOS logic is a well known thing. The fact you don't work in that area doesn't change that. Do you expect everyone to write out "complimentary metal-oxid-semiconductor" every time they want to talk about CMOS? \$\endgroup\$
    – The Photon
    May 27 '13 at 15:38
  • 1
    \$\begingroup\$ OK, UWB is a well-known thing like GSM or TDMA is a well known thing. \$\endgroup\$
    – The Photon
    May 27 '13 at 15:51

Wow. 500,000 Samples/s ( aka 500 kSamples/s) at 10 bit resolution is pretty quick. I suspect any processor that has an ADC that can do this can easily handle the SPI data processing required. SPI is a perfectly fine choice for transmitting at this data rate over a few inches.

stand-alone ADCs

Is there any reason not to use a stand-alone ADC for this application? (These SPI ADC chips require some other chip to act as a SPI master. If your UWB chip cannot be set up as a SPI master, then none of these chips will work with it -- skip to the next section). It's pretty easy to use the parametric selection tool at Newark or Digikey to select "at least 5,000,000 Samples/second" AND "at least 10 bits/Sample" AND "SPI". The results include dozens of chips such as

  • Linear Technology LTC1197LCS8#PBF : ADC, 10BIT, 500kSPS, SOIC-8, SPI
  • National Semiconductor ADC101S051CIMF : ADC, 10BIT, 500kSPS, SOT-23-6, SPI
  • Texas Instruments ADS7884SDBVT : ADC, 10BIT, 3MSPS, SOT-23-6, SPI
  • National Semiconductor ADC124S101CIMM : ADC, 12BIT, 1MS/s, MSOP-10, SPI
  • National Semiconductor ADC122S101CIMM : ADC, 12BIT, 1MS/s, MSOP-8, SPI

A stand-alone ADC will be smaller and conceptually simpler and probably lower power than a processor with a built-in ADC.


There are quite a few processors that can handle 500,000 Samples/second at 10 bits/Sample. Alas, the parametric selection tools don't make it easy to sift out those that meet that requirement from the vast majority or processors that don't quite meet those specs.

  • All the chips in in the 8-bit AVR Atmel Xmega AU series, such as the ATxmega128A4U, can sample at 2,000,000 Samples/second at 12 bit resolution.
  • Many in the "32-bit AVR" Atmel AT32UC3C series, such as the AT32UC3C0512C, can sample at up to 1,500,000 Samples/second at 12 bit resolution.
  • Many in the 32-bit ARM NXP LPC series, such as the LPC1347FBD48, can sample at 500,000 Samples/second at 12 bit resolution.
  • Many chips in the 32-bit ARM Cortex-M3 Atmel SAM3S series, such as the SAM3S1A, cam sample at 1,000,000 Samples/second at 12 bit resolution.
  • Many chips in the 16-bit Microchip dsPIC and PIC24 series, such as the PIC24FJ64GB002, can sample at 500,000 Samples/second at 10 bit resolution.

video transmitters

Transmitting video wirelessly is more-or-less a solved problem. Perhaps getting some off-the-shelf "tiny video transmitter" and matching receiver will allow you to get something working weeks earlier, letting you focus on the parts of your project that are not "solved problems". Then later, after the rest of the system is starting to work, you could experiment with building a video capture/transmitter system that is lower-power or better in some other way.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.