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?
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? What exactly is your measurement setup? 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. 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. With a clear idea of how the power supply reacts, I'd actually look at the cleaned-up (i.e. filtered) time domain signal. I'd expect to see some kind of pulse shape there. I think you can already guess from the spectrogram: _Switch_ mode power supplies will modulate things with rectangular waveforms, which have sinc shape in spectrum, and hence, a lot of side lobes. That would imply the best-guess matched filter would be a moving average – but I don't quite believe that; in fact, the power supply's job is to give a clean, constant voltage, so there's going to be quite some low pass filtering on the output, and the properties of that will most likely have an influence on the spectrum of the emitted pulses. Also you forgot to attach your flowgraph, it seems ;) Best regards, Marcus On 07.06.2016 07:35, abhinav narain wrote: > Hi all, > I am trying to make a covert communication channel using SMPS noise > generated by the processor as a part of my research. > > I see a change in frequency emitted by the processor when I run the > following loop (http://pastebin.com/uRghLuLm) with message variable > containing the message, and see the spectrogram > (http://postimg.org/image/g0ec0nvqj/full/), with fluctuating red > points ~60kHz, indicating the change due to a loop and sleep executed > on the processor. > > I want to decode the bits and I think I should use FSK, although I > lack understanding to configure the details. > The following is the current flowgraph where I have used bandpass > filter to narrow down the signal to ~60kHz and using quadrature block > to demodulate. > > Since the entity of interest is actual SMPS noise of the laptop > adapter instead of a sinosoid, I have no clue how to write a clear > decoder after looking at some tutorials of GNU Radio to know the > symbol rate etc for the clock recovery algorithm. > > I would be grateful, if someone can guide me on how to proceed > > > Thanks, > Abhinav > > > > _______________________________________________ > 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
