Ilda Digital Network (IDN)

[masterpj]

your price is off by a few hundred euros:

http://www.dexlogic.com/work/4108-is...te-ISP-en.html

But you need a converter for recieving and transmitting end X_x and those are not for the price of 1

[JohnYayas]

But you need a converter for recieving and transmitting end X_x and those are not for the price of 1

You only need a converter on the receiving end. The sending end will likely already be Ethernet ready. You'd only need a sending converter if you hook up to the output of a normal DAC or DMX output, which would only be useful for legacy purposes.

[DexLogic]

Hi all,

Christopher pointed me to this thread (thanks) and I'd like to reply to some posts.
I'm the chair of the Technical Committee of ILDA and was in charge with the development of the specification.

First, please note that the current specification just covers the encoding of artwork and more standards will follow.
Further work is in draft or pre-draft / proof of concept stage. Just need to set a start...

After a first glance over the document, here are some of my findings:

- Signals are now split over things called channels, I believe there can be 64 channels simultaneously
- Rather than specifying which channel does what like with the analog standard (eg pin 1 is X+, pin 2 is Y+ etc) channel assignment is now fully flexible and should be agreed on between the "producer" (the laser program) and the "consumer" (the control board).
- This allows for a uniform way to handle multiple projector setups, no channels are wasted on projectors that only have a green module and there is no longer a limitation on the amount of colours in a projector
- You can also send DMX512 signals over it in the same way as a laser channel
- Same for static effects like bounce mirrors and gratings and such
- There's a distinction between continous point stream (like an analog module) and per-frame streaming
- There is no dedicated shutter channel anymore, the shutter is supposed to go down when no signal is received automatically
- There does not appear to be a way for the consumer to send status signals back to the laser program. It would probably cause too much headache to implement this on every DAC but things like interlock status, temperature, maybe even scanner feedback signal for advanced auto-tuning algorithms would be very neat if they could get sent back to the computer
- somebody at Ilda has difficulties discerning its and it's

- The concept of channels is on separate streams. Regarding the ISP cable - a single link could replace 64 ISP cables (when used in continuous mode). Alternatively, channels could be used to encode multiple streams of frames. The signals (X, Y, ...) are encoded in wide samples that have descriptor sets for the various encodings (X/Y/R/G/B and all the variations that are possible).
- Producer and Consumer do not necessarily agree. Generally, the Consumer shall work with what the Producer sends (only one direction to allow for more complicated setups and filters). To overcome situations where the Consumer might not be able to handle the data - the Producer will be able to ask for capabilities (this will be available in the network protocol) such that it can encode the stream accordingly.
- The Shutter signal can be included in continuous mode (to be able to transparently map the ISP cable)

IDN-Stream is just the encoding of the artwork. Next will be a transport across Ethernet/UDP and storage of the stream in files. The most basic transport will be a realtime profile which is part of the discovery protocol which allows for plug and play and a way to handle device properties (IDN and manufacturer specific).

[DexLogic]

Since multiple devices use multiple transports this just scales.
A single device (well - better a single session) can handle up to 64 channels (could be a 64 head projector - or 32 heads and 32 DMX - well or any logical partition when using frames). Generally a device can support multiple sessions. Regarding Ethernet/IP, a session then needs distinct remote IP addresses and/or port numbers.

The planned protocol is point to point - meaning that each device needs a IDN decoder (well - it's supposed to have a Ethernet interface - right?)
The reason for point to point is that multicast is implemented as broadcast for most off the shelf switches and this would just degrade network performance. However - IDN-Stream can absolutely be used with multicast - this is up to the transport.

I'm currently taking care of developers individually - so please contact me in case you're interested.
The discovery and basic (realtime) transport protocol will very likely be the next step.

I glanced over the document for the first time this morning and noticed it really only talked about the data content and not the transport mechanism. I need to get into the details but right now I am wondering how this works for multiple devices. Let's say there are 10 projectors and 10 DMX fixtures that are to be controlled. Is the intent for some device to capture this stream and send distribute it to the various projectors and fixtures? Or is it intended to be so that each fixture has its own controller that listens for this stream and handles the portion that is intended for it? Or is it a combination where some device might handle a set of fixtures? Or, is that totally undefined and left up to the implementer? Is there a 2nd part coming that defines how this should behave over ethernet so that someone could create compatible hardware that is plug and play or is that in the details of the current document? Maybe these questions will be answered as I read on but these are my questions at the moment.

[DexLogic]

William Benner and Justin Perry made some facebook comments that should clarify this.

Hmmm - I'm not sure how to comment here.
Generally - William Benner and Justin Perry make points about a product of Pangolin.
As long as this is technically based and can be argued I'm more than happy to join.
Unfortunately, wrong statements have already been issued (and I doubt that this will end).
I prefer discussions on a professional level.

With FB4, our standard test scenario is three separate cascaded wireless networks. FB4 can withstand this kind of environment which professionals will no doubt use. From what we know about IDN so far -- our opinion is -- no way. We will make a video comparing the results of FB4 on networks and IDN on networks and then everyone can judge for themselves.

This can easily get into an apple/pear situation.
First, the comparison will not be about IDN vs. FB4. In best case it is about an _implementation_ of IDN vs. FB4.
Second - I wonder where three separate cascaded wireless networks can be used... But - well - my implementation (StageFeed ISP and StageMate ISP) can easily handle this as long as the there is no loss and jitter is low. Regarding the apple/pears - please keep in mind that the converters are transparently copying all ISP signals at 100kHz for lossless reproduction in realtime. When doing such things (the cascaded wireless links) you very likely want to use a frame-oriented transmission or ahead of time streaming (which both is possible with IDN).

Stated another way -- why should Pangolin spend our development time implementing what we strongly believe is a sub-optimal protocol, when we could spend our time continuing to develop the great tools and completely new things for laserists to use? Plus, if we support two protocols, this will INEVITABLY create many support phone calls. Stated another way, we are spending Pangolin's time (and the customer's money) answering phone calls that we would not have otherwise. Sorry, but your idealistic view does not take into account the daily realities of a company that must support products and customers in the field!!!

Well - It's Pangolin's decision whether to implement a protocol or not. I'd however defend the quality. I can't see any sub-optimal issues. Neither did anyone come up with one. About 25 years ago, ISP was set as a standard with a rather idealistic approach to unify the laser projector connection. This was the analogue age. IDN likes to do this digitally (and like ISP, IDN will have sub-standards). From my point of view, it's sad to see proprietary solutions.

Moreover, according to my discussions with Dirk, his IDN boxes could only support a pretty small number of devices on a 100mBit line (something between 3 and perhaps 7). On the other hand, we have had *** FOURTY *** FB4 running on a single 100mBit line.

Hmm - this is wrong. It is 7-8. This means - replacing up to 8 ISP-DB25 cables with one 100 MBit cable.
Since this will very likely involve a switch - and I'm not sure if 100 MBit switches are available anymore - you're very likely into 1G links with up to 80
streams. Please, again, remember that this means copying all ISP signals (X/Y/U4 in 16 bit and Intensity/R/G/B/U1/U2/U3 in 12 bit) at 100 kHz. The link can be configured to use a lower sample rate or less signals - reducing the load...

[masterpj]

Its actually really respectable you are joining in on this conversation and are clarifying things about this protocol.

[DexLogic]

ILDA moves at a snails pace. It took them years to approve frame formats 4 & 5. The industry feeds ILDA, not the other way around. ILDA should be learning what is best for the industry by observing the current needs and taking input from the leaders of the industry. IDN is something that should have been introduced years ago so I don't really buy that ILDA is actually even working in the best interest of the industry. I don't know if Pangolin just wants to keep their secrets or if they just don't have time to argue with committee members about what the best path is. I know how the committees work and I have had a glimpse of how ILDA works. "Works" is a generous term in both cases.

Well - IDN-Stream started about 5 years ago and took about one year of full time development (just for me) up to where it is right now. This includes research, tests, proof of concept, reference implementation, drafts, discussions - and the final document. Needless to say that I'm not payed by ILDA.

Pangolin did not contribute. As said earlier - Everyone who decides to do a proprietary solution is free to do so - and there are many. It's not just Pangolin. I spoke to just about all of them and asked them to join - very early.

IDN aims to be an open standard, usable by everyone - and regarding the projector connection, featuring a network API such that it can be used with any operating system.

[DexLogic]

Regarding the ILDA plug to IDN converter: It's too expensive... What like 750 euros for a Ethernet chip, FPGA or DSP and an ADC and DAC and some ports?? Like I get it costs time and money to write software for those 2 devices but if they'd lowered the price of it they would have more people buying it and more of it.

It's EUR 349 for the ADC and EUR 299 for the DAC.
Most of this is manufacturing. You can do your own ADC/DAC boards and use the CPU or even do this yourself. I'm fine with EUR 100.- for the FPGA configuration and firmware license on both sides. In case you have serious suggestions on how to lower prices I'd be happy to talk to you - you should consider the whole system though. It's not just the mentioned components (and - well - it's times two - two ends...).

[DexLogic]

Its actually really respectable you are joining in on this conversation and are clarifying things about this protocol.

Thanks :-)
Sure. Just - keep in mind that a single person doesn't scale too good...

About five years ago, there was a very intense discussion about digital transmission on the ILDA list. By that time, the Technical Committee was pretty much idle for various reasons. Tim remembered my work in the 90es (I did the first digital projector there) and asked me to take over. I did and was working on IDN since then. The first demo was about three years ago in San Antonio. Such things usually take a long way - but - I'd assume that you'd rather like it well researched and at a professional level than overhasty and incomplete...

[JohnYayas]

Well - IDN-Stream started about 5 years ago and took about one year of full time development (just for me) up to where it is right now. This includes research, tests, proof of concept, reference implementation, drafts, discussions - and the final document. Needless to say that I'm not payed by ILDA.

Pangolin did not contribute. As said earlier - Everyone who decides to do a proprietary solution is free to do so - and there are many. It's not just Pangolin. I spoke to just about all of them and asked them to join - very early.

IDN aims to be an open standard, usable by everyone - and regarding the projector connection, featuring a network API such that it can be used with any operating system.

Thanks for chiming in and adding some history. I think IDN is a fantastic idea and am glad to hear that the other parts of that I asked about earlier are eventually coming. I am a developer of small independent laser show software package called Spaghetti. If it helps the cause at all, I would certainly assist in becoming an earlier adopter of the standard, whether finalized or not. Feel free to reach out to me at support@hingednewt.com or even a PM through this forum if interested.

Edit: after re-reading your first reply to me you already mentioned contacting you to get involved, so I will.