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.
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.
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:
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.
This is a follow-up on the series about DSLWP-B’s orbital dynamics (see part I and part II). In part I we looked at the tracking files published by Wei Mingchuan BG2BHC, which list the position and velocity of the satellite in ECEF coordinates, and presented basic orbit propagation with GMAT. In part II we explored GMAT’s capabilities to plan and perform manoeuvres, making a tentative simulation of DSLWP-B’s mid-course correction and lunar orbit injection. Now we turn to the study of DSLWP-B’s elliptical lunar orbit.
In this post we will examine the Keplerian elements of the orbits described by each of the tracking files published so far. We will also use Scott Tilley VE7TIL’s Doppler measurements of the S-band beacon of DSLWP-B to validate and determine the orbit.
This forms parts of a series of posts showing how to use GMAT to track the DSLWP-B Chinese lunar satellite. In part I we looked at how to examine and validate the tracking files published by BG2BHC using GMAT. It is an easy exercise to use GMAT to perform orbit propagation and produce new tracking files. However, note that the available tracking files come from orbit planning and simulation, not from actual measurements. It seems that the elliptical lunar orbit achieved by DSWLP-B is at least slightly different from the published data. We are already working on using Doppler measurements to perform orbit determination (stay tuned for more information).
Recall that there are three published tracking files that can be taken as a rough guideline of DSLWP-B’s actual trajectory. Each file covers 48 hours. The first file starts just after trans-lunar injection, and the second and third files already show the lunar orbit. Therefore, there is a gap in the story: how DSLWP-B reached the Moon.
There are at least two manoeuvres (or burns) needed to get from trans-lunar injection into lunar orbit. The first is a mid-course correction, whose goal is to correct slightly the path of the spacecraft to make it reach the desired point for lunar orbit injection, which is usually the lunar orbit periapsis (the periapsis is the lowest part of the elliptical orbit). The second is the lunar orbit injection, a braking manoeuvre to get the spacecraft into the desired lunar orbit and adjust the orbit apoapsis (the highest part of the orbit). Without a lunar orbit injection, the satellite simply swings by the Moon and doesn’t enter lunar orbit.
In this post we will see how to use GMAT to calculate and simulate these two burns, so as to obtain a full trajectory that is consistent with the published tracking files. The final trajectory can be seen in the figure below.
DSLWP-B orbit from trans-lunar injection to lunar orbit injection and elliptical orbit
As you may well know, on May 20 a CZ-4C rocket launched from Xichang, China, to deliver Queqiao, the Chang’e 4 relay satellite, to the Moon. Queqiao is a communications relay satellite designed to orbit the L2 point of the Earth-Moon system, supporting the future Chang’e 4 rover that will land on the far side of the Moon. From the L2 point, Queqiao has a good view of both the Earth and the far side of the Moon.
This launch was shared by the DSLWP-A and -B microsatellites, also called Longjiang 1 and 2. These two satellites are designed to be put on a 200 x 9000km lunar orbit and their main scientific mission is a proof of concept of the Discovering the Sky at Longest Wavelengths experiment, a radioastronomy HF interferometer that uses the Moon as a shield from Earth’s interferences.
The DSLWP satellites carry an Amateur radio payload which consists of a 250 baud (or 500 baud) GMSK transmitter which uses \(r=1/2\) or \(r=1/4\) turbo codes, a JT4G beacon, and a camera allowing open telecommand (such as the camera on BY70-1 and LilacSat-1). A year ago, while the radio system was being designed, I wrote a post about DSLWP’s SSDV downlink, which transmits the images taken by the camera.
Wei Mingchuan BG2BHC, who is part of the DSLWP team, has been posting updates on Twitter about the status of the mission. If you’ve been following these closely, you’ll already know that unfortunately radio contact with DSLWP-A was lost on the UTC afternoon of May 22. Since then, all tries to contact the spacecraft have failed (the team will publicly release more information about its fate soon). On the other hand, DSLWP-B has been successfully injected into lunar orbit and is now orbiting the Moon since the UTC afternoon of May 25.
More posts will follow about the radio communications of DSLWP, but this series of posts will deal with the orbital dynamics part of the mission. In this first post, I will look at the tracking files released so far by Wei, which can be used to compute the spacecraft’s position and Doppler.
A few days ago, I spoke about my tries to decode telemetry from 1KUNS-PF. Since then, Mike Rupprecht DK3WN has managed to get in contact with Lorenzo Frezza, from the satellite team in La Sapienza, who has given us very valuable and detailed information regarding the telemetry. This has allowed me to include a fully working decoder for 1KUNS-PF in gr-satellites. Many thanks to Lorenzo for his collaboration.
Just after reading Lorenzo’s description of the coding, where he mentions Golay and Reed Solomon, I noticed that 1KUNS-PF was using the NanoCom AX100 transceiver in ASM+Golay mode. This is the same mode that the Chinese TY-2 and TY-6 satellites use, and I’ve already spoken about ASM+Golay mode in a post about TY-2. The only difference between these Chinese satellites and 1KUNS-PF is that 1KUNS-PF is currently using 1k2 (but perhaps might change to 9k6 in the future), whereas the Chinese satellites use 9k6. With this in mind, it is very easy to adapt the decoder for TY-2 to obtain a decoder for 1KUNS-PF.
Regarding my previous tries, note that I had tried to identify the syncword as 11011001111010010101110001000011, whereas the correct syncword is 10010011000010110101000111011110. My syncword candidate was inverted (this might be a problem with sideband inversion in the recording by Mike that I used) and off by one bit (due to the difficulty of deciding where the preamble ends).
After reading Lorenzo’s email, it has been a very easy and fast task to add a fully working decoder to gr-satellites, while before I wasn’t optimistic at all about the difficulty of decoding this satellite. This makes me think about two things:
We should really check the usual suspects (i.e., popular modems) when trying to reverse-engineer some new satellite. I could have found this out by myself just by trying the AX100 ASM+Golay decoder.
Some advice IARU Satcoord: if a satellite uses some popular hardware (for instance the U482C or the AX100) or some popular standard (CCSDS), please list that in the frequency coordination sheet. Lorenzo’s email could have been well summarised in the sentence “1KUNS-PF uses a NanoCom AX100 in the ASM+Golay mode”, and then we would have been able to decode this satellite without any effort.
Lorenzo has also sent us the telemetry format, which is rather simple. Using that, I’ve been able to add a telemetry decoder also. The new decoder for 1KUNS-PF can be found as sat_1kuns_pf.grc in gr-satellites. I have also added a sample recording to satellite-recordings. The telemetry in one of the packets in the sample recording is as follows:
Following a discussion with Carlos Cabezas EB4FBZ over on the Spanish telegram group Radiofrikis about using Codec2 with DMR, I set out to study the error correction used in DMR, since it quickly caught my eye as something rather interesting. As some may know, I’m not a fan of using DMR for Amateur Radio, so I don’t know much about its technical details. On the other hand, Carlos knows a lot about DMR, so I’ve learned much with this discussion.
In principle, DMR is codec agnostic, but all the existing implementations use a 2450bps AMBE codec. The details of the encoding and FEC are taken directly from the P25 Half Rate Vocoder specification, which encodes a 2450bps MBE stream as a 3600bps stream. Here I look at some interesting details regarding the FEC in this specification.
Irazú and UBAKUSAT both use standard 9k6 FSK packet radio (AX.25 with G3RUH scrambler), so they can be decoded with direwolf and many other packet radio decoders. However, no one has been able to decode 1KUNS-PF yet, due to the lack of information about the modulation and coding used. Mike Rupprecht DK3WN has some information about 1KUNS-PF, including a recording of some packets. I’ve taken a look at Mike’s recording and here are my findings.
Please read the title of this post in a light-hearted way: the STARcon 2018 Scientific and Technical Amateur Radio congress that took place last weekend in Murcia turned out to be a huge success. Personally, the weekend has been an intense but extremely rewarding experience.
Recently I have added a telemetry parser to the S-NET decoder in gr-satellites. Recall that I have talked about S-NET and its decoder in a previous post. To implement this telemetry parser I have used the information in Mike Rupprecht DK3WN’s web, some additional information shared by the S-NET team, as well as some recordings done by Mike. Many thanks to Mike and the S-NET team for all their help. Here I describe a few details about the telemetry.
