Reaching out again regarding the Binar satellites with a (hopefully fun) request for you all. Due to the increased solar activity, our TLE prediction indicates that the satellites will be re-entering much sooner than anticipated, and we are still struggling to obtain a successful transmit up from our ground station.
To that end, if there are any amateurs with a Tx-capable rig who are interested, I have attached the raw bytes for the telecommand to switch the satellite from safe mode into application mode, and the telecommand that will generate a short beacon (āpingā) response after reception. If any amateur would like to try sending either (or both) of these commands to Binar 3, we would greatly appreciate the additional Tx attempts, and the information generated from this. Transmissions should be in GFSK at 9600 bps, modulation index 1 (deviation 4.8 kHz).
Ping:
aa aa aa aa aa aa aa aa aa aa d3 91 d3 91 3b 01 01 01 11 11 01 01 01 01 2d df 0f 53 9c 71 23 06 6d 5c 29 d5 39 fb f2 83 61 e1 95 6d 2d f4 0f 04 6d e8 36 21 d6 62 2c 57 b1 3e 7e f5 45 44 b5 b9 c4 76 a1 aa 91 00 02 01 be ef a7 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Change to Application Mode:
aa aa aa aa d3 91 d3 91 3b 01 01 01 11 11 01 01 01 01 2d 8c 20 3b 9a 94 7e 3b 55 c5 a6 da ad 4e f8 2e d6 16 50 1a 0d 4d 6a ac 07 ae a4 20 31 2a 96 a3 03 ca 59 38 f0 7f 52 a9 ea 93 e2 13 4d 00 02 01 be ef e3 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
If you are able to get a ping response from the satellite, you will see a short packet from the spacecraft within approximately 2 seconds of the transmit ceasing. If the switch to application mode is successful, the transmit period of the beacon will permanently increase to 15 seconds. If either command works, please let us know of your success here on the forum alongside an IQ recording, so we can discuss the details of your transmission and ground station hardware.
Huge thank you in advance from our entire team to anyone who is able to assist us with transmitting.
Iāve moved this into a separate thread for better visibility!
I would suggest if anyone tries to let us know here the timestamp of the attempt in order to schedule observations in Network too and have better chance/coverage to receive a possible transmission from the satellite.
Is the frequency for these uplink commands also 437.850 MHz?
And also, do uplink packets to BINAR-3 require the same modulation & framing that the downlink packets use?
I ask because custom deframers had to be created both by UZ7HO and in gr-satellites (the āBinar-2 Deframerā block) to accommodate the downlink frames from BINAR 2, 3, & 4.
If the same framing is required on the uplink, off-hand I donāt know how one could create packets in the required formatā¦ the expert programmers mentioned above that weāre so fortunate to have in this hobby created new DE-framers for Binar-2/3/4 but not tools for the creation of uplink packets meeting the same specifications.
Hey! Yes, CYSAT-1 uses Endurosat framing w/ a specific preamble & a particular CRC-16 at the end.
The instruction here for BINAR-3 is āTransmissions should be in GFSK at 9600 bpsā, so I read that to be standard 9600 *FSKā¦ which in my own slang I refer to as āoriginalā or āplainā 9600 baud that you can encode or decode w/ something like Direwolf. However, as I was reviewing the uplink packets that I created for the two payloads given, I noticed that the BINAR-2/3/4 downlink actually required custom decoders - the downlink isnāt āregularā 9600 at all. Bob (N6RFM) kindly showed me the UZ7HO SoundModem specific to BINAR-2/3/4 and about the same time we realized that I had not recently updated gr-satellites so was missing a new āBinar2 Deframerā block.
So, that prompted me to post my question as to whether the uplink packets could just be plain olā 9600 FSK or if they needed to use the same format as the downlink packets. (Seems to be academic at the moment for my location - Iāve had several good BINAR-3 passes with NOTHING heard, but in sunlight over EU, there seem to be downlink packets every 5 or 6 seconds). Does anyone know if BINAR-3 has lost battery power & runs in sunlight only?
Well, I thought that the given uplink strings for CYSAT-1 as well as for BINAR-3 consist already of everything needed to be decodable by the satellite.
For CYSAT-1, you showed that very clearly mentioning the preamble, sync word and CRC.
So, even Direwolf put an additional CRC at the very end to follow AX.25 rules, I would not care because everything CYSAT-1 needs to hear would be there.
And so was my thinking for BINAR-3.
We know that the format of BINAR-3 do not conform to AX.25.
My assumption was that the uplink string has already the needed format, equivalent to the downlink one.
Did I get something wrong?
Does anyone know if BINAR-3 has lost battery power & runs in sunlight only?
I donāt know, but thatās only partially because of my microscopic understanding about these things. Here is whyā¦
Itās been my experience that Cubesat Teams provide two very different scenarios when communicating instructions about how to uplink to their satellites.
In some cases, teams know and have documented EXACTLY what the transmitted payload should look like. Thatās an incredible blessing since itās then possible for us to decode āliveā over-the-air any uplink packets that we create to confirm whether or not we have a perfect match.
However, many teams only know the āpayloadā required to communicate with their satellite, not the format of the transmitted packet. What this means is that, instead of ALSO sharing the complete transmitted packet structure, the CYSAT-1 Team might have instead ONLY asked that we send the payload āES+W22F2110Aā to deploy the antenna. What follows then is a lot of back & forth to find out what RF & framing parameters are requiredā¦ what header bytes are needed & which variety (if any) checksum is utilized. Sometimes a Team can provide this info and sometimes they cannot.
Why the two very different scenarios? Seems to me that many Teams are intimately involved in all aspects of their satelliteās comm situation both up & down but other Teams have simply bought a turn-key package of TWO data radiosā¦ one for the satellite & one for the ground station. You get a manual about how to transmit command strings up to the satellite, so all you need to know as the end-user is that a string such as āES+W22F2110Aā will deploy the antenna.
Iām sure everyone doesnāt care about these types of details but since Iāve worked with a number of Teams - using both of the scenarios outlined above - I wanted to share why the exact format of uplink commands might be shared w/ the Amateur Community in more than one level of detail.
Hi everyone, apologies for not getting stuck into this over the weekend, I was away from the lab.
K4KDR - The frequency is the same as the downlink (437.850), yes. The two packets I posted contain the preamble and sync words. I was given the exact bytes that we transmit up to the satellite ready to go, so they do not require additional processing.
I have linked a picture of our entire upload chain below:
I will work on getting this broken out into a separate GNURadio Flowgraph to share today.
Binar 3 has been sitting on >90% battery for the lifetime of the mission (due to not switching out of safe mode), so we should be seeing constant beacons with a period of 5 seconds. We believe that there might be a more intense null/low gain orientation with the antenna than simulated (we have an experimental UHF patch antenna with approximately toroidal gain pattern) which causes some passes to drop out.
Thanks for the updates! Yes - many people have been posting decodes that had approx. 5-second packet intervals. I guess from your original post, if we are successful w/ the uplink, that will change to 15-seconds.
Beat me to it! We successfully got an application mode switch command through last night. The Tx and response can be seen in this pass plot at approximately 125 seconds: SatNOGS Network - Observation 10467564
The command was sent at max elevation during the 76-degree pass from our ground station at 8:40pm local, which is running at 25W at the antenna. It appears to be the only command that has responded so far from any satellite.
It appears from the satellite beacon data that Binar 3 moved from sunlit to eclipse just before the pass started. With any luck over the next few days we will determine the conditions that allow for transmissions to be processed consistently.
We are going to have a team meeting and I will update here if there are new commands for everyone to attempt to send.
Binar-4 has a 10 second interval by default - we had initial modelling that indicated our power balance was going to be a bit off, and we reduced the frequency of this satellite to increase its operational lifetime.
