.. | index about projects posts media links

update #5 - 9-13-23
me working on this over the summer was a total fantasy. college applications are happening so there was no rest this summer. this project has been kind of dead, so i'm going to stop lying to myself and officially put it on hold for now. there is too much i need to learn to make it a relaxing 10-minutes-at-a-time kind of project, which makes it unrealistic to work on during the busiest time of my life so far.
in other news, the link on sckzor's smd reflow plate is now a dead link because it blew up in his basement. RIP to the clothes iron and cheap thermocouple glued onto it.
one day i'll finish this and it will be cool, but that day will not be for a while.

update #4
ok so exams are happening so of course to procrastinate i ended up getting a lot done on this project. i am in the process of designing the pcb for printing and hopefully it will be done by the time school gets out, letting me order it start of summer break. after that, assembly is straightforward and all changes are cosmetic.

update #3
i promise eventually i will finish this project
so i have finally gotten my shit together in terms of designing this pcb. i need to fully flesh out the schematic of the entire box so i can determine my pcb's dimensions, but my electrical schematic isn't hard to put together and after that the actual pcb design should fall into place fairly simply (i have no idea if that is true or not). after that i order the parts, get the pcb printed and then put them together. i have a heat gun hot enough to melt solder paste and so while i will not have a pretty solder reflow heat curve it should do the job according to at least one guy's answer to an amazon question about solder paste. i was going to completely copy my friend (sckzor's smd reflow plate) but i figured that this will probably work just fine and worst case i find an old iron in a thrift store and frankenstein it with a few thermocouples and an arduino so i can make a nice little reflow temperature curve. anyways, this project isn't dead. hopefully it is done soon, although school might swoop down from the sky, pluck my ambitions from my hands and carry them off to the land of mordor never to be seen again.

update #2
i have not done a ton on this in a while because other projects and school took precedence for a variety of reasons. i have been doing a little research on how i'll need to wire up the ZIF connectors and i am actually terrified of soldering those. i am dogshit at soldering and do not own solder paste. maybe i can 3d print a stencil somewhere.

update #1
my lack of forethought brought me to a sticky situation. i have 7 displays; i have killed 3 of my breakout boards on accident (due to my own stupid error of breaking off the connector pads) and when i finally 3D printed an enclosure for everything i discovered that a snowball had a better chance in hell than i did fitting those 5 breakout boards anywhere smaller than a 6cm cube, which is horrible to look at and i do not want this project to be visually inappealing. also, i don't want to have 3 dormant screens. the solution i have come to to solve this problem is to design my own driver board for all 7 displays. this could horribly backfire on me due to my complete lack of knowledge on designing PCBs, but you gotta start somewhere. this is it for me. doing research on the process of printing those things, i was shocked at how dirt cheap you can get them, but unfortunately shipping anything to canada has the effect of at least quadrupling the impact on your wallet, so a $3 board ends up totalling at $25 when accounting for shipping.
regarding the software, it should be pretty simple. i have one little algorithmic problem to work out (which is made difficult because arduinos don't have a built-in hardware clock (understandably)) so i do not have a reliable way, as far as i know, to figure out the execution time of each run of the main loop. i want variable framerates on each screen which relies on me being able to calculate the time between the last render and the current to appropriately delay it. the whole reason i want variable framerates is this: with the 32kb of memory on the nano, 2kb goes to dynamic memory, while the other 30kb goes to program memory. one frame takes up 896 bytes. however, this number is just for one frame on one screen, meaning that the actual memory footprint of a single frame is 6272 bytes. this leaves me with less than 5 frames... with zero program. the program is a few kilobytes as well. realistically i can get 4 frames total which is kind of disappointing. however, if i could make the back screen render a smaller frame set at a lower speed, it could use less memory by virtue of having a smaller frame cycle while having an effect of distance, perhaps, compared to the closer screens. this could also be flipped based on how many different graphics one screen needs to display. i know i could just use the existing frame cycle and have it display less graphics, but i'd love to have the flexibility of having different framerates to give more granular control over the system. the code for this should add up to less than 200 bytes i hope, having minimal impact on the already slim number of frames allowed by the hardware. updates will follow!
original post so this is a project i've been chipping away at for a few months now (11/21/22). back in june i invested 90% of my project money into some transparent displays from crystalfontz and am stacking them and controlling them individually to make layered images. this project is a lot of firsts, really my first hardware project ever (besides toying around with 3 volt dc motors in elementary and middle school). i've figured out a lot, but have a lot to learn.

since i have zero experience in designing circuits, i bought breakout boards to go with each of the screens. this is a decision i regret but as i am an aware victim of the sunk-cost fallacy and refuse to design one and throw out the boards. it would be a waste anyways. to save space in my planned 3d printed enclosure, i removed the pins from the board to solder straight to the metal points, and killed 2 of the relevant pins on 2 of the boards. i will probably revisit this project and print my own board. however, in the mean time i will make do with only 6 screens. i've also learned how to 3d model and print for this project, undoubtedly important skills to have for future projects, including the wheelchair revamp. it's pretty fun, actually, but i think that fun might wear off pretty soon.

the software will be fun, but i haven't worked on it very much yet besides for the test rigs. it shouldn't be too crazy, but i'm slightly worried about memory on my board (bootleg arduino nano) in regards to storing bitmap graphics. i did not build the system with a storage expansion in mind, but it should be fine. probably will have to forego my idea of having a little button to swap between preset graphics, unless i just want to have a few very very small loops - i believe this board has 32KB of flash memory, some of which is consumed by the bootloader... 1KB of which should be taken up by just one frame, which limits me to maybe 10 frames depending on how compact i can write my code. unbelievable that people landed on the moon with just over twice this amount of memory, and i may struggle to store a few frames of bitmap graphics in it. we will see. however it ends up it will be a fun challenge as i have never had to work around hardware restrictions before. lots of firsts this project!
speaking of the bootleg nano, it's an elegoo brand replica, and when finding the chip drivers i discovered that the download page on their official website... points to a google drive folder. i find that incredible, i guess there just aren't enough of people downloading the ATmega328P and CH340 chip drivers for google to care. i thought that was pretty funny.

i'll update this page with ongoing progress!