You are here

900 MHz

9 posts / 0 new
Last post
900 MHz

I haven't seen anything on 900 MHz nodes recently, so I thought I'd start a new thread.

I setup a M900, with AIROS 5.6 to see what the interference looked like.
It looked pretty good.  Noise floor was between -100 and -96 dbm.
I didn't see any strong signals in the band.
So I setup an AP with a 10 MHZ bandwidth and 28 dbm.  (nothing is connected now)
I started to notice some odd behavior from my home automation system which is a "Smartthings" system from Samsung.
I have a dozen sensors and devices and some of them would stop working for a while.

I looked up Z-wave (one of the Smarthings modes) and discovered in the US, it uses 908.42 MHz with a 300 KHz bandwidth.  It also can use 916 MHz with a 400 KHz bandwidth.

These devices can be very low duty cycle to preserve battery life.  That is likely why they don't show up on a frequency scan.

I moved the frequency to deconflict with 908.42.  We'll see what it does.


AE6XE's picture
N8JJ,   These 802.11 devices

N8JJ,   These 802.11 devices don't have a way of measuring an absolute signal value.   I don't know the algorytm in AirOS, but it will be very similiar given how the chip works--this is an 802.11 specification issue.     AREDN basically measures the strength of ambient noise when the channel is clear for a brief period of time.  Whatever this measured value is becomes the noise floor value-- a table look up  based on the band/channel.  This is, for example, -95dBm in 5Ghz, the therectical hardware device noise in 20Mhz.   

Received signals are then measured and given a value relative above this noise floor.   (In AREDN/OpenWRT/LEDE) the determined noise floor is not compensated for 10Mhz or 5Mhz channel widths, which should be -3dB each time the bandwidth is cut in half.    We don't have a way to compare or know if one location has more noise than the other, without using a device that can measure absolute value.  All locations would show as the same noise floor level on an 802.11 device.

The noise floor value will jump up/down when there are interfening signals, QRM, as a way to block out the interfering signal.   If a threshold count of beacons can't be sent out due to the channel continuously detected as busy, then interference is assumed and the noise floor is stepped up to block out the interfering signal.  


nc8q's picture
Node makes itself deaf

"If a threshold count of beacons can't be sent out due to the channel continuously detected as busy, then interference is assumed and the noise floor is stepped up to block out the interfering signal."

So, if the channel is too busy for a node to transmit a 'threshold count of beacons', it makes itself deafer. Can it reach a virtual noise floor of -75 dB ?

Hmmm, this could be why our high-profile node seems deaf. It seems to only hear stations with > 20 dB over noise floor. This high profile node has 10 stations in 'iw wlan0 station dump'. The 5 strongest neighbors have viable links, the 5 weakest do not. The 5 weaker, S/N 15-24 dB, see, more or less, LQ NLQ 100% 0%.

If a node 'automagically' makes itself deafer, it makes itself an alligator! Ears smaller than mouth. :-| ----- Off topic:

What is the threshold count of beacons? What is the byte count or length of transmission time of beacons at 10 MHz bandwidth?

Still seeking a guess as to how many 10 MHz bandwidth nodes does it take to require 100% of available channel time to conduct maintenance (beacons and broadcasts). 30, 100 ?

History indicates that the gurus will avoid a definitive statement on this topic. ;-)


AE6XE's picture


Here's the statement in the code that I'm referring to:

1)  if sending out the beacons is stuck, then trigger to recalibrate the noise floor:
         * If beacons are stuck, the most likely cause is interference.
         * Triggering a noise floor calibration at this point helps the
         * hardware adapt to a noisy environment much faster.
         * To ensure that we recover from stuck beacons quickly, let
         * the baseband update the internal NF value itself, similar to
         * what is being done after a full reset.
        if (!test_bit(NFCAL_PENDING, &caldata->cal_flags))
                ath9k_hw_start_nfcal(ah, true);
                ath9k_hw_getnf(ah, ah->curchan);

        set_bit(NFCAL_INTF, &caldata->cal_flags);

2)  When we are recalibrating,  if the beacon is stuck, allow the noise floor to increase
                         * Normally we limit the average noise floor by the
                         * hardware specific maximum here. However if we have
                         * encountered stuck beacons because of interference,
                         * we bypass this limit here in order to better deal
                         * with our environment.
                        if (!test_bit(NFCAL_INTF, &cal->cal_flags))
                                h[i].privNF = limit->max;

3)  I haven't found a limit on how high the NF value can raise, but this code says at least to -50. 
         * We timed out waiting for the noisefloor to load, probably due to an
         * in-progress rx. Simply return here and allow the load plenty of time
         * to complete before the next calibration interval.  We need to avoid
         * trying to load -50 (which happens below) while the previous load is
         * still in progress as this can cause rx deafness. Instead by returning
         * here, the baseband nf cal will just be capped by our present
         * noisefloor until the next calibration timer.


AE6XE's picture
"History indicates that the

"History indicates that the gurus will avoid a definitive statement on this topic. ;-)"

This might be more accurately stated as "gurus may not decide to spend hours researching every question in the forum".   As volunteers, we have to have interest and then choose to spend our free time on the issue.   Consequently, motivation can make a big difference.

In this case,  Conrad worked through the math for a 2Ghz @ 5Mhz channel back when the effort to change beacons from 10/sec down to 2/sec.   I don't recall if the results were posted in the forum.  If not, I'll defer to Conrad to post his work.     I prefer to avoid re-inventing the wheel :).


I only looked at the SSID

I only looked at the SSID Beacons, I didn't calculate the beacon packets from the routing daemon because of all the variables involved. was the chart I used.

Noting that with a refresh rate of ~2/sec (its actually once every 512ms) you can multiple the number of nodes by 5 (so if you have 10 nodes you would look at the 2 AP's row)

Smaller bandwidth of 10Mhz use the "SSID's per  channel of 2 and 5MHz use the 4 colum for conservative numbers and this will be a very conservative RF avaliability number.

The chart was what made it obvious though that we needed to have a less frequent SSID beacon after the subject was brought up in a ticket IIRC

Realistically however its rare that most nodes in a mesh hear each other and as such meshes can get bigger and bigger, that said a 2GHz mesh does need to be segmented.

The recommended design concept has been 2GHz feeds a small area (say part of a city)  5.8 GHz then feeds that data up to higher level nodes (Mountains/tall buildings/towers/etc) that then link to each other on 3.4GHz (creating a backbone)    in this manner none of the links ever really over saturate as they are small cells for the user access layer where contention is highest  and  the backbone is all well designed and linked and also uses the faster speed of 6Mb/s @20Mhz instead of the 1Mb/s used on 2GHz @20Mhz (factor of 6 speed increase for beacons)


nc8q's picture
threshold count of beacons can't be sent out

If a "threshold count of beacons CAN be sent out due to the channel sufficiently detected as idle", does the node automatically step the noise floor back down?

AE6XE's picture
Yes, here's a section of code

Yes, here's a section of code that is restoring noise floor.   There's another section, can't find it for the moment, but as I recall, it steps up the noise flow, and down, by +-10 to adjust to the environment.
         * If the noise floor seems normal for all chains, assume that
         * there is no significant interference in the environment anymore.
         * Re-enable the enforcement of the NF maximum again.
        if (!high_nf_mid)
                clear_bit(NFCAL_INTF, &cal->cal_flags);


N6FOG's picture
902-928 QRM

I took a look at the 902-928 spectrum with a SDR locally, and there's crap from one end to the other from all the Z-Wave, Zigbee, "Smart Meter" and other random devices across the band. If we are to use 900 MHZ, then I recommend it should be used in certain areas that are known to have reduced QRM, and should be used for directional or point-to-point links, not Omni/Point to Multipoint. 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer