discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] question about using FSK on noise


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] question about using FSK on noise
Date: Tue, 7 Jun 2016 17:20:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

Hi Abhinav,

On 07.06.2016 17:08, abhinav narain wrote:
Dear Marcus,

On Tue, Jun 7, 2016 at 6:05 AM, Marcus Müller <address@hidden> wrote:
Hi Abhinav,

Cool research, with lots of security implications :) !
Out of curiosity: as there are a lot of different power supply topographies, which one are you concentrating on? What does one find in "normal" laptop power supply "bricks"? Is it the "classical" fixed-frequency PWM buck, where the frequency modulation is really an effect of the different lengths of the duty cycle, modulating the spectrum's sinc shape in amplitude and spacing of side lobes, or is it the newer "adaptive frequency" kind of control? Or are there, like for class-D amplifiers, spread-spectrum modulators for the switching currents? (if not spread) What are the "typical" switching frequencies under "normal" load of these astonishingly small supplies?

I think they are due to different duty cycle, when there is a loop running vs when the process is sleep().
Well, that would be something I'd really try to get to know, because it will definitely define what you're looking for.
Also, really, Python on a non-RTOS on a laptop is not a clean measurement setup.
 
So: your question is pretty impossible to answer without you explaining the model you have:
How does your input (the program) influence the emissions? What's the mechanism behind that?

I have observed a change in the frequency of EM emission when the processor is idle(running the OS) vs when I run a busy loop.
"change" is not really well-defined!
So, I wrote a simple code(attached in last email) that sleeps when the message bit is 1,
and runs a busy computing an exponential value when the message bit is 0.
What exactly is your measurement setup?
Measurement setup:- 
I have analog filter and laptop plugged in adjacent power-plugs and I sample the first 500 kHz of the frequencies on powerline.
Ah ok, so no EM emissions, but you get the horrible, horrible power line channel, with its LPTV behaviour, including wildly varying insertion impedance based on frequency; this really makes doing a reference measurement with reduced sources of secondary effects all the more important!


As an input on "scientific methods": I think your whole research hinges on your power supply do different things under different load, right? So maybe I'd start with a much much reduced testcase: A complete laptop running something as non-deterministic as a wait loop in Python under a fully fledged operating system with a CPU that might do things like voltage scaling, a lot of buffering of energy in on-board capacitors and a screen with a fully fledged high-voltage SMPS might be a bit hard to get to do things 100% repeatably at first.
You are close to what I described. I haven't tried using the screen to draw power, but that sounds like a good direction to move forward.
 
Do you have already decoded something simple, like your power supply just heating a 10Ω resistor, and you then connecting a second one in parallel, maybe using a mosfet, just to get a "clean as possible" idea of how you can decode "simple" load changes? I think a lot of the energy between your 60kHz "blips" really is just due to the fact that your laptop varies its power consumption much faster than that, or actual EMI emissions of the SMPSes (there should be dozens!) inside the laptop itself. It's a bit hard to guess from your specgram what part of the signal is relevant.

I am trying to decode the message I transmitted using this flowgraph:- http://postimg.org/image/fkwdlyhyp/
well, your high pass filter is a bit redundant, isn't i? But it might be necessary if the low frequencies are very dominant here.

Have fun and all the best scientific output,

Marcus

reply via email to

[Prev in Thread] Current Thread [Next in Thread]