4 Likes
We've got dozens of PTP550's deployed at this point. Many are still on 4.1.x. Obviously I'd like to have DFS support on some of the shorter paths to utilize bonding.
In the past week or so I've upgraded a handful of radios to 4.3.2. Two have resulted in failure to link back up.
On the first, the slave reported 'No GPFs from Master'. Rolling the master back to what it was on previously (4.1.2) brought the link back up. I left the slave on 4.3.2 because it's working and the customers wouldn't tolerate any more down-time.
The second has been running 4.3.1 for a while. Today I upgraded both to 4.3.2 and the slave was having trouble registering. Took about 2-4 minutes. After it came up, I saw what the problem was. The uplink RSSI was -85, while the downlink was fine at the normal -59. The slave reported that Tx power used was 20-21dBm. I played around with all kinds of settings trying to figure out why the uplink was so low. Turned antenna gain down to zero. Nope. Even defaulted the slave and reconfigured. Rolled the master back to 4.3.1. Nope. Rolled the slave back to 4.3.1 and everything returned to normal. Tried to upgrade to 4.3.2 again and experienced the same issue. Both sides are back on 4.3.1. (I did get a support capture of both ends on 4.3.2 in this state)
Today we installed a completely new link. One side was 4.0.1 out of the box. The other was on 4.1.4 I believe. Both sides are happily running 4.3.2. We've also upgraded some others to 4.3.2 with no apparent issues. Both integrated and connectorized units.
What's the deal? This makes absolutely no sense.
Hi George,
With the latest 4.3.2 FW in a very rarely cases reduced Tx Power can be observed on a cetain PTP550 radios.
We are going to release 4.3.2.1 FW with the fix included wery soon.
Sorry for possible inconveniences.
Thnak you.
We had a similar issue with one of our PTP 550 links. After upgrade, the link was fine for an hour or two, but when we came back into the office it was down, and the slave end seemed to be reporting some kind of hold-off for the frequency that was in use. I attached the syslog for the device in question
- system_log.txt (4.24 KB)
I am assuming that this is the problem:
May 7 07:13:48 BH-RTC-WEL kernel: [ 0.482183] msm_bus_fabric_init_driver May 7 07:13:48 BH-RTC-WEL kernel: [ 1.597245] mtdsplit: no squashfs found in "rootfs" May 7 07:13:48 BH-RTC-WEL kernel: [ 1.602021] mtdsplit: no squashfs found in "1ac00000.nand" May 7 07:13:48 BH-RTC-WEL kernel: [ 1.828546] spi_qup 1a280000.spi: Failed to allocate dma rx chan May 7 07:13:48 BH-RTC-WEL kernel: [ 1.834448] spi_qup 1a280000.spi: Failed to allocate dma tx chan May 7 07:13:48 BH-RTC-WEL kernel: [ 1.873674] cpu cpu0: dev_pm_opp_get_opp_count: device OPP not found (-19) May 7 07:13:48 BH-RTC-WEL kernel: [ 1.970511] Frequency table not initialized. May 7 07:13:48 BH-RTC-WEL kernel: [ 1.973967] Frequency table not initialized. May 7 07:13:48 BH-RTC-WEL kernel: [ 1.978041] Frequency table not initialized. May 7 07:13:48 BH-RTC-WEL kernel: [ 1.982253] Frequency table not initialized. May 7 07:13:48 BH-RTC-WEL kernel: [ 1.986587] Frequency table not initialized. May 7 07:13:48 BH-RTC-WEL kernel: [ 1.992325] Frequency table not initialized. May 7 07:13:48 BH-RTC-WEL kernel: [ 1.995647] Frequency table not initialized. May 7 07:13:48 BH-RTC-WEL kernel: [ 1.999819] Frequency table not initialized. May 7 07:13:48 BH-RTC-WEL kernel: [ 2.004131] Frequency table not initialized. May 7 07:13:48 BH-RTC-WEL kernel: [ 2.008312] Frequency table not initialized.
I am also experiencing this issue and see the same log messages. Is there a time frame for 4.3.2.1?
We are going to release 4.3.2.1 next week.
Thank you.
2 Likes
1 Like
Nice. Going to load up a couple links this afternoon to test.