aurora42lambda

aurora42lambda

0-day streak
It's kind of end of summer, already I honestly did not expected the nixie clock to take so long to build, and my goal has failed, I did not finished it for end of August. To be honest, it's fine, better to not rush something as expensive as a nixie clock to avoid doing careless errors which could lead to disastrous consequences. Today I got the top layer PCB, the missing piece now is the motherboard. I'll finish it, hopefully before 2021 as classes will start soon and will take me a lot of time. I guess it's time for me to draw conclusions about what I learnt while doing this project: • PCB designing is honestly fun on an occasional basis, I wouldn't like to do that all day though, it can become quite tedious quickly. • Nixie tubes are fascinating and not that hard to control when you have the right components • 170V power supply are tricky to find • Programming on a STM32 is really fun and interesting, will do that again instead of using a Raspberry Pi or an Arduino, there's much more control, at the expense of having fewer ready-to-go libraries • I did too much OOP for a clock again • I DO NOT recommend to wire up a nixie clock without a PCB, it's just hell • The common DS3231 RTC module has big problems, like having a """charging""" circuit which is just more dangerous than anything else because it does not have any protection and this module is often used with non rechargeable Lithium coin batteries, in my case it's mostly fine for now as I run everything under 3.3V so it doesn't charge the battery, I added on the motherboard a pin based switch to use 5V the day I recreate a similar module with an actual charge circuit (hopefully the motherboard will be enoughly future-proof). • Discovered this community, which is very cool, you are all super cool and supportive :D I really hope I'll be able to finish the nixie clock soon, and once finished I really hope I am able to show you all the final result. Thanks a lot for supporting this project ;)
image.png
image.png
Today it was Minecraft modding again because why not, I wanted a multi line text box, and it has gone very wrong, it's not finished, it's very borked, and I spent too much time on it (big oof) So here's a screenshot and a video of what it looks like when used: streamable.com/cw0qaz Hopefully to finish it I won't spend another day xd
image.png
My other cat because I was away all day so I couldn't progress on any of my projects :/
img_20200606_135517.jpg
Today was a very busy day, I had a lot of code to do for some other projects, a pull request to manage, etc. But sadly there's nothing visual to show you, so here's one of my cats, she's very cute :) Also if someone knows a N-type MOSFET which can drive at least 1A (or 500mA it could work) and only requires 3.3V logic levels at its gate it would be great :D
img_20200628_131128.jpgimg_20200403_200730.jpg
So I made the symbol for the power regulator, I'm still trying to find the correct MOSFET to use (and it's hard). The top PCB for the nixie clock has been finished and now I have to wait it to be shipped! Sorry I have not a lot of things to show you all today 😔
image.pngimage.png
Please accept bumblebees and bees from my garden instead of my usual posting because I was very busy today so I was unable to work on the nixie clock :C
img_20200813_233600.jpgimg_20200813_233605.jpgimg_20200813_233609.jpgimg_20200712_170828.jpgimg_20200712_170755.jpgimg_20200712_170900.jpg
I struggle a lot with MOSFETs/transistors but that's what I guess I need to use for my nixie clock, good news is I already found a little 5V regulator! Tomorrow I will not be available a lot to work on this but hopefully by the end of the week I'll have finished the PCB designing of the nixie clock motherboard and I'll start working on other PCBs for my scooter which had failed attempts for lighting (because nights in winter) but always failed as I did not have a 3D printer nor the knowledge for proper PCBs at the time.
image.png
So uh today: Tried to tackle the 5V problem of the nixie clock Discovered the NOT gate as a NPN transistor Designed simple schematic to power 5V regulator if 12V supplied Sadly this circuit won't work after some research Time to try to learn about MOSFET Why is transistors so confusing and hard? I wonder... I wonder... I don't know what I wrote, there's no rhymes, that's a bit sad but I don't like writing with rhymes anyway xd
image.png
Ordered one of the PCB for the nixie clock, hopefully it will come quickly
image.png
Today was a hot day so working on the motherboard of the nixie clock was a bit hard, so here's just a symbol footprint for the DS3231 module. I also modified a bit the first PCB which I'll order tomorrow.
image.pngimage.png
I don't have anything to show today about the nixie clock, so I'm showing you something I recently added to my minecraft mod LambdaBetterGrass the better snow feature from OptiFine, but made it better again as now you can specify if it needs the snow layer and a custom block state json! So you can entirely replace the models, and the textures! and here's the result with a test resource pack, snowy fences! I'll embed the resource pack as optional in the mod as it uses custom textures which will not adapt with resource packs, but it really looks cool :)
image.png
Very scary motherboard PCB for the nixie clock, still very WIP as it still misses a lot, but I successfully routed every shift registers, binary decoders and nixie connectors :) Sadly I couldn't get away with a 2 layer PCB so it's a 4 layer PCB! Which is.... more expensive then :c (hopefully not too much but will depend a lot on the final size)
image.png
Today I worked again on my nixie clock and today was motherboard PCB time! First the schematics! Though those are not finished as it still misses some debug features and buttons (and the RTC connector) There is multiple pages, first page is the devboard connected to page 2 which is a set of 3 shift registers to control 4 nixie tubes. Then the shift registers are connected to page 4 which contains a pair of nixie tubes with the power connector And last page which contains one binary decoder and the nixie connector for the "nixie holder" PCB I have designed prior to this :) Multiple pages were necessary to decrease errors by repetition and to be more time efficient :)
image.pngimage.pngimage.pngimage.png
Continued to work on the nixie clock again! Still the same PCB as yesterday but now it's not a schematic anymore but a PCB (not real for now but it's already a good step)
image.png
So I finally really started to work on the schematics (and future PCB) of the nixie clock! This is the "top" layer, there will be 4 PCBs like this with this schematic connected to the motherboard. The top layer has 2 nixie tubes connector, the quad channel optocoupler, and the resistors. Hopefully it will fit and not too big. On the motherboard there will be the binary decoders and shift registers :) (note: the image is hard to read but can't do better with KiCad ><) (note: I made myself the symbol for the PS2833-4-A because the symbol I originally found was on a website which required to have an account and I did not want give my details to another random website and I did not liked their license which prohibited redistribution which makes harder to make the schematics open source 😔 )
image.png
Today I got caught up in bikeshedding so not a lot have been done today, and I horribly slept last night so that did not help either. So please accept this configuration GUI I just added today, transparent is noice to see exactly which effect is which when changing setting ;) Tomorrow I'll struggle with KiCAD ahah
image.png
Was a very long time since last post, my scrapbook posts should resume starting now! Got a bit burned out of programming and hardware for some time and I got caught up by Fallout 4 😔 Today still nothing about nixie clock but I learned that the PSU I have soldered works miraculously as the ground pad for the controller is under the SMD component and it makes contact because I accidentally applied solder on that pad xD Instead I'll present you my most recent work which involves again Minecraft modding and this time it involves a whole lot more rendering! For those who plays with OptiFine you might know the "Better Grass/Snow" feature. I personally dislike it a lot and the first image might tell you why: it's too unnatural. So I wanted to make a mod to solve this and do it kind of better than OptiFine! But how? Introducing blending on those blocks! When loading the models I look into the resource packs and search for bettergrass states file, if it exists then it tells which variants of this block is actually affected and their bettergrass metadata file! The metadata JSON file is composed of layers with top/side textures definition and overrides textures definition for the blending, masks textures to automatically generate the blending texture with top and side textures, and which color index is affected. Then I replace the vanilla baked model and introduce logic to choose the correct texture and at resource pack time I add a virtual resource pack which holds the generated textures, the texture generator is highly cursed. And here's the result on grass/snowy grass, mycelium, warped nylium and podzol! You can change a lot through resource packs which is useful for mod authors and resource pack authors! Some of the textures are not definitive but it's already better than OF's bettergrass I believe ;) If anyone is interested in the source code and documentation: github.com/LambdAurora/LambdaBetterGrass
image.png2020-08-01_23.07.42.png2020-08-01_23.15.54.png2020-08-01_23.16.45.png2020-08-01_23.17.42.png
Today I haven't done a lot of programming to be honest, but when I had I tried super hard to uncurse the fox model from Minecraft to allow tail wagging, now I have to tie that to when the player pet a fox.
Working on fox/player interaction, bit hard. The idea is the fox likes you more the more you can interact with! (Like giving them an armor, etc.) And when breeding, if they like you enough the baby will trust you more.
image.png
Did more code/modding, and oops, fox armors in Minecraft! Besides that, I'm still learning a bit Kicad ahah, will try to make custom symbols and footprints, hopefully that's not too complicated.
image.png
Not happens a lot, but today I have nothing interesting to share, apart that I uncursed some Minecraft code and make my foxes spawn or that PCB designing is a bit hard when you can't find the symbol for an IC. Instead, please accept those little pictures of the nixies lighten up in the dark, the result is not as good in pictures as it is in real life tho, but we can slightly see something really interesting about those nixies I couldn't show with the light on: a slight blue glow, in real life there's a blue glow around the orange glow, but why? After some research it's perfectly normal as it's not blue dots (which are because there's too much current flowing in the nixie tube) but it's because of mercury present in the mix of gazes! Mercury was not always present in nixie tubes, it was added in the latter versions to extend their lifespan and prevent, to an extent, cathode poisoning! That's also why some nixie clocks have blue LEDs below to hide that blue glow (but I personally dislike those LEDs) or that's also why some nixie tubes have a red-tinted glass instead of fully clear glass to hide the blue glow! Nixie tubes are so special, I hope one day I'll fully remember all the physics behind nixie tubes so I can casually explain it xD
img_20200715_233715.jpgimg_20200715_233758.jpg
I started working on the PCB of my nixie clock but still don't have anything to show related to this >< so please accept this instead: fennec foxes in Minecraft! Adding the big ears was a bit difficult ahah.
image.png
Are you ok fox? I think your tail is spinning 😐 (I tried to mod something to make the tail go lower when the health is low, but my method wasn't overriding so it used the default animation progress)
AI is weird, thanks Minecraft's spaghetti code. I'll maybe figure out what's actually broken. Note: setting a velocity of 0 did not help either.
I added more foxes because why not, I added platinum, white and marble foxes! Now I should start working on the spawn logic, etc. Soon I'll also start the PCB design of the nixie clock ;)
image.png
Random Minecraft mod coding is back! Today I really wanted to add custom fox types in Minecraft, I had to make a little API as the original code uses an enum :c And the worst is it uses numeric ids too! Which is horrible for modding. So what did I do? I replaced the enum by a new class with the original values, when you want to add a new fox type you'll have to use a method which requires an identifier in the format namespace:name which is great for modding, to break the less things possible I made that it still associates a numerical id. But how does it work? The goal was to use a ℕ^n -. But how with strings? I simply for-loop the string characters and use their ASCII/UTF-8 values to compute the numerical id! Honestly I wasn't thinking that when modding I would involve Maths ahah. But it's good I think and it works :) And I'm happy with the texture I made for the silver fox! The other cool detail is it can technically work with Vanilla clients, they will not crash if they join a server with the mod, they will just see red foxes.
image.pngimage.pngimage.png
Haven't done a lot today, I added a little random mode for my clock for fun and debugging I also rewrote the display code of the time clock mode so it uses a for loop, kind of better. I also fixed the thermometer mode to display with only 2 nixie tubes! And that's all for today ahah. PCB designing is hard, and it's a pain when a part symbol isn't available for kicad :c
image.pngimage.png
Since I can light up my 2 nixies I can't turn them off as I spend too much time admiring their beauty. But the code doesn't handle 2 nixies so I added something so every 10 seconds it switch between displaying minutes and hour. Why only 2? because it's the size of the prototype and wiring 22 wires is already hard enough. Will soon start on designing the PCB and hopefully get it very soon to start soldering everything and bring it to life! Note: the entire clock is powered only from USB-C and that's cool af honestly, and soon I'll see my grandfather who worked with nixie tubes in the 70' so I can't wait to show him! :)
image.png
Finally finished some power supplies, sadly the first I finished to solder did not work, I may have overheated the controller :/ That's kind of why I wanted to complete multiple power supplies: I'm sure that at least one will work and if one fail I can replace it easily. Soldering SMD is hard, I had to solder the smallest IC. But everything works! I finally can light up the nixies!!!
img_20200706_144235.jpgimg_20200707_142248.jpg
I'm too lucky, got the other part of the power supply :fixparrot:
img_20200706_115152.jpg
Oh? What is this? Got some hardware thanks to @sampoder and SoM team! Thanks a lot! Will have to wait for the rest of the power supply to come to solder the SMD, can't wait to test it!
img_20200706_104628.jpgimg_20200706_104711.jpg
image.pngimage.png
I don't really have anything to share today, so may you all accept this picture: my 3D printer with a very unstable spool holder ahah.
img_20200704_215833.jpg
Can't wait!!! Thanks again SoM team!
image.png
The PCB and SMT assembly of the nixie tubes power supply has finished, now waiting for it being shipped! As the SMT assembly is incomplete because not every parts were available in their catalog, I'll have to wait for the missing components to come and solder them myself!
image.png
Today I continued to mod Minecraft and I tried to make a very difficult mod: dynamic lights The problem is the light engine of Minecraft is difficult to use and to find how everything works take a lot of time. I succeed with one implementation but I'm still not happy as it's not smooth at all. So yeah, here's a little video demo-ing it, hopefully I'll achieve an implementation with smooth lighting.
So today I have 2 things to say: The power supply PCB for the nixie clock project is finished (with the SMT assembly, there's just the missing components which I'll have to wait to get them and solder them myself) and now I have to wait it to be shipped! The firmware isn't progressing much these last days as working on a firmware without the more hardware makes little sense to me and it makes debugging/testing a bit harder. Until then, I'll only share progress on this project when it's about supplies and PCB design (which I should really start). Today I worked again on my controller support mod for Minecraft, which may seem a bit ridiculous for some people, but it's actually a great tool to learn some things! Today I finally added analog movements after modifying my ButtonBinding API (which manages bindings made with the controller buttons instead of KeyBinding which is for keyboard/mouse) to include the float value. It's really great to work on those kind of things as it will certainly help when making your own game! Everytime I implemented an input system I struggled but with this API I'll be able to make a more robust input system the day I'll make my own game! The screenshot is an example implementation of a PressAction interface which handles the input actions of a ButtonBinding, and this one is also the analog movement implementation. :)
image.png
Working on a firmware without the hardware is a bit difficult so today, after thinking about the part list, I worked again on Minecraft modding! I have made a mod to add controller support to the game and other quality of life control improvements, I already have added something I call "front block placing" which allows you to put blocks in front of you to make like bridges without having to be backwards and in sneak and that is available in the Bedrock Edition of the game. But what about vertical block placing? Down the block your standing on? So today I worked on vertical reacharound! I had to change a lot of the previous implementation of "front block placing" that I have to allow vertical reacharound, as I make a special "Block Hit Result" which is raytraced from the player's eye position towards where the player look with a range. Now that I have a common class for front block placing and vertical reacharound so they share the same cached variables, I had to make the actual algorithm, how to detect that I want to put a block with vertical reacharound? Well, given the methods available it's actually simple! First I check for the pitch orientation, which has to be bigger than 80.0f (max being 90.0f), then I had to determine if I can vertical reacharound and where. To do that I use the ray tracing function with as range the player's max reach and a start position slightly modified, the goal being to ray trace to the block the player is standing on. So I take the player's position and add 0.75 on the Y-coordinate and checks if I hit a block. If I hit a block, then I check if the block down is air or replaceable and if it is I can return a modified "Block Hit Result" with as the hit side the Down side and the block position below the block which the player is standing on. Then I cache it each tick so I don't have to call this function each render, etc. The method for the actual block placement (which is the item use) was already implemented so I didn't had a lot of work to do beside adding a little animation around the crosshair to indicate that you can place the block below. And tada, here's the result in-game! Hopefully my explanation is understandable, ahah! ^^
image.png
Today was not very about code so I almost haven't coded. But I haven't shown everything about updating my Minecraft mods to the latest version. One of them is a client mod about displaying the key presses on the screen, someone requested it so I made it. While updating the mod I also wanted to add a new feature which was rainbow text! But I was a bit lost as I didn't know how to do that, there's multiple methods: • combining the font texture with a rainbow texture in the OpenGL shader, but that was unpractical with the mess which is Minecraft rendering (and I don't know enough about it) and making a "moving" texture would be hard with my limited knowledge about shaders. • drawing every character a different color: that's possible, with the latest MC update as they dropped the immediate rendering (OpenGL 1.0) it's not a big deal to do that way as it won't destroy performance So I chose the second method which is less smooth than the first one but it still gives a convincing effect. How does it work? Simple, when I want to draw a string, I'll use a special function if I want the rainbow effect, which will draw each character separately. To get the color I use a HSB to RGB method which allows me to make easy colors as it goes from 0.0 to 1.0 (from red to purple, like a rainbow but circular), and to make the color "move" I tied it to the current time in milliseconds and to make the color independent from each character I also tied the position of each character:
    public static int getRainbowRGB(double x, double y)
    {
        float speed = 2600.0F;
        return Color.HSBtoRGB((float) ((System.currentTimeMillis() - x * 10.0D - y * 10.0D) % speed) / speed,
                (float) AuroraKeystrokes.get().config.getRainbowSaturation(),
                0.9F);
    }
A bit difficult to find it at first but when found it gives a cool effect :)
image.png
Today was a bit different, I didn't work on the nixie clock as I was a bit busy updating my Minecraft mods to 1.16. It would have taken little time if those mods weren't client mods, but they are and rely heavily on rendering and that changed a lot in 1.16 is it took a lot of time. This particular mod is for controller support on Java Edition on the Fabric modloader. I'll come back to the nixie clock firmware development soon ahah.
image.png
Today I worked a little bit on the nixie clock firmware! I added the thermometer mode (as the DS3231 as a temperature sensor), the handling of the mode button to cycle through the different modes, the cathode poisoning prevention algorithm and I changed a little bit how modes are registered to fix a bug in the cycle mode algorithm as std::map orders alphabetically with string keys so I replaced it with a std::vector so I can keep the original order. The code below is the code of the thermometer mode, there's two display modes (if there's more than 4 nixie tubes) which just defines if the comma is on the same nixie tube as the last integer digit of the temperature. Here's the commit if someone is interested: github.com/LambdAurora/nixie_clock/commit/1ca878372e1efada336288ecba3bab174d6ae272
image.png
Nixie Clock Update! Today I added a lot of things to my mode system: timeout handling so it can timeouts a mode after an amount of seconds without any interaction to go back to the default mode which has cathode poisoning prevention (it avoids accidentally staying on a mode which doesn't have this), auto reset of the nixie array each update, initialization system for optimization, etc. I also added the date mode! Which was quite difficult as I had to add two new configuration entries: date_full_year which determines if the year is fully displayed or only the two last digits and date_format which is the date format like YMD, MDY and DMY as default. The difficulty was figuring out how to display that correctly in the correct order with 4, 6, 8 or more nixie tubes! I had the idea to put the date in a 8-bit unsigned int array in the format dd MM YYYY then I have another array which contains the indexes of the first array in an order which depends of the date format! It allowed me to make the display algorithm simple and understandable! If anyone interested, here's the commit: github.com/LambdAurora/nixie_clock/commit/c37c5d1f649f646f165d2cd6f450de5699b74d43
lambda_nixie_clock_date_mode.png
Still working on the nixie clock firmware and... today there's a lot of changes in the code! It was time to code the "modes" to switch between time and date displays, thermometer, configuration, etc. And it was a bit complicated to implement that in an easy and working way. Also, display centering for huge number of nixie tubes is fun. But now the modes are represented by classes with an update method and timeout to fall back to the default mode if no interaction was done for a certain amount of seconds. I also added a code for the RTC module in case it losts power (but it shouldn't with its battery), in the case it lost power it will restore the last time and date the firmware knew which is its compilation time & date! I also had to search for an algorithm to determine the day of week from year, month and day of month; and I found the answer on the website of a Canadian university with a C code from 1993. If anyone wants to see the changes: github.com/LambdAurora/nixie_clock/commit/22cac8b004324ba2eb293c8547379e5909bbe7e3
lambda_nixie_clock_rtc_restore.pnglambda_nixie_clock_day_of_week_function.png
I wanted to work on the mode manager in the firmware of my nixie clock (so I can write different behaviors, update methods, etc. easily) but it was taking time and I was not entirely happy with the result. Instead I worked on the configuration part. The configuration is represented by a struct and there is a manager class to write/read the configuration from the EEPROM module which is present on the RTC module that I have. The picture is the code in the header file of the configuration code!
lambda_nixie_clock_config_hpp_wip.png
Today I could not work on my nixie clock as I had to move a lot of wood but I can show you a project done in the last year of High School for my art class instead. (Note: it was one of the art project which I had to show at the final exam (Baccalauréat)) We had to make a mask from our face, and we had to customize it, and one of the goal would be that it would reflect a bit on our personality/person, etc. So I customized my mask as a PCB with a lot of components on it, etc. There's a speaker which allowed me to playback sound with a Raspberry Pi! (I'm a terrible photographer so everything is a bit blurry)
image.pngimage.pngimage.pngimage.pngimage.png
Began to work on the algorithm for the nixie tube array through shift registers! I had a little trouble with a part of the code which resulted into an infinite loop because I forgot about unsigned integers and decrementation while writing the code. In the screenshot look for the nixies variable which is the result of the work on that algorithm. (and nixie.hpp/nixie.cpp) And I pushed it to GitHub (github.com/LambdAurora/nixie_clock/commit/04bec99740df109aa000040f4ac211a3f8c4e43f)!
image.png
Today I didn't code, but I made a little sketch on the shift registers for my nixie clock! Maybe when done I'll make a video about the process of making a nixie clock ahah. The sketch shows how shift registers can be used to reduce the data lines count because in my case with 8 nixie tubes there will be 812=96 data lines, 86=48 data lines with binary decoders (4 bit binary decoders so 8*4 data lines + 16 data lines for commas), etc. I already know that 8-bit shift register can be used to get 8 output with 3 data lines but I didn't know that they could be chained (now I know about the overflow pin), so I can chain my 6 8-bit shift registers to only get 3 data lines to control my 8 nixie tubes! Hopefully my sketch is readable and understandable. Edit and nota bene: separating commas to their own shift register is really inefficient so I won't recommend that and just put each output group (for a nixie tube) one after one another.
nixie_shift_register.png
One of my summer projects, which is the main one! I'm currently working on a nixie clock project, which use, you guessed it, nixie tubes (IN-14) for its display. You could tell me that there are kits for that, and yes there are, but it's not as fun as making one from scratch and the cool thing is I learn a lot about embedded programming and electronics! Here there is a 3D printed support with 2 nixie tubes mounted on it and an electronic board behind with a shift register and nixie tube drivers (which are binary decoders) and there is a missing transformer (which really annoys me); and there is my breadboard with an OtterPill, a shift register and 8 LEDs which represents the output of the shift register and there is a RTC module wired to the OtterPill and a Raspberry Pi which I only use to get the serial console output of the OtterPill (and the UART connection is super instable). The nixie clock will be open-source and I'll try to make it in a way which you can build a nixie clock with 4, 6, or 8 nixie tubes with the same firmware (and maybe even the same PCB). If anyone is interested, here's the GitHub repository, at the moment there is only the firmware with the RTC module/EEPROM and serial console code completed. github.com/LambdAurora/nixie_clock
img_20200619_182937.jpg