[OpenWrt-Devel] [PATCH] ar71xx: add support for the UniFi AP Outdoor Plus

[David Hutchison]

Hello,

It's probably driven by a GPIO on the radio itself. Possibly monitor
/sys/kernel/debug/ieee80211/phy[0-9]/ath9k/regidx and
/sys/kernel/debug/ieee80211/phy[0-9]/ath9k/regval. Perhaps someone
with a datasheet might be able to tell you which register(s) it
*could* be tied to, then take Sergey's strategy and watch changes to
those registers.

* Just a thought, I could be completely wrong :) *

-- Davey

On Mon, Mar 16, 2015 at 6:37 PM, Sergey Ryazanov <ryazanov.s.a at gmail.com> wrote:
> Hello Stefan,
>
> 2015-03-16 23:36 GMT+03:00 Stefan Rompf <stefan at loplof.de>:
>> However, independant of the channel selected the ports are always set to
>> 0x00081405 (or 0x00081404 or 0x00081406 depending on the LED setting):
>>
>> BZ.v3.2.7# /tmp/io -4 -r 0x18040004
>> 18040004:  00081405
>>
>> If anyone has ideas where else to look, please share. Meanwhile let's see what
>> I can do with strace ;-)
>>
> If they built SPIoverGPIO or I2CoverGPIO or some other serial bus over
> GPIO, then you do not see any changes between channel switches. Or
> they could use some non GPIO interface to communicate with external
> filter (embedded SPI, I2C or even USB or PCI of SoC).
>
> Possibly, you could see some changes during change. Try check GPIO
> pins with oscillograph during channel change.
>
> Or you could put device in continuous scan (e.g. use STA mode and
> enter some not available SSID to put device for infinite AP search)
> and then read GPIO register state in circle. That trick does not
> reveal actual protocol, but shows GPIO lines in use, if any.
>
> --
> Sergey
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel