The communications system of 3CAT-1 uses a Texas Instrument CC1101 FSK transceiver chip, which is very similar to the CC1125 used in Reaktor Hello World. It transmits a 9k6 FSK telemetry beacon in the 70cm Amateur band. An interesting thing about this beacon is that it is powered by a temperature gradient that generates naturally within the satellite. A Peltier module is used to collect energy from the gradient and power the communications module. This is called “eternal self-powered beacon demonstrator” by the designers of the satellite, since it doesn’t depend on batteries or solar cells.
I have been in contact with Juan Fran Muñoz from NanoSat Lab, who has been kind enough to send me a telemetry recording for 3CAT-1. With this, and following my implementation of the Reaktor Hello World decoder, I have added a decoder for 3CAT-1 to gr-satellites.
It is again the beginning of the month, which means that the Earth will be in view of the Inory eye camera on board DSLWP-B. As usual, I have updated my camera planning notebook to compute the location of the Moon and Earth, as seen from the camera.
Wei has already scheduled observations on 2018-12-06 11:20 UTC and 2018-12-07 08:30 UTC. On each of these observations, an image will be taken at the start of the observation and the UHF transmitter will be activated for 2 hours.
I have used the 20181128 tracking file from dslwp_dev as orbital state for the calculations. As the date of the observations comes nearer, I might rerun the computations with updated ephemeris data, but this time it doesn’t seem critical to estimate the orbit with precision. In November, there were occultations of the Earth behind the lunar disc, and the times for these depended a lot on the orbital state. In December there will be no occultations, however.
The figure below shows the prediction for the camera view in the scheduled observations. On the 6th, the Earth will come close to the edge of the Moon. On the 7th, the Earth will be closest to the camera centre since we started planning and taking images in October.
Reaktor Hello World is a 2U cubesat built by the Finnish company Reaktor Space Lab as a test of their cubesat platform and demonstration of the first miniature infrared hyperspectral imager. It was launched on November 29 by a PSLV from Satish Dhawan Space Centre, together with several other cubesats. It transmits 9k6 GFSK telemetry in the 70cm Amateur satellite band.
The satellite uses a Texas Instruments CC1125 FSK transceiver chip. This is very similar to the CC1101 that I used a few years ago in my 70cm Hamnet experiments, so I already knew the coding and features of this chip quite well. The satellite team has a Github repository with a GNU Radio decoder based on the gr-cc11xx decoder block for the CC11xx series of chips. Since gr-cc11xx doesn’t seem to be maintained anymore, I wanted to implement my own CC11xx decoder in gr-satellites and use it to decode Reaktor Hello World.
As an Amateur Radio operator experienced in the field of Amateur satellites and in the space industry, I am publishing this open letter to motivate and request the release of the complete technical specifications for the telemetry that the ESEO satellite will transmit in the frequency 437.00MHz, in the 70cm Amateur satellite band.
According to the ITU Radio Regulations for the Amateur and Amateur-satellite Services, “Transmissions between amateur stations of different countries shall not be encoded for the purpose of obscuring their meaning, except for control signals exchanged between earth command stations and space stations in the amateur-satellite service.” A strict interpretation of this rule means that the specifications of all digital protocols used by Amateur stations should be publicly available, so that anyone is able decode the data. The use of protocols with undisclosed specifications can be seen as a try to obscure the meaning of the data.
Continuing with the ITU Radio Regulations, the definition of the Amateur service describes it as “a radiocommunication service for the purpose of self-training, intercommunication and technical investigations carried out by amateurs, that is, by duly authorized persons interested in radio technique solely with a personal aim and without pecuniary interest.” In my opinion, the use of protocols with undisclosed specifications goes against the spirit of this definition, in particular, it can hinder technical investigations and self-training.
For these reasons, I am a strong proponent of requiring that all the protocols used by Amateur stations have publicly available specifications, allowing anyone to decode the data, study the protocols, learn, experiment and improve upon the state of the art. In view of the paragraphs cited above, publishing the full specifications so that anyone can build a complete decoder independently is both an obligation and the best practice.
This is especially important for Amateur satellites, which often use at least some form of ad-hoc protocols in their telemetry downlink. The public specifications for this telemetry downlink are often incomplete or inexistent. As an attempt to remedy this situation, I develop gr-satellites, which aims to decode every satellite that transmits in Amateur bands. Developing this tool usually requires some reverse engineering, due to the lack of documentation. Some similar tools by other Amateurs are the Soundmodem decoders by Andrey Kopanchuk UZ7HO and the Telemetry decoders by Mike Rupprecht DK3WN, who face similar challenges.
A large number of Amateur operators and enthusiasts throughout the world routinely use these tools to decode telemetry from Amateur satellites, contributing valuable data to the satellite operators through the SatNOGS network and other databases. Also, these tools can be an invaluable reference to educational or research institutions or companies that start building satellites.
Regarding the ESEO satellite, I believe that the educational and collaborative aims of the project is in line with the self-training and investigation aspects of the Amateur service. Thus, publishing complete specifications for the telemetry downlink seems the best practice to respect the goals of the project.
Additionally I think ESA should be held to the highest standards and be exemplary in publishing the specifications. This is specially important, since currently it is often hard to get documentation from the developers of many Amateur satellites.
While some documentation for ESEO has already been published, this is not enough to build a complete telemetry decoder. For instance, the equations needed to interpret the raw telemetry readings such as voltage, current and temperature are missing.
I hope that this letter serves to raise awareness about the need of publishing specifications for the protocols used in the Amateur service and that a complete set of documentation is published for ESEO, allowing Amateurs to build their own telemetry decoders.
However, so far the reflection has been detected by hand by looking at the recording waterfalls. We don’t have any statistics about how often it happens or which conditions favour it. I want to make some scripts to process all the Dwingeloo recordings in batch and try to extract some useful conclusions from the data.
Here I show my first script, which computes the power of the direct and reflected signals (if any). The analysis of the results will be done in a future post.
Es’hail 2 is the second communications satellite operated by the Qatari company Es’hailSat. It was built by Mitsubishi Electric Corporation (MELCO). It carries several Ku and Ka band transponders intended for digital television, Internet access and other data services. It also carries an Amateur radio payload designed by AMSAT-DL, in collaboration with the Qatar Amateur Radio Society. The payload has two transponders, with S-band uplink and X-band downlink. One of the transponders is 250kHz wide and intended for narrowband modes, and the other one is 8MHz wide and intended for DVB-S and other wideband data modes.
SpaceX live-streamed the launch, and the recording can be seen in YouTube. Today, Space-Track has published the first TLEs for Es’hail 2 and the second stage of the Falcon 9 rocket. Here I look at these TLEs using GMAT.
Lately, I have been testing the GPSDO that I will use to discipline my Es’hail 2 groundstation. One of the tests I have done is to measure the frequency of the TCXO that I use in my Hermes-Lite 2.0beta2 over a few days. Here I show the details of the measurement process and how to process the data in Python.
In previous posts, I have already spoken about the chance of DSLWP-B taking images of the Moon and Earth during the beginning of November. The window to take these images was between November 6 and 9. This window included the possibility of taking an Earthrise image, with the Earth appearing from behind the Moon.
The planning for the activations of the Amateur payload made by Wei Mingchuan BG2BHC was as follows.
7 Nov 2018 08:13 to 7 Nov 2018 10:13 8 Nov 2018 09:40 to 8 Nov 2018 11:40 9 Nov 2018 12:00 to 9 Nov 2018 14:00 10 Nov 2018 14:00 to 10 Nov 2018 16:00 11 Nov 2018 13:30 to 11 Nov 2018 15:30
On November 7, from 8:13 to 9:33 UTC, a total of 9 images with 10 minutes of spacing between each would be taken. These images would be downloaded during the activations on the next days. As usual, an image would also be taken when the Amateur payload powered up on November 8 to 11, but the main focus was on downloading the sequence of images taken on November 7. This is a complete report of the images taken and downloaded.
In my last post, I detailed the DSLWP-B camera planning for the beginning of November. There, I used orbital state taken from the 20181027 tracking file to compute good times to take images of the Moon and the Earth, especially looking for an Earthrise-like image.
Now that the planned dates are closer, it is good to rerun the calculations with a newer orbital state. It turns out that there has been an important change in the mean anomaly, which shifts all the predictions by a few hours.
I have spoken in other occasions about planning the appropriate times to take pictures with the DSLWP-B Inory eye camera. In the beginning of October there was a window that allowed us to take images of the Moon and Earth. A lunar month after this we have new Moon again, so it is an appropriate time to take images with the camera.
This time, the Moon will pass nearer to the centre of the image than on October, and at certain times the Earth will hide behind the Moon, as seen from the camera. This opens up the possibility for taking Earthrise pictures such as the famous image taken during the Apollo 8 mission.
I have updated my camera planning Jupyter notebook to compute the appropriate moments to take images. The image below shows my usual camera field of view diagram.
The vertical axis represents the angular distance in degrees between each object and the centre of the image (Assuming the camera is pointing perfectly away from the Sun. In real life we can have a couple degrees of offset). The red lines represent the limits of the camera field of view, which are measured between the centre and the nearest edge, and between the centre and one corner. Everything between these two lines will only appear if the camera rotation is adequate. Everything below the lower line is guaranteed to appear, regardless of rotation.
We see that between November 6th and November 9th there are four times when the camera will be able to image the Earth and the Moon simultaneously. On the 6th it is almost guaranteed that the Earth will appear inside the image, and on the 9th it depends on the orientation of the camera. On the 7th and 8th it is guaranteed that the Earth will be in the image.
To compute appropriate times for taking an Earthrise picture, I have made the graph below. This shows the angular distance between the Earth and the rim of the Moon. If the distance is negative, the Earth is hidden by the Moon. We see that the Earth hides behind the lunar disc on each of the four days mentioned above.
In the figures below, we zoom in each of the events. In this level of zoom we can plot the “inner” and “outer” Earth rim, so we can see when the Earth is partially hidden by the Moon.
On November 6th the situation is the most interesting in my opinion. It turns out the the Earth will not even hide completely between the Moon. In theory, a tiny sliver will remain visible. Also, it will take more time for the Earth to hide behind the Moon and then reappear. As we will see, the next days this will happen faster. Here, it takes 15 minutes for the Earth to hide, and another 15 minutes to reappear. It spends 10 minutes almost hidden.
It can be a good idea to take a series of 10 images with an interval of 5 minutes between each image, and spanning from 12:40 UTC to 13:30 UTC, to get a good coverage for this event.
On November 7th the Earth goes deeper into the lunar disc, taking 5 minutes to hide, spending 70 minutes hidden, and taking 10 minutes to reappear.
On November 8th the Earth goes even deeper into the lunar disc. It takes around 7 minutes to hide, spends 105 minutes hidden and takes 10 minutes to reappear.
On November 9th the configuration is quite similar to November 7th, but the hiding speed is slower. It takes 15 minutes to hide, spends 100 minutes hidden and takes 15 minutes to reappear.
Overall, I think that the best would be to take a good series of images on November 6th, since this shallow occultation is a rarer event. The challenge will be perhaps to download all the images taken during these days. On average, I think we are downloading around 2 new images per 2 hour activation, taking into account repeats due to lost blocks and dead times. DSLWP-B is able to store 16 images onboard, and every time the UHF transmitter comes on, a new image is taken, overwriting an old image (more information in this post). Thus, if we take many images during these days, we have the danger of overwriting some when trying to download them over the next few days.
Perhaps a good strategy is to arrange for a series of 10 images to be taken on the 6th, and then programming the UHF transmitter to take an image as the Earth comes out of its occultation on the 7th, 8th and 9th. In this way, the 2 hour periods of these three days can be used to download some of the images taken on the 6th, and there are still 3 images of margin in the buffer in case something goes wrong during the downloads over the next few days.
