Yesterday a group of us went out to our dorm repeater sites and upgraded a Bullet from v1 to v2. We had some issues with stability but a power reset fixed the issue. We also installed a second Bullet with v2 on a nearby dorm that sits a few feet higher. The taller dorm called Guinn has a better line of sight, but the shorter dorm was used for testing it is called Stark. 

We maintained both for testing purposes to see the range differences between the dorms. You see we have free roam of the shorter dorm but have limited use on Guinn.

Now for the issue we are experiencing. Using a Rocket M2 on version 1 firmware I had a beautiful signal strength using dual 6dBi Cradlepoint antennas. This is from a hill top, radio sitting in the dash of the windshield facing the Stark dorm. My connection was showing a strong 83% and the air mile distance was 6.5. 

After upgrading all devices to v2, I can no longer see a connection at that distance with the same setup, I've experimented with different antennas to no avail. We did bring a Nano Beam out and managed to get a connection but we could only see one local neighbor and the other devices as remote neighbors. I tested the Rocket much closer in fact on the roof tops of the two dorms and had connections but no where else. 

I am completely baffled, any thoughts that might help explain my issue? 

Thanks!

I've seen multiple combinations, all involve the RSSI led's (the network activitiy and power are not relevent)

It involves some form of the link led lights comming on in one configuration as you hold the reset button THEN plug in the power some of the LINK led's will be on and then they will change to different set of LED's in a repeating pattern

You can find several samples on YouTube for TFTP Ubiquiti Recovery that will show various diffrent LED.

The most common I have seen is  2 LINK LEDs are on as you power on holding reset, than it changes to a diffrent set of 2 LED's at which time you can release and it will become alternating 1+3 followed by 2+4 and repeat.

Andre, on your benchmark test exactly what was the chain to grid configuration on the M2s on both ends of the path? Single chain 0 with a single 24dBi grid for TX & RX, not using chain1? Or, dual 24dBi grids using diveristy, or what? We seem to be getting unrepeatable results with different configs. Can't tell yet what's best so curious about you exact chain to antenna configs.

Bob AF5RS

Thanks for the reply. I've got to bring it down from the tower to the bench to attempt this is a more "controlled" environment ;-). I been attempting this with me on the tower and another on the ground cycling the POE supply. I thought I could pull it off, but obviously not. Exactly how do the LEDs change? I see power and network activity under normal conditions on power up boot now.

Thanks again.

Bob AF5RS

The TFTP method works, I've done it 50+ times personally to restore to factory image.

You have to hold the button until the indicator lights change to indicate it's in TFTP mode.

The BBHN firmware takes no action to enable or disable the TFTP recovery mode. This is handeled before we boot our software.

No luck here using the latest 1.2.1 firmware on a Rocket M2 using the OEM "Recovery" method of depressing the reset switch during power up for 8 to 15 seconds. Unit still boots up normally to normal BBHN operation. Using the firmware upload method aborts with "firmware not recognized". I can feel the tactile depression on the reset button, but no luck after several attempts. Does anyone know if this method really works? It appears the BBHN firmware has disabled this recovery method. It normally should revert back to the factory IP (192.168.1.20) to allow TFTP upload of the OEM image, however, it appears this is only true if you have factory OEM firmware in the M2 already. So, how do we get back to OEM firmware?

Thanks in advance for an experienced answer,

73 Bob AF5RS

The downtilt and the beamwidth are indepednet of each other.

If it ships with 2 degree of down tilt and the antenna is vertically plumb than the center of the beam is at -2 degrees. With a 4 degree beamwidth this means it covers between 0 to -4 degrees with center again at -2.

So if you want to cover -2 to -6 you would need to shim it from the top to add an additional 2 degree of physical downtilt to give you a center at -4 ( -2 physical and + -2 electrical )

Note: Ubiquiti (like a lot of wifi antenna vendors) use -6dbm figures for beamwidth as compared to normal HAM antennas which use -3dbm. This data sheet calls out that it is -6dbm but some do not and it's easy to overlook as well. 

We have a solar powered linksys node on a hill. I am able to get in from 6 miles out with a Bullet M2 HP with 25 dbi grid and my friend is able to to get in from 9 miles out with M2 HP and 35 dbi grid. Hope that info helps.

Sounds like this is the same as BBHN->ticket:53

I believe a node reboot after saving will cause it to advertise the service as a work around until the changset in that ticket gets incorporated into a full release. 

After upgrading my firmware and setting things back up a little differently, I am not able to get advertised services working again.

My setup consists of a WRT54GL running 1.1.2 firmware. It is set as 5 host direct. I have a laptop host setup with DHCP address reservation.

On this host I have a webserver listening on the standard port 80.

I also have another WRT54GL attached to the first as an access point.

I can connect to the host web server by typing the hostname into the browser HOSTNAME/

and the web server launches fine, however, if I try to set it as an advertised service:

Web Server: Link :http://hostname(selected from drop down) port: 80 

I get the Configuration saved, however:
problem with port setup and therefore doesn't end up showing as an advertised service on the mesh.

I also have ngircd package running on the node and it works fine, but i get the same error if trying to set it up as an advertised service, even if it is the sole advertised service.

Any help would be greatly appreciated.

The numbers are indeed important they have to match. 

The first major issue I see is you removed vlan1 from ports 7 and 8. This vlan needs to be there and it needs to be there in a tagged format so the node can read the traffic as being on it's "WAN" port.

DTDLINK sounds like it should be setup correct so that if you plug a Ubiquiti into 7 or 8 they would talk to each other on VLAN2. 

This post may help http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-18-how-we-used-hsmm-mesh/topic-1021-ubiquiti-radios-and-providing-internet.html#ccbp4595