FantomXR
-
Posts
1,035 -
Joined
-
Last visited
-
Days Won
22
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by FantomXR
-
-
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.
-
11 minutes ago, Zam said:
This won't change that much for ripple, noise and jitter from external interferences.
22 hours ago, tago said: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 -
Great! Looks good! :-)
Strange keybed... from C to B?
-
Hey people,
I have a question: I have made my own MB_NG & KB-application. Now I want to save only the files that are needed to "make" this firmware into a separate folder to keep the oversight.
Does anybody know how to do this? I'm on OSX and work with XCode.
Thanks,
Chris -
MCAN
in MIDIbox NG
Looks like an awesome feature! A perfect way to connect two or more midiboxes without adding latency! Thanks for sharing! :-)
I'll give it a try also...
-
Oh dear... thanks for clearing my mind! ;-)
BTW: Do you watch this forum all day? ;-)
-
Hey people,
I try to understand how the DIN is even working in the STM32F4-Core.
PB14 is not going through the HCT541 buffer. It goes directly into the IC. If I understood it correctly the purpose of the HCT541 is to do a level-amplification. It takes the level from the STMs outputs (which is 3.3V - 0.4V for HIGH for CMOS or 2.4V or TTL) and amplifies them. As the HC165 and HC595 are powered from +5V they need 3.15V to see a HIGH-signal. As the HCT541 delivers 4.5V for HIGH the HC595 does of perfectly work.But why do the HC165 even work? As I said it doesn't get an amplification. So in theory the HC165 sees 2.9V for HIGH but that's not enough so it should stay LOW and doesn't work. But it does...
Can someone explain this behavior?
Thanks,
Chris -
17 minutes ago, Antichambre said:
Yeah but you have to be sure you don't loose on other function on the new pin or they are not used somewhere else in MIOS32.
33 minutes ago, FantomXR said:I'll look into it ;-) You don't have any suggestions which pins I can use? :-)
-
Got you... but changing the pins for SPI2 in MIOS32 firmware shouldn't be that hard. So I could move those functions to other pins. But I don't have a clue how to implement that second USB port in the firmware... and I assume you don't want to share this informations which I can totally understand.
-
My mainboard uses the 407.
Hm... there is still something I do not get.
The discovery-boards use the micro-USB-connector for USB-Host-Mode. That means, when connecting a device (mouse or MIDI controller) to the discovery-board via this board it's not possible to connect to the core itself through USB (because the USB-port (PA12 & PA13) is blocked through the device). But in your video I see that you still have your core connected through USB to the computer. How did you do that?? :-)
-
Hey Bruno,
I'd like to connect another USB device (mouse or midi controller) to my core. :-) Like in your video...
-
@Antichambre I'd like to integrate such feature onto my mainboard. Are you willing to share the schematics and if necessary the code?
Any feedback is very appreciated. Thanks!
Chris -
No one? Any help would be very appreciated!
Working Project : DreamBlaster X2
in Miscellaneous
Posted · Edited by FantomXR
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...