• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About weasel

  • Rank
    MIDIbox Newbie
  1. thank you so much, great advice! will get back later with results and thoughts! i'll order some troLED and get that fablab CNC going..   what do you think about the idea of just casting 0.84mm (LED height) of black resin or epoxy directly on the LED PCB, to surround the LEDs and thereby cover the sides, only leaving the top side open? either cast a thin liquid expoy or use something more gluey pasty and press it in/scrape off the top? i think the direct 90 degree side-to-side bleed between two neighbouring LEDs is my biggest culprit right now.   edit: what router bits are you using? dremel/proxxon stuff? i assume you run through a lot of them, breaking? any recommended brand?
  2. @Antichambre man that finished frontplate looks so incredibly amazing, insane job, congratulations again. what kind of router & bit did you use to mill the PMMA? not sure the CNC at my fablab is fine enough.. not only are my measurements a good bit smaller but also i start realizing the laser cutter with its convexed cutting edge is not really precise enough for light channels like that.. so the biggest issues of translating your approach would be the holes in the black MASK layer, or rather the walls between the holes. @FantomXR i did some quick maffs, if we go 36>32 that will give me an additional width of the radial gap between each of the LEDs of 0.2-0.3mm, at the smallest most inwards point. so almost double what it is right now, i would have around 0.5mm at the smallest point which should make the masking much easier. might still have to CNC and not laser cut. oh and trotec FTW, they were the easiest and nicest to deal with too. innograv almost didn't take my business lol. oh bruno if there is any chance you have some pictures of the MASK and WINDOW layer combined with the LEDs stuck through? or any more close up/side shots of the all-layer frontplate. that would be formidable oui oui. i ordered a bunch of different epoxy/milliput/sealer combinations too though and still wanna try just casting/filling the whole 0.84mm height around each LED. anybbody ever tried filling frontplate LED holes with epoxy or similar? EDIT: epiphany? what if i make a silicone negative of the fully assembled LED ring board, and then cast a theoretically perfect resin/epoxy mask from it? where do i learn about this haha. oh wait. i need a double negative casting shape. prolly all too much effort, i wanna make music not get into plastic manufacturing. also i will try some ready made light pipes - anyboby has a good source for those? mouser etc start at 50ct/piece for the 1mm ones, that would be 70EUR per 4x1 board lol. have some regular 1mm and 1.5mm optical fibre cable coming too but i assume that will be hard to cut to size precisely and make it perfectly flush with the frontplate? made some more lasercut cardboard masks last night, i think they came out better but probably not perfect. will test and report tonight.   @TK. thanks, yeah i somehow was sure you would consider fixing the code after we approached this barrier... i know you'd do that "im schlaf" basically. but here's my opinion: other than RGB LED rings probably nobody would ever want to connect that amount of WS2812 to a midibox. i personally would LOVE to be able to avoid the extra arduino, i just went there lacking an easier alternative, i didn't prefer it at all! just everything luckily worked pretty much right away. so of course, midibox support would be great, because right now even if you only want to use lets say 100-150 ws2812 they would currently not leave much RAM for other stuff anymore. but if i understood it correctly you drastically reduced the amount of work you want to put in on midibox overall, and given that, i am also not sure if it is worth your time to fix this driver. for perspective, i have about 2-3 people interested in the order from the midibox platform as opposed to around 10x that from other platforms combined. i don't really have any numbers to judge how active the midibox community overall really is these days and how many new developements, products and users there are outside of this forum. but my gut feeling tells me that you should maybe save your precious midibox time for something more urgent down the line? would love to hear other people's opinion on this. cause on the other hand the WS2812 is such a stable in the DIY world by now. i'd very happily send you whatever display/mapping/ring-style code i have if you end up doing something. for you to laugh at, delete and redo properly.     EDIT 2 i can't stop staring at your frontplate bruno haha so beautiful you need to sit your ass down and finish these.
  3. haha man i keep coming back to that solution but i wanna try everything first to avoid it. i know i wanted 32 LEDs to start out with, but now that i got used to the higher resolution, i'd miss it. if i keep the same 5 bottom LEDs covered which i have to, it would only be left with a real life resolution of 26-27 LEDs... shoulda went with 0603 APAs maybe lol   seriously though, we might have to walk the 32 LED way.. give me a couple more days.
  4. Hey @Antichambre, thanks a lot, good call on the forum post! I feel like this doesn't belong in the bulk order thread though so lmk if you want me to move this to a new thread before you or anyobdy else answers... So i am currently investigating frontplate options and i realized some small issues with these 2020 LEDs: they are in a completely transparent housing, as opposed to the white housing with a top lense of the 5050 2812s. So naturally i get quite some cross bleed between the neighbouring LEDs, at highest brightness setting even up to 2-3 LEDs far. In real life it is not nearly as noticeable as on those videos i posted but i am still trying to optimize it. Then of course i remembered your own glorious LED rings and the transparent inlays you sent me a picture of once. Would you mind in explaining in detail a bit more how you did them and if you think they are viable for my situation? Following are some sketches of what i have so far and some ideas. The "light channel" drill holes got pretty long, 3.5-5mm over all, but that actually makes frontplate assembly super convenient and also should reduce the cross bleeding by creating a more narrow viewing angle. any input is welcome! 1. This is a description of what you see on the videos, what i started out with. just a 3mm mdf with 1.25mm holes for each LED, and another 1.6mm acrylic layer on top, same holes. they align nicely and sit right on top of the middle of the LEDs. The thin arrows show where i think most of the crossbleed comes from. the whole housing of the LED is transparent resin so the 3 tiny R G B LEDs all emit light in any direction of almost half a sphere.   2. So the first thing i tried to improve it was to cut a negative mask out of MDF to enclose each LED, leaving room for the condensators and solder points. its black coated MDF and obviously the details are a good bit too much for the laser. but i am sure i could still improve on these first tries. it did improve the bleed a little but not to the extend i hoped for.   3. i tried the same technique but with black cardboard instead of the MDF, and the little bridges betwees the LEDs came out even better.   4. the next thing i want to try is different materials. i did a first cut of the same negative mask as above in solid acrylic but didn't get to test it yet. i have to play with the lasercutting margins and measures to make the fit as good as possible, eg. i left space for the extra solder points but not for the blobs of solder around the LED connectors. but right now i am more interested in alternative methods. what about using milliput or some other thick epoxy stuff, press it on the LED pcb so the top stays somewhat clear, and carve off remainders after hardening? something like this: (note: most likely my final front-frontplate will be aluminum..) anybody has experience with using milliput/expoy like this? another thing to try is the resin-based 3d printer in my local fablab which might be detailed enough to get a better mask going. and yet one more idea is to get some thick lightproof acrylic paint and a tiny brush and try to paint the sides of the LEDs, or even spray paint it with circular masking tape on the top?   also i am not sure about how to fill the light channels in the frontplate, what you, @Antichambre did so beautifully with those inlays. i was also gonna try just fill them with epoxy and razer off any residue on the outside? or maybe get some 1.25/1.5 mm optical fibre, and stuff each LED hole with a 3-5mm piece that ends directly on the LED enclosure? might also help reduce bleeding.   Here are some more pics of @FantomXR's beautiful prototype SMD assembly job, you can see the shape of the LEDs really good. in before questions: shot on iphone with a 10$ hama macro lens i just bought on impulse at the local electronics megastore. keep in mind these LEDs you see are 2x2.2mm small...     and to lighten things up here's another video, this time i added some shift functions.  
  5. of course, first things first!!   the manufacturer seems to currently have a discount on the assembly parts of the job, so prices will go down a bit! will update asap!   here's some basic music functionality tests:    
  6. here's a cute little video with a prototyping frontplate. bottom 5 LEDs are blacked out intentionally for classic "fake poti" use. this right now is controlled via arduino, not midibox, since there were more convenient demo routines available. frontplate is 3mm mdf, sitting more or less directly on the ws2812. top row has slightly bigger holes than bottom row. ws2812 running at 25% brightness....  
  7. New eurorack modules from midiphy - preview

    will do, i ordered the chip a couple days ago to try and improve on the existing unoffical driver for axoloti (stm32f4 based too), but will also try and look into direct midibox use!   enough derailment, these midiphy modules look like all midibox users would ever want!!
  8. New eurorack modules from midiphy - preview

    i love the paper panels haha! no lasercutter fablab near to where you live i guess? are these MAX11300 powered by any chance?
  9. Great work @FantomXR that picture looks absolutely terrific. we will evaluate the design for a couple more days and run some more tests and then finalize the bulk order with updated prices, anybody interested can PM me now.     edit: fwiw, alternative method of driving ws2812 on the F7DISCO: https://stm32f4-discovery.net/2018/06/tutorial-control-ws2812b-leds-stm32/
  10. Wow this is amazing news, the OG just blessed us with a firmware update! I am pretty sure @FantomXR will get them running just fine now! Thanks so much @TK. this will help alot and we should get at least 2-4 LED-Ring-Boards going. I'll send you some for reference once i have the production run! I read through the mios32 ws2812 documentation and realized you need to use 48bytes per LED for the PWM DMA solution. I do understand the motivation behind this, saving CPU power, but is there a somewhat easy way to go back to other methods as described in the uC.net article you linked? Thinking of the "average" midibox tasks, i doubt it pushes an STM32f4 to it's CPU limits? Guess using the flash memory would wear it out too fast? I would love to implement it myself but that's way beyond my knowledge and time constraints, and at the same time i assume there is little need for other people to go beyong 300-400 LEDs. But how do other ie. arduino ws2812 drivers get away with just using 3 bytes per LED, on a much slower CPU? Since for 40-50 encoders i need to adress between 1500 and 1800 LED - 72kb at 48bytes, ca 5kb at classic adressing - i guess i might have to just add a little arduino or similar MCU to control the ws2812. even the smallest UNO can handle 500 ws2812 at 60Hz, and the Due with its 3-4 serial lines should be able to run all 50 encoder-LEDs i need.    
  11. yeah since i'm coming form woodworking - maybe the OLED had to adjust to room temperature first
  12. well after a million tests and power cycles yesterday i just turned on my main system power supply this morning and got this   so consider this case closed.
  13. The NG and the DSP...

    These look very interesting indeed. Not as obviously/conveniently freely programmable. I am currently building a synth on the axoloti platform. While rough around the edges the patching software for it is a really great balance between simple modular patching and hardcore coding. But the hardware is kind of outdated (same STM32F4) and the community rather slow these days. There are currently notions to develope upgraded hardware on an ARM m7 or other newer platform though. http://axoloti.com/ sorry i just kind of crashed into this thread from a search result, not sure if this might have been discussed before or even is way off topic. oops.
  14. I wired up my 7pin SPI 1306 according to this diagram using 1k res and 10u cap.     but i'm failing to get anything out of the screen. trying to just print text through the console lcd command, or the hello world program or even the NG init message. i did set the correct LCD type in the bootloader: there's this other old thread where someone had to connect the OLEDs reset pin to some other core connectors GPIO pin iirc? is that really the way to go, no convenient simple conncetion available? i tried manually setting the reset pin to 0/3.3 via the testlcdpin command, no success. while manual, that should do the same trick as the GPIO pin reset above, right? edit: i realized the J15 reset pin is connected to the DC pin of the OLED? so no manual reset this way?   i tried doing some measurements. core board soldering seems ok. power/ground voltages are also where i think they're supposed to be everywhere. is there a page or list with debugging measurement points on the STM32F4 core board? DINOUT and AINSER 64 work for what its worth.   more pictures of my "circuit" i realized in the above picture the SDA cable was in p4 instead of p6, that was not the issue though. OLED supposed to work on 2.8-5.5v, i tried both 3.3 and 5v jumper settings. yeah i know my soldering is "sub par" GND and VCC from both j15 and the OLED going to the power strip on the breadboard, and the blue wire to the reset pin.  
  15.   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.