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

[Stefan Oltmanns]

Am 18.07.2014 11:07, schrieb Martin Braun:
> 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 did that (see pic) but I have no still have no idea what
quadrature_demod actually does, no matter how I change the parameters,
that only affects amplitude of demodulated signal.

>>>> 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.

I think decoding in µC is done like I described: Measuring distances
between peaks. There are 3 different ones, 0, 1 and new packet.
I found out the result of quadrature_demod is not that nice: The
distance between the peaks is quite precise while the output of
quadrature_demod is not good in case the shape of the curve is not
symmetrical. I tried Peak Detector (2), but I cannot get anything but 0
out of it.
Any ideas how I can implement that in GnuRadio (measure distance between
peaks)? Ans then convert the distances into packets of 0 and 1?

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
>>>>>>>
>>>>>>>
>>>>>>>> _______________________________________________ Discuss-gnuradio
>>>>>>>> mailing list address@hidden 
>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

fsk_simul.png
Description: PNG image