Calibrating AVR RC clock using a frequency counter (idea)

Not that I want to calibrate all my AVRs' internal RC clocks, but I want to test this non-automated procedure. These microcontrollers can be programmed to output a buffered version of the master clock (+ prescaler, if enabled) to the CKOUT pin. So, why not measure the output with a frequency counter?

Also, section 8.12.1 of ATmega168 manual describes the OSCCAL register, which should allow to change RC frequency during program execution.

So, why not build a simple firmware that sweeps through the OSCCAL value? Then with a big red button the operator interrupts the sweep when the frequency counter reads the desired value. Last but not least, either use an LCD to display the result or store the value in the onboard EEPROM for future reading.

UV-3R has a FAQ

With a fast collaborative approach, in less than 24 hours a FAQ for UV-3R has been compiled and published in the UV-3R Yahoo! Groups files area. With 11 pages packed of information, the FAQ already looks like an UV-3R Bible ;-) And it is still incomplete.

UV-3R received carrier on 156 MHz

If you let the "R" scan through the entire VHF band, it will stop on 156.000 MHz, whatever antenna you try, change location, ... S9 signal.

The "R" has an internal oscillator at 26 MHz. Since it is an SDR, it  runs the receiver with square waves, so you're hearing the 6th harmonic of 26 MHz. There might be one or two on UHF too (the proof is left as an exercise for the reader).

By the way, the diagram published on the Yahoo! Group mentions a 13 MHz oscillator,  while I'm holding right now a UV-3R board with 26000 (kHz) oscillator right next to the RDA chip. I've also found a difference on VHF and UHF mosfets, to be documented in another post.

Wrong 1wirecount result

If the 1wirecount function returns a wrong (higher) number of devices, try decreasing the pull-up resistor between Vcc and the data line.

Just tested on my DS18B20 network :-) Going from 4k7 to 2x4k7 in parallel solved the device enumeration error.

Failing button cell batteries

I had seen a leaking button cell battery, but never found a jumping one. The AG10 cell on the left (picture) was found 20cm away from its cousin, that's where it was put to rest after removal from a toy pen.

It felt fat and round, and still gave some energy to power my Joule Thief, but then overnight it probably exploded:

There is no leak of any substance and the process has apparently stopped by now. Other two specimen removed from the same toy do now show the same failure signs.

FT-8x7 CAT Emulator - power budget

One of the adavantages of not relying on the real FT-817 for testing an I.F.R. is the fact that it is easier to measure current consumption. I plugged a milliAmp meter in series with the 12Vdc line before the Emulator and measured:

• FT-8x7 CAT Emulator + IFR: 50 mA @12V
• FT-8x7 CAT Emulator alone: 17 mA @12V

So the I.F.R. with a white/blue LCD and my choice of resistor values (for backlight intensity) drains 50-17 = 33 mA.

It's not much (could be lower?), the whole equipment could be powered off a 9V rechargeable battery or a 7.4V Li-ion cell.

FT8x7 CAT Emulator: success

As announced few days ago, I have developed a simple and cheap hardware that emulates the CAT interface of ACC port of a FT-817/FT-857/FT-897 transceiver.

This is useful for testing devices without having a real FT-8x7 at hand. A short circuit on the accessory will not damage radio internals. A software bug will not keep your radio on hold or ruin its settings while you are busy developing or testing your solution.

The FT-8x7 CAT Emulator is based on a Atmel ATtiny2313 microcontroller (the same of my FT-817 keypad) and it accepts all standard documented CAT commands at 9600 baud. Feed it with 12V and the Emulator will power your accessory too, as if it were a real FT-8x7 transceiver.

A LED blinks when a 5-byte sequence is received at the emulator side.

Schematic diagram for IK1ZYW FT-8x7 CAT Emulator

The emulator handles two VFOs with frequency and mode and the get RX/TX status commands. Other Yaesu officially documented commands have been implemented but do not return data to the CAT accessory, so their usefulness is currently limited.

At powerup the Emulator initializes its internal VFO representations on 14200 USB and on 145500 FM. You may QSY using your accessory (keypad, FR, IFR, computer control software, ...) and the new value will be kept until power off. Since this is a tool meant for testing devices, it always powers up in a known VFO state (14200 USB and 145500 FM).

RX and TX status are returned with a static string, just to give some valid data to the CAT accessory to play with.



Conclusion. This is a blind emulator of the FT-8x7 standard CAT protocol. It feels like hiding your transceiver in a black box and controlling it with an external accessory. But it is indeed useful for testing all sort of CAT devices without having an FT-8x7 at hand. Firmware for ATtiny2313 will be available through my pages soon (the impatient can send me an email request).

AVR board not powering off

... or why does my Attiny2313/ATmega168 board stay alive when I flip the switch?

That's the case with my FT-817 keypad&I.F.R. if a SPST switch is used on the Vcc line.

The block diagram above illustrates the situation: if board 2 (right) is switched off and board 1 (left) is powered, a "high" signal on any input pin of board 2 will keep it awake and running. The board on the right goes off only if the TXD-to-RXD line is interrupted as well. Why so?

I initially thought the culprit were the pull-up resistors, so I disabled them all around the UART: board 2 was still up (LCD backlight on, LED lit, uC code running, ...).

I asked around and I was pointed to the right direction: AVR uC input pins protection diodes! I had somehow overlooked them on the mega168 datasheet.

They are there on every single I/O pin, so there is no way I can live without a DPST switch on both Vcc and TXD line. All other (hardware) workarounds mean more components.

Like a small forward voltage diode between 78L05 and Atmega168 that would prevent the LCD to stay up, but the uC would still run the code. Or a line driver chip in front of the ATmega168.

Let's keep things simple and physically interrupt both Vcc and TXD lines (RXD pin on board 2).