Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3 GHz Nodes: API reporting wrong channel and freq. #116

Closed
FletchFFletch9 opened this issue May 31, 2021 · 6 comments
Closed

3 GHz Nodes: API reporting wrong channel and freq. #116

FletchFFletch9 opened this issue May 31, 2021 · 6 comments
Labels
bug Something isn't working

Comments

@FletchFFletch9
Copy link

FletchFFletch9 commented May 31, 2021

When polling a 3GHz node it returns that it is using channel 3400 and freq 5.400 GHz. The channel (in this case) should be 80 and the freq should be 3.400 GHz.

Robert
KC6RKG

http://w6jpl-rm3-pleasantspk-p2p-jpl:8080/cgi-bin/sysinfo.json?link_info=1

{
"lon": "-117.623617",
"sysinfo": {
"uptime": "6 days, 17:16:34",
"loads": [
0.27000000000000002,
0.23000000000000001,
0.23999999999999999
]
},
"interfaces": [
{
"mac": "68:72:51:85:4E:EB",
"name": "eth0.2",
"ip": "10.133.78.235"
},
{
"mac": "68:72:51:84:4E:EB",
"name": "wlan0",
"ip": "10.132.78.235"
},
{
"mac": "68:72:51:85:4E:EB",
"name": "br-lan",
"ip": "10.34.119.89"
},
{
"name": "tunl0",
"mac": "00:00:00:00"
},
{
"name": "eth0",
"mac": "68:72:51:85:4E:EB"
},
{
"name": "eth0.1",
"mac": "68:72:51:85:4E:EB"
}
],
"api_version": "1.8",
"lat": "33.797861",
"meshrf": {
"ssid": "AREDN-10-v3",
"channel": "3400",
"status": "on",
"freq": "5.400 GHz",
"chanbw": "10"
},
"tunnels": {
"active_tunnel_count": "0",
"tunnel_installed": false
},
"link_info": {
"10.8.221.154": {
"neighborLinkQuality": 1,
"noise": -95,
"linkQuality": 0.92100000000000004,
"linkType": "RF",
"hostname": "KC6RKG-NG3-SE5-SM33-RKG2PP.local.mesh",
"tx_rate": 78,
"olsrInterface": "wlan0",
"rx_rate": 52,
"signal": -74
},
"10.15.32.134": {
"neighborLinkQuality": 1,
"linkQuality": 1,
"hostname": "AE6XE-PleasantsPk-RM3.local.mesh",
"olsrInterface": "eth0.2",
"linkType": "DTD"
},
"10.146.164.14": {
"neighborLinkQuality": 1,
"noise": -95,
"linkQuality": 0.75700000000000001,
"linkType": "RF",
"hostname": "WM3SH-RKM3D-SE5-SM15-CH2PP.local.mesh",
"tx_rate": 78,
"olsrInterface": "wlan0",
"rx_rate": 78,
"signal": -66
},
"10.253.213.11": {
"neighborLinkQuality": 1,
"linkQuality": 1,
"hostname": "KE6BXT-PleasantsPk-M5R-NE.local.mesh",
"olsrInterface": "eth0.2",
"linkType": "DTD"
},
"10.14.231.218": {
"neighborLinkQuality": 1,
"noise": -95,
"linkQuality": 0.36399999999999999,
"linkType": "RF",
"hostname": "W6GSW-NBM3-14-231-218.local.mesh",
"tx_rate": 26,
"olsrInterface": "wlan0",
"rx_rate": 19.5,
"signal": -81
},
"10.36.198.231": {
"neighborLinkQuality": 1,
"noise": -95,
"linkQuality": 1,
"linkType": "RF",
"hostname": "KA6ECT-RM3-Pleasants-36-198-231.local.mesh",
"tx_rate": 117,
"olsrInterface": "wlan0",
"rx_rate": 104,
"signal": -69
},
"10.175.175.46": {
"neighborLinkQuality": 1,
"linkQuality": 1,
"hostname": "AE6XE-PleasantsPk-P2P-LagunaWoods.local.mesh",
"olsrInterface": "eth0.2",
"linkType": "DTD"
},
"10.146.163.160": {
"neighborLinkQuality": 1,
"noise": -95,
"linkQuality": 0.61899999999999999,
"linkType": "RF",
"hostname": "W6JPL-RM3-180R6.local.mesh",
"tx_rate": 78,
"olsrInterface": "wlan0",
"rx_rate": 78,
"signal": -68
},
"10.41.100.204": {
"neighborLinkQuality": 1,
"linkQuality": 1,
"hostname": "AE6XE-PleasantsPk-P2P-Yucaipa.local.mesh",
"olsrInterface": "eth0.2",
"linkType": "DTD"
},
"10.106.250.239": {
"neighborLinkQuality": 1,
"noise": -95,
"linkQuality": 0.72499999999999998,
"linkType": "RF",
"hostname": "KF6RTA-RM3-QTH.local.mesh",
"tx_rate": 117,
"olsrInterface": "wlan0",
"rx_rate": 104,
"signal": -71
},
"10.127.114.40": {
"neighborLinkQuality": 1,
"linkQuality": 1,
"hostname": "AE6XE-PleasantsPk-RM2.local.mesh",
"olsrInterface": "eth0.2",
"linkType": "DTD"
},
"10.171.187.130": {
"neighborLinkQuality": 1,
"linkQuality": 1,
"hostname": "KE6BXT-PleasantsPk-M5R-SW.local.mesh",
"olsrInterface": "eth0.2",
"linkType": "DTD"
}
},
"grid_square": "",
"node": "W6JPL-RM3-PleasantsPk-p2p-JPL",
"node_details": {
"description": "Pleasants Peak, Orange County, CA",
"model": "Ubiquiti Rocket M",
"mesh_gateway": "0",
"board_id": "0xe1c3",
"firmware_mfg": "AREDN",
"firmware_version": "3.21.4.0"
}
}

@ae6xe
Copy link
Contributor

ae6xe commented May 31, 2021

There aren't any generally published or accepted channel #s for the 3GHz space. There's no unlicensed or other usage in this space to be assigned. Consequently, the AREDN UI does not show channel numbers, only freq. The hardware chip set and embedded linux OS only have awareness of 5GHz. The device has a -2GHz hardware down converter. Consequently, any data that the firmware sees is 5GHz. There's also an issue with 5GHz signals getting through and showing up with co-located nodes or other strong signals, so it is not always definitive when a signal is received, if it is really a 3GHz or 5GHz signal.

I agree, if this api is returning a 5GHz freq, it should return a 3GHz freq instead. However, for the channel, this is undefined, so not clear how to handle in the api. options are to pass back A) "N/A"; B) the 5GHz (+2GHz) channel; C) make up our own channel #s.

@FletchFFletch9
Copy link
Author

FletchFFletch9 commented May 31, 2021

The OC Mesh website seems to think there are channels... even if not official. Who came up with those? Anyway, it doesn't really matter to me if there are channel numbers. I was just looking for a consistent way to the frequency band and thought it was odd that the freq gave the wrong number. https://sites.google.com/site/orangecountymeshorganization/bands-channels-and-frequencies

@ae6xe
Copy link
Contributor

ae6xe commented Jun 1, 2021

Feedback on the 3 options to handle the channel number in the api would be helpful. For lack of an AREDN stance on what to do for 3GHz channels, 3rd party sites are making their own determination. This issue is also applicable for the 900MHz devices, which are 2GHz chipsets, also with hardware down converter. Chips in use are 2GHZ and 5GHz capable. There are no chipsets native to 900MHz and 3GHz as unlicensed part 15 does not support these bands to date.

@FletchFFletch9
Copy link
Author

Making up your own channel numbers 5MHz apart would make it consistent with the other bands.

@ae6xe ae6xe added the bug Something isn't working label Sep 10, 2021
@ae6xe
Copy link
Contributor

ae6xe commented Sep 10, 2021

Marked as a bug because channel shows as 3GHz freq and Freq shows as 5GHz in the api. Assigning channel numbers in 3GHz needs further community discussion - would be an enhancement as original design was not to use channel numbers, and we should split out to a separate request.

@dman776 dman776 changed the title 3 GHz Nodes reporting wrong channel and freq. 3 GHz Nodes: API reporting wrong channel and freq. Nov 6, 2021
@Orv
Copy link

Orv commented Apr 28, 2022

This issue can be closed, as it's fixed in the recent nightly builds.

@dman776 dman776 closed this as completed Apr 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants