Re: Need DSP recommendation

I don't understand what you mean by sampling. Are you talking about decoding the RF signal or acquiring the A/D values? The microchip parts aren't limited by clock speed for A/D conversion -- in fact you just have to wait longer for the setup time at higher clockspeeds. Back of the envelope calculation (based on my foggy memory of 16F aprts) says you aren't going to get much more than 10-20k analog samples/sec.

If *that* is what you're talking about you probably need a dedicated A/D converter.

--
Ben Jackson

http://www.ben.com/

Don't fall into the comparison by MIPS trap; different architectures will achieve the same result in fewer or more instructions. PIC for example is (from memory) heavily accumulator-bound - you spend a lot of time shuffling data into and out of the accumulator. Other architectures have several registers that can be used as accumulators, reducing the number of data movement instructions. ARM also has an inline barrel-shifter, allowing (for example) the contents of one

32-bit register to be shifted by one to 31 bits, added to the contents of a second register and the result stored in a third register - all in one instruction and one clock tick.

Purely in the interests of sparking an off-topic debate, I'd be interested in hearing how many instructions that would take in other processors ;)

Hi, the short answer is no. You do need an ad conv that will sample that fast. What you need in MIPS depends on what you intend to do with the data you collect.

hi Rahul

I guess you have an algorithm that your using and the demodulation part is a bit heavy. I did somthing like this and when looking for the right micro/dsp I had to know what I needed for my algorithm before I looked at chip specs.

The main thing was what frequency was I going to have to demodulate, to select the sampling rate(assuming no heterodyne). Once I had the sammpling rate then I knew how much time I had between samples to get all the processing done. The selection seemed to me to really came down to MIPs, how many instructions to do things like a MAC (for demodulating there were a lot of these depending on your number of taps, rule of thumb is micro MAC = 5 instructions and dsp MAC = 1) and memory access times (ie wait states for external flash or single verses double access).

A fast micro may do the trick but then you may have to drop the number of taps on your filters or how may loops your algorithm runs. A dsp running at the same clock speed will probably do many times more work in the same time because its architecture is made for efficient signal processing, but the circuit may be more complicated and you will have to learn a new beast.

I think the next step up from your pic would be wither the TI C2000 family of chips or the Motrola 56Fxxx family, others may disagree? These are 40 MIPS parts too but can do much more per intruction. Then it would be the C5000 family, which are used a lot in comms applications but are a lot trickier get running.

Another thing to consider is making your code work on your existing system. Your demodulator should be in assembly. Is the method your using the most appropriate for the application. Is your code efficient. Could you reduce performance to get it to work with higher freqs e.g lower tolerance to noise or lower baud.

Just some thoughts of the top of my head. Tony McKay

That should not be a problem, so I do not think that you need a DSP.

This is the hard part, if you are really planning to use bit banging to generate the signal.

With 50 kHz sample rate at 10 bits/sample, the net bit rate would be

500 kbit/s and adding bit stuffing, self clocking (Manchester coding), headers etc, the bit banger would have to operate around 1 MHz clock rate. Thus, for each sample, the bit banger would have to run 20 times. With the 40 MHz processor, 40 clock cycles would be needed for banging out one bit, but of course also reading the A/D will need some cycles, so the number of cycles for bit banging would be less.

Even if you would have available a noise free bandwidth of at least

1.5 MHz, a line of sight path would be required. However, with reflections from various objects and especially from the ground, there are going to be frequency selective multipath dips within the signal spectrum corrupting the signal. Thus, spread spectrum or similar systems would be required for such large data rates. You should check for WLAN and similar devices that operate in the 2.45 GHz ISM band.

If you are trying to use some home grown transceiver system, you should first test it with some external 1 MHz clock (e.g. signal generator) and observe the waveform at the receiving end with an oscilloscope or other device that can be used to calculate errors when the transmitter and/or receiver are moving around in the final application area, _not_ in the lab. After this, you can decide, is the RF module usable for this application.

Unless the RF module provide these services, I would suggest that some external USART chip to be used that can be put into HDLC mode and capable of generating Manchester coding. The interface between the processor and USART should be with parallel ports so that only a few instructions are needed to transfer a complete _sample_ to the USART compared that multiple instructions are needed to generate a single_bit_in the bit banging case.

Paul

Yes all of that is correct. 40 clock cycles on pic means 10 instruction cycles. The way I have the program written it is impossible to have it sending out a bit with only 10 instructions. Keep in mind it is not just a bit shift, I have to encode the sample every sample period and have flags to check to see whether I am transmitting header or data etc.

Pardon my ignorance as I have very little knowledge of rf. However the rf engineer at rfm.com said that we could get 1 mbps throughput from the TR1100 transceiver module over short distances. We are transmitting a maximum of 50 yards. It is not possible to use a standard WLAN card with TCP/IP due to the extremely high delays (~milliseconds) and protocol overheads. However, would it help to have a rf trasmitter/receiver in 2.4 Ghz frequency? Is there anything available out there?

Well, the final application is also in the lab. This is a reasearch project at a university. I do plan to see the signal delay and accuracy using A/D->micro->transmitter->receiver->micro->D/A and comparing the original and obtained analog signal.

This would be ideal. Do you know of any USART chip that can do this? A

12-bit encoding will be even better as that will save 50% overhead compared to Manchester.

Thanks a lot Paul. Rahul