• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register


Thread Rating:
  • 1 Vote(s) - 1 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Relation between raw-output and pulse length
#1
Can anyone tell me, or does anyone know what the relation is between the detected pulse-length and the number produced by pilight-raw output?

Am I correct that the polarity of the pulses do not matter (i.g. "High to Low" is equal to "Low to High")?

I should be able to figure that out by reading the source code, but I'm not really a C-coder (and by "not really" I mean I'm totally not!).
 
Reply
#2
The footer of the code devided by 34 is the pulse length.
 
Reply
#3
curlymo Wrote:The footer of the code devided by 34 is the pulse length

Thanks for the prompt reply!

I don't know what the "footer" is. I'm trying to find out the relation between raw-output and pulses I see on my scope so I can do calculations for a filter (and a bit of trail-and-error configuring).

There must be some looping or timing in the C-code to measure the time between the up- and down- flank of a pulse which results in a numeric representation for pilight-raw..(I think).

Thanks again..
 
Reply
#4
pilight uses pulse change interrupts so indeed, the low-to-high is the same as the high-to-low.

The footer is the last long pulse. Take this example of Conrad RSL:
Code:
1180 590 590 1180 1180 590 1180 590 1180 590 590 1180 590 1180 1180 590 1180 590 590 1180 1180 590 590 1180 590 1180 590 1180 590 1180 590 1180 1180 590 1180 590 1180 590 1180 590 590 1180 590 1180 590 1180 590 1180 590 1180 590 1180 1180 590 590 1180 590 1180 1180 590 590 1180 1180 590 590 6785
You can clearly see the footer as a long distinct pulse around 6785. So the pulse length of this protocol is around 200.

The pulses are the actual time difference between a low-to-high or a high-to-low.
 
Reply
#5
curlymo Wrote:You can clearly see the footer as a long distinct pulse around 6785. So the pulse length of this protocol is around 200.

That helps!!
I assume "200" means 200 Micro Seconds (10e-6).
 
Reply
#6
Yes
 
Reply
#7
curlymo Wrote:You can clearly see the footer as a long pulse around 6785. So the pulse length of this protocol is around 200.

I'm still a bit puzzled by the raw-output and the actual pulses generated by the transmitter.

Given the pilight-raw output of the alecto_ws1700 protocol:
Code:
540 1890 540 3780 540 1890 540 3780 540 3780 540 3780 540 3780 540 3780 540 1890 540 1890 540 3780 540 3780 540 3780 540 1890 540 1890 540 1890 540 1890 540 1890 540 1890 540 1890 540 3780 540 3780 540 1890 540 1890 540 4050 540 1890 540 4050 540 4050 540 1890 540 1890 540 4050 540 1890 540 3780 540 1890 540 3780 540 3780 540 9180

The footer 9180 divided by 34 (why 34? is that alway's and for all protocols the same divider?) gives a pulse-length of 270 microseconds.
Now, what I read from the numbers is that the protocol looks like this (a dash is a high and a space a low or vice versa) :
Code:
-+     +------+     +-----+     +--------------+     +--------------+     +-----
   540  1890    540   1890  540      3800        540       3800       540

A 540 followed by a 1890 is a "0" and a 540 followed by a 3800 is a "1". In this example there are two "0"s and two "1"s albeit "0011".

Now, what does "the pulse length of this protocol is around 270 microseconds" mean? I clearly see three distinct pulses. One identified by 540, one by 1890 and one by ~3800. I assumed that these numbers where the length of the pulses in microseconds. Which is clearly not the case as I wrote an Arduino program that works with these numbers as microseconds which I measured with a scope and a Logic State analyser to confirm that the lengths are correct .. but pilight does not "see" the transmission.
I'm close to understanding this thinky, but not really..
I just can't figure out how many microseconds the 540 pulse should be, and how many microseconds the other two ('1890' and '3800') should be.

This "not understanding" has kept me awake for night's in a row so if someone would please explain this to me I can finally program my own sensors and get a decend night sleep!! Tongue

Thanks in advance!
 
Reply
#8
The timing parameters are the result of some standard chip design implementations used for 433MHz equipment, it does not mean that all devices use it, but a lot of them.

For some designs it would be beneficial if we do know whether we have a Low-to-High or a High-to-Low transition as that does allow a better detection of pauses and a better implementation of decoding logic, however it carries some other implications with it, the most notable one is noise.

Due to the nature of OOK, implementing a filter is more or less limited to filtering out spikes and to ensure that proper logic levels are enforced, everything else is causing problems with pulse durations and decoding algorithms.
 
Reply
#9
May I ask again, I have not fully understood the details (sorry for this, but I am completely new to 433MHz, AM etc.). Assume I record a signal like that

.png   Code1.png (Size: 11.1 KB / Downloads: 7)
then I would expect something like
Code:
30 60 30 60
Now, if the pulselength is added, I have taken the lowest value (30 micro sec) times 34, so I get the response
Code:
Raw code:
30 60 30 60 1020
First question: Is that correct? Second question: Is there also something like a signal, i.e.

.png   CodeithFooter.png (Size: 14.73 KB / Downloads: 6)
 
Reply
#10
I just found this
(12-11-2013, 07:07 PM)mercurio. Wrote: so the procedure is the following:

you always fill a buffer with the last let's say 32 pulses.
then you analyze it and if the last pulse is somewhat around 4440us or bigger you divide it by 34. this way you get the pulse length.
then you check if it's valid for some protocol.
if it's valid you use it to analyze the rest of the 32 pulses and get the command.
(the footer pulse is the last one) and it seems now (for me) that both stories converge.
 
Reply
  


Possibly Related Threads...
Thread Author Replies Views Last Post
  ERROR: The Broadcom 2835 GPIO 0 is not set to output mode stuckinger 10 782 05-07-2019, 09:11 PM
Last Post: curlymo
  Start command/script on pulse receive wous 10 9,849 12-24-2013, 09:39 PM
Last Post: bultje76

Forum Jump:


Browsing: 1 Guest(s)