The CMM should continue providing sync even if GPS track is lost. This is the main complain.
CMM Power supply should be available in a weatherised version; customers do not always avail of an indoor place to install it. Another suggestion was to have enough space inside the CMM box to place the power supply module.
Not top priority, but it would be nice that the CMM could power the PTP300/500/600 series

Enrique

More feedback from a large user:
1) At a minimum the ability to link timing between units and thus no multiple GPS units at a site

2) Make the cable run holes in the unit large enough to feed in 4 or 5 already terminated cable ends

3) Move the cable plug-in/connectors away from the board and back of the CMM box so you can actually reach in to manipulate the cables

4) Move the default switch away from the cable ends

5) Add a software feature that shows the state of the default switch so you don't have to be on-site to know if the switch is in the default position or not

6) Add a line at the top of each page that says what user you are logged in as

7) Silkscreen or otherwise label each port that is away from the board with it's port number

8) Add a hyper-link to each stat in the port MIB that will go to a web-page (when the unit is on-line) that gives an explanation of what the data represents.

9) On the MIB Port Selection page - across the top or bottom of the data, it would be nice to have the Port Status information such as:

Port Description Label

Link

100BaseT

Full Duplex

Powered

Uplink

 

So you don't have to flip back and forth to remember which Port is which. This will be really important with more ports available.

Customers have been asking for the ability to connect an external Sync. source to the CMM instead of using his own GPS Yair

An option to deploy an indoor CMM and select individual components as needed.  For example - this could be a scenario where a user could deploy their own "CMM swtich" and all we provide is the GPS sync and Power injection element.  This would removed the need for us to maintain and update the switch technology and a user could select a device that fits in with their current wired infrastructrue strategy.

From a large NA customer: 1.       Separate powered/timed ports – not tied by internal switch like they are on the CMM3

2.       Oscillator that continues to provide timing when GPS is lost

3.       Dual hot swappable power inputs

4.       Ability to slave more ports by adding slave units.

 

Two things that were annoying about the CMM4 was that it was HUGE, expensive and really didn’t give us more ports than CMM3. We typically use the CMM3 at our smaller sites to generate timing where we don’t need network segmentation. At our larger sites we need to have the capability of providing timing/power to Moto devices while having the flexibility to allow for multiple layer 3 segments. Usually have a layer 3 switch/router available, so don’t need any switch provided in the CMM. This is where the CTMs work great.

If the PTP backbone is truly a ring, each node should have a router and not just a switch so that optimum and backup directions of data flow can be performed.

Not if it's a Layer 2 ring that supports "Seamless Mobility".  A different scenario than you propose.  We usually do this for City and County Government deployments in the Law Enforcement arena.

Customer's in Latin America have a common power of -48 V.  They would love Motorola build a custom Canopy AP with a DC Power of 48 VDC instead of the actual 24 VDC.  It would save the customer from buying  an inverter for every AP or CMM that they would have to put at a tower. This is a feature request put in under Mantis. ID number 10711

I think it would be good idea to have an option and do not include etherWAN at all. CMM would then work as fully managable power injector / sync provider and all VLAN tagging, routing etc.etc. could be done on let's say Cisco catalyst etc. There might be some heat dissipation issues but it would be good to look into that. Also I would find it very useful to have oprional RJ45 GPS sync output port so CMM can be backhauled using PTP600 series and provide sync. (It can be done, I have made special RJ12 -> RJ45 cable and it worked fine) Thanks Jiri

In situations where you deploy a wireless ring with PTP backhauls for aggregation no switch would be fine, but the customer will have to supply an appropriate switch.

If the Etherwan Switch was robust enough it could participate in the backbone and if it was integrated with the CMM that would be idea since no one would have to spec and buy another switch in the first place.

So I guess it just depends on what end goal would be.  Provide the FULL solution or put it on the customer to provide that part of the setup.

The CMM5 should have some type of "backup" sync option.  In Nov. of 2009 the US Gov't had a couple of GPS "outages"  When the CMM3 loses sync, the AP cluster then goes down causing an ISP to get lots of complaints for their customers.  There should be a feature on the CMM5 to have an internal sync when the GPS receiver can not track any satellites.

It would be nice and perhaps less expensive if the security and managed switch could be an integral part of a single switch with PoE capabilities. It would be good if there was both 24v PoE and 48v PoE output capability with a single 24v dc input. 8 or 24 hour battery backup capability is becoming a larger issue with the Electric Utilities and Smart Grid. Built in Eth and GPS surge protection are both good. Wall or pole mount hardware are needed. The door should be lockable, external padlock ok.

Most of this pertains to a mixed deployment where 802.11 or Mesh APs are behind any number of clusters and provide public network access.

Canopy is being used to backhaul DUO APs and items that provide public or open access.  The 4K MAC Limit on the present switch is not sufficient for these deployments.  It needs to be a minimum of 16k MACs that are supported for cluster that backhaul 802.11 APs such as this.

Also customers tend to want to connect them together from cluster to cluster, so when one floods it floods the next one in line causing issues.  If you support more MAC addresses this setup will become possible and save customers from having to use a different switch behind these clusters.  This also makes for more justification on the cost.

Spanning Tree Support should be extended to support MST as well.  Currently they support RSTP which will integrate with the Common STP instance of an MST based deployment but it would be better if it were per VLAN.  Most all of these systems trunk VLANs.