Ficara Emilio Pietro Giovanni Home AVR micro projects page
Ultima modifica: 23/01/2008


RxMet1: Rs232 interface for Hygro-Thermo remote station

First of all, my language is Italian, so I apologize for the errors you can find in this page (I hope my translation will be better than the Google one). Due to large amount of downloads for the RxMet1, I decided to write some additional notes that will help someone to build the circuit. In the free version of the firmware (available for download) the AVR micro only converts the raw data received from 433MHz RX module in ascii format, then sends the resultant ascii string to the PC serial port. A VB program (also downloadable) uses my module meteo.dll for converting the raw data in temperature and humidity data. This DLL can be called by any VB program and is free (for non commercial use !) Someone asked for the protocol used by the sensor to transmit the informations on 433MHz radio channel. There are NO INFORMATIONS about this protocol on the net (more specifically, I haven't found after many and many searches). So the procedure for decoding the data was based on binary sampling of the sensor transmission at different temperatures and humidity conditions. This involved the heating of the sensor with an hair dryer and the cooling in the freezer. At every condition the raw data was assigned to the corresponding base station display data, then with patience and many ones and zeroes written to tenths of paper sheets I discovered how the info was coded. Not all the bits have been decoded: the last 32 of the string seems to be a CRC validation for the data, but at this moment, I haven't find a rule for them. The digits related to the temperature and the humidity are coded with a sort of look-up table, so in most cases the use of CRC can be skipped. This is the way I used in this project. The validity of the data is NOT sure at 100%, but if there is an error, it is so big that can be easily filtered by application software. For example I've seen two consecutive samples of 13.5°C and 63.5°C ; obviously the second read is wrong. Errors are very rare (I've seen two in three months) but not impossible. The probability of wrong decodes is higher when the received signal is poor. If you put the transmitter not so far from the interface, this probability reaches the zero. There is also a version of the firmware in which the decoding job is done by the AVR micro itself; in this version the serial output is an ascii string with explicit Temperature and Humidity values, but this firmware isn't FREE (but cheap) ! For who asked for the transmission protocol, this request can't be satisfied 'cause some legal accident can fall on me if I make public such things. For additional informations regarding the construction of the interface, contact me through the home page of the site, using the communication's form.

Thank you.
Emilio Ficara


"Questions & Answers":


  • Q: ... received this link from Russia http://wapbox.nm.ru : there is a brief protocol description for a similar receiver unit and also a transmitter unit.

  • Q: ... for your RxMet1 (Rs232 interface for Hygro-Thermo remote station) what kind of HF RX module do you use ?

    A: ... You can find the PDF of the RF module at this link: BC-NBK data sheet (in english)
  • Q: ... I´m very interested in your solution for the wireless temperature sensor. I was thinking of doing this myself, but with a temperature sensor from La Crosse ... Your site has answered many of my questions, however there is still some questions left unanswered ... You are using the Attiny2313 to decode the raw data to ascii format, I think this can be done in labview so this chip is not necesarry for me, but instead connect the rf-receiver directly to the rs-232 port. In sweden there is a similar rf-receiver as the one you use, please see: http://www.kjell.com/filarkiv/SUPPORTPDF/81-90/88/88900/88-900%20433%20Mhz%20Mottagarmodul.pdf and http://www.kjell.com/filarkiv/SUPPORTPDF/81-90/88/88901/88-901_88-902%20%20433%20Mhz%20Mottagare_Sändare%20Karakteristik.pdf Do you think this module can be used ? Did you have to adjust the frequency in your rf-receiver to be able to contact the sensor ? If so, how did you find the right frequency ? Do you see any problems with connecting the rf-receiver directly to the rs-232 port and decoding the information in the software ? Do you know if there is any difference for the protocoll between the Oregon and the La Crosse sensor transmitter ?

    A: ... No frequency adjustment was needed in the receiver for the 433MHz module (with the Oregon Scientific sensor). The modulation is OOK (on off keyed) so the data format isn't compatible with the serial port of PC. The data is coded in a sort of Manchester - biphase modulation and the level is 0/5V. So, the circuit I've made does two jobs: the first, converts from manchester to asynchronous serial protocol; the second, translates the voltage level from 0/5V (TTL) to -5/+5 (EIA). The decoding job is done (on the PC) by the DLL available for download on my site. I don't know the LaCrosse protocol, but I suppose that will be something similar to the Oregon, probably the data bits are scrambled to make incompatible the data (as usual). The way I used to decode those bits, was to make many reads of the values on the base display and the corresponding binary streams and find the relation between the first and the second.
  • Q: ... I have now built the circuit according to your specs. After some trouble with downloading the firmware I finally succeed to get the Attiny running...at least I guessing since the LED is flashing constantly. However there is no values when I'm running your software to read the binary stream of the rs-232 port (as I guessed...). So I was hoping you have the time to answer some more questions from me ? What kind of antenna do you use ? The specs for my rf-receiver is some kind of a 50 Ohm antenna, but right now I only use a 35 cm long wire. Does your firmware or the pc software have some kind of filter, so if there is a bit-stream that aren’t "Oregon-compatible" these are sorted out and not transferred to the rs-232 port or visual in your program ? The best for me right now is if ALL datastreams is presented even if they are just noise. I will take a closer look at the circuit with a oscilloscope tomorrow, but when I measured the output pin of the ATtiny (pin 3) this is constantly high (+4,95V). Will this go low if a datastream is received ? Do you have any other idea what the failure could be ? Is there any chance I could look at your uncompiled firmware ?

    A: ... the firmware on ATtiny2313 makes a filter for incoming signals from 433MHz receiver, checking for congruency of the data bits. The LED output is a mirror for the input stream: this means that any variation on input port (PortB.0) will be reflected on the led port (PortB.5). The input data MUST have correct timing to be decoded. If you measure the LED output with an oscilloscope, you can see the same signal that comes from the RF module, but sampled every 100 uS. If the timings are NOT correct, the software doesn't recognize the stream header and doesn't output any character on the RS232 serial output. The serial data output (when present) is sent at 19200,n,8,1 in ascii form, so you can use any program (such as Hyperterminal) as monitor. If you use the ATtiny2313 (and not AT90S2313) remember to run the batch file "TinySetClock.bat" to force the external oscillator to take effect. The program I used to burn the hex file into the micro is the SP12.EXE; it can be downloaded from the Internet for free (try google search).

    Example of dll use with VB6

    // declare the convert function
    Private Declare Function RawConvert Lib "meteo.dll" (ByVal text As String) As String
    
    // use the function
    //  rxraw contains the full ascii string received from RxMet1
    //  rxd containd the decoded Temperature and Hygro
    dim rxd as string
    dim rxraw as string
    
        rxd = RawConvert(rxraw)
    
    
    Download the meteo.dll file only (zipped 4.06 KB)