Choice of microcontroller or FPGA for DIY "Ambilight" - Page 1
Forum section: electronics / general

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 28, 2019, 06:10:35 am
content: I'm building a DIY "Ambilight" and although I'm aware of the implementation that uses a Raspberry Pi, I would like to try doing it in "bare metal". I have a downscaling splitter to tap off a 1080p version of the 4K signal driving the display, then either a HDMI to VGA or HDMI to Svideo converter to convert that into something easy to work with using low cost DIY electronics.I'm leaning towards the Svideo option with a TVP5150A or similar to interpret it since that gives a data rate that could possibly be processed by a microcontroller. Output will be WS2812 LEDs, about 60 along the top edge and 35 on each side.I haven't looked very far into the exact algorithms used for the Ambilight effect, but what sort of processing power should I be looking at if I want the LEDs to update at 30Hz? I'm most familiar with PIC so would a dsPIC or PIC32 be able to do it? Or should I step up to a STM32F4 or even a FPGA?

author: Berni
author_rank: Super Contributor
timestamp: January 28, 2019, 06:26:51 am
content: Well video input buses tend to be a rarity on MCUs. Usually they are found on bigger Linux capable chips from TI,NXP etc... So to look at 1080p video you probably would be best off with a FPGA.But for what you are doing id assume you are mostly just interested in finding the average color in sections of the display. This means you could add glue logic that clock divides the video bus out of a HDMI receiver chip so that it only clocks every 32th pixel cutting down the massive 400MB/s bandwith down to only about 10MB/sBut if you have VGA that makes things even simpler. There the red green blue components of the image are carried in analog form over 3 separate wires. There is no clock to worry about keeping up with the data rate. In fact if you simply terminated the lines into 75Ohm (VGA needs that) and fed the signal into a RC low pass filter you would get roughly the average color of the whole screen as a analog voltage. To do more advanced things you could use a less restrictive low pass filter to only smooth out the time it takes VGA to draw 1/4 of one video row and then feed that into the slow ADC on a MCU. If you time sync your MCU to the Hsync and Vsync signals in VGA you can then know exactly what part of the frame is currently being shown and take it in.

author: JPortici
author_rank: Super Contributor
timestamp: January 28, 2019, 06:47:01 am
content: Quote from: NiHaoMike on January 28, 2019, 06:10:35 amif you're willing to change the LEDs, a guy in the microchip forum came up with an hardware driver for WS2412B using the CLC module in the newest dsPIC33Cit can run with DMA so zero cpu time is spent on drawing the screenhttps://www.microchip.com/forums/m1083323.aspx

author: Berni
author_rank: Super Contributor
timestamp: January 28, 2019, 06:54:21 am
content: Oh neat. Finally i see a cool use for those "baby CPLD blocks" that Microchip sticks onto there MCUs.I haven't worked with these addressable RGB LEDs all that much, but it does look like its a case of a slow communication bus that makes them a pain in the ass to drive in large numbers, not the actual amount of data. So being able to offload an entire string update to the DMA is a huge help.

author: james_s
author_rank: Super Contributor
timestamp: January 28, 2019, 06:55:04 am
content: Somewhere I saw a project to do just that with an FPGA connected to a HDMI source driving an array of addressable RGB LEDs. I don't recall where I saw it though.

author: hamster_nz
author_rank: Super Contributor
timestamp: January 28, 2019, 07:42:08 am
content: If you did want to go FPGA, then this is the level of board you would need.https://www.scarabhardware.com/minispartan6/Updating the LEDs isn't the problem, it is the HDMI clock rates 1485 Mb/s , vs the FPGA SERDES performance.You will also need a splitter that strips HDCP from the HDMI stream, if you intend to use it with copy protected sources....

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 28, 2019, 02:06:49 pm
content: I'm using a cheap HDMI to Svideo converter specifically so that I can take advantage of cheap ASICs to downsample with and take care of supporting all the different formats. Then I'm thinking I could just use a TVP5150A or similar to convert that into a parallel stream that could be interpreted by the parallel slave port on some microcontrollers.

author: Berni
author_rank: Super Contributor
timestamp: January 28, 2019, 04:03:09 pm
content: Yes exactly, its best to just use a whatever to RGB parallel converter chip to do the high speed conversion for you.But do be aware that HDMI 1080p 60Hz uses a pixel clock of about 130 MHz at 24bit colors. So that better be a blazing fast parallel slave port to keep up. When you consider each pixel is 3 bytes you get 390 MB/s. hence why my suggestion to use external logic to skip pixels.

author: tsman
author_rank: Frequent Contributor
timestamp: January 28, 2019, 04:31:04 pm
content: Quote from: hamster_nz on January 28, 2019, 07:42:08 amI found the old blog post I remember from before.Somebody already made an Ambilight clone based on that board. They say the FPGA limits them to 720p operation though. EDID, CEC and HDCP aren't implemented.

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 29, 2019, 12:05:39 am
content: Quote from: Berni on January 28, 2019, 04:03:09 pmHence the route of using a HDMI to Svideo converter and then some video ADC, to take the data rate down to a much more manageable 27MHz on an 8 bit bus. (The Raspberry Pi based Ambilight also does that to avoid having to get an expensive HDMI capture box.)Quote from: tsman on January 28, 2019, 04:31:04 pm1080p support is a must have, so that means the only affordable FPGA able to directly interface with the HDMI would be an Artix 7, quite overkill for this project. Additionally, the existence of affordable splitters with downscaling (to get 1080p from 4K) is what made the project feasible at all - other ways of dealing with that firehose of data are a lot more expensive.

author: lucazader
author_rank: Regular Contributor
timestamp: January 29, 2019, 04:31:22 am
content: If you already have it split into a parallel bus then the DCMI interface on some of the stm32 processors might be useable..?I have never really done anything with this, but just thought i'd plonk it here with an app note in case it is of use..https://www.st.com/resource/en/application_note/dm00373474.pdf

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 30, 2019, 03:17:25 am
content: Quote from: JPortici on January 28, 2019, 06:47:01 amHaven't found much info on WS2412B LEDs (appear to be a higher voltage version for more brightness), but the protocol looks similar enough that the idea can easily be adapted for the WS2812 strips. I already have some ideas on how to clock out the data using two channels of PWM, a SPI peripheral in slave mode, and a little bit of external logic, so the CLC is not a hard requirement. I'm focusing on the video capture for now since that's the harder problem to solve. (Worst case, I wouldn't mind having to use a second microcontroller just for driving the LEDs, although that appears to not be necessary.)

author: Berni
author_rank: Super Contributor
timestamp: January 30, 2019, 06:27:30 am
content: If you are doing for Svideo then you might as well just use Composite instead. The only difference in Svideo is that the chroma and luminance signal is carried on different wires. The chroma signal is still phase and amplitude modulated onto a 3.5MHz carrier, in composite this carrier is simply mixed into the lower frequency luminance signal. So by using Svideo you just make more work for you by needing 2 ADCs that need to run just as fast as 1 ADC used for composite video.So you do still need a ADC runni at least 10 MSPS to capture a NTSC signal. And make essentially a software defined radio to demodulate the chroma signal out of it. You also need to extract the synchronization signals from it to know where you are on the screen and also synchronize yourself to the phase of the color burst at the beginning of each line to get consistent color hue in your colors. And once you have captured the information you have to then convert the HCL color space into the RGB color space.In contrast VGA has the synchronization signals carried on separate pins so they can go right into a interrupt pin on a MCU and the analog R,G and B signals have no modulation on them, just feed it straight into a ADC and grab the RGB value of the current pixel. VGA running at 1080p still needs a 130 MSPS ADC to fully capture, but because its just analog you can simply put the RGB signal trough a low pass filter to average about 100 pixels together and then feed that into a 1.3 MSPS ADC. This then gets into the territory of ADCs that are built into MCUs. So this makes it a 2 chip solution of HDMI to VGA converter chip and MCU driving the LEDs.

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 30, 2019, 02:07:48 pm
content: Video ADCs like the TVP5150A have the color decoding built in.

author: asmi
author_rank: Super Contributor
timestamp: January 30, 2019, 02:17:56 pm
content: Lol what's the point converting digital signal to analog only to be converted back to digital?Use FPGA to downscale FullHD to whatever resolution you want while still keeping it all-digital. The simplest 4x averaging (2x2 square) will result in 960x540 frame, if that's still too much - do it again to get 480x270 frame. Or you can use non-cardinal dividers for more flexibility, but slightly higher complexity. If you don't feel like coding this in HDL, you can use HLS tools to generate the code for you.

author: janoc
author_rank: Super Contributor
timestamp: January 30, 2019, 02:37:28 pm
content: This has been done quite a few times:http://zerocharactersleft.blogspot.com/2015/04/diy-fpga-based-hdmi-ambient-lighting.htmlhttp://hacks.esar.org.uk/hdmi-light-v2/https://hackaday.io/project/694-ambicontrollerAnd probably a few more. You won't find one using a microcontroller and a HDMI/DisplayPort style input for the reasons described by others above.The implementations that use a micro/Raspberry Pi rely on a modified media player that extracts the necessary color information from the image and feeds it to the device e.g. over USB or GPIO (Raspberry Pi). As a consequence, such implementation doesn't work with anything else but that modified media player program.

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 30, 2019, 11:51:58 pm
content: Hyperion supports using USB capture boxes, most users opting for the HDMI to Svideo converter since that plus a Svideo capture box ends up way cheaper than any HDMI capture box. But I would like to try an implementation that does not require an OS.Quote from: asmi on January 30, 2019, 02:17:56 pmThe cheapest FPGA that can handle 1080p HDMI directly is the Artix 7, the cheapest board with that I can find is about $60. (Using a universal HDMI input board allows the use of a much cheaper FPGA but that board itself costs about $20.) The output is such low resolution that even Svideo is overkill. A HDMI to Svideo converter is about $8 and Svideo ADCs are super cheap.

author: asmi
author_rank: Super Contributor
timestamp: January 31, 2019, 01:36:42 am
content: Quote from: NiHaoMike on January 30, 2019, 11:51:58 pmBut in case of FPGA you can implement LED control logic directly inside that FPGA and will not need any external components. This will also allow achieving very high refresh rates and/or very sophisticated control algorithms. In any case needless conversions are just wrong thing to do IMHO regardless of price.

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 31, 2019, 03:31:21 am
content: I think someone tried a HDMI capture box with the Raspberry Pi Ambilight and found it had basically no advantage over the HDMI to Svideo converter + Svideo capture box solution for that use. As for latency, the Raspberry Pi is going to be at a big disadvantage - a microcontroller solution should have no problem getting less than one frame of latency. At this point, it looks like my best bet is to start with a high end dsPIC or STM32.I found this device that claims to do it with some M4 microcontroller, sadly not open source.https://www.scimolight.de/index-en.html

author: james_s
author_rank: Super Contributor
timestamp: January 31, 2019, 04:49:32 am
content: I have not tried this, but you may be able to get away without capturing anywhere near the whole image. Ambilight is very low resolution, effectively just a handful of "pixels" and all that really matters is the edges of the picture. You could probably do some sampling at approximate locations in the picture and average the color value. I doubt you'd ever see a difference between grabbing a full 1080p frame in one shot over HDMI or capturing at a much lower rate over composite video at the other extreme. A technique as used by the old sampling oscilloscopes might let you get by with much lower performance hardware, video is roughly a repetitive signal, changes in the image occurring at a far slower rate than the pixel clock.

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 31, 2019, 06:00:27 am
content: Doing equivalent time averaging over multiple frames would not work for more than a few frames as it would cause ghosting. But it is correct that the data near the middle can simply be ignored - that's time better spent processing the samples previously captured.One advantage of using Svideo instead of composite is the possibility of adding some analog filtering to the Y (intensity) signal in order to be able to skip some of the Y samples. That won't work on the C (color) signal since it's modulated on a carrier. I have looked at HDMI to YPbPr converters but the cheap ones seem to just be HDMI to RGB converters with some additional circuits to convert the RGB to YPbPr, so no downscaling that I'm looking for.

author: Berni
author_rank: Super Contributor
timestamp: January 31, 2019, 06:29:26 am
content: Yes but the point of analog RGB is that no modulation is used, so that your downsampling can simply be done with a analog low pass filter. But as far as i know YPbPr used in component video are also non modulated just like RGB so you could also use the same analog low pass filter downsampling trick. Tho i do admit its a bit of a hack to use analog video just to downsample it and then use a ADC on it right after. But it is a low cost and low effort solution.The more proper solution would involve a HDMI to DPI RGB converter chip feeding into a cheap FPGA that then drives the LED strings directly. Its a bit more expensive and involves annoying FPGA software development but it would give optimal performance.Yes you can feed HDMI directly into a FPGA but the datarate is about 1.5Gbit per lane so that means a pretty expensive FPGA that has some fast enough pins or transceivers to handle that. So its likely cheaper to simply add a HDMI to DSI RGB converter chip and use the cheapest reasonable FPGA you can find.

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 31, 2019, 02:21:08 pm
content: If I were to target mass production (I'm not), most likely the cheapest way to make it work would be one of those HDMI mini monitor chipsets that can downscale very low, plus a Lattice FPGA. But for a hobbyist, it's basically impossible to get the former already mounted on a board for a reasonable price.

author: Berni
author_rank: Super Contributor
timestamp: January 31, 2019, 06:07:05 pm
content: I have a 10 inch 1920x1200 touchscreen monitor with one of these boards in it, but because i wanted to modify mine i went and bought a replacement board for it to be safe. Manged to get it for 6 USD on aliexpress i think. Its a board that takes in HDMI,VGA, Composite etc and outputs LVDS at the correct resolution to drive the LCD panel. It also provides menus for setting stuff, generates the power rails from 12V input and drives stereo speakers.It uses a chinese chip that all of these boards use and you can buy only the chip if you look around for long enough. Tho it does also need firmware to go along with it, that's what configures it how to drive the LCD panel correctly and what resolutions to use.

author: james_s
author_rank: Super Contributor
timestamp: February 01, 2019, 01:40:06 am
content: I hadn't even thought of those. Some of those small TFT driver boards are not even LVDS, their output is simple 3.3V logic, digital RGB lines, hsync, vsync and a dotclock. Piece of cake to interface to an FPGA.

author: Berni
author_rank: Super Contributor
timestamp: February 01, 2019, 06:47:24 am
content: Well once you get past 720p resolution the old school parallel RGB bus seams to disappear because the clock rates start becoming so high.But LVDS can be pretty nice for FPGA interfacing. It tends to use more pairs at higher resolutions so the clock speeds stay lower and you can often get away with a soft serdes on cheap FPGAs. And LVDS uses the standard serdes encoding schemes so the serdes block in the FPGA will know how to synchronize and decode it out of the box, spitting out raw RGB data out the other end. LVDS is also directly logic level compatible with FPGA pins (HDMI needs level shifting if you go by the book). With these high resolution displays i seen things like a dual 4 lane LVDS bus, this means 8 data diff pairs + clock. For 1080p 60Hz this brings the bitrate per lane to 500Mbit and its quite common to have 500 to 900Mbit soft serdes support in low end FPGAs.Tho the nice simple LVDS interface is getting replaced nowadays with more complicated buses such as MIPI DSI or eDP.

author: cobusve
author_rank: Newbie
timestamp: February 01, 2019, 09:00:17 am
content: I quite liked this approachBack in the day I remember reverse engineering a video motion detection system which allowed you to select (using a mouse) regions on the tv and then detect motion in those areas. Yes seems trivial, the thing is this was implemented using a 8051 running at 10MHz!The secret sauce was that they detected the H-sync and V-sync on a stadard PAL signal in hardware, and then used 2 GAL20V8's to generate a pixel clock, sample the image and generate a bit stream into the device representing a low-resolution pre-processed signal.Using the approach above with a cheap PAL camera, or even just a couple of 1-pixel color sensors you could do a pretty interesting DYI implementation with pretty much any microcontroller you can buy todayYou could e.g. for a crude version mount one of thesehttps://www.digikey.com/product-detail/en/broadcom-limited/APDS-9160-003/516-4303-6-ND/9740445at each corner of your TV and then use some WS2812's behind to match the colors interpolated between the corners ... That you can probably do with a little 8-bitter using only I2C and a couple of I/O pins.

author: Lunasix
author_rank: Regular Contributor
timestamp: February 02, 2019, 05:37:25 pm
content: I'm used to drive WS2812 with PIC32. I simply use SPI with DMA channel and a single level shifter to have 5V signal. In order to code 0 and 1 for WS2812, I simply use a spi clock 5x faster (4MHz), each WS2812 bit is then coded with 5 spi bits (10000 or 11100 for example), and the table is computed before DMA start. Each led (24bits) need 120 spi bits, but it's not a real problem for a PIC32 with a lot of RAM. The SCK io is not really used and SDI input is driven at the right level to have the wanted SDO level when no data is shifted out (SPI shift out SDI input). Tested with 40 WS2812.On a PIC32MM, for which I had forgotten there was no DMA, I used normal SPI interrupt and it works well in that case because I have only 3 leds and a low refresh rate, 3 interrupts for 1 led would be too much in other cases, and you must prevent delay between 2 spi words (32bits) to prevent timing errors and then color errors.

author: NorthGuy
author_rank: Super Contributor
timestamp: February 02, 2019, 07:34:17 pm
content: Quote from: Lunasix on February 02, 2019, 05:37:25 pmFor this timing, it's easier to use UART with inverted output. This way you need only 4 bits for one LED bit (one byte is needed to encode 2 LED bits). Two extra bits (start and stop bits) get emitted by UART automatically. This is easier to encode and takes less space.

author: Lunasix
author_rank: Regular Contributor
timestamp: February 02, 2019, 07:51:01 pm
content: Good idea ! I will try. But without DMA (not advised), uart will need more interrupts as fifo is 8 x 8 for uart and 4 x 32 for spi. And calcul will be more efficient for UART... To be compared.

author: NiHaoMike
author_rank: Super Contributor
timestamp: February 02, 2019, 08:00:01 pm
content: There also appears to be a way to do it with two PWM outputs set to the two required duty cycles, a SPI module synchronized to the PWM, and the CLC or external logic selecting the correct output based on what the SPI module is outputting.

author: Lunasix
author_rank: Regular Contributor
timestamp: February 02, 2019, 08:53:47 pm
content: Yes, could be a better idea ! I will think about it.

author: NiHaoMike
author_rank: Super Contributor
timestamp: February 05, 2019, 12:54:22 am
content: Surprise, surprise, Ben Heck just did a video about interfacing SPI to WS2812 LEDs!