And my dog, have eat receiver, so now they are just pinging, but i can't go far away without remote receiver.
I want to rebuild it, i have logic analyzer, i received some packets with 433mhz receiver, i see that packets actually are not that long, and they are repeating, and i can assume that
risin+falling (200 + 200 us) is 1 or 0
falling+rising (200 + 200 us) is 0 or 1
But im not sure, there is also some data with 240us length low or high, or with 160, or with 440
Here is screen of data from one alarm
You will discover that the transmitters begins transmitting by sending some unknown number of synchronizing pulses before the actual data bits are sent. The receiver needs to know when the transmitter begins to send actual data so as to no confuse sync pulses with data bits. How that works may be different for each manufacturer. Best to open one of the senders and find the IC that is sending and look for documentation.
I have seen this bits
2 bits, pause, 38 packets (always same)
then its starts again, but some times, i saw sync 3 bits, not at the begining, but on second cycle.
I will check tomorrow rest 2 alarms, what i see is packets have same duration, but different bits count, so maybe i decoded them wrong.
can't it also be drivent not only by rise-fall, but also with time, some of falls or rises are ++40 or +60 us, lets say it define end of byte or something?
Didn't get it
here is my packet begining
rise, fall, rise, fall for 2.2ms, then packet, then again fall for 2.2ms and packet
first 2 rises, are 200us long, then inside packet i see same rises or falls, but also i see 440 us rise, 440us fall, 160 rise, 240 fall, and its pereats, so this is not time mistake, it means something
by the way alarm use unknown microcontroller & seems like it use syn115 as transmitter
It's nice to see that someone is getting his hands dirty analyzing the packets.
Most of us wire that receiver to arduino and use a RF433 library to get the protocol, decode it or just use raw codes recorded.
Good suggestion. Just capture the various packets sent under different conditions and pattern-match those on your own receiver. See how that goes.
Nowhere it is written that each bit should always be of equal length in any given transmission protocol. There are sometimes (usually) 'rules' in a protocol that determine how a bit is encoded based on previous data; e.g. a '1' following after '00' may look different form a '1' that follows after a '01'. This is usually due to the requirement of retaining synchronization over an inherently asynchronous line.
It may be possible to decode this, which tends to be easier if you have a combination of data + encoding. In this case, it's probably difficult to obtain such a key, and thus, I suspect that the brute force pattern-matching approach suggested earlier is likely easier.
I like do something like that, its first time i decode RF packets, but before i worked a lot with tcp/udp in gaming programing
i will try to capture all 4 different alarms, and match them. also will try to to as suggested with RF433, but still i will more like to totaly decode packet
I don't know if I follow you... You want to decode it manually with analyzer? It's great but quite time consuming. Arduino+library probably do it for you, so you can start programming it as a receiver.
Im actually trying now arduino + receiver, and RF433any library, but its do not display anything, while i also connected to analyzer, and i see that data is coming.
May be your arduino broken or... almost whatever.
I don't know your board, not your sensor, not your wiring , not your serial monitor connection, and not your code.
For sure I can't help.
