Introduction
GreenCube is a new satellite that was designed by S5Lab and there are lots of interesting parts to this one. Most amateur radio satellites we usually play with is in Leo orbit, meaning its only a couple hundred kilometers away. The Greencube satellite is in Meo orbit with a distance of 5800+ km. This makes it a bit more challenging. The original goal of the satellite is to demonstrate an autonomous biological laboratory for growing plants in space which is very important for future long distance space travels.
Along with the very cool experiment, the satellite also hosts an amateur radio digipeater and because of the distance it gives us a very nice big footprint to play in. Here is a comparison of footprints between ISS which is in Low earth orbit, QO-100 which is in Geosynchronous orbit and the GreenCube (MTCube-2) which is in Medium earth orbit.
Below is a bunch of notes of the various software, hardware I used to play with this satellite. This is less of a tutorial, but rather just notes for my future self 😉 Maybe it will help others get on the air as well. If you need more detail into any specific sections, then leave a comment or find me here.
Equipment Used
On the antenna side I’m running my homebrew rotator project with a 70cm (UHF) Wimo X-Quad antenna. I originally tried to receive this satellite without any pre-amplifier and even though I could see the data packets I could not decode it. I added a SHF Low Noise Pre-Amplifier (MV 342-VOX) into the mix and only then I could successfully decode it.
The pre-amplifier is hooked up (Relay Board on Raspberry PI) to my Ground Station Node-Red Dashboard so that I can switch it on and off as needed.
There are others though that use something as simple as the common dual band arrow antenna, so lots of possibilities.
Initially I started listening with an SDR (Airspy SDR) to try receive and decode the telemetry, from there onwards I moved on to using an ICOM 9700 hooked up to my computer for both reception and transmitting.
Software – Tracking/Doppler
Depending on what you want to do there are lots of bits of pieces of software involved with playing with this satellite. There are also lots of different ways of doing this, depending on your hardware and operating system. You need to be able to predict the satellite position, control the doppler on your radio/sdr. The received signal goes into a TNC that decodes it and makes it available for other software, like the digipeater client, or telemetry viewer and sending the data to SatNOGS.
For tracking and radio doppler control I used Gpredict. I decided not to use my own satellite server for this one as I’m not sure yet about the accuracies of the tracking on Meo objects. Since the initial reception was done with a SDR I used sdr++ which has a built in rigctl server. This allows Gpredict to set the frequencies during the pass.
My config on Gpredict for the radio interface is
As Gpredict tracks the satellite it will also apply the doppler to the frequency in sdr++
If all goes well on your next pass and then you will see data packets received from the satellite.
Our next step now is to see if we can decode these packets. For this you need a TNC/Sound Modem,
Software – Sound Modem/TNC
To decode the packets we use the SoundModem software developed by UZ7HO. You can download it here. It includes a version for fm reception as well as ssb reception. I’ve only tried the ssb tnc.
The download also includes the digipeater client (more on that later). If you are using an SDR to receive the packets then you need to use a virtual audio cable software to link the two together. If you are using a radio then make sure you select the audio in your devices. You should be seeing your packets on the waterfall. but you will notice that they are off center. You want to adjust your frequency so that the center of the packet is roughly around 1500 Hz between the two markers.
The default frequency for the digipeater and telemetry is 435.310.000 Hz (Same downlink/uplink), but I had to change my offset to 435.305.926 Hz to get successful decodes. I change this in Gpredict so that it uses my frequency change and still apply the doppler to it.
I have also noticed that there is a difference between the offset on my SDR and my Icom 9700. You should adjust your frequency so that the packets look something like this:
Its a bit finicky, but once you have to tuned it should be the same on every pass. On decodes your will see all kinds of messages showing in the window that doesn’t necessarily make sense. To make sense of those you need a Telemetry decoder and the Digipeater client. The Sound Modem makes this data available on a KISS port for other applications to connect to. You can have multiple applications connected to the same port, so you can run the telemetry and digipeater client at the same time.
Software – Telemetry/GetKiss+
The telemetry application that decodes the gibberish into something more sensible was written by DK3WN and can be found here. While you are there also grab the latest GetKiss+ software. The telemetry app needs to connect to your Sound Modem, so make sure the KISS port is configured in both to the same port. When you now receive a packet on the Sound Modem and the data received is a telemetry packet then it will show on the telemetry app with all kinds of fun data from the satellite. Digipeater packets will also show in the application under the digipeater tab. Once you have that working, it would be a good idea to also configure and get the GetKiss+ software going. It essentially is just a data forwarder and it forwards all received packets to SatNOGS. Keep in mind that most of the satellites we play with have been launched by amateurs/universities etc. They don’t need to provide amateur radio aspects to their satellites, but they do. In exchange we can help out their project by collecting the telemetry and sending it to a central server. In this case the central server is SatNOGS. You can still play with the satellites while GetKiss+ is running in the background and it won’t affect anything.
Software – Digipeater
At this point, if all the above is working and you can receive and decode packets, then its time to look at the digipeater. The digipeater concept is similar to the aprs digipeater on the ISS. You send a message to the satellite and it repeats it. Since the footprint is so huge, someone in Brazil can see your message all the way from South Africa (depending on the pass).
The only changes to the above is to make sure output is configured on your soundmodem and that it can control your ptt. This is very dependent on your hardware (the next section shows what I’m doing with the Icom 9700). The digipeater client will be part of your Sound Modem package.
The digipeater client is fairly simple to use. You specify your callsign, and the callsign you want to send a message to. Or ALL if you are calling CQ. Keep your messages short and simple. Only other thing to mention is the ReTX Delay. The value you put in there tells the satellite in how many seconds you want this message transmitted. This means that you can send a message to someone on the other side of the world. I made a simple calculator that will show you where your message will end up based on the amount of seconds specified.
Jean Marc (3B8DU) has used it to send himself a message for the next pass over his QTH, so it seems to work well. This feature doesn’t get used a lot though, but its pretty cool.
Remember Kids!: Make sure you can receive and decode first before you try to transmit. Thats the rule when using these satellites. Since we are using a bit more power than normal for satellites, be sure to follow this rule.
Icom 9700 Interface
This section is very hardware dependent, but once I had it working on the SDR, I wanted to move it to the radio so that I could transmit into the satellite as well. Basically the same rules apply than all of the above with the exception that I’m using the sound card enumerated from the radio as my input and output on Sound Modem. Same as the sdr your radio needs to be doppler controlled. I used rigctld from the hamlib tools to connect it to the radio.
I started rigctld with the following parameters:
c:\tools\hamlib-w64-4.5\bin>rigctld.exe -m 3081 -r com2 -s 115200 -vvvvv
The 3081 specifies my radio model (Icom 9700) and the com2 is the comport which the serial port enumerates on my pc. (The Icom 9700 enumerates two serial ports, only one of them will work, try either). On the radio side I kept the settings fairly the same as for most digital applications (I can expand on this is needed, leave a comment). Again, different settings work for different people, for me I have the radio set to USB-D, using FIL1 or FIL2, AGC as well as noise blanker and noise reduction is turned off as it can interfere with the signal.
My Gpredict configuration for working with the icom is:
I also had to set my Sound Modem TX delay to 800 to give Gpredict time to detect the PTT before changing the frequency
New Method for Switching PTT – Updated 2022/11/21
I originally used the method documented below for ptt switching from sound modem, but I am now using the 2nd port that is enumerated from the icom and setting it to trigger ptt directly from sound modem by triggering the DTR line on that usb port. This means I don’t need 2 CAT ports anymore, but just 1 for the doppler control from gpredict, and the 2nd usb port from icom is used without cat. This is the setting on the icom 9700
And my sound modem configuration looks like this:
So I don’t need to use the cat.dll anymore which makes things simpler. I’ve left the info on my old method below.
Old Method:
Things get a bit more tricky on the PTT signal, since I’m already using the usb for my cat port. You basically need a second cat port so that Sound Modem can control it. There are many different ways of doing this, first is wiring a UART module into the cat socket on the radio, 2nd is to use virtual serial port drivers that can share a serial port. I decided to take the lazy option using wfview. Since my radio is network connected I can open up wfview which connects to the radio via ethernet and exposes another cat port for me to use (also via virtual serial ports).
To get Sound Modem to talk to my Radio for the ptt I had to download and copy cat.dll and ptt.dll into my Sound Modem folder. You can also download this from UZ7HO’s site. (ptt-dll.zip). Inside your Sound Modem you choose CAT as your PTT port and then use Advanced PTT settings to configure your cat port.
Icom 9700 – Switching off AGC
As per comment below from Wolfgang, when you first try to switch of your AGC you will notice that it only shows SLOW/MID/FAST options. To switch it off, hold down the AGC button in the Function menu
Then select on of your AGC options and with the tuning wheel you can now turn it down until it shows OFF
The one you changed to OFF will now be available as OFF in your function menu.
Conclusion
I can understand that the above is a lot, and also keep in mind that working Green Cube is not the easiest satellite to play with, but don’t be discouraged and keep at it even if you only aim for trying to receive it.
Another guide written by FG8OJ is available here.
You can also ask for help on twitter, lots of information is available there and I was helped by most people on that list. See you on the satellite soon.
73,
Tom – ZR6TG
Excellent description Tom !
Hello Tom
I found your articel about the new Grrencube SAT and the digipeater mode.
I will try to decode today the first time the signales.
This morning I got a good signal with just 6 degrees Elevation, but I was not able to decode.
What are your settings in the IC-9700 für USB etc.?
I can’t switch off the AGC, just set slow, med, or fast.
73 de HB9RYZ
Wolfgang
Hi Wolfgang,
I’ve sent you a mail, and also updated the writeup with the info 🙂
Good luck with the Satellite, its tricky, but its a lot of fun!
73,
Tom
Adjust in VFO mode
Thanks this nice instruction / information. Will contact you if my efforts fail. Decoding no problem here. I understand you working SSB down and up. Any idea if FM down and up will also work ? Or FM down and SSB up ?
Thanks again yr advice. 73 Albert PA5OXW
Thanks so much Tom
Great description of a working setup! I’m running the S5lab client and UZ7HO software in parallel. They can share the audio devices, but need separate PTT ports, so I have the CIV port for frequency & doppler control, one of the USB-exposed COM ports for UZ7HO PTT, and the other for rigctrld (used by the S5Lab client) PTT. Yes, somehow all 3 work! For TX output sound levels, I used the Calibration TX both tones in Soundmodem and adjusted Windows “speaker” (USB Audio Codec) level for AGC just flickering on/off. For RX sound (Windows “mic” USB Audio Codec) level, I ran WSJT-X in Rx only (no radio) and set for 30db signal level on noise with preamp on (on my station, 30% IC9700 audio level out and ~30% Windows device setting. Other folks may have other values).
I’m still tweaking the station, I’d like to get better decodes (too many frames not detected or RS error correction errors). The S5Lab client seems to decode better than soundmodem, which is the opposite of what I’ve read other ops are experiencing.
73 Steve KS1G
Great writeup and I’ve not had many issues with receiving and sending, however, doppler shift and satellite tracking IS a big problem. As I use PSTRotator for satellite tracking and doppler this means the program controls COM2 (My Yaesu FT847), this means that when HS moden via DigiPeater wishes to transmit, it loses control of COM2 to PSTRotator and there is a conflict. It is obvious that SSB needs good doppler but not as much as LEO satellite. Due to Greencube being MEO the doppler isn’t that fast moving compared to ISS, SO-50 or CAS-5a for example which require fast doppler.
It would be nice to see PSTRotator and developers of HS modem ‘UZ7HO’, Digipeater and GreenCube ‘DK3WN’ telemetry decoder all join to produce one software that does it all?
Apart from Digipeating, then the satellite could be picked up and tracked with one software. Laws in my country forbid unattended Digipeating of this kind so that must be stopped unless I’m at me transceiver.
de Spence M0STO