WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2015-Sep-08 02:27:32

vten3075
Member
Registered: 2015-Mar-05
Posts: 18

Star Configuration for CM-PLL Modules

Hi,

We are trying to connect our boards in a star topology, so our secondary nodes can be triggered all at the same time. We are using the CM-PLL Clock Modules, and have configured the 1st board as the head node and the 2nd board as the tail.

We want to trigger the 2nd board using the debug headers, so we connected the head node's Pin 7 (Trigger Output D3) to the tail node's Pin 15 (Trigger Input D3), since we are using D3 in our code, using http://warpproject.org/trac/wiki/WARPLa … bugHeader. The GND pins on the boards have been connected similarly. However, we cannot get the tail board to turn on properly and it shows the 'error' on the hex display (88). We have also tried connecting the clock modules together using the MMCX Jack, but that hasn't worked either.

We have tried following what was written here http://warpproject.org/forums/viewtopic … 495#p13495 but we have been unable to properly execute the star/tree topology.

Can you please help us? Thank you.

Offline

 

#2 2015-Sep-08 08:38:50

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: Star Configuration for CM-PLL Modules

Have you connected the set the SIP switches on the CM-MMCX correctly and connected the clocks?  Please see the WARPLab clock configuration guidelines and also an example of connecting two nodes with the CM-MMCX modules.  If you connect the UART output of the "tail board", you can get a better sense of where it stopped in the boot process.  However, from your description, it looks like the "tail board" is not properly receiving clocks.

Offline

 

#3 2015-Sep-08 20:25:22

vten3075
Member
Registered: 2015-Mar-05
Posts: 18

Re: Star Configuration for CM-PLL Modules

We are using CM-PLL clock modules, not the CM-MMCX. We only tried connecting two of the CM-PLL clock modules with the jack, but it did not work.

Offline

 

#4 2015-Sep-08 22:25:13

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Star Configuration for CM-PLL Modules

Can you describe the cable connections between your boards in detail? Specifically, what pins/connectors are connected to which pins/connectors on which boards, using what kind of cable?

One important note- the MMCX jack on the CM-PLL is an input only. You cannot connect two CM-PLL boards together using an MMCX cable. Connections between CM-PLL boards must use the Samtec coax ribbon cables described in the CM-PLL user guide.

Offline

 

#5 2015-Sep-08 23:49:10

vten3075
Member
Registered: 2015-Mar-05
Posts: 18

Re: Star Configuration for CM-PLL Modules

Our Head node is connected to 2 Tail boards, one is connected via the daisy chain, and the second via the debug headers.

From the Head to the 2nd Tail node, we have:
Head: Gnd pin to Tail: Gnd pin
Head: Pin7 Trigger Output D3 to Tail: P15 Trigger Input D3

We are not sure if this is correct. How do we connect the debug header pins from the Head node to the Tail node using the CM-PLL?

Offline

 

#6 2015-Sep-09 08:29:21

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: Star Configuration for CM-PLL Modules

So, if I understand correctly, you want to daisy chain the clocks using the CM-PLL modules but then connect the triggers for some of the boards using the debug header pins instead of fully daisy chaining the triggers?

In that case, you would need the cabling set up to be:

HEAD   --> TAIL_1 :  1 CM-PLL cable (for both clocks and triggers); Enable Trigger output D3 on the HEAD;  Enable Trigger input D3 on TAIL_1
TAIL_1 --> TAIL_2 :  1 CM-PLL cable (for clocks)
HEAD   --> TAIL_2 :  1 Twisted pair (for triggers):  GND to GND and Pin 7 Trigger Output D3 to P15 Trigger input D3 (This will allow the same D3 trigger output to trigger both TAIL nodes)

The CM-PLL input pins are ORed with the Debug Header input pins in the trigger manager.  Similarly, the CM-PLL output pins are replicated versions of the Debug output pins.

The main thing is to make sure that the TAIL_2 node is getting clocks and that you have enabled the appropriate trigger inputs and outputs on the respective nodes.  Also, make sure that you have the appropriate settings for the CM-PLL module for each of the nodes. 

It should be easy to see the trigger pulse on the debug header pins with a scope if you want to make sure the triggers are being output.

Offline

 

#7 2015-Sep-09 23:15:57

vten3075
Member
Registered: 2015-Mar-05
Posts: 18

Re: Star Configuration for CM-PLL Modules

Hi murphpo & welsh,

Thanks for your quick response. We've connected it as above, with the CM-PLL cable from TAIL_1 output to TAIL_2 input etc., but our TAIL_2 will not turn on properly and the HEX shows a '88'/error or doesn't turn on at all (HEX is blank). Our SIP switches are set to 001110 for TAIL_1 and TAIL_2 and our HEAD is set to 110101 (as per http://warpproject.org/trac/wiki/WARPLa … ebugHeader). We're not sure we have set the SIP switches correctly though, or if we have correctly connected it.

We also tried running

wl_triggerManagerCmd([primary_tx_node,node_rx], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3, T_OUT_D1], [T_IN_ETH_A]); %First node triggered by Ethernet
wl_triggerManagerCmd(node_tx2, 'input_config_debounce_mode', [T_IN_D3], 'enable');

to enable Trigger output D3 on the HEAD (primary tx node) and the trigger input D3 on TAIL_1 (node_tx2), but this still caused problems since TAIL_2 (node_tx3) won't turn on.

To get it to turn on, we had to switch the SIP switch for TAIL_1 to 101101 (Middle), which is obviously not correct. However, we did not use the D3 outputs, and instead ran a code like this:

wl_triggerManagerCmd([primary_tx_node,node_rx], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3, T_OUT_D3], [T_IN_ETH_A]); %First node triggered by Ethernet
wl_triggerManagerCmd(node_tx2, 'input_config_debounce_mode', [T_IN_D3], 'enable');       
wl_triggerManagerCmd(node_tx3, 'input_config_debounce_mode', [T_IN_D3], 'enable');       
wl_triggerManagerCmd(node_tx2, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC], [T_IN_D3]); %All other nodes triggered by CM-PLL trigger connections
wl_triggerManagerCmd(node_tx3, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC], [T_IN_D3]); %All other nodes triggered by CM-PLL trigger connections

But this still does not work, even though there is no output config for TAIL_1 and TAIL_2 and both are meant to be triggered by T_IN_D3.

We think this is because it is still somehow taking in the D3 output from TAIL_1, but our result is the same.

Can you please help us? Thanks again.



Also, two of our boards (0036 and 0682) are having some hardware-related issues and we are not sure if it is affecting it.

Board 0036 (TAIL_1)'s on/off switch is fairly unstable and the board will sometimes will not turn off or turn on by itself even if it is in the "off" position, and Board 0682 (TAIL_2) consistently has the '88.'/error issues or HEX values not appearing at all, even though we know the SD card works. With Board 0682, sometimes not even rewriting the .bin files or swapping out the SD card for another board's SD card (which we know is working) will not work. Is it possible that these issues are affecting our result as well?



We've also gone through and checked a few things with the normal HEAD (110101) --> MIDDLE (101101) --> TAIL (001110) nodes too. We are running a transmit beamforming code and trying to make a 12 Tx to 1 Rx (12x1) MISO system. We have checked all the mathematics and encoding parts etc. in our code, but we cannot figure out why it is not working. We've tested it with an 8x1 system using two boards (a HEAD and a TAIL) as well as using the 3-node system, but only using the 4RF on the HEAD and the TAIL nodes, and it works perfectly. But when we try to incorporate the MIDDLE node in any way (8x1 HEAD --> MIDDLE, 8x1 MIDDLE --> TAIL and 12x1 HEAD --> MIDDLE --> TAIL) the received signal Rx looks like either the AGC is not working as it should or there are synchronisation issues. Instead of a relatively constant amplitude, we get something that resembles a sine wave (similar to what a modulated signal would look like).

The trigger commands we are using are:
wl_triggerManagerCmd([primary_tx_node,node_rx], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3, T_OUT_D3], [T_IN_ETH_A]); %First node triggered by Ethernet
wl_triggerManagerCmd(node_tx2, 'input_config_debounce_mode', [T_IN_D3], 'enable');        % enable M and T inputs
wl_triggerManagerCmd(node_tx3, 'input_config_debounce_mode', [T_IN_D3], 'enable');       
wl_triggerManagerCmd(node_tx2, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3], [T_IN_D3]); %MIDDLE
wl_triggerManagerCmd(node_tx3, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC], [T_IN_D3]); %TAIL

We've tried to eliminate all other factors too, such as the AGC gain, AGC delay, RF & Baseband gain, Tx and Rx gain, channel (we are using 5GHz, channel 14), the boards (we have swapped out the two boards mentioned above for some other ones) and our antennas as well, and we even tested the actual delay of the Tx, using this part:

node_tx1.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 2*56.25);
node_tx2.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 1*56.25);
node_tx3.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 0);

We originally thought it was because this delay (2*56.25) was too long and the channel was interfering with our signals, so we wanted to put it into a star topology instead. We have determined that with all the working 8x1 configurations, no matter how much delay we put here (we put up to 20*56.25) and how much we separated the delay by (Head with 20*56.25 delay and TAIL with 0), we could still get a clean, accurate signal. The only thing that we can think of is that we have not configured the middle node correctly, and instead of a 101101 configuration for the SIP switches, it might need to be something else. Is there something we have forgotten to enable so we can pass on the T_OUT_D3 and Clock from MIDDLE to TAIL?

Thanks for your time.

Last edited by vten3075 (2015-Sep-10 04:16:19)

Offline

 

#8 2015-Sep-10 08:54:38

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: Star Configuration for CM-PLL Modules

Ok, there are a couple of different parts to this post, so there will be multiple responses :)

Thanks for your quick response. We've connected it as above, with the CM-PLL cable from TAIL_1 output to TAIL_2 input etc., but our TAIL_2 will not turn on properly and the HEX shows a '88'/error or doesn't turn on at all (HEX is blank). Our SIP switches are set to 001110 for TAIL_1 and TAIL_2 and our HEAD is set to 110101 (as per http://warpproject.org/trac/wiki/WARPLa … ebugHeader). We're not sure we have set the SIP switches correctly though, or if we have correctly connected it.

...

To get it to turn on, we had to switch the SIP switch for TAIL_1 to 101101 (Middle), which is obviously not correct.

The first issue is that you only have a star configuration for triggers.  You have to daisy chain the clocks.  This means that TAIL_1 must be in the 101101 (Middle) configuration since it needs to accept clocks from the HEAD node and output clocks to the TAIL_2 node.  Since you do not enable the output trigger on the debug header of TAIL_1, that means the trigger for TAIL_2 will come from the HEAD node via the twisted pair.


wl_triggerManagerCmd([primary_tx_node,node_rx], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3, T_OUT_D3], [T_IN_ETH_A]); %First node triggered by Ethernet
wl_triggerManagerCmd(node_tx2, 'input_config_debounce_mode', [T_IN_D3], 'enable');       
wl_triggerManagerCmd(node_tx3, 'input_config_debounce_mode', [T_IN_D3], 'enable');       
wl_triggerManagerCmd(node_tx2, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC], [T_IN_D3]); %All other nodes triggered by CM-PLL trigger connections
wl_triggerManagerCmd(node_tx3, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC], [T_IN_D3]); %All other nodes triggered by CM-PLL trigger connections

But this still does not work, even though there is no output config for TAIL_1 and TAIL_2 and both are meant to be triggered by T_IN_D3.

We think this is because it is still somehow taking in the D3 output from TAIL_1, but our result is the same.

First, you do not need T_OUT_D3 twice in the first line, unless you meant to put T_OUT_D0.  Second, are you able to get the setup to work with a single TAIL node (i.e. HEAD --> CM-PLL cable --> TAIL_1)?  If this works, then when you set add the second TAIL_2 node, check to make sure you are using the correct debug header pins.  All of our examples that use a twisted pair to route triggers use the T_OUT_D0 pin.  This was to make it easy to connect both the ground and signal since they were next to each other.  Check to make sure you are using T_OUT_D3 with your twisted pair.  If not, then make sure the appropriate output trigger is being set in the HEAD node.

Offline

 

#9 2015-Sep-10 08:55:52

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: Star Configuration for CM-PLL Modules

Also, two of our boards (0036 and 0682) are having some hardware-related issues and we are not sure if it is affecting it.

Board 0036 (TAIL_1)'s on/off switch is fairly unstable and the board will sometimes will not turn off or turn on by itself even if it is in the "off" position, and Board 0682 (TAIL_2) consistently has the '88.'/error issues or HEX values not appearing at all, even though we know the SD card works. With Board 0682, sometimes not even rewriting the .bin files or swapping out the SD card for another board's SD card (which we know is working) will not work. Is it possible that these issues are affecting our result as well?

Please contact Mango (support[at]mangocomm.com) to discuss repair options.

Offline

 

#10 2015-Sep-10 11:05:30

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Star Configuration for CM-PLL Modules

vten3075 wrote:

We've also gone through and checked a few things with the normal HEAD (110101) --> MIDDLE (101101) --> TAIL (001110) nodes too. We are running a transmit beamforming code and trying to make a 12 Tx to 1 Rx (12x1) MISO system. We have checked all the mathematics and encoding parts etc. in our code, but we cannot figure out why it is not working. We've tested it with an 8x1 system using two boards (a HEAD and a TAIL) as well as using the 3-node system, but only using the 4RF on the HEAD and the TAIL nodes, and it works perfectly. But when we try to incorporate the MIDDLE node in any way (8x1 HEAD --> MIDDLE, 8x1 MIDDLE --> TAIL and 12x1 HEAD --> MIDDLE --> TAIL) the received signal Rx looks like either the AGC is not working as it should or there are synchronisation issues. Instead of a relatively constant amplitude, we get something that resembles a sine wave (similar to what a modulated signal would look like).

A couple of things come to mind:

1) Until you verify that your 3-node transmitter triggering setup is working as expected, all bets are off on trying to run your beamforming algorithm. welsh had some good suggestions on how to debug that. Another debugging step that will be very useful is to enable yet another trigger output on each of your three Tx nodes with the following code chunk:

Code:

wl_triggerManagerCmd([primary_tx_node,node_rx], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3, T_OUT_D2, T_OUT_D0], [T_IN_ETH_A]); %First node triggered by Ethernet
wl_triggerManagerCmd(node_tx2, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3, T_OUT_D2], [T_IN_D3]); %MIDDLE
wl_triggerManagerCmd(node_tx3, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D2], [T_IN_D3]); %TAIL

If you have an oscilloscope with at least 3 channels, you can take a look at the D2 trigger output on each of your boards and verify that they all synchronized at the same time. D2 wouldn't actually be used for any triggering -- it's just for easy oscilloscope access access.

2) If you find that there is a + or - 1 sample "jitter" in the start times between your transmit nodes across executions of your script, it could be that the trigger signals are arriving during a setup or hold time. You can fix this metastability by increasing the output_config_delay by a quarter or half a sample period to move the trigger into a safer region.

vten3075 wrote:

The trigger commands we are using are:
wl_triggerManagerCmd([primary_tx_node,node_rx], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3, T_OUT_D3], [T_IN_ETH_A]); %First node triggered by Ethernet
wl_triggerManagerCmd(node_tx2, 'input_config_debounce_mode', [T_IN_D3], 'enable');        % enable M and T inputs
wl_triggerManagerCmd(node_tx3, 'input_config_debounce_mode', [T_IN_D3], 'enable');       
wl_triggerManagerCmd(node_tx2, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3], [T_IN_D3]); %MIDDLE
wl_triggerManagerCmd(node_tx3, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC], [T_IN_D3]); %TAIL

Assuming, as welsh pointed out, that the second T_OUT_D3 was intended to be T_OUT_D0, this looks correct. Also, this assumes that the physical configuration of your hardware is the following:

vten3075 wrote:

primary_tx_node D3 out -> node_tx2 D3 in
  * Note: For this connection, you don't actually need to connect the debug header between primary_tx_node and node_tx2. That connection is already in place through the CM-PLL.
primary_tx_node D0 out -> node_tx3 D3 in
  * Note: This needs to be explicitly connected via the pins on the debug header.

We've tried to eliminate all other factors too, such as the AGC gain, AGC delay, RF & Baseband gain, Tx and Rx gain, channel (we are using 5GHz, channel 14), the boards (we have swapped out the two boards mentioned above for some other ones) and our antennas as well, and we even tested the actual delay of the Tx, using this part:

node_tx1.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 2*56.25);
node_tx2.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 1*56.25);
node_tx3.wl_triggerManagerCmd('output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 0);

We originally thought it was because this delay (2*56.25) was too long and the channel was interfering with our signals, so we wanted to put it into a star topology instead. We have determined that with all the working 8x1 configurations, no matter how much delay we put here (we put up to 20*56.25) and how much we separated the delay by (Head with 20*56.25 delay and TAIL with 0), we could still get a clean, accurate signal. The only thing that we can think of is that we have not configured the middle node correctly, and instead of a 101101 configuration for the SIP switches, it might need to be something else. Is there something we have forgotten to enable so we can pass on the T_OUT_D3 and Clock from MIDDLE to TAIL?

Thanks for your time.

If you are doing the star topology where node_tx2 and node_tx3 are both triggered directly from node_tx1, you shouldn't need any output_config_delay for their triggers of the baseband and AGC. That staggered triggering setup is useful when you are daisy chaining only.

Offline

 

#11 2015-Sep-10 21:27:21

vten3075
Member
Registered: 2015-Mar-05
Posts: 18

Re: Star Configuration for CM-PLL Modules

Hi welsh & chunter,

We've tested all of the different configurations above, but it still does not seem to be working. We're in the process of getting a scope to test out if the triggers are working as they should. So far on our plot, we can see the LTS being triggered and it can be detected at Rx, but the signal received is still wrong.

First, you do not need T_OUT_D3 twice in the first line, unless you meant to put T_OUT_D0.  Second, are you able to get the setup to work with a single TAIL node (i.e. HEAD --> CM-PLL cable --> TAIL_1)?  If this works, then when you set add the second TAIL_2 node, check to make sure you are using the correct debug header pins.  All of our examples that use a twisted pair to route triggers use the T_OUT_D0 pin.  This was to make it easy to connect both the ground and signal since they were next to each other.  Check to make sure you are using T_OUT_D3 with your twisted pair.  If not, then make sure the appropriate output trigger is being set in the HEAD node.

Yes, we meant to put T_OUT_D0, sorry for the confusion. The setup works with a single tail node connected by the CM-PLL. When we add TAIL_2, we tried both T_OUT_D0 to T_IN_D3 (and gnd) and T_OUT_D3 to T_OUT_D3 with the correct pins, and the correct triggers were used, but neither worked.

Until you verify that your 3-node transmitter triggering setup is working as expected, all bets are off on trying to run your beamforming algorithm. welsh had some good suggestions on how to debug that. Another debugging step that will be very useful is to enable yet another trigger output on each of your three Tx nodes with the following code chunk:

We've tested the 3 nodes transmitting together in a DAISY CHAIN format with a different code and does not work - we have the same synchronisation issue. We took one of our working TxBF codes and spread out the Tx antennas so we have 1 antenna on the HEAD, MIDDLE and TAIL nodes, and everything else is the same, so we are pretty sure it's not our code, and it is the MIDDLE board that does not work as it should, and we are not sure how to proceed.

We will try measuring D2 with the scope once we get it.


We're sure that the middle node is transmitting (and according to the received samples, they are received at the same time), but we still can't get the correct result, because it is definitely not synchronised. Is it possible that there's some kind of configuration in the middle node that we haven't put in?



We are also working on Multi User BF, for a 4x2 case. For the RxBF, it works perfectly, but when we use the same calculations and do the channel estimate at the transmitter with the TxBF, it gives a very noisy result that looks like it has a lot of interference, and we can't figure out why. Could you please help us with this as well? Thanks again for all your help.

Last edited by vten3075 (2015-Sep-10 21:42:54)

Offline

 

#12 2015-Sep-10 23:19:31

vten3075
Member
Registered: 2015-Mar-05
Posts: 18

Re: Star Configuration for CM-PLL Modules

Hi,

We've sort of solved the issue, we have configured it in the star formation and set TAIL_1's SIP to 101110 instead of 101101, and it is now working. Our layout looks like this:

HEAD: 110101, TAIL_1: 101110, TAIL_2: 001110
HEAD --> CM-PLL --> TAIL_1
HEAD --> Debug Header Output D3 to Debug Header Input D0 and GND --> TAIL_2
TAIL_1 --> CM-PLL --> TAIL_2

So only the CLK of TAIL_1 is being passed on to TAIL_2, not the triggers. We think there might be some kind of hardware problem with the CM-PLL, and it cannot properly send the trigger if it has already previously been triggered by another node.

Offline

 

#13 2015-Sep-11 16:03:18

welsh
Administrator
From: Mango Communications
Registered: 2013-May-15
Posts: 612

Re: Star Configuration for CM-PLL Modules

We apologize.  You are correct that there is an issue with the CM-PLL triggers in the WARPLab 751 release.  Unfortunately, in the UCF file that maps FPGA pins to the various connectors, we used the CM-PLL Rev 1.0 mapping instead of the CM-PLL Rev 1.1 mapping.  As you can see, "cm_pll_hdr_out_d<0>" and "cm_pll_hdr_out_d<2>" are swapped from what they should be in CM-PLL Rev 1.1.

The good news is that this is easy to fix in your M-code.  When using the CM-PLL module, the mapping of trigger output pins to trigger input pins is:

Code:

T_OUT_D0  -->  T_IN_D2
T_OUT_D1  -->  T_IN_D1
T_OUT_D2  -->  T_IN_D0
T_OUT_D3  -->  T_IN_D3

Therefore, you can just use Pin 3 to propagate all the triggers in a daisy chain fashion (i.e. no twisted pairs needed):

Code:

wl_triggerManagerCmd([primary_tx_node, node_rx], 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3], [T_IN_ETH_A]); %First node triggered by Ethernet
wl_triggerManagerCmd(node_tx2, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC, T_OUT_D3], [T_IN_D3]); %MIDDLE
wl_triggerManagerCmd(node_tx3, 'output_config_input_selection', [T_OUT_BASEBAND, T_OUT_AGC], [T_IN_D3]); %TAIL

wl_triggerManagerCmd(node_tx2, 'input_config_debounce_mode', [T_IN_D3], 'enable');        % enable M and T inputs
wl_triggerManagerCmd(node_tx3, 'input_config_debounce_mode', [T_IN_D3], 'enable');        

% Note:  if debounce is disabled, the delay factor will be 31.25ns vs 56.25ns when the debounce is enabled.
wl_triggerManagerCmd(primary_tx_node, 'output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 2*56.25); 
wl_triggerManagerCmd(node_tx2, 'output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 1*56.25); 
wl_triggerManagerCmd(node_tx3, 'output_config_delay', [T_OUT_BASEBAND, T_OUT_AGC], 0);

This will trigger all of the baseband and AGCs at the same time. 

In terms of DIP switch configuration, if you push into the clock configuration documentation, you will see that the DIP switches are split into different types of functionality:  1)  The first three switches control the reference clocks on the module;  2) The second three switches control the configuration within the WARPLab clock controller.

The DIP switch setting 101110 vs 101101 is selecting between either CFG_CMPLL_A (last three switches are 101) and CFG_CMPLL_B (last three switches are 110).  The HEAD node must use CFG_CMPLL_A since this clock will be used as the reference frequency for the entire chain.  However, for the Middle / Last nodes, could use either CFG_CMPLL_A or CFG_CMPLL_B.  It shouldn't make a difference since it will be ignored due to the reference clock source being set to not use the "local oscillator" source.   However, based on some discussions, we will be updating the documentation to use 101110 as the DIP switch setting for the middle node.

We have set up a three node configuration using HEAD:  110101,  MIDDLE:  101110,  LAST:  001110  with just the CM-PLL cables and can see that all three nodes are triggered correctly and that the baseband and AGC are all triggered at the same time by using the output delay scheme described above.  If you are not able to get that to work, one other thing to check is that you are using the correct CM-PLL cables (i.e. they need to end in SBL-3).   

We will add documentation about this issue to WARPLab 7.5.1 and are fixing it in WARPLab 7.6.0.

Offline

 

Board footer