Re: [Discuss-gnuradio] weird interaction between start of burst and oscillator phase
On 10/26/2010 02:42 AM, Matt Ettus wrote: On 10/25/2010 11:20 PM, Arun Pillai wrote: Hi folks, I am seeing a very bizarre problem. I am using the USRP2 to transmit a stream of packets interleaved with silence. Each USRP packet obviously spans multiple Ethernet packets. When I send each USRP packet as part of its own burst (i.e. start of burst = 1 on the first ethernet packet corresponding to a USRP packet, end of burst = 1 on the last ethernet packet corresponding to that USRP packet, immediate = 1 on all packets, and repeated for each USRP packet), the channel that I see at the receiver for each packet has a very different phase even after accounting for CFO. However, if I send all the USRP packets along with complex zeros for intervening silence as one burst, I see that the channel phase is as expected i.e. the change in channel phase from packet to packet corresponds to exactly the CFO. Any idea why this could be happening? Thanks, Arun. See line 61 of dsp_core_tx.v, which is the NCO. During a burst, "run" is asserted, so the NCO continues to turn. When run is deasserted (i.e. between bursts), the NCO is reset to 0. Alternative ways of handling this would be to either just freeze the NCO when run is deasserted, or allow it to run all of the time. There are various reasons why you might want one mode or another. If this behavior is not desired, you can easily change those lines to have the NCO run all the time. Just to respond: changing the NCO seemed to make most of the problem go away. However, there is still some lingering weirdness: In particular, if I just send one continuous stream of data spaced by sending zeros from the host, and compute the phase, it is on a rock solid line. However, if I don't send intervening zeros, but instead just send the data at regular intervals using the timestamp in the metadata, there is some jitter in the phase. I've attached graphs of the phase as a function of packet index. timedstream.pdf is the phase of each packet when I use the timestamp metadata function. singlestream.pdf is the phase when I just send one long stream of data interleaved with zeros between packets. This graph is just for a small number of packets, but the pattern is consistent over hundreds of packets. The trend line in both cases corresponds to residual oscillator offset. I only compute oscillator offset once at the beginning, and keep it constant for all packets, so the problem is not one of offset estimation. I have looked through the FPGA code but have been unable to isolate why this might be. I'd appreciate any help you could offer. Thanks, Arun singlestream.pdf Description: application/xpdf timedstream.pdf Description: application/xpdf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] weird interaction between start of burst and oscillator phase
Thanks, Matt. That's probably it - looking at the code from tx_control.v, it seems like just twiddling the start/end of burst bits alone is not enough either, the host needs to keep sending, otherwise the FPGA thinks it is an underrun. So, it seems like the correct solution would be to change the NCO code. One other question: Where is the UHD code in terms of maturity? Will future FPGA/firmware fixes happen on the UHD code, or will the existing code also be maintained? I will have to change a bunch of my host side code to use UHD, wondering if I should invest in that effort to avail of more robust firmware/FPGA code. (I don't care about portability or for the code to work on anything other than RFX daughterboards). Rahul On 10/26/2010 2:42 AM, Matt Ettus wrote: On 10/25/2010 11:20 PM, Arun Pillai wrote: Hi folks, I am seeing a very bizarre problem. I am using the USRP2 to transmit a stream of packets interleaved with silence. Each USRP packet obviously spans multiple Ethernet packets. When I send each USRP packet as part of its own burst (i.e. start of burst = 1 on the first ethernet packet corresponding to a USRP packet, end of burst = 1 on the last ethernet packet corresponding to that USRP packet, immediate = 1 on all packets, and repeated for each USRP packet), the channel that I see at the receiver for each packet has a very different phase even after accounting for CFO. However, if I send all the USRP packets along with complex zeros for intervening silence as one burst, I see that the channel phase is as expected i.e. the change in channel phase from packet to packet corresponds to exactly the CFO. Any idea why this could be happening? Thanks, Arun. See line 61 of dsp_core_tx.v, which is the NCO. During a burst, "run" is asserted, so the NCO continues to turn. When run is deasserted (i.e. between bursts), the NCO is reset to 0. Alternative ways of handling this would be to either just freeze the NCO when run is deasserted, or allow it to run all of the time. There are various reasons why you might want one mode or another. If this behavior is not desired, you can easily change those lines to have the NCO run all the time. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] weird interaction between start of burst and oscillator phase
On 10/25/2010 11:20 PM, Arun Pillai wrote: Hi folks, I am seeing a very bizarre problem. I am using the USRP2 to transmit a stream of packets interleaved with silence. Each USRP packet obviously spans multiple Ethernet packets. When I send each USRP packet as part of its own burst (i.e. start of burst = 1 on the first ethernet packet corresponding to a USRP packet, end of burst = 1 on the last ethernet packet corresponding to that USRP packet, immediate = 1 on all packets, and repeated for each USRP packet), the channel that I see at the receiver for each packet has a very different phase even after accounting for CFO. However, if I send all the USRP packets along with complex zeros for intervening silence as one burst, I see that the channel phase is as expected i.e. the change in channel phase from packet to packet corresponds to exactly the CFO. Any idea why this could be happening? Thanks, Arun. See line 61 of dsp_core_tx.v, which is the NCO. During a burst, "run" is asserted, so the NCO continues to turn. When run is deasserted (i.e. between bursts), the NCO is reset to 0. Alternative ways of handling this would be to either just freeze the NCO when run is deasserted, or allow it to run all of the time. There are various reasons why you might want one mode or another. If this behavior is not desired, you can easily change those lines to have the NCO run all the time. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] weird interaction between start of burst and oscillator phase
Hi folks, I am seeing a very bizarre problem. I am using the USRP2 to transmit a stream of packets interleaved with silence. Each USRP packet obviously spans multiple Ethernet packets. When I send each USRP packet as part of its own burst (i.e. start of burst = 1 on the first ethernet packet corresponding to a USRP packet, end of burst = 1 on the last ethernet packet corresponding to that USRP packet, immediate = 1 on all packets, and repeated for each USRP packet), the channel that I see at the receiver for each packet has a very different phase even after accounting for CFO. However, if I send all the USRP packets along with complex zeros for intervening silence as one burst, I see that the channel phase is as expected i.e. the change in channel phase from packet to packet corresponds to exactly the CFO. Any idea why this could be happening? Thanks, Arun. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
