Multiple Adapters

[ktucker]

Looking for anyone who may have experience using multiple adapters.  For example, using an adapter to represent an SFP in a switch and then another adapter to represent an MPO>LC fiber breakout cable connected to that SFP.

 

It seems like CC wants an adapter connected directly to the Socket, so I cannot connect the MTP>LC cable adapter directly to the SFP.

 

 

[EdwardMatthew]

Hey Use an MTP>LC adapter Instead of connecting the MTP>LC fiber breakout cable directly to the SFP module, use an MTP>LC adapter. This adapter will convert the MTP connector to an LC connector, allowing you to connect the fiber breakout cable to the adapter. Then, use a separate LC patch cable to connect the adapter to the SFP module. This way, you can indirectly connect the MTP>LC fiber breakout cable to the SFP module while still adhering to the requirement of a direct connection to the SFP socket.
 

[ktucker]

Thanks Edward,

 

From an inventory control and reporting side of things, wouldn't this eliminate the SFP object entirely?  The documentation would show a switch connected directly to an MTP breakout vs an SFP then a breakout.  Functionally it would look ok, but running reports would not include any SFP modules.

Unless I'm not understanding what you're referring to.

[spettitt]

We've had this exact problem recently with the SFP and an MTP>LC breakout. Try making the breakout as a device (but change the appearance to look the same as if it were an adapter) and change the circuit number prefix of the 'fake' circuit between the SFP and breakout to something special, which could then be filtered from reports. Or, it could be deliberately not numbered. This has the benefit of being able to put the breakout 'device' anywhere, as two SFPs side by side with breakouts fitted would result in breakout tails fouling.

Edited June 19, 2023 by spettitt

[ktucker]

@spettitt  Appreciate it.  This workflow had crossed my mine, but I wanted to rule out a proper solution before going for a workaround.

 

Another #featurerequest if you ask me!

[Conrad Preen]

Hey guys! this question came up during our discussions around the design of the adapter object - would adapters be chained together? We deliberately opted for not, on the basis that the additional complexity is significant.

 

You could think of two adapters in series as a new type of adapter - and create that as a specific type. After all, the only thing an adapter does is convert one kind of socket to another - what happens in between is immaterial.

 

What @spettitt says about fouling breakout tails is a good point though - it might be nice to be able to put the adapter somewhere and pull a control point to the device socket to make the connection. I'm not a big fan of fake cables because they will be hard to filter out of the data model.

 

Good discussion - let me know what you think of my suggestion.

 

Conrad

[spettitt]

59 minutes ago, Conrad Preen said:

You could think of two adapters in series as a new type of adapter - and create that as a specific type.

 

This has inventory implications though. Having them separate would be better

 

1 hour ago, Conrad Preen said:

After all, the only thing an adapter does is convert one kind of socket to another - what happens in between is immaterial.

 

One purpose may be to convert one kind of socket to another, but another may be to convert a socket containing multiple circuits to separate identifiable sockets. In this example, one adapter's job is to deal with the format conversion, and another to split the circuits.

 

Thinking out loud - maybe a development to the adapter tool of 'hosted' and 'loose' types. Hosted types work as they are now - whereby they are hosted by a given socket on a Device. Loose types operate independently of a host socket (as lots of adaptors do in the real world) and can be positioned more freely. It would be easy to say that they are just devices - except that a Device is a hub permitting multiple inputs and multiple outputs with no prescribed hardwired paths. An adaptor has a single input hardwired to several outputs, or v/v.

 

A good example is an L-Acoustics DO-SUB, which breaks a single CA-COM multi-pole loudpseaker connector in to individual NL4 connectors to drive several sub loudspeakers. This adaptor will sit on the floor behind stacks of loudspeakers, and is not captive to a host socket.

 

Re. pulling a control point to make connections - if that could work alongside the existing functionality then that could be quite useful, but it depends what the appearance of the link looks like - the splines used for drop points may not look so nice on the schematic layer unless there is greater control over them. But a controllable spline between the output of an SFP and the input of an MTP-LC breakout would be interesting to see.

[Conrad Preen]

20 hours ago, spettitt said:

One purpose may be to convert one kind of socket to another, but another may be to convert a socket containing multiple circuits to separate identifiable sockets. In this example, one adapter's job is to deal with the format conversion, and another to split the circuits.

Yes, all that is already possible in our current adapter object - it can have multiple sockets comprising a mixture of types, signals etc.

 

20 hours ago, spettitt said:

A good example is an L-Acoustics DO-SUB, which breaks a single CA-COM multi-pole loudpseaker connector in to individual NL4 connectors to drive several sub loudspeakers. This adaptor will sit on the floor behind stacks of loudspeakers, and is not captive to a host socket.

In this case you have a cable from the source device to the input of the adapter so it effectively becomes a device in its own right in terms of our model. Which in fact it is. It needs its own name otherwise in the cable list it could become quite hard to understand which adapter we are talking about. Not to mention the list-to-drawing comparison which being a piece of software has no common sense at all.

 

If we were to support this in the adapter we could have the "host" socket appear when the adapter is not attached to a device. But this undermines the simplicity of it in a couple of ways. Until now we needed no specification of the host socket since the host device provides that info - if I go for this idea we will need more data entry. I also fear that people will use it in the wrong way and then start asking for circuits to be marked as fake. Yuk!

 

I'm open to ideas about this. But I don't want to lose our way in special cases.

 

Conrad