I’ve been running this firmware on my b5-lite since Friday, (1.3.1) my access point node locked up and required power-cycling after around 12 hours (not certain of time as link is not in production or monitored yet) once i noticed it was down I power-cycled and It has now been almost 48hrs with no issue. not sure how useful above info is but thought it worth reporting
Please send your logs (.tar files) from both radios to email@example.com, and collect them before rebooting if possible.
Done, hope it helps
One feature request is to have a button when in Auto mode to force renegotiation of the channels.
I’m a little unsure about 1.3.1 on our B5-Lite link. We’d been running 1.2.4 and it had a crash this afternoon, so we swung the traffic over to the backup radio and installed 1.3.1. Yes, I rebooted first.
I upgraded the station end first. I had Ethernet links to both ends of the path, via a backup radio, so I could connect to it. It did not connect to the AP end. Then I upgraded the AP. It still didn’t connect. Site survey saw it, and the SSID was set, but I had to redo the “select” process to get it to connect to the AP. Note that this is on 4940-licensed! Maybe it forgot to scan the licensed band.
Then it needed a second reboot before SNMP worked. The AP end SNMP came right up after the upgrade though.
Auto everything sometimes recommends 80 MHz channels on U-NII-3. It should be possible to limit it to a given bandwidth and range of channels. On a licensed link, it should not jump above 4990, and if we don’t want 80 MHz we shouldn’t get it. I would however like auto frequency selection, so it jumps out of the way when somebody clobbers us.
The new elastic MAC, the only choice on a -Lite, has much more latency jitter. We LOVED how the earlier sync MAC held down jitter. This is a public safety audio-over-Ethernet link, so jitter and latency are all that count; throughput never gets above 1 Mbps. The RAD IPmux used to show a typical 15-minute interval maximum jitter buffer around 7ms., with no underflows on a 22 ms. buffer. Now it’s running around 16-20 ms. latency, and a few underflows have shown up (they’re a serious problem in this application). So my observation is that the new “low-latency” mode is not low latency at all, and looks a whole lot like ordinary Wi-Fi in a PtP mode.
Even without GPS, sync does serve a function. Raw speed and throughput isn’t everything.
Upgraded one of the links to 1.3.1, and immediately saw an vast improvement both on the Connection rates, and the throughput rates. Suddenly able to get MCS9 on both sides.
Going to switch over my others later in the week when we can !
We upgrade 3 link to 1.3.1 but after an half day the traffic stop passing also if wireless seems to be connected.
We try 1x40 channel, 2x20 channel and auto-everithing but the links still stop passing traffic after few hour.
Please send support logs (.tar files) to firstname.lastname@example.org. We can help diagnose your problem.
Same issue for us running B5-Lite on v1.3.1 after around 26 hours the link stopped passing traffic, although i could reach the remote side to get to the management page, it did say connected and wireless was showing as up. the device was simply not passing any traffic. reboot of the AP side resolved this. We never had this occurance on v1.2.4 but again we had stability issues on v1.2.4 were by the AP kept disassociating and reassociating, and then completey dropped off after 48 hours. Not good in a production environment, really needs a solid set of fixes to stop these drop outs and reboots. doesnt help getting called out a 3am when the link drops.
Hi Richard (and everyone),
Please help us solve problems by collecting the logs before rebooting. Go to Diagnostics > Logs > Support Info > click the blue Support Files button to download a .tar file from each radio to your local computer, and then email the files to email@example.com. There is useful information within them that we can use to understand and solve the problem that is otherwise lost upon reboot.
Just blocked now. downloaded files and sent.
Was there any outcome from your drop outs Francesco? id be interested to see what the issue is/was. i had the same occur again yesterday but someone rebooted the antennas before i could grab the logs
Traffic stalls/dropouts have many causes (e.g. interference, DFS hits, disassociation, channel changes, power changes, power outages, antennas blowing in the wind, rain fade, etc.), so it is important to differentiate the root causes. Please send your logs to firstname.lastname@example.org anyway and we will check it for you.
We did discover an edge case where Dual-link and rate adaptation interact and result in incorrect modulation rates. This has affected only a few users with certain configurations and link distances. We are testing a fix for this now.
The same symptom can occur when coaxial cables are reversed on one side of the link with a B5c. TPC attempts to correct for differences between Rx chains and bring the signal strengths closer to the average, but if the cables are reversed, TPC pulls them apart instead leading to modulation changes. That is one of the common causes for the issues reported above.
Firmware 1.3.1 allows additional TPC power adjustment than previous versions, so existing cabling problems have a more pronounced effect. Reversing cables on one side of the link fixes the problem. Please contact support if you suspect this may be the case, and we can help review cloud data to verify it.
Chris, I looked through the support site and don’t see any mention of having the cables hooked up any specific way. Most of our dish antennas are just labeled Chain 0 or 1, not necessarily vertical/horizontal. Can Mimosa create a FAQ or setup page talking about the correct way to connect the cables to the antenna so we don’t see these power issues you mention?
It would help our techs if we could give them information on the correct installation method so we don’t need to climb later to fix things. Thanks
Excellent suggestion. We’ll work on that.
The B5c’s antenna outputs are very clearly marked H and V, but we realize that 3rd party antennas may not be, and that datasheets for them may not be handy.
Many antennas have the V polarization pointing down, and the H polarization pointing to the side, but as long as you install both sides of the link in the same way, it doesn’t matter.
After learning how many links are wired differently on each side, we are going to address this in firmware such that the radio learns how it is connected and adapts TPC to compensate.
The links continue to be really instable.
to go deep:
interference: as in every tower no more no less
DFS hits: from log exported you can see if this is the case but the channel used it’s not always DFS channel
disassociation: the radio says “connected” but the traffic doesn’t pass
channel changes: this would be correctly handled by mimosa gear, right?
power changes; no power change
power outages: no power outages (the link remain powered but the traffic not pass
antennas blowing in the wind: not in my case (the signal remain stable)
rain fade: also in sunny days
I can see that the drop happen when used in 2x20 channel setup and seems to no happen when 1x40.
Also when traffic pass we see more often several second of burst ping timeout (more than 10).
I’m available for any further test.
We responded to you by email about this last Saturday, and asked several questions.
We see heavy interference on one of your links. Noise is -52 dBm and your signal is at -58 dBm. It looks like coax cables are reversed on one link, and you may have a bad coax cable on another link since the Rx signal is intermittent.
One channel has higher gain and higher spectral density than two channels, so you are better off with one channel when spectrum is crowded.
It is probably best if we discuss the specific details privately in email.
Sorry, we doesn’t read your emails for a antispam problem.
Now your domain it’s whitelisted!
I am sorry to say, that we too had to downgrade our B5c link back to firmware 1.2.3 from 1.3.1 !
The 1.3.1 looked real good, but then we had problems getting traffic through it. Seems https would go through, but regular http would not, although we could ping all our devices at the other end.
As soon as we put the 1.2.3 back in, everything went back to normal and working again like it should.
Was really hoping the 1.3.1 was good, as it really improved the signals, and connection rates!
Hopefully, you can figure out what is wrong with it ?
I’m not confident upgrade to firmware 1.3.1 now. The latency is 1ms is great but with some issues in this discuss I can not do upgrade.