Build a PIC-Based Remote Temp Sensor

[marc4g]

Hello:

In this month's issue, the article by Ryan Clark refs. to temperature_transmitter.c.

I am new to PIC programming, but should there not be a file posted on /index.php....Clarke?

Marc

"BUILD A PIC-BASED REMOTE
TEMPERATURE
SENSOR
By Ryan Clarke
Post comments on this article and find any associated files and/or downloads at www.nutsvolts.com /index.php?/magazine/article/ january2014_Clarke.

Referencing temperature_transmitter.c, the first order of business is configuring the PIC appropriately by setting the desired device configuration words:"

[elproducts]

This is a great article but I wonder why he didn't just use a CHIPINO module instead of Arduino?
He could then use the XC8 compiler for both the 8 pin PIC and the Receiving module.

[PatrickG]

This is a great article, well written, and seemed like great project, helping me to get back into using PIC's while also using Arduinos, which is where I have been playing around for the last year, or two.

I ordered the parts, assembled the board, and downloaded (the new version of) MPLAB to program the PIC, including the 8-bit compiler for PIC 12's. All went well. I have a PicKit3 programmer that I have used in the past for programming PIC16 and PIC18 devices using an old demo board (the PICDem 2 Plus), but it does not take the smaller PIC 12 series, so I tried to program the PIC using a breadboard with power, ground, a pull up resistor on the MCLR line, and the the unit hooked up per the PICKit manual.

I was able to get the program to compile and download onto the PIC (I think), but the chip (and I tried with 2 different ones, with the same result) does not do anything. I checked with an o-scope, using the programmed chip on the board I built and a breadboard, too, and I cannot seem to get the PIC's to come to life. I also built the transmitter using another set of compoonents on a breadboard with the same results. Separately, I have tested each of the components in both builds, and all work, including the radios, transmitting and receiving, using Arduinos and different code.

The MPLAB software says it downloaded the chip successfully, and I can watch the lights on the programmer as if it is communicating OK with the PC and the PIC. I can program both of these chips repeatedly with no erros and the loaded successfuly comment.

This is my first time programming anything using the new MPLABX, and/or a PIC12, and it has been years since I have programmed a PIC16 or PIC18. Can anyone suggest what I am missing? It seems like the program is loaded on the chip, but the microcontroller program counter is on hold, or something like that. I am NOT trying to download the debug build, either.

Does anyone have any suggestions?

[hanavin]

Hello:



I am new to PIC programming, but should there not be a file posted on /index.php....Clarke?

Marc

Hi Marc, There should be zip file under download section.

http://www.nutsvolts.com/index.php?/magazine/downloads/

Chuck

[arcs_n_sparks]

I too built this project and have not seen success (yet).

Putting a scope on the RF transmitter shows the PIC sending out the correct set of bytes (I went down to two seconds on the watchdog timer for debug). Those are received at the RF receiver, plus a lot of other 433 MHz traffic.

One thing I am confused about is that six bytes are sent (two preamble, device ID, two data bytes, and checksum). However, the Ardunio code is set up to receive four bytes. I have not figured how the Arduino is ignoring the preamble bytes in the process.

[G8RPI]

PatrickG wrote
"I was able to get the program to compile and download onto the PIC (I think), but the chip (and I tried with 2 different ones, with the same result) does not do anything."
Sounds like the clock or reset options are not correctly set.
Check that MPLAB is set to use the config settings from the code, not the MPLAB programmer defaults. It's in the MPLAB CONFIG tab under Configuration bits, check box in pop-up window.

HTH,
Robert

[rfclarke]

This is a great article but I wonder why he didn't just use a CHIPINO module instead of Arduino?
He could then use the XC8 compiler for both the 8 pin PIC and the Receiving module.

Because I didn't have a CHIPINO

Ryan Clarke

[rfclarke]

I too built this project and have not seen success (yet).

Putting a scope on the RF transmitter shows the PIC sending out the correct set of bytes (I went down to two seconds on the watchdog timer for debug). Those are received at the RF receiver, plus a lot of other 433 MHz traffic.

One thing I am confused about is that six bytes are sent (two preamble, device ID, two data bytes, and checksum). However, the Ardunio code is set up to receive four bytes. I have not figured how the Arduino is ignoring the preamble bytes in the process.

This is a problem with the 433 MHz ISM band... it can be extremely noisy with other ISM traffic as well as Amateur Radio transmissions (it shares part of the 70cm band). Also, as mentioned in the article, the gain of these type of receiver modules is WAY up when it doesn't sense a "good" signal. This introduces a lot of noise in the system, hence the preamble bytes to "condition" the receiver. This can be alleviated with other transmitter/receiver options (using an FSK system, XBee, etc).

As for the Arduino and the preamble bytes, it doesn't care about them. The preamble is only there to drive the gain of the receiver down, so that you get good reception. Since the preamble could be all messed up on the receiver side, you just throw out everything until you receive the first good data byte (the address in this case).

Ryan Clarke

[rfclarke]

Does anyone have any suggestions?

Have you resolved your issue? I would be happy to help. As someone else has stated, may be a configuration issue. Let me know.

Ryan Clarke

[arcs_n_sparks]

I too built this project and have not seen success (yet).

Putting a scope on the RF transmitter shows the PIC sending out the correct set of bytes (I went down to two seconds on the watchdog timer for debug). Those are received at the RF receiver, plus a lot of other 433 MHz traffic.

One thing I am confused about is that six bytes are sent (two preamble, device ID, two data bytes, and checksum). However, the Ardunio code is set up to receive four bytes. I have not figured how the Arduino is ignoring the preamble bytes in the process.

This is a problem with the 433 MHz ISM band... it can be extremely noisy with other ISM traffic as well as Amateur Radio transmissions (it shares part of the 70cm band). Also, as mentioned in the article, the gain of these type of receiver modules is WAY up when it doesn't sense a "good" signal. This introduces a lot of noise in the system, hence the preamble bytes to "condition" the receiver. This can be alleviated with other transmitter/receiver options (using an FSK system, XBee, etc).

As for the Arduino and the preamble bytes, it doesn't care about them. The preamble is only there to drive the gain of the receiver down, so that you get good reception. Since the preamble could be all messed up on the receiver side, you just throw out everything until you receive the first good data byte (the address in this case).

Ryan Clarke

Mr. Clarke,

Appreciate your reply. Understand the preamble is to drive the gain down. However, when I look at the Arduino code:

Code: Select all

  while(rfSerial.available() < 4);
  address = rfSerial.read();
  high_byte = rfSerial.read();
  low_byte = rfSerial.read();
  checksum = rfSerial.read();

The Arduino is waiting until four bytes are in the receive buffer. If the first preamble byte drives the receiver into a "normal" mode, what is to prevent the second preamble byte from being recognized and loaded into the receiver buffer? Of course, it would fail on checksum at that point. I also understand the address test.

Sincerely,
Mark Strauch

[rfclarke]

Mr. Clarke,

Appreciate your reply. Understand the preamble is to drive the gain down. However, when I look at the Arduino code:

Code: Select all

  while(rfSerial.available() < 4);
  address = rfSerial.read();
  high_byte = rfSerial.read();
  low_byte = rfSerial.read();
  checksum = rfSerial.read();

The Arduino is waiting until four bytes are in the receive buffer. If the first preamble byte drives the receiver into a "normal" mode, what is to prevent the second preamble byte from being recognized and loaded into the receiver buffer? Of course, it would fail on checksum at that point. I also understand the address test.

Sincerely,
Mark Strauch

Mark,

The reason for waiting for four incoming bytes is due to how the checksum result is computed. With a noisy RF environment or a receiver with the gain maxed out, this would not be a problem. However, in testing, I had the transmitter and receiver directly connected (no RF links). If you happen to read a preamble byte, no harm, no foul, as the checksum will fail. The Arduino is plenty fast to typically not miss a byte (or at least not too many).

Let me know if that clears it up. If you have a better method, please share!

[PatrickG]

PatrickG wrote
"I was able to get the program to compile and download onto the PIC (I think), but the chip (and I tried with 2 different ones, with the same result) does not do anything."
Sounds like the clock or reset options are not correctly set.
Check that MPLAB is set to use the config settings from the code, not the MPLAB programmer defaults. It's in the MPLAB CONFIG tab under Configuration bits, check box in pop-up window.

HTH,
Robert

I was able to get the program running. Indeed, it was the config settings. I also discovered that the header file was not attached, even though it was in the window, it was not included in the build. The circuit works.

Thanks for the help.

[awirger]

Nice article.

I'm currently working my way through the project. So far I have only implemented the transmitter portion of the circuit, but I believe there is a problem with the checksum calculation. When you watch the data sent from the transmitter with a logic analyzer, the checksum never changes, regardless of whether the high and low data changes. I tracked this back to the pic C code DEVICE_ID definition. The device id is defined this way in the current code:

#define DEVICE_ID 0x11;

The trailing semicolon keeps the compiler from using the high and low values in the checksum calculation:

checksum = DEVICE_ID + ADRESH + ADRESL;

I took the semicolon out of the DEVICE_ID definition and rebuilt/reloaded, and the problem went away.

#define DEVICE_ID 0x11

I'm actually surprised that the compiler (xc8\v1.30) didn't catch this.

I should finish implementing the receiver in the next few days. I'll let you know how it goes.

Cheers.

[awirger]

Today I finished the remote temperature sensor project. I don't have an Arduino, so I hooked up the output of the receiver to a PC serial port by using a MAX232 in the middle. Then I wrote a quick C# app to read the data and display the results.

A few notes for anyone out there who is going to build this project:

1. The RF link is very noisy, so quite a few of the data transmissions fail due to bad checksums, etc.
2. I tried to run the project at 1200, 2400, and 4800 baud. 4800 didn't work well. 1200 and 2400 worked for most (~90%) transmissions.
3. Whenever the watchdog timer wakes the micro up, it seems to send some extra garbage characters out the serial port. The checksum logic on the receiver end discards it.

Thanks for the article.

[rfclarke]

Nice article.

I'm currently working my way through the project. So far I have only implemented the transmitter portion of the circuit, but I believe there is a problem with the checksum calculation. When you watch the data sent from the transmitter with a logic analyzer, the checksum never changes, regardless of whether the high and low data changes. I tracked this back to the pic C code DEVICE_ID definition. The device id is defined this way in the current code:

#define DEVICE_ID 0x11;

The trailing semicolon keeps the compiler from using the high and low values in the checksum calculation:

checksum = DEVICE_ID + ADRESH + ADRESL;

I took the semicolon out of the DEVICE_ID definition and rebuilt/reloaded, and the problem went away.

#define DEVICE_ID 0x11

I'm actually surprised that the compiler (xc8\v1.30) didn't catch this.

I should finish implementing the receiver in the next few days. I'll let you know how it goes.

Cheers.

Great catch. I missed that as well! Thanks for the heads up and correction!