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?