Manchester Decoding? Any experiences?

[ChristoRei]

Hello,

i am trying to demodulate and decode the 2FSK Signal that my car keyfob sends at 433.92 MHz.

Demodulating works well, but i have no clue how to decode the demodulated manchester coded Signal. There is no block available for manchester decoding i think.

I know, that i can use the signals clock and use a XOR. My problem is, that i dont know how to get the signals clock. Just generating a clock signal is not enough because it won't fit the timings of the Signal.

Has anyone a idea of how to do the decoding?

I would be very pleased about answers and tips.

[ChristoRei]

I push the question up and hope that someone has experience with Manchester decoding in Pothos.

[guruofquality]

Perhaps you could follow this: https://nccgroup.github.io/RFTM/fsk_receiver.html

I believe that Clock Recovery MM should be available

[ChristoRei]

I already tried this manual, but unfortunately it didn't work. The Clock Recovery MM simply does nothing.

I have also tried to simplify the program and only a Wav file of short length, but unfortunately nothing happens when I start the program.

It would be great if the Clock Recovery MM would work, but i don't know how to get it work.

Edit: I found out it does something, but not what is expected. If i put a Binary File Sink instead of the Monitor i get this:

The actual Signal is 192 bits 0 and 1 changing pattern.

[ChristoRei]

I have now decided to do the decoding with a C++ program and not in Pothos. In my opinion Pothos doesn't offer the right functions here.

I noticed another problem.

When I save my binary data stream, I have to decimate it first, because I would scan every bit 64 times and otherwise have 64 digits in my .bin file.

But this results in an error. Unfortunately the signal is not sampled exactly 64 times per symbol. Thus errors result from the shift. How do you solve this normally? I have simply worked with a decimation of the values around 64.

Here is the Problem in the .bin File. The first line of 1 is ok. Its a code violation and i expect that.

But in 3. row there is a line of 1 to. This does not display the scope i have from the Stream. I think it is because of the decimation. What do you think?

[guruofquality]

I have now decided to do the decoding with a C++ program and not in Pothos. In my opinion Pothos doesn't offer the right functions here.

Pothos is supposed to be a framework for building blocks. You have the right idea there, if you need a specific functionality, you should build it. I hope that you can contribute something back.

Since you are interested in windows: https://github.com/pothosware/PothosSDR/wiki/Development

But this results in an error. Unfortunately the signal is not sampled exactly 64 times per symbol. Thus errors result from the shift.

If I am understanding correctly, your sample point is drifting, so there is no correct position to decode the data over time? Thats pretty typical with receivers because the sample clock is different, or the antenna can even move. CFO is often an issue in general, but I think maybe its not in FSK since you are just taking the difference between frequency symbols.

A block like Clock Recovery MM is supposed to be able to track the clock transitions while simultaneously avoiding loosing lock due to noise. And I think its somewhat of a challenge to understand and to adjust the parameters to achieve that balance.

Often protocols like this have some kind of header/preamble/etc to initially estimate the timing, and phase distortions of a packet. Then you either have a good time estimate for the duration of the packet, or perhaps a way to estimate the drift as you progress through the packet.

[ChristoRei]

If I am understanding correctly, your sample point is drifting, so there is no correct position to decode the data over time? Thats pretty typical with receivers because the sample clock is different, or the antenna can even move. CFO is often an issue in general, but I think maybe its not in FSK since you are just taking the difference between frequency symbols.

A block like Clock Recovery MM is supposed to be able to track the clock transitions while simultaneously avoiding loosing lock due to noise. And I think its somewhat of a challenge to understand and to adjust the parameters to achieve that balance.

Yes i think thats the problem. I'm trying to fix it now with CLock Recovery, just like you suggested. I've tried this block before but it didn't work properly. Probably because I didn't understand it correctly and the parameters were wrong.

[ChristoRei]

Since I still couldn't find out why the Clock Recovery MM BLock doesn't work, I send more detailed information here.

The signal I'm sending looks like this:

I've already bent it so that it's reasonably symmetrical and also has peaks. Actually, the block should work well with it. I also squelched the noise.

However, nothing comes out at the back of the block. I can't see a signal with a wave monitor or a file here.

This is what i am doing. Signal looks good after demodulation and Moving average (used it to get peaks). But it won't come through the CR MM Block. Its simply not doing anything. I don't know why. I tried following some tutorials but it does not work.

Is it maybe not working in Pothos but only in Gnu Radio?

[ChristoRei]

I actually just tested it without live data. I just used the following .wav file and the Clock Recovery MM Block. Nothing comes out of the Clock Recovery MM Block. I dont understand why....

test.zip

I also tried to put a Cosine Signal directly from a Signal Source into the Clock Recovery MM. It still does nothing. Am i doing completely wrong?

[ChristoRei]

Does anyone have any experience with the Clock Recovery MM Block? To me it looks like it would have been imported incorrectly into Pothos. If anyone had an executable example program where the block would work it would be really great. I think the key to the problem is really the Clock Recovery MM block.

[guruofquality]

So the block was actually dumping this output from the executor:

        // Is it possible to ever fulfill this request?
        if(d_ninput_items_required[i] > d->input(i)->max_possible_items_available()) {
          // Nope, never going to happen...
          std::cerr << "\nsched: <block " << m->name()
                    << " (" << m->unique_id() << ")>"
                    << " is requesting more input data\n"
                    << "  than we can provide.\n"
                    << "  ninput_items_required = "
                    << d_ninput_items_required[i] << "\n"
                    << "  max_possible_items_available = "
                    << d->input(i)->max_possible_items_available() << "\n"
                    << "  If this is a filter, consider reducing the number of taps.\n";
          goto were_done;
        }

I put this fix in: https://github.com/pothosware/gr-pothos/commit/e5ac545aec131b7cc8ce846abe05cecb154c1bb0

[ChristoRei]

I want to thank you for your help. I'd also like to make two remarks about the Clock Recovery MM BLock.

The block now works, and since I've worked with it a bit now, I'd like to share my experience briefly.

Read the following link as well: https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/

It explains in detail how the block works.

What I wasn't aware of is what the parameters mean.

In short, the most important one: Omega is the sample/symbol rate. You need to know which samples/symbols the signal has.

Mu you can write 0 in, because you can't guess the start value here. Mu is the phase shift. I left Gain Omega and Gain Mu at 0.1.

What is important now: Omega Relative Limit Here you can set by how much deviation from your Omega value the value for the frequency may vary. If you set this value too low, the program may not be able to reconstruct the frequency because the value is outside of Omega +- Omega Relative.

Little Appendum: Small addendum: Make sure that your signal is balanced by 0. If not, use Add Const to set your signal up or down. You can see if you are balanced by 0 by measuering the time of a bit. In my example a 1 was longer than a 0. Because of that the CR MM made mistakes and detected 1 instead of 0 sometimes. Be carefull with this