Posts – Page 36 – Daniel Estévez

Validation of DSLWP-B orbit determination using VLBI observations

In my last post I presented my orbit determination of DLSWP-B using one lunar month of S-band Doppler measurements made by Scott Tilley VE7TIL. In this post, I will use the delta-velocity measurements from the VLBI experiment on 2018-06-10 to validate my orbital elements.

In the figures below, I compare between the sets of data: The old elements, obtained in this post:

DSLWP_B.SMA = 8762.40279943
DSLWP_B.ECC = 0.764697135746
DSLWP_B.INC = 18.6101083906
DSLWP_B.RAAN = 297.248156986
DSLWP_B.AOP = 130.40460851
DSLWP_B.TA = 178.09494681

The new elements obtained in my last post:

DSLWP_B.SMA = 8765.95638789
DSLWP_B.ECC = 0.764479041563
DSLWP_B.INC = 23.0301858287
DSLWP_B.RAAN = 313.64185464
DSLWP_B.AOP = 113.462338342
DSLWP_B.TA = 178.5519212

The elements obtained from the 20180610 tracking file published by Wei Mingchuan BG2BHC in dslwp_dev. This tracking file contains a list of ECEF position and velocity vectors for DSLWP-B. The first entry is taken as the orbital state and the orbit is propagated in GMAT, as done in this post. It would also be possible to calculate the delta-velocity directly from the ECEF data, but the results would be fairly similar and I already have a script to do it with GMAT orbit propagation.

A degree 2 polynomial fit to the VLBI observations. It turns out that the delta-velocity during the VLBI experiment can be approximated fairly well by a parabola, so it makes sense to use this as a reference. Note that this also implies that this set of delta-velocity measurements alone would be insufficient to perform orbit determination, as a degree 2 polynomial gives us 3 coefficients, while we would need to determine 6 parameters for the orbital state. Adding delta-range would only give us an extra variable, so orbit determination using VLBI would need several sets of measurements well space in time so that the orbit can be observed at different anomalies.

The figures below show a comparison between the four sets of data and the VLBI measurements.

The RMS errors are respectively 0.248m/s for the old elements, 0.167m/s for the new elements, 0.156m/s for the tracking file, and 0.137m/s for the polynomial fit. Thus, we see that the newer elements represent a good improvement over the older elements. The tracking file gives a slightly better result than the new elements. However, the new elements should give good results over a long time span of over 20 days, as we have seen in the previous post, while the orbital parameters derived from the tracking files tend to change often.

The Jupyter notebook used to make these calculations has been updated in here.

DSLWP-B first month in orbit

DSLWP-B has now been for more than a month in lunar orbit, since the orbital injection was made on May 25. Scott Tilley VE7TIL has sent me his latest batch of S-band Doppler measurements, including data for all this first lunar month. Having a complete lunar month of data is interesting for orbit determination purposes, since it gives observability of the orbit from all possible right ascension angles.
I have run my orbit determination with the new data.

DSLWP-B GMSK detector

Following the success of my JT4G detector, which I used to detect very weak signals from DSWLP-B and was also tested by other people, I have made a similar detector for the 250baud GMSK telemetry transmissions.

The coding used by the DSLWP-B GMSK telemetry follows the CCSDS standards for turbo-encoded GMSK/OQPSK. The relevant documentation can be found in the TM Synchronization and Channel Coding and Radio Frequency and Modulation Systems–Part 1: Earth Stations and Spacecraft blue books.

The CCSDS standards specify that a 64bit ASM shall be attached to each \(r=1/2\) turbo codeword. The idea of this algorithm is to correlate against the ASM (adequately precoded and modulated in GMSK). The ASM spans 256ms and the correlation is done as a single coherent integration. As a rule of thumb, this should achieve a reliable detection of signals down to around 12dB C/N0, which is equivalent to -12dB Eb/N0 or -22dB SNR in 2500Hz. Note that the decoding threshold for the \(r=1/2\) turbo code is around 1.5dB Eb/N0, so it is much easier to detect the GMSK beacon using this algorithm than to decode it. The difficulty of GMSK detection is comparable to the difficulty of JT4G decoding, which has a decoding threshold of around -23dB SNR in 2500Hz.

Here I explain the details of this GMSK ASM detector. The Python script for the detector is dslwp_gmsk.py.

DSLWP-B detected with 7 element yagi

Yesterday I tried to detect DSLWP-B using my 7 element Arrow satellite yagi. The test schedule for DSLWP-B was as follows: active between 21:00 and 23:00 UTC on 2018-06-22. GMSK telemetry transmitted both on 435.4MHz and 436.4MHz. JT4G only on 435.4MHz every 10 minutes starting at 21:10. The idea was to record the tests with my equipment and the run my JT4G detector, which should be able to detect very weak signals. Today I have processed the recorded data and I have obtained a clear detection of one of the JT4G transmissions (albeit with a small SNR margin). This shows that it is possible to detect DSLWP-B with very modest equipment.

DSLWP-B first JT4G test

Yesterday, between 9:00 and 11:00, DSLWP-B made its first JT4G 70cm transmissions from lunar orbit. Several stations such as Cees Bassa and the rest of the PI9CAM team at Dwingeloo, the Netherlands, Fer IW1DTU in Italy, Tetsu JA0CAW and Yasuo JA5BLZ in Japan, Mike DK3WN in Germany, Jiang Lei BG6LQV in China, Dave G4RGK in the UK, and others exchanged reception reports on Twitter. Some of them have also shared their recordings of the signals.

Last week I presented a JT4G detection algorithm intended to detect very weak signals from DSLWP-B, down to -25dB SNR in 2500Hz. I have now processed the recordings of yesterday’s transmissions with this algorithm and here I look at the results. I have also made a Python script with the algorithm so that people can process their recordings easily. Instructions are included in this post.

First results of DSLWP-B Amateur VLBI

In March this year I spoke about the Amateur VLBI with LilacSat-2 experiment. This experiment consisted of a GPS-synchronized recording of LilacSat-2 at groundstations in Harbin and Chongqing, China, which are 2500km apart. The experiment was a preparation for the Amateur VLBI project with the DSLWP lunar orbiting satellites, and I contributed with some signal processing techniques for VLBI.

As you may know, the DSLWP-B satellite is now orbiting the Moon since May 25 and the first Amateur VLBI session was performed last Sunday. The groundstations at Shahe in Beijing, China, and Dwingeloo in the Netherlands performed a GPS-synchronized recording of the 70cm signals from DSLWP-B from 04:20 to 5:40 UTC on 2018-06-10. I have adapted my VLBI correlation algorithms and processed these recordings. Here are my first results.

JT4G detection algorithm for DSLWP-B

Now that DSLWP-B has already been for 17 days in lunar orbit, there have been several tests of the 70cm Amateur Radio payload, using 250bps GMSK with an r=1/2 turbo code. Several stations have received and decoded these transmissions successfully, ranging from the 25m radiotelescope at PI9CAM in Dwingeloo, the Netherlands (see recordings here) and the old 12m Inmarsat C-band dish in Shahe, Beijing, to much more modest stations such as DK3WN‘s, with a 15.4dBic 20-element crossed yagi in RHCP. The notices for future tests are published in Wei Mingchuan BG2BHC’s twitter account.

As far as I know, there have been no tests using JT4G yet. According to the documentation of WSJT-X 1.9.0, JT4G can be decoded down to -17dB SNR measured in 2.5kHz bandwidth. However, if we don’t insist on decoding the data, but only detecting the signal, much weaker signals can be detected. The algorithm presented here achieves reliable detections down to about -25dB SNR, or 9dB C/N0.

This possibility is very interesting, because it enables very modest stations to detect signals from DSLWP-B. In comparison, the r=1/2 turbo code can achieve decodes down to 1dB Eb/N0, or 25dB C/N0. In theory, this makes detection of JT4G signals 16dB easier than decoding the GMSK telemetry. Thus, very small stations should be able to detect JT4G signals from DSLWP-B.

Update on DSLWP-B orbit determination

Last Sunday, I used Scott Tilley VE7TIL’s Doppler measurements of the DSLWP-B S-band beacon to perform orbit determination using GMAT. Yesterday Scott sent me the Doppler data he has been collecting during this week. I have re-run my orbit determination process to include this new data.

Below I show the Keplerian state that was determined on 2018-06-03, in comparison with the new state determined on 2018-06-10 (both are referenced to the same epoch of 2018-05-26 00:00:00 UTC).

% 20180603
%DSLWP_B.SMA = 8761.0758581
%DSLWP_B.ECC = 0.768016853537
%DSLWP_B.INC = 16.9728174682
%DSLWP_B.RAAN = 295.670653562
%DSLWP_B.AOP = 130.427472407
%DSLWP_B.TA = 178.126596496

% 20180610
DSLWP_B.SMA = 8762.40279943
DSLWP_B.ECC = 0.764697135746
DSLWP_B.INC = 18.6101083906
DSLWP_B.RAAN = 297.248156986
DSLWP_B.AOP = 130.40460851
DSLWP_B.TA = 178.09494681

It seems that there is still an indetermination of a few degrees in the inclination and right-ascension of the ascending node and a few kilometres in the semi-major axis.

The graph below shows the Doppler fit.

The Jupyter notebook where these calculations are performed can be found here.

Flashing a Vaisala RS41 radiosonde

The Vaisala RS41 radiosonde is a weather radiosonde that is currently being launched in Madrid Barajas and other sounding sites in Spain, Europe and Australia. I have already spoken about how to decode it. One of the most interesting aspects of this model is that the RS41 contains a STM32F1 ARM Cortex-M3 microcontroller, a SiLabs FSK transmitter, and a uBlox GPS receiver, whereas the older RS92 contained custom ASICs to perform these functions. Thus, it is easy to reflash this radiosonde and write custom firmware for it, giving a lot of possibilities for experimentation.

In STARcon 2018, Julián Santamaría from AEMET (the Spanish meteorological office) gave me an RS41. While I have some long-term ideas about how to use it as a propagation sounder, I have just started playing with it. In this brief note, I explain how to flash the radiosonde with custom firmware.

1KUNS-PF image decoder

A week ago, Mike Rupprecht DK3WN told me that he had discovered JPEG images in the packets transmitted by 1KUNS-PF. I’ve had some time now to take a look at the information he sent me (including KISS dumps of the packets) and add an image decoder to gr-satellites.

JPEG images are not so difficult to spot amongst binary data, since they contain JFIF in ASCII in their header (4a 46 49 46 in hex). Another telltale sign of JPEG is the ff d8 ff that marks the start of the file. Presumably this is how Mike first noticed the images.

Mike has published some information about the image packets transmitted by 1KUNS-PF and he has been posting some of the images he receives.

Below there is the hex dump of the first and second packet CSP packet of a JPEG image (note the JFIF and ff d8 ff inside the packet payload).

pdu_length = 138
contents = 
0000: 00 e2 92 42 00 00 ff d8 ff e0 00 10 4a 46 49 46 
0010: 00 01 01 01 00 00 00 00 00 00 ff db 00 43 00 0c 
0020: 08 09 0b 09 08 0c 0b 0a 0b 0e 0d 0c 0e 12 1e 14
0030: 12 11 11 12 25 1a 1c 16 1e 2c 26 2e 2d 2b 26 2a
0040: 29 30 36 45 3b 30 33 41 34 29 2a 3c 52 3d 41 47
0050: 4a 4d 4e 4d 2f 3a 55 5b 54 4b 5a 45 4c 4d 4a ff
0060: db 00 43 01 0d 0e 0e 12 10 12 23 14 14 23 4a 32
0070: 2a 32 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a
0080: 4a 4a 4a 4a 4a 4a fa 14 dc 9e

pdu_length = 138
contents = 
0000: 00 e2 92 42 00 01 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 
0010: 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 4a 
0020: 4a 4a 4a 4a ff c4 00 1f 00 00 01 05 01 01 01 01 
0030: 01 01 00 00 00 00 00 00 00 00 01 02 03 04 05 06 
0040: 07 08 09 0a 0b ff c4 00 b5 10 00 02 01 03 03 02 
0050: 04 03 05 05 04 04 00 00 01 7d 01 02 03 00 04 11 
0060: 05 12 21 31 41 06 13 51 61 07 22 71 14 32 81 91 
0070: a1 08 23 42 b1 c1 15 52 d1 f0 24 33 62 72 82 09 
0080: 0a 16 17 18 19 1a 95 64 b7 7e

It seems that all the image packets are 138 bytes long. The first four bytes are the CSP header. Then we have 16bit big-endian field which counts the number of chunk, starting by 00. The last four bytes of the packet are most likely a checksum, and the remaining bytes are the corresponding chunk of the JPEG file.

I don’t know how to detect the end of one image other than by taking note of the beginning of the next image. In fact, this is the last packet of this image:

pdu_length = 138
contents = 
0000: 00 e2 92 42 00 47 8a 00 5a 28 00 a2 81 05 14 00 
0010: 51 40 05 14 00 51 40 05 14 00 51 40 05 14 00 51 
0020: 40 c2 8a 00 28 a0 02 8a 00 28 a0 04 a2 80 0a 28 
0030: 18 51 40 05 14 00 51 40 05 14 00 51 40 05 14 c6 
0040: 14 50 01 45 00 14 50 01 45 00 14 50 01 45 00 14 
0050: 50 01 45 00 14 50 01 45 00 7f ff d9 00 00 00 00 
0060: 00 00 00 00 00 11 41 42 00 48 00 00 04 58 00 00 
0070: 00 10 00 00 00 51 d0 38 c9 54 05 ac 8f d7 00 00 
0080: bc 24 00 00 bc 24 dc bd 44 b0

The ff d9 that occurs mid-packet is the end-of-file of the JPEG file. I don’t know what to make of the rest of the data following it. Since not all of it is zero, it doesn’t look as deliberate padding. It might be the case that the satellite is sending information left over in a buffer.

The image below is the whole JPEG file contained in the packets received by Mike. It was sent using 72 chunks, for a total of 9216 bytes (at 128 bytes per chunk) and its resolution is 640×480. Most of the other images sent by 1KUNS-PF are smaller.