On Thu, 08 Jan 2004 09:52:14 +0200, Paul Keinanen wrote:> 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.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.> >> Assume plenty rf bandwidth. > > 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.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?>>What is the cheapest solution to this? I cannot use a SPI module since >>the rf module doesn't like them. > > 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.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.> > 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.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.> PaulThanks a lot Paul. Rahul
Need DSP recommendation
Started by ●January 5, 2004
Reply by ●January 8, 20042004-01-08
Reply by ●January 11, 20042004-01-11
On Thu, 08 Jan 2004 07:28:52 GMT, in msg <UE7Lb.608$Wa.338@news-server.bigpond.net.au>, onestone <onestoneXYZ@ABCbigpond.net.au> wrote:>Zonn wrote: > >> On Wed, 07 Jan 2004 17:48:55 GMT, in msg >> <bEXKb.15$Wa.0@news-server.bigpond.net.au>, onestone >> <onestoneXYZ@ABCbigpond.net.au> wrote: >> >> >>>You should be able to do this with the PIC18F, even at much lower clock >>>rates than 40MHz. I suggest you re-examine your design, then look at the >>>following:- >>> >>>Sample rate of PIC is > 25kHz, I don't know what the 18's will do, I >>>left PIC s behind a few yars ago. Certainly an MSP430 with as low a >>>clock rate as 32.768kHz could handle this application. >> >> >> <snip> >> >>>>My application is the following. The processor is connected to an >>>>analog sensor. It needs to sample the sensor to a 10-bit digital value >>>>and transmit it bit-by-bit after encoding along with some protocol >>>>overhead to an rf transmit module attached to a pin. >>>> >>>>The reverse procedure happens on the receiving end where the mcu >>>>receives data bit-by-bit from the rf receiver module and it needs to >>>>decode it and spit out the value through digital i/o. >>>> >>>>With the 18F pic (10 MIPS) I can acheive a sampling rate of 5 Khz. I >>>>would like to sample at 50 Khz (or more). >> >> >> <snip> >> >> Really, you can sample a 10 bit ADC at 50khz using a processor running at 33khz? >> >> What is that, something like 1.5 samples per clock cycle? >> >> That some fancy codin'! I'm not worthy... ;-) > >Obviously you don't know the MSP430, otherwise you wouldn't be so >sarcastic. Like many other micros (including the PIC) it has more than >one clock source, In fact the PIC has a dedicatred A/D clock, so while >the main crystal might be slow internally generated clocks allow much >faster operation of peripherals. so I agree with you, you're not worthy ;@}The perceived sarcasm was based on the fact I had assumed you simply misquoted your "clock rate" as your "external crystal speed". The smiley was to indicate I felt is was just an oversight on your part, something that I've been known to have done on quite a few occasions myself! I'm sorry you mistook it as an insult, but as such a can see your need to respond in an insulting manner. No problem! Assuming the original *was* meant as an insult I'd respond the same way! :-) <-- note smiley. I don't believe my original response shows a lack of knowledge on the MSP430, though I have not had the opportunity to use it in a project. The MSP430 series has a very flexible clock module with a nice thing they call a Frequency Locked Loop (FLL) but you did not indicate "crystal speed" in your original post, but instead quoted a clock rate figure. Using a x32 multiplier on a 32.768khz crystal (or something similar like I assumed you meant) does not give a clock rate of 32.768khz, but instead a clock rate of 1.048576 MHz (this example is from the datesheet), with a large enough multiplier you can indeed achieve a clock rate that would allow enough MCU clocks to support a 50khz sample rate, based on an external 32.768khz crystal. You specified you could sample at 50khz, using a 32.768khz clock rate, not a 1.04mhz clock rate (or whatever clock rate achieved by the programming of your FLL). Obviously at one cycle per instruction, using clock rate of 32.768khz would only allow a 32.768khz sample rate assuming you could write your whole program in one instruction. If your clock rate was referring to the external crystal frequency, why stop at 32.768khz? Why not claim you can do it with a "0hz clock rate", since the PIC, and MSP430 along with other MCUs like the AVR, can all run with no external clock at all using an internally generated R/C clock? I'm certain you do not mean to imply in your above paragraph that you can achieve a 50khz sample rate running a PIC on a 32.768khz crystal, simply because an ADC sample can be done asynchronously to the MCU clock. My assumption is that you know that while some of the newer PICs may allow a x4 clock multiplier, using a Phase Lock Loop, their internal sysclock is generated by dividing the external oscillator by 4, leaving you with a 32.76khz MCU clock rate. This assumes you could even use the x4 PLL on the low speed clock, the datasheets seem to claim this can only be done on the high speed (1-10mhz) external clocks. The PICs have no where near the versatility in their clock generation as the MSP430 does. -Zonn