Re: [open-lighting] Raspberry-Pi; OLA; addressable LED strips

[Simon Newton]

On Tue, Oct 23, 2012 at 5:42 AM, Scott Gibson <scott...@gmail.com> wrote:
> Hey all; so I'm looking for some advice on getting my Addressable LED
> driver utility to work with OLA.
>
> Some background:
> - Current code here: https://github.com/scottjgibson/PixelPi
> - Supports WS2801; LDP8806; LDP6803 connected via SPI to the raspberry pi
> - Currently supports lots of stand alone operations (on/off; rgb; fade;
> wiimote control (kind of); chase; image display (as a pixel matrix or
> persistence of vision) etc
> - Supports network control using UDP from pixelinvaders
> - Also starting a rewrite based on re-architecture from another github user
> here:https://github.com/PixelPi/PixelPi
>
> What I want to do:
> - I want to allow the addressable strip to be controlled via artnet (or
> other standard DMX over IP type protocol)
> - Configurable such that each pixel can be controlled or have the whole
> strip (or subset) controlled as one RGB light
>
>
> So it seems OLA is a good match as I see there are python libraries.
>
> What I'm looking for is some help getting started. I'm new to OLA and DMX
> control but I've been learning (slowly). Is there example code for a artnet
> client using ola which I could stitch in to my existing project? Does it
> make sense to use the python libraries or should I write something in C/C++?
> I've used this project as a means to learn python, but I'm a C/C++ developer
> by profession so I'm happy with either.

Hi Scott,

You've come to the right place. An OLA client is protocol-independent.
By writing a client you get support for ArtNet, Streaming ACN, and a
bunch more. There is some sample code in the examples directory of the
tarball, or you can view it online at
http://code.google.com/p/open-lighting/source/browse/#git%2Fexamples

The wiki also has some information (but it may be slightly out of date
since things change):

http://www.opendmx.net/index.php/OLA_Client_API#Example_IV:_Receiving_DMX_data
http://www.opendmx.net/index.php/OLA_Python_API

As for the language it's up to you. I'd like to eventually get SPI
support into the core daemon as a plugin but that would require us to
agree on a DMX/RDM over SPI protocol* and I think it's a bit early for
that. As we start seeing more SPI devices for the Pi we'll have a
better idea of what people are trying to do.

Let me know if you have any other questions.

* Much like there is a de-facto DMX over USB thanks to Enttec &
http://www.opendmx.net/index.php/USB_Protocol_Extensions

Simon

>
> Thanks,
>
> Scott
>
>
> --
>
>

[Andrew Frazer]

Hey Scott, really nice work on this..

On 24/10/2012, at 1:42 AM, Scott Gibson <scott...@gmail.com> wrote:

> Hey all; so I'm looking for some advice on getting my Addressable LED driver utility to work with OLA.
>
> Some background:
> - Current code here: https://github.com/scottjgibson/PixelPi
> - Supports WS2801; LDP8806; LDP6803 connected via SPI to the raspberry pi
> - Currently supports lots of stand alone operations (on/off; rgb; fade; wiimote control (kind of); chase; image display (as a pixel matrix or persistence of vision) etc
> - Supports network control using UDP from pixelinvaders
> - Also starting a rewrite based on re-architecture from another github user here:https://github.com/PixelPi/PixelPi
>
> What I want to do:
> - I want to allow the addressable strip to be controlled via artnet (or other standard DMX over IP type protocol)
> - Configurable such that each pixel can be controlled or have the whole strip (or subset) controlled as one RGB light
>
>
> So it seems OLA is a good match as I see there are python libraries.
>
> What I'm looking for is some help getting started. I'm new to OLA and DMX control but I've been learning (slowly). Is there example code for a artnet client using ola which I could stitch in to my existing project? Does it make sense to use the python libraries or should I write something in C/C++? I've used this project as a means to learn python, but I'm a C/C++ developer by profession so I'm happy with either.
>

> Thanks,
>
> Scott
>
>
>
> --
>
>

[Lorenzo Fattori]

that's nice... i'm also looking for something similar for direct control artnet > ws2801!

if you need a beta tester, i'm here ;)

[Mac Biostar]

I guess I'll throw in my two-cent opinion here.

I looked at the Pi for controlling pixels and it only seemed capable of controlling one string without any additional hardware. So what I thought might be more versatile is to make the "additional hardware" a USB interface that directly controls pixels. Since there is no point in hanging professional-grade hardware on a $35 computer, I wanted it to be as cheap as I could come up with. I came up with this:

http://www.ebay.com/itm/1PCS-USBasp-USBISP-3-3V-5V-AVR-Programmer-USB-ATMEGA8-New-/261021924011?pt=LH_DefaultDomain_0&hash=item3cc61e7aab

It is an AVR Atmega8 micro controller programmed with modded uDMX code. It will control a string of 50 pixels, 2801 or 6803. It will look to OLA as an Anyma output interface.

http://i1142.photobucket.com/albums/n618/machosehead/udmxpixels.jpg

On a similar project I am looking to blend code from the Arduino RGB Mixer with the FastSPI library and run it on an Arduino Nano clone. The hardware should cost under $15

http://code.google.com/p/fastspi/

-MH

--
 
 

[Peter Stuge]

Mac Biostar wrote:
> So what I thought might be more versatile is to make the
> "additional hardware" a USB interface that directly controls
> pixels. Since there is no point in hanging professional-grade
> hardware on a $35 computer, I wanted it to be as cheap as I could
> come up with. I came up with this:

> http://www.ebay.com/itm/261021924011

> It is an AVR Atmega8 micro controller programmed with modded uDMX
> code.

> The hardware should cost under $15

Avoid V-USB. At the very least get a processor with actual hard USB
IP. You can find an ARM USB processor for less than $3.

You can also find a USB PIC for similarly little. Microchip announced
some parts just last week that do full speed USB with internal clock.
Various sizes, 14-pin, 20-pin, DIP, SOIC, TSSOP. Find one with USART
that can drive the SPI. Use Holger Oehm's single-file PicUsbFirmware
under Apache license, compileable with gpasm. You need the PIC, a USB
cable, a resistor or two, and the connection to SPI. The software is
ready. You need to write descriptors and handle e.g. interrupt
transfers. It is super easy, and super low cost. It will take a few
hours to finish the project.


//Peter

[Mac Biostar]

Thank you for your two cents.

-MH

> --
>
>

[Peter Stuge]

Mac Biostar wrote:
> Thank you for your two cents.

You're welcome. A reason to prefer an ARM processor such as NXP
LPC11U24 might be that it has a bootloader in mask ROM, so it does
not need a programmer. No such luck with the PIC, while on the other
hand a PIC-based design, e.g. on PIC16F1645, will be simpler to build
thanks to DIP/SO package options and almost no supporting components.


//Peter

[Mac Biostar]

You know, the real problem with V-Bus is it grabs a good amount of processing power and you have to constantly poll it. There is always a consequence for cheap.

Are there any good development boards/software on the processors you have suggested?

-MH

> --
>
>

[Andrew Frazer]

if it was me, i'd take two low cost 3 to 8 pin demux IC, connect the 3 pins to some GPIO on on the PI, and "steer" the SPI around between multiple strings. About $3 of parts…

> --
>
>

[Mac Biostar]

Yes, I have seen this done (not on the Pi). The pixels will latch to the last value sent so can "share" a SPI interface between strings. I'm still waiting for someone to show me a cheaper solution. Remember, free shipping.

-MH

> --
>
>

[Andrew Frazer]

Cheaper than a 74xx138? and a header plug? you'll be scratching.. I've manufactured 1000's of pixel controllers, and this is what we do. the SPI is derived from a PIC24 however, and not a RPI.

but the theory is the same..

You'll easily be able to get around 8 strings of say 85 ( thats 4 universes ), and achieve a refresh rate of more than 50fps. The 2801 IC is particularly good for this application, because you can use a real api interface. some of the other pixels out there have all sorts of weird and wonderful interfaces that give you a bunch of trouble.

Additonally, while you can drive the pixels directly from the 74138, i'd recommend you might use some kind of buffering, and make sue you put some low value resistors inline on the clk and data.. The ws2801 has a nasty fault mode, where current will flow *back* on clk and data, and make sure that your GND is *always* connected.. Other problem with the 2801, is that there are a *lot* of clones flying around, and most of the clones are built in the back of bicycle factories not IC clean rooms, and many people are reporting failures.. If you're pixels are costing sub 0.50 on ebay, you can be pretty sure the quality of the parts is dubious. However they are so cheap, that you can of douse just buy lots of spares. If your application is not critical, this is not always a bad way of doing things.

Regards

Andrew.

> --
>
>

[Jannis Achstetter]

Am 23.10.2012 23:15, schrieb Mac Biostar:
> I came up with this:
> http://www.ebay.com/itm/1PCS-USBasp-USBISP-3-3V-5V-AVR-Programmer-USB-ATMEGA8-New-/261021924011?pt=LH_DefaultDomain_0&hash=item3cc61e7aab
> It is an AVR Atmega8 micro controller programmed with modded uDMX code.
> It will control a string of 50 pixels, 2801 or 6803. It will look to OLA
> as an Anyma output interface.
> http://i1142.photobucket.com/albums/n618/machosehead/udmxpixels.jpg

That idea is so awesome! Using a really cheap device actually built as
programmer to drive the LED-strips by modifying the firmware to look
like a DMX-sender! Thanks for sharing :D

[Hippy]

+1 that is pretty awesome... I mean $3.50 with free shipping! you get what you pay for and all that, so a redundant stream can be made available for another $3.50 :)  this really should be sent into hackaday if it already hasn't.  Very nice! 

--

[Scott Gibson]

Ok great links; I have some reading / research to do.  I'm going to keep going with this simple python apprach for now; but realisically the Pi is super overkill for this sort of thing.

So my other option is to go with something more suited for this single purpose application.  I have done a ton of development on ARM cortex M3 (including a number of custom hardware designs for clients); I'm specifically using the Stellaris LM3S6965 right now which has a nice built in Ethernet mac and phy (so you just need a magjack).  Also has nice SPI hardware unit.  It would be a good match.  Only two SPI busses; but it would be low cost.  Should be able to get the full populated and assembled under $20 per unit in prototype quantities.  I can reuse most of the layout from some of my other designs. 

From the software side; I typically rely on freeRTOS and the lwip tcp stack; its my baseline for this sort of project.  Makes it easy to get off the ground.  I havn't had the opportunity to play with the SPI peripherals too much on this hardware but it looks simple enough (and it supports DMA so it should be good and fast).

Unfortunately I wouldn't get to reuse OLA directly for this sort of project; but a simple UDP receiver should be simple enough.  Can have a simple web configuration page.  I'll start a github page for this designs HW/SW this week.

Scott

[Scott Gibson]

Something I'm not clear on in your reply;

"I'd like to eventually get SPI
support into the core daemon as a plugin but that would require us to
agree on a DMX/RDM over SPI protocol* and I think it's a bit early for
that. As we start seeing more SPI devices for the Pi we'll have a
better idea of what people are trying to do.
"

I guess I was thinking of having a different application; I wasn't thinking to have DMX/RDM over SPI; I was thinking to instansiate a DMX/RDM node in software which translates the RGB data to the hardware specific requirements of the various LED pixels (similar to what my python scripts do for pixelinvaders data over UDP).  So instead of repacking the dmx data and sending it out over USB; it would be configured to extract the rgb data in order to send it out over SPI (based on the selected pixel type).

[Scott Gibson]

So could something generic be done; like have OLA output the DMX data to a standard posix pipe object; then my script (or any others) can grab dmx data from there and display it? 

[Simon Newton]

On Wed, Oct 24, 2012 at 7:36 AM, Scott Gibson <scott...@gmail.com> wrote:
> So could something generic be done; like have OLA output the DMX data to a
> standard posix pipe object; then my script (or any others) can grab dmx data
> from there and display it?

That's essentially what the OLA client library does.

> --
>
>

[Simon Newton]

On Wed, Oct 24, 2012 at 7:29 AM, Scott Gibson <scott...@gmail.com> wrote:
> Something I'm not clear on in your reply;
>
>
> "I'd like to eventually get SPI
> support into the core daemon as a plugin but that would require us to
> agree on a DMX/RDM over SPI protocol* and I think it's a bit early for
> that. As we start seeing more SPI devices for the Pi we'll have a
> better idea of what people are trying to do.
> "
>
> I guess I was thinking of having a different application; I wasn't thinking
> to have DMX/RDM over SPI; I was thinking to instansiate a DMX/RDM node in
> software which translates the RGB data to the hardware specific requirements
> of the various LED pixels (similar to what my python scripts do for
> pixelinvaders data over UDP). So instead of repacking the dmx data and
> sending it out over USB; it would be configured to extract the rgb data in
> order to send it out over SPI (based on the selected pixel type).

That's fine as well. We just need to agree on how a universe of DMX
maps to SPI data.

Simon

> --
>
>

[Scott Gibson]

I see; this is where I get a little fuzzy because I don't have a
background in DMX. I was thinking to have it configurable such that
each pixel could be controlled individually or the whole string (or
groups) could be controlled as one.

> --
>
>

[Simon Newton]

On Wed, Oct 24, 2012 at 7:43 AM, Scott Gibson <scott...@gmail.com> wrote:
> I see; this is where I get a little fuzzy because I don't have a
> background in DMX. I was thinking to have it configurable such that
> each pixel could be controlled individually or the whole string (or
> groups) could be controlled as one.

That can be done with a personality in RDM. Personality 1 would
consume 1 slot (or 3 if you wanted RGB). Personality 2 would consume 1
x N slots or 3 x N if it's RGB.

Simon

> --
>
>

[Simon Newton]

On Wed, Oct 24, 2012 at 5:49 AM, Scott Gibson <scott...@gmail.com> wrote:
> Ok great links; I have some reading / research to do. I'm going to keep
> going with this simple python apprach for now; but realisically the Pi is
> super overkill for this sort of thing.
>
> So my other option is to go with something more suited for this single
> purpose application. I have done a ton of development on ARM cortex M3
> (including a number of custom hardware designs for clients); I'm
> specifically using the Stellaris LM3S6965 right now which has a nice built
> in Ethernet mac and phy (so you just need a magjack). Also has nice SPI
> hardware unit. It would be a good match. Only two SPI busses; but it would
> be low cost. Should be able to get the full populated and assembled under
> $20 per unit in prototype quantities. I can reuse most of the layout from
> some of my other designs.

I would caution you on this. While it seems easy and quick to do, you
do gain a lot by building on top of OLA. Both the ArtNet and E1.31
(Streaming ACN) stacks have been very well tested and it means you get
things like E1.33 (RDMNet) for free later.

If it's a one off device that's going to run in your basement that's
fine, but if you intend for other people to use it please think twice
before writing yet another ArtNet / E1.31 implementation. There are
already plenty of bad ones out there.

Simon

> --
>
>

[Scott Gibson]

yeah realizing that as I read more. It would defeat my reason for
using the Raspberry Pi in the first place; to build on top of the work
of others (OLA).

> --
>
>

[Greenalien]

Just so nobody wastes their time 'reinventing the wheel' on this - when I made a similar enquiry on the forum a couple of months ago, I was directed to www.sandevices.com - in particular, their E680 board plus Eeprom is $19, the rest of the components to complete the board cost around $50 depending on the chosen connectors, and for that you get an Ethernet interface and 4 universes of pixel control, with a large range of pixel string chips covered. This board runs happily from professional MagicQ lighting desk software, which is free to download from http://www.chamsys.co.uk/download and has extensive pixel array handling capabilities and the all-important capability to output ACN (E1.31) DMX over Ethernet. The board is easy to build if you have moderate soldering skills, and all setup is done from a web interface. As it has been in production for a while now, the snags have been ironed out, so it's easy to put a working system together.
Cheers...John

[Scott Gibson]

Cool product! So I guess I would be looking to make something similar
with my Pi (since I have the hardware).

It seems things are quite close I just need to lean some more about
DMX so that I can pull the RGB data out and send it to the pixels.

> --
>
>

[Hippy]

Would something simple like this be usable....

rgb pixels 1 - 170 = universe 0 dmx 1-510
rgb pixels 170 - 340 = universe 1 dmx 1-510

....

........

--

[Scott Gibson]

I guess some of my motivation of doing this on the Pi is to add other
things like DC RGB led string control; as well as servo control. It
would be trivial when using the I2C PWM breakout and software (here:
http://adafruit.com/products/815
https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code/tree/master/Adafruit_PWM_Servo_Driver)

To start I would like to have the RGB pixel support; but I would also
like to configure the 12 PWM channels as servo's or use them as pulse
widths for RGB channels of standard 12V LED strings.

[Peter Stuge]

Mac Biostar wrote:
> You know, the real problem with V-Bus is it grabs a good amount of
> processing power and you have to constantly poll it. There is
> always a consequence for cheap.

Indeed. It is also not quite standards compliant on the USB, and it
is unable to do any error correction, which is a rather nice feature
that USB gives one for free, using actual USB hardware.

> Are there any good development boards/software on the processors
> you have suggested?

Unfortunately no, no boards for those exact processors, but there are
some good boards for processors in the same family or ones that are
similar enough.

The NXP LPC11U24 is a Cortex-M0 with USB. There's a neat board for
the LPC1343, which is a Cortex-M3 with USB:

https://www.olimex.com/Products/ARM/NXP/LPC-P1343/

I use this board for education, as does Alessandro Rubini (maybe you
recognize the name from the Linux kernel device drivers book) and
both our materials are online. http://cbs.stuge.se/ is mine, and in
the links.html file there are links over to Alessandros really great
examples.

The difference between Cortex-M0 and M3 is there, but is not very
relevant for this application. There are other processors in the
LPC11U family (Cortex-M0 with USB) that have boards, for example:

https://www.olimex.com/Products/ARM/NXP/LPC-H11U14/

However the LPC11U14 lacks the very convenient USB bootloader found
in both LPC11U24 and LPC1343, so an external programmer would still
be neccessary, or at the very least using the UART bootloader, which
isn't as fun. There's also no USB connector. More work; not worth the
few EUR saved on the development board, and the two chips 1343 vs.
11U24 are similar enough that code will not need many changes.

So if you want to look at ARM, there is that LPC-P1343 development
board for a prototype 0, next step would be making a PCB with the
LPC11U24, crystal, caps, voltage regulator, caps, USB connector,
reset button and bootloader button. If you prefer you can go straight
for that step of course, software development will be the same.


As for the PIC, I was way too tired and got the part number wrong.
Sorry about that. The part available is PIC16F1459. $1.96 in single
qty, DIP20 and SO20 can be sampled or ordered from Microchip, or
ordered from DigiKey.

http://www.microchip.com/samples/Default.aspx?DeviceFamily=PIC16F1459
http://www.microchipdirect.com/ProductDetails.aspx?Category=PIC16F1459
http://www.digikey.com/product-detail/en/PIC16F1459-I%2FP/PIC16F1459-I%2FP-ND/3671489

The family is PIC16F1454, PIC16F1455, and big brother PIC161459.
The two smaller ones come in 14-pin packages. Big brother in 20.
PIC16F1455 will be available in a few weeks it seems, but is not
at the moment. (They were announced last week.)

http://www.microchipdirect.com/ProductDetails.aspx?Category=PIC16F1455

No neat development boards for these products, only an older kit for
previous low-pin-count devices.

http://www.microchipdirect.com/productsearch.aspx?Keywords=DV164139

For the PICs there is Holger Oehm's PicUsbFirmware in just a single
assembly file, really well written, which supports PIC18F13K50 and
PIC18F2550 at the moment and would need to be adapted to the
PIC16F145x series, but that would not take very long just by
comparing data sheets.

It would of course be possible to build also using e.g. that
PIC18F13K50, but then you need crystal and more supporting components
again, and could probably just as well go the ARM route with all the
benefits of development ecosystem and the USB bootloader in ROM.


//Peter

[Peter Stuge]

Scott Gibson wrote:
> I'm going to keep going with this simple python apprach for now;
> but realisically the Pi is super overkill for this sort of thing.

..

> So my other option is to go with something more suited for this single
> purpose application. I have done a ton of development on ARM cortex M3
> (including a number of custom hardware designs for clients); I'm
> specifically using the Stellaris LM3S6965 right now which has a nice
> built in Ethernet mac and phy (so you just need a magjack). Also
> has nice SPI hardware unit. It would be a good match.

It's probably also overkill :) but the macphy is very very nice.
Watch out with the flash errata for development though, I guess
Luminary messed up their process somehow.

Another gotcha, especially with UDP, is that there's only 2kbyte of
packet memory, so the DMA needs to be used to pull off the data from
packet RAM to main RAM quickly, but even then the controller will
miss some packets if they are arriving too quickly. Sad face.

> Only two SPI busses; but it would be low cost. Should be able to
> get the full populated and assembled under $20 per unit in
> prototype quantities. I can reuse most of the layout from some of
> my other designs.

I really like it. It does need a programmer, but on the other hand it
has the ethernet.

> From the software side; I typically rely on freeRTOS and the lwip tcp
> stack; its my baseline for this sort of project. Makes it easy to get
> off the ground.

Yes, I've used lwip on them without the OS, that works too. It is
after all just a single task.

> I havn't had the opportunity to play with the SPI peripherals too
> much on this hardware but it looks simple enough (and it supports
> DMA so it should be good and fast).

It will easily output multi-megahertz SCK, the question is if the LED
strip can keep up with that (no) and if incoming data can be
reformatted quickly enough (probably also no). Slowly there will also
be signal integrity issues, if trying to go that fast over a long
distance.

> Unfortunately I wouldn't get to reuse OLA directly for this sort of
> project; but a simple UDP receiver should be simple enough.

Ack. See also other thread.

> Can have a simple web configuration page. I'll start a github page
> for this designs HW/SW this week.

Please keep us posted.


//Peter

[Peter Stuge]

Simon Newton wrote:
> I would caution you on this. While it seems easy and quick to do,

It *is* easy and quick to do.

> you do gain a lot by building on top of OLA.

This is also true, but in comparison to something running
independently on a cortex-m3, OLA is bloatware.

> Both the ArtNet and E1.31 (Streaming ACN) stacks have been very
> well tested and it means you get things like E1.33 (RDMNet) for
> free later.

Of course. The really clever thing would be to reuse as much OLA code
as possible, within the embedded project.

> if you intend for other people to use it please think twice before
> writing yet another ArtNet / E1.31 implementation. There are
> already plenty of bad ones out there.

Who says another implementation must be a bad one?

I guess the problem may be that the domain is so simple compared to
many other things involving network programming.

But of course there are bad programmers in every domain! That's no
reason not to make something new good if it makes sense.

I really like the idea to re-use OLA code in an embedded solution. It
would take more work than writing a receiver from scratch, but brings
a nice synergy effect. Depending on the target it may turn out to be
infeasible, but it's certainly worth a closer look.


//Peter

[Simon Newton]

On Wed, Oct 24, 2012 at 9:10 AM, Peter Stuge <pe...@stuge.se> wrote:
> Simon Newton wrote:
>> I would caution you on this. While it seems easy and quick to do,
>
> It *is* easy and quick to do.
>
>
>> you do gain a lot by building on top of OLA.
>
> This is also true, but in comparison to something running
> independently on a cortex-m3, OLA is bloatware.
>
>
>> Both the ArtNet and E1.31 (Streaming ACN) stacks have been very
>> well tested and it means you get things like E1.33 (RDMNet) for
>> free later.
>
> Of course. The really clever thing would be to reuse as much OLA code
> as possible, within the embedded project.
>
>
>> if you intend for other people to use it please think twice before
>> writing yet another ArtNet / E1.31 implementation. There are
>> already plenty of bad ones out there.
>
> Who says another implementation must be a bad one?

Nothing, but the reality is that both the E1.31 and ArtNet specs
aren't clear in some areas. Unless you're willing to devote time
sourcing and testing other equipment, chances are it's not going to
work in some cases.

>
> I guess the problem may be that the domain is so simple compared to
> many other things involving network programming.
>
> But of course there are bad programmers in every domain! That's no
> reason not to make something new good if it makes sense.
>
> I really like the idea to re-use OLA code in an embedded solution. It
> would take more work than writing a receiver from scratch, but brings
> a nice synergy effect. Depending on the target it may turn out to be
> infeasible, but it's certainly worth a closer look.
>
>
> //Peter
>

> --
>
>

[Andrew Frazer]

>
> Nothing, but the reality is that both the E1.31 and ArtNet specs
> aren't clear in some areas. Unless you're willing to devote time
> sourcing and testing other equipment, chances are it's not going to
> work in some cases.

Not a truer word spoken.. For example, take the E680 device that has been talked about today.. It accepts a *some* E1.31 but it doesn't send IGMP messages, so doe'snt join multicast groups properly, it relies on every frame being flooded.. And it doesn't accept unicast.. So get it on a busy network, and your in trouble.

Havig built receiver applications in C, for a PIC24 platform, i'll tell you that its neither trivial or easy!

[Peter Stuge]

Andrew Frazer wrote:
> > specs aren't clear in some areas

Right, that's one obvious benefit of reusing existing work.

> Havig built receiver applications in C, for a PIC24 platform, i'll
> tell you that its neither trivial or easy!

Neither PIC24 nor Cortex-M3 is of course suitable for 100 Mbps full
duplex, but the Cortex-M3 at least comes closer. I'm not sure how far
ahead the ARM11 lands, it is really ancient, but has faster clocks.


//Peter

[Andrew Frazer]

Huge Benefits of reuse. I didn't write a TCP/IP stack from the start either! or a web server.. In fact my original code probably is 3-5% of the code.

Thats why i'm using the PI, with OLA for the 341 project.. Anyway that decisions been made, and we'll see if its a good one or bad one later.. Point is i'm actually doing something rather than debating if its a good idea or not. Gotta work on the premise that something that works is better than a better idea. Because the better idea won't get a job done.

The DMX over SPI protocol is an interesting idea, and probably describes what i was fleshing out this week anyway, as i wait for some parts to arrive for the 3141 hardware, however i'm not sure if a 'generic' solution is good, or if a specific implementation needs to be put together for each kind of device that the PI might be attached to.. It may be a case of some generic bit and some specific bits.

It would be advantageous that we could use the SPI plus a couple of GPIO's so we can signal interrupts, back and forward.
=for example when the SPI end, has received a RDM response, it could create an interrupt on the PI, using some GPIO.. I'm in favour of an interrupt based solution rather than regular polling..






NB Theres not really any need to receive 100Mbs on my PIC24 based apps though.. Worse case, i'm receiving 8 universes, for a total of around 2.5 Mbs-1 It happy keeps up at 44fps, without issue.. On large scale showes were i have in excess of 1000 universes, the most data i've seen on the network at any time was 130Mbs. Just because we have 10Gb capable devices in the world doesn't mean we need to use them for everything!

> --
>
>

[Peter Stuge]

Andrew Frazer wrote:
> Huge Benefits of reuse.

Completely agreed. And why we do open source.

> Gotta work on the premise that something that works is better than
> a better idea.

Anything that works is not better than a better idea.

> the better idea won't get a job done.

True, but if a job is worth doing at all then may as well do it the
very best way.


I completely understand the desire to reuse, I have it as well! :) At
the same time it's important to make a break sometimes, "starting over"
at the cost of less reuse initially, but on a platform that pays off
pretty quickly as time goes on.

I've been forced to "start over" a couple of times and while not too
pleasant at first it always turned out to be a really great thing. :)


> DMX over SPI

Maybe pick a few fields out of artnet packets and make a fixed size
packet format.

Don't get too clever with SPI duplex. Some simple SPI hosts only do
half duplex.

> I'm in favour of an interrupt based solution rather than regular
> polling..

Yep, that's the only thing that makes sense.


//Peter

[Andrew Frazer]

I'd suggest we follow Sacn rather than Art-net if w are going to start copying the fields!

I can wait for the stadnards argument on DMX over SPI.. ( e1.7n? )

Adjancent to the DMX data needs to be some control data as well, which will be specific to your end device.. if you need to send it some variable configuration for example. My thinking is that it might be simpler just to have a plugin for the device, ( much like you have plugins for other devices now ), rather than try to shoe horn each device into a specific protocol, ( just because it uses SPI )..

I'm sure there might be some synergies to be had between things that connect on SPI ( much code reuse ) but locking them into a set specific protocol might be also bad.

> --
>
>

[Simon Newton]

On Wed, Oct 24, 2012 at 11:35 AM, Andrew Frazer
<andrew...@stellascapes.com> wrote:
> Huge Benefits of reuse. I didn't write a TCP/IP stack from the start either! or a web server.. In fact my original code probably is 3-5% of the code.
>
> Thats why i'm using the PI, with OLA for the 341 project.. Anyway that decisions been made, and we'll see if its a good one or bad one later.. Point is i'm actually doing something rather than debating if its a good idea or not. Gotta work on the premise that something that works is better than a better idea. Because the better idea won't get a job done.

Exactly. We're not writing firmware for hard drives here. Write the
code, release it, then iterate. More often than not the product /
project that arrives first to market dominates.

Simon

>
> The DMX over SPI protocol is an interesting idea, and probably describes what i was fleshing out this week anyway, as i wait for some parts to arrive for the 3141 hardware, however i'm not sure if a 'generic' solution is good, or if a specific implementation needs to be put together for each kind of device that the PI might be attached to.. It may be a case of some generic bit and some specific bits.
>
> It would be advantageous that we could use the SPI plus a couple of GPIO's so we can signal interrupts, back and forward.
> =for example when the SPI end, has received a RDM response, it could create an interrupt on the PI, using some GPIO.. I'm in favour of an interrupt based solution rather than regular polling..
>
>
>
>
>
>
> NB Theres not really any need to receive 100Mbs on my PIC24 based apps though.. Worse case, i'm receiving 8 universes, for a total of around 2.5 Mbs-1 It happy keeps up at 44fps, without issue.. On large scale showes were i have in excess of 1000 universes, the most data i've seen on the network at any time was 130Mbs. Just because we have 10Gb capable devices in the world doesn't mean we need to use them for everything!
>
>
>
>
> On 25/10/2012, at 7:08 AM, Peter Stuge <pe...@stuge.se> wrote:
>
>> Andrew Frazer wrote:
>>>> specs aren't clear in some areas
>>
>> Right, that's one obvious benefit of reusing existing work.
>>
>>
>>> Havig built receiver applications in C, for a PIC24 platform, i'll
>>> tell you that its neither trivial or easy!
>>
>> Neither PIC24 nor Cortex-M3 is of course suitable for 100 Mbps full
>> duplex, but the Cortex-M3 at least comes closer. I'm not sure how far
>> ahead the ARM11 lands, it is really ancient, but has faster clocks.
>>
>>
>> //Peter
>>
>> --
>>
>>
>

> --
>
>

[Andrew Frazer]

> . More often than not the product /
> project that arrives first to market dominates.
>

aka VHS video tapes, Artnet and Windows

[Hippy]

I would caution you on this. While it seems easy and quick to do, you
do gain a lot by building on top of OLA. Both the ArtNet and E1.31
(Streaming ACN) stacks have been very well tested and it means you get
things like E1.33 (RDMNet) for free later.

 

+1... i've been working through the test code Simon has developed to check the integrety of various OLA components,

and the testing is very, _very_ comprehensive!!

 

If it's a one off device that's going to run in your basement that's
fine, but if you intend for other people to use it please think twice
before writing yet another ArtNet / E1.31 implementation. There are
already plenty of bad ones out there.

Sorry, i'm guilty of this - for ArtNet anyway ;)  I'll never do it again, promise!

 

Simon

 

[Peter Stuge]

Simon Newton wrote:
> Write the code, release it, then iterate.

Iterating hardware takes much longer (production and distribution)
and costs more, so it's a bit different.

Of course it's still true that non-discerning users are happy with
the first thing to market.

Today I saw a kickstarter project that gets $132000 for a (one) RGB LED on
USB, retailing for over $30. Now that's a race to the intellectual bottom.


//Peter

[Jason Kyle]

Ha ha that's really funny and sad at the same time. They say there's a
sucker born every minute but I think it's a little more frequent.
Now let's scale it up to 100 LEDs on USB and maybe we can get a $13,200,000
kickstarter project for OLA.
jpk

Today I saw a kickstarter project that gets $132000 for a (one) RGB LED on
USB, retailing for over $30. Now that's a race to the intellectual bottom.


//Peter

--

[Scott Gibson]

Hey All; so an update on my project progress so far;

I have stitched together OLA with my output devices (WS2801 pixels in my case).  I kept a stand alone pixel driver (https://github.com/PixelPi/PixelPi/blob/master/controller.py)  which receives RGB data from from the ola receiver: https://github.com/PixelPi/PixelPi/blob/master/ola_output_interface.py

Currently the code just handles RGB LEDs but I'm in progress of adding support PWM generator hardware (PCA9685) which will be connected to SSRs to provide control for standard incandescent lights (some channels are being connected to FETs for analog RGB led strip control).

Main page here: https://github.com/PixelPi/PixelPi

So far for the LED pixels; you can configure the number of pixels in a group; each group is controlled by 3 (RGB) DMX channels.  The group size can be configured however you want.  I have also added chase and chase_fill groups which light up pixels in proportion to the value of a DMX channel.   Its working great.

I'm working on a demo video now; I'll add it here: http://thegreatgeekery.blogspot.ca/2012/10/pixelpi-update.html

Scott

[Simon Newton]

On Mon, Apr 22, 2013 at 1:55 PM, Nicola Regge <nicol...@gmail.com> wrote:
> Hi, i'm interestedd too. Only to contol Ws2801 Led with Raspberry.
> Someone can help me?

Ws2801 SPI devices have been supported since 0.8.27. There are
instructions at http://www.opendmx.net/index.php/OLA_Raspberry_Pi

Simon

>
>
> Il giorno martedì 23 ottobre 2012 14:42:06 UTC+2, Scott Gibson ha scritto:
>>
>> Hey all; so I'm looking for some advice on getting my Addressable LED
>> driver utility to work with OLA.
>>
>> Some background:
>> - Current code here: https://github.com/scottjgibson/PixelPi
>> - Supports WS2801; LDP8806; LDP6803 connected via SPI to the raspberry pi
>> - Currently supports lots of stand alone operations (on/off; rgb; fade;
>> wiimote control (kind of); chase; image display (as a pixel matrix or
>> persistence of vision) etc
>> - Supports network control using UDP from pixelinvaders
>> - Also starting a rewrite based on re-architecture from another github
>> user here:https://github.com/PixelPi/PixelPi
>>
>> What I want to do:
>> - I want to allow the addressable strip to be controlled via artnet (or
>> other standard DMX over IP type protocol)
>> - Configurable such that each pixel can be controlled or have the whole
>> strip (or subset) controlled as one RGB light
>>
>>
>> So it seems OLA is a good match as I see there are python libraries.
>>
>> What I'm looking for is some help getting started. I'm new to OLA and DMX
>> control but I've been learning (slowly). Is there example code for a artnet
>> client using ola which I could stitch in to my existing project? Does it
>> make sense to use the python libraries or should I write something in C/C++?
>> I've used this project as a means to learn python, but I'm a C/C++ developer
>> by profession so I'm happy with either.
>>

>> Thanks,
>>
>> Scott
>>
>>
> --
> The Open Lighting Group: open-l...@googlegroups.com, #openlighting
> (irc.freenode.org)
> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en
>
>