Post by thread:[PIC]: Crystals

Dear all, I'm using a PIC16F877 for analog-digital conversion and datalogging. I sample at only 16 Hz, and because there is a limit in the number of subdivisions of the clock frequency, this requires a 32kHz crystal. However, to run the PIC at this frequency would be a waste, so I also have a 10MHz crystal for the main clock. Having two crystals seems to me rather messy, especially as size is important (I know watch crystals are quite small, but nevertheless they have an appreciable thickness, which I am trying to keep down to 1-2 mm) - also it's one more component that could fail, especially as my circuit is subject to cyclical loaidng. Can anyone suggest a way round this problem? Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: spam_OUTkirtleyTakeThisOuTcua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to .....listprocKILLspam@spam@info.curtin.edu.au -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

Hello Chris, i don't think you need 2 crystals, you just need more creative ways of wasting time with one crystal. for example, figure out the exact number of cycles that it takes to process one sample compleyely, then set up a nested set of loops that will waste cycles until the total is 1/16 second. then do that 15 more times. you can even sleep the chip in little chunks of time, using the option register prescaler, the little chunks would be easier to count than a bazillion cycles. i dont consider running an f877 at 32kHz a waste, i consider it a lesson in humility for the mighty pic. alice {Quote hidden}> Dear all, > > I'm using a PIC16F877 for analog-digital conversion and datalogging. > > I sample at only 16 Hz, and because there is a limit in the number of > subdivisions of the clock frequency, this requires a 32kHz crystal. > However, to run the PIC at this frequency would be a waste, so I also > have a 10MHz crystal for the main clock. > > Having two crystals seems to me rather messy, especially as size is > important (I know watch crystals are quite small, but nevertheless they > have an appreciable thickness, which I am trying to keep down to 1-2 mm) > - also it's one more component that could fail, especially as my circuit > is subject to cyclical loaidng. > > Can anyone suggest a way round this problem? > -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

On Wed, 4 Oct 2000, Dr. Chris Kirtley wrote: {Quote hidden}> Dear all, > > I'm using a PIC16F877 for analog-digital conversion and datalogging. > > I sample at only 16 Hz, and because there is a limit in the number of > subdivisions of the clock frequency, this requires a 32kHz crystal. > However, to run the PIC at this frequency would be a waste, so I also > have a 10MHz crystal for the main clock. > > Having two crystals seems to me rather messy, especially as size is > important (I know watch crystals are quite small, but nevertheless they > have an appreciable thickness, which I am trying to keep down to 1-2 mm) > - also it's one more component that could fail, especially as my circuit > is subject to cyclical loaidng. > > Can anyone suggest a way round this problem? > > Chris > > -- > Dr. Chris Kirtley MD PhD > Associate Professor > HomeCare Technologies for the 21st Century (Whitaker Foundation) > NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation > Dept. of Biomedical Engineering, Pangborn 105B > Catholic University of America > 620 Michigan Ave NE > Washington, DC 20064 > Tel. 202-319-6247, fax 202-319-4287 > Email: kirtleyKILLspamcua.edu > http://engineering.cua.edu/biomedical > > Clinical Gait Analysis: http://guardian.curtin.edu.au/cga > Send subscribe/unsubscribe to .....listprocKILLspam.....info.curtin.edu.au > Do you mean the counters provide an interrupt at too fast a rate when run at 10MHz? If so, you can just have your own counter, in software, that is incremented each time you get a timer interrupt. When you have the correct number of timer interrupts you then take your measurement. You can adjust your timer interrupts to give you very good accuracy. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

Alice Campbell wrote: > > Hello Chris, > i don't think you need 2 crystals, you just need more > creative ways of wasting time with one crystal. > for example, figure out the exact number of cycles that it > takes to process one sample compleyely, then set up a nested > set of loops that will waste cycles until the total is > 1/16 second. then do that 15 more times. > > you can even sleep the chip in little chunks of time, using > the option register prescaler, the little chunks would be > easier to count than a bazillion cycles. > > i dont consider running an f877 at 32kHz a waste, i consider > it a lesson in humility for the mighty pic. Not to mention the power you'd save by running a slow clock. The slower your base clock rate, the less power the PIC draws. It sounds to me like you're doing a data logging app. Why not use a 'nice' crystal rate like 1.8432Mhz, which still lets you get high baud rates easily, while saving a substantial amount of power over 16Mhz? Robert -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's

Dear Alice/Patrick/Robert and others interested, Thanks for your replies about using two crystals. I showed them to my friend who is advising me on the circuit, and here's what he says: The replies are quite valid, but have you asked the whole question ? I think correct answer is one that you are trying to avoid. i.e. YOU need to calculate/work-out/measure the amount of processing that is required per sample/frame/second. What ever this value is, it should give you an indication of the minimum overall clock speed required. (I am guessing but ... I guess less than 10MHz and more than 32kHz). It is true that you can use one(high frequency) crystal and divide-down the clock rate to get required sampling rate, but in doing so you need to keep significant portions of the PIC in an awake state and operating at the high clock rate ( and hence relatively high power consumption). So YOU have to balance the cost penalties of an extra crytal against the extra battery volume required to operate at the high clock rate. Keep in mind that the manufacturers of the 32kHz crystals will have spent a great deal of effort in designing crystals which operate stably under very, very low power conditions. I'd be interested in your further comments. TIA! Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: EraseMEkirtleyspam_OUTTakeThisOuTcua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to listprocspam_OUTinfo.curtin.edu.au -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Ok, the reason you received all those replies earlier suggesting the use of only one crystal is that you did not specify that you needed very low power. It is messy using two crystals, and I cannot think of a simple way to connect two crystals to the PIC without external logic or other discrete parts. For us to effectively help you, we need to know more details about your project. Do you need the full 16MHz speed? What are your real power requirments? Could you perhaps use a PIC with a timer and interrupt capability? Set the timer to overflow at the rate you need to make readings, and go to sleep. The timer will wake you up, you can take your reading, and go back to sleep. What kind of data are you collecting, what processing needs to be done, and are what are you doing with the processed data and when? You can do a lot with a microcontroller that executes 8,000 instructions per second. You also mention size limitations. Can you be more specific? There are a lot of solutions to your problem, but we can eliminate those that don't fit the bill if you can give us more detailed information. -Adam "Dr. Chris Kirtley" wrote: {Quote hidden}> > Dear Alice/Patrick/Robert and others interested, > > Thanks for your replies about using two crystals. I showed them to my > friend who is advising me on the circuit, and here's what he says: > > The replies are quite valid, but have you asked the whole question ? > I think correct answer is one that you are trying to avoid. i.e. YOU > need > to calculate/work-out/measure the amount of processing that is required > per sample/frame/second. What ever this value is, it should give you an > > indication of the minimum overall clock speed required. (I am guessing > but ... I guess less than 10MHz and more than 32kHz). > > It is true that you can use one(high frequency) crystal and divide-down > the clock rate to get required sampling rate, but in doing so you need > to > keep significant portions of the PIC in an awake state and operating at > the high clock rate ( and hence relatively high power consumption). So > YOU have to balance the cost penalties of an extra crytal against the > extra battery volume required to operate at the high clock rate. Keep > in > mind that the manufacturers of the 32kHz crystals will have spent a > great > deal of effort in designing crystals which operate stably under very, > very low power conditions. > > I'd be interested in your further comments. > > TIA! > > Chris > -- > Dr. Chris Kirtley MD PhD > Associate Professor > HomeCare Technologies for the 21st Century (Whitaker Foundation) > NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation > Dept. of Biomedical Engineering, Pangborn 105B > Catholic University of America > 620 Michigan Ave NE > Washington, DC 20064 > Tel. 202-319-6247, fax 202-319-4287 > Email: @spam@kirtleyKILLspamcua.edu > http://engineering.cua.edu/biomedical > > Clinical Gait Analysis: http://guardian.curtin.edu.au/cga > Send subscribe/unsubscribe to KILLspamlistprocKILLspaminfo.curtin.edu.au > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Are you sure you need ANY crystals? The RC oscillator is the lowest-power option for just about any microcontroller chip. You might want to put a 32KHz crystal on the Timer1 oscillator, keep the PIC asleep most of the time waiting on Timer1 interrupt (not super-low-power, around 50 microamps usually), and let the PIC itself run on the RC oscillator when awake. Then you could have a pretty accurate timebase from the watch crystal (cheap ones are 20ppm in a wristwatch which stays close to body temperature, but nearly as good over industrial temp range), and then run the PIC at whatever speed it needs to get its work done in time. On the RC oscillator a PIC wakes up very quickly, not having to wait for a crystal oscillator to start up (often several milliseconds). > {Original Message removed}

Dear Adam, others, Thanks for your interest in my question. I am doing the following with the PIC: 1. Reads from up to 8 channels of ADC at a sampling rate of 16Hz 2. Stores the data in EEPROM 3. Reads the data from EEPROM and outputs it to an RF telemetry tramsmitter when it detects it is in range of the receiver 4. Sleeps in between samples The size requirement is bascially an inch (25-30 mm) square or so. But I would like to keep the thickness down to the thickness of the PCB, PIC and EEPROMs (about 3 mm). I'd also like to keep the component count as low as possible to increase reliability asthe board will be subjected to cyclical loading. Also keep the power consumption as low as possible (the RF takes 7 mA and some of the sensors about the same, so these need to to be turned off when they are not active) to run from a lithium button cell (about 30mAh) for a day or so. Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: RemoveMEkirtleyTakeThisOuTcua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to spamBeGonelistprocspamBeGoneinfo.curtin.edu.au -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Chris Kirtley wrote: ........ >The replies are quite valid, but have you asked the whole question ? >I think correct answer is one that you are trying to avoid. i.e. YOU >need >to calculate/work-out/measure the amount of processing that is required >per sample/frame/second. What ever this value is, it should give you an > >indication of the minimum overall clock speed required. (I am guessing >but ... I guess less than 10MHz and more than 32kHz). ....... > Hi Chris, To give you rough estimate of power reqs, which may be appropos to your project, I designed/built a datalogger a couple of years ago that used a PIC71, 32Khz xtal, and ran off 2 Li cells in series feeding an LM2936 low-power v.reg. It also had a specially-designed magnetic pickup amp. Total current draw was about 50 uA, and I estimated it would run for about 1 year off the Li cells [~500 mAH]. LM2936 v.reg ~15 uA PIC71 @ 32Khz ~15 uA RS232 - zero quiescent current design CMOS opamps & EEPROM - powered off between reads magnetic pickup amp ~10 uA If you went to say a 200 Khz xtal, as a power-vs-performance tradeoff to get 6X more crunch power, power reqs would be roughly 6X greater, and it would run for about 2 months. Alternately, if you go to a 32Khz sleep-mode with 10Mhz run-mode, you have to weight-average the power reqs, and the battery life scales accordingly. This should give you some idea what is do-able. Get that current draw down. [note - I still think I would hang the uC on the front of the shoe, but ........... <-- couldn't resist]. best regards, - Dan Michaels Oricom Technologies http://www.users.uswest.net/~oricom =================================== -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

well, lets see: assume 32768/4 instructions per second..0.000122 each 1/16 second= 0.0625 so you need to use up 512 clock ticks between measurements. the sleep prescaler can give you sleeps of 3.2 sec/128=.025 sec, or 204 instructions. so now we really need to know how many cycles your measure- and-stuff routine takes, because we can either sleep twice and then measure-and-stuff, then ditch the few odd cycles left, or we might be able to only sleep once, and ditch rather more leftover cycles. say a measure-and-stuff cycle is 100 instructions. now you need to dump 412 instructions, two sleeps, and lose the odd 4 cycles to nops, and you're there. a longer measurement cycle would mean you can only afford one sleep, and hum for the rest of the time. now if your measurement cycle is over 512 clock ticks, youre stuck. you cant use the watch crystal. but i bet you can cram it all in and still get a nap. alice {Quote hidden}> Dear Alice/Patrick/Robert and others interested, > > Thanks for your replies about using two crystals. I showed them to my > friend who is advising me on the circuit, and here's what he says: > > The replies are quite valid, but have you asked the whole question ? > I think correct answer is one that you are trying to avoid. i.e. YOU > need > to calculate/work-out/measure the amount of processing that is required > per sample/frame/second. What ever this value is, it should give you an > > indication of the minimum overall clock speed required. (I am guessing > but ... I guess less than 10MHz and more than 32kHz). > > It is true that you can use one(high frequency) crystal and divide-down > the clock rate to get required sampling rate, but in doing so you need > to > keep significant portions of the PIC in an awake state and operating at > the high clock rate ( and hence relatively high power consumption). So > YOU have to balance the cost penalties of an extra crytal against the > extra battery volume required to operate at the high clock rate. Keep > in > mind that the manufacturers of the 32kHz crystals will have spent a > great > deal of effort in designing crystals which operate stably under very, > very low power conditions. > > I'd be interested in your further comments. > -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Since you are doing very little or no data processing, and you are doing RF telemetry, then I don't see a need for a crystal faster than 32kHz. The only thing you might need to worry about is data transfer speed. Depending on the amount of data you need to transfer, I suspect you could do with the 2000bps you can get with a 32kHz crystal. If you have a lot of data (more than a KB or so) then you'll need to speed up the microcontroller during data transmission. I suspect that Don's suggestion (crystal on the timer, RC for the main clock) will be the lowest power, but your receiver will have to deal with a serial stream that varies in speed by 10-20%. (If this is something someone wears, the speed should be fairly constant). This isn't trivial but it isn't too difficult either. I suspect also that you could, with a few surface mount components, manage two crystals if absolutely needed. -Adam "Dr. Chris Kirtley" wrote: {Quote hidden}> > Dear Adam, others, > > Thanks for your interest in my question. I am doing the following with > the PIC: > > 1. Reads from up to 8 channels of ADC at a sampling rate of 16Hz > 2. Stores the data in EEPROM > 3. Reads the data from EEPROM and outputs it to an RF telemetry > tramsmitter when it detects it is in range of the receiver > 4. Sleeps in between samples > > The size requirement is bascially an inch (25-30 mm) square or so. But I > would like to keep the thickness down to the thickness of the PCB, PIC > and EEPROMs (about 3 mm). I'd also like to keep the component count as > low as possible to increase reliability asthe board will be subjected to > cyclical loading. Also keep the power consumption as low as possible > (the RF takes 7 mA and some of the sensors about the same, so these need > to to be turned off when they are not active) to run from a lithium > button cell (about 30mAh) for a day or so. > > Chris > -- > Dr. Chris Kirtley MD PhD > Associate Professor > HomeCare Technologies for the 21st Century (Whitaker Foundation) > NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation > Dept. of Biomedical Engineering, Pangborn 105B > Catholic University of America > 620 Michigan Ave NE > Washington, DC 20064 > Tel. 202-319-6247, fax 202-319-4287 > Email: TakeThisOuTkirtleyEraseMEspam_OUTcua.edu > http://engineering.cua.edu/biomedical > > Clinical Gait Analysis: http://guardian.curtin.edu.au/cga > Send subscribe/unsubscribe to RemoveMElistprocTakeThisOuTinfo.curtin.edu.au > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Dear Adam and others, Yes - I think you've hit the nail on the head. Sorry about this - I'm sort of learning as I go because my friend designed the circuit and although he explained why we needed to do it this way, I guess I hadn't fully understood. The telemetry has to be very preceise because it is one-way (there's no way of making sure that the data has been received correctly). So I guess that makes an RC clock rather risky, hence the reason for using a watch crystal at 32kHz. Equally, though, as you rightly point out, we need a high clock speed to download the data as quickly as possible - well I assume we do. The bandwith of the transmitter (Linx LC) is 5kHz, so I suppose that allows only 6 clock cycles between each bit. The transmission is actually done by the on-board UART, but this still would not leave enough clock cycles to do the rest of teh stuff, I guess. Tell me if my reasoning is incorrect - I'm learning - slowly, I know :-) Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: kirtleyEraseME.....cua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to EraseMElistprocinfo.curtin.edu.au -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Sorry - I just realised that message was a bit misleading, too! The watch crystal is on the ADC sampling (timer1), while the main clock is presently a 10MHz crystal. Replacing the latter by an RC oscillator might compromise the telemetry. Duh... is that clear(er)? Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: RemoveMEkirtleyEraseMEEraseMEcua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to RemoveMElistprocspam_OUTKILLspaminfo.curtin.edu.au -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Ok, so the only reason you have a faster clock is for transmitting data via the UART. The fastest standard rate UART can send (limited by the transmitter) is 4800bps. This will enable you to send 480 bytes per second. (given 8 bits, a start bit and a stop bit) To obtain 4800 bps via the UART, you would need a crystal of 76.8kHz (minimum). I see DigiKey has four different 76.8kHz crystals available, two surface mount, a can, and a dip. Now, you could just use a 76.8kHz crystal and do away with the 32kHz. I am certian you can get your design to work well with a combination of interrupts based on the timer, taken from the main clock, and I'm almost certian that you'll use less energy running one clock at 76.8kHz than running that and another crystal. -Adam "Dr. Chris Kirtley" wrote: {Quote hidden}> > Sorry - I just realised that message was a bit misleading, too! > > The watch crystal is on the ADC sampling (timer1), while the main clock > is presently a 10MHz crystal. Replacing the latter by an RC oscillator > might compromise the telemetry. > > Duh... is that clear(er)? > > Chris > > -- > Dr. Chris Kirtley MD PhD > Associate Professor > HomeCare Technologies for the 21st Century (Whitaker Foundation) > NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation > Dept. of Biomedical Engineering, Pangborn 105B > Catholic University of America > 620 Michigan Ave NE > Washington, DC 20064 > Tel. 202-319-6247, fax 202-319-4287 > Email: RemoveMEkirtleyTakeThisOuTspamcua.edu > http://engineering.cua.edu/biomedical > > Clinical Gait Analysis: http://guardian.curtin.edu.au/cga > Send subscribe/unsubscribe to EraseMElistprocspamspamBeGoneinfo.curtin.edu.au > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Chris Kirtley wrote: ......... Equally, though, as you rightly point out, we >need a high clock speed to download the data as quickly as possible - >well I assume we do. The bandwith of the transmitter (Linx LC) is 5kHz, >so I suppose that allows only 6 clock cycles between each bit. The >transmission is actually done by the on-board UART, but this still would >not leave enough clock cycles to do the rest of teh stuff, I guess. Tell >me if my reasoning is incorrect - I'm learning - slowly, I know :-) > Just a point of information [to help clog the ole memory banks] - when running a PIC off a 32 Khz xtal, you can just barely get it to clock RS-232 at 1200 baud, if the uart is done in s.w. -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Dear Rob, (should I change the subject heading now?) Does your MPS430 also have 8 channels of ADC and a UART? Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: RemoveMEkirtleyKILLspamcua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to listprocSTOPspamspam_OUTinfo.curtin.edu.au -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Dear all, Thanks for all these suggestions - I hope I'm not hogging the list. A question crosses my mind - what would use least power: 1. Running a PIC at a high clock speed for short bursts and sleeping in between; or 2. Running at a slow speed almost constantly (no time left for sleeping)? Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: spamBeGonekirtleySTOPspamEraseMEcua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to KILLspamlistprocspamBeGoneinfo.curtin.edu.au -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Just solve two equations: 10MHZ_amphours = (Operating_power_used * time_running_@_10_MHz + startup_overhead_@_10 MHz) + (sleep_power_used * time_sleeping) 32KHZ_amphours = (Operating_power_used * time_running_@_32kHz) + (sleep_power_used * time_sleeping) Now, which is smaller? There's the answer. I believe you should be able to get all this data from your data sheets and from previous replies. Andy "Dr. Chris Kirtley" <EraseMEkirtleyEraseMECUA.EDU> on 10/05/2000 03:28:18 PM Please respond to pic microcontroller discussion list <@spam@PICLIST@spam@spam_OUTMITVMA.MIT.EDU> To: spamBeGonePICLISTKILLspamMITVMA.MIT.EDU cc: (bcc: Andrew Kunz/TDI_NOTES) Subject: Re: [PIC]: Crystals Dear all, Thanks for all these suggestions - I hope I'm not hogging the list. A question crosses my mind - what would use least power: 1. Running a PIC at a high clock speed for short bursts and sleeping in between; or 2. Running at a slow speed almost constantly (no time left for sleeping)? Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: .....kirtleyspam_OUTcua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to TakeThisOuTlistproc.....TakeThisOuTinfo.curtin.edu.au -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

I left out a few words which might have made that post more confusing, so I'll restate a portion: Your radio transmitter, you indicated, has a bandwidth of 5kHz. Thus, the fastest standard rate the UART could send over that link would be 4800. You could use the bandwidth at exactly 5000, or even push it past, but I think you'll be better off sticking with a standard 4800. This lends itself to using a 76800 Hz crystal, which, on the 16F877 with baud rate generator set to high and SPBRG set to 0, will give you exactly 4800 bps. This is twice as fast as the 32kHz crystal, but less hassle, and possible less power consumption than using two crystals. As far as your two questions (running fast and sleeping, and running slow constantly) the PIC is a static CMOS device. Thus, each time a gate changes state the chip consumes a specific amount of power. Whether you complete 100 cycles in 1ms and rest or 100 cyles each second makes little difference on the power consumption. At that point you need to look at the consumption of the various oscillators you have running, and other peripherals. -Adam "M. Adam Davis" wrote: {Quote hidden}> > Ok, so the only reason you have a faster clock is for transmitting data via the > UART. The fastest standard rate UART can send (limited by the transmitter) is > 4800bps. This will enable you to send 480 bytes per second. (given 8 bits, a > start bit and a stop bit) > > To obtain 4800 bps via the UART, you would need a crystal of 76.8kHz (minimum). > I see DigiKey has four different 76.8kHz crystals available, two surface mount, > a can, and a dip. > > Now, you could just use a 76.8kHz crystal and do away with the 32kHz. I am > certian you can get your design to work well with a combination of interrupts > based on the timer, taken from the main clock, and I'm almost certian that > you'll use less energy running one clock at 76.8kHz than running that and > another crystal. > > -Adam > > "Dr. Chris Kirtley" wrote: > > > > Sorry - I just realised that message was a bit misleading, too! > > > > The watch crystal is on the ADC sampling (timer1), while the main clock > > is presently a 10MHz crystal. Replacing the latter by an RC oscillator > > might compromise the telemetry. > > > > Duh... is that clear(er)? > > > > Chris > > > > -- > > Dr. Chris Kirtley MD PhD > > Associate Professor > > HomeCare Technologies for the 21st Century (Whitaker Foundation) > > NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation > > Dept. of Biomedical Engineering, Pangborn 105B > > Catholic University of America > > 620 Michigan Ave NE > > Washington, DC 20064 > > Tel. 202-319-6247, fax 202-319-4287 > > Email: TakeThisOuTkirtleyKILLspamspamcua.edu > > http://engineering.cua.edu/biomedical > > > > Clinical Gait Analysis: http://guardian.curtin.edu.au/cga > > Send subscribe/unsubscribe to .....listprocRemoveMEinfo.curtin.edu.au > > > > -- > > http://www.piclist.com hint: The list server can filter out subtopics > > (like ads or off topics) for you. See http://www.piclist.com/#topics > > -- > http://www.piclist.com hint: The list server can filter out subtopics > (like ads or off topics) for you. See http://www.piclist.com/#topics -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

Dear Steve, Well, I confess I haven't tackled this problem yet (I have more pressing matters), but I guess I will have to transmit a unique address with the data. I don't think I'd need to do this with every byte - I could send it occasionally. Also, although I also haven't started work on this yet either - there will be some sort of return transmission (probably a simple inductive loop, or possibly an RFID tag) to let the tramsmitter know it is within range - I could arrange for this to be turned off (or toggled) when another device appears. I don't anticipate this will happen anyway for the moment - this is a research project, after all, and only one device exists at present! Does that satisfy you? Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: RemoveMEkirtleyspamBeGonecua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to spamBeGonelistproc@spam@spam_OUTinfo.curtin.edu.au -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

It's pretty much of a wash power-wise. PIC's, like most CMOS devices use very little power to maintain a state, most of the power consumed being needed to charge and discharge the stray capacitance of the internal circuits. That means that the power consumed per clock cycle is about the same regardless of the clock rate. There is some power consumed by leakage, which is constant regardless of the clock rate, and I think that in sleep mode some circuitry that consumes leakage current is shut down, so that sleeping takes a little less energy than staying awake. On the other hand, it usually takes some housekeeping to enter/leave sleep mode, which consumes extra cycles. One of the most significant is the time it takes to start up a crystal oscillator. This is one reason the RC oscillator saves power. Faster crystal oscillators take more power. This is why the PIC has the HS oscillator mode. In HS mode, it uses more power because it takes more power to drive a faster crystal. You might consider a ceramic resonator rather than a crystal. They are smaller, cheaper, and I think they start up faster and need less power to drive them. They are not as accurate as a crystal, but still plenty accurate enough to keep your baud rate within UART specs. Actually, the total baud-rate error budget with UARTS is about +-5%, so if your receiver uses a crystal with something like .002% accuracy (20 ppm), then you can use essentially all that error budget in your transmitter. 5% accuracy is not impossible to achieve with an RC oscillator if you have a tweaker on it, especially if, as I suspect, this is a device intended to be worn on a human body so that it would be reasonable to assume a temperature range much smaller than -40C to 85C industrial. By the way -- does the radio have a crystal? At 7 mA, which implies maybe 5 mW output, it might not be required to have that accurate a carrier frequency, but if it does, then that could wind you up with 3 crystals on your tiny little board. > {Original Message removed}

With multiple transmitters, you basically have an Aloha protocol (like ethernet). In any RF transmission, you MUST assume that some of your messages will be garbled. The world is very full of RF noise sources. RF data transmissions usually occur in blocks, with a header containing ID information, and a checksum so that scrambled data can be detected and discarded. Sometimes sophisticated error-correction algorithms are used, but it is easier to just use a CRC (which is a good checksum), and transmit the data more than once. My company sells radios, and gives away an Aloha calculator program that can be used to determine the probability of getting a message through, give a number of repetitions, length of message, how often messages are sent, how many transmitters are on the air, and the noise level. Contact me off-list, and I'll see if I can send you a copy of the program. > {Original Message removed}

> The watch crystal is on the ADC sampling (timer1), while the main clock > is presently a 10MHz crystal. Replacing the latter by an RC oscillator > might compromise the telemetry. The separate oscillator on the A/D is for timing the individual bit conversions. This can also be derived from the main clock, or an internal RC oscillator. In either case, the A/D oscillator isn't much good for overall program loop timing and the like. The best thing for that is to use the main clock and any of the various timer/counters. Keep in mind that the A/D precharge timing must be done somehow by the software. The A/D oscillator will not help with this. The main purpose of the A/D oscillator is so that the A/D can run while the rest of the processor is in sleep. It generally doesn't need to be that accurate unless you are trying to clock the A/D exactly at its maximum rate. At 16 samples/second, this should not be an issue. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, TakeThisOuTolinspamcognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

The telemetry has to be very preceise because it is one-way (there's no way of making sure that the data has been received correctly). So I guess that makes an RC clock rather risky, hence the reason for using a watch crystal at 32kHz. The TI MSP430 takes an interesting compromise to this tradeoff. The CPU clock comes off of an RC circuit, but a crystal oscillator is also included, and accuracy-critical stuff (like the timer, semi-software uart, etc) operates off of the crystal oscillator clock instead of the CPU clock. It might be possible to implement something similar with a PIC. An RC clock circuit would seem to be much more easilly adapatable to speed-switching, as well. What portion of PIC power consumption is the crystal oscillator, anyway? (ie how much power do you save using RC at 1MHz vs a crystal?) BillW -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

"Dr. Chris Kirtley" wrote: > > The telemetry has to be very preceise because it is one-way (there's no > way of making sure that the data has been received correctly). So I So add some FEC bytes (forward error correction). With a little bit of computation this allows you to send your data and reconstruct any missing bits on the rx side. Or you could send it twice with a simple checksum or CRC to confirm that the packet was received correctly. > guess that makes an RC clock rather risky, hence the reason for using a > watch crystal at 32kHz. Equally, though, as you rightly point out, we > need a high clock speed to download the data as quickly as possible - > well I assume we do. The bandwith of the transmitter (Linx LC) is 5kHz, > so I suppose that allows only 6 clock cycles between each bit. The > transmission is actually done by the on-board UART, but this still would > not leave enough clock cycles to do the rest of teh stuff, I guess. Tell > me if my reasoning is incorrect - I'm learning - slowly, I know :-) The UART runs by itself. You can be collecting your next data bytes while the UART is shifting out your data. You'll need to run the A/D in 'RC' mode, if you use the suggested low crystal rates (it's in the specs). If you use a 200Khz resonator, you'll probably have the best compromise between cost/speed/power. From the sounds of it your transmitter is the major power consumer. Would it make sense for you to buffer your low speed data for several steps and then fire up the transmitter to send a bigger packet of data? I also agree with the suggestion about putting the PIC on the shoe, and just the sensor in the sole. Then your weight/thickness is much less of an issue. Robert -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics

> Just a point of information [to help clog the ole memory banks] > - when running a PIC off a 32 Khz xtal, you can just barely get it > to clock RS-232 at 1200 baud, if the uart is done in s.w. You should be able to do better than that, for transmitting at least. The original question was about a one-way link, so this is appropriate in this case. I did a 9600 baud software UART using a 160 KHz oscillator once. This is equivalent to 2400 baud with 40 KHz oscillator. If I remember right (I'm not in my office right now where the code is), the minimum requirement was 3 instructions per bit. 32 KHz oscillator means 8 KHz instructions, implying 2.67 Kbaud max. Therefore it is possible to do a 2400 baud software UART with a 32 KHz oscillator. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, olinEraseMEcognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> A question crosses my mind - what would use least power: > > 1. Running a PIC at a high clock speed for short bursts and sleeping in > between; or > 2. Running at a slow speed almost constantly (no time left for > sleeping)? The latter if clock rate is just enough to do the job. This is because it takes time and therefore wasted current to start up the main oscillator, especially if it is a crystal. There are several startup delays, including a deliberate 1024 cycle delay to make sure the crystal oscillator is stable. In other words, waking up from sleep takes power. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, RemoveMEolinEraseMEspam_OUTcognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Hi, I have just done almost exactly what you want to do. I used a PIC16F876 with a 32.768kHz crystal on TMR1 to wake it up from sleep every 2,4,8 or 16 seconds. The main crystal is 1.8432MHz which gives OK processing speed, correct baud rates and fairly low power dissipation. I send the data over a FM transmitter every 15 minutes, 2400 baud, using a 16 bit checksum on each packet, and the packet is repeated 4 times with a random time period betweeen each packet. There is nothing wrong about using two crystals. It's also OK waking up for a few milliseconds every now and then and going back to sleep if its not time for the next conversion/transmission. Do the maths to find out the average power consumed. I know you want to save space also, so as I see it the next best alternative is to use just a 1.8432MHz main crystal. I think a 32kHz operaing speed may be OK for your ADC and processing but would be too restricting on your baud rate. If anyone knows of a two speed crystal switchable by a port pin - now is the time to speak up. Brent Brown Electronic Design Solutions 16 English Street Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/text: 025 334 069 eMail: @spam@brent.brownRemoveMEEraseMEclear.net.nz -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Olin wrote: >> Just a point of information [to help clog the ole memory banks] >> - when running a PIC off a 32 Khz xtal, you can just barely get it >> to clock RS-232 at 1200 baud, if the uart is done in s.w. > >You should be able to do better than that, for transmitting at least. The >original question was about a one-way link, so this is appropriate in this >case. > >I did a 9600 baud software UART using a 160 KHz oscillator once. This is >equivalent to 2400 baud with 40 KHz oscillator. If I remember right (I'm >not in my office right now where the code is), the minimum requirement was 3 >instructions per bit. 32 KHz oscillator means 8 KHz instructions, implying >2.67 Kbaud max. Therefore it is possible to do a 2400 baud software UART >with a 32 KHz oscillator. > You may be right - did it a good while ago. Could probably be done more efficiently. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Not original topic. Brent I would be interested to know what type of FM tx you used? Is there any info on the www. Thanks Jason >>> EraseMEbrent.brown@spam@CLEAR.NET.NZ 10/06/00 03:14pm >>> Hi, I have just done almost exactly what you want to do. I used a PIC16F876 with a 32.768kHz crystal on TMR1 to wake it up from sleep every 2,4,8 or 16 seconds. The main crystal is 1.8432MHz which gives OK processing speed, correct baud rates and fairly low power dissipation. I send the data over a FM transmitter every 15 minutes, 2400 baud, using a 16 bit checksum on each packet, and the packet is repeated 4 times with a random time period betweeen each packet. There is nothing wrong about using two crystals. It's also OK waking up for a few milliseconds every now and then and going back to sleep if its not time for the next conversion/transmission. Do the maths to find out the average power consumed. I know you want to save space also, so as I see it the next best alternative is to use just a 1.8432MHz main crystal. I think a 32kHz operaing speed may be OK for your ADC and processing but would be too restricting on your baud rate. If anyone knows of a two speed crystal switchable by a port pin - now is the time to speak up. Brent Brown Electronic Design Solutions 16 English Street Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/text: 025 334 069 eMail: @spam@brent.brownspam_OUT.....clear.net.nz -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> Not original topic. > > Brent I would be interested to know what type of FM tx you used? > Is there any info on the www. Jason, the transmitters and receivers were designed and built by a third party specifically for my client. He couldn't find anything off the shelf that met his specs so he had something made. If it comes about that he wants to make these available for sale then for sure I'll pass on the info to the PIC list, as I know these things are of interest to many. Brent Brown Electronic Design Solutions 16 English Street Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/text: 025 334 069 eMail: spamBeGonebrent.brownEraseMEclear.net.nz -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Dennis wrote: > Nasty stuff using a second xtal to do the wakeup. What do you do if the > second xtal fails? > This method has been used often before, and more times than not it produces > troubles (I can think of a Sony micro that produced some problems with a > second low speed xtal and wakeup) No problems. If I only had one xtal and it failed then wouldn't that be just as big a problem? The 32kHz crystal on TMR1 runs all the time, so startup isn't an issue, great for low power timekeeping. Startup time of the main xtal may be a consideration, but thats not always a problem either. I still think it's a great idea and I wish more micros had this ability (I think some of the AVRs have it). I'd be interested to hear more about the possible problems. I used the same scheme with a PIC16C63, 32kHz xtal on TMR1 and 4MHz ceramic resonator for the main oscillator, and it has been very reliable. These units work in the great outdoors hanging on an electric fence, which is kind of a noisy environment with big temperature extremes. TMR1 generated an interrupt and wake up from sleep every 2 secs which incremented a software real time clock and checked if scheduled events should be executed. Even retained the use of the watchdog timer while awake. Small problem in cold temps when the WDT period drifts below the 2 sec sleep time, but in that case it only causes a wake up from sleep which can be differentiated in software and ignored. Brent Brown Electronic Design Solutions 16 English Street Hamilton, New Zealand Ph/fax: +64 7 849 0069 Mobile/text: 025 334 069 eMail: brent.brownspamBeGoneclear.net.nz -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Hi, may be the new 18Cxx2 its the solution. You can configure the source of system clock to be comming either from the main oscilator like you normal know from 16C74 or switch it to second source on TMR1. This nice feature would be the best one for this application. You configure the MCU to start with internal RC oscilator, then start the TMR1 oscilator with 32kHz and you can switch system clock between 32kHz or 4MHz. Also you can turn-off the watchdog by software in sleep. Andrej _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

>The watch crystal is on the ADC sampling (timer1), while the main clock >is presently a 10MHz crystal. Replacing the latter by an RC oscillator >might compromise the telemetry. This may be an off the wall thought, but you obviously need an oscillator for the transmitter somewhere. If the PIC clock were derived from this oscillator, then the receive could know the baud rate from the carrier frequency. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, RemoveMEolin@spam@spamBeGonecognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Dear all, Thanks very much indeed for all your advice about crystals (also telemetry). I'm tempted to go for the single 76.8kHz crystal solution. I've decided that the only way to settle the arguement about power consumption is to try it out on the bench. I notice that one company (ECS Inc. - p296 of the new DigiKey catalog) does sell a watch-crystal sized 1MHz crystal, but it costs $7! Anybody know of any other miniature crystals? Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: .....kirtley@spam@EraseMEcua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to .....listprocRemoveMEinfo.curtin.edu.au -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> Since you are doing very little or no data processing, and you are doing RF > telemetry, then I don't see a need for a crystal faster than 32kHz. > > The only thing you might need to worry about is data transfer speed. Depending > on the amount of data you need to transfer, I suspect you could do with the > 2000bps you can get with a 32kHz crystal. A big BUT: the slower the PIC, the longer it takes to read the sensors and to control the transmitter. And, the longer they are turned on, the bigger their timeslice of battery energy is. I had this happen to me once, where I went for 32khz to save power, and in the end *wasted* power. If your peripherials draw 20mA when turned on, and you turn them on once a second: each instruction cycle @32khz is equivalent to a continous draw of 2.5uA. Your C compiler wastes 10 instructions at function entry? 25uA more, thank you sir. If you can, go for a faster speed, or a two-speed solution. The PIC really doesn't draw so much, especially when you don't need exact time and can put it into watchdog-sleepmode between the RF packets. 455khz sounds good and crystals are available. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> The telemetry has to be very preceise because it is one-way (there's no > way of making sure that the data has been received correctly). So I > guess that makes an RC clock rather risky, hence the reason for using a > watch crystal at 32kHz. If your receiver has a better power source, you can let the sender run off RC-clock and big timing tolerance (if it helps you to save power), while the receiver can make use of its better resources and receive even the worst-case signal right. In the end it is OK, the receiver corrects what the sender messes up. Much like mobile phones, where the base station sends with high power to let the cheap mobile receiver see the signal. And on the other hand the base station has a very expensive and sensitive receiver to still receive the weak mobile tx. A similar tradeoff to minimize cost & weight. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Dear Marc, Yes, you're right. I'm going to go for a 10MHz RC oscillator for the main clock (for fast response on waking up from sleep) and 32kHz for the ADC sampling. Can you suggest what combination R & C to use for 10MHz? Chris -- Dr. Chris Kirtley MD PhD Associate Professor HomeCare Technologies for the 21st Century (Whitaker Foundation) NIDRR Rehabilitation Engineering Research Center on TeleRehabilitation Dept. of Biomedical Engineering, Pangborn 105B Catholic University of America 620 Michigan Ave NE Washington, DC 20064 Tel. 202-319-6247, fax 202-319-4287 Email: .....kirtleySTOPspam@spam@cua.edu http://engineering.cua.edu/biomedical Clinical Gait Analysis: http://guardian.curtin.edu.au/cga Send subscribe/unsubscribe to listprocEraseME@spam@info.curtin.edu.au -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> The telemetry has to be very preceise because it is one-way (there's no > way of making sure that the data has been received correctly). So I > guess that makes an RC clock rather risky, hence the reason for using a > watch crystal at 32kHz. you could use RC mode if you use a phase encoded signal. This has the advantage that the clock rate is included in the signal and can be recovered at the receiving end. This means that you do not need an accurate clock at the transmitting end. For an easy hardware way to do this at the receiving end look at application notes for the CD4046 PLL, but it would also be possible to do it in software. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use RemoveMElistservspamBeGonemitvma.mit.edu?bodyT%20PICList%20DIGEST

At 09:03 27/10/00 +0100, you wrote: Peter I get 2 posts for every message you send to the PICLIST. Peter >> The telemetry has to be very preceise because it is one-way (there's no >> way of making sure that the data has been received correctly). So I >> guess that makes an RC clock rather risky, hence the reason for using a >> watch crystal at 32kHz. > >you could use RC mode if you use a phase encoded signal. This has the advantage that the clock rate is included in the signal and can be recovered at the receiving end. This means that you do not need an accurate clock at the transmitting end. > >For an easy hardware way to do this at the receiving end look at application notes for the CD4046 PLL, but it would also be possible to do it in software. > >-- >http://www.piclist.com#nomail Going offline? Don't AutoReply us! >use spamBeGonelistservKILLspam@spam@mitvma.mit.edu?bodyT%20PICList%20DIGEST > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! use listservspam_OUT@spam@mitvma.mit.edu?body=SET%20PICList%20DIGEST