[gismo2004]

Hi again!

I've now checked the pilight debug code, and for me it seems this will never show something valid, because as far as i understood the oregon proto. there is no "footer" --> see my wav file. pilight debug is assuming that the sender is providing a footer, and then devide it by "34"?!?!(why) to calculate the pulselen. i think this kind of method will not work for oregon.

The question for me now is, how to create something like @1000io has in his solution? we need to check if the initial sequence is matching the oregon proto.

The sequence starts with 24 or 32 long pulses (~1000) and after that we know we have a oregon sequence and can use this values + values until a long pulse (> 4000 for example) for recording.

if this can be recorded in raw values, we can handle the Manchester stuff in proto.c but without getting the stream it will be hard for me to help creating the proto.

i hope someone is willing to help here!

cheers

[curlymo]

What about updating and testing the protocol io1000 already has created?

[gismo2004]

i didn't get it?! is there already a pilight proto for oregon?

because the one from 1000io (github) is not compatible with pilight...

thats why i'm asking for getting the raw stream out of pilight... and since the logic of pilight is different to what oregon needs i have no clew how to implement this into pilight... we need to touch dameon.c and and and... its not enough to just add a new proto.

cheers

[curlymo]

You're right.

[gismo2004]

Would it be possible to define something like a header length and then how many samples should be taken to store into raw[]?

This way it would be possible to use nearly the same code as 1000io.
Unfortunately (for me) pilight is more complex than expected, i definitely need some help from you guys to help implementing that on "core" side.

what do you think?

cheers

[curlymo]

A pulse has either a footer or header and footer.

Header + Footer: 100 1000 100 300 100 300 [...] 100 7000 100 1000 100 300 100 300 [...] 100 7000
Footer: 100 300 100 300 [...] 100 7000 100 300 100 300 [...] 100 7000

However, we can also write the footer as this:
Header: 100 7000 100 300 100 300 [...] 100 7000 100 300 100 300 [...] 100

So as you can see, it doesn't really matter how we interpret the header or footer. So i believe that Oregon just doesn't have a header and what you call the header is actually the footer

[gismo2004]

As you can see in 1000io's code, and also in my logs, and also in the wav file, there is just a "init" sequence. (whatever you want to call it) and the init sequence starts wit high and low pulses with a length of ~1000. Maybe i'm using the wrong wordings for it, but thats what i see in the files.

I don't know, if there is already a possibility to define something like that in pilight?.

Once we can "record" this stream starting with this sequence until a long "gap" i can adapt 1000io's code to work in a normal protocol file.

[curlymo]

Maybe @wo_rasp can shed his light on this as well?

[gismo2004]

Jeah that would be nice!

[wo_rasp]

Typically the press of a button results in a minimum of 3 or 4 repeated data frames.
pilight-debug is searching for repetitive footer pulses within a 255 byte window, and than analyzes if it can detect valid data pulses that fit to the footer and compute the datalength and the value for pulselen and pulse.
If there is a footer present this method will work with 2 repetitive footer values, if there is a header present, this method will require 3 repetitive header values.

Oregon sends all information four times, but each bit is doubled immediately and the whole frame is repeated only once, in some cases separated by one GAP (appr. 10000µS), in other cases instead of a GAP, a set of 10 long pulses is used (the pulse length is not long enough in order to qualify as a footer condition).

This is the problem why pilight-debug does not detect the OREGON protocol data stream, it does not find sufficient valid data.

@gismo2004:
As the data is manchester encoded, we need to pickup the pulses from the start and detect the RF preamble pulses, as they are different for V1.0, V2.x and V3.0.
I would recommend to implement that logic as part of the individual protocol driver, and use the same mechanism as for parsing the payload, for example:
oregon_weather->parseHeader=&oregonWeatherParseHeader;
Thus the computing overhead is limited to required functionality.

@curlymo:
If this approach is acceptable, i would recommend to add "int (*parseHeader) (void)" to struct protocol_t. The return parameter is used to indicate success or failure. In case of success the code for decoding the payload is called.