https://wiki.faked.org/api.php?action=feedcontributions&feedformat=atom&user=JanfakedWiki - User contributions [en]2026-05-30T22:58:10ZUser contributionsMediaWiki 1.40.0https://wiki.faked.org/index.php?title=DIY_Ambilight&diff=474DIY Ambilight2021-01-02T20:09:09Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [https://github.com/Aircoookie/WLED WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).<br />
<br />
=== WLED ===<br />
As WLED doesn't allow exporting its config (yet), here are the most important settings i changed from the stock setup:<br />
* Wifi Setup: SSID & Key already set in the image i uploaded, so nothing to change here for me, but have a look at the [https://github.com/Aircoookie/WLED/wiki WLED wiki] how to connect to a stock image.<br />
* LED Preferences: LED count = 298, Enable automatic brightness limiter = Off<br />
* Sync Interface: Force max brightness = Off (this is important so that data from Hyperion can switch the relay on if it was off)<br />
<br />
=== Hyperion ===<br />
As Hyperion.NG is not yet available as a package for OSMC, i used the excellent [https://github.com/hissingshark/hyperion-vero4k hyperion-vero4k] script to build Hyperion.NG on my Vero 4K+ (using the current master branch, not a release). This makes the initial installation a breeze and is easily reproduceable, leaving plenty of time for the more challenging part: setting Hyperion up correctly.<br />
<br />
For Hyperion, the most important settings are:<br />
* LED Hardware / LED Controller<br />
** Controller Type: udpraw<br />
** Hardware LED count: 298<br />
** Target IP: <the IP of your ESP8266><br />
** Target Port: 19446<br />
* LED Hardware / LED Layout<br />
** Top: 100<br />
** Bottom: 100 (should be the same a Top)<br />
** Left: 56<br />
** Right: 56<br />
** Gap Length: 14<br />
** Gap Position: 199 (position, not count - so it starts from 0, not 1 - and is actually the 200th LED)<br />
** Input Position: 199<br />
** Reverse Direction: On<br />
<br />
Your exact layout depends on your number of LEDs and how you attach them, but this should give you a general idea of how to configure the layout. And always remember: this layout is viewed from the front of your TV!<br />
<br />
Feel free to use a ruler or similar to measure the left and right bottom parts length on your computer screen when configuring the exact gap/input position of the layout - i know i did! ;-)<br />
<br />
As i'm running this on a Vero 4K+, i'm using the AMLogic grabber with a width and height of 100 and 56 (matching my LED layout). I have also written some short Python scripts to enable and disable the "platform capture" feature whenever Kodi wakes up or goes to sleep, so that Hyperion doesn't block WLED by sending LED commands even though Kodi is not actually in use, and the relay can switch the LEDs off.<br />
<br />
'''.kodi/userdata/wake.py'''<br />
<pre><br />
import requests<br />
<br />
hyperion_url = 'http://127.0.0.1:8090/json-rpc'<br />
hyperion_data = '{"command":"componentstate","componentstate":{"component":"GRABBER","state":true}}'<br />
requests.post(hyperion_url, hyperion_data)<br />
</pre><br />
<br />
'''.kodi/userdata/standby.py'''<br />
<pre><br />
import requests<br />
<br />
hyperion_url = 'http://127.0.0.1:8090/json-rpc'<br />
hyperion_data = '{"command":"componentstate","componentstate":{"component":"GRABBER","state":false}}'<br />
requests.post(hyperion_url, hyperion_data)<br />
</pre><br />
<br />
Yes, they're not pretty and nearly identical, but honestly: i don't care as long as they work. (PS: Yes, i know that Python can use JSON natively, but Hyperion doesn't like real JSON from Python because of the '''exact''' true/false values that are required, and Python complains if i use those exact values. So strings it is!)<br />
<br />
=== Hyperion Android Grabber ===<br />
The Hyperion Android Grabber does pretty much what its name implies: it grabs the screen output of Android and sends it to Hyperion.<br />
<br />
Configuration should be fairly simple, just make sure to point it to your Hyperion IP and port 19445, configure the same number of vertical and horizontal LEDs as in Hyperion, but one important settings is the '''priority''': set this to something like 150 (i think the default is 50), otherwise it won't trigger the output.<br />
<br />
=== Enigmalight ===<br />
Mostly working, but still not perfect. Also not that easy to even get installed. To be continued...</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=473DIY Ambilight2021-01-02T20:00:53Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [https://github.com/Aircoookie/WLED WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).<br />
<br />
=== WLED ===<br />
As WLED doesn't allow exporting its config (yet), here are the most important settings i changed from the stock setup:<br />
* Wifi Setup: SSID & Key already set in the image i uploaded, so nothing to change here for me, but have a look at the [https://github.com/Aircoookie/WLED/wiki WLED wiki] how to connect to a stock image.<br />
* LED Preferences: LED count = 298, Enable automatic brightness limiter = Off<br />
* Sync Interface: Force max brightness = Off (this is important so that data from Hyperion can switch the relay on if it was off)<br />
<br />
=== Hyperion ===<br />
As Hyperion.NG is not yet available as a package for OSMC, i used the excellent [https://github.com/hissingshark/hyperion-vero4k hyperion-vero4k] script to build Hyperion.NG on my Vero 4K+ (using the current master branch, not a release). This makes the initial installation a breeze and is easily reproduceable, leaving plenty of time for the more challenging part: setting Hyperion up correctly.<br />
<br />
For Hyperion, the most important settings are:<br />
* LED Hardware / LED Controller<br />
** Controller Type: udpraw<br />
** Hardware LED count: 298<br />
** Target IP: <the IP of your ESP8266><br />
** Target Port: 19446<br />
* LED Hardware / LED Layout<br />
** Top: 100<br />
** Bottom: 100 (should be the same a Top)<br />
** Left: 56<br />
** Right: 56<br />
** Gap Length: 14<br />
** Gap Position: 199 (position, not count - so it starts from 0, not 1 - and is actually the 200th LED)<br />
** Input Position: 199<br />
** Reverse Direction: On<br />
<br />
Your exact layout depends on your number of LEDs and how you attach them, but this should give you a general idea of how to configure the layout. And always remember: this layout is viewed from the front of your TV!<br />
<br />
Feel free to use a ruler or similar to measure the left and right bottom parts length on your computer screen when configuring the exact gap/input position of the layout - i know i did! ;-)<br />
<br />
=== Hyperion Android Grabber ===<br />
The Hyperion Android Grabber does pretty much what its name implies: it grabs the screen output of Android and sends it to Hyperion.<br />
<br />
Configuration should be fairly simple, just make sure to point it to your Hyperion IP and port 19445, configure the same number of vertical and horizontal LEDs as in Hyperion, but one important settings is the '''priority''': set this to something like 150 (i think the default is 50), otherwise it won't trigger the output.<br />
<br />
=== Enigmalight ===<br />
Mostly working, but still not perfect. Also not that easy to even get installed. To be continued...</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=472DIY Ambilight2021-01-02T19:56:40Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [https://github.com/Aircoookie/WLED WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).<br />
<br />
=== WLED ===<br />
As WLED doesn't allow exporting its config (yet), here are the most important settings i changed from the stock setup:<br />
* Wifi Setup: SSID & Key already set in the image i uploaded, so nothing to change here for me, but have a look at the [https://github.com/Aircoookie/WLED/wiki WLED wiki] how to connect to a stock image.<br />
* LED Preferences: LED count = 298, Enable automatic brightness limiter = Off<br />
* Sync Interface: Force max brightness = Off (this is important so that data from Hyperion can switch the relay on if it was off)<br />
<br />
=== Hyperion ===<br />
For Hyperion, the most important settings are:<br />
* LED Hardware / LED Controller<br />
** Controller Type: udpraw<br />
** Hardware LED count: 298<br />
** Target IP: <the IP of your ESP8266><br />
** Target Port: 19446<br />
* LED Hardware / LED Layout<br />
** Top: 100<br />
** Bottom: 100 (should be the same a Top)<br />
** Left: 56<br />
** Right: 56<br />
** Gap Length: 14<br />
** Gap Position: 199 (position, not count - so it starts from 0, not 1 - and is actually the 200th LED)<br />
** Input Position: 199<br />
** Reverse Direction: On<br />
<br />
Your exact layout depends on your number of LEDs and how you attach them, but this should give you a general idea of how to configure the layout. And always remember: this layout is viewed from the front of your TV!<br />
<br />
Feel free to use a ruler or similar to measure the left and right bottom parts length on your computer screen when configuring the exact gap/input position of the layout - i know i did! ;-)<br />
<br />
=== Hyperion Android Grabber ===<br />
The Hyperion Android Grabber does pretty much what its name implies: it grabs the screen output of Android and sends it to Hyperion.<br />
<br />
Configuration should be fairly simple, just make sure to point it to your Hyperion IP and port 19445, configure the same number of vertical and horizontal LEDs as in Hyperion, but one important settings is the '''priority''': set this to something like 150 (i think the default is 50), otherwise it won't trigger the output.<br />
<br />
=== Enigmalight ===<br />
Mostly working, but still not perfect. Also not that easy to even get installed. To be continued...</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=471DIY Ambilight2021-01-02T19:55:20Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [https://github.com/Aircoookie/WLED WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).<br />
<br />
=== WLED ===<br />
As WLED doesn't allow exporting its config (yet), here are the most important settings i changed from the stock setup:<br />
* Wifi Setup: SSID & Key already set in the image i uploaded, so nothing to change here for me, but have a look at the [https://github.com/Aircoookie/WLED/wiki WLED wiki] how to connect to a stock image.<br />
* LED Preferences: LED count = 298, Enable automatic brightness limiter = Off<br />
* Sync Interface: Force max brightness = Off (this is important so that data from Hyperion can switch the relay on if it was off)<br />
<br />
=== Hyperion ===<br />
For Hyperion, the most important settings are:<br />
* LED Hardware / LED Controller<br />
** Controller Type: udpraw<br />
** Hardware LED count: 298<br />
** Target IP: <the IP of your ESP8266><br />
** Target Port: 19446<br />
* LED Hardware / LED Layout<br />
** Top: 100<br />
** Bottom: 100 (should be the same a Top)<br />
** Left: 56<br />
** Right: 56<br />
** Gap Length: 14<br />
** Gap Position: 199 (position, not count - so it starts from 0, not 1 - and is actually the 200th LED)<br />
** Input Position: 199<br />
** Reverse Direction: On<br />
<br />
Your exact layout depends on your number of LEDs and how you attach them, but this should give you a general idea of how to configure the layout. And always remember: this layout is viewed from the front of your TV!<br />
<br />
Feel free to use a ruler or similar to measure the left and right bottom parts length on your computer screen when configuring the exact gap/input position of the layout - i know i did! ;-)<br />
<br />
=== Hyperion Android Grabber ===<br />
The Hyperion Android Grabber does pretty much what its name implies: it grabs the screen output of Android and sends it to Hyperion.<br />
<br />
Configuration should be fairly simple, just make sure to point it to your Hyperion IP and port 19445, configure the same number of vertical and horizontal LEDs as in Hyperion, but one important settings is the '''priority''': set this to something like 150 (i think the default is 50), otherwise it won't trigger the output.</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=470DIY Ambilight2021-01-02T19:49:35Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [https://github.com/Aircoookie/WLED WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).<br />
<br />
As WLED doesn't allow exporting its config (yet), here are the most important settings i changed from the stock setup:<br />
* Wifi Setup: SSID & Key already set in the image i uploaded, so nothing to change here for me, but have a look at the [https://github.com/Aircoookie/WLED/wiki WLED wiki] how to connect to a stock image.<br />
* LED Preferences: LED count = 298, Enable automatic brightness limiter = Off<br />
* Sync Interface: Force max brightness = Off (this is important so that data from Hyperion can switch the relay on if it was off)<br />
<br />
For Hyperion, the most important settings are:<br />
* LED Hardware / LED Controller<br />
** Controller Type: udpraw<br />
** Hardware LED count: 298<br />
** Target IP: <the IP of your ESP8266><br />
** Target Port: 19446<br />
* LED Hardware / LED Layout<br />
** Top: 100<br />
** Bottom: 100 (should be the same a Top)<br />
** Left: 56<br />
** Right: 56<br />
** Gap Length: 14<br />
** Gap Position: 199 (position, not count - so it starts from 0, not 1 - and is actually the 200th LED)<br />
** Input Position: 199<br />
** Reverse Direction: On<br />
<br />
Your exact layout depends on your number of LEDs and how you attach them, but this should give you a general idea of how to configure the layout. And always remember: this layout is viewed from the front of your TV!<br />
<br />
Feel free to use a ruler or similar to measure the left and right bottom parts length on your computer screen when configuring the exact gap/input position of the layout - i know i did! ;-)</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=469DIY Ambilight2021-01-02T19:49:23Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [https://github.com/Aircoookie/WLED WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).<br />
<br />
As WLED doesn't allow exporting its config (yet), here are the most important settings i changed from the stock setup:<br />
* Wifi Setup: SSID & Key already set in the image i uploaded, so nothing to change here for me, but have a look at the [https://github.com/Aircoookie/WLED/wiki WLED wiki] how to connect to a stock image.<br />
* LED Preferences: LED count = 298, Enable automatic brightness limiter = Off<br />
* Sync Interface: Force max brightness = Off (this is important so that data from Hyperion can switch the relay on if it was off)<br />
<br />
For Hyperion, the most important settings are:<br />
* LED Hardware / LED Controller<br />
** Controller Type: udpraw<br />
** Hardware LED count: 298<br />
** Target IP: <the IP of your ESP8266><br />
** Target Port: 19446<br />
* LED Hardware / LED Layout<br />
** Top: 100<br />
** Bottom: 100 (should be the same a Top)<br />
** Left: 56<br />
** Right: 56<br />
** Gap Length: 14<br />
** Gap Position: 199 (position, not count - so it starts from 0, not 1 - and is actually the 200th LED)<br />
** Input Position: 199<br />
** Reverse Direction: On<br />
<br />
Your exact layout depends on your number of LEDs and how you attach them, but this should give you a general idea of how to configure the layout. And always remember: this layout is viewed from the front of your TV!<br />
<br />
Feel free to use a ruler or similar to measure the left and right bottom parts length on your computer screen when configuring the exact gap/input position of the layout - i know i did! ;-)</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=468DIY Ambilight2021-01-02T19:49:08Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [https://github.com/Aircoookie/WLED WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).<br />
<br />
As WLED doesn't allow exporting its config (yet), here are the most important settings i changed from the stock setup:<br />
* Wifi Setup: SSID & Key already set in the image i uploaded, so nothing to change here for me, but have a look at the [https://github.com/Aircoookie/WLED/wiki WLED wiki] how to connect to a stock image.<br />
* LED Preferences: LED count = 298, Enable automatic brightness limiter = Off<br />
* Sync Interface: Force max brightness = Off (this is important so that data from Hyperion can switch the relay on if it was off)<br />
<br />
For Hyperion, the most important settings are:<br />
* LED Hardware / LED Controller<br />
** Controller Type: udpraw<br />
** Hardware LED count: 298<br />
** Target IP: <the IP of your ESP8266><br />
** Target Port: 19446<br />
* LED Hardware / LED Layout<br />
** Top: 100<br />
** Bottom: 100 (should be the same a Top)<br />
** Left: 56<br />
** Right: 56<br />
** Gap Length: 14<br />
** Gap Position: 199 (position, not count - so it starts from 0, not 1 - and is actually the 200th LED)<br />
** Input Position: 199<br />
** Reverse Direction: On<br />
<br />
Your exact layout depends on your number of LEDs and how you attach them, but this should give you a general idea of how to configure the layout. And always remember: this layout is viewed from the front of your TV!<br />
Feel free to use a ruler or similar to measure the left and right bottom parts length on your computer screen when configuring the exact gap/input position of the layout - i know i did! ;-)</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=467DIY Ambilight2021-01-02T19:45:58Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [https://github.com/Aircoookie/WLED WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).<br />
<br />
As WLED doesn't allow exporting its config (yet), here are the most important settings i changed from the stock setup:<br />
* Wifi Setup: SSID & Key already set in the image i uploaded, so nothing to change here for me, but have a look at the [https://github.com/Aircoookie/WLED/wiki WLED wiki] how to connect to a stock image.<br />
* LED Preferences: LED count = 298, Enable automatic brightness limiter = Off<br />
* Sync Interface: Force max brightness = Off (this is important so that data from Hyperion can switch the relay on if it was off)<br />
<br />
For Hyperion, the most important settings are:<br />
* LED Hardware / LED Controller<br />
** Controller Type: udpraw<br />
** Hardware LED count: 298<br />
** Target IP: <the IP of your ESP8266><br />
** Target Port: 19446<br />
* LED Hardware / LED Layout<br />
** Top: 100<br />
** Bottom: 100 (should be the same a Top)<br />
** Left: 56<br />
** Right: 56<br />
** Gap Length: 14<br />
** Gap Position: 199 (position, not count - so it starts from 0, not 1 - and is actually the 200th LED)<br />
** Input Position: 199<br />
** Reverse Direction: On<br />
<br />
Your exact layout depends on your number of LEDs and how you attach them, but this should give you a general idea of how to configure the layout. And always remember: this layout is viewed from the front of your TV! ;-)</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=466DIY Ambilight2021-01-02T19:35:10Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [https://github.com/Aircoookie/WLED WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).<br />
<br />
As WLED doesn't allow exporting its config (yet), here are the most important settings i changed from the stock setup:<br />
* Wifi Setup: SSID & Key already set in the image i uploaded, so nothing to change here for me, but have a look at the [https://github.com/Aircoookie/WLED/wiki WLED wiki] how to connect to a stock image.<br />
* LED Preferences: LED count = 298, Enable automatic brightness limiter = Off<br />
* Sync Interface: Force max brightness = Off (this is important so that data from Hyperion can switch the relay on if it was off)<br />
<br />
For Hyperion, the most important settings are:<br />
* LED Hardware / LED Controller<br />
** Controller Type: udpraw<br />
** Hardware LED count: 298<br />
** Target IP: <the IP of your ESP8266><br />
** Target Port: 19446<br />
* LED Hardware / LED Layout<br />
** Top: 100<br />
** Bottom: 100<br />
** Left: 56<br />
** Right: 56<br />
** Gap Length: 14<br />
** Gap Position: 200<br />
** Input Position: 200<br />
** Reverse Direction: On<br />
<br />
Your exact layout depends on your number of LEDs and how you attach them, but this should give you a general idea of how to configure the layout. And always remember: this layout is viewed from the front of your TV! ;-)</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=465DIY Ambilight2021-01-02T19:26:02Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [https://github.com/Aircoookie/WLED WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).<br />
<br />
As WLED doesn't allow exporting its config (yet), here are the most important settings i changed from the stock setup:<br />
* Wifi Setup: SSID & Key already set in the image i uploaded, so nothing to change here for me, but have a look at the [https://github.com/Aircoookie/WLED/wiki WLED wiki] how to connect to a stock image.<br />
* LED Preferences: LED count = 298, Enable automatic brightness limiter = Off<br />
* Sync Interface: Force max brightness = Off (this is important so that data from Hyperion can switch the relay on if it was off)</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=464DIY Ambilight2021-01-02T19:20:31Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)<br />
<br />
== Software ==<br />
Now that the hard part of the build is done, let's go over the software i'm using:<br />
* [WLED https://github.com/Aircoookie/WLED]<br />
* [https://github.com/hyperion-project/hyperion.ng Hyperion]<br />
* [https://play.google.com/store/apps/details?id=com.abrenoch.hyperiongrabber&hl=en&gl=US Hyperion Android Grabber]<br />
* [https://www.boxpirates.to/index.php?thread/206406-plugin-enigmalight-ambilight-f%C3%BCr-enigma2-receiver-oe1-6-oe2-0-oe2-2-oe2-5-dreamb/ Enigmalight]<br />
<br />
The star of the show is WLED. It receives data from Hyperion on my OSMC Vero 4K+ (my mediacenter running Kodi), from Hyperion Android Grabber on my Nvidia Shield TV Pro (which i use to stream games from my PC) and from Enigmalight on my VU+ Uno 4K SE (basically "just" cable television, on steroids).</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=463DIY Ambilight2021-01-02T19:13:10Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]<br />
<br />
I did all of my testing using a bench power supply that provided exactly 5V, while also showing me how much current is being drawn, but when i moved the setup to the power supply i bought for this project, at least 2 of my ESP8266 died over night, and i was completely clueless why this was happening (as opposed to those that died with a puff of magic smoke, where it was rather obvious that something was wrong).<br />
While replacing the old relay that didn't quite latch anymore after the last visit of the magic smoke monster, i used my multimeter (Aneng AN8009 - very cheap, but quite good!) to measure the voltage that was being delivered through the relay, and noticed that the power supply's output voltage was at a rather high 5.4V instead of the 5.0V i was looking for. While genuine Wemos D1 Mini boards are hard to come by, and may tolerate voltages higher that 5V, i highly recommend using that multimeter to dial the output voltage of the power supply down (or up) to something as close as 5.0V as you can.<br />
<br />
(At the time of this writing, the ESP8266 i'm currently using with the proper voltage hasn't died yet - but i'll update this page if it turns out to be something other than overvoltage.)</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=462DIY Ambilight2021-01-02T19:01:07Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should use a relay. Even when switched off, my ~300 LEDs draw ~0.25 amps, unless i completely cut the power with the a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip the further you get away from the powered end.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=461DIY Ambilight2021-01-02T18:59:25Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should add the relay, because even when switched off, those 300 LEDs draw ~0.25 amps unless you completely cut the power by using a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from pretty much anywhere you like also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=460DIY Ambilight2021-01-02T18:58:37Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should add the relay, because even when switched off, those 300 LEDs draw ~0.25 amps unless you completely cut the power by using a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from the level shifter also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [https://www.amazon.de/dp/B0728HZHTR/ perfboard] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=459DIY Ambilight2021-01-02T18:57:56Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should add the relay, because even when switched off, those 300 LEDs draw ~0.25 amps unless you completely cut the power by using a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from the level shifter also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [perfboard https://www.amazon.de/dp/B0728HZHTR/] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:<br />
[[File:ESP8266 WLED.jpg|thumb|center|ESP8266 + TXS0108E + KY-019]]</div>Janhttps://wiki.faked.org/index.php?title=File:ESP8266_WLED.jpg&diff=458File:ESP8266 WLED.jpg2021-01-02T18:57:33Z<p>Jan: </p>
<hr />
<div>ESP8266 + TXS0108E + KY-019</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=457DIY Ambilight2021-01-02T18:56:26Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should add the relay, because even when switched off, those 300 LEDs draw ~0.25 amps unless you completely cut the power by using a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
<br />
* The 5V connection from the power supply goes into "common" of the relay, and from "NO" ("normally open", as we want the power to be cut when the relay is off) to the 1000 uF capacitor.<br />
* The ground connection from the power supply goes straight to the 1000 uF capacitor.<br />
* From the 1000 uF capacitor, both connections go to the power injection cables of the LED strip, on both ends.<br />
<br />
* The 5V for the electronics goes to "+" pin on the control side of the relay, the 5V pin of the ESP8266 and the "VCC B" reference input on the level shifter.<br />
* The GND between all the electronics gets also connected, and is also wired up to the GND pin of the LED strip's plug. <br />
* In short (no pun intended): all the electronics are on the same 5V and GND, except that the LED strip only gets GND (as it get its 5V from the relay).<br />
<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A6)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A5). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) goes to the 470 Ohms resistor.<br />
* Pin B5 on the level shifter (the high-voltage output of input A5) gets connected to the signal pin on the relay.<br />
<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
<br />
* Again: GND from the level shifter also goes to the GND pin of the LED strip connector.<br />
* Again: The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
<br />
After doing some first tests with a dead-bug-style setup, i eventually decided to build my "production" unit a bit more reliable, with pin headers for easy replacement of components (and i had to do that a lot, because:) and JST connectors for the power connections. A word of advice here: if you're going to add connectors, for the sake of everything that's holy to you, make sure that if you have two plugs that carry 5V and GND, do absolutely make sure that they're both wired identically, with 5V on the same pins. I think in total i wasted 3x ESP8266, 2x level shifters and at least one relay because it didn't notice early enough that the polarity of my power plugs didn't match. Oh well, sacrifices to the magical smoke monster.<br />
<br />
Anyways, so what it did is get a [perfboard https://www.amazon.de/dp/B0728HZHTR/] of the appropriate size to fit all 3 board onto, soldered the female pin headers into place (with 1 row of holes in between for making connections), then used some thin wire to connect all the pins to match my schematic and added two screw terminals (one for electronics power, one for data/GND to the LED strip), replaced the pins on the relay to point straight down instead of to the side (but you could do it any way you see fit, just make sure it all fits somehow).<br />
The 1000 uF capacitor was added to the power plug for the LED strip (which is actually splitting up into another set of cables with a JST plug on one end for the "near end" power injection leads that have a JST socket now, and one half of a LED strip connector on the other end to inject power into the end of the LED strip that was cut off).<br />
<br />
The 470 Ohms resistor was already present in the data/GND cable with the socket for the LED strip's plug, so i just connected that into the screw terminal, but for another build i would probably move that right behind the screw terminal onto the perfboard, so i can just use any cable without having to add the resistor there first.<br />
<br />
And that's what it looked like in the end:</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=456DIY Ambilight2021-01-02T18:21:43Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should add the relay, because even when switched off, those 300 LEDs draw ~0.25 amps unless you completely cut the power by using a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266_WLED_Steckplatine_final.png|thumb|center]]<br />
<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
* Power to the LED strip goes to the 1000 uF capacitor and from there into the power injector cables of the LED strip, but the 5V line for this i also wired into the relay: from power supply into "common" or "middle", and to the LED strip from "NO" ("normally open", as we want the power to be cut when the relay is off).<br />
* Power to the electronics first goes to the control pins of the relay (because they provide enough contact surface to solder multiple connections), and from there to the 5V and GND pins on the ESP8266 and the high-voltage (well, still 5V) reference input on the level shifter. The GND between the level shifter and the ESP8266 was still connected from my early testing, so i left that in place, but i could also have soldered a separate connection from the relay's GND to the level shifter's GND. In short: all the electronics are on the same 5V and GND.<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A4)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A6). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B4 on the level shifter (the high-voltage output of input A4) goes to the 470 Ohms resistor.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) gets connected to the signal pin on the relay.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
* GND from the level shifter also goes to the GND pin of the LED strip connector.<br />
* The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
* TODO: plugs on cables<br />
* TODO: secondary power injection</div>Janhttps://wiki.faked.org/index.php?title=Main_Page&diff=455Main Page2021-01-02T17:20:55Z<p>Jan: </p>
<hr />
<div>=== Guides ===<br />
* [[Asus_PCE-AC88_with_hostapd|Asus PCE-AC88 with hostapd]] - extracting the firmware and configuring hostapd<br />
<br />
=== Asterisk ===<br />
*[[Asterisk/SMS|Asterisk SMS]] - Sending and receiving SMS from SIP phones and ISDN<br />
*[[fcusb2_module|Fritz!Card USB on 2.6.32]] - Compiling the kernel module for a Fritz!Card USB v2.1 on Debian "squeeze" with kernel 2.6.32<br />
*[[Siemens Gigaset S685IP/Troubleshooting|Troubleshooting]] - Some stuff about the VoIP capable Siemen Gigaset S685IP:<br />
*[[Asterisk/Skype|Skype over Asterisk]] via [[Headless_Skype|headless Skype]]<br />
<br />
=== XenServer ===<br />
* [[XenServer/USBIP|USB over IP]] on XenServer 5.5.0 (dom0) and Debian Lenny 2.5.29 (domU)<br />
* [[XenServer/FritzUSB|Fritz!Card USB v2.1]] kernel module for Debian Lenny 2.5.29 (domU)<br />
<br />
=== Cacti ===<br />
* Wifi signal strength/channel/speed of [[Cacti/OpenWRT|OpenWRT]] radio devices<br />
* [[Cacti/Bcache|bcache]]<br />
=== Builds ===<br />
*[[DIY Ambilight]]<br />
*[[DIY NAS]]<br />
*[[FPV Racing Drone]]<br />
<br />
=== Stuff ===<br />
==== Hacks ====<br />
*How i hacked my [[Xbox360|Xbox 360]]<br />
*Privilege Escalation in the [[Promise_VTrak_M500f|Promise VTrak M500f]]<br />
==== Scripts ====<br />
*[[Scripts/dynsupdate|Dynamic NSupdate]] (for Bind9)<br />
*[[Scripts/dynpowerup|Dynamic Powerup]] (for PowerDNS)<br />
==== Kludges ====<br />
*[[Remote_Logstalgia|Logstalgia with multiple hosts]]</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=454DIY Ambilight2020-12-24T17:14:27Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should add the relay, because even when switched off, those 300 LEDs draw ~0.25 amps unless you completely cut the power by using a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266 WLED Steckplatine final.png|thumb|center]]<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
* Power to the LED strip goes to the 1000 uF capacitor and from there into the power injector cables of the LED strip, but the 5V line for this i also wired into the relay: from power supply into "common" or "middle", and to the LED strip from "NO" ("normally open", as we want the power to be cut when the relay is off).<br />
* Power to the electronics first goes to the control pins of the relay (because they provide enough contact surface to solder multiple connections), and from there to the 5V and GND pins on the ESP8266 and the high-voltage (well, still 5V) reference input on the level shifter. The GND between the level shifter and the ESP8266 was still connected from my early testing, so i left that in place, but i could also have soldered a separate connection from the relay's GND to the level shifter's GND. In short: all the electronics are on the same 5V and GND.<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A4)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A6). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B4 on the level shifter (the high-voltage output of input A4) goes to the 470 Ohms resistor.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) gets connected to the signal pin on the relay.<br />
* Pin OE (Output Enable) on the level shifter gets connected to the 3.3V input, too, otherwise the outputs won't output. Don't ask me how long it took me to figure that out.<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
* GND from the level shifter also goes to the GND pin of the LED strip connector.<br />
* The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
* TODO: plugs on cables<br />
* TODO: secondary power injection</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=453DIY Ambilight2020-12-24T17:08:09Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should add the relay, because even when switched off, those 300 LEDs draw ~0.25 amps unless you completely cut the power by using a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
=== Wiring ===<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266 WLED Steckplatine final.png|thumb|center]]<br />
<br />
Let's go over the connections so you'll understand what they do: the 5V and Ground from the power supply is split into two cables each, one for the electronics and one for the LED strip. <br />
* Power to the LED strip goes to the 1000 uF capacitor and from there into the power injector cables of the LED strip, but the 5V line for this i also wired into the relay: from power supply into "common" or "middle", and to the LED strip from "NO" ("normally open", as we want the power to be cut when the relay is off).<br />
* Power to the electronics first goes to the control pins of the relay (because they provide enough contact surface to solder multiple connections), and from there to the 5V and GND pins on the ESP8266 and the high-voltage (well, still 5V) reference input on the level shifter. The GND between the level shifter and the ESP8266 was still connected from my early testing, so i left that in place, but i could also have soldered a separate connection from the relay's GND to the level shifter's GND. In short: all the electronics are on the same 5V and GND.<br />
* The level shifter gets an additional connection from the ESP8266's 3.3V pin to the low-voltage reference input.<br />
* Pin D4 of the ESP8266 is the "data" pin for the LEDs, so that gets connected to any of the inputs on the level shifter (i used A4)<br />
* Pin D6 of the ESP8266 is the "data" pin for the relay, and that also goes to any of the inputs on the level shifter (i used A6). Technically it's not really necessary to use the level shifter to control the relay, as it should also work with 3.3V, but as i have 8 channels on the level shifter, that additional connection is just added peace of mind.<br />
* Pin B4 on the level shifter (the high-voltage output of input A4) goes to the 470 Ohms resistor.<br />
* Pin B6 on the level shifter (the high-voltage output of input A6) gets connected to the signal pin on the relay.<br />
* From the 470 Ohms resistor, split the cable into two connections: one for the main data pin of the LED strip connector, the other for the backup data pin (as the WS2813 has two data pins for redundancy).<br />
* GND from the level shifter also goes to the GND pin of the LED strip connector.<br />
* The 5V input of the LED strip connector is NOT connected, otherwise it would bypass the relay and still draw power when the relay is off.<br />
* TODO: plugs on cables<br />
* TODO: secondary power injection</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=452DIY Ambilight2020-12-24T16:09:02Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should add the relay, because even when switched off, those 300 LEDs draw ~0.25 amps unless you completely cut the power by using a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:<br />
<br />
[[File:ESP8266 WLED Steckplatine final.png|thumb|center]]</div>Janhttps://wiki.faked.org/index.php?title=File:ESP8266_WLED_Steckplatine_final.png&diff=451File:ESP8266 WLED Steckplatine final.png2020-12-24T16:08:49Z<p>Jan: </p>
<hr />
<div>Wiring for DIY Ambilight</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=450DIY Ambilight2020-12-24T16:05:16Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
<br />
# Yes, you should add the relay, because even when switched off, those 300 LEDs draw ~0.25 amps unless you completely cut the power by using a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)<br />
<br />
After wiring it up, i would have liked to see something like the image below, but real life is messy so i won't show any actual photos of the build:</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=449DIY Ambilight2020-12-24T16:00:13Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)<br />
<br />
== Hardware ==<br />
For the first proof-of-concept build i just went with the setup shown in the [https://github.com/Aircoookie/WLED/wiki WLED Wiki] and the hardware i had laying around: an ESP8266 Board, a TXS0108E Level Shifter and a short WS2813 LED Strip. That got wired up on a breadboard and connected to a 5V power supply (although the USB connection for uploading the firmware would probably have been sufficient for those few LEDs - just don't go full brightness), et voilà, we have blinkenlights. I was able to control the LEDs via the web interface, and the included effects looked like everything was working a intended, so i moved on to full build stage.<br />
<br />
Two things i'd like to point out right away, because i only noticed them after the first prototype was finished and i connected the full 5 meter LED strip to it and had to integrate these fixes when i thought i was already done:<br />
# Yes, you should add the relay, because even when switched off, those 300 LEDs draw ~0.25 amps unless you completely cut the power by using a relay.<br />
# Yes, you should inject power also from the other end of the LED strip, as there will be a very noticeable drop in brightness along the LED strip.<br />
<br />
So here's the bill of materials for my DIY Ambilight:<br />
* ESP8266 Board [https://www.amazon.de/dp/B0754N794H/ Amazon] 3 for ~12€<br />
* TXS0108E Level Shifter [https://www.amazon.de/dp/B07NNRS8FS/ Amazon] 6 for ~10€<br />
* KY-019 Relay [https://www.amazon.de/dp/B07CNR7K9B/ Amazon] 3 for ~5€<br />
* WS2813 LED Strip [https://www.amazon.de/dp/B07DPJNMRP/ Amazon] 5m for ~47€ (60LED/m, black, IP30)<br />
* 5V 20A Power Supply [https://www.amazon.de/dp/B07PQT2Q7L/ Amazon] ~16€<br />
* 4 pin LED Strip Connectors [https://www.amazon.de/dp/B012UXUSP6/ Amazon] ~5€<br />
* 1000 uF Capacitor [https://www.amazon.de/dp/B0734T3GJ9/ Amazon] Set of 125 for ~9€<br />
* 470 Ohm Resistor [https://www.amazon.de/dp/B07PZ3M75Z/ Amazon] Set of 500 for ~7€<br />
<br />
Breaking the cost down into what was actually used for my build, i ended up at ~75€. This does not cover the cost of the wires, connectors, soldering tin and tools i used, let alone the time, but it should give you a general idea. ProTip: buy electronics in bulk. It's cheaper, and it's always good to have some ESP8266, level shifters and relays at home. ;-)</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=448DIY Ambilight2020-12-24T15:22:51Z<p>Jan: </p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much so i deciced to build my own Ambilight clone.<br />
<br />
Most solutions seem to go the way of using a HDMI splitter and a HDMI capture card connected to a Raspberry Pi, which interprets the grabbed video frames and controls the LEDs connected to one of its GPIO pins. This is not the way i wanted to go, first because that would require running another Raspberry Pi, and second because that's where it gets expensive if you want something that captures at 4K@60Hz and does not mess up the HDMI connection.<br />
<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB like the Lightpack does was also not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)</div>Janhttps://wiki.faked.org/index.php?title=DIY_Ambilight&diff=447DIY Ambilight2020-12-24T15:14:24Z<p>Jan: Created page with "== Introduction == I've been using two Lightpack v1 modules connected via USB to my mediacenter box running for years, but after getting a new TV, the old Lightpack setup wasn..."</p>
<hr />
<div>== Introduction ==<br />
I've been using two Lightpack v1 modules connected via USB to my mediacenter box running for years, but after getting a new TV, the old Lightpack setup wasn't big enough anymore. Pretty much all products that can be bought ready-to-use cost way too much, so i deciced to build my own Ambilight clone.<br />
As one of the requirements was being able to use it with Kodi (on a Vero 4K+), Enigma (on a VU+ Uno 4K SE) and Android TV (on a Nvidia Shield TV Pro), controlling it via USB was not an option, unless i wanted to move the USB cable between each device whenever i switch to it, so it needed to be something that can be controlled via network.<br />
<br />
The very first search result for "ws2812b wifi" is [https://github.com/Aircoookie/WLED WLED], so i started reading up on what it does and how to use it. The short version: it's a firmware for the wifi-capable ESP8266 board which can control addressable RGB LEDs (commonly referred to as "ws2812b"). And it has support for [https://github.com/hyperion-project/hyperion.ng Hyperion], which is a software that can grab the display output of a video device and convert it to instructions for LED controllers. <br />
<br />
=== WLED ===<br />
WLED seems to be around for less than two years (as of this writing) but it looks like it is very mature and has lots of features and supports many common protocols already. Using ESP8266 boards also makes it very easy to set up, as those boards cost <$5, can be bought pretty much anywhere and you only need a USB cable to upload new firmware (disclaimer: i've been using them for years, so i may be a bit biased regarding what would be considered "easy to use").<br />
<br />
=== Hyperion ===<br />
Hyperion was also the software i have been running on my Kodi boxes, as it provided a very reliable video grabber and made it reasonably easy to set up the LED layout, which is something you have to do so Hyperion can covert the rectangular image from the video grabber into a command for the LEDs at the respective positions. (It basically looks at the video image, sees that e.g. the top left corner is red, so it refers to the LED layout you configured because it needs to know which LEDs in the LED strip are mapped to the top left corner, so that it can send a command to turn those red, too.)</div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=446Asus PCE-AC88 with hostapd2018-12-10T21:28:03Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have a PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
<br />
== Firmware ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for the position of those bytes in the kernel module:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
This is not necessary, but let's get the full details about the firmware we just extracted:<br />
$ strings brcmfmac4366c-pcie.bin_10.10.122.47 | grep Version<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
<br />
Or in a more readable format:<br />
{| class="wikitable"<br />
|-<br />
| Features || pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon<br />
|-<br />
| Version || 10.10.122.47<br />
|-<br />
| CRC || 13f8b3a1 <br />
|-<br />
| Date || Tue 2018-08-14 10:45:51 CST <br />
|- <br />
| FWID || 01-ef91d5ac<br />
|}<br />
<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Initialization ====<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<br />
==== Verification ====<br />
Run the command below, and if you get a similar output you now have a working PCE-AC88.<br />
<nowiki><br />
$ iw phy#0 info<br />
Wiphy phy0<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki><br />
<br />
<br />
==== Versions ====<br />
The first line is the version reported in dmesg, the second line the strings in the firmware:<br />
<nowiki><br />
$ ls -1 brcmfmac4366c-pcie.bin* | xargs -i% strings % | grep -P '\d+\.\d+\.\d+\.\d+'<br />
10.10.122.303 (r666429)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 9ebbf2e1 Date: Wed 2017-07-26 14:44:35 CST FWID 01-fb27523d<br />
10.10.122.303 (r666429)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
10.10.69.6908 (r658761)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr Version: 10.10.69.252 CRC: 9fa88ab1 Date: Mon 2016-09-12 13:28:49 CST Ucode Ver: 1073.579 FWID: 01-fed440e1<br />
10.10.69.69017 (r730013)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr-stamon Version: 10.10.69.69017 (r730013) CRC: cf0b5621 Date: Tue 2017-11-07 12:34:00 CST Ucode Ver: 1073.579 FWID: 01-e258597c<br />
10.10.69.69027 (r766943)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr-stamon Version: 10.10.69.69027 (r766943) CRC: 9055790c Date: Thu 2018-08-23 14:36:02 CST Ucode Ver: 1073.579 FWID: 01-15a952d6<br />
10.10.69.69 (r625687)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac Version: 10.10.69.69 CRC: 34d30c8c Date: Tue 2016-08-23 17:31:24 PDT FWID 01-8438621f<br />
10.10.69.74 (r629731 WLTEST)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfgtest-seqcmds-phydbg-phydump-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-11nprop-dbgam-dbgams-ringer-dmaindex16-bgdfs-hostpmac Version: 10.10.69.74 CRC: a6268b76 Date: Mon 2016-09-12 16:39:23 CST FWID 01-5c0166fa<br />
</nowiki><br />
<br />
== hostapd ==<br />
<nowiki><br />
interface=wlp66s0<br />
bridge=br0<br />
driver=nl80211<br />
<br />
ctrl_interface=/var/run/hostapd<br />
ctrl_interface_group=0<br />
<br />
##### IEEE 802.11<br />
ssid=ThisIsMySSID<br />
country_code=DE<br />
ieee80211d=1<br />
ieee80211h=1<br />
hw_mode=a<br />
channel=60<br />
auth_algs=1<br />
wmm_enabled=1<br />
<br />
##### IEEE 802.11n<br />
ieee80211n=1<br />
ht_capab=[HT40-] [SHORT-GI-40] [DSSS_CCK-40]<br />
<br />
##### IEEE 802.11ac<br />
ieee80211ac=1<br />
vht_capab=[VHT160] [SHORT-GI-80] [SHORT-GI-160] [BF-ANTENNA-4] [SOUNDING-DIMENSION-4] [MU-BEAMFORMER] [MU-BEAMFORMEE]<br />
vht_oper_chwidth=1<br />
vht_oper_centr_freq_seg0_idx=66<br />
<br />
##### WPA/IEEE 802.11i<br />
wpa=2<br />
wpa_passphrase=ThisIsMyPassword<br />
wpa_key_mgmt=WPA-PSK<br />
rsn_pairwise=CCMP<br />
</nowiki></div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=445Asus PCE-AC88 with hostapd2018-12-09T13:03:00Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have a PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
<br />
== Firmware ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for the position of those bytes in the kernel module:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
This is not necessary, but let's get the full details about the firmware we just extracted:<br />
$ strings brcmfmac4366c-pcie.bin_10.10.122.47 | grep Version<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
<br />
Or in a more readable format:<br />
{| class="wikitable"<br />
|-<br />
| Features || pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon<br />
|-<br />
| Version || 10.10.122.47<br />
|-<br />
| CRC || 13f8b3a1 <br />
|-<br />
| Date || Tue 2018-08-14 10:45:51 CST <br />
|- <br />
| FWID || 01-ef91d5ac<br />
|}<br />
<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Initialization ====<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<br />
==== Verification ====<br />
Run the command below, and if you get a similar output you now have a working PCE-AC88.<br />
<nowiki><br />
$ iw phy#0 info<br />
Wiphy phy0<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki><br />
<br />
<br />
==== Versions ====<br />
The first line is the version reported in dmesg, the second line the strings in the firmware:<br />
<nowiki><br />
$ ls -1 brcmfmac4366c-pcie.bin* | xargs -i% strings % | grep -P '\d+\.\d+\.\d+\.\d+'<br />
10.10.122.303 (r666429)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 9ebbf2e1 Date: Wed 2017-07-26 14:44:35 CST FWID 01-fb27523d<br />
10.10.122.303 (r666429)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
10.10.69.6908 (r658761)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr Version: 10.10.69.252 CRC: 9fa88ab1 Date: Mon 2016-09-12 13:28:49 CST Ucode Ver: 1073.579 FWID: 01-fed440e1<br />
10.10.69.69017 (r730013)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr-stamon Version: 10.10.69.69017 (r730013) CRC: cf0b5621 Date: Tue 2017-11-07 12:34:00 CST Ucode Ver: 1073.579 FWID: 01-e258597c<br />
10.10.69.69027 (r766943)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr-stamon Version: 10.10.69.69027 (r766943) CRC: 9055790c Date: Thu 2018-08-23 14:36:02 CST Ucode Ver: 1073.579 FWID: 01-15a952d6<br />
10.10.69.69 (r625687)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac Version: 10.10.69.69 CRC: 34d30c8c Date: Tue 2016-08-23 17:31:24 PDT FWID 01-8438621f<br />
10.10.69.74 (r629731 WLTEST)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfgtest-seqcmds-phydbg-phydump-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-11nprop-dbgam-dbgams-ringer-dmaindex16-bgdfs-hostpmac Version: 10.10.69.74 CRC: a6268b76 Date: Mon 2016-09-12 16:39:23 CST FWID 01-5c0166fa<br />
</nowiki><br />
<br />
== hostapd ==<br />
Not yet...</div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=444Asus PCE-AC88 with hostapd2018-12-09T13:01:54Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
<br />
== Firmware ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for the position of those bytes in the kernel module:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
This is not necessary, but let's get the full details about the firmware we just extracted:<br />
$ strings brcmfmac4366c-pcie.bin_10.10.122.47 | grep Version<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
<br />
Or in a more readable format:<br />
{| class="wikitable"<br />
|-<br />
| Features || pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon<br />
|-<br />
| Version || 10.10.122.47<br />
|-<br />
| CRC || 13f8b3a1 <br />
|-<br />
| Date || Tue 2018-08-14 10:45:51 CST <br />
|- <br />
| FWID || 01-ef91d5ac<br />
|}<br />
<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Initialization ====<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<br />
==== Verification ====<br />
Run the command below, and if you get a similar output you now have a working PCE-AC88.<br />
<nowiki><br />
$ iw phy#0 info<br />
Wiphy phy0<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki><br />
<br />
<br />
==== Versions ====<br />
The first line is the version reported in dmesg, the second line the strings in the firmware:<br />
<nowiki><br />
$ ls -1 brcmfmac4366c-pcie.bin* | xargs -i% strings % | grep -P '\d+\.\d+\.\d+\.\d+'<br />
10.10.122.303 (r666429)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 9ebbf2e1 Date: Wed 2017-07-26 14:44:35 CST FWID 01-fb27523d<br />
10.10.122.303 (r666429)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
10.10.69.6908 (r658761)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr Version: 10.10.69.252 CRC: 9fa88ab1 Date: Mon 2016-09-12 13:28:49 CST Ucode Ver: 1073.579 FWID: 01-fed440e1<br />
10.10.69.69017 (r730013)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr-stamon Version: 10.10.69.69017 (r730013) CRC: cf0b5621 Date: Tue 2017-11-07 12:34:00 CST Ucode Ver: 1073.579 FWID: 01-e258597c<br />
10.10.69.69027 (r766943)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac-txpwr-stamon Version: 10.10.69.69027 (r766943) CRC: 9055790c Date: Thu 2018-08-23 14:36:02 CST Ucode Ver: 1073.579 FWID: 01-15a952d6<br />
10.10.69.69 (r625687)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-hostpmac Version: 10.10.69.69 CRC: 34d30c8c Date: Tue 2016-08-23 17:31:24 PDT FWID 01-8438621f<br />
10.10.69.74 (r629731 WLTEST)<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfgtest-seqcmds-phydbg-phydump-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-11nprop-dbgam-dbgams-ringer-dmaindex16-bgdfs-hostpmac Version: 10.10.69.74 CRC: a6268b76 Date: Mon 2016-09-12 16:39:23 CST FWID 01-5c0166fa<br />
</nowiki><br />
<br />
== hostapd ==<br />
Not yet...</div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=443Asus PCE-AC88 with hostapd2018-12-09T10:12:30Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
<br />
== Firmware ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for the position of those bytes in the kernel module:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
This is not necessary, but let's get the full details about the firmware we just extracted:<br />
$ strings brcmfmac4366c-pcie.bin_10.10.122.47 | grep Version<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
<br />
Or in a more readable format:<br />
{| class="wikitable"<br />
|-<br />
| Features || pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon<br />
|-<br />
| Version || 10.10.122.47<br />
|-<br />
| CRC || 13f8b3a1 <br />
|-<br />
| Date || Tue 2018-08-14 10:45:51 CST <br />
|- <br />
| FWID || 01-ef91d5ac<br />
|}<br />
<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Initialization ====<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<br />
==== Verification ====<br />
Run the command below, and if you get a similar output you now have a working PCE-AC88.<br />
<nowiki><br />
$ iw phy#0 info<br />
Wiphy phy0<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki><br />
<br />
== hostapd ==<br />
Not yet...</div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=442Asus PCE-AC88 with hostapd2018-12-08T16:11:41Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
<br />
== Firmware ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for those bytes in the kernel module we extracted:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
This is not necessary, but let's get the full details about the firmware we just extracted:<br />
$ strings brcmfmac4366c-pcie.bin_10.10.122.47 | grep Version<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
<br />
Or in a more readable format:<br />
{| class="wikitable"<br />
|-<br />
| Features || pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon<br />
|-<br />
| Version || 10.10.122.47<br />
|-<br />
| CRC || 13f8b3a1 <br />
|-<br />
| Date || Tue 2018-08-14 10:45:51 CST <br />
|- <br />
| FWID || 01-ef91d5ac<br />
|}<br />
<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Initialization ====<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<br />
==== Verification ====<br />
Run the command below, and if you get a similar output you now have a working PCE-AC88.<br />
<nowiki><br />
$ iw phy#0 info<br />
Wiphy phy0<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki><br />
<br />
== hostapd ==<br />
Not yet...</div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=441Asus PCE-AC88 with hostapd2018-12-08T13:30:53Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
<br />
== Firmware ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for those bytes in the kernel module we extracted:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
This is not necessary, but let's get the full details about the firmware we just extracted:<br />
$ strings brcmfmac4366c-pcie.bin_10.10.122.47 | grep Version<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
<br />
Or in a more readable format:<br />
{| class="wikitable"<br />
|-<br />
| Features || pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon<br />
|-<br />
| Version || 10.10.122.47<br />
|-<br />
| CRC || 13f8b3a1 <br />
|-<br />
| Date || Tue 2018-08-14 10:45:51 CST <br />
|- <br />
| FWID || 01-ef91d5ac<br />
|}<br />
<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Initialization ====<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<br />
==== Verification ====<br />
Run the command below, and if you get a similar output you now have a working PCE-AC88.<br />
<nowiki><br />
$ iw phy#0 info<br />
Wiphy phy0<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki></div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=440Asus PCE-AC88 with hostapd2018-12-08T13:30:34Z<p>Jan: /* Extraction */</p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
<br />
== Firmware ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for those bytes in the kernel module we extracted:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
This is not necessary, but let's get the full details about the firmware we just extracted:<br />
$ strings brcmfmac4366c-pcie.bin_10.10.122.47 | grep Version<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
<br />
Or in a more readable format:<br />
{| class="wikitable"<br />
|-<br />
| Features || pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon<br />
|-<br />
| Version || 10.10.122.47<br />
|-<br />
| CRC || 13f8b3a1 <br />
|-<br />
| Date || Tue 2018-08-14 10:45:51 CST <br />
|- <br />
| FWID || 01-ef91d5ac<br />
|}<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Initialization ====<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<br />
==== Verification ====<br />
Run the command below, and if you get a similar output you now have a working PCE-AC88.<br />
<nowiki><br />
$ iw phy#0 info<br />
Wiphy phy0<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki></div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=439Asus PCE-AC88 with hostapd2018-12-08T13:26:28Z<p>Jan: /* Extraction */</p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
<br />
== Firmware ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for those bytes in the kernel module we extracted:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
This is not necessary, but let's get the full details about the firmware we just extracted:<br />
$ strings brcmfmac4366c-pcie.bin_10.10.122.47 | grep Version<br />
4366c0-roml/pcie-ag-splitrx-fdap-mbss-mfp-wnm-osen-wl11k-wl11u-txbf-pktctx-amsdutx-ampduretry-chkd2hdma-proptxstatus-11nprop-obss-dbwsw-ringer-dmaindex16-bgdfs-stamon-hostpmac-murx-splitassoc-hostmemucode-dyn160-txpwr-stamon Version: 10.10.122.47 CRC: 13f8b3a1 Date: Tue 2018-08-14 10:45:51 CST FWID 01-ef91d5ac<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Initialization ====<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<br />
==== Verification ====<br />
Run the command below, and if you get a similar output you now have a working PCE-AC88.<br />
<nowiki><br />
$ iw phy#0 info<br />
Wiphy phy0<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki></div>Janhttps://wiki.faked.org/index.php?title=Main_Page&diff=438Main Page2018-12-08T13:21:50Z<p>Jan: </p>
<hr />
<div>=== Guides ===<br />
* [[Asus_PCE-AC88_with_hostapd|Asus PCE-AC88 with hostapd]] - extracting the firmware and configuring hostapd<br />
<br />
=== Asterisk ===<br />
*[[Asterisk/SMS|Asterisk SMS]] - Sending and receiving SMS from SIP phones and ISDN<br />
*[[fcusb2_module|Fritz!Card USB on 2.6.32]] - Compiling the kernel module for a Fritz!Card USB v2.1 on Debian "squeeze" with kernel 2.6.32<br />
*[[Siemens Gigaset S685IP/Troubleshooting|Troubleshooting]] - Some stuff about the VoIP capable Siemen Gigaset S685IP:<br />
*[[Asterisk/Skype|Skype over Asterisk]] via [[Headless_Skype|headless Skype]]<br />
<br />
=== XenServer ===<br />
* [[XenServer/USBIP|USB over IP]] on XenServer 5.5.0 (dom0) and Debian Lenny 2.5.29 (domU)<br />
* [[XenServer/FritzUSB|Fritz!Card USB v2.1]] kernel module for Debian Lenny 2.5.29 (domU)<br />
<br />
=== Cacti ===<br />
* Wifi signal strength/channel/speed of [[Cacti/OpenWRT|OpenWRT]] radio devices<br />
* [[Cacti/Bcache|bcache]]<br />
=== Builds ===<br />
*[[DIY NAS]]<br />
*[[FPV Racing Drone]]<br />
<br />
=== Stuff ===<br />
==== Hacks ====<br />
*How i hacked my [[Xbox360|Xbox 360]]<br />
*Privilege Escalation in the [[Promise_VTrak_M500f|Promise VTrak M500f]]<br />
==== Scripts ====<br />
*[[Scripts/dynsupdate|Dynamic NSupdate]] (for Bind9)<br />
*[[Scripts/dynpowerup|Dynamic Powerup]] (for PowerDNS)<br />
==== Kludges ====<br />
*[[Remote_Logstalgia|Logstalgia with multiple hosts]]</div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=437Asus PCE-AC88 with hostapd2018-12-08T13:18:01Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
<br />
== Firmware ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for those bytes in the kernel module we extracted:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Initialization ====<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<br />
==== Verification ====<br />
Run the command below, and if you get a similar output you now have a working PCE-AC88.<br />
<nowiki><br />
$ iw phy#0 info<br />
Wiphy phy0<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki></div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=436Asus PCE-AC88 with hostapd2018-12-08T13:11:12Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
<br />
== Howto ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for those bytes in the kernel module we extracted:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
<br />
==== Initialization ====<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<br />
==== Verification ====<br />
<nowiki><br />
$ iw phy#1 info<br />
Wiphy phy1<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki></div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=435Asus PCE-AC88 with hostapd2018-12-08T13:06:21Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
== Howto ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
==== Preparation ====<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
==== Investigation ====<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for those bytes in the kernel module we extracted:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
==== Extraction ====<br />
We have the kernel module, we know where the firmware starts, and we know the size of it, so now we can use <code>dd</code> to extract the section that we think is is the firmware from the kernel module: <br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
<br />
==== Installation ====<br />
The <code>brcmfmac</code> module is looking for its firmware files in a specific folder, so you need to copy the extracted firmware there:<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
<br />
==== Initialization ===<br />
You probably have the <code>brcmfmac</code> module still loaded, so let's unload and reload it:<br />
$ modprobe -r brcmfmac<br />
$ modprobe brcmfmac<br />
<br />
If everything went well, <code>dmesg</code> should show you that it was able to initialize the chip with the firmware, even though it complains about <code>brcm/brcmfmac4366c-pcie.txt</code> and <code>brcm/brcmfmac4366c-pcie.clm_blob</code>:<br />
<nowiki><br />
[62448.893550] usbcore: registered new interface driver brcmfmac<br />
[62449.000758] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.002127] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[62449.002137] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.txt (-2)<br />
[62449.002330] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.txt failed with error -2<br />
[62449.753733] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[62449.753749] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[62449.753926] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[62449.753928] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[62449.754055] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Sep 12 2016 13:26:44 version 10.10.69.6908 (r658761) FWID 01-fed440e1<br />
[62449.767104] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0</nowiki><br />
<br />
<nowiki><br />
$ iw phy#1 info<br />
Wiphy phy1<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.<br />
</nowiki></div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=434Asus PCE-AC88 with hostapd2018-12-08T12:54:04Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware file, called <code>brcmfmac4366b-pcie.bin</code>,is readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs the firmware file <code>brcmfmac4366c-pcie.bin</code> - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
== Howto ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory. This is not the firmware, but, as mentioned before, only a kernel module containing the firmware.<br />
<br />
To figure out what the start of the firmware file looks like, we have a look at <code>brcmfmac4366b-pcie.bin</code> from the <code>firmware-brcm80211</code> package to get the first four hex bytes:<br />
<br />
$ xxd /lib/firmware/brcm/brcmfmac4366b-pcie.bin | head -n1<br />
00000000: 00f2 3eb8 04f2 b0bf 04f2 bbbf 04f2 c6bf ..>.............<br />
<br />
Now that we know that we're looking for the bytes <code>00 F2 3E B8</code>, we can use <code>binwalk</code> to look for those bytes in the kernel module we extracted:<br />
<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<nowiki><br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8<br />
</nowiki><br />
<br />
Let's do it once more and grab that offset to put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
256904<br />
<br />
So now we know at what offset the firmware starts, but where does it end? This gets a bit tricky, but stay with me: Kernel modules are ELF files (which you can verify by running <code>file dhd.ko</code>), so we can use <code>readelf</code> to get some information about the kernel module's structure, especially the objects (ko = kernel object) inside it:<br />
$ readelf -s dhd.ko | grep OBJECT<br />
...<br />
484: 00004220 4 OBJECT GLOBAL DEFAULT 35 dhd_radio_up<br />
487: 0000442c 20 OBJECT GLOBAL DEFAULT 35 dlimagedate_4366c0<br />
521: 00000654 4 OBJECT GLOBAL DEFAULT 35 dhd_download_fw_on_driver<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
527: 00004210 4 OBJECT GLOBAL DEFAULT 35 dhd_console_ms<br />
544: 00001058 4 OBJECT GLOBAL DEFAULT 45 dhd_found<br />
545: 00004218 4 OBJECT GLOBAL DEFAULT 35 dhd_master_mode<br />
...<br />
<br />
We see a long list of tiny objects (the third column is the size), but one that sticks out because of its size, and the name <code>dlarray_4366c0</code> also implies that we have found the object we are looking for - and its size.<br />
<br />
So let's do that again, and also grab the size and put it into an environment variable:<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
1094481<br />
<br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.txt<br />
<br />
[ 4254.199723] usbcore: registered new interface driver brcmfmac<br />
[ 4254.306332] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[ 4254.307882] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[ 4254.308213] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.txt<br />
[ 4255.083576] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[ 4255.083600] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[ 4255.083616] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[ 4255.083618] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[ 4255.083843] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Aug 14 2018 10:35:53 version 10.10.122.303 (r666429) FWID 01-ef91d5ac<br />
[ 4255.096622] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0<br />
<br />
$ iw phy#1 info<br />
Wiphy phy1<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.</div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=433Asus PCE-AC88 with hostapd2018-12-08T12:18:28Z<p>Jan: </p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware is, acording to my previous research, readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs different firmware - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
== Howto ==<br />
The first step is to download the current [https://www.asus.com/us/Networking/RT-AC88U/HelpDesk_Download/ firmware package] for the Asus RT-AC88U - which is the Asus Wifi router with the same chip in it. Why? It also runs Linux, so it obviously also needs the firmware for that chip! You can pick any OS (e.g. "Others") from the dropdown menu, as long as you download the file below "Firmware". For me that was version <code>3.0.0.4.384.45149</code>, released just 2 days ago.<br />
<br />
Download that file to a folder, make sure you have <code>p7zip</code> installed, then run the following to extract the kernel module that contains the firmware somewhere inside it:<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory.<br />
The firmware<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8\x04\xf2<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8\x04\xf2<br />
</nowiki><br />
Let's grab that offset and put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
<br />
<br />
$ readelf -s dhd.ko | grep dlarray_4366c0<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
<br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.txt<br />
<br />
[ 4254.199723] usbcore: registered new interface driver brcmfmac<br />
[ 4254.306332] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[ 4254.307882] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[ 4254.308213] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.txt<br />
[ 4255.083576] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[ 4255.083600] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[ 4255.083616] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[ 4255.083618] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[ 4255.083843] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Aug 14 2018 10:35:53 version 10.10.122.303 (r666429) FWID 01-ef91d5ac<br />
[ 4255.096622] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0<br />
<br />
$ iw phy#1 info<br />
Wiphy phy1<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.</div>Janhttps://wiki.faked.org/index.php?title=Asus_PCE-AC88_with_hostapd&diff=432Asus PCE-AC88 with hostapd2018-12-08T11:57:13Z<p>Jan: Created page with "== Intro == For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacem..."</p>
<hr />
<div>== Intro ==<br />
For several years i've been using [https://w1.fi/hostapd/ hostapd] on my home server to create a Wifi access point for all my devices, but due to a recent replacement of the server's hardware, i needed to get a new Wifi adapter as the new mainboard didn't have an PCI slot anymore.<br />
<br />
After initially buying a [https://www.tp-link.com/us/products/details/cat-11_Archer-T9E.html TP-Link Archer T9E], which needs a closed-source driver and doesn't even support master (AP) mode, i (finally!) did a bit more research and found the [https://www.asus.com/Networking/PCE-AC88/ Asus PCE-AC88] to be a worthy, albeit expensive, candidate.<br />
<br />
The PCE-AC88 uses the Broadcom BCM4366 chip, which is supported by the open-source <code>brcmfmac</code> driver - if you feed it the proper (still proprietary) firmware. Luckily that firmware is, acording to my previous research, readily available for Debian 9 in the <code>firmware-brcm80211</code> package - so ''what could possibly go wrong''?<br />
<br />
Well, getting a card with a newer hardware revision (v4), which needs different firmware - that's what ''could possibly go wrong''.<br />
<br />
Fortunately i'm not the only person with issues like this, so there were other people who figured out ways how to get a firmware if there is no official source for it. So here's how i did it...<br />
<br />
== Howto ==<br />
<br />
7z x FW_RT_AC88U_300438445149.zip<br />
7z x RT-AC88U/RT-AC88U_3.0.0.4_384_45149-g467037b.trx lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko<br />
mv lib/modules/2.6.36.4brcmarm/kernel/drivers/net/dhd/dhd.ko ./<br />
rm -r ./RT-AC88U ./lib<br />
<br />
This will give you the file <code>dhd.ko</code> in the current directory.<br />
The firmware<br />
$ binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko<br />
<br />
DECIMAL HEXADECIMAL DESCRIPTION<br />
--------------------------------------------------------------------------------<br />
256904 0x3EB88 \x00\xf2\x3e\xb8\x04\xf2<br />
256936 0x3EBA8 \x00\xf2\x3e\xb8\x04\xf2<br />
</nowiki><br />
Let's grab that offset and put it into an environment variable:<br />
$ OFFSET=$(binwalk -R "\x00\xf2\x3e\xb8\x04\xf2" dhd.ko | sed '4!d' | awk '{print $1}')<br />
$ echo ${OFFSET}<br />
<br />
<br />
$ readelf -s dhd.ko | grep dlarray_4366c0<br />
526: 00004448 0x10b351 OBJECT GLOBAL DEFAULT 35 dlarray_4366c0<br />
<br />
$ SIZE=$(readelf -s dhd.ko | grep dlarray_4366c0 | awk '{print $3}' | xargs printf "%d\n")<br />
$ echo ${SIZE}<br />
<br />
$ dd if=dhd.ko skip=${OFFSET} ibs=1 count=${SIZE} of=brcmfmac4366c-pcie.bin<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.bin<br />
$ cp brcmfmac4366c-pcie.bin /lib/firmware/brcm/brcmfmac4366c-pcie.txt<br />
<br />
[ 4254.199723] usbcore: registered new interface driver brcmfmac<br />
[ 4254.306332] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[ 4254.307882] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.bin<br />
[ 4254.308213] brcmfmac 0000:42:00.0: firmware: direct-loading firmware brcm/brcmfmac4366c-pcie.txt<br />
[ 4255.083576] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4366c-pcie for chip BCM4366/4<br />
[ 4255.083600] brcmfmac 0000:42:00.0: firmware: failed to load brcm/brcmfmac4366c-pcie.clm_blob (-2)<br />
[ 4255.083616] brcmfmac 0000:42:00.0: Direct firmware load for brcm/brcmfmac4366c-pcie.clm_blob failed with error -2<br />
[ 4255.083618] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available<br />
[ 4255.083843] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4366/4 wl0: Aug 14 2018 10:35:53 version 10.10.122.303 (r666429) FWID 01-ef91d5ac<br />
[ 4255.096622] brcmfmac 0000:42:00.0 wlp66s0: renamed from wlan0<br />
<br />
$ iw phy#1 info<br />
Wiphy phy1<br />
max # scan SSIDs: 10<br />
max scan IEs length: 2048 bytes<br />
max # sched scan SSIDs: 0<br />
max # match sets: 0<br />
max # scan plans: 1<br />
max scan plan interval: -1<br />
max scan plan iterations: 0<br />
Retry short limit: 7<br />
Retry long limit: 4<br />
Coverage class: 0 (up to 0m)<br />
Device supports roaming.<br />
Supported Ciphers:<br />
* WEP40 (00-0f-ac:1)<br />
* WEP104 (00-0f-ac:5)<br />
* TKIP (00-0f-ac:2)<br />
* CCMP-128 (00-0f-ac:4)<br />
* CMAC (00-0f-ac:6)<br />
Available Antennas: TX 0 RX 0<br />
Supported interface modes:<br />
* IBSS<br />
* managed<br />
* AP<br />
* P2P-client<br />
* P2P-GO<br />
* P2P-device<br />
Band 1:<br />
Capabilities: 0x1022<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
Bitrates (non-HT):<br />
* 1.0 Mbps<br />
* 2.0 Mbps (short preamble supported)<br />
* 5.5 Mbps (short preamble supported)<br />
* 11.0 Mbps (short preamble supported)<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 2412 MHz [1] (20.0 dBm)<br />
* 2417 MHz [2] (20.0 dBm)<br />
* 2422 MHz [3] (20.0 dBm)<br />
* 2427 MHz [4] (20.0 dBm)<br />
* 2432 MHz [5] (20.0 dBm)<br />
* 2437 MHz [6] (20.0 dBm)<br />
* 2442 MHz [7] (20.0 dBm)<br />
* 2447 MHz [8] (20.0 dBm)<br />
* 2452 MHz [9] (20.0 dBm)<br />
* 2457 MHz [10] (20.0 dBm)<br />
* 2462 MHz [11] (20.0 dBm)<br />
* 2467 MHz [12] (20.0 dBm)<br />
* 2472 MHz [13] (20.0 dBm)<br />
* 2484 MHz [14] (disabled)<br />
Band 2:<br />
Capabilities: 0x1062<br />
HT20/HT40<br />
Static SM Power Save<br />
RX HT20 SGI<br />
RX HT40 SGI<br />
No RX STBC<br />
Max AMSDU length: 3839 bytes<br />
DSSS/CCK HT40<br />
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)<br />
Minimum RX AMPDU time spacing: 16 usec (0x07)<br />
HT TX/RX MCS rate indexes supported: 0-31<br />
VHT Capabilities (0x0c1b4064):<br />
Max MPDU length: 3895<br />
Supported Channel Width: 160 MHz<br />
short GI (80 MHz)<br />
short GI (160/80+80 MHz)<br />
MU Beamformer<br />
MU Beamformee<br />
VHT RX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT RX highest supported: 0 Mbps<br />
VHT TX MCS set:<br />
1 streams: MCS 0-9<br />
2 streams: MCS 0-9<br />
3 streams: MCS 0-9<br />
4 streams: MCS 0-9<br />
5 streams: not supported<br />
6 streams: not supported<br />
7 streams: not supported<br />
8 streams: not supported<br />
VHT TX highest supported: 0 Mbps<br />
Bitrates (non-HT):<br />
* 6.0 Mbps<br />
* 9.0 Mbps<br />
* 12.0 Mbps<br />
* 18.0 Mbps<br />
* 24.0 Mbps<br />
* 36.0 Mbps<br />
* 48.0 Mbps<br />
* 54.0 Mbps<br />
Frequencies:<br />
* 5170 MHz [34] (disabled)<br />
* 5180 MHz [36] (20.0 dBm)<br />
* 5190 MHz [38] (disabled)<br />
* 5200 MHz [40] (20.0 dBm)<br />
* 5210 MHz [42] (disabled)<br />
* 5220 MHz [44] (20.0 dBm)<br />
* 5230 MHz [46] (disabled)<br />
* 5240 MHz [48] (20.0 dBm)<br />
* 5260 MHz [52] (disabled)<br />
* 5280 MHz [56] (disabled)<br />
* 5300 MHz [60] (disabled)<br />
* 5320 MHz [64] (disabled)<br />
* 5500 MHz [100] (disabled)<br />
* 5520 MHz [104] (disabled)<br />
* 5540 MHz [108] (disabled)<br />
* 5560 MHz [112] (disabled)<br />
* 5580 MHz [116] (disabled)<br />
* 5600 MHz [120] (disabled)<br />
* 5620 MHz [124] (disabled)<br />
* 5640 MHz [128] (disabled)<br />
* 5660 MHz [132] (disabled)<br />
* 5680 MHz [136] (disabled)<br />
* 5700 MHz [140] (disabled)<br />
* 5720 MHz [144] (disabled)<br />
* 5745 MHz [149] (disabled)<br />
* 5765 MHz [153] (disabled)<br />
* 5785 MHz [157] (disabled)<br />
* 5805 MHz [161] (disabled)<br />
* 5825 MHz [165] (disabled)<br />
Supported commands:<br />
* new_interface<br />
* set_interface<br />
* new_key<br />
* start_ap<br />
* join_ibss<br />
* set_pmksa<br />
* del_pmksa<br />
* flush_pmksa<br />
* remain_on_channel<br />
* frame<br />
* set_wiphy_netns<br />
* set_channel<br />
* start_p2p_device<br />
* connect<br />
* disconnect<br />
* crit_protocol_start<br />
* crit_protocol_stop<br />
* Unknown command (122)<br />
Supported TX frame types:<br />
* managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
* P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0<br />
Supported RX frame types:<br />
* managed: 0x40 0xd0<br />
* P2P-client: 0x40 0xd0<br />
* P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0<br />
* P2P-device: 0x40 0xd0<br />
WoWLAN support:<br />
* wake up on disconnect<br />
* wake up on magic packet<br />
* wake up on pattern match, up to 8 patterns of 1-128 bytes,<br />
maximum packet offset 1500 bytes<br />
software interface modes (can always be added):<br />
valid interface combinations:<br />
* #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,<br />
total <= 3, #channels <= 1<br />
* #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,<br />
total <= 4, #channels <= 1<br />
* #{ AP } <= 4,<br />
total <= 4, #channels <= 1, STA/AP BI must match<br />
Device supports scan flush.</div>Janhttps://wiki.faked.org/index.php?title=Kodi&diff=429Kodi2017-11-12T18:04:14Z<p>Jan: </p>
<hr />
<div>= Standalone Kodi from Scratch =<br />
<br />
This is how i installed a standalone Kodi "Krypton" 17 on a Gigabyte GA-F2A88XN-WIFI Mini-ITX board with an AMD A8-7600 APU and a Samsung EVO 850 SSD.<br />
<br />
I've skipped the Wifi setup because i'm using a wired connection (high quality 1080p streaming is nicer without buffering).<br />
<br />
== Install OS ==<br />
* Ubuntu 16.04 (netboot via PXE is perfect, but you can use whatever you want, preferably Ubuntu Server)<br />
* New User: kodi<br />
* In the software selection dialog choose:<br />
** [x] Basic Ubuntu server<br />
** [x] OpenSSH server<br />
<br />
== Install Kodi ==<br />
* i used the "unstable" PPA, but if you prefer final releases just replace the "unstable" with "ppa"<br />
<nowiki>sudo add-apt-repository -y ppa:team-xbmc/unstable<br />
sudo apt-get update<br />
sudo apt-get install -y xinit alsa-utils avahi-daemon libva-glx1 libva-egl1 upower libcurl3 mysql-client mesa-utils mesa-vdpau-drivers vdpauinfo xserver-xorg-video-radeon kodi <br />
</nowiki><br />
* allow "anybody" to start the X server<br />
<nowiki>sudo apt-get install xserver-xorg-legacy<br />
sudo dpkg-reconfigure xserver-xorg-legacy<br />
sudo sed -i 's/allowed_users=console/allowed_users=anybody/' /etc/X11/Xwrapper.config<br />
echo needs_root_rights=yes | sudo tee -a /etc/X11/Xwrapper.config<br />
</nowiki><br />
* grant the "kodi" user access to serial devices (CEC), the soundcard and to shutdown, reboot, etc.<br />
<nowiki>sudo usermod -aG users,dialout,audio,video,sudo kodi<br />
</nowiki><br />
* grant the audio thread a higher priority<br />
<nowiki>echo "kodi - nice -1" | sudo tee -a /etc/security/limits.conf<br />
</nowiki><br />
* add some tweaks to '''/etc/X11/xorg.conf''' to eliminate tearing<br />
<nowiki>Section "Device"<br />
Identifier "Radeon"<br />
Driver "radeon"<br />
Option "ColorTiling" "on"<br />
Option "ColorTiling2D" "on"<br />
Option "DRI" "3"<br />
Option "TearFree" "on"<br />
Option "AccelMethod" "glamor"<br />
EndSection<br />
</nowiki><br />
<br />
== Allow Shutdown/Reboot ==<br />
* create '''/etc/polkit-1/localauthority/50-local.d/custom-actions.pkla'''<br />
<nowiki>[Actions for kodi user]<br />
Identity=unix-user:kodi<br />
Action=org.freedesktop.login1.reboot;org.freedesktop.login1.reboot-multiple-sessions;org.freedesktop.login1.power-off;org.freedesktop.login1.power-off-multiple-sessions;org.freedesktop.login1.suspend;org.freedesktop.login1.suspend-multiple-sessions;org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions<br />
ResultAny=yes<br />
ResultInactive=yes<br />
ResultActive=yes<br />
</nowiki><br />
<br />
== Splashscreen (optional) ==<br />
This only started working as expexted after i disabled the "Fullscreen BIOS Logo" in my BIOS.<br />
<nowiki>sudo apt-get install -y plymouth-label v86d<br />
wget https://dl.dropboxusercontent.com/u/22410524/xbmc/plymouth-theme/plymouth-theme-kodi-logo.deb<br />
sudo dpkg -i plymouth-theme-kodi-logo.deb<br />
echo "GRUB_GFXMODE=1920x1080" | sudo tee -a /etc/default/grub<br />
echo "GRUB_GFXPAYLOAD_LINUX=keep" | sudo tee -a /etc/default/grub<br />
sudo update-grub<br />
</nowiki><br />
<br />
== Autostart Kodi ==<br />
* create '''/etc/systemd/system/kodi.service'''<br />
<nowiki>[Unit]<br />
Description=Job that runs Kodi<br />
After=getty.target sound.target network.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
User=kodi<br />
Restart=always<br />
RestartSec=1s<br />
ExecStart=/usr/bin/xinit /usr/bin/kodi --standalone -- /usr/bin/X -bs -nocursor -nolisten tcp :0<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki><br />
* enable the startup script<br />
<nowiki>sudo systemctl daemon-reload<br />
sudo systemctl enable kodi.service<br />
sudo systemctl enable systemd-networkd.service<br />
sudo systemctl enable systemd-networkd-wait-online.service<br />
sudo ln -s /etc/systemd/system/kodi.service /etc/systemd/system/display-manager.service<br />
</nowiki><br />
* reboot. now. Kodi won't start with the new driver unless you reboot<br />
<nowiki>sudo reboot<br />
</nowiki><br />
<br />
= Custom Tweaks =<br />
== ALSA Dual Audio (Digital & Analog) ==<br />
I have a pair of Bass Shakers (a.k.a. Butt Kickers) that need receive audio output, too. Usually you'd use the LFE channel of surround content, but as some content (e.g. Music) is only in Stereo, i want all audio always output via S/PDIF to my AV receiver and additionally via jack to the subwoofer amp (which does the low-pass filtering itself).<br />
Surround content stays surround for the digital output, but will also be converted to stereo for the analog output, and stereo gets output as is.<br />
<br />
This is what my '''/etc/asound.conf''' looks like:<br />
<nowiki>pcm.main {<br />
#type hw<br />
#card 1<br />
#device 1<br />
type plug<br />
slave.pcm "iec958:CARD=Generic,DEV=0"<br />
slave.rate 48000<br />
}<br />
<br />
pcm.shaker {<br />
type hw<br />
card 1<br />
device 0<br />
}<br />
<br />
<br />
pcm.!default {<br />
type plug<br />
hint.show on<br />
hint.description "S/PDIF 2.0 & Analog 2.0"<br />
<br />
slave.channels 2<br />
slave.pcm {<br />
type route<br />
<br />
ttable.0.0 1.0<br />
ttable.1.1 1.0<br />
<br />
ttable.0.2 1.0<br />
ttable.1.3 1.0<br />
<br />
slave.channels 4<br />
slave.pcm {<br />
type multi<br />
<br />
slaves.a.pcm "main"<br />
slaves.a.channels 2<br />
slaves.b.pcm "shaker"<br />
slaves.b.channels 2<br />
<br />
bindings.0.slave a<br />
bindings.0.channel 0<br />
bindings.1.slave a<br />
bindings.1.channel 1<br />
<br />
bindings.2.slave b<br />
bindings.2.channel 0<br />
bindings.3.slave b<br />
bindings.3.channel 1<br />
}<br />
}<br />
}<br />
<br />
pcm.!surround51 {<br />
type plug<br />
hint.show on<br />
hint.description "S/PDIF 5.1 & Analog 2.0"<br />
<br />
slave.channels 6<br />
slave.pcm {<br />
type route<br />
<br />
ttable.0.0 1.0<br />
ttable.1.1 1.0<br />
ttable.2.2 1.0<br />
ttable.3.3 1.0<br />
ttable.4.4 1.0<br />
ttable.5.5 1.0<br />
<br />
ttable.0.6 1.0<br />
ttable.2.6 -0.87177978870813471044739639677192<br />
ttable.3.6 -0.48989794855663561963945681494118<br />
ttable.4.6 0.70710678118654752440084436210485<br />
ttable.5.6 0.70710678118654752440084436210485<br />
<br />
ttable.1.7 1.0<br />
ttable.2.7 0.48989794855663561963945681494118<br />
ttable.3.7 0.87177978870813471044739639677192<br />
ttable.4.7 0.70710678118654752440084436210485<br />
ttable.5.7 0.70710678118654752440084436210485<br />
<br />
slave.channels 8<br />
slave.pcm {<br />
type multi<br />
<br />
slaves.a.pcm "main"<br />
slaves.a.channels 6<br />
slaves.b.pcm "shaker"<br />
slaves.b.channels 2<br />
<br />
bindings.0.slave a<br />
bindings.0.channel 0<br />
bindings.1.slave a<br />
bindings.1.channel 1<br />
bindings.2.slave a<br />
bindings.2.channel 2<br />
bindings.3.slave a<br />
bindings.3.channel 3<br />
bindings.4.slave a<br />
bindings.4.channel 4<br />
bindings.5.slave a<br />
bindings.5.channel 5<br />
<br />
bindings.6.slave b<br />
bindings.6.channel 0<br />
bindings.7.slave b<br />
bindings.7.channel 1<br />
}<br />
}<br />
}<br />
</nowiki><br />
If you're interested in something similar, i can recommend the BS-200 bass shakers and the A-408 amp from [https://reckhorn.com/ Reckhorn] - they're also offering a sets with 2 shakers and an amp. The A-500 is basically the same amp with less controls, but i guess that would have been more that sufficient, too.<br />
<br />
== Lightpack ==<br />
<nowiki>git clone --recursive https://github.com/hyperion-project/hyperion.git<br />
cd hyperion<br />
cmake -DPLATFORM=x86 -DCMAKE_BUILD_TYPE=Release<br />
make -j $(nproc)<br />
sudo make install<br />
</nowiki><br />
<br />
* '''/etc/systemd/system/hyperion.service'''<br />
<nowiki>[Unit]<br />
Description=Job that starts Hyperion<br />
<br />
[Service]<br />
User=root<br />
Restart=always<br />
RestartSec=1s<br />
ExecStart=/usr/local/bin/hyperiond /etc/hyperion.config.json<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki><br />
<br />
* '''/etc/systemd/system/hyperion-x11.service'''<br />
<nowiki>[Unit]<br />
Description=Job that starts Hyperion-X11<br />
After=kodi.service<br />
<br />
[Service]<br />
User=root<br />
Restart=always<br />
RestartSec=1s<br />
Environment=DISPLAY=:0<br />
ExecStart=/usr/local/bin/hyperion-x11<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki><br />
<br />
* enable units<br />
<nowiki><br />
systemctl enable hyperion<br />
systemctl enable hyperion-x11<br />
</nowiki><br />
<br />
Use HyperCon to generate a config file and save it to /etc/hyperion.config.json</div>Janhttps://wiki.faked.org/index.php?title=Kodi&diff=428Kodi2017-11-12T18:01:51Z<p>Jan: </p>
<hr />
<div>= Standalone Kodi from Scratch =<br />
<br />
This is how i installed a standalone Kodi "Krypton" 17 on a Gigabyte GA-F2A88XN-WIFI Mini-ITX board with an AMD A8-7600 APU and a Samsung EVO 850 SSD.<br />
<br />
I've skipped the Wifi setup because i'm using a wired connection (high quality 1080p streaming is nicer without buffering).<br />
<br />
== Install OS ==<br />
* Ubuntu 16.04 (netboot via PXE is perfect, but you can use whatever you want, preferably Ubuntu Server)<br />
* New User: kodi<br />
* In the software selection dialog choose:<br />
** [x] Basic Ubuntu server<br />
** [x] OpenSSH server<br />
<br />
== Install Kodi ==<br />
* i used the "unstable" PPA, but if you prefer final releases just replace the "unstable" with "ppa"<br />
<nowiki>sudo add-apt-repository -y ppa:team-xbmc/unstable<br />
sudo apt-get update<br />
sudo apt-get install -y xinit alsa-utils avahi-daemon libva-glx1 libva-egl1 upower libcurl3 mysql-client mesa-utils mesa-vdpau-drivers vdpauinfo xserver-xorg-video-radeon kodi <br />
</nowiki><br />
* allow "anybody" to start the X server<br />
<nowiki>sudo apt-get install xserver-xorg-legacy<br />
sudo dpkg-reconfigure xserver-xorg-legacy<br />
sudo sed -i 's/allowed_users=console/allowed_users=anybody/' /etc/X11/Xwrapper.config<br />
echo needs_root_rights=yes | sudo tee -a /etc/X11/Xwrapper.config<br />
</nowiki><br />
* grant the "kodi" user access to serial devices (CEC), the soundcard and to shutdown, reboot, etc.<br />
<nowiki>sudo usermod -aG users,dialout,audio,video,sudo kodi<br />
</nowiki><br />
* grant the audio thread a higher priority<br />
<nowiki>echo "kodi - nice -1" | sudo tee -a /etc/security/limits.conf<br />
</nowiki><br />
* add some tweaks to '''/etc/X11/xorg.conf''' to eliminate tearing<br />
<nowiki>Section "Device"<br />
Identifier "Radeon"<br />
Driver "radeon"<br />
Option "ColorTiling" "on"<br />
Option "ColorTiling2D" "on"<br />
Option "DRI" "3"<br />
Option "TearFree" "on"<br />
Option "AccelMethod" "glamor"<br />
EndSection<br />
</nowiki><br />
<br />
== Allow Shutdown/Reboot ==<br />
* create '''/etc/polkit-1/localauthority/50-local.d/custom-actions.pkla'''<br />
<nowiki>[Actions for kodi user]<br />
Identity=unix-user:kodi<br />
Action=org.freedesktop.login1.reboot;org.freedesktop.login1.reboot-multiple-sessions;org.freedesktop.login1.power-off;org.freedesktop.login1.power-off-multiple-sessions;org.freedesktop.login1.suspend;org.freedesktop.login1.suspend-multiple-sessions;org.freedesktop.login1.hibernate;org.freedesktop.login1.hibernate-multiple-sessions<br />
ResultAny=yes<br />
ResultInactive=yes<br />
ResultActive=yes<br />
</nowiki><br />
<br />
== Splashscreen (optional) ==<br />
This only started working as expexted after i disabled the "Fullscreen BIOS Logo" in my BIOS.<br />
<nowiki>sudo apt-get install -y plymouth-label v86d<br />
wget https://dl.dropboxusercontent.com/u/22410524/xbmc/plymouth-theme/plymouth-theme-kodi-logo.deb<br />
sudo dpkg -i plymouth-theme-kodi-logo.deb<br />
echo "GRUB_GFXMODE=1920x1080" | sudo tee -a /etc/default/grub<br />
echo "GRUB_GFXPAYLOAD_LINUX=keep" | sudo tee -a /etc/default/grub<br />
sudo update-grub<br />
</nowiki><br />
<br />
== Autostart Kodi ==<br />
* create '''/etc/systemd/system/kodi.service'''<br />
<nowiki>[Unit]<br />
Description=Job that runs Kodi<br />
After=getty.target sound.target network.target<br />
Wants=network-online.target<br />
<br />
[Service]<br />
User=kodi<br />
Restart=always<br />
RestartSec=1s<br />
ExecStart=/usr/bin/xinit /usr/bin/kodi --standalone -- /usr/bin/X -bs -nocursor -nolisten tcp :0<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki><br />
* enable the startup script<br />
<nowiki>sudo systemctl daemon-reload<br />
sudo systemctl enable kodi.service<br />
sudo systemctl enable systemd-networkd.service<br />
sudo systemctl enable systemd-networkd-wait-online.service<br />
sudo ln -s /etc/systemd/system/kodi.service /etc/systemd/system/display-manager.service<br />
</nowiki><br />
* reboot. now. Kodi won't start with the new driver unless you reboot<br />
<nowiki>sudo reboot<br />
</nowiki><br />
<br />
= Custom Tweaks =<br />
== ALSA Dual Audio (Digital & Analog) ==<br />
I have a pair of Bass Shakers (a.k.a. Butt Kickers) that need receive audio output, too. Usually you'd use the LFE channel of surround content, but as some content (e.g. Music) is only in Stereo, i want all audio always output via S/PDIF to my AV receiver and additionally via jack to the subwoofer amp (which does the low-pass filtering itself).<br />
Surround content stays surround for the digital output, but will also be converted to stereo for the analog output, and stereo gets output as is.<br />
<br />
This is what my '''/etc/asound.conf''' looks like:<br />
<nowiki>pcm.main {<br />
#type hw<br />
#card 1<br />
#device 1<br />
type plug<br />
slave.pcm "iec958:CARD=Generic,DEV=0"<br />
slave.rate 48000<br />
}<br />
<br />
pcm.shaker {<br />
type hw<br />
card 1<br />
device 0<br />
}<br />
<br />
<br />
pcm.!default {<br />
type plug<br />
hint.show on<br />
hint.description "S/PDIF 2.0 & Analog 2.0"<br />
<br />
slave.channels 2<br />
slave.pcm {<br />
type route<br />
<br />
ttable.0.0 1.0<br />
ttable.1.1 1.0<br />
<br />
ttable.0.2 1.0<br />
ttable.1.3 1.0<br />
<br />
slave.channels 4<br />
slave.pcm {<br />
type multi<br />
<br />
slaves.a.pcm "main"<br />
slaves.a.channels 2<br />
slaves.b.pcm "shaker"<br />
slaves.b.channels 2<br />
<br />
bindings.0.slave a<br />
bindings.0.channel 0<br />
bindings.1.slave a<br />
bindings.1.channel 1<br />
<br />
bindings.2.slave b<br />
bindings.2.channel 0<br />
bindings.3.slave b<br />
bindings.3.channel 1<br />
}<br />
}<br />
}<br />
<br />
pcm.!surround51 {<br />
type plug<br />
hint.show on<br />
hint.description "S/PDIF 5.1 & Analog 2.0"<br />
<br />
slave.channels 6<br />
slave.pcm {<br />
type route<br />
<br />
ttable.0.0 1.0<br />
ttable.1.1 1.0<br />
ttable.2.2 1.0<br />
ttable.3.3 1.0<br />
ttable.4.4 1.0<br />
ttable.5.5 1.0<br />
<br />
ttable.0.6 1.0<br />
ttable.2.6 -0.87177978870813471044739639677192<br />
ttable.3.6 -0.48989794855663561963945681494118<br />
ttable.4.6 0.70710678118654752440084436210485<br />
ttable.5.6 0.70710678118654752440084436210485<br />
<br />
ttable.1.7 1.0<br />
ttable.2.7 0.48989794855663561963945681494118<br />
ttable.3.7 0.87177978870813471044739639677192<br />
ttable.4.7 0.70710678118654752440084436210485<br />
ttable.5.7 0.70710678118654752440084436210485<br />
<br />
slave.channels 8<br />
slave.pcm {<br />
type multi<br />
<br />
slaves.a.pcm "main"<br />
slaves.a.channels 6<br />
slaves.b.pcm "shaker"<br />
slaves.b.channels 2<br />
<br />
bindings.0.slave a<br />
bindings.0.channel 0<br />
bindings.1.slave a<br />
bindings.1.channel 1<br />
bindings.2.slave a<br />
bindings.2.channel 2<br />
bindings.3.slave a<br />
bindings.3.channel 3<br />
bindings.4.slave a<br />
bindings.4.channel 4<br />
bindings.5.slave a<br />
bindings.5.channel 5<br />
<br />
bindings.6.slave b<br />
bindings.6.channel 0<br />
bindings.7.slave b<br />
bindings.7.channel 1<br />
}<br />
}<br />
}<br />
</nowiki><br />
If you're interested in something similar, i can recommend the BS-200 bass shakers and the A-408 amp from [https://reckhorn.com/ Reckhorn] - they're also offering a sets with 2 shakers and an amp. The A-500 is basically the same amp with less controls, but i guess that would have been more that sufficient, too.<br />
<br />
== Lightpack ==<br />
<nowiki><br />
git clone --recursive https://github.com/hyperion-project/hyperion.git<br />
cd hyperion<br />
cmake -DPLATFORM=x86 -DCMAKE_BUILD_TYPE=Release<br />
make -j $(nproc)<br />
sudo make install<br />
</nowiki><br />
* '''/etc/systemd/system/hyperion.service'''<br />
<nowiki>[Unit]<br />
Description=Job that starts Hyperion<br />
<br />
[Service]<br />
User=root<br />
Restart=always<br />
RestartSec=1s<br />
ExecStart=/usr/local/bin/hyperiond /etc/hyperion.config.json<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki><br />
* '''/etc/systemd/system/hyperion-x11.service'''<br />
<nowiki>[Unit]<br />
Description=Job that starts Hyperion-X11<br />
After=kodi.service<br />
<br />
[Service]<br />
User=root<br />
Restart=always<br />
RestartSec=1s<br />
Environment=DISPLAY=:0<br />
ExecStart=/usr/local/bin/hyperion-x11<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki><br />
* enable units<br />
<nowiki><br />
systemctl enable hyperion<br />
systemctl enable hyperion-x11<br />
</nowiki><br />
<br />
Use HyperCon to generate a config file and save it to /etc/hyperion.config.json</div>Janhttps://wiki.faked.org/index.php?title=FPV_Racing_Drone&diff=427FPV Racing Drone2017-07-01T19:37:00Z<p>Jan: </p>
<hr />
<div>Cheap 3S motor/ESC setup to get started, upgrade to 4S later.<br />
<br />
==== Frame ====<br />
* <strike>[https://www.thingiverse.com/thing:511668 Hovership MHQ2]</strike><br />
* <strike>[https://www.thingiverse.com/thing:1163884 Firefly Pro]</strike><br />
* [http://www.armattanquads.com/chameleon/ Armattan Chameleon (silver)] - not 3D printed, but lifetime warranty<br />
<br />
==== Flight Controller ====<br />
* [http://www.holybro.com/product/46 HolyBro Kakute F4 AIO] - with PDB and OSD<br />
<br />
==== ESCs ====<br />
* [https://n-factory.de/Lumenier-BLHeli_S-35A-4-in-1-Regler-OPTO-ESC_1 Lumenier BLHeli_S 35A 4-in-4]<br />
<br />
==== Motors ====<br />
* <strike>2x [https://hobbyking.com/en_us/black-widow-2204-18a-16d-cw-2300kv.html ZTW Black Widow 2204-2300kv CW] - with internal ESCs</strike><br />
* <strike>2x [https://hobbyking.com/en_us/black-widow-2204-18a-16d-cww-2300kv.html ZTW Black Widow 2204-2300kv CCW] - with internal ESCs</strike><br />
* 4x [https://n-factory.de/EMAX-RS2205S-2300kv-Motor_1 EMAX RS2205S 2300kV]<br />
<br />
==== Props ====<br />
* 4x [https://hobbyking.com/en_us/gemfan-propeller-5x4-black-cw-ccw-2pcs.html Gemfan 5x4 (CW/CCW)] (2 sets + 2 spare sets)<br />
<br />
==== Low Voltage Warner ====<br />
* [https://hobbyking.com/en_us/hobbykingtm-lipoly-low-voltage-alarm-2s-4s.html HK Lipoly Low Voltage Warner 2S-4S]<br />
<br />
==== LiPos ====<br />
* <strike>2x [https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-3s-35-70c-lipo-pack.html Turnigy Nano-Tech 1500mAh 3S 35-70C] - for drone</strike><br />
* 2x [https://hobbyking.com/en_us/graphene-1500mah-4s-65c-w-xt60.html Turnigy Graphene 1500mAh 4S 65C] - for drone<br />
* 1x [https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-2s-35-70c-lipo-pack.html Turnigy Nano-Tech 1500mAh 2S 35-70C] - for FPV goggles<br />
<br />
==== VTX ====<br />
* [https://n-factory.de/58GHz-TBS-Unify-Pro-HV-RACE-SMA_1 TBS Unify Pro HV - RACE (SMA)]<br />
<br />
==== FPV Camera ====<br />
* [https://n-factory.de/RunCam-Swift-2-25-Linse-600TVL-FPV-Kamera_1 RunCam Swift 2] - with 2.5mm lens (FOV: 130°)<br />
<br />
==== VTX/VRX Antenna ====<br />
* [https://n-factory.de/58GHz-FOXEER-Antenna-kit-RHCP-SMA Foxeer RHCP SMA Antenna kit]<br />
<br />
==== TX/RX ====<br />
* <strike>[https://hobbyking.com/en_us/i6s-afhds-2a-black-mode2-6ch-radio-with-colour-box.html Turnigy TGY-i6S Digital Proportional Radio Control System (Mode 2)]</strike><br />
* [http://rclife.co.uk/FrSky-Taranis-X9D-Plus-Special-Edition-Carbon FrSky Taranis X9D Plus Special Edition (Carbon)]<br />
* [http://rclife.co.uk/X8R-Receiver FrSky X8R Receiver]<br />
<br />
==== FPV Goggles ====<br />
* [https://hobbyking.com/de_de/quanum-cyclops-v2-fpv-goggle.html Quanum Cyclops v2]<br />
<br />
==== GPS/Compass ====<br />
* [https://www.banggood.com/Ublox-NEO-M8N-Flight-Controller-GPS-with-Protective-Shell-for-PIX-PX4-Pixhawk-p-1005394.html Ublox NEO-M8N] (Compass not usable with Kakute F4, i think - no i2c)</div>Janhttps://wiki.faked.org/index.php?title=FPV_Racing_Drone&diff=426FPV Racing Drone2017-07-01T19:36:46Z<p>Jan: </p>
<hr />
<div>Cheap 3S motor/ESC setup to get started, upgrade to 4S later.<br />
<br />
==== Frame ====<br />
* <strike>[https://www.thingiverse.com/thing:511668 Hovership MHQ2]</strike><br />
* <strike>[https://www.thingiverse.com/thing:1163884 Firefly Pro]</strike><br />
* [http://www.armattanquads.com/chameleon/ Armattan Chameleon (silver)] - not 3D printed, but lifetime warranty<br />
<br />
==== Flight Controller ====<br />
* [http://www.holybro.com/product/46 HolyBro Kakute F4 AIO] - with PDB and OSD<br />
<br />
==== ESCs ====<br />
* [https://n-factory.de/Lumenier-BLHeli_S-35A-4-in-1-Regler-OPTO-ESC_1 Lumenier BLHeli_S 35A 4-in-4]<br />
<br />
==== Motors ====<br />
* <strike>2x [https://hobbyking.com/en_us/black-widow-2204-18a-16d-cw-2300kv.html ZTW Black Widow 2204-2300kv CW] - with internal ESCs</strike><br />
* <strike>2x [https://hobbyking.com/en_us/black-widow-2204-18a-16d-cww-2300kv.html ZTW Black Widow 2204-2300kv CCW] - with internal ESCs</strike><br />
* 4x [https://n-factory.de/EMAX-RS2205S-2300kv-Motor_1 EMAX RS2205S 2300kV]<br />
<br />
==== Props ====<br />
* 4x [https://hobbyking.com/en_us/gemfan-propeller-5x4-black-cw-ccw-2pcs.html Gemfan 5x4 (CW/CCW)] (2 sets + 2 spare sets)<br />
<br />
==== Low Voltage Warner ====<br />
* [https://hobbyking.com/en_us/hobbykingtm-lipoly-low-voltage-alarm-2s-4s.html HK Lipoly Low Voltage Warner 2S-4S]<br />
<br />
==== LiPos ====<br />
* <strike>2x [https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-3s-35-70c-lipo-pack.html Turnigy Nano-Tech 1500mAh 3S 35-70C] - for drone</strike><br />
* 2x [https://hobbyking.com/en_us/graphene-1500mah-4s-65c-w-xt60.html Turnigy Graphene 1500mAh 4S 65C]<br />
* 1x [https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-2s-35-70c-lipo-pack.html Turnigy Nano-Tech 1500mAh 2S 35-70C] - for FPV goggles<br />
<br />
==== VTX ====<br />
* [https://n-factory.de/58GHz-TBS-Unify-Pro-HV-RACE-SMA_1 TBS Unify Pro HV - RACE (SMA)]<br />
<br />
==== FPV Camera ====<br />
* [https://n-factory.de/RunCam-Swift-2-25-Linse-600TVL-FPV-Kamera_1 RunCam Swift 2] - with 2.5mm lens (FOV: 130°)<br />
<br />
==== VTX/VRX Antenna ====<br />
* [https://n-factory.de/58GHz-FOXEER-Antenna-kit-RHCP-SMA Foxeer RHCP SMA Antenna kit]<br />
<br />
==== TX/RX ====<br />
* <strike>[https://hobbyking.com/en_us/i6s-afhds-2a-black-mode2-6ch-radio-with-colour-box.html Turnigy TGY-i6S Digital Proportional Radio Control System (Mode 2)]</strike><br />
* [http://rclife.co.uk/FrSky-Taranis-X9D-Plus-Special-Edition-Carbon FrSky Taranis X9D Plus Special Edition (Carbon)]<br />
* [http://rclife.co.uk/X8R-Receiver FrSky X8R Receiver]<br />
<br />
==== FPV Goggles ====<br />
* [https://hobbyking.com/de_de/quanum-cyclops-v2-fpv-goggle.html Quanum Cyclops v2]<br />
<br />
==== GPS/Compass ====<br />
* [https://www.banggood.com/Ublox-NEO-M8N-Flight-Controller-GPS-with-Protective-Shell-for-PIX-PX4-Pixhawk-p-1005394.html Ublox NEO-M8N] (Compass not usable with Kakute F4, i think - no i2c)</div>Janhttps://wiki.faked.org/index.php?title=FPV_Racing_Drone&diff=425FPV Racing Drone2017-07-01T19:15:48Z<p>Jan: </p>
<hr />
<div>Cheap 3S motor/ESC setup to get started, upgrade to 4S later.<br />
<br />
==== Frame ====<br />
* <strike>[https://www.thingiverse.com/thing:511668 Hovership MHQ2]</strike><br />
* <strike>[https://www.thingiverse.com/thing:1163884 Firefly Pro]</strike><br />
* [http://www.armattanquads.com/chameleon/ Armattan Chameleon (silver)] - not 3D printed, but lifetime warranty<br />
<br />
==== Flight Controller ====<br />
* [http://www.holybro.com/product/46 HolyBro Kakute F4 AIO] - with PDB and OSD<br />
<br />
==== ESCs ====<br />
* [https://n-factory.de/Lumenier-BLHeli_S-35A-4-in-1-Regler-OPTO-ESC_1 Lumenier BLHeli_S 35A 4-in-4]<br />
<br />
==== Motors ====<br />
* <strike>2x [https://hobbyking.com/en_us/black-widow-2204-18a-16d-cw-2300kv.html ZTW Black Widow 2204-2300kv CW] - with internal ESCs</strike><br />
* <strike>2x [https://hobbyking.com/en_us/black-widow-2204-18a-16d-cww-2300kv.html ZTW Black Widow 2204-2300kv CCW] - with internal ESCs</strike><br />
* 4x [https://n-factory.de/EMAX-RS2205S-2300kv-Motor_1 EMAX RS2205S 2300kV]<br />
<br />
==== Props ====<br />
* 4x [https://hobbyking.com/en_us/gemfan-propeller-5x4-black-cw-ccw-2pcs.html Gemfan 5x4 (CW/CCW)] (2 sets + 2 spare sets)<br />
<br />
==== Low Voltage Warner ====<br />
* [https://hobbyking.com/en_us/hobbykingtm-lipoly-low-voltage-alarm-2s-4s.html HK Lipoly Low Voltage Warner 2S-4S]<br />
<br />
==== LiPos ====<br />
* 2x [https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-3s-35-70c-lipo-pack.html Turnigy Nano-Tech 1500mAh 3S 35-70C] - for drone<br />
* 1x [https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-2s-35-70c-lipo-pack.html Turnigy Nano-Tech 1500mAh 2S 35-70C] - for FPV goggles<br />
<br />
==== VTX ====<br />
* [https://n-factory.de/58GHz-TBS-Unify-Pro-HV-RACE-SMA_1 TBS Unify Pro HV - RACE (SMA)]<br />
<br />
==== FPV Camera ====<br />
* [https://n-factory.de/RunCam-Swift-2-25-Linse-600TVL-FPV-Kamera_1 RunCam Swift 2] - with 2.5mm lens (FOV: 130°)<br />
<br />
==== VTX/VRX Antenna ====<br />
* [https://n-factory.de/58GHz-FOXEER-Antenna-kit-RHCP-SMA Foxeer RHCP SMA Antenna kit]<br />
<br />
==== TX/RX ====<br />
* <strike>[https://hobbyking.com/en_us/i6s-afhds-2a-black-mode2-6ch-radio-with-colour-box.html Turnigy TGY-i6S Digital Proportional Radio Control System (Mode 2)]</strike><br />
* [http://rclife.co.uk/FrSky-Taranis-X9D-Plus-Special-Edition-Carbon FrSky Taranis X9D Plus Special Edition (Carbon)]<br />
* [http://rclife.co.uk/X8R-Receiver FrSky X8R Receiver]<br />
<br />
==== FPV Goggles ====<br />
* [https://hobbyking.com/de_de/quanum-cyclops-v2-fpv-goggle.html Quanum Cyclops v2]<br />
<br />
==== GPS/Compass ====<br />
* [https://www.banggood.com/Ublox-NEO-M8N-Flight-Controller-GPS-with-Protective-Shell-for-PIX-PX4-Pixhawk-p-1005394.html Ublox NEO-M8N] (Compass not usable with Kakute F4, i think - no i2c)</div>Janhttps://wiki.faked.org/index.php?title=FPV_Racing_Drone&diff=424FPV Racing Drone2017-06-30T17:51:39Z<p>Jan: </p>
<hr />
<div>Cheap 3S motor/ESC setup to get started, upgrade to 4S later.<br />
<br />
==== Frame ====<br />
* <strike>[https://www.thingiverse.com/thing:511668 Hovership MHQ2]</strike><br />
* <strike>[https://www.thingiverse.com/thing:1163884 Firefly Pro]</strike><br />
* [http://www.armattanquads.com/chameleon/ Armattan Chameleon (silver)] - not 3D printed, but lifetime warranty<br />
<br />
==== Flight Controller ====<br />
* [http://www.holybro.com/product/46 HolyBro Kakute F4 AIO] - with PDB and OSD<br />
<br />
==== Motors ====<br />
* 2x [https://hobbyking.com/en_us/black-widow-2204-18a-16d-cw-2300kv.html ZTW Black Widow 2204-2300kv CW] - with internal ESCs<br />
* 2x [https://hobbyking.com/en_us/black-widow-2204-18a-16d-cww-2300kv.html ZTW Black Widow 2204-2300kv CCW] - with internal ESCs<br />
<br />
==== Props ====<br />
* 4x [https://hobbyking.com/en_us/gemfan-propeller-5x4-black-cw-ccw-2pcs.html Gemfan 5x4 (CW/CCW)] (2 sets + 2 spare sets)<br />
<br />
==== Low Voltage Warner ====<br />
* [https://hobbyking.com/en_us/hobbykingtm-lipoly-low-voltage-alarm-2s-4s.html HK Lipoly Low Voltage Warner 2S-4S]<br />
<br />
==== LiPos ====<br />
* 2x [https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-3s-35-70c-lipo-pack.html Turnigy Nano-Tech 1500mAh 3S 35-70C] - for drone<br />
* 1x [https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-2s-35-70c-lipo-pack.html Turnigy Nano-Tech 1500mAh 2S 35-70C] - for FPV goggles<br />
<br />
==== VTX ====<br />
* [https://n-factory.de/58GHz-TBS-Unify-Pro-HV-RACE-SMA_1 TBS Unify Pro HV - RACE (SMA)]<br />
<br />
==== FPV Camera ====<br />
* [https://n-factory.de/RunCam-Swift-2-25-Linse-600TVL-FPV-Kamera_1 RunCam Swift 2] - with 2.5mm lens (FOV: 130°)<br />
<br />
==== VTX/VRX Antenna ====<br />
* [https://n-factory.de/58GHz-FOXEER-Antenna-kit-RHCP-SMA Foxeer RHCP SMA Antenna kit]<br />
<br />
==== TX/RX ====<br />
* <strike>[https://hobbyking.com/en_us/i6s-afhds-2a-black-mode2-6ch-radio-with-colour-box.html Turnigy TGY-i6S Digital Proportional Radio Control System (Mode 2)]</strike><br />
* [http://rclife.co.uk/FrSky-Taranis-X9D-Plus-Special-Edition-Carbon FrSky Taranis X9D Plus Special Edition (Carbon)]<br />
* [http://rclife.co.uk/X8R-Receiver FrSky X8R Receiver]<br />
<br />
==== FPV Goggles ====<br />
* [https://hobbyking.com/de_de/quanum-cyclops-v2-fpv-goggle.html Quanum Cyclops v2]<br />
<br />
==== GPS/Compass ====<br />
* [https://www.banggood.com/Ublox-NEO-M8N-Flight-Controller-GPS-with-Protective-Shell-for-PIX-PX4-Pixhawk-p-1005394.html Ublox NEO-M8N] (Compass not usable with Kakute F4, i think - no i2c)</div>Janhttps://wiki.faked.org/index.php?title=FPV_Racing_Drone&diff=423FPV Racing Drone2017-06-30T16:42:13Z<p>Jan: </p>
<hr />
<div>==== Frame ====<br />
Should be 3D printed, current options:<br />
* <strike>[https://www.thingiverse.com/thing:511668 Hovership MHQ2]</strike><br />
* <strike>[https://www.thingiverse.com/thing:1163884 Firefly Pro]</strike><br />
* [http://www.armattanquads.com/chameleon/ Armattan Chameleon (silver)] - not 3D printed, but lifetime warranty<br />
<br />
==== Flight Controller ====<br />
* [http://www.holybro.com/product/46 HolyBro Kakute F4 AIO] - with PDB and OSD<br />
<br />
==== Motors ====<br />
* 2x [https://hobbyking.com/en_us/black-widow-2204-18a-16d-cw-2300kv.html ZTW Black Widow 2204-2300kv CW] - with internal ESCs<br />
* 2x [https://hobbyking.com/en_us/black-widow-2204-18a-16d-cww-2300kv.html ZTW Black Widow 2204-2300kv CCW] - with internal ESCs<br />
<br />
==== Props ====<br />
* 4x [https://hobbyking.com/en_us/gemfan-propeller-5x4-black-cw-ccw-2pcs.html Gemfan 5x4 (CW/CCW)] (2 sets + 2 spare sets)<br />
<br />
==== Low Voltage Warner ====<br />
* [https://hobbyking.com/en_us/hobbykingtm-lipoly-low-voltage-alarm-2s-4s.html HK Lipoly Low Voltage Warner 2S-4S]<br />
<br />
==== LiPos ====<br />
* 2x [https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-3s-35-70c-lipo-pack.html Turnigy Nano-Tech 1500mAh 3S 35-70C] - for drone<br />
* 1x [https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-2s-35-70c-lipo-pack.html Turnigy Nano-Tech 1500mAh 2S 35-70C] - for FPV goggles<br />
<br />
==== VTX ====<br />
* [https://n-factory.de/58GHz-TBS-Unify-Pro-HV-RACE-SMA_1 TBS Unify Pro HV - RACE (SMA)]<br />
<br />
==== FPV Camera ====<br />
* [https://n-factory.de/RunCam-Swift-2-25-Linse-600TVL-FPV-Kamera_1 RunCam Swift 2] - with 2.5mm lens (FOV: 130°)<br />
<br />
==== VTX/VRX Antenna ====<br />
* [https://n-factory.de/58GHz-FOXEER-Antenna-kit-RHCP-SMA Foxeer RHCP SMA Antenna kit]<br />
<br />
==== TX/RX ====<br />
* <strike>[https://hobbyking.com/en_us/i6s-afhds-2a-black-mode2-6ch-radio-with-colour-box.html Turnigy TGY-i6S Digital Proportional Radio Control System (Mode 2)]</strike><br />
* [http://rclife.co.uk/FrSky-Taranis-X9D-Plus-Special-Edition-Carbon FrSky Taranis X9D Plus Special Edition (Carbon)]<br />
* [http://rclife.co.uk/X8R-Receiver FrSky X8R Receiver]<br />
<br />
==== FPV Goggles ====<br />
* [https://hobbyking.com/de_de/quanum-cyclops-v2-fpv-goggle.html Quanum Cyclops v2]<br />
<br />
==== GPS/Compass ====<br />
* [https://www.banggood.com/Ublox-NEO-M8N-Flight-Controller-GPS-with-Protective-Shell-for-PIX-PX4-Pixhawk-p-1005394.html Ublox NEO-M8N]</div>Jan