LRE 4x1 breakable RGB LED-Ring/Rotary-Encoder PCB bulk order

[weasel]

Hey there,

As announced in the other thread I had the need for a 4x1 LED-ring/rotary encoder board. The incredibly talented @FantomXR helped me realize the design and together we came up with some pretty cool improvements on @Fairlightiii's (RIP) classic:

 

- two layer sandwich PCB to get the SMD LEDs on surface level

- encoder-slots compatible with both 11mm and 16mm encoders, with or without switch

- two 74HC165 per encoder-board for direct connection to the core board, convenient midibox 10-pin IDC connectors

- breakable design allowing to easily get 3x1, 2x1, 1x1 board configurations, partially leaving both broken parts usable/connectable/chainable.

- Full ring of 36 WS2812c RGB LEDs in 2020 size, diameter of 27mm. The full ring allows for vertical or horizontal application as opposed to the classic 80% perimeter LED ring. 36 LEDs make up for the lost resolution.

- additional power supply inlets for the hungry LED rings

- distance between encoders is 33mm in the prototype, might change to 35mm for production, allowing for bigger knobs. Not a fan of the current micro-encoders.

- option for whoever needs it to design a compatible OLED-overlay-board to use instead of the LED-Ring board and thereby achieve something similar to @Antichambre's great OLRE board.

 

The design is not fully tested yet and we might make some adjustments but I wanted to put this bulk order up already so everybody gets a chance to see it before we order. Which will be as soon as the prototype has proven itself, hopefully in about 2-3 weeks. There is a number of questions to be addressed when the prototype arrived, ie maximum number of WS2812 on a single core board, overall power consumption etc. Obvisouly i am very happy about any ideas or constructive criticism regarding the design.

 

Here is a price overview that we calculated from an offer we got on a slightly older design, so it might vary depending on the total order amount and possible design changes, plus a tiny shipping&handling fee. I will personally order around 50 each so would make it to the middle price bracket probably.

 

Encoder board:

50pc --> 10€ / pc.

100pc --> 7€ / pc.

200pc --> 6€ / pc.

 

LED-Ring board

50pc => 28€ / pc.

100pc => 23€ / pc.

200pc. => 20€ / pc.

 

Yes these are pretty expensive compared to your usual diy pcb board, but we ruled out any self-assembly pretty early, given the amount of parts and also the sheer number of boards I personally need. So we will order these boards with all SMD parts fully assembled, if anybody is interested we could obviously also get some plain pcb boards made on the side.

So yeah please send me a DM or post in this thread if you are interested in ordering some of these.

Here are some nice renderings courtesy of the genius @FantomXR who might also chime in with schematics or if anybody has more specific technical questions.

 

Edited May 9, 2019 by weasel

[FantomXR]

Thanks for the thread!

A few comments:
- The PCBs are breakable in the configurations mentioned above. But please have in mind that only the LED-modules can be reused. If you break the encoder board for a 1x1 configuration, the other 3 pcbs can't be used anymore.
- We are not sure yet if we take WS2812c or WS2812b. They differ in power consumption thus brightness. We will compare both options and decide on this.
- The renderings do not represent the actual status. But they give an idea how it will look.

Prototypes ordered today. I'll assemble those by myself. The batch-production we will do externally. 

[engineer]

Hi, I did not get so far why an LED ring PCB is required to use the WS-LED. Wouldn't it be suitable to use a ready built ring instead?

 

[pastaclub]

I also wonder what led to the decision to use these very pricy LEDs, especially since so many are needed. Wouldn’t it have been much cheaper to design the PCB for regular plain SMD LEDs and add a simple microcontroller per encoder with enough pins to drive all LEDs?

(maybe I just didn’t understand yet why RGB LEDs are needed)

Edited April 30, 2019 by pastaclub

[weasel]

RGB LEDs allow to code a lot more information on a single ring - i can for example have several shift- or mapping applications on the same encoder with the changing color immediately and obvisouly indicating the function. you could also do classic VU style green-yellow-red structures indicating the "hotness" of a value, giving much easier and faster visual feedback over the current value. i think @latigid on did something similar with encoders with a transparent knob.

 

all the ready built WS-/or other RGB-LED rings have far to low resolution, you would get about 8 LEDs on the same diameter. as far as i know there are no hi-res (ie 24+) LED rings on a 2020 base, allowing for usable diameters.

edit.: just did some quick maths - 4 neopixel rings also actually aren't really cheaper than getting these perfect sized hi res PCBs fully assembled.

 

of course there are cheaper ways to get a LED ring but in this case i don't want to DIY to be cheaper, but rather better than commercially or previously available solutions.

Edited April 30, 2019 by weasel

[pastaclub]

That makes sense if you want RGB functionality. I personally would be happy enough with single color LEDs, especially in a design with many encoders, due to cost.

Resolution of course needs to be much higher than only 8 LEDs, so it seems a good candidate for DIY as well... and for PCBA since it’s quite boring to place so many components.

Speaking of resolution, there aren’t any affordable encoders with more than 24 positions per rotation, right?

[latigid on]

The LEDs are quite cheap in bulk, the real cost here is the PCBA. But it is required for such LEDs as there are no pads to solder (they're underneath the LED dies). Plus, reflow soldering of these parts is notoriously difficult and it is very important to control the humidity to avoid lots of dead pixels.

There are other projects around e.g. from @Antichambre and midiphy (myself) that are based on a similar concept.

[weasel]

Yeah as @latigid on said WS2812c is only a couple cents in the quantities we're buying. about 50% of the quoted prices goes into the assembly. @FantomXR thought about assembling himself with his reflow equipment but soon realized it will be way too many parts that need almost perfect precision.

Regarding encoders, the cheapest higher resolution ones i ever saw started at 30-40 euro. i'll personally most likely use regular 24 ppr ones with no detent which is perfectly fine for me.

i think based on the layout for these boards which we'll publish once finished, it should be easy for someone to remodel the upper LED layer to make a cheaper single colour version. or maybe there randomly are cheaper single colour chainable LEDs that fit the same footprint?

Edited April 30, 2019 by weasel

[FantomXR]

Using those RGB LEDs have a significant advantage: you don't need any driver ICs. So if you would take normal SMD LEDs you also would need tons of shift registers, resistors, etc. So they would eat up a lot of space on the PCB. 

WS2812 have integrated driver ICs and can be chained without the need of any other parts. I don't think that there are other LEDs with the same footprint. 2020 is just the housing. For example you can get the APA102 also in a 2020 housing but with a totally different footprint. So it doesn't seem standardized like 0805 or SO16. 

PCBs were shipped today. :-)

Edited April 30, 2019 by FantomXR

[pastaclub]

You still need driver ICs, but they are already integrated into the LEDs. So the PCB gets simpler but you have one controller per LED, so with 36 LEDs you‘re paying for 36 controllers.

“Tons of shift registers“ is exaggerated. Microcontrollers like the ATtiny88 already have 28 GPIOs, so up to 26 or so you wouldn‘t need any shift registers. If you opt for a small controller plus shift registers, it still would only be 1/8 or 1/16 of the number of LEDs, which isn’t tons. You‘re right about the resistors, but with industrial PCBA that shouldn’t be an issue.

Your pre-connected break-away approach is awesome and makes it very versatile.

And it‘s great to see a finished project. That thread on the german forum has been there for years, received many replies but nobody has shown working hardware before.

[Antichambre]

Inconvenient with this approach is the transfer time, there's no random write access, the whole chain has to be refreshed on each change.
There's not too much data to send but the NRZ protocol is very slow, for a 64 chained led it needs 4ms for the whole refresh this is already a lot of process for just 64 led, less than 2 rings in your case(36led/ring),
notes about that ,36 is not a good number to deal with memory, using 2ⁿ is always better for coding...

But this deserves to be tested and could be enough for a dedicated application which has not extra/other heavy processes.

best regards
Bruno

 

[FantomXR]

I already used 170 LEDs in a chain without any problems... refresh rate never was a problem... but yeah: Let's leave away the theoretical talk :-D We will check with the PCBs and if we are not successful, we will overthink the layout / idea. 

[weasel]

As another estimate, from what i gathered the update rate of the WS2812 limits one chain to about 500 LEDs, and at that keeps a refresh rate of 60fps for the whole chain which should be more than enough for musical controller values. So as already mentioned in our DMs, worst case we'll have to use 2-3 serial pins.

So while there might be limitations and downsides to our approach i am pretty confident it will still do just what i want it to do :)

[weasel]

prototypes arrived today!

(just posting to try and create a little pressure on @FantomXR for the proto-assembly )

[FantomXR]

Yes... they look pretty :-)

[Antichambre]

@FantomXR,

You can maybe use some small flip-flops on each encoder board to get a 3 bit shift register, no waste of bit on the SPI data, the enc board will be divisible with all breakable part usable.

BR
Bruno

Edited May 8, 2019 by Antichambre

[FantomXR]

Dear Bruno,

not sure, what do you mean. Could you explain please?

Best,
Chris

[FantomXR]

Help needed! :-(

I try to adapt the code to work with the WS2812-2020. I have to edit the ws2812.c because the 2020-version runs at 2kHz instead at 800kHz.
So I try to understand what happens here. This is the original code:

// timers clocked at CPU/2 clock, WS2812 protocol requires 800 kHz (1.25 uS period)
#define WS2812_TIM_PERIOD       ((MIOS32_SYS_CPU_FREQUENCY/2) / 800000)
#define WS2812_TIM_CC_RESET     0
#define WS2812_TIM_CC_IDLE      WS2812_TIM_PERIOD
#define WS2812_TIM_CC_LOW       (u16)((WS2812_TIM_PERIOD - 1) * 0.28) // 28% -> ca. 0.35 uS
#define WS2812_TIM_CC_HIGH      (u16)((WS2812_TIM_PERIOD - 1) * 0.74) // 74% -> ca. 0.90 uS

// DMA channel (DMA1 Stream 0, Channel 2 - fortunately DMA1_Stream0 not used by any other MIOS32 driver yet...!)
#define WS2812_DMA_PTR          DMA1_Stream0
#define WS2812_DMA_CHN          DMA_Channel_2


#define WS2812_BUFFER_SIZE ((WS2812_NUM_LEDS+10)*24) // +10*24 to insert the RESET frame of 10*24*1.25 = 300 uS

MIOS32_SYS_CPU_FREQUENCY should be 168000000, found in mios32_sys.h. But if I type this into a calculator:
(168000000 / 2) / 800000 = 105
So, why is 105 == 1.25uS? Doesn't make any sense to me....

Any help?

Here is the datasheet of the 2020:
https://www.tme.eu/Document/4a8239e52df5e0b5cc2eb96834c5d8b6/WS2812B-2020.pdf

And here of the 4040:
https://cdn-shop.adafruit.com/datasheets/WS2812B.pdf

 

Edited May 8, 2019 by FantomXR

[Antichambre]

a 74HC165 is a 8 inputs IC with some flip-flop you can recreate the same thing but for 3 inputs only.
Check how the 165 is made internally you will understand ;)

[weasel]

4 hours ago, FantomXR said:

// timers clocked at CPU/2 clock, WS2812 protocol requires 800 kHz (1.25 uS period)
#define WS2812_TIM_PERIOD       ((MIOS32_SYS_CPU_FREQUENCY/2) / 800000)
#define WS2812_TIM_CC_RESET     0
#define WS2812_TIM_CC_IDLE      WS2812_TIM_PERIOD
#define WS2812_TIM_CC_LOW       (u16)((WS2812_TIM_PERIOD - 1) * 0.28) // 28% -> ca. 0.35 uS
#define WS2812_TIM_CC_HIGH      (u16)((WS2812_TIM_PERIOD - 1) * 0.74) // 74% -> ca. 0.90 uS

// DMA channel (DMA1 Stream 0, Channel 2 - fortunately DMA1_Stream0 not used by any other MIOS32 driver yet...!)
#define WS2812_DMA_PTR          DMA1_Stream0
#define WS2812_DMA_CHN          DMA_Channel_2


#define WS2812_BUFFER_SIZE ((WS2812_NUM_LEDS+10)*24) // +10*24 to insert the RESET frame of 10*24*1.25 = 300 uS

IOS32_SYS_CPU_FREQUENCY should be 168000000, found in mios32_sys.h. But if I type this into a calculator:
(168000000 / 2) / 800000 = 105
So, why is 105 == 1.25uS? Doesn't make any sense to me....

 

i might be too high or otherwise intelectually challenged for this, but fwiw your maths seem right - it is 105 CPU cycles which at 168 MHz amount to 1.25uS.

so at a 2 MHz clock rate it should be

(168000000 / 2) / 2000000 = 42 CPU cycles = 0.5 uS

which also seems to roughly correlate to the timings given in the datasheet which says 580nS-1uS

 

edit: ignore the last 3 lines, i am confused about which clock rate we actually need to get to, all data sheets say 800 KHz. so if it's not 2 MHz, do your own maths everybody :) but hey i did notice that 105 is CPU cycles and that it indeed is 1.25uS. That gotta be worth something, right?

 

Edited May 8, 2019 by weasel

[Antichambre]

11 hours ago, FantomXR said:

not sure, what do you mean. Could you explain please?

It needs something like:

• 7 NAND gate - 2x 74HC00
• 3 D-type FF with Set and Reset - 2x 74HC74

Clock inhibit is not necessary.

Edited May 8, 2019 by Antichambre

[FantomXR]

On 8.5.2019 at 3:25 PM, weasel said:

it is 105 CPU cycles which at 168 MHz amount to 1.25uS.

This calculation is not clear to me. 
1 CPU cycle @ 168MHz is about 0,006uS
105 x 0,006 = 0,63uS

Or not?

[weasel]

Quote

This calculation is not clear to me. 

1 CPU cycle @ 168MHz is about 0,006uS
105 x 0,006 = 0,63uS

 

yeah so at first i just randomly tried multiplying the result by two and then it was right and i thought "well that's one of these programming things where you just hack a '+1' and then it works" and never find out why.

but then i found this line

// timers clocked at CPU/2 clock, WS2812 protocol requires 800 kHz (1.25 uS period)

CPU/2 clock

 

so it actually adds up. or rather divides up.

 

[Antichambre]

10 hours ago, weasel said:

 

yeah so at first i just randomly tried multiplying the result by two and then it was right and i thought "well that's one of these programming things where you just hack a '+1' and then it works" and never find out why.

but then i found this line

// timers clocked at CPU/2 clock, WS2812 protocol requires 800 kHz (1.25 uS period)

CPU/2 clock

 

so it actually adds up. or rather divides up.

 

There's some prescaler in the RCC registers(Reset and Clock Control) for all peripherals Clock Source. Those registers are also set in mios32_sys.
For the Timers clock this Prescaler is 2, means F_cpu divided by 2.
Then you have to take it in account in your calculation... TIMER_PERIOD = (MIOS32_SYS_CPU_FREQUENCY/2) / TIMER_FREQ

Datasheet is your friend for that ;)

Edited May 10, 2019 by Antichambre

[FantomXR]

So, I made some progress today.

I've tested it on another core (which I designed myself) and there the LEDs were running with the stock-firmware. No changes were needed. So I pick&placed 3 1/3 boards today.

What I still don't get why it doesn't work on a core with a discovery-board. Both ran the same firmware... 

But I ran into another problem. In my first test I set WS2812_NUM_LEDS to 140. I compiled the firmware and flashed it. It was running fine except that LED 139 and 140 were flickering. Not sure if this is a sign of RAM-overload or if it was power-related. well... I don't think it's power-related though because they were also flickering if only they were turned on and all other LEDs off.

Next I tried to set WS2812_NUM_LEDS to 300. I compiled and flashed the firmware. Result: The core doesn't boot anymore. Since my own core doesn't have a user-button I have to reflash the bootloader through SWD. I don't have time the next days to try it. But I wanted to give you an update on this.
And here is a short video of my p&p-machine... it wass running slow because it was a first test. 

https://www.dropbox.com/s/89zfhdda1sc2f45/VID_20190510_151248.mp4?dl=0

By the way: I left out the filter-caps because I normally don't work with 0603 parts and though don't have them in my workshop and don't have them in my machine. Should be okay for the prototypes. 

Edited May 10, 2019 by FantomXR