Ah - that would help a lot... And a bit thick of me not to realise, seeing as the Dout comes from the chip!
The USB block thingy would be a bit of a heisenbug if you didn;t already suspect it - imagine trying to trace that!
This is the driver/ethernet interface Matt used:
It's actually quite cost effective if you are driving a boat load and can run cables out from a single location for a group.
But I still like the Pi idea...
I looked at that - and it seems to use something called DMX over Ethernet aka E1.31 aka ArtNet(?).
I can find no meaningful examples of how to talk ArtNet(etc), except for a very complete protocol definition (it is royalty free) - so that meant dozens of pages of a very complex looking protocol. Without a clear simple example, it's hard to know how easy/hard in practise it would be.
All the videos seem to be:
1) How to wire up pixel strings;2) How to wire up E1.31 bridge.
3) Stick a Pi on it.???
5) Profit!If *I* were doing this, I think I would stick to my Pi idea - it would probably be easier to invent your own simple text protocol, rather than try to understand and drive E1.31! It looks very clever and very suitable for full on theatrics (and efficient in its use of multicast).
I suppose it depends on how well timed your sequences need to be - if you are running 10 strings in chaser mode, that must be 100% lockstep, E1.31 looks like it is well designed for this. It might be harder to get that sort of synchronisation over WIFI via a few Pi controllers.
I suppose once you get past the low hundreds of devices, it makes sense to split it into multiple blocks with a dedicated controller looking after them.
DMX and DALI I've heard of, but not E1.31
Yes if I had a Pi I'd use it instead of USB->sync, just do your own bit-banging, you could probably drive 8 strings of RGB LEDs per GPIO port.
See also "Mikes electric stuff" on youtube for impressive commercial stuff in the UK.
I wonder how practical that would be - bit banging at 400kHz (is that right - it's been a while?) - seems a pretty realtime operation for a full on OS like linux (unless you actually use RT features or write it as a kernel driver or something???
800kHz
Does a Pi have DMA based GPIO?
Can't remember the name (banana pi? Latte Panda?) but oneof the pi-alikes has an arduino "slave" onboard, which could do the bitwise I/O, while the linuxy section decided what colours to send.
Blimey! I would not feel confident of bitbanging that in ordinary userland.
Yes: GPIO 18 in DMA-PWM mode.
I did look at the Adafruit library for this and IIRC it does as you described earlier: Has one byte per bit, describing the mark/space of one PWM pulse. Load up 24xNumLEDs bytes into RAM and let it rip. Do at the end to cause the registers to be latched to the LED drive outputs.
I think the Pi only has one such pin so you only get to do one chain this way.
That would be elegant. It's the sort of job an 8pin Atmel AVR could probably manage too for £3 and some really simple programming, assuming the clock goes high enough (20MHz being the tinyAVR max) to handle bit banging with reliable timing - OR if it's onboard PWM is upto the job (I thought tinyAVR PWM was limited to a single mark/space until reprogrammed, rather than being able to ramp through RAM - but my experience of PWM on AVRs is minimal)
4k RAM would allow for RGB on over 1000 LEDs leaving working space as you'd not be using the more wasteful method of the Pi PWM.I wonder how easy it would be to link it to the over I2C... You only really need 3-4 commands: SetNumLEDs; SetLEDXwithRGB; BulkLoadBuffer; SendBufferToLEDs
It does sound a rather neat way of doing it :)
If that were viable, making a custom "HAT" with 1/2 dozen of these on board would be pretty cool.
They latch one-by-one not all at once, e.g starting from an idle state
the first LED (well all of them) is listening for the combined clock/data to start,
it receives the first 24 pulses without echoing them, and latches those as its colour,
after that it receives and echoes every pulse it hears to the next LED until it sees the pulses have stopped,
when it goes back to waiting for a new colour for itself.
so an unbroken sequence of pulses will "fill up" consecutive LEDs with colours, but a break in pulses starts back again with the first LED.
And some optimising commands maybe:
BulkLoadBuffer(OffSet) to allow for simple chasers (offset=0,1,2,0...) and switching between banks of preloaded sets if RAM vs NumLEDs permits.
With respect, are you *certain* of that? I was reading the spec sheet of the one in the Unicorn Hat and I seem to recall a clever almost synchronous signal that was used to latch the register to the outout driver.
But that could be a fabrication of my imagination - I'll have to go bac to the sheet...
You see, I *thought* that break was used to clock the stored value through to the driver?? OK, you need 3 registers for that.
I might well be very mistaken...
It's China, I've got my eye on a 5 m 240 pixel IP65 strip on Amazon for £23.00...
I just want something does a bit more than flash/fade simple sequences. I suspect it won't pass management approval what ever I do. I'd like it to do the simple "ordinary" things but also do something to make people notice and think "Hey! That's different".
There is one hardware PWM GPIO on a Pi but there is also libs that provide software PWM on any GPIO. My three channels uses the hardware PWM GPIO and two software ones. Each channel has it's own thread in my Python program so they operate completely independantly. Each thread also has a queue so you can adjust the fade up time, on time, fade down time, off time and the LED level for "on" and "off", all on the fly. Each thread then just loops round repeating that pattern.
5 V strips seem very common but you still need to level shift from the 3.3 V of the Pi GPIO.Might be able to run more than one string from a Pi, it would depend on the Pi being able to run at 800 kHz software PWM, TBH I don't think it will or only for only a couple of channels.
A full brightness strip showing white takes a fair bit of juice. Each pixel draws around 60 mA (18.5 mA/LED), 240 pixels is as near as damn it 15 A! Depending on the display patterns a car battery might not last very long. And car batteries don't like being deep discharged either.
Out there some where is some code for bit banging on an aurdino. The core is a bit of assembler that untilises the known number of clock cycles per instruction to get the timing right. IIRC that assembler is called as an interupt service routine. Getting the interupt rate right might be tricky on a Pi as the clock isn't fixed.
24V makes a lot of sense with long LED strings, but I don't think anyone has done a version of these addressable LEDs...
I dug out a 4A/5V PSU and now have the 144 LEDs strung up in the window, wish I'd ordered a few hundred more ... next year ... maybe poundland will have them by then.
Just playing about re-jigging my patterns, provided I don't eat too much CPU time on the PC with poorly coded functions, it pushes out about 300 "frames" per second. Loop unrolling type optimisations are a bit trickier when you're working in multiples of 9 bytes :-(
Just read the data sheet again - lack of a schematic doesn't help, but I think I'm wrong - there does not seem to be an extra latch.
I don't think there are any 24 V LEDs ... Higher driving voltage LED strings have series connected LEDs which makes controling each one individually a bit tricky.
I've investigated the "normal" set of lights we have in view of PWM driving them from a Pi. 2 channels, 240 LEDs, 32 V drive. LEDs arranged in 12 parallel connected blocks of 20 LEDs. Within a block there are two 10 LED series connected chains from each channels drive to a common rail.
The rating plate says total 8.5 W @ 32 V, so I = 8.5/32 = 265 mA =
130+ mA per string. I only have a stock of small signal transistors but do have some L293D H bridge drivers (up to 600 mA and 36 V). However the control box must have some suitable switching and be microprocessor controlled so just hacking into that is probably easier.
Personally I don't want any fast switching, I far prefer slow transitions and colour morphing, of which there seems to be limited availability.
Chris
A quick calculation on the addressable LEDs indicates that it takes 80us to load one up, so that's about a 30/sec refresh rate on a string of 300 which would give a nice fade.
Hmm. I looked at the separate driver chip for the addressable, the WS2811. It does seem to show 1 LED = 5V supply and 3 in series = 12V, so that would explain some of the addressable tapes that have 1 pixel=3LEDs as the addressable element (being 12V tapes).
I suppose one option would be to have a 4 wire system (24V, 5V, OV and Data) and have a DC-DC converter module every X-LEDs to maintain the 5V rail.
I'm thinking very long strings here...
Agreed simple switching is boring, rapid simple switching distracting/annoying. All the commercial sets of lights we have have fade/slow transition mode(s) and yes finding such sets is not straigt forward. A decent "twinkle" is something I'd like. My 3 channel play set up isn't bad at that but could do with one or two more channels. Each channel switches on to full brightness for between 20 and 40 ms, then fades to zero over 150 to 300 ms followed by an off time of 500 to 1500 ms. Each of those settings is randomly selected every 15 seconds per channel and each channel sequentially changed every five seconds.
Still want to play with a Raspberry Pi's and indivdually controlled RGB LEDs. you can set the brightness and colour of each LED at fairly high rate. But that is just strip of LEDS, bit boring. The 18 m 240 LED set is folded back on itself twice to triple the LEDs/inch and give the whole a bit more bulk.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.