Variaing Data are not transmitted!

Using FMCOMMS4 and ZCU102 Rev 1.1. 

Hardware : HDL_2018_R2 + dac_upack_v2

Software : No-OS_2018_R2

I am implementing a QPSK modulator/demodulator by using the setup explained above.

When I use the fixed data like "Hello World" and send it without changing the message itself, the transmission is successfully completed. The transmitted and QPSK modulated data can be received and demodulated every time without any problem. But I am trying to send different data on each transmission. Unfortunately, there is problem about demodulating the data. Why the data is not demodulated when I change the data on every transmission?

Top Replies

    •  Analog Employees 
    Feb 9, 2021 in reply to emincetin +1 verified
    www.mathworks.com/.../quote]

    This is not an ADI model, it is authored and maintained by MathWorks. If you have questions about its implementation you will have to contact MathWorks support…

Parents
  • 0
    •  Analog Employees 
    on Feb 1, 2021 2:57 PM 2 months ago

    You are not really providing much info here. I'm am also not sure of what you mean by "Hello World" example for QPSK. The standard No-OS example only transmits a sinusoid.

    -Travis

  • The problem in here is that If I send a custom data without change it, the transmission is completed successfully. But If I change my data for every transmission, I can't demodulate it. By the way, I setup a tick timer and every 250 usec I start tranmission then capture it. When I say "hello world" I mean it is custom data. I am sending my packets which is consist of 26 bit barker (13 for I channel and 13 for Q channel), 1 Byte unsigned integer header, 12 Byte floating point number, 27 bit bernoulli, 2 byte CRC. (Exactly 100 I and 100 Q bit. Because the QPSK model is succesfully work for 100 I/Q pair.)

    In a time perspective, If I send always the same floating point number like "1.1" in packets, The tranmission is successfully completed. I can send, receive and demodulate it. But when I change the "1.1" like "1.2", "1.3", "1.4" in every tranmission, I can't demodulate it. 

    The interesting point, under these circumstances there is no problem with sending and receiving data succesfully in HDL loopback mode. However when I try to send throughly RF antennas or RF Cable, the transmission is failed.

    If you ask what is the success and fail, after sending data I am looking how many of tranmission is completed successfully by looking the TRANSFER COMPLETED FLAG of ADC_IRQ. Furthermore, if that flag is not set I say transmission is failed.

Reply
  • The problem in here is that If I send a custom data without change it, the transmission is completed successfully. But If I change my data for every transmission, I can't demodulate it. By the way, I setup a tick timer and every 250 usec I start tranmission then capture it. When I say "hello world" I mean it is custom data. I am sending my packets which is consist of 26 bit barker (13 for I channel and 13 for Q channel), 1 Byte unsigned integer header, 12 Byte floating point number, 27 bit bernoulli, 2 byte CRC. (Exactly 100 I and 100 Q bit. Because the QPSK model is succesfully work for 100 I/Q pair.)

    In a time perspective, If I send always the same floating point number like "1.1" in packets, The tranmission is successfully completed. I can send, receive and demodulate it. But when I change the "1.1" like "1.2", "1.3", "1.4" in every tranmission, I can't demodulate it. 

    The interesting point, under these circumstances there is no problem with sending and receiving data succesfully in HDL loopback mode. However when I try to send throughly RF antennas or RF Cable, the transmission is failed.

    If you ask what is the success and fail, after sending data I am looking how many of tranmission is completed successfully by looking the TRANSFER COMPLETED FLAG of ADC_IRQ. Furthermore, if that flag is not set I say transmission is failed.

Children
  • 0
    •  Analog Employees 
    on Feb 2, 2021 7:39 PM 2 months ago in reply to emincetin

    If things are working reliably for one packet and not the others, my guess is that your synchronization methods are not robust to certain symbol sequences. Have you verified you can handle these packets in simulation and with RF data offline?

    -Travis

  • didn't try verify to handle in simulation etc. But I realized that the signal comes properly but it can't lock to the Barker. When I changed the threshold to 15 from 16 for 13 bit barker, It locks. I am working with threshold 15. I am asking you too much about that model because of the fact that it is your's design. Excuse me please.

    I have a problem that I couldn't figure out yet why it is happening. I am sending qpsk modulated signal then demodulate it etc. As I said I send it periodically. Till now everything is ok. I measure between 2 exact point. It does not matter where it is. The problem is that sometimes I measure the delay between these points as lets say X. But sometimes it is X + Y. All of the measurements is taken under same conditions. X and Y are almost constant.

    I get the X values from measurements, after power cycle the board, I get X + Y values. What could be the reason?

    Thank you. 

  • 0
    •  Analog Employees 
    on Feb 8, 2021 8:56 PM 2 months ago in reply to emincetin
    I am asking you too much about that model because of the fact that it is your's design. Excuse me please.

    I asked this originally, what QPSK design are you referring to?

    I get the X values from measurements, after power cycle the board, I get X + Y values. What could be the reason?

    If you are triggering transfers from software there will be always randomness associated with any series of actions.  For example, if you submit a buffer to the TX DMA and then request one from the RX DMA you cannot guarantee every time only N cycles have passed inside the fabric.

    From HDL the link between the transceiver and the FPGA is tuned during every boot, which can change the delay. There are also FIFOs in the path which must be reset to have determinism. Both these can cause a variable delay. However, it will be fixed after the first boot and transfer. Note that this is digital lay inside the system when using loopback. Your receiver should be able to handle randomized delay.

    -Travis

  • what QPSK design are you referring to

    https://www.mathworks.com/help/supportpkg/xilinxzynqbasedradio/ug/hw-sw-co-design-qpsk-transmit-and-receive-using-analog-devices-ad9361-ad9364.html;jsessionid=54a6f9d64f798ff678b473361398

    My design is based on that model.

    If you are triggering transfers from software there will be always randomness associated with any series of actions.  For example, if you submit a buffer to the TX DMA and then request one from the RX DMA you cannot guarantee every time only N cycles have passed inside the fabric.

    Yes I trigger transfers from software. I suppose that this delay does not affect too much my system.

    However as you said, transceiver - fpga link and FIFOs should be main problem. I will try resetting FIFOs to have determinism, thanks.

    However, it will be fixed after the first boot and transfer.

    Interesting point is that If I try the system with HDL loopback, collect measurements and then plot histogram of these measurements, I see that Gaussian shaped distribution but with its spurious. By using RF cable or antenna It has no spurious and I see one Gaussian distribution. If it is not clear I will attach histogram of my results. 

    Actually this is not my main problem. As I said the main problem is gettin X versus X + Y. 

    Thanks again. 

  • +1
    •  Analog Employees 
    on Feb 9, 2021 6:33 PM 2 months ago in reply to emincetin
    www.mathworks.com/.../quote]

    This is not an ADI model, it is authored and maintained by MathWorks. If you have questions about its implementation you will have to contact MathWorks support.

    Interesting point is that If I try the system with HDL loopback, collect measurements and then plot histogram of these measurements, I see that Gaussian shaped distribution but with its spurious. By using RF cable or antenna It has no spurious and I see one Gaussian distribution. If it is not clear I will attach histogram of my results. 

    I cannot make any argument in regards to going out into the analog domain, but for digital loopback, this should not change assuming you are not re-initializing the part and you are accounting for the FIFOs.

    However, this should not matter to your receiver as it should handle any offset since in a real scenario this offset is truly random.

    -Travis

    [/quote]