Re: CCSDS BCH and CLTU coding
Thank you, I see that the library is built for gnuradio 3.7, is there a ported version for 3.8 by any chance? On Sat, Nov 5, 2022 at 6:39 AM WarMonkey wrote: > Check this out > > https://github.com/opensatellite/KS-1Q/blob/master/host/gr-kcsa-ks1q/lib/halfduplex_tc_impl.cc#L195 > > > Yotam Rabin 于2022年11月3日周四 21:50写道： > >> Hi everyone! >> I'm trying to design a gnuradio based ccsds transmitter using the ccsds >> 231.0-b TC standard. >> My design requires the use of BCH (63,56) code and the encapsulation of >> the data inside the CLTU packet. >> Does anyone have any experience with this in gnuradio ? I wasn't able to >> find any implementations of such coding. >> [image: image.png] >> Any help would be greatly appreciated >> Thanks, >> Yotam >> >
Re: CCSDS BCH and CLTU coding
Reuse the function and build your OOT module. On Mon, 7 Nov 2022 at 17:54, Yotam Rabin wrote: > Thank you, I see that the library is built for gnuradio 3.7, is there a > ported version for 3.8 by any chance? > > On Sat, Nov 5, 2022 at 6:39 AM WarMonkey wrote: > >> Check this out >> >> https://github.com/opensatellite/KS-1Q/blob/master/host/gr-kcsa-ks1q/lib/halfduplex_tc_impl.cc#L195 >> >> >> Yotam Rabin 于2022年11月3日周四 21:50写道： >> >>> Hi everyone! >>> I'm trying to design a gnuradio based ccsds transmitter using the ccsds >>> 231.0-b TC standard. >>> My design requires the use of BCH (63,56) code and the encapsulation of >>> the data inside the CLTU packet. >>> Does anyone have any experience with this in gnuradio ? I wasn't able to >>> find any implementations of such coding. >>> [image: image.png] >>> Any help would be greatly appreciated >>> Thanks, >>> Yotam >>> >>
Re: CCSDS BCH and CLTU coding
Great, thanks! On Mon, Nov 7, 2022 at 11:55 AM WarMonkey wrote: > Reuse the function and build your OOT module. > > On Mon, 7 Nov 2022 at 17:54, Yotam Rabin wrote: > >> Thank you, I see that the library is built for gnuradio 3.7, is there a >> ported version for 3.8 by any chance? >> >> On Sat, Nov 5, 2022 at 6:39 AM WarMonkey wrote: >> >>> Check this out >>> >>> https://github.com/opensatellite/KS-1Q/blob/master/host/gr-kcsa-ks1q/lib/halfduplex_tc_impl.cc#L195 >>> >>> >>> Yotam Rabin 于2022年11月3日周四 21:50写道： >>> Hi everyone! I'm trying to design a gnuradio based ccsds transmitter using the ccsds 231.0-b TC standard. My design requires the use of BCH (63,56) code and the encapsulation of the data inside the CLTU packet. Does anyone have any experience with this in gnuradio ? I wasn't able to find any implementations of such coding. [image: image.png] Any help would be greatly appreciated Thanks, Yotam >>>
Re: When I try to run test block receive this
Ah this looks like you entered "10.0M" into a field. Sadly, that display logic doesn't work the other way around - you need to note that as 10.0e6 (and 2.5e6 instead of 2.5M). Hope that helps! Best regards, Marcus On 06/11/2022 21.14, robin ivetic wrote: File "/home/otpisani/Downloads/top_block.py", line 139 self.filter_fft_low_pass_filter_0 = filter.fft_filter_ccc(1, firdes.low_pass(1, 15.0, 10.0M, 2.5M, window.WIN_HAMMING, 0), 1) ^ SyntaxError: invalid decimal literal >>> Done (return code 1) What am'I doing wrong. using Python 3.10.8, and companion 3.10.4.0 Robin smime.p7s Description: S/MIME Cryptographic Signature
Re: Running flowfraph dies with segfault with GR 3.10.4 (gr-fosphor)
Hi Vasil, It works now. It was about having an old / duplicate version of the gr-fosphor library lying around. I was able to remove the old library and re-install it again. However, it also required removing an old version of the gr-fosphor python library files. I'm fairly new with all this python and GR installation stuff. It seems to me that when I try to install new GR components, they tend to go to the wrong place by default. It has happened to my own OOT modules as well as 3rd party components. Maybe one of the problems is that my GR installation is from a Ubuntu package and not build from source. I tried that quite a while ago, but it was not that simple either due to so many dependencies. Anyway, big thanks for your patience in helping me out! Regards, Ville On 05/11/2022 20:26, Vasil Velichkov wrote: Hi Ville, On 04/11/2022 17.35, Ville Eerola wrote: Thread 1 "python3" received signal SIGSEGV, Segmentation fault. 0x7fff458b5fe5 in ?? () from /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 (gdb) bt #0 0x7fff458b5fe5 in () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 #1 0x7fff45961927 in () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 #2 0x7fff458c193f in gr::block::allocate_detail(int, int, std::vector > const&, std::vector > const&, std::vector > const&) () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 #3 0x7fff458d628e in gr::flat_flowgraph::allocate_block_detail(std::shared_ptr) () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 #4 0x7fff458d7845 in gr::flat_flowgraph::setup_connections() () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 #5 0x7fff4590d40b in gr::top_block_impl::start(int) () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 #6 0x7fff4590d7f6 in gr::top_block::start(int) () at /lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.4 So this segfault happens during block allocation and initialization. Check if you have multiple versions of libgnuradio-fosphor.so or fosphor_python*.so installed at the same time. ls -alt /usr/lib/x86_64-linux-gnu/libgnuradio-fosphor.so* /usr/lib/python3/dist-packages/gnuradio/fosphor/fosphor_python* If you have multiple versions then remove them all and reinstall gr-fosphor. - In order to rectify this I have updated all the OOT modules from Osmocom, which I had previously installed with: $ cd / $ rm -rf build; Ideally before removing the build directory you should have uninstalled previous version by running `make uninstall` Best Regards, Vasil -- Ville Eerola ville.eer...@iki.fi 050-4804435
