3.30 to 4.17 to 5.1, 23 miles, odd problems

I have an RB600, 3.30, R52H x2, one 5.8GHz 29dBi, one 2.4GHz, 5MHz channel, 24dBi at remote tower site.

RB433 with XR5 and 26dBi, R52 and 24dBi for 2.4GHz on my tower.

I was running 3.30, everything works fairly well. 5Mb, bandwidth increases 2x if I enable Nstreme, but that causes some issues with other links on my tower. Still tinkering with that one.

This is a production link, but I have a backup built into my network, so I tried 5.1 on my RB433 locally. The remote tower refused to associate with the updated AP. It would hit for just a second, this disconnect. I manually changed the ACK to 37km, 5GHz would work fairly well. The 2.4GHz link is 5MHz wide, just for backup and administrative purposes, maybe Nstreme dual at a later date. After the 5.1 update this link would not associate at all on 5MHz channel. I changed to B or B/G and it would link up. I downgraded to 4.17, same config, fires right up and works almost identical to 3.30.

Tried NV2 package on 4.17 and the same problem. The remote tower (3.30) will not associate with 2.4GHz on a 5MHz channel.

It appears there is an incompatibility of 5MHz wide channels on 2.4GHz between 5.1 and the older versions.

I am very interested in upgrading to the newer versions, at least a few test shots. I am very hesitant to update the remote tower without being on site. Any info is appreciated.

Some things to be aware of with the new wireless package that will cause problems you mentioned.

  1. I have found that you need to set data rates to default if the other end is running the older wireless package.
  2. Make sure you disable noise floor threshold as it does some really odd stuff with the new wireless package.

Chadd

Data rates are default.

Where is the noise floor threshold setting?

You have to be in advanced mode then click on the advanced tab.

Chadd

Don’t know if this could have anything to do with it, but;

I noticed that in v5.x the 5gHz band, you can pick every 5Ghz channel you’d like. In the ´before nv2 package´ era ros versions you could only pick the rounded off frequencies. So 5620, 5640, 5660 in 20Mhz wide band or 5610, 5620 etc. in 10Mhz wide band
In the ros5.x I can pick 5620, 5625, 5630, 5635 etc. in any set bandwidth! It doesn’t matter if default 20 or the 10 or 5Mhz bandwidth is chosen!
[This might have been done to accommodate third party devices (ubnt) that have the option to shift the working channel 5Ghz up or down?]

Maybe in the wireless packages something has changed between 4.16 and 5.0 so any lower versions of ros (<4.16 or v3.x) cannot communicate well with the latest versions when a 10 (or even 5) Mhz channel bandwidth is chosen?

You might be on to something, but I was using 2462MHz. It would not associate if 5.1 was the AP, it did work as the station while 3.30 was the AP. Forgot to mention that.

Well, the bottom line is that I always try to update both ends of the link to the same ros versions.
Over the years there have been several occasions where newer versions of ros did not completely were backwards compatible with older ones.
You say you have a backup build in to reach that remote tower? If that means the remote unit is wired to another unit you have access to via another route, why then not update that remote unit as well to 5.1? Or go over there and update it while you then instructed someone back home to do the update on your home end at the same time.
If things go wrong both could than downgrade to bring status back. Make sure both made a backup and saved it outside the router.

I am confident that after the update to 5.1 on both end you’ll end up with a big smile on your face! :smiley:

I have a backup link on this side, the other side is an all in one unit.

Definitely moving away from all in ones…

X2 on upgrading both ends to the same version for testing. Though on a production link this may be difficult.

if you have the hardware laying around, i would recommend you recreate your link in a lab environment first, and test using 5mhz channels in the frequencies you will be using on your production link. this will increase your safety factor by a large margin :slight_smile:

The reason for this test was I had a backup on my side of the link. If I screwed up the primary it would change over. New link, only a couple of customers.

A lot of stuff works great in testing, not quite as well 150ft up and a few miles out.

Next time I go that way I’ll probably try to upgrade both sides. Just a little leery of upgrading it from 23 miles away.