[Top][All Lists]

## Re: [Discuss-gnuradio] Demodulating digital signal (FSK?) from audio

 From: Martin Braun Subject: Re: [Discuss-gnuradio] Demodulating digital signal (FSK?) from audio Date: Fri, 18 Jul 2014 11:07:17 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 07/18/2014 05:23 AM, Stefan Oltmanns wrote:
>>> What exactly does mix to zero mean? From what I understood so far,
>>> I=RF*cos(ωt) and Q=RF*sin(ωt), when I set ω=0 => I=RF and Q=0 is that
>>> what you mean?
>>
>> No, that would still be a real signal. In your nomenclature, if ω=10Hz *
>> 2\pi, then you get a complex signal (10 Hz being what you said was the
>> center frequency of the battery signal).
>
> I think the center is 4 Hz, the signal is below 10 Hz

Hint: You can dowconvert with an exp(j2\pi \omega t) instead of a sine
and cosine, but it doesn't really matter.
But the more I think about it it's probably not something you need
complex math to demod, given the simplicity.

>>> I changed the filter settings and now the dip between two blocks is more
>>> precise. I attached two signals generated by the different microphone
>>> types using the same protocol. I tried the quadrature_demod, but result
>>> especially for the varicap-mic seems not be useful (also tried changing
>>> the only parameter).
>>
>> To understand what's going on, I recommend you generate an FSK signal in
>> GRC and then use quadrature_demod and see what happens.
>
> That´s a good idea, but I have a stupid question: How do I generate a
> FSK signal? There are lots of modulators available, but no FSK.

You can either drive a 'Frequency Mod' with discrete keys, or use the
'Continuous Phase Modulation' block with appropriate settings.

>>> I think what I have to do is measure the distance between two peaks
>>> (only positive, threshold 200u):
>>> Distance more than 0,5s -> New Block starts
>>> Distance between 0,3s and 0,4s -> 1
>>> Distance between 0,15s and 0,25s -> 0
>>> else -> reset (delete buffer and wait for new block start)
>>> Can this be done with GnuRadio?
>>
>> Hm, this sounds too much like guesswork. Do you have a spec sheet or
>> something describing the modulation in more detail?
>
> No, it´s a proprietary protocol and I´m reverse-engineering it (I can
> actually read it when I look at the signal, what I have to do is make
> the software read it). All I have is circuit diagrams (service manuals)
> of microphones and receivers. There is no detailed description of the
> battery status signal (and of course no source of the µC code), no more
> than it´s a low frequency signal in the range around 5 Hz with a nominal
> FM deviation of 2 kHz.
>
> I was able to remove everything below 200u of the signal, convert it to
> complex and then quadrature_demod generates something quite nice. Is
> that how the demodulated signal is supposed to look like? AFAIK it´s now
> pulse position modulation.
> But it´s still an "analog" signal, how can I make a real digital signal?

The big issue is synchronisation. In general, for digital comms, you
need to find the 'right' time to sample your signal, then make a
decision based on your value. Finding the 'right' time is always the
funky part of digital receivers. Here, there should be a simple rule, if
this is supposed to be decoded by simple µCs.

M

>
> Best regards
> Stefan
>
>
>>>
>>> Am 16.07.2014 15:43, schrieb Marcus Müller:
>>>> Ahh-- my mistake, I was assuming the "dips" were something like one
>>>> symbol, the other being the continous wave with the 400u amplitude, and
>>>> completely missed the differences in period on the non-dippy signal...
>>>> The lower halfwaves of the lower-frequency oscillations look a little
>>>> strange; maybe this signal was generated by RC-lowpassing a PWM signal?
>>>>
>>>>
>>>> On 16.07.2014 15:18, Martin Braun wrote:
>>>>> On 07/16/2014 03:08 PM, Marcus Müller wrote:
>>>>>> this doesn't look like FSK, because then the amplitude of the
>>>>>> oscillations shouldn't change (only their frequency).
>>>>>> If I had to guess, it would be on-off-keying, and you could simply
>>>>>> detect that by squaring the signal, and using the integrate block on
>>>>>> that, with a integration length amounting to your symbol duration in
>>>>>> samples, which might be a little hard to guess from the signal you
>>>>>> posted, but maybe you know the symbol rate from elsewhere, or can
>>>>>> determine it by comparing signals from different battery states?
>>>>> The dips might also be between bursts -- it does look a bit like FSK,
>>>>> but hard to say.
>>>>> Stefan: If you mix this down to zero, your signal will be complex anyway
>>>>> (radio signals are also always real, but we don't care :D ). Then you
>>>>> can put it into a quadrature_demod_cf.
>>>>> Question is, how do you synchronise? Maybe you can use those dips to do
>>>>> that... Or maybe the symbol timing is well defined, then it's easier.
>>>>>
>>>>> M
>>>>>
>>>>>
>>>>>
>>>>>> Greetings,
>>>>>> Marcus
>>>>>>
>>>>>> On 16.07.2014 14:51, Stefan Oltmanns wrote:
>>>>>>> Hello,
>>>>>>> I would like to write an application that checks the battery status
>>>>>>> of wireless microphones. The battery status is transmitted as a
>>>>>>> very low frequency (below 10 Hz) signal that is mixed in the normal
>>>>>>> audio. I was able to filter the signal out of the demodulated audio
>>>>>>> and display it (see image). AFAIK this modulation is called FSK.
>>>>>>> The signal that is shown there should decode to data-blocks
>>>>>>> containing "11100000000" or something like that, are there any
>>>>>>> blocks in GnuRadio that can do that? Because the signal is derived
>>>>>>> from audio it is not complex but normal float, all GnuRadio
>>>>>>> demodulators seem to work only on complex data. Can somebody please
>>>>>>> help me?
>>>>>>> Best regards, Stefan
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>
>>
>> _______________________________________________
>>
>
>
>
> _______________________________________________