Posts – Page 34 – Daniel Estévez

DSLWP-B talk in IberRadio

As you may already know if you follow me on Twitter, on Saturday September 15 I was in Ávila in the IberRadio Spanish Amateur Radio fair giving a talk about DSLWP-B. The talk was well received and I had quite a full room. I recorded my talk to upload it later to YouTube as I did last year.

Since I know that many international people would be interested in this talk and the talk was in Spanish, I wanted to prepare something in English. As I would be overlaying the slides on the video (since the video quality is quite poor and it is impossible to see the projected slides), I thought of overlaying the slides also in English and adding English subtitles.

Doing the subtitles has been a nightmare. I have been working on this non-stop since Sunday morning (as my free time allows me). I intended to use YouTube’s transcript and auto-sync feature, where you provide a transcript (in the video’s original language) and presumably an AI will auto-sync this to the video’s audio. I say presumably because in my case the auto-sync was a complete failure, so I had to resync everything by hand.

Also, since I have listened to the video over and over, I have gotten a bit bored of my own voice and noted some expressions and words that I tend to use a lot. I think this is good, because now I am more conscious when talking in public and can try to avoid using these expressions so much.

In any case, here is the final result. First you have the video with English slides:

And also you have the video with Spanish slides:

Remember that you can use either Spanish or English subtitles with any of the videos. Also, I have the translation contributions enabled, so feel free to provide subtitles in your own language if you wish.

The PDF slides for the talk can be downloaded in Spanish here and in English here.

DSLWP-B clock running late

This Wednesday, a DSLWP-B test was done between 04:00 and 06:00 UTC. During this test, a few stations reported on Twitter that they were able to receive the JT4G signal correctly (they saw the tones on the waterfall) but decoding failed.

It turns out that the cause of the decoding failures is that the DSLWP-B clock is running a few seconds late. Thus, the JT4G transmission starts several seconds after the start of the UTC minute and so the decoding fails, since WSJT-X only searchs for a time offset of a few seconds.

Lunar orbit perturbations and DSLWP-B

Ever since simulating DSLWP-B’s long term orbit with GMAT, I wanted to understand the cause of the periodic perturbations that occur in some Keplerian elements such as the eccentricity. As a reminder from that post, the eccentricity of DSLWP-B’s orbit shows two periodic perturbations (see the figure below). One of them has a period of half a sidereal lunar month, so it should be possible to explain this effect from the rotation of the Moon around the Earth. The other has a period on the order of 8 or 9 months, so explaining this could be more difficult.

In this post I look at how to model the perturbations of the orbit of a satellite in lunar orbit, explaining the behaviour of the long term orbit of DSLWP-B.

Playing with LilacSat-1

Even though the cubesat LilacSat-1 was launched more than a year ago, I haven’t played with it much, since I’ve been busy with many other things. I tested it briefly after it was launched, using its Codec2 downlink, but I hadn’t done anything else since then.

LilacSat-1 has an FM/Codec2 transponder (uplink is analog FM in the 2m band and downlink is Codec2 digital voice in the 70cm band) and a camera that can be remotely commanded to take and downlink JPEG images (see the instructions here). Thus, it offers very interesting possibilities.

Since I have some free time this weekend, I had planned on playing again with LilacSat-1 by using the Codec2 transponder. Wei Mingchuan BG2BHC persuaded me to try the camera as well, so I teamed up with Mike Rupprecht DK3WN to try the camera this morning. Mike would command the camera, since he has a fixed station with more power, and we would collaborate to receive the image. This is important because a single bit error or lost chunk in a JPEG file ruins the image from the point where it happens, and LilacSat-1 doesn’t have much protection against these problems. By joining the data received by multiple stations, the chances of receiving the complete image correctly are higher.

Aircraft reflections of a 2.3GHz beacon

A couple months ago, Andrés Calleja EB4FJV installed a 2.3GHz beacon in his home in Colmenar Viejo, Madrid. The beacon has 2W of power, radiates with an omnidirectional antenna in the vertical polarization, and transmits a tone and CW identification at the frequency 2320.865MHz.

Since Colmenar Viejo is only 10km away from Tres Cantos, where I live, I can receive the beacon with a very strong signal from home. The Madrid-Barajas airport is also quite near (15km to the threshold of runway 18R) and several departure and approach aircraft routes pass nearby, particularly those flying over the Colmenar VOR. Therefore, it is quite easy to see reflections off aircraft when listening to the beacon.

On July 8 I did a recording of the beacon from 10:04 to 11:03 UTC from the countryside just outside Tres Cantos. In this post I will examine the aircraft reflections seen in the recording and match them with ADS-B aircraft position and velocity data obtained from adsbexchange.com. This will show the locations and trajectories which produce reflections strong enough to be detected.

Amateur stations in the Perseids recording

In one of my latest posts I analysed the meteor scatter pings from GRAVES on a recording I did on August 11 (see that post for more details about the recording). The recording covered the frequency range from 142.5MHz to 146.5MHz and was 1 hour and 34 minutes long. Here I look at the Amateur stations that can be heard in the recording. Note that Amateur activity in meteor scatter communications increases considerably during large meteor showers, due to the higher probabilities of making contacts.

Weird repair of the day: u-blox LEA-5S I2C interface

I have a DF9NP 10MHz GPSDO that is based on a u-blox LEA-5S GPS receiver. Essentially, the LEA-5S outputs an 800Hz signal that is used to discipline a 10MHz VCTCXO with a PLL. The LEA-5S doesn’t have persistent storage, so an I2C EEPROM is use to store the settings across reboots.

Lately it seemed that the reading of the settings from the EEPROM had failed. The u-blox was always booting with the default settings. This prevents the GPSDO from working, since the default for the timepulse signal is 1Hz instead of 800Hz. Here is the summary of my troubleshooting session and the weird repair that I did.

Decoding TANUSHA-3

On August 15, during a Russian EVA on the ISS, a total of four Russian nanosatellites were deployed by hand. Although different online sources give incomplete and contradictory information about which satellites were released, it seems that they were SiriusSat 1 and 2, from the Sirius educational centre in Sochi, and Tanusha 3 and 4 from the Southwest State University in Kursk (see also Jonathan McDowell’s space report).

The SiriusSats are using 4k8 FSK AX.25 packet radio at 435.570MHz and 435.670MHz respectively, using callsigns RS13S and RS14S. The Tanushas transmit at 437.050MHz. Tanusha-3 normally transmits 1k2 AFSK AX.25 packet radio using the callsign RS8S, but Mike Rupprecht sent me the other day a recording of a transmission from Tanusha-3 that he could not decode.

It turns out that the packet in this recording uses a very peculiar modulation. The modulation is FM, but the data is carried in audio frequency phase modulation with a deviation of approximately 1 radian. The baudrate is 1200baud and the frequency for the phase modulation carrier is 2400Hz. The coding is AX.25 packet radio.

Why this peculiar mode is used in addition to the standard 1k2 packet radio is a mystery. Mike believes that the satellite is somehow faulty, since the pre-recorded audio messages that it transmits are also garbled (see this recording). If this is the case, it would be very interesting to know which particular failure can turn an AFSK transmitter into a phase modulation transmitter.

I have added support to gr-satellites for decoding the Tanusha-3 phase modulation telemetry. To decode the standard 1k2 AFSK telemetry direwolf can be used. The decoder flowgraph can be seen in the figure below.

The FM demodulated signal comes in from the UDP source. It is first converted down to baseband and then a PLL is used to recover the carrier. The Complex to Arg block recovers the phase, yielding an NRZ signal. This signal is lowpass filtered, and then clock recovery, bit slicing and AX.25 deframing is done. Note that it is also possible to decode this kind of signal differentially, without doing carrier recovery, since the NRZI encoding used by AX.25 is differential. However, the carrier recovery works really well, because there is a lot of residual carrier and this is an audio frequency carrier, so it should be very stable in frequency.

The recording that Mike sent me is in tanusha3_pm.wav. It contains a single AX.25 packet that when analyzed in direwolf yields the following.

RS8S>ALL:This is SWSU satellite TANUSHA-3 from Russia, Kursk<0x0d>
------
U frame UI: p/f=0, No layer 3 protocol implemented., length = 68
 dest    ALL     0 c/r=1 res=3 last=0
 source  RS8S    0 c/r=0 res=3 last=1
  000:  82 98 98 40 40 40 e0 a4 a6 70 a6 40 40 61 03 f0  ...@@@...p.@@a..
  010:  54 68 69 73 20 69 73 20 53 57 53 55 20 73 61 74  This is SWSU sat
  020:  65 6c 6c 69 74 65 20 54 41 4e 55 53 48 41 2d 33  ellite TANUSHA-3
  030:  20 66 72 6f 6d 20 52 75 73 73 69 61 2c 20 4b 75   from Russia, Ku
  040:  72 73 6b 0d                                      rsk.
------

The contents of the packet are a message in ASCII. The message is of the same kind as those transmitted in AFSK.

Detecting meteor scatter pings from GRAVES during the Perseids

GRAVES is a French space surveillance radar that transmits with very high power at 143.050MHz. It is easy to receive it from neighbouring countries via meteor scatter. During this year’s Perseids meteor shower I did a recording of GRAVES and the 2m Amateur band for later analysis. The recording was done at 08:56 UTC of Saturday 12th August and it is about 1 hour and 34 minutes long. Here I present an algorithm to detect and extract the meteor scatter pings from GRAVES.

Trying to make the DSLWP-B GMSK decoder more robust

If you’ve being following my latest posts, probably you’ve seen that I’m taking great care to decode as much as possible from the SSDV transmissions by DSLWP-B using the recordings made at the Dwingeloo radiotelescope. Since Dwingeloo sees a very high SNR, the reception should be error free, even without any bit error before Turbo decoding.

However, there are some occasional glitches that corrupt a packet, thus losing an SSDV frame. Some of these glitches have been attributed to a frequency jump in the DSLWP-B transmitter. This jump has to do with the onboard TCXO, which compensates frequency digitally, in discrete steps. When the frequency jump happens, the decoder’s PLL loses lock and this corrupts the packet that is being received (note that a carrier phase slip will render the packet undecodable unless it happens very near the end of the packet).

There are other glitches where the gr-dslwp decoder is at fault. The ones that I’ve identify deal in one way or another with the detection of the ASM (attached sync marker). Here I describe some of these problems and my proposed solutions.