Weeky update (week 47)

Not too much happened since our last post. The most important news is that our two-weeks span without experiment interaction went as expected. Our ground support BioTESC was busy with live operations for the German Horizons experiment CIMON, which went pretty well. BioTESC asked in advance if it is possible to prepare MarconISSta such that no interaction is needed in week 46. So we decided to finally do a more detailed analysis of the S band amateur allocations and are currently swiping through 2400 MHz to 2450 MHz. The S band assessment will go on until the end of this week. So far we can say that the S band seems to be less used than the L band. The most interesting signal can be seen in the picture below. A signal that varies over time between 2403 MHz and 2405 MHz. This signal clearly originates from the ISS, but we do not know what it is, most probable a frequency shift of a TCXO (oscillator). We will analyze the discontinuities and oscillations of the signal and how these match the ISS orbits and eclipse times. We also asked regulatory authorities and ARISS if they have any idea what the signal is, with a final answer still pending.2018-11-12T14-00-00_LNA_30_PGA_12_TIA_0_S_HIGH.csv.png

7 thoughts on “Weeky update (week 47)

  1. The frequency shift is too wide (2MHz) to be a product of Lime. See the upper frequencies’ time difference. Almost exactly the time period ISS orbits the earth(92m according to wikipedia). I suggest that we see some drift caused by gradual heating and cooling of some element. Maybe solar panels’ inverters? Maybe not, because part of the time ISS is in earth’s shadow(inverters inactive). Maybe the abrupt changes are when ISS comes from/to earth’s shadow. Or is oriented with some angle to the sun. Or the voltage onboard abruptly changes because of aritificial light (light switched on/off). An maybe it’s ISS’s power supply distribution – i.e. something connected to batteries.

    So I suspect some inverter, maybe some equipment onboard. The drift’s derivation may tell something about place on ISS that’s responsible (in shadow, maybe). And it may even reveal how deep under the skin it is. Cause on the surface, temperature changes much steeper than this.

    It looks very stable. So I think it’s the voltage of the ISS’s batteries that changes oscillating frequency of some equipment. And there are two dips spaced 92m too.


  2. According to this

    Click to access 20020070608.pdf

    Figure 6 the voltage on some of the battery compartments (out of 12 total) changes abruptly twice per orbit. Other batteries change voltage continuously. Therefore it should be easy to look into logs and find out, which battery (and its circuits) is connected with that noisy equipment.

    Newer batteries have Li-Ion chemistry and active temperature management (5 degC +-5). The heating/cooling element can be a suspect too.

    On a second thought, given the spectral stability of your wandering peak, I’d rule out general switching power supplies. The’re noisy, but the frequencies they emit vary greatly and move erratically. And are wide-band.

    Can’t the source be some PSU that’s near Lime?


    1. Thanks Lada for these inputs! This sound very promising. I will ask the Ops guys for more information on the It is quite difficult to rule out which of the vast number of equipment is inserting the noise, I did not receive any further feedback from NASA/ ARISS yet, but we will publish it here.


      1. I’ve recalled a badly designed linear voltage stabilisator. When badly blocked by capacitors, it tends to oscillate. Depending on surrounding inductances and capacitances, it can be very high. If the voltage on ISS is DC in the (let’s say) 80-123V range, and there is probably some equipment operating on DC, having some up to 36V input voltage, I as a designer of a PSU would be tempted to use linear regulators. High voltage transistors would be needed, cause it’s not common to get a linear regulator with an input voltage span that high, given the space compliance needed. And when designing such circuit with transistors acting as a stabiliser, it’s very easy to screw it up. And create and oscillator, modulated by (perhaps) the input voltage, yet working in DC domain. That could explain why it changes frequency even in big steps. Otherwise, I’d wonder how could the input battery voltage get past voltage regulators (if it is battery voltage leaking and modulating the noise source).

        That’s an example for illustration of one kind of scenario. One of my fantasies how it may be generated. Another one is a leak of some intermediate frequency for some communication or measurement equipment.

        One of the DAQ equipment I have come across had a place near ADC chip that was oscillating too. It was designed for tokamak hence you can see that even highly professional equipment can have issues too (in some revisions of board). But in this case, the battery voltage couldn’t leak down the circuit past voltage regulators.

        So, in my opinion, either it’s some noisy oscillating PSU (most likely linear) or some temperature induced drift past the PSU.

        You can mark time, when ISS went into shadow, when it came out, when it rotated it’s solar panels to the sun, when it (if) passed behind moon in it’s shadow. And reason about two phenomena: temperature and voltage. One of them can be ruled out by timing of drifting the noise frequency. Thermal issues would exponentially move when entering shadow, voltage induced issues would tract gradually decreasing voltage in shadow AND step-like voltage drop when some actuator, heating or whatever runs and loads the batteries, decreasing voltage due to wiring impedance.

        Combined effects are also possible – imagine an oscillating place on a PCB board nearby linear regulators. Leaking of input voltage into the drifting noise generator could be indirect – via excess heat dissipated into board by voltage regulator.


  3. Out of curiosity, do you use DC corrector in Lime? It whould wipe the center peak, which is caused by ADC DC offset in the direct conversion SDR. The center frequency (of selected frequency range) maps to 0 Hz in DC range – it’s sampled by an ADC. And the ADC’s DC offset voltage therefore looks like some frequency is present. IIR filter between ADC and FFT routine should wipe it. I believe it’s hardware based in LMS chip.

    “DC corrector” or “Automatic DC calibration mode” should remove the offset and therefore the peak at center frequency I believe. I don’t know how you set LMS chip up, but this config parameter should be somehow settable.


    1. Lada, sorry for answering so late! Things have been busy again with other projects. No, we currently do not use any DC offset correction that Soapy Power (https://github.com/xmikos/soapy_power) does not do internally. The software allows to interpolate the area of DC offset, but we figured out we would rather take the disturbed signal including DC offset than taking pre-processed data. However, we vary the center frequency of recordings to make sure that we can look at all frequencies.
      We cannot change the software itself, because this would require a lengthy software security analysis by ESA/NASA – the only thing we can change are the parameters offered by Soapy Power.


      1. See https://destevez.net/2017/04/quick-fixes-for-some-bugs-in-limesdr-drivers/

        “…DC spur hardware removal. We are used to the fact that many IQ SDR hardware have a (sometimes huge) DC spur in the centre of the passband, due to several hardware imperfections. This is also the case for the LimeSDR, but the LMS7002M has a hardware system (called RX DC correction) which is quite effective at removing the DC spur. I noted that DC spur removal was much better in LimeSuiteGUI than in GNU Radio or SoapySDR based applications.”

        “…It seems that the DC_BY_RXTSP bit that controls the RX DC correction was being overwritten…”

        So far from what I know, it’s just about setting this bit and LimeSDR hardware will report DC corrected data. Maybe there’s some command-line parameter that can be passed by SoapySDR driver to the chip and voila – it’s done.

        Maybe the software security analysis could be shortened, were it just a one line of code patch – setting this bit, presumably in SoapySDR.

        I’ll try to dive into it in some spare time.

        Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s