Hmm. Thanks for explanation. My problem is - i put all your schematic in CPLD and can't test it by oscilloscope for find problem. In any case thanks.

I see your use resistor for hysteresis but i not see resistor before U1B...

That would be R9 and R10.

I don't know if this will help - probably not, because of the way RC4 seems to be encoded - but this is how I got around this problem in an AM carrier wave:

Except the sync-byte, every bit is manchester encoded.

Every bit gets sampled 8 times. The result is you can re-sync your timing on every single bit when you get a little bit of drift. By spreading sampling 8 times within a bit, you can find the point in, say, a high bit at which a low goes high, or on a low bit, when a high goes low. If it drifts by more than 1/8th of a sample for two bits in a row (allowing for a bit of noise), I resync.
If you're using a 5MHz crystal, then you're not going to have much luck here. To achieve this in the same way you'd want to be using a at least a 40MHz TCXO.

In an active system you can use your active field for synchronization. For example, say you have a 125kHz active field, you can use that either embed a sync (eg, every 12th wave has three times the power, something like that).

Food for thought maybe?

If I knew a bit more about the RC4 protocol/carrier specifically I could probably be of more help, sorry, otherwise I can only give general/abstract ideas

Hi,
based on algorithm which is used for encoding number to bytestream you can use sw error correction. You can find the algorithm with source code in transponder design thread. It is based on convolution with long constrain length so viterbi can not be used but you can use some other algs. If you need further explanation i can help you with this as i worked a lot with finding this alg.
regards
Brano

I mean - Must be resistor before 74HC04 if your use it as Schmitt trigger.
This is typycal schematic: h t t p://upload.wikimedia.org/wikipedia/commons/thumb/6/64/Op-Amp_Schmitt_Trigger.svg/300px-Op-Amp_Schmitt_Trigger.svg.png

R9 and R10 serve this function. Their Thevenin equivalent is the input resistor; that's 1K, in this case.

http://en.wikipedia.org/wiki/Th%C3%A9venin%27s_theorem

If i right understand - 11 bytes = 88 bits/ 2 = 44 bits. It is 5 bytes + 1 nibble.
So... Why your decoder and encoder use only 3 bytes?

the are some bits which meaning is unknown and number is still the same, we tested that. What we tested is that decoder does not care about these bits. They just needs to be encoded correctly. Maybe in newer version of decoder these bits has some meanings. First 2bits in each received byte after preamble does not have meaning at least we do not know. Or maybe this alg is wrong ;0)
Anyhow you can calculate which bit you should receive and till some extent you can correct wrongly received bits.

Somewhere in this unknown bits hided secret of detecting where is ID packet and where is Status packet.

That might be jumping to an incorrect conclusion. The terms "ID" and "status" for describing the packets are totally arbitrary, created by me. I needed to call them something, and I named the packet that was transmitted most often by the transponder "ID" because that's what I ended up using it for in my decoder software. At the time I created these arbitrary names, I had no idea what was contained in the data.

I think you right with terms "ID" and "status".
Without Status packets AMBrc decoder stop accept chip after 1-2 laps.
Also Status packets is unique for every single chip. So i think it based on ID number.
100% somewhere must be identificator of packet type.
All chips what i read (not too much, just 4 chips) have data like xxxxxxxxxxxxxxxxxxxxx0 - last nibble all time = 0. I think it's not a data. It is part of packet footer (like zeros before preamble data) . And it have reason - 5 bytes = 40 bits length.

i do not think so, at least not in this case, this works with dp (older) transponders and i think those do not have status message. From my observation those sends all the time the same message.

I believe you are correct. Three of the twenty "bonus numbers" contained in the MRT PTX-20 do not have status messages, and all of these were "cloned" by MRT from AMB devices.

Hi Howard,

i do not have access to decoder now, can you or anybody test to generate the same number with different 'ghost bits' and check which of them works ?

DP chip have ID and 7 status messages.