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

Reply via email to