I randomly found a 6V6GTA vacuum tube in the rubbish bin of a used book store. They wanted 3$ for it -- how could I not? Visually, it did not have any indication of failure, or any mechanical rattling. So it might actually be functional! They did warn me that they had no idea if this was the case though :) Anyway, I had heard that tubes can be configured to work at much lower that the typical voltages, if you design with them differently. I've seen [as low as 3.3V reported](https://avdweb.nl/tech-tips/electronics/3-3v-vacuum-tube)! I figured it would be fun to make a portable tube amplifier powered by a rechargeable lithium cell. I did not have a tube socket (and was not going to buy a $$$ one from some fancypants audio store), so jury-rigged one from protoboard using a drill press and soldering directly to the tube pins. So far I've tested the heater, it draws an appropriate amount of current (~400mA @ 4.2V). I sort of expected it to explode (implode?), burn out immediately, or otherwise fail spectacularly at this point. So I was unprepared for the apparently normal operation -- I did not have an audio source handy to test it with. That will have to be a story for another day. It's set up as an inverting amplifier, so it might be funny to give it a gain of 1 and subtract the input from the output (e.g. digitally or via a summing amplifier). People say things like "tubes sound warmer" -- I have no idea what this means, so logically I must investigate. The difference between the two signals should give me the sound of *pure warmth*, right? :P

Ask Electronics Saigonauticon • 10 months ago • 93%

So, there are these great 32700 LiFePO4 batteries that showed up in my local industrial market. For like USD 2$! However, there are no LiFePO4 chargers available. The vendors assure me I can "totally use" a 4.2V Li-ion charger, but I don't believe them (although the cells test as being in good shape). I whipped up a 5V system with a buck converter managed by an MCU. It turns off the buck converter that charges the battery, measures the battery voltage, and if it's under 3.6V it enables the buck converter. Repeats every few 100s of milliseconds. Did I overengineer this? Could I have just used a linear voltage regulator that outputs 3.6V (or a Zener), and a current-limited 5v power supply? Charge speed is not really important in my application. Anything under 4 hours is great. Frankly, I'm just trying to phase out the less safe kinds of lithium cell in my lab.

Asklemmy Saigonauticon • 10 months ago • 40%

I've always considered the nature of living to be to grow, to become more -- and the nature of dying to be reduced, to become less. Sort of like taking the derivative of what you are, the rate of change.. This has the unusual consequence that when people tell me to 'live a little' e.g. with idle pastimes, it feels to me like they are asking me to 'die a little'. What do you consider the difference?

First off, yes my oscilloscope screen is dying. It's very old. It's a portable unit I carry around for testing, the good scope stays in my home lab. Anyway, the particle detected here is almost certainly a β⁻ from background radiation or isotopes part of the detector itself. I would expect a muon to have more energy, the detector is not very sensitive to gamma rays at all, and in it's current configuration cannot see alpha particles at all. The case is aluminium, technically 26Al is a β⁺ emitter with a long half live (~700,000 years). However, 26Al generally doesn't form on Earth, that half life is short compared to the age of the Earth, and I didn't buy the case offworld. So while it technically *could* instead be a positron, it's quite unlikely.

I saw this neat particle spectrometer (also works as a detector) published under CERN's open hardware license: https://scoollab.web.cern.ch/diy-particle-detector I used to design these in grad school for fun, but I was making boards by hand in those days, so I didn't have any convenient Gerber files to send off to the local factory. I wanted to add a nuclear/quantum/modern physics component to a STEM course, so thought this would be pretty great! There are a few things I would do differently on the board -- I'd go SMT (especially for capacitor C5), but I get that it's done this way for ease-of-assembly. I'd also maybe increase the trace width on some traces, to make sure the factory ships fewer bad boards. I also moved capacitor C8 to the other side of the board, so the distance between the radiation window and the board would be smaller. All of these things really amount to personal preference, and overall the board is really nicely done! I might redesign the whole thing as SMT later though to reduce size and cost. As configured, this board detects moderately penetrating particle radiation, like beta radiation. I could have configured it to detect alpha particles, but I've already built a few alpha spectrometers, so figured this would be more interesting. The component that handles the actual 'detecting' is the array of 4 PIN photodiodes:  These are a common choice for low cost solid-state particle detectors. Incident radiation causes a tiny voltage on one end of the diode, which is amplified tremendously by the operational amplifier. The extremely high amplification required, means an extremely stable power supply (e.g. a battery) is required, and the entire device should be in a light-proof Faraday cage (e.g. a metal box). I made 2 units, because the minimum order quantity for the boards was 5, and I'm sure I'll think of more than one use for the device. Hopefully I'll be able to detect muon radiation to demonstrate time dilation, beta particles from K-40, and perhaps even detect antimatter via rare K-40 β+ decays. I'll try a banana as an antimatter source first, but a banana doesn't produce very much antimatter (...wow, this is an unusual sentence). Probably I'll need to go order some pure KCl, and even then low detector efficiency and the rarity of that decay mode will be a (possibly insurmountable) challenge.

Size is 5cm x 5cm. Most of the issue was that the capacitor-sized tilt switches were taller than the box -- so I had to order smaller ones from overseas. I certainly wasn't going to do that for just one part, so had to wait until I needed more stuff. Even then, common CR2032 cell holders and the new boards just barely fit in the box. I could have 3D printed a custom box, but this way it's made from ABS and is more durable (my 3D printer uses acrylic which is brittle). I also switched the LED from red to yellow to hopefully be less evil-looking. Red looked OK for the cat, but made the duck look less than sleep-inducing. One side effect is that the battery usage is a little higher, but still enough to last several months of daily use on one CR2032 cell. As long as the battery doesn't leak corrosive goo over the internals, it ought to function for a long, long time.

Taking it down for a couple of weeks. If you message kong_ming they will store your query, but will not reply until the RNG is reconnected in October.

Ask Electronics Saigonauticon • 1 year ago • 100%

Disclaimer: this is not *specifically* for a commercial product, but various things I design sometimes get commercialized. I mention this so that you may decide whether you want to weigh in. If it's commercialized, I will probably make very little money but a bunch of university students may get a neat STEM program in the countryside :D That out of the way, I've designed some boards for a Wi-Fi controlled robot with mechanum wheels. So 4 independent motor drivers, one for each wheel, allow omnidirectional motion. It's built around a Pi Pico W, 4 SOIC-8 9110S motor drivers, and some buck/boost converters to give the system a 5V and 12V line. It's very basic, mostly made to be cheap. Here's a photo:  Right now it just receives UDP communications (a little app written in Godot) and activates the motors in different combinations -- very "hello world". I'm planning to add some autonomy to move around pre-generated maps, solve mazes, and so on. I have foolishly used 2-pin JST connectors for the motors, so using motors with rotary encoders would be a pain without ordering new boards. I'll probably fix that in a later board revision or just hack it in. Also the routing is sloppy and there's no ground plane. It works well enough for development and testing though :D What I'm thinking about right now, is how to let the robot position itself in a room effectively and cheaply. I was thinking of adding either a full LiDAR or building a limited LiDAR out of a servo motor and two cheap laser ToF sensors -- e.g. one pointed forward, the other back, and I can sweep it 90 degrees. Since the LiDAR does not need to be fast or continuously sweep, I am leaning toward the latter approach. Then the processing is handled remotely -- a server requests that the robot do a LiDAR sweep, the robot sends a minimal point cloud back to the server, which estimates the robot's current location and sends back some instructions to move in a direction for some distance -- probably this is where the lack of rotary encoders is going to hurt, but for now I'm planning on just pointing the forward laser ToF sensor towards a target and give the instruction "turn or move forward at static speed X until the sensor reads Y", which should be pretty easy for the MCU To handle. I'm planning to control multiple robots from the same server. The robots don't need to be super fast. What I'm currently wondering is whether my approach really needs rotary encoders in practice -- I've heard that mechanum wheels have high enough mechanical slippage that they end up inaccurate, and designers often add another set of unpowered wheels for position tracking anyway. I don't want to add more wheels in this way though. On the other hand, it would probably be easier to tell the MCU to "move forward X rotary encoder pulses at a velocity defined by Y pulses per second, and then check position and correct at a lower speed" than to use a pure LiDAR approach (e.g. even if rotary encoders don't give me accurate position, on small time scales, they give me good feedback to control speed). I could possibly even send a fairly complex series of instructions in one go, making the communications efficient enough to eliminate a local server and control a ton of robots from a cloud VPS or whatever. Anyone have some experience with encoders + mechanum wheels that can offer a few tips my way? At this stage the project doesn't have clear engineering goals and this is mostly an academic exercise. I've read that using a rigid chassis and minimizing the need for lateral motion can reduce slippage, reading through a few papers didn't get me any numerical indication of what to expect.

The original board was too large. So I redesigned it to be about 12mm x 45mm. I can get a panel of 12 of these for about 3$ and cut out the individual units myself. So that's about 0.25$ per board which is pretty good! The battery holder extends past the board. Not much I can do about that! The light and tilt switch can be soldered directly in, or attached via JST header. There are also 2 spots for a current-limiting resistor for the LED, in case I want it brighter but don't have a 500 ohm 0402 resistor around (closest I usually keep in stock is 1k). Near Q1, there's also a junction that connects the signal out to an optional MOSFET -- designed to control at most 2A of current. In this case, the power supply is not a CR2032, but something else soldered in, and the light is connected between VCC and the extra pad just above the transistor. This way the circuit can be used to make a powerful flashlight as well as a nightlight. One small thing I could have done better -- I designed it as a single sides PCB to save costs. However, the cost different is minimal, and the manufacturer doesn't plate the holes in the board if it's single sided! This makes the connections less mechanically robust, and presents fewer options for how the board can be populated (presently through-hole components can only be populated from the verso). Given the minimal cost savings, future revisions of the board should use double-sided board even if it's unused. Although perhaps I can think of additional features to put there, e.g. a TP4056 lithium battery controller or a spot for a full-size MOSFET. One neat thing! The manufacturer seems to have put a thicker layer of solder mask on this board (as well as on the other unrelated boards I ordered at the same time). This actually really makes them look and feel high-quality. So if any manufacturers out there are listening, it's a bit of a value-add!

So, we started with this:  It arrived looking like this:  And then I populated it by hand:  (on the verso is the tilt switch and the CR2032 holder) Some lessons learned! 1. When putting a current limiting resistor in place for an LED, put space for another in parallel. That way, if you only have one part, you can double the brightness without ordering new parts. 2. Swapping the position of the tilt switch and the LED is possible, this would have made a slightly smaller board. I could also have made it properly 2-layers, but this is more expensive without making it much smaller -- although it does let me place the CR2032 cell more freely on the board, instead of only exactly where it is. 3. I thought I could just solder an LED to the board and bend the leads so it fits into a hole in a case. This turns out not to be a good idea, mainly because the LED is too far from the center of the board, most LED leads are shorter than I remembered, and it can needlessly place strain on the LED leads. This makes the board require a bigger case than it otherwise would have. A better solution would have been to use a JST header and just plug the LED in -- it is worth the small extra cost. Thankfully, I made the pads a little bigger than they needed to be and can implement this by just drilling the holes off-center. The JST header will be on the verso of the board though, which is mildly suboptimal as the cable has to be passed back around the board for most lamp designs. This would still be a big improvement for most lamp designs, as the inconvenience is minor. As much as I tried to think of these things in advance, I guess I can't think of everything! So it was really instructive to go through the experience of getting the boards professionally made, and assembling by hand. Also wow, soldering surface mount is way easier when there's solder mask. It's way easier and cleaner than through hole stuff. It feels practically like cheating.

So I decided to try out a local board manufacturer (thegioiic.com). Their online order form was pretty good (with instant quote), and I could just send them the Gerber files from KiCAD. I optimized this board to be single-sided, and decided to drill the holes myself, as I don't really need vias in this design. The battery, LED, and tilt switch mount from the verso, so the pads are fine as-is without plating the through-holes. The board quality was consistently good overall. A few very minor cosmetic scratches (and I'm being really picky here), but nothing that would affect performance. Also importantly, it cost about 450k VND (20$ USD) for 10 units delivered to my door, pre-cut, tinned, etc. I chose the slowest (and cheapest) service, and the boards arrived exactly 16 days later as promised. The staff communicated via Zalo, but thankfully had very few questions (my Vietnamese is not very good). Mostly they wanted to be absolutely sure that I wanted black color boards, as the price of dying them black had gone up significantly. I took their advice and switched to green :D This board is very simple -- I wanted to see the quality and service level firsthand before trusting them with something more complex or time-sensitive. They've passed the challenge and I'll surely use them again in the future. I'm still not sure if I'll make a minor product out of this board someday. I rather like it, and I think it was neat to try and engineer a product that could last 100 years. So we'll see -- certainly I'll need to factor in ROHS compliance and CE certification. The latter can be expensive, but for something this simple (and that uses no high frequency signals) I can investigate the possibility of self-certifying.

Programmer Humor Saigonauticon • 1 year ago • 95%

You those software projects that have no defined scope, budget, or timeline? Yet somehow land on your desk? For those times, I built a Lemmy bot that does an I Ching divination (https://en.wikibooks.org/wiki/I_Ching) using a hardware random number generator. It doesn't help, but it makes me feel better. If it would make you feel better too, you can use it too by sending a DM to @kong_ming@voltage.vn. The message can't be length zero. You should not consider the messaging secure :D It also may break, bug out, catch on fire, get unplugged, or get overloaded with requests. If none of those things happen, you'll get a response in a couple of minutes. It's also literally build from scrap, and is sitting precariously on the edge of my desk in Vietnam. Still, it's the state-of-the-art in software consulting!

TLDR; if you message the user kong_ming on this instance with a question, it will return a judgement from the Book of Changes, an ancient text used in divination. I like to build hardware random number generators. I had an old prototype lying around that used diode avalanche noise. I've since made it smaller and cheaper, but it was perfectly functional, so I wanted to use it for something. At it's core, it consists of a BJT transistor that I pass current the wrong way through, at a moderate voltage (~16v). A big resistor keeps that current small, but it still happens in spikes whee the time between them has a high entropy. After that, another transistor amplifies the signal, I use a DC blocking capacitor, and then amplify the signal some more using some old CD4069 hex inverters. This gets me a nice square wave of wildly varying period. Next, an MCU has a little routine written in assembly that samples that signal, and measures two time intervals per 3 rising edges of my entropy source. If the intervals are measured as equal, it restarts the process. If the first interval is longer, it records a 1. If the second interval is longer, it records a zero. When 8 recordings are done, it outputs the result out one of the MCU ports, and additionally toggles a pin to indicate that a new random 8-bit value is ready. Next, I had to get that data to the internet. I used an ESP32, with the Adafruit MQTT library. A C++ program accumulates 224 bytes of entropy, and pushes that to an MQTT server. By coincidence, 3 of the I/O pins of the ESP32 were connected to an RGB LED on the development board, so it flashes pretty wild colors:  Next, I converted the entire text of the I Ching to JSON. The I Ching is divided into 64 hexagrams, each with an associated passage of text. Then, there is additional text depending on the "changing line" of your hexagram. Long ago, these were once created by casting yarrow sticks. This created an unusual and unbalanced probability table for the different outcomes. In more modern (but still ancient) times, coin flips were used to determine the hexagram and changing lines -- but this uses a 'balanced' probability table whee the 4 outcomes (yin, yang, changing yin, changing yang) have equal probabilities. I decided to go with the ancient method, the yarrow-stick probabilities. This uses up more entropy (4 bits per hexagram line instead of 3) than the coin-flip method, as the probability table is more complex. Then, I had to determine which changing line is considered. The rules for this are a bit annoying (https://en.wikibooks.org/wiki/I_Ching/The_Moving_Line). Presumably, the ancients did not consider algorithmic elegance an important part of divination. Long story short, regardless of how many changing lines are created, only zero, one, or in rare cases 6 of them can be considered. Finally, I build a lemmy bot in Python that checks for new messages to kong_ming (named after a famous Daoist strategist). It discards messages of length zero, as an I Ching consultation requires that you reflect upon the question at hand. So you should write something about the matter at hand, keeping in mind the messages are not secure -- so be as vague as you want. It will reply to each, as entropy permits. Usually you should get a response within a couple of minutes. There we have it -- ancient wisdom from the I Ching, a hardware random number generator on my desk in Vietnam, assembly language, C++, MQTT, Python, The Fediverse, and finally your eyeballs. Quite a convoluted tech stack! REF: Yi Ching, translated by James Legge (1815 –1897)

Ask Electronics Saigonauticon • 1 year ago • 91%

So I wanted to design a children's toy, where the electronics could last 100 years (ignoring mechanical abuse). I figured some people here might be interested. I settled on a CR2032-powered night light, using an attiny10 microcontroller, where the flash is rated for 100 years unless you're writing to it (which I am not). I did some pretty heavy power optimization. The firmware is hand-optimized assembly. When you turn it upside-down, a tilt switch toggles an LED @ 3mA via a pretty intense debouncing routine. A watchdog timer has it auto power off in 30 minutes. When off, it consumes less than 1 uA. So it has about 25 years of standby time, although the battery is only rated for 10 years (it is replaceable though). If a child uses it every day, then the battery should last about 4.5 months. I made custom boards for it -- I kept is simple with few components as possible (resistor is for scale):  I kept assembly simple. A better design would snap right in to the pins of the CR2032 holder, but that's an addition I'll make another day. I also should have added one more ground pad to solder to, but forgot. Still, an OK result I think.  I used some spay-on lacquer to protect the traces a bit after assembly.

Ask Electronics Saigonauticon • 1 year ago • 100%

What I've done is take a large 2n3055 BJT NPN power transistor, and decap it (it is a large metal-can type). Then I carefully removed any coating from the exposed silicon (it typically has a dab of silicone potting compound on it). Then, I had a weak alpha source at ~5MeV lying around the lab from previous work. This was inserted into the can with the beam facing downward towards the exposed silicon, and the can reattached and made lightproof. Then I threw together the circuit shown here using the modified transistor (the base is left floating). What I expected to happen was that at TP1 (relative to GND), with my scope AC-coupled, I should see small voltage spikes followed by a decay. This is caused by alpha particles impacting the silicon and knocking loose enough electrons to permit some current flow. However, I just see... more or less nothing, maybe some electrical noise from fluorescent lamps in the room next door. Certainly not the spike+decay curve I've seen with other detectors. Did I make a wrong assumption somewhere? It's been a while since I worked with discrete transistors much, and I feel like I am missing something silly. Or is this more or less right, and I should maybe question whether my alpha source is still good? Or whether the signal strength is in a voltage domain I can even clearly see without amplification? Or maybe I should suspect that a thin passivating glass layer is added to big BJTs these days, enough to block the alpha? The source is past expiry, but not by that much. I'm mostly interested in characterizing and documenting the detector as an academic exercise.

Ask Electronics Saigonauticon • 1 year ago • 100%

I've wondered this occasionally over the years, but never got it working. I tried just putting a dried piece of chicken bone pressed between two plates (mild compressive stress perpendicular to the bone), and using an inverter just like I would use a crystal. It did not work. Maybe I need a really thin segment? I have no practical application in mind. I might make a CPU from it for Halloween I guess? I'm not sure if I would classify it as electronics or necromancy, but I thought it was an interesting question to ask here :)

I was hoping that I could leave open registration here for a few days, but apparently there are a ton of lemmy bots. I got 18k within 2 days. So I logged in to my server, and did this: 1. Run docker ps to get the name of the container running postgres. 2. docker exec -it <container name> /bin/bash 3. psql -h localhost -p 5432 -U lemmy -d lemmy 4. The bot users in my case were all users where id>=3 in my case. 5. So I ran DELETE FROM TABLE local_user where id>=3 6. Done To anyone else with this problem, this approach will only work if the bots are within a certain range of user ids. Still, it worked in my very simple case so I'll leave it here. User registration is no longer open. My VPS provider tends to block outbound 485, so until I sort that out, user registration is temporarily closed.

Someone asked me how to make an automated system that measures the threshold voltage on a MOSFET. This is sometimes defined as the voltage where the MOSFET begins to conduct significant current when Vgs=Vds -- and a common definition of 'significant current' is 250uA. I initially thought this was a trivial problem but it actually turns out to be quite interesting. So this post ended up much longer than I thought. With some cleverness, MOSFETs can be used as (cheap) radiation sensors, so this is occasionally an interesting thing to do. With incident ionizing radiation, the threshold voltage of the MOSFET increases. I know microcontrollers better than anything else, so my approach would be to use a microcontroller to incrementally raise the gate+source voltage via an DAC, while using a sense resistor to convert the current conducted through the MOSFET to a measurable voltage (after amplification) by the microcontroller ADC. The MOSFET in question is the IRFP250NPbF, so as usual, we start with the datasheet. This is a power MOSFET, with a threshold voltage of 2-4V. Off the bat, I would not have chosen this MOSFET -- if V(th) increases much higher, it will be out of the range a 5V microcontroller can measure. It would be better to work with a MOSFET with a lower starting V(th) -- but this is what we've got for now. The microcontroller I would use as a student would either be an Arduino, or a Pi Pico W. The former can read out via serial, the latter by serial or Wi-Fi (e.g. throw together a smartphone app or use a laptop). Neither of these microcontrollers has a DAC, so we'll need to implement one. A binary-weighted DAC is probably a good choice, but during prototyping a R/2R DAC (https://www.electronics-tutorials.ws/combination/r-2r-dac.html) is faster to throw together with cheap junk from the side of the road to see if this works (use 1% resistors if you can though). Then if we need more accuracy, we can implement a binary-weighted one. Anyway, the way an R/2R DAC works, is you output a digital value out the port it is connected to. The output voltage will be approximately equal to the value you send out the port, times 5V, divided by 2^(number of GPIO connected to the DAC). So for an 8-pin port, you can send 256 different voltage levels between 0-5V. Both microcontrollers have an integrated ADC, so we can just use that. Building an ADC is a pain anyhow. So far, what we have is something like this:  At this point, we have the ability to apply a controlled voltage to a system, and measure an output voltage -- but we are interested in measuring a current (250uA). So we use a small sense resistor between the MOSFET and ground. The voltage across the sense resistor will be very small, so we will need to buffer and amplify it. A nice dual op-amp like the OPA2132 would be overkill, but easy to use here. So out MOSFET / Analog stage would look something like this:  The input to this is the output of our microcontroller DAC. The output of the above goes into the microcontroller ADC. Note that we connect the source directly to the gate. forcing Vgs=Vds. So all we need to do is slowly increase the input voltage until the output voltage indicates that the current passing through our MOSFET is 250uA. Then the microcontroller would run an algorithm something like this: 1. With output = 0, read the ADC. If it's not close to zero, then your MOSFET is in backward, or something is very wrong. Return an error. 2. Increase the value you output from the DAC by 1. 3. Read the ADC, to see if the voltage is less than the target value. 4. If it's lower than the target, goto 2. Otherwise, output the DAC value out the serial port or WiFi, then set the DAC value to zero and start over. The exact target value is calculated by taking the expected voltage across your sense resistor at 250uA (V=IR), and multiplying by the gain of your amplifier. Do note all of this with a grain of salt. I didn't build or test this circuit, and it's a little out of my expertise :D

I wanted to make a music box as a gift. I'll extend this post with more details as I photograph components. First, what are the design goals? It certainly has to be a box that plays music. That means an MP3 player, a speaker, some buttons for control, a rechargeable battery, and a way to charge the battery. These will have to fit into the box, which should be nice. I also wanted it to have motion -- like the common 'dancing ballerina' you see in music boxes. However, I wanted it to have more than just one, it should have 3! That means it needs at least one motor. I also want the dancing figures to be removable -- so the box can close properly, and so that a variety of dancing figures can be used. Finally, it needs to include elements of Vietnamese culture wherever possible. To this end, I chose the porcelain figures of *dân tộc Việt Nam* (Vietnamese ethnic groups) produced by Minh Long, a local porcelain company:  I also wanted to include the pattern from the Dong Son drum, and the music should of course be Vietnamese instrumentals. Then we get to the specifics. The electronics were pretty easy. I chose a DY-SV5W MP3 player, as the 5W output means I don't need a separate amplifier (and space is limited). The charge controller is a TP4056 based board, with an adjustable output (which I set to 5V). For the battery, I chose a Panasonic 21700 lithium cell, as this allows quite a lot of playback time, and is safer than a pouch cell. For the control switches, I chose small chromed steel industrial switches as they are high-quality and look good. The we get to the mechanical parts -- this is where things get harder. First off, it is a waste of power and (very limited) space to use 3 motors to move 3 figures. So we need clockwork, specifically a set of gears that transmits the (somewhat too fast) motor rotation to a slower turn rate for the 3 figures. It also has to be quiet, so as not to interfere with the motion. So for this I chose a small gear that connects to 3 large gears of equal size. For the teeth I chose a very low pressure angle to make them run quieter at the cost of some efficiency. Then the gears need to somehow rotate the figures. Initially, I though a bar shaped socket that they plug in to would work:  However, testing proved that this was fragile, difficult to use, and risked bits of broken plastic falling into the gears. So instead, to the tops of the gears I attached disc-shaped magnets to act as a magnetic friction drive. The figures have a small steel bolt attached to the bottom (invisible once inserted) that causes them to rotate along with the magnet:  To hold everything in place, I used brass sheets cut to size, separated by brass hex spacers. I chose brass because it has a good aesthetic, and is easy to drill holes in. Though trial and error, I found that the gear spacing needed to have a tolerance of about 0.1mm for each part. Annoying, but not impossible with hand tools. The brass sheet presented an opportunity -- I can etch brass using the same techniques as etching circuit boards. This meant I could include the Dong Son drum pattern on the brass:  This came out well, but left a lot of unused space around the pattern, as the brass place was much longer than it is wide. So I added some traditional Buddhist patterns that are common here. Western audiences should note that the symbol that looks superficially similar to the symbol of a certain terrible regime has a very different meaning here. 

One of the smarter things I did was buy a used DSLR for a bit under 3 mil VND (~135$) to document my work better. I had been using a smartphone camera for years. The thing is, most of the stakeholders I communicate with don't understand at a deep level what I build, so being able to document using photos that look OK is sort of important. So I divide photos into 3 categories that use different strategies. First, there are purely descriptive photos for internal use or for communicating with other engineers. For these, I still use a smartphone in macro mode, and a good ruler:  These don't have to look great, but need to clearly show the parts and something for scale. Next, comes something which mainly to communicate with non-engineers. The message is probably related to size, the state of the project, cost, or function. These photos have to look halfway decent, but there's no specific need for it to provide exact dimensions or part numbers. In this case, I take out the tripod and DSLR. I'll do one of two things -- either use an ancient manual 50mm lens with sharp focus plus lens extender rings, or more commonly, I'll use an ancient manual telemacro lens. The former is better for photographs at very high magnification and narrow depth of field -- when I want to highlight some specific part. The latter is better for medium magnification and deep depth of field, when I want an overall photo. In both cases, pretty long exposure times are required. This is an example of the latter:  And this is an example of the former, with focus on the GPIO capability of the ATMEGA chip:  Finally, in the third case, I want to communicate to a mix of engineers and non-engineers. For this I use a cheap, new telemacro lens with autofocus, and a tripod. I usually set the aperture to enable a large depth of field, rather than a narrow focus. This is so every component is in focus, ideally with part numbers legible. These photos are pretty generic, the type you might see in a user manual. I won't waste space with an example! One thing I found interesting is that ancient lenses outperform newer ones at a given price point -- by a significant margin. My best closeup shots are with lenses from the 1970s which I picked up for a very low price (even in junk heaps). I think I have a Nikon 50mm f/1.4 AI, and a ridiculously heavy all-metal Tamron 60-300mm telemacro. However, they are more complicated to use, so in the 3rd case where I might need a lot of photos and don't want to spend too much time on it, a cheap modern telemacro lens with autofocus works well (I don't even remember the brand, I paid 50$ for it). In summary, I am definitely not a professional photographer. However, spending a few hundred dollars and a little effort learning to use a camera helped me document projects much better, and land more work. Some images have even ended up in the final marketing materials!

This is one of those things that is much more complicated than it looks. You turn it upside down for a short time, and an internal red light toggles. Should be simple, right? Haha, not really -- a practical implementation involves a fair bit of engineering. Tiny engineering! First, the box is 2cm x 3cm x 4cm. The internals are absolutely dominated by a barrel jack connector (not shown). That leaves only a tiny space for a rechargeable battery, charge controller, sensor, control circuit, and a light. The charge controller is a standard TP4056. The sensor is a tilt-switch, sort of like a capacitor shell filled with ball bearings. This is where things get messy -- anyone who has worked with microcontrollers knows about switch debouncing, and tilt switches bounce a lot! So to make the tilt switch work the way a user expects, we need a low microcontroller with a very small footprint. I selected an Attiny10 -- it's about half the size of a grain of rice. This sits in the deepest of sleep modes, with the INT0 pin pulled high. When the tilt switch pulls that pin low, this triggers an interrupt that initiates a fairly long debouncing routine. This is written in hand-optimized assembly, because that's what I know best (so I can knock it out in a couple of hours). Power consumption in standby is measured in nanoamperes. When active, it consumes a few milliamps for the LED (it doesn't need to be that bright). For the battery, it had to be small yet high-quality. So, I selected parts I found lying by the side of the road (a common theme). In this case, it meant a shattered Xiaomi smartwatch donated a small but good quality lithium pouch cell. On standby, the power usage of the device is absolutely dominated by the self-discharge of the battery. In this mode, I estimate it can last around a year. While active, it can last some tens of hours before needing a new charge. The design was intended for children who want a small comforting nightlight. That's why you can turn it on by simply turning it upside-down for a few seconds, instead of fumbling in the dark for a switch or button. One thing I do not like about the design, is it will probably fail after five or so years due to the lithium cell. Children can become very attached to the things that bring them comfort, sometimes treasuring them well into adult life. It would be good to design electronic systems that can accommodate our irrational human attachments. However the limited lifetime of rechargeable batteries make it difficult to design something that lasts this long without making expensive tradeoffs. For example, I could have used replaceable non-rechargeable batteries. These should last for at least 5 years on standby (low self discharge!), but only maybe 30-60 hours of light. So this means a fair amount of battery replacement. One alternative would be low-light solar charging and a pseudocapacitor, but this is extremely sophisticated and difficult to fit in this form factor. Probably the best choice would be replaceable 3V batteries, and adding an auto-off function after 1 hour of light. This would allow for at least a month of use on a coin cell, and as the device does not rely on writing EEPROM or flash, it should endure for many decades. However, a user-accessible battery holder also takes up a fair amount of space, and would require a custom case. Anyway, a surprising amount of engineering goes into making simple things that endure.

I threw this together as a demo for a few bits of technology. It's nothing fancy, but came out well enough -- just a Pi Pico receiving control via UDP, and itself controlling a differential drive via H-bridge. It's all powered by a single lithium cell, which is stepped up to provide 5V and 12V lines (via JST headers for future expansion). This system used to be in Lua on the ESP8266, but I migrated to code to micropython. I also pushed out an Android app in Godot in 20 mins to control it. Godot is pretty great! Unfortunately, the motors are *far* too powerful. Even tapping the controls sends it flying! So I'm going to have to add PWM to control the motor power -- which I'd have to do anyway because no two motors will ever be perfectly balanced. I could also have added a feedback loop with rotary encoders on the motors, but "dumb" manual balancing of the motors is accurate enough for such a simple system. The control protocol is bidirectional, literally just strings converted to bytes, sent via UDP, converted back into strings and split. The robot acts as a Wi-Fi hotspot and so has a known IP (although using UDP broadcast works OK too). I used brass for the construction because I had spare plates lying around. It's easy to cut and drill, durable, reasonably rigid, looks neat, and easily available in Asia (because shrines and placards). One lesson when building any type of robot: separate your design and construction. Never make design decisions on the fly while building! This was always the biggest contributing factor to weird problems in earlier builds. The other lesson is to leave space on your main power and control boards for future expansion -- some JST header sockets on each power line and place to add something similar to the GPIO lines is fine!

Lemmy Be Wholesome Saigonauticon • 1 year ago • 100%

This is a story about something that was entirely unlikely to turn our wholesome, but somehow did. I was digging around the yard a few years ago, when I found some old artillery shells (not usually the start of a good day). One interesting local term for this in Vietnam is 'fruits of democracy', like it's literally a tree that drops fruit! Although these are from WWII, not the American War -- so these were supplied by the US and date to the 1940s from the serial. My concern about unexploded ordnance faded as I realized they had already been completely disarmed, hollowed out, and carefully hammered into flower vases. They were just the brass outside of the shell with nothing inside (the shell of the shell?). Then they had been forgotten for decades and were completely corroded. So I did the only logical thing -- I bought a few liters of hydrochloric acid, donned some goggles and gloves, and cleaned them up! So we have something designed to kill people, being instead transformed into something to hold flowers, and then being forgotten and buried during more conflict. Decades later, it is found, restored, and again holds flowers -- an artillery shell became an unlikely allegory for the enduring idea of peace.

Malicious Compliance Saigonauticon • 1 year ago • 96%

I'm sure someone was complying maliciously here, but I'm not sure who. Everything in the store was on 'sale'. What they do is mark up the price, then discount it back to the normal price. For every single item in the store. So there are hundreds of these little printed standee signs everywhere next to each little thing. Looks like management forgot to define a markup+discount to an item, and a programmer and/or sales staff just abided by the ridiculous 'everything must be on (fake) sale' directive.

Mildly Infuriating Saigonauticon • 1 year ago • 98%

This is sometimes my example for 'why paying attention to documentation is important'. I didn't take the photo myself, a colleague sent it to me years back.

Việt Nam Saigonauticon • 1 year ago • 100%

It's a whip scorpion -- harmlessly sprays acid at you when annoyed. Ok, admittedly that sounds way more alarming than it actually is. The acid is sort of like strong vinegar. They're sometimes called 'vinegaroons', and don't have a poisonous sting.

Malicious Compliance Saigonauticon • 1 year ago • 100%

So I once made the mistake permitting a client to store some (say a dozen) boxes of financial records in my home for a couple of weeks. By 'permit', I mean they just dumped them there, and I didn't physically restrain them from leaving. This is in Vietnam, where you are required by law to keep your corporate records for *35 years*. The government already had a copy of these records, this was the company's copy. It's things like tax invoices, contracts, audits, expenses, and so on -- you hold on to them to protect yourself from incorrect claims. Two weeks turned into over a year, they had accumulated quite a collection of unpaid invoices, and I had halted all work for them long ago. Needless to say, I was not pleased with the boxes all over my house and the lack of responses about it. As you may know, in Vietnam our houses are not so big -- I think mine is under 25 square meters. So this was beyond absurd. Eventually, I was gloriously told "to just do whatever", *in writing*. So rather than go to the dumpster, I sold the boxes of paper to a scrap dealer for VND 10,000 (about USD 0.50 at the time). Not because I'm petty or anything -- it's important to recycle and save the planet, right? Fast forward a couple of years, I see their company license has been revoked -- they failed to pay some tax or other. Probably because they didn't keep any records to work out what taxes to pay... If the director ever steps foot in the country again, newer laws permit the authorities to withhold their passport until taxes are paid -- and the authorities can quote any amount they want, since they have the only copy of the financials :) I see no need to volunteer that particular piece of information. Time makes fools of us all, but some people faster than others.

Việt Nam Saigonauticon • 1 year ago • 100%

Ok, it's taking longer than we'd like... but at least it's not like in the photo anymore! 

I run software company, but my own background is more about hardware, especially embedded systems. I know the industrial markets in HCMC quite well. The parts you may use here as a student, hobbyist, or when developing a commercial prototype are a little different than say, North America. I also have gone through the process of importing electronic components from overseas. So if you're a student or hobbyist in VN and trying to learn something, traveling here and want to buy some parts, or just curious where machines are born, ask away.

Don't be worried that there aren't many posts yet. I check in here and will answer -- maybe others will too, eventually. I immigrated to Vietnam in ~2012, started a software company in HCMC, got married here, etc. So mostly I know this city very well, and also a few things about paperwork, laws, and taxes. Also where to eat, things to avoid, and how to do all the things that tourists do. I can also answer questions about daily life, culture, what the workplace is like, and so on. I read and speak Vietnamese *poorly*. I get by, but don't expect me to translate anything super well. I also know my way around Da Nang, Phan Thiet, Vung Tau, and Hoi An somewhat.