git-artes / gr-isdbt

DTV ISDB-T in GNURadio
http://iie.fing.edu.uy/investigacion/grupos/artes/gr-isdbt/
Other
147 stars 35 forks source link

Upgrade to 3.8 #39

Closed v0l closed 4 years ago

v0l commented 4 years ago

Hi,

I upgraded this repo to run on GnuRadio 3.8 but im having some problems running the examples, im getting the same error as https://github.com/git-artes/gr-isdbt/issues/24, ill keep checking when i get more time but this also serves as an FYI if you or anybody else wanted to try out this module on 3.8... obviously without any guarantees :)

Also as a side note im a complete noob with GnuRadio so sorry in advance if ive done something silly..

https://github.com/v0l/gr-isdbt/commit/60c508f58aef93bffdf3fc07b35ce95788fd1084

git-artes commented 4 years ago

Hi, I've completely missed this post. Thanks for the work! I'll try when things get back to normal and I can test it in a 3.8 installation. Did you solved the problem you had? best

v0l commented 4 years ago

Dont remember, will try to get back at this soon was playing around with other DTV stuff recently so its in fashion haha

viamonte commented 4 years ago

Hi, I've been trying to run this upgraded repo but I'm also having the same issues as #24 (the only difference is that I'm using an RTL-SDR Source) and since that discussion is closed I thought it was best to bring it up here. Here's the error stack of the rx_1seg_demo

Traceback (most recent call last): File "/home/viamonte/prefix/gr-isdbt/examples/rx_demo.py", line 272, in main() File "/home/viamonte/prefix/gr-isdbt/examples/rx_demo.py", line 248, in main tb = top_block_cls() File "/home/viamonte/prefix/gr-isdbt/examples/rx_demo.py", line 149, in init self.isdbt_viterbi_decoder_0 = isdbt.viterbi_decoder(4, 1) File "/home/viamonte/prefix/lib/python3/dist-packages/isdbt/isdbt_swig.py", line 5911, in make return _isdbt_swig.viterbi_decoder_make(constellation_size, rate) RuntimeError: block::set_relative_rate: relative rate must be > 0.0 Reattached kernel driver

I'd appreciate the help, thanks.

git-artes commented 4 years ago

Hi, I didn't understand. You are using the updated repo by @v0l ? Or you're using ours? best

viamonte commented 4 years ago

The upgraded one since I'm running gnuradio 3.8

git-artes commented 4 years ago

OK. I'll start the 3.8 migration of gr-isdbt eventually, but not very soon. My experience from migrating gr-tempest is that it's not very difficult if you have few blocks, but in this case there are many, which kept me from starting (not enough free time). In the meantime, if you find a solution to this problem, we always welcome pull request ;-).

viamonte commented 4 years ago

Sure, I'll try my best, thanks for replying. By the way do you have any idea of what could be happening with the set_relative_rate of the Viterbi Decoder? I'm sure it's >0.0 with the rate set in 2/3 so I'm running low on ideas on how to fix that.

git-artes commented 4 years ago

Did you try printing the values of d_k, d_m and d_n just before the set_relative_rate? Maybe that will give us a hint on what's going on.

viamonte commented 4 years ago

Where should I write the print command to see what it shows? I'm trying to do it on the isdbt_swig.py right before the return call (the line where the error shows)

git-artes commented 4 years ago

You should go the c++ code (lib/viterbi_decoder.cc) and look for the set_relative_rate() call. Editing the swig-generated files won't work (they are overwritten by swig).

viamonte commented 4 years ago

Ok so it should look kinda like this right? Where should it be showing?

        /*
         * We input n bytes, each carrying m bits => nm bits
         * The result after decoding is km bits, therefore km/8 bytes.
         *
         * out/in rate is km/8n in bytes. We are outputting unpacked bytes. 
         * To generate k bits, we needed n bits (and since we are inputting
         * bytes with one symbol at a time, each with m bits). Thus, the 
         * relative rate would be d_k/(d_n/d_m). However, since we are outputting
         * packed bytes (all 8 bits carry useful data) the output rate is divided by
         * 8. 
         */
        assert((d_k * d_m) % (8 * d_n));

/ ---------- TRATANDO DE ARREGLAR ----------- / printf("d_k: %i\n", d_k); printf("d_m: %i\n", d_m); printf("d_n: %i\n", d_n); set_relative_rate((d_k d_m) / (8 d_n));

git-artes commented 4 years ago

You have to compile it and when run it should be displayed on the standard output (in GNU Radio's console).

viamonte commented 4 years ago

OK, so I got this: d_k: 2 d_m: 2 d_n: 3

git-artes commented 4 years ago

Then why would it complain about a negative relative rate? Did you output (d_k d_m) / (8 d_n) to check, just in case? Does it stop right at that set_relative_rate() or not?

viamonte commented 4 years ago

Yeah I just did, and well, this is what I got: (d_k d_m) / (8 d_n): 0.000000

git-artes commented 4 years ago

Well, in my c++ ignorance i clearly neglected the fact that, the way it's written, it would perform integer division and thus would result in a 0. Did you try changing the 8 to a 8.0?

viamonte commented 4 years ago

Sir, I cannot express my happiness right now, that actually worked! Thanks a lot!

I'll go ahead and fix the parameters so I can try and receive a channel in my country (I'm from Venezuela, I thought it would be best to discuss this in English so anyone could understand for future references, pero de nuevo le doy las gracias, puedo hablarle por correo? Así le explico un poco lo que quiero lograr con el receptor)

git-artes commented 4 years ago

glad it worked. I'll fix this bug in the original 3.7 version. Weird it didn't come up more often. Guess those parameters are not used very often. In any case, let us know how it went when you use hardware. We have thoroughly (or so I thought) tested the 3.7 version, but not the 3.8 one. Y sí, claro, me podés escribir por mail. saludos!