ATtiny202 - Oregon Scientific temperature sensor replacement

Go To Last Post
39 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My THN132N wireless temperature sensor is dead so I have decided to replace it by ATtiny202 with built in temperature measurement and send data to the Oregon Scientific base station.

 

I was inspired by the project "Make Your Own Remote Temperature/Humidity Sensor" and I would like to adopt Arduino code to ATtiny202. Unfortunately MPLAB X IDE and XC8 compiler reports some errors. Is there any way how to use Arduino constructor function class in XC8 or how to modify it e.g.

OregonSensor::OregonSensor(uint8_t txPin, uint8_t channel, uint8_t sensorID, bool Humidity)

See WlessOregonV2.cpp code.

 

This topic has a solution.
Last Edited: Fri. Mar 19, 2021 - 07:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Kevil wrote:
any way how to use Arduino constructor function class in XC8 or how to modify it e.g.
C++ code in a C only compiler. Nope I don't think so.

 

You'll have to port the code to C (or use GCC which includes the av-g++ C++ compiler that Arduino uses).

 

On the whole a C++ constructor is usually little more than a FOO_begin() or FOO_init() kind of function anyway.

 

Of course another option is to see if there is a "202 compatible core" for Arduino and just stick with Arduino anyway.

 

EDIT: looking at that code it is very "C like" and only touches on C++ usage so should be fairly easy to convert to C but one bit that may take a bit more effort is:

void DecodeOOK::interuptHandler(void) {
    static int16_t last;
    // determine the pulse length in microseconds, for either polarity
    wl_pulse = micros() - last;
    last += wl_pulse;
}

so you would need to implement an equivalent of Arduino's timer interrupt stuff to provide an equivalent for this.

 

Really GCC or Arduino look like the better options.

Last Edited: Mon. Feb 15, 2021 - 09:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Implementing of pulses is pretty easy with ATtiny202. I don't need to use micros() but I will use TCB in Periodic or Single Shot mode (e.g. 80µs for Triac control).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel Microchip Studio can import Arduino "sketches" - have you tried that ... ?

 

https://www.avrfreaks.net/forum/microchip-trying-wean-people-arduino-atmel-studio

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Built-in temperature measurement?  And a triac mention?

 

Are you planning to use an on-chip temperature sensor?  Remember that [assuming resolution and accuracy are suitable; are they?] you will be measuring the temperature inside the chip.  And the chip is mounted to your circuit board.  And all may be inside an enclosure.  So given all the sources of heat dissipation, it might be a very poor measure of e.g. ambient air temperature.
 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you. I will try Atmel Studio but first I will verify the Arduino sketch on Arduino.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevil wrote:
Atmel Studio 

note that it's called "Microchip Studio" now

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Are you planning to use an on-chip temperature sensor?

Yes, I have tried it already and it's working fine. Note that the original Oregon Scientific temperature sensor (thermistor) is soldered by a short wire to the PCB inside of the plastic case. I will just replace the original PCB with my PCB (ATiny202 + 433 MHz transmitter).

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevil wrote:
Yes, I have tried it already and it's working fine.

And you tried it under full load, in warm conditions, and enclosed?  And there was no difference from ambient?  Wow; remember the movie "Cool Runnings"...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. Feb 15, 2021 - 07:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevil wrote:
Thank you. I will try Atmel Studio but first I will verify the Arduino sketch on Arduino.

Note MCS7 is the same compiler as Arduino, no real advantage if it works in Arduino, unless you need to debug and have the required DB hardware/interface.

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No arduino needed, but still uses c++ 

https://godbolt.org/z/Pz9szz

not much there and could easily be done in C.

 

without division-

https://godbolt.org/z/d5jGq8

 

You can add other compilers to MPLABX, and are not stuck just using XC8. If you don't already have arduino, you can get its compiler and in either case can point mplabx to the avr/bin folder and you now have c++. The above example is for a mega4809, but will work just the same for a tiny0/1.

 

I have some temp sensors on an nRF52 board, and the internal temp sensor is 'close' to the more accurate temp sensors but I wouldn't use it for anything more than 'close enough'-

[0952.000000][../Temperature.hpp:79 ::read]
  internal raw: 105  F: 79.2
[0952.125965][../Temperature.hpp:123 ::read]
  Tmp117 raw: 3524  F: 81.5
[0952.148901][../Temperature.hpp:176 ::read]
  Si7051 raw: 27716  F: 81.4

 

I also have a mega4809 board 3ft from the nRF52 board, and its internal temp also reads 'close' to all the other readings. Still don't have much trust in the internal, though. I don't have a great deal of confidence in the better temp sensors either, although they will be 'more' close enough for my use.

Last Edited: Mon. Feb 15, 2021 - 11:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Gotta laugh, at least a little bit.

 

In the original article referenced in the original post the author stated that he had to redo some of the data trasmission library because the micro wasn't fast enough.

 

Perhaps it would have been easier to run the micro at 20 MHz, instead of 1 MHz, and instantly gained a 20x performance increase!

 

For a episodic temperature data packet transmission, running the micro at 20 MHz,and then sleeping between transmissions, might have been an easier approach to solving this issue while maintaininig energy effiency.

 

JC  

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I have decided to start from scratch with ATtiny202 and follow the Manchester Encoder Using USART and CCL on ATtiny817. It is running well on standard ATtiny202 frequency 20 MHz / 6 = 3.333 MHz and 9600 bits/s.

 

ATtiny202 same result as in the AN2371 example above:

 

 

 

Although I found the OregonScientific-RF-Protocols (need version 2.1) I do not fully understand how to generate the "sauce" around Manchester encoded temperature data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What ‘sauce’ are you missing? I decoded the protocol years ago.
It is pretty easy just using a timer with compare to generate the bits. No need for clock and logic to generate the manchester.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DocJC wrote:
running the micro at 20 MHz,and then sleeping between transmissions, might have been an easier approach to solving this issue while maintaininig energy effiency.

Indeed, that is often the case: run fast to finish quickly, then maximise sleep.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
It is pretty easy just using a timer with compare to generate the bits. No need for clock and logic to generate the manchester.

I am almost done with the program for synchronous USART and logic, just need to buy the 433 MHz transmitter and test it on real Oregon Scientific station.
 

Preamble v2.1 sequence start, magenta (USART cyan & CCL):


 

Sync pattern 10 11 10 11 i.e. 0101 = 'A' with LSB first

Part of the code:
 

        USART_0_write(0x15);    // Two short bursts to alert Oregon receiver
        for (int i = 3; i > 0; i--) {
            USART_0_write(0x55); // 0x10101010 Preamble
        }
        USART_0_write(0x66);    // Sync 10 11 10 11 i.e. 0 1 0 1 'A' LSB first
        USART_0_write(0x40);    // Finish Sync

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I’ll have to dig out my code to recall the finer details, but why 9600? Its more like 1024 bits/second if i remember correctly. 9600 is pushing it a bit for 433MHz OOK. I also seemto recall the preamble is a series of ‘1’s then the sync. I’ll see if i can dig up my old code tomorrow and refresh my memory.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are right, I need to change the speed to  1024 wink.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had a quick look at the code I wrote many years ago.

 

The start is 24 Manchester '1' bits followed by 0101, again Manchester encoded. This is followed by a number of nibbles with the required data.

 

If in doubt, capture a real transmission to compare with yours.

Last Edited: Mon. Feb 22, 2021 - 11:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I captured real V2.1 data. Everything is clear just I don't know the meaning of last two nibbles after checksum (2 nibbles) at the end called Post-amble.
 

Sync Preamble 0xA, bits 1, 2, 4, 8 starting from LSB:
 


 

Last Edited: Sun. Mar 7, 2021 - 05:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Over-peaked scope probe. Those tops and bottoms should be flat.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


ka7ehk wrote:
Those tops and bottoms should be flat.

True dat.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did we really need a moob picture? I can't un-see that now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure of the exact reason for the post-amble apart from being a specific end-of-message sequence. Might be something to do with anti-collision detection (or collision for that matter) as the Oregon devices transmit asynchronously - i assume they rely on being started at much the same time for timing. I do find they clash every so often. I dare say the cost of Bluetooth has dropped to a point where it might be a better  and more reliable choice than 433MHz OOK.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Finally I succeeded. I can now transmit temperature data from the ATtiny202 through 433 MHz transmitter to the Oregon Scientifics base station.
 

I am going to make a final version of the program with sleep mode to transmit data each 30 seconds. The ATtiny202 clock 20 MHz is devided by 24 to 833333 Hz to save the power consumption and to get the 1 024 Hz bit rate. I am using synchronous USART and  Configurable Custom Logic (CCL) to generate Manchester code.
 

The program uses 103 out of 128 bytes of RAM and 932 out of 2 048 bytes of Program Flash.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevil wrote:
Finally I succeeded.

Good news.

 

Would you care to share the secret - for the benefit of future readers who may com along with the same question.

 

Then mark the solution.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Attached you can find my MPLAB X IDE working test project which sends temperature 12.3°C each 30 seconds to the Oregon Scientific base station 259981. The ATtiny202 is simulating the Oregon Scientific THN132N Wireless Temperature Sensor.

 

The THN132N is using Oregon Scientific protocol 2.1 and 1024 Hz bit rate. 1024 BAUD doesn't work but 1028 BAUD Yes.

 

The ATtiny202 clock 20 MHz is divided by 24 which is 833333 Hz. Synchronous IRQ USART routines generated at start.atmel.com

 

ATtiny202 pins PA3 (SOIC 7) CLK, PA1 (SOIC 4) TX and PA6 (SOIC 2) is the Manchester code output to 433 MHz transmitter.

 

Message structure (send twice with pause 6.42 ms between these two messages and then long pause 30 seconds):

After test while (USART_0_tx_elements != 0) there ares s till two USART registers shifting data out (USART buffer ~ 19.64 ms)   

So you need actually set delay to 29 ms to get 6.42 ms pause (29 -  19.64 = 9.36 ms)

_delay_ms(29); // ~6.42 ms; USART buffer ~ 19.64 ms

 

Preamble 16 pulses (i.e. send 4x 0xAA)
Sync, send 1x 0x99 which is in Manchester 0xA

Actual Data Test Data

Nibble:

  0  0xE  Sensor Id: 0xEC40 (THN132N)

  1  0xC

  2  0x4

  3  0x0

  4  0x4  Channel No. = 3  (1<<(ch-1))

  5  0x6  Rolling Code, Value changes randomly every time the sensor is reset (it's up to you)

  6  0x8 

  7  0x0  Battery voltage 0 = OK (Bit value 0x4 is the battery low flag)

  8  0x3  Temperature, tenth of a degree (BCD temperature in degrees Centigrade i.e 12.3°C)

  9  0x2  Temperature, units of degrees

10  0x1  Temperature, tens of degrees

11  0x0  Temperature sign, 0 = positive temperature (Non-zero for negative values)

12  0x6  Checksum (of nibbles 0 to 11) i.e. 0x36

13  0x3

14  0xD  CRC* nibbles 0 to 11 excluding Rolling Code (Nibbles 5 and 6), start CRC value = 0x43, polynomial = 0x07

15  0x7

 

CRC calculation is not part of the test program yet. I calculated it in Visual Studio C++:
 

#include <stdio.h>
#include <stdlib.h>

#define CRC8INIT  0x43
#define CRC8POLY  0x07

char msglen = 5;
unsigned char msg[] = { 0xEC, 0x40, 0x40, 0x32, 0x10 };	// CRC 0x7D, for my test program

unsigned char crc8(unsigned char* data_in, char number_of_bytes_to_read) {

	unsigned char  crc, loop_count, bit_counter;

	crc = CRC8INIT;

	for (loop_count = 0; loop_count != number_of_bytes_to_read; loop_count++)
	{
		crc = crc ^ data_in[loop_count];

		bit_counter = 8;
		do {
			if ((crc & 0x80) != 0) {
				crc <<= 1;
				crc = crc ^ CRC8POLY;
			}
			else crc <<= 1;
			bit_counter--;

		} while (bit_counter > 0);
	}

	return crc;
}

int main()
{
	unsigned char crc;
	crc = crc8(msg, msglen);
	printf("\r\n crc %2x", crc);
	return (0);
}

 

 

Attachment(s): 

Last Edited: Fri. Mar 19, 2021 - 07:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

fyi

Kevil wrote:

		crc = crc ^ data_in[loop_count];

'loss of sign on assignment' from a linter.

		crc = (unsigned int) crc ^ data_in[loop_count];

 

Kevil wrote:

	printf("\r\n crc %2x", crc);

crc promoted to int

	printf("\r\n crc %2x", (unsigned int) crc);

 


PC-lint Plus Online Demo - Gimpel Software - The Leader in Static Analysis for C and C++ with PC-lint Plus

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Just to let make the PCB. U1 is the Microchip MCP16251 (high-efficiency, fixed frequency, synchronous step-up DC-DC converter 1.5 to 3.3V), U2 ATtiny202 and U3 is the 433 MHz transmitter.
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The layout needs to be improved -especially around U1 otherwise it will make a better transmitter than the actual tx module!

Last Edited: Thu. Apr 8, 2021 - 12:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What's wrong ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tracks are too thin, too long and bad placement. The dc/dc converter switches at high frequency and needs proper attention paid to layout - refer to the datasheet. It gives you the recommended layout. The inductor and capacitors are critical as well. Whilst it might be ‘working’, it could be inefficient and radiating..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't do much more because of the constraints (AA battery next to "+" sign, two holes) of the PCB layout to fit into the Oregon temperature sensor casing. I can only move R2 & C2 closer to the U1 voltage converter chip. Tracks are 0.3 mm (11.811 mils).
 

See the design of the Microchip Evaluation Board:
 

Last Edited: Thu. Apr 8, 2021 - 08:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it works for you, then i’d say you’re lucky as you’ve violated a few design rules. 11thou tracks are ok for interconnects, but you want thicker for the power traces to minimise inductance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kevil wrote:
See the design of the Microchip Evaluation Board

indeed - look at the thickness of the power interconnects on that!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

PCB in production, waiting for delivery smiley.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it doesn’t work, then you’ll know where to look. For one, L1 doesn’t look to be the right size. Pcbs are cheap, so just spin another if required.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Working PCB as expected wink. R1 label should be more to the right below U1. I forget to move it there below resistor.
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Temperature measured by ATtiny202 at the Base Station.