The personal website of Scott W Harden

Crystal Oven Experiments

Now that I've finished my 6-channel data logger (previous post), it's time to put it to the test! I'm using a handful of LM335 temperature sensors to measure temperature, and a 20 Ohm resistor to act as a heater. When 1A of current passes through it, it gets quite toasty! First, I'll make some temperature probes...

UPDATE: Those photos show a partially completed sensor. Obviously the third wire is required between the resistor and the LM335 to allow for measurement! Here's a more completed sensor before the shrink tube was massaged over the electrical elements:

Then I mounted the sensors on a block of steel with the heater on one side. This way I can use one temperature to measure the heater temperature, and the other to measure the temperature of the metal chassis. I then put the whole thing in a small Styrofoam box.

When I fire the heater, that sucker gets pretty darn hot. In 40 minutes it got almost 250F (!) at which time I pulled the plug on the heater and watched the whole thing cool. Notice how the metal chassis lags behind the temperature of the heater. I guess it's a bit of a "thermal low-pass filter". Also, yes, I'm aware I spelled chassis incorrectly in the graphs.

But how do we use this to build a thermo-stable crystal oven for a MEPT (radio transmitter)? I tried a lot of code, simply "if it's too cold, turn heater on / if it's too hot, turn heater off" but because the chassis always swung behind the heater, and even the heater itself had a bit of a delay in heating up, the results were always slowly oscillating temperatures around 10F every 20 min. That's worse than no heater! My best luck was a program to hold temperature stable at 100F with the following rules:

  • 1.) If heater > 155F, turn heater off (prevent fire)
  • 2.) If chassis < 100F, turn heater on
  • 3.) if (heater-target) > (target-chassis), turn heater off

What a great job! That thing is practically stable in 20 minutes. The advantage of this over an analog method is that I can set the temperature in software (or provide an interface to change temperature) and my readings are analytical, such that they can be conveyed in a radio message. Again, my best results came when I implemented rule 3 in the code above. More experiments to come!

Markdown source code last modified on January 18th, 2021
---
title: Crystal Oven Experiments
date: 2010-11-28 17:06:18
tags: circuit, microcontroller, old
---

# Crystal Oven Experiments

__Now that I've finished my__ 6-channel data logger (previous post), it's time to put it to the test!  I'm using a handful of LM335 temperature sensors to measure temperature, and a 20 Ohm resistor to act as a heater.  When 1A of current passes through it, it gets quite toasty!  First, I'll make some temperature probes...

<div class="text-center img-border">

[![](IMG_4581_thumb.jpg)](IMG_4581.jpg)
[![](IMG_4588_thumb.jpg)](IMG_4588.jpg)

</div>

__UPDATE:__ Those photos show a partially completed sensor. Obviously the third wire is required between the resistor and the LM335 to allow for measurement! Here's a more completed sensor before the shrink tube was massaged over the electrical elements:

<div class="text-center img-border">

[![](IMG_4591_thumb.jpg)](IMG_4591.jpg)

</div>

__Then I mounted the sensors__ on a block of steel with the heater on one side.  This way I can use one temperature to measure the heater temperature, and the other to measure the temperature of the metal chassis.  I then put the whole thing in a small Styrofoam box. 

<div class="text-center img-border">

[![](IMG_4606_thumb.jpg)](IMG_4606.jpg)
[![](IMG_4615_thumb.jpg)](IMG_4615.jpg)

</div>

__When I fire the heater,__ that sucker gets pretty darn hot. In 40 minutes it got almost 250F (!) at which time I pulled the plug on the heater and watched the whole thing cool. Notice how the metal chassis lags behind the temperature of the heater. I guess it's a bit of a "thermal low-pass filter".  Also, yes, I'm aware I spelled chassis incorrectly in the graphs.

<div class="text-center">

[![](howhot_thumb.jpg)](howhot.png)
[![](quicktest_thumb.jpg)](quicktest.png)

</div>

__But how do we use this to build a thermo-stable crystal oven for a MEPT (radio transmitter)?__ I tried a lot of code, simply "if it's too cold, turn heater on / if it's too hot, turn heater off" but because the chassis always swung behind the heater, and even the heater itself had a bit of a delay in heating up, the results were always slowly oscillating temperatures around 10F every 20 min. That's worse than no heater!  My best luck was a program to hold temperature stable at 100F with the following rules:

* `1.) If heater > 155F, turn heater off (prevent fire)`
* `2.) If chassis < 100F, turn heater on`
* `3.) if (heater-target) > (target-chassis), turn heater off`

<div class="text-center">

[![](heaterworks_thumb.jpg)](heaterworks.png)

</div>

__What a great job!__ That thing is practically stable in 20 minutes. The advantage of this over an analog method is that I can set the temperature in software (or provide an interface to change temperature) and my readings are analytical, such that they can be conveyed in a radio message. Again, my best results came when I implemented rule 3 in the code above. More experiments to come!

ATMega48 + LM335 + MAX232 = Serial Port Multi-Channel Temperature Measurement

While working to perfect my temperature-controlled manned experimental propagation transmitter (MEPT), I developed the need to accurately measure temperature inside my Styrofoam enclosure (to assess drift) and compare it to external temperature (to assess insulation effects). I accomplished this utilizing the 8 ADC channels of the ATMega48 and used its in-chip USART capabilities to send this data to a PC for logging. I chose the ATMega48 over the ATTiny2313 (which has USART but no ADCs) and the ATTiny44a (which has ADCs but no USART). From when I see, no ATTiny series ATMEL AVR has both! Lucky for me, the ATMega48 is cheap at $2.84 USD. Here's my basic circuit idea:

EDIT: the voltage reference diagram is wrong at the bottom involving the zener diode. Reference the picture to the right for the CORRECT way to use such a diode as a voltage reference. (stupid me!)

MULTIPLE SENSORS - Although in this demonstration post I only show a single sensor, it's possible to easily have 8 sensors in use simultaneously since the ATMega48 has 8 ADC pins, and even more (infinitely) if you want to design a clever way to switch between them.

LM335 Temperature Sensor - selected because it's pretty cheap (< $1) and quantitative. In other words, every 10mV drop in voltage corresponds to a change of 1ºC. If I wanted to be even cheaper, I would use thermistors (<$0.10) which are more qualitative, but can be calibrated I guess.

Notes on power stability - The output of the sensor is measured with the ADC (analog to digital converter) of the microcontroller. The ADC has a 10-bit resolution, so readings are from 0 to 2^10 (1024). AREF and AVCC can be selected as a voltage reference to set what the maximum value (1024) should be. If the ADC value is 1V (for example) and AREF is 1V, the reading will be 1024. If AREF becomes 5V, the reading will be 1024/5. Make sense? If AREF is fluctuating like crazy, the same ADC voltage will be read as differing vales which is not what we want, therefore care should be taken to ensure AREF is ripple-free and constant. Although I did it by adding a few capacitors to the lines of the power supply (not very precise), a better way would be to use a zener diode (perhaps 4.1V?) as a voltage reference.

Here is my circuit. I'm clocking the chip at 9.21MHz which works well for 19200 baud for serial communication. Refer to my other MAX232 posts for a more detailed explanation of how I chose this value. The temperature sensor (blurry) is toward the camera, and the max232 is near the back. Is that an eyelash on the right? Gross!

The data is read by a Python script which watches the serial port for data and averages 10 ADC values together to produce a value with one more significant digit. This was my way of overcoming continuously-fluctuating values.

Here you can see me testing the device by placing an ice cube on the temperature sensor. I had to be careful to try to avoid getting water in the electrical connections. I noticed that when I pressed the ice against the sensor firmly, it cooled at a rate different than if I simply left the ice near it.NOTICE THE PROGRAMMER in the background (slightly blurry). The orange wires connect the AVR programmer to my circuit, and after the final code is completed and loaded onto the microcontroller these orange wires will be cut away.

Here is some actual data from the device. The LM335 readout is in Kelvin, such that 3.00V implies 300K = 80ºF = 27ºC (room temperature). The data is smooth until I touch it with the soldering iron (spike), then it gets cool again and I touch it with a cold piece of metal (wimpy dip), then later I put an ice cube on it (bigger dip). Pretty good huh? Remember, 0.01V change = 1ºC change. The bottom of the dip is about 2.8V = 280K = 44ºF = 7ºC. If I left the cube on longer, I imagine it would reach 0ºC (273K, or 2.73V).For everyone's reference, here's the pinout diagram of the ATMega48:

import socket
import sys
import serial

ser = serial.Serial('COM1', 19200, timeout=1)
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)

chunk=""
i=0
data = ser.readline()
while True:
    i+=1
    data = ser.readline()
    data=data.replace("n","")
    data=data.replace("r","")
    data="["+data[:-1]+"]"
    data=eval(data)
    val=sum(data)/float(len(data))
    print i,data,val
    chunk=chunk+"%.01f,"%val
    if i==100:
        print "nSAVING"
        i=0
        f=open("data.txt","a")
        f.write(chunk)
        f.close()
        chunk=""

and the code to PLOT the data file:


import matplotlib.pyplot as plt
import numpy

def smoothTriangle(data,degree,dropVals=False):
        """performs moving triangle smoothing with a variable degree."""
        """note that if dropVals is False, output length will be identical
        to input length, but with copies of data at the flanking regions"""
        triangle=numpy.array(range(degree)+[degree]+range(degree)[::-1])+1
        smoothed=[]
        for i in range(degree,len(data)-degree*2):
                point=data[i:i+len(triangle)]*triangle
                smoothed.append(sum(point)/sum(triangle))
        if dropVals: return smoothed
        smoothed=[smoothed[0]]*(degree+degree/2)+smoothed
        while len(smoothed)<len(data):smoothed.append(smoothed[-1])
        return smooth

print "loading..."
f=open("data.txt")
raw="["+f.read()+"]"
f.close()
data=eval(raw)

print "converting..."
data=numpy.array(data)
data=data/1024.0*5 #10-bit resolution, 5V max

print "graphing"
plt.plot(data)

plt.grid(alpha=.5)
plt.title("ATMega48 LM335 Temperature Sensor")
plt.ylabel("Voltage (V)")
plt.xlabel("Time (5/sec)")
plt.show()

Also, the AVR-GCC code loaded on the ATMega48:

#define F_CPU 9210000UL

#include <avr/io.h>
#include <util/delay.h>

void init_usart(unsigned long);

unsigned int readADC(char times){
    unsigned long avg=0;
    for (char i=0; i<times; i++){
        ADCSRA |= (1<<ADSC); // reset value
        while (ADCSRA & ( 1<<ADSC)) {}; // wait for measurement
        avg=avg+ADC;
    }
    avg=avg/times;
    return avg;
}

int main (void){

    ADMUX = 0b0100101; // AVCC ref on ADC5
    ADCSRA = 0b10000111; //ADC Enable, Manual Trigger, Prescaler 128
    ADCSRB = 0;

    DDRD=255;

    init_usart(19200);
    for(;;){
        for(char j=0;j<10;j++){
            sendNum(readADC(10)>>6); // shift to offset 10bit 16bit
            send(44); // COMMA
            PORTD=255;_delay_ms(10);
            PORTD=0;_delay_ms(10);
            }
        send(10);send(13); // LINE BREAK
        }
    }

void sendNum(unsigned int num){
        char theIntAsString[7];
        int i;
        sprintf( theIntAsString, "%u", num );
        for (i=0; i < strlen(theIntAsString); i++)
        {send(theIntAsString[i]);}
}

void send (unsigned char c){
        while((UCSR0A & (1<<UDRE0)) == 0) {}
        UDR0 = c;
}

void init_usart (unsigned long baud)
{
    /////////////////////////
    //        Baud Generation
    unsigned int UBRR_2x_off;
    unsigned int UBRR_2x_on;
    unsigned long closest_match_2x_off;
    unsigned long closest_match_2x_on;
    unsigned char off_2x_error;
    unsigned char on_2x_error;

    UBRR_2x_off = F_CPU/(16*baud) - 1;
    UBRR_2x_on = F_CPU/(8*baud) - 1;

    closest_match_2x_off = F_CPU/(16*(UBRR_2x_off + 1));
    closest_match_2x_on = F_CPU/(8*(UBRR_2x_on + 1));

    off_2x_error = 255*(closest_match_2x_off/baud - 1);
    if (off_2x_error <0) {off_2x_error *= (-1);}
    on_2x_error = 255*(closest_match_2x_on/baud -1);
    if (on_2x_error <0) {on_2x_error *= (-1);}

    if(baud > F_CPU / 16)
    {
        UBRR0L = 0xff & UBRR_2x_on;
        UBRR0H = 0xff & (UBRR_2x_on>>8);
        UCSR0A |= (1<<U2X0);
    } else {

        if (off_2x_error > on_2x_error)
        {
            UBRR0L = 0xff & UBRR_2x_on;
            UBRR0H = 0xff & (UBRR_2x_on>>8);
            UCSR0A |= (1<<U2X0);
        } else {
            UBRR0L = 0xff & UBRR_2x_off;
            UBRR0H = 0xff & (UBRR_2x_off>>8);
            UCSR0A &= ~(1<<U2X0);
        }
    }
    /////////////////////////
    //    Configuration Registers
    UCSR0B = (0<<RXCIE0) |//We don't want this interrupt
    (0<<TXCIE0) |//We don't want this interrupt
    (0<<UDRIE0) |//We don't want this interrupt
    (1<<RXEN0) |//Enable RX, we wont use it here but it can't hurt
    (1<<TXEN0) |//Enable TX, for Talkin'
    (0<<UCSZ02);//We want 8 data bits so set this low

    UCSR0A |= (0<<U2X0) |//already set up, so don't mess with it
    (0<<MPCM0) ;//We wont need this

    UCSR0C = (0<<UMSEL01) | (0<<UMSEL00) |//We want UART mode
    (0<<UPM01) | (0<<UPM00) |//We want no parity bit
    (0<<USBS0) |//We want only one stop bit
    (1<<UCSZ01) | (1<<UCSZ00) |//We want 8 data bits
    (0<<UCPOL0) ;//This doesn't effect UART mode
}

UPDATE: A day later I added multiple sensors to the device. I calibrated one of them by putting it in a plastic bag and letting it set in ice water, then I calibrated the rest to that one. You can see as my room temperature slowly falls for the night, the open air sensor (red) drops faster than the insulated one in a Styrofoam box. Also, I did a touch of math to convert voltage to kelvin to Fahrenheit. You can also see spikes where it quickly approached 90+ degrees from the heat of my fingers as I handled the sensor. Cool!

UPDATE: a day and a half later, here's what the fluctuations look like. Notice the cooling of night, the heating of day, and now (near the end of the graph) the scattered rain causes more rapid fluctuations. Also, although one sensor is in an insulated styrofoam box, it still fluctuates considerably. This measurement system is prepped and ready to go for crystal oven tests!

Markdown source code last modified on January 18th, 2021
---
title: Serial Port Multi-Channel Temperature Measurement
date: 2010-11-24 08:17:03
tags: circuit, microcontroller, python, old
---

# ATMega48 + LM335 + MAX232 = Serial Port Multi-Channel Temperature Measurement

__While working to perfect my temperature-controlled manned experimental propagation transmitter (MEPT), I developed the need to accurately measure temperature inside my Styrofoam enclosure (to assess drift) and compare it to external temperature (to assess insulation effects).__ I accomplished this utilizing the 8 ADC channels of the ATMega48 and used its in-chip USART capabilities to send this data to a PC for logging.  I chose the ATMega48 over the ATTiny2313 (which has USART but no ADCs) and the ATTiny44a (which has ADCs but no USART).  From when I see, no ATTiny series ATMEL AVR has both!  Lucky for me, the [ATMega48 is cheap](http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=ATMEGA48-20PU-ND) at $2.84 USD. Here's my basic circuit idea: 

<div class="text-center img-border"> 

[![](IMG_4559_thumb.jpg)](IMG_4559.jpg)

</div>

EDIT: the voltage reference diagram is wrong at the bottom involving the zener diode. Reference the picture to the right for the CORRECT way to use such a diode as a voltage reference. (stupid me!)

<div class="text-center"> 

![](aref.jpg)

</div>

__MULTIPLE SENSORS__ - Although in this demonstration post I only show a single sensor, it's possible to easily have 8 sensors in use simultaneously since the ATMega48 has 8 ADC pins, and even more (infinitely) if you want to design a clever way to switch between them.

__LM335 Temperature Sensor__ - selected because it's pretty cheap (< $1) and quantitative. In other words, every 10mV drop in voltage corresponds to a change of 1ºC.  If I wanted to be even cheaper, I would use thermistors (<$0.10) which are more qualitative, but can be calibrated I guess.

Notes on power stability  - The output of the sensor is measured with the ADC (analog to digital converter) of the microcontroller. The ADC has a 10-bit resolution, so readings are from 0 to 2^10 (1024).  AREF and AVCC can be selected as a voltage reference to set what the maximum value (1024) should be.  If the ADC value is 1V (for example) and AREF is 1V, the reading will be 1024.  If AREF becomes 5V, the reading will be 1024/5. Make sense?  If AREF is fluctuating like crazy, the same ADC voltage will be read as differing vales which is not what we want, therefore care should be taken to ensure AREF is ripple-free and constant.  Although I did it by adding a few capacitors to the lines of the power supply (not very precise), a better way would be to use a <a href="http://en.wikipedia.org/wiki/Zener_diode">zener diode (perhaps 4.1V?) as a voltage reference.

<div class="text-center img-border">

[![](IMG_4575_thumb.jpg)](IMG_4575.jpg)

</div>

<b>Here is my circuit.</b> I'm clocking the chip at 9.21MHz which works well for 19200 baud for serial communication. Refer to my other MAX232 posts for a more detailed explanation of how I chose this value. The temperature sensor (blurry) is toward the camera, and the max232 is near the back. Is that an eyelash on the right? Gross!

<div class="text-center img-border"> 

![](logger.jpg)

</div>

<b>The data is read by a Python script</b> which watches the serial port for data and averages 10 ADC values together to produce a value with one more significant digit. This was my way of overcoming continuously-fluctuating values.

<div class="text-center img-border"> 

[![](IMG_4564_thumb.jpg)](IMG_4564.jpg)

</div>

<b>Here you can see me testing the device</b> by placing an ice cube on the temperature sensor. I had to be careful to try to avoid getting water in the electrical connections. I noticed that when I pressed the ice against the sensor firmly, it cooled at a rate different than if I simply left the ice near it.<b>NOTICE THE PROGRAMMER</b> in the background (slightly blurry). The orange wires connect the AVR programmer to my circuit, and after the final code is completed and loaded onto the microcontroller these orange wires will be cut away.

<div class="text-center"> 

[![](lm335-microcontroller-graph-annotated_thumb.jpg)](lm335-microcontroller-graph-annotated.png)

</div>

<b>Here is some actual data from the device.</b> The LM335 readout is in Kelvin, such that 3.00V implies 300K = 80ºF = 27ºC (room temperature). The data is smooth until I touch it with the soldering iron (spike), then it gets cool again and I touch it with a cold piece of metal (wimpy dip), then later I put an ice cube on it (bigger dip). Pretty good huh? Remember, 0.01V change = 1ºC change. The bottom of the dip is about 2.8V = 280K = 44ºF = 7ºC. If I left the cube on longer, I imagine it would reach 0ºC (273K, or 2.73V).<b>For everyone's reference, here's the pinout diagram of the ATMega48:</b>

<div class="text-center img-medium"> 

[![](atmega48pinout_thumb.jpg)](atmega48pinout.png)

</div>

```python
import socket
import sys
import serial

ser = serial.Serial('COM1', 19200, timeout=1)
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)

chunk=""
i=0
data = ser.readline()
while True:
    i+=1
    data = ser.readline()
    data=data.replace("n","")
    data=data.replace("r","")
    data="["+data[:-1]+"]"
    data=eval(data)
    val=sum(data)/float(len(data))
    print i,data,val
    chunk=chunk+"%.01f,"%val
    if i==100:
        print "nSAVING"
        i=0
        f=open("data.txt","a")
        f.write(chunk)
        f.close()
        chunk=""

```

<b>and the code to PLOT the data file:</b>

```python

import matplotlib.pyplot as plt
import numpy

def smoothTriangle(data,degree,dropVals=False):
        """performs moving triangle smoothing with a variable degree."""
        """note that if dropVals is False, output length will be identical
        to input length, but with copies of data at the flanking regions"""
        triangle=numpy.array(range(degree)+[degree]+range(degree)[::-1])+1
        smoothed=[]
        for i in range(degree,len(data)-degree*2):
                point=data[i:i+len(triangle)]*triangle
                smoothed.append(sum(point)/sum(triangle))
        if dropVals: return smoothed
        smoothed=[smoothed[0]]*(degree+degree/2)+smoothed
        while len(smoothed)<len(data):smoothed.append(smoothed[-1])
        return smooth

print "loading..."
f=open("data.txt")
raw="["+f.read()+"]"
f.close()
data=eval(raw)

print "converting..."
data=numpy.array(data)
data=data/1024.0*5 #10-bit resolution, 5V max

print "graphing"
plt.plot(data)

plt.grid(alpha=.5)
plt.title("ATMega48 LM335 Temperature Sensor")
plt.ylabel("Voltage (V)")
plt.xlabel("Time (5/sec)")
plt.show()
```

<b>Also, the AVR-GCC code loaded on the ATMega48:</b>

```c
#define F_CPU 9210000UL

#include <avr/io.h>
#include <util/delay.h>

void init_usart(unsigned long);

unsigned int readADC(char times){
    unsigned long avg=0;
    for (char i=0; i<times; i++){
        ADCSRA |= (1<<ADSC); // reset value
        while (ADCSRA & ( 1<<ADSC)) {}; // wait for measurement
        avg=avg+ADC;
    }
    avg=avg/times;
    return avg;
}

int main (void){

    ADMUX = 0b0100101; // AVCC ref on ADC5
    ADCSRA = 0b10000111; //ADC Enable, Manual Trigger, Prescaler 128
    ADCSRB = 0;

    DDRD=255;

    init_usart(19200);
    for(;;){
        for(char j=0;j<10;j++){
            sendNum(readADC(10)>>6); // shift to offset 10bit 16bit
            send(44); // COMMA
            PORTD=255;_delay_ms(10);
            PORTD=0;_delay_ms(10);
            }
        send(10);send(13); // LINE BREAK
        }
    }

void sendNum(unsigned int num){
        char theIntAsString[7];
        int i;
        sprintf( theIntAsString, "%u", num );
        for (i=0; i < strlen(theIntAsString); i++)
        {send(theIntAsString[i]);}
}

void send (unsigned char c){
        while((UCSR0A & (1<<UDRE0)) == 0) {}
        UDR0 = c;
}

void init_usart (unsigned long baud)
{
    /////////////////////////
    //        Baud Generation
    unsigned int UBRR_2x_off;
    unsigned int UBRR_2x_on;
    unsigned long closest_match_2x_off;
    unsigned long closest_match_2x_on;
    unsigned char off_2x_error;
    unsigned char on_2x_error;

    UBRR_2x_off = F_CPU/(16*baud) - 1;
    UBRR_2x_on = F_CPU/(8*baud) - 1;

    closest_match_2x_off = F_CPU/(16*(UBRR_2x_off + 1));
    closest_match_2x_on = F_CPU/(8*(UBRR_2x_on + 1));

    off_2x_error = 255*(closest_match_2x_off/baud - 1);
    if (off_2x_error <0) {off_2x_error *= (-1);}
    on_2x_error = 255*(closest_match_2x_on/baud -1);
    if (on_2x_error <0) {on_2x_error *= (-1);}

    if(baud > F_CPU / 16)
    {
        UBRR0L = 0xff & UBRR_2x_on;
        UBRR0H = 0xff & (UBRR_2x_on>>8);
        UCSR0A |= (1<<U2X0);
    } else {

        if (off_2x_error > on_2x_error)
        {
            UBRR0L = 0xff & UBRR_2x_on;
            UBRR0H = 0xff & (UBRR_2x_on>>8);
            UCSR0A |= (1<<U2X0);
        } else {
            UBRR0L = 0xff & UBRR_2x_off;
            UBRR0H = 0xff & (UBRR_2x_off>>8);
            UCSR0A &= ~(1<<U2X0);
        }
    }
    /////////////////////////
    //    Configuration Registers
    UCSR0B = (0<<RXCIE0) |//We don't want this interrupt
    (0<<TXCIE0) |//We don't want this interrupt
    (0<<UDRIE0) |//We don't want this interrupt
    (1<<RXEN0) |//Enable RX, we wont use it here but it can't hurt
    (1<<TXEN0) |//Enable TX, for Talkin'
    (0<<UCSZ02);//We want 8 data bits so set this low

    UCSR0A |= (0<<U2X0) |//already set up, so don't mess with it
    (0<<MPCM0) ;//We wont need this

    UCSR0C = (0<<UMSEL01) | (0<<UMSEL00) |//We want UART mode
    (0<<UPM01) | (0<<UPM00) |//We want no parity bit
    (0<<USBS0) |//We want only one stop bit
    (1<<UCSZ01) | (1<<UCSZ00) |//We want 8 data bits
    (0<<UCPOL0) ;//This doesn't effect UART mode
}

```

<b>UPDATE:</b> A day later I added multiple sensors to the device. I calibrated one of them by putting it in a plastic bag and letting it set in ice water, then I calibrated the rest to that one. You can see as my room temperature slowly falls for the night, the open air sensor (red) drops faster than the insulated one in a Styrofoam box. Also, I did a touch of math to convert voltage to kelvin to Fahrenheit. You can also see spikes where it quickly approached 90+ degrees from the heat of my fingers as I handled the sensor. Cool!

<div class="text-center"> 

[![](3traces_thumb.jpg)](3traces.png)

</div>

<b>UPDATE:</b> a day and a half later, here's what the fluctuations look like. Notice the cooling of night, the heating of day, and now (near the end of the graph) the scattered rain causes more rapid fluctuations. Also, although one sensor is in an insulated styrofoam box, it still fluctuates considerably. This measurement system is prepped and ready to go for crystal oven tests!

<div class="text-center"> 

[![](insulated3_thumb.jpg)](insulated3.png)

</div>

Improved MEPT Enclosure

I've been pretty busy lately, but I drip to the hardware store with the XYL produced a PVC enclosure that looked perfect for my ongoing MEPT (manned experimental propagation transmitter) projects. I didn't want to buy it (it was a little pricey by my standards, at $6 USD, which is about the total cost of the transmitter!) but the wife convinced me and I'm glad she did! I intended it to replace the styrofoam enclosure I had been using, but I wasn't thinking clearly and drilled holes in the box and mounted screws through them. While electrically this is a wonderful way to add antenna connections, thermally it was a bad idea. The main point of the enclosure was to be temperature stable! Oh well. I put the whole thing in the Styrofoam and as a test, I'm leaving it outside tonight. I can't wait to see how it goes! Here are some photos of the project.

Update: Even when being housed outdoors when temperature fluctuations vary greatly between day and night, this MEPT is surprisingly stable! When I open the box, it's very warm inside, so I am thinking that the voltage regulators and the MOSTFETs of the PA are heating the device nicely. Here's a capture spanning about 2 hours. The vertical height of each "V" is about 10Hz, so I estimate that for this span of time, drift is <1Hz. However, I do believe that long term (day to day) frequency stability is still not optimal, but only time will tell.

Signal report: briefly, this is my signal in Alaska courtesy of KL7UK. My signal is the V-shaped one near the bottom:

Markdown source code last modified on January 18th, 2021
---
title: Improved MEPT Enclosure
date: 2010-11-14 20:22:38
tags: qrss, amateur radio, circuit
---

# Improved MEPT Enclosure

__I've been pretty busy lately__, but I drip to the hardware store with the XYL produced a PVC enclosure that looked perfect for my ongoing MEPT (manned experimental propagation transmitter) projects. I didn't want to buy it (it was a little pricey by my standards, at $6 USD, which is about the total cost of the transmitter!) but the wife convinced me and I'm glad she did!  I intended it to replace the styrofoam enclosure I had been using, but I wasn't thinking clearly and drilled holes in the box and mounted screws through them.  While electrically this is a wonderful way to add antenna connections, thermally it was a bad idea.  The main point of the enclosure was to be temperature stable! Oh well. I put the whole thing in the Styrofoam and as a test, I'm leaving it outside tonight. I can't wait to see how it goes!  Here are some photos of the project.

<div class="text-center img-border">

[![](IMG_4526_thumb.jpg)](IMG_4526.jpg)
[![](IMG_4534_thumb.jpg)](IMG_4534.jpg)
[![](IMG_4547_thumb.jpg)](IMG_4547.jpg)
[![](IMG_4548_thumb.jpg)](IMG_4548.jpg)

</div>

__Update:__ Even when being housed outdoors when temperature fluctuations vary greatly between day and night, this MEPT is surprisingly stable! When I open the box, it's very warm inside, so I am thinking that the voltage regulators and the MOSTFETs of the PA are heating the device nicely.  Here's a capture spanning about 2 hours. The vertical height of each "V" is about 10Hz, so I estimate that for this span of time, drift is <1Hz.  However, I do believe that long term (day to day) frequency stability is still not optimal, but only time will tell.

<div class="text-center img-border">

[![](qrss_stable_thumb.jpg)](qrss_stable.jpg)

</div>

__Signal report__: briefly, this is my signal in Alaska courtesy of KL7UK. My signal is the V-shaped one near the bottom: 

<div class="text-center img-border">

[![](KL7UK_alaska_thumb.jpg)](KL7UK_alaska.jpg)

</div>

Deciphering QR Code from Radio Spectrogram

Although I've been ridiculously busy the last few weeks, I've been eying some posts circulating around the Knights QRSS mailing list regarding mysterious signals in the 40m band. They recognized it as a QR Code and tried decoding it with phones and such, but the signal wasn't strong enough above the noise to be automatically deciphered.

That's the original spectrograph as captured by ON5EX in Belgium. It's a pretty good capture, it's just not great enough to be automatically decoded. The first thing I did was pop it open in ImageJ, separate the channels, and use the most useful one (red, I believe). When adjusted for brightness and contrast, I was already at a pretty good starting point.

I tried using an automated decoder at this point (http://zxing.org/w/decode.jspx) but it wasn't able to recognize the QR code. I don't blame it! It was pretty rough. I decided to manually recreate one, so I slapped the image into InkScape, add a grid, and align the image with the grid. From there, it was as easy as drawing a single grid-square-sized rectangle and copy/pasting it in all the right places.

However problems came when working on those last few rows. The static was pretty serious, so I tried a lot of different filters / adjustments. One of the greatest benefits was when I stretched the image super-wide and performed a "rolling ball" background subtraction, then revered it to its original size. That greatly helped reduce the effect of the vertical striping, and let me visually determine where to place the last few squares by squinting a bit.

Once it was all done, I saved the output as orange, then later converted it to black and white for web-detection via the ZXing Decoder.

The final result:

which when decoded reads:

WELL DONE / F4GKA QSL PSE 73

Yay! I did it. Although my call sign is AJ4VD, I'm spending the afternoon at the University of Florida Gator Amateur Radio Club station and am using their computers, so I might QSL as W4DFU. Also, there's a lot to be said for ON5EX for capturing/reporting the QR code in the first place. After a bit of research, it turns out that F4GKA is one of the Knights! I should have known it =o)

Thanks for the fun challenge!

Markdown source code last modified on January 18th, 2021
---
title: Deciphering QR Code from Radio Spectrogram
date: 2010-11-11 15:13:29
tags: qrss, amateur radio
---

# Deciphering QR Code from Radio Spectrogram

__Although I've been ridiculously busy the last few weeks,__ I've been eying some posts circulating around the [Knights QRSS mailing list](http://cnts.be/mailman/listinfo/knightsqrss_cnts.be) regarding mysterious signals in the 40m band.  They recognized it as a [QR Code](http://en.wikipedia.org/wiki/QR_Code) and tried decoding it with phones and such, but the signal wasn't strong enough above the noise to be automatically deciphered.

<dev class="center border medium">

[![](on5ex-odd_thumb.jpg)](on5ex-odd.jpg)

</dev>

__That's the original spectrograph__ as captured by ON5EX in Belgium. It's a pretty good capture, it's just not great enough to be automatically decoded.  The first thing I did was pop it open in ImageJ, separate the channels, and use the most useful one (red, I believe).  When adjusted for brightness and contrast, I was already at a pretty good starting point.

<dev class="center border medium">

![](better.jpg)

</dev>

__I tried using an automated decoder__ at this point (<http://zxing.org/w/decode.jspx>) but it wasn't able to recognize the QR code. I don't blame it! It was pretty rough.  I decided to manually recreate one, so I slapped the image into [InkScape](http://inkscape.org/), add a grid, and align the image with the grid.  From there, it was as easy as drawing a single grid-square-sized rectangle and copy/pasting it in all the right places.

<dev class="center border medium">

[![](building_thumb.jpg)](building.jpg)

</dev>

__However problems came__ when working on those last few rows.  The static was pretty serious, so I tried a lot of different filters / adjustments.  One of the greatest benefits was when I stretched the image super-wide and performed a "rolling ball" background subtraction, then revered it to its original size. That greatly helped reduce the effect of the vertical striping, and let me visually determine where to place the last few squares by squinting a bit.

<dev class="center border medium">

[![](building3_thumb.jpg)](building3.jpg)

</dev>

__Once it was all done,__ I saved the output as orange, then later converted it to black and white for web-detection via [the ZXing Decoder](http://zxing.org/w/decode.jspx).

<dev class="center border medium">

[![](building2_thumb.jpg)](building2.jpg)

</dev>

__The final result:__

<dev class="center">

![](finished.jpg)

</dev>

__which when decoded reads:__

`WELL DONE / F4GKA QSL PSE 73`

__Yay!__ I did it.  Although my call sign is AJ4VD, I'm spending the afternoon at the University of Florida Gator Amateur Radio Club station and am using their computers, so I might QSL as W4DFU.  Also, there's a lot to be said for ON5EX for capturing/reporting the QR code in the first place. After a bit of research, it turns out that F4GKA is one of the Knights! I should have known it =o)

Thanks for the fun challenge!
September 17th, 2010

Climbing A 1786 Foot Tall Tower

When I saw this, I had to share it.

... and no, that's not me!

Markdown source code last modified on January 18th, 2021
---
title: Climbing A 1786 Foot Tall Tower
date: 2010-09-17 08:40:38
---

# Climbing A 1786 Foot Tall Tower

__When I saw this,__ I had to share it.

![](https://www.youtube.com/embed/RDNGZVmhkTo)

... and no, that's not me!
Pages