If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Want to remove the ads? Registered users do not see the ads.

I have received a bunch of PMs this past week about Supporting Memberships. Due to that I wanted to put a notice for all to see should they be interested.
You can learn more about Supporting Memberships by Clicking Here

Re: WS2811 pixel compatibility

Hey Jim,

If I were to purchase the following strips (http://www.aliexpress.com/product-fm...olesalers.html) based on WS2811, would these work with my E681 that I built back in February? Do I need to upgrade any firmware, or just select 1804 as the pixel type in the controller? Thanks!

Re: WS2811 pixel compatibility

Originally Posted by jaywalk101

Hey Jim,

If I were to purchase the following strips (http://www.aliexpress.com/product-fm...olesalers.html) based on WS2811, would these work with my E681 that I built back in February? Do I need to upgrade any firmware, or just select 1804 as the pixel type in the controller? Thanks!

You would need to update the firmware, it will be available on the web site soon.

First of all, I don't think this signalling scheme is NRZ. Basically, all of these pixels (1804 and 2811 and even the GE ColorEffects chips) work essentially the same way. There is a low-to-high transition at the start of each bit cell, then at the center of the bit cell the chip samples the data line to determine if the bit is a 1 or a 0. So all that's required is that some time after the start of the bit cell, and prior to the center of the bit cell, the sender has to (in the case of a 0) return the data line to 0. In the case of a 1 the sender must return the data line to 0 some time *after* the mid-point of the bit cell.

The 1804s recommended timing uses a scheme which essentially divided the bit cell into three segments. For a nominal 800kbps data rate, the bit cell is 1250ns long. For an 1804 the recommendation was to send 833ns high (2/3) followed by 417ns low (1/3) for a 1 or 417 ns high followed by 833ns low for a 0.

The WS2811 recommended timing essentially divides the bit cell into fifths. A 1 is sent as 1000ns high (4 segments) followed by 250ns low (1 segment), while a 0 is sent as 250ns high and 1000 ns low. The fact is that either approach will work, the only thing the pixel chip really cares about is the state of the data line at 625ns.

The "1804" apprpach has the advantage that less bandwidth is required on the wiring between pixels since the narrowest pulse we are ever sending is 417ns, while the 2801 technique requires more bandwidth since we are sending 250ns pulses. OTOH, the 2811 technique has better noise immunity since the transition time of the data line is farther away from the sample point.

Both data sheets spec timings as +/- 150ns. So let's look at the worst case:

With an 1804, worst case is a 0 sent as 567ns high (417+150) followed by a transition to low. That means the time where the data line transitions from 1 to 0 (567ns) is only 58ns from the point where the chip samples the data line (625ns). With a 2811, say a 0 is sent as 400ns high (250+150). Now there's still 225ns between the time the data line transitions to 0 and the sample point, so much better in terms of noise immunity.

At this point I'm using the WS2811 recommended timing for both 2811s and 1804s, and the 1804s appear to be happy. Likewise the 2811s will work with the 1804 timing recommendations as long as the data rate is very close to 800kbps.

Re: WS2811 pixel compatibility

Thanks for your explanation. Not being NRZ make sense, as the chip need to synchronise its free running oscilltor using a very basic clock recovery mechanism. ( That I undestand well from my digital old Modulator / Demodultor days).
This may also explain why the 2811 is cheap.
However it added a level of complexity to the data stream creation as the AVR SPI is real NRZ. Food for thought.

[B][I]Matt[/I][/B]

You too can become a Supporting member of DIYC.
Check it out [URL="http://doityourselfchristmas.com/forums/payments.php"]here[/URL]

Re: WS2811 pixel compatibility

There is a new firmware version on the web site for the E68x controllers that adds support for the 2811s and also the 880x, and 981x series pixels. This version also includes the dithering to achieve 8-bit dimming with the 6803 pixels. Right now it is available as an .eeprom file, which must be loaded using a Parallax Prop Plug programmer. The version that will install over the lan without requiring a programmer will be up soon.

Re: WS2811 pixel compatibility

Originally Posted by jstjohnz

There is a new firmware version on the web site for the E68x controllers that adds support for the 2811s and also the 880x, and 981x series pixels. This version also includes the dithering to achieve 8-bit dimming with the 6803 pixels. Right now it is available as an .eeprom file, which must be loaded using a Parallax Prop Plug programmer. The version that will install over the lan without requiring a programmer will be up soon.

Great support as always sir! Is there any other reason to upgrade my existing 681's if I'm not using those pixels? (i.e. bug fixes, etc)

Re: WS2811 pixel compatibility

Excuse my ignorance on things Prop, but is the .eeprom fromat proprietary to the Prop programmer? I had visions on updating a really old eeprom using a Nedham programmer (yes they are out of business, and yes it does support the PROM, and yes I have the adapter and personality card.)

I am familar with .bin, .hex, .rom, and a few others that escape me, but I've NOT seen .eeprom before. Any ideas on how I might get a programmer to choke down a .eeprom file??

[I][SIZE=2]"Beam me up Scotty, there are only limited pockets of intelligent life on this planet!!"[/SIZE][/I]
Communicating humor in a text only medium is an art form subject to imprecise interpretation by the audience...

Re: WS2811 pixel compatibility

Originally Posted by CaptKirk

Excuse my ignorance on things Prop, but is the .eeprom fromat proprietary to the Prop programmer? I had visions on updating a really old eeprom using a Nedham programmer (yes they are out of business, and yes it does support the PROM, and yes I have the adapter and personality card.)

I am familar with .bin, .hex, .rom, and a few others that escape me, but I've NOT seen .eeprom before. Any ideas on how I might get a programmer to choke down a .eeprom file??

The .eeprom file I believe is a byte-for-byte image of what's to be written to the first 32KB of the eeprom. The file, therefore, is exactly 32K bytes long. I should have the utility available for download soon that allows you to send the .eeprom file to the controller via the lan connection, so no programmer required when doing it that way.