|
ooh thats evil
|
#
?
Jul 4, 2020 02:02
|
|
|
|
| # ? May 31, 2024 20:30 |
|
|
Ambrose Burnside posted:The specific thing that's throwing me here is imagining a "piston" trimcap vs the more usual rotor type, where you have a rod-shaped rotor entering or retracting from a tubular stator. If I'm visualizing things correctly: with a plate rotor sort, yeah, it's clear how the actual overlapping regions are going to be equal no matter what. With a piston design, though, the element with the smaller effective radius will always have a smaller plate area than the larger element, and that imbalance is maintained no matter the rotor position. I think. If so, how do you square it- find the average of the two plate areas? The most accurate answer is that you have to start with basic equations and re-derive the capacitance for the coaxial arrangement instead of the parallel plate arrangement. What happens in practice, though, is that the gap between the piston and sleeve is made intentionally small compared to the radius of the piston or sleeve, meaning that the plate area is roughly the same and the geometry is "close enough" to the parallel plate arrangement that it can be modeled as such. Compare: http://hyperphysics.phy-astr.gsu.edu/hbase/electric/capcyl.html With: http://hyperphysics.phy-astr.gsu.edu/hbase/electric/pplate.html For situations where (b-a)/ln(b/a) is approximately b, these equations are equal. This happens when b and a are close in value and in these situations it doesn't matter which one you use since the difference in their surface areas is going to be much smaller than their surface areas. To provide a concrete example, say the radius of the piston's outer surface is 100mm and the radius of the inner surface of the sleeve is 101mm. 1/ln(101/100) is 100.5, which would be the "effective radius" for modeling as a parallel plate capacitor. This is very close to the average distance, but as the gap gets wider the approximation becomes less valid, 10/ln(110/100) is 104.92. Stack Machine fucked around with this message at 17:34 on Jul 4, 2020 |
|
#
?
Jul 4, 2020 02:46
|
|
|
taqueso posted:ooh thats evil Wouldn't work anymore I don't think, people obsessively document everything with phone pics now
|
|
#
?
Jul 4, 2020 06:41
|
|
|
shovelbum posted:Wouldn't work anymore I don't think, people obsessively document everything with phone pics now Which would, I imagine, be a perfectly valid solution. The point is not to trust yourself that "I'll remember how/why I did this." Also, I definitely don't have much faith that those who had trouble would "obsessively document" anything. At least not before that assignment.
|
|
#
?
Jul 4, 2020 14:01
|
|
|
Stack Machine posted:The most accurate answer is that you have to start with basic equations and re-derive the capacitance for the coaxial arrangement instead of the parallel plate arrangement. What happens in practice, though, is that the gap between the piston and sleeve is made intentionally small compared to the radius of the piston or sleeve, meaning that the plate area is roughly the same and the geometry is "close enough" to the parallel plate arrangement that it can be modeled as such. Neat, thanks. I’ve only ever run into the parallel plate model + formula so I didn’t realize other weirder capacitor geometries have their own derived equations to work from, but in retrospect it makes sense. KnifeWrench posted:I was specifically thinking of code comments as the analog, in fact. oh man lol not electronics, but: those Unambiguously Not-Nice Teachable Moments are either sadistic or incredibly valuable with no middle ground. i trained as a blacksmith under a bunch of old-hand smiths, and one of them set aside an entire week for one task: forge a hook with XYZ features, hooks being one of the first things you learn to make b/c they’re real simple. Now forge 4 more identical hooks. I should not be able to tell that they didn’t come off a pristine assembly line. Make as many hooks as is necessary, but the fewer the better. I thought i was v clever to make up a few jigs for each part feature, but he disqualified any hook that would fit onto any tooling at your bench  it WAS a valuable lesson in developing systems for working precisely and repeatably by hand without any tooling aids, but i’m still a little salty about it
Ambrose Burnside fucked around with this message at 15:09 on Jul 4, 2020 |
|
#
?
Jul 4, 2020 14:18
|
|
|
Ambrose Burnside posted:Neat, thanks. I’ve only ever run into the parallel plate model + formula so I didn’t realize other weirder capacitor geometries have their own derived equations to work from, but in retrospect it makes sense. What you're really talking about in a capacitor is the amount of work needed to move a unit of charge from one plate to another as a function of the amount of charge difference that already exists between the two plates, and all of the models with simple equations make assumptions so this is easy. The cylindrical capacitor link I sent, for example, assumes the cylinder is of infinite length. I had some errors in my algebra earlier so I corrected the earlier post just to avoid confusing anybody reading through the thread. You were right though; the average surface area is a very good approximation in the "piston" design. The following plot is the effective radius with a 100mm piston and 1 to 100mm gap:  And this is the error from using the average radius approximation vs the effective radius. It's never bad; it's only 4% when the outer radius is double the inner radius: 
|
|
#
?
Jul 4, 2020 18:08
|
|
|
Good to know. I half-built a trimcap using just two big spring-loaded plates as per the ancient 20s radio magazine design but it's awkwardly big to do anything with and the napkin math says it isn't going to perform particularly well, so I'm thinking of other approaches I can use that'll make for a more compact and useful trimcap while also being aesthetically-interesting or novel from a fabrication perspective.hence the cylinder-sleeve cap plate questions
Ambrose Burnside fucked around with this message at 01:38 on Jul 5, 2020 |
|
#
?
Jul 4, 2020 18:56
|
|
|
So uh... these Dell DA-2 power supplies are pretty cool. ~$15 for a 12V 220W SMPS. The eGPU guys use them and they're widely available on eBay. Just figured I'd throw this out there cause that's a hell of a price on a quality beefy power supply for someone who needs it.
|
|
#
?
Jul 6, 2020 00:07
|
|
|
Got mine the other day and it runs my old Radeon HD 7970 (technically 250W TDP) just fine, although it probably can't be fully loaded because the connection to the laptop is only a v1.1 PCIe 1x lane.
|
|
#
?
Jul 6, 2020 00:29
|
|
|
Closing the loop on the user-updating firmware thing. Sorted out. Here's the recipe, including build steps for Rust at the beginning (Which would be swapped out for your toolchain as required). No St-Link, custom work, or high-level skills required, and should work for most STM32 chips: Preparing and flashing firmware recipe for STM32 using Rust Board wiring considerations: - USB P and M connections must be made between the USB port, and MCU's USB pins. - Set up the boot0 pin with a button. It should default to pull down using a 510Ω resistor, with the button setting it to pull up using a 10kΩ resistor. Tools to install - Download and install dfu-util (and maybe zadig.exe, which helps the OS recognize the USB device?) - cargo install cargo-binutils - rustup component add llvm-tools-preview - (Note: You can optionally install dfu-tool or ST's DfuSe_demo utility) Build the binary - Run cargo objcopy --release -- -O binary firmware.bin Flash (To be run on the user's computer) - Press and hold the boot0 button to pull the boot0 high while connecting the device to the computer via USB. - (Use zadig.exe to set up USB driver?) - Run .\dfu-util.exe -d 0483:df11 -a 0 -s 0x08000000 -D .\firmware.bin (0483:df11 is the USB vendor ID (0483=ST) and product ID (df11="dfU") for the onboard bootloader, which doesn't change. -a0 means "program the flash memory, not the option bytes") (Note: Alternatively, you can use dfu-tool to convert the .bin file to a .dfu, which you use above in lieu of the .bin file, and ommit the -s command.) Dominoes fucked around with this message at 01:15 on Jul 6, 2020 |
|
#
?
Jul 6, 2020 01:07
|
|
|
That's a pretty big ask for a user. Can you at least try and put the command line stuff into batch files?
|
|
#
?
Jul 6, 2020 01:19
|
|
|
The only thing that needs to be run on the user's computer is .\dfu-util.exe -d 0483:df11 -a 0 -s 0x08000000 -D .\firmware.bin - the rest is for building the binary. (which is also a one-liner once you have the tools installed) Going to wrap that command / executable with something that downloads the firmware, and package it as a downloadable executable. Don't need a ST-link dongle with this this approach - just the same USB port used for power. Tested on dev board, with some modifications to wire boot0 as described above. Dominoes fucked around with this message at 01:26 on Jul 6, 2020 |
|
#
?
Jul 6, 2020 01:22
|
|
|
Even wrapped in an executable I think you’re overestimating the average skill of users, especially aquarium people judging by the intersection of Reefcentral posts and Apex updating. What happens when they pull the USB cable before updating is done? This absolutely will happen and you’ll have to be able to recover from it. I’m not sure how your bootloader is working but it looks like your command is writing a new binary directly over the execution area, which is generally “unsafe” due to the possibility of interrupted or otherwise corrupted transfers. It’s more foolproof to write to a scratch area and make your bootloader able to verify/checksum the uploaded data before writing to the executable region.
|
|
#
?
Jul 6, 2020 01:57
|
|
|
Process should be (Once I've written the program) Download executable for your OS. Run executable. It shows GUI. You click a button to find and download lastest firmware. You click another to flash. ~20s later, it's done. I just tried yanking the cord a few times during the flash process and it still works. (But obv need more testing and a better understanding of what's happening, and what safeguards exists before proceeding with this aproach)
|
|
#
?
Jul 6, 2020 02:08
|
|
|
Memory is cheap. Just get double what you need and flip the address after you update.
|
|
#
?
Jul 6, 2020 02:30
|
|
|
Forseti posted:So uh... these Dell DA-2 power supplies are pretty cool. ~$15 for a 12V 220W SMPS. The eGPU guys use them and they're widely available on eBay. Just figured I'd throw this out there cause that's a hell of a price on a quality beefy power supply for someone who needs it. My favorite will forever be the HP DPS-800GB. 850W @ 110v, 1000W @ 240v and they're usually $35-50. Breakout boards are cheap and readily available. If you want cheaper the HP 80+ are like $15 and are rated for 750W with 92% efficiency. Both are fantastic if you can mitigate the noise or you're building a custom rackmount solution.
|
|
#
?
Jul 6, 2020 03:10
|
|
|
Forseti posted:Memory is cheap. Just get double what you need and flip the address after you update. This. The way I've seen it done: 1) Device has 2x flash so that an entire new firmware image can be sideloaded 2) Update mechanism pushes updated firmware into memory space reserved for update image 3) update mechanism validates that firmware image is complete and valid, then sets a pending update flag somewhere 4) power cycle 5) bootloader checks for pending update, sees it, and uses new firmware, marking previously used area as the new update area This way if your image is corrupted or you pull power or one of a million other things happens, you just keep using the previous firmware and you haven't bricked a device.
|
|
#
?
Jul 6, 2020 03:47
|
|
|
That's using the bootloader ROM in the STM32, it shouldn't be possible to brick it beyond recovery with that method. Loads of other projects package DFU loaders as user updateable firmware, e.g. md380tools, and a ton of Rak Wireless stuff. So there are plenty of scripts available to run that part automatically, and ST provides Windows GUI tools for doing the same thing. I guess it might leave an incomplete firmware image if interrupted - seems like you could solve that on the PC side by doing a verify after flash and telling the user if it worked. longview fucked around with this message at 08:52 on Jul 6, 2020 |
|
#
?
Jul 6, 2020 08:40
|
|
|
I appreciate the details! Almost have the wrapping program done. Leaning towards a sep executable for each firmware version instead of a version manager. Ie you download program. Run program. It tells you to plug the device in while pressing the update button. It flashes and verifies. You delete program. edit: Got it done. Compiles to a ~1mb standalone executable (with Win, Linux, Mac conditional compiling), which includes the firmware, flashing tools, and terminal-based UI which mainly exists to show success/error message. Dominoes fucked around with this message at 22:47 on Jul 6, 2020 |
|
#
?
Jul 6, 2020 20:01
|
|
|
Why am I having such a hard time finding 2.54mm perfboard with a complete copper clad? It's all pad-per-hole and variations on stripboard/etc. There are things that might be what I'm looking for on Digikey/Mouser but naturally it's hard to tell what I'm actually looking at because I'm not cool enough to know what's going on.
|
|
#
?
Jul 6, 2020 23:52
|
|
|
Probably because entirely copper-clad perfboard would mean you were connecting every component to every other one in every possible way, unless you went and painstakingly cut out the traces with a knife or something. (not saying it doesn't exist, idk, but it does seem like a pain in the rear end to use compared to stuff that only has plated holes or is laid out like a breadboard or whatever)
|
|
#
?
Jul 7, 2020 00:19
|
|
|
Wasn’t there a video in this thread of a guy etching out different regions of a copper clad board to make things to hang components off of for prototyping?
|
|
#
?
Jul 7, 2020 00:21
|
|
|
Yeah that's just Manhattan style, but no holes
|
|
#
?
Jul 7, 2020 00:28
|
|
|
babyeatingpsychopath posted:
|
|
#
?
Jul 7, 2020 00:35
|
|
|
Subjunctive posted:Wasn’t there a video in this thread of a guy etching out different regions of a copper clad board to make things to hang components off of for prototyping? Yeah, he also used solid clad perfboard as a ground plane and to ground together separate boards.
|
|
#
?
Jul 7, 2020 00:37
|
|
|
Free 130nm chip fab service for your open source design https://fossi-foundation.org/2020/06/30/skywater-pdk https://github.com/google/skywater-pdk quote:Today, in a FOSSi Dial-Up talk, Tim Ansell of Google announced SkyWater PDK, the first manufacturable, open source process design kit. What differentiates this PDK from previous attempts is the fact that it is manufacturable: with this PDK, you can actually produce chips with the SkyWater foundry in the 130nm node. quote:The SKY130 Process node technology stack consists of; I'm going to make the 666 timer taqueso fucked around with this message at 08:22 on Jul 7, 2020 |
|
#
?
Jul 7, 2020 08:17
|
|
|
taqueso posted:Free 130nm chip fab service for your open source design Its funny to think that this both gets them very good will points among super dedicated electrical engineers AND is hilariously cheaper than recruiting if they were to ever use the list of people who actually make chips to recruit from.
|
|
#
?
Jul 7, 2020 12:24
|
|
|
CarForumPoster posted:Its funny to think that this both gets them very good will points among super dedicated electrical engineers AND is hilariously cheaper than recruiting if they were to ever use the list of people who actually make chips to recruit from. Now Sam Zeloof is going to have people asking him why he doesn't just send his designs to this place to get made
|
|
#
?
Jul 7, 2020 13:44
|
|
|
Wow, that's a pretty big opportunity for hobbyists. I guess not that I have a deep understanding of digital integrated circuits or even have an understanding of the entire process of turning an idea for a digital chip into a working product, but I suspect there is a lot of other expensive stuff after the chip manufacturing. Like, I wonder how the hobbyists are going to test and package their chips. Unless Google is paying for that as well. I didn't watch the Youtube Video link. edit: What is the entire open source chip design software situation? I understand and realize that there are a lot of aspects to and niches in integrated circuit design and there are a lot of different kinds of design software which have different functions. silence_kit fucked around with this message at 14:45 on Jul 7, 2020 |
|
#
?
Jul 7, 2020 14:33
|
|
|
Magic is one of the first open source software projects, from Berkley in the 70s. Not easy though Edit: I also briefly looked at that PDK repo a few days ago, and it just looked like a collection of proven Verilog blocks, no?
|
|
#
?
Jul 7, 2020 16:18
|
|
|
It sounds really cool but it looks like each run is only 40 groups. So if more than 40 people sign up, they pick 40 chips to make. It would be cool if making simple ICs in a DIP package were affordable for hobbyists though.
|
|
#
?
Jul 7, 2020 16:26
|
|
|
I feel like making ASICs is the exact opposite of what hobbyists need. It takes a huge amount of obscure knowledge to do correctly, there's no reasonable way that a hobbyist can test their work, if anything is hosed up once the chips are made there's no way to fix it, and the whole point of using an ASIC instead of an FPGA or something is that it reduces cost in massive production runs. It's conceptually neat that they're doing this but I would be surprised if there are even 40 hobbyists worldwide who can successfully pull it off.
|
|
#
?
Jul 7, 2020 16:37
|
|
|
ante posted:Magic is one of the first open source software projects, from Berkley in the 70s. Not easy though I don't know. I really only have a vague understanding of the digital integrated circuit design process. That's just a mapping of certain canned digital circuit functions to circuit layouts, right? Isn't that at least a good start? I have been told that most digital integrated circuit design is done by describing the function of your circuit in a hardware description language, and there is some software which maps the HDL to a bunch of canned digital circuits and circuit layouts ('standard cells') provided by the foundry service team (or maybe it is the EDA software vendor / other third party)? Then there is software which places the canned digital circuits in the overall circuit layout and maybe mostly automatically connects each canned circuit to each other. I have been told that 'full custom design' of the layout of digital integrated circuits is not often done even on certain sub-portions of the circuit, and most digital designs start at the 'standard cell' abstraction level. Are there open source versions of all of these software functions? silence_kit fucked around with this message at 18:28 on Jul 7, 2020 |
|
#
?
Jul 7, 2020 16:38
|
|
|
Sagebrush posted:It's conceptually neat that they're doing this but I would be surprised if there are even 40 hobbyists worldwide who can successfully pull it off. Yeah, I wonder if we’ll just see it being done by the crowdsupply Big Time DIY crew, or if people will develop libraries of configurable designs so people can mix and match the peripherals/memory/etc they want on-package and get exactly the thing they want for their kickstarter or whatever. Thinking of the sort of thing you get with the Allwinner ARM chips like F1C200 but like ordering a burrito I guess.
|
|
#
?
Jul 7, 2020 16:49
|
|
|
ante posted:Magic is one of the first open source software projects, from Berkley in the 70s. Not easy though Huh, is that what the dude is running in this part of the AT&T UNIX video? I'd been wondering that https://www.youtube.com/watch?v=tc4ROCJYbm0&t=1283s
|
|
#
?
Jul 7, 2020 16:55
|
|
|
I think you still need some very much not free software package to compile the design?
|
|
#
?
Jul 7, 2020 18:26
|
|
|
#1: Super cool #2: I speculate this will have limited practical utility, outside of learning: The general purpose chips we have today are cheap and powerful enough to limit specialty chips to niche roles. Using a popular general-purpose MCU provides the benefit of documentation, guides, and support from a manufacturer that wants you to succeed at building products with their chip, and a potentially large community that understands its processes, has made examples, and can find bugs. You need a strong incentive to eschew these things for a specialty or custom chip.
|
|
#
?
Jul 7, 2020 19:04
|
|
|
Dominoes posted:You need a strong incentive to eschew these things for a specialty or custom chip. And even if you need a specialty or custom chip, there have got to be close to zero situations where a hobbyist -- or even a manufacturer making less than several thousand copies of a product -- can't get away with an FPGA and truly needs custom silicon.
|
|
#
?
Jul 7, 2020 19:12
|
|
|
You're thinking in terms of SoCs and I'd agree with your take in that regard. I'm guessing a modern FPGA can dunk all over a 130nm chip in the digital domain. However, the ability to make a bespoke analog IC opens up a whole new world of cool things. Like, I can't even imagine what people will cook up with this which I'm sure is what Google is getting out of this. https://twitter.com/szeloof/status/1280249239495479297 Edit: And I think this is one of those moments where technology cycles back and an older technique becomes important again because of modern capability and advances on the other side of the coin. I think analog will start seeing some cool advances again because of the AI/sensor space, but right now it's cost prohibitive for people with ideas outside of the norm to experiment with. Forseti fucked around with this message at 19:20 on Jul 7, 2020 |
|
#
?
Jul 7, 2020 19:16
|
|
|
|
| # ? May 31, 2024 20:30 |
|
|
Frankly, regardless of practicality, it is amazing this exists and is a step towards more open hardware.
|
|
#
?
Jul 7, 2020 19:18
|
|