Handshake LED flashlight

Had gotten a couple of these gadgets by General Electrics during Winter Olympic Games in Torino 2006 (that's 6 years ago!): no matter how long I had shaken them, I never saw the white LED lit. Time to take a peek inside.

In there I found a well packed coil into which a magnet slides through with the shake movement; a 4x1N4148 fullwave bridge rectifier, a 0.22F 5.5V capacitor and what looks like a white LED. No resistor in series with the LED, so perhaps it didn't survive the first time 5.5V were applied?

I will check all parts with a DMM, but meanwhile I had the usual bizarre idea: what if I turn the coil into a MW resonating circuit and let the capacitor recharge with the environment RF? Otherwise it will become a simple - and smaller - LED flashlight charged via USB. :-)


Update.  All parts inside the original flashlight worked. Maybe there was a broken PCB trace, because voltage did not reach the 5mm LED. The supercap and the LED have now been wired to an USB plug making a USB-rechargable LED flashlight. It will be featured on this blog in the next days.

23cm downconverter from analogue Sat-TV receiver

If you take apart an old analogue satellite TV receiver you might find leaking electrolytic capacitors and what looks like a shielded RF module.

Well, it actually IS a tuneable intermediate frequency of some sort, working across the 23cm HAM band: 900 to 2000 MHz, more or less. It outputs video baseband, so somewhere between 0 and 5.5 MHz.

Why not take control of the module and turn it into a 23cm-to-HF downconverter? With just one setting of the PLL you would be able to tune around 5.5 MHz of SHF. Yeah, sure.

My IF module contains a TSA5055 "2.65 GHZ Bidirectional I²C-bus Controlled Synthesizer" (PLL), and I²C can be easily mastered with modern microcontroller. But but but ...

The whole IF module has been designed to work with strong broadband signals: the sensitivity of my specimen is -60 dBm (pretty deaf!) and there are no info on phase noise. I would need a powerful RF preamp in front of it, and it is not suitable for SSB/CW work. Project idea discarded.

I am left with the PLL system, tuneable in 125 kHz steps between 1 and 2.65 GHz. It might work as a signal generator, so I will not throw it away, in case one day I will get into the microwave mindset... too bad the prescaler output is not available on one pin, otherwise it could be placed in front of a frequency counter.


Next!

How to find out XTAL frequency with MFJ-259

The simplest way to find out the resonant frequency of a XTAL (or "crystal" or "rock") is to oscillate it. What if you do not have (yet) a simple crystal tester circuit and a frequency counter (or an HF receiver)?

I was in a hurry and I could not assemble a simple oscillator. Then I turned around and saw the MFJ-259 antenna analyzer... would it work?

I picked a known frequency XTAL and held it at the antenna socket: SWR and Z were as if I had connected nothing. Then I swept the frequency close to the stamped one and I could clearly see the impedance dip while passing over. I could actually see two distinct dips, probably series and parallel resonance. Nice!

It is important to look for the dip on the SWR analog meter, not the display or impedance meter. The frequency knob has to be rotated VERY slowly and remember that the MFJ-259 VFO is pretty unstable. Rotate so slowly that, for an unknown rock, you would probably have enough time to heat up the soldering iron and throw together a simple oscillator!

Bluetooth CAT interface for Yaesu 8x7

I am not a fan of Computer Aided Transceiving (CAT), that's why I developed an embedded system to control remotely my FT-817, but I could not pass on this one.

This is a Bluetooth(tm) CAT interface for FT-817, FT-857 and FT-897 (possibly FT-100 too). It plugs directly into the ACC socket on the rear of the radio, it is self powered and it should be the definitive solution to wrong/missing/unrecognized drivers for USB-to-serial adapters, cables running around the shack, ground-loops,  ...

CAT BT adapter on FT817 with internal battery

A LED lits when the pairing is complete and the PC is connected, thus the serial channel is open and ready for use (I know I should have used a blue LED ;-)). I have programmed it to present itself as "FT8x7-CAT" and tunnels the serial interface at 9600 baud.

I could use the CAT signal two rooms away in near line-of-sight, which is more than 5m.

This homebrew accessory is 2cm wide and 5cm long. The current drain has been measured to be:

• ~40mA when not paired (and no other BT devices around, weird)
• ~10mA when paired and not sending data after few seconds
• ~30mA when paired, sending data and few seconds thereafter

It should work on Linux and MAC too provided there is a CAT control software. The Android smartphone pairs with the BT adapter but then it doesn't know what to do with it

I also had a plan: let my FT817 accessories go wireless. This would require an independent power source for the keypad or (interactive) frequency reader, A.K.A. batteries. But besides being a nice system integration exercise, would that be really useful?

Update 2012-03-21, see the video of the interface in action!

How fast does FT817 react to CAT commands? Part 2

Even thought I had all signals from FT817 that it was not accepting data faster than 1 : 90ms, I wanted to be sure that the radio was not tuning on the missed "steps" and simply not updating the display.

As a mater of fact, the main dial knob accepts updates much faster than one every 90-100 milliseconds.

I set up a simple test using a real-time spectral analysis software (Argo in this case was more than enough), and tuned a carrier at 500 Hz audio. Then let my CATspeedTest firmware run 10x 100 Hz increments at decreasing intervals. The first screen capture compares side-by-side the automatic re-tuning result at 90 and 80 ms intervals:

How to read the picture. Time goes up Y axis: the lower the older. X axis has audio frequency. Color from dark black to bright white indicate signal intensity. So in the 90ms square box, it begins at 500 Hz, counts 10 steps to 1500 Hz beat frequency: 9 dots are clearly visible (plus the last -10th- jump becoming a straight line). The 80ms box shows that the first increment is accepted, then the second is skipped, third accepted and so on. Since only odd commands are accepted, the end frequency is 900 Hz above the starting point (400 + 900 = 1400 Hz) instead of +1000 Hz.

The test continued and at about 30ms intervals between increases it was still taking odd command sequences. At 20ms intervals it accepted one every three commands, so +100, +400, +700 and +1000 Hz ending up at the correct VFO frequency but skipping too many steps: imagine what would you miss if the required step was 500 Hz or 1kHz.

The upmost trace in the second picture shows what happens at ~10ms delay, where even more steps/commands are lost.


My guess is that the FT817 CPU is polling the CAT serial line every 90ms or thereabout. Nothing is mentioned in the documentation, except for a maximum time between bytes of each command sequence: "All commands sent from the computer to the transceiver consist of five-byte blocks, with up to 200 ms between each byte."

How fast does FT817 react to CAT commands? Part 1

While writing and debugging a Frequency Reader firmware with support of a tuning knob, the test-team found out that the FT817 was not able to keep up with fast spins. When the external knob spins, a new frequency is sent over the serial CAT interface. If data is sent too often, the FT817 ignores it. Setting baud rate to 38400 instead of 9600 did not show any improvement.

The annoying part of this behavior is that the FT817 is "left behind" if the external knob is spun fast and abruptly stopped. This causes a mis-alignment of the external display and the actual tuned frequency. Any re-alignment software procedure would either re-tune the radio or change the external display, which does not look nice.

So I came up with a new software routine that does not send data too often, but it uses the fast rotation to increase the step (right now the increase is linear). But but but: how fast does FT817 accept a new frequency, without loosing a bit?

So I wrote a simple firmware that sends 200 frequency increments at a steady rate, each loop with a shorter delay between updates. Starting at 100ms (+ some uC time) down to 0ms, the "safe self-imposed delay" was determined to be 90ms (+ uC data processing, less than 1ms). Please note that this delay within the radio CPU applies to all those computer programs that interact with the FT-8x7 via the CAT interface (excellent HRD probably being the most popular).

Given the result of this simple experiment, the Frequency Reader Knob will send updates at a safe rate of 1 every 100ms. And vary step accordingly.


The "CAT reaction speed test" firmware is based on the Frequency Reader circuit, it requires at least an ATmega48 chip and it is available on request for those that want to repeat the test on their equipment (FT-8x7).

UV-3R FAQ article

This post is mostly for Italian readers.

Un mio articolo sulla stesura della FAQ UV-3R è stato pubblicato su Radio Rivista di febbraio 2012.

A short article I have written about the making of UV-3R FAQ has been published on the Italian magazine "Radio Rivista" February 2012.

Italy is on 70 MHz for 2012

Italian HAMs have been authorized to operate on 70 MHz from Feb 1st to Dec 31st 2012. Conditions remain unchanged, so:

• 70.100 MHz +/- 12,5 kHz
• 70.200 MHz +/- 12,5 kHz
• 70.300 MHz +/- 12,5 kHz

All modes, 25W EIRP. Excluding areas of 30km from the national borders.

CD-R and time

I had to burn a CD-R last night. I rarely do it, maybe twice a year. I located the old 50 pieces tower, which was sitting in a shady shelf inside the flat, cover still there to keep dust away from the content.

Left: not working. Right: ok.

The first CD I picked was not recognised by the laptop CD-ROM reader/writer (made in 2004). It looked empty, but it was late and I moved forward to the CD sitting in the second place from the top. First thing I noticed was they had a different color: the topmost Sony 700 MB silver CD-R made in Malesia in 2003 was looking gold-ish (oxydated?), while all other positions retained the expected color.

Needless to say, the normal-looking-color CD-R was recognized, written and verified correctly. A second copy (3rd topmost position in the tower) was equally successfull.

Most of my recorded CD's at home come from the same tower so I will inspect them, compare colors and read the data.

So far I can conclude that a 9 years old virgin CD-R is still good for storing new data.