Transmit power stuck at 14?

My signal is fading, but my transmit power is stuck at 14dbm. Maximum transmit power is set to 27 on both ends, but it is adamently stuck at 14!!! What am I missing??

What radios and antennas are you using and in what region? Are you possibly running into a regional EIRP limitation due to the band you’re using?

Thanks for your suggestion, but I do not believe this is the case. I am in the US (Alaskan Arctic) and using the unii-1 band. 20Mhz channel with a center freq of 5172, and have a dozen links spread out across our area. I found out today that they are using a power supply from a ptp600 on the remote end, unsure about the near end… wonder if that has anything to do with it? I believe that they were lower amperage?

Can you tell us which Regulatory Band you selected for 5.1 GHz please?

What receive power are you seeing?

Are you using integrated antennas or connectorized?

The use of a PTP 600 PIDU won’t affect the maximum transmitter power that the radio can achieve.

Capture

Regulatory band 84-5.1. Using a connectorized antenna

Regulatory band 84 has an EIRP limit of 36dBm at 20MHz. What is your antenna gain?

It is set at 13 dbi on both ends, and cable loss is set to 10 db. EIRP is calculated at 30. Antenna gain is likely higher, and cables loss is lower. I seem to remember manipulating these figures in the past but it is fuzy???

PS- cambuim has been really impressive on watching these forums lately! I think we talked about an API issue a few weeks ago. Cheers! This is the reason we are investigating the cnWave line for our site-specific backbone.

1 Like

How long is your link? Do you have a link plan for it, and if so, do the receive levels match the prediction (at least when it’s not fading)

Can you show us the Wireless Configuration page of the installation wizard for both ends?

7.7 miles
did not do a link planner for this link, but had a nearly identical shot last winter that was sitting around -50. The antenna’s are not as precisely aligned perhaps (it is -42F outside right now), but the radios are not compensating by increasing the tx power for some reason. Thankyou for taking a look at this.

To be honest I’m hoping @Mark_Thomas will chime back in now, because I’m not an expert on this topic, I’m just trying to gather enough information so that the real experts will be able to solve your problem :crossed_fingers:

To that end, I suppose screenshots of the TX and RX power diagnostic plots might be useful as well.

TX power is a solid straight line at 14dbm for the past 30 days regardless of the RX power, which is precisely my problem! :slight_smile:

Fair point :laughing:. I just thought that showing the TX and RX power graphs side by side would make it absolutely clear what the problem was to anyone looking. The RX graph in particular would show how much time is being spent at the lower powers.

At the moment, I can’t satisfactorily explain the 14 dBm limit based on the configuration shown above. I’ll keep working on this part.

However, it is worth bearing in mind that the ODU restricts power quite significantly towards the bottom of the band in order to comply with the very strict out of band emission limits imposed by the FCC at 5150 MHz. RB#84 has an EIRP limit at 36 dBm in 20 MHz bandwidth, but this is reduced by 13 dB (to 23 dBm EIRP) below 5175 MHz, and reduced by 6 dB (to 30 dBm EIRP) between 5175 MHz and 5187 MHz. Try using a higher frequency channel.

Which software version is in these radio?

1 Like

Thanks Mark,
I moved to the unii-3 band, and things are operating as normal. I would like to move back to the unii-1 band once more channels are available and I can try a non-edge channel.

We investigated the calculation of the maximum transmit power. The correct value for the maximum transmitter power given the configuration you entered is 36 - 13 + 13 - 13 = 23 dBm. The ODU normally calculates transmit power correctly, but the values you entered for antenna gain and cable loss exposed a problem in the calculation, hence the result of 14 dBm. We’ll fix this problem in the next release.

If you can find a channel above 5187 MHz then you will avoid the 13 dB edge channel backoff, and you should be able to operate at 27 dBm with the current software.

Can you tell us which version of software you’re using at present please?

2 Likes

Mark,
Just got back from vacation, so apologize if I left you hanging…hopefully you will see this! We are currently running a one-off software version that cambium had provided to us. We had the need to run 2 isolated networks, with the help of the aux port, and the more recent firmware broke that capability. I believe it is just a previous firmware version <50670-01-47> that we are using. I would be ecstatic if Cambuim would reintegrate this feature in to newer firmware or at least a fork!
As I get back in to monitoring this link, I now have an error “Incompatible License Keys”. I am using th 1-5.8ghz regulatory band, USA license country, and FULL license capacity. Any quick fix for that? I will start a new thread perhaps, but the radio is functioning just fine it seems…anything to be worried about?

Hi pboynton,

I hope it was a good vacation!

Incompatible License Keys

Incompatible License Keys is the error value for the alarm Incompatible Regulatory Bands. This alarm is normally generated if the two ends of the link have different RB numbers. Is it possible that you have RB#1 at one end and RB#101 at the other end?

Second Data Service

We introduced the Second Data Service (SDS) in PTP 650 as a way to support customer data at two different wired Ethernet ports. This was in reality a workaround because we hadn’t implemented Ethernet switching in the ODU. From 50670-02-60 onwards we support the embedded Ethernet switch. At that point we assumed that the need for the SDS would disappear, but several customers have told us that the SDS workaround was actually a useful feature.

As you point out above, it’s possible to use the SDS with PTP-650-compatibility firmware on the PTP 670. The latest in this sequence is 50670-01-50. This has the same features as 650-01-50.

If you still think that SDS would be useful then we need to create a feature request. Two options are worth investigating: a second virtual circuit just like the original SDS, or some more general purpose VLAN functions that would allow a separate virtual circuit to be configured. What do you think?

Mark