Ah, interesting; how much data did you send out with your previous message period time?
DISCLAIMER: Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code. Use of the Code is subject to terms of the licenses to the UHD or RFNoC code with which the Code is used. Standard licenses to UHD and RFNoC can be found at https://www.ettus.com/sdr-software/licenses/.
NI will only perform services based on its understanding and condition that the goods or services (i) are not for the use in the production or development of any item produced, purchased, or ordered by any entity with a footnote 1 designation in the license requirement column of Supplement No. 4 to Part 744, U.S. Export Administration Regulations and (ii) such a company is not a party to the transaction. If our understanding is incorrect, please notify us immediately because a specific authorization may be required from the U.S. Commerce Department before the transaction may proceed further.
On 07.07.21 23:06, Jack wrote:
> Running it at 1MS/s didnt yield particularly good results, however using 2MS/s along
> with increasing the message period time to around 150ms gives some progress. Received
> packets are few and far between, along with a very out of phase constellation. The time
> sink labeled rx is directly after the UHD sink and before the multiply constant, and
> shows an pretty expected amplitude. The out of phase constellation was the original
> problem I stumbled upon when using 3.8 and 3.9 and what caused me to try the OFDM
> example before later updating to 3.10. In my experience, changing values of the PCS does
> not bring the constellation back into phase while OTA.
>
> https://imgur.com/a/ehdr7lX
>
No comments:
Post a Comment