As several people pointed out last night, USB Serial is too slow for even DMX communication. It was suggested that we look at HID or just raw packets. I haven't been able to turn up much information on any speed limitations of HID, but the Atmega 32u4 (for example) supports both 1.5 and 12Mbps in some manner. I guess the mode implementation is up to the user.
A USB Serial option would be nice, but we definitely need a faster communications method, either implementing our own USB or using Ethernet, or both.
As for protocols, RDM doesn't look terribly difficult to implement, and gives us DMX compatibility. Also, ACN, if we wanna get crazy with it.
I posted some technical questions on the wiki page. Not sure if we should have a multi-level protocol with a basic shift register based system for the output boards and optional controllers that manage busses of these sift register systems.
On Fri, Sep 23, 2011 at 2:01 PM, Max Henstell <m...@kapamaki.net> wrote: > As several people pointed out last night, USB Serial is too slow for even > DMX communication. It was suggested that we look at HID or just raw packets. > I haven't been able to turn up much information on any speed limitations of > HID, but the Atmega 32u4 (for example) supports both 1.5 and 12Mbps in some > manner. I guess the mode implementation is up to the user.
> A USB Serial option would be nice, but we definitely need a faster > communications method, either implementing our own USB or using Ethernet, or > both.
> As for protocols, RDM doesn't look terribly difficult to implement, and > gives us DMX compatibility. Also, ACN, if we wanna get crazy with it.
Here's what I'm thinking on the hardware level, let me know if this makes sense.
Single master (the "logic unit") with an RS485 transceiver. Communication with dumb modules (no microcontroller) happens over unidirectional SPI over 485, at adjustable speeds (send-and-pray). Communications with smart modules (with micro) happens over bi-directional SPI over 485.
Looks like most 485 transceivers can do at least 16Mbps with slew rate limiting off, I see no reason to support at least 10Mbps. If I'm not terrible at math, that supports about 2000 RGB LEDs at 16bits/color, which is probably excessive. We could also support enabling the slew rate limiting for low speed communications (~500kbps) over longer distances, or for supporting DMX networks.
Does that sound practical?
On Fri, Sep 23, 2011 at 3:06 PM, Nick Vermeer <nicholas.verm...@gmail.com>wrote:
> I posted some technical questions on the wiki page. Not sure if we should > have a multi-level protocol with a basic shift register based system for the > output boards and optional controllers that manage busses of these sift > register systems.
> On Fri, Sep 23, 2011 at 2:01 PM, Max Henstell <m...@kapamaki.net> wrote:
>> As several people pointed out last night, USB Serial is too slow for even >> DMX communication. It was suggested that we look at HID or just raw packets. >> I haven't been able to turn up much information on any speed limitations of >> HID, but the Atmega 32u4 (for example) supports both 1.5 and 12Mbps in some >> manner. I guess the mode implementation is up to the user.
>> A USB Serial option would be nice, but we definitely need a faster >> communications method, either implementing our own USB or using Ethernet, or >> both.
>> As for protocols, RDM doesn't look terribly difficult to implement, and >> gives us DMX compatibility. Also, ACN, if we wanna get crazy with it.
Which driver chips were you looking to use again? What's their max speed? requiring multi-port 10Mbit SPI probably puts us into ARM territory, as I don't think you can get that much data in and out of an atmega@16Mhz.
Checking the math, 10 Mbit SPI seems to be able to do 104 updates/sec at 6000 channels (or 2k RGB) and 16 bit per channel. Thats way more than what we would want running on one controller anyway, so that should be good.
On Sun, Sep 25, 2011 at 3:28 PM, Max Henstell <m...@kapamaki.net> wrote: > Here's what I'm thinking on the hardware level, let me know if this makes > sense.
> Single master (the "logic unit") with an RS485 transceiver. Communication > with dumb modules (no microcontroller) happens over unidirectional SPI over > 485, at adjustable speeds (send-and-pray). Communications with smart modules > (with micro) happens over bi-directional SPI over 485.
> Looks like most 485 transceivers can do at least 16Mbps with slew rate > limiting off, I see no reason to support at least 10Mbps. If I'm not > terrible at math, that supports about 2000 RGB LEDs at 16bits/color, which > is probably excessive. We could also support enabling the slew rate limiting > for low speed communications (~500kbps) over longer distances, or for > supporting DMX networks.
> Does that sound practical?
> On Fri, Sep 23, 2011 at 3:06 PM, Nick Vermeer <nicholas.verm...@gmail.com>wrote:
>> I posted some technical questions on the wiki page. Not sure if we should >> have a multi-level protocol with a basic shift register based system for the >> output boards and optional controllers that manage busses of these sift >> register systems.
>> On Fri, Sep 23, 2011 at 2:01 PM, Max Henstell <m...@kapamaki.net> wrote:
>>> As several people pointed out last night, USB Serial is too slow for even >>> DMX communication. It was suggested that we look at HID or just raw packets. >>> I haven't been able to turn up much information on any speed limitations of >>> HID, but the Atmega 32u4 (for example) supports both 1.5 and 12Mbps in some >>> manner. I guess the mode implementation is up to the user.
>>> A USB Serial option would be nice, but we definitely need a faster >>> communications method, either implementing our own USB or using Ethernet, or >>> both.
>>> As for protocols, RDM doesn't look terribly difficult to implement, and >>> gives us DMX compatibility. Also, ACN, if we wanna get crazy with it.
Also, RS-485 is usually used in async serial, rather than synchronous. For our application, we will need at least a Clock, Latch and Data pair for the unidirectional circuit, and RX,TX, Clock for the bidirectional link. That increases the number of drivers a bit.
On Sun, Sep 25, 2011 at 3:52 PM, Nick Vermeer <nicholas.verm...@gmail.com>wrote:
> Which driver chips were you looking to use again? What's their max speed? > requiring multi-port 10Mbit SPI probably puts us into ARM territory, as I > don't think you can get that much data in and out of an atmega@16Mhz.
> Checking the math, 10 Mbit SPI seems to be able to do 104 updates/sec at > 6000 channels (or 2k RGB) and 16 bit per channel. Thats way more than what > we would want running on one controller anyway, so that should be good.
> On Sun, Sep 25, 2011 at 3:28 PM, Max Henstell <m...@kapamaki.net> wrote:
>> Here's what I'm thinking on the hardware level, let me know if this makes >> sense.
>> Single master (the "logic unit") with an RS485 transceiver. Communication >> with dumb modules (no microcontroller) happens over unidirectional SPI over >> 485, at adjustable speeds (send-and-pray). Communications with smart modules >> (with micro) happens over bi-directional SPI over 485.
>> Looks like most 485 transceivers can do at least 16Mbps with slew rate >> limiting off, I see no reason to support at least 10Mbps. If I'm not >> terrible at math, that supports about 2000 RGB LEDs at 16bits/color, which >> is probably excessive. We could also support enabling the slew rate limiting >> for low speed communications (~500kbps) over longer distances, or for >> supporting DMX networks.
>> Does that sound practical?
>> On Fri, Sep 23, 2011 at 3:06 PM, Nick Vermeer <nicholas.verm...@gmail.com >> > wrote:
>>> I posted some technical questions on the wiki page. Not sure if we >>> should have a multi-level protocol with a basic shift register based system >>> for the output boards and optional controllers that manage busses of these >>> sift register systems.
>>> On Fri, Sep 23, 2011 at 2:01 PM, Max Henstell <m...@kapamaki.net> wrote:
>>>> As several people pointed out last night, USB Serial is too slow for >>>> even DMX communication. It was suggested that we look at HID or just raw >>>> packets. I haven't been able to turn up much information on any speed >>>> limitations of HID, but the Atmega 32u4 (for example) supports both 1.5 and >>>> 12Mbps in some manner. I guess the mode implementation is up to the user.
>>>> A USB Serial option would be nice, but we definitely need a faster >>>> communications method, either implementing our own USB or using Ethernet, or >>>> both.
>>>> As for protocols, RDM doesn't look terribly difficult to implement, and >>>> gives us DMX compatibility. Also, ACN, if we wanna get crazy with it.
Oh right, you need a clock for SPI. How about straight SPI for very short range communications? It looks like the 328 can do SPI at Fosc/2, or about 10MHz if nothing else is going on, so 4 or 5MHz should be more than doable, right?
We could also add a 485 transceiver for DMX applications.
Driver chips - for the LED drivers you mean? The ones I'm using personally are the TLC5971 - Max speed 20MHz.
Do you think 24bit color (8bit/channel) is adequate? 16 bits per channel seems a little out there, I only mentioned it because the TLC5971 is 16-bit/channel, so we should probably support it, even if we pad half the bits.
For higher speeds / larger installations - maybe we should consider an ARM-based master unit? If so, is this something we should develop in parallel? After the Atmega version? Instead of the Atmega version?
On Sun, Sep 25, 2011 at 4:08 PM, Nick Vermeer <nicholas.verm...@gmail.com>wrote:
> Also, RS-485 is usually used in async serial, rather than synchronous. For > our application, we will need at least a Clock, Latch and Data pair for the > unidirectional circuit, and RX,TX, Clock for the bidirectional link. That > increases the number of drivers a bit.
> On Sun, Sep 25, 2011 at 3:52 PM, Nick Vermeer <nicholas.verm...@gmail.com>wrote:
>> Which driver chips were you looking to use again? What's their max speed? >> requiring multi-port 10Mbit SPI probably puts us into ARM territory, as I >> don't think you can get that much data in and out of an atmega@16Mhz.
>> Checking the math, 10 Mbit SPI seems to be able to do 104 updates/sec at >> 6000 channels (or 2k RGB) and 16 bit per channel. Thats way more than what >> we would want running on one controller anyway, so that should be good.
>> On Sun, Sep 25, 2011 at 3:28 PM, Max Henstell <m...@kapamaki.net> wrote:
>>> Here's what I'm thinking on the hardware level, let me know if this makes >>> sense.
>>> Single master (the "logic unit") with an RS485 transceiver. Communication >>> with dumb modules (no microcontroller) happens over unidirectional SPI over >>> 485, at adjustable speeds (send-and-pray). Communications with smart modules >>> (with micro) happens over bi-directional SPI over 485.
>>> Looks like most 485 transceivers can do at least 16Mbps with slew rate >>> limiting off, I see no reason to support at least 10Mbps. If I'm not >>> terrible at math, that supports about 2000 RGB LEDs at 16bits/color, which >>> is probably excessive. We could also support enabling the slew rate limiting >>> for low speed communications (~500kbps) over longer distances, or for >>> supporting DMX networks.
>>> Does that sound practical?
>>> On Fri, Sep 23, 2011 at 3:06 PM, Nick Vermeer < >>> nicholas.verm...@gmail.com> wrote:
>>>> I posted some technical questions on the wiki page. Not sure if we >>>> should have a multi-level protocol with a basic shift register based system >>>> for the output boards and optional controllers that manage busses of these >>>> sift register systems.
>>>> On Fri, Sep 23, 2011 at 2:01 PM, Max Henstell <m...@kapamaki.net> wrote:
>>>>> As several people pointed out last night, USB Serial is too slow for >>>>> even DMX communication. It was suggested that we look at HID or just raw >>>>> packets. I haven't been able to turn up much information on any speed >>>>> limitations of HID, but the Atmega 32u4 (for example) supports both 1.5 and >>>>> 12Mbps in some manner. I guess the mode implementation is up to the user.
>>>>> A USB Serial option would be nice, but we definitely need a faster >>>>> communications method, either implementing our own USB or using Ethernet, or >>>>> both.
>>>>> As for protocols, RDM doesn't look terribly difficult to implement, and >>>>> gives us DMX compatibility. Also, ACN, if we wanna get crazy with it.
