The chipset detetmibe a what mode to operate under.  

It should I belive operate up to MCS7.  The chipset /driver makes the decision about what mode to go into.  In your case the noise floor is the limiting factor. the nodes have to push higher power (slower speed) to get over the noise. 

As speed picks up the tx power decreases (linearity of signal amplifier) so you can't expect full speed in your case because it would drop the signal into the noise floor.

for modeling levels:

personaly I model anywhere from -96 to -85 dbm  and extrapolate based on what I know. Modeling is a bit of an art as much as if is a science you have to know when to doubt the data and when to trust the data.

a -74 would be a generally safe number in many cases as that gives you plenty of room (~22db) for noise floor and for signal strength for a good strong signal but would likely be overkill for a true "I can connect and use it" model. 

Ive seen some nodes flirting in the -86dbm range (noise floors in the -92ish). Are they my best links? No , do they connect and get the job done, yes,  would I like better, of course.

Conversely I got another couple nodes in the -74dm range with a -82dbm noise floor (yes it hurts ) and they have some fair amount of drop (30-50%)   If I put some small dish antennas it will get better I just haven't done it yet. 

So the -70's won't hurt to model in but know it's possible to do in the weaker zones.

I tend to model using a low gain antenna (10dbi) due to my conservative nature and know I can make the link stronger if needed that is one reason I model closer to the -96 mark but I also know not to assume any link is guranteed to work..

Hi,

I'm VA3GMT, I'd like to connect to the mesh, I noticed that close by there are VA3DCY and VE3SHA. I'm at Hwy48 and 16th ave.

 Could you please tell me if I could connect to any of those (still operational ? )

What settings do I need ? IP address ?

I have a WRT54GS ver3, I already upgraded the soft.

Thanks a lot,

VA3GMT - Felix

The switch port needs to be configured as a dot1q TRUNK port on Cisco.

Vlan 2 is a trunked vlan.

You could use vlan 10 and 20 for each node  so you don't have to disable dhcp/etc if you want as well as the native vlan but that's optional.

See: http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-910/topic-910-managed-switch-configuration.html as an example.

Webmaster: please recategorize to one of the other forums (problems and answers perhaps) for tracking as this is not firmware development related.

Good afternoon to all.

I have a mock up using a Nano Bridge M2 , Nano Bridge M5 and a Cisco 2950 switch.

The switch port in use are configured for vlan 2. The M5 DHCP has been disabled . This will allow the M2 to serve all DHCP addresses.

Problem :: Neither radio can see the other. no traffic is flowing between the radios

with a static address on the laptop I can connect to the M5 I don't see the M2 when I look at OLSR

dhcp on the M2 I connect and I don't see M5 in OLSR

Wireshark only shows the individual M2 & M5 . No coms between the two units . This is odd, what I have seen on previous captures of neighbor relations between nodes. 

There are some old topics on link modeling, but I thought I'd start a new one rather than pull up the old ones. I'm attempting to model a PtMP infrastructure using RadioMobile Online and I'm having some problems wrapping my head around some basic pricipals. Help a newbie out, woudja?

The Nanostation M2 has specs for MCS index data rates as well as 11b/g data rates. I've read up on what the acronyms mean, and I'm just starting to get a grip on the subject.

I get the impression that in a MIMO radio, the radio (and it's driver) make some decisions on what modulation scheme and other parameters to set, and that's reflected in the MCS index.

So here's the basic question... Does BBHN preserve the radio's MIMO operation, making the MCS specs relevant, or does BBHN lock the NSM2 into a 802.11b/g mode which locks the radio out of using MIMO parameters?

I've empirically measured a link of 13 km (9 miles, more or less) using a pair of NSM2's with clear line of sight over an urban environment. BBHN V1.0 s/w.  Data rate was not great, but adequate; around 3-5 Mb/s. Some drop-outs no doubt caused by noise; the GUI reported a S/N ratio of 0-5 db, which I thought showed great performance in a harsh environment. Rx level indicated by the GUI was bouncing around -80 to about -85.

I've found a post that says to use a rx threshold of 4.74 uV in radiomobile. I believe the post was in reference to Linksys radios. Is this a valid value for the NSM2? That's about -75dbm according to my calculator.

Thanks for any edification offered.

This forum and the Yahoo group have been silent for some time.  Is anyone still trying to work on this?  

I have VoIP phones to use/trade for other gear  They only use 5vdc at 1.5 amp +-  New/Old Stock.  Thought I might see someone at TOTR hamfest doing a demo.  Did meet up with KG4VUB but he said he had not worked on it in some time.

I have access to a high spot in the Vinings area looking north and maybe a spot on the same building looking towards Stone Mtn.  Who wants to do some testing at placing a backbone link or two up?

CQ CQ de K4RJJ Calling and standing by....

Hi,

Thank you very much. I am asking because I have see attached on Nanostation 2 possibility select frequency inside hamradio bandplan

Attachments
 NS2-4.jpg [293 KB] :: Nanostation2 with hamnet bandplan

For those interested I did some throughput tests. I appended them to this blog entry. Ubiquiti gear does about 10% percent better.

http://kb9mwr.blogspot.com/2013/04/hsmm-mesh-to-become-broadband-hamnet.html

A bit of both actually.

We have the Regulatory Domain controls and we have the offset that is not known to the operating system.

These are the items we are putting into the BBHN system to make it more user friendly for HAM's.

I don't think it's a Ubiquti only item as the items I've seen apply to ALL Atheros radios.

Each Atheros device registers a channel list (in kernel dricers for ath9k. The ath9k module  looks up calibration data (as noted above) that is programmed at the FACTORY only to make sure it stays linear and doesn't fry and components. In addition a calibration routine based on temapture runs periodically (a relative term meaning in the sense of data it's infrequent but from a human time it's very frequent) 

Here is the article I read that got me started on knowing these issues.

https://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg06790.html

ath9k/init.c among other various kernel field are relevant as well as changes to the iw program.

We also know the 3.6ghz devices use very heavy frontend filtering(we tried to bring it to 3.4 ham, it failed), the same could be true of the 2.4 and 5gh devices (we don't know for sure on that) as yet another limitation.

Any information you find would always be appreciated as it can only helps us to better understand the situation and the chances of success.  

We know dd-wrt claims to do it (using a closed source driver) but we don't know if they are paying attention to this data or caring about any filtering, etc.

Standard GUI.

You are correct, I did some further tests and it doesn't appear to be actually on the negative channel.

That or there is some sort of incompatibility in the AirOS / Open WRT channels.

What a pain. I just found out the hard way after specifically ordering the world wide Ubiquiti hardware that if you upgrade the AirOS firmware past 5.5.6 you lose the compliance test mode. I'll keep messing around with OpenWRT and let you know if I stumble into anything.

True there isn't a whole lot to gain with 2.4 GHz, but if it can be figured out there are 10 non overlapping channels on 5.5 Ghz that could be used exclusive to hams, not mention whatever applies with 3 GHz devices.

I don't have one as I've been doing mostly openwrt but they are very likely wells documented in the dd-wrt manual.

Look for how to flash than onboard switch configuration (in OpenWRT this is done by ending th switch switching of the network config file ) (be careful of the hardware flaw we found where a port is tagged and untagged at same time)

At that point it's operating as a switch and your set for that and you can extend the operating system to handle routing if needed as well.

Here is a guide I've given out as a starter before:

http://www.dd-wrt.com/wiki/index.php/Switched_Ports

Iv been playing with my Node, RasPi, and installed OpenFire.

OpenFire is up and running on my node. Its also visable, reachable, and useable across my mesh. Im hoping to get some more testing done tomorrow, maybe even from work tomorrow. :)

What I would like is to get connected to one of the tunnels, and see if I am accessable from that tunnel. 

Is that the standard Luci GUI ?

I've tried setting negative channels in 12.09 in core openwrt (but not Luci) are you sure it's actually operating on a negative channel?  Everything I've seen so far says kernel won't permit it, regulatory domain control wouldn't permit it etc.

If so, I'll fire up a stock OpenWRT and investigate to see what I have been missing.

You can always roll your own firmware by starting with OpenWRT and adding in olsrd. Selecting channel 0 appears pretty simple in OpenWRT:

http://kb9mwr.blogspot.com/2012/10/nw-mesh.html