Between 10's of thousands of channels, and hundreds.

C

charleskerr

New elf
Joined
May 28, 2011
Messages
37
Well, last year a friend and I did a show using DMX. We use Mac's, and like the native integration, so spent most of the year writing native Cocoa software to control our show (and visualize it, etc).


Along the way, we decided it would be fun to develop our own controllers, and pixel controllers. We knew a lot are going to E1.31, but for us, it felt like overkill. We wanted more channels, but as we plan on using pixel control to accent the show, we don't feel we need tens of thousands of channels. We felt if we could drive 3K or more channels from a single "dongle", we could live with that (we had two dongles threaded last year, and felt if worse, we could do that again).


We also like the ability to refresh at 25msec, so that was another one of our requirements. Anyway, we thought about intelligent ways to do our protocol, but decided to just go with a "stupid" streaming approach (and thus named it Stupid Streaming Data, SSD). It actually sends two streams of data down four wires.


Anyway, we have the dongle completed and running, and have a DC controller bread boarded. THe mac Software is updated to support it.


Anyway, didn't know if anyone was interested in expanding to a larger amount of channels, but not have to worry about the ethernet setup for E1.31. We are over at www.diyblinky.com.


We move slowly, as this is a huge learning curve for us, but this is purely a hobby for us. So to us, it has the right priority.
 
Well it's great to see software work in the MAC space, i don't own one but realise that this has been an un-catered space in this hobby.


I can't say that the idea of another proprietary protocol fills me with any joy as this just further complicates/muddies the waters for new people into the hobby and makes it worse for the experienced people to assist and advise.


Industry Standards DMX, ACN(E131) provide for the greatest inter-connectivity of products now and into the future.
E131 is as simply as it gets these days, everyone knows how to plug in a network cable, network switches are a dime a dozen and the star data cabling from the switch is simple to explain.


I will however welcome you to throw information and designs back into the development area here as many people still enjoy true DIY and your proposed design openness promises to shake up the existing DIY community.


Good luck with the forum and the various hardware designs.


Aussiephil
 

[/size]I look at it this way, there isn't a standard for USB interface for 3000 or so channels. I don't want to have to setup a switch, etc, nor take the hassle/cost (yes, I know it isn't great cost, but it isn't something I need). I appreciate the simplicity, but it is as simple to plug in a usb cable as well.

[/size]But I do understand the position! And I haven't ruled out the day I won't update to some type of ethernet connection, but for now, I can avoid the learning curve to program the firmware for the E1.31. As I said, if you want a lot of channels, it is the way to go. But for a few thousands, I think this is good enough. And easy for anyone to implement (for instance, one can interface to it as an Entec Pro, just they can write up to 3036 channels instead of 512).
Thanks for input!

Anyway, it is a hobby, and most of the stuff we do, we post up for others to do what they want with it.
 
Charles


:) I didn't say "closed", i did realise it was declared open and you may even get surprised at who picks it up, but thanks for understanding my comments as it is all to easy to take things the wrong way.


One thing, have you looked into the concept/using hyperDMX?


Phil
 
I tend to agree here, love the fact that you guys are working on Mac solutions and designing open source boards but i like things that are based on standards so interconnectivity isnt an issue and that is what allows people choices. Because without the app to support your hardware then the only choice they will have is to use your software which then limits choice.

I think that the smart string dongle from RJ is a USB multi thousand channel dongle, so its not like this path hasnt been walked before

I do hope that you consider including DMX/e1.31 support as i believe this will give your controllers a lot more backing and community support. If your devices could support both a standard comms and the new comms this will go a long way to allowing people options in the future.

But then it seems like your doing it for yourselves and if others want to join in they can.

I dont want you thinking that we are bagging your efforts in any way, we appreciate good design and effort, but would like to highlight some potential issues that may come about by introducing another non standard communication to the community where many of the people new are already confused.

So i look forward to seeing what you talented guys come up with in the future
 
Yes, we actually looked at a lot of options.


We balanced our skills of firmware, Mac Software, Electrical understand, and assembly (etching, etc) against our needs and options.


It came down to E1.31, or a way to extend a simple interface to write from the computer. The streaming on the two RS-485 was the simplest for us to do firmware wise for now, so we could move on off the distribution to take the Manchester coding with the TLS3001 firmware we wanted to bite off next for our smart pixel controller.


So we decided on SSD. We did recognize that one may want to also do DMX, which is why with a jumper, our dongle will take up to a 1024 channels, and put out two DMX universes (not something we use, but a nice fallback).


We definitely want to stay RS-485 on our actually controllers, due to cost (we just don't need ethernet for around the yard distribution and the cost on each controller). But we will probably , after we get setup, later go back and see if a E1.31 dongle type device to SSD might make sense.
Just have soooo much on the list. Not only do we have this software (firmware, light software) and design, we have had to write our own Logic Analyzer software, and we did our own SSD analyzer software to aid debugging the our network. Also, we are not anywhere the most experienced or learned in this fields, just curious enough with motivation to actually try stuff *smile*


PS, one thing that we traded differently from RJ's large channel USB dongle was support for 25msec requirement, and usage of all data values. So there are other trades.
No offense taken, I think all the comments have been valid. We appreciate standards as well. And if we go ethernet, we probably won't make a "new" standard. But we don't think we should have to change our transport (USB), to just form with a single standard.


I have talked to Matt about seeing if xlights could be updated to allow an enter pro compatable dongle say it has more then 512 channels (then flights would actually be able to use the dongle, and thus controllers), opening it past usage of our software.
 
AussiePhil said:
Charles


:) I didn't say "closed", i did realise it was declared open and you may even get surprised at who picks it up, but thanks for understanding my comments as it is all to easy to take things the wrong way.


One thing, have you looked into the concept/using hyperDMX?


Phil
Click to expand...




If we're talking about standards then hyperDMX in the same idea I think it should be noted that hyperDMX is not an officially recognized standard. It is an extension to DMX developed by a few members of the hobby. I have nothing against it. However it's not a standard.
HyperDMX only works on devices that are specifically designed to operate under a hyperDMX data stream (unless you're using the lowest warp speed, and different start bits, but then you lose refresh... blah blah blah)


My $.02
 
Thanks for the clarification.


Didn't mean to start a controversy over standards. I look at it a tad different. As an EE for many years, I appreciate standards, so by all means understand the points being raised I would also point out, that standards are applicable some sort of constraints as well. I do not agree with the fact, if one wants larger then 512 channels, there is one standard. I think I would agree, that if one is going to use ethernet as a transport, and wants to do large channel counts, one should have some understanding of why one isn't adopting existing standards.


So we looked at our constraints. We didn't want to have to worry about switches/routers, etc. We wanted to stay with USB, have a 25msec refresh, and support 2-4K channels. Since we wanted to do USB and large pixel counts, as FastEddy pointed out, DLA has pixel net. To avoid making additional standards, we did consider it. But if didn't meet our criteria (25msec, and full range of dimming values).


So we didn't just go about doing a new protocol to just do one. There was no protocol standard that met our constraints. That is why new ones get made.


Will it never be adopted, perhaps not. As Fasteddy pointed out, this is our hobby, and something we take enjoyment in doing. We noticed there where not a lot of sites, to actually documenting and delving into the details of exploring the end to end (hardware, firmware, software) of the problem. So we decided to document that, our experiences and our failures (such as some attempts on hand etching our boards). As with all hobbies, we see it as a way to share, for others may enjoy to participate, and we can learn from others as well.
We are not about competing, or looking for a following. Just something we enjoy, and explain the problems we encounter, and have discussion on how to go about solving them.


I think the discussion on standard is a good one. It should be a factor, and this is the type of input we appreciate. Just recognize, it isn't the only factor, we have other constraints as well.
 
ChillOutDocDoc said:
AussiePhil said:
Charles


:) I didn't say "closed", i did realise it was declared open and you may even get surprised at who picks it up, but thanks for understanding my comments as it is all to easy to take things the wrong way.


One thing, have you looked into the concept/using hyperDMX?


Phil
Click to expand...




If we're talking about standards then hyperDMX in the same idea I think it should be noted that hyperDMX is not an officially recognized standard. It is an extension to DMX developed by a few members of the hobby. I have nothing against it. However it's not a standard.
HyperDMX only works on devices that are specifically designed to operate under a hyperDMX data stream (unless you're using the lowest warp speed, and different start bits, but then you lose refresh... blah blah blah)


My $.02
Click to expand...


Josh


In Aus we charge GST so really i can only take 1.8c of that :)


Agreed, i mentioned it only because it is already something that can transport up to 2048 channels using RS485, and wasn't sure if Charles had heard of it.


Cheers
Phil
 
charleskerr said:
Thanks for the clarification.


Didn't mean to start a controversy over standards. I look at it a tad different. As an EE for many years, I appreciate standards, so by all means understand the points being raised I would also point out, that standards are applicable some sort of constraints as well. I do not agree with the fact, if one wants larger then 512 channels, there is one standard. I think I would agree, that if one is going to use ethernet as a transport, and wants to do large channel counts, one should have some understanding of why one isn't adopting existing standards.


So we looked at our constraints. We didn't want to have to worry about switches/routers, etc. We wanted to stay with USB, have a 25msec refresh, and support 2-4K channels. Since we wanted to do USB and large pixel counts, as FastEddy pointed out, DLA has pixel net. To avoid making additional standards, we did consider it. But if didn't meet our criteria (25msec, and full range of dimming values).


So we didn't just go about doing a new protocol to just do one. There was no protocol standard that met our constraints. That is why new ones get made.


Will it never be adopted, perhaps not. As Fasteddy pointed out, this is our hobby, and something we take enjoyment in doing. We noticed there where not a lot of sites, to actually documenting and delving into the details of exploring the end to end (hardware, firmware, software) of the problem. So we decided to document that, our experiences and our failures (such as some attempts on hand etching our boards). As with all hobbies, we see it as a way to share, for others may enjoy to participate, and we can learn from others as well.
We are not about competing, or looking for a following. Just something we enjoy, and explain the problems we encounter, and have discussion on how to go about solving them.


I think the discussion on standard is a good one. It should be a factor, and this is the type of input we appreciate. Just recognize, it isn't the only factor, we have other constraints as well.
Click to expand...


Charles,


I see this as good, healthy discussion rather than controversy. It's great to get some understanding about the direction you are going in and i'm sure that any number of tech heads may pop up from here with thoughts in the future


Cheers
Phil
 
It's great to see others coming up with new hardware and software. I think the Mac sector has been under represented for some time, so this will certainly help those folk.
 
Charles,

Not at all a controversy. You can picture me as the teenager of the site that somehow finds his way to giving some of the well aged (think of fine wine, not old) members a lot of gray hair.

Overall I love seeing other development take place, it excites me as much as when I'm developing my own projects.
I just wanted to clarify the difference between DMX and hyperDMX. More often than not, a new protocol is needed, otherwise there would be one universal language for the world, and humans and computers would both understand it. All in all, who cares if you use your own or something that's out there. It's YOUR show and YOU know what you need best.

I definitely look forward to seeing your development progress and will check out your site when I get home.

my $.03 (to make up for GST)
 
You must log in or register to reply here.
Back
Top