So, your expensive piece of technology had a bath?

Picture by Patrick Hoesly.

It happens. Sometimes technology packed expensive electronic equipment (decide to) get in touch with liquid substances. As many online sources will tell, hope is not lost the very moment the two incompatible objects get in touch. I will not reveal any new method, just what I have done.

Let us consider the case of a smartphone (Galaxy S) being dipped in clean drinkable water.

First of all: read the picture on the right.

As soon as the bath is over take the device apart (battery, main body, back cover, memory card, SIM card) and dry it wth towel/napkin. Don't shake it, but turn it around to get the water out of holes such as the earphone and USB sockets. Then let it dry for at least 48 hours. Be patient: you aim to recover your data from the device, don't you? This should be your first target. If your device works afterwards then it is luck or well designed technology. Or a combination of both.
I dried mine in a bowl filled with (uncooked!) rice close to a heat radiator. Temperature should have peaked to more than 40°C, but heat is not a must: leave it longer.

When you are ready plug the battery and keep your fingers crossed. If the device powers up be prepared to extract your data using the standard method.


Additional notes.
Some online resources mention water-sensitive labels all around these expensive mobile devices. I haven't been able to spot them on the external body of the i9000. Anyway do not lie to the customer service if you are going to return it.
If your device allows to use an external memory card, it is probably wise to save your mobile-authored data on it, or take periodic backups. It is more unlikely that a self-contained hole-less memory card becomes damaged with water (anyway let it equally dry).

UV-3R data cable (homemade)

I had ordered an USB-to-UART TTL adapter to debug the rotary encoder on the Frequency Reader. While it was on the way to my lab, I solved the encoder problem, so the adapter had to be tested somehow.

Around the shack I had found a cable terminated in a 4-way 3.5mm jack, probably from an old digital camera. That is the connector of UV-3R data cable (and external ear/microphone too), so I gave it a chance. Steps were:

• identify which cable goes to which connector ring
• draw a map of pin matches between the cable and the adapter
• test the whole thing (as shown in the picture)

My ugly UV-3R data cable (not for permanent use)

At first there was no communication with the radio. Then I swapped RXD and TXD connections: UV-3R software downloaded radio parameters. Cool. Note that the UV-3R says nothing on the display about the data cable being inserted or ongoing computer communication. If data is uploaded to the radio it will automatically power cycle.

The adapter is based on the CP2102 chip and costs 3 USD (2.3 EUR) shipped from Hong Kong. Both WinXP and Vista 64bit recognized the device (XP grabbed the driver from an online source).

The same adapter can be used to build a data cable for the FT817, or other transceivers that expose a serial port with TTL logic levels instead of RS-232 voltages (ICOMs, ...).

New frequency formatting for I.F.R.

My development board with the new display

... and new display too.

On the I.F.R. firmware I have modified the way the frequency is displayed when there is no transverter connected or configured. Information on the first line is right aligned, "Hz" symbol expanded and decimal separator dot added to make the frequency value look nicer.

On the picture you can also see a new display I received: orange on black. For operations in a dark environment it is less bright than the white on blue LCD. Last but not least it matches 817's amber display color (not too closely, I know).

TX-only transverter for 4m - with mixer

The picture shows my TX-only transverter with the diode ring mixer (SBL-1 or ADE-1) component added. The circuit has not grown a lot, but it does indeed work.

The canned oscillator is now terminated in a 1kohm trimmer and feeds the IF port of the mixer. RF from the HF transmitter goes to the LO port. Trimmers will most probably be replaced with fixed resistors.

As a signal generator I used the FT-817 at 24.9 MHz. Listening on a panoramic receiver I could clearly hear LO-HF (20 MHz) and LO+HF (69.8 MHz). The frequency counter on the mixer output picked up the LO-HF difference, which was expected since there is no bandpass filtering afterwards.

I tried swapping HF and LO signals but the result was the same. Signal output decreases if the HF trimmer reduces the mixer drive.

Next step is to build a resonating termination followed by an amplifying buffer. G3XBM circuit calls for a BF199, which is already sitting on the workbench, committed to take part into this project.

TX-only transverter for 4m

While I have no news about a possible 4m allocation for Italy in the next months, I have started working on my TX-only transverter - a "txverter"? - for HF-to-70 MHz.

The idea behind this project is that the IC706MKiiG receives on 4m, so there is no need for a full transverter, provided the operator accepts to operate split. It is a KISSAL principle: Keep It Short Simple And Lazy :-)

I decided to replicate G3XBM's simple transverter, TX chain only. I will build it manhattan/dead-bug style using an ADE-1 passive DBM mixer.

The picture shows first components placed on the copper clad board:

• 5V voltage regulator
• canned oscillator @44.900 MHz
• HF input attenuator of about 30dB (50, 680, 100 ohms)

Current drain at 12V is about 18mA, all for the voltage regulator and the canned oscillator.

The output of the latter is not a sine wave on a 100 MHz scope&probe, but it swings 0-5V if left floating.

I plan to blog how the circuit grows and how it performs.

UV-3R VHF second harmonic

Definition: a second harmonic is a spurious emission of a transmitter located at twice the fundamental frequency (or first harmonic or "dial"). In most cases the second harmonic is not produced on purpose.

UV-3R, especially the single-line display, exhibits too little suppression of the second harmonic of the VHF transmitter. This occurs when the RTX is used on the VHF HAM band (144-146/148 MHz). Suppression gets better and within required limits when the VHF transmitter is used above 150 MHz.

This means un-modified UV-3R is not certified for VHF amateur radio operations. Transmitting, say, at 145.500 MHz, will result in a parallel transmission on 291.000 MHz, which is probably allocated to a Defence Ministry. In the Files area of the Yahoo! group some LPF modifications have been measured and described in detail. Unfortunately they are not for everyone.

So, what options do I have?

• use unmodified UV-3R on VHF only if strictly needed, being aware you might be disturbing communications around 290 MHz. On UHF the little "R" is spurious emissions compliant.
• insert a VHF band/low-pass filter between UV-3R and the antenna
• have someone apply the LPF modification

Why is it so? No one has figured out why the VHF signal is so dirty. It might be a driver/final wrong bias current. UV-3R Mark II is apparently performing better, but still above the required suppression level.

Back up pictures during long trips

I have had an interesting chat about methods for preserving your digital pictures (movies) while being out on an important and long trip. In other words, how to make sure you precious shots come back home with you.

Assumption: you have a way to read memory cards through a computer (not necessarily yours) or use a stand-alone card copier.


Memory cards are pretty cheap. So, why not bringing along an additional extra set, making a copy of a full card and sending it to your home address? You may even prepare addressed envelopes with a thin cardboard reinforce inside. Stamp can be bought as if you were shopping for postcards and you don’t even need a trip to a post office unless you want a Registered letter. Better to send one card per envelope. Once you have safely backed up your picutres (at home), extra cards can be reused for the following adventure.

If you know a trustworthy local, leave her/him your backup copies, either an external HDD or extra memory cards. This will minimize the risk of loss/damage on the journey back home too. If nothing bad happens to your "originals", she/he will keep the hardware afterwards as a reward for the service offered.

Online storage populated overnight is another option, if your hotel has a fast and cheap Internet connection. (If you carry your own laptop consider using Dropbox through my referral link.) But if you shoot a lot (and in RAW ), it might not be practical.


Worried about someone stealing your shots? Either the postman or your local contact person? Encrypt the backup card content with a tool like TrueCrypt. Format the card/disk to resume full, unencrypted, functionality.

Fast knob rotation solved

Good news: I have solved the puzzle of missing steps with fast rotary encoder rotations. It was a piece of inefficient code, which has now been rearranged using AVR's Pin Change INTerrupts ("PCINT").

The 96 states / 24 cycles per rotation encoder is now read properly: it doesn't miss a step.

Now the FR/IFR firmware has to be adapted to a new form of interaction...

Hey! Isn't that a knob?

It is a knob indeed. I have started tests of a quadrature rotary encoder connected to my (Interactive) Frequency Reader development board. This extension will allow to tune the FT817 as if we were rotating the main knob on the front panel.

The firmware is able to read the rotation direction and increase (decrease) the VFO frequency accordingly. I am having troubles with fast rotations, something that should be mitigated with the use of a larger knob or a less sensitive encoder. I would like to avoid the addition of a binary divider between the encoder and MCU.

Broken AF on Canon 18-55 IS lens, what about IS? - part 2

Previous blog post ended with a question: "if the AF is lost, how about the IS? How to find out?"

Many people say that you can hear the Image Stabilyzer in action as soon as the shutter button is half-pressed. Honestly, on the 18-55 IS lens, I didn't feel/hear anything. Other references online tend to confirm that the lens is "quiet" and you can't tell the IS is in action.

Another test is to shoot two pictures, with and without IS, freehand, and look at the difference. You need the proper subject and light too, and perhaps more than just a couple of shots (and maybe 10 coffees...).

Then it occurred to me once that if I hold the camera lens against my ear (grab the camera with the right hand, so the bottom side of the lens touches the right ear) and half-press the shutter button ... I can hear a faint ringing, like a few small bells at the other end of a tunnel. When the IS switch is turned off, no ringing can be heard.

What does this mean?

Well, in my case it means that probably the IS is still working despite the AF being out of order. If you have doubts, listen closely to your lens whispers.

Broken AF on Canon 18-55 IS lens, what about IS?

With no previous signs of failure, the autofocus of a Canon 18-55 IS lens stopped working (this is the lens being offered in kit with low-end cameras, like the 1000D, 450D, 1100D).

Few searches online suggested that a flat cable has gone bad inside the lens. The cable brings commands from the camera body to the lens front, where the autofocus motor is located.

This failure occurred after about 7000 shots taken through the lens, with a lot of zoom in/zoom out. A new lens costs 95-100, the repair service has been quoted at 60-70 (€uro). The flat cable itself is about 12 €uro.

I could keep the lens without autofocus, but it also has another electrically controlled feature: the Image Stabilyzer. If the AF is lost, how about the IS? How to find out?

The answer will be in another post.

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).

Design engineers still playing with 2nd harmonics (article)

One of the weekly newsletters I receive mentioned an interesting application note from Maxim: Adapting Low-Band ISM Transmitters for High-Band Operation.

It is about adapting a 434 MHz transmitter to work on the second harmonic 868 MHz. Both frequencies sit into license-free bands in most Countries and are harmonically related, like many of our HAM bands.

The article talks about how those simple transmitters work (25% duty cycle switching PA), how their output looks like, how clean their output is, how to redesign the matching network and to do some noise measurements maths.

These chips can deliver about 13dBm/20mW (10dBm/10mW on the 2nd harmonic after proper matching): not much power for E.M.E., but enough for a simple beacon in a tiny (SOT-8) 8-pin package.

I found it a good (morning) reading, packed with well explained design information.

Bad luck with an UV-3R

I have read recently of HAM operators that got out of trouble during a mountain excursion because they had a VHF handy with them. My Standard C150's electrolytics gave up some 8 years ago so I have been without a lightweight "walkie talkie" for emergency communications since then. Incidentally the HAM market is being flooded by a Chinese-made dual bander for 35€ named UV-3R, so cheap that I couldn't resist.

Many people have written reviews about it; my contribution: it does what you pay for. The C150, designed 20 years before, was way beyond the UV-3R.

Anyway, I have had bad luck with my UV-3R which fails to receive on VHF. A schematic diagram is available online and I have tracked down where the problem probably is. It could be a cold solder joint, fairly easy to locate and fix, or a failing component.

Now the doubt: try to fix it and - in the worst case - keep a UHF-only handy or return it for a replacement/repair?

FT-817 remote "F" button - first picture

Here is how my I.F.R. firmware development board looked like once I added the code to show current A/B/C functions:

This modification makes the I.F.R. to work exclusively on the 817, not on 857/897, so I will add a configuration option to exclude this function.

As a side note I understood how the FT-817 CPU handles the current F-menu setting. On the RTX, when F is pressed the current menu page is displayed. If SEL is rotated the new menu page is not saved to the internal EEPROM, until A/B/C or F are pressed: FT-817 display returns to Signal strength meter, and the I.F.R. can display the new page.

FT-817/FT-857/FT-897 CAT emulator

What do FT817, FT857 and FT897 have in common? The documented CAT protocol, for remote control of some functions of the radio.

What have I been mostly writing about in the past 2 years? CAT protocol :-)

In a mail exchange about my 817 accessories, a builder asked me if there is a way to emulate the CAT protocol on the PC. It is possible, probably with little effort, but I am not able to do it. But I can easily do it on an microcontroller system: it is a matter of "reversing" the code for my FT817 keypad, so that it will respond to commands.

I had never though of it, but a CAT emulator allows to test my accessories without having the FT817 around. That's why I am going to write the code.

This device can be as simple as an ATtiny2313, XTAL, 2x27pF. A LED could blink on data transfer, no LCD needed. Software-wise it will ignore unknown commands and initially keep the VFO frequency and mode set by the controlling device. More functions to be added if/as needed.

FT-817 remote "F" button - proof of concept

While showing both the Keypad and the IFR to a local HAM, he suggested that it would be useful to have a way to remotely press the "F" button (and show the current menu page). Unfortunately the CAT protocol does not allow it. But the "Quick Menu" function silently activates a menu page with two keypresses, as opposed to F press and SEL rotation.

How about removing the word "silently" from the last sentence?

The IFR has a display and on the second line there is room for extra info. Especially if the mode string can be moved on the first line: that is true if the FT817 is not used in conjunction with a transverter.

My plan. Develop a no-transverter IFR firmware that shows the current menu page on the remote display. It will be a reminder of what is actually on the radio and what do keys A/B/C do if pressed.

Expect a demo screenshot soon.

Reading date/time from GSM network

Still playing with the serial GSM modem to send SMSes, I investigated a way to obtain a timestamp from the network. Just in case I want to record an event and place it on the time line.
It turns out that the GSM network does not (always?) carry date/time information and the extended GSM AT command set does not provide a way to read that information. So, a workaround is needed.

All received SMSes contain a timestamp, usually set by the originating network. This is an example:

+CMGL: 5,"REC UNREAD","4130",,"11/07/07,18:07:19+08"
message body

The timestamp is in the first line in the format yy/mm/dd,hh:mm:ss+tz . Well, don't ask me what +08 stands for, but 18:07 was local Summer time.

My trick is: find out if your operator has a service that auto-replies with an SMS to SMSes or calls to a special number. Italian operators have such a service to inform the subscriber of the amount of credit left. When you need a timestamp, let your device query the proper network service via SMS or call; wait for the SMS to come; read the datetime string. Don't forget to delete the SMS so that your SIM/MT memory fills up.

This procedure will not provide a precise timestamp down to 1" resolution, but it will put your application in the right ballpark, usually within a minute (which is more than enough for my remote thermometer!).

Of course an RTC chip can be added for as little as 2EUR/2USD, but you need a way to initialize it and board space too.

Differential signal path in transceiver designs (article)

In July 2011 issue of AD's Analog Dialogue I spotted this article on RF design: Differential Interfaces Improve Performance in RF Transceiver Designs.

It is about designing an I/Q receiver and a transmitter using a differential signal path instead of the more common single-ended approach. With three practical examples including calculations, this article should help the design of a differential chain for HF/VHF HAM use.

Prove me wrong, but hasn't the NE602 got differential inputs and outputs?!

DS18B20 self-heat

I have been playing with a DS18B20 1-wire temperature sensor, with its default factory configuration: 12-bit resolution, meaning about 0.75" conversion time. The control software forced the sensor into an almost 50% duty-cycle, so updating temperature reading every 2 seconds.

With this stress, I noticed that the bare sensor was reporting an increasing temperature in the first minute of operation: it got into a "warm-up" phase which caused a wrong reading of the actual temperature. Almost as high as +1°C.

Well, the device measures its own die temperature, so if it is stressed and left in open-air without a heatsink it probably does heat up. Power consumption according to the datasheet is 5V*9mA = 45mW. Room temperature was lightly above 25°C.

In order to better understand this useful tiny device I will try and report three approaches:

• keep the 12-bit resolution and add a small heatsink
• decrease resolution to 9-bit and keep the duty cycle
• at 9-bit resolution keep the 2" loop

Share serial port with guest VM in Virtualbox 4

This is probably the N^th page about this subject, so consider it a personal reminder.

How to allow direct access to the physical serial port to a virtual machine under Virtualbox (currently version 4.0.x) ? Edit VM's properties and flag as shown in the screenshot below:

[Info: "Dispositivo host" should translate into "Host device" in English.]

Settings shown above worked both for a MS and a Linux guest virtual machine.

Power up the VM and it will appear as COM1: under a MS OS or /dev/ttyS0 under your preferred Linux distro. For already installed Windows machines you'll have to fiddle with new hardware detection, and do a web search to find the most straightforward procedure.

If you want a reliable serial communication with AVRs ...

... do not rely on the internal RC clock.

Now, Paolo, fill the blackboard with that sentence.

If you want a reliable serial communication with AVRs
do not rely on the internal RC clock.

If you want a reliable serial communication with AVRs
do not rely on the internal RC clock.

If you want a reliable serial communication with AVRs
do not rely on the internal RC clock.

If you want a reliable serial communication with AVRs
do not rely on the internal RC clock.

If you want a reliable serial communication with AVRs
do not rely on the internal RC clock.

:-)

Dealing with SMS storage on a GSM modem

I should have called this post "History repeATs": I would have never imagined that I would reuse my Hayes AT knowledge after ... 20 years. From dialup to GSM modems, technology has evolved but not the way to communicate with the DCE: the AT command set.

This is all part of my GSM remote control project, that has abandoned the idea of using an unmodified GSM cellphone.

Problem: a GSM modem kept blinking a LED, meaning there were unread messages. Since the SIM card was empty, the message(s) had to be inside the modem:

AT+CPMS?

+CPMS: "SM",0,50,"SM",0,50,"MT",2,250

There they are, 2 of them. How to get to them? Given the AT command documentation, "SM" stands for SIM and "ME" is the Mobile Equipment. What is "MT"? In my opinion it is the whole Mobile Terminal, so MT=SM+ME.
Still, the AT+CMGL (List SMS) and AT+CMGR (Read SMS) commands do not accept a parameter to select the message storage (SM vs ME).

The trick is then to select a different default message storage, "ME" in this case, and proceed to read/delete those messages:

AT+CPMS="ME","ME","MT"  # switch to ME message storage
AT+CMGL # list messages
#... do your SMS actions ...
AT+CPMS="SM","SM","MT" # switch back to SIM if you want to

It took me a while to figure out this procedure and the product documentation didn't help much.

If you landed on this blogpost looking for GSM modems for a M2M application or the like, known models are: Nokia 12, Nokia 30; Siemens M20t, Siemens TC35; Telit GM862/GM864; etc etc You better look for their "terminal" version, that usually comes with a manageable interface like RS232 instead of a small 80 pin connector.

Locked ATmega168 and avreal32 (CKDIV8)

Excuse the very technical article, but I feel this might help someone to recover an apparently locked Atmel microcontroller.

I use avreal32 to program my AVR uCs, and I needed to bring back to the factory defaults some fuses. Chip had CKSEL=1111 (external high-frequency XTAL) and CKDIV8=0, so effectively running at XTAL frequency. I wanted to have it back to the internal 8 MHz RC oscillator divided by 8, so: CKSEL=0010 and CKDIV8=0.

What I did was to call avreal and first change the value of CKDIV8 with:

avreal32.exe +MEGA168 -ap -p1(0x378) -o0 -4 -w+ -fCKDIV=0

Note that my original configuration on my programming hardware does not require an external XTAL for programming the uC as long as avreal32 is generating the clock with -o0 switch.

Result: chip couldn't be read, avreal32 said "Can't resync". I did not touch RSTDISABLE this time. After a bit of thinking and reading avreal32's -help I tried this command to set CKSEL:

avreal32.exe +MEGA168 -ap -p1(0x378) -o0,8 -4 -w+ -fCKSEL=2

It worked.

I think that the uC was running 8 times slower than avreal32 expected it to, given the computer generated clock and the internal divider enabled. Slowing down avreal32 by a factor 8 did the trick and now I can program again the chip at my usual speed -o0.

Note that this procedure does not cure a disabled RSTDISABLE fuse. You need a HVP for that.

Rain detection DIY

This project started as a complement to my cellphone remote control idea: I have opted for using a "GSM module" with standard AT commands, which allows me to receive and send SMSes. Since some info about the remote location can be fit into an SMS, I have been thinking of useful ambient parameters to be measured and transmitted.

I got stuck on how to detect an ongoing rainfall, and search engines didn't seem to help with DIY solutions, at least with keywords I used.


After some brainstorming, there seem to be two ways to detect rain, actually three: with a resistive sensor, with a capacitive sensor and with an infrared reflectometer.

Resistive sensor can be as simple as a copper clad board with two interlaced combs designed on it. Quick and cheap. How to protect it from the harsh environment? Use iron, Cu+Sn or Au (gold) as contacts.

The capacitance method does not require electrical contact, but it rather relies on the different dielectric characteristic or water vs air. It has to be defined how much C changes and then understand how hard is to measure it: an interesting challenge.

The infrared reflectometer is used in rain detection systems on car windshields, and it is mentioned here just in case you want to learn about it (in that case use a search engine).


I will first investigate the resistive method: if it lasts 10-12 months I can afford to change the sensor once a year. First step: build two interlaced copper combs and measure R when water bridges them.

Deadbug as (space) industry acceptable building standard

Usually I do not publish links to other online resources, but this one is worth a mention for all solder smoke addicteds out there: NASA Workmanship Standards (Pictorial Reference) (click on "NASA" button at the page bottom).

In section 3.03, "deadbug" or "Manhattan style" building tecnique is analysed and therefore declared as acceptable by NASA!

But all other chapters of this pictorial reference show how things should be done and look in homebrew electronics (cabling, PCB soldering, ...), so the whole book is really worth a look.

However I could not find other similar publications from the same source with simple URL tricks. Too bad. Wait, there is a whole website dedicated to Workmanship Standards! Can anyone spot something useful in there?

Comb generator, full diagram

It was back in 2007 when I designed and built a simple comb generator to test the wideband response of RF filters.

An interested builder asked me for further details about my circuit, but it was so simple and flexible that the only help I could provide was to complete the circuit diagram.

The circuit shown above generates an uncalibrated and non-constant "RF comb" from the XTAL frequency well up to the 500 MHz region. The comb is good for relative measurements, such as peaking a filter.

Comb peaks were observed to be spaced as much as the base XTAL frequency: the smaller the rock, the more dense the spectrum will be. Note that you might need to increase C's across the XTAL for lower frequencies.

An alternative for much more dense comb in HF is the "VE3DNL Marker Generator", do a web search for references and diagram. I think both of these circuits should be in every builders' shack.

Low Vcc voltage on ACC port (FT817)

Twice in the same week, that's the occurrence of a fault occurred at the ACC port of two unlucky FT817 transceivers.

The symptom is a low voltage on the "13.8V" line of the ACC port when an external keypad or FR or IFR is connected to it (or another ACC powered device, of course). The cause has been a short between the "13.8V" line and ground, that has damaged the tiny R1235 10 ohm 1/8W resistor. In both reported cases the resistor has increased its resistance, effectively protecting the remaining circuitry.

On the circuit diagram it is obvious that R1235 is the only protection on the unfused Vcc line (internal battery or external supply) for the 13.8V ACC output. There is a resettable fuse, but that one goes towards the FINALS board and has nothing to do with the ACC port.

How to fix it? I can think of three ways:

• replace the resistor with an identical one (it is tiny, you need proper equipment, SMD reworking ability and a firm hand);
• replace the resistor with a physically larger one, and a fuse if there's room for that [but be aware that a 1/4W resistor won't blow up the same way!]
• parallel the existing resistor with another 10-15 ohm one, but still consider adding a 500mA fuse

Do not simply short R1235. Old R1235 can be gently cut in half instead of being desoldered.

Summing it up. Be very careful with the Vcc line on the ACC port. If you are reading this because the damage is already there, refer to Yaesu assistance or a skilled electronic technician (yourself?) to trace and fix the damage.

FT-817 external tuning knob experiment

Time to share a new development in my accessories for FT-817.

Following the suggestion of a keypad owner I investigated a way to implement an external tuning knob that would overcome the limitations of the small radio main dial.

An optical rotary encoder would be the best component for this task, but they tend to be expensive for an experiment and not readily available. (Yes, I know they can be built from stepper motors, but this wanted to be a quick check.)

In my junk box I located a central-zero potentiometer that was in a VCR jog dial control. Left/right with a spring taking it back to midpoint. I wired it to the analog-to-digital converter of an ATmega168 and successfully controlled the VFO frequency as if I was turning slow/fast the main dial.

Implemented transfer function, with a central no-action range

If one was to further develop this accessory, the most interesting part would be to define a transfer function between the pot position and the VFO change: both step and update delay can be computed to implement a slow-to-fast tuning. For this first experiment I simply used a linear transfer function giving steps in the 130-1300 Hz range.

This kind of interface requires the microcontroller to have an analog-to-digital converter onboard, so one of the ATmega series used in my Frequency Readers. The ATtiny2313 is not suitable for this option unless I get to use a proper quadrature optical encoder (not planning to invest on it).
 

If you have a spare central-zero potentiometer and ATmega48/88/168 laying around I can send over a diagram and the compiled firmware.

White on blue Interactive Frequency Reader

Please meet my completed I.F.R. with a white on blue display.

Size is 12cm high, 9cm wide and 3cm thick.

The connector on the left goes to the CAT port on FT817. The jumper is provided to add an off-board on/off switch. On the back of the board there is a resistive trimmer to adjust display contrast (drill a hole in the case). Another jumper (under the LCD) gives access to backlight intensity control.

The pictured object is for sale, including keypad, white-on-blue LCD, molded cable to FT-817. It carries the latest fully featured IFR firmware (including 6 LO values for transverter users). Chips, display and keypad are detachable. It needs a housing.

My own second IFR build

I built a second "prototype" of the Interactive Frequency Reader on a 12x5 cm perfboard slice. I hope that showing it to interested builders will give a glimpse of the build (non?)complexity.

First of all, here is how it looks like when assembled and ready for usage. Display on top, keypad on bottom, as shown in the previous post schematic assembly diagram.

The display this time is white on blue, very charming. It does require backlight 100% of the time, increasing the current consumption to 32mA.

Noteworthy is that the backlight diode Anode-Cathode is reversed as compared to my other black/green LCD: always, always check your display pinout before soldering it in!

Display and keypad are connected to the board with 2.54mm pin header rows, so that it is easier to remove them for maintenance or re-programming the ATmega168.
Here you can see the actual position of these connectors on the topmost and lowest rows.

CAT cable enters on the mid-left 4-way connector, which is equipped with an old-fashioned jumper if the future owner wants to insert an on/off switch.

And the third picture exposes the board backside. The 10kR resistive trimmer is used for contrast control.

Many connections can be kept short if some building tricks are adopted, like keeping close display and ATmega or using resistor leads to join PCF8574 to the keypad connector.

One useful mod would be to add a backlight intensity control (100R fixed + 100R variable would do).

I am trying to take a decent photograph of the lit LCD. but I need to work on ambient light a bit more. Stay visually tuned!

I.F.R. suggested layout

If you are going to build the Interactive Frequency Reader on a 12x5 cm perfboard (like the one shipped in the bag of parts), this is a suggested layout of chips, keypad and LCD: keypad on the lowest row, LCD on the topmost row.

Following these positions you will be able to hide all components under the large keypad and display, plus they will be aligned to each other and most wirings will be easier too (pictures will follow). For example some LCD<->ATmega will be straight bridges, and resistors leads will be long enough to connect the keypad to the PCF8574.

I.F.R. bag-of-parts on offer with molded connector

As announced few days ago, I got hold of a small stock of cables terminated in a MiniDIN8 connector, suitable for FT817 ACC port. So I have assembled an offer for a bag-of-parts bringing to you both the ready-made cable and the fully featured I.F.R. firmware.

Modding PLL MC145106

Original configuration

 Back to my Pearce Simpson device, I have decided to go through all the steps necessary to make it "digitally" tuneable.

In order to set free the 2x4008 I had to unscrew the front panel and remove all knobs. The black plastic can be removed and the front panel structure detached.

Chips are now exposed. This is "old" technology, so with a solder wick and a thin tip I could set 4008 free just with 3 lifted pads.

2x 4008 on their new sockets

It took a bit of work to get the new sockets in, and they are not perfectly aligned to the board, but the melt solder did the rest and joined everything (checked).

As a final check I plugged in the replacement ICs, connected a dummy load and a frequency counter and made sure that it tunes around.

Next is to draw a board that holds an ATtiny2313 for tuning up and down, AND to make sure that it all fits inside the case before melting any other solder! Oh, yes, I have one more cut trace to restore.

Molded MiniDIN8 cable for FT817 accessories

I have just secured a small lot of MiniDIN8 molded cables, 2m long, terminated in a DB9 connector.

These will be offered as an option to fellow builders of my FT817 accessories.

FT-817 Interactive Frequency Reader - current consumption

Measured on the FT-817ND 12Vdc input, the I.F.R. draws:

• nominally about 16 mA
• about 110 mA when communicating over the CAT interface

These measurements were taken without LCD backlight.

Since the circuit uses a 78L05 regulator, rated at 100mA continous, I would power the LCD backlight directly from the 12Vdc line, or a dedicated battery.

Fiddling with a MC145106 PLL

While re-arranging the shack, I have come across a 10-11m RTX with MC145106 PLL inside. I had used it on 10m, so I decided to check its electrolytic capacitors since it was built more than 20 years ago. While peeking inside I traced damages and mods I had done and fixed, and that was about 20 years ago too!

I had always wanted to "upgrade" the RTX by feeding the PLL divider with a binary counter, in place of the rotary switch + band switches. Now that I can "master" (aehm...) microcontrollers, adding such a control will give even more flexibility.

The plan is to remove the two 4008 adders between the rotary switch and the PLL, and replace them with DIP sockets. Then build a daughter board with a ATtiny2313 and two or more buttons to get the tuning done.

If this works, meaning that I have understood how was designed the PLL circuitry, an external display could be added too, memories, scanning, restricting to 10m and so on.

The RTX will keep the orignal 10 kHz channelization, unless I manage to make the PLL chip do 5 kHz increments. But that would require close work on the PLL.


First I will check the RTX power ups and is still generating some RF :-)



The picture shows PCB traces between 2x4008 and the PLL 145106.

For the records, this RTX is called Pearce Simpson Super Cheetah but it has 6 "bands". It has a circuit very similar to Superstar 3900, which I am using as a reference for this mod.

150th blog banner picture

On March 17th 2011 Italy will celebrate its 150th birthday. The only colored waves I could think of are made of photons, so let me introduce you to the new blog banner:

Celebrations will last 9 months, so if you are planning a Spring/Summer trip to Italy make sure to check out the program!

Measure CFL color temperature with a picture

Say you are lighting a room with two pendants. One day you replace one pendant's CFL bulb and find out that, despite being both "warm light", their color rendering is different. You may notice this effect looking at their light spot on the ceiling, or observing usual room objects under the two bulbs.

That was my case, with a brand new "warm light" 2700K CFL looking colder than a Philips CFL. There my curiosity stroke: how to find out the actual color temperature of CFL bulbs?

Having played with digital pictures I remembered that it is possible to control while balance (that usually sits in "AWB" mode) in post-production, that is with a picture editing software. One condition: the camera must be able to save pictures in RAW format, not JPEG. Most recent point-and-shoot cameras should be able to save uncompressed pictures ("RAW").

The white balance is controlled by adjusting a slider to the light source's actual color temperature: colors will look natural only when picture settings match light source's value.

So, here's the procedure I tried:

• take a picture of the object/room lighted with the suspect bulb, it MUST be in RAW
• colors might look wrong, it doesn't matter
  
• download the picture to your computer and open it up with your camera producer's RAW processing software (Canon's is called Digital Photo Professional)
• edit the RAW picture settings and find out how to control the white balance
• select "Color temperature" and move the slider until picture colors match real ones: that WB value is your actual CFL's color temperature
  

Canon's slider goes from 2500 to 10000 Kelvin in 100 K steps. Probably you will not be able to find the exact value, but a non-trained human eye can recognize a range of +-/ 200 K around the actual, true setting.

Few words of caution. Wait for the CFL to warm up before taking the picture. Mind that your computer screen might modify colors too. More?

Cellphone remote control, step 1

Following the request described a couple of months ago, I haven't stopped thinking of the cellphone remote control. So, an ATtiny2313 will be the processing unit and to ADC the incoming sound command I will use a tone decoder.

Why not build a software frequency counter? Because it would keep the 2313 running all the time (that's about 99,999% of the time needed) and it would use internal timers that I need to validate the incoming command sequence.

A simple tone decoder is the good old NE567 that I located inside a PSTN answering machine from 90's. The local shop doesn't sell them anymore.

Some more details. The ring tone will be bitonal, so that any ambient noise gets cancelled when the remote cellphone rings. High tone will be used as a carrier, low tone as a signal to the microcontroller. Low tone will be chosen away from flies and mosquitoes sound :-) The ON 001000100010 decoded sequence will have a lower frequency than the OFF command.

Let's warm up the iron!

FT-817 Interactive Frequency Reader - fast dial

One request I got while designing the I.F.R. was to allow a default value for 100/10/1 GHz and 100/10 MHz. This way a frequency can be entered with fewer keypresses.
Like a QSY to 10'368'367'0oo Hz would require to dial in only 8-3-6-7-0-# instead of 1-0-3-6-8-3-6-7-0-#.

This feature can now be (de)activated from the configuration mode, key C. It applies also to normal operations, when the transverter math is not used.

FT-817 Interactive Frequency Reader - PREVIEW video

Here is a 3'33" youtube video showing how the Interactive Frequency Reader works right now.

The firmware shown is taylored for users that use FT-817 in conjunction with a microwave transverter. Please note that not all implemented functions have been shown, the firmware can be extended and it is still subject to changes.

Please leave feedback and, most important, ideas.

Statistiche IAC di gennaio 2011

Guardando il mio log e la classifica mensile inviata da BPU, mi sono chiesto se non possa essere interessante vedere la distribuzione per quadratoni dei partecipanti allo IAC.

Con un paio di operazioni in OpenOffice Calc, ecco un risultato tabellare:

Count - LOC	Banda
LOC	50	144	432	SHF	UHF	Total Result
JN35		2				2
JN44	4	4	3		1	12
JN45	5	15	7	3	10	40
JN52			1			1
JN53	1	7				8
JN54		1	1	1	2	5
JN55	3	2	2			7
JN61			1			1
JN62		1				1
JN65	1	1				2
Total Result	14	33	15	4	13	79

E la rappresentazione grafica:

Traete voi le conclusioni sulla base della vostra banda preferita >30 MHz, ricordando che questi numeri rispecchiano la distribuzione geografica di chi ha inviato i log, non necessariamente dell'effettiva presenza "in aria".

FT-817 Interactive Frequency Reader

... or "detachable display". A first version is currently working on my bench. It is taylored for microwave transverter users, so the current features are:

• configuration mode accessed at frequency reader start-up with parameters in EEPROM
  
• holds baud rate setting
• holds transverter mode on/off
• holds LO+IF and LO-IF math mode
  
• holds frequency update delay in 15 x 100 ms steps
  
• holds two L.O. values down to 100 Hz resolution
• direct microwave frequency dial, with invalid FT-817 frequency control
• mode change
• VFO A/B toggle
• VFO A=B
• RIT on/off
• LO value selection (#1 or #2)
• 15 onboard frequency/mode memories

Since many frequency values can now be entered, keypad digits can no longer work as jolly buttons for other advanced features (a further study on HAM microwave bands is needed, though!). If the transverter mode is OFF, then the frequency reader takes direct VFO value (with valid frequency check; i.e. 156'000'000 Hz will not be sent to the radio because it is out of FT-817 range).

I plan to record a demo video in the next days, so that I can gather readers' feedback before a final public firmware version is packed up and documented.

FT-817 Frequency Reader, present and future

Firmware development has not stopped, and now the frequency reader has a bigger brother: the Interactive Frequency Reader.

Based on the same circuit core (ATmega88/168), it adds the matrix keypad to the external display readout.

Most of the recent work has been towards enabling the I.F.R. to accept direct microwave frequency dial and QSY the FT-817 to the proper frequency, according to the selected L.O. value.

Meanwhile I am completing the Frequency Reader documentation, so that it will be up on the website soon. The stand-alone display firmware is now stable and ready for the general public.

Heat up your soldering irons!

FT817 Interactive Frequency Reader: weights...

I have assembled a circuit of the work-in-progress "Interactive Frequency Reader" and weighted it: about 90 grams without the CAT cable to the FT-817.

This weight includes the circuitry, the 16x2 LCD and the 4x4 matrix keyboard.

Must not forget to add the enclosure weight too!

The assembled circuit confirms that the hardware design has reached a stable version, as well as basic firmware functions. Now I have to think of a user friendly, menu driven?, interface.

Macro for cameraphone from viewfinder lens

I have come across an article on Hack a Day about building and adding a macro lens to a cameraphone at almost no cost. It requires a lens from the laser head of a DVD reader, and according to published pictures and tutorials, we are talking about a very small part.

While looking inside the 35mm camera (see previous post), I gained access to some lenses and ... guess what? There's one that can be used as a macro extension for a cameraphone!

It is the viewfinder lens, the one where the photographer was looking into before the digital camera era. It is larger than the DVD laser head, so it is easier to handle and mount on an adapter (to be constructed).

This addition works by reducing the minimum distance at which the camera can focus, so that you can get closer to the subject and in fact capture more details.

Let's see how my 3.2 Mp F2.8 auto focus cameraphone behaved when holding the macro lens in front of it.

The sample was a 2 €cent coin at sunset, that you can see here side by side to the lens:

(picture shot without the macro lens, obviously)

Let's hold the lens in front of the camera and get an interesting detail (click on pictures to see them 1:1):


Or, zooming in at full resolution on the focused area:


If I had shot at the same distance but without the macro lens, this would have been the result:


As last, with and without the macro lens side by side:


Now I have to figure out a way to hold the lens in front of the camera.

What is inside a 35mm point&shoot camera

After few days in the hands of my daughter, a point and shoot 35mm camera plastic has started to break apart... time to put it aside and start opening it up.

It was a Minolta Riva Zoom Pico with a motorized 35-60mm zoom lens and autofocus. It did allow me to experiment with photography, and it took good pictures.

Anyway, I never opened up a photocamera, so I was curious to see what was inside.


I was surprised to find "enough" electronics, all mounted on a flexible PCB fit between the inner body and the outer shield. The electrolytic capacitor of the flash (220 uF, 300 V) was fit inside the film roll cylinder: a very smart arrangment. Everything was a tight fit and I bet it was hand assembled back in 1994 or so. What else can be taken off and recycled? Here's a list:

• flash strobe with circuitry
• small screws
• whitworth 1/4" nut (plastic)
• small plastic gears
  
• DC stepper motor
• lenses
• (zoom) objective
• photoresistor
• IR LED
• 200 pixel sensor from the autofocus
  

Out of all electronics in the list above, very little can be reused in other projects, the easiest probably being the flash strobe circuitry once the pinout is sorted out. On the PCB there are very few "useful" components.

The zoom objective has many wires making it almost impossible to control it from the outside (zoom, focus and shutter), so it is stuck in the "rest" position.

Lenses can be used to experiment with light.. maybe one of the small biconvex lenses from the autofocus could focus the Sun and set something on fire?!

Last but not least, around the camera body there are some metallic springy contacts that could become a Morse key.