Making local LLM fast

2026-06-10T00:00:00+00:00

I built a tool called Fono. It’s a voice front-end for your computer that can run entirely on your own machine. No cloud, no account, no audio leaving the laptop. It has three jobs, on two hotkeys:

Hold F7 to dictate and cleaned-up text lands in whatever window you were typing in.
Hold F8 to talk to an assistant and it answers various thinkgs. It can also call tools (look at what’s on your screen, and more to come) to actually do things, not just reply.
Give your computer a voice. Coding agents or other tools can speak to you through it.

The first two jobs can lean on a local language model. The problem is that a local model has to think before it speaks, and that feels slow in a way a cloud API running on a rack of GPUs does not. On my laptop, the very first assistant turn was taking almost three seconds before a single word came back. By the sixth turn of a conversation it was closer to seven. That’s death by a thousand milliseconds. It makes the whole thing feel broken even when it’s working perfectly.

This post is the story of getting that first word out in about a third of a second instead. I will explain what actually costs the time, show you the bug I made (it’s a good one) and give you the exact commands to reproduce everything on your own hardware. I don’t do “trust me bro” benchmarks :)

What actually takes the time

When you send a prompt to a local model, the work splits into two very different phases.

Prefill is the model reading your prompt. Every token (every chunk of text) gets pushed through the neural network so the model “understands” the context before it responds.

Decode is the model answering. You watch this happen, word by word.

The number a user feels is the time to first token. That’s the gap between letting go of the hotkey and the first word appearing. (In Fono it’s a bit more complex, but we’ll go with this.) That gap is almost entirely prefill. Decode controls how fast the answer then streams out, but prefill is what makes you sit there wondering if anything is happening.

If you are not careful, a local chat assistant makes you pay prefill over and over. Every turn, the model re-reads the entire conversation so far: the system instructions, every previous question, every previous answer. All that work just to append one new sentence. Turn six pays for turns one through five all over again.

Detour: how prefill and decode stress hardware

Let’s spend 2 minutes on this because I find it very interesting. Prefill and decode bottleneck on different parts of your computer.

Prefill is compute-bound. All the prompt’s tokens can go through the network together, in one big parallel batch of matrix multiplications. That keeps every core and every SIMD lane (the AVX/NEON instructions that do many multiply-adds per clock) busy. More cores and wider vector instructions make prefill faster. This is why the right build of llama.cpp for your CPU matters a little bit.

Decode is memory-bandwidth-bound. To produce one token, the model has to read essentially all of its weights out of RAM. A 4-billion-parameter model at 4 bits is roughly 2-3 GB. Generating 100 tokens means streaming those gigabytes from memory a hundred times over. Your cores spend most of that time waiting for data, not computing. This is the dirty secret of local LLM speed. Decode is usually limited by how fast you can move the model out of RAM, not by raw math. It’s also why quantization (shrinking the weights) speeds decoding up and why fast memory matters.

Of course, there are many caveats here, but let’s keep this lean :)

Two takeaways set up the rest of the post. First, since the latency you feel is dominated by prefill, and prefill cost is “how much prompt do I have to read”, the way to win is to read less prompt. Second, the part of the prompt we re-read every turn is exactly the part that doesn’t change. We shouldn’t be reading it at all.

The trick: stop reading what you already read

The model’s “understanding” of the prompt isn’t thrown away after prefill. It lives in a chunk of memory called the KV cache (key/value cache, the name doesn’t matter here). Think of it as the model’s working memory of everything it has read so far.

The insight that makes local models usable: if the start of this turn’s prompt is identical to last turn’s, the model’s working memory for that part is identical too. So don’t recompute it, reuse it. Snapshot that state and next turn restore the snapshot instead of prefilling from scratch. Restoring is basically a memory copy. In Fono it takes 15-40 milliseconds regardless of size. Prefilling the same content cold can take seconds (the right lane in the animation above). That’s the whole game.

There is one ironclad rule though, and it’s where I shot myself in the foot.

Reuse only works from the front

Cache reuse only works for a prefix that is byte-for-byte identical from the very first token. The moment something changes early in the prompt, every token after it must be recomputed. It’s like a spreadsheet. Change cell A1 and every formula below recalculates.

So the order you put things in completely decides how much you get to reuse. The stuff that never changes (system prompt, tool descriptions) wants to be at the front, forming a stable prefix you cache once and reuse forever. The stuff that changes every turn (the new thing the user just said) goes at the back.

I had it exactly backwards.

The dumb bug

There were several dumb bugs. The model got loaded twice at some point. And other where a bit more complex. I’ll share an easy one so we can laugh together.

Fono now ships with Google’s Gemma as the default local model. Gemma’s prompt format has no dedicated slot for system instructions like some models have, so when I first implemented it I glued the system prompt onto the current user turn:

[ conversation history ]
<start_of_turn>user
{the entire big system prompt + tools}
User request: {what you just said}

Read that with the prefix rule in mind. On turn one it’s fine because there is no history and the system prompt sits at the front. But on turn two, the conversation history slides in front of the system prompt. The big unchanging block is no longer at position zero. The prefix is broken. The cache misses. The model re-reads everything, every single turn.

I built the entire snapshot-and-restore machine and then laid out the prompt so it could basically never fire after the first turn.

The fix

Put the system prompt where it belongs: first.

Now the prompt is append-only. Each turn only adds to the end, and everything before the new line is a byte-for-byte stable prefix. The system prompt is cached once, at startup, and reused on every turn of every conversation. Each turn, the only thing the model actually reads is the new sentence you just spoke. A couple of dozen tokens on top of a restored snapshot.

I wrapped this in regression tests that walk a three-turn conversation and assert each turn’s prompt is an exact string prefix of the next turn’s. If anyone reorders the prompt and breaks the append-only property again, the tests fail loudly. I don’t trust myself to not make this mistake twice.

Then I was caching garbage because the template was off but still, caching worked :)

The two paths, and how they reuse the cache

The append-only layout gives both hotkeys a stable base at the front of the prompt. Fono prefills it once at startup, snapshots it and pins it so it’s never evicted. For F7 (dictation) the base is your cleanup instructions plus a personal dictionary. For F8 (the assistant) it’s the system prompt plus the tool descriptions. Everything else stacks on top.

Play with the buttons below to get an intuitive feel how it works.

F7 fans out. Dictation cares which app you’re in because text for a terminal reads differently than text for a chat box. So each app gets its own snapshot and they all branch off the same pinned base. The first time you dictate into your editor, Fono restores the base, decodes the small editor context on top and saves that branch. Every dictation into the editor after that restores the editor snapshot whole and decodes nothing but your words. What you actually said is never cached. Only the reusable prefix is kept.

F8 builds a chain. The assistant is a conversation, so each turn is stacked on the previous one. Turn one restores the pinned base, decodes your first request and the reply, and saves the result as the turn-one snapshot. Turn two restores turn one and decodes only the new exchange. Nothing earlier in the conversation is ever re-read. The cost of a turn tracks what you just said, not how long you’ve been talking. Conversations expire after five idle minutes, which trims the chain back to the pinned base.

Both shapes use the same two ideas. A pinned base that pays the expensive work only once, and longest-prefix restore: start from the deepest snapshot that still matches and decode only the delta.

The numbers

Same laptop, same model (Gemma 4 E2B, 4-bit quantized), same six-turn conversation. First the headline. Time to first word, turn by turn, with the cache working versus not. The “not” line is exactly what my system-in-the-tail bug produced. The gray line is ollama, which we get to in a bit.

And the same data as a table, with the checkpoint size and the restore time that replaces the growing prefill:

Turn	History	Tokens	Uncached first token	Cached first token	Restore	Checkpoint
1	0	31	786 ms	341 ms	30 ms	0.6 MB
2	2	90	1,917 ms	641 ms	39 ms	1.7 MB
3	4	150	2,468 ms	383 ms	37 ms	2.8 MB
4	6	211	3,321 ms	509 ms	34 ms	3.9 MB
5	8	273	4,367 ms	491 ms	15 ms	5.0 MB
6	10	333	4,892 ms	375 ms	21 ms	6.1 MB

The uncached column climbs as the conversation grows. The cached column stays flat because each turn restores a snapshot (15-40 ms) and only reads your new sentence.

To make the effect impossible to miss, I also swept the size of the cached prefix directly. Imagine an assistant with a big pile of tool definitions in its system prompt. Here is the first-token latency as that prefix grows from tiny to about 3,300 tokens, cold prefill versus cached restore:

Prefix (tool defs)	Prefix tokens	Cold prefill	Cached first token	Checkpoint
none	25	217 ms	114 ms	0.5 MB
5 tools	424	5,143 ms	115 ms	7.8 MB
10 tools	821	10,341 ms	118 ms	15.2 MB
20 tools	1,631	21,077 ms	120 ms	30.1 MB
40 tools	3,251	44,806 ms	133 ms	60.0 MB

Read the last row twice. A cold prefill of a 3,251-token system prompt takes 45 seconds on this modern CPU. The cached restore serves the first token in 133 ms and the cost is a 60 MB snapshot sitting in RAM. A little memory for a lot of saved latency.

This is what makes local tool use feasible in the future. It’s already on the roadmap :)

Keeping it bounded

Trading memory for latency is only a good trade if the memory can’t run away. The scale is smaller than it looks. The KV cache runs about 18 KB per token, so one user-and-assistant exchange adds about a megabyte. The big snapshots come from prefixes, not history. A fat tool-definition block is 60 MB on its own.

Three things keep the cache in check:

Pruning. While a conversation grows, each new checkpoint contains the previous one, so the old one is deleted on the spot. A short conversation sits at one live checkpoint, not one per turn.
A rolling window. Assistant memory is capped at 12 turns within a 5-minute window of activity. Once the window starts sliding, the oldest turn drops off the front, old checkpoints can’t be pruned anymore and they fall under the hard bound below. Go idle for more than 5 minutes and the history is wiped, so the next turn restores just the base. That’s the cheapest case there is.
A hard bound. Everything else (other apps’ dictation contexts, one-off window grabs, leftovers from long conversations) is capped at 8 checkpoints and 256 MB total. When a limit is crossed, the least-recently-used entry is evicted. The pinned bases are never evicted.

One subtlety makes all this deleting safe. Each snapshot is a complete, standalone copy of the model state, not a link to the previous one. The chain is only how a snapshot gets built cheaply. Once saved, it refers to nothing else, so removing one snapshot can never corrupt another. The cost is some redundancy (the base prefix is duplicated inside every snapshot built on top of it) and that is exactly why the byte budget and the pruning exist.

But is it actually faster than ollama?

Here is where I have to be honest, because it’s easy to lie with a chart.

ollama is the popular way to run local models. It’s built on the same engine (llama.cpp) that Fono uses. I imported the exact same model file into ollama and ran the exact same conversation over its local API, feeding its own replies back so its cache worked at its best.

ollama is not naive. It has a server-side prefix cache too and it works. Its prefill stays roughly flat across the conversation instead of climbing. So this isn’t “clever Fono vs. clueless ollama”. It’s a tool tuned for one job vs. a general-purpose server:

Turn	Fono cached first token	ollama first token	ollama prefill
1 (cold)	341 ms	2,649 ms	790 ms
2	641 ms	1,397 ms	1,059 ms
3	383 ms	1,322 ms	973 ms
4	509 ms	1,352 ms	955 ms
5	491 ms	1,317 ms	922 ms
6	375 ms	1,521 ms	1,216 ms

Warm, Fono is roughly 2-4x faster to the first word. On the cold first turn it’s about 8x. Both run the same weights at the same quantization, so the gap is all integration:

Fono runs the model in-process. No HTTP hop to a separate server and no second copy of anything. Restoring a snapshot is a local memory operation.
Fono warms the cache at startup. The system-prompt snapshot is built once when the app launches, while you’re not waiting on anything. Turn one is already as fast as turn six. ollama builds it on the first request, so its first turn is cold.
Fono lays the prompt out for maximum reuse. The whole point of this post.

A fair warning. These are CPU-bound numbers on a laptop, medians of a few passes, and a little noisy. One ollama turn spiked to 5.6s and I took the median to ignore it. This is not a benchmark-suite-grade result. It shows that a tool built for one job can shave the latency that a general server leaves on the table.

Replicate it yourself

I don’t like “trust me bro” benchmarks. Everything above comes out of Fono’s own benchmark binary and a small script against ollama. Here is how to run it.

The machine: an 8-thread CPU, no GPU, 4 GB context. Same gemma-4-e2b GGUF (4-bit) for both engines.

Fono’s side. Build the bench tool with the embedded llama.cpp backend and run the multi-turn conversation benchmark:

cargo build --release -p fono-bench --features llama-local

./target/release/fono-bench assistant-conversation-cache \
  --model-path /path/to/gemma-4-e2b.gguf \
  --turn "turn on the kitchen light" \
  --turn "now dim it to fifty percent" \
  --turn "what's the weather tomorrow morning" \
  --turn "add milk and eggs to my shopping list" \
  --turn "set a timer for ten minutes" \
  --turn "what did I ask you to buy" \
  --ctx-size 4096 --threads 8 --batch-size 4096 \
  --iterations 2 --out conversation-cache.json

It replays the conversation through Fono’s actual prompt builder and for each turn reports the cold prefill, the cached restore and both first-token timings. The prefix-size sweeps are a sibling command:

./target/release/fono-bench assistant-cache-scaling \
  --model-path /path/to/gemma-4-e2b.gguf \
  --dimension tools --sizes 0,5,10,20,40 \
  --ctx-size 4096 --threads 8 --batch-size 4096 --out cache-scaling-tools.json

(One gotcha I hit: set --batch-size at least as large as your biggest prompt, or llama.cpp aborts when a single prefill overflows the logical batch.)

ollama’s side. Import the same GGUF and drive a growing conversation over the local API, feeding the model its own replies back so its prefix cache is maximally effective:

printf 'FROM /path/to/gemma-4-e2b.gguf\n' > Modelfile
ollama create fono-gemma-bench -f Modelfile

Then loop over the turns hitting POST /api/generate with "raw": true and the same system-first, append-only prompt layout Fono emits. Record the wall-clock time to the first streamed token and the server’s reported prompt_eval_duration. The Python script of about 40 lines lives alongside the JSON artifacts. It just builds the append-only prompt, streams the response and records timings.

Point being, same model, same machine, same conversation, both numbers measured the same way. Run it and tell me if your laptop disagrees with mine.

I also did GPU runs and other older CPUs but let’s keep it focused. Maybe at some point I write about how I did 900+ benchmark runs to tune Fono’s first run wizard.

Takeaways

For a local LLM, the latency you feel is prefill, and prefill is the prompt you re-read every turn. Optimize that and everything feels instant.
Cache reuse only works from the front. Put the unchanging stuff (system prompt, tools) first and the new stuff last. Keep the prompt append-only.
Order is an architectural decision. My slowest and fastest paths generated identical text in a different order. One reused everything, one reused nothing.
Know which phase is compute-bound and which is bandwidth-bound. It tells you whether more cores, a better-compiled binary or faster RAM will actually help.
Warm the cache before the user needs it, and remember it costs RAM. Startup is free time, spend it. Bound the cache so it can’t eat the machine.
Test the invariant, not just the output. “Each turn’s prompt is a prefix of the next” is a one-line property that would have caught my bug on day one.

The cache work is committed. Next on the list is making sure the heavy prompt-building never fights the speech-to-text engine for CPU while you’re mid-sentence. That’s a scheduling problem for another post.

If you want to read the actual code, it’s all in the Fono repository. GPL-3.0.

Learning How To Learn

2023-02-20T00:00:00+00:00

If you’re a little bit like me, some subjects could seem too complicated. Other times you’d find it very hard to get started with something and keep procrastinating it. Or you might find yourself very tired to learn something new. And frankly, if we overcome all these we might find it was all in vain and we forgot most of it. Let’s fix this!

It’s mostly a thing of having a well-rested brain, a proper mindset and a proper technique to improve your learning a lot.

As part of my “Learning How to Learn: Powerful mental tools to help you master tough subjects” Coursera class I am writing this post. It’s supposed to be a gift that keeps on giving. It helps me master what I learned by repeating the concepts and it will teach someone else concepts that are supposed to be life-changing.

The big picture

Many of us enjoy exploring new interests and learning new things. I think I always did, except maybe for half my life when I was in school 🙂. The school system in my country favored going for the grades and not for the education so pretty much everybody that learned, did it just before getting tested, we got our grades and then we would forget most of it. I used to think that even though in 19 years the school didn’t teach me much, at least it taught me how to learn. But it seems that is not the case either.

Anyways, this is not about school systems it’s about our personal systems. I often need (for making money) or want (for health, hobbies, the sake of others, etc.) to learn more, faster, better and I find myself accomplishing way less than I think I could accomplish. It’s time to get better at learning before we can get better at other things.

The Mindset

Like many of the other things which follow, it’s essential to have the proper mindset. Knowledge is made by people FOR people. We all start as a blank slate. We learn a HUGE amount of things by the time we grasp reading and basic arithmetic. Let’s not stop learaning, ever!

If you read or listen to interesting things which you’d like to learn but you don’t apply yourself in the direction of learning them, likely that will not happen.

Looking at scientific research tells us that most of us think we’re above average. Let’s use this fallacy to our advantage, believe we can learn everything and increase our chances to become above average.

Sleep

When you’re tired you don’t remember. As the day progresses, the brain accumulates substances that interfere with strengthening neural pathways.

During sleep, the brain clears all the substances which inhibit learning.

I highly recommend reading the Why We Sleep book (ISBN 9781501144318). It presents many other advantages to having proper sleep which will also be good for your learning.

Thinking modes

Our brain has two modes of thinking:

Focused mode thinking
Diffused mode thinking

In focused mode thinking we can point our mind to e narrow subject, just like a searchlight. It helps us understand that specific thing so we can then store it in memory, thus forming a chunk of information. Focused mode thinking uses a lot of mental energy and it’s not sustainable for prolonged periods. Also, when we’re in focused mode our vision is very narrow and often we can’t clearly see the bigger picture.

Diffused mode thinking is a more relaxed way of thinking when we just let our minds wander. We let the thoughts pop into our minds as they please and it’s often a very good source of general problem-solving and creativity. We can stimulate diffuse mode thinking by walking or doing other relaxing activities that don’t grab your focus. During the diffused mode thinking, the chunks we formed in focus mode interact in a relaxed fashion.

Both modes are very important. Thinking works best by alternating between these two.

Memory

Although our memory is very complex, for the sake of grasping the main ideas as quickly as possible we are going to touch a little on the main two branches, short-term memory and long-term memory.

Our short-term memory, often described as working-memory, is handled by our prefrontal cortex and it can only store 4±1 items for just 15-30 seconds, according to Cowan (2001) and Atkinson and Shiffrin (1968). We’re using this memory pretty much for any type of thinking and it’s important to understand its limitations.

This memory is small, easily distracted, and very short-lived. If I am focused on my work and notifications fire on the computer and the phone, they bump items out of my short-term memory. If I actually check out those notifications, the short-term memory gets wiped out and I need to recreate it. This process requires energy and our brain gets tired faster in the process.

When we’re working with chunks of information (pieces that we already have in the long-term memory), they use less space in our working memory. To solve complex problems we first need to develop the necessary chunks.

Long-term memory is VAST. It is comparable to a warehouse where pieces of information stay until they’re needed. Like a warehouse, different areas seem to be used for storing different types of information. Walking, biking and writing are part of our unconscious memory and we call this implicit memory.

Knowledge about factual information, like how you use some software on your computer, is called semantic memory and it’s part of our explicit memory. Semantic memory is subject to fading and we can protect from that through deliberate recall.

Things get into the long-term memory when after the information is manipulated in the short-term memory and then it’s encoded by the hippocampus. Repeating the information activates and strengthens the neural pathways related to that piece of information. If the hippocampus gets damaged you can still retrieve memories but you can’t form new ones. The protagonist of the movie Memento had this problem.

Chunking

As we learn a concept, it becomes a chunk of information and it gets stored in the long-term memory. When we grasp it clearly, this chunk takes only one slot in our working memory.

Our diffused mode thinking interacts with different chunks, sometimes even from different areas of knowledge, to come to a solution for a complex problem.

Spaced repetition

We mentioned before that repeating a piece of information makes it stick. Instead of doing all the work of memorizing in one big session, it’s way more effective to split it across multiple days into much shorter sessions. If you learn the subject at once you’re way more likely to forget it and have a bad day.

This technique of learning was studied multiple times since 1932 and has been proven to increase the rate of learning.

Spaced repetition allows us to be more chill about learning and learn better.

For example, Duolingo, the popular language app employs spaced repetition as the main teaching mechanism. Headway tries to apply this to books. A general-purpose tool for doing spaced repetition is Anki. Let me know if you find something better.

Procrastination

When we think about starting to work on a complex task our brain actually feels pain. Not like skin pain, but brain pain. And it wants to protect itself by changing our attention to something way easier, like surfing on the Internet or talking to other people.

If we get started with our task, the pain goes away very quickly and we can then focus on our task. A notification would break that focus and we’d have to go through that initial pain again. And another problem is that going through this pain uses the limited willpower we have during a day.

There are a few key actions that we can do here:

Start early with the task that would require the most willpower
Minimize notifications so we don’t waste energy on overcoming the pain over and over again
Take deliberate breaks to rest and do diffuse mode thinking
Treat yourself so that you train your brain that at the end of a work session something good is coming

The most well-known technique for fighting procrastination is the Pomodoro method. Its basic principle is that you work for 25 minutes and then take a break for 5 minutes. After two hours you’ve done 4 pomodoros and you can take a 30-minute break.

The Pomodoro method doesn’t really work for me. I need longer than 25 minutes sessions so I will invent the Rădulescu method. 50 minutes of work and 10-20 minutes of break. It’s not yet clear how many of these sessions I would do in a day but I’ll try different things.

Illusion of competence

If you know how to drive a car and you look at F1 races, you might think you could drive an F1 car. This is a well-known cognitive bias called the Dunning-Kruger effect.

When I started to write this blog post about learning how to learn I thought it was going to be quick and easy. I got 100% on my test so to me that looked like I mastered the subject matter. In reality, I am 5 hours into this and still learning.

You can only know for sure you are competent in a subject when you do it yourself. Test yourself!

What next?!

If you feel it’s worth keeping anything out of this I will give you an assignment. Drop me a message with 3 key points which you think will improve your learning the most. This exercise WILL strengthen neural pathways especially if you go over those key points on different days during a week.

Looking forward to your message!

Taking my first photo of the Milky Way

2019-08-03T00:00:00+00:00

While searching for a hobby for my wife I got interested in photography. It seems that I am especially drawn towards low light photography which I understand is what “normal” photographers don’t usually do. I played a little with my phone in low light situations and even though it’s amazing where things are in 2019, it’s still not good enough for what I am looking for.

The gear

Of course, part of the fun is getting the gear so after doing a little bit of research I decided to get the Sony A6000 because “they” say it’s a very capable compact mirrorless camera. I was also considering RX100 and A7 because the first one is way more compact and the second one more capable but bulkier, I feel this one I chose is a good middle ground.

About lenses

My understanding right now is that the glass is the most important thing if you have a decent camera. Also, there is no point in having a very good camera if you don’t have a decent lens because it will probably not make a difference.

There are 4 main properties to consider for lenses and some other less important things:

Focal length
Aperture
Manual or not
Image quality

1. Focal length

Generally speaking, is a measure of that fits into the frame. A small focal length makes wide pictures which fit a lot into the frame and a high focal length number “zooms” a lot bringing the subject closer. The image below should make it the basic concept clear.

The focal length also changes how compressed things appear in the background. In this example, the zoom is done with the legs so the subject is kept in the frame. As you can see, the background changes drastically.

The first lens I got is a versatile 18-200mm which means that I can take both wide and significantly zoomed-in photos.

2. Aperture

The aperture is the opening through which the light enters the camera. Lenses have a variable aperture but we care about the smaller number which represents how much the aperture opens thus allowing more light in.

A lens with a smaller aperture is called a fast lens because more light comes in thus we can expose for a shorter time and catch faster-moving subjects.

Changing the aperture also influences what is kept in focus.

The second lens I got for photographing the stars is an f/2.0, 12mm which should allow for capturing lots of lite and a decent portion of the sky.

3. Manual or not

Manual lenses are just what the name says. They don’t have motors or electronics and can easily be adapted to different camera systems. For setting the focus and aperture they have some ring which you turn. The zoom lenses also have a ring for that.

Normally I would prefer a lens with autofocus but for some applications such as night photography, it doesn’t matter because you set it once and live it like that.

The 18-55mm kit lens of my camera has a lot of “auto” in it. Autofocus, auto-aperture, optical stabilization and even motors for zoom. Of course, all these auto things can be set to manual and configured with buttons from the camera.

I wouldn’t say one is better than the other, it just depends on what you do with it. I like that my 12mm, f/2 lens is manual because to me it means that most of the cost comes from having better glass. And I also like that my “walk-around” lens has a lof of auto because that optical stabilization is a very nice feature when taking pictures zoomed in and handheld.

4. Image quality

Glass is not perfect and physics not on our side when light is bent in complex ways. The science of producing a good lens deals with issues such as distortion, chromatic aberration, vignetting, lens flare and others. To fight these issues lenses use multiple glass elements combined into groups. The issue with this is that the more elements are used the more light is lost due to reflections. The glass can have antireflection coating but I guess you can see why lenses can get expensive.

Distortions are more of an issue with wide-angle lens and chromatic aberrations with faster lens used wide open. Combine that with a high contrast image of stars against the dark void of space and you probably have the least favorable scenario.

The 12mm, f/2 which I got for night photography is supposed to be pretty good quality.

About the camera body

I wanted to get a camera which is affordable, compact and way better than my phone.

It’s a lot to consider when you get the first camera and don’t know what you get into:

Body type: DSLR, mirrorless, point-and-shoot, stick to the phone :)
Sensor size: 1 inch, APS-C, Full Frame
Brands: Canon, Nikon, Sony, Fuji, etc

1. Body type

The main thing I considered here it’s that it’s supposed to be compact and capable. DSLR is too bulky for me and I think it’s just older tech without any real advantage. The point and shoot cameras “feel” too limiting since you can’t change lenses on them, even though RX100 really seems way better than a phone.

2. Sensor size

For the same number of megapixels, a larger sensor has a larger pixel and thus can collect more photons of light. Then the signal to noise ratio is higher and thus the image can be better. This is especially important in low light photography when we need to amplify the signal a lot (set a high ISO) to see the very little available light.

The most recent phones which produce usable images in low light with a very small sensor do a lot of post-processing and what you get is not what the sensor sees. As a fun fact, a sensor in a phone is more than 10x smaller than a sensor in a cheap mirrorless camera.

The most common sensor sizes are full-frame, APS-C, 4/3 and 1 inch. Full-frame cameras are too large for my taste and the lenses are more expensive and they also need to be bigger. I don’t see myself caring these with me. The next best thing is APS-C which looks like something that I’d drag with me on vacations or to the park.

3. Brands

There is a lot of variation here and once you choose a brand you kinda get locked in the ecosystem. Manufacturers usually have their own mount for lenses and while adapters exist it’s not ideal especially for lenses with electronics#### 3. Brands

Sony seems to dominate the mirrorless game so far so I choose the A6000. It looks like their lenses are more expensive and less available than the Nikon lenses but so far I don’t regret my choice. Having almost no experience with other cameras I have nothing to complain :)

Preparing to photograph the stars

In this case, I need to find a very dark place on a very dark day with clear skies.

The very dark day was 1st August 2019 when it was a new moon which means the moon was completely in the shadow. We have one of these every month. I was quite lucky the first one had clear skies and that I didn’t have something else to do.

The very dark place can be found looking at a light pollution map like lightpollutionmap.info. I live in Bucharest so I can find some very dark places ~100km away.

I’ve ended up ~70km away because I thought it was dark enough and very convenient. The next day I found out that I was in a class 4 zone on the Bortle scale. If I’ve driven for an hour more I certainly could have reached a darker place (class 3).

Once you have the day, the place and the weather, all you have to do is put the camera on a tripod and make these settings on the camera:

exposure: for my 12mm lens, the exposure is supposed to be 27 seconds to avoid star trails. I’ve set it to 30” because the other option on my camera was 20” and that was too little.
aperture: opened it all the way to f/2
ISO: I experimented between 1600-3200. I feel like 3200 was a bit too much but the picture I’m going to share was shot with ISO 3200 and then the exposure was taken down in lightroom because I liked it more from the bunch.

The result

What next?!

I realize it can be better in various ways, but to be honest I’m satisfied with this first attempt. If there is going to be the next time, I want to go to a place with even less light pollution, try to make a timelapse and learn how to actually edit these. Also, I could experiment with stacking and if I find something interesting to put in the frame also experiment with light painting.

How to give access on AWS to a consultant

2019-04-03T00:00:00+00:00

I am a DevOps consultant so I have access to a bunch of AWS accounts, in addition to my own. If I was to use individual credentials for each account, it would be very inconvenient especially since I have to switch between accounts multiple times a day. For a while now, AWS has a nice feature which allows me to access multiple accounts from my own AWS account. This feature is called Roles.

The official documentation for this is easily available but maybe not so easy to understand by everybody.

This guide is intended to be the most straightforward way of giving access to a person who uses more than one AWS account.

Setting up a role for access from another account

Go to IAM -> Roles and click Create role. Ask for the account ID.
Go through each step one by one and select the appropriate permissions.
Cases matter. I use Bogdan every time so it’s easy to remember.
Click Create role and if you’re only in charge of giving access your job is done.

Using this new role in your main account

Click your account name from the top right corner and find the Switch Role button.
Fill in all the info.
Enjoy this faster way of switching AWS accounts.

There is a limitation though to a maximum of 5 accounts but if you just learned about this I am sure you can live with this limitation :)

Conclusion

This is a nice time-saving feature which facilitates using multiple AWS accounts. AWS was somewhat late in the game with this feature. Others from my toolbox that support something similar are CloudFlare, GoDaddy and obviously Google.

Internationalized domain names ...in Linux

2018-08-01T00:00:00+00:00

The Internet was made for Latin script, more specifically a-z, 0-9 and a hyphen. Of course, I’m talking about Internet addresses, which is exactly how you reach content online. The problem is that around 2 billion people actually use Chinese, Arabic, Devanagari, Cyrillic and other writing systems. Even the French, Germans and Romanians have non-latin characters so let’s see how those are handled online.

I got the domain ă.cc. How can I use it?

Some background info

The DNS, which is the system that helps us get around online using names instead of IP addresses is restricted to only ASCII characters. It makes sense to me because:

The Americans who invented DNS can’t really be blamed that they didn’t think of characters they didn’t understand.
Coordinating the update of many servers on the Internet to support some major new feature is not reasonable.
Adding UTF-8 could be a huge liability. It has some strange characters such as blank and go back one character. This would open interesting possibilities.

Nevertheless, in 1996 a guy from Zurich felt that we need domains with all types of characters so he wrote a draft. People implemented, debated and more than a decade later, in 2009 ICANN brought the languages of the world to the global Internet.

Internationalized domain names (IDNs for short) are domain names which use non-ASCII characters and could be helpful to more than 30% of the world population.

But all this time DNS didn’t change, so how does this work?!

At some point, some guy proposed a standard for converting any character (Unicode) into ASCII. This is called Punycode. For my domain, ă.cc, Punycode looks like xn--0da.cc. The character ă is actually 0da. xn-- tells applications this is Punycode.

So, IDNs are implemented at the application level. Internet Explorer started to support this late 2006 and others a little bit earlier but it seems that 12 years later, support is poor in pretty much any other basic tool.

The Linux situation

SSH, traceroute and many others don’t support IDNs.
The browsers, nslookup and dig are OK.

The thing that handles resolving domain names in Linux is glibc, which has some resolver code copied mostly from BIND. BIND is that DNS server which we talked about in the beginning, that only supports ASCII.
Pretty much all programs link against glibc and when they need to resolve some address, glibc handles it for them.
There is a library in Linux, called libidn, which handles the conversion to Punycode.

nimblex:~# ldd /usr/bin/nslookup 
 linux-vdso.so.1 (0x00007ffc3dde8000)
 libedit.so.0 => /usr/lib64/libedit.so.0 (0x00007fed5f979000)
 libdns.so.1100 => /usr/lib64/libdns.so.1100 (0x00007fed5f551000)
 liblwres.so.160 => /usr/lib64/liblwres.so.160 (0x00007fed5f33e000)
 libbind9.so.160 => /usr/lib64/libbind9.so.160 (0x00007fed5f12d000)
 libisccfg.so.160 => /usr/lib64/libisccfg.so.160 (0x00007fed5ef01000)
 libisc.so.169 => /usr/lib64/libisc.so.169 (0x00007fed5ec89000)
 libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fed5e802000)
 libcap.so.2 => /lib64/libcap.so.2 (0x00007fed5e5fd000)
 libjson-c.so.4 => /usr/lib64/libjson-c.so.4 (0x00007fed5e3ee000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fed5e1cf000)
 libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007fed5de6a000)
 libz.so.1 => /lib64/libz.so.1 (0x00007fed5dc53000)
 liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fed5da2d000)
 libm.so.6 => /lib64/libm.so.6 (0x00007fed5d692000)
 libdl.so.2 => /lib64/libdl.so.2 (0x00007fed5d48e000)
 libidn.so.12 => /usr/lib64/libidn.so.12 (0x00007fed5d25a000)
 libc.so.6 => /lib64/libc.so.6 (0x00007fed5ce70000)
 libncurses.so.6 => /lib64/libncurses.so.6 (0x00007fed5cc46000)
 libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fed5ca1a000)
 /lib64/ld-linux-x86-64.so.2 (0x00007fed5fbb1000)

nslookup links against libidn and that’s why it can resolve my domain; ă.cc

Now a few things come to mind:

link glibc against libidn to support resolving internationalized domains names. Well, this is stupid because glibc is primordial. libidn links to it, not the other way around.

nimblex:~# ldd /usr/lib64/libidn.so.12
  linux-vdso.so.1 (0x00007ffe1cbdc000)
  libc.so.6 => /lib64/libc.so.6 (0x00007fc7f9785000)
  /lib64/ld-linux-x86-64.so.2 (0x00007fc7f9da3000)

merge glibc and libidn. It seems this was done before ICAN made their grand announcement, almost a decade ago, but then abandoned.
link tools like ping, ssh and others against libidn.
- it looks like for ping, libidn was encouraged since 2015 but many distros don’t support it yet. Still, I’m sure ping will support IDNs in most distros soon.
- for ssh the territory is virgin.

Conclusion

In 2018 we have AI which recognizes my face better than my family but most tools don’t work with domains such as рнидс.срб. It seems seriously limiting and I don’t like that. I guess I will start bothering some people about this.

Pedal car electric conversion - preparation

2018-06-26T00:00:00+00:00

I did an impulse buy and got a Baghera Legend Red for my son and I decided to convert it from clean and boring pedal power to dirty and fun electric power. In this first part, I will do calculations and planning so I don’t order too many useless parts.

The motor

Of course, it all starts with the motor. It needs to be:

cheap (it’s a pedal car conversion)
fairly small and light
powerful enough to move 20Kg

At ~24V there is a good selection of motors which would do it for this application. Electric scooter motors start at 250W so I guess I want something that handles 30-150W.

With motors I don’t think it’s proper to rate them only by voltage, current and power because you’re putting electricity through a wire/coil which creates a magnetic field that makes the motor turn. If the motor draws more current then it heats up and the wire insulation could be damaged. Usually, motors draw more current when they are loaded so I consider the rating loosely and I’d keep an eye on the temperature.

I have no problem getting a motor rated for 30W nominal and run it at 100W for a minute or so. It would only shorten the life of the motor slightly and it would provide the bursts of acceleration which are all the fun.

I got a good deal on this motor which is going to work just fine at 50-100W. This one has a nice diagram showing the specs. Most of the cheaper ones don’t.

The battery pack

Once we have a general idea about our motor size we can think about the battery pack. We don’t really have real-life numbers with it but again, we make some assumptions.

The battery pack needs to satisfy 3 things:

voltage ~24V. This will allow us to reach higher speeds but also to extract power from the motor.
current handling >5A. To run our motor at 100W. We need this to accelerate faster or to go uphill.
capacity >50Wh. To get a decent play time.

It could be as easy as 2x12V 7Ah UPS batteries. Both are less than 30$ new around here. The main disadvantage is that they weigh 4KG. Other than that these would be good because they have excellent current handling capability. One disadvantage though is that SLA batteries have this capacity if they are discharged at a very low rate, in 10-20 hours. If we discharge the SLA battery in 1 hour it’s capacity would be closer to 2/3 of what it says on the tin. Smaller capacity UPS batteries cost a little more because they’re not that common and weight just a little less.

Li-Ion has a better energy density (smaller & lighter) but the pack would be more expensive. One cell is 3.7V nominal so 24/3.7 => 6 batteries and a half. I’d go for 7 batteries in series because I want to have enough voltage even when the cells are discharged. When the batteries are fully charged the voltage is closer to 30V but that’s not bad for us. One cell is usually 2.2-3Ah and it’s not recommended to pull more than 4A of one of those cells. There are some high discharge cells on the market but those are more expensive. We can improve both current handling and capacity by adding more batteries in parallel. It looks like the pack that we need is 7S2P (7 series 2 parallel). This would provide a similar runtime for 1/4 of the weight and 2x the cost.

The speed controller

To control the speed of the motor we need to control the voltage that gets to it. Usually, this is done with PWM (pulse width modulation) on a MOSFET. Something similar was done for a flashlight in the past.

To control direction and braking, we need 4 of those MOSFETs in an H-bridge configuration. Also, those MOSFETs are coupled with a flyback diode to dissipate the inductive energy that is characteristic to motors.

The cheaper speed controllers are just 10$ so I’m going to buy one because this project is not about the speed controller. Knowing how it works should help in case it breaks.

The drivetrain

To transfer power from the motor to the wheels, I think there are 3 practical options:

gears (hard to mount)
chain drive (more efficient)
belt drive (less noisy and doesn’t require lubrication)

I am choosing belt drive because I care about noise and not having to grease it.

There is a large variety for belt drive and I am going for timing pulleys of the HTD3M variety because they are fairly common, with decent performance and not expensive. When transferring power from the motor we need to reduce the RPM and increase the torque. The driving pulley is the smaller one and the math is like this: If the driving pulley has 15T (T = teeth) and the driven one has 120T then RPM is decreased 8 times. Our motor is rated for 3300 RPM so, at the axle we’d have 3300/8 ~ 412RPM. Because the diameter of our wheels is 10” then the theoretical top speed is 20KM/h. That’s very nasty for a pedal car which will be driven by a toddler.

After doing a little bit more reading, it seems that because of the higher RPM I can’t really use a 15T pulley, I have to use a 20T one. This means lower torque and high speed up to 26KM/h. I see these options:

limit top speed electronically (torque stays the same but it’s simpler for me)
add another set of pulleys (gain more torque with lower top speed)

Browsing pages 67 to the end in this document indicate that given our 108 Ncm peak torque a 6mm belt wouldn’t do it and a 15mm one would be more than enough. We are using a very short belt so our length correction factor is ~0.7 and to account for beginner errors I am just going to go for the beefier option.

Once we have our choice of pulleys we need to calculate the belt length. Since the math is a bit more involved for that I provide a calculator below which does the heavy lifting.

D=Pitch Diameter Large Pulley

d=Pitch Diameter Small Pulley

C=Center Distance

L=Belt Pitch Length

Center Distance Known
Large Pulley D:
Small Pulley d:
Center Distance C:
Belt Length:

Belt Length Known
Large Pulley D:
Small Pulley d:
Belt Length L:
Center Distance:

In my case, 405mm is close enough to a standard belt size but I’m getting a 408mm belt to make sure it can be mounted.

Servo steering

I am thinking to implement remote control so I need to be able to steer the car. I am just going to do it like they do it on RC cars, with a servo motor.

Basically a servo motor it’s special because it can rotate or push to a specific angle or distance and then keep that position steady. To do that it has a positive feedback loop which compares the input signal which specifies the position, with the actual position and tries to keep them in sync.

Generally, servos are controlled with PWM at 50Hz and rotate 180 degrees.

They tend to have high torque because they have a gear reduction mechanism but I’m getting one which is way bigger than the ones used for RC cars because the car is much bigger. I’ll use a SUPER200 servo which is rated for 200Kg/cm which means it can lift 200Kg at 1cm distance from the shaft. If the lever which moves the wheels is mounted 20cm away from the shaft I still get 10Kg of force to move the wheels so that’s good.

Quick CAD modeling

I believe I have pretty good imagination and I can see in my mind how things fit together. That was a problem in the past because there are always differences from reality so I decided to do a little bit of modeling to confirm all would fit together.

Errors were visible right away so look at the image below.

The large timing pulley cuts in the dark blue metal plate which supports the motor near one of the edges which supports it. I will try to mount the motor 180 degrees rotated so the metal plate would have better structural integrity.
The two timing pulleys collide. I would have to make the metal brackets which support the motor narrower so I can place the motor 10mm closer to the back edge.
The small timing pulley rubs on the motor. I will mount it 2mm offset on the shaft and hope one of the sides will not fall off. I don’t want to use a thinner pulley because we determined earlier 15mm would do it.

After putting a bit more thought into it, this assembly makes more sense like this:

To view the actual 3D assembly click HERE.

BOM for this conversion

pedal car
GR 63X25 DC motor
24V battery pack
motor speed controller
10A fuse
acceleration pedal
threaded rod as a drive train
20T & 120T HTD3M timing pulleys
408mm timing belt (15mm wide)
SUPER200 servo

We’re getting close to 300$ in parts, without considering the cost of the car.

… I’ll think about it.

Operating Systems hidden on your PC

2017-11-16T00:00:00+00:00

Whether you use a Mac or PC with Windows or Linux, your Intel computer runs some other operating systems in the background without bothering you with this piece of information. These OSs run all the time, have amazing capabilities and are impossible to remove.

Some time ago, computer scientists devised a mechanism called protection rings which has the purpose of allowing operating systems limit access to resources. It goes from ring 0 (most privileges) to ring 3 (least privileges). For example, the kernel of your operating system runs at ring 0 and your web browser at ring 3. The kernel should have the capability to access all the RAM to allocate it to different programs, but your web browser should not be able to read the memory of your bitcoin wallet software.

Then it came hardware virtualization and that hypervisor runs one level below the kernel so that the guest OS can run just as before. We call this ring -1.

Bellow ring -1 there are many other things lurking in the shadows.

System Management Mode (SMM)

This is a special operating mode of your CPU, which runs code from the firmware completely independent of the Operating System. Some people call this ring -2.

It does things such as:

control fans or shut down the computer when the CPU overheats
resume the OS from standby when the laptop lid is open
emulate a USB keyboard as PS/2 so it can be used in a super legacy OS like DOS
control voltage regulators to manage how much power your CPU gets
vendors use it to implement features specific to their devices

SMM was designed so it can’t be overwritten by the main OS when it’s enabled and it reserves 8MB of RAM which is not visible anymore.

SMM runs the vendor code all the time and you can’t do much about it. You don’t see what and when it runs and it has excellent control over USB or other peripherals.

The code that runs in SMM takes time away from applications and in current implementations, it switches all the cores even to add 1+1.

But of course, you should trust your vendor will do a good job here. It’s not like NSA exploited SMM against the most reputable vendors like Dell, HP and Juniper.

Unified Extensible Firmware Interface (UEFI)

The word “extensible” sounds good in general, but not so good for things you want to be specific, simple and secure.

This is a piece of software that replaces the BIOS which has some limitations such as it can only run in 16bit mode, address 1MB of memory and use up to 2TB drives. The specification was originally developed by Intel but in 2005 this responsibility was transferred to the UEFI Forum.

The main features of UEFI I would like to debate are:

CPU independent device drivers
The possibility to run EFI applications
Graphical features which allow having a GUI before loading the OS
Network booting (PXE)
Secure Boot

This list of advantages sounds like having an Operating System?!

Let’s take this great features one at a time:

Universal drivers should be a great feature. I speculate that many of these drivers could be used by the main OS directly through the UEFI API. The truth is this most often they are implemented twice; once for firmware and once for the OS.
The application I willingly run is the GRUB boot loader which gives me flexibility when I start my operating system. I can’t think of anything more that I would want to run at this stage so I can’t appreciate this capability too much.
I don’t really need anything before I load the OS. I only need my OS to load fast so I wouldn’t mind a couple of seconds of black screen before the kernel of my OS initializes the display.
Network booting is a neat feature. I have also used it in the days of the BIOS when network cards had a dedicated chip which included the software implementation for doing that. This feature allowed me to either run stateless machines without HDDs or to automatically install the OS without handling CDs. My concern now is that in the context of UEFI, this means an obscure application can communicate over the network and applications now are not limited like they used to be.
Secure boot is complete bullshit! It was mostly used by Microsoft to restrict people to only use the Windows which comes preinstalled. It restricts the firmware to only load a kernel signed with a private key which corresponds to a public key which is loaded in the firmware.

Now let me tell you another concept. In UEFI there are boot services and runtime services. The boot services run until your operating starts loading and runtime services run also when your OS is running.

Most of UEFI is closed source and only the vendor knows what’s there. Some parts of it are OpenSource but basically that doesn’t make a difference for the end user.

In a nutshell, UEFI is an extremely complex proprietary kernel which runs on the main CPU even while your OS is running. Exploits where demonstrated this year which work even when updates and security measures are in place.

Intel Management Engine (Intel ME)

This is the masterpiece. RING -3

It is a separate processor core embedded in the CPU package, with internal ROM, RAM and DMA (direct memory access) to the main system memory. In addition to that, it has network access with its own MAC address through the ethernet controller.

When you apply power, the first thing that starts is ME, which loads its firmware from the flash chip where you usually also have the UEFI firmware and SMM stuff. Parts of this firmware are signed by Intel and if it doesn’t find what it expects it either doesn’t start the main CPU or it reboots the computer every 30 minutes.

One nice component of ME is Active Management Technology (AMT) which can be used remotely even when the PC is turned off.

Another nice one is Protected Audio Video Path (PAVP) which allows ME to communicate with the GPU so it can read and write to the screen. I wonder about the audio capabilities which are hinted in the name.

In a nutshell, ME is the nicest control tool which runs a proprietary MINIX based OS that can do everything on your computer:

power ON/OFF
access all memory
view/paint your screen
read your keystrokes
… ?!

Having so nice features it was surely bound to be vulnerable for 9 years. If you have an i3, i5 or i7 computer bought before the end of 2017 then you are likely vulnerable.

If you want to know more, in the PCH datasheet at chapter 5.25 you can see a short overview. The PCH is the die on the right side of the image below.

Can we do something about it?

Technically speaking, the options are very limited. All these beautiful things are burned on a flash chip like this one you can see on the right side of the CPU in my PC.

In theory, we could do the following:

Disable parts of ME with this Linux tool or the Windows one.
Buy a SPI flash programmer to dump all the firmware.
Use me_cleaner to remove a good part of the ME firmware.
Flash the minimized firmware back to that chip.
Hope for the best
To improve the UEFI and SMM issue, it’s going to be much harder. You’ll have to learn about heads, coreboot, the UEFI specifications. Then you’ll have to build a custom UEFI of your own which will start a Linux kernel very early on (at BDS stage). This kernel would take a good chunk of the EFI responsibility and it could also run your Linux OS. For me, it will be a little more difficult because I have 32bit UEFI and it would only start a 32bit kernel which I could then use to start the main OS kernel.

… or maybe I will just buy a Purism computer next time.

If you are a Windows or MAC user, I think your only option is to complain to the government. Spreading awareness is something that I am sure you can do.

We only talked about Intel here but AMD does something similar. Chromebooks are a little less affected by this but they only run Google stuff.

Conclusion

Most of us are always running a version of MINIX on their computers, which makes Tanenbaum very happy because MINIX is used more than Windows, Linux or MacOS.

To access AMT you can use the user “admin” with an empty password and you have complete control. The right janitor in the wrong network would make a very interesting story.

We also run UEFI and SMM stuff all the time which was proven to be exploited very effectively time and time again.

Basic function generators

2017-11-06T00:00:00+00:00

If you have electronics as a hobby it’s unlikely you are going to get away without using a function generator. Its role is to make electrical waveforms over a range of frequencies while allowing to control the amplitude of the waveform. Some basic use cases include testing speakers or amplifiers, calculating inductance for coils or experimenting with resonant circuits such as for wireless energy transfer, induction heating or tesla coils. In some cases, I got away without spending a cent but at some point I got a 10$ kit and a while later I spent 50$ for a finished product. A “normal” generator starts from 300$ so what exactly is inside the 50$ one?

Specs to consider

Waveform types should be at least sine, square, triangle. Sawtooth and reverse sawtooth can also be useful but an ARB generator will do everything.
Frequency range: I would be satisfied with 0.1Hz-1MHz but if you only play with audio applications pretty much any generator would cover the range.
DC Offset is not really a must-have feature but I would be happy if I could add +5V DC offset to the signal. For example, it would help to fake digital signals.
Duty cycle control is often used to control the power supplied through MOSFETs. For example, with PWM I am adjusting the light level in a flashlight.
Output level represents the maximum and minimum level of the signal. If it does 10Vpp then you can have +/-5V signals and it would cover a lot.
Output impedance is 50 Ohm standard but with crappy generators is larger. If the impedance is larger it would have less driving capability for a load.
Modulation would come handy if you plan to do more advanced experiments. Amplitude, frequency and phase modulation are the common types.

Analog or digital

If we want to do it in less than a day, analog is the best option. We should be able to do it with a few components and for very little money. The first chip that comes to my mind is XR-2206 and in its databook from more than 30 years ago, you can see some good notes starting with page 42. The other one I am thinking about is ICL8038 and this one has the advantage of being readily available in my parts bin.

They are both designed for generating signals and I guess with a dual opamp, three potentiometers, some caps and resistors will be all done. Half of the dual opamp I could use as a summing amplifier for offset and the other half as a buffer. The potentiometers would be frequency, amplitude and offset.

This approach with analog would be fun, easy, quick and cheap but lacking in some areas. It wouldn’t be easy to precisely set the frequency, not high frequency and having two channels in sync with controllable phase shift is not easy with these. Not to mention they are not being manufactured anymore.

Buying a decent analog generator is not really attractive to me because it’s bulky and I live in an apartment.

With a digital generator, we dial in exactly the frequency that we want. Coupled with some simple software it can sweep between two frequencies in a predefined amount of time or even generate some arbitrary waveforms with the fancier ones. These unlock a lot of other possibilities and are by far the most common commercial function generators these days.

Out of the digital type, the most common ones use direct digital synthesis, DDS. They are very versatile but of course more complicated and more expensive.

DDS uses a phase accumulator, a look-up table containing a digital representation of the waveform, and a DAC. The phase accumulator advances position each time it receives a clock pulse. This position in the look-up table contains a digital value that is feed in a DAC.

As a DIY approach, I would probably consider using AD9833 which is not expensive and would allow me to generate signals up to a few MHz. I would add a second one for having two channels, some Arduino compatible board, a nice LCD, rotary encoder and plenty buttons to make it easier to jump to the functionality we care about. I don’t like instruments where you spend time navigating through menus. Of course, just like before we need the opamps for controlling the offset or amplifying the signal.

The free generator

Yeah, it’s just a jack cable which I hook to my phone where I run the Function Generator Android App.

Sacrifice a pair of old headphones and you got yourself a dual channel function generator for free. Its sample rate is bad, the output level is horrible and there is no DC offset but you can’t beat this price point. This thing is just good enough to test audio stuff and it can be set up in no time.

The 10$ kit

I got this mostly because I felt like building a kit and I imagine it would come in handy at some point. I like its design for its simplicity but I don’t enjoy using it because it’s awkward to operate. It didn’t come with a power supply so I adapted the picoPSU I’ve had around. The power supply was way more expensive than the kit!

The design of this seems to be copied from ScienceProg.

The Atmega16 micro generates signals which go in an 8bit R-2R DAC that then goes in an OpAmp for setting the amplitude and offset.

Its frequency range (0-65KHz) and output levels (10Vpp) are a few times better than the Android generator but I ended up using the Android generator way more than this. Without having it in a proper case with buttons it’s just not fun to use.

The 50$ unit

It comes fully assembled as a product, packed in a cardboard box, with charger and some cables for 50$ including shipping from China! Its specs are impressive to me:

0.01Hz-25MHz for sine and up to 6MHz for the other waves
5mVpp~20Vpp amplitude
12 bits amplitude resolution
Arbitrary waveforms with memory for my own
PC control over USB
… and the list goes on and on

How is this possible?! What’s inside?

It’s actually got quite a few things which are not necessarily the cheapest if we got 1000 of them from a reliable supplier like DigiKey or Mouser.

From left to right:

There is the switching power supply which converts 5V to +13V and to -13V. ~ 1$
Next to the power supply it’s the ST 8bit, 16MHz microcontroller which most likely handles the LCD, menu and all that user interaction. < 1$
Bellow the power supply it’s the USB-SERIAL converter which allows us to talk to the micro and an EEPROM for storing ARB waveforms and settings. < 0.3$
Then it’s the Lattice MachX02 FPGA which is one of the cheaper ones but still one of the most expensive single chips from this board. < 6$
The R-2R resistor ladder is a good way to make two DACs without spending money. When a 12bit DAC is implemented, 0.1% resistors should be used but here cost is the driving force so normal resistors were used. < 0.1$
Then the signal flows in the two AD8017 variable gain amplifiers. < 6$
Just before these but not in the signal path there are two LM OpAmps which control the DC Offset. These are super cheap. ~ 0.1$
Last, under the way too small heatsink there are the most expensive chips. Those are the output buffers which actually drive the load that we hook up to our generator. My board had THS4022 which are pretty high-speed chips so at 25MHz the sine was still looking good. > 12$

Quicky adding these up, then making some very optimistic estimations for PCB, connectors, plastic case, LCD, power adaptor, cables, cardboard box and labor it probably goes to a minimum of 35$ for the cost of goods sold.

This also shows that both resellers and manufacturers operate on very thin profit margins. I am sure they pay less than my estimations and I would really learn how they do that.

Improvements I did

Replace THS4022 with THS3092 which is slightly cheaper and can handle more current. This means we maintain the amplitude better at higher frequencies.
Replace the heatsink with a much larger one. At high frequency or with low impedance loads this thing gets hot.
Add some decoupling capacitors on the input of the power supply to remove some noise. On my board I added 1600uF and it was enough for medium loads.
Add a small heatsink to the XL6007 switching converter. This works at the very limit of its output current when the generator is driven hard. In it’s SEPIC topology it should do 0.6A but the OpAmps want way more.
Blocked the light from the LCD to bleed to the LEDs.

Improvements I wish the manufacturer did

Much better SEPIC converter. This implementation can’t handle enough current.
OpenSource software. I am sure nobody can make it cheaper so if the software was OpenSource people would be happy to improve it. For example, I don’t see why this unit wouldn’t support modulation.
Better load handling.
Lower noise.

A professional generator board

Sigilent SDG 5000 series are entry level arbitrary waveform generators which might actually be used in a professional environment. This one is more than $500 and as you can see below, the main board is way more complex. The obvious things are a fancier FPGA, SRAM, a nice DAC and many OpAmps in parallel on the output.

Another board does only the software and control stuff and this one is also quite impressive to me.

Conclusions

Function generators can be fun :)
As usual, you get what you pay for so don’t get the 10$ Kit.
The 50$ MHS-5200A unit is good bang for the buck and with some small improvements and OpenSource firmware, it can be even better.

Flashlight with software

2017-10-12T00:00:00+00:00

So, you know when you are tired or bored and you go to strange places online? I somehow found this flashlight online and from the picture, you can see many high power LEDs + many high power batteries + adequate cooling => awesome light output. The price at that time was ~50$ so I ordered because it seemed I get a lot for my money.

As a technical guy, I see 10x CREE XM-L T6 and I go straight to the datasheet to see what that is about. It looks like one LED is able to output 692 lumens at 2A and 3.2V. This is the rated power but the datasheet also suggests it can be overdriven too, so I could speculate one of these LEDs can reach 1000 lumens. 10 of these would output 10000 lumens and they would consume either MANY amps (in parallel) or volts (in series).

Anyways, from the theoretical (not the advertised) specs it looks like a 100W LED flashlight which can output 10.000 lumens. This should be great.

I ordered, it arrived, and it wasn’t great. The light output was not impressive so I disassembled it to see what’s up.

Principle of operation

All those LEDs are in parallel so to reach max output it should draw more than 20A and that’s insane. That’s also at the very limit of the 4 parallel 18650 cells but I guess in theory it should be OK to go to maximum for a few seconds. A quick measurement revealed it draws under 1A, so something is clearly not right.

Looking at the electronics we can quickly deduce it works like this:

Pressing the button is registered by the microcontroller.
The microcontroller switches the MOSFET on/off. By changing the amount of time the FET is ON vs OFF the light output can be controlled.
Some resistors limit the current flow between batteries, MOSFET and LEDs.

More is less

The first thing to try is shunting those resistors so more current will flow to the LEDs. I can immediately see the light is way brighter and now it’s drawing around 3A. It’s not even close to the expected maximum not now at least is nice.

I played with it for a little more and suddenly it was dead. No smoke or something like that, it just didn’t work anymore.

Probing the circuit a little I was able to determine the microcontroller was faulty. If it was the MOSFET then I could easily replace that and get it working. The microcontroller had no markings and I had no software to flash to it anyway. Before I abandon this I decided to hook the LEDs directly to the bench power supply to see how much light can these actually deliver and it seems not more than 4A. It seems the LEDs are also fake. :)

I clearly didn’t get what I paid for.

Less is more

One year has passed, and that weekend when I made time to do something different arrived.

The footprint of an ATtiny13 matches what used to be on that board so I incorrectly assumed it should fit right in. Reality is that it doesn’t even match the VCC and GND pins but it’s OK; we cut a few traces, bypass with a few wires and we make it work.

Basically, we need to power the ATtiny13, connect the MOSFET to a pin that can be used for PWM (pin 5 or 6) and the button to a digital IO pin which is pretty much any other pin.

I made this simple programming rig where I used an Arduino nano as an ISP and connected a button and an LED to the ATtiny13.

Code

All I want from this flashlight is to be able to control the light intensity.

I keep the button pressed from Off and the light starts ramping up.
I keep the button pressed from On and the light reverses until it turns off.

That’s easy to use for everyone and easy to implement.

I have an array of 16 intensity values which should be somehow logarithmic since perception of light is not linear. We go through those every 100ms and when you lift the finger of the button light stays at that level.

Initially, the array had 64 values for much smoother ramping but ATtiny13 doesn’t have enough RAM for that. :)

The signal that is sent to the MOSFT when the button is pressed looks like this:

With this code, the microcontroller works all the time it’s powered. Fortunately this micro is not power hungry.

Just as a quick and easy power saving method I disable the ADC and the Analog comparator to save 25% energy and if I configure it to work at 1.2MHz instead of the default 9.6MHz. This cuts the energy consumption in half once more. It now uses under 1mA so it’s good enough for now.

End result

After fitting our new microcontroller on our board, it looks like this:

… and the end result looks like this: I actually press the button twice. Once to go to max and again to go from max to zero.

YEAH! The flashlight is alive again!

Possible improvements

Read the battery voltage with the ADC and reduce the output or produce a warning strobe when the voltage is too low.
When the flashlight is off power down the microcontroller and wake it up with an interrupt when the button is pressed. This would improve the standby time a little.
Automatically reduce the output from 100% to 50% after a number of minutes. This should help a lot with heat and battery life.
Go hardcore and make another board which can accommodate more MOSFETs for better power dissipation, temperate sensor and ATtiny85 which has more memory.

Since the flashlight is usable now, I am going to stop here but if I was to develop a product, I would definitely do those improvements.

Power meter for the entire apartment

2017-04-19T00:00:00+00:00

In the weekend I wanted to do something fun for improving the visibility of energy consumption. I ended up with a nice LED display that shows usage in realtime and some cool charts on my phone.

Principle of operation

We learned in middle school that current passing through a wire generates a magnetic field and that a magnetic field passing through a wire generates electricity. Later I learned that this is the basic principle of the transformer. Our current sensor is essentially a transformer which generates a voltage across a burden resistor proportional to the current passing through the wire we are clamping the sensor to.

Now we need to read the voltage from the sensor and do some calculations to determine the power usage.

Since our voltage is AC, it has negative values and we would have to add a DC offset to it so the alternation would only happen above zero.

Our microcontroller has an ADC which would convert the voltage value to a numerical value depending on it’s resolution. A 10bit resolution could have a value between 0-1023.

Finally, the circuit going to our ADC looks something like this:

Implementation

Our BOM (Bill of materials) is short and cheap (~$20):

Microcontroller: Wemos D1 mini
CT Sensor: YHDC SCT-013-000
Display: Dot matrix with MAX7219 driver
Power supply: HLK-PM03

Yeah, I am a fan of the ESP8266 microcontroller even though it doesn’t have the best ADC. Still, it has WiFi and works well with the Arduino SDK.

To determine the burden resistor for the CT sensor we have two options:

Do some math

Assuming we want to measure up to 9kW then the peak current would be: 9000/230=39.13 ~ 40A
Since we have AC, we have to multiply with √2 to get peak values: 40A × 1.414 = 55.33A
Our sensor is rated 50mA on the secondary for 100A on the primary so we have 100 x 1000 / 50 = 2000 turns.
The peak current we can expect on the secondary will be: 55.33A / 2000 = 0.0276A
Now the burden resistor should be chosen so that voltage doesn’t go over half of 3.3V: 3.3 V / 2 / 0.0276 A = 59.7 Ω This is close to 56Ω which is a common value so we can choose that.

Do some measurements

Took out the old scope and measured Vpp with various burden resistors and with all the major appliances running. ;) WTF is this?! Where is my sine wave?! Yeah, with all those reactive and non-liner loads (Fridge, TV, CFL and LED bulb, computers, etc) it will not look like a sine wave. If I plug everything off and only run the stove or some other resistive load it looks like a very pretty sine wave but with normal devices, never.

It seems that the sweetspot is 2 x 47Ω and adding all the running appliances sums up to ~6kW. I added a calibration feature in the Android app anyways and this way we could get slightly better results.

After a bit of soldering and coding, our prototype looks like this:

Here my meter is measuring 1525Wh and the commercial thing I have is measuring 1550Wh. The error margin is less than 2% so I’m happy with this result. We don’t know how well the commercial meter is calibrated anyways.

Code

The SDK we are going to use is Arduino and a bunch of libs that make things simple.

Blynk will help us with the Andorid app and communications through Internet.
ArduinoOTA will allow us to do wireless firmware updates.
MAX7219_Dot_Matrix is obviously the lib which paints the display.
EmonLib does all the math for energy monitoring.

After the prototype testing I installed it in the fuse box and it looks like this:

… and the Android app looks like this:

Possible improvements

Add more channels.
Improve the resolution.
Predict the cost.

The ESP8266 has a single 1V, 10bit ADC built in. This isn’t great if you want precision. Using an external ADC such as ADS1115 would allow us to go to 4 channels, 5V and 16 bit. It would be a huge step up and just a small increase in cost.

Hacking the washing machine

2017-04-11T00:00:00+00:00

I got the perfect washing machine in my early 20s when I was single. It has some predefined programs, no display or any other complicated features. I was using mostly “power + quick wash”. Now, in my early 30s, my wife uses programs that take hours and staring them after work means the cycle would be done after midnight. So, let’s make that hunk of metal controllable from the Internet.

Step 1 - Understand how it works

At first impression all is simple. It’s a relatively unknown micro with many GPIOs, some used as inputs for buttons and some to switch transistors that drive LEDs.

I got the control board out from the machine and hooked it to a bench power supply but nothing happens. Obviously there is also a power module with relays and stuff for controlling valves and the motor. It turns out that on this power module there is an EPROM which identifies the model and which allows the control board to actually run. That is not going to be an issue because we can test with the complete circuit.

Probing around with the multimeter made it clear quickly that the buttons pull GPIOs to GND. LEDs on the other hand, are NOT connected to GND or to a voltage rail directly through a resistor. The LEDs are connected to GND through individual transistors and power is applied to all of them through another transistor.

Doing a bit more investigation, seems that there are a lot of failsafe mechanisms so the machine wouldn’t run with a jammed engine or failed valves. Still, we don’t care about all that so we move on.

Step 2 - Interface a wireless microcontroller

Our microcontroller of choice is going to be the notorious ESP8266 for obvious reasons; it has builtin WiFi, it’s cheap, easily available and works well with easy to use SDKs such as Arduino. It has some minor shortcomings, such as it’s logic is 3.3V while the micro in the washing machine is 5V. That it’s easy to overcome with some simple voltage dividers or a level shifter circuit so we move on.

We just want to do two simple things:

Push buttons to actually start wash cycles.
Read LEDs so that we know remotely the state of the machine.

If we only did the button pushing thing then we would have no guaranty things are actually happening.

For pushing the buttons we will connect some transistors to ESP8266 and use them as a second set of switches. This will use 3 GPIOs and handle Power, the 40°C program and the 60°C program.
For reading the LEDs I decided to use a level shifter I had around. We will use all the 4 channels to detect the power, lock, 40° and 60° LEDs.

It would be a good idea to improve the 5V power supply included in the power module because our microcontroller draws extra 100mA and the added consumption takes us very close to the limit. Still, I will do that some other day.

Code

The SDK we are going to use is Arduino and with just a library or two this is going to be really simple.

Blink will help us with the Andorid app and communications with the microcontroller through Internet.

WiFiManager will help us not hardcode the AP credentials in the code so that when we change the wireless router, we don’t have to reflash the washing machine.

After some testing with the ESP8266 disconnected I procedded to solder it in and it now looks like this:

… and the Android app looks like this:

Step 3 - Enjoy

To me, this is still the best washing machine because I don’t have to buy a new one :)

Automating SurveyMonkey Responses

2017-03-24T00:00:00+00:00

I wanted to give Selenium a try for a while and I just found the perfect pretext: earn enough votes in a SurveyMonkey poll to win a bottle of cognac.

Constrains

The automation has to work on SurveyMonkey because this was the chosen poll system. After some initial checking it was clear this one has some security checks in place so that makes it even more fun.

Why this works

We will instantiate an incognito browser every time so cookies will not be saved and we can run this over and over again. This will be a real browser which will receive simulated clicks on HTML elements so it will be hard to detect it’s automated.

Also, SurveyMonekey has an option to check if voting is done from the same IP address. In this case the option was not used so unfortunately this was quite easy.

Code

import time
from selenium import webdriver
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.chrome.options import Options
chrome_options = webdriver.ChromeOptions()
chrome_options.add_argument("-incognito") 
driver = webdriver.Chrome(executable_path='/usr/lib64/chromium/chromedriver', chrome_options=chrome_options)
driver.get('https://www.surveymonkey.com/r/YD6G9PT')
vote_check = driver.find_element_by_xpath(".//*[@id='question-field-96043893']/fieldset/div/div/div[1]/div/label/span[1]")
vote_check.click()

vote_done = driver.find_element_by_xpath("//button[contains(text(), ' Done')]")
vote_done.click()

time.sleep(3)

driver.quit()

Obviously you have to replace the survey URL and the ID of the question. HERE you can find a starting point regarding how we locate the clickable elements.

Installing selenium is easy with pip3 install selenium.

And to run it, all you have to do is: python3 win.py

Before applying jerk script

After applying jerk script

Wear protection

It seems there is an option to send the survey by email, and not by a web link. If you send the survey by email you are doing two things:

You are giving SurveyMonkey the email address of your respondents (not cool)
You are allowing SurveyMonkey to generate links for each email address (cool)

Notes:

I actually ran the automation after the winner was chosen.

It works well in March 2017 but it’s likely it will have to be adjusted at some point if SurveyMonkey will make changes to their system.

Benchmarking Cloud VMs

2017-01-05T00:00:00+00:00

Once in a while I compare the performance vs cost benefits of cloud vendors. In this case I just need to compare virtual machines, which is by far the most used service out there, so I guess sharing these results should be useful to many people.

Constrains

I am automating things are a pretty high degree so the vendors I am looking at should have a decent API that would allow me to create and destroy servers without ever going into the web admin interface.

I only care about compute for this project so we are only comparing that. There will be no added value if a vendor has features that we don’t use.

Methodology

By analyzing the offerings, I will choose some vendors and an instance type that is equivalent and the most cost effective.

Thus, the chosen instance size was 8G RAM and 4 vCPUs and the vendors are:

Amazon Web Services
Google Compute Engine
Digital Ocean
Linode
Scaleway

We will test, CPU, Disk IO, memory and network bandwidth.

Environment

All tests would be done on Debian 8 because it has fairly recent tooling and it’s a popular and well maintained distro.

apt-get install fio sysbench ioping

Disk

All the instances had 100G SSD attached. Performance will vary significantly here because they use different technologies.

Random RW

fio --ioengine=libaio --direct=1 --bs=4k --iodepth=64 --size=5G --rw=randrw --gtod_reduce=1 --name=rw

Random Read

fio --ioengine=libaio --direct=1 --bs=4k --iodepth=64 --size=5G --rw=randread --gtod_reduce=1 --name=read

Random Write

fio --ioengine=libaio --direct=1 --bs=4k --iodepth=64 --size=5G --rw=randwrite --gtod_reduce=1 --name=write

CPU

We are running the tests with a different number of threads in order to observe if performance scales well as we increase the number of cores.

These tests should be repeated a few hours apart to determine observe if the CPU performance looks predictable or if there is a big chance for noisy neighbors.

for each in 1 2 4; do sysbench --test=cpu --cpu-max-prime=20000 --num-threads=$each run|grep "execution time"; done

Memory

sysbench --test=memory --num-threads=4 run | grep "execution time"

Bandwidth

On machine A iperf -s -p 81
On machine B iperf -c 10.150.0.146 -i 1 -t 60 -V -p 81

Results

Notes:

Amazon and Google both limit IO performance according to disk size. They both can perform very well with way more expensive storage. Scaleway offers a very interesting cloud offering with both physical and virtual servers. I tested both and each one is OK for a different job.

Conclusions:

There is a huge difference in the cloud offering.
Compute at Amazon is very expensive compared with others.
I chose Linode in this case because peformance is really good at it’s price point.
Out of these 5 vendors Scaleway seems the cheapest as of January 2017, but it depends on what do you need. To achive such a low cost they use commodity hardware with Atom CPUs but that is fine since it’s reflected in the price.
Remember that in the cloud, CPUs, RAM, disks are not created equal.

Testing charge-pump ICs

2016-12-08T00:00:00+00:00

Sometimes we need a negative voltage rail. There are several ways to obtain that but most likely the easiest is to use a charge-pump IC with only two capacitors. Because the datasheet doesn’t always paint a clear picture I decided to order a few and do my own testing for the things I care about (current, ripple, switching frequency).

Application

I suppose that you already have an application in mind since you are reading this. Nevertheless, this time my use case is powering up OpAmps which I will use in an audio application. Is might not work well for this but that’s what I want to find out.

Charge pumps are essentially integrated in almost all flash-memory and they are instrumental in deleting data. As standalone devices they are not common place.

Possible issues

Let’s see quickly how they work. In the image below we can see that we essentially have 4 switches.

Closing S1 and S3 charges C1 in the first half cycle. In the second half, S1 and S3 open and S2 and S4 close. C1 is then in parallel with the reservoir capacitor C2. If the voltage across C2 is smaller than that across C1, charge flows from C1 to C2 until the voltage equalizes. Since the polarity is inverted then the voltage would be negative.

The more current you draw from C2 the more ripple you’ll observe. The frequency of the ripple will be the frequency at which the switches operate.

For powering OpAmps this is clearly not ideal because charge pumps are switching devices which, of course, have ripple on the output. On the other hand, OpAmps have a PSRR (power supply rejection ratio) which define how much of the noise from the power supply will end up in the output of the OpAmp.

In the image below we have a generic graph for PSRR.

This essentially tells us that at 10kHz the rejection of noise from the negative supply is ~ 105 dB. This means that if you have 10 kHz ripple on the negative supply, the noise would be 0.000005 of the audio signal. Even if we amplify the signal 10x it’s still going to be great. Nevertheless, this is OP4177 which has a great PSRR. For many other OpAmps we don’t even have this data in the datasheet so we just need to do some tests and see for ourselves.

It looks great. Even with 100x worse PSRR it should still be good enough.

Also, I have another plan. If we can use the charge pump at greater than audible frequencies then we could probably even ignore this data. A young and super pretentious teenager should be able to hear all the way up to 20kHz. Once you get older you don’t hear high frequencies well anymore. Because I was never a golden ear I will count on measurements.

In short:

Large ripple + bad PSRR => noisy output.
Small ripple at high frequency + decent PSRR => happiness

Change pump ICs

Intersil 7660S

Microcip TC7660

Linear LTC1144

Misterion 7662

I am interested in testing the following:

maximum current they can dump in a 100 Ohm resistor when supplied with 8V
ripple while loaded with the 100 Ohm resistor
operating frequency

Some of these have a boost functionality that can increase the operating frequency so I will also test this where available.

Intersil 7660S	Microcip TC7660	Linear LTC1144	Misterion 7662
37mA	41mA	36mA	31mA
1.6V	1.0V	1.3V	1.5V
3kHz	6kHz	3kHz	2kHz

We have some pretty picture too, taken with the scope. You can say which is which by looking at the Vpp and frequency values.

The doubled waveform is obviously a trigger error captured by the scope.

Out of the bunch, the last two also had a boost function which would increase the switching frequency. That should have also been available for Intersil 7660S but it didn’t work. Perhaps I had a fake of defective batch.

Linear LTC1144 + boost	Misterion 7662 + boost
30mA	30mA
0.7V	1.2V
37kHz	2.7kHz

LTC1144 actually stats to look acceptable, especially compared with the others. It’s oscillating at much more higher frequencies than audible. Even though the ripple is huge, at least is much better than the others. I guess it makes sense now that is twice the cost of the next one in the bunch.

Still, 700mV ripple is huge. According to the datasheet we should be able to do much better.

At the bottom of page 7, the datasheet tells us that capacitors are not critical. On the other hand they also show that most of the charts go up to 20mA, even though one goes up to 50mA. Still, regular 10uF electrolytic caps have a pretty big ESR. At high frequencies, the resistance of the caps should greatly influence the transfer of energy from C1 to C2, thus it will increase the ripple and decrease the output current.

Let’s test LTC1144 with 10uF capacitors that have much lower ESR.

	Tantalun	Ceramic
Current	40mA	39mA
Ripple	0.8V	1.0V
Freq	3kHz	3kHz

Already a big difference even at the lower frequencies. Surely it would be better once we activate the boost function.

	Tantalun	Ceramic
Current	30mA	33mA
Ripple	0.3V	0.16V
Freq	37kHz	36kHz

That’s more like it! LTC1144 is the only decent charge pump for this job. With 10uF ceramic caps, it shows the best performance, even though that is not mentioned in the datasheet. Perhaps I am missing something but even so, tantalum caps are a much better option and they make a huge difference.

Conclusions:

The difference between pin compatible parts ca be huge.
The ESR of capacitors can be a huge influence in various applications.
Charge pumps could be a very decent option where low power is required.
LTC1144 is significantly more expensive than the bunch that was tested but it’s performance is much better.

One thing that was brought to my attention is that I didn’t mention the voltage drop is huge with our 100 Ohm load. After we account for the output resistance in our IC, if we put 8V in, we will get -3.3V out.

Unfortunately I think I need a few times more current than these can deliver for driving headphones decently. Even though I could parallel more charge pumps ICs, I will also consider LT1054. If that doesn’t work perhaps I will have to consider a switching power supply with an inductor.

IoT Fuzzy Clock

2016-10-29T00:00:00+00:00

Let’s see how to make a very precise clock that will be read with a large margin of error. It should be easy for the technically inclined and it can also be fun.

The purpose is to introduce some very versatile and yet cheap building blocks in the most straightforward way possible. It was written for beginners and it explains a bunch of things from scratch.

Above you can see the green LED is the minute, the red one is the hour and the blue one indicates atmospheric pressure. It’s a 12 hour clock and in the time lapse it goes from ~ 5:10 to 6:50 PM. When the blue LED is close to the left there is a small chance of rain and when it’s close to the right there is a significant chance of rain.

BOM (Bill of materials)

ESP8266 module
WS8211 LED strip
Any USB charger

At the time of the writing both the module and the LED strip could be purchased for under $10 online. I would never recommend getting a cheap USB charger because it could burn down your house or create a lot of RF noise that could interfere with other stuff such as the WiFi signal.

ESP8266

ESP8266 is a very cost effective chip that integrates WiFi with a capable microcontroller. We will be using a module that uses that chip along with flash so we could store our code and a voltage regulator so we can power it from 5V.

I used the Witty board because I already had it lying around and because for this particular project it comes with an LDR soldered on. I will use the LDR to detect the ambient light and control the intensity of the LEDs accordingly. You can get the module from Aliexpress if you don’t have a faster alternative.

Features

32-bit RISC CPU running at 80 MHz
64 KiB of instruction RAM, 96 KiB of data RAM
External SPI flash - usually 4 MiB
IEEE 802.11 b/g/n Wi-Fi
UART on dedicated pins
16 GPIO pins
one 10-bit ADC
SPI, I²C

To see the beautiful piece of silicon check out the work done by Zeptobars.

WS2812B

We are going to use an RGB LED strip with individually addressable LEDs. Different LED colors will indicate different things and the position on the strip will indicate a relative value.

WS2812 is essentially a capsule which has red, green and blue LEDs connected directly to a chip. This makes it possible to digitally control 256 brightness levels for each color to obtain 16M colors. Depending on the version of the chip we could change colors 400-800 times per second. These can be cascaded and the signal would be sent through a one wire interface. In theory we could achieve 30fps with 1024 of these huge pixels. These work great at 5V, have reverse polarity protection and are very cost effective.

For this project I plan to use only one color at a time and to change it every minute so we will be well under spec. For this application 60 LEDs would make the math easier because it divides nicely with 60 minutes or 12 hours. Nevertheless I only have 30 LEDs at hand so I am going to use that because we are making the fuzzy clock :)

Soldering

Soldering is easy. Connect the red wire (+5V) to VCC, the white wire to GND and the green wire (data in) to GPIO5. The signal travels in the direction of the arrow on the LED strip so just keep that in mind.

Also add a small resistor (less than 1K) between GPIO16 and REST. This will bring the micro back to life then it’s done sleeping.

Software

ESP8266 works with quite a few different SDKs so it can be programmed using different languages. MicroPython is very nice if you like Python, NodeMCU for Lua, Arduino for C++ and there is even a firmware for BASIC. I played with all these and personally I prefer Arduino because it has libraries for almost everything. I also read the documentation for mongoose-iot but as of 2016 it’s just getting started. It also looks interesting but time will tell if it’s going to be an enterprise product or for everybody.

Arduino

Yeah, you all heard about this one. They are some people that like to fight who make some boards and an IDE.

I like the boards that inspired a lot of people and because they were OpenSource it also became possible to get clones for much smaller prices. This inspired even more people. Hardware wise, I am not impressed with the boards. After all these years, I think they are still lacking in some areas.

Now the IDE is a very different story. I think the IDE got better and better. There are many easy to use libraries out of the box. You can find a bunch of other libraries on the Internet. You can even use all these ecosystem for unofficially supported boards and that’s exactly what are we going to do.

The IDE is written in Java so make sure you have JRE. It uses a library from the Wiring project to make it easy to interact with the pins of the microcontroller. It organizes the code in a minimum of two functions setup() and loop() which are pretty self explanatory. setup() runs only once when the microcontroller is powered up and then loop() runs continuously. The Blink sketch makes everything clear.

Just remember that the Arduino IDE is not only for Arduino boards.

Installing with Boards Manager is usually the easiest to get started with ESP8266.

Code

The big picture is:

We import libraries
- ESP8266WiFi makes it easy to connect to WiFi and go to sleep
- NTPtimeESP is an extension that gets us nicely formatted time
- Adafruit_NeoPixel makes it easy to work with WS2812B LEDs
- ArduinoJson helps us handle the JSON data that we get from an external API
We define a bunch of constants and variables
We only execute the setup() function because we want to run things only once and then go to sleep for a little while. When we come back from sleep we reset the micro and the setup() function is executed again. This way, most of the time the microcontroller is actually powered down so it’s drawing very little energy.
Some functions are defined to make it a bit more readable
- WUAPI connects to api.wunderground.com to get the barometric pressure for our city
- showWeather formats the JSON weather data
- getShowData retrieves data from NTP, calculates the position of the LEDs and lights them up. Yeah, this one is not very well structured but it is late and I want to finish this post.

Possible improvements

OTA (Over The Air) software upgrades
Add a buzzer and make a short sound every hour during the day
Add a visual or acoustic alarm that could be dismissed with a press of a button
Add a PIR sensor and trigger an alarm when a person’s presence is detected
Connect a HTU21D or a SHT10 temperature and humidity sensor and put the data in the cloud
Make it flash crazy beautiful colors for various anniversaries
Make it possible to adjust the timezone by pressing a button.
If it can’t connect to WiFi, go in STA mode so the user could connect to it and do to a web interface from where he could setup WiFi.

Conclusion:

I guess you could say this is a IoT project but let’s not say that because it doesn’t sound very nice. :)

We are doing it this way because it’s much simpler than if we used an RTC. We don’t need to adjust the time. We don’t need to maintain power to maintain the time. We get daylight saving adjustments automatically.

Hacking Radio Remotes

2015-08-24T00:00:00+00:00

Cheap wireless remotes are everywhere and the purpose of this article is to learn how most of them work, how secure they are and how to create your own in order to clone or extend an existing remote.

The kind of remotes we are talking about are usually used for controlling lights, opening garage doors or gates, controlling thermostats or any other general purpose application. I hope in 2020 this article will be obsolete but in 2015 it works for 90% of the remotes.

The remote we’ll use here comes from a pretty new product class, the RGB LED controllers for individually addressable WS8211 LEDs. My intuition tells me that in a few years more people are going to use these but let’s hope I’m wrong.

Capturing the signal

For capturing the signal I used a RTL-SDR dongle (RTL2832U) which can be bough for about $10 from the Internet. Everybody who is familiar with software defined radios know them well. For everybody else it’s important to understand what’s SDR and how this dongle can be used. Software defined radio, SDR, is the implementation of some radio components such as modulators, demodulators, filters and amplifiers in software instead of hardware. Because of this, with the proper software and the right configuration we should be able to demodulate and decode pretty much any signal in the frequency range which can be received by our radio.

A very important feature of our $10 dongle is that it’s frequency range is 24 - 1766 MHz. Within this range there are radio and TV signals as well as our remote signal, baby monitors, CB radios (such as those used by taxi) some GSM communication and a lot more. Nevertheless, my remote works on 433MHz and we’ll listen on that frequency.

For software we have several options such as rtl-sdr, GNURadio and gqrx. I prefer to use gqrx because it is very easy to tune precisely to the right frequency with it’s FFT plot and waterfall display. Also it can record the signal to a WAV file which we can then import in Audacity to analyze.

Pressing a button on the remote while you are listening on 433MHz will show a strong signal on the waterfall display. You can now tune precisely on the right frequency. Another very common frequency is 315MHz and 90% of the remotes will use one of these. Also, the vast majority of these remotes use a form of amplitude modulation called OOK so we need to select AM in the Mode dropdown box in gqrx. Pressing a button on the remote should now produce some high pitch sounds. Record a couple of those key presses so we can analyze the data that is being transmitted.

Decoding the signal

For decoding those sounds we’ll use Audacity. We need to import that wave file and zoom right into our signal. After you select Waveform (dB) for that channel, it should look a little bit like this: With the classical method of eyeballing we can easily determine these are some bits which are either high or low.* This is called OOK modulation. Also by eye I translate this into bits. A fancy oscilloscope could do the translation automatically but I don’t have one so I’m going old school. The translated message looks like this: 11100000000011101000111011101000100010001110100010001000100010001000111011101000 1000111010100011...

A huge part of this decoding is also figuring out the proper timing but it can easily be done in audacity. We need to zoom right to the smallest bit and measure it’s length. I prefer to go down to the samples level because that’s more precise. Here we can see that we recorded with a resolution of 48000 samples per second and that our bit has a length of 26 samples. With some quick math (1/48000*26) we determine that the bit lenght is 541 micorseconds.

Transmitting

For this we need a 433MHz RF transmitter which supports ASK modulation and a microcontroller. For the microcontroller I used an Arduino Nano board because it’s easy to program. Connecting is just power, ground and a digital pin to the data line, and then you go straight to coding.

#define TX_PIN 3
#define BIT_PERIOD 528
#define BITS 145

int OnOff[BITS] =   {1,1,1,0,0,0,0,0,0,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,   1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0};

int Red[BITS] =     {1,1,1,0,0,0,0,0,0,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,   1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0};
int Green[BITS] =   {1,1,1,0,0,0,0,0,0,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,   1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0};
int Blue[BITS] =    {1,1,1,0,0,0,0,0,0,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,   1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,1,1,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0};
int White[BITS] =   {1,1,1,0,0,0,0,0,0,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,   1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0};
int SpeedP[BITS] =  {1,1,1,0,0,0,0,0,0,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,   1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0};
int SpeedM[BITS] =  {1,1,1,0,0,0,0,0,0,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,   1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0};
int ModeP[BITS] =   {1,1,1,0,0,0,0,0,0,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,   1,0,0,0,1,1,1,0,1,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,1,1,0,1,1,1,0,1,0,0,0,1,0,0,0,1,1,1,0,1,0,0,0,1,1,1,0,1,0,0,0,1,0,0,0};


void setup()
{
  pinMode(TX_PIN, OUTPUT);

  // This is just for debugging purposes  
  Serial.begin(115200);  
}

void send_command()
{
  Serial.println("Boom!\n");

  // the remote sends our signal at least twice. Sending 4 times seems to be the most reliable.
  for (int j = 0; j < 4; j++)
  {
		on_off();
  }
  // Here we make sure we are not transmitting anything.
  digitalWrite(TX_PIN, LOW);
}

void on_off()
{
	for (int i = 0; i < BITS-1; i++)
	{
	    if (OnOff[i] != 0) {
		digitalWrite(TX_PIN, HIGH);
            } else {
		digitalWrite(TX_PIN, LOW);
            }
	    delayMicroseconds(BIT_PERIOD);
	}
}

void loop() {
  send_command();
  delay(1000);
}

As you can see this sample code is very easy. I actually decoded all the buttons from my remote but I am sending only one with the test code. Also you can notice that the first 80 bits from our signal is a preamble and then it follows the specific command. Also, this remote sends the message at least twice and I found out that sending it 4 times is even more reliable.

Below you can see the fabricated message captured and analyzed and if you look carefully you can see there is a lot less ripple at the top of the signal. In effect we are actually sending a better signal.

Now you can imagine that it would be possible to extend this so that I would create a smart remote which turns the LEDs certain colors for various notifications such as when Forex prices reach a certain value or when a Skype messages is received. In addition to that we could consolidate a bunch of these remotes into a single smarter remote that also adjusts heating, opens the garage door or whatever else you might find interesting.

Conclusion

Hacking this RF remote took a few hours and if we can do it, everybody from the neighborhood can do it. All the materials required could be bought for $15. NEVER use cheap wireless remotes for controlling things that you care about!

IR remotes are way safer because they don’t transmit in the hood. The reverse engineering is similar but you need to be there physically.

Footnotes:

If you stare at this even more you could also draw the conclusion that it could be PWM with two different duty cicles of either 25% or 75%. Nevertheless the OOK modulation could easily accomodate this scenario because we just send 4 bits instead of one with a different duty cycle.

MicroSD card quick test

2015-06-15T00:00:00+00:00

MicroSD cards are everywhere these days but since these days it’s possible to film in UHD or in high speed with action cameras and phones it’s actually very important how quick these cards are at writing this data.

Of course these cards could also be used as storage for all those boards which run Linux, such as the well known Raspberry Pi but in this case a durability test would be just as important as a speed test.

Method

I took four of the MicroSD cards which I found in the house and which could be easily found in stores. I was only interested in the write speed to card so I used dd to dump data to the card.

dd if=/dev/zero of=/root/card/testfile bs=1M count=1024 oflag=direct

The card was tested in the SD/MMC port on the laptop, with a fast card reader in USB 2.0 and in USB 3.0. The last option was significantly faster so I used the card reader in a USB 3.0 port for all the tests.

The tests were run multiple times and the average was considered. It was proven that most cards have a very unpredictable performance. The minimum write speed can sometimes be half of the maximum speed.

Results

Lexar 633x	Sony	Kingston Class 10	Kingston Class 4
40 MB/s	17 MB/s	9.5 MB/s	3.5 MB/s

Conclusion

One card can be at least 10 times slower than another so it’s quite possible to get a card which is not fast enough for filming. The industry has the UHS class 3 marking, which defines the minimum writing speed of 30MB/s, but the indication is frequently misused. I recommend you get a card which was tested by someone and has proven to be good enough.

The writing speed for the SD cards can also fluctuate quite badly so performing only one write test is not enough. Out of these 4 cards I tested, Lexar 633x was the only one which has consistent performance and it was the fastest one.

PHP on Google App Engine

2013-11-14T00:00:00+00:00

You can host your PHP apps on the Google infrastructure and only pay according to how popular your app is. Let’s see how it actually works.

This sounds super nice, specially since it can even be free of charge for personal websites or provide automatic scalability for sites which plan to attract a lot of traffic.

How straightforward is that?

Well, not very. To maintain very high level of scalability your code doesn’t use a LAMP stack like you’re used to, but instead it uses a container which has some advantages and some limitations.

The main limitations:

Other computers can only connect to the application by making HTTP (or HTTPS) requests on the standard ports. The app container doesn’t even have a normal networking stack so it will communicate externally by doing URL Fetch
Applications cannot write to the file system. The app must use the App Engine datastore, memcache or other services for all data that persists between requests.
Application code only runs in response to a web request, a queued task, or a scheduled task, and must return response data within 60 seconds in any case. A request handler cannot spawn a sub-process or execute code after the response has been sent.
No way of using PHP modules which are not supported by Google App Engine.

The main advantages:

It’s very efficient as it utilizes the minimum amount of resources necessary to run your code, thus it can be very cost effective.
Having a minimal read-only environment where you don’t even have a shell makes things very secure both for your app and for Google.
Integration with other very nice services such as CloudSQL, PageSpeed and others.
Introduction of new “concepts” such as Task Queues which makes things more efficient.

Running off the shelf apps:

If you are interested in running something complex app like Joomla, Wordpress or many others, App engine is probably not the way to go, even though PHP is almost standard and they could run.

Specifically, these two are made such that you customize them with modules and templates from the admin panel by uploading and decompressing files on the file system, which is not possible here. Fortunately there is a workaround for that because you can do it in your local development environment and then redeploy the application. Actually, there is even a tutorial made especially for WordPress.

Also, all these have Media Managers for uploading photos and other files you offer for download on your site. For these you could have modifications done in the code or plugins which allow uploading files to Google Cloud Storage.

Running new apps:

If you plan to write a new app, indeed Google App Engine will almost constrain you from the beginning to make it scalable. With some of the limitations they provide you also get benefits, but certainly there are things to consider beyond that.

For example, if your application will get more complex, then you’ll want to start using Task Queues, not only because it’s a great concept but because you won’t have a choice. I bet Google uses this a lot with their apps to give the impression of everything happening instantly. Unfortunately, the downside is that using this creates vendor lockin and then you’ll be stuck with having to use App Engine forever.

Other considerations:

For MySQL, Google also has a separate service called Cloud SQL which is pretty nice. You connect to it using a socket connection and of course there are some decent limits in place. The Cloud SQL service should be fine for small to medium traffic levels where it’s not necessary to tune MySQL or to store lots of data.

While running your local development environment is the way to go in most situations, having to do that for simple tasks such as installing a theme to platforms such as Wordpress or Joomla is definitely not very convenient. I will have to do it on the computer where I have everything setup and it would be out of the reach for non-technical people.

The Google Apps admin interface is not done yet. It switches back and forth between the old and new depending on the service you access and some of the things are not integrated well and clear. While running my test Wordpress app I qualify for free of charge usage on App Engine but I need to enable billing for using Cloud SQL and Cloud Storage. These also seem to be cost effective for low usage but I can’t really figure out how much I’d have to pay if I have an app that gets 100 requests per day.

Conclusion:

App Engine for PHP seems awesome if you develop specifically for it and if you are fine with going on purpose into vendor lock-in. For other situations also consider the alternatives (shared hosting, virtual machines, etc.).

Update 1 (18 Dec 2013):

I figured out how much it costs to run the smallest setup for hosting WordPress. For the past month the cost was $15.25 in total from which the Google SQL D0 Service was ~$15. I didn’t make any requests to the site after testing it initially but CloudSQL charged me for ~75% of the hours because every few hours there were some read and write openration. Also, in the logs there are a few unknown errors associated with backups.