A little help recognizing signal encoding

Hello,

I’m now playing around with an RTL DVB-T dongle for some weeks, and decided to take the step into something I never really used : electronics. Thanks to Arduino, I’m now able to understand what I never took time to undestand before : microcontrollers !
Anyway, I decided to reverse-engineer and reproduce my portal-door remote control to do something usefull with this little Arduino Uno board. So I sniffed the signal sent by the remote, but I must say I’m not really sure about the encoding. (I already played with remote weather station sensors, that use OOK and Manchester Encoding, but I don’t recognize it here.)

Here is an image of the recorded signal :

The “high” states are always the same lenght (approximately 120us), and only the low states have a varying length (120us or 240us). So I wonder how I have to “read” and decode this signal in order to understand it.
If somebody have the answer, I’d be glad to hear the explanation :slight_smile:

Thank you

PS: if you’re good at recognizing signals, I also stumbled upon a very strange signal (who was repeated at varying delays, and always the exact same pattern). Here it is : http://www.hexrender.com/tiituuudrrrdrrr.wav If you know what it could be, let me know !

I have limited knowledge of all the systems, but this waveform seems to go against the idea of Manchester encoding.

If you look at the first dozen bits of the preamble, they are all nicely symetrical around the zero volts, which makes data slicing easy ( the data is fed to one input of an opamp/comparator directly, while the other is smoothed to take the average )

If you look at about time 0.848, the signal has crept up on the data line, so the mark to space ratio of the comparator output will be distorted.

Perhaps it is a system that detects the top of the pulses, and measures the interval between them ?

First, thanks for your fast answer :) !

I'm not sure I exactly understood the part about the opamp/comparator, and what is "the other" that is smoothed. Do you mean you "smooth" this datastream to get the "average voltage", and then use this to detect the high "peaks", to be able to calculate the time between each ones ? And what do you mean by "the signal has crept up on the data line"? I must say I'm not good enough in electronics to understand the effect you're talking about.

Anyway, it seems to be a viable trail !

Anyone else has an opinion ?

I'm not sure how and if I'm allowed to "bump" this topic to the top page but it has now sinked into oblivion, so I'll allow myself a little post.

For the moment, I'm taking the Boffin1's answer for the right answer, but it's strange because the number of bits sent is odd (am I wrong ?). Anyway, anyone can confirm what Boffin1 think ? Or is it another encoding ?

I can download but not open the .wav file you linked to. It seems to use some unknown codec. Could the signal be as simple as something like... short low period = 0 long low period = 1 or vice-versa.

That type of coding looks similar to what a SC2262 encoder produces. See if you can see any ICs in the Transmitter with part numbers like this. If there are, just have a look at the spec sheet for the SC2262. This chip and its decoder pair SC2272 , are very common in applications like this.