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.