Re: [WISPA] Maximum sector power?

[Justin Wilson]

Yeah no way to tell unless you hook it up.  I just go by if the radio is
rated at 27dbm and the software is set to 27dbm then I am assuming it is
100%.  Assuming is the key word.
-- 
Justin Wilson 
http://www.mtin.net/blog
Wisp Consulting ­ Tower Climbing ­ Network Support



From: RickG 
Reply-To: WISPA General List 
Date: Thu, 24 Jun 2010 19:53:34 -0400
To: WISPA General List 
Subject: Re: [WISPA] Maximum sector power?

Not to argue your point as I agree with you but how do you know your
running it at 100%? Just cause it says so doesnt mean it is. ("It"
being the radio).
-RickG

On Thu, Jun 24, 2010 at 10:43 AM, Justin Wilson  wrote:
>    I look at power compared to a car.  You get better performance at a
> certain RPM on a car.  This is almost never near the redline.  Once you
> reach the limit you are wasting power.  Radio cards are the same way.  If
> you drive them at 100% they can not be as efficient as on a lower power
> setting.
>
>    Justin
> --
> Justin Wilson 
> http://www.mtin.net/blog
> Wisp Consulting ­ Tower Climbing ­ Network Support
>
>
>
> From: Ryan Ghering 
> Reply-To: WISPA General List 
> Date: Wed, 23 Jun 2010 22:53:23 -0600
> To: WISPA General List 
> Subject: Re: [WISPA] Maximum sector power?
>
> We are running RocketM2's and RocketM5's and we have set policy's on the 120
> sectors
> to limit the power on the radios to 17db they seem to act better then
> setting them to 20.
> Oddly enough much stronger signal's at 17 than at 20..
>
> We have one site where we have the radios set to 13 and they work
> beautifully.
>
> Ryan
>
> On Wed, Jun 23, 2010 at 10:43 PM, Rubens Kuhl  wrote:
>
>> >
>> > The PtP/PtMP distinction does create interesting ambiguity.  But then
>>
>> My favorite ambiguity is whether the PtP/PtMP distinction applies to
>> the full-duplex system or per traffic direction... one reading would
>> say that an uplink(Customer - > WISP) that is made using directive
>> antennas can follow PtP instead of PtMP rules, which would apply only
>> to the downlink (WISP -> Customer) .
>>
>>
>>
>> Rubens
>>
>>
>>
>>
> 

>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>>
>>
> 

>>
>> WISPA Wireless List: wireless@wispa.org
>>
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>> Archives: http://lists.wispa.org/pipermail/wireless/
>>
>
>
>
> --
> Ryan Ghering
> Network Operations - Plains.Net
> Office: 970-848-0475 - Cell: 970-630-1879
>
>
> 
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
> 
>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>
> 

> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 

>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>




WISPA Wants You! Join today!
http://signup.wispa.org/


 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue

[Michael Baird]

Turn off extra reporting on the Ubiquities.

Regards
Michael Baird
> Sounds like Cisco / Vlan is giving you trouble...
> Two suggestions... check if there is a loop getting created somewhere..
> and 2nd suggestions... turn CDP off on the Cisco ...
>
>
> Faisal Imtiaz
> Snappy Internet&   Telecom
> 7266 SW 48 Street
> Miami, Fl 33155
> Tel: 305 663 5518 x 232
> Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net
>
>
> On 6/24/2010 8:08 PM, Scott Lambert wrote:
>
>> On Thu, Jun 24, 2010 at 07:20:23AM -0600, Jayson Baker wrote:
>>
>>  
>>> On Thu, Jun 24, 2010 at 7:20 AM, Faisal Imtiaz wrote:
>>>
>>>
 On Jun 24, 2010, at 9:08 AM, Jayson Baker wrote:

  
> On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert wrote:
>
>
>
>> We have been putting up some Ubiquity RocketM5 point-to-point
>> bridge links, running airos 5.2, lately to replace some
>> overloaded StarOS backhauls.  Where these links have gone in, we
>> static route the traffic across them.
>>
>> These are our first experience with Ubiquity.  The first two
>> were no muss, no fuss.  The third link went up nicely.  It's
>> configured the same as the other two links.  About an hour after
>> we plugged the local end at our office into the main switch,
>> rather than a laptop, we started loosing routes to sites which
>> pass through the tower at the far end of the link.
>>
>> All hosts on the tower LAN can see each other.  We can reach all
>> of them from anywhere else on our network.  It is just routes
>> for hosts connected wirelessly to that tower which are no longer
>> known to the staros box which has the existing backhaul to our
>> office.
>>
>>**   SNIPPED **
>>** OLSR between StarOS boxes at the remote tower **
>>** dropping routes, but not OLSR adjacencies **
>>
>> Administratively shutting down interface gig0/3.13 at the office
>> seems to be enough to heal OLSR at the tower.  If the tower LAN
>> can see the cisco, we drop routes.  But the other ubiquity links
>> connect back to the same cisco at the office.
>>
>> I think we will probably replace the switch at the tower tomorrow
>> to see if it has problems we haven't tickled before.  I'm
>> stumped.  Does anyone else have any ideas?
>>
>>  
> I didn't quite follow all of that, it must be too early. But I can
> tell you we have 4 of the PtP UBNT links using their M-series. 3
> of those OSPF fine. The other won't OSPF for the life of me. All
> same config and firmware on all units.
>
>
 Make sure you are running the most recent version of 5.2
 firmware.also you need to be running then in AP-WDS and CPE-WDS
 mode.

  
>>> I can't comment on the OP, but I can tell you that we are. OSPF talks,
>>> but never goes Full and exchanges routes.
>>>
>>> Latest FW on both ends. Like I said, same exact config as the other
>>> links which work perfect.
>>>
>>>
>> I'm still waiting for a chance to test again during off-peak hours.
>>
>> I may have included too much information, and too little information,
>> and created confusion.  The e-mail was helping me document and track
>> my trouble shooting process.  I often solve my own problem while
>> writing up e-mail to mailing lists.  Usually, because I've skipped
>> some simple trouble shooting step without realizing it until I proof
>> read the message before sending it.
>>
>> The summary is :
>>
>> When the Ubiquity bridge is up, passing traffic or not, the OLSR
>> at the tower site begins having issues between StarOS routers
>> directly connected to the tower switch.  The OLSR which is falling
>> apart, does not need to cross the Ubiquity link in order to function.
>> In fact, there is nothing at the near end of the link which could
>> do anything with the OLSR packets.
>>
>> OLSR falls apart BEFORE I get to the point at which I would attempt
>> to actually utilize the Ubiquity link.  The only traffic I am
>> attempting to pass at the point of failure is from the office to
>> the RocketM5 at the tower.
>>
>> Here are the series of changes to the network which lead to issues:
>>
>> Connect RocketM5 to tower switch:  OLSR at tower OK
>>
>> Create association AP-WDS at office to STA-WDS at the tower: OLSR
>> at tower OK
>>
>> Connect RocketM5 AP at office to office switch in it's own VLAN:
>> OLSR at tower OK
>>
>> Configure Cisco at office to join VLAN:  OLSR at tower falls apart
>>
>> Configure Cisco at office to exit VLAN:  OLSR at tower OK
>>
>> Cisco join VLAN to OLSR time to failure approximately 90 - 105
>> seconds.
>>
>> Cisco exit VLAN to OLSR time to heal approximately 10 seconds.
>>
>> The Cisco is not configured to run any routing protocols over this
>> VLAN.
>>
>> If anyone thinks it would help, I could draw up an ascii 

Re: [WISPA] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue

[Faisal Imtiaz]

Sounds like Cisco / Vlan is giving you trouble...
Two suggestions... check if there is a loop getting created somewhere..
and 2nd suggestions... turn CDP off on the Cisco ...


Faisal Imtiaz
Snappy Internet&  Telecom
7266 SW 48 Street
Miami, Fl 33155
Tel: 305 663 5518 x 232
Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net


On 6/24/2010 8:08 PM, Scott Lambert wrote:
> On Thu, Jun 24, 2010 at 07:20:23AM -0600, Jayson Baker wrote:
>
>> On Thu, Jun 24, 2010 at 7:20 AM, Faisal Imtiaz wrote:
>>  
>>> On Jun 24, 2010, at 9:08 AM, Jayson Baker wrote:
>>>
 On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert wrote:

  
> We have been putting up some Ubiquity RocketM5 point-to-point
> bridge links, running airos 5.2, lately to replace some
> overloaded StarOS backhauls.  Where these links have gone in, we
> static route the traffic across them.
>
> These are our first experience with Ubiquity.  The first two
> were no muss, no fuss.  The third link went up nicely.  It's
> configured the same as the other two links.  About an hour after
> we plugged the local end at our office into the main switch,
> rather than a laptop, we started loosing routes to sites which
> pass through the tower at the far end of the link.
>
> All hosts on the tower LAN can see each other.  We can reach all
> of them from anywhere else on our network.  It is just routes
> for hosts connected wirelessly to that tower which are no longer
> known to the staros box which has the existing backhaul to our
> office.
>
>   **   SNIPPED **
>   ** OLSR between StarOS boxes at the remote tower **
>   ** dropping routes, but not OLSR adjacencies **
>
> Administratively shutting down interface gig0/3.13 at the office
> seems to be enough to heal OLSR at the tower.  If the tower LAN
> can see the cisco, we drop routes.  But the other ubiquity links
> connect back to the same cisco at the office.
>
> I think we will probably replace the switch at the tower tomorrow
> to see if it has problems we haven't tickled before.  I'm
> stumped.  Does anyone else have any ideas?
>

 I didn't quite follow all of that, it must be too early. But I can
 tell you we have 4 of the PtP UBNT links using their M-series. 3
 of those OSPF fine. The other won't OSPF for the life of me. All
 same config and firmware on all units.
  
>>>
>>> Make sure you are running the most recent version of 5.2
>>> firmware.also you need to be running then in AP-WDS and CPE-WDS
>>> mode.
>>>
>>
>> I can't comment on the OP, but I can tell you that we are. OSPF talks,
>> but never goes Full and exchanges routes.
>>
>> Latest FW on both ends. Like I said, same exact config as the other
>> links which work perfect.
>>  
> I'm still waiting for a chance to test again during off-peak hours.
>
> I may have included too much information, and too little information,
> and created confusion.  The e-mail was helping me document and track
> my trouble shooting process.  I often solve my own problem while
> writing up e-mail to mailing lists.  Usually, because I've skipped
> some simple trouble shooting step without realizing it until I proof
> read the message before sending it.
>
> The summary is :
>
> When the Ubiquity bridge is up, passing traffic or not, the OLSR
> at the tower site begins having issues between StarOS routers
> directly connected to the tower switch.  The OLSR which is falling
> apart, does not need to cross the Ubiquity link in order to function.
> In fact, there is nothing at the near end of the link which could
> do anything with the OLSR packets.
>
> OLSR falls apart BEFORE I get to the point at which I would attempt
> to actually utilize the Ubiquity link.  The only traffic I am
> attempting to pass at the point of failure is from the office to
> the RocketM5 at the tower.
>
> Here are the series of changes to the network which lead to issues:
>
> Connect RocketM5 to tower switch:  OLSR at tower OK
>
> Create association AP-WDS at office to STA-WDS at the tower: OLSR
> at tower OK
>
> Connect RocketM5 AP at office to office switch in it's own VLAN:
> OLSR at tower OK
>
> Configure Cisco at office to join VLAN:  OLSR at tower falls apart
>
> Configure Cisco at office to exit VLAN:  OLSR at tower OK
>
> Cisco join VLAN to OLSR time to failure approximately 90 - 105
> seconds.
>
> Cisco exit VLAN to OLSR time to heal approximately 10 seconds.
>
> The Cisco is not configured to run any routing protocols over this
> VLAN.
>
> If anyone thinks it would help, I could draw up an ascii diagram.
>
>



WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wir

Re: [WISPA] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue

[Scott Lambert]

On Thu, Jun 24, 2010 at 07:20:23AM -0600, Jayson Baker wrote:
> On Thu, Jun 24, 2010 at 7:20 AM, Faisal Imtiaz wrote:
> > On Jun 24, 2010, at 9:08 AM, Jayson Baker wrote:
> > > On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert wrote:
> > >
> > >> We have been putting up some Ubiquity RocketM5 point-to-point
> > >> bridge links, running airos 5.2, lately to replace some
> > >> overloaded StarOS backhauls.  Where these links have gone in, we
> > >> static route the traffic across them.
> > >>
> > >> These are our first experience with Ubiquity.  The first two
> > >> were no muss, no fuss.  The third link went up nicely.  It's
> > >> configured the same as the other two links.  About an hour after
> > >> we plugged the local end at our office into the main switch,
> > >> rather than a laptop, we started loosing routes to sites which
> > >> pass through the tower at the far end of the link.
> > >>
> > >> All hosts on the tower LAN can see each other.  We can reach all
> > >> of them from anywhere else on our network.  It is just routes
> > >> for hosts connected wirelessly to that tower which are no longer
> > >> known to the staros box which has the existing backhaul to our
> > >> office.
> > >> 
> > >>  **   SNIPPED ** 
> > >>  ** OLSR between StarOS boxes at the remote tower **
> > >>  ** dropping routes, but not OLSR adjacencies **
> > >>
> > >> Administratively shutting down interface gig0/3.13 at the office
> > >> seems to be enough to heal OLSR at the tower.  If the tower LAN
> > >> can see the cisco, we drop routes.  But the other ubiquity links
> > >> connect back to the same cisco at the office.
> > >>
> > >> I think we will probably replace the switch at the tower tomorrow
> > >> to see if it has problems we haven't tickled before.  I'm
> > >> stumped.  Does anyone else have any ideas?
> > >
> > >
> > > I didn't quite follow all of that, it must be too early. But I can
> > > tell you we have 4 of the PtP UBNT links using their M-series. 3
> > > of those OSPF fine. The other won't OSPF for the life of me. All
> > > same config and firmware on all units.
> > 
> >
> > Make sure you are running the most recent version of 5.2
> > firmware.also you need to be running then in AP-WDS and CPE-WDS
> > mode.
> 
> 
> I can't comment on the OP, but I can tell you that we are. OSPF talks,
> but never goes Full and exchanges routes.
>
> Latest FW on both ends. Like I said, same exact config as the other
> links which work perfect.

I'm still waiting for a chance to test again during off-peak hours.

I may have included too much information, and too little information,
and created confusion.  The e-mail was helping me document and track
my trouble shooting process.  I often solve my own problem while
writing up e-mail to mailing lists.  Usually, because I've skipped
some simple trouble shooting step without realizing it until I proof
read the message before sending it.

The summary is :

When the Ubiquity bridge is up, passing traffic or not, the OLSR
at the tower site begins having issues between StarOS routers
directly connected to the tower switch.  The OLSR which is falling
apart, does not need to cross the Ubiquity link in order to function.
In fact, there is nothing at the near end of the link which could
do anything with the OLSR packets.

OLSR falls apart BEFORE I get to the point at which I would attempt
to actually utilize the Ubiquity link.  The only traffic I am
attempting to pass at the point of failure is from the office to
the RocketM5 at the tower.

Here are the series of changes to the network which lead to issues:

Connect RocketM5 to tower switch:  OLSR at tower OK

Create association AP-WDS at office to STA-WDS at the tower: OLSR
at tower OK

Connect RocketM5 AP at office to office switch in it's own VLAN:
OLSR at tower OK

Configure Cisco at office to join VLAN:  OLSR at tower falls apart

Configure Cisco at office to exit VLAN:  OLSR at tower OK

Cisco join VLAN to OLSR time to failure approximately 90 - 105
seconds.

Cisco exit VLAN to OLSR time to heal approximately 10 seconds.

The Cisco is not configured to run any routing protocols over this
VLAN.

If anyone thinks it would help, I could draw up an ascii diagram.

-- 
Scott LambertKC5MLE   Unix SysAdmin
lamb...@lambertfam.org




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[RickG]

Not to argue your point as I agree with you but how do you know your
running it at 100%? Just cause it says so doesnt mean it is. ("It"
being the radio).
-RickG

On Thu, Jun 24, 2010 at 10:43 AM, Justin Wilson  wrote:
>    I look at power compared to a car.  You get better performance at a
> certain RPM on a car.  This is almost never near the redline.  Once you
> reach the limit you are wasting power.  Radio cards are the same way.  If
> you drive them at 100% they can not be as efficient as on a lower power
> setting.
>
>    Justin
> --
> Justin Wilson 
> http://www.mtin.net/blog
> Wisp Consulting ­ Tower Climbing ­ Network Support
>
>
>
> From: Ryan Ghering 
> Reply-To: WISPA General List 
> Date: Wed, 23 Jun 2010 22:53:23 -0600
> To: WISPA General List 
> Subject: Re: [WISPA] Maximum sector power?
>
> We are running RocketM2's and RocketM5's and we have set policy's on the 120
> sectors
> to limit the power on the radios to 17db they seem to act better then
> setting them to 20.
> Oddly enough much stronger signal's at 17 than at 20..
>
> We have one site where we have the radios set to 13 and they work
> beautifully.
>
> Ryan
>
> On Wed, Jun 23, 2010 at 10:43 PM, Rubens Kuhl  wrote:
>
>> >
>> > The PtP/PtMP distinction does create interesting ambiguity.  But then
>>
>> My favorite ambiguity is whether the PtP/PtMP distinction applies to
>> the full-duplex system or per traffic direction... one reading would
>> say that an uplink(Customer - > WISP) that is made using directive
>> antennas can follow PtP instead of PtMP rules, which would apply only
>> to the downlink (WISP -> Customer) .
>>
>>
>>
>> Rubens
>>
>>
>>
>>
> 
>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>>
>>
> 
>>
>> WISPA Wireless List: wireless@wispa.org
>>
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>> Archives: http://lists.wispa.org/pipermail/wireless/
>>
>
>
>
> --
> Ryan Ghering
> Network Operations - Plains.Net
> Office: 970-848-0475 - Cell: 970-630-1879
>
>
> 
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
> 
>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>



WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[RickG]

Does the FCC take its cues from the IRS? :)

On Thu, Jun 24, 2010 at 12:43 AM, Rubens Kuhl  wrote:
>>
>> The PtP/PtMP distinction does create interesting ambiguity.  But then
>
> My favorite ambiguity is whether the PtP/PtMP distinction applies to
> the full-duplex system or per traffic direction... one reading would
> say that an uplink(Customer - > WISP) that is made using directive
> antennas can follow PtP instead of PtMP rules, which would apply only
> to the downlink (WISP -> Customer) .
>
>
>
> Rubens
>
>
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>



WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue

[RickG]

Just curious - what if you switch the radio roles around (make the AP,
the CPE and vice-versa)?
I've had that "fix" some strange issues like that.
-RickG

On Thu, Jun 24, 2010 at 9:20 AM, Jayson Baker  wrote:
> I can't comment on the OP, but I can tell you that we are.  OSPF talks, but
> never goes Full and exchanges routes.
> Latest FW on both ends.  Like I said, same exact config as the other links
> which work perfect.
>
> On Thu, Jun 24, 2010 at 7:20 AM, Faisal Imtiaz  wrote:
>
>> Make sure you are running the most recent version of 5.2 firmware.also
>> you need to be running then in AP-WDS and CPE-WDS mode.
>>
>> Faisal
>>
>> On Jun 24, 2010, at 9:08 AM, Jayson Baker  wrote:
>>
>> > I didn't quite follow all of that, it must be too early.
>> > But I can tell you we have 4 of the PtP UBNT links using their M-series.
>>  3
>> > of those OSPF fine.  The other won't OSPF for the life of me.  All same
>> > config and firmware on all units.
>> >
>> > On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert > >wrote:
>> >
>> >> We have been putting up some Ubiquity RocketM5 point-to-point bridge
>> >> links, running airos 5.2, lately to replace some overloaded StarOS
>> >> backhauls.  Where these links have gone in, we static route the traffic
>> >> across them.  They happen to be on the OSPF/OLSR divider boundry.  I
>> >> would like to find a good way to redistribute between the routing
>> >> protocols, but that's for another day.  When I get time, I'll probably
>> >> just convert the 20 odd OLSR towers to OSPF.
>> >>
>> >> These are our first experience with Ubiquity.  The first two were no
>> >> muss, no fuss.  The third link went up nicely.  It's configured the same
>> >> as the other two links.  About an hour after we plugged the local end
>> >> at our office into the main switch, rather than a laptop, we started
>> >> loosing routes to sites which pass through the tower at the far end of
>> >> the link.
>> >>
>> >> All hosts on the tower LAN can see each other.  We can reach all of
>> >> them from anywhere else on our network.  It is just routes for hosts
>> >> connected wirelessly to that tower which are no longer known to the
>> >> staros box which has the existing backhaul to our office.
>> >>
>> >> We rebooted everything at the remote tower.  The links came up.  The
>> >> routes were good.  Approximately an hour later, the same routes fell
>> >> out.  So, we decided it must be due to some sort of wierd multicast OLSR
>> >> issue when these towers were suddenly able to see each other across
>> >> the bridges.  I unplugged the ethernet at the office and waited until
>> >> tonight to try again.  The routes straightened themselves out as soon as
>> >> I unplugged the office end.  Wild.
>> >>
>> >> This afternoon, I setup a seperate VLAN on the switch for this link.
>> >> Before I left the office I plugged it in about, 8:00pm.  I didn't have
>> >> any other devices configured on that VLAN.
>> >>
>> >> There were no problems for several hours until I configured the new VLAN
>> >> on the Cisco that was sometime between 1:01 and 1:10am.  The RANCID
>> >> run at 1:01 didn't see any changes but the run at 2:01 found them.  At
>> >> 1:10am Nagios noticed that it couldn't reach the equipment through those
>> >> same routes.
>> >>
>> >> + interface GigabitEthernet0/3.13
>> >> +  description "Wireless VPN 3
>> >> +  encapsulation dot1Q 13
>> >> +  ip address 10.127.3.1 255.255.255.0
>> >> +  no cdp enable
>> >> + !
>> >>
>> >> That's the subnet for the RocketM5s.  The StarOS gear on the tower uses
>> >> a public /29 subnet.
>> >>
>> >> I tried various things with reboots and restarts of OLSR on the staros
>> >> gear at the tower.  The routes came back for four or five minutes then
>> >> went away again.  No good.
>> >>
>> >> So, at about 2:10am, I logged into the RocketM5 at the tower and
>> >> disabled it's ethernet interface.  Within a few seconds, my pings to
>> >> equipment through the lost routes began succeeding.
>> >>
>> >> It's now 3:25, and all's well.  I am puzzled.  We really need the
>> >> additional bandwidth the ubiquity link can give us on this link.
>> >>
>> >> At 3:26 I enabled the LAN at the tower just to make sure.  Within 2
>> >> minutes, splat.  This time I left the LAN enabled at the tower and
>> >> disabled the WLAN interface at the office.  All better in seconds.
>> >>
>> >> Administratively shutting down interface gig0/3.13 at the office seems
>> >> to be enough to heal OLSR at the tower.  If the tower LAN can see the
>> >> cisco, we drop routes.  But the other ubiquity links connect back to the
>> >> same cisco at the office.
>> >>
>> >> I think we will probably replace the switch at the tower tomorrow to see
>> >> if it has problems we haven't tickled before.  I'm stumped.  Does anyone
>> >> else have any ideas?
>> >>
>> >>
>> >> --
>> >> Scott Lambert                    KC5MLE                       Unix
>> SysAdmin
>> >> lamb...@lambertfam.org
>> >>
>> >>
>> >>
>> >>
>> >>
>> --

Re: [WISPA] Maximum sector power?

[Greg Ihnen]

Not as efficient or as clean

Greg

On Jun 24, 2010, at 10:13 AM, Justin Wilson wrote:

>I look at power compared to a car.  You get better performance at a
> certain RPM on a car.  This is almost never near the redline.  Once you
> reach the limit you are wasting power.  Radio cards are the same way.  If
> you drive them at 100% they can not be as efficient as on a lower power
> setting.
> 
>Justin
> -- 
> Justin Wilson 
> http://www.mtin.net/blog
> Wisp Consulting – Tower Climbing – Network Support
> 
> 
> 
> From: Ryan Ghering 
> Reply-To: WISPA General List 
> Date: Wed, 23 Jun 2010 22:53:23 -0600
> To: WISPA General List 
> Subject: Re: [WISPA] Maximum sector power?
> 
> We are running RocketM2's and RocketM5's and we have set policy's on the 120
> sectors
> to limit the power on the radios to 17db they seem to act better then
> setting them to 20.
> Oddly enough much stronger signal's at 17 than at 20..
> 
> We have one site where we have the radios set to 13 and they work
> beautifully.
> 
> Ryan
> 
> On Wed, Jun 23, 2010 at 10:43 PM, Rubens Kuhl  wrote:
> 
>>> 
>>> The PtP/PtMP distinction does create interesting ambiguity.  But then
>> 
>> My favorite ambiguity is whether the PtP/PtMP distinction applies to
>> the full-duplex system or per traffic direction... one reading would
>> say that an uplink(Customer - > WISP) that is made using directive
>> antennas can follow PtP instead of PtMP rules, which would apply only
>> to the downlink (WISP -> Customer) .
>> 
>> 
>> 
>> Rubens
>> 
>> 
>> 
>> 
> 
>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>> 
>> 
> 
>> 
>> WISPA Wireless List: wireless@wispa.org
>> 
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>> 
>> Archives: http://lists.wispa.org/pipermail/wireless/
>> 
> 
> 
> 
> -- 
> Ryan Ghering
> Network Operations - Plains.Net
> Office: 970-848-0475 - Cell: 970-630-1879
> 
> 
> 
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
> 
> 
> WISPA Wireless List: wireless@wispa.org
> 
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
> 
> Archives: http://lists.wispa.org/pipermail/wireless/
> 
> 
> 
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
> 
> WISPA Wireless List: wireless@wispa.org
> 
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
> 
> Archives: http://lists.wispa.org/pipermail/wireless/




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] St. Louis Regional Meeting Change of Venue

[Forbes Mercy]

Great job, Rick.

Forbes


On 6/24/2010 1:09 PM, Rick Harnish wrote:
> To everyone,
>
>
>
> I have successfully negotiated a lower rate of $79/room at the Renaissance
>  otel/>   Hotel near the St. Louis Airport.  This rate will include free
> parking (normally $10/night, free Internet in rooms (Ethernet Jacks) and
> free Airport Shuttle service.  The Exhibition Hall and Meeting Room space is
> tremendous and is approximately 6x the size we had at the Holiday Inn.  I am
> going back to the hotel tonight and will sign the contract in the morning.
> They will be giving us a registration page and discount code as their normal
> room rates are $149.  I will update everyone as soon as I have the discount
> code to register.
>
>
>
> I appreciate everyone's patience as this has taken almost 4 days to
> complete.
>
>
>
> The Holiday Inn would prefer that you call in to cancel your reservations
> ASAP, so they can release the rooms to their staff to fill with new
> reservations.  They promised to be very cooperative.  Please make sure you
> ask for a cancellation confirmation number just in case.  The
> reservation/cancellation number is 1.314.427.4700
>
>
>
> This meeting is going to be a great time, value and educational seminar that
> I wish all of our members could attend.   I look forward to seeing old
> friends and meeting new ones.  We are also able to open up the exhibition
> hall for new vendor booths and tabletop reservations.  Contact me if you are
> interested.
>
>
>
> My time to respond is difficult right now as I am in a non-verizon area.  I
> will be returning to St. Louis tonight and then leaving in the morning for
> my trip back to Indiana.  If you have questions, it is probably better to
> give me a call in the meantime.
>
>
>
> Thanks,
>
>
>
> Rick Harnish
>
> President
>
> WISPA
>
> 260-307-4000 cell
>
> 866-317-2851 WISPA Office
>
> Skype: rick.harnish.
>
> rharn...@wispa.org
>
>
>
>
>
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>
>




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] St. Louis Regional Meeting Change of Venue

[Jeff Broadwick]

Great work on that Rick!   


Regards,

Jeff


Jeff Broadwick
ImageStream
800-813-5123 x106 (US/Can)
+1 574-935-8484 x106  (Int'l)

-Original Message-
From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On
Behalf Of Rick Harnish
Sent: Thursday, June 24, 2010 4:10 PM
To: memb...@wispa.org; 'WISPA General List'
Subject: [WISPA] St. Louis Regional Meeting Change of Venue

To everyone, 

 

I have successfully negotiated a lower rate of $79/room at the Renaissance
  Hotel near the St. Louis Airport.  This rate will include free
parking (normally $10/night, free Internet in rooms (Ethernet Jacks) and
free Airport Shuttle service.  The Exhibition Hall and Meeting Room space is
tremendous and is approximately 6x the size we had at the Holiday Inn.  I am
going back to the hotel tonight and will sign the contract in the morning.
They will be giving us a registration page and discount code as their normal
room rates are $149.  I will update everyone as soon as I have the discount
code to register.

 

I appreciate everyone's patience as this has taken almost 4 days to
complete.  

 

The Holiday Inn would prefer that you call in to cancel your reservations
ASAP, so they can release the rooms to their staff to fill with new
reservations.  They promised to be very cooperative.  Please make sure you
ask for a cancellation confirmation number just in case.  The
reservation/cancellation number is 1.314.427.4700 

 

This meeting is going to be a great time, value and educational seminar that
I wish all of our members could attend.   I look forward to seeing old
friends and meeting new ones.  We are also able to open up the exhibition
hall for new vendor booths and tabletop reservations.  Contact me if you are
interested.

 

My time to respond is difficult right now as I am in a non-verizon area.  I
will be returning to St. Louis tonight and then leaving in the morning for
my trip back to Indiana.  If you have questions, it is probably better to
give me a call in the meantime.

 

Thanks,

 

Rick Harnish

President

WISPA

260-307-4000 cell

866-317-2851 WISPA Office

Skype: rick.harnish.

rharn...@wispa.org

 





WISPA Wants You! Join today!
http://signup.wispa.org/


 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

[WISPA] St. Louis Regional Meeting Change of Venue

[Rick Harnish]

To everyone, 

 

I have successfully negotiated a lower rate of $79/room at the Renaissance
  Hotel near the St. Louis Airport.  This rate will include free
parking (normally $10/night, free Internet in rooms (Ethernet Jacks) and
free Airport Shuttle service.  The Exhibition Hall and Meeting Room space is
tremendous and is approximately 6x the size we had at the Holiday Inn.  I am
going back to the hotel tonight and will sign the contract in the morning.
They will be giving us a registration page and discount code as their normal
room rates are $149.  I will update everyone as soon as I have the discount
code to register.

 

I appreciate everyone's patience as this has taken almost 4 days to
complete.  

 

The Holiday Inn would prefer that you call in to cancel your reservations
ASAP, so they can release the rooms to their staff to fill with new
reservations.  They promised to be very cooperative.  Please make sure you
ask for a cancellation confirmation number just in case.  The
reservation/cancellation number is 1.314.427.4700 

 

This meeting is going to be a great time, value and educational seminar that
I wish all of our members could attend.   I look forward to seeing old
friends and meeting new ones.  We are also able to open up the exhibition
hall for new vendor booths and tabletop reservations.  Contact me if you are
interested.

 

My time to respond is difficult right now as I am in a non-verizon area.  I
will be returning to St. Louis tonight and then leaving in the morning for
my trip back to Indiana.  If you have questions, it is probably better to
give me a call in the meantime.

 

Thanks,

 

Rick Harnish

President

WISPA

260-307-4000 cell

866-317-2851 WISPA Office

Skype: rick.harnish.

rharn...@wispa.org

 




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[Jeromie Reeves]

I am not driving them past the default power, and often at lower then
max modulations. The replaced cards are working closer to expected
(still some bleed over but well under what the others were doing). The
nano still spews like a collage student after sumer break. I am going
to drop its modulation and power each in steps and see if it cleans up
any. It also looks like only the places where I have 2 5ghz units are
acting that dirty. I wonder if the other antennas are not picking up
the near field? I will separate the units instead of just un plugging
one, and see if it cleans up.

On Thu, Jun 24, 2010 at 7:43 AM, Justin Wilson  wrote:
>    I look at power compared to a car.  You get better performance at a
> certain RPM on a car.  This is almost never near the redline.  Once you
> reach the limit you are wasting power.  Radio cards are the same way.  If
> you drive them at 100% they can not be as efficient as on a lower power
> setting.
>
>    Justin
> --
> Justin Wilson 
> http://www.mtin.net/blog
> Wisp Consulting ­ Tower Climbing ­ Network Support
>
>
>
> From: Ryan Ghering 
> Reply-To: WISPA General List 
> Date: Wed, 23 Jun 2010 22:53:23 -0600
> To: WISPA General List 
> Subject: Re: [WISPA] Maximum sector power?
>
> We are running RocketM2's and RocketM5's and we have set policy's on the 120
> sectors
> to limit the power on the radios to 17db they seem to act better then
> setting them to 20.
> Oddly enough much stronger signal's at 17 than at 20..
>
> We have one site where we have the radios set to 13 and they work
> beautifully.
>
> Ryan
>
> On Wed, Jun 23, 2010 at 10:43 PM, Rubens Kuhl  wrote:
>
>> >
>> > The PtP/PtMP distinction does create interesting ambiguity.  But then
>>
>> My favorite ambiguity is whether the PtP/PtMP distinction applies to
>> the full-duplex system or per traffic direction... one reading would
>> say that an uplink(Customer - > WISP) that is made using directive
>> antennas can follow PtP instead of PtMP rules, which would apply only
>> to the downlink (WISP -> Customer) .
>>
>>
>>
>> Rubens
>>
>>
>>
>>
> 
>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>>
>>
> 
>>
>> WISPA Wireless List: wireless@wispa.org
>>
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>>
>> Archives: http://lists.wispa.org/pipermail/wireless/
>>
>
>
>
> --
> Ryan Ghering
> Network Operations - Plains.Net
> Office: 970-848-0475 - Cell: 970-630-1879
>
>
> 
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
> 
>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>



WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[Justin Wilson]

I look at power compared to a car.  You get better performance at a
certain RPM on a car.  This is almost never near the redline.  Once you
reach the limit you are wasting power.  Radio cards are the same way.  If
you drive them at 100% they can not be as efficient as on a lower power
setting.

Justin
-- 
Justin Wilson 
http://www.mtin.net/blog
Wisp Consulting ­ Tower Climbing ­ Network Support



From: Ryan Ghering 
Reply-To: WISPA General List 
Date: Wed, 23 Jun 2010 22:53:23 -0600
To: WISPA General List 
Subject: Re: [WISPA] Maximum sector power?

We are running RocketM2's and RocketM5's and we have set policy's on the 120
sectors
to limit the power on the radios to 17db they seem to act better then
setting them to 20.
Oddly enough much stronger signal's at 17 than at 20..

We have one site where we have the radios set to 13 and they work
beautifully.

Ryan

On Wed, Jun 23, 2010 at 10:43 PM, Rubens Kuhl  wrote:

> >
> > The PtP/PtMP distinction does create interesting ambiguity.  But then
>
> My favorite ambiguity is whether the PtP/PtMP distinction applies to
> the full-duplex system or per traffic direction... one reading would
> say that an uplink(Customer - > WISP) that is made using directive
> antennas can follow PtP instead of PtMP rules, which would apply only
> to the downlink (WISP -> Customer) .
>
>
>
> Rubens
>
>
>
> 

> WISPA Wants You! Join today!
> http://signup.wispa.org/
>
> 

>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>



-- 
Ryan Ghering
Network Operations - Plains.Net
Office: 970-848-0475 - Cell: 970-630-1879




WISPA Wants You! Join today!
http://signup.wispa.org/


 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[Fred Goldstein]

At 6/24/2010 09:32 AM, Bob West wrote:
>Man, that's ugly.  I've never tested the spread of the older nanos, the new
>M series look as if they stay where you put them though.  But that's a
>mess...

Sure is.  I smell hardware.  Looking at the plot over time, it 
reminded me of a well-known phenomenon from the vacuum tube era, 
parasitic oscillation.  Drifting crappy waveforms, not constant 
power.  Isn't that why the tetrode was invented?  I have vague 
memories of using "gimmick" capacitors (two pieces of 
teflon-insulated wire, twisted together tighter or looser to adjust) 
to neutralize VHF power amplifiers, back around 40 years ago.

I've never taken apart a Ubiquiti or MikroTik board but I'd guess 
that they are using a reasonably high-gain final output transistor 
with some microstrip PC-board tuned circuits.  A little out of spec 
and you can find enough feedback to make it oscillate.  Maybe too 
high a VSWR?  Or just a marginal design?  Positive feedback to the 
parasitic itself caused by heat, making it get worse as it warms 
up?  Just an OT guessing, of course.

>Bob-
>-Original Message-
>From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On
>Behalf Of Jeromie Reeves
>Sent: Thursday, June 24, 2010 12:56 AM
>To: WISPA General List
>Subject: Re: [WISPA] Maximum sector power?
>
>Do not forget OOB and the likes. I have been using AirView for a while
>to check on my sites and some were unacceptable to me (5mhz but still
>hitting 10 or 20mhz at -85) so I replaced the cards (all MT sites). I
>am unsure if the cards are bad, going bad, or just how they were
>working from day one. Swapped them, and they look much better. I have
>been hunting down interference (most of it not self, only 2 links were
>over lapping and that due to the spread on the cards). I noticed that
>some sites had a higher then expected noise floor. I tracked it down
>to pretty much all of my NS5's (non M's). There is a pretty high bleed
>from a number of them. The linked airview screen shot shows a site
>with nothing but a nano5 in AP WDS mode with no clients connected. It
>is set for 5mhz and ch 164.  The step to -...@5.810 is present with in
>30 seconds of powering the nano. The next step down, to about
>-...@5.793 a bit after that (60~90sec). This was taken with a rocket
>and 120* 16db sector about 10ft in front and 10ft below the nano. The
>nano is running stock firmware and will be replaced with a nano5m.
>
>
>
>http://img718.imageshack.us/img718/8832/snapshot3v.png
>

  --
  Fred Goldsteink1io   fgoldstein "at" ionary.com
  ionary Consulting  http://www.ionary.com/
  +1 617 795 2701 




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[Robert West]

The US would probably go for that if it was all smart antenna and radios.  

Bob-



-Original Message-
From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On
Behalf Of Francois Menard
Sent: Thursday, June 24, 2010 9:04 AM
To: WISPA General List
Subject: Re: [WISPA] Maximum sector power?

Or you can be legit in Canada, and go for 3.65 GHz and get up to 57 dBM
legally in rural areas ;)

Courtesy of the guy that changed the rules for 3.65 in Canada and is looking
for the US to do the same...

F.

On 2010-06-23, at 5:41 PM, Fred R. Goldstein wrote:

> I'm just a little confused about some of these nice-looking access 
> points.  The UBNT Rocket M5, for instance, can put out +27 dBm.  It 
> plugs *right into* a nice 19dB sector antenna.  Okay, the smaller, 
> 120 dB sector is only 16 dB.  Now math is not really my thing but I 
> get a total ERP there of +43 to 46 dBm.
> 
> FCC Rule 15.247 states that the maximum transmitted power output for 
> digitally-modulated intentional radiators in the 5725-5850 MHz band 
> ("ISM") is 1 watt, and the maximum antenna gain is 6 dBi.  Each 
> additional dB of antanna gain means one less dB of power.  So the 
> maximum ERP is 4 watts (+36).
> 
> Point-to-point is an exception in that specific band; it is allowed 
> unlimited antenna gain.  But "point-to-multipoint systems, 
> omnidirectional applications, and multiple co-located intentional 
> radiators transmitting the same information" are under the cap.
> 
> So am I correct in assuming that everybody who uses the Rocket M5, or 
> any other similar PtMP system for subscriber access, turns the 
> transmitter power REAL low (~+20 + feedline loss), in order to keep 
> the ERP below +36?  Or are we assuming that since you're technically 
> only transmitting and receiving to one end user at a time, it's really
PtP?
> 
> SkyPilot's legal hack, of course, is to have eight 45 degree sector 
> antennas and only use one at a time, so it is legally PTP even with 
> +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something 
> like that will become relatively easy.  But we're not quite there 
> yet.  Thoughts?
> 
>  --
>  Fred Goldsteink1io   fgoldstein "at" ionary.com
>  ionary Consulting  http://www.ionary.com/
>  +1 617 795 2701 
> 
> 
> 
>


> WISPA Wants You! Join today!
> http://signup.wispa.org/
>


> 
> WISPA Wireless List: wireless@wispa.org
> 
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
> 
> Archives: http://lists.wispa.org/pipermail/wireless/





WISPA Wants You! Join today!
http://signup.wispa.org/


 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[Robert West]

Man, that's ugly.  I've never tested the spread of the older nanos, the new
M series look as if they stay where you put them though.  But that's a
mess...

Bob-



-Original Message-
From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On
Behalf Of Jeromie Reeves
Sent: Thursday, June 24, 2010 12:56 AM
To: WISPA General List
Subject: Re: [WISPA] Maximum sector power?

Do not forget OOB and the likes. I have been using AirView for a while
to check on my sites and some were unacceptable to me (5mhz but still
hitting 10 or 20mhz at -85) so I replaced the cards (all MT sites). I
am unsure if the cards are bad, going bad, or just how they were
working from day one. Swapped them, and they look much better. I have
been hunting down interference (most of it not self, only 2 links were
over lapping and that due to the spread on the cards). I noticed that
some sites had a higher then expected noise floor. I tracked it down
to pretty much all of my NS5's (non M's). There is a pretty high bleed
from a number of them. The linked airview screen shot shows a site
with nothing but a nano5 in AP WDS mode with no clients connected. It
is set for 5mhz and ch 164.  The step to -...@5.810 is present with in
30 seconds of powering the nano. The next step down, to about
-...@5.793 a bit after that (60~90sec). This was taken with a rocket
and 120* 16db sector about 10ft in front and 10ft below the nano. The
nano is running stock firmware and will be replaced with a nano5m.



http://img718.imageshack.us/img718/8832/snapshot3v.png

On Wed, Jun 23, 2010 at 9:12 PM, Robert West 
wrote:
> Stick with the rules, dude.   You'll still get customers and you'll still
> make money.
>
> One FCC visit can ruin your day,
>
> Bob-
>
>
>
> -Original Message-
> From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On
> Behalf Of Fred R. Goldstein
> Sent: Wednesday, June 23, 2010 5:41 PM
> To: WISPA General List
> Subject: [WISPA] Maximum sector power?
>
> I'm just a little confused about some of these nice-looking access points.
> The UBNT Rocket M5, for instance, can put out +27 dBm.  It plugs *right
> into* a nice 19dB sector antenna.  Okay, the smaller,
> 120 dB sector is only 16 dB.  Now math is not really my thing but I get a
> total ERP there of +43 to 46 dBm.
>
> FCC Rule 15.247 states that the maximum transmitted power output for
> digitally-modulated intentional radiators in the 5725-5850 MHz band
> ("ISM") is 1 watt, and the maximum antenna gain is 6 dBi.  Each additional
> dB of antanna gain means one less dB of power.  So the maximum ERP is 4
> watts (+36).
>
> Point-to-point is an exception in that specific band; it is allowed
> unlimited antenna gain.  But "point-to-multipoint systems, omnidirectional
> applications, and multiple co-located intentional radiators transmitting
the
> same information" are under the cap.
>
> So am I correct in assuming that everybody who uses the Rocket M5, or any
> other similar PtMP system for subscriber access, turns the transmitter
power
> REAL low (~+20 + feedline loss), in order to keep the ERP below +36?  Or
are
> we assuming that since you're technically only transmitting and receiving
to
> one end user at a time, it's really PtP?
>
> SkyPilot's legal hack, of course, is to have eight 45 degree sector
antennas
> and only use one at a time, so it is legally PTP even with
> +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something
> like that will become relatively easy.  But we're not quite there yet.
> Thoughts?
>
>  --
>  Fred Goldstein    k1io   fgoldstein "at" ionary.com
>  ionary Consulting              http://www.ionary.com/
>  +1 617 795 2701
>
>
>
>

> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
>

> 
>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>
>


> WISPA Wants You! Join today!
> http://signup.wispa.org/
>


>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>




WISPA Wants You! Join today!
http://signup.wispa.org/


 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/




WISPA Wa

Re: [WISPA] Maximum sector power?

[Jeremie Chism]

We had a discussion about this on the ubnt board. I have a pair of nanobridge M 
units. No difference was shown with an increase or decrease in power. I did 
notice at a certain point that after a day the units would completely stop 
transmitting. A reboot would fix it. 

Sent from my iPhone

On Jun 24, 2010, at 8:16 AM, Faisal Imtiaz  wrote:

> FYI.
> Please make sure that you are running the most recent version 5.2 on the M 
> series... Older firmware had known issues in setting up the output power.
> 
> Faisal
> 
> On Jun 24, 2010, at 10:06 AM, "Stuart Pierce"  wrote:
> 
>> I see negligible difference in signal strength anyway between 20 and 27.
>> 
>> -- Original Message --
>> From: Francois Menard 
>> Reply-To: WISPA General List 
>> Date:  Thu, 24 Jun 2010 09:03:59 -0400
>> 
>>> Or you can be legit in Canada, and go for 3.65 GHz and get up to 57 dBM 
>>> legally in rural areas ;)
>>> 
>>> Courtesy of the guy that changed the rules for 3.65 in Canada and is 
>>> looking for the US to do the same...
>>> 
>>> F.
>>> 
>>> On 2010-06-23, at 5:41 PM, Fred R. Goldstein wrote:
>>> 
 I'm just a little confused about some of these nice-looking access 
 points.  The UBNT Rocket M5, for instance, can put out +27 dBm.  It 
 plugs *right into* a nice 19dB sector antenna.  Okay, the smaller, 
 120 dB sector is only 16 dB.  Now math is not really my thing but I 
 get a total ERP there of +43 to 46 dBm.
 
 FCC Rule 15.247 states that the maximum transmitted power output for 
 digitally-modulated intentional radiators in the 5725-5850 MHz band 
 ("ISM") is 1 watt, and the maximum antenna gain is 6 dBi.  Each 
 additional dB of antanna gain means one less dB of power.  So the 
 maximum ERP is 4 watts (+36).
 
 Point-to-point is an exception in that specific band; it is allowed 
 unlimited antenna gain.  But "point-to-multipoint systems, 
 omnidirectional applications, and multiple co-located intentional 
 radiators transmitting the same information" are under the cap.
 
 So am I correct in assuming that everybody who uses the Rocket M5, or 
 any other similar PtMP system for subscriber access, turns the 
 transmitter power REAL low (~+20 + feedline loss), in order to keep 
 the ERP below +36?  Or are we assuming that since you're technically 
 only transmitting and receiving to one end user at a time, it's really PtP?
 
 SkyPilot's legal hack, of course, is to have eight 45 degree sector 
 antennas and only use one at a time, so it is legally PTP even with 
 +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something 
 like that will become relatively easy.  But we're not quite there 
 yet.  Thoughts?
 
 --
 Fred Goldsteink1io   fgoldstein "at" ionary.com
 ionary Consulting  http://www.ionary.com/
 +1 617 795 2701 
 
 
 
 
 WISPA Wants You! Join today!
 http://signup.wispa.org/
 
 
 WISPA Wireless List: wireless@wispa.org
 
 Subscribe/Unsubscribe:
 http://lists.wispa.org/mailman/listinfo/wireless
 
 Archives: http://lists.wispa.org/pipermail/wireless/
>>> 
>>> 
>>> 
>>> 
>>> WISPA Wants You! Join today!
>>> http://signup.wispa.org/
>>> 
>>> 
>>> WISPA Wireless List: wireless@wispa.org
>>> 
>>> Subscribe/Unsubscribe:
>>> http://lists.wispa.org/mailman/listinfo/wireless
>>> 
>>> Archives: http://lists.wispa.org/pipermail/wireless/
>>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Sent via the WebMail system at avolve.net
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>> 
>> 
>> WISPA Wireless List: wireless@wispa.org
>> 
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>> 
>> Archives: http://lists.wispa.org/pipermail/wireless/
>> 
> 
> 
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
> 
> WISPA Wireless List: wireless@wispa.org
> 
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
> 
> Archives: http://lists.wispa.org/pipermail/wireless/



WISPA Wants You! Join today!
http://signup.wispa.org/
---

Re: [WISPA] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue

[Jayson Baker]

I can't comment on the OP, but I can tell you that we are.  OSPF talks, but
never goes Full and exchanges routes.
Latest FW on both ends.  Like I said, same exact config as the other links
which work perfect.

On Thu, Jun 24, 2010 at 7:20 AM, Faisal Imtiaz  wrote:

> Make sure you are running the most recent version of 5.2 firmware.also
> you need to be running then in AP-WDS and CPE-WDS mode.
>
> Faisal
>
> On Jun 24, 2010, at 9:08 AM, Jayson Baker  wrote:
>
> > I didn't quite follow all of that, it must be too early.
> > But I can tell you we have 4 of the PtP UBNT links using their M-series.
>  3
> > of those OSPF fine.  The other won't OSPF for the life of me.  All same
> > config and firmware on all units.
> >
> > On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert  >wrote:
> >
> >> We have been putting up some Ubiquity RocketM5 point-to-point bridge
> >> links, running airos 5.2, lately to replace some overloaded StarOS
> >> backhauls.  Where these links have gone in, we static route the traffic
> >> across them.  They happen to be on the OSPF/OLSR divider boundry.  I
> >> would like to find a good way to redistribute between the routing
> >> protocols, but that's for another day.  When I get time, I'll probably
> >> just convert the 20 odd OLSR towers to OSPF.
> >>
> >> These are our first experience with Ubiquity.  The first two were no
> >> muss, no fuss.  The third link went up nicely.  It's configured the same
> >> as the other two links.  About an hour after we plugged the local end
> >> at our office into the main switch, rather than a laptop, we started
> >> loosing routes to sites which pass through the tower at the far end of
> >> the link.
> >>
> >> All hosts on the tower LAN can see each other.  We can reach all of
> >> them from anywhere else on our network.  It is just routes for hosts
> >> connected wirelessly to that tower which are no longer known to the
> >> staros box which has the existing backhaul to our office.
> >>
> >> We rebooted everything at the remote tower.  The links came up.  The
> >> routes were good.  Approximately an hour later, the same routes fell
> >> out.  So, we decided it must be due to some sort of wierd multicast OLSR
> >> issue when these towers were suddenly able to see each other across
> >> the bridges.  I unplugged the ethernet at the office and waited until
> >> tonight to try again.  The routes straightened themselves out as soon as
> >> I unplugged the office end.  Wild.
> >>
> >> This afternoon, I setup a seperate VLAN on the switch for this link.
> >> Before I left the office I plugged it in about, 8:00pm.  I didn't have
> >> any other devices configured on that VLAN.
> >>
> >> There were no problems for several hours until I configured the new VLAN
> >> on the Cisco that was sometime between 1:01 and 1:10am.  The RANCID
> >> run at 1:01 didn't see any changes but the run at 2:01 found them.  At
> >> 1:10am Nagios noticed that it couldn't reach the equipment through those
> >> same routes.
> >>
> >> + interface GigabitEthernet0/3.13
> >> +  description "Wireless VPN 3
> >> +  encapsulation dot1Q 13
> >> +  ip address 10.127.3.1 255.255.255.0
> >> +  no cdp enable
> >> + !
> >>
> >> That's the subnet for the RocketM5s.  The StarOS gear on the tower uses
> >> a public /29 subnet.
> >>
> >> I tried various things with reboots and restarts of OLSR on the staros
> >> gear at the tower.  The routes came back for four or five minutes then
> >> went away again.  No good.
> >>
> >> So, at about 2:10am, I logged into the RocketM5 at the tower and
> >> disabled it's ethernet interface.  Within a few seconds, my pings to
> >> equipment through the lost routes began succeeding.
> >>
> >> It's now 3:25, and all's well.  I am puzzled.  We really need the
> >> additional bandwidth the ubiquity link can give us on this link.
> >>
> >> At 3:26 I enabled the LAN at the tower just to make sure.  Within 2
> >> minutes, splat.  This time I left the LAN enabled at the tower and
> >> disabled the WLAN interface at the office.  All better in seconds.
> >>
> >> Administratively shutting down interface gig0/3.13 at the office seems
> >> to be enough to heal OLSR at the tower.  If the tower LAN can see the
> >> cisco, we drop routes.  But the other ubiquity links connect back to the
> >> same cisco at the office.
> >>
> >> I think we will probably replace the switch at the tower tomorrow to see
> >> if it has problems we haven't tickled before.  I'm stumped.  Does anyone
> >> else have any ideas?
> >>
> >>
> >> --
> >> Scott LambertKC5MLE   Unix
> SysAdmin
> >> lamb...@lambertfam.org
> >>
> >>
> >>
> >>
> >>
> 
> >> WISPA Wants You! Join today!
> >> http://signup.wispa.org/
> >>
> >>
> 
> >>
> >> WISPA Wireless List: wireless@wispa.org
> >>
> >> Subscribe/Unsubscribe:
> >> http://l

Re: [WISPA] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue

[Faisal Imtiaz]

Make sure you are running the most recent version of 5.2 firmware.also you 
need to be running then in AP-WDS and CPE-WDS mode. 

Faisal

On Jun 24, 2010, at 9:08 AM, Jayson Baker  wrote:

> I didn't quite follow all of that, it must be too early.
> But I can tell you we have 4 of the PtP UBNT links using their M-series.  3
> of those OSPF fine.  The other won't OSPF for the life of me.  All same
> config and firmware on all units.
> 
> On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert wrote:
> 
>> We have been putting up some Ubiquity RocketM5 point-to-point bridge
>> links, running airos 5.2, lately to replace some overloaded StarOS
>> backhauls.  Where these links have gone in, we static route the traffic
>> across them.  They happen to be on the OSPF/OLSR divider boundry.  I
>> would like to find a good way to redistribute between the routing
>> protocols, but that's for another day.  When I get time, I'll probably
>> just convert the 20 odd OLSR towers to OSPF.
>> 
>> These are our first experience with Ubiquity.  The first two were no
>> muss, no fuss.  The third link went up nicely.  It's configured the same
>> as the other two links.  About an hour after we plugged the local end
>> at our office into the main switch, rather than a laptop, we started
>> loosing routes to sites which pass through the tower at the far end of
>> the link.
>> 
>> All hosts on the tower LAN can see each other.  We can reach all of
>> them from anywhere else on our network.  It is just routes for hosts
>> connected wirelessly to that tower which are no longer known to the
>> staros box which has the existing backhaul to our office.
>> 
>> We rebooted everything at the remote tower.  The links came up.  The
>> routes were good.  Approximately an hour later, the same routes fell
>> out.  So, we decided it must be due to some sort of wierd multicast OLSR
>> issue when these towers were suddenly able to see each other across
>> the bridges.  I unplugged the ethernet at the office and waited until
>> tonight to try again.  The routes straightened themselves out as soon as
>> I unplugged the office end.  Wild.
>> 
>> This afternoon, I setup a seperate VLAN on the switch for this link.
>> Before I left the office I plugged it in about, 8:00pm.  I didn't have
>> any other devices configured on that VLAN.
>> 
>> There were no problems for several hours until I configured the new VLAN
>> on the Cisco that was sometime between 1:01 and 1:10am.  The RANCID
>> run at 1:01 didn't see any changes but the run at 2:01 found them.  At
>> 1:10am Nagios noticed that it couldn't reach the equipment through those
>> same routes.
>> 
>> + interface GigabitEthernet0/3.13
>> +  description "Wireless VPN 3
>> +  encapsulation dot1Q 13
>> +  ip address 10.127.3.1 255.255.255.0
>> +  no cdp enable
>> + !
>> 
>> That's the subnet for the RocketM5s.  The StarOS gear on the tower uses
>> a public /29 subnet.
>> 
>> I tried various things with reboots and restarts of OLSR on the staros
>> gear at the tower.  The routes came back for four or five minutes then
>> went away again.  No good.
>> 
>> So, at about 2:10am, I logged into the RocketM5 at the tower and
>> disabled it's ethernet interface.  Within a few seconds, my pings to
>> equipment through the lost routes began succeeding.
>> 
>> It's now 3:25, and all's well.  I am puzzled.  We really need the
>> additional bandwidth the ubiquity link can give us on this link.
>> 
>> At 3:26 I enabled the LAN at the tower just to make sure.  Within 2
>> minutes, splat.  This time I left the LAN enabled at the tower and
>> disabled the WLAN interface at the office.  All better in seconds.
>> 
>> Administratively shutting down interface gig0/3.13 at the office seems
>> to be enough to heal OLSR at the tower.  If the tower LAN can see the
>> cisco, we drop routes.  But the other ubiquity links connect back to the
>> same cisco at the office.
>> 
>> I think we will probably replace the switch at the tower tomorrow to see
>> if it has problems we haven't tickled before.  I'm stumped.  Does anyone
>> else have any ideas?
>> 
>> 
>> --
>> Scott LambertKC5MLE   Unix SysAdmin
>> lamb...@lambertfam.org
>> 
>> 
>> 
>> 
>> 
>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>> 
>> 
>> 
>> WISPA Wireless List: wireless@wispa.org
>> 
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>> 
>> Archives: http://lists.wispa.org/pipermail/wireless/
>> 
> 
> 
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
> 
> WISPA Wireless List: wireless@wispa.org
> 
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wirel

Re: [WISPA] Maximum sector power?

[Faisal Imtiaz]

FYI.
Please make sure that you are running the most recent version 5.2 on the M 
series... Older firmware had known issues in setting up the output power.

Faisal

On Jun 24, 2010, at 10:06 AM, "Stuart Pierce"  wrote:

> I see negligible difference in signal strength anyway between 20 and 27.
> 
> -- Original Message --
> From: Francois Menard 
> Reply-To: WISPA General List 
> Date:  Thu, 24 Jun 2010 09:03:59 -0400
> 
>> Or you can be legit in Canada, and go for 3.65 GHz and get up to 57 dBM 
>> legally in rural areas ;)
>> 
>> Courtesy of the guy that changed the rules for 3.65 in Canada and is looking 
>> for the US to do the same...
>> 
>> F.
>> 
>> On 2010-06-23, at 5:41 PM, Fred R. Goldstein wrote:
>> 
>>> I'm just a little confused about some of these nice-looking access 
>>> points.  The UBNT Rocket M5, for instance, can put out +27 dBm.  It 
>>> plugs *right into* a nice 19dB sector antenna.  Okay, the smaller, 
>>> 120 dB sector is only 16 dB.  Now math is not really my thing but I 
>>> get a total ERP there of +43 to 46 dBm.
>>> 
>>> FCC Rule 15.247 states that the maximum transmitted power output for 
>>> digitally-modulated intentional radiators in the 5725-5850 MHz band 
>>> ("ISM") is 1 watt, and the maximum antenna gain is 6 dBi.  Each 
>>> additional dB of antanna gain means one less dB of power.  So the 
>>> maximum ERP is 4 watts (+36).
>>> 
>>> Point-to-point is an exception in that specific band; it is allowed 
>>> unlimited antenna gain.  But "point-to-multipoint systems, 
>>> omnidirectional applications, and multiple co-located intentional 
>>> radiators transmitting the same information" are under the cap.
>>> 
>>> So am I correct in assuming that everybody who uses the Rocket M5, or 
>>> any other similar PtMP system for subscriber access, turns the 
>>> transmitter power REAL low (~+20 + feedline loss), in order to keep 
>>> the ERP below +36?  Or are we assuming that since you're technically 
>>> only transmitting and receiving to one end user at a time, it's really PtP?
>>> 
>>> SkyPilot's legal hack, of course, is to have eight 45 degree sector 
>>> antennas and only use one at a time, so it is legally PTP even with 
>>> +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something 
>>> like that will become relatively easy.  But we're not quite there 
>>> yet.  Thoughts?
>>> 
>>> --
>>> Fred Goldsteink1io   fgoldstein "at" ionary.com
>>> ionary Consulting  http://www.ionary.com/
>>> +1 617 795 2701 
>>> 
>>> 
>>> 
>>> 
>>> WISPA Wants You! Join today!
>>> http://signup.wispa.org/
>>> 
>>> 
>>> WISPA Wireless List: wireless@wispa.org
>>> 
>>> Subscribe/Unsubscribe:
>>> http://lists.wispa.org/mailman/listinfo/wireless
>>> 
>>> Archives: http://lists.wispa.org/pipermail/wireless/
>> 
>> 
>> 
>> 
>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>> 
>> 
>> WISPA Wireless List: wireless@wispa.org
>> 
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>> 
>> Archives: http://lists.wispa.org/pipermail/wireless/
>> 
> 
> 
> 
> 
> 
> 
> Sent via the WebMail system at avolve.net
> 
> 
> 
> 
> 
> 
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
> 
> WISPA Wireless List: wireless@wispa.org
> 
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
> 
> Archives: http://lists.wispa.org/pipermail/wireless/
> 



WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[Dennis Burgess]

Now, do this.  Take a Mikrotik, set the transmitting antenna to A, and
put your smaller sector up, then put on the B connector the largest
sector you can find. :)  That work?

---
Dennis Burgess, Mikrotik Certified Trainer 
Link Technologies, Inc -- Mikrotik & WISP Support Services
Office: 314-735-0270 Website: http://www.linktechs.net
LIVE On-Line Mikrotik Training - Author of "Learn RouterOS"


-Original Message-
From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On
Behalf Of Fred R. Goldstein
Sent: Wednesday, June 23, 2010 4:41 PM
To: WISPA General List
Subject: [WISPA] Maximum sector power?

I'm just a little confused about some of these nice-looking access
points.  The UBNT Rocket M5, for instance, can put out +27 dBm.  It
plugs *right into* a nice 19dB sector antenna.  Okay, the smaller,
120 dB sector is only 16 dB.  Now math is not really my thing but I get
a total ERP there of +43 to 46 dBm.

FCC Rule 15.247 states that the maximum transmitted power output for
digitally-modulated intentional radiators in the 5725-5850 MHz band
("ISM") is 1 watt, and the maximum antenna gain is 6 dBi.  Each
additional dB of antanna gain means one less dB of power.  So the
maximum ERP is 4 watts (+36).

Point-to-point is an exception in that specific band; it is allowed
unlimited antenna gain.  But "point-to-multipoint systems,
omnidirectional applications, and multiple co-located intentional
radiators transmitting the same information" are under the cap.

So am I correct in assuming that everybody who uses the Rocket M5, or
any other similar PtMP system for subscriber access, turns the
transmitter power REAL low (~+20 + feedline loss), in order to keep the
ERP below +36?  Or are we assuming that since you're technically only
transmitting and receiving to one end user at a time, it's really PtP?

SkyPilot's legal hack, of course, is to have eight 45 degree sector
antennas and only use one at a time, so it is legally PTP even with 
+42 EiRP. And with advanced 11N 4x4 beamforming antennas, something
like that will become relatively easy.  But we're not quite there yet.
Thoughts?

  --
  Fred Goldsteink1io   fgoldstein "at" ionary.com
  ionary Consulting  http://www.ionary.com/
  +1 617 795 2701 





WISPA Wants You! Join today!
http://signup.wispa.org/


 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/



WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue

[Jayson Baker]

I didn't quite follow all of that, it must be too early.
But I can tell you we have 4 of the PtP UBNT links using their M-series.  3
of those OSPF fine.  The other won't OSPF for the life of me.  All same
config and firmware on all units.

On Thu, Jun 24, 2010 at 4:38 AM, Scott Lambert wrote:

> We have been putting up some Ubiquity RocketM5 point-to-point bridge
> links, running airos 5.2, lately to replace some overloaded StarOS
> backhauls.  Where these links have gone in, we static route the traffic
> across them.  They happen to be on the OSPF/OLSR divider boundry.  I
> would like to find a good way to redistribute between the routing
> protocols, but that's for another day.  When I get time, I'll probably
> just convert the 20 odd OLSR towers to OSPF.
>
> These are our first experience with Ubiquity.  The first two were no
> muss, no fuss.  The third link went up nicely.  It's configured the same
> as the other two links.  About an hour after we plugged the local end
> at our office into the main switch, rather than a laptop, we started
> loosing routes to sites which pass through the tower at the far end of
> the link.
>
> All hosts on the tower LAN can see each other.  We can reach all of
> them from anywhere else on our network.  It is just routes for hosts
> connected wirelessly to that tower which are no longer known to the
> staros box which has the existing backhaul to our office.
>
> We rebooted everything at the remote tower.  The links came up.  The
> routes were good.  Approximately an hour later, the same routes fell
> out.  So, we decided it must be due to some sort of wierd multicast OLSR
> issue when these towers were suddenly able to see each other across
> the bridges.  I unplugged the ethernet at the office and waited until
> tonight to try again.  The routes straightened themselves out as soon as
> I unplugged the office end.  Wild.
>
> This afternoon, I setup a seperate VLAN on the switch for this link.
> Before I left the office I plugged it in about, 8:00pm.  I didn't have
> any other devices configured on that VLAN.
>
> There were no problems for several hours until I configured the new VLAN
> on the Cisco that was sometime between 1:01 and 1:10am.  The RANCID
> run at 1:01 didn't see any changes but the run at 2:01 found them.  At
> 1:10am Nagios noticed that it couldn't reach the equipment through those
> same routes.
>
> + interface GigabitEthernet0/3.13
> +  description "Wireless VPN 3
> +  encapsulation dot1Q 13
> +  ip address 10.127.3.1 255.255.255.0
> +  no cdp enable
> + !
>
> That's the subnet for the RocketM5s.  The StarOS gear on the tower uses
> a public /29 subnet.
>
> I tried various things with reboots and restarts of OLSR on the staros
> gear at the tower.  The routes came back for four or five minutes then
> went away again.  No good.
>
> So, at about 2:10am, I logged into the RocketM5 at the tower and
> disabled it's ethernet interface.  Within a few seconds, my pings to
> equipment through the lost routes began succeeding.
>
> It's now 3:25, and all's well.  I am puzzled.  We really need the
> additional bandwidth the ubiquity link can give us on this link.
>
> At 3:26 I enabled the LAN at the tower just to make sure.  Within 2
> minutes, splat.  This time I left the LAN enabled at the tower and
> disabled the WLAN interface at the office.  All better in seconds.
>
> Administratively shutting down interface gig0/3.13 at the office seems
> to be enough to heal OLSR at the tower.  If the tower LAN can see the
> cisco, we drop routes.  But the other ubiquity links connect back to the
> same cisco at the office.
>
> I think we will probably replace the switch at the tower tomorrow to see
> if it has problems we haven't tickled before.  I'm stumped.  Does anyone
> else have any ideas?
>
>
> --
> Scott LambertKC5MLE   Unix SysAdmin
> lamb...@lambertfam.org
>
>
>
>
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
>
> 
>
> WISPA Wireless List: wireless@wispa.org
>
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
>
> Archives: http://lists.wispa.org/pipermail/wireless/
>



WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[Stuart Pierce]

I see negligible difference in signal strength anyway between 20 and 27.

-- Original Message --
From: Francois Menard 
Reply-To: WISPA General List 
Date:  Thu, 24 Jun 2010 09:03:59 -0400

>Or you can be legit in Canada, and go for 3.65 GHz and get up to 57 dBM 
>legally in rural areas ;)
>
>Courtesy of the guy that changed the rules for 3.65 in Canada and is looking 
>for the US to do the same...
>
>F.
>
>On 2010-06-23, at 5:41 PM, Fred R. Goldstein wrote:
>
>> I'm just a little confused about some of these nice-looking access 
>> points.  The UBNT Rocket M5, for instance, can put out +27 dBm.  It 
>> plugs *right into* a nice 19dB sector antenna.  Okay, the smaller, 
>> 120 dB sector is only 16 dB.  Now math is not really my thing but I 
>> get a total ERP there of +43 to 46 dBm.
>> 
>> FCC Rule 15.247 states that the maximum transmitted power output for 
>> digitally-modulated intentional radiators in the 5725-5850 MHz band 
>> ("ISM") is 1 watt, and the maximum antenna gain is 6 dBi.  Each 
>> additional dB of antanna gain means one less dB of power.  So the 
>> maximum ERP is 4 watts (+36).
>> 
>> Point-to-point is an exception in that specific band; it is allowed 
>> unlimited antenna gain.  But "point-to-multipoint systems, 
>> omnidirectional applications, and multiple co-located intentional 
>> radiators transmitting the same information" are under the cap.
>> 
>> So am I correct in assuming that everybody who uses the Rocket M5, or 
>> any other similar PtMP system for subscriber access, turns the 
>> transmitter power REAL low (~+20 + feedline loss), in order to keep 
>> the ERP below +36?  Or are we assuming that since you're technically 
>> only transmitting and receiving to one end user at a time, it's really PtP?
>> 
>> SkyPilot's legal hack, of course, is to have eight 45 degree sector 
>> antennas and only use one at a time, so it is legally PTP even with 
>> +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something 
>> like that will become relatively easy.  But we're not quite there 
>> yet.  Thoughts?
>> 
>>  --
>>  Fred Goldsteink1io   fgoldstein "at" ionary.com
>>  ionary Consulting  http://www.ionary.com/
>>  +1 617 795 2701 
>> 
>> 
>> 
>> 
>> WISPA Wants You! Join today!
>> http://signup.wispa.org/
>> 
>> 
>> WISPA Wireless List: wireless@wispa.org
>> 
>> Subscribe/Unsubscribe:
>> http://lists.wispa.org/mailman/listinfo/wireless
>> 
>> Archives: http://lists.wispa.org/pipermail/wireless/
>
>
>
>
>WISPA Wants You! Join today!
>http://signup.wispa.org/
>
> 
>WISPA Wireless List: wireless@wispa.org
>
>Subscribe/Unsubscribe:
>http://lists.wispa.org/mailman/listinfo/wireless
>
>Archives: http://lists.wispa.org/pipermail/wireless/
>
 





Sent via the WebMail system at avolve.net


 
   



WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[Francois Menard]

Or you can be legit in Canada, and go for 3.65 GHz and get up to 57 dBM legally 
in rural areas ;)

Courtesy of the guy that changed the rules for 3.65 in Canada and is looking 
for the US to do the same...

F.

On 2010-06-23, at 5:41 PM, Fred R. Goldstein wrote:

> I'm just a little confused about some of these nice-looking access 
> points.  The UBNT Rocket M5, for instance, can put out +27 dBm.  It 
> plugs *right into* a nice 19dB sector antenna.  Okay, the smaller, 
> 120 dB sector is only 16 dB.  Now math is not really my thing but I 
> get a total ERP there of +43 to 46 dBm.
> 
> FCC Rule 15.247 states that the maximum transmitted power output for 
> digitally-modulated intentional radiators in the 5725-5850 MHz band 
> ("ISM") is 1 watt, and the maximum antenna gain is 6 dBi.  Each 
> additional dB of antanna gain means one less dB of power.  So the 
> maximum ERP is 4 watts (+36).
> 
> Point-to-point is an exception in that specific band; it is allowed 
> unlimited antenna gain.  But "point-to-multipoint systems, 
> omnidirectional applications, and multiple co-located intentional 
> radiators transmitting the same information" are under the cap.
> 
> So am I correct in assuming that everybody who uses the Rocket M5, or 
> any other similar PtMP system for subscriber access, turns the 
> transmitter power REAL low (~+20 + feedline loss), in order to keep 
> the ERP below +36?  Or are we assuming that since you're technically 
> only transmitting and receiving to one end user at a time, it's really PtP?
> 
> SkyPilot's legal hack, of course, is to have eight 45 degree sector 
> antennas and only use one at a time, so it is legally PTP even with 
> +42 EiRP. And with advanced 11N 4x4 beamforming antennas, something 
> like that will become relatively easy.  But we're not quite there 
> yet.  Thoughts?
> 
>  --
>  Fred Goldsteink1io   fgoldstein "at" ionary.com
>  ionary Consulting  http://www.ionary.com/
>  +1 617 795 2701 
> 
> 
> 
> 
> WISPA Wants You! Join today!
> http://signup.wispa.org/
> 
> 
> WISPA Wireless List: wireless@wispa.org
> 
> Subscribe/Unsubscribe:
> http://lists.wispa.org/mailman/listinfo/wireless
> 
> Archives: http://lists.wispa.org/pipermail/wireless/




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Re: [WISPA] Maximum sector power?

[Stuart Pierce]

How about the age old, if your AP talks to one client at a time, then it is a 
ptp system. Much more so now with scheduling and UBNT's AirMax. I'm still on 
the talk about a 120* or less allows you to increase beyond 36 on each end. The 
talk was coming from the FCC a few years back from people like Van Budweiser 
and Dr. Pepper.

-- Original Message --
From: Rubens Kuhl 
Reply-To: WISPA General List 
Date:  Thu, 24 Jun 2010 01:43:03 -0300

>>
>> The PtP/PtMP distinction does create interesting ambiguity.  But then
>
>My favorite ambiguity is whether the PtP/PtMP distinction applies to
>the full-duplex system or per traffic direction... one reading would
>say that an uplink(Customer - > WISP) that is made using directive
>antennas can follow PtP instead of PtMP rules, which would apply only
>to the downlink (WISP -> Customer) .
>
>
>
>Rubens
>
>
>
>WISPA Wants You! Join today!
>http://signup.wispa.org/
>
> 
>WISPA Wireless List: wireless@wispa.org
>
>Subscribe/Unsubscribe:
>http://lists.wispa.org/mailman/listinfo/wireless
>
>Archives: http://lists.wispa.org/pipermail/wireless/
>
 





Sent via the WebMail system at avolve.net


 
   




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

[WISPA] Wierd StarOS/OLSR - Ubiquity RocketM5 bridge - Cisco issue

[Scott Lambert]

We have been putting up some Ubiquity RocketM5 point-to-point bridge
links, running airos 5.2, lately to replace some overloaded StarOS
backhauls.  Where these links have gone in, we static route the traffic
across them.  They happen to be on the OSPF/OLSR divider boundry.  I
would like to find a good way to redistribute between the routing
protocols, but that's for another day.  When I get time, I'll probably
just convert the 20 odd OLSR towers to OSPF.

These are our first experience with Ubiquity.  The first two were no
muss, no fuss.  The third link went up nicely.  It's configured the same
as the other two links.  About an hour after we plugged the local end
at our office into the main switch, rather than a laptop, we started
loosing routes to sites which pass through the tower at the far end of
the link.  

All hosts on the tower LAN can see each other.  We can reach all of
them from anywhere else on our network.  It is just routes for hosts
connected wirelessly to that tower which are no longer known to the
staros box which has the existing backhaul to our office.

We rebooted everything at the remote tower.  The links came up.  The
routes were good.  Approximately an hour later, the same routes fell
out.  So, we decided it must be due to some sort of wierd multicast OLSR
issue when these towers were suddenly able to see each other across
the bridges.  I unplugged the ethernet at the office and waited until
tonight to try again.  The routes straightened themselves out as soon as
I unplugged the office end.  Wild.

This afternoon, I setup a seperate VLAN on the switch for this link.
Before I left the office I plugged it in about, 8:00pm.  I didn't have
any other devices configured on that VLAN.

There were no problems for several hours until I configured the new VLAN
on the Cisco that was sometime between 1:01 and 1:10am.  The RANCID
run at 1:01 didn't see any changes but the run at 2:01 found them.  At
1:10am Nagios noticed that it couldn't reach the equipment through those
same routes.

+ interface GigabitEthernet0/3.13
+  description "Wireless VPN 3
+  encapsulation dot1Q 13
+  ip address 10.127.3.1 255.255.255.0
+  no cdp enable
+ !

That's the subnet for the RocketM5s.  The StarOS gear on the tower uses
a public /29 subnet.

I tried various things with reboots and restarts of OLSR on the staros
gear at the tower.  The routes came back for four or five minutes then
went away again.  No good.

So, at about 2:10am, I logged into the RocketM5 at the tower and
disabled it's ethernet interface.  Within a few seconds, my pings to
equipment through the lost routes began succeeding.

It's now 3:25, and all's well.  I am puzzled.  We really need the
additional bandwidth the ubiquity link can give us on this link.

At 3:26 I enabled the LAN at the tower just to make sure.  Within 2
minutes, splat.  This time I left the LAN enabled at the tower and
disabled the WLAN interface at the office.  All better in seconds.

Administratively shutting down interface gig0/3.13 at the office seems
to be enough to heal OLSR at the tower.  If the tower LAN can see the
cisco, we drop routes.  But the other ubiquity links connect back to the
same cisco at the office.

I think we will probably replace the switch at the tower tomorrow to see
if it has problems we haven't tickled before.  I'm stumped.  Does anyone
else have any ideas?


-- 
Scott LambertKC5MLE   Unix SysAdmin
lamb...@lambertfam.org




WISPA Wants You! Join today!
http://signup.wispa.org/

 
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/