The Road to HADES-SA CODEC2 Voice Decoding
#1, #2, #3, #4, #5, #6
(Part #1)
Verifying the Operation of the HADES-SA CODEC2 Decoder
I obtained the Windows version of the HADES-SA (SpinnyONE) decoder released by AMSAT-EA and
tested its operation.
[Preparing the Decoder]
I downloaded "unified-bytes-decoder-hades-sa-windows-x86.exe" from GitHub and saved it in the
following folder: https://github.com/AMSAT-EA/HADES-SA_SpinnyONE?utm_source=chatgpt.com
C:\Program Files\hadesa\byte_version
[Preparing Sample Data]
I created "sample_type_11.txt" in the same folder and saved the publicly available 37-byte sample
data as hexadecimal values separated by single spaces.
[Running the Decoder]
I ran the following command from the Command Prompt.
unified-bytes-decoder-hades-sa-windows-x86.exe sample_type_11.txt
[Results]
The decoder successfully read the input data and confirmed the following:
Satellite ID: 3 (HADES-SA / SpinnyONE)
Packet type: 11 (CODEC2 voice)
Input data length: 37 bytes (matched)
Frame number: 27
CODEC2 frame data: 40 bytes (output)
Official 40-byte frame structure:
Byte position Contents
0-1 Sync BF 35
2 Size 0x25 (37 bytes)
3 Type/Address B3 (upper 4 bits B = Type 11; lower 4 bits 3 = Satellite ID/Address)
4 Frame number
5-39 CODEC2 data (35 bytes)
[Fixed XOR Processing of CODEC2 Data]
The source code of the official decoder used in this test also defines the same 35-byte fixed
XOR data, xor_codec2[35], that I identified in the previous investigation.
uint8_t xor_codec2[35] = {
0xed, 0x15, 0xd5, 0x3b, 0x34, 0x70, 0xe0, 0xfd,
0xed, 0x83, 0x90, 0xdb, 0xaa, 0x2e, 0x25, 0xd6,
0x5e, 0x81, 0x41, 0x86, 0xbd, 0x67, 0x79, 0x5d,
0x70, 0xa1, 0x13, 0xce, 0x50, 0x0c, 0x19, 0xca,
0xfb, 0x44, 0x0d
};
This is a process separate from the RF transmission scrambler. It is a fixed XOR mask applied to
the CODEC2 data. It forms part of the process that converts data, after RF descrambling and CRC
checking, into the final CODEC2 frame data. The findings from the previous investigation were also
confirmed in the source code of the official decoder.
[Key Points of the First Experiment]
Process Tool / Method Purpose
---------------------------- ------------------------ --------------------------
RF descrambling LFSR, initial value Restore received RF data
0x2C350000
Fixed XOR of CODEC2 data xor_codec2[35] Restore CODEC2 data
---------------------------- ------------------------ --------------------------
RF transmission scrambling:
The scrambling process performed by genesis_scrambler.c is used to recover the data transmitted
over the radio link.
Initial value: 0x2C350000
Polynomial: 1+x^(-12)+x^(-17)
Receiver: Reversed by SelfSyncDeScrambler()
XOR processing to restore CODEC2 data:
A fixed XOR mask is applied to the CODEC2 data. The decoder performs this operation internally
to restore the frame data.
Decoder source:
uint8_t xor_codec2[35] = { 0xed, 0x15, 0xd5, 0x3b, ... };
[Future Work]
I confirmed that the decoder I obtained operates correctly. The sample data used in this test had
already been descrambled and CRC-checked. The next goal is to extract valid packets from HADES-SA
reception data obtained with GNU Radio, perform descrambling and CRC checking, and prepare the data
in a format that can be supplied to this decoder.
(Part #2)
Obtaining CODEC2 Frames from HADES-SA (SpinnyONE) Reception Data!
[Successful Decoding of Frame 157]
HADES-SA data extracted from a reception recording using GNU Radio was processed with the
official Byte Version Decoder, and I successfully obtained a CODEC2 frame. (4 Nov 2026)
[Preparing Data for Seven Frames]
The source data was "CHECK26_D_7frames_sync_aligned.bin" (280 bytes).
[**Supplement: Data Generation Process Leading to Audio Recovery]
The starting point for this HADES-SA CODEC2 audio recovery project was the WAV file 60923hda.wav,
which was directly received from the satellite and recorded. This received audio data was fed into
the GNU Radio Companion (GRC) receiver flowgraph, where the 800 bps FSK signal was demodulated and
the bitstream was extracted using a Binary Slicer. The extracted bitstream was then saved to a
File Sink, producing the file CHECK26_bits2.bin.
An examination of this file revealed frame synchronization positions repeating at intervals of 320
bits (40 bytes), beginning at bit position 19169. Accordingly, 2240 bits (320 bits × 7 frames) were
extracted starting from bit position 19169 and reconstructed into a byte sequence in MSB-first order,
using groups of 8 bits. The resulting file was CHECK26_D_7frames_sync_aligned.bin.
In other words, this file is 280 bytes in size and contains seven consecutive frames, each consisting
of 40 bytes. Analysis of this data became the starting point for the subsequent HADES-SA CODEC2 audio
recovery process. Using the frame synchronization position (19169) as the reference, seven frames of
40 bytes each were extracted from the bitstream and reconstructed as binary data in 40-byte units.
Analysis of these seven frames enabled us to generate CODEC2 data, which was ultimately successfully
recovered as a WAV audio file.
[Data Flow]
60923hda.wav
↓ FSK demodulation and bitstream extraction using GRC
CHECK26_bits2.bin
↓ Extraction of seven frames based on synchronization positions
CHECK26_D_7frames_sync_aligned.bin
↓ Frame analysis and CODEC2 data extraction
CODEC2 audio file
↓ Audio conversion
hades_sa.wav
Thus, everything began with a single received WAV file. It is much like the origin of humanity. **
I inverted every byte in the 280-byte file using XOR 0xFF. This operation inverts each bit from
0 to 1 and from 1 to 0. After inversion, the sync word "BF 35" was confirmed at the beginning
of all seven groups.
---------------------------------------------------------------------------------------
Group First 5 bytes (after inversion) Size Type Address Frame No. Assessment
1 BF 35 25 B3 1D 37(0x25) 11 3 1D = 29 Header OK
2 BF 35 25 B3 1E 37 11 3 1E = 30 Header OK
3 BF 35 25 B3 1F 37 11 3 1F = 31 Header OK
4 BF 35 05 B3 20 05 11 3 20 = 32 Size field mismatch
5 BF 35 25 B3 21 37 11 3 21 = 33 Header OK
6 BF 35 25 F3 22 37 15* 3 22 = 34 Type/Address mismatch
7 BF 35 25 B3 23 37 11 3 23 = 35 Header OK
--------------------------------------------------------------------------------------
*Type/Address F3 (Type 15, Address 3)
Removing the first three bytes from each 40-byte group leaves 37 bytes containing Type/Address,
Frame Number, and CODEC2 data. This is a candidate input corresponding to the official Type 11
frame structure. Whether each group is correctly recognized by the official decoder must be
checked individually.
Input file: "CHECK26_Frame1_type11_candidate_37bytes_hex.txt"
[Key Steps in Converting the Data to HEX Text]
1. Source data: 280 bytes (seven frames)
CHECK26_D_7frames_sync_aligned.bin
2. Divide into frame-sized groups
Each frame is 40 bytes. Divide the data into 40-byte groups.
3. Align and invert the bit sequence
Identify the start of each target frame, align the bit sequence,
and perform the required inversion.
4. Check the sync word
Confirm the sync word "BF 35" at the beginning of each frame.
5. Check the frame length
Confirm the size information 0x25. The following data is 37 bytes.
6. Check Type/Address
Confirm B3, corresponding to Packet Type 11 and Satellite ID 3.
7. Descrambling
Examine the official source function SelfSyncDeScrambler().
Identify the descrambling method using the initial value 0x2C350000.
8. Create HEX text
Convert the 37 bytes into two-digit hexadecimal values, separated by one space,
and place them on a single line.
9. Save the input file
CHECK26_Frame1_type11_candidate_37bytes_hex.txt
10. Verify with the official decoder
Supply the 37-byte HEX text to the official decoder.
Confirm that it is recognized as Frame 157 and that CODEC2 data is generated.
[**Supplement: Merit of Multi-Part Processing]
- Identification of frame start positions using synchronization words:
Allows for the determination of where a valid frame begins.
- Clarification of data boundaries using length information:
Enables the identification of where a single frame ends.
- Handling of polarity inversion:
Allows for correction even if 0s and 1s are inverted during reception.
- Appropriate processing based on packet type:
Ensures data is handled in the correct format according to the Packet_Type. **
[Processing with the Official Decoder]
Program used: "unified-bytes-decoder-hades-sa-windows-x86.exe"
Command:
unified-bytes-decoder-hades-sa-windows-x86.exe CHECK26_Frame1_type11_candidate_37bytes_hex.txt
[Successful Decoding of Frame 157!]
Decoder output: The target data was recognized successfully.
Satellite ID: 3 (SpinnyONE HADES-SA)
Packet Type: 11 (CODEC2 voice)
Frame Number: 157
Received bytes match
[Automatically Generated Files]
The following three files were generated in the byte_version folder. I also checked the contents of
the TLM file and the size of the BIN file, confirming that 40 bytes of CODEC2 data had been obtained.
------------------------------------------------------------------------------
sat_03_type_11_codec2_frame_157.tlm Decoding information
sat_03_type_11_codec2_frame_157.bin CODEC2 data, 40 bytes
20261104-175328_sat_03_type_11_codec2_frame_157.tlm Timestamped decoding log
------------------------------------------------------------------------------
[Results of Part 2 and the Next Goal]
I successfully extracted Frame 157, had it recognized by the official decoder, and generated
40 bytes of CODEC2 data. Next, I will check the relationship between the seven groups of data
and the successful Frame 157 data, and verify the Frame Numbers of the next frame candidates.
And, I aim to convert the obtained CODEC2 data into audio and actually play back HADES-SA voice.
(Part #3)
HADES-SA (SpinnyONE) Reception Data Analysis: Successful Consecutive Decoding of Frames 029 and 030!
[Results of Part 3]
For the HADES-SA (SpinnyONE) 800 bps FSK reception data, I examined the bit sequence obtained
with GNU Radio in 40-byte groups using HxD Hex Editor, and verified the results with
the official AMSAT-EA Bytes Decoder.
An especially important result was achieved this time. The official decoder successfully
recognized Frame 029 from Group 1 and Frame 030 from Group 2, as identified in HxD. The two
frame numbers were consecutive, 29 and 30, confirming that the data extraction method is
consistent with the observed data.
[Examining the Data in 40-Byte Groups with HxD]
I opened the previously investigated file "CHECK26_D_7frames_sync_aligned.bin" in HxD and
examined the data in 40-byte groups.
The following two groups were used.
Group 1: Offset 00 to 27 (hexadecimal, 40 bytes)
40 CA DA 4C E2 DC 1B 2A C1 65 D3 1F 19 6D FC 6D AA 99 D7 C1 7C E1 7D E0 49 45 B0 45 02 81 62 00 34 ED 00 26 37 8F 4B F2
Group 2: Offset 28 to 4F (hexadecimal, 40 bytes)
40 CA DA 4C E1 09 95 AA C6 47 77 1F 34 FE BC 6D A9 0D D1 14 AD A1 7B 54 ED 42 56 0B 62 D0 FD 9C 31 58 8D A6 5A 72 77 F5
The first five bytes of Group 1 were "40 CA DA 4C E2".
The first five bytes of Group 2 were "40 CA DA 4C E1".
The first four bytes of both groups are identical; only the fifth byte differs.
[Inversion Using XOR 0xFF]
I applied "XOR 0xFF" to each byte.
This operation inverts every bit. For example, 40 becomes BF, and CA becomes 35.
The converted leading bytes are shown below.
Item Group 1 Group 2
HxD source data 40 CA DA 4C E2 40 CA DA 4C E1
After XOR 0xFF BF 35 25 B3 1D BF 35 25 B3 1E
In both groups, the first three bytes after conversion became "BF 35 25". I therefore removed
these first three bytes and used the remaining 37 bytes as candidate data for the official decoder.
[Verification with the Official Decoder]
Software used:
AMSAT-EA HADES-SA (SpinnyONE) Satellite Telemetry Decoder:
unified-bytes-decoder-hades-sa-windows-x86.exe
AMSAT EA - Free distribution
Version 1.04 (Bytes)
Compilation: Mar 29 2026
Group 1: Frame 029
File created:
CHECK26_Frame1_type11_candidate_37bytes_hex.txt
B3 1D 23 E4 D5 3E 9A 2C E0 E6 92 03 92 55 66 28 3E 83 1E 82 1F B6 BA 4F BA FD 7E 9D FF CB 12 FF D9 C8 70 B4 0D
Command:
unified-bytes-decoder-hades-sa-windows-x86.exe CHECK26_Frame1_type11_candidate_37bytes_hex.txt
Main output from the official decoder:
Satellite id 3 (SpinnyONE HADES-SA)
packet type 11 (CODEC2 voice)
Expected bytes are 37 for this packet type
Received bytes match
frame num : 29
data: CE F1 00 00 5A E5 C0 00 1B 7F 80 00 28 EC C0 60 1B 55 40 00 35 E3 00 70 28 C3 A0 00 E3 CE C0 50 42 F3 C0 00 28 BF 00 00
In addition, CODEC2 data was output, and three files with the suffix frame_029 were automatically
generated.
Group 2: Frame 030
File created:
CHECK26_Frame2_type11_candidate_37bytes_hex.txt
B3 1E F6 6A 55 39 B8 88 E0 CB 01 43 92 56 F2 2E EB 52 5E 84 AB 12 BD A9 F4 9D 2F 02 63 CE A7 72 59 A5 8D 88 0A
Command:
unified-bytes-decoder-hades-sa-windows-x86.exe CHECK26_Frame2_type11_candidate_37bytes_hex.txt
Main output from the official decoder:
Satellite id 3 (SpinnyONE HADES-SA)
packet type 11 (CODEC2 voice)
Expected bytes are 37 for this packet type
Received bytes match
frame num : 30
data: 1B 7F 80 00 28 CF 80 00 36 EC C0 00 28 D5 80 00 CE 84 00 00 5E A9 40 00 CE 8D C0 50 FA 37 00 00 F7 7E 40 60 F7 6C C0 70
This also produced CODEC2 data, and three new files with the suffix frame_030 were automatically
generated. The complete output data for each stage is summarized below, with each data block
written on a single line.
Group 1: Frame 029
1) HxD Hex Editor: Data extracted from the received data (40 bytes):
CHECK26_D_7frames_sync_aligned.bin
2) Decoder input file: Data after XOR inversion, with the first 3 bytes removed (37 bytes):
CHECK26_Frame1_type11_candidate_37bytes_hex.txt
3) Decoder output file: CODEC2 voice data (40 bytes):
sat_03_type_11_codec2_frame_029.bin
40 CA DA 4C E2 DC 1B 2A C1 65 D3 1F 19 6D FC 6D AA 99 D7 C1 7C E1 7D E0 49 45 B0 45 02 81 62 00 34 ED 00 26 37 8F 4B F2
B3 1D 23 E4 D5 3E 9A 2C E0 E6 92 03 92 55 66 28 3E 83 1E 82 1F B6 BA 4F BA FD 7E 9D FF CB 12 FF D9 C8 70 B4 0D
CE F1 00 00 5A E5 C0 00 1B 7F 80 00 28 EC C0 60 1B 55 40 00 35 E3 00 70 28 C3 A0 00 E3 CE C0 50 42 F3 C0 00 28 BF 00 00
Group 2: Frame 030
1) HxD Hex Editor: Data extracted from the received data (40 bytes):
CHECK26_D_7frames_sync_aligned.bin
2) Decoder input file: Data after XOR inversion, with the first 3 bytes removed (37 bytes):
CHECK26_Frame2_type11_candidate_37bytes_hex.txt
3) Decoder output file: CODEC2 voice data (40 bytes):
sat_03_type_11_codec2_frame_030.bin
40 CA DA 4C E1 09 95 AA C6 47 77 1F 34 FE BC 6D A9 0D D1 14 AD A1 7B 54 ED 42 56 0B 62 D0 FD 9C 31 58 8D A6 5A 72 77 F5
B3 1E F6 6A 55 39 B8 88 E0 CB 01 43 92 56 F2 2E EB 52 5E 84 AB 12 BD A9 F4 9D 2F 02 63 CE A7 72 59 A5 8D 88 0A
1B 7F 80 00 28 CF 80 00 36 EC C0 00 28 D5 80 00 CE 84 00 00 5E A9 40 00 CE 8D C0 50 FA 37 00 00 F7 7E 40 60 F7 6C C0 70
[Consistency Between Frames 029 and 030]
Summarizing the results of Part 3:
HxD data Official decoder result
----------- ----------------------
Group 1 (40 bytes) Frame 029
Group 2 (40 bytes) Frame 030
Both were recognized as Satellite ID 3, Packet Type 11 (CODEC2 voice), and displayed
"Received bytes match" for the 37-byte input. Confirming the consecutive frame numbers
029 and 030 from two consecutive data groups was a major step forward in this analysis.
[Regarding Frame 157 Confirmed in Part 2]
On the previous day, decoding of Frame 157 had succeeded using a different candidate file. However,
it has not yet been possible to identify which reception data was used to create that 37-byte data
set. Therefore, the successful decoding of Frame 157 will be retained as a record, but it will not
be associated with Frames 029 and 030. It will be kept as reference data of unknown origin. The results
in Part 3 are strictly the new verification results obtained from Groups 1 and 2 identified in HxD.
[Further Analysis]
This time, I created 37-byte candidates from the 40-byte groups and confirmed two consecutive frames
using the official decoder. I plan to verify the remaining groups in the same way. I would also like
to color-code the byte fields in HxD so that the sync word, length, type/destination, frame number,
and data area can be distinguished visually.
The following color assignments should make the actual HxD screen easier to read.
Byte position Role Color
00-01 (from start of each 40-byte group) Sync word (BF 35 after inversion) Cyan
02 Length (25) Yellow
03 Type/Address (B3) Purple
04 Frame number (1D / 1E) Green
05-27 Remaining data area Gray
* This is a proposed color scheme corresponding to the structure after inversion of
the 40-byte groups. In HxD, apply the colors to the same offsets in the original data.
Note that XOR 0xFF is a bit-inversion operation and must be distinguished from descrambling.
According to the official decoder's description, its input is a byte sequence that has already
been descrambled and CRC-checked. The "Received bytes match" message obtained this time is
recorded as a new result indicating that the decoder accepted the input.
[Summary of Part 3]
Group 1 in HxD: Frame 029; Group 2 in HxD: Frame 030.
Two consecutive frames were confirmed with the official AMSAT-EA decoder.
(Part #4)
Successful Recovery of CODEC2 Audio from Reception Data Analyzed with GNU Radio!
[Introduction]
The work on receiving and analyzing the 800 baud FSK signal from HADES-SA (SpinnyONE) has finally
reached the stage of audio recovery. The received signal was processed with GNU Radio to extract
frames. I then used the decoder released by AMSAT-EA to obtain CODEC2 audio data, and successfully
converted it into a WAV file. This section records the procedure and results.
[Extracting Frames from HADES-SA Reception Data]
The received WAV data was processed with GNU Radio Companion (GRC) to extract the bit sequence
from the 800 baud FSK signal. The frame positions were then identified using the sync pattern
as a guide. The extracted data was prepared as frame candidates by inverting the bit polarity
(inverting 00/01 using XOR). The data used in this analysis was a file containing seven groups
of 40 bytes each: CHECK26_D_7frames_sync_aligned.bin (280 bytes).
Sync: BF 35
Size: 25 (hexadecimal)
Satellite ID: 03
Packet Type: 11 (CODEC2 Voice)
Of the seven groups, Groups 1, 2, 3, 5, and 7 were found to be usable as Type 11 CODEC2 voice
frame candidates. Group 4 had a size field mismatch, while Group 6 had Packet Type 15, so both
were excluded from this audio recovery.
[Verification with the AMSAT-EA Public Decoder]
Next, I used the HADES-SA decoder released on the AMSAT-EA GitHub repository:
unified-bytes-decoder-hades-sa-windows-x86.exe
For each frame, I removed the first three bytes (BF 35 25) and supplied the remaining
37 bytes as input. All five frames produced the result "Received bytes match".
Frame number Packet Type Result
029 11 Success
030 11 Success
031 11 Success
033 11 Success
035 11 Success
The decoder output 40 bytes of CODEC2 data for each frame. Thus, I was able to obtain
five voice frames.
[Combining CODEC2 Data and Converting It to WAV]
Next, I used the CODEC2 utilities released by AMSAT-EA:
AMSAT-EA_HADES-SA_SpinnyONE_CODEC2_utilities.zip
Working folder: C:\Program Files\hadesa\AMSAT-EA_HADES-SA_SpinnyONE_CODEC2_utilities_new
I placed the five CODEC2 files in the sat subfolder. The supplied run_codec2.bat contains
a bug and cannot be used as provided. A corrected BAT file can be downloaded here:
run_codec2.bat -- Use this version.
Files used:
sat_03_type_11_codec2_frame_029.bin
sat_03_type_11_codec2_frame_030.bin
sat_03_type_11_codec2_frame_031.bin
sat_03_type_11_codec2_frame_033.bin
sat_03_type_11_codec2_frame_035.bin
The processing proceeded in the following order. For details, see hadesagr.htm.
Create a file list of the CODEC2 frames
Combine the frames with codec2-merge-windows-x86
Convert the CODEC2 data to RAW audio with c2dec 700C
Convert the RAW audio to WAV format with FFmpeg
During the combining process, zero data was inserted at the positions of missing frames.
In this case, Frames 032 and 034 were missing, and missing-frame data was also inserted at
the beginning of the sequence. The process completed without errors, and hades_sa.wav was
finally generated.
[Finally, the Audio!]
hades_sa.wav (A brief human voice can be heard during the final second.)
I opened the file in Audacity and examined its waveform. The first part was almost silent,
but an audio waveform appeared near the end. When I actually played it, I could hear a human
voice during approximately the final second of the 14-second recording! Although the audio
is still very brief, successfully recovering voice from received HADES-SA data is undoubtedly
a major step forward.
[Results of Part 4 and Future Work]
This work achieved the following sequence of operations:
Extracting the HADES-SA signal bit sequence with GNU Radio
Identifying sync positions and cutting out frame candidates
Preparing frame data by inverting bit polarity
Extracting CODEC2 data with the AMSAT-EA public decoder
Combining CODEC2 frames
Converting RAW audio into a WAV file
[Confirmation of Actual Audio Playback]
The next goal is to receive more frames and recover a continuous audio sequence with fewer
gaps. I will also continue investigating whether the analysis method used here can be applied
to future HADES-L reception.
After continuing to pursue the HADES-SA signal, I finally heard a human voice. This achievement
marks a major step forward in the analysis of HADES-SA reception.
(Part #5)
HADES-SA CODEC2: Merging Additional 9-Frame and Audio Recovery - CMD Operation Log -
[Additional: List of Operations Including CMD Commands]
1. Apply XOR to the 40-byte data, Remove the first 3 bytes, and create 37-byte input files
CHECK26_Frame1_type11_candidate_37bytes_hex.txt
CHECK26_Frame2_type11_candidate_37bytes_hex.txt
:
2.Change to the byte_version folder
cd /d "C:\Program Files\hadesa\byte_version"
3. Run the official decoder
unified-bytes-decoder-hades-sa-windows-x86.exe CHECK26_Frame1_type11_candidate_37bytes_hex.txt
unified-bytes-decoder-hades-sa-windows-x86.exe CHECK26_Frame2_type11_candidate_37bytes_hex.txt
:
4. Confirm that BIN files have been generated in the byte_version folder
sat_03_type_11_codec2_frame_017.bin
sat_03_type_11_codec2_frame_018.bin
:
5. Move all BIN files into the sat folder
C:\Program Files\hadesa\AMSAT-EA_HADES-SA_SpinnyONE_CODEC2_utilities_new\sat
6. Check the contents of the sat folder
dir sat\*.bin
7. Change to the working folder
cd /d "C:\Program Files\hadesa\AMSAT-EA_HADES-SA_SpinnyONE_CODEC2_utilities_new"
8. Check the usage of CODEC2 Merge in the working folder
codec2-merge-windows-x86.exe --help
9. Check the previously used 5-frame input list
type codec2_file_list.txt
10. Create a new input list for the 9 frames
(
echo sat\sat_03_type_11_codec2_frame_017.bin
echo sat\sat_03_type_11_codec2_frame_018.bin
echo sat\sat_03_type_11_codec2_frame_019.bin
echo sat\sat_03_type_11_codec2_frame_020.bin
echo sat\sat_03_type_11_codec2_frame_029.bin
echo sat\sat_03_type_11_codec2_frame_030.bin
echo sat\sat_03_type_11_codec2_frame_031.bin
echo sat\sat_03_type_11_codec2_frame_033.bin
echo sat\sat_03_type_11_codec2_frame_035.bin
) > codec2_file_list_9frames.txt
11. Verify the newly created 9-frame input list
type codec2_file_list_9frames.txt
12. Merge the 9 frames
codec2-merge-windows-x86.exe codec2_file_list_9frames.txt hades_sa_9frames.c2
13. Decode CODEC2 into RAW audio
c2dec 700C hades_sa_9frames.c2 hades_sa_9frames.raw
14. Convert RAW audio into WAV format
ffmpeg\bin\ffmpeg.exe -f s16le -ar 8000 -ac 1 -i hades_sa_9frames.raw hades_sa_9frames.wav
[Generated Audio File]
hades_sa_9frames.wav (Audio signals are present near the middle and at the end of the recording)
Audio specifications: 14.40 seconds, 8,000 Hz, mono, 16-bit PCM.
(Part #6)
Ruby Program to Automatically Generate 37-Byte TXT Files
Using a HEX_TXT file containing consecutive 40-byte frames extracted from the GRC
file CHECK26_bits2.bin as input data, I created a Ruby program that automatically
generates a 37-byte candidate file for each frame by applying the XOR 0xFF inversion
to each frame and then removing the first 3 bytes.
Among the files generated, I compared the contents of Frame1 (Frame017) with the TXT
file created previously and the TXT file generated by the new Ruby program. I confirmed
that their contents matched exactly. The contents of the other Frame* (Frame***) files
also matched in the same way.
Ruby program:
https://www.ne.jp/asahi/hamradio/je9pel/hades_hex_to_candidates_v2.rb
Command:
ruby hades_hex_to_candidates_v2.rb CHECK26_D_11frames_40bytes_hex.txt
(Previous) hades folder: CHECK26_Frame1_type11_candidate_37bytes_hex.txt
B3 11 E5 F5 E4 70 30 E9 E6 7B 7F FE 21 4A 41 7C C4 CF E3 C9 2F 91 FE 7E 6B 87 54 D3 D8 11 8A 6F AC 02 93 9B 58
(This time) ruby folder: Frame01_F017_candidate_37bytes_hex.txt
B3 11 E5 F5 E4 70 30 E9 E6 7B 7F FE 21 4A 41 7C C4 CF E3 C9 2F 91 FE 7E 6B 87 54 D3 D8 11 8A 6F AC 02 93 9B 58
[About Bits and Bytes] 61108bit.htm (JP)
Back to Top
Return to Previous Page
Go to Next Page (Under editing)
Return to Home Page (Contents)