reading pulses

stef

Hi

Just a general question on how to start with this. We are starting a project where we recieve 12 bit from a machine thrue a wireless device (aurel rx 4mm5). I want to capture the 12 bit by a prop and reakt on it if the bit condition is ok. I still need to look into the timing how fast the bits are comming . What I know is that the device is sending 2 times the same bit stream for every event.
Is thier somebody that can point me in the good direction on how to start reading the bits. I want to work in spin if possible.
I will try to mesure and capture the bitstream and timing this evening on my scope to give an idea of what is comming in.
Also the aurel device is a 5 V device. I need to do some kind of level shift to the prop 3,3v device that can keep up with the speed of the bitstream. Also any sudgestion is welcome.

Stef

Mike G

Stef; There's a lot of great info in the sticky http://forums.parallax.com/showthread.php?111166-Propeller-Resource-Index

That's where I found the 5V interface
http://forums.parallax.com/showthread.php?85474-How-to-safely-interface-a-5v-signal-to-the-propeller-See-Post-Reply-104&p=585920#post585920

I'm not sure about the 12 bit. Do you have a datasheet? I see where there is a demodulated analog output.

kwinn

It sounds like receiving the bit stream can be done by one of the serial objects in the OBEX but we need a little more information to be sure. What is the data rate and format of the bit stream?

stef

Hi

Today the owner of the device sending me the bitstream let me look into his device to do some test. He gave me the wrong information on paper.
With my scope I could capture and mesure the bitstream.
This is what I got.

The device is always sending 38 pulses.
It starts with 34 ms (milliseconds) low, then I get 38 pulses. If a bit is 0 then I maesure a chort puls (0,34ms high and 0,34 ms low) If a bit is 1 then I maesure a longer puls (0,60ms high and 0.60ms low.)
The device is repeating the 38 pulses two times. Between the sequence thier is a 34ms time low.
If nothing is send then I got a lot of noise on the line. I see a lot of shot spikes of 0.2ms. They are unreagulare. Seems to me like the line is not pult low when it is in idle state.
But whenever the device is starting to send it starts with the clean 34ms low.

The only thing I need to do is to reakt on one particulare bitsequense. If he is sending that I need to swith a relay. The relay part is easy. I 'm not finding a way to read the pulses.

Hopes this information is helpful. If somebody hase an idea to start , pleas let me know

Stef

kwinn

The propeller can certainly handle the data rate provided the signal can be cleaned up so it is useable. I have a couple of questions and a suggestion. First the questions.

What are the DC levels (minimum and maximum) on the line when there is a signal ?

Do the spike voltages go above or below those DC levels when there is no signal on the line ?


I would suggest measuring the output signal using the attached schematic. If the signal out is good then the propeller should do the job.

stef

Hi Kwinn

Thanks for your reaktion.
When I was at the device sending the pulsstream I measured with the scoop the values.

A low is always 0 V
A High is max 4.9V

When the line is Idle I saw the spikes. They are much shorther then the pulses but they also folow the same valuse like abouve. Thier was never a time that the voltage was abouve 5V

I hoped that on idle I would get a flat line on 0V but that was not the case.

I supose with these valuse that I can connect the device to the propeller input with just a serie resistor to limit the current.

stef

kwinn

The circuit I posted previously will limit the voltage to the prop pin to approximately -0.6V and +3.9V. A 1K resistor between the output of that circuit and the prop will provide enough protection for the prop.

The noise on the line suggests that it is floating when there is no signal from the device it is connected to. If that is the case then the pullup resistor in the diode clamping circuit should pull the signal on the prop input pin up to 3.3V when there is no signal. That should make sensing the start of data and decoding the bits fairly simple.

Phil Pilgrim (PhiPi)

From OOK (on-off keying) receivers like that, I'm almost sure the noise will be driven, not floating. It's what the receiver "thinks" it's receiving when there's no real signal. The reason for this is that the data slicer is constantly searching for a threshold and will settle on an unhappy medium between RF noise spike amplitudes. This is also the reason each transmission starts with an unmodulated carrier: to set a zero level for subsequent data. I think the only solution will be to wait for a null of a certain length before starting to interpret data. And, even then, I would recommend multiple samples per bit and a voting scheme to determine each bit's state.

-Phil

stef

Hi

I set up the puls reading with monitorpwm.spin. I can get back the thprobe,tlprobeand pulscount with this object on the parallax serial terminal. I think I 'm calling it the right way. What I 'm a bit suprised to see is that in the pulscount thier are gaps. I was especting a normal upgoing count. Seems like I miss getting settings. I call them in a loop like this

repeat
  if pulscntold < pulseCnt
     debug.str(string("pulsHIGH :")) 
     debug.dec(tHprobe)
'     debug.putc(13)
     debug.str(string("     pulsLOW :")) 
     debug.dec(tLprobe)
'     debug.putc(13)
     debug.str(string("     pulscount :")) 
     debug.dec(pulseCnt) 
     debug.putc(13)
   pulscntold := pulsecnt

see hier the result
pulsHIGH :30810 pulsLOW :49232 pulscount :12111
pulsHIGH :51536 pulsLOW :49506 pulscount :12118
pulsHIGH :26815 pulsLOW :49627 pulscount :12125
pulsHIGH :26346 pulsLOW :25069 pulscount :12132
pulsHIGH :50402 pulsLOW :26116 pulscount :12139
pulsHIGH :50129 pulsLOW :26749 pulscount :12144
pulsHIGH :29027 pulsLOW :48242 pulscount :12149
pulsHIGH :52259 pulsLOW :49494 pulscount :12156
pulsHIGH :26801 pulsLOW :49311 pulscount :12163
pulsHIGH :26735 pulsLOW :25087 pulscount :12170
pulsHIGH :50666 pulsLOW :25875 pulscount :12177
pulsHIGH :50388 pulsLOW :26560 pulscount :12182
pulsHIGH :28947 pulsLOW :48226 pulscount :12187
pulsHIGH :52026 pulsLOW :49173 pulscount :12194
pulsHIGH :27331 pulsLOW :49575 pulscount :12201
pulsHIGH :26848 pulsLOW :24666 pulscount :12208

what am I doing wrong? If I mis getting the pulses I can not reakt on the good result. With the timing discribed on the previous post this should not be a problem.
I'm doing something wrong?

stef

kwinn

Stef, pulses as short as 0.34mS and 0.60mS are too short to measure reliably using spin. You will need to use PASM to do this.

stef

Hi Kwin

Than I have a problem. I don't know PASM.

The TestDualPwmWithProbes manual mentioned that it can masure 12,5 ns. Is that not in spin then?

The values I got back are in order of 30000 / 40000. What is the unit of that? (milliseconds, nanoseconds or clockticks) I can't find anywhere mentioning that.

stef

Ariba

stef

This can be done in Spin, if you use the Propeller counters.
In the following code I use one counter to count the high time clock pulses, and another to detect a negative edge (which is the end of the high time, measured by the first counter).

With the included test-pulse generator it seems to work fine. Not sure if it also will work with the real device. To test that, just comment the cognew line out, and connect your device at the pin (Don't connect it while the generator is running !)

Andy

CON
  _clkmode  = xtal1 + pll16x
  _xinfreq  = 5_000_000

  pin = 0

VAR
  long  us
  byte  pulses[38]
  
OBJ
  disp : "FullDuplexSerial"
      
PUB Main  | i
  disp.start(31,30,0,115200)     'start serial driver
  us := 80                       '80 clocktick per microsecond
  cognew(generator,$7000)
  ctra := %01110<<26 + pin       'ctra for neg edge detection
  frqa := 1
  ctrb := %01000<<26 + pin       'ctrb for pulstime high 
  frqb := 1

  repeat
    repeat                         'wait for start 
      i := cnt
      repeat while ina[pin]==0         'measure low time
    until cnt-i > constant(80_000*29)  'until > 29ms?
     
    repeat i from 0 to 37         'record pulse times
      phsa := phsb := 0           'clr edge and pulstime
      repeat until phsa           'wait for neg edge
      pulses[i] := (phsb > 36_000) & 1  'received bit to array
     
    disp.tx(0)
    repeat i from 0 to 37         'show pulse times
      disp.dec(i)
      disp.tx(":")
      disp.dec(pulses[i])
      disp.tx(13)
      
    waitcnt(200_000*us + cnt)     'display refresh rate
     

PUB generator                    'generates the test-pulses 
  dira[pin] := 1
  repeat
    outa[pin] := 0               'long Low
    waitcnt(32_000*us + cnt)

    repeat 19                    '19*2 pulses = 38
      outa[pin] := 1
      waitcnt(340*us + cnt)    'Low
      outa[pin] := 0
      waitcnt(340*us + cnt)
       
      outa[pin] := 1
      waitcnt(600*us + cnt)    'High
      outa[pin] := 0
      waitcnt(600*us + cnt)

kwinn

@stef, I couldn't find monitorpwm.spin in the obex to verify what the high/low times were but I am pretty sure they are clock counts. At 80MHz 0.34mS would be 27200, and 0.6mS would be 48000 which is pretty close to the numbers you are getting.

@Andy, using spin and the counters sounds great but is there enough time to process the timing values into a series of 38 one and zero bits to compare to the value he is looking for ?

Ariba

kwinn

Ohh I had the timing wrong, 10 times slower than it should be, but I tested it right now with the correct values and it works still well. I have updated the code above.
I also added the decoding of the High/Low to the receive loop - no problem.
I think it would even work with waitpeq/waitpne commands but the use of the counter gives more time. You really only get a change if a negative edge happens, so you have 0.68ms and 1.2ms time to read and store the pulses. And this is well inside the speed of Spin.

He can receive the pulses two times and store it in two arrays, and compare the values later, if it is not possible in realtime.

What I don't know is if the detection of the start works, this depends a lot on the hardware. The Prop must read a long Low only if the Device drives it low and not if it just sends noise.

Andy

kwinn

Ariba wrote: »

kwinn

Ohh I had the timing wrong, 10 times slower than it should be, but I tested it right now with the correct values and it works still well. I have updated the code above.
I also added the decoding of the High/Low to the receive loop - no problem.
I think it would even work with waitpeq/waitpne commands but the use of the counter gives more time. You really only get a change if a negative edge happens, so you have 0.68ms and 1.2ms time to read and store the pulses. And this is well inside the speed of Spin.

He can receive the pulses two times and store it in two arrays, and compare the values later, if it is not possible in realtime.

@Andy - This sounds very promising. My impression is that realtime is not required so having a delay of a few milliseconds between the end of receiving the data and turning on the relay is not a problem. Could you perhaps post the latest test code so stef can use it as a starting point?

@stef - Am I correct in this assumption ?

What I don't know is if the detection of the start works, this depends a lot on the hardware. The Prop must read a long Low only if the Device drives it low and not if it just sends noise.

Andy

I am also concerned with this as well as the possibility of noise during the data bits. My first thought was to use a pasm loop to count low and high times and have thresholds for determining if it was 0 or 1. This would compensate for short noise pulses. Of course that could also be done with the data from the counters when the signal is analyzed.