Project related links:
hardware based TV Ambient-Light "SCIMO" - Project Status
Project Status and News
- 27. July 2016 - release of firmware V2.5
- 02. May 2016 - SCIMO available to buy
- 01. March 2016 - release of firmware V2.4
- 06. February 2016 - second prototype of SCIMO V1.2 enclosure (3D printed)
- 22. January 2016 - first prototype of SCIMO V1.2 enclosure (3D printed)
- 28. October 2015 - release of firmware V2.3
- 1. July 2015 - release of firmware V2.2
- 11. May 2015 - release of firmware V2.1
- 14. March 2015 - hardware redesign "SCIMO V1.2"
- 18. January 2015 - release of firmware V2.0
- 23. July 2014 - release of firmware V1.2
- 4. July 2014 - support of 3D-TOB content
- 22. February 2014 - support of 3D-SBS content
- 21. February 2014 - additional surround LEDs (DMX512 based) finished
- 21. December 2013 - dual composite video input
- 23. November 2013 - adding new functions in firmware (IR code sets, user defined static LED color)
- 29. September 2013 - added new section: SCIMO Installation
- 06. September 2013 - supporting more zones (240), testing new LED stripe "WS2812B"
- 02. September 2013 - IR remote control support done
- 10. August 2013 - configuration of SCIMO using "config.ini" file
- 22. July 2013 - FAT32 filesystem and firmware update (IAP) using USB Interface is working
- 6. July 2013 - hardware redesign "SCIMO V1.1" finished
- 16. June 2013 - USB Interface is working (mass storage device)
- 11. June 2013 - Auto Power on/off
- 12. May 2013 - supporting TM18xx based LEDs stripes
- 07. May 2013 - finished test for Composite video input signal
- 02. May 2013 - publish some new demo videos showing 170 channel Ambient-Light (link: demo videos and pics)
- 28. April 2013 - added some video preprocessing feature
- 24. April 2013 - supporting now more zones in Ambient-Light mode (up to 200 zones / LEDs )
- 20. April 2013 - added support for digital RGB LEDs WS2811 / WS2812
- 24. March 2013 - reached biggest milestone: process 50fps (PAL) in realtime (added video of SCIMO in action)
- 04. March 2013 - compensate display input lag from TV
- 01. March 2013 - started first tests using TV setup (S-Video signal)
- 10. February 2013 - checked LED power supply and data transfer over DMX512-Bus at heavy load (50 RGB-LED)
- 23. January 2013 - assembled digital (DMX-512) RGB LED stripes
- 03. November 2012 - reached a milestone: successfully sampled test image with SCIMO
- 19. Juli 2012 - finished some hardware tests (voltage regulators, analog backend of video interface, digital backend of video interface: ITU-R BT.656 - DCMI, I2C, LED Interface: DMX512, JTAG, SWD, LED)
- 29. April 2012 - received PCB, finished assembling (hand soldered)
- 10. April 2012 - finished schematic and PCB design, order PCB prototyp
|PAL||Input Color Format: PAL (B, D, G, H, I, M, N, Nc)||done||high||1.0|
|NTSC||Input Color Format: NTSC (J, M, 4.43)||done||high||1.0|
|SECAM||Input Color Format: SECAM (B, D, G, K, K1, L)||test needed||low|
|S-Video||analog video input signal: S-Video (Separate Video) aka Y/C aka S-VHS||done||high||1.0|
|Composite||analog video input signal: Composite aka CVBS (Composite Video Baseband Signal)||done||medium||1.0|
|widescreen||adjust video zones to widescreen signal at runtime||done||high||1.0|
|video processing||some configuration points to have more influence on Ambient-Light behavior like: ||partly done||medium||1.0|
|TM18xx||digital RGB LED or LED stripe based on IC: TM1803, TM1804, TM1809, TM1812||done||high||1.0|
|WS2801||digital RGB LED or LED stripe based on IC: WS2801||discarded||-||-|
|WS281x||digital RGB LED or LED stripe based on IC: WS2811 / WS2812 / WS2812B||done||high||1.0|
|DMX512||Transmission protocol DMX512 to connect e.g. stage lighting RGB LED spot or small digital RGB LEDs like: led-nanoit||done||high||1.0|
|analog LED stripe||support for analog LED stripe (four RGB channels) using PWM||discarded||-||-|
|USB||identify as an USB mass storage device on PC||done||high||1.0|
|firmware updates||firmware updates using USB Interface (mass storage device)||done||high||1.0|
|Auto Power||automatic power on/off dependiing on video input signal||done||medium||1.0|
|configuration||configure SCIMO (e.g. LED Interface type, LED quantity, LED position...) using USB Interface (MSD)||done||high||1.0|
|save configuration by remote control||saving changed configuration (red, green, blue, gamma, 16:9) using IR remote control -> IR button "Exit"||done||medium||1.0|
|IR remote control||control some SCIMO basic function with remote control: ||done||medium||1.0|
|audio in||sound to light control||discarded||-||-|
|enclosure||CAD drawing of some nice enclosure for SCIMO PCB||done||medium||-|
|MoodLight||video independent light mode||done||low||1.0|
|selectable IR code set||support of different IR code sets which can be choosen by config-file||done||medium||1.1|
|user defined color||By config file a user defined static color can be used as moodlight profile and also for onboard RGB LED.||done||medium||1.1|
|surround LEDs||Some additional surround RGB LEDs controlled over DMX512 protocol.||done||medium||1.2|
|3D support||Support of 3D content (3D-SBS, 3D-TOB)||done||medium||1.2|
27. July 2016: firmware V2.5 released
What has been changed ?
- feature added: At moodlight-mode the LED colors can be selected directly using colored buttons at remote control (red, green, blue, yellow).
2. May 2016: SCIMO is available to buy
Finally it is possible to buy SCIMO at a online shop which i also offer worldwide shipping.
This online shop is well experienced in LED lightning using different technologies and now also offers SCIMO to buy: SCIMO buy online
1. March 2016: firmware V2.4 released
What has been changed ?
- feature added: new parameter added OP-MODE where prefered operation mode (moodlight, ambient-light) after startup can be defined
- feature added: new parameter added SKIP_INTRO which allows to skip LED intro during startup
- improved: onboard LED videostate are sometime showing unclear status when USB is connected
06. February 2016 - second prototype of SCIMO V1.2 enclosure (3D printed)
Next prototype of enclosure arrived and it looks pretty fine. It was produced again by SLS "selective laser sintering" technology and is now available for everbody.
More details can be found here: SCIMO V1.2 enclosure
22. January 2016 - first prototype of SCIMO V1.2 enclosure (3D printed)
Now finally a first prototype of the SCIMO V1.2 enclosure are done.
It was produced by SLS "selective laser sintering" technology which makes some really good impression. Dimensions are very accurate and fits very well to connectors and board, the surface is not smooth but pretty nice and it seems to be quite stable. But i will make some smaller optical modifications at CAD drawing and also try next time a black enclosure.
Assembling of this enlosure is very easy, just flip in the board and stick in the three optical prismas into the holes (for LEDs and IR sensor), there is no glue needed. Four screws at the bottom are fixing everthing, thats it.
28. October 2015: firmware V2.3 released
What has been changed ?
- feature added: new parameter added 3D_MODE where prefered 3D-mode can be preselected by definition at configuration file
- improved: now all Moodlight modes are making use of defined brightness und color settings from configuration file (maybe need to readjust MOOD_USER_COLOR).
- bugfix: DMX512 surround LED-channel do not work properly in some cases (at SCIMO hardware V1.1)
1. July 2015: firmware V2.2 released
What has been changed ?
- feature added: Extended parameter IR_CODE_SET because there are different hardware versions of remote control available, URC-3920 R02 and URC-3920 R03 where buttons "3" and "4" are interchanged. More details can be found here: IR remote control
- bugfix: In some cases NTSC videosignal was not detected
11. May 2015: firmware V2.1 released
At this new firmware version i just added support for new hardware version "SCIMO V1.2", there are no new feature added.
14. March 2015: hardware redesign "SCIMO V1.2"
A new hardware version of SCIMO is finished and first prototype is running fine. Reason for this redesign was to have a smaller board and to reduce component count.
Board size has been reduced about 30% and component count about 25%.
More details can be found here : SCIMO V1.2 hardware desciption
SCIMO V1.1 in compare to SCIMO V1.2
|hardware version 1.1||hardware version 1.2|
|dimension||71 x 64 mm||60 x 50 mm|
|LED type||WS281x, TM18xx, DMX512||WS2811, WS2812, WS2812B|
|videosignal in||S-Video, Composite, dual Composite||S-Video, Composite, dual Composite|
|USB connector||USB 2.0||USB 2.0|
|enclosure lightning||RGB LED||none|
|power supply in||5 - 12 Vdc , 11 ampere||5 Vdc , 11 ampere|
|IR remote control||yes||yes|
|onboard power switch||yes||yes|
|switched LED power||yes||yes|
|onboard LEDs||2 x dual color||2 x dual color|
18. January 2015: firmware V2.0 released
What has been changed ?
- changed: configuration file "temp.ini" are no more used, instead configuration files "config1.ini" - "config6.ini" are now used
- changed: "configuration save" with remote control are now written to last selected configuration file (before it was always saved to "temp.ini")
- added: at startup the selected configuration file are shown by flashing power LED (for example: at "config3.ini" LED is flashing 3 times)
- added: up to six configuration files are now possible
- added: startup behavior in case of power brownout (off, on) can be defined by parameter
- added: separate buttons on remote control for power: on/off, mode: ambient-light/moodlight
- added: automatic standby mode when device is running for long time (default: 8 hours, can be defined by parameter)
- added: parameter(s) where starting point (lower left corner) of LED stripe and data direction can be defined
- improved: much more better performance on file operations (saving configuration...)
- improved: reaction time on power button (onboard)
- improved: data refresh rate to LED stripes
- improved: precision of video zones position <-> LEDs
- improved: reation time on IR commands
- improved: boarder detection works better at dark videocontent
- bugfix: firmware freeze when changed signalsource from PAL to NTSC during runtime
23. July 2014: firmware V1.2 released
What has been changed ?
- feature added: 3D support (3D-SBS, 3D-TOB)
- feature added: support of surround LEDs using DMX512 protocol
- feature added: automatic recreation of config file "temp.ini" in cases of miss
- improved: boarder detection (16:9, 4:3...) delivers reproducible results
- improved: vertical size of LED zones are now calculated in respect to video format (16:9, 4:3...)
- improved: algorithm for LED color calculation improved by performance and precision
- improved: file operations on SCIMO MSC drive improved by performance
- bugfix: in some cases the status of videosignal was not shown correct at onboard LED (red/green)
- bugfix: in some cases parameter "VideoSource = composite" was ignored
- bugfix: in some cases it was not possible to change Moodlight mode to other than "1"
04. July 2014: Support of 3D-TOB content
Firmare now also supports 3D-TOB (top over bottom) content. This mode can be selected by pressing again the button "Guide" on IR remote control.
22. February 2014: support of 3D-SBS content
I started to include support of 3D-SBS (side by side) from SCIMO. For this some modification in video preprocession was necessary and first version is looking good. Until now not all types of 3D content is supported but nearly 85%. Mainly some animation movies are not supported.
3D support can be activated by pressing "Guide" button on IR remote control. This feature is available since firmware version 1.2.
21. February 2014: additional surround LEDs (DMX512 based) II
Development is finished and a new section with some additional information is available: surround LEDs (DMX512)
For this feature some new parameters are available which allows to configure surround LED channel independently from normal LED outut (like: RGB correction, color averaging, gamma correction, brightness min / max ).
29. December 2013: additional surround LEDs (DMX512 based) I
For a while i was thinking about to extend Ambient-Light feature to complete living room and not only restricted to some space around TV. To make this done i want to use some RGB LED stripes in backside of room and let them directly control from SCIMO, additional to digital WS2812 LED stripes behind TV.
First problem i'm faced with is that i need to bridge some distance (SCIMO <-> surround LEDs) of about 10 meter. With normal LED stripes (like WS2812) this can't be done because data signal is based on normal TTL-levels with 800 kHz and after 10 m of cable there won't reach something usable the LED stripe. So i decided to use a DMX512 based system (which can easy bridge 10 meter and much more) to control some LEDs in backside of room. To be more exact i'm using a "DMX512 to RGB" converter where i have connected round 3 meters of simple LED stripes. The mentioned "DMX512 to RGB" converter can be get at moderate price for about 20€ and is able to drive 3 x 4 ampere by 12V for simple LED stripes. Also those simple RGB LED stripes can be get for less then 5€ per meter, so overall cost won't be very high.
Below i have added connection scheme to give a better overview:
21. December 2013: dual composite video input
A new feature has been added to firmware which allows to connect two composite video signal sources to SCIMO and make them selectable through config file. This allows to switch very comfortable between different video sources (e.g. TV and PS3) by IR remote control without changing wiring to SCIMO.
To make use of this feature it is necessary to have composite video signals (not S-Video signal) and use a special cable adapter which has S-Video plug (male) on one side and two composite plugs (female) on other side. The desired composite signal can be chosen in config file by parameter "VideoSource" setting to "compositeA" or "compositeB".
23. November 2013: adding new functions in firmware
Firmware has been improved and some new functions and configuration parameters has been added.
- To avoid conflicts with other IR devices (for example TV) it is possible to tell SCIMO that an alternative IR code set should be used. Additional also IR remote control has to be reprogrammed but this is very easy because of use from universal IR remote control "One for All", just simply program alternative device code. An other use case is that two devices of SCIMO can be controlled separately by IR remote control because of different code sets.
- Added user defined Moodlight profile (key"5") which allows to use an static color for LED stripes. Also onboard RGB LED can be set to an fixed color if random mode is not desired.
A detailed description of all available parameters can be found here: Software description
29. September 2013: added new section "Installation"
Under this link: SCIMO Installation i added a new section which describes how LED stripes are connected to SCIMO and installed at TV / Monitor. Additional i have added some more information about available configuration parameters on SCIMO.
06. September 2013: supporting more zones (240), testing new LED stripe "WS2812B"
Some weeks ago i received new digital LED stripe based on IC "WS2812B" which is integrated in LED. This new version has some technical improvements (brighter, wrong polarity protection...) and use same protocol like old version. I just make some test with this new stripe and think it is up to now best choice for Ambient-Light solution.
At this time i also improved firmware and increased support for more LEDs (zones), now up to 240 zones can be controlled from SCIMO.
02. September 2013: IR remote control
Last days i invested some time in finding good concept for IR remote control support.
I was faced two main question:
- Which remote control should i use ?
- Which features are makes sense to be controlled by IR ?
For first point i deceided to use a simple universal remote control from "One for All" (company name). This remote control can be get at low price, is worldwide available and offers good quality (my personal feeling). Because i use a very common IR code, any other universal remote control can be used too.
For second point i build two groups of features to be controlled by IR:
- operation mode selection: power on/off, switching between Ambient-Light/moodlight, configuration profile selection, moodlight mode selection, start/stop, widescreen detect
- configuration fine tuning in Ambient-Light mode: color ajustment (red, green, blue), averaging time, brightness, contrast, saturation
Especially the option to fine tune configuration in realtime by remote control helps to find best settings faster and is more comfortable then editing configuration file. More features will follow by time...
10. August 2013: configuration of SCIMO using "config.ini" file
Now finally this milestone is reached too and SCIMO can be configured by user using simple text file. SCIMO supports up to three predefined config profiles which can be easily selected by remote control. To use this feature just give the new config file the name "config1.ini" and and copy it to MSC drive, it will be used from SCIMO as profile 1. In the same way profile 2 is using the file "config2.ini" and so on...
This text file contains various parameters like:
- LED number: left, right, upper, lower (max. 200 overall)
- min. / max. brightness (0 - 100%)
- video delay (0 - 400ms)
- contrast, brightness,saturation (0 - 100%)
- gamma correction (0.10 - 9.99)
- adjustable: red, green, blue (0.00 - 1.00)
- LED stripe type: WS281x, WS281xB, TM18xx, DMX512
- Video Source: svideo, composite
- image averaging time: (0.00 - 20.0)
22. July 2013: writeable FAT32 filesystem and firmware update (IAP) using USB Interface is working
Some good news, as mention some days before i was working on USB Interface and developing an MSD (Mass Storage Device) on SCIMO to make firmware updates and configuration of SCIMO possible without special driver needed on PC OS (like Windows, Linux...). ...and finally FAT32 and firmware updates are working.
To make this running it was necessary to support a readable and writeable FAT32 filesystem on SCIMO which was a bit more tricky than i was expecting. The reason for this problem are structure of microcontroller flash where FAT32 filesystem is non volatiled stored. Microcontroller is offering its flash in sector sizes of 128 kbyte which can only be erased at onces but not in single bytes. A FAT32 filesystem (which is supported from windows) needs to work with much smaller sector sizes (for example 512 bytes). So i needed to develop an algorithm which is working as a bridge between those two worlds (128 kbyte microcontroller flash sector <-> 512 byte FAT32 sector) and this without wasting massive RAM space on microcontroller.
After this algorithm is working and firmware file can be saved on SCIMO mass storage device the rest was done very fast. I just included an bootloader which is checking on every reboot of SCIMO for new firmware file on FAT32 filesystem and installing new firmware if found one. In same boot sequence firmware file is renamed from "firmware.bin" to "firmware.bak" to avoid an reinstall on every reboot of SCIMO.
As next i need to care about configuration file on SCIMO MSD. But i did not expecting as much problems than on last point (FAT32)...
6. July 2013: hardware redesign "SCIMO V1.1" finished
I decided to redesign SCIMO hardware and make a new board: SCIMO V1.1 .
The new version is based on last hardware concept (same core components) but has been optimized for it's primary function which is TV Ambient-Light.
For this optimized version some feature / components has been removed:
- audio TOSLINK connector removed (connector is meanwile not easy to get and thus too expensive)
- No more direct support of simple (analogue) LED stripes. But still can be connected by using external "DMX512 -> RGB adapter".
- Removed onboard Composite connector, instead composite signal can be connected to SCIMO using S-Video connector and a very small adapter.
The new version V1.1 contains following improvements:
- switchable power supply of LED connector (to avoid idle current of digital LED stripes when SCIMO is shut off)
- more power for LED stripes, now up to 11 ampere possible (old version V1.0 has 3 ampere)
- much smalller PCB and reduced component count (reduced PCB size about ~44%)
- rearranged connectors: all connectors now accessible from on side (gives clearer wiring of SCIMO)
- For better power efficiency of LED power, removed internal Step-down regulator. Now using pass-through from power input of SCIMO.
From the new board i have already assembled some prototypes and successfully tested. More infos to new version can be found here: SCIMO V1.1 hardware desciption
assembled PCB Scimo V1.1 topside:
16. June 2013: first steps for USB Interface are done
I deceided to implementing a USB mass storage device on SCIMO. This has the advantage that no special driver are needed on PC OS (Windows, Linux...) and it will instantly run on any PC.
So if SCIMO is connected to PC it will identify as an USB mass storage device (like an usual USB stick) and it becomes available as an additional drive. On this drive will be at least two files available:
- XML based configuration file (text file)
- firmware file (SCIMO firmware)
The XML based configuration file contains all possible parameters for SCIMO and can be edited by normal text editor or a special application (in development) which has an GUI (Graphical user interface) and helps user to configure SCIMO properly.
A firmware update of SCIMO is done very easy by simply copying new firmware file to drive. Thats all.
What is at the moment working from USB ?
First steps are successfully done and USB Enumeration process is working. This means that if is SCIMO is connected to PC it will identify as an USB mass storage device and PC will load default drivers and a new drive becomes available.
As next i need to add function for parsing XML configuration file, processing new firmware file and supporting FAT file system.
11. June 2013: Auto Power on/off depending on input signal
As described in feature list SCIMO is now able to automatically power off if no input signal is detected (timeout 15 seconds). In same way it wakes up from input signal, but only if it has entered power-down mode before automatically . So if SCIMO was powered off by remote control or switch, it stays off and won't awake from input signal.
I think this procedure is the best one to match user expectation:
- if user want to use automatic power mode he do not need to do something
- if user power off SCIMO manual (by remote control or switch) SCIMO goes off and stays off
Additional i added new feature to hardware and SCIMO is now able to switch off power supply from LED connector. This helps to avoid idle current from LED stripes if SCIMO is power-down. (thanks to Milos V. for this advice)
20. May 2013: comparing different LED pitch for Ambient-Light
I just received the question if maybe higher LED pitch (60 LEDs per meter) gives better Ambient-Light feeling. So spent some hours and make direct compare between 30 LEDs per meter and 60 LEDs per meter.
For this test i used in both cases same LED stripe (WS2812) and same configuration of SCIMO, which means that defined video zones are identical and used same signal source (PS3, HDMI), distance from TV to wall is round 15cm. The used LED stripe is equiped with 60 LEDs per meter, so i deactivated every second LED (in SCIMO firmware) for test with 30 LED per meter.
I tried to figure out some visible difference but i have to save that it looks identical to me and higher LED pitch won't give better Ambient-Light feeling or higher visible resolution of LEDs colors. The only difference that was visible for me is that 60 LEDs per meter looks a bit brighter. The reason why it looks like just a bit brighter and not twice (as maybe expected) is caused from human brightness feeling that is not linear even more a exponential function (thats also the reason why gamma correction needs to be done with LED colors).
The visible Ambient-Light resolution (light from LEDs reflected on wall behing TV) is for my feeeling a bit better when using 30 LEDs/meter, but not really much. To get a better visible Ambient-Light resolution it is necessary to place the TV as close as possible to the wall to reduce light mixing of neighbored LEDs.
Another way to increase visible resolution is to use LEDs with smaller viewing angle (less then 120°) which also has the advantage that brighness becomes visible higher. But all digital LED stripes that i have seen so far are using LEDs with 120° viewing angle, so this is badly no option...
From both tests (30 LEDs/meter and 60 LEDs/meter) i maked a video, so you can compare on your own:
|30 LEDs per meter||60 LEDs per meter|
16. May 2013: using HDMI signal (PlayStation 3) as input source for SCIMO
Yesterday i was taking some time to check how Ambient-Light SCIMO feels in combination with PS3. Because i didn't want to use composite output of PS3 for my TV (reduced image quality) i was using HDMI signal and feed it into SCIMO by using external "HDMI to S-Video" converter device (see connection diagram below). Like my TV also this HDMI converter has an display input lag of round 200ms. This means that the video signal is delayed from input (HDMI) to output (S-Video) of round 200ms and i needed to configure SCIMO that no additional signal delay is inserted in LED data stream (see also my post from 05. March 2013). After that i got Full-HD image on TV and working Ambient-Light syncron to video image on TV.
For this test i used again WS2812 based LED stripes with 170 channels (every of this 170 LEDs has his own zone), on horizontal sides i have 2 x 53 LEDs and on vertical sides i have 2 x 32 LEDs -> 170 LEDs.
I will publish next days some new demo videos showing SCIMO in combination with some PS3 ingame scenes...
[18. May 2013] ...done, new videos can be found here: demo videos and pics
12. May 2013: support TM18xx based LED stripes
Last days i received some pixel of TM18xx based LED stripes ( TM1803 and TM1812 ) and was able to check if they working too with SCIMO. As i mention some days before the communication protocol from TM18xx looks very close to WS2812 LED stripes except a bit different timing. But for my surprise that was not the only difference, TM18xx is expecting a different order of data bytes (colors) than WS2812. As a result TM18xx was showing wrong colors, to be more exactly green and red was interchanged. But this was easily adapted in firmware (also timing) and now SCIMO is able to support TM18xx based stripes too.
07. May 2013: video input connector "composite" is working too
Up to now i have done my tests using video input connector S-Video.
Now it was time to check if video input connector "composite" is working too and if reduced video quality of composite signal has influence on Ambient-Light function. First of all i can say that Ambient-Light function is also making good impression when using Composite signal, used video decoder "TVP5150" is making good job.
In direct compare between Composite and S-Video as input source for Ambilght function, i got the feeling that S-Video gives a bit more brilliant colors and a bigger dynamic range of LED colors. But thats not surprising, S-Video makes use of two wires and delivers luma (luminance) and chroma (colour) is separate channels which results in better image quality. I'm only suprised about the small difference that can be seen in Ambient-Light mode, i expected a bigger influence...
So all in all i can say that both input connectors (S-Video and Composite) working correctly and my suggestion is to use S-Video where it can be choosen.
28. April 2013: added some video preprocessing feature
I have modified firmware that user is able to configure some video preprocessing feature. In details i have included configuration values to define:
- min. brightness: LEDs won't set darker than this value, helps to keep a minimum of brightness from back of TV which is more relaxed for eyes.
- max. brightness: LEDs won't set brighter than this value, usefull if LED stripes equipped with very bright LEDs.
- color adjustment (red, green, blue): Usefull to fine-tune colors from LED stripe to match colors from TV.
- gamma correction: This value has big influence on Ambient-Light behavior, a lower value (e.g. "1.5") has the effect of smoother color mixing and is more relaxed for eyes. A bigger value (e.g. "2.4") gives more exciting color effects with sharper and saturated colors, which is for example nice at action games. This value has also big influence on color matching.
Remaining point blurred video feature still needs to be done...
Blurred video is a feature that allows user to adjust how precise the LED zones are (imagine a picture going out of focus), this is good for getting more averaged LED colors over video frame and not hard restricted to defined video zone. Request from Justin B. , thanks for suggestion
24. April 2013: support for 200 zones (LEDs) in Ambient-Light mode
Next biggest milestone is reached and i can say that SCIMO is able to support up to 200 zones in Ambient-Light mode. As mention above i have optimized some function to reduce calculation time (especially gamma correction) and now SCIMO is able to control up to 200 LEDs separately. This means that in Ambient-Light mode for every LED a suitable color is calculated in realtime and refreshed with 50fps at PAL/SECAM video input signal and with 60fps at NTSC.
I will publish a new video in next days, just need to organize a better camera than last one which has better video quality especially at dark scene...
Some more words to WS28xx based LED stripes:
For my test (checking maximum zones = 200) i used WS2812 digital LED stripe equipped with 60 LED per meter. As expected this is a very close LED pitch (~17mm) for TV Ambient-Light function and less LEDs per meter would give better backlighting experience (sharper color effects). In my first test i used DMX512 based digital LEDs with 15 LED per meter where i got the feeling that i can see position of LEDs on back of TV.
So i think best solution is to use LED stripes equipped with 30 LED per meter which are also available with WS2812 IC. And of course stripes with less LEDs per meter are cheaper and need less power.
In my test i also take a closer look on brightness and color stability compared between the start (where power is injected) and the end (faraway from power injection) of LED stripe. There i have seen no difference between start and end of stripe which is a big advantage of WS28xx based stripes. WS28xx IC include a feature (constant current) to compensate voltage drop across the stripe, this helps to get stable color and brigthness output of each LED independend of temperature, unit dispersions and supply voltage (a minimum of voltage is still required).
A supply voltage drop across stripe, on those without integrated constant current drive, will result on some LED stripes in visible loss of brightness and color shift which is specially visible at white (all three color active). For example white becomes more violett because green part (LED) needs highest forward voltage and thus first effected from voltage drop.
Where it is necessary to compensate voltage drop across stripe, this can be done by injecting power supply on one or more points along LED stripe (for example every 2-3 meters) and not only at beginning or end of stripe . But as i still mention WS28xx based stripes do not need this technique if stripe is not too long.
20. April 2013: support of digital LEDs "WS2811 / WS2812"
Last days i received digital LED stripe based on IC WS2811 aka WS2812 equipped with 60 LEDs per meters. I modified firmware that SCIMO is able to control these LEDs. Used communication protocol from these LEDs is not very complicated and thus it was easy included in firmware. I make some test to check how reliable data transfer works if communication timing is not exactly matched and was surprised how good it works also when timing is more worst then allowed by datasheet.
For my test i used 200 LEDs and configured SCIMO to MoodLight mode -> works stable without LED flicker or other problems.
As next i will start to modify firmware that SCIMO is able to control 200 LEDs (= 200 zones) in Ambient-Light mode which needs a bit optimization in some mathematical function to reduce overall calculation time.
How many FPS (frames per second) can be reached at 200 LEDs ?
Digital LED stripes using 800kHz for data transmission, to send one bit to LED it will need about 1.25µs.
-> 200 LEDs * 3 colors per LED * 8 bit per color = 4800 bit for one frame.
-> 4800 bit * 1.25 µs per bit + 50µs reset pulse = 6050µs = ~6ms for one frame.
-> 1 / 6ms = ~165Hz (FPS)
In Ambient-Light mode SCIMO is analyzing every video frame which means that at PAL or SECAM input signal are 50 fps analyzed and at NTSC are 60 fps analyzed. So available bandwidth from WS2812 is big enough to visualize Ambient-Light colors for 200 digital LEDs at full speed (using all frames from video input signal).
Note to TM1812 LEDs:
I have checked datasheet of TM1812 based digital LEDs and seen that communication protocol looks very close to WS2812 just a slide bit different timing. So i think support for TM1812 based LEDs is almost done too, just need to do some test to finish this point.
05. April 2013: widescreen detect
Many films and TV signals are provided in widescreen format and have different proportion. Because of that it is sometime necessary to adjust position and relative size of LED video zones to current widescreen format.
Note: Zones are rectangular areas in video frame which are analyzed in realtime and avarage color is build for LED. Every LED can have his own zone and is defined by user in size and position.
To be more comfortable i decided that don't user has to adjust video zones every time he changed video input source and included an way that zones are rescaled and new position is automatically configured depending on current screen format.
How it works ?:
User configure video zones at intial setup for normal screen format (4:3), this has to be done only one time. If at runtime video format change and e.g. is now received as widescreen format (16:9) than user can simply press button on remote control and SCIMO will analyze video data for new boarders in background (Ambient-Light function is not interrupted at this time) and adjust user defined video zones to new proportion of video frame. New found settings will be saved non-volatile in flash memory and used until user starts a rescan.
In first test i used a brighness sensitive algorythm which detected sometimes incorrect boarder values especially when widescreen format was analyzed. The reason for that behavior are caused by upper and lower area of widescreen video which is not full black even more gray and thus detected as valid video area.
As next version i tried a combination of brightness and motion sensitive video analysis which gives me much better results and works very reliable.
03. April 2013: adjustable gamma correction
After image grabbing in realtime is working successfully i startet fine tuning of building average color for LEDs. One realy importend parameter for matching color on TV with LED color is gamma correction. In first version i used exponential function and realized that LED color is compared to TV color more saturated. A way better solution is to use a power function like: y = 255*(x/255)^g
( Where input and output values are 8 bit wide and g = gamma factor. )
For my setup i found with g = 2.0 a good matching to my TV, some also very common gamma factors are g = 2.2 or g = 2.8.
I will make this parameter adjustable so that user can define it he likes.
24. March 2013: biggest milestone reached: optimize video analysis for 50fps (PAL)
Finally i'm proud to say that biggest milestone is reached and main part of firmware is finished: Video analysis is done in realtime and process 50fps (PAL).
Currently i'm using 50 digital RGB LEDs, based on DMX512, connected to SCIMO (as used in video below). And this is not the limit, additional RGB channels won't increase CPU load and only limit is available RAM in microcontroller. I guess that with current implementation of firmware up to 200 RGB channels (zones) are possible. By the time i will order some WS2812 based digital LED stripes equipped with 60 LEDs per meter and check limit.
For my test i used following configuration:
- Video Signal: S-Video, PAL (720x625 pixel, 50Hz)
- LED data output mode: DMX512
- 50 video zones with a size of round 40x40 pixel (each LED channel has his own video zone)
- compensate TV display input lag with 200ms
Below you can see position and order of video zones to analyse for LED color. The here used configuration of video zones is just an example and can be defined from user (is done using USB interface).
order and position of video zones:
I started first test using SCIMO in combination with real TV setup (see picture below). One thing i first noticed was a delay between light output from SCIMO and picture an TV. To be more exactly a have seen that SCIMO changed light output ~250ms earlier than picture on TV changed. After some research i found out that this behaviour is very common on many TVs and is caused by image processing from TV such as upscaling, motion smoothing or edge smoothing which takes some time. This is known as display input lag.
The solution is very simple and done in software: I added FIFO buffer in LED data stream which can be customized in size (time) from user (is done via USB).
14. February 2013: playing around with digital RGB-LEDs
To check data transfer from SCIMO to digital RGB-LEDs (using DMX512 Bus) i added a small function which generates data for sending to LEDs. I used three sine-function, for each color one, and give them a slight different phase velocity and a period that LED quantity is a multiple of it.
The produced light effect is just amazing :-).
For those if interested in code (output values are between 0x00 - 0xff, removed typecast for better readability ):
for ( i=0; i
led[i].green = (sin( PI*timerticker/34 +6*PI*i/(LED_QUANTITY-1) ) + 1 ) * 127.5f;
led[i].blue = (sin( PI*timerticker/40 + 6*PI*i/(LED_QUANTITY-1) ) + 1 ) * 127.5f;
For those if interested in video:
10. February 2013: checking digital LED power supply under worst case
After all digital RGB-stripes are assembled, i started some test to make sure they are working correctly and power supply from SCIMO is stable to drive 50 RGB-LEDs. First of all i can say that 5.0V voltage is stable even under worst case with means that all 50 RGB-LEDs are switches on ( 5V, 3.0A ). But released heat from power stage (mainly from step-down regulator and inductor) needs to be sufficiently derived. Fortunately i used in PCB many additional VIAs (VIA = electrical connection between layers) at power stage to cool down parts by using upper and lower PCB ground plane as heat sink. But all in all the used step-down regulator LM 2576 S5,0 makes good impression, i think i will used it again in future projects...
Below in schematic you can see used step-down regulator LM 2576 S5,0 in my design. Part Q2 (FET) works as reverse polarity protection from external power supply feeded in at connector X2. Diode D1 is a simple ESD protection.
23. January 2013: assembled digital RGB LED stripes
12. November 2012: RGB-LED modules controlled with DMX512
As i told in main project description, one of my goal is to use protocol DMX512 for controlling LEDs with SCIMO. Because i didn't find small and cheap modules/stripes thats includes RGB-LEDs with DMX512 Interface, i have build my own: low-cost RGB LED control with DMX512 . After these RGB-LED modules are now working, i have done next step and implemented DMX512 interface at SCIMO.
First tests shows pretty good performance, i will post a video in the next days...
...done (can be found here: RGB LED control with DMX512 )
03. November 2012: successfully sampled test image
It needed a lot of time to get DCMI work correctly, but finally a test image was successfully sampled by SCIMO using DCMI hardware sync lines. Below you can see how test image was delivered to SCIMO and received from PC:
I used the laptop's video output to generate a S-Video signal (PAL) and feed it into SCIMO. After detection the embedded video decoder IC "TVP5150" was synchronizing to video signal and started digitizing. The video signal is delivered in realtime to microcontroller using DCMI-Interface. Additionally the video decoder holds some information about the detected video signal which can be retrieved from special registers accessible through "I2C-Bus". These registers contain information about encoding (PAL, NTSC), widescreen on/off, lines per frame and so on...
Because of limited RAM available in microcontroller it is not possible to sample a full video frame at once. To sample a full frame it needs about: 720dots x 625dots x 2Byte_per_dot = 900000 Byte of RAM which is too much for microcontroller. So the frame was split in several parts and sequential sampled and send through USART to PC. After receiveing all data on PC is has been converted from native YCbCr format to a viewable "*.bmp" file using software "ImageMagick". The final result shows a pretty good image quality sampled by SCIMO:
Conversion from native YCbCr data to *.bmp file can be simply done by using following comand with software ImageMagick (freeware) :
convert -size 720x625 pal:input_file.raw output_file.bmp
|original test image:||image sampled by SCIMO:|
27. October 2012: microcontroller STM32F4xx are incompatible to video decoder using ITU-R BT.656
The last weeks i spend most of time in figuring out a big problem in DCMI Interface:
The used video decoder "TVP5150" is delivering its digitized video stream to microcontroller's DCMI-Interface. That is a 8-bit wide interface clocked with 27Mhz. Additionally it consists of some more hardware signal lines which indicates the actual synchronisation state (e.g. horizontal sync, vertical sync). But these signal lines are optional because all necessary sycronisation informations can be also retrieved by using ITU-R BT.656 (aka ITU.656). ITU.656 means that sync information is embedded in video data stream with special markers and this makes the hardware signal lines "hsync" and "vsync" unnecessary. And right here all problems started.
The mentioned ITU.656 mode, which has to be activated in microcontroller, can not be configured in a way that it works with video decoder "TVP5150". Although both components ( video decoder "TVP5150AM1" and microcontroller "STM32F4xx" ) are declared as ITU.656 compatible, it is not possible to get it work.
The reason for that problem is quite simple, but not possible to solve:
[LSC] = embedded sync marker: frame start delimiter (using Mode 1 = 0xff ) -> [SAV] generates "frame start"
[SAV] = embedded sync marker: Start Active Video
[EAV] = embedded sync marker: End Active Video
[FEC] = embedded sync marker: frame end delimiter (using Mode 1 = 0xff ) -> all unused synccodes generates "frame end"
Microcontroller is expecting a frame like this:
line n+0: [SAV] [active video data] [EAV] [horizontal blanking]
line n+1: [SAV] [active video data] [EAV] [horizontal blanking]
line n+2: [SAV] [active video data] [EAV] [horizontal blanking]
Video decoder is delivering its frame as follow (line starts with EAV and not SAV):
line n+0: [EAV] [horizontal blanking] [SAV] [active video data]
line n+1: [EAV] [horizontal blanking] [SAV] [active video data]
line n+2: [EAV] [horizontal blanking] [SAV] [active video data]
The result is that microcontroller won't sample video data because of "wrong" order of embedded sync marker. After some research its seems to me that video decoder deliver correct frame and microcontroller is not full ITU.656 compatible. I startet a request to microcontroller manufactor STMicroelectronics, lets see what they say to this problem...
As workaround i will now use hardware sync lines.
Published on: Wednesday, September 14 2016 (45811 reads)
Copyright © by Keiang's electronics hobby side
[ Go back ]