'The frequency'

  • I spoke with an Es'hailSat technician at IBC2018 and

    told him I consider the payload of his company's

    (to be launched) satellite with impact in/on

    amateur frequency allocations as a 'normal' amateur

    band. That is, despite different up- and downlink

    frequencies, for me it's a 'transparent' bird in the sky

    (with with some delay and technical efforts).

    Identical to 50 MHz in the late '80's or mid '90's, where

    most countries had allocated around 200 kHz.

    The NB transponder bandwidth is 250 kHz <-- similar.

    Like on most VHF/UHF/microwave bands, I reckon people

    want to collect 'squares' (locators), so I forecast

    there will be an incentive to work 'DX(-entities)' or

    'rare squares'.

    Suppose I worked I1/DB2OS from JN43 (a rare square) or
    ZP/PT9KK (in GG27) as new DXCC and 'grid', and want to

    inform the community via/by the DX-cluster ... what to

    enter as 'the frequency' ?

    Several perspectives / 'points of view' apply:

    1. the IF-frequency (e.g. 14x.170 or 43x.170 MHz)

    2. the transmit/uplink frequency (e.g.) 2400.170 MHz

    3. the downlink frequency (e.g.) 10489.670 MHz

    Ad 1. personally I think it's useless to enter your

    IF-frequency as 'the frequency'

    Ad 2. this is where you create your spectral impact
    and 'for reasons beyond your control' it's relayed

    8089.5 MHz higher

    Ad 3. the 'receive frequency' is reported (although
    there you do not generate spectral impact yourself)

    So, what is wisdom?

    • Official Post

    traditionally we always used the Downlink frequency on OSCAR's for such reports. That's where we hear the others and where we hear ourself, or the beacon.

    Operating via Es'hail-2 / P4-A will be very similar to operating OSCAR-10/13 or OSCAR-40 in apogee and there will be no Doppler shift on P4-A.

    However, if you have an unmodified LNB (without TCXO or external GPS reference) there might be large offsets in your received IF frequency... So others might not find you, unless users will "calibrate" the receive frequency using the actual upper/lower beacon frequency. Perhaps someone will write an SDR code which will automatically track the beacon while receiving other signals ;)

  • Hi Peter

    With regards to perhaps someone will write an SDR code which will automatically track the beacon while receiving other signals:

    I now have gnuradio code that measures a carrier frequency down to 1Hz in a 250kHz bandwidth. Tests have been carried out using terrestrial sources, some strong, some weak(MSF on 60k, DCF on 77.5k TDF on 162k, RBU on 66.6667k , and RWM on 4996 and 9996kHz.)

    Without a 10MHz reference my USRP N200 appeared to be up to 6-10Hz off at 9996kHz (although some of that may have been atmospheric of course). Multiply that up to 10GHz and you get 6-10kHz. With a 10MHz reference, 0Hz off!

    RWM is very weak here on certain frequencies at certain times of day, but I can still get a 'Lock' even then, next steps are to test with space sources (AO-73, Nayif-1 are targeted for later this week, and maybe JYSAT-1 as well once she launches.)

    I also have some early ranging code (Sorry Achim, only carrier at present, Spread Spectrum will be have to wait), that I'm hoping to test to at least some degree with the same spacecraft assuming I can confirm a good uplink to them

    The carrier measurement code has also been modified to measure to 1kHz rather than 1Hz. That version can run on a Raspberry Pi 3! I am planning to see how accurate I can reliably go with a Pi 3 (I do not expect to get to 1Hz, but fully expect to be able to manage somewhere between 100 and 10Hz)

    Also working on separating the different sources of frequency drift (Lack of GPS lock on uplink, LNB drift, doppler (due to dinuaral effects from the Moon) etc, and am hoping to measure the figure of eight "wobble"



  • Perhaps someone will write an SDR code which will automatically track the beacon while receiving other signals ;)

    That is a great idea, it would enable receive using a standard PLL LNB without external GPS reference, which normally is a little too unstable for SSB (and much too unstable for digital modes). When you could point at the beacon and tell the software "keep this at fixed frequency" and then tune around the passband relative to that, I think the free running PLL LNB would be good enough and the mod to feed up 25 or 27 MHz from a GPSDO would not be required.