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