A Tale Of Two Pulse Modulators

In the realm of test equipment, there are a number of items that you don’t know you need until you need one. That’s probably the case with the HP11720A pulse modulator. [Tom] acquired two of these even though, by his own admission, he had “no need for these things.” We’d like to say we don’t get that, but — alas — we do.

The good news, though, is he used one of them to measure the quality of some coax cable and shared the exercise with us in the post and a video, which you can watch below. The device can generate pulses with extremely fast rise and fall times (under 10 nanoseconds) at frequencies from 2 to 18 GHz. These were often used in pulsed radar applications and probably cost quite a bit more new than [Tom] shelled out for them.

Continue reading “A Tale Of Two Pulse Modulators”

A Literate Assembly Language

A recent edition of [Babbage’s] The Chip Letter discusses the obscurity of assembly language. He points out, and I think correctly, that assembly language is more often read than written, yet nearly all of them are hampered by obscurity left over from the days when punched cards had 80 columns and a six-letter symbol was all you could manage in the limited memory space of the computer. For example,  without looking it up, what does the ARM instruction FJCVTZS do? The instruction’s full name is Floating-point Javascript Convert to Signed Fixed-point Rounding Towards Zero. Not super helpful.

But it did occur to me that nothing is stopping you from writing a literate assembler that is made to be easier to read. First, most C compilers will accept some sort of asm statement, and you could probably manage that with compile-time string construction and macros. However, I think there is a better possibility.

Reuse, Recycle

Since I sometimes develop new CPU architectures, I have a universal cross assembler that is, honestly, an ugly hack, but it works quite well. I’ve talked about it before, but if you don’t want to read the whole post about it, it uses some simple tricks to convert standard-looking assembly language formats into C code that is then compiled. Executing the resulting program outputs the desired machine language into a desired file format. It is very easy to set up, and in the middle, there’s a nice C program that emits machine code. It is not much more readable than the raw assembly, but you shouldn’t have to see it. But what if we started the process there and made the format readable?

At the heart of the system is a C program that lives in soloasm.c. It handles command line options and output file generation. It calls an external function, genasm with a single integer argument. When that argument is set to 1, it indicates the assembler is in its first pass, and you only need to fill in label values with real numbers. If the pass is a 2, it means actually fill in the array that holds the code.

That array is defined in the __solo_info instruction (soloasm.h). It includes the size of the memory, a pointer to the code, the processor’s word size, the beginning and end addresses, and an error flag. Normally, the system converts your assembly language input into a bunch of function calls it writes inside the genasm function. But in this case, I want to reuse soloasm.c to create a literate assembly language. Continue reading “A Literate Assembly Language”

The Bicycle (and More) Explained

They say a picture is worth a thousand words, but an animation, then, must be worth a million. Make that animation interactive, and… well, we don’t know how many words it is worth, but it is plenty! That’s the idea behind [Bartosz Ciechanowski’s] blog where he uses clever interactive animations to explain the surprisingly complex physics of riding a bicycle.

The first animation lets you view a rider from any angle and control the rider’s pose. Later ones show you how forces act on the rider and bicycle, starting with example wooden boxes and working back up to the original bike rider with force vectors visible. As you move the rider or the bike, the arrows show you the direction and magnitude of force.

Continue reading “The Bicycle (and More) Explained”

DIY Metal Detector

If you want to get rich by hunting with a metal detector, you might want to consider how much you invested in the hardware to start with. Finding a tin can with a $200 detector might not make economic sense. But building a metal detector yourself doesn’t have to be hard, as [Mirko] shows in a recent post. His STM32-based pulse induction metal detector looks good and works well, as you can see in the video below.

[Mirko] reports that the device can detect a coin at 30 cm and a large metal object at more than 80 cm. The project uses the Arduino IDE and a Blue Pill STM32 module. The project looks good with an LED module and a rotary encoder to set sensitivity.

Continue reading “DIY Metal Detector”

Linux Fu: Supercharge Bash History

Having a history of shell commands is a great idea. It is, of course, enormously handy when you have to run something repetitively or you make a simple mistake that needs correction. However, as I’ve mentioned in the past, bash history isn’t without its problems. For one thing, by default, you don’t get history in one window from typing in another window. If you use a terminal multiplexer or a GUI, you are very likely to have many shells open. You can make them share history, but that comes with its own baggage. If you think about it, we have super fast computers with tons of storage compared to the “old days,” yet shell history is pretty much the same as it has been for decades. But [Rcaloras] did think about it and created Bashhub, a history database for bash, zsh, and probably some other shells, too.

Command detail screen

You might think you don’t need anything more than what you have, and, of course, you don’t. However, Bashhub offers privately stored and encrypted history across machines. It also provides context about commands you’ve executed in the past. In other words, you can see the directory you were in, the exact time and date, the system you were on, and the last return code of the command.

Continue reading “Linux Fu: Supercharge Bash History”

Linux Cell Phone? Build OURPhone

[Evan] couldn’t find a phone he liked, so he decided to build his own. There are advantages and disadvantages, as you might expect. On the plus side, you have the ultimate control. On the negative side, it doesn’t quite have the curb appeal — at least to the average user — of a sleek new cell phone from a major manufacturer.

The phone uses a Raspberry Pi, along with a 4G modem and a 480×800 touchscreen. There’s a laser cut box that measures 90x160x30 mm. For reference, a Google Pixel 7 is about 73x156x9 mm, so a little easier on the pocket.

But not one the pocketbook. The OURPhone only costs about $200 USD to build. There are trade-offs. For example, the touchscreen is resistive, so you’ll want a stylus (there’s a slot for it in the case). On the other hand, if you don’t like something, it is all there for you to change.

Obviously, a better screen would help. Thinner batteries might be a good enhancement too. But that’s the beauty of an open project. You can do all these things and more.

We wondered if you could get one of the “mobile” Linux editions to run or even Android. It seems like the hardest part is coming up with a sophisticated enclosure.

Hacking Hue Lightbulbs

What do you do with a Hue smart lightbulb? Well, if you are [Chris Greening], you take it apart and get hacking. If you ever wondered what’s inside, the teardown is pretty good, and you can also watch the video below. The potting compound, however, makes a mess.

Once you get the potting undone, there are three PCBs: an LED carrier, a power supply, and a logic board. The arrangement of the LEDs is a bit confusing, but [Chris] explains it along with providing schematics for all of the boards.

Continue reading “Hacking Hue Lightbulbs”