Jump to content
Light-O-Rama Forums
prevue12

N4-G4-MP3 Director Documentation

Recommended Posts

Was thinking about using one of the new N4-G4-MP3 Directors,  but then remembered I added TUNE TO signs made from P5 panels last year that run on E1.31.  I can't find documentation on the specs for this on the web site, does anyone know if the outputs can be E1.31?  Trying to get away from my computer running the show. 

Share this post


Link to post
Share on other sites

There is no indication on the web page for it that it supports E1.31.  Unfortunately the link to the manual goes to the G3-MP3.

 

  • Like 1

Share this post


Link to post
Share on other sites

No LOR MP3 Director works with E1.31/Ethernet.

I'll see why the N4-G4 manual is not posted.  Can post a link to the page that is linking the N4 G4 to the G3?

Share this post


Link to post
Share on other sites
Posted (edited)
14 minutes ago, k6ccc said:

Sure can.

http://www1.lightorama.com/stand-alone-show-directors/

About a quarter of the way down the page.

 

When I click on the link it takes me to the G3 not the new one

NM- I see Mike was asking and not stating he was going to post the link to the N4 G4 LOL

JR

Edited by dibblejr

Share this post


Link to post
Share on other sites

Exactly.  That was the point.  The link to the G4 manual actually goes to the G3 manual.  Bet it gets fixed real soon too...

 

Share this post


Link to post
Share on other sites
1 minute ago, k6ccc said:

Exactly.  That was the point.  The link to the G4 manual actually goes to the G3 manual.  Bet it gets fixed real soon too...

 

Yes and that may help Orville and some of the others with their questions.

Jim- isn't their a bridge or something that the OP could use for his quest? Just asking, seems I read that some place for the panels.

JR

Share this post


Link to post
Share on other sites
4 minutes ago, dibblejr said:

Jim- isn't their a bridge or something that the OP could use for his quest? Just asking, seems I read that some place for the panels.

I think that would be the PixieLink - but it's not available yet.

 

Share this post


Link to post
Share on other sites
1 minute ago, k6ccc said:

I think that would be the PixieLink - but it's not available yet.

 

I think the pixielink is geared towards pixie controllers. The OP is using P5 panels, can they be controlled using pixies? (just trying to learn something here) They are my next venture. I thought there was some sort of dongle and perhaps that could connect to a director to run the e1.31. 

I think the pixielink will allow those of us with pixies be able to run them in DMX el.31 - much needed in my case. It is exactly what I need. That's why I am holding off buying any more DMX controllers. I already have 30+ pixies. LOL

JR

Share this post


Link to post
Share on other sites

Maybe I failed to understood what the PixieLink will be.  I thought it was a converter that would input LOR network and output E1.31.  Assuming that is the case, it still might be hard to get enough bandwidth on the LOR network side of it.  Even my fairly small P10 matrix is a little over 18,000 channels - which is roughly double the max channel count for a 1,000K enhanced LOR network.  And my even smaller P5 matrix is double that number of channels.

 

Share this post


Link to post
Share on other sites
9 minutes ago, dibblejr said:

The OP is using P5 panels, can they be controlled using pixies?

No.  With one exception, currently, the only way to control P5 & P10 panels is with a Raspberry Pi or BeagleBone computer running Falcon Player.  To drive that from LOR, you use E1.31.  The exception is that you can drive a panel using a Video sender and receiver card combination (there are a couple of these) where you are sending video - not sequenced in the traditional sense.

 

 

 

Share this post


Link to post
Share on other sites
5 minutes ago, k6ccc said:

No.  With one exception, currently, the only way to control P5 & P10 panels is with a Raspberry Pi or BeagleBone computer running Falcon Player.  To drive that from LOR, you use E1.31.  The exception is that you can drive a panel using a Video sender and receiver card combination (there are a couple of these) where you are sending video - not sequenced in the traditional sense.

 

 

 

Got it. 

JR

Share this post


Link to post
Share on other sites
Posted (edited)
12 minutes ago, k6ccc said:

Maybe I failed to understood what the PixieLink will be.  I thought it was a converter that would input LOR network and output E1.31.  Assuming that is the case, it still might be hard to get enough bandwidth on the LOR network side of it.  Even my fairly small P10 matrix is a little over 18,000 channels - which is roughly double the max channel count for a 1,000K enhanced LOR network.  And my even smaller P5 matrix is double that number of channels.

 

Just a snippet of what I had read when they first introduced the concept and design. I volunteered to Beta test them right after the Expo but I guess they may not have needed a beta tester for them . 

"You can begin using pixels with inexpensive Pixie controllers, which operate on LOR networks, so no Ethernet LAN is required. If your show grows to a point where the data bandwidth of Ethernet becomes a requirement, you don’t lose your investment in Pixies; you can move them to a PixieLink Adapter. PixieLink is a high-speed protocol supported by Pixie controllers with firmware 1.05 or greater. PixieLink protocol has a guaranteed bandwidth per output port of 16 full (512 intensities) DMX universes being refreshed 44 times per second. The PixieLink adapter provides Ethernet users with a simple, less expensive method of creating self-contained pixel props. You could make a small prop with one Pixie2 controller and put 8 of these props on one PixieLink port. On the other end, you could create larger props with Pixie16 controllers. Or, a mix of Pixies."

Edited by dibblejr

Share this post


Link to post
Share on other sites

Pixielink:  Other way around.  It takes E1.31-like data and outputs ELOR/Pixel Protocol.  It may actually be E1.31 or may be something else (like what I envisioned when I created the Net Prefs program:  LOR:ACN).  I am not involved with the development of Pixielink.

I just learned that we don't have an N4 G4 manual made yet.  Dan said "We have not made the G4 manual yet. Will get it done shortly. "

The N4 G4 works pretty much like the G3 MP3 director, but instead of 2 networks, it has 4 (or 3 + Director Link).  The help file for Hub describes how to use Director Link.

http://www.lightorama.com/help/index.html?differences_between_mp3_direct.htm

http://www.lightorama.com/help/how_to_use_director-link.htm

http://www.lightorama.com/help/advanced_sd_card_wizard.htm

Etc.

Share this post


Link to post
Share on other sites
21 minutes ago, DevMike said:

Pixielink:  Other way around.  It takes E1.31-like data and outputs ELOR/Pixel Protocol.  It may actually be E1.31 or may be something else (like what I envisioned when I created the Net Prefs program:  LOR:ACN).  I am not involved with the development of Pixielink.

So much for what I remembered...

Honest opinion here:  Use E1.31 - not your own variation of it.  Reason is that it gives a better ability of people running other software to use LOR controllers (which lots of those other people have).

 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
5 hours ago, DevMike said:

No LOR MP3 Director works with E1.31/Ethernet.

I'll see why the N4-G4 manual is not posted.  Can post a link to the page that is linking the N4 G4 to the G3?

When I got my G4 {N4-G3 Director, unit is actually stamped G4} Director in hand, what I got was the G3 manual to go with it.  Seems there isn't a printed version or an on-line version of the G4 Director manual.  Like others, online goes to G3, and the manual that came with my G4 is also the same manual posted online for the G3.  

G3 manually does not mention  4 ports, only  2 on the G3 Director.  I think the G4 may be close to the same as the G3 Director with a few more improvements and additions.   I read the G3 manual, but it didn't seem to cover all the aspects of the G4 Director unit.   Would have been nice to have the correct manual available for the newest Director units {G4/4 port}.

If one is available, I can't print it, but at least I could download it and have it for reference to know what the G4 specifications and functions actually are.

 

Mike, tried searching for the N4-G3 manual, but the link isn't found now.  Did a search with assorted variations and this is what I got:

Nothing Found

Sorry, but nothing matched your search terms. Please try again with some different keywords.
Search for:
 

Tried words manual, booklet, instructions and all yielded that same result now {as of 05/22/2020  16:30}.

But I know there was a link for it under the support area and documentation at one time, as that is where I downloaded the manual from originally, but when I downloaded it, it was the G3-MP3 Director manual, not the one for the G4{N4-G3 MP3 Director} unit.  I've not ever seen a G4 Director manual as yet, and when I received mine a couple weeks ago, it came with the G3-MP3 Director Manual.  I know G4 can use up to a 32GB SD Card, as that is what came with mine, the G3 manual states only up to an 8GB SD Card, that's a huge difference, as well as the G3 has 2 ports and the G4 has 4 ports.

So if you know where an N4-G3 MP3 Director manual is located, I'm sure all of us that has purchased one would love to get the link to the G4 Director manual if there is one somewhere.  But from my searching the LOR Home website, sure couldn't find one.

Edited by Orville

Share this post


Link to post
Share on other sites
On 5/22/2020 at 1:23 PM, k6ccc said:

Honest opinion here:  Use E1.31 - not your own variation of it.  Reason is that it gives a better ability of people running other software to use LOR controllers (which lots of those other people have).

The PixieLink Adapter does process standard E1.31. Everybody's software already has the ability to transmit E1.31, it would be silly to create some new protocol. The idea was to make an inexpensive device that would allow Pixies, and other LOR G3 controllers, to be easily moved to a standard E1.31 environment. The Pixie firmware, that supports the higher speeds used by the PixieLink Adapter, also supports 200 pixels/port. This is not possible with standard E1.31 since it really is just an IP transport for DMX universes. We will most likely allow (at some point in the future) users to configure universes that have 600 intensities instead of the 512 permitted by DMX -- this internal LOR discussion sounds like we may be running a non-standard E1.31; all we've done is allow the PixieLink Adapter to process a universe in the E1.31 message that is bigger than 512 intensities. Presumably, the Adapter will never see this larger packet from non-LOR software.

Share this post


Link to post
Share on other sites
1 hour ago, LightORamaJohn said:

The Pixie firmware, that supports the higher speeds used by the PixieLink Adapter, also supports 200 pixels/port. This is not possible with standard E1.31 since it really is just an IP transport for DMX universes.

John, I can't think of any E1.31 pixel controller that can't put multiple Universes on a single pixel string.  In the case of a standard E1.31 pixel controller, the controller is outputting SPI pixel data, not DMX, so the 512 channel limit of a DMX universe does not apply.  Every E1.31 controller I have ever played with could apply multiple DMX universes of E1.31 data to each pixel string.

In the PixieLink, since Pixie controllers are LOR protocol only, the PixieLink would be outputting LOR protocol, not DMX protocol, so again, the DMX limit would not apply.  In fact, I would presume that the RS485 output would be able to handle dozens of DMX universes that come in encapsulated as DMX over E1.31, and output as LOR protocol over the RS-485 - else you could not very well drive any of the larger capacity Pixie controllers.

Either that or I am missing something here...

 

Share this post


Link to post
Share on other sites
Posted (edited)

Interesting as when I was reading through my Pixie manual is shows DMX universes is limited to 500 {on some of the Pixies}, not the usual 512 universes available with standard DMX protocols.   But I don't know much about how DMX works and can only go by what I read in the LOR supplied manuals for the Pixie Controllers about it.

P.S. Would still like a link to the actual N4-G3 MP3 {G4} Director unit if one is available.  The current manual I got with my G4 Director is not even listed within the manual I received, and I know it has a few more additions and features.  Would be nice to have an actual manual for the G4 Director I now own.

Edited by Orville

Share this post


Link to post
Share on other sites
22 hours ago, k6ccc said:

John, I can't think of any E1.31 pixel controller that can't put multiple Universes on a single pixel string.  In the case of a standard E1.31 pixel controller, the controller is outputting SPI pixel data, not DMX, so the 512 channel limit of a DMX universe does not apply.  Every E1.31 controller I have ever played with could apply multiple DMX universes of E1.31 data to each pixel string.

The PixieLink adapter is not a pixel controller. It maps 192 E1.31 universes to its six RS485 ports. If we were to go the route of using an additional universe just to target the remaining 30 pixels/string, it would have to handle 384 universes. This probably isn't possible, but even if it is, it would mean that the LAN bandwidth consumed by a fully loaded PixieLink device would jump from 32+Mbps to 65Mbps because I have only seen full DMX payloads regardless of the configured pixels/string. It seemed to us to be the wrong way to go, especially since almost no one does power injection to get above 150 pixels/string anyway. Using multiple universes to target one pixel string is an artifact of the higher cost of LAN based E1.31 pixel controllers. The Pixies were designed to make it possible to distribute the controllers rather than use null pixels and power injection. LOR users typically build props like trees, faces, arches, or outline something. If you are just doing a huge matrix, you are probably better off doing it with an E1.31 Pixel controller.

22 hours ago, k6ccc said:

In the PixieLink, since Pixie controllers are LOR protocol only, the PixieLink would be outputting LOR protocol, not DMX protocol, so again, the DMX limit would not apply.  In fact, I would presume that the RS485 output would be able to handle dozens of DMX universes that come in encapsulated as DMX over E1.31, and output as LOR protocol over the RS-485 - else you could not very well drive any of the larger capacity Pixie controllers.

There is a new protocol in Pixies specifically for the PixieLink device. You should not use ELOR when using a PixieLink adapter to talk to Pixies. When the PC transmits ELOR, it compresses across pixel strings and across controllers. This is impossible because the PixieLink adapter does not know what Pixie controllers are hanging off its ports. An even if it did, it would have to compare all the universes destined to a port to recreate the compression. This would delay transmission, and I don't think there is enough processor power to recreate the compression in real time. Also, it would be really hard, so I'm tapping out on this.

ELOR has a maximum speed of 1Mbps, and usually this speed along with the compression works well. But, I felt that in order to make the Pixie viable for any user (meaning non-LOR too) of E1.31 pixel controllers, it would not be good enough to say your display will probably work well. I wanted guaranteed bandwidth to the Pixies. The new PixieLink protocol that Pixies with 1.05 firmware understand runs up to 8.5Mbps. This allows me to send uncompressed intensity data with guaranteed delivery regardless of complexity.

Share this post


Link to post
Share on other sites
29 minutes ago, LightORamaJohn said:

The PixieLink adapter is not a pixel controller. It maps 192 E1.31 universes to its six RS485 ports. If we were to go the route of using an additional universe just to target the remaining 30 pixels/string, it would have to handle 384 universes. This probably isn't possible, but even if it is, it would mean that the LAN bandwidth consumed by a fully loaded PixieLink device would jump from 32+Mbps to 65Mbps because I have only seen full DMX payloads regardless of the configured pixels/string. It seemed to us to be the wrong way to go, especially since almost no one does power injection to get above 150 pixels/string anyway. Using multiple universes to target one pixel string is an artifact of the higher cost of LAN based E1.31 pixel controllers. The Pixies were designed to make it possible to distribute the controllers rather than use null pixels and power injection. LOR users typically build props like trees, faces, arches, or outline something. If you are just doing a huge matrix, you are probably better off doing it with an E1.31 Pixel controller.

There is a new protocol in Pixies specifically for the PixieLink device. You should not use ELOR when using a PixieLink adapter to talk to Pixies. When the PC transmits ELOR, it compresses across pixel strings and across controllers. This is impossible because the PixieLink adapter does not know what Pixie controllers are hanging off its ports. An even if it did, it would have to compare all the universes destined to a port to recreate the compression. This would delay transmission, and I don't think there is enough processor power to recreate the compression in real time. Also, it would be really hard, so I'm tapping out on this.

ELOR has a maximum speed of 1Mbps, and usually this speed along with the compression works well. But, I felt that in order to make the Pixie viable for any user (meaning non-LOR too) of E1.31 pixel controllers, it would not be good enough to say your display will probably work well. I wanted guaranteed bandwidth to the Pixies. The new PixieLink protocol that Pixies with 1.05 firmware understand runs up to 8.5Mbps. This allows me to send uncompressed intensity data with guaranteed delivery regardless of complexity.

With as many pixies I have and as many faces as I am converting o RGB I cant wait. Means more faces per controller.

John, any hint of a release date? I would still volunteer for Beta testing, if needed.

JR

Share this post


Link to post
Share on other sites
9 hours ago, dibblejr said:

With as many pixies I have and as many faces as I am converting o RGB I cant wait. Means more faces per controller.

John, any hint of a release date? I would still volunteer for Beta testing, if needed.

JR

The device has been ready for a while. We've had them in stock for at least 6 months.  So, we've been using them for a while and have had no problems -- of course, people using them in real displays will likely expose something(s). We're confident in the hardware. However, we wanted distribution of new firmware to be easy for customers...

There were two problems, one was releasing it right before Christmas, which would have incurred a support load we didn't want, and the other was the bootloader. Dan wrote the bootloader in all our devices in LOR year 0. So, as devices became more complicated, bootload times started creeping up. They finally became ridiculous with the N4 director and PixieLink adapter. So, the bootloader has been re-written for these devices. To take advantage of this, we have to distribute a new Hardware Utility. We will merge that into the next PC software release, which we hope isn't more than a month off.

There is another minor problem in that we are just being allowed to restart our operation. We have the PixieLink boards, the cases, and the firmware, but they have to be assembled,  programmed, & packaged. So, that will happen after we recover from the Mad Grab Sale.

Since the PC software and hardware assembly are done by different groups, these should both be ready in a month or so. I hate giving dates, because as we just experienced, the universe has been particularly uncooperative lately. If we are going to miss this date significantly, I will get some of these out to beta testers so that any problems can be resolved well before Christmas.

Share this post


Link to post
Share on other sites
11 hours ago, LightORamaJohn said:

The PixieLink adapter is not a pixel controller. It maps 192 E1.31 universes to its six RS485 ports. If we were to go the route of using an additional universe just to target the remaining 30 pixels/string, it would have to handle 384 universes.

Ah, got it - it's an almost zero config device.  I am gathering that it is something like:  Universe n maps to output 1 Unit ID y, Universe n+1 maps to output 1 Unit ID y+1, etc

I was making the assumption that like essentially every E1.31 controller out there, you could configure the channel arrangement - to varying degrees.

11 hours ago, LightORamaJohn said:

It seemed to us to be the wrong way to go, especially since almost no one does power injection to get above 150 pixels/string anyway. Using multiple universes to target one pixel string is an artifact of the higher cost of LAN based E1.31 pixel controllers.

Although I personally do not like using really long strings (mainly because a pixel failure will have a far greater impact on your show), there are LOTS of people out there who think that strings of up to at least 1,000 nodes is the way to do it...  Power injection is a very common topic on the various forums (including this one from time to time).

 

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, LightORamaJohn said:

The device has been ready for a while. We've had them in stock for at least 6 months.  So, we've been using them for a while and have had no problems -- of course, people using them in real displays will likely expose something(s). We're confident in the hardware. However, we wanted distribution of new firmware to be easy for customers...

There were two problems, one was releasing it right before Christmas, which would have incurred a support load we didn't want, and the other was the bootloader. Dan wrote the bootloader in all our devices in LOR year 0. So, as devices became more complicated, bootload times started creeping up. They finally became ridiculous with the N4 director and PixieLink adapter. So, the bootloader has been re-written for these devices. To take advantage of this, we have to distribute a new Hardware Utility. We will merge that into the next PC software release, which we hope isn't more than a month off.

There is another minor problem in that we are just being allowed to restart our operation. We have the PixieLink boards, the cases, and the firmware, but they have to be assembled,  programmed, & packaged. So, that will happen after we recover from the Mad Grab Sale.

Since the PC software and hardware assembly are done by different groups, these should both be ready in a month or so. I hate giving dates, because as we just experienced, the universe has been particularly uncooperative lately. If we are going to miss this date significantly, I will get some of these out to beta testers so that any problems can be resolved well before Christmas.

Thank you, I really look forward to this. Much needed as I transfer my faces over to RGB with all of my huge inventory of pixies. Please keep me in mind for the Beta release if needed.

JR

Edited by dibblejr

Share this post


Link to post
Share on other sites
2 hours ago, k6ccc said:

Ah, got it - it's an almost zero config device...

Exactly, you can configure it in a couple minutes:

image.png

2 hours ago, k6ccc said:

Although I personally do not like using really long strings...

The Pixie is based on a 16-bit processor which only has enough RAM to support 3,200 pixels. So the max is 200/port. The idea was to provide users who wanted only 10 to 20 thousand pixels with an inexpensive, easy to configure and cable up solution. We sell a lot of these, so we think we've guessed correctly. As an engineer, it's easy for me to understand and use null pixels and power injection, but as an intrinsically lazy person, it's just too much of a nuisance to setup, configure and then repair displays built that way. I think most commercial users believe this too. It's just so much easier to replace a prop, or pull out a defective pixel string and replace it. It's nice to have a prop that's self-contained, so it's not attached to a bunch of other props.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...