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