Composite video at variable refresh rate

I am currently troubleshooting the CRT monitor of an Olivetti typewriter that produces composite video at 70 Hz refresh rate. Weird? Indeed. Strange design choice, but I need to fix it to have a history-correct setup.

Since the ETV 2700 typewriter is quite bulky and takes up all my desk space I would like to have a small source of PAL composite video at 70 Hz to feed the CRT circuitry. I checked Arduino TVout library, which supports both NTSC (60 Hz) and PAL (50 Hz), but I see no way to fiddle with timings and even at 60 Hz it is already a stretch with very reduced resolution (I don't care).

Dead end? No, read on.

The clock on many Arduino-alike boards is set at 16 MHz, whereas the ATmega328 chip can be clocked up to 20 MHz. A program whose timers have been computed for 16 MHz at compile time, at 20 MHz it will run faster, therefore I will obtain a faster video signal.

So, this is the plan.

1. Write an ATmega328 with a demo program of TVout library, as in a normal Arduino-alike board
2. Test it against a known working screen that accepts composite video signal (probably your smartTV does)
3. Change the fuses of ATmega328 to use an external clock
4. Feed a variable frequency clock signal to get a linearly controllable composite video signal!

For a 70 Hz PAL I need a clock of 22.4 MHz, that the ATmega328P is likely to withstand peacefully (check online discussions about overclocking those Atmels). I will decide whether use a fixed clock source or some DDS with TTL output. In the latter case I will get a PAL signal with variable refresh rate from 1 Hz up to the maximum overclocking frequency of the microcontroller.

I need this tool because I also have a bare green phosphor CRT with control circuit that doesn't sync on the standard PAL. Who gave it to me mentioned some "trick" used by the manufacturer of that industrial system to do a form of vendor lock-in on spare parts or avoid clones, and a non-standard refresh rate now makes sense.

No output from Arduino TVOUT examples

I am in the process of reverse engineering an industrial monochrome 12" monitor, mainly trying to figure out the pinout to drive it.

My initial analysis of the circuit, based on TDA1175 and TDA1180, concluded that it needed a composite video. So I programmed the PAL sample of the TVOut Arduino library on a Nano (clone) and got nothing. I got no signal on the TV, and nothing was moving under the oscilloscope scrutiny.

The library is scarcely documented, but reading here and there I understood that the resulting circuit was originally meant to produce overlay text on an existing video stream. This means that the Arduino sketch needs a sync input to stay ... in sync. Without an input sync, there's no composite output (this was confirmed later).

I checked the code and in the setup() portion there is this initialisation call:

TV.begin(PAL|OVERLAY);

Well, changing it to remove the OVERLAY requirement like this:

TV.begin(PAL);

Recompile, reflash ... and the composite video comes out.

Green phosphors here I come!

The 4-weeks challenge: deliver a Nixie clock from scratch

Last weekend of October a curious teenager guest noticed the Nixie clock in our living room. The most eye-catching element was the short depoisoning routine that runs once a minute. B-5750 Nixies have their numbers 0-to-9 back-to-front, which is an even more eye-catching feature.

So I quickly explained him and his family some basics of these lovely tubes, showed them my lab/workshop/messy room and of course I told them I had designed and built that clock.

The next day I came up with a self-challenge: design and build a fully functional Nixie clock that I could give the teen at our next (and probably last for a very long time) meeting four weeks ahead.

With a small personal "library" of hardware design and AVR firmware I was quite sure I could get over all the small challenges inside this project:

• design a working circuit and receive the PCB from the fabhouse
• sub-task: fix the KiCAD footprint for the chosen ZM1020 Nixie
  
• design a suitable case and get it 3D printed (this then turned to laser cut)
• build it without easy access to my lab for the same period of time
• write a user's manual
  

The PCB was designed with KiCAD and etched by JLCPCB. To save on board space and stay into the chosen round design I used a bare AVR ATmega uC with its internal 8 MHz clock; it also drives the voltage booster. On the board I included an ICSP header which is very useful if you're debugging or adjusting the firmware code. I used a ZM1020 round top view tube

While waiting for PCBs to arrive I learned how to use OpenSCAD to design the case, which is plain geometry applied to programming. I also risked to have no AVR microcontroller for the clock as the ATmega48 doesn't have enough program memory (or I would have needed to do heavy optimizations). I managed to unbrick a couple of ATmega168 that are enough for my firmware (wrong fuse settings).

The circuit diagram was correct. The PCB was suitable, meaning I kept HV and LV separated enough. The laser cut case (two plates) was perfect and I picked it at 3.5 weeks into the challenge. In the last week I did some firmware corrections and upgrades and today the clock has been delivered to a happy teenager.

Here it is!

Single Digit Nixie Clock with ZM1020

Arduino based AVR ATmega fuse doctor

Given the ongoing semiconductors shortage and needing urgently a bare ATmega168/P/328/P chip, I had to reset two 168's unresponsive to the usual avrdude programmer command.

Actually I could have spent about 10€ to buy an ATmega328P rather than spend two hours assembling the fuse doctor.

According to my own blog posts, back in 2010/2011/2012 I had already built a fuse doctor, but the link doesn't work anymore. Well, I found this Fuse Reset by Thuta Kyaw on Instructables. It uses an Arduino Nano, which I still had at home. This time I decided to do a permanent build, in case I will need it again 10 years from now.

My build of Thuta Kyaw's Fuse Reset.

Building it with wires requires patience and a steady hand. There is no radiofrequency involved, so there's no need to do careful planning of the layout.

Operation is easy. Fit the ATmega patient in the socket, apply 12V, wait few seconds for the LED to switch off. Enjoy.

Milliwatt meter with AD8318 inconsistent readings

First of all: I do not own a calibrated generator in the frequency range of the AD8318 chip. The closest approximation is a Kenwood handheld that emits about 50 mW at 450 MHz. That is my source.

With 30 dB attenuation I could bring that signal down to about -13 dBm that the AD8318 reads as 0,904V, which is in the ballpark of -16 dBm according to figure 4 of the datasheet.

What I could confirm is the -0.025 V/dB slope by adding and removing attenuators. This let me compute the 0V intercept, but the Arduino firmware does something weird and tells me I am feeding a much higher power.

There also is a dependency on impedance matching at the AD8318 board input, since swapping my attenuation chain changes the detected value, appreciably. 

The NanoVNA did help to confirm my attenuation chain value and impedance mismatch.

For the time being, since I lack too much instrumentation to turn the circuit into something precise, I will use its output voltage to peak an RF signal and I will not care of its actual Wattage (trimming 10 GHz filters on PLL modules).

Milliwatt meter with AD8318 Arduino code

I have published the Arduino+AD8318 milliwatt meter code on github. I have changed the slope (can be re-computed with calibration), intercept points and the table with correction factors.

Note that I use LiquidCrystal_PCF8574 library for driving the I2C 16x2 display to avoid incompatibilities between various LiquidCrystal_I2C versions (same name, different API!).

The hardware circuit around Arduino is the same of PA0RWE's design.

I still get too high power readings with about 5 mW UHF at AD8318 input and I suspect it's because the error is very high, at least according to the datasheet graph (900 MHz reference). 

Typ. AD8318 response at 900 MHz.

Milliwatt meter with AD8318

Pushed by a friend who needed help with the firmware of a AD831x milliwatt meter, I (think I) decided to build a real circuit around the AD8318 module I have.

I used it for making differential power measurements of a 10 GHz generator to get the maximum juice out of it, so a voltmeter was enough to spot the lowest output voltage (the output is -25mV/dB, so the lower the better).

Nevermind. I have everything at home to build the whole power meter, so why not? I'm using PA0RWE Arduino firmware that is freely available and quite comprehensive. But his firmware was written for the AD8317, which has a different output slope (-22mV/dB) and different non-linearities.

I think that the slope value could be changed with a recalibration of the meter, but not the correction factors table. That's why I produced a different firmware with the right values for AD8318 (and I2C 16x2 display only) that will be up on my github repositories soon.

Again problems with LiquidCrystal_I2C Arduino library

I am having issues again with third party Arduino code that uses the LiquidCrystal_I2C library. The code was written in 2015-2017 and since then the said library has been hijacked, abandoned and is not backward compatible. In other words: it doesn't work. But I mostly do not like the "hijack and abandon" part.

The second part of the problem is using a mjkdz I2C adapter that reacts on address 0x20 but has a different wiring to the display, let alone the IC part number scratched off. This adapter needs a flexible library that allows remapping the PCF8574x outputs, which is not the case for most common LiquidCrystal_I2C. Or custom code and direct I2C drive. No thanks.

Conclusions of few hours spent debugging this stuff are:

• throw away mjkdz modules so I don't fall again in the same mistake few months from now;
• use LiquidCrystal_PCF8574 to avoid ambiguities and LiquidCrystal_I2C hijacked libraries: they are 95% compatible (just chance the instantiation and call to begin method)
  

Surplus GPS "mouse" receiver and AVR input protection

Somewhere in the back of my mental to-do list I have a project with GPS, NMEA and precise clock (as in hh:mm:ss, not in the digital electronics sense). While I could use the ubiquitous Wi-Fi connection to query an NTP server, I prefer a solution that gets the timestamp without needing a user/password. As a bonus, it tells me the position as well.

A local HAM sells surplus GPS-only receivers (no GLONASS, no Galileo). They require 5V (later found that the range is 3.5V to 5.xV) and speak out NMEA at 4800 baud 8N1. The module inside is one of the GlobalSat series, probably BR-355S4. At least that model number provided a spot-on description of the pinout and existing wiring.

I wired it to a serial TTL/USB adapter and the dongle kept disconnecting from the computer. Both dongles I own. Weird. I needed to see what was going on, so I fired up the oscilloscope. Surprise! The NMEA data out of the surplus GPS dongle is RS-232, with -10/+10V! BTW, I couldn't get the data decoder of the Hantek scope to decode anything out of it.

In order to fix the signal levels I assembled a simple BJT adapter, which also inverts mark/space as in RS-232 logic "mark" (or logic "1") is the negative voltage and "space" (logic "0") is positive WRT ground. In TTL serial, "1" is 5V and "0" is 0V. This let me use the dongle and a GPS decoder software on the computer.

The adapter is 10k resistor into the base of any BJT (BC547, 2N2222, whatever). Emitter to ground. 4k7 from +5V to the collector. You can add a diode between ground and the base, with the cathode on the base side. The diode limits the Vbe reverse voltage to 0.7V. TTL output is at the collector.

The seller told me he could read the data with an Arduino just fine. How comes? Well, many Arduinos use an Atmel AVR ATmega328 processor, whose inputs are protected like this:

From an Atmel datasheet, it's all inside the chip.

 

Those two diodes clip the -/+10V right into the AVR microprocessor and everything looks fine, but might break in the future.

Even if I will use the GPS mouse with an AVR micro, I will include the BC547 adapter.

Eight TIL308 displays in a clock

I would not say that the long lockdown and alike has allowed me to reach the bottom of the to-do bucket, but it slowed down the consumption of projects in the waiting list.

When I spend the whole work-day at the computer, writing firmware in the remaining hours is not so pleasant. In the Xmas break I finished the code for the clock that uses eight Texas Instruments TIL308 vintage LED+logic displays.

Final firmware onboard! I can solder the remaining capacitors to complete symmetry.

Hardware design files and software source code have released to github.

This clock is self-standing if the RTC module is inserted perpendicular to the display board. Adjustments are accomplished through a linear potentiometer and a push-button. With a software trick ;) the same analog input is used both for reading the light-dependent resistor to adjust display luminosity and the push-button. I had to adjust resistor values and add a couple of them outboard.

I like these clocks to do something unexpected, so every 60" it might display a word built using available letters (or lookalike) and numbers:

// Available letters are:   ABCEFIOSG-
// Mapped to these symbols: A8CEF1059B  (mind the mix of letters and numbers!)
// Plus space ("D") and all the numbers are at your disposal!

TIL308 is not a full hexadecimal display because it maps "B" to "dash" and "D" to whitespace. This reduces the possibilities of long words and exercises your fantasy a bit further to find meaningful text to display randomly. Don't forget you can use multiple languages for your words!

A nice addition would be to be able to add words at runtime (and store them in EEPROM), rather than at compile time. That means more firmware to write ...

When you think you've got enough parts to complete a project

... and realize you ran out of IC sockets!

That is what happened when I started building the first display board (...clock...) with eight TIL308 displays. I had many sockets around but not enough with 16 pins. I know I can use pin headers but I would like to keep a consistent look. I had to desolder sockets from old boards I built 20+ years ago.

Nevermind, the display board is now alive. I ordered 5 of them from JLCPCB. I have used all I/O pins of Arduino Nano. While I wanted to be able to control the brightness of each digit, I had to resort to group them in couples. I will complete one board and see how it looks if some displays are left out: the two outermost, #3 and #6.

Because the lack of inputs I grouped together (in series) the incoming light detection (day/cloudy/night) with the user interface pushbutton and solve the puzzle in software. Another ADC-only input is for the linear potentiometer which will be used as in the 4x TIL311 clock board.

Hardware plans and firmware will be published on githib.

DOS saves - A tale of retrocomputing

It is early 2020 AD and I am developing some Arduino firmware for a friend. I chose Arduino for several reasons, one of them is that the friend in his 70's can program Arduino clones using a legacy PC that runs Windows XP. You know, HAM and electronics enthusiasts have a bunch of equipment that requires software/drivers that have never been updated/ported to newer operating systems: so why change it, when it works?!

My computer runs a supported Ubuntu distribution and the latest Arduino IDE. Actually our Arduino IDEs are not too far apart version-wise, so I started sending him updated .ino source code.

First problems appeared with I2C LCD driver libraries that misbehaved: there are too many with the same name and you can't know which one is being used at compile time. This forced me to find an I2C LCD library with a different name than LiquidCrystal_I2C, which is actually better than others:

#include <hd44780&.h> // main hd44780 header

#include <hd44780ioclass/hd44780_i2cexp.h> // i2c expander i/o class header

This solved it, but the same firmware worked differently on his hardware than mine. What broke was a function that picks a random value and looks it up in a static table, which went out of bounds. This happened at the second iteration of the main loop() and then the firmware basically crashed.

Since it didn't happen on my side, one solution was to send him the compiled firmware (.hex) and burn that directly. It is fairly easy: have Arduino IDE print out the avrdude programmer command and replay it with the .hex that you want to load. I planned to do it over TeamViewer, as I had done few years ago.

Second problem: his WinXP has TeamViewer 10 and cannot be upgraded, while on my Ubuntu I got TeamViewer 15. They don't talk to each other. Fair enough. TeamViewer guys let you download old versions (excellent!), so I installed 10 on my Ubuntu, but it still refused to connect. No time to troubleshoot that, so I switched to Plan B which required a bit of preparation: blindly write down the instructions and have my friend do it without my real-time assistance.

Once I got from him the complete avrdude command (in form of screenshots because you cannot copy the debug output in Arduino IDE!), I needed the safest way to get him on the right track. Consider that I do not have a Windows machine to try the procedure beforehand.

So, I produced a DOS batch file hoping that the Arduino board would end up always on the same COM port. The simplest thing was to put everything in C:\ so to avoid long paths. A .bat file cannot be sent over email, so it was a .txt then renamed. Once I explained to click on the batch file, nothing happened: the DOS window just flicked quickly. I needed to see the error message.

We worked out together an old DOS trick: pause the execution of the batch. He remembered the right command was "pause", so he did everything on his own to edit the file, rename and run again. I could now see (a screenshot) that I had misread an avrdude flag in "1" rather than "i". So, one more edit and run and .... mission accomplished! DOS saved us.

Even better, he managed to program a second Nano board that ends up on COM10 simply editing the batch file.

My binary firmware works as expected on his hardware, no more array out-of-bound and firmware crashes. His Arduino installation probably has stale libraries or doesn't work properly on the experimental now-dead WinXP 64 bit.

For the next updates I will send him the .hex microcode and all will be fine. And if something else goes wrong, there is always DOS!