Virgin Orbit LauncherOne - ELaNa 20 - 2021-01-17

Yeah, I wasn’t involved in the comms system design, but I do recall seeing a strongly worded letter from the ITU to the FCC after the FCC gave us our grant.

I could understand it being allowed if the spacecraft was only transmitting in response to commands from the ground. That’s how a few commercial sat licenses work here in Australia…

But given it’s beaconing over countries where those frequencies are in use for other commercial services, I can understand why the ITU would be a little pissed… and yet you continued to use those frequencies anyway?!

1 Like

Hi, @patrickwalton

I’m going to add PICs in DB so people, that use it, will be able to find your frequency, but unfortunately there aren’t stations that support this frequency in SatNOGS Network.

@dryerzinia
I’ve fixed the wrong frequency in both DB and Network and I fixed it in the initial post to resolve any future confusion.

There are some initial TLE from spacetrack with NORAD ID 47309. All the satellites follow this object in Network.

1 Like

I think I gave you the wrong impression about what happened. The university (first time doing a CubeSat) worked with a consultant assigned to them by its NASA integrator to get the frequencies. Frequency licensing and coordination was left to the consultant and were kept pretty opaque to the university. It wasn’t until after the satellite was already delivered and I was moved on that I started working on a project on my own and found that letter and realized what had been done.

1 Like

Thanks @fredy for adding it. I didn’t think it would hurt to put the details out there. Certainly wish the team had worked with the SatNogs community sooner and avoided bad bands.

2 Likes

Hi Patrick!

Regarding PIC-A & PIC-B, what is the modulation on those 900 MHz downlinks? And ref. the frequency ranges you listed (903.65-903.95) & (903.25-903.55) is that how WIDE the signals are, do they frequency-hop within that range, or what?

Thanks and good luck!

-Scott, K4KDR

2 Likes

I’m told the modulation is 8-bit GMSK. Baud rate is 19.2 kbps. Sampling rate is 8 samples / symbol.

I’m going to say that is how wide the signals are. I’m pretty sure there isn’t any frequency hopping.

Thanks Scott!

1 Like

There are more TLE sets from spacetrack:

Currently:
MiTEE one of: 47313, 47314(selected in Network), 47315
CP12 one of: 47311(selected in Network), 47312

TLE sets are still marked as “TBA - TO BE ASSIGNED”, so they may change or swap.

@pierros has also received CAPE-3 and it fits better to 47309.

Also by @pierros using strf tools, a TLE set for CP12:

CP12
1 47311U          21018.20600000  .00000000  00000-0  00000-0 0    09
2 47311  60.6985 133.3369 0014148 265.9295 186.0084 15.21029718    09
1 Like

Frequency for CAPE-3 is now changed to 437.325 MHz. Source:

PS the coordinated one was 435.325, maybe a typo?

Please correct 43713 to 47313, etc.

1 Like

Fixed! Thanks! :slight_smile:

After the change in frequency, CAPE-3 is the third satellite that is received from ELaNa 20 in Network.

Hello, i’v found in DB

99752 - VR3X-C Transmitter Mode U - CW 915.600 MHz CW None Unknown active
99750 - VR3X-A Transmitter Mode U - CW 915.600 MHz CW None Unknown active
99751 - VR3X-B Transmitter Mode U - CW 915.600 MHz CW None Unknown active

My station 972 can be use for this frequency but satellite not appear in new observation view…

Hi @michel these satellites belong to another launch, check more details in SpaceX F9 Transporter-1 (21 Jan 2021 TBC)

1 Like
  • PIC-A and PIC-B have been added in DB with their transmitters.

  • From the rest of the ELaNa 20 mission, there are some new TLE from spacetrack, still nothing stable so we continue following the same objects in DB.

  • Still, only MiTEE, CAPE-3 and CP12(EXOCUBE-2) have been received.

  • CAPE-3 wrong frequency was a typo in IARU entry:

1 Like

Hey Scott, the PICs team tells me the signals are about 150kHz to 200 kHz wide, but yeah no frequency hopping

1 Like

150-200 kHz wide for a 19.2kbit/s GMSK signal is going to make it even harder to decode reliably too. (e.g 10x more noise bandwidth than is really necessary for that bit-rate).
It’s also going to make it difficult to see on a SatNOGS waterfall, as SatNOGS assumes a modulation index of around 1 (e.g. signal bandwidth is roughly equal to the baud rate), and sets the observation sample rate accordingly.

What is the transmitter chip used, and what was the engineering decisions around using such a wide bandwidth?

It’s not actually that wide. That was the original requested allocation, when the design was somewhat different. The frequency deviation is actually configured to be 28.8khz, and is using a Semtech SX1278 transmitter chip, in 2-GMSK mode, with all other options default (or very close to it).

The GNURadio based receiver for the system that I have been peeking at actually has a band pass filter at a little less than 40kHz wide, so I suspect a bandwidth somewhere around there is more appropriate.

Sync word is 0x1ACFFC1D. Reed Solomon encoding is done as specified in the CCSDS TM Sync Blue Book. The decoded packets first 12 bytes are an SDLP and SPP header, and the remaining bytes are all ASCII, starting with the WI2XZG callsign.

Sorry for the slow information recall, I haven’t been directly involved in a couple years now.
Thanks!
J

1 Like

Thanks for the info! We could dearly use a flowgraph capable of demodulating the FSK/GMSK modes coming out of an SX1278… any idea where that GNU Radio flowgraph can be found?

Any help appreciated!

-Scott, K4KDR

I have pulled out the flowgraphs relevant, as well as supporting parts, and put them into a github repository here: https://github.com/jholtom/gr-flowgraphs
The only truly strange part is the python implemented FLL.

Feel free to contact me on that repository, or at the e-mail listed on that profile if you have questions or issues with them, or I left out a part. I am also on freenode (jholtom) or matrix (@jholtom:grandcanyon.holtom.me)

Thanks!
J, KF5WPA

3 Likes