Accelerometer | ADC | ADXL | Adxl20 | AVR | BasicStamp | BX-35 | BX28 | BX35 | COM3 | Compiler | Downloader | EEPROM | Electromagnet | GetADC | GP2D1 | GPS | I2C | IDE | Keypad | LCD | LCD+ | MIDI | Motors | Multitasking | Netmedia | Networking | PCB | PID | PlaySound | PWM | Relays | RTC | Servo | ShiftOut | SitePlayer | SPI | Stack | Timer | USB

I need to measure incoming pulses of 100 and 200 milliseconds.
The PulseIn in not suitable for this, it's rangs is to short.
Before I start doing difficult things with the rtc I will ask if
someone has another bright idea how to do a simple pulswidth
measurement of pulses of this lenght.



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

I do this on one of my projects. It is very simple but the accuracy is only +/- 4 ms. s=false

do
If pin = high and s=false then
t=timer
s=true
end if

If pin=low and s=true then
pulsewidth=-timer-t
s=false
end if
loop

Its accuracy is limited by the 2ms accuaracy of timer and it can stack in both directions to generate a +/-4 ms range. In my case that was fine.

Art
[] I need to measure incoming pulses of 100 and 200 milliseconds.




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

How about hooking the pulse up to an interrupt, then the interrupt
should loop while checking the pin state until it changes back.

You could benchmark the interrupt by manually triggering the
interrupt, and holding it for a fairly precise, long time and then
read out the number of loop iterations.

Do this for 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 20.... seconds
then look at the loop iterations. There will be a small time
overhead of the entry into the interrupt, but not much compared to
many milliseconds.

By simple comutation, you can calculate the decimal fraction of a
second per loop. You could get more sophisticated and do a
regression to calculate the seconds per loop, but unless you have a
precise mechanism to handle the pulse duration, the regression will
not be much better than averaging many 10 second trials.

Then try it in real life and see what you get.

A logic probe, or even a DMM can tell you the frequency and duty-
cycle of the signal, if your signal is repetetive and fixed. An
oscilloscope would work too for the benchmarking.

--- In basicx@basi..., "wimn.rm" <wimn@r...> wrote:
>
> I need to measure incoming pulses of 100 and 200 milliseconds.





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "wimn.rm" <wimn@r...> wrote:
> I need to measure incoming pulses of 100 and 200 milliseconds.

You may be able to use WaitForInterrupt. If you're measuring a high
pulse, use bxPinRisingEdge initially. When the interrupt occurs store
the value of Register.RTCTick and do another WaitForInterrupt using
bxPinFallingEdge. When the interrupt occurs again the pulse width is
the difference between Register.RTCTick and the stored value time
1.95mS. You'll have to add code to detect when RTCTick rolls over to
zero. (Unfortunately, Register.RTCStopWatch is broken on the BX-24 -
that would be a much simpler solution.) Alternately, you could employ
Timer1 to measure the elapsed time with better resolution. See the
BasicX Timer1_Stopwatch_App_Note.pdf for detail on how to do this.



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

If you are decoding DCF77 (a German 77.5KHz timecode broadcast), you
don't need any precision, just a threshold to determine if the incoming
bit is a one or zero. That bit can then shift into a 60-bit string to
contain the entire minute frame of data, or code can parse the bit
stream on the fly.

I believe that all you need to do is find the start of a bit and then
determine if the bit period is >150mS. A missing bit signals bit 59 in
anticipation of :00 - or loss of data. You can, of course, time the bit
with code, but another way to decode it is to charge a capacitor during
the high bit period - either spinning in code until the bit falls, or
interrupting the machine when the bit falls. Immediately sample the
analog charge on the cap to determine the bit state, then discharge it.

Somewhere I have code for an MSF/DCF77/WWVB decoder that I wrote for
DOS. If that is helpful, I'll hunt it down. Tom





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "wimn.rm" <wimn@r...> wrote:
> I need to measure incoming pulses of 100 and 200 milliseconds.

On further reflection, I assume that you're trying to decode the
pulse-width-modulated DCF77 signal. In that case, you might
consider using external hardware to discriminate between the pulse
widths.

One way to do that simply is to use a one-shot that is triggered by
the incoming pulse. The pulse width of the one-shot should be set
to 150mS. Use the trailing edge of the one-shot's pulse to clock a
D flop whose data input is the original pulse signal. If the
original pulse was 100mS long the D flop will store a zero and if it
was the longer 200mS pulse it will store a 1.

The trailing edge of the one-shot's pulse could also set another
flip-flop to indicate that data is ready to be read. Your code
would then read the D flop output and then reset the "data-ready"
flip-flop.

I've put a quick sketch of such a circuit at:
http://www.kinzers.com/don/BX24/dcf77.jpg

The proposed circuit requires 3 I/O pins on the BX-24 but you could
reduce that to 2 by using the /RESET output to multiplex the DATA
RDY and DATA signals.

Don



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Actually, now that I think about it, my MSF/DCF77/WWVB decoder is an
assembly language TSR, so it will be of little use. I was thinking it
was a QuickBasic app that might be useful for structure, but I doubt
the assembly code will serve any useful purpose. Tom





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

That is a nice "quick" sketch! Do you just know the R & C values off
the top of your head for the 1-shot (3.3M, 0.1uF)?

-Tony



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Don, I'm close to the solution I think.
I now use 2 do while loops.

First waits for the raising edge. Next is starting a sleep of 120 mSec
Then a check if it's still high.
If not we have a short ( 100mSec)
If yes we have a long ( 200mSec)

Wim
[]




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Works! so simple afterward. do
CB = 0

'Wait for a 1
do while (cb = 0)
CB = GetPin(DCF77) 'Get clock output
loop

call sleep(60) 'pass the 100mSec
CB = GetPin(DCF77) 'Get clock output
if (cb = 1 ) then 'still a 1 ?
bit =1 'So it's a long pulse
else
bit = 0 'It's a short pulse
end if
debug.print cstr(bit)
call sleep(100) 'to prevent in enters the
'do-while with a value of 1
loop




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Tom, I got it working now. Surprizing short piece of
code afterward.
I'm not shure if it's realy failsave and how reliable
my receiver delivers it's pulses.

Thanks for your inputs!

Wim

--- Tom Becker <gtbecker@gtbe...> wrote:

> Actually, now that I think about it, my
> MSF/DCF77/WWVB decoder is an
> assembly language TSR...[]




(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> Do you just know the R & C values off
> the top of your head for the 1-shot...

Would that it were so. The formula is fairly simple. The pulse width
is 0.45 * R * C for the LS123. It's different for other
technologies. With the HC series, it also varies based on supply
voltage.

Don



(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., "Don Kinzer" <dkinzer@e...> wrote:
> Would that it were so. The formula is fairly simple. The pulse
width
> is 0.45 * R * C for the LS123.

Yeah, I thought you put a bit more effort in your reply than your words
suggested.

-T





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

Why would you make it more complicated than it is?
Why adding external one-shots?
The call sleep() does the same thing.
Now it works, just some formatting stuff to do.
Look:

00000000000000001001100100000100010000101101000011010000
01
22:9 28-10-5

0000000000000000100100001001010001000010110100001101000001
22:10 28-10-5 Public Sub Main()

Call PutPin(DCF77,bxInputPullup)
do
tb = 0.0
do while (tb < 1.2)
t1 = timer
call getbit(bit)
debug.print cstr(bit)
t2 = timer
tb = t2 - t1
debug.print cstr(tb)
loop

debug.print "Sync gevonden"
dim i as integer
for i = 1 to 58
call getbit(bit)
debug.print cstr(bit);
index = i
call leesbaar(index,bit)
next
debug.print

debug.print cstr(uur);":";cstr(minute);"
";cstr(cal);"-";cstr(maand);"-";cstr(jaar)
loop
end sub sub getbit(bit as integer)
CB = 0

do while (cb = 0) 'Wait for a 1
CB = GetPin(DCF77) 'Get clock output
loop

call sleep(60) 'pass the 100mSec
CB = GetPin(DCF77) 'Get clock output
if (cb = 1 ) then 'still a 1 ?
bit =1 'So it's a long pulse
else
bit = 0 'It's a short pulse
end if
call sleep(100) 'to prevent entering the do-while
with a value of 1
end sub
--- arhodes19044 <spamiam@spam...> wrote:

> --- In basicx@basi..., "Don Kinzer"
> <dkinzer@e...> wrote:
> > Would that it were so. The formula is fairly
> simple. The pulse
> width
> > is 0.45 * R * C for the LS123.
>
> Yeah, I thought you put a bit more effort in your
> reply than your words
> suggested.
>
> -T
Wim Nijntjes
Oranjekanaal 38 NZ
9415TP Hijken
The Netherlands

__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )

--- In basicx@basi..., Wim Nijntjes <wimn@r...> wrote:
> Why would you make it more complicated than it is?
> Why adding external one-shots?

The design of embedded systems involves many trade-offs, including the
hardware/software trade-offs. Sometimes, adding a bit of external
hardware solves a difficult problem whose solution fully in software
is "too expensive" in terms of the limited resources available - time,
RAM, code space, etc. Also, a software-only solution may not provide
the accuracy that is required in a particular circumstance.

It may be that using Delay() to implement the timing necessary for
accurate pulse width discrimination is a pefect solution in your
situation. Be aware, however, that Delay() only guarantees a
*minimum* delay, not a *maximum* delay. Depending on what other tasks
in your system are doing, the actual delay could be much longer than
the maximum delay that would allow accurate discrimination.

Don





(You need to be a member of basicx -- send a blank email to basicx-subscribe@yahoogroups.com )