Thanks for the update!
I will certainly get setup to transmit your command ASAP. My location is in Virginia.
Please feel free to post follow-ups here or communicate with me via email if you wish (scott23192@gmail.com).
-Scott, K4KDR
1 Like
Quick question, please.
Looking at the YML file, can you please advise if the satellite listening for uplinks as standard 9k6 FSK + AX.25, or only as 9k6 Endurosat?
And IF the uplink should be standard 9k6 FSK + AX.25, is there a requirement on what the TO: and FROM: call signs should be?
Thanks!
-Scott
2 Likes
To our knowledge, the call sign should be W0ISU if it cares.
While we have the satellite normally configured to accept Ax.25, that was for transmitting commands to for the onboard computer. Since we are trying to directly communicate with the transceiver, we believe it requires the 9k6 endurosat.
1 Like
Thanks very much!
As an update to this with a little more info:
We attempted to strobe the command at 5:15PM CST with an approximately 30 W transmission to the satellite. We are unsure if the command was received.
However, if the command is received by the satellite, it is possible no signal will be returned due to undervolt protection on the satellites power system going into safe mode to allow the batteries to recharge. The satellite will reboot once the batteries reach their target voltage and should begin beaconing at that point.
2 Likes
I wonder if you could please confirm that the following uplink command packet structure is accurate for CYSAT-1?
Previous satellites (equipped with Endurosat transceivers) that I have uplinked commands to used the following packet structure:
A preamble of 5 0xAA bytes, the 0x7E flag as syncword, followed by one byte indicating the packet length, then the packet (length 0 to 128 bytes), and finally a CRC-16 (CRC type = CRC-16/CCITT-FALSE). The CRC-16 applies to the packet and packet length.
Therefore, with a desired payload of ascii “ES+W22F2110A”, I calculate the uplink packet to be:
desired payload: ES+W22F2110A
in hex: 45 53 2B 57 32 32 46 32 31 31 30 41
packet length = 12 decimal = 0C hex
CRC (length + payload, CRC-16/CCITT-FALSE): 49 3D
packet to be transmitted:
AA AA AA AA AA 7E 0C 45 53 2B 57 32 32 46 32 31 31 30 41 49 3D
And then formatted as a .KSS file for transmission into Direwolf:
echo -n -e ‘\xc0\x00\xAA\xAA\xAA\xAA\xAA\x7E\x0C\x45\x53\x2B\x57\x32\x32\x46\x32\x31\x31\x30\x41\x49\x3D\xc0’ > /tmp/kisstnc
… with the following decode:
… ignoring the unused (in this case) ‘dest’ & ‘source’ fields in Direwolf, you can see the decode of your uplink command on the right.
Thanks in advance if you could kindly confirm if this format is correct - or please set me straight on any parts that are not correct for CYSAT-1.
-Scott
2 Likes
That packet seems accurate to my understanding. I admit I’m not the most familiar with the ESTTC protocol as we hadn’t intended to use it. The current team has no continuation from the team that developed the satellite and we’ve been on-boarding ourselves as quickly as we can, but we only have the user manual to rely on.
I believe we may have the firmware installed that includes the change to not include the crc value, but the code has a section with
“crc32(command, 12, &command[13]);”,
So we arent entirely sure. I believe this means the input value for crc32 is 12?
I’m sorry we’re not able to be more clear. It’s an entirely undergraduate team and there’s a lack of familiarity with many topics that we’re working on correcting.
John
1 Like
I understand - thanks very much for all you’ve shared.
Interesting that (if used), a ‘crc32’ field is specified. Perhaps that’s a choice that is available and the previous team using this equipment selected crc16 (hence my notes).
I’ll see what turns up when I search online for “ESTTC protocol” as that is new to me as well.
One thing that would be EXTREMELY helpful is if you have (or could generate) either an audio or I/Q file recording of the uplink command that YOU are transmitting. Even just a clean over-the-air RX with another SDR would allow you to produce one or both types of recordings. That allows people in this community to confirm whether they are transmitting the same signal that you are.
Thanks!
1 Like
I am not sure there is public documentation of it. It stands for Endurosat Telemetry, Tracking and Command. We have the user manual that was included with the Trasceiver II but I have not found anything on google.
We will try to get the audio or I/Q tomorrow. We’ve all headed home after a long day.
1 Like
Very good on your ‘long day’! Very understandable.
Here is some info on your CRC situation that might be helpful.
Using the payload included in your repository as Newly_Generated_CySat_Packet_For_Uplink.bin, and leaving off the last two bytes (typically a CRC-16):
69 AD 01 78 69 C4 56 59 B0 49 2F E7 4D 6B BC A7 44 C3 7A F8 D6 05 D8 F0 B6 23 06 38 AB C2 40 9C B0 1C C0 5B FC 0B A7 26 38 69 03 3D 2B D5 BA 17 1A 1C 4A AC E9 FE 8D 71 F7 C1 E1 98 8F 22 D3 DA 32 28 5D F7 97 E4 D3 D9 32 19 DE F7 66 6B B3 E8 81 1A 37 88 05 22 36 D4 10 4D 6A 96 7A 4A FF EC E7 5E 78 70 CF DB 75 B5 0E 60
… it turns out that the CRC calculation being used (bytes ‘8D 07’ in this case) is the same CRC-16/CCITT-FALSE calculation that I mentioned from my notes.
–
By chance can you please confirm if that file in your repository actually IS a valid uplink command payload? If so, then I believe we have the correct CRC method.
Thank you!
-Scott
2 Likes
The packet generated is created by a custom gui created by the prior team to ease command of the satellites components.
According to prior documentation, this gui was used to command the satellite until it’s delivery to the launch provider.
While we’ve made changes to the GNU radio and uploaded those, we haven’t changed that guiprogram. However, we do know there are issues with several of the included commands that we’ve been working to correct. We unfortunately do not have an engineering model to test with, so we’re operating a little blind.
So to summarize the rambling: to our best knowledge that packet is accurate to our communication scheme
2 Likes
Thanks for the info regarding the uplink HEX file from your repository. Since that packet has been shown to use the CRC-16/CCITT-FALSE calculation -and- my notes from transmitting commands previously to satellites using the same hardware specifies that CRC type, it feels like that is probably correct for CYSAT-1.
Very good, then. Since for all we know time could be of the essence (my next pass isn’t until tomorrow), if anyone has the ability to transmit an audio file through the high-speed / DATA connection to their 9600-baud capable FM radio on 436.375 MHz and would like to help these folks out, I will link to a standard 48k audio .WAV file created in GNU Radio that contains the ‘antenna deploy’ command that they kindly have provided to us.
As shown below, when run thru the gr-satellites ‘FSK Demod’ (9600 baud) block & the ‘Endurosat Deframer’, the resulting payload is what CYSAT-1’s transceiver is expecting… one byte indicating packet size + the payload itself. To the side I run a quick confirmation that the HEX bytes are in fact the command payload that we’ve been asked to transmit. (note that GNU Radio / gr-satellites strips off the leading ‘marker’ bytes as well as the CRC-16 bytes)
One last comment – at 9600 baud a 12-byte payload only lasts a tiny fraction of a second. It’s been my experience that not only for PTT reasons, but also to allow for receiver lock at the other end, etc., it’s better to REPEAT an uplink command multiple times. So, the audio file I’m linking to at the end actually repeats the command 10 times. Here is a visual, just FYI:
… and finally, the audio file URL:
https://www.qsl.net/k/k4kdr//uplink/cysat-1/
( if anyone is wondering why I don’t use the GNU Radio TX flowgraphs often provided by Project Teams for this type of work, I can’t afford any of the TX-capable SDRs!! )
-Scott
9 Likes
88° CYSAT-1 pass just ended… transmitted the Antenna-Deploy command numerous times, so hopefully it was received.
If no signals are received from the satellite, I have a 53° pass this afternoon (1920utc) & will try again.
4 Likes
Scott,
Also check the SatNOGS network or let me know if we can add some obs.
Jan
3 Likes
Thanks for the reminder! I actually started reviewing all the ‘green’ and ‘orange’ observations immediately after this morning’s pass. Now I just caught up on checking all the ones since then.
So far, I’ve only found a few with suspect marks on the waterfall but they did not decode on audio replay. Will have to keep hoping that we get some luck on this one!
3 Likes
How much power did you send into your antenna(s) and how many dBd has it?
50w from the TM-V71A w/ the data rate set to 9600. The 70cm Wimo X-Quad lists the gain dbd as 12.8.
On a related note, I have been doing some over-the-air testing today to confirm that I am transmitting a valid packet. Only by actually transmitting & trying to decode w/ a separate RX device can you ‘really’ know if you’re sending up valid data. (previously I played the .WAV audio file in GNU Radio to confirm the decode, but that could be distorted when transmitted via an actual radio due to an incorrect setting, using a ‘too-low’ or ‘too-high’ audio level, etc.)
While my GNU Radio flowgraph did not (initially) decode the payload ‘live’ over-the-air, interestingly the old GASPACS UZ7HO SoundModem decoded my signal fine. However, when I INVERTED the audio (either on the sending side or in GNU Radio), the GNU Radio flowgraph also decoded my packets properly.
Obviously my radio is inverting the signal when it transmits - the issue is whether the receiver on the satellite cares one way or the other. On this afternoon’s pass, I’ll transmit 50% with the original audio payload & 50% with it inverted here on the TX side. Learn something new every day!
For those interested, you can invert the FSK demod in GNU Radio by specifying a negative deviation value:
4 Likes
Uh, I thought my 50 watts into a 9.5 dBd lin pol HB9CV would be way too less.
You couldn’t do automatic doppler correction, right? Only manually in 5 kHz steps?