logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

[BK7231N] [CBU] Ligency RGBW+IC LED Spotlights GPIO Identification After Flashing

pborrelli 2175 6

TL;DR

  • Two outdoor addressable RGBW+IC LED spotlights using a CBU module with BK7231N were flashed to OpenBeken after backing up the factory firmware.
  • GPIO doctor testing found no pin that lit the LEDs, but P24 responded as the button using "Set Input P-up."
  • Tuya’s extracted config lists CBU, SPI MISO17, SPI MOSI16, SCL14, CS15, and key1_pin 24, with the Tuya section starting at 2023424.
  • The light-control GPIO mapping remains unknown, and the board tracing plus similar forum threads still left the author stuck.
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • Hi all! I just got two of these outdoor addressable LED Spotlights (RGBW+IC) that use a CBU. Disassembly was a bit destructive and cracked the case that held the circuit board, but it'll still be usable when it's done.
    Photo of a circuit board with a CBU module and electronic components.
    Circuit board of JBT-WF1-XC004-YWY module with pin labels
    Close-up of a circuit board with markings and LED lights.
    Close-up of a circuit board with electronic components.
    I was successfully able to backup the factory firmware (attached) and install OpenBeken using BK Flasher, but haven't been able to make much progress since then. I can't seem to figure out how the GIPOs control the lights. I used the GPIO doctor on all the pins, but none will cause the lights to light up in any way (they did work before I flashed OpenBeken). I've only been able to identify that P24 is the button by using the "Set Input P-up," and pressing the button to see the change. Other than that, I am hitting a wall.
    Code: text Expand Select all Copy to clipboard
    Text Description
Device configuration, as extracted from Tuya: 
- Microphone (TODO) on P23
- SPI MISO17
- SPI MOSI16
Device seems to be using CBU module, which is using BK7231N.
And the Tuya section starts, as usual, at 2023424

JSON Format:
{
	"Jsonver":"1.0.0",
	"brightmin":"10",
	"gmwb":"75",
	"title20":"1",
	"gmwg":"70",
	"knum":"1",
	"wfcfg":"spcl_auto",
	"colormin":"10",
	"pmemory":"1",
	"gmkb":"60",
	"k1sfunc":"5",
	"cmod":"4",
	"lednum":"12",
	"netlptime":"3",
	"micpin":"23",
	"rstbr":"50",
	"musicfunc":"1",
	"colormax":"100",
	"module":"CBU",
	"cwmaxp":"100",
	"rstmode":"1",
	"k1lfunc":"1",
	"dmod":"7",
	"brightmax":"100",
	"speedstep":"20",
	"wfct":"3",
	"expowctrl_pin":"8",
	"defbright":"100",
	"rstnum":"3",
	"rstcor":"r",
	"key1_pin":"24",
	"sensimax":"300",
	"miso":"17",
	"mosi":"16",
	"keyfunc":"1",
	"irfunc":"0",
	"expowctrl_lv":"1",
	"adclimit":"2400",
	"sensimin":"30",
	"MISO":"17",
	"wt":"20",
	"key1_lv":"0",
	"brightstep":"20",
	"remdmode":"0",
	"colorpfun":"0",
	"CS":"15",
	"gmwr":"100",
	"gmkg":"60",
	"onoffmode":"1",
	"colororder":"0",
	"brightrate":"20",
	"lptime":"3",
	"aging":"0",
	"category":"1101",
	"SCL":"14",
	"gmkr":"80",
	"defcolor":"r",
	"crc":"107",
	"}cPhAgw_di{abi":"0",
	"id":"null",
	"swv":"1.0.20",
	"bv":"40.00",
	"pv":"2.2",
	"lpv":"3.4",
	"pk":"keyfwt38nejumpuv",
	"firmk":"keyfwt38nejumpuv",
	"cadv":"1.0.5",
	"cdv":"1.0.0",
	"dev_swv":"1.0.20",
	"s_id":"null",
	"dtp":"0",
	"sync":"0",
	"attr_num":"1",
	"mst_tp_0":"9",
	"mst_ver_0":"1.0.20",
	"mst_tp_1":"0",
	"mst_ver_1":"null",
	"mst_tp_2":"0",
	"mst_ver_2":"null",
	"mst_tp_3":"0",
	"mst_ver_3":"null } )Agw_wsm{nc_tp",
	"ssid":"null",
	"passwd":"null",
	"md":"0",
	"random":"0",
	"wfb64":"1",
	"stat":"0",
	"token":"null",
	"region":"null",
	"reg_key":"null",
	"dns_prio":"0 }{uuid",
	"psk_key":"MnXfZutokIqrbtJmhnyMq6P1A0fcXxvuXcRmO",
	"auth_key":"tAOi6vMDmHSZ7VN7CvmGSE3IFbjv0AEi",
	"ap_ssid":"SmartLife",
	"ap_passwd":"null",
	"country_code":"null",
	"bt_mac":"null",
	"bt_hid":"null",
	"prod_test":"false",
	"fac_pin":"q8es5qukiuljknuj }{nc_tp",
	"lckey":"null",
	"h_url":"null",
	"h_ip":"null",
	"hs_url":"null",
	"hs_ip":"null",
	"hs_psk":"null",
	"hs_psk_ip":"null",
	"mqs_url":"null",
	"mqs_ip":"null",
	"mq_url":"null",
	"mq_ip":"null",
	"ai_sp":"null",
	"ai_sp_ip":"null",
	"mq_psk":"null",
	"mq_psk_ip":"null",
	"lp_url":"null",
	"lp_ip":"null",
	"time_z":"null",
	"s_time_z":"null",
	"wx_app_id":"null",
	"wx_uuid":"null",
	"dy_tls_m":"0",
	"cloud_cap":"0",
	"psk21_key":"null }{nc_tp"
}

    I did find out from the backup that BK Flasher identified the use of SPI, MOSI, and MISO. You'll have to forgive me, as that is getting beyond my level of knowledge and it's a bit of a foreign language. I did my best to trace out the pins on the board and what components they are connected to. Here's what I found:
    Circuit board with CBU module and labeled pins and pathways.
    I've spent the past three days reading and learning; these threads seem similar to my device:
    [BK7231N/CBU] Casa Life ALDI Aus - Floor Lamp Mood Lamp - RGB control, SPI? MOSI? MISO?
    Deciphering Pin Configuration & JSON Readout for Marlrin RGBCW Corner Floor Lamp (MOSI/MISO)
    [BK7231N - CBU] Teardown of Aldi (Australia) CasaLux Smart Led Corner Lamp
    If there's any recommendations or literature that informs how to make this work, please let me know. I've been searching, but haven't found the solution yet.
    Attachments:
    • readResult_BK7231N_QIO_OutdoorLEDSpotlights_2024-12-1-07-27-55.bin (2 MB) You must be logged in to download this attachment.

    Cool? Ranking DIY
    About Author
    pborrelli
    Level 3  
    Offline 
    pborrelli wrote 10 posts with. Been with us since 2022 year.
  • ADVERTISEMENT
  • #2 20911963
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14595
    Help: 654
    Rate: 12613
    This looks like individually adressable LEDs, the DO (Data Out) marking also indicates this. Have you tried our experimental SPI driver?
    Code: text Expand Select all Copy to clipboard
    
1. Start driver
startDriver SM16703P

2. Init Driver - replace 64 with number of LEds
SM16703P_Init 64

3. Set Pixel
SM16703P_SetPixel 1 255 0 0
SM16703P_SetPixel 2 0 255 0
SM16703P_SetPixel 3 0 0 255

4. Start Output (each call will trigger one)
SM16703P_Start


    What is the marking here:
    Close-up of a circuit board fragment with visible electronic components and traces. A marked area with the DO (Data Out) label.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #3 20912759
    pborrelli
    Level 3  
    Posts: 10

    You Sir are a genius and a saint! I ran the SPI Driver commands and got light! Two of the four lit up, one blue and the other white. I then powered it down to get a picture of the chip on the LED board:
    Close-up of WS2814A chip on a PCB board.
    It appears to be WS2814A LEDs ... ? Again, I'm out of my league here.
    Problem now is I can't get it to light up again after powering down and back up. I set everything back the way it was, but rerunning the SPI Driver commands is doing nothing now. What am I missing?
    I've set the GPIOs P8, P15, and P16 to be PWMs or Relays, but nothing appears to be working. What are the recommended GPIO settings for the SPI Driver? I'm going to keep tweaking with it, but it's got me scratching my head at the moment.
    Thank you again @p.kaczmarek2 I don't know how you keep on top of all the posts in this forum, as well as the modifications to the firmware!
  • ADVERTISEMENT
  • #4 20912797
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14595
    Help: 654
    Rate: 12613
    WS2814A ... well, to be honest, it's the first time ever I see this chip, but it bears a significant resemblance to WS2812 LEDs.

    Let's check the datasheet:
    Timing diagram and connection layout of WS2814A circuit.
    Timings are similiar... but frame is 32 bit, and not 24 bit like WS2812B.

    This would require some adjustements to our driver, but still, our driver should theoretically at least be able to lit some random colors on that....

    Futher testing might be needed, but it would require hooking an oscilloscope to the DO pin.

    Alternatively, can you try:
    Code: text Expand Select all Copy to clipboard
    
SM16703P_Init 4
SM16703P_SetPixel 0 255 255 255
SM16703P_SetPixel 1 255 255 255
SM16703P_SetPixel 2 255 255 255
SM16703P_SetPixel 3 255 255 255

    don't forget to start the driver as well.

    Do not set any GPIO role for P16, just start driver, and run the commands I gave.
    Helpful post? Buy me a coffee.
  • #5 20912961
    pborrelli
    Level 3  
    Posts: 10
    Good to know that it's new equipment, and not just that I'm new.
    I cleared the assignment on P16 and did some poking and prodding and am finally getting somewhere. P8 & P15 are set to relays, and I have to toggle either or both on to get light output.
    The first three of the four spotlights turn on with a blue light (They go 1 to 4 from RIGHT to LEFT).
    Four LED spotlights with cables on a bed, three of which emit blue light.
    I plan to do more testing by changing the parameters, but work is starting to get in the way of play!
    There was one error, but I still got light when starting the output:
    Code: text Expand Select all Copy to clipboard
    (startDriver SM16703P)
Info:MAIN:Started SM16703P.
Info:CMD:[WebApp Cmd 'startDriver SM16703P' Result] OK
...
(SM16703P_Init 4)
Info:CMD:Register driver with 4 LEDs
Info:CMD:[WebApp Cmd 'SM16703P_Init 4' Result] OK
...
(SM16703P_SetPixel 0 255 255 255)
Info:CMD:Set Pixel 0 to R 255 G 255 B 255
Info:CMD:Raw Data 0xee 0xee 0xee 0xee - 0xee 0xee 0xee 0xee - 0xee 0xee 0xee 0xee
Info:CMD:[WebApp Cmd 'SM16703P_SetPixel 0 255 255 255' Result] OK
...
(SM16703P_SetPixel 1 255 255 255)
Info:CMD:Set Pixel 1 to R 255 G 255 B 255
Info:CMD:Raw Data 0xee 0xee 0xee 0xee - 0xee 0xee 0xee 0xee - 0xee 0xee 0xee 0xee
Info:CMD:[WebApp Cmd 'SM16703P_SetPixel 1 255 255 255' Result] OK
...
(SM16703P_SetPixel 2 255 255 255)
Info:CMD:Set Pixel 2 to R 255 G 255 B 255
Info:CMD:Raw Data 0xee 0xee 0xee 0xee - 0xee 0xee 0xee 0xee - 0xee 0xee 0xee 0xee
Info:CMD:[WebApp Cmd 'SM16703P_SetPixel 2 255 255 255' Result] OK
...
(SM16703P_SetPixel 3 255 255 255)
Info:CMD:Set Pixel 3 to R 255 G 255 B 255
Info:CMD:Raw Data 0xee 0xee 0xee 0xee - 0xee 0xee 0xee 0xee - 0xee 0xee 0xee 0xee
Info:CMD:[WebApp Cmd 'SM16703P_SetPixel 3 255 255 255' Result] OK
...
(SM16703P_Start)
Error:CMD:before enable tx 0x0000320c
Error:CMD:enable tx 0x0000320c
Info:CMD:[WebApp Cmd 'SM16703P_Start' Result] OK

    Light output is ... interesting. Sometimes when entering the Start command, I may only get two of the lights, and one was warm white one time. If I mess with the toggle buttons on the main console, the lights will sometimes turn off without turning back on. Also, if I enter the commands and try to start the lights before toggling on the relays, it won't work.
    It's exciting to get somewhere with these. I'm happy to do more testing and tuning, is there a writeup on the SPI Driver?(nevermind, I found them). I'll go do some things and report back the findings, not sure how much I can do because of the 32 bit frame, but I'm going to play anyway.
  • ADVERTISEMENT
  • #6 20915260
    pborrelli
    Level 3  
    Posts: 10

    I've been doing some testing and tuning, but not much to report. I can get all four lights to light up by playing with various settings on the number of pixels and the color assignment going to each one, but there's no pattern or predictability to them. This is of course due to the 24 vs 32 bit data packaging.
    I wish I knew how to write C, I'd be happy to make adjustments. That's well above my pay grade.
    In the meantime, I'm happy to do more testing, and when this is up and running properly I'll do a full teardown write-up.
    Four spotlights emitting different colors: red, green, blue, and white, placed on a dark background.
  • #7 21192339
    pborrelli
    Level 3  
    Posts: 10
    So it's been most of a year now, these sat for about seven months, but I finally picked them up again.

    I found a workaround that provides correct color and individual control of each LED; though it's with ESPHome and not OpenBeken. It turns out the WS2814 are known to be a variant of the SK6812 with a white channel. I was able to use the "Beken_SPI_LED_Strip" platform in ESPHome and set the chipset option to "sk6812" and the color option "is_wrgb" to "True." This set the correct color on each led and and allowed individual control. I think having a data packet for the white channel pushed the correct 32bit full data packet and corrected the problem.

    I don't know if there's a way to leverage this in OpenBeken, but it could be a quick workaround for using WS2814 LEDs.
    Control panel with options for four uplight pixels, each with an individual toggle switch.

    Four LED spotlights emitting light in red, green, blue, and yellow colors.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion revolves around the identification and control of GPIOs for Ligency RGBW+IC LED Spotlights after flashing with OpenBeken firmware. The user successfully backed up the factory firmware and installed OpenBeken but faced challenges in controlling the lights via GPIOs. Initial attempts using the SPI driver commands yielded partial success, lighting up some LEDs but not consistently. The LEDs were identified as WS2814A, which are similar to WS2812 but require different data packet configurations. After further testing, the user found that using ESPHome with the "Beken_SPI_LED_Strip" platform allowed for correct color and individual control of each LED by setting the chipset option to "sk6812" and enabling the white channel. This workaround provided a solution to the control issues experienced with OpenBeken.
Generated by the language model.
Today's popular

FAQ

TL;DR: For these 4-light BK7231N CBU spotlights, "Do not set any GPIO role for P16" is the key fix. Leave P16 free for SPI data, toggle P8 and P15 to power the LED section, and test with OpenBeken SM16703P. If colors remain random, ESPHome Beken_SPI_LED_Strip with sk6812 and is_wrgb: True solved correct RGBW control. [#20912797]

Why it matters: This FAQ helps OpenBeken and ESPHome users recover LED control after flashing a Ligency RGBW+IC spotlight whose addressable LEDs do not respond to normal GPIO probing.

Option What the thread showed Best use in this device
OpenBeken + SM16703P Produced light, but colors were inconsistent because the driver sent 24-bit style data to a 32-bit RGBW LED chain Fast hardware discovery and GPIO testing
ESPHome + Beken_SPI_LED_Strip Worked with chipset: sk6812 and is_wrgb: True, giving correct color and per-LED control Practical workaround for normal use

Key insight: GPIO Doctor failed because this spotlight does not use simple PWM RGBW outputs. It uses individually addressable RGBW LEDs, so power-enable pins and SPI-style data behavior matter more than direct GPIO toggling.

Quick Facts

  • The Tuya dump exposed five key mappings: key1_pin=24, expowctrl_pin=8, micpin=23, MOSI=16, and MISO=17, which gave the first reliable map of button, power control, and LED data paths. [#20911851]
  • OpenBeken's experimental test sequence used startDriver SM16703P, then SM16703P_Init 64 or SM16703P_Init 4, followed by SM16703P_SetPixel and SM16703P_Start. [#20911963]
  • The LED board was identified as WS2814A, and the thread highlighted the critical framing mismatch: WS2814A uses a 32-bit frame, while WS2812B uses 24-bit data. [#20912797]
  • Stable light output required P8 and P15 to be toggled like relays before SPI output started, while P16 had to stay unassigned in GPIO roles. [#20912961]
  • After roughly 7 months of pause, the working workaround was ESPHome Beken_SPI_LED_Strip with chipset: sk6812 and is_wrgb: True, which restored correct colors and individual control. [#21192339]

How can I identify the correct GPIOs on a BK7231N CBU Ligency RGBW+IC spotlight after flashing OpenBeken when GPIO Doctor doesn’t light the LEDs?

Use the Tuya JSON and PCB tracing first, not GPIO Doctor alone. In this spotlight, GPIO Doctor found only the button on P24, while the dump pointed to expowctrl_pin=8, key1_pin=24, micpin=23, MOSI=16, and MISO=17. That pattern indicates addressable LEDs, not plain PWM channels, so the LEDs will not react to simple per-pin toggling. Trace power-enable lines and test the SPI-style driver path instead. [#20911851]

What is the WS2814A LED chip, and how is it different from WS2812B or SK6812 in RGBW addressable lighting?

WS2814A is an addressable RGBW LED driver that resembles WS2812-family parts but uses a 32-bit frame instead of the 24-bit frame discussed for WS2812B. "WS2814A" is an addressable LED controller category that drives individually controlled pixels, adds a dedicated white channel, and expects a longer data frame than classic 3-channel RGB parts. In this thread, that extra white data path explained why partial light worked but colors stayed wrong with a 24-bit-oriented test driver. [#20912797]

How do I use the experimental SM16703P SPI driver in OpenBeken to test individually addressable LEDs on a CBU module?

Use the driver from the OpenBeken console in four commands. 1. startDriver SM16703P 2. SM16703P_Init 4 or another LED count 3. Send pixels with SM16703P_SetPixel ..., then trigger output with SM16703P_Start. The earlier test example also showed SM16703P_Init 64 and three color writes for red, green, and blue. This confirms whether the LED chain reacts to SPI-style output at all. [#20911963]

Why would a Ligency outdoor RGBW+IC spotlight light up once with SM16703P commands and then stop responding after a power cycle?

It stops because the LED section needs both correct power-enable state and a fresh data start. After reboot, the user found P8 and P15 had to be toggled first, or SM16703P_Start produced no visible output. The thread also showed inconsistent behavior after power cycling, including only 2 of 4 spotlights lighting and some lights turning off when relay states changed. That points to power-gating plus protocol mismatch, not a dead LED chain. [#20912961]

Which GPIO settings are recommended for OpenBeken SPI LED testing on this BK7231N device, especially for P8, P15, and P16?

Leave P16 unassigned, and use P8 and P15 as relay-style power controls. The direct guidance was: "Do not set any GPIO role for P16, just start driver." Later testing showed the LEDs only came alive when P8 and P15 were toggled on first. On this board, P16 behaves like the SPI data path, while P8 and P15 appear to enable power or sections of the LED hardware. [#20912797]

What does the Tuya JSON dump mean for a CBU spotlight, including fields like key1_pin, expowctrl_pin, micpin, MOSI, and MISO?

It is the factory configuration map that exposes how the BK7231N CBU firmware expected the hardware to work. In this dump, key1_pin=24 matched the pushbutton, expowctrl_pin=8 suggested external power control, micpin=23 matched the microphone input, and MOSI=16 plus MISO=17 pointed to an SPI-style peripheral path. The same dump also listed lednum=12, firmware swv=1.0.20, and module CBU. [#20911851]

Why do P8 and P15 need to be toggled like relays before the SPI-driven LEDs start working on this Ligency spotlight?

They appear to gate power to the LED subsystem or related stages. The user reported that setting P8 and P15 as relays and toggling either or both on was necessary before any light output appeared. If SM16703P_Start ran before those relays were enabled, nothing happened. That behavior fits a board where the data pin alone cannot drive LEDs until one or more power-enable lines are active. [#20912961]

How can I tell from the PCB markings and traces whether a smart spotlight uses individually addressable LEDs instead of simple PWM RGBW channels?

Look for a data-chain marking and serial LED topology, not four separate RGBW power channels. In this case, a DO marking on the LED board strongly suggested data-out chaining between LEDs, and that led directly to trying the SM16703P driver. The board then lit partially under pixel commands, confirming individually addressable behavior. A simple PWM RGBW lamp would respond to direct GPIO-to-channel testing instead. [#20911963]

What causes random colors or unpredictable LED behavior when driving WS2814A lights with a 24-bit OpenBeken SPI driver?

The random output comes from frame-length mismatch. The thread identified WS2814A as similar to WS2812 timing-wise, but using a 32-bit frame, while the OpenBeken test path behaved like a 24-bit RGB driver. That mismatch shifted color data and produced cases where only some of the 4 lights responded, sometimes blue, sometimes warm white, and without a stable pattern. The hardware was alive; the payload format was wrong. [#20912797]

Where should I probe with an oscilloscope on a WS2814A LED board to verify the data signal and timing from a BK7231N CBU module?

Probe the DO-labeled data path on the LED board. The thread explicitly suggested hooking an oscilloscope to the DO pin because that point should reveal whether the BK7231N side is sending valid timing into the addressable LED chain. That is the fastest way to separate a GPIO or power-enable problem from a protocol problem. It also helps confirm whether the 32-bit stream is being framed correctly. [#20912797]

How does the 32-bit frame used by WS2814A affect compatibility with OpenBeken’s SM16703P driver?

It makes the current test driver only partially compatible. The OpenBeken SM16703P path could still light "some random colors," but the thread noted that WS2814A needs 32-bit frames, not the 24-bit structure used by WS2812B-style RGB data. That means a driver change is needed for correct RGBW ordering and predictable per-pixel control. Without that change, test output proves activity, not full compatibility. [#20912797]

What is a CBU module in Tuya devices, and how does it relate to the BK7231N chip used in smart LED spotlights?

A CBU module is the Tuya radio-and-MCU module used here, and this thread identified it as carrying a BK7231N. "CBU" is a Tuya Wi‑Fi/Bluetooth module category that hosts the main control chip, runs the device firmware, and exposes GPIOs used for buttons, power control, and LED data interfaces. In this spotlight, the backup and JSON both confirmed a CBU with BK7231N and mapped several pins around it. [#20911851]

ESPHome Beken_SPI_LED_Strip vs OpenBeken SM16703P driver: which works better for WS2814A or SK6812-style RGBW LEDs?

ESPHome worked better for normal use in this case. OpenBeken's SM16703P driver was useful for discovery because it proved the LEDs were addressable, but colors stayed unpredictable due to the 24-bit versus 32-bit mismatch. Months later, the user reported correct color and individual LED control with ESPHome Beken_SPI_LED_Strip, using sk6812 and is_wrgb: True. That makes ESPHome the practical choice here. [#21192339]

How do I configure ESPHome Beken_SPI_LED_Strip for WS2814A by using chipset sk6812 and is_wrgb True on a BK7231N device?

Set the ESPHome platform to Beken_SPI_LED_Strip, choose chipset: sk6812, and enable is_wrgb: True. That exact combination was the workaround that restored correct colors and individual control on these WS2814-based spotlights after about 7 months of testing and pause. The user concluded that adding the white-channel data effectively pushed the full 32-bit packet the LEDs expected. [#21192339]

What literature, examples, or similar teardown threads are most useful for learning how SPI, MOSI, and MISO control addressable LEDs in Tuya-based BK7231N lights?

Start with closely related BK7231N/CBU lamp teardowns that also mention SPI, MOSI, and MISO. The original post specifically linked three useful examples: Casa Life ALDI floor lamp RGB control, Marlrin RGBCW corner lamp pin/JSON analysis, and CasaLux smart LED corner lamp teardown. Those threads helped frame this device as an addressable LED design rather than a standard PWM RGBW light, which shortened troubleshooting after 3 days of trial and reading. [#20911851]
Generated by the language model.
ADVERTISEMENT