[curlymo]

@wo_rasp, you think my previous comment about footer / header doesn't apply here?

[gismo2004]

@curlymo
as far as i understood his replay --> no

i don't know if you already checked my logfiles... as i said: There is NO "GAP" of xxx usec. which can be used to identify a "footer or header". It does not even have to be like in v2, where there is a gap between the two sequences! --> this is also new to me, since i just own V2 devices...

the only way of identifying a oregon message is to check the initial sequence of 1010101010... with a length of ~1024us + a count of min. 24 (as i already have written...).

i also have seen in code, that pilight is very strict in checking pulselength:

Code:

if((recvqueue->plslen >= ((double)plslengths->length-5) && recvqueue->plslen <= ((double)plslengths->length+5)))

this might be also problematic, because if you check my logs again, it is not very "stable" --> this might also be a problem of my receiver, but i think we need also some kind of tolerance setting.

I know i'm new in this forum, and i know my English is not very good, but i've done a lot of tests to understand what 1000io is doing in his code, and i guess i've unterstood quite good why it is like it is. Now with pilight i'm a little bit lost, since i'm not used to use c and also it is far more complex then 1000io's code :-)

So i need some help to get started.

cheers

[curlymo]

So the only way is to check for header sequences independent of any gaps?

[gismo2004]

That's how i understood the signal. You just have 2 sequences for V2 and if you check the signal, this is the only "repeating" thing in the sequence. everything else might change if you unplug the battery or switch channel, or, or, or...

what do you think about the "tolerance"? wouldn't it be a good idea to add this to "protocol_plslen_t" ? default is 5 --> so nothing will change for other protocols.

cheers

[curlymo]

Let's not assume too quickly that pilight isn't tolerant enough.

[gismo2004]

Let's not assume too quickly that pilight isn't tolerant enough.

i don't want to assume something, but if i check the "raw output" of pilight (same as for 1000io's output) i see that the tolerance must be higher than 5...

below there is the initial sequence of a THGR122N sensor. please tel me which pulslen you would set in "protocol_plslen_add(oregon, xxx);"? (once we have this initial sequence stuff sorted)
i'm definitely not able to set a number, since it is fluctuating far more than 5 right?

Code:

433gpio: 929
433gpio: 918
433gpio: 1168
433gpio: 810
433gpio: 982
433gpio: 951
433gpio: 989
433gpio: 947
433gpio: 1004
433gpio: 972
433gpio: 996
433gpio: 950
433gpio: 997
433gpio: 945
433gpio: 998
433gpio: 953
433gpio: 995
433gpio: 967
433gpio: 987
433gpio: 966
433gpio: 990
433gpio: 971
433gpio: 978
433gpio: 983
433gpio: 965
433gpio: 968
433gpio: 994
433gpio: 984
433gpio: 976
433gpio: 965
433gpio: 980
433gpio: 969
433gpio: 980
433gpio: 509
433gpio: 454
433gpio: 1010
433gpio: 479
433gpio: 471
433gpio: 1018
433gpio: 467
433gpio: 476
433gpio: 1000
433gpio: 470
433gpio: 487
.
.
.

if it is just my receiver, well than i'm fucked, but i don't think it's just me, because if you check the logs here : http://forum.pilight.org/Thread-Oregon-T...84#pid5284 you'll find nearly the same fluctuation!

cheers

[curlymo]

You're not reading the pilight tolerance correctly. pilight has a tolerance of -5 > 0 < 5. So if that was all, it would mean 10 and not 5. Secondly, pilight divides the raw pulses by 34. So pilight is actually (-5*34) > 0 < (5*34) pulses. That means a tolerance of 340 us.

[gismo2004]

ohh, thats enought i think :-)

https://github.com/pilight/pilight/blob/...on.c#L1324

my fault, sorry for that!

could you please also explain why this magic number "34" is used for dividing timings?

cheers

[wo_rasp]

... below there is the initial sequence of a THGR122N sensor .....

Code:

433gpio: 929

[b]Start of preamble[/b]
433gpio: 918
433gpio: 1168
433gpio: 810
433gpio: 982
433gpio: 951
433gpio: 989
433gpio: 947
433gpio: 1004
433gpio: 972
433gpio: 996
433gpio: 950
433gpio: 997
433gpio: 945
433gpio: 998
433gpio: 953
433gpio: 995
433gpio: 967
433gpio: 987
433gpio: 966
433gpio: 990
433gpio: 971
433gpio: 978
433gpio: 983
433gpio: 965
433gpio: 968
433gpio: 994
433gpio: 984
433gpio: 976
433gpio: 965
433gpio: 980
433gpio: 969  -0
433gpio: 980  -1
[b]End of preamble
Start of SYNC[/b]
433gpio: 509
433gpio: 454 -1
433gpio: 1010 -0
433gpio: 479
433gpio: 471 -0
433gpio: 1018 -1

433gpio: 467
433gpio: 476 -1
433gpio: 1000 -0
433gpio: 470
433gpio: 487 -0
.
.
[b]The next value should be a logical 1, so i would expect:
433gpio: 1018 -1[/b]
.

if it is just my receiver, well than i'm fucked, but i don't think it's just me, because if you check the logs here : http://forum.pilight.org/Thread-Oregon-T...84#pid5284 you'll find nearly the same fluctuation!

cheers

No it is not your receiver, everything looks fine, it looks like OREGON V2.1,
but you stopped too early, before the last pulse of the SYNC byte, which should be a logical 1, thus a long pulse ....

I have added some comments in your code snippet.
Can you please post the complete set of raw data ?

[curlymo]

Because of the good relationship between footer, pulse length, and headers.