Saigonauticon

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.

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?

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.

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.

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_[email protected].

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)

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.

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 /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