ECG-P2, ECG-D2, XCG-X2A preview ....

Thx for the detailed explanations Ed, your boards certainly make it easier for newbies like me to get a display up and running, your new series of boards will allow me to do a couple of items that were otherwise going to be too difficult for me to do with my limited experience. Plus the costs you are suggesting will allow me to have a few more items in my first display than I thought.


Cheers
Mick
 
Question and sorry if it was answered above and I di dnot understand or missed it.

last year I ran DMX through my ECG-DR4 to a couple small controller board. However this year, I doing the Mega-Tree and a few other things and this require and lot more channels.

Does this run through the ECG-DR4 or is it standalone?

What software will support ARC NET if LSP does not?
 
ECG-Dxx series (DR4, D4, D8, D2) all take in E1.31 and send out RS485 DMX to controllers. controllers can be anything from animatronics to pro jobo lights or a DMX -> Pixel controller (TP3244).

One problem is that pixels mount up in a hurry. so going E1.31 -> DMX -> pixel can get more expensive and less responsive. So going E1.31 -> Pixel directly is the way most people want to go (expense allowing).

ArtNet (not Arcnet which is an old LAN hardware/protocol) vs E1.31 is just a question of how to get the data over the ethernet connector to the devices. We support E1.31 right now on all of our products. we have ArtNet working in the lab and will enable it in very near firmware upgrades.

ArtNet is still more popular in the Pro world. they never totally embraced the E1.31. Also some software supports one, some the other, and some both. So we just want to be flexible where possible.

So, short answer, ECG-Pxx series direct to pixel is probably best for megatrees etc. if you have some RGB spots or candy canes or something ECG-Dxx to DMX and then daisy chaining the DMX signals is better.

Look at my signature block: "There are no rules, and those are the rules". There is not one best or only way to do most things.

-Ed
 
I'm guessing the answer to this is obvious but I assume that the ECG-P2 will be supporting the 3001 pixels.


Thanks
John
 
all Pxx series use the same code base. we currently support WS2801, LPD6803, TM180x, TLS3001 and plan on adding more.

The TLS3001 is only linear at the moment, we are adding dimming curves to map the 8 bit space into the 12 bit space very soon.

-Ed

btw: this is a good time to mention. based on my research TLS3001 is also the same as CYT3005 but the CYT3001 is a different beast. I could be wrong. But that is why I always say TLS3001 and not 3001.
 
Im not sure if this is an easy question to answer but, will the new p2 be
Compatible with madrix. Either the e1.3 or artNET? Or do you have to use
Pre approved controllers?

Thanks in advance :)
 
moogle said:
Im not sure if this is an easy question to answer but, will the new p2 be
Compatible with madrix. Either the e1.3 or artNET? Or do you have to use
Pre approved controllers?

Thanks in advance :)
Click to expand...

Actually this is a simple answer - Yes.

Longer comment:
Madrix, LightFactory and other Pro software and even LSP/Vixen - it is not about the software being compatible with any particular Hardware Controller when the controllers use industry standard communications protocols.

DMX, sACN(E1.31), artNET are the three industry standard data protocols usually output by Pro Level software.
Not all Pro software yet supports sACN though.

So for people looking to use hardware designed in the community it's as simple as looking for hardware that uses one of the industry standard protocols that the chosen software supports.

Hardware not based on Industry Standards will stop you moving away from or up to Pro Level software that is becoming more desirable as RGB Pixel counts increase through the roof.

Cheers
Phil
 
ahh thats good to hear. I assumed so, however the wording on the madrix website was making me think i needed an approved controller.


I will definitely be buying a ECG-p2 as soon as they are released for my 900 pixel array im making soon. I thought i was going to need a more expensive 8 universe dmx led-walker controller.


thanks for the quick response
 
Ed,
Any update on the availability of the ECG-P2 and X2 hardware?
I plan on building a 16 universe RGB Tree this year. If I have understood everything correctly, to accomplish this, I would need 3 of the P2 and 2 or 3 the X2? That would give me some head room to spare. Can you clarify? Thanks.
 
Hi Mark
using your info you would end up with 28-30 universes, so you would have loads of headroom. You could get away with 2 of P2 and no head room or 2 of P2s and 2 of X2 and end up with 4 spare universes as a minimum.
 
Duh I can add, no really. Right. 2 strings 4 Universes each, 8 universes per P2. 2 X2's give me an additional 4 universes. Thanks Dougie.
That still leaves availability update.
Ed by chance are you going to Academy in June?
 
Zman et al -

Things progressing real well on all products. Expect to have some hard info by early next week. I'm shooting for announcing/releasing before the end of May and having availability by 15th June. We had some minor production hurdles that came up a week ago and took last week to straighten out.

I would only count on the 2x 4 universes on the main board for the initial ECG-P2 production. The work on XCG-X2 is progressing but might take another week or so to fulfill it's potential.

-Ed

We probably aren't attending any shows in the near future. The time for travel and show vs. putting final touches on products is not justified. We are looking at having a set of prototypes make the rounds of all the ACL mini's in June. We would ship them to someone for the first show and then pay to ship/forward to someone for each succeeding show.
 
zman said:
Ed,
Any update on the availability of the ECG-P2 and X2 hardware?
I plan on building a 16 universe RGB Tree this year. If I have understood everything correctly, to accomplish this, I would need 3 of the P2 and 2 or 3 the X2? That would give me some head room to spare. Can you clarify? Thanks.
Click to expand...


Z,


One thing to consider is the trade off between the number of pixels you control and the risk of losing that entire string in the display due to a pixel failure.


Typically we have seen in the past a controller output controlling 50 to 100 pixels with some people running maybe 150.
Now as pixels are a repeated serial protocol the failure of a pixel early in the string would take out that string of 50/100/150 pixels, with maybe not a noticeable lose on the night.


Now drive 600 pixels from the same single output on a ECG-P2 because we can then the failure of a pixel could take out a 1/4 of 2400 pixel megatree.... this you will notice.


Now if you have confidence that pixels won't fail and accept the risk then all's good, just wanted to flag the risk.


Cheers
Phil
 
You must log in or register to reply here.
Back
Top