I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
once 5 seconds.
The PIC I plan to use is the low power 84 variant, running at 32 KHz,
if possible.
The two separate requirements are easy to implement on their own, it's
getting the PIC to implement them concurrently that I'm having trouble
with. I need to continue measuring the input frequency even while I am
transmitting the output message.
I'd appreciate it if anybody who has solved this type of problem, can
give me a few pointers as this type of task, measure an input and
transmit it must be quite common.
With the PIC running at 32KHz, it is only operating at 8K instructions
per second. Transmitting at 2400 baud, there is time for only 7
instructions per bit.
I been tossing ideas around for a number of months now with no real
solution comming forward. I could use 2 Pics, one to do the counting,
the other to do the transmitting, but then I might as well use a
faster crystal.
Are there other alternatives? I may be blinkered down a set path.
Any input would be great. Code fragments would be fantastic.
Thanks guys,
Peter.
--
_______________________________________________________________________
Peter Homann email: spam_OUTpeterhTakeThisOuTadacel.com.au Work : +61 3 9596-2991
Adacel Pty Ltd Fax : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
>I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
>and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
>once 5 seconds.
Peter, what's the six-byte message you send?
(I want to get a handle on the processing required to
create the message string.)
>
> Hi,
>
> I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> once 5 seconds.
>
> The PIC I plan to use is the low power 84 variant, running at 32 KHz,
> if possible.
>
> The two separate requirements are easy to implement on their own, it's
> getting the PIC to implement them concurrently that I'm having trouble
> with. I need to continue measuring the input frequency even while I am
> transmitting the output message.
>
> I'd appreciate it if anybody who has solved this type of problem, can
> give me a few pointers as this type of task, measure an input and
> transmit it must be quite common.
>
> With the PIC running at 32KHz, it is only operating at 8K instructions
> per second. Transmitting at 2400 baud, there is time for only 7
> instructions per bit.
>
> I been tossing ideas around for a number of months now with no real
> solution comming forward. I could use 2 Pics, one to do the counting,
> the other to do the transmitting, but then I might as well use a
> faster crystal.
>
> Are there other alternatives? I may be blinkered down a set path.
>
> Any input would be great. Code fragments would be fantastic.
>
> Thanks guys,
>
> Peter.
> --
> _______________________________________________________________________
> Peter Homann email: .....peterhKILLspam@spam@adacel.com.au Work : +61 3 9596-2991
> Adacel Pty Ltd Fax : +61 3 9596-2960
> 250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
Hi, I have been working on a system that counts pulses and pulse width
using the 84 .I use both the T0 clock and INT on portB0 to generate
ints.
If you set the ints up so that an int is generated on the rising edge of
portb0 and increment a counter every time an int is generated you can
count pulses. now if you also set the clock to generate an int at a set
duty cycle you can count the number of pulses on the portb0 pin within a
set time. all of this can be done in the background and due to the
nature of the ints it is also VERY presise.
>With the PIC running at 32KHz, it is only operating at 8K instructions
>per second. Transmitting at 2400 baud, there is time for only 7
>instructions per bit.
>I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
>and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
>once 5 seconds.
>
>The PIC I plan to use is the low power 84 variant, running at 32 KHz,
>if possible.
Peter, you don't indicate the accuracy with which you need
to measure the frequency...
However, with a 32.768 kHz clock (which is 8192 instructions
per second) a variation of one instruction in detecting the
edge of a 250 rpm signal will cause an error in the calculated
instantaneous frequency of 0.2 rpm.
Assuming you don't want your measurement to be much less
accurate than this, you must measure the edges of the input
signal to within an instruction time.
You can do this by setting up TMR0 as a free running timer
with no prescale, configuring RB0 as an interrupt, and
connecting your input signal to RB0.
On each rising edge you get an interrupt, and in your ISR
you capture TMR0.
You must handle overflow of TMR0 in your main line code.
You are now measuring your signal period, and thus your
signal frequency, as accurately as it is possible.
Ok, now to the output side of the equation...
I can solve your problem if I can change your requirements :-)
Use 300 baud instead of 2400 baud (which is barely possible
anyway).
At 300 baud you have just over 27 instructions per bit. The
ISR to capture TMR0 should be six instructions. This interrupt
can never occur more than once per character (indeed, can never
occur more than once per six byte transmission). Stretching
a single bit time by 20% will _probably_ be ok...
Don't forget to handle TMR0 overflow between each byte.
Robert Lunn wrote:
>
> >I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> >and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> >once 5 seconds.
>
> Peter, what's the six-byte message you send?
>
> (I want to get a handle on the processing required to
> create the message string.)
>
> ___Bob
Bob, you could try setting up an array of say 6 bytes in memory
where the first would be an STX byte the next four would be the ascii of
the 4 digit number and the last being EOT so a value 123 would be
<stx><0><1><2><3><eot> or in hex 033031323304 this way the stx will
indicate the start of the numeric string and the eot the end. the
receiving equipment would be able to take the val of the four digits
using an ascii to int conversion. if the interupt code updates the bytes
of the output string then all you have to do is just keep sending it out
every 5 seconds or so.
>>I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
>>and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
>>once 5 seconds.
>>
>>The PIC I plan to use is the low power 84 variant, running at 32 KHz,
>>if possible.
>
> On each rising edge you get an interrupt, and in your ISR
> you capture TMR0.
>
> At 300 baud you have just over 27 instructions per bit. The
> ISR to capture TMR0 should be six instructions.
I was a bit quite of the mark. The ISR _is_ six instructions,
but it executes in _seven_ cycles (because of the RETFI). Also,
there are two cycles spent getting into the ISR.
That's a total of NINE cycles.
This is a 30% error in bit timing. At 300 baud I still think
this will work (hopeful grin). And because the bit timing is
27.3 instructions rather than 27, you do make up a couple of
cycles if the interrupt occurs early in the transmitted byte.
>
> Peter Homann wrote:
> >
> > Hi,
> >
> > I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> > and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> > once 5 seconds.
> >
> > The PIC I plan to use is the low power 84 variant, running at 32 KHz,
> > if possible.
> >
> > The two separate requirements are easy to implement on their own, it's
> > getting the PIC to implement them concurrently that I'm having trouble
> > with. I need to continue measuring the input frequency even while I am
> > transmitting the output message.
> >
> > I'd appreciate it if anybody who has solved this type of problem, can
> > give me a few pointers as this type of task, measure an input and
> > transmit it must be quite common.
> >
> > With the PIC running at 32KHz, it is only operating at 8K instructions
> > per second. Transmitting at 2400 baud, there is time for only 7
> > instructions per bit.
> >
> > I been tossing ideas around for a number of months now with no real
> > solution comming forward. I could use 2 Pics, one to do the counting,
> > the other to do the transmitting, but then I might as well use a
> > faster crystal.
> >
> > Are there other alternatives? I may be blinkered down a set path.
> >
> > Any input would be great. Code fragments would be fantastic.
> >
> > Thanks guys,
> >
> > Peter.
> > --
> > _______________________________________________________________________> >
> > Adacel Pty Ltd Fax : +61 3 9596-2960
> > 250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
>
> Hi, I have been working on a system that counts pulses and pulse width
> using the 84 .I use both the T0 clock and INT on portB0 to generate
> ints.
> If you set the ints up so that an int is generated on the rising edge of
> portb0 and increment a counter every time an int is generated you can
> count pulses. now if you also set the clock to generate an int at a set
> duty cycle you can count the number of pulses on the portb0 pin within a
> set time. all of this can be done in the background and due to the
> nature of the ints it is also VERY presise.
>
> I hope this is of some use
>
> Peter........
I think Peter solution is good. In order to improve it you program the
interrupt to be generated in the rising edge and during the int you put
a timer running and program the int for the complementary edge (if it
was up edge turns to down edge and vice-versa), you can get know
information about dutty-cycle and frequency and you can estimate the
frequency with more precision.
Don't know why you need to use 32 kHz --- likely to save power.
One thought. You need a higher clock speed to transmit at 2400 baud. I
don't know if this would work, but you could have two external clocks
... one at 32 kHz and one at an appropriate higher rate for the 2400
baud stuff. Use a gate controlled by a pin on the PIC to switch clock
speeds to the higher one when you need to send the 6 bytes of data at
2400 baud, the switch back to the slower clock.
It would require some testing to see if the clock speed switch is
practicle or not.
>----------
>From: Peter Homann[SMTP:.....peterhKILLspam.....ADACEL.COM.AU]
>Sent: Tuesday, November 05, 1996 7:20 PM
>To: Multiple recipients of list PICLIST
>Subject: Concurrency Problem on a low power PIC 84
>
>Hi,
>
>I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
>and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
>once 5 seconds.
>
>The PIC I plan to use is the low power 84 variant, running at 32 KHz,
>if possible.
> (stuff deleted)
Robert Lunn wrote:
>
> >I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> >and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> >once 5 seconds.
>
> Peter, what's the six-byte message you send?
>
> (I want to get a handle on the processing required to
> create the message string.)
Bob,
Sorry, but there are only five bytes and are as follows;
Byte Description
-----------------------------------------------------------------
1 Start of Message ID Constant
2-3 Unit Identification 15 bits constant (1 bit battery low)
4 Frequency Value Variable
5 Checksum Variable
Sorry for the delay in answering, and thanks for your interest.
Regards,
Peter
--
_______________________________________________________________________
Peter Homann email: EraseMEpeterhspam_OUTTakeThisOuTadacel.com.au Work : +61 3 9596-2991
Adacel Pty Ltd Fax : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
Robert Lunn wrote:
>
> >With the PIC running at 32KHz, it is only operating at 8K instructions
> >per second. Transmitting at 2400 baud, there is time for only 7
> >instructions per bit.
>
> Ah, isn't that 3.4 instructions per bit?
>
> ___Bob
Yep, looks like the data rate will be slower, 1200 maybe.
Peter.
--
_______________________________________________________________________
Peter Homann email: peterhspam_OUTadacel.com.au Work : +61 3 9596-2991
Adacel Pty Ltd Fax : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
>
> Peter Homann wrote:
> >
> > Hi,
> >
> > I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> > and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> > once 5 seconds.
> >
> > The PIC I plan to use is the low power 84 variant, running at 32 KHz,
> > if possible.
> >
> > The two separate requirements are easy to implement on their own, it's
> > getting the PIC to implement them concurrently that I'm having trouble
> > with. I need to continue measuring the input frequency even while I am
> > transmitting the output message.
> >
> > I'd appreciate it if anybody who has solved this type of problem, can
> > give me a few pointers as this type of task, measure an input and
> > transmit it must be quite common.
> >
> > With the PIC running at 32KHz, it is only operating at 8K instructions
> > per second. Transmitting at 2400 baud, there is time for only 7
> > instructions per bit.
> >
> > I been tossing ideas around for a number of months now with no real
> > solution comming forward. I could use 2 Pics, one to do the counting,
> > the other to do the transmitting, but then I might as well use a
> > faster crystal.
> >
> > Are there other alternatives? I may be blinkered down a set path.
> >
> > Any input would be great. Code fragments would be fantastic.
> >
> > Thanks guys,
> >
> > Peter.
> > --
> > _______________________________________________________________________
> > Peter Homann email: @spam@peterhKILLspamadacel.com.au Work : +61 3 9596-2991
> > Adacel Pty Ltd Fax : +61 3 9596-2960
> > 250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
>
> Hi, I have been working on a system that counts pulses and pulse width
> using the 84 .I use both the T0 clock and INT on portB0 to generate
> ints.
> If you set the ints up so that an int is generated on the rising edge of
> portb0 and increment a counter every time an int is generated you can
> count pulses. now if you also set the clock to generate an int at a set
> duty cycle you can count the number of pulses on the portb0 pin within a
> set time. all of this can be done in the background and due to the
> nature of the ints it is also VERY presise.
>
> I hope this is of some use
>
> Peter........
I think the problem is that the output of serial data will be
corrupted by the interrupts.
Peter.
--
_______________________________________________________________________
Peter Homann email: KILLspampeterhKILLspamadacel.com.au Work : +61 3 9596-2991
Adacel Pty Ltd Fax : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
Robert Lunn wrote:
>
> >I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> >and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> >once 5 seconds.
> >
> >The PIC I plan to use is the low power 84 variant, running at 32 KHz,
> >if possible.
>
> Peter, you don't indicate the accuracy with which you need
> to measure the frequency...
Bob,
I only need an accuracy of +/- 0.5 cycles/minute.
Peter
--
_______________________________________________________________________
Peter Homann email: RemoveMEpeterhTakeThisOuTadacel.com.au Work : +61 3 9596-2991
Adacel Pty Ltd Fax : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
Robert Lunn wrote:
>
> >I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> >and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> >once 5 seconds.
> >
> >The PIC I plan to use is the low power 84 variant, running at 32 KHz,
> >if possible.
>
> Peter, you don't indicate the accuracy with which you need
> to measure the frequency...
>
> However, with a 32.768 kHz clock (which is 8192 instructions
> per second) a variation of one instruction in detecting the
> edge of a 250 rpm signal will cause an error in the calculated
> instantaneous frequency of 0.2 rpm.
>
> Assuming you don't want your measurement to be much less
> accurate than this, you must measure the edges of the input
> signal to within an instruction time.
>
> You can do this by setting up TMR0 as a free running timer
> with no prescale, configuring RB0 as an interrupt, and
> connecting your input signal to RB0.
>
> On each rising edge you get an interrupt, and in your ISR
> you capture TMR0.
>
> You must handle overflow of TMR0 in your main line code.
>
> You are now measuring your signal period, and thus your
> signal frequency, as accurately as it is possible.
Seems a good solution so far.
>
> Ok, now to the output side of the equation...
>
> I can solve your problem if I can change your requirements :-)
>
> Use 300 baud instead of 2400 baud (which is barely possible
> anyway).
300 baud may be a bit slow, Ill have to check. 1200baud is preferred.
I want to use a 32KHz crystal because of its availability. Maybe I'll
have to use a faster one, so as to increase the baud rate. The reason
for the slow crystal is purely for power consumption reasons.
>
> At 300 baud you have just over 27 instructions per bit. The
> ISR to capture TMR0 should be six instructions. This interrupt
> can never occur more than once per character (indeed, can never
> occur more than once per six byte transmission). Stretching
> a single bit time by 20% will _probably_ be ok...
>
> Don't forget to handle TMR0 overflow between each byte.
>
> ___Bob
Thanks again,
Peter.
--
_______________________________________________________________________
Peter Homann email: spamBeGonepeterhspamBeGoneadacel.com.au Work : +61 3 9596-2991
Adacel Pty Ltd Fax : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
> I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
> and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
> once 5 seconds.
>
> The PIC I plan to use is the low power 84 variant, running at 32 KHz,
> if possible.
I'd suggest doing the following:
[1] Use the following variables:
CurrTime : 16-bit
LastEvent : 16-bit
LastEvLatch : 16-bit
PrevEvent : 16-bit
NextOutput : 16-bit
At 09:02 07/11/96 +1100, Peter Homann wrote:
>I think the problem is that the output of serial data will be
>corrupted by the interrupts.
Didn't you say that you need to send only in quite big intervals? How about
stopping measuring while sending data, if there really is a timing problem?
Gerhard Fiedler wrote:
>
> At 09:02 07/11/96 +1100, Peter Homann wrote:
> >I think the problem is that the output of serial data will be
> >corrupted by the interrupts.
>
> Didn't you say that you need to send only in quite big intervals? How about
> stopping measuring while sending data, if there really is a timing problem?
Although I wish to initially transmit approximately once every
five seconds, eventually I would like to speed it up. Otherwise I
could restart the measurement after the transmission has finished.
At 20 rpm the period is 3S. The worst case is when the pulse is
missed during transmission and the next pulse is not for another
3 seconds, then the next pulse is another 3 seconds a delay of
6 seconds before the frequency value is calculated.
If necessary I can live with this but its not ideal.
I plan to transmit the signal at a random interval, averaged at
once every 5 seconds. It would be nice to have the "Current"
value ready for when the transmission is required.
The reason for the random transmission is that there is more than one
unit transmitting. A poor mans ethernet with no collision detection
by the sender. If the receiver get a screwed message it ignores it
and picks up the value on the next transmission.
--
_______________________________________________________________________
Peter Homann email: TakeThisOuTpeterhEraseMEspam_OUTadacel.com.au Work : +61 3 9596-2991
Adacel Pty Ltd Fax : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
> Although I wish to initially transmit approximately once every
> five seconds, eventually I would like to speed it up. Otherwise I
> could restart the measurement after the transmission has finished.
>
> I plan to transmit the signal at a random interval, averaged at
> once every 5 seconds. It would be nice to have the "Current"
> value ready for when the transmission is required.
>
> The reason for the random transmission is that there is more than one
> unit transmitting. A poor mans ethernet with no collision detection
> by the sender. If the receiver get a screwed message it ignores it
> and picks up the value on the next transmission.
What would happen if you were to, after each input pulse, randomly decide
to output a packet [possibly with some random delay beforehand]? If you
have observed the input frequency as 60bpm, you could wait up to about 800ms
after an input transition before sending your packet and still be done
in time for the next input; if your frequency is faster (e.g. 240bpm) you
can't wait as long but you have a better selection of pulses to trigger
on.
I decided that I had better do a bit of investigation in my
problem. Below are some thoughts and a possible solution. All
comments are welcome. Be kind as this is my first cut at it.
Therefore I need to calculate the frequency over
different number of Signal pulses depending on the frequency.
When the count gets greater then a particular value
the frequency is then calculated.
--------------------------------------------------------
Therefore use 1.953ms (32768/512) for timer increment so;
@ 250rpm period is 60/250 = 240.00mS and @ 1.9531ms = 122.88 counts
@ 249rpm period is 60/249 = 240.96mS and @ 1.9531ms = 123.37 counts
At this rate we would need to count over at least 2 cycles.
At the minumum frequency.
@ 20rpm period is 60/20 = 3.000S and = 1536 counts
@ 21rpm period is 60/21 = 2.857S and = 1642 counts
At this rate we could count over a single cycle.
Therefore we should be looking for about 300 counts.
Use of Interrupts
-----------------
Because the PIC is beign run of a 32KHz crystal, the CPU will not
need to utilise sleep modes as the current consumption is approx
65uA, therefore interrupts may not be needed as;
o The bit banging can't be interrupted
o If its time to send a message and we're calculating the
signal frequency or something else, we can wait until we're
finished. It doesn't matter that we're 1/2 sec late.
o At 32KHz there are onky 8K instructions/sec. Overheads in
processing the interrupts may be significant
o Use the KISS principle whereever possible.
Message Transmission
--------------------
For 5 bytes, ie 50 bits (1 Start, 1 Stop, 8 Data)
At 1200 baud 50 / 1200 = 42ms
At 1200 baud 1 byte takes approx 5ms
If we don't get a Signal during the transmission then everything is
fine. If we do, we can't detect it until the byte is banged out as
there is not enough time during the transmission to check it.
Note: we may even be able to wait until the whole message has
been sent. If the signal stays low for longer than 50ms we may
be able to guarantee it will still be low after the message is sent.
We could also use a flip-flop on the signal and then check
transitions in either direction. But this is more hardware and thus
more power and board real-estate.
Frequency Measurement
---------------------
To measure the frequency between 20 - 250 rpm the timer could
set up so as to overflow every 500ms. Whenever the Signal is detected,
the timer value is recorded. The period of the frequency is the
absolute difference between the timer value for a number of pulses. If
the absolute value is too small to get an accurate frequency
calculation, we can just wait for the next pulse, using the
totalled period duration.
We can also "defer" the frequency calculation if we are busy doing
other things, ie bit banging out the serial message.
The PIC 16C84 has an 8 bit timer(I think) with a prescaler.
Therefore, if we overflow at 0.5 second, we get a resolution of
just under 2 ms (1.9531ms).
Example
-------------
If we use 1.9531ms timer increments we get
512 counts /sec
or
30720 counts/minute
Using a bit of scaled arithmetic;
freq = 1/Period
Freq = 30720/count
for more accuracy use 30720 * 2 = 61440
Therefore the frequency is
F = ((61440 / count ) * number_of_Signals) / 2)
Example:
for a frequency of say 220 rpm over 3 pulses.
Period for 3 pulses is .818s
Count = 0.818/.001953 = 418
Freq = ((61440/418) * 3 ) / 2
= 219 rpm
BEGIN Main
. CALL Reset_Signal_Timing
. WHILE forever
. . CALL Check_Signal
. . CALL Check_Timer_Overflow
. . CALL Check_Transmission
. ENDWHILE
END Main
BEGIN Reset_Signal_Timing
. Set the present_count to 0
. Set the last_time_count to 0
. Set the number_of_Signals to 0
. Set the overflow_count to 0
. Set Timing_In_Progress to FALSE
END Reset_Signal_Timing
BEGIN Check_Signal
. IF Signal line has Hi to Lo transition
. . Set the present_count to the current counter value
. . Increment the number_of_Signals received
. . Set Timing_In_Progress to TRUE
. . CALL Calculate_Frequency
. ENDIF
END Check_Signal
BEGIN Calculate_Frequency
. Calculate the absolute interval
. IF the interval > MIN_PERIOD
. . IF the interval < MAX_PERIOD
. . . Calculate Temp = ???? / interval
. . . Calculate Frequency = Temp/Number_of_Signals
. . . Set the number_of_Signals received to zero
. . . Set the last_time_count to the present_count value
. . . Set the overflow_count to 0
. . ELSE
. . . CALL Reset_Signal_Timing
. . ENDIF
. ENDIF
END Calculate_Frequency
BEGIN Check_Timer_Overflow
. IF the timer has over flowed
. . IF overflow_count > MAX_OVERFLOW_COUNT
. . . CALL Reset_Signal_Timing
. . ELSE
. . . Increment the overflow_count
. . END
. END
END Check_Timer_Overflow
BEGIN Check_Transmission
. IF it is time to transmit
. . FOR x = 1 to 5
. . . Bit bang out byte(x)
. . . IF Signal line has Hi to Lo transition
. . . . Increment number_of_Signals received
. . . ENDIF
. . ENDFOR
. . IF the counter has overflowed
. . . Increment overflow_count
. . ENDIF
. . Calculate the next transmission time
. ENDIF
END Check_Transmission
--
_______________________________________________________________________
Peter Homann email: RemoveMEpeterhTakeThisOuTadacel.com.au Work : +61 3 9596-2991
Adacel Pty Ltd Fax : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
>
> > Although I wish to initially transmit approximately once every
> > five seconds, eventually I would like to speed it up. Otherwise I
> > could restart the measurement after the transmission has finished.
> >
> > I plan to transmit the signal at a random interval, averaged at
> > once every 5 seconds. It would be nice to have the "Current"
> > value ready for when the transmission is required.
> >
> > The reason for the random transmission is that there is more than one
> > unit transmitting. A poor mans ethernet with no collision detection
> > by the sender. If the receiver get a screwed message it ignores it
> > and picks up the value on the next transmission.
>
> What would happen if you were to, after each input pulse, randomly decide
> to output a packet [possibly with some random delay beforehand]? If you
> have observed the input frequency as 60bpm, you could wait up to about 800ms
> after an input transition before sending your packet and still be done
> in time for the next input; if your frequency is faster (e.g. 240bpm) you
> can't wait as long but you have a better selection of pulses to trigger
> on.
John,
Yes it is possible. I'm not sure that a pattern may develop because
the randomised interval may be less. I'll need to think about it. My
original concept was to have the current frequency alway available,
and the transmission part would just use that latest value when it
needed to transmit the message.
Thanks for your input. I look forward to tomorrows replys. I'm off
now and will think about the problem further.
Thanks again.
Peter.
--
_______________________________________________________________________
Peter Homann email: peterhEraseME.....adacel.com.au Work : +61 3 9596-2991
Adacel Pty Ltd Fax : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA Mobile : 014 025-925
>Robert Lunn wrote:
>>
>> >I need to measure a continuous frequency between 0 - 250 cycles/MINUTE,
>> >and transmit it via RS-232 at 2400 baud in a message containing 6 bytes
>> >once 5 seconds.
>>
>> Peter, what's the six-byte message you send?
>>
>> (I want to get a handle on the processing required to
>> create the message string.)
>
>Bob,
>
>Sorry, but there are only five bytes and are as follows;
>
>Byte Description
>-----------------------------------------------------------------
> 1 Start of Message ID Constant
> 2-3 Unit Identification 15 bits constant (1 bit battery low)
> 4 Frequency Value Variable
> 5 Checksum Variable
>
>Sorry for the delay in answering, and thanks for your interest.
>
>Regards,
>
>Peter
Hmm. A six byte message at 1200 baud takes 0.05 seconds. At 250 rpm the
input pulses arrive every 0.3 seconds. So there's enough time between pulses
to send multiple messages if necessary.
Providing your transmit routine waits until just after a pulse (or counter
overflow when there's no input) it should have hardly any problems with
packets corrupted by interrupt servicing routines, in fact you should
probably disable the interrupt for 100mS after each pulse.
Disabling the interrupt allows for the situation where the flag is
stationary on the edges of the sensor and produces anomolously high
readings. These noise readings appear as 600 rpm and can be filtered out
(binned).
Just a few thoughts,
Keith.
==========================================================
Keith Dowsett "Variables won't; constants aren't."
>Gerhard Fiedler wrote:
>> Didn't you say that you need to send only in quite big intervals? How about
>> stopping measuring while sending data, if there really is a timing problem?
>
>Although I wish to initially transmit approximately once every
>five seconds, eventually I would like to speed it up. Otherwise I
>could restart the measurement after the transmission has finished.
>
As others have mentioned, it seems that the best solution is to send the
data immediately after receiving an input pulse. It has already been
demonstrated that if you use this technique under the operating conditions
you have described, you will not miss and input pulses.
I don't know how long the 'data conversion' steps take, but it is likely
you could wait for an input pulse, do your calculations, and send the data
before another input pulse arrives.
Or am I missing something? Also, you're guaranteed to have one measurement
at least every three seconds, according to your operating conditions.
-Matt
"DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and
millions of others are by far the most popular, with about 70 million
machines in use wordwide. Macintosh fans, on the other hand, may note that
cockroaches are far more numerous than humans, and that numbers alone do
not denote a higher life form."
Hey, gang. I'm not sure where this thread has lead since I'm still a
week or so behind on my digests, but...
The 16F84-04/P through DigiKey is $6.48 in singles and $4.31 in 100s,
while the 16C62A-04/SP is $5.35 in singles and $3.56 in 100s. This
indicates that the '62A is cheaper than the '84 (your mileage may
vary), even though the former is in a skinney 28 rather than the 18
pin pkg.
This is significant in that the '62A HAS one CCP module that you can
capture the input waveform with WHILE you are bit-banging out the
other end. You can use TMR0 for the baud-rate generator to interrupt
you at the next bit time, and the CCP will interrupt you after the
capture has occured.
Checking two interrupt sources should not give too much of an
erroneous bit time at 1200/2400 baud, and leaving TMR2 can be used for
baud-rate generation using the period register for continuous
constant-period bit-time interrupts.
However, if you HAVE an '84 and you're just trying to use IT, then
that is another story. If you're trying to do the most efficient job,
though, I'd recommend the '62A.
adacel.com.au Work : +61 3 9596-2991
