digital RGB LED question - Page 1
Forum section: electronics / projects

author: glenenglish
author_rank: Frequent Contributor
timestamp: April 20, 2024, 11:40:18 pm
content: HII'm troubleshooting some RF problems with digital LEDs (single wire DIN DOUT cascade) . The design of the product is lacking much engineering rigour, but its what I have to work with from the client.The designer has used an opamp to drive several meters of cable with a string of cascaded digital LEDs on, them a total RFI and EMC nightmareie a) low speed opamp cant make square waves, so it starts off bad, and b) no shields anywhere, RF gets into it very easily and muds up the edges.QUESTION : The date bit rate in the datasheet is given as 1.25uS typical. (800kHz)This is what it is running at. If it ran at 1/10th of that, or 1/100th of that,will the chips still work?- IE are they edge triggered, or is there some asynchronous timing activity internallySLowing the clock would permit the opamp to make decent looking waveforms. and permit some scope for EMI filtering from 10-200 MHz RF.I cant just try it, have to go back to the client to get a change. There isnt time budget for me to dick around with the led's myself. Hmm maybe I can program up my AWG to do this...... That might work-glen

author: ataradov
author_rank: Super Contributor
timestamp: April 21, 2024, 12:54:35 am
content: Quote from: glenenglish on April 20, 2024, 11:40:18 pmThey are asynchronous. You can't run them slower at all. In fact, long low level is the reset signal.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 21, 2024, 04:21:05 am
content: So, no, you can't. There is some tolerance, but not enough to make a difference in your case.(This tolerance can be leveraged though to use some "spread spectrum" approach to lower EMI.)The datasheet for the WS2812B specifies 1.25µs +/- 600ns, which is about +/-50%.

author: glenenglish
author_rank: Frequent Contributor
timestamp: April 21, 2024, 06:41:58 am
content: thanks both for the info.

author: tooki
author_rank: Super Contributor
timestamp: April 21, 2024, 12:45:15 pm
content: Given that, as I understand it, each LED is retransmitting the data (after stripping off the packet it will display), I don’t think the issue is the driver, because only the first LED in the string sees it. Could the problems actually be due to current spikes on the power supply rail? You could try putting caps near the LEDs and seeing if that helps.Or is the issue several meters of cable between the driver and the first LED?

author: glenenglish
author_rank: Frequent Contributor
timestamp: April 21, 2024, 10:39:58 pm
content: The problem is much simplerpassing logic level signals, of typical drive impedances, terminations, expected risetimes etc over 3m of unshielded multicore cable is a no-no.These are board level driven parts.Without strong schmitt trigger action, RF causes the edges to toggle even at very low levels. And higher levels will of course overcome the schmitt threshold.and the 3V/uS slew rate of a driving opamp , generating triangle waves to start with doesnt help....

author: glenenglish
author_rank: Frequent Contributor
timestamp: April 24, 2024, 09:29:02 pm
content: HiYeah but did your system pass IEC61000 RF immunity requirements ? and emissions ?Your CMOS GPIO was probably doing an OK job at making square waves.In this case the opamp was making triangles...... permitting the waveform to spend alot more time in the danger threshold band .I used a 6 pin AVR, to do a translation in the led bar. They're fantastic !I kept the existing driver (already in production.....) slowed the physical interface down to 2 kbps biphase-mark with a CRC , and drove the PDM '2812 from the AVR with the PWM output which was nice and low overhead for the little cpu....while its doing the PWM for the current bit, you can load the next bit because it's double buffered.

author: tooki
author_rank: Super Contributor
timestamp: April 26, 2024, 01:52:33 pm
content: Ummm… as I understand it (someone please correct me if I’m wrong), square waves are worse for EMI emissions than triangle waves, due to the faster rise times.It’s still kinda unclear what you are doing. Can’t you share a block diagram or schematic?

author: glenenglish
author_rank: Frequent Contributor
timestamp: April 26, 2024, 08:56:47 pm
content: well, they were not really triangles, they have rounded tops.Square waves have a rich odd harmonic spectrum, so they are more likely to produce EMI issues at higher frequenciesIn addition, the high frequency harmonic content can excite parasitic reactances in the wiring (stray C, L) which generates rings and spectral components up into VHF and UHF. (maybe 1000 times to square wave fundamental frequency)..Start with a sine wave wave, and progressively add odd harmonics and you'll end up with a square wave.

author: tooki
author_rank: Super Contributor
timestamp: April 26, 2024, 09:00:30 pm
content: Right, that’s how I understood it.So why would your triangle waves beworsefor EMI than the clean square waves described in the now-deleted post you replied to?

author: glenenglish
author_rank: Frequent Contributor
timestamp: April 26, 2024, 09:04:32 pm
content: I didnt delete anything.The fundamental freq at 800kHz was a problem . Yu cant meet CISR25 with a transmitter running inside the AM broadcast bandnever mind the harmonics.The problem for the devices was the lack of harmonics (IE being not square waves, IE without necessary fast risetimes to ensure the transition between 0 and 1 is fast enough to avoid the chip toggling states internally as it passes through the threshold band.),

author: tooki
author_rank: Super Contributor
timestamp: April 26, 2024, 09:32:01 pm
content: Quote from: glenenglish on April 26, 2024, 09:04:32 pmI know you didn’t, which is why I never said you did. I said that the post you were REPLYING TO was deleted. See your replies #5 and 6 above? There used to be another post between them. That post was from someone else. They deleted it after you replied to it.Quote from: glenenglish on April 26, 2024, 09:04:32 pmSo wouldn’t the harmonics have made EMI emissionseven worse?!Quote from: glenenglish on April 26, 2024, 09:04:32 pmSure. But that’s not an EMI issue.Is there some reason you are reluctant to share any of the requested information, like a block diagram? Super frustrating.

author: glenenglish
author_rank: Frequent Contributor
timestamp: April 26, 2024, 09:37:25 pm
content: harmonics maybe might have made EMI worse, it depends on their amplitude, which might depend on the cable characteristics, the driver characteristics, the load characteristics...problem 1-the lack of sharp edges mean the link is unreliable (those chips need square waves). long periods in the transition region leads to (even poorer) RF immunityproblem 2-signals in the broadcast band on unshielded cables are radiators and likely cannot meet CISPR25 etc emission requirements, and are likely to cause harmful interference to you and your neighbour's listening of the radio.

author: glenenglish
author_rank: Frequent Contributor
timestamp: May 09, 2024, 09:11:13 am
content: well I have some maybe useful info for others.While the required data cycle time is shown in the data sheets as 800kHz / 1250uS, as long as you stick to the required high times of 400 and 800nS +/- 100nS, it seems you are good to goI've tested up to 5uS data bit width (with high time 400nS =0 or 800nS = 1 ) IE a bit fat chunk of low after the pulse , seems to be fine.