FantomXR

Hey people, we could need some help on this project. So far the pick and place machine did a great job and the reflow oven as well. So I now have a few boards to test. But I already run into a problem. In the firmware I set WS2812_NUM_LEDS to 144, because one prototype board is made from 4x36 LEDs => 144. Compiled and flashed. The core boots up nicely. As stated in my previous post, the last 5 or 6 LEDs are slightly flickering. I've tested inserting 5V at the end of the LEDs again but this doesn't change anything. So it doesn't seem to be a power-related problem. Things start to get crazy if I connect another LED-ring-board in series with the first. I set WS2812_NUM_LEDS to 180 (with 190 the core doesn't boot anymore), compiled and flashed. I think a video can describe better what happens here: https://www.dropbox.com/s/b5phnsji4k9wjhs/YI051501.mp4?dl=0 Does anyone know where this could come from?! Also does someone has an idea why the cores do not boot anymore as soon as I set WS2812_NUM_LEDS to 190 and more? Any help would be very appreciated. Thanks, Chris

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.

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

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

Dear Bruno, not sure, what do you mean. Could you explain please? Best, Chris

Yes... they look pretty :-)

Here a picture... see the standard 0.96" in the background how small it is...

Hey people, I just want to inform you, that I've got a SSD1309 display here and it works perfectly well with NG without any changes on the firmware! :-) The screen next to me is 1.54". There is also a 2.42" version, which I also ordered but it has not arrived yet. This one has also SSD1309 :-D Awesome displays! Best, Chris

By the way: all prices are "or best offer". Id like to get rid of those parts. So if you are interested just drop me a PM.

Hey people, I cleaned up my room a bit and found some PCBs I do not need anymore. Here we go: This is something I developed years ago! It has a PCB with 8 encoders with LED rings. Although they look blue, they are not. The LEDs (0603) are white! As you can see the PCB an be connected to a standard DOUT-module even without any resistors. The LEDs won't get damaged. I did a mistake in the wiring of the LEDs at this point. So if you follow the official LED-Matrix-Pattern, you will get crazy results. But anyway: This is a software-thing. If you change the matrix-pattern, they work perfectly. I'll advice you about it if you buy it. I have two of those available. On one of them I needed to fix a trace (3rd. picture on the left). But it's perfectly working. Encoders are Bourns PEC16 with integrated switch. Underneath there are three IDC connectors for the encoders and switches that can be directly connected to a DIN-module. Price: 30€ each o.b.o. Next is a LRE: It has warmwhite LEDs. Lower row is mounted on spacer, the others not. Encoders are PEC16 with integrated switches. On the switch-header I soldered a flat-cable directly. So if you don't need it you have to remove it. Price: 35€ This is PCB where you can mount encoders on the top. Necessary shiftregisters have to be mounted on the backside. It's SMD, but can be soldered with a good soldering iron without any problems. No need for SMD-equipment like reflow-oven. Price: 3€ each STM32F4 Discovery! Price: 15€ each AINSER8-module assembled. Price: 6€ each AINSER8-PCBs. Each PCB includes three layouts. I will not cut those in pieces. You have to do it by yourself. Price: 4€ each PCB (=> 3 AINSER8 Layouts) AINSER64-PCB Price: 5€ each (two available) DIO-Matrix-PCBs. Each PCB includes two layouts. I will not cut those in pieces. You have to do it by yourself. Price: 4€ each PCB (=> 2 DIO-Matrix Layouts). GM5x5x5-PCB Price: 5€ That's it for now! I'm located in Berlin, Germany. Best, Chris

You can connect the midibox either via USB or via the MIDI jacks of the Zynthian. I have a Zynthian here. Latency is... well... "okayish". I don't think it will satisfy professional-musicians. Here are some latency-tests: https://discourse.zynthian.org/t/zynthian-midi-audio-latency-measurements/1793 There are "faster" soundcards like PiSound. But it seems not 100% compatible with zynthian. Also the original soundcard, that is recommend with Zynthian (HiFi Berry) doesn't have an audioinput while PiSound has... not sure if this is important for you. There is a version of the HiFi Berry that has an audioinput too... I wanted to check it out the next days... I'd like to run MODEP on it...

Did you ever look at the Zynthian Project? That looks quite promising.

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.

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. :-)

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.

I'm quite sure you can leave it away if using an external PSU. I've never used it in conjunction with MCP1541. I think the resistor should "decouple" the VRef from Vdd somehow. But I don't know anything about the technical background.

I don't know. I can't see in the datasheet if 5V input voltage is enough... so, try it and please report back.

Well... at least for me it solved all problems :-)

I use this method a year or so on different cores with different configurations. My last build was a faderbox with 9 100mm faders which can send 10bit resolution with USB-power. If you only need 7bit, there shouldn't be any problem. Yes, it has 4V Output. Of course 5V would be better. But as @Zam already said: You can not really clean up 5V USB and end up with 5V. You will loose something. I'm okay with it, because it works perfectly. Even on breadboard. No need for a high-precision PCB-design to get this working. Just try it. It costs just a few cents. I have a few capacitors connected to the USB-5V-rail and an inductor in front. But even that is not necessary. My earlier designs didn't have that filter-caps and worked very well too.

The solution is easy: Go and get a MCP1541. You connect USB 5V to the input and it's output you connect to the VREF input on the AINSER8 (of course you need to cut the trace between VREF and +5V on the AINSER) and to the all analog controls that are connected to the AINSER8. This little IC solved all my problems I had with jitter. Especially when running just at 7bit, this should do the trick.

Strange... Could you please upload an image from the core-module? Maybe there is a jumper missing on the discovery-board itself? Also you don't need both USB-connectors for uploading that firmware. The micro-USB should be enough.

So in case I have another sysex-stream assigned to the 2nd line this would also get overwritten? This is also no solution for me :-(

And what happens with the text when it exceeds 128px? Wordwrap? Or discarded?

Hey people, I have a question: I use OLEDs with a resolution of 128 x 64. I use them in a row. I set up a sysex-stream which shows text on the displays. This stream is set to lcd(1:1:1). If the text takes more space than 128px, the rest gets printed on the next screen(s). I know that this could be useful. But not in my application. Can I somehow disable that? I took a look into the code but I didn't find it yet. Each OLED should get it's own stream. If I do not push the streams in the correct order (f.e. first stream 2 => OLED 2 and then stream 1 => OLED 1) it will overwrite stream 2 of the 2nd OLED. Thanks, Chris