Here are a few threads related to control frame timeouts. There are more than a few people having problems with. These are all individual threads related to timing disconnects in one way or another. This is just from the first page of a search "control frame". I don't think the disconnects can be considered isolated they are happening on all frequencies, different hardware, PTP, PTMP, different ROS versions, etc etc.

http://forum.mikrotik.com/viewtopic.php ... me#p271651

http://forum.mikrotik.com/viewtopic.php ... me#p271501

http://forum.mikrotik.com/viewtopic.php ... trol+frame

http://forum.mikrotik.com/viewtopic.php ... trol+frame

http://forum.mikrotik.com/viewtopic.php ... trol+frame

http://forum.mikrotik.com/viewtopic.php ... trol+frame

http://forum.mikrotik.com/viewtopic.php ... trol+frame

http://forum.mikrotik.com/viewtopic.php ... trol+frame

http://forum.mikrotik.com/viewtopic.php ... me#p261934

http://forum.mikrotik.com/viewtopic.php ... trol+frame

http://forum.mikrotik.com/viewtopic.php ... trol+frame

http://forum.mikrotik.com/viewtopic.php ... trol+frame

if everyone you mentioned would give remote access to such location from AP side and also from the client ethernet side so we could have access to the client at the time when the disconnection happens and we would be allow to debug that system (reboot, install packages), then it would speed up the process.
As we are unable to reproduce such problem in lab.

uldis.
It is very easy to reproduce this problem, this explained in post 'Annoying "control frame timeout" with RB SXT'

Regards
Dzieva

if everyone you mentioned would give remote access to such location from AP side and also from the client ethernet side so we could have access to the client at the time when the disconnection happens and we would be allow to debug that system (reboot, install packages), then it would speed up the process.
As we are unable to reproduce such problem in lab.

Uldis,

I am not quite sure how you can be provided with access to the client from the Ethernet side as I am sure most of these locations are fed their only net access through the wireless interface. As I mentioned to you some of the clients I gave you access to have access available to them through a second wireless interface but not through the Ethernet interface, the other problem is that you guys are on the opposite time schedule as we are so you are accessing our network during off peak hours and disconnects rarely occur during these times.

You guys really need to get your own test network setup so you can reproduce real world conditions and problems rather than having to rely on your end users to beta test/trouble shoot software issues. I don't see how you can provide bug free reliable software without your own outdoor test network.

Chadd

No need to mention I fully agree whit what chadd mentions here.

In the next week, time given, I will see if I can find a client with the problem where I can use another second link to create a trouble free connection to the ´back´ (=ethernet port) of troubled client.
But like chadd already mentioned, that is going to be a bit of a problem, since if client would have a troublefree alternative connection I would already use that for his connection!

Or I should find a client with a stable connection that would also be setup with a second link that has problems!

I would think MT runs a network in Latvia. I would be really dissapointed if they didn't. Or maybe they do and like old sovjet style no competition allowed!

I would think MT runs a network in Latvia.

yes we do, and we don't have such problems, like Uldis said

I would think MT runs a network in Latvia.

yes we do, and we don't have such problems, like Uldis said

OK, and how many other networks around?

Yesterday made a scan on a client unit that is regurlarly disconnecting (20-30 times a day, but daytime hours)
Client unit: SXT, Tx/Rx signal -53/-57, CCQ >95%

I scan 12 AP's in the 5500-5700 range (and another 7 in 5200-5400 range).
Working freq. of this unit is 5680-10Mhz and I pick up -87 signal in 5685(10Mhz), -64 at 5640(20Mhz) and a -86 at 5700(10Mhz) to mention only the close ones.

This AP+client are running normal 802.11 while the mentioned close freq. units all run NV2 protocol.

Why would this unit disconnect so often? We already had swapped his CPE twice now, everytime the same result. So it is noting to do with the hardware. (First unit was a rb411 with R52 card in a plastic, but shielded, box. 2nd was also a SXT where 10Mhz channel stopped functioning.)

The signal of the 5685 AP is only 5Mhz away but 30dB weaker. (But they do ´touch´ eachoter in their band)
The signal of the 5640 AP is 40Mhz away but at -64 which means only 7dB weaker. But since this last one is alsoa 20Mhz band it only separates 30Mhz from troubled CPE.

Normally spoken (802.11) this would not give problems. A year ago, before TDMA was introduced in this valley it wasn't a problem! It worked fine then with the rb411 but now it is not anymore.
Abandoning NV2 on other of my AP's is not an option anymore since it does help other units to get better stability plus competition also uses TDMA which I have no control off.

normis, uldis; any comment on this?

Oh yeah, some add-on information on the post above:

Client claims he doesn't notice any disconnects, not even during regular Skype phone calls with family that sometimes can last for half an hour.....
So my feeling is (I have same reports from other clients with troubled units, they notice nothing.) that the disconnects mainly happen during idle time of stations.

Dear Normis

reading many answer your on other topics, not if you can trust what you say.

do not skip a favour when it exists.

Dzieva

yes we do, and we don't have such problems, like Uldis said

Normis,

This is what Uldis said.

As we are unable to reproduce such problem in lab.

The key word there being lab, I can't repeat it in a controlled "lab" setup either. I tested NV2 on an indoor network for a while before I started running it outdoor and I never saw disconnects on the indoor network but once I started running it outdoors then the disconnects appeared.

Thanks,
Chadd

He didn't mean a small lab on the table, our "lab" is an actual wireless network with real customers on it.

if everyone you mentioned would give remote access to such location from AP side and also from the client ethernet side so we could have access to the client at the time when the disconnection happens and we would be allow to debug that system (reboot, install packages), then it would speed up the process.
As we are unable to reproduce such problem in lab.

He didn't mean a small lab on the table, our "lab" is an actual wireless network with real customers on it.

If MT cannot reproduce such issues in their lab (with real customers)and our networks suffer from disconnects, what are we doing wrong then?

Can we ask what equipment MT is using in it's lab (from CPE to internet) I ask this question because a recent issue with a 433AH virtual AP using 4.17 + OSPF was causing ping drops but downgraded the 493ah from 4.17 to 3.30 which the 433's sector antenna's were connected to and problem solved?

n21roadie, please don't bring up such old problems. OSPF has been re-made for v5 and wireless drivers have been changed too. what was true with v4.17 and v3.30 isn't the same anymore in v5.5, did you try to upgrade all your devices to v5?

You probably think that all we do is ask to uprade, but the upgrades contain improvements and fixes, and that's why we make them

n21roadie, please don't bring up such old problems. OSPF has been re-made for v5 and wireless drivers have been changed too. what was true with v4.17 and v3.30 isn't the same anymore in v5.5, did you try to upgrade all your devices to v5?

You probably think that all we do is ask to uprade, but the upgrades contain improvements and fixes, and that's why we make them

Without full change logs it makes it difficult to determine if it is worth it to risk upgrading to the current release. I have been told in the past to upgrade to fix a problem yet the fix is not listed in the change log. So why would I upgrade if there is no fix listed in the change log?

Like it or not new bugs are introduced with the latest release all the time, so I steer clear of them until they have been out for a little while if possible.


Thanks,
Chadd

You probably think that all we do is ask to uprade, but the upgrades contain improvements and fixes, and that's why we make them

Without full change logs it makes it difficult to determine if it is worth it to risk upgrading to the current release. I have been told in the past to upgrade to fix a problem yet the fix is not listed in the change log. So why would I upgrade if there is no fix listed in the change log?

Like it or not new bugs are introduced with the latest release all the time, so I steer clear of them until they have been out for a little while if possible.


Thanks,
Chadd

normis, chadd,

You both are completely right. Hence I always upgrade in the hope issues are solved, even ones not listed in the change log, and hence yes, I cut my fingers every time again....
I try to stay at least some weeks behind with upgrades but sometimes I really need to try things that ARE mentioned in the change log.

But overall, we could do with lots more info on what has been worked on by MT development. Like these disconnects. MT wouldn't take its customers serious if they are not at least scratching themselves behind their ears and think: "What is it these guys consistently keeps nagging on about?" "We better take a deeper look into the subject, even although we can't find it in our own network."

To create an ´outdoor lab environment´ I would suggest MT sets its network up in such a way that several AP's work in very close (spectrum) vicinity of each other and have at least 25 client on each AP. If you take about 4 or 5 AP's this way all basically in ´view´ of each other, it is almost guaranteed you will have one or two CPE's start playing up.....

And if not, please show us the full setup. Maybe we are just doing something wrong.....

I re arranged some working channels of some AP's of my networks last weekend. Some units that were continuously disconnecting and had probably interference issues from far away (>15km) AP are now very stable.

BUT, now I have other units in some other AP network starting to play up again! Meaning I have to start shifting again. This time it is an AP that receives an 5Mhz different NV2 signal from an AP 15km away in an absolutely no NLOS or LOS situation (25meter high hill in-between!). It picks up that signal bounced from some buildings on the other side of the street I presume.

During the playing with this issue last weeks I get also more and more the ´feeling´ it is actually mostly my own MT AP's running NV2 creating the issues.

Reverting back to no-NV2 is not an issue since in that case foreign TDMA almost immediately starts bringing my AP's down. I have done so and than I see all CPE's in my AP register starting to disconnect regularly. Even if ´foreign´ channel usage is not in the same band as the one the AP works in.

I re arranged some working channels of some AP's of my networks last weekend. Some units that were continuously disconnecting and had probably interference issues from far away (>15km) AP are now very stable.

BUT, now I have other units in some other AP network starting to play up again! Meaning I have to start shifting again. This time it is an AP that receives an 5Mhz different NV2 signal from an AP 15km away in an absolutely no NLOS or LOS situation (25meter high hill in-between!). It picks up that signal bounced from some buildings on the other side of the street I presume.

During the playing with this issue last weeks I get also more and more the ´feeling´ it is actually mostly my own MT AP's running NV2 creating the issues.

Reverting back to no-NV2 is not an issue since in that case foreign TDMA almost immediately starts bringing my AP's down. I have done so and than I see all CPE's in my AP register starting to disconnect regularly. Even if ´foreign´ channel usage is not in the same band as the one the AP works in.

Rudy- looks like you have a ongoing battle trying to select a uncongested channel, if it was me and if distance wasn't a issue is use 24GHZ (twentyfour) http://www.stelladoradus.com/24GHz.poin ... t.link.php for backhaul or some other unlicensed band for backhaul and retain the frequency the backhaul was using ( I assume you are using 2.4/5.8 also for backhaul PtP) up with a standby AP, so others cannot use that frequency and then you should have two frequencies to use?

He didn't mean a small lab on the table, our "lab" is an actual wireless network with real customers on it.

Hmm, why do i feel like a part of this "lab" now?? :/

He didn't mean a small lab on the table, our "lab" is an actual wireless network with real customers on it.

Hmm, why do i feel like a part of this "lab" now?? :/

Rudy- looks like you have a ongoing battle trying to select a uncongested channel, if it was me and if distance wasn't a issue is use 24GHZ (twentyfour) http://www.stelladoradus.com/24GHz.poin ... t.link.php for backhaul or some other unlicensed band for backhaul and retain the frequency the backhaul was using ( I assume you are using 2.4/5.8 also for backhaul PtP) up with a standby AP, so others cannot use that frequency and then you should have two frequencies to use?

I have too many backhauls to see that as an option. Too dear. But yes, I have been playing with that idea.
On the other hand, my PtP links are all fine. I have several back-hauls criss cross the valley to reach corners others can't but they all don't have any issues (at the moment). Probably because the use of high gain (concentrated beam!) and better antenna's make them less vulnerable for the disconnection issue. And maybe NV2 handles PtP links better than PtMP.

And yes, I am re-arranging some of my networks to create more free spectrum but that is quit a process since all clients have the AP freq. locked (´freq scan list´) and thus have to be ´on-line´ to swap these as well while I don't do this during busy hours of the day.
Little by little I am getting there so we'll see. Just got some info abt v5.6 fm MT. see what they come up with.... and how it will work out.

we made a test packagage for the Nv2 disconnect issues, it has been sent to those who emailed support

we made a test packagage for the Nv2 disconnect issues, it has been sent to those who emailed support

Normis,

I Just emailed in a few support files to Uldis from the new test package.

Thanks,
Chadd

we made a test packagage for the Nv2 disconnect issues, it has been sent to those who emailed support

I will be interested to hear if this resolves the issue, if you are testing this package please post your experiences.

we made a test packagage for the Nv2 disconnect issues, it has been sent to those who emailed support

I will be interested to hear if this resolves the issue, if you are testing this package please post your experiences.

As far as I can tell the test package doesn't do anything to address the disconnects, it just gives some extra debug info in the support output files so they can track down what is going on.

we made a test packagage for the Nv2 disconnect issues, it has been sent to those who emailed support

I will be interested to hear if this resolves the issue, if you are testing this package please post your experiences.

As far as I can tell the test package doesn't do anything to address the disconnects, it just gives some extra debug info in the support output files so they can track down what is going on.

Should MT not make this test package available to others who also have disconnection issues but have not emailed support,
the more info MT can get on these issues can only speed up this matter being addressed?

is this just for nv2 disconnects?? or the no beacons also in the jam?!?!

Should MT not make this test package available to others who also have disconnection issues but have not emailed support,
the more info MT can get on these issues can only speed up this matter being addressed?

Well I have sent them over a dozen output files so far, I imagine they would have a hard time keeping up with bunches of people sending them files in. Also if there is an existing ticket history it may help them sort things out as far as what has been done in the past on that particular ticket with regards to the disconnects.

Should MT not make this test package available to others who also have disconnection issues but have not emailed support,
the more info MT can get on these issues can only speed up this matter being addressed?

Well I have sent them over a dozen output files so far, I imagine they would have a hard time keeping up with bunches of people sending them files in. Also if there is an existing ticket history it may help them sort things out as far as what has been done in the past on that particular ticket with regards to the disconnects.

Yes i agree with bunches of people sending files in but could not MT simply file these replies,

Can i ask if MT have replied with any progress after sending in over a dozen files, if MT cannot pinpoint quickly from the files already received then having more files to cross reference can only help if required, also like other wisp's i had to go back to 802.11 from NV2 on some sector AP's so i can only use NV2 on these ap's at certain periods only to use the test package, i don't want to have customers complaining?

Yes i agree with bunches of people sending files in but could not MT simply file these replies,

Can i ask if MT have replied with any progress after sending in over a dozen files, if MT cannot pinpoint quickly from the files already received then having more files to cross reference can only help if required,

Yes they have gotten back with me indicating that they are going through all the output files I sent and that they had enough files at this time. They indicated they would be getting back with me in the next few days.

also like other wisp's i had to go back to 802.11 from NV2 on some sector AP's so i can only use NV2 on these ap's at certain periods only to use the test package, i don't want to have customers complaining?

I have had the same experiences that you have, I only have NV2 running on 2 sectors on our entire network. One very small sector with 4 clients and the other is running 24 clients on it. I had it on several more towers also but ended up rolling back to Nstreme or 802.11 because of the NV2 disconnects.

I am running NV2 on some PTP links with no issues at all. I really think the disconnects are somehow noise related and if that is the case MT needs to work on hardening the protocol up a little bit to be more robust when dealing with noise. As I have said in the past if I don't have a 30db or better SNR NV2 doesn't work well at all.

NV2 works great. I have over 1000 customers on NV2 and I make sure all customer customers are -70 signal or I know they will have issues.

NV2 works great. I have over 1000 customers on NV2 and I make sure all customer customers are -70 signal or I know they will have issues.

-70 ? or not below -70 or not above -70 , how about SNR

NV2 works great. I have over 1000 customers on NV2 and I make sure all customer customers are -70 signal or I know they will have issues.

-70 ? or not below -70 or not above -70 , how about SNR

Ideal working range is -50 through -70 dbm signal. I dont tend to worry about the snr very much. The noise levels are usually -90 or worse. So if your signal is -70 and the noise is -90. So your snr would be 20db. Thats a good signal and I can pass 10mbps to 20mbps with that signal. If signal is better I can get up to 40mbps.

NV2 works great. I have over 1000 customers on NV2 and I make sure all customer customers are -70 signal or I know they will have issues.

Sorry but that doesn't really add anything to the thread, I have customers in the -50's with disconnect issues.

As you can see from the threads I posted above not all share your same success with NV2, myself included.

Your success with it may well come from your low noise floor, or possibly magic pixie dust?

Curious if you have scanned through your registration tables lately to check uptime on clients also take a look at your logs. I don't receive a lot of complaints either from people on the two sectors I have running NV2 but the disconnects are there none the less. The few complaints I do receive are mainly from gamers.

I just don't think the rest of the people complain about it. I have asked a few customers if they notice it and they said that they do but thought it was because "it is wireless internet". I don't want our customers thinking of wireless internet as being unreliable, it is bad for our industry as a whole.

But yeah other than the disconnects NV2 is really nice, good throughput and stable latency. It is just about there but not quite.


Thanks,
Chadd

NV2 works great. I have over 1000 customers on NV2 and I make sure all customer customers are -70 signal or I know they will have issues.

Sorry but that doesn't really add anything to the thread, I have customers in the -50's with disconnect issues.

As you can see from the threads I posted above not all share your same success with NV2, myself included.

Your success with it may well come from your low noise floor, or possibly magic pixie dust?

Curious if you have scanned through your registration tables lately to check uptime on clients also take a look at your logs. I don't receive a lot of complaints either from people on the two sectors I have running NV2 but the disconnects are there none the less. The few complaints I do receive are mainly from gamers.

I just don't think the rest of the people complain about it. I have asked a few customers if they notice it and they said that they do but thought it was because "it is wireless internet". I don't want our customers thinking of wireless internet as being unreliable, it is bad for our industry as a whole.

But yeah other than the disconnects NV2 is really nice, good throughput and stable latency. It is just about there but not quite.


Thanks,
Chadd

Most of my customers are line of site. I know in the 5.4 version if I use automatic data rates. That helps with the uptime. Every midnight I have a script that reconfigures every customer. So my uptime every day does reset. Maybe its because I use cavity filters so i have a very clean 2.4ghz frequency and thats why I dont get very many disconnects. Kinda like you said about the noise floor. I am just giving my experience to let you know whats all happening out there.

NV2 works great. I have over 1000 customers on NV2 and I make sure all customer customers are -70 signal or I know they will have issues.

Sorry but that doesn't really add anything to the thread, I have customers in the -50's with disconnect issues.

As you can see from the threads I posted above not all share your same success with NV2, myself included.

Your success with it may well come from your low noise floor, or possibly magic pixie dust?

Curious if you have scanned through your registration tables lately to check uptime on clients also take a look at your logs. I don't receive a lot of complaints either from people on the two sectors I have running NV2 but the disconnects are there none the less. The few complaints I do receive are mainly from gamers.

I just don't think the rest of the people complain about it. I have asked a few customers if they notice it and they said that they do but thought it was because "it is wireless internet". I don't want our customers thinking of wireless internet as being unreliable, it is bad for our industry as a whole.

But yeah other than the disconnects NV2 is really nice, good throughput and stable latency. It is just about there but not quite.


Thanks,
Chadd

Most of my customers are line of site. I know in the 5.4 version if I use automatic data rates. That helps with the uptime. Every midnight I have a script that reconfigures every customer. So my uptime every day does reset. Maybe its because I use cavity filters so i have a very clean 2.4ghz frequency and thats why I dont get very many disconnects. Kinda like you said about the noise floor. I am just giving my experience to let you know whats all happening out there.

I'm all with chadd. Same issue as he has and same customer comments.

My network is all 5Ghz though, and all my noise levels are -100 or even higher -105 to -109! Which I always found a bit strange since my whole 5ghz spectrum is filled with 802.11a/n/nv2 channels.

In the first weeks of working with 5.4 and have set all my 200+ units to nv2 I also thought it all was nice. I still think NV2 is nice but at the same time I do have issues with some clients that do regularly disconnect.
Some disconnect issues have been solved by swapping working frequencies of AP's. But as bonus I than get some other units in other AP-networks to start disconnecting. So I have to swap them etc. etc. etc.

I also had one CPE with a signal strength or around -70 both rx/tx that was in scan mode also picking up 2 other AP's some 15Mhz away with -70 to -75 signal that had at times almost every minute a disconnect. That client could not go on-line.
I swapped her antenna for a slightly better shielded (spray paint on the plastic back and side of the box) and although signals are now even 1 or 2 dBm worse (of her AP) she suffers no more disconnects!
For me this is just another proof the whole disconnection issue is interference related. Not so much real radio wave interferences, but more that the interference create a situation radio's working in NV2 mode are picking up data not mend for them.
I have the ´feeling´ some time slot info of the ´foreign´ AP is picked up by the AP/CPE with the issue and since this doesn't belong to the troubled AP/CPE network this info makes the CPE or AP disconnect the unit.

Maybe I prescribe it better in a sort of ´real world´ scenario:

Imagine you are in a field with all kinds of groups of people. You have some dedicated listeners and you are the ´speaker´(=AP). You maintain a conversation to each of your ´group members´ and at a certain moment in time you communicate to only one. Your group speak a certain language where the other groups in the field speaks all kind of other languages.
Now, while you communicate direct with one of your group members sometimes some words of these ´others´ reach your ears by accident. If this happens to be a word that also have some real meaning in your language your brain understands it and tries to figure out if this words has anything to do with the communication you maintain on that moment with one of your group members. Or your group member's brain might hear it and tries to figure the same. In both case the brain needs some time to figure what to do with it and in case where this strange word is really having some impact my conversation with my partner is disturbed for a second.
[You speak in German language about Mikrotik nv2 issue with your partner as suddenly somebody not belonging to your group, but in hearing distance, shouts in English "yeah, show me these mama's!" I'll bet any of us would choque in the conversation to hear and see where this is happening! ]
If this now happens where you (as AP) heard that praise and you stopped talking while your communications partner is someone that didn't hear any of the commotion he will be pissed off why your conversation stopped and he might bail out of the communication. The next split second you realised the scream was not for you nor has anything to do with your group of member you try to maintain the conversation to this person again....

Personally I think something similar happens now with NV2.
Although the group (AP network) agreed to speak in one language (one freq.) and we even maintain an organised protocol (your turn to speak, than he, than the chair, then she etc. and everybody ID's him or herself before he or she speaks. = NV2) this system can easily be disrupted if a guy speaking in another language, but using many similar words, that also has similar sounding name (=ID = mac address) is using similar sounding commands to regulate the time slots for communications. (I mean, the word "stop", and start" are in many languages the same so the meaning of it gets heard and understand and even reacted to amongst people that furthermore would not understand eachother.

I really think that NV2's digital frames that regulates the time slots and regulates the amount of present clients allowed to speak can pick up some similar digital packets from other networks not mend for this one. All you need it that the receiver (´ears´) of one of your units picks up some signal traces with the right data package, or part of a package, from another tdma network.
In 802.11 protocol the issue wouldn't be that severe since there are no clear commands regulating the AP-Client communications as in NV2.

So dallas, if you have 1000+ units running NV2 I would like to know some extra info:
You already told 2,4Ghz but with filters which makes the station dedicated to listen to its AP only.
But are there no other AP's in the region that happen to send with similar signals and tdma (any make) that can be picked up by one of the clients or AP? If this is not the case you are just a very lucky man. And off course your filters are proven to be a good investment. (They don't even exist for 5Ghz band, I can't find them...)

And indeed, are your registration tables really that clear? I mean, like chadd, I get no complaints from customers and I only found about the severity of the issue after studying the tables and logs for long times and since I made every disconnect trigger an e-mail alert my mail box gets about 200 messages a day!
And some of the worst units have 40 to 60 disconnect a day, but clients use Skype etc. and still found nothing strange they can't cope with.....

Also very strange, almost all disconnects disappear during night time hours....
At the same time because clients don't notice something I was thinking it happens mainly on ´idle´ units.
This last makes me thing a station that is communicating has no issue but when it stops it's kept silence for a while, or the AP stops assigning him time slots, and the station sort of disconnects. But by sending such disconnection message to AP the AP suddenly realizes the station is still there and allows the station to connect again....

Hope MT reads all this, or any will comment this....

Most of my customers are line of site. I know in the 5.4 version if I use automatic data rates. That helps with the uptime. Every midnight I have a script that reconfigures every customer. So my uptime every day does reset. Maybe its because I use cavity filters so i have a very clean 2.4ghz frequency and thats why I dont get very many disconnects. Kinda like you said about the noise floor. I am just giving my experience to let you know whats all happening out there.

Cavity filters = Band pass filters have a insertion loss of -3dB = loss of 50% of your radiated power + equal loss of receiver sensitivity, then we have reduced fade margin for customers, if the band pass filter was built into the radio card for both TX and RX then we may have a better solution, maybe card manufacturers might read posts on this forum and note there is market with NV2 issues ?

Most of my customers are line of site. I know in the 5.4 version if I use automatic data rates. That helps with the uptime. Every midnight I have a script that reconfigures every customer. So my uptime every day does reset. Maybe its because I use cavity filters so i have a very clean 2.4ghz frequency and thats why I dont get very many disconnects. Kinda like you said about the noise floor. I am just giving my experience to let you know whats all happening out there.

Cavity filters = Band pass filters have a insertion loss of -3dB = loss of 50% of your radiated power + equal loss of receiver sensitivity, then we have reduced fade margin for customers, if the band pass filter was built into the radio card for both TX and RX then we may have a better solution, maybe card manufacturers might read posts on this forum and note there is market with NV2 issues ?

Anymore the only thing that I see cavity filters helping with is collocation interference and as you mentioned there is quite a bit of insertion loss from them, it also isn't going to help you when someone decides to hop on the same frequency as you with a home router or another wisp tower a few miles away.

What we all need is wireless cards with better filter masks for channels to stop them from transmitting so far out of the selected channel, especially when you are trying to run 10Mhz channels. The bleed over on some of the cards out there is almost as bad as a standard 20Mhz channel. Ok well not quite that bad but still it is way more than 10Mhz.

I must be doing something different. I am not having very many issues. If I have a issue. I am able to fix it by using test equipment at customer end to find the reason for the issue. With everyday products coming out there is always something new that can interfere with public frequencies. I am sure everyone already knows this. Anyway, I am getting off the topic. Nv2 works but you need a good enough signal to overcome interfering products.

I am curious who out the in the mikrotik world uses a spectrum analyzer and field detectors to learn more about the frequencies that you use?

Anymore the only thing that I see cavity filters helping with is collocation interference and as you mentioned there is quite a bit of insertion loss from them, it also isn't going to help you when someone decides to hop on the same frequency as you with a home router or another wisp tower a few miles away.

What we all need is wireless cards with better filter masks for channels to stop them from transmitting so far out of the selected channel, especially when you are trying to run 10Mhz channels. The bleed over on some of the cards out there is almost as bad as a standard 20Mhz channel. Ok well not quite that bad but still it is way more than 10Mhz.

Transmitting is not the problem as i assume radio card manufacturers have to comply with regulations during TX cycle (frequency+bandwidth for each channel) however in RX mode no regulation exists and the card can now go from a TX bandwidth of say 40MHz to RX receive bandwidth of over 1GHZ (4.9 to 6.0GHZ) am i incorrect in this?

Anymore the only thing that I see cavity filters helping with is collocation interference and as you mentioned there is quite a bit of insertion loss from them, it also isn't going to help you when someone decides to hop on the same frequency as you with a home router or another wisp tower a few miles away.

What we all need is wireless cards with better filter masks for channels to stop them from transmitting so far out of the selected channel, especially when you are trying to run 10Mhz channels. The bleed over on some of the cards out there is almost as bad as a standard 20Mhz channel. Ok well not quite that bad but still it is way more than 10Mhz.

Transmitting is not the problem as i assume radio card manufacturers have to comply with regulations during TX cycle (frequency+bandwidth for each channel) however in RX mode no regulation exists and the card can now go from a TX bandwidth of say 40MHz to RX receive bandwidth of over 1GHZ (4.9 to 6.0GHZ) am i incorrect in this?

If you have access to a spectrum analyzer you need to put a wireless card on 10Mhz channel and see the ridiculous about of bleed over outside of the 10Mhz channel width. I have tested ~6 different wireless cards both N and A/B/G with ours and it really is appalling. The higher the output power the worse it is.

Anymore the only thing that I see cavity filters helping with is collocation interference and as you mentioned there is quite a bit of insertion loss from them, it also isn't going to help you when someone decides to hop on the same frequency as you with a home router or another wisp tower a few miles away.

What we all need is wireless cards with better filter masks for channels to stop them from transmitting so far out of the selected channel, especially when you are trying to run 10Mhz channels. The bleed over on some of the cards out there is almost as bad as a standard 20Mhz channel. Ok well not quite that bad but still it is way more than 10Mhz.

Transmitting is not the problem as i assume radio card manufacturers have to comply with regulations during TX cycle (frequency+bandwidth for each channel) however in RX mode no regulation exists and the card can now go from a TX bandwidth of say 40MHz to RX receive bandwidth of over 1GHZ (4.9 to 6.0GHZ) am i incorrect in this?

I can't answer this 100% but I do know when 10Mhz channels first started coming around that I read the receive was still listening on the full 20Mhz channel, I am not sure if this is true or not because I don't really know of a good way of testing it. But if the cards were listening across an entire band none of our 802.11 equipment would ever work with the amount of in and out of band noise out there.

I must be doing something different. I am not having very many issues. If I have a issue. I am able to fix it by using test equipment at customer end to find the reason for the issue. With everyday products coming out there is always something new that can interfere with public frequencies. I am sure everyone already knows this. Anyway, I am getting off the topic. Nv2 works but you need a good enough signal to overcome interfering products.

No offence meant here but if you are resetting your devices every night I am not sure how you could track issues that exist on your network. Extended uptime and logs is one of the only ways to really keep a good eye on your network and its performance/problems.

If I were resetting all my devices once a day I would assume our network was golden because I wouldn't see the disconnect patterns that are occurring.

The ap keeps track of disconnects. The aps don't reset. My client load a new config at midnight. I am able to keep track. I am not saying I don't. Have disconnects. Because I do have some. 802.11does have same issues. The best way to stop disconnects is diversity with wireless n.

I guess I a m trying to say I don't think its a protocol problem. 802.11n with n and diversity will get you what you want.

I guess I a m trying to say I don't think its a protocol problem. 802.11n with n and diversity will get you what you want.

I don't see how "disconnected-control frame timeout" can not be related to the TDMA protocol in some shape or form.

Not that it matters much though because we are both playing the guessing game. It appears that MT is taking it seriously and is working to fix it so hopefully they will get it nailed down and we can all move on in the near future.

I don't get control frame timeouts at all. Sometimes I get just disconnects.

I also am not using the latest version. Once I got nv2 working great I stopped upgrading and made sure all my customers were on that version.

I don't get control frame timeouts at all. Sometimes I get just disconnects.

If you are getting a disconnect in your AP log and you then look in the CPE log it may show the control frame timeout. Sometimes it will show control frame timeout on both ends sometimes it will show control frame timeout on one end and a disconnect on the other.

There use to be a disconnect message that said medium access timeout but I haven't seen it in my logs for a while so I am not sure if they changed it or not.

Edit: I take that back I just saw a medium-access timeout in one of the logs

I can't answer this 100% but I do know when 10Mhz channels first started coming around that I read the receive was still listening on the full 20Mhz channel, I am not sure if this is true or not because I don't really know of a good way of testing it. But if the cards were listening across an entire band none of our 802.11 equipment would ever work with the amount of in and out of band noise out there.

I asked the question about RX bandwidth http://forum.mikrotik.com/viewtopic.php?f=7&t=49835 after not getting info from card manufacturers about this ( and strange even MT did not comment on my post ????), you refer to WISP usage of a radio cards outdoors (Ap to CPE, etc) but if i am correct would this RX entire band for a domestic customer using a AP for a link indoors and the question of out of band noise be a issue, no doubt sales spin doctors would advertise any advantages of having a narrow band pass filter on the rx would mean for performance, is there a extra component(s) involved with extra cost and will it reduce rx sensitivity another big selling point,
I really do wish card manufacturers would publish these technical parameters?

Just my 2 cents on this disconnection thing..

I have been a long time complainer here when I have had some issues... I have experienced these control frame timeout disconnects before and o one important link in particular..

Although no one seems to be able to explain what the msg actually means, it has been my experience that this indicates an actual problem with your link and not ROS.

When the CCQ goes down for a split second due to interference or for whatever reason, this is one of the msg's youll get with these newer versions of ROS. Forget about the msg and just try and figure out whats wrong with your link, because it is a link problem.!

There are several possibilities..

if its a new link there could be cross polarization
faulty pigtails
faulty coax
severe sporadic interference
did you try and compare link results between the different protocols 802.11, nstreme and NV2
actually might just be RF issues, competition? same freqs? someone running to close but on a different channel bandwidth?? 10 Mhz anywhere near a 20 Mhz really hurts the 20

if your link was a long standing solid link that just started to get unstable with these msgs, check your hardware...

In my case, I had the issues for almost a couple months. Link would run great with good ccq and not bad signal levels but more than a 2 dozen times a day the link would just disconnect for a split second..

Turned out to be a faulty XR5 that I think got moisture on it.. First faulty XR5 in 5 years so I never thought to change it before..

signal levels shot up to never before seen levels on that link and shes been solid ever since.!


long story short, in my experience of 5+ years and these new disconnect msgs that ROS spits out on disconnects, its your link/hardware/RF issue, well, maybe not the famous polled timeout issue but even then I think I was getting those ones also on this link but on the client side....

Check your Stuff!

just my 2 cents

Just my 2 cents on this disconnection thing..

I have been a long time complainer here when I have had some issues... I have experienced these control frame timeout disconnects before and o one important link in particular..

Although no one seems to be able to explain what the msg actually means, it has been my experience that this indicates an actual problem with your link and not ROS.

When the CCQ goes down for a split second due to interference or for whatever reason, this is one of the msg's youll get with these newer versions of ROS. Forget about the msg and just try and figure out whats wrong with your link, because it is a link problem.!

There are several possibilities..

if its a new link there could be cross polarization
faulty pigtails
faulty coax
severe sporadic interference
did you try and compare link results between the different protocols 802.11, nstreme and NV2

if your link was a long standing solid link that just started to get unstable with these msgs, check your hardware...

In my case, I had the issues for almost a couple months. Link would run great with good ccq and not bad signal levels but more than a 2 dozen times a day the link would just disconnect for a split second..

Turned out to be a faulty XR5 that I think got moisture on it.. First faulty XR5 in 5 years so I never thought to change it before..

signal levels shot up to never before seen levels on that link and shes been solid ever since.!


long story short, in my experience of 5+ years and these new disconnect msgs that ROS spits out on disconnects, its your link/hardware/RF issue, well, maybe not the famous polled timeout issue but even then I think I was getting those ones also on this link but on the client side....

Check your Stuff!

just my 2 cents

I agree. That's what I do when I have a issue. Thanks for posting.

Check your Stuff!

just my 2 cents

That doesn't explain why switching back to Nstreme or 802.11 causes the disconnects to magically disappear. Do you think NV2 is that much more susceptible to noise?

Check your Stuff!

just my 2 cents

That doesn't explain why switching back to Nstreme or 802.11 causes the disconnects to magically disappear. Do you think NV2 is that much more susceptible to noise?

There is a lot of factors. I just play it as the problem projects come to me. I am pretty much always able to fix them by moving the antenna or something at the customers location as long as I can get a -70 signal. Having a margin of -70 signal, is suitable me my network. There is a lot of variables to consider. But rule of thumb is -70. I am sure you will have issues if it is higher than that signal. Signal change over time because of changing variables. Anyone have there input on this?

Dallas

Check your Stuff!

just my 2 cents

That doesn't explain why switching back to Nstreme or 802.11 causes the disconnects to magically disappear. Do you think NV2 is that much more susceptible to noise?

There is a lot of factors. I just play it as the problem projects come to me. I am pretty much always able to fix them by moving the antenna or something at the customers location as long as I can get a -70 signal. Having a margin of -70 signal, is suitable me my network. There is a lot of variables to consider. But rule of thumb is -70. I am sure you will have issues if it is higher than that signal. Signal change over time because of changing variables. Anyone have there input on this?

Dallas

It all depends on your noise floor and the area you are operating in really. In most of our area I can't hardly connect anyone with a signal worse that -65. But other areas and in different bands we could get away with -75, so it is all relative to your environment.

I agree. Also the fresnel zone is very important. Most people dont understand what it is and how it effects your customer. Shadowing and reflections are also issues that mimo fixes.

If -70 is the RSSI limit to use nv2 in AP, then I will immediately remove it. With 30dbm EIRP is very difficult stay in this range.

your environment it may be different. Try it out. Also it can work at worse signal but your not going to have the performance. Remember the receive sensitivity of a wireless card. Lots of cards are around -70 in order to get the data rate of 54mbps regardless of the protocol you use.

You could force your card to use lower data rates. But that defeats the purpose.

also remember that when you buy a card each data rate has a different power. I dont know why they dont make all data rates all same power. Then we get optimal 1 watt eirp. Most of the time most users are only using less than 600mw and dont know it.

Dallas....I see you talk a lot about a -70 signal. What is your noise floor? I have heard in the past to have a better then 20 snr. Some of my repeaters have noise floor of -100 give or take a few. So I can have a -75 signal with a snr of 25. Just trying to gauge what I should go be more.

Thanks

Here is my experience with NV2 disconnects, had four sectors working great with NV2 with two PTP grids working OK below the sectors but I put on a extra 2 more PTP’s grids and then NV2 disconnects but here is the strange bit even when I powered down both of the 2 extra links – still NV2 disconnects had to use on two sectors NV2 and two on 802.11, my guess is - physical layout on the mast the mesh of the grids is probably reflecting signal back onto the AP’s from other AP’s or PTP’s, the two sectors now working on NV2 have no disconnections and signal from CPE’s is -64 to -83dB and snr 17 to 34dB, for me mounting a physical barrier around the AP’s to reduce the co-location interference without impeding on the AP 90hor X 10vert RX/TX radiation pattern will be a challenge and see if my disconnects continue after that modification

Here is my experience with NV2 disconnects, had four sectors working great with NV2 with two PTP grids working OK below the sectors but I put on a extra 2 more PTP’s grids and then NV2 disconnects but here is the strange bit even when I powered down both of the 2 extra links – still NV2 disconnects had to use on two sectors NV2 and two on 802.11, my guess is - physical layout on the mast the mesh of the grids is probably reflecting signal back onto the AP’s from other AP’s or PTP’s, the two sectors now working on NV2 have no disconnections and signal from CPE’s is -64 to -83dB and snr 17 to 34dB, for me mounting a physical barrier around the AP’s to reduce the co-location interference without impeding on the AP 90hor X 10vert RX/TX radiation pattern will be a challenge and see if my disconnects continue after that modification

Thanks for you input. I agree with you. You were creating self interference. Best way to solidly test that setup is to have a spectrum analyzer.

Ok, I have been away for some days.
Last week I upgraded some units very much troubled by the disconnect issue. Most units became stable after the upgrade to 5.6 apart from some occasional disconnects.
Went abroad on Thursday, back Sunday night. Looked at my logs this Monday morning and saw one of the SXT units that was upgraded last week to 5.6 having over 600 (!) disconnects....
And they started Sunday morning..... and stopped basically last night to start again this morning around 9am. From about 11AM this morning the unit was off-line. (Almost every 2 mins a disconnection!)
Nobody had access to that unit, nor to my network.....

Went to that client to see what is going on and to do some spectrum scan and ask if they noticed anything lately on their connection... "No, the internet is fine and we made several skype calls over the weekend without a single problem of disconnect..."
The rest of my 35 clients on that rb800 AP are stable up for some days, no problems with them.

Anyway, logged into the SXT through local Ethernet and found the unit was desperately trying to connect to AP since this morning but every attempt resulted in a disconnect and it then took many minutes before the log showed a new connection attempt. This while the AP's freq. was in the ´freq. scan´ list.

Made a wireless scan and found in the 10Mhz band nearest other AP was 20Mhz down from the working freq. of this clients AP at -83dBm. Which means 10Mhz channel separation between the channel edges. Marginal, but ok, other units haven't got an issue with that...
Did a scan in the 20Mhz band and found one ´other´(not mine) AP 15Mhz away with -72dBm and one other AP with the same 15Mhz distance at -66dBm!. This would mean that the channel band limits of my SXT's AP and these other´ units would ´touch´ each-other...
Signals when this SXT is connected to its AP are Tx/Rx -67/-71 (read in CPE)

I found that on this SXT both TX/RX chains were enabled while the unit is actually only associating to an AP transmitting in the vertical pol. (All other 15 or so SXT's of that AP's client network have the Tx CH0 disabled.)
This SXT is fit vertically with its normal connection like all others.
I disabled the TX CH0 and immediately the unit associated to the AP again and stayed connected to it for 10-15 mins until I enabled the TX CH0 again. Immediately the unit started to disconnect again.
Disabled TX CH0 and unit connected and stayed connected, enabled TX-CH0 and unit started to disconnect again.....
So having all chains enabled where only the one in need (CH1 in this case since this is the V-pol) is used is definitely not something to do! (In contrary of MT advice...)

After waiting for another 15 mins to see SXT stabilized now with TX-CH0 disabled I left for home.
Late this evening took another look to see the unit started to disconnected again regularly (10-20mins time spacing) after 2 hours of peace!

So, my conclusion is now that 5.6 is still not bringing the solution to the disconnection issue....
(It must be the adjacent 20Mhz channels that is `pushing` their data into the receiver of my SXT, Interference!)
(Foreign AP is probably Airmax system while second -66dBm is normal 802.11a unit of mine.)
(All my NV2 networks have encryption enabled, so that should create an extra obstacle for ´digital data interference´as I would call it.)

While writing this report in the middle of the night the SXT is stable connected for over an hour so I can't make a supout.rif for MT since this has to be done immediately after a disconnect. Something for tomorrow!

Conclusion is reasonable. To fix my issues, I remove the interference or hide from it. No more disconnects.

Conclusion is reasonable. To fix my issues, I remove the interference or hide from it. No more disconnects.

Your fix is not a cure. You just avoid scenarios that give problems where that wans't the case in the pre ´tdma´ era. It would be better if MT found a cure.
In an environment with as many as 6 competitors all using the same 200Mhz wide band (I count almost 30 channels in use. 10, 20 and some 40Mhz mimo!) the only way to make use of it is to have a sturdy protocol. If UBNT can do it I don't understand why MT can't?

If you are in the desert on your own you have no issue. But unlike the real world, wifi spectrum ´deserts´ are becoming rare. In some years everywhere in the world 5Ghz is going to be used like 2,4Ghz is now. For any WISP that tries to run a business in these free bands it is going to be a nightmare if his hardware can't cope to all the interferences. MT has to do a better job or loose its market in Wifi in the end.....

The solution you are looking for can only be fixed by a radio card feature. Intel is making a card that can recieve your signal and 2 different interferences and remove the interference 100%. There is 3 different methods of removing interference. It recieves then all at the same time. It compares the ways and picks out just yours and listens to it. I will do more research on that later on if you want me too. Via software you can not avoid all the interference. If your competitor is using 100% of the fequency, thats it your not going to pass traffic if there signal is stronger and on same channel. Unless you get the intel card. This card is not complete for us to even use yet. Ubnt uses small antennas and very close range. This is a legit way to tone down the interference so your signal is stronger going back to the ap. Thus not having a issue. If you did this with mikrotik it would work also.

The solution you are looking for can only be fixed by a radio card feature. Intel is making a card that can receive your signal and 2 different interferences and remove the interference 100%. There is 3 different methods of removing interference. It receives then all at the same time. It compares the ways and picks out just yours and listens to it. I will do more research on that later on if you want me too.

hmm, I would like to know more about this although it all sounds a bit weird to me... "2 different interferences"? I'm not sure what you mean here. Did you mean "2 different type of interferencies"? (see than further down this post). If you have any links with info I would be happy to read these.

Via software you can not avoid all the interference. If your competitor is using 100% of the frequency, that's it your not going to pass traffic if there signal is stronger and on same channel.

The issue here is that even channels 5, 10 up to 40Mhz away from your AP's working frequency interferes with that AP or its clients. This problem actually started to be a problem after the introduction of NV2 or TDMA. It is already explained elsewhere that the TDMA protocol is actually more ´aggressive´ than plain 802.11. This together with a possible higher sensitivity with new hardware or less ´hardness´ of the protocol against this interferences is imho the issue. This can be dealed with hardware and/or hardware drivers, which is in fact the ´software´.

Ubnt uses small antennas and very close range. This is a legit way to tone down the interference so your signal is stronger going back to the ap. Thus not having a issue. If you did this with mikrotik it would work also.

Ubnt can be used in same ranges as I use my MT stuff. Actually, in my region the competition has in general to bridge bigger distance than I have. At the same time, my network is build with ´over-link-budget´ antenna's anyway because I am well aware that the higher gain the antenna, and the more it is focussed to its AP, the better the signals from counter part is received and the higher the resistance is against interferences from nearby radio's ("nearby" in both distance as in freq. range). It also sort of ´shields´ the receiver from ´foreign´signals coming from other directions than where the associated AP is to be found.
Hence the discussion we had on some other topics about the need of good shielded directional antenna's for client units with the high as possible gains. It is better to have a good antenna and tune down the radio because it is overpowering the other end's receiver than save some bucks on the antenna and make the radio work hard just to reach the 'other side'.

I already had changed some ´troubled´ (many disconnects in NV2 network) CPE by just a CPE that was shielded better off against ´off-centre´ signal penetration and it cured some of the troubled sites.

But just the plain effect that units that worked fine in 802.11 mode now are beeing ´pushed´ out of the spectrum because some distant AP is working with TDMA is something MT still needs to do some homework for....

Imho we have two sorts of interferences.
1. The old fashioned stile one. A receiver listening on a certain frequency also receives signals from other frequencies and the radio wave now entering the receiver becomes a combined radio wave with a modulation and frequency and strength varying to such extend the receiver actually can't ´hear´ the info carried by the radio wave any longer in clear.
2. Data layer interference. A receiver picks up traces of radio waves from AP (or in case of AP, from CPE not belonging to its CPE network). These radio waves would normally only increase the noise level in the AP and that will than be ignored by the internal data processor since the main signal from its AP is much stronger.
But now these ´weaker´ radio wave could actually carry TDMA data that in parts can be understood by the data processor.
For instance, in TDMA CPE gets assigned a time slot to speak and listen with AP. If he is in idle mode waiting for its turn, it can well be that at that moment a trace of another AP reaches the receiver. If this now happens to carry some date (part of the TDMA protocol) that can be ´understood´ by this CPE it might react to it. This data can be anything that is part of the protocol and can make the CPE disconnect, or change its slots timing. Result in both cases is a short disconnect followed by an immediate connection because off course the main ´mother´-AP is still there sending its commands to this CPE with even higher signal strength than the ´foreign´ intruding signal.
I made some other example in this topic: http://forum.mikrotik.com/viewtopic.php ... 38#p272938

The solution you are looking for can only be fixed by a radio card feature. Intel is making a card that can recieve your signal and 2 different interferences and remove the interference 100%. There is 3 different methods of removing interference. It recieves then all at the same time. It compares the ways and picks out just yours and listens to it. I will do more research on that later on if you want me too. Via software you can not avoid all the interference. If your competitor is using 100% of the fequency, thats it your not going to pass traffic if there signal is stronger and on same channel. Unless you get the intel card. This card is not complete for us to even use yet. Ubnt uses small antennas and very close range. This is a legit way to tone down the interference so your signal is stronger going back to the ap. Thus not having a issue. If you did this with mikrotik it would work also.

As I mentioned in another thread a while back I replaced one of my troubled MT sectors and all the clients with an UBNT M2. Same channel same channel width, Airmax enabled and I haven't had a single disconnect on that sector "other than power outage" since I made the move from MT on it. The AP is in the same location as the MT AP was the clients are in the exact same locations as the MT clients were. All my MT AP's and Clients are in metal enclosures so they should have an advantage over the plastic cases of the UBNT stuff.

So whether the problem is interference or not there is something going on with MT and NV2 that UBNT's Airmax isn't having issues with.

Thanks,
Chadd

Conclusion is reasonable. To fix my issues, I remove the interference or hide from it. No more disconnects.

I thought you didn't have disconnect problems to begin with?

I have a lot of customers there will always be some customers. I can fix any customer that calls in if they have a issue. There hasn't been one I couldn't fix. I use tools to tell me what the issue is.

SISO system is not a very good system. I am moving to a new system that is MIMO/NV2. Doing this will help remove the flaws of the old style wireless. Diversity with MIMO will also help with the remote interferences that you maybe facing. I got PTMP systems with nv2 and most of the customers are 5-9 miles out. They are working well as long as there isnt interference. I think there is not a issue with nv2 but with the major flaw of SISO systems. But with the SiSO sytems. There is ways to hide from the interference. Traces it with a spectrum analyzer the move the equipment. Thats not a great solution but thats why we have MIMO and the diversity to solve these issues.

SISO system is not a very good system. I am moving to a new system that is MIMO/NV2. Doing this will help remove the flaws of the old style wireless. Diversity with MIMO will also help with the remote interferences that you maybe facing. I got PTMP systems with nv2 and most of the customers are 5-9 miles out. They are working well as long as there isnt interference. I think there is not a issue with nv2 but with the major flaw of SISO systems. But with the SiSO sytems. There is ways to hide from the interference. Traces it with a spectrum analyzer the move the equipment. Thats not a great solution but thats why we have MIMO and the diversity to solve these issues.

As several of us have repeated over and over and over, you can change back to Nstreme or 802.11 and the disconnects go away. The problem is also present on MIMO NV2 links so that shoots the MIMO theory out of the water.

So yes there is a problem with NV2 and if it can't deal with interference it has no place in an industry that relies on unlicensed spectrum to operate. You can't avoid interference 100% of the time it is a part of our business like it or not, if you claim that you can avoid interference 100% you are making some pretty outrageous claims.

SISO system is not a very good system. I am moving to a new system that is MIMO/NV2. Doing this will help remove the flaws of the old style wireless. Diversity with MIMO will also help with the remote interferences that you maybe facing. I got PTMP systems with nv2 and most of the customers are 5-9 miles out. They are working well as long as there isnt interference. I think there is not a issue with nv2 but with the major flaw of SISO systems. But with the SiSO systems. There is ways to hide from the interference. Traces it with a spectrum analyser the move the equipment. That's not a great solution but that's why we have MIMO and the diversity to solve these issues.

As several of us have repeated over and over and over, you can change back to Nstreme or 802.11 and the disconnects go away. The problem is also present on MIMO NV2 links so that shoots the MIMO theory out of the water.

So yes there is a problem with NV2 and if it can't deal with interference it has no place in an industry that relies on unlicensed spectrum to operate. You can't avoid interference 100% of the time it is a part of our business like it or not, if you claim that you can avoid interference 100% you are making some pretty outrageous claims.

chadd, I fully second this!
Even within MT network the issue hardly exists with normal 802.11 or SISO as dallas calls it.
The more we play and test this NV2 of MT the more I only see proof there is definitely something wrong with their protocol.
The fact that v5.6 is available for some of us charlie testers some weeks now but still not made available to all and we hardly hear any more news from MT makes me think they are really ´taken´ by this issue.
(This is my positive intake. I don't want to consider a negative approach .... yet.)

I believe that MT this working on this problem.
I also already have sent a supout file with this issue.

Hope they help us.

Regards,
Dzieva

I spent 15 minutes going through aps. I found the only customers that had disconnects were ones that had -70 signal. I don't know if Mikrotik sees that as a problem.

Hey Mikrotik,

Are you able to make NV2 work stable with signals above -70?

I do think the speed and reliability of NV2 at -70 signal is such an improvement above nstreme or 802.11. I truely think if wisps are trying to make wireless work above -70 signal. That is a mistake. Because the environment fluctuates so much. We need at least -70 signal as a margin so if a blizzard comes through the customer still stays connected.

I am thinking about upgrading to 5.6v of routeros. My aps are 5.4 and clients are 5.0rc10. I will upgrade clients but not anytime soon because they are working so well.

Are you able to make NV2 work stable with signals above -70?

I hope with "above" you mean "bigger" or "worse"? Like in -72, -80 etc?

I truely think if wisps are trying to make wireless work above -70 signal. That is a mistake. Because the environment fluctuates so much. We need at least -70 signal as a margin so if a blizzard comes through the customer still stays connected.

This comment shows you don't have a ´real' feeling on what WISPs in general are facing but you more only compare it to your situation.
Most WISP's HAVE TO deal with any signal up to -80/-85 or even -90 at times. If the world would be that perfect that you could always place you customer in the -60 - -70 range than Wifi would hardly be a challenge.

I am working in a relative short ranged environment and already need about 12 AP's to reach all corners of the valley. Some parts are heavily populated with clients. No matter how hard I would like it to have all my client's in the optimum range, I can't avoid some AP's have to serve clients that both are very close and with very good signals (up -40!) while at the same time some other clients of same network having problems just to stay on the good side of -80 which I consider as being the weakest signal I can use for a reasonable stable connection rate with the CPE.

I am thinking about upgrading to 5.6v of routeros. My aps are 5.4 and clients are 5.0rc10. I will upgrade clients but not any time soon because they are working so well.

I am using 5.6 on some units for 2 weeks now and now after the major release am in the process of updating my whole network.

Although the change log not mentions anything about wireless MT confirmed me by email some improvements compared to 5.5 are made and they now also have a better more extended debug system for the supout.rif.

Also, with 5,6 my network did indeed see some of the troubled units become more stable.

If you have other aps that are on the same channel and your signal that you recieve is -40. They will interfere with your ap no matter how good the software is. Your only option would be to use gps sync. Your ap and their ap would have to both use that feature. Then you get no interference.

If you have other aps that are on the same channel and your signal that you recieve is -40. They will interfere with your ap no matter how good the software is. Your only option would be to use gps sync. Your ap and their ap would have to both use that feature. Then you get no interference.

Off course I have no AP's receiving other AP's in the same freq. with signals of -40! Where did you read that?

I believe it was 5.2 I was on and I did not have any aps lockup. But since 5.4 and 5.6. I have random ap lockups across my network. Is anyone else seeing this problem? I uploaded 2 aps supouts to mikrotik just now.

I believe it was 5.2 I was on and I did not have any aps lockup. But since 5.4 and 5.6. I have random ap lockups across my network. Is anyone else seeing this problem? I uploaded 2 aps supouts to mikrotik just now.

Still having disconnects but no AP lockups.

I believe it was 5.2 I was on and I did not have any aps lockup. But since 5.4 and 5.6. I have random ap lockups across my network. Is anyone else seeing this problem? I uploaded 2 aps supouts to mikrotik just now.

you talk about lock ups in the forum, but you have not yet contacted support. please send more info to support. give us remote access.

I sent a support file to your support last Friday from control frame timeout and haven't heard a thing back about it. Ticket number 2011081266000417 Would really love to start using the NV2 but kinda hard when radios keep disconnecting.

Hi MT team,

Is Ticket#2011080966000281 fixed in next release?

"Chain 1" disabled resolve this issue, but rate is only 150Mbps/150Mbps.

Any updates on this from the MT guys?

Thanks,
Chadd