Very useful, thank you ! Do you have a link to the Altera Max II board you used starting at 33:00 ? Everything I turn up with Google is pretty different looking. Thanks !
Can someone to do a tutorial how to find pinouts from micro sd card or sd card witch is under the layer mask for the recovery purpose?? Thank you . Every help i apriciate !!!
2:00 - Zadik.exe - how in heaven did you find this out? Well, my device still is not recognized, but without your video I would never ever have found this driver ....
Hi sir, new to the channel here, I am currently using debian, because it's a very stable distro, but after watching this, I think I am gonna give nix a try, thank you, and I can watch u all day.
I had several boards, starting with no board Lattice CPLD maybe 20 years to 15 years back. Done nothing, then Xilinx cheap eval board, I think DE-0 without VGA and so. Then Xilinx DIL module (XuLA), only tested some small blinking. Then a DE-0 Nano board, done nothing, then a Zync 7000 series with ARM, also nothing - maybe blinking and now a Gatemate from Cologne Chip with an Eval board from Olimex. They claim to support the open source way and I was able to synthetise also a blinking sample. But then I found it not working and digged into what was wrong. Slightly different scripting to program the chip from non vendor tools. Fixed. Different example pin for LED. I was expecting the FPGA_LED to blink, but it was routed to header without a LED. Maybe small design differences. But with that, I started to fix my first verilog 'bug' and adopted the script to support my USB port for that eval board. The board with an VGA and PS2 connector seems well suited for soft core SoPC's and is really a cheap no brainer (~50€). Over all, open source yosys and propably open source place and route from vendor, I need to check if their claims are true here also. Long story short, I ever felt to have locked in to the vendor tools. Cologne Chip and Gatemate seems to be another alternative up to medium sized FPGA's.
It is impressive that oscillator gives a very good signal, I have seen it on a "specific" spectrum analyzer and it looks the same. Thanks good video 📵🤣🤣😅
I'm all for nix, weirdly it's better at building docker images than dodcker. However, it should be mentioned that you CAN specify a hash instead of a tag in dockerfiles.
Is there anyone who has experience with USB Logic Analyzer ALIENTEK DL16 Plus ($125, 16ch, 1GHz@8ch, 500MHz@16ch, 3.5Gbit sample buffer, PGL22G chip) and can compare it to Saleae and DSLogic products, including the SW GUI? Thank you!
Hello friend, in the unit that I have received, it gives me a value depending on the ambient temperature and the time I have been handling my IBQ 102. When cold, for example, it gives me a measurement and when the unit "warms up" 200 hertz less on average . It is not a reliable equipment. What do you think?
For dev environments, tooling, languages, libraries, etc. You don't need to create a Docker container to accomplish things locally. For example, you can setup direnv and put a flake.nix in your project repo. When you clone the repo and change to the project directory, the flake will be run to install just what you need for the project. When you exit the project directory, the environment self-destructs and the /nix/store packages are dereferenced. When you go back into the project it will load the already installed dev env near instantly. This allows to have various incompatible environments that would not play together nicely and switch between them. You can also just spin up a nix-shell with the tooling you need. Meanwhile, building containers with Nix is still viable and useful to spin up containers in Kubernetes, etc.
hi @matthewstott3493 , i tried that but it downloads the tools each time - probably due to the nix.gc runs. i don't know, but it downloads some 400 MiBs every run after few days. i don't have that kind of network all the time. > _"put a flake.nix in your project repo"_
Cable chains are actually a downgrade. You've increased the mass that it has to drag, and in an asymmetrical way. The carriage moving left has to overcome more inertia as it moves and less as it moves right. Same with the bed. It has to move more chain as it moves away and less as it moves toward you. Compare to the weight of just the wire and you'll find that it's much more likely to skip steps in one direction than another when running at high speed. These printers are very capable of running at ridiculous speeds with only minor modifications, and I applaud most of the other changes you made, but cable chains should only be used where they're absolutely necessary.
This is awesome. I bought a Kingst LA2016 on Amazon, and for some reason I'm paranoid about installing their software. Their website is sketchy and I don't want to get a virus on my computer. This Sigrok/PuseView seems safer. I would like to run it on my Raspberry PI if possible. Do I need to flash new firmware to get it to work with this software?
I really want to like the nix approach, but the declarative nature of a Dockerfile is so much more readable and accessible. The Nix approach seems to overcomplicate things significantly. Maybe this cool for weekend projects, but I see the risk of wasted developers hours trying to understand the intricacies of nix, that would be quite straightforward and well documented in Docker. Add the really bad documentation of nix and you realize that any CTO pushing nix in a productive environment will be cursed by devs that want to work on code not waste their time on their tooling. There’s no wonder Shopify abandoned its nixos experiments.
Thanks for the great video! I'm wondering whether there could be more details about the very cool STL SDR spectrum analyzer you've shown. Is that from some open-source project or you made it on your own? I checked upon some similar designs and none has that very nice recording video and zoom-in feature in your video where you used to observe the settling time. Thanks! Would appreciate it if there is some source/guide on how to obtain one of that for hobbyists!
Thanks for the wonderful video! Soon I will have to connect to the USB cable and see what happens there. My project is getting close to this. I tried PulseView and ran into a problem with cursors. Since you said that you were or are one of the developers of this program, I am looking for an opportunity to report the problem found. I'm using Fedora 39. When I enable spacing cursors and try to move them, it causes the program to freeze for a long time. And subsequently they still move, but only after a few seconds. All this time the program is in a frozen state. I wanted to report this on Github, but there you can only do a pull. But I couldn’t find any way to register in bugzilla. I hope my message will lead to the correction of this situation. Thanks a lot!
Love the idea of Nix, just wish it had a few more new user friendly tools or better documentation. It'd be my daily driver if it was more in either or both areas.
this is so funny... I was following along (~6 months after this video was launched) and the Dockerfile build completely failed and I gave up trying to get it to work. But the nix way worked (after a simple syntax fix of adding a missing ')' to the flake.nix file. After that nix worked "one-shot" basically. Wow, docker confirmed not reproducible but nix is!
Very useful, thanks. After trying it for a few months I finally switched to NixOS in all my development enviroments. I'm still fine-tuning all the dev tools and stuff, and this video is a treasure trove of cool ideas and precious information.
31:40 modules are great, one thing that often gets overlooked is the children() function. you can use that to bundle up a set of transformations (say a complicated move and rotate). I end up with a lot of modules in my project with names like at_screws(), where it'll position a copy of the module's children at each screw hole, for example. this can be useful because it gives you a lot more topological flexibility; instead of having one transformation that positions the children at the screws, and have all the hole related features (standoff, holes, and lateral supports) be children of that one transform, you can distribute your screw features throughout the code. this can be useful if you want the screw holes to drill through not just the standoffs, but also the base plate they're attached to, despite the fact that the base plate is outside the scope of that transform and therefore can't be modified by it. so it would be useful to be able to move one of the screw related features elsewhere in the tree, in this case move the hole geometry up into some outer difference() that contains all the stuff you want it to be able to go through. you can either write your transform (probably some for loops and a translate call) twice, or you define an at_mounting_holes() module, and just invoke that whenever you need to position something at each screw hole, anywhere in your model tree. that way also, if you need to change the screw positioning code later, there's one named and easy to find place where all of it lives. you can also chain together these modules, which can be useful for assemblies. any time you call rotate() or translate() (or a module that applies these transformations to its children), you can think of it as creating a new coordinate system for its children. so, you can make a bunch of parts, each one positioned at the origin, and then use translate() and rotate() to assemble the parts into the final assembly. but instead of just calling rotate and translate, you define a module for each part's assembly position (called to_mypart()), and a second module that performs the inverse transformation (moving it back to the origin, called from_mypart()). then you use these modules to build up a preview of the assembly, and even better, you can use these modules to transfer geometry between different parts' coordinate systems. so if you define a module to position a set of, say, alignment pins on Part A, you call that function within part A's local coordinate system: part_a_at_alignment_pins() cylinder(d=pin_d, h=pin_h) and then on part b, you convert that transform from a Part A's local coordinate system to global coordinates, and then from global coordinates to Part B's local coordinate system: to_part_b() from_part_a() part_a_at_alignment_pins() cylinder(d=pin_d + pin_clearance*2, h=pin_h + clearance) since openscad doesn't have any proper namespacing, if you're making a multi part assembly, you'll need to use a scheme (like prefixes) to make your different parts' module names unique, and you'll probably want to have a separate file per part, so you can protect each part's global variables by importing with "use" (which limits access to just modules and functions, compared to "include" which gives you everything). then in each part file, you have your to_ and from_ modules defined, and a single outer module containing all the geometry of the part, which you then call in the file. you open this file when you want to work on that part in isolation, in its "natural" position, and then you have a separate "assembly" file that just imports all the part modules, and calls to_mypart() mypart(); for each part, and you view that in openscad to preview how it'll all fit together, as well as to have visual feedback as you write those coordinate transforms. (and if you wanna get really fancy, you might end up defining some parts in relation to other parts' origins, rather than the global origin. so if part_b is defined as rotated 45 degrees and 10mm above of part_a, then to_part_b would look like this: module to_part_b() to_part_a() rotate(45) translate([0, 0, 10]) children(); and from_part_b() would just be this in reverse. then if you later decide part_a should attach to the assembly in a totally different place, you modify to_ and from_part_a, and part_b will automatically tag along since it references part_a's origin.
oh also hull() is wonderful in 3d but especially in 2d, to quickly build up complex shapes out of a few primitives. and roof() is... extremely powerful but limited in usefulness as it's still experimental and often broken :(
24:39 another thing that looks encouraging: seeing the lines of code graph not just going up, but also down. freecad has some serious structural problems (like the topological naming problem) that require fundamental changes to the way the app represents objects internally, so it's a good sign that there appears to be a willingness to not just add, but also replace code. (and no you can't fully work around the topological naming problem with good practices, if you wanna see the problem in action, load in a complex step file, make a drawing of it in techdraw, and see what happens when you save, exit, and reload)
