How can I measure Duty-Cycle???

Beagle

This is my first project with a Propeller.· I've out-grown the Basic Stamps, and am impressed with the power of the Propeller.· I am trying to interface a IST-506F temperature sensor to the Propeller.· The IST-506F uses a wierd one-wire communication scheme to speak to a micro-controller.

I need to decode the duty cycle of a Manchester code (not exactly Manchester code, but kinda like it) into 1's and 0's, then build the 1's and 0's up into 8-bit bytes.· The total word is 11-bits long.· The coding starts with a 50% duty cycle start bit (negative edge then positive edge transition)· next there are eight bits of either 25% or 75% duty cycles to represent 1's and 0's.·Finally a parity bit then 1-1/2 stop bits...

The 50% duty cycle start-bit begins with a negative transition· ¯¯¯¯¯¯¯¯|__|¯¯|· (the total negative and positive cycle is 125 µSec)
The Logic-1 is·represented by a 75% duty cycle begining with a negative transition |_|¯¯¯|· (again the total cycle is about 125 µSec, the·low part is about 30 µSec)
The Logic-0 is represented by a 25% duty cycle begining with a negative transition |___|¯|· (again the total cycle is about 125 µSec, the·low part is about 90 µSec)

Using the fastest Basic Stamp, I could measure the negative transitions using PULSIN.· It was almost working, but when there was a 0 followed by a 1, then the Basic Stamp would miss the transition, and melt several bits together.· I've spent the last couple days figuring out how to deal with serial communications with my LCD and radio MODEM.· I've got that stuff understood, but this Manchester-esque Code has me befuddled.

Any help would be appreciated,
Thank you,

Clint

StefanL38

Helo Clint,

there are two commands "WaitPeq" and "WaitPne" that you could use

second idea: as you are coming from the basic stamp in the obex there is a object BS2 Functions
that mimics PBasicfunctions.

In the first step this might be an easier approach. But as PBasic has its limitations this is the smae on the propeller

best regards

Stefan

Mike Green

To add to StefanL38's comment, use WAITPEQ and WAITPNE to wait for the negative and positive transitions, but save the system clock (CNT) on the transitions. Subtract the H->L CNT from the L->H CNT to get the width of the low pulse in clock ticks and subtract the L->H CNT from the 2nd H->L CNT to get the width of the high pulse in clock ticks. Compare the two widths. If they're too close in value, it's an error. If the first is greater than the second, you've go a zero bit, otherwise you've got a one bit and you can shift the bit into your final value.

PRI theValue(pin,threshold) | startTime, transition, endTime, temp1, temp2
   ' pin is 0-31, threshold in % from 0-100.  Use something like 60
   ' assume here that bits come in LSB first.  If not, change
   ' "result := result << 1 | 1" to "result := result >> 1 | $400"
   ' and "result <<= 1" to "result >>= 1"
   waitpeq(0,|<pin,0)       ' wait for initial 1 -> 0
   startTime := cnt
   repeat 11
      waitpne(0,|<pin,0)    ' wait for 0 -> 1
      transition := cnt
      waitpeq(0,|<pin,0)    ' wait for 1 -> 0
      endTime := cnt
      temp1 := transition - startTime   ' width of low pulse
      temp2 := endTime - transition   ' width of high pulse
      if (temp2 * 100) / (temp1 + temp2) > threshold
         result := result << 1 | 1
      else
         result <<= 1
      startTime := endTime

Post Edited (Mike Green) : 9/13/2009 2:45:33 PM GMT

JonnyMac

Here's another approach, in pseudo-code, based on timing you specify in your post

repeat
  measure low pulse
  until pulse = ~63us (not more, not less)

repeat nbits
  wait for line to transition from 1-> 0 (waitpne)
  wait 63us (waitcnt)
  sample line for bit (result := result << 1 | dpin)

You might want to setup one of the counters to measure the low-going pulse for the "start" bit

[noparse][[/noparse]Edit] Here's some *real* (albeit untested) code to go along with the above idea:

pub rdtemp(p, us63lo, us63hi) | pmask, t

  dira[noparse][[/noparse]p] := 0                                                  ' make pin an input
  pmask := |< p

  ctra := (%01100 << 26 ) + p                                   ' set for negative detect
  frqa := 1

  repeat
    waitpeq(pmask, pmask, 0)                                    ' wait for high
    phsa := 0
    waitpne(pmask, pmask, 0)                                    ' wait for low
    waitpeq(pmask, pmask, 0)                                    ' wait for high
  until (phsa => us63lo) and (phsa =< us63hi)                   ' wait for start low pulse

  result := 0
  t := cnt
  
  repeat 9
    waitpeq(pmask, pmask, 0)                                    ' wait for high
    waitpne(pmask, pmask, 0)                                    ' wait for low
    waitcnt(t += us63hi)                                        ' wait for sample time
    result := (result << 1) | ina[noparse][[/noparse]p]                            ' sample the pin

Again, this is predicated on the timing you specify. You'll need to pass the pin # and the counts in something just lower and just higher than 63 microseconds. For example:

us63lo := clkfreq / 1_000_000 * 56
us63hi := clkfreq / 1_000_000 * 70

This gives a little variablity to detecting the 62.5us low-going start pulse, yet the high end is safely less than the low pulse of a 0 bit and can be used as the sample delay from the 1->0 transition at the start of each bit.

Post Edited (JonnyMac) : 9/13/2009 5:46:08 PM GMT

Beagle

Wow, thanks for the fast responce...

Here's a little more clarification to the bit stream.

1. Start bit (50% duty Cycle)
2. 0 bit (25% duty cycle)
3. 0 bit (25% duty cycle)
4. 0 bit (25% duty cycle)
5. 0 bit (25% duty cycle)
6. 0 bit (25% duty cycle)
7. MSB
8. MSB -1
9. MSB -2
10. Parity bit (even) (I was palnning on ignoring it for now)
11. Stop bit - High for 125 µSec
12. Start bit (50% duty Cycle)
13. MSB -3
14. MSB -4
15. MSB -5
16. MSB -6
17. MSB -7
18. MSB -8
19. MSB -9
20. LSB
21. Parity bit
22. output goes high for about 1/4 second then starts over

I'll try Mike's and JonnyMac's ideas.· JonnyMac's idea is very similar to what I was thinking of doing, but I'm still trying to get used to the spin code.· Thank you guys very much.

Clint