/random/ - random

I have two great breakthroughs to announce.

First, it suddenly occurred to me that I don't have to print onto PCB transfer paper and then transfer that over to the copper clad Pyralux flat flex PCB but instead I can simply tape the copper clad Pyralux flat flex PCB directly onto my envelope and feed that through my laser printer directly. See, I previously ruled this out when originally researching this stuff because I was planning to use FR-4 PCB which is not flexible nor flat enough to feed through a printer directly. However, now that I am using flat and flexible blank PCB there's no reason not to feed it straight into my laser printer that I'm aware of. Now I haven't tested this but if it works it's a game changer. Will make DIY PCBs that much faster and more streamlined to make!

Next, on the subject of attaching the 6 solder wick braids to the mosfets, I was struggling going through the various methods whereby I can tightly clamp it to the mosfet drain and add electrical isolation barrier to the connection point. It's very tight spacing and has to be a very tiny clamping mechanism and the clamp from most directions would have things getting in the way of any clamp design I visualized. It was a nightmare problem IMO. However, my solution I came up with today is game changing: I will simply solder the braids directly to the mosfet drain! This will maximize conductivity off the drain into the braids due to the metal on metal direct connection and eliminate all need for any kind of clamping at all there. Unfortunately, this will make these braids live electrically, but it occurred to me that this is not a big deal. I will simply wrap them in fiberglass window screen to allow them to have great airflow and breath-ability for emissivity of the heat they will be wicking off the mosfet drain and the fiberglass window screen will also act as a physical barrier to them contacting other live metal parts. Window screen is also non-conductive and has good abrasion resistance IMO. I don't anticipate these short wire braid runs to have much contact with anything as they are going to be making short runs from the motor to the water cooling pipe anyways and the exoskeleton mesh that holds up the rubber skin will create spacing and cushion contact bumping or w/e coming from the outside. All in all I think this is a safe solution for the most part and we'll have fuses anyways to prevent major problems in the low risk event of two neighboring live groups of solder wick braid breaking out of their window screen and contacting eachother thereby shorting the circuit. I just see this as highly unlikely but it's covered by the fuse in any case.

That all having been said, the electrical isolation barrier stage we now can place at the location where these solder wick braid ends attach to the copper liquid cooling pipe. There at that attachment point I'll put my electrically isolating thermal tape between the solder wick braid and the pipe and clamp things down by tightly wrapping it in electrical tape at the connection point. This is trivial to achieve compared to doing this at the location of the mosfet drain. So we kicked the electrical isolation and clamping problem further downstream than the mosfet drain connection point in order to make the problem a piece of cake.

Note: chatgpt said I should tin the braided copper solder wick to prevent oxidization of it which would potentially lower its emissivity. Not sure I agree on this though but I may do it just to be safe we'll see. I'd use MG Chemicals Liquid Tin to do this which I already have on hand for tinning circuit boards.

I did some research of some loose ends today on chatgpt and discovered that my .1mm x 4mm x 60mm sections of nickel strip on my bldc motor controllers that run from the battery to the motor controller mosfets and from the mosfets out to the motor are too high in resistance and at 30a they would within a few seconds get so hot that they would desolder my low temperature solder paste. So to solve this I will be placing two side by side solder wick braids hugging the underside of the nickel strips which will lower resistance so much that temperature will stop being an issue. They will be a combined .1mm x 4mm x 60mm. Then on future mosfets for this portion I will just use the solder wick braids for this section and not use nickel strips at all because they add too much resistance under this high of amp flow. The 2430 BLDC motors are rated to 25a continuous so my conduit has to also handle that easily without overheating.

Another really cool discovery I made today was on the topic of measuring current. I'd been putting this off till now but finally got around to deep diving it with chatgpt and discovered something shocking. So basically it was saying to use a shunt resistor inline with the ground side running from the motor controller to the battery. All the current of the motor controller (30a on the high end) will pass through this resistor as its only path. The special thing about a shunt resistor is that its resistance is so low that it doesn't affect voltage or amps a whole lot. I asked chatgpt if I can use nickel strips as my shunt resistor since a smd shunt resistor it said would overheat fast at 30a. It said yes! So I'll be using a .1mm x 4mm x 30mm section of nickel strip as part of my wire run going from the motor controller back to the battery on the ground side. This will act as my homemade shunt resistor. Now the way the arduino will read the amount of current is the analogue input pin will feed into the upstream side (closest to motor controller) of the shunt resistor section of nickel strip and the arduino ground will attach to the downstream side of this nickel strip shunt resistor. It will measure the tiny amount of voltage drop that occurs on account of the shunt resistor's resistance. What is really cool is that the voltage drop changes at this resistance and amp level are read granularly enough by the Arduino analogue input pins that I don't even need to amplify them to read them in meaningfully. Some things like strain gauges provide such tiny resistance changes that you have to use a OP AMP amplifier to be able to read the changes in with your analogue input pin of your arduino to detect them meaningfully but in this case, the resistance changes are large enough and the analogue input pins are granular enough to be able to read them in without any amplification. This means reading in the current for my motor controllers requires ZERO components! It's literally just nickel strip which I already had for the battery tab making and some jumper wire or w/e to take in the readings and that's it! No parts to buy. I had bought some hall effect based current sensor kits and they are not needed at all. I wasted my money on them in the past because I did not know about this shunt resistor option at all at the time. Had I known I would have never bought hall effect based sensor kits - a waste of money. Not to mention they were relatively huge whereas this takes up like practically zero space to measure a shunt resistor section of conduit between the battery and motor controller. So it's awesome news!

Note: the current sensing is meant to tell my control system anytime a new unexpected load has hit the motor so it can slow down the flow rate of electric to the motor to prevent burning out something for example or it can also detect any kind of snags or w/e anything getting stuck. It can also help monitor amp flow for the sake of holding the motor in place with stall current kept low enough to prevent overheating etc. It can also act as collision detection if trying to monitor its interactions with its environment and know if something has hit something - which is insanely useful for situational awareness. So it's extremely useful and basically not even optional frankly. To now know that adding this feature is free and super easy to implement and will take up practically ZERO extra space is very exciting to me.

Note: my diy shunt resistor (.1mm x 4mm x 30mm section of nickel strip) will have a .005 ohm resistance which is pretty much perfect for my use case it seems (unproven but chatgpt sounds sure of it). It will enable me to monitor the range of 5a to 30a and detect a change in amperage with like 1a granularity.

So it hit me that having these braided solder wick wires live all the way to the water cooled pipe distal attachment point is not necessary. And could cause some EMI or noise related issues that is avoidable if I do the following: I can simply cut them off 1/2" from the mosfet, stick thermal tape on one face of the cut off stubs, then stick the rest of the braided solder wick wire run against that thermal tape, then wrap this joint tightly with electrical tape. Finally we then electrically insulate the braided solder wick that is live but leave the braided solder wick section that is now no longer live completely exposed on the duration of its 3"-4" long run from near the mosfet to the water cooled pipe. This way we have electrical isolation near to the mosfet, no antenna effect, no need for window screens now, and no live wires hanging out that aren't properly insulated. Thermal conductivity is reduced negligibly with this solution. This should be trivial to implement as well. It's the perfect solution here and very fast to implement. It may even be slightly less work than dealing with window screens would have been.

Well I tested printing directly onto Pyralux copper and it was a massive failure. Not even one spec of ink stayed on it and the print came out a inch off the location of the copper. Chatgpt said this is because copper can't hold a electro static charge long enough to take ink onto itself or w/e. Ah well I can fall back to the method I already used successfully.

On that note, I realized printing my blue circuit is bad since a black and white printer won't print as densely and darkly a blue thing as it would a black thing so I have to make my circuit black before printing it. Also I should set my dpi to 600 dpi instead of 1200dpi which will create denser thicker prints for better transfer. Also I should select label paper instead of heavy paper which will work better. Also using Lumicolor Straedler pen is not good as it can be undercut easily supposedly. Better to use oil based marker instead. So I ordered that in 0.3mm tip. These are all improvements chatgpt suggested and I plan to use when printing onto the pcb transfer paper and hand touching those up if needed. I'm getting ready to make a bunch of flex pcbs for finishing this motor controller. I already started doing it.

Another disaster happened to me as well: my highside circuit I just soldered the solder wick wire onto, when I was analyzing it closely on the front I noticed that excess solder from the drain side of it oozed and dripped toward the front side of it and attached to the gate pin! I heated up that attachment point from the front side and my capacitor and resistor from gate to source both came off from the heat! Anyways I heated it up to remove that short circuit and used a xacto knife to wedge between the gate pin and back of mosfet's drain pad which had a solder bridge. I got through the bridge successfully but now have to redo the gate to source resistor and capacitor. Ugh! Two steps forward one step back. Then while inspecting and cleaning everything I moved the control circuitry a bit too much and it broke off for the 3rd time! So that has to be done again. This time I'm using flat flex for it. I've had it with the non flat flex variant breaking. The flat flex is way more solid mechanically. So that's a redo needed. Ugh.

Then to top it all off, the solder wick braids recent idea I had to electrically isolate their run near to the mosfet so that they aren't live for very long - which had to do with wanting to eliminate any short circuit risks in their longer run as well as remove any potential for antenna affects - yeah... well after cutting them all in half to do this transition idea, as I was doing it, I realized the surface area where the hand-off takes place between one section of solder wick braid and onto the next seems very small to me (2mm wide by 6mm long) and it seemed to me that the passage of heat across this tiny bridge of thermal tape might be severely compromised and would depend on how tight I made the squeeze of the two pieces of solder wick braid together as well. And I'm not sure I can clamp it tight enough with just tape wrapping it firmly. And if it gets quite hot I'm concerned electrical tape will get gooey and come loose over time and not hold it well. I'm not sure how tight kapton can wrap things I've never used it before so I'm inexperienced with using it and trusting it is hard without experience working with it. This all cumulatively gave me enough doubt that I said heck with it, I'm going to revert to the former plan to just run it live over to the water cooled pipe 3-4" away and use the thermal tape at that junction point where it wraps the pipe. This ensures alot of metal volume is directly tied to the mosfet which means more heat sinking directly with little risk of trapping heat near mosfet - which could happen if my thermal tape junction of copper braid to copper braid were to fail for example by being pulled apart by accident for any reason. Too much risk there IMO. And the risk of a short on account of live wiring it for 3-4" with the live wire sheathed in window screen to emit heat freely but not touch anything I feel is low enough risk IMO. So whatever route I choose has tradeoffs and I feel reverting to my former plan is more robust and foolproof thermally with some minor electrical risks that are mitigated by fuses and careful execution in general. So yeah I had to solder the cut pieces of solder wick braid back together again which was another pain.

Note: the next time I solder the heatsink braids onto the drain I plan to use less solder paste so it doesn't ooze and drop forward onto the front circuitry on the front face of the mosfet by accident. I also plan to insulate the front side's circuitry beforehand so even if solder did ooze that way the insulation barrier would prevent short circuits and make the oozing no big deal in theory.

So yeah it was a tough session but I learned alot from the mistakes etc.

So I did manage to add a pair of braided solder wick wire as a added layer over the nickel strips of the highside mosfet setup and I insulated that with red electrical tape folded over it. I also insulated everything else in sight for the most part. I lost the original control circuit so I made the replacement flat flex pcb style which should be more robust. I also added a yellow 30ga wire for the 20v input line of the gate pin of the main mosfet. I also got my fiberglass window screen mesh ready to be installed to insulate the solder wick wires acting as heatsinks. So this setup is getting close to install ready now but I want to test it again to make sure its still working after all the major changes and messing with it so much.

On another note, I noticed that stacking the 0.1mm x 4mm x 100mm nickel strip plus braided solder wick to reduce resistance and increase conductivity made the lines a bit thicker than I'd like, especially after adding tape. So to resolve this I decided to roll with 0.2mm x 6mm x 100 mm hand cut out strips of pure copper plate. I was not aware of this option before but I was able to find copper in .2mm thickness in a roll on amazon that I can use for this. With this thicker size and the much lower resistance of copper I should be able to run 30a through it with less than 1w of waste heat which is great. And this will still give me a way thinner result than what I used on this first one while lending lower resistance by getting rid of nickel strip entirely for the high amp stuff (aside from the shunt resistor nickel strip which I still plan to keep).

I was randomly talking to chatgpt about how I have been feeling burdened by having to make my own BLDC motor controllers for my robot lately and it randomly mentioned integrated half-bridge power modules as something I could use to cut down on my labor load in making these motor controllers. This immediately stood out to me as something I'd never heard of and something intriguing. I have so far been working on my lowside switch and highside switch which together form a half bridge. Many solder connections have been involved and alot of discrete components are involved. The concept of an integrated half bridge on a single chip - meaning two big power mosfets and all the drive circuitry for those power mosfets all condensed into a single chip would be a huge reduction in size and component count as well. So I researched if any are able to do 8v 30a for my 2430 BLDC motor's needs. Turns out there are some out there. At first I was looking at Texas Instruments CSD95377Q4M Half‑Bridge Driver (30 A) which can do 30a continuous so perfect for me. However, I didn't want to lock myself into a single vendor chip that may one day be discontinued. I prefer something ubiquitous with many competitors making it that can be purchased from aliexpress. Something commodity level. This way I future proof it and don't have to worry about any one manufacturer discontinuing parts I'm using and prices soaring because of that or simply the part becoming unavailable. So after a bit further digging I found CSD95481RWJ QFN chipset on aliexpress sold by several vendors and one was under $1 each. So it is equivalent to two power mosfets plus all drive circuitry for each power mosfet all for under $1. This one also has 60a continuous rating. It is only 5mm x 6mm in size which to me is insane. This is so much smaller than the setup I've been working on yet just as powerful. They are usually used for tiny buck converters and used directly on videocard PCBs and in servers and in automotive PCBs and much more. In any case, using 3 of these half bridge chips you can drive a BLDC motor. The consolidation of so many parts into such a tiny package is truly blowing my mind. So I ordered 60 of these chips - enough to drive 20 BLDC motors. I am leaning toward using these for all my motor controllers if working with them is easier than working with discrete components like I have been. They are cheaper to work with I think - I'd have to run the numbers on that though. They even have built in temp sensing we can read in which is a bonus. Their built in current sensing will not work for BLDC motors so I'll still need my shunt resistor current sensing circuit setup external to it but that's ok. All in all these appear to be a game changer in terms of reducing part count so less potential points of failure and also reducing board footprint so miniaturizing my electronics even more which is very good for us. I'm still needing to work out now how I want to hook these up in terms of PCB making for it and any discrete external components needed to support it. It is also top cooled which is interesting. I'm envisioning using silicone thermal adhesive to glue on a copper pad that has my braided solder wick wires already soldered to it. These will carry the heat away to my water cooled pipe system.

I'm kind of amazed that nobody really seems to use these for BLDC motor controllers. They seem perfect for it. Maybe I'll start a trend. Assuming I don't find out the hard way why they are never used for this application!

note: the full product title: "(5pcs)100% original New CSD95481RWJ 95481RWJ CSD59950RWJ 59950RWJ QFN Chipset"

note: for my previous BLDC motor controller design I was needing to use 6 digital IO pins to drive a single BLDC motor controller's 6 power mosfets by way of their control circuitry. But for a BLDC motor controller design using 3 CSD95481RWJ H-bridge chips, I will only need to use 3 digital IO pins on the microcontroller. These CSD95481RWJ H-bridge chips use a pwm pin that is a tri-state pin - you can have high, low, and floating as the signal you send to it from your microcontroller. Digital output high and low are the usual digital output modes but the floating mode you do in your code by configuring the pin to be a digital input pin which makes it a floating pin. These 3 states fed into the chip makes it either give you V+ as its output or V- as its output or just off/floating as its output. This corresponds perfectly to the normal h-bridge 3 states we'd be using with our discrete components previous microcontroller design. So this savings in total digital I/O pin usage on the microcontroller means you can drive more motors per microcontroller in theory which is pretty cool.

Well I deep dove into the CSD95481RWJ IC route. I estimate it will cut the work in half roughly for every motor controller made and cut the size taken up by about 60% compared to my previous discrete components approach.

Now I will note that I did come across the BTN8982TA which is rated to 40v and can handle 30a continuous 50a peak short burst. But it's TO-263 form factor so about 4 times as big as the CSD95481RWJ. It also costs about $2 each so double the price. It's not a bad option though all things considered but just not quite as good as the CSD95481RWJ for the reasons mentioned. I note it here so I don't forget about it. It can be a great option if the CSD95481RWJ doesn't work out in the end or something.

Anyways, for the thermal concern - which is my biggest concern, I plan to top cool the CSD95481RWJ using a .2mm plate thermal siliconed into place on top of the CSD95481RWJ and then solder a bundle of 4 braided solder wick wires to that and run that off to the water cooled copper pipe about 4" away. The top cooling only handles about 30% of the cooling according to chatgpt. The most important 70% is from the bottom cooling through its pads on its bottom. For this I plan to use double stacked .2mm thick copper plate soldered to its IC pads. So that's .4mm thick. Also it will be around 2mm wide where it attaches to the pads. It will then route out from under the chip and swing upward into free space and head over to the 8v+ and 8v- buses coming from the 8v motor battery banks in the robot's lower torso. These thick copper traces I will fork off of with braided solder wick wire right near the CSD95481RWJ IC chip for thermal conductivity reasons. This braided solder wick wire will be live so I will wrap it in fiberglass window screen so nothing can touch it - preventing short circuits. It will then be electrically isolated from where it connects to the water cooled copper pipe with thermal conductive tape. The braided solder wick wire attaching to these thick copper traces will be a bundle of 4 per trace. The various decoupling capacitors this chip calls for I will connect to its output pins using flat flex PCB DIY hand made. I'll be attaching this PCB first and attaching the thick copper traces to the underside pads second as a separate layer that goes underneath the flat flex PCB layer. The flat flex PCB layer will mostly stay around the outsides of the chip and have its center cut out and removed - the part of it that would get in the way of the underside main pads under the chip. So the flat flex PCB will just hug the outsides of the IC mainly in a U shape around the chip leaving the center of the bottom of the chip free to solder to with my thick copper traces.

Note: the thick copper traces will be cut out with scissors from a roll of .2mm copper sheeting I bought on amazon which I mentioned a few posts back. Double stacking it wil double its thickness and increase its conductivity both electrically and thermally.

Note: in a usual setup with this CSD95481RWJ IC, a multilayer board with a array of vias is used to bring the heat downward off the chip and into another lower layer within the multilayer board where it can then radiate on said layer outward in every direction. In my approach, I use thicker traces than the layers of a multilayer PCB has so I have alot more local copper in play. Then instead of the heat transferring down and then outward in all directions on very thin copper, mine travels down then in a single direction outward away from the IC on that trace. The trace will need to be as wide as possible as soon as possible. I expect to get it from 2mm width - the width of the pad - to 5mm width within a few mm. This rapid transition to a wider width combined with the use of much thicker copper compared to a multilayer PCB's copper thickness of its layers means I should be able to exceed the thermal performance of a multilayer board using my approach. Especially since I also plan to quickly fork off the main traces with bundles of 4 solder wick wire braids that will carry the heat off to a water cooled pipe 4" away.

Note: in my attached schematic I only show a single CSD95481RWJ IC because they are all wired up the exact same way. It's just doing it 3 times for each of the 3 phase wires of the BLDC motor.

Note: I will use a single electrolytic capacitor per motor controller also not pictured in the schematic.

OK, so when I was thinking of using both my discrete components motor controller design parts I already made and then also separately implementing the integrated half bridge IC design going forward, it hit me that the 8v- and arduino gnd tie together on the half bridge IC by necessity but this ruined their intended isolation I needed for my discrete components motor controller design particularly for the lowside switching portion of that schematic. On the lowside switching portion, the little mosfet has 12v- and arduino gnd tied to its source pin. If on the integrated half bridge I also have to tie arduino gnd and 8v-, then that means 12v- and 8v- and arduino gnd are all tied together always.

That completely ruined the necessary isolation between arduino gnd/12v- and 8v- that I had intended to be in place for my lowside switch setup. So that was bug #1 freshly introduced that I would then need to solve for in my discrete components motor controller design. When studying this out on the discrete components motor controller design, another error hit me: when any lowside switch turned on in the design, the 12v- dedicated power supply gnd and the 8v- motor supply gnd become connected as long as that lowside switch is on. Since every lowside switch had always access to 8v gnd on its source pin, then even one moment of 12v gnd and 8v gnd attachment anywhere on the robot would cause every lowside switch in the entire robot to immediately turn on at the same time. So if any turned on, then all turned on. This was a huge oversight. For some reason since I only designed and focused on one half bridge conceptually at a time, I did not consider the effects one half bridge has on its neighboring half bridges. This just never occurred to me. I guess conceptually I envisioned that every half bridge had its own personal 12v ground from its own personal 12v supply that was electrically isolated from the entire rest of the robot. But of course that's not practical even if it is technically possible. So in testing, things did work, but would have failed as soon as I tried to test more than one half bridge at a time. So I caught this bug before testing revealed it.

I discussed this horrible situation with chatgpt and it taught me that in a complex system like a robot, grounds of all your different supply rail voltages cannot be relied on to be isolated from one another like I was treating it. Even if at times they were momentarily, one switch, one change and suddenly they are not and it all becomes a common system ground again. So if I can't safely assume a ground for any given voltage is safely disconnected from the grounds of other voltages, I should not rely on switching on and off access to any particular ground to any of my lowside switches. Instead, I should be shorting the gate driver of the lowside switches to ground to shut them off rather than messing with their source pin's ground connections like I was before. I am to leave the source pin's ground connection as 12v- and its gate connection as 12v+ at all times except when I want to shut it off - at which point I short the gate pin to gnd using my logic level mosfet to do so.

The fix was very straightforward and minor: I just had to add a 100ohm resistor in series with the gate pin of my big power mosfet lowside switch and then reroute my little mosfet a09t drain pin to the big lowside mosfet's gate pin instead of its source pin. The connection to its gate pin must be downstream of that 100 ohm series resistor so that the path from the big mosfet's gate pin has almost zero resistance when traveling through the little mosfet's drain line and over to its source line into ground. This way when you turn on the little mosfet, the big mosfet's internal capacitor quickly empties out, flushing into the path to ground created by the little mosfet and that discharges the big mosfet, shutting it off. When you want it back on, you shut the little mosfet off, which allows the big mosfet's internal capacitor to charge up again, which turns the big mosfet back on. So the setup now acts like a normally on relay.

Note: the resistor on the drain line of the little mosfet that we used to have when it fed into the source line previously is now removed. We want no resistance on there because that would impede the little mosfet's ability to discharge the big mosfet's internal capacitor in a timely manner. We want to be able to not only discharge that capacitor quickly but also direct all incoming current from the 12v+ line that makes it past the 100ohm resistor heading for that big mosfet's gate into our ground path. This rapid redirect flushes so much of that already limited current that hardly any can make it inside the gate of the big mosfet which causes the gate of the big mosfet's voltage to approach near zero volts. So it's called a "pull down" path to ground.

Attached is a photo of my schematic before and after the fix.

Attached is a photo of full updated schematic with the changes in place.

That all having been said, this discrete components original bldc motor controller design, now fixed, is worth keeping archived, but is now basically abandoned now that I have access to the time, money, and space saving shortcut of my integrated half bridge IC based design. It's kind of sad to abandon something I spent so much time on, but who knows, I may still use it if I ever come across a motor that I can't find a cheap half bridge integrated IC for in the future. It's a great schematic to have at the ready for that scenario.

Ok so I was thinking now that each half bridge is just a tiny IC rather than a pair of hefty power mosfets, the space taken up overall by my entire bldc motor controller is going to be about 3cm x 1cm x 2mm which is insanely small for 30a continuous at 8v motor controller! This realization caused me to reconsider whether I even need to treat this as a single motor controller cluster that has to be sat like a horse saddle onto the side of my bldc motor - my original intention for my discrete components original design for my original bldc motor controller. What I realized instead is that things are now so small that I can simply build a half bridge for each phase as a inline element nexted inside the cable run leading to each phase wire of the bldc motor. So instead of having a dedicated spot for each motor controller, I'm going to have just a slight bulge in the phase wire leading out from the bldc motor and that buldge will contain the half bridge that handles that phase wire. All nested inline. This is the easiest way to implement and most streamlined I think. It also means the whole motor controller will just be "floating" in midair, not actually mounted to any motor or anything at all. Just part of the wire harness nested right in there. This is a radical approach IMO. Only made reasonable by the fact we miniaturized the design by such an insane degree.

So the previous version of the schematic was intended to be mounted to the side of the motor like a horse saddle and had an l shape so inputs would come up from bottom and outputs out to left side toward motor phase wires. These L shaped half bridge setups would be stacked next to eachother side by side. In the new variation everything is inline, inputs coming from right and outputs exit out left side to motor.

Here's the updated inline variation of the schematic (no longer L shaped flow like before).

Ok so I realized I don't have to feed in 8v+ from an external wire when I can just pull it from a neighboring pin on the chip that has 8v+ already fed to it from one of the big 8v+ copper traces attached to one of the big 8v+ pads on the underside that connect directly to one of the side pins. That side pin can then be routed to any 8v+ requiring pins if I can find a path for this routing - which I did find. So that is one less external wire input needed - bringing total external input wires needed to 3 instead of 4 as far as the 30ga wires I need to attach. So now all I need for 30ga wire attachments are 5v+ from arduino, GND from arduino, and PWM from arduino. This saves work and simplifies the wiring so its a great improvement.

Oh and I also did the same thing for the 8v- feed, pulling it from a local pad rather than a external wire feed for that.

Also, I have separated out the PCB traces themselves and made them black instead of blue for printing them onto the PCB transfer paper and laminating this onto the blank Pyralux flex PCBs for etching them. I also mirrored it since it prints and laminates backwards onto the PCB.

its a sandnigger death cult

So I ran into some issues trying to make the DIY flex PCB for my integrated half bridge IC chip. This chip has extremely fine 0.4mm pin spacing so the PCB has to be insanely accurate. My previous discrete components BLDC motor controller variant enabled me to create much more crude and less dialed in flex PCBs and things still worked. But with this flex PCB it has to be very dialed in and with very high execution precision. This is no joke. The first issue is that my laser printer does not adhere well to the pcb transfer paper I bought on amazon. It prints on it with some of the toner showing up mirrored a inch or so away from where the print originally lands onto the PCB transfer paper.

This means the ink isn't setting onto the transfer paper enough and is coming off onto the fuser roller or something and that is corrupting the fuser roller. This can destroy my printer's performance over time and cause improper fusing onto all prints going forward even for normal office use which means addresses I print on envelopes are smearing off while in transit and envelopes are being lost in the mail system for me. This is VERY VERY bad. So I had to ditch using this transfer paper.

Thankfully chatgpt recommended using glossy magazine paper and so I gave that a try. I used Psychology Today magazine paper and the print went onto there PERFECTLY. I used 600 dpi setting, heavy as paper type. I prepped my copper flex PCB blank (Pyralux) with 400 grit sandpaper followed by alcohol prep pad wipes. Next, I laminated the glossy magazine paper print onto my copper flex PCB blank (Pyralux) with my laminator a few passes. Next I soaked the magazine and flex PCB sandwich in 110F water for around 30 minutes which turned the glossy magazine paper mushy/pulpy. I then rubbed the paper repeatedly with my fingers working from the outside edges and was able to roll it off gradually and gently. It came off in two layers. It leaves a bit of pulp residue behind on the pads but that is ok it doesn't affect the etching process later you can leave that. And with this method I got the cleanest traces on there EVER.

But when I went to etch this clean PCB with toner in place, things fell apart again. I used room temperature water with my Ammonium Persulfate crystal and water mixture. So it was 68F water. I did not agitate the etchant much. The etching took about 2.5-3 hours! That is horrible etching speed. The larger copper planes took their dear time to evaporate and meanwhile the finer traces had undercutting so bad that the entire copper under the toner etched away and evaporated and the toner came off having nothing to stick to anymore and whose sections were lost. The total etching time is supposed to be no more than 5-15 minutes. 3 hours is totally unacceptable. I found out from chatgpt that the reason it took forever was I failed to heat the etchant to 110-120F and I failed to agitate the mix (stir or vibrate or w/e helps). I also learned from chatgpt that for every 10F increase in temperature of the etchant, the etching time cuts in half. So a increase to 110F will mean the etching time should come down to the 5 minute range pretty likely if I also agitate well. The instructions on the container of etchant crystals said room temperature and no agitation is fine. THEY WERE WRONG for SURE on that.

So to address perfecting the etching process I plan to get a AC hot plate with temperature adjust which I already own - one for like pans or kettles cooking/heating. I also determined that the easiest way to agitate would be to put the etchant and PCB in a small container and create a apparatus that lifts and lowers one side of the container in a rhythmic way so that it rocks the etchant back and forth across the PCB. Below is my simple apparatus design for that. The advantage of this approach is its free if you have the very few parts needed. I can power it with my lab power supply. The n20 gear motor is like $1. Super easy to make. Can handle my 15g of etchant sloshing easily. Simple to make. Does not have anything going INSIDE the acid which would then be spinning and crashing into the PCB and possibly causing issues there. We want just a bear minimum amount of etchant batch per PCB job and so even a spinning stir rod with magnet setup would be hitting the PCB and tossing it around violently etc I didn't want that and didn't want acid on that and having to fish it out and clean it of acid. Prefer nothing going into the acid but the PCB itself. So rocking the whole container makes sense for this and resolves that problem.

The rocker apparatus consists of a n20 gearmotor ($1 on aliexpress), a little wheel (paper and superglue composite wheel), string, a little block to get the motor up higher in placement than the etchant container. As the n20 gearmotor rotates it lifts the string, raising up one end of the etchant container. As it reaches 180 degrees of rotation (6 o'clock) it has lowered the etchant container back down. It repeats this raising and lowering of the container over and over in a cyclic pattern which will cause the etchant solution to slosh back and forth over the PCB improving the rate of the chemical etching reaction and moving copper ions away from the PCB surface being etched more efficiently. No pwm motor controller is needed I don't think since you can change the rock speed by changing voltage setting on the lab power supply and/or changing radius of the wheel that is turning and doing the lifting and lowering action.

If I were going to try and produce micro scale circuits I would look into re-purposing a DVD burner drive, those lasers and drivers are insanely accurate, down to microns and it's like 80% built already, you just need to add a second stepper assembly from another burner and there's your X and Y done, I haven't searched but I bet there's already open source tools to drive them, you could make/modify some cool shit I would think.

So I was randomly watching YouTube recently and saw a George Hotz past broadcast entitled "George Hotz | Programming | Welcome to Gas Town and the future of Computer Use | Agentic AI | Part 1". It kind of shocked me to see this. I was under the impression for some years now that vibecoding was for total noob programmers who were incompetent and horrible coders that were happy to throw together some absolute trash bug filled code with LLM help and call it done. And that were they ever to need to go back and fix the code and remove bugs, it would be more trouble than it was worth due to the horrible code the LLM output. That it would be easier to rewrite it all from scratch at that point than to try to fix its bugs. I'd been watching this space closely though. That was the consensus I thought was at hand. But then this video threw a monkey wrench into that consensus. Here, a world renowned god-tier coder in George Hotz was using agentic AI and saying its the future of coding. Kind of blew my mind. I then deep dove into agentic AI, how agents work, what is the agentic loop, what are agent tools, what are agent skills, what is good vibe coding practice, what are good vs bad vibe coding methodologies, how much does it cost, etc etc. I discovered something called Claude Code and Codex and OpenCode and OpenClaw and people raving about these tools or warning about them and making fun of them. It is a incredibly polarizing topic with people adamantly for and against it all. I even listened to a 11.5 hour long audiobook called Vibe Coding Audiobook by Gene Kim, Steve Yegge. It was a huge deep dive for me.

In the end I drew several conclusions or hypothesis and chose the following stances: I think full blown vibe coding infrastructure low level important lengthy and complex coding projects is not a good idea now and maybe ever. But I think LLM assisted coding can do it. Vibe coding where you don't even really look at the code at all and trust the LLM and agentic AI using the LLM completely is probably only doable for very simple things and will be buggy and ugly code in many ways. Not useful for 99% of my goals. Maybe that can work for front-end web UIs but nothing intensive and low level like computer vision, game engines, AI dev, making an OS, making speech synthesis or speech recognition engines, SLAM, etc etc. It would be horrible for that IMO.

So for my goals, how can I best use LLM assisted coding? Well, my chosen LLM at this time for this is Chatgpt. How will I use it? Well I can use it to co-develop plans and algorithm workflows for modules or sections of code one step at a time. Working through it all. Then once that is done and saved, we can go step by step together writing the code or editing existing code as needed to bring about successful steps one at a time and test it thoroughly as we go. Now in some ways I had already been asking Chatgpt some questions while I code and getting SOME coding help as I code when I used it a few years back as a stack exchange substitute or ask a friend type assistant. At that time I didn't have it producing much code for me though. You can see videos of me coding this way on my YouTube robotics playlist. But I am now planning to take LLM use for coding assistance to a whole other level in a novel way I came up with. So on my IDE of choice, Dev C++ 4.9.9.2, there are no copilot AIs or w/e to code along with you and those are mostly autocomplete AIs anyways - they don't code for you. So that's not what I want. I also don't want to use any other IDEs for various reasons we won't go into here. So what I decided to do is just make my web browser full-screen and stay on the chatgpt chat interface THE WHOLE TIME I am coding. No alt tabbing, no terminal uses, no IDEs. Just stay on chatgpt web browser and that's it. For the most part. That's kind of the aim. So how can I code like this and test the code and whatnot then? Well basically chatgpt and I came up with the idea of creating a program that we called "The Orchestrator" that would run on my PC and read the chat I'm having with chatgpt and read the code that chatgpt writes or wants to change in my codebase and it would then validate that code change request or code snippet addition, make sure it fits our desired formatting and coding style, make sure it doesn't break any rule or screw up anything, possibly query another LLM AI with a submission of that code change and a copy of the surrounding code module it is changing and ask if it will break anything, if it will do what it claims it will do, etc etc etc. And after a extensive series of validation steps, the Orchestrator will either report back that the code was faulty with a reason why it was faulty or it will determine the code was good and passed checks. It will report back via a popup window message and/or possibly optionally text to speech so I hear it talking to me verbally which might be kind of cool. It would populate my clipboard of my mouse and tell me to paste its response into chatgpt. Which I would then do and hit enter to submit the response. Chatgpt would then see what it screwed up and rewrite it after apologizing or w/e. This would rinse repeat until the Orchestrator approved the code. Upon approving it, it would bring up a popup window UI that would act as a IDE containing my codebase file we are editing, the ability to scroll up and down to read my code, etc. It would highlight in green the new code chatgpt was recommending we add within my codebase, giving a green background there. Or if it was a code change chatgpt had written, it would split the screen of that section into two halves. On the left half would be the original code being modified. On the right half would be the changed code proposal with the actual changes highlighted with a red background. I would read both at that point, make any modifications I wanted right there in that window, and hit ok if I approved. So then my job besides co-planning with chatgpt and talking back and forth till I like the plan with the code steps is to read and approve all code changes before they go in and make any final tweaks. Ideally I no longer actually write the code, I just help plan and submit approvals. I have to understand the codebase deeply the whole time, I give all approvals, and I at no point let the LLM just go haywire on my codebase. It's relative to full automation with a local AI agent a slow and methodical process where I retain full understanding and control the whole time. This I feel comfortable with. And this setup I described is my planning coding workflow. It does not have me using the terminal nor an IDE. Its like a custom kind of weird LLM chat and popup windows weird IDE kind of "thing".

Advantages of this approach is much less brainpower needed looking up APIs to find what I want to use or manually typing all code. This also saves on keystrokes which saves my fingers from overworking and prevents any risk of carpal tunnel and whatnot. It should greatly speed up my coding development compared to manual typing especially once all the features I want the Orchestrator to have are all working.

Note: when a new session starts, I will have a big context dump notify chatgpt of its role and of our plans and short-term and long term goals and keyword trigger commands it can give the Orchestrator to get things rolling and have it go out and find files or directory structures etc from the codebase to help chatgpt navigate the codebase. Together with Chatgpt the Orchestrator will give a context snapshot to catch chatgpt up to date on what the code does so far for the module we are working on, what steps were done recently, what next steps are, etc.

Note: as of right now the way chatgpt talks to the Orchestrator is by me manually copying the browser text output of chatgpt. The Orchestrator polls the mouse clipboard to read these text inputs and parses them and acts on them accordingly. But soon I hope to develop a way for the Orchestrator to scrape the DOM of the browser to read the output of chatgpt directly or create a browser extension that outputs that as a file or as a web socket communication to the Orchestrator or perhaps eventually even have the Orchestrator just use computer vision to literally read the pixels of the screen to read what chatgpt is saying and get its input that way just as my own eyes do. Not sure what direction I'm going to go on that front quite yet but that's coming soon I feel. That will make it even easier to use.

Note: unlike most local AI agents that have to use a local LLM (costs alot to have a good one as far as hardware which is super inflated right now as well in cost) or use a cloud LLM API (charge based on tokens used or a monthly subscription - heavy use gets extremely expensive with guys like Yegge saying they are spending like $3k/mth on tokens WOW!), I chose to just use free Chatgpt as my LLM hookup. And that's good enough. But going that route, not using an API, I can't brute force problems as fast or as parallelized as some AI agents are doing but that is fine because I'm not having AI write my entire program and beat its head against a wall trying to fix its own bugs for ages and work through its own spaghetti code making stupid mistakes but eventually after a million tokens are used it finds its way like a blind man reaching around bumping into stuff in the dark, I don't need big brute forcing like those full automated AI agents are doing. So I don't need massive token use and fast calls, etc. Since I am myself co-coding, reading everything, preventing any bad code changes from making it through into my codebase, I don't need the brute forcing stuff then. And my usage can still fall into normal expected use category and not get rate limited or get me banned. I'm still the only one interacting with my mouse and keyboard into chatgpt. All inputs are manually done by a human user. So yeah, with my system, the LLM co-piloting is FREE which is important for me on my tight budget.

So anyways, chatgpt and I developed this system of using this Orchestrator as a 3rd copilot. Chatgpt is my copilot and the Orchestrator is our 3rd copilot. The Orchestrator extends Chatgpt's abilities to leave the browser and do stuff online or with my file system etc as its assistant just like local AI agents do. So it is loosely inspired by the same concept as a local AI agent. I am excited about this tool/workflow. I think it will vastly speed up my overall developer speed while still giving me fine grained control. So the downsides of automated code production associated with vibecoding don't really apply here since I'm not taking myself out of the loop so much like people warn about.

So to make this Orchestrator, chatgpt highly recommended we use Python. I've never coded in Python before and was under the impression its much slower than C/C++ so no good for anything in my robotics projects. However, since this is basically just a sort of weird LLM assisted coding assistant thing we are making, I figured it's probably fine for that use case. So I gave in and downloaded an old version Python that runs on my machine. Within a few days I, with chatgpt's help, got Python installed and working and learned how to use a text file as my Python code which I edit in notepad on windows. I use a .bat file to launch that orchestrator.py file and it launches and works. We've got it polling the clipboard and taking action when valid clipboard changes come in, doing some simple things chatgpt tells it to do successfully. I am also working on implementing a boot sequence thing where chatgpt commands it to run a boot sequence which has it open a window where it asks me to select what coding project I want to work on today from a list we store in a txt file and I press a letter on my keyboard to select a coding project from that list. It then pulls up a .txt context file about that coding project from the Orchestrator directory containing these project specific context files and it puts that file plus a list of trigger keywords and instructions chatgpt can use into the mouse clipboard and tells me to paste in the context. I then paste that in and chatgpt is told to basically use a series of command trigger words and commands to essentially open up my codebase of that particular coding project, explore the files, explore the directory, explore the various sections of code, and find out where we left off and see what the next steps are on the coding to do list for that project if any. If none, it will work with me to create the next steps of a todo list for that code project. We then can start to code it.

So far the orchestrator.py is about 500 lines of Python code. It's all bug free and working great. I took the time to carefully read it all and understand it all and now carefully read and understand every proposed change chatgpt writes for it. Only then do I add it and test it. But eventually, my aim is to have the Orchestrator do the reading of the original code and the proposed changes or additions and validate and filter it before I personally read and approve change or addition requests. The idea there is that my brainpower is limited and I only have so much fuel in the tank mentally for a given session. So the Orchestrator will see if chatgpt is doing something clearly dumb in its code change or addition request and catch that and have me paste the problem back to chatgpt by just bringing a popup window saying "paste this to chatgpt" and I just paste it. No thinking needed. And chatgpt corrects itself and tries again. Only once Orchestrator approves do I get a popup window showing the code change and old code and highlighted changes or updates text for me to read carefully and approve or reject. By taking my brain out of the loop for the dumb mistakes, the Orchestrator shields me from petty code corrections mostly and filters out the obvious dumb LLM mistakes so I don't have to. This saves me frustration and brainpower so I only see the good stuff that makes it through the filter. That makes the system more friction-less and leaves less waste of my time nonsense to deal with so I don't get so frustrated with dumb LLM code outputs. And the idea to possibly send it off to Gemini or w/e with their API free tier usage to verify it if it was a complicated change the Orchestrator wants a second opinion on should be icing on the cake and all of this happens behind the scenes while I wait.

I will say this: for me to get as far as I did with the Orchestrator in just a few days as I did is a marvel for me. I am not that fast but with Chatgpt's guidance I am so much faster. I found a 5.5 hour tutorial on how to install Python, get it going in a IDE, create projects, etc etc and watched some of it and realized I didn't need to do any of that. Chatgpt had me up and running Python in under an hour as someone who never even used it before and we were already having working code within the hour. It was amazing. Super fast for me. Chatgpt still makes dumb mistakes and bad code often, but with the Orchestrator and its guardrails and a tightly designed context window and guidance, plus all the filtration and validation steps, this can be a amazing semi-automated coding workflow.

So that's where I'm at. It's exciting stuff. This doesn't mean I'm stopping the electronics development. I plan to do this stuff in parallel with that so updates will still come on that. But the whole wait to code AT ALL until all electronics are done I just could not stick to anymore. It's been like 3-4 years since I last worked on coding for the robot project and I just couldn't hold off anymore. I think coding some then working on electronics some then coding some is fine. A bit all over the place but so be it. I got caught up in the AI assisted coding hype and just couldn't help myself jumping in and figuring out how I can best use AI to help my coding adventures in a way that fits my needs best. I couldn't wait anymore. PLUS, if I spend many more years NOT coding, I'd start to get somewhat concerned that what I already coded and learned and still remember would start to fade more and more from memory and I'd basically have no clue of what I was trying to do if I wait too long. I wanted to get back into my code before I have no mental architecture skeleton left in memory which would make things harder for me to get back into it. It's a lot of things to keep in my mind for so long without actively spending time in the codebase. So yeah that's my other excuse for why I'm going back into it "prematurely."

Note: my first impressions of Python were very, very good. I was amazed at how much it achieved by so little lines of code. Its 500 lines of code it has so far would have taken like 3,000 lines of C/C++ code I feel. It is crazy. It's very intuitive to use. I already just get it. Although chatgpt is doing the heavy lifting so I'm not actually typing it out myself. But it doesn't matter as long as I understand what it's all doing and how then I can keep its architecture clear and consistent and avoid bugs.

>>151411

cool idea but I feel the laser printer accuracy is enough for my needs

1

Ok so I created what I'm calling the Orchestrator.py, a python code a couple thousand lines long that interfaces with chatgpt, being able to go into my codebase for chatgpt and pull sections of code out and populate my clipboard with that code and ask me to paste it in for chatgpt which I then manually do. Chatgpt outputs commands like list all sections of code in this or that file and if I copy this command, the orchestrator who polls the clipboard goes out and goes into the code file and parses out the code section names and populates the clipboard with it and tells me to paste it in to chatgpt which I then do and then chatgpt is like okay, these 3 code sections we are dealing with for today's project, pull out code section #1 - lists its name and I copy this request into clipboard and orchestrator goes out and pulls that section of code from the codebase, populates it into the clipboard, and tells me to paste this into chatgpt which I manually do. So then chatgpt fully is able to get up to date on the codebase and where we left off. Also backing up a bit, this ALL starts off for a new session in chatgpt with me pasting in a huge context dump about my various projects and the orchestrator.py and the commands it can give the orchestrator.py etc and kind of seeding its context window with what is going on. Then it begins issuing the commands to list sections of code or w/e. Next I have to manually launch the orchestrator.bin file which launches the python code of orchestrator.py which upon opening asks me what code project we are working on this session and gives a window with a list of coding projects we have ongoing. I select from that list the coding project we are doing that session. The orchestrator then takes the coding project I selected and opens up a context txt for that coding project that lists the overall goals of that project, the list of to-dos for it, the most recently completed steps, and where we left off, any constraints, any special notes or rules, any dependencies, any special files or directories the related project files are located in, etc etc. It copies this coding project specific txt extra information into the clipboard and tells me to paste that into chatgpt which I then do manually. So this way chatgpt now has overarching major context dump for all coding projects and then today's coding project specifics for that session. It is now fully equipped to be my coding copilot. The orchestrator saved me just a ton of navigating codebases and files and copy pasting all the time. That is basically its job, to be a bridge for chatgpt and I into the hard drive and the projects. My next plan for making this even more seamless that I have been working on is to make my own diy browser. This browser will then be my interface for chatgpt and will enable my orchestrator.py to tap into what chatgpt is saying to me without me having to copy output text from chatgpt into my clipboard for the orchestrator to see the output of chatgpt. The browser will communicate this output text via some method that the orchestrator.py can read. Haven't decided yet how. I think socket based client server communications tunnel is the normal way two separate programs communicate like this. Although I could just output to a txt file maybe? I have used just changing the title of a window's text as a way to have two programs talk to eachother. Sometimes high speed talking can be too laggy or buggy when talking via .txt file generation and deleting. But there might be workarounds for that. And it depends on rate of communication needs too I think as far as when bugginess kicks in.

So anyways, as far as the diy browser goes, so far it creates a socket, uses OpenSSL, creates the handshake, connects to a web server, creates get requests, downloads that request, parses some of that request, etc. So I've come a long way with it. My first server I'm teaching it to connect to is gmail. So far it will connect to gmail.com and get a 301 redirect to https://mail.google.com/mail > it detects this and it then redirects to that url. That URL then issues a 302 redirect telling the browser to go to https://accounts.google.com/ServiceLogin?service=mail which is the login page for google accounts. That is where I paused for now. So it now needs to detect that 302 redirect request and close the socket and close the secure connection handshake stuff and start a fresh socket and fresh secure connection and connect securely to the account login page.

I chose gmail as a test bed starting point for the browser since one of the things I want the browser to do is act as a very advanced spam filter but more. I want it to actually go into my spam folder and follow custom rules to locate certain specific types of spam and delete it out of the spam filter folder for me. Then when I regularly look through my spam folder for anything that is not spam, I won't have as much regular and obvious complete junk mail in there to sift through to find non-spam. I know you can use a couple popular 3rd party software to interface with browsers with your desktop applications like Selenium and Puppeteer but I prefer not to get locked into any 3rd party ecosystem for this kind of thing and want to DIY this instead for MANY reasons I won't go into here. Suffice to say I've wanted a DIY browser for browser related personal AI assistant related tasks like the spam filter filter of filters thingy I was talking about before as well as many other cool projects related to browser automation and I've wanted to do it from the ground up for years for many reasons. One of which is I simply want a custom browser in GENERAL even for personal use. For various reasons I want this to supplement Chrome and Firefox and Opera and Vivaldi and Supermium etc that I use already for various things.

So anyways building your own browser is a huge job but I think its a great asset for my goals. It will play a key role in my AI for my robot being able to use the internet to do many many things like researching, learning, watching videos, training, etc. I plan to have it be a very minimal diy browser that does bare minimum html parsing and display as well as parsing and displaying Javascript to a smaller degree. It won't be a full JavaScript engine it will just do bear minimum to get the key dynamically loaded content downloaded. I do not even intend for it to display websites as they were intended to be displayed by the website developers. It will just display websites as pure text with most images removed in many cases and it will often run in headless mode which means no graphical interface at all just console outputs only in many cases. It will often be moreso just a bridge between my AI and websites than a proper actual browser that people use with their mouse and keyboard to interface with websites as a human user of websites. But it WILL enable that form of use of the internet and websites as well as a optional use of this browser. So it will be multipurpose. One thing I want for it to be able to do one day is lets say the robot is fixing one of its own pulley systems and notices the ball bearings for pulley system repair are running low on stock. It can go online and order more ball bearings and doesn't even need to ask me first. It would just use my credit card and buy it. And one day ideally it would make its own money online and use its own money to repair itself so it doesn't use my money. I'd let it have its own money for its own maintenance and business ideas although the latter would be limited and need some oversight but could be a cool realm of experimentation that could be fun. So yeah, that is just one of like thousands of potential future uses for it.

Well and since I said this much I'll say a LITTLE more my philosophy and approach behind this custom browser thing. Because I plan to run windows 7 on the robot and use it myself, refusing to upgrade to Windows 10 and GOD FORBID the notoriously and INFAMOUSLY Windows 12 NIGHTMARE that is causing mass exodus of faithful Windows users to Linux in recent times, that really affects my long term planning. By choosing to stay in Windows 7, now all browsers are going out of support and websites one by one are no longer displaying saying I must upgrade my browser. Soon extensions will stop working and all things will start to be unusable one day. So by making my own Windows 7 friendly browser now, I don't EVER have to worry about losing the ability to use Windows 7 as my daily driver. Supermium browser is a legacy windows friendly browser that IS maintained and still works on all websites but is that guaranteed to be maintained 15 or 30 years from now? Not in my opinion. Better to just roll my own now if I plan to stay on Windows 7 forever. My next operating system upgrade may never come or may be Linux or may be my own custom operating system which I already started building. But in the meantime a bare bones custom browser will potentially turn into a great thing for me.

Now alot of the diy web browser progress I mentioned here I did the work on like 4 years ago I think and there's video footage on my youtube of me making it on my youtube channel. I was just continuing where I left off on this project recently is all. Did not get a ton done yet recently but did progress a bit. And I'm HOPING that with chatgpt and the orchestrator.py's help that I can code much faster now on the DIY browser development. We'll see. I think I do code a bit faster with it so far but I am still hoping to improve there.

As far as the robot electronics, I did manage to find my hotplate with temperature control knob and a nice glass vessel I can put on the hotplate with water filling it up half way that I can heat up to 110F or w/e the ideal is for the etching solution I'm using. Then I will put the plastic earplug container I used for etching the little PCBs inside that hot water and do the etching at these higher temps. So I have everything ready for that next step. I did not start making the motorized etchant agitator yet though.

I got together my temperature sensor and my hot plate and my glass container and some water and figured out where on the hotplate temp dial I need to be to get the desired water temperature. I then used label paper sticker and marked it off and wrote 118f on it which is the average temperature of that spot on the dial. It has about 15 degrees variance I think up or down. Good enough.

Next, I mixed up a batch of water and PCB etchant (Ammonium Persulfate crystals and water mixture) using a postal scale to get the ratios right. I mixed it into the bottom third of a wet ones baby wipes container. It was 0.8oz total. Then I submerged the etchant mix into the warm glass basin of heated water to bring it up to temp. I noticed the etchant wet ones container wanted to tip over so I used scotch tape to tape it off in all 4 directions to the glass container and pull it under water a bit too in order to maximize temperature transfer from the hotter outside water into the etchant container contents to warm it efficiently. I skipped the automated agitator entirely opting to just stir the mix with a hot glue stick manually.

All in all, it did etch within the 5 to 8 minutes range and I think etched even faster when the temperature was closer to 130f - closer to 5 minutes then maybe even 4 minutes I didn't time it. It was lightning fast compared to room temperature etchant which took 2-3 hours to etch a single board. So indeed, the instructions that said room temperature is fine were wrong. All that leads to is undercutting.

Anyways, with the stirring and the warm temps my results were significantly improved and almost every board was usable. I produced 8 or 9 in total. Enough to do at least 2 motors and part of a 3rd at least. So plenty for now. I had still a tiny bit of undercutting on the fine traces, but rarely enough to break their continuity. I will make the traces slightly wider in Photoshop for future prints with the expectation that around 15% of the outer edges will be removed so we print wider to compensate and then the result will be the width we wanted in the first place after the undercutting has done its thing. This way the undercutting is worked with and non-detrimental. That's my planned workaround for it.

In the rare instance of pinholes randomly in the center of pads or traces or a tiny open circuit on a thin trace, I am confident that a coating of solder over all of those areas will correct that. These little holes and whatnot are microscopically small so very easy to solder bridge as needed. I think for the most part my boards are almost all fully usable as is. I'm sure my methods will improve as I continue to tweak and iterate techniques over time - but the fact that we can already produce working circuits at this extremely fine detail and miniaturization level is already very encouraging. Any improvements from here is just icing on the cake IMO.

My next step will be to solder on the half bridge IC chips using the method shown in this video - a method I think looks very impressive and sound and hopefully not too hard to replicate on my end: https://www.youtube.com/shorts/r-HaRjBvWgU