Issue in pack repack block? (former Issue in file sink block)

[Christophe Seguinot]

  
  
Hi, 

I've been investigating the pack /unpack /repack block since the
  problem raised by Maitry where not  originating from
  modulation/demodulation (which I tested and was correct). 


  Maitry did some test using repetitive pattern of bits  such as
1100, 1010,, and lead to the conclusion that its file sink was
correct (*). 
  
  I did similar test with small repetitive pattern but found
that only some of them give correct file sink (see explanation
further)
  

From this it seems that somewhere in its flowgraph bytes to bit
  or bits to bytes conversion. 

The attached flowgraph (GR 3.8 and 3.9, not compatible with GR
  3.7) illustrates my investigation. Running this flowgraph shows
  that whatever conversion is in use give the same series of bytes
  and bits.
However, in order to obtain this I had to set endianness
  to MSB for both repack blocks (all other blocks set to LSB). Il
  all endianness are set to LSB, repack blogk reverse bit ordering
  compared to pack/unpack blocks, OR uses symmetric pattern as
  Maitry does (*).


  I was expecting that unpack(8) and repack(8,1) should give the
same result
  What am I missing or misunderstanding ? 
  
  Or is this a bug? 
  

Maitry, please try to set Endianness to MSB in your repack block.
  Not sure it cans solve your issue! 

Regards, 





On 11/11/2020 09:30, Maitry Raval
  wrote:


  
  
Dear sir,


Thank you for your response.


As I have a final application to use only demodulation and
  data storage using GNU radio as my transmitter is external.
  after that also I am facing an issue for stored data which is
  random not as transmitted. so request you to please guide me
  further in this demodulation.


Thank you in advance


With Best Regards,
  Maitry Raval,
  R& D engineer|Azista Industries Pvt Ltd|
  079-40605800|www.azistaaerospace.com



From: "Christophe
  Seguinot" 
  To: "Maitry Raval"
  
  Cc: "discuss-gnuradio"
  
  Sent: Wednesday, November 11, 2020 1:53:34 PM
  Subject: Re: Issue in file sink block




  Hi 
  
  I've been investigating but did not yet found the origin of
this problem. I'm working under GR 3.9/Ubuntu 20.04
  
  
the bit sequence is correctly demodulated, whatever the
  source (txt or random) is. There is a 58 sample delay
  between bit source and demodulated bit. (so
  modulation/demodulation is OK)

however, the received bytes don't match the emitted
  bytes. 

I'm further investigating if "pack bits" and "unpack
  bits" block are used correctly (I'm not familiar to them)
  
  Regards 
  
  On 11/11/2020 04:25, Maitry Raval
wrote:
  
  

  Hello,
  
  
  I think there is some misunderstanding here, I am
using the attached grc file which includes all the ok
blocks such as polyphase clock sync, costas loop, CMA
equilizer etc for demodulation. Please check the
attached file. for the attached grc, I am facing the
below issue.
  
  
  
I understand that I
  have use online ASCII to binary converter and for that
  I am using below online converter.
https://www.rapidtables.com/convert/number/ascii-to-binary.html



But I am facing an
  issue, while I am transmitting repetitive pattern such
  as 1100, 1010 , the data stored in the file after
  mod-demod is almost similar( only some initial bits
  are changed) . Please check the screenshot attached. 


But when I am
  transmitting some random pattern instead of repetitive
  using file source, I am not receiving the same
  pattern, while I am converting the stored ASCII to
  binary using converter. 
  
  
  
  Please help.
  
  
  With Best Regards,
Maitry Raval,
R& D engineer|Azista Industries Pvt Ltd|
079-40605800|www.azistaaerospace.com
 

Re: Makefile:127: recipe for target 'test' failed during 'make test' command

[Marcus Müller]

Hi Rupak,

can you update to a moderner Ubuntu? GNU Radio 3.8 should work with
Ubuntu 16.04, indeed, but on 20.04, you can just

sudo apt install gnuradio gnuradio-dev cmake swig

and have a working GNU Radio 3.8 development environment, eradicating so
many sources of error...

Anyway, did you implement that test?
Also, when you run `ctest --output-on-failure` instead of `make test`,
you should be getting a more detailed error report.

Best regards,
Marcus


On 12.11.20 04:02, Rupak Paul wrote:
> Hi there,
> 
> I am using Ubuntu 16.08 and GNU 3.8.
> When I run ''make test'' cmd for creating new OOT module, it fails and
> shows-
> ..
> Running tests...
> Test project /home/rupak/gr-howto/build
>     Start 1: test_howto
> 1/2 Test #1: test_howto ...   Passed    0.02 sec
>     Start 2: qa_square_ff
> 2/2 Test #2: qa_square_ff .***Failed    0.42 sec
> 
> 50% tests passed, 1 tests failed out of 2
> 
> Total Test time (real) =   0.44 sec
> 
> The following tests FAILED:
>  2 - qa_square_ff (Failed)
> Errors while running CTest
> Makefile:127: recipe for target 'test' failed
> make: *** [test] Error 8
> ...
> 
> I followed every steps according to'OutOfTreeModules'.
> How can I fix this issue?
> -- 
> 
> 
> Thanking you, 
> 
> Rupak Paul 
> 

Re: Ofdm transceiver with more than 16QAM

[Marcus Müller]

You don't need to measure it. You need to ask yourself *why* a
constellation with many points might not work well with a low SNR.

Then you have your answer.

On 11.11.20 14:03, p...@koalatech.pt wrote:
> I don know how can I measure the SNR with QAM modulation. There is only
> a MPSK SNR probe.
> Can you tell me how to measure SNR with MQAM?
> 
> Thanks for your help,
> Pedro Viegas
> 
> Citando Marcus Müller :
> 
>> Hi. this is a typical question like I'd ask it when talking a student
>> through a test for a digital comms computer lab. So here's a hint:
>>
>> "Constellations with very many points" don't always work. It has to do
>> with SNR. Can you explain what the problem is with low SNR?
>>
>> Best regards,
>> Marcus
>>
>> On 10.11.20 12:56, p...@koalatech.pt wrote:
>>> Hi, I'm trying to make an OFDM transmission of a png file (9.3 kB) with
>>> 256QAM with the gnuradio
>>> example of OFDM transmitter / receiver. The USRP I'm using is the ettus
>>> n210 with the cbx daughter board. With the QPSK and 16QAM modulations it
>>> works, but with 64QAM or 256QAM I can´t receive the file, sometimes it
>>> receives some packets but most of the time it doesn't receive any byte.
>>> Can anyone help me with with this problem?
>>>
>>> Thanks in advance.
>>> Pedro Viegas
> 
>