WARP Project Forums - Wireless Open-Access Research Platform

You need to tell us more about your hardware setup, Tx waveforms and Rx processing. What are the connections between the Tx/Rx RF interfaces? What are your trigger and clocking connections? What is your Tx waveform? And how do you estimate TOA from the Rx waveform?

And I *strongly* recommend using the latest version of our reference designs. We recently posted WARPLab 7.7. One of the changes in WL 7.7 is explicit downsample blocks in the logic path of the Ethernet trigger signals. This fixes a potential source of timing variation across nodes that share trigger signals.

murphpo wrote:

You need to tell us more about your hardware setup, Tx waveforms and Rx processing. What are the connections between the Tx/Rx RF interfaces? What are your trigger and clocking connections? What is your Tx waveform? And how do you estimate TOA from the Rx waveform?

And I *strongly* recommend using the latest version of our reference designs. We recently posted WARPLab 7.7. One of the changes in WL 7.7 is explicit downsample blocks in the logic path of off-board trigger signals. This fixes a potential source of timing variation across nodes that share trigger signals.

Hello, murphpo. I'm using WARPLab 7.7 for  wl_example_siso_txrx_nodeSync.m. When I'm using WARPLab 7.4, the CM-MMCX clock modules is advanced configured. And I can directly download bitstreams to work. However, with WARPLab 7.7, after download bitstreams the node show 00, it says not working .I don't kown why it isn't better than 7.4. It may need other configuration for CM-MMCX with 7.7 ?

chunter wrote:

1) The meaning behind the SIP switches on the CM-MMCX module changed between WARPLab 7.4 and 7.7. The documentation shows the correct usage for the latest design. This user had similar issues.

2) The CM-MMCX module, unlike the CM-PLL, provides no ability to trigger another WARPLab instance -- it is only used for sharing clocks. Are you triggering both your transmitter and receiver with Ethernet triggers? Or do you have external connections between the debug headers of the two WARP v3 boards and are only triggering one board with the Ethernet trigger?

Thank you very much! I know that the CM-MMCX only make transceiver share RF and sampling clocks. I use external connections between the debug headers of the WARP V3 and only triggering one board with the Ethernet trigger . Do you mean that WARPLab 7.4 and 7.7 SIP configuration have been changed ? I will try it .  Thank you !

Do you mean that WARPLab 7.4 and 7.7 SIP configuration have been changed ?

Yes, the CM-MMCX SIP switch settings changed as of v7.5. Chris linked to the user guide above - please refer to that page for details on the current clock module switch interpretations.

Please refer to my post #2 above - you need to tell us more about your setup for us to provide any help. Specfically, what is your Tx waveform, what signal processing does your Rx code do, what is the trigger setup between nodes, etc. And you should be using WARPLab 7.7, the latest version of the ref design.

These forums are the best place for discussion as it benefits all users.

When you have the boards in a state such that there is a ±1 sample TOA measurement ambiguity, can you get the ambiguity to go away by adjusting the delay on the output trigger that feeds the receiver? The resolution of that output_config_delay parameter is 6.25ns ... smaller than a 40MHz sample period.

The CM-MMCX modules will frequency lock your boards, but their sampling phase relationship is arbitrary and changes when you program the boards. By adjusting the output_config_delay parameter, you might shift the location of the trigger away from a sampling edge.

Are you using the latest v7.7.1 version of the WARPLab Reference Design? v7.7 had a fix related to this in the Ethernet trigger subsystem.

If you are using the latest version, are there any other details about the experiment you could provide that would assist us?