AO-73 example doesn't decode

daniestevez commented 4 years ago

@Darkkey reports the following in #86

Thank you! Now it builded ok, however it seems it's not working. When I try e.g.

$ gr_satellites FUNcube-1 --wavfile ~/gr-satellites/satellite-recordings/ao73.wav --samp_rate 48e3 --hexdump
$

I got no output. What kind of information I could provide to you to help understanding what's broken?

Originally posted by @Darkkey in https://github.com/daniestevez/gr-satellites/issues/86#issuecomment-629764031

daniestevez commented 4 years ago

That is really odd, as I've just tested that it works properly in my system.

To get more information, you can add the --verbose_rs parameter to see if at least the packet is being detected.

However, since this isn't guaranteed to give any useful information, I suggest you create a new folder somewhere (in /tmp/, for example), use --dump_path to dump the internal demodulator signals to that folder, and then share the resulting files in that folder.

Darkkey commented 4 years ago

Here are the results:

$ gr_satellites FUNcube-1 --wavfile ~/gr-satellites/satellite-recordings/ao73.wav --samp_rate 48e3 --hexdump --verbose_rs --dump_path /tmp/grsatbug1/
Reed-Solomon decode failed (1st decoder).
$

Please see the content of a folder below: funcube_nooutput_grsat.tar.gz

daniestevez commented 4 years ago

Thank you. So the demodulator output is perfectly fine. I compared it with the output I get running the same, and the difference is very small (nonzero due to numerical precision, most likely).

error_clk_recovery_out

This makes me suspect the problem is in one of the blocks in the AO-40 FEC deframer, or in libfec itself. It might be reasonable for me to write some unit tests for this to see if they pass in your system (indeed I want to start adding unit tests for the next versions of gr-satellites). I'll see if I can get to this today.

In any case, the main reason I can think of the deframer failing in your system is some portability thing I failed to take into account regarding endianness or word size. Are you running on anything other than an x86_64?

Darkkey commented 4 years ago

Thanks for a quick response! No, it's ubuntu 18.04 in VMWare (Fusion) running on OS X Catalina.

Linux ubuntu 4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Also, I've noticed a weird thing: when I open an example file in GRC, I'm getting this:

Is it normal that some blocks are missing? I'm new to gr-satellites, and a bit new to gnuradio, so can't say whether it's normal or not.

daniestevez commented 4 years ago

I guess that is examples/satellites/equisat.grc. That uses some blocks from gr-equisat, which probably you haven't installed. However missing blocks should still appear in the flowgraph, coloured in red, not be completely gone as in your case (another odd thing happening with your system).

Darkkey commented 4 years ago

I'm using Gnuradio 3.8.1.0 (Python 3.6.9).

daniestevez commented 4 years ago

I have pushed up a new branch with a unit test to try to debug this problem. Please checkout the unittest-#88 branch and run ctest -V inside the build/ directory after compiling gr-satellites.

Darkkey commented 4 years ago

Done:

UpdateCTestConfiguration  from :/home/key/gr-satellites/build/DartConfiguration.tcl
UpdateCTestConfiguration  from :/home/key/gr-satellites/build/DartConfiguration.tcl
Test project /home/key/gr-satellites/build
Constructing a list of tests
Done constructing a list of tests
Updating test list for fixtures
Added 0 tests to meet fixture requirements
Checking test dependency graph...
Checking test dependency graph end
test 1
    Start 1: qa_ao40_fec_deframer

1: Test command: /bin/sh "/home/key/gr-satellites/build/python/components/deframers/qa_ao40_fec_deframer_test.sh"
1: Test timeout computed to be: 9.99988e+06

1: .
1: ----------------------------------------------------------------------
1: Ran 1 test in 0.022s
1: 
1: OK
1/2 Test #1: qa_ao40_fec_deframer .............   Passed    0.61 sec
test 2
    Start 2: qa_satyaml

2: Test command: /bin/sh "/home/key/gr-satellites/build/python/satyaml/qa_satyaml_test.sh"
2: Test timeout computed to be: 9.99988e+06
2: .
2: ----------------------------------------------------------------------
2: Ran 1 test in 0.210s
2: 
2: OK
2/2 Test #2: qa_satyaml .......................   Passed    0.30 sec

100% tests passed, 0 tests failed out of 2

Total Test time (real) =   0.91 sec

daniestevez commented 4 years ago

Then I'm at a loss here. We've checked that the output of the demodulator matches the one produced on my machine. The unit test also passes. And that test basically takes that demodulator output, deframes it, and checks intermediate outputs as well as the final output. Yet running the whole thing with gr_satellites gives you a Reed-Solomon decoding error.

The only option I can think of is that when running gr_satellites you have leftover files from an older installation that are messing up.

Could you please run make uninstall, make sure that everything is removed from your system (look in /usr/local/lib and in the Python site-packages), then build and install again from this branch?

Darkkey commented 4 years ago

Done, didn't help :(

daniestevez commented 4 years ago

The unit test is now included in master and will make it into the v3.0.0-rc1 that will be made today.

I'm sorry but I currently I don't have any more ideas to try to debug this, since it runs well in my machine and your machine passes the unit test. I'm going to mark this as "unable to replicate" in case other users have the same problem and can report their findings.

f6bvp commented 4 years ago

I am not sure it can help, however I did not find any issue while decoding example wav file. bernard@f6bvp-Ubuntu:~/GNU-Radio/gr-satellites$ gr_satellites AO-73 --wavfile satellite-recordings/ao73.wav --verbose_rs --samp_rate 48000 --hexdump Reed-Solomon decode OK. Bytes corrected 0, 0.

MESSAGE DEBUG PRINT PDU VERBOSE * () pdu_length = 256 contents = 0000: 89 00 00 00 00 00 00 00 00 1f cc 00 ce 02 d1 00 0010: 00 07 08 09 09 00 00 05 01 01 00 40 13 2f c8 f2 0020: 5c 8f 34 23 f3 ba 0b 5d 62 74 51 c7 ea fa 69 4a 0030: 9a 9f 00 09 ef a0 1f f4 a7 ea 4a c6 8f 11 40 11 0040: 1e 10 f7 01 3e 20 64 00 d7 8b f8 d7 94 c8 93 a8 0050: 2a da 52 a6 0e 58 0e c8 0f 4e 01 1d 20 5a 00 db 0060: 94 a8 aa 8a 98 13 ac 69 0a a6 a8 10 e6 10 92 0f 0070: b8 01 50 20 64 00 d7 96 a8 c1 8b 48 25 ab a9 ca 0080: ce 9d 10 76 0f c9 10 55 01 3a 20 5a 00 d7 97 29 0090: 08 8c 48 4f a9 6a 5a f2 a4 10 39 0f 7b 0f 86 01 00a0: 49 20 64 00 d7 94 08 d0 8a d8 2a ad 6a 5a 7e b4 00b0: 0e 53 0e 9b 0e b7 01 09 20 5a 00 db 99 a8 f2 8f 00c0: e8 38 af aa 8a c2 9e 0e de 0f 48 0e 31 01 31 20 00d0: 5a 00 ce 9b c8 ff 88 68 1b b2 6a 5a ca a7 0f c3 00e0: 0e 74 0e 58 01 34 20 5a 00 d7 9b 39 1b 97 b8 c5 00f0: b0 2b 3a d6 b5 01 6b 00 6a 02 9e 00 03 20 13 00

bernard@f6bvp-Ubuntu:~/GNU-Radio/gr-satellites$

Linux f6bvp-Ubuntu 5.3.0-51-generic #44~18.04.2-Ubuntu SMP Thu Apr 23 14:27:18 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux GNU Radio Companion 3.8.1.0 and main gr-satellites branch

Bernard

daniestevez commented 4 years ago

@py2sdr has had the same problem. He has two machines with the same distribution, GNU Radio version, etc., and one of them shows this problem and the other doesn't. The difference we've been able to spot between both machines is that the problematic one has AVX2, while the other doesn't. We suspect from the AVX2 implementation for the Viterbi decoder in Volk.

In the case of PY2SDR, this was fixed by running volk_profile and making sure that in ~/.volk/volk_config has the line

volk_8u_x4_conv_k7_r2_8u spiral spiral

rather than something mentioning AVX2. In this way, the SSE3 Spiral Viterbi decoder will be used instead.

@Darkkey it would be good if you can check if this also fixes your problem.

Darkkey commented 4 years ago

Yeah, that fixes the problem. Was able to decode:

$ gr_satellites FUNcube-1 --wavfile ao73.wav --samp_rate 48e3 --hexdump
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 256
contents = 
0000: 89 00 00 00 00 00 00 00 00 1f cc 00 ce 02 d1 00 
0010: 00 07 08 09 09 00 00 05 01 01 00 40 13 2f c8 f2 
0020: 5c 8f 34 23 f3 ba 0b 5d 62 74 51 c7 ea fa 69 4a 
0030: 9a 9f 00 09 ef a0 1f f4 a7 ea 4a c6 8f 11 40 11 
0040: 1e 10 f7 01 3e 20 64 00 d7 8b f8 d7 94 c8 93 a8 
0050: 2a da 52 a6 0e 58 0e c8 0f 4e 01 1d 20 5a 00 db 
0060: 94 a8 aa 8a 98 13 ac 69 0a a6 a8 10 e6 10 92 0f 
0070: b8 01 50 20 64 00 d7 96 a8 c1 8b 48 25 ab a9 ca 
0080: ce 9d 10 76 0f c9 10 55 01 3a 20 5a 00 d7 97 29 
0090: 08 8c 48 4f a9 6a 5a f2 a4 10 39 0f 7b 0f 86 01 
00a0: 49 20 64 00 d7 94 08 d0 8a d8 2a ad 6a 5a 7e b4 
00b0: 0e 53 0e 9b 0e b7 01 09 20 5a 00 db 99 a8 f2 8f 
00c0: e8 38 af aa 8a c2 9e 0e de 0f 48 0e 31 01 31 20 
00d0: 5a 00 ce 9b c8 ff 88 68 1b b2 6a 5a ca a7 0f c3 
00e0: 0e 74 0e 58 01 34 20 5a 00 d7 9b 39 1b 97 b8 c5 
00f0: b0 2b 3a d6 b5 01 6b 00 6a 02 9e 00 03 20 13 00 
***********************************

Thank you so much for finding the solution! :)

daniestevez commented 4 years ago

Thanks for the fast reply.

Well, I guess this fixes the problem, but there is an underlying bug in Volk. If any of you wants to report it, please go ahead. I tried to replicate this issue today in the only AVX2 machine I have at hand and it worked OK for me.

I'll proceed to close the issue now.

py2sdr commented 4 years ago

I had the same issue. Initially I thought it could be related to the version of Linux I was using. But after installing the same Linux version (Xubuntu 20.04) on two separate machines and having the problem on one and not on the other, I contacted Daniel and he suggested me to run volk_profile. After that, the problem was resolved.

Much thanks, Daniel!

73, Edson PY2SDR

daniestevez / gr-satellites

AO-73 example doesn't decode #88