Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auriol temperature sensor Model no Z31743a-TX triggers Prologue callback #45

Closed
Batilan opened this issue Aug 11, 2014 · 43 comments

Comments

@Batilan
Copy link
Contributor

commented Aug 11, 2014

I have written a callback for the Auriol temperature sensor Model no Z31743a-TX which works fine.
This sensor is available in the "Auriol temperature station", the package containing both the sensor and the "base station" is available at e.g. LIDL for € 9,99 (at least in DE and NL).

auriol-temperaturstation

However when testing and triggering different sensor ID's I found out that it may also trigger the prologue_callback. It might be hard to differentiate the 2 callbacks as both devices send 7 identical packets. The prologue callback is triggered when the mentioned id0 is 1001 (as documented) or 0101 (only in the code), so it has a chance of 1/8 of triggering a "false positive" when it receives packets from the Auriol sensor (can be "fixed" by taking the battery out of the Auriol sensor so it generates a new sensor ID that hopefully does not contain one of the mentioned patterns (might need a few retries).

In the prologue_callback there is a remark "FIXME validate the received message better", any chance of making this happen. I would be glad to assist.

The Auriol temperature sensor submits only 32 bits, the Prologue temperature sensor submits 36 bits I read, however the bits_per_row is not available to the callback, so it is not an option to check for that when we want to keep the callbacks simple. Any other ideas?

What testing / qualification needs to be done before submitting the code (pull request)?

Attached some output of triggering the prologue callback by the Auriol sensor:


*** signal_start = 29051340, signal_end = 29280530
signal_len = 229190,  pulses = 233
Iteration 1. t: 102    min: 83 (1)    max: 121 (232)    delta 36
Iteration 2. t: 102    min: 83 (1)    max: 121 (232)    delta 0
Distance coding: Pulse length 102

Short distance: 488, long distance: 977, packet distance: 2319

p_limit: 102

[00] {0} 00 : 00000000
[01] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[02] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[03] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[04] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[05] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[06] {32} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000
[07] {33} 52 80 df 57 00 : 01010010 10000000 11011111 01010111 00000000

Sensor temperature event at 2014-08-11 20:41:38:
protocol       = Auriol
rid            = 52
temp           = 22.3
Sensor temperature event:
protocol      = Prologue
button        = 0
battery       = Low
temp          = -52.3
humidity      = 112
channel       = 1
id            = 5
rid           = 40
hrid          = 28
52 80 df 57 00

When the sensor ID changes, it no longer triggers the prologue_callback:


*** signal_start = 27438007, signal_end = 27660354
signal_len = 222347,  pulses = 233
Iteration 1. t: 93    min: 69 (1)    max: 117 (232)    delta 36
Iteration 2. t: 93    min: 69 (1)    max: 117 (232)    delta 0
Distance coding: Pulse length 93

Short distance: 493, long distance: 981, packet distance: 2323

p_limit: 93

[00] {0} 00 : 00000000
[01] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[02] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[03] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[04] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[05] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[06] {32} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000
[07] {33} aa 80 d3 a6 00 : 10101010 10000000 11010011 10100110 00000000

Sensor temperature event at 2014-08-11 20:41:31:
protocol       = Auriol
rid            = aa
temp           = 21.1
@deennoo

This comment has been minimized.

Copy link
Contributor

commented Nov 3, 2014

Hello,

i'm interest by testing your code to get my z31743a information.

can you send it to me ?

@Batilan

This comment has been minimized.

Copy link
Contributor Author

commented Nov 3, 2014

Hi Deennoo, I will prepare a pull request. I think the issue is not so much in the Auriol decoding but also in the Prologue callback because it doesn't do full message validation (neither does my code by the way because I have not yet determined the way the checksum is calculated). Please allow me some time to prepare.

@Batilan

This comment has been minimized.

Copy link
Contributor Author

commented Nov 5, 2014

Please for now have a look at https://github.com/Batilan/rtl-wx/tree/auriol-Z31743a-TX/src I adjusted the rtl_433.c file because I wanted to use rtl-wx for it's ability to decode Oregon Scientific sensors also. I will merge the changes in rtl_433 later.

Please note that this branch is not up-to-date with the latest rtl-wx which includes support for highcharts for nicer graphs.

@deennoo

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2014

ok thank you (sorry for late reponse i'll waiting for a mail notification)

@deennoo

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2014

thank you for this that work perfectly !

your code start to work with OTIO sht-20 & sht-10 (very famous in france, temp & humidity sensor with or without lcd) sensor depending of the Id it got on battery insertion.

it work once time with auriol z32171-tx again depending about ID when battery insert.

how can i help you ? (i have to admit that i'm a real newbee on developping), sending you raw data and wave record from otio sensor ?

@deennoo

This comment has been minimized.

Copy link
Contributor

commented Nov 14, 2014

i finally get rtl-wx running on my pi, on putty lunching/rtl-wx/src ./rtl-wx
i get info from my auriol and 3 otio sensor with fantasy value -128°c (in south of france this is hard to live...)

apache server is running well, but i can't see the auriol value

@deennoo

This comment has been minimized.

Copy link
Contributor

commented Nov 15, 2014

Batilan,

i start to decode OTIO protocol, and i found the way to get temp and humidity value on binary, decimal and hexa decimal (channel, bat statut and +or- sign are to find but i'm on chaze...), i'm looking to get this result since August 2014). i can give my how to if you want to put it on rtl-wx.

How can i contact you in privat ?

@Batilan

This comment has been minimized.

Copy link
Contributor Author

commented Nov 19, 2014

Sorry, missed a few of your messages the last few days. Note that I am not the author of rtl-wx (this is magellannh). If you know the OTIO protocol it should be relatively easy to add a decoder to rtl_433.c Just choose the right decoder (OOK_PWM_D, OOK_PWM_P or OOK_MANCHESTER) find the right values for the short, long and reset limits and see if rtl_433 is able to decode. I plan on writing a wiki about rtl_433, but it will take some time.

Like mentioned my rtl-wx branch is not up-to-date with the latest rtl-wx, I should do some work on getting my work into the main stream of rtl-wx. However at the moment I'm busy making a plugin infrastructure for rtl_433 so that users can choose which sensors to enable, and developers can add sensors without having to modify the rtl_433,c source file. I think this will enable a much more flexible use of rtl_433.

@Batilan

This comment has been minimized.

Copy link
Contributor Author

commented Nov 19, 2014

BTW You can reach me on github at atilas nl

@deennoo

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2014

ok thank you very much for this plug ins work... this will help very much

Using a rtl_433 from pm-cz : https://github.com/pm-cz/rtl_433 i get my otio sensor working (and it seams that a lot of sensor are reconize).

but when i copy your aureol code on his rtl_433.c file, my otio sensor are reconize twice :

  • One time with the Silvercrest Weather (2008)/Auriol (2011) protocol with the good value
  • One time with your aureol protocol with the bad value...

how can i fix that ? by searching crc on aureol ?

have you some exemple for your research on the Z31743a-TX decoding ?

@Batilan

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2014

Hi Deenoo,

This is probably because the validation of in the Z31743a-TX decoding isn't complete (see the FIXME comment in the code), we need to figure out the checksum so we can do better message validation. Besides getting the data bits from the Z31743a-TX I have not done any serious research on it (like determining the mentioned checksum)

It would also help if we can determine the bits/packet but the callback currently doesn't provide this info. Once I have the plugin infra ready I want to offer a second type of callback which does offer the bits/packet info, but that won't help for now.

If someone knows about the checksum for this Auriol transmitter I can add it to the code, then the otio sensor probably won't trigger the Auriol callback anymore (actually the callback will recognize the data isn't valid).

What data value's are returned BTW? I'm also thinking about adding some sanity check for temperature (like assuming data isn't valid when e.g. temp is > 60 C or < -40 C. This is bad news for people in the Sahara or in Siberia but will alleviate the problem a little (it by no means is a serious solution and should only be used as a last resort when other more reliable checks aren't available)

@pm-cz

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2014

This is a problem I found when adding some sensors in my (https://github.com/pm-cz/rtl_433) branch and one of the reasons (besides the talk about complete reworking of the code and workload) that I did not do a pull request myself and did not have time to integrate new patches from mainline.

Since I was playing with similar set of sensors, a few comments:

  • Some Auriol sensors do not provide a checksum, I probably did not write a code for this sensor so I am not sure (for other sensors, I check CRC in my code)
  • The temperature sanity checks help to a degree, but sometimes the temperature moves to "belivable" range and sanity check will not help
  • The sensor (esp. the module used inside of it) typically has a working range and does not provide data outside of it, so the "Sahara" and "Arctic" scenarios may not happen anyway. I tried to set the ranges according to sensor specifications.

I hope this helps at least a little.

@deennoo

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2014

thanks again for your input

Otio sensor active z31743a callback, but z31743a don't active otio callback.

some question are comming :

How the signal is analyse ?
Does his try to be decode by first callback , if no result, the second, if no result the third etc etc (on the same order as writting on the code source).

  • if yes is it easy to put : signal give result stop to try other callback.(exemple : using product ID) and put the Z31743A-TX call back at the end on the callback chapter or call it on last position

pm-cz : second question : Temp sanity : does your code can fit for other sensor (with some adaptation of course)

third question : concerning artic/sahara scenarios : this can be use with temp + product ID + time stamp.
ex : input 1 : ID1234 give +20.5°c @ 12:00:10
input 2 : ID1234 give +16.5°c @ 12:00:15 program decid to ignire this input (this input can't be real because nowhere lost 4°c on 5 secondes).

@pm-cz

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2014

They try to process it with all "matching" callbacks, so you get multiple parses of single input.
Don't know, there is a lot of sensors, some measure in 0,1C, some in F moved to some value, etc.

Since the program does not keep any data from previous sensing, you would have to do this when parsing the output.

@Batilan

This comment has been minimized.

Copy link
Contributor Author

commented Nov 23, 2014

@pm-cz @deennoo About preventing false positive hits for the Z31743A-TX sensor: I think there is a checksum in this Auriol sensor: Byte 1 (index 0) contains the sensor ID, part of byte 2 and byte 3 contain the temperature. Probably the 4'th byte is some kind of checksum. However I tried a few standard functions and they don't seem to generate any kind of valid checksum. So it would need some investigation to find out the checksum. I did notice that the 7't and 8'th bit of the first byte always seem to be '10', so probably they are not part of the sensor-id. However I don't think it is wise to assume they will always be '10' because it might be that battery low is in those bits.

How many bits are in the Otio sensor packets? You can find out by using rtl_433 -a (the number of bits per row is shown like {32}). As mentioned currently the callback can not determine how many bits the PWM decoder saw. I can however add a check for the 5'th byte: it should always be 0, if this is not the case then we can be sure it is not the Auriol Z31743A-TX sensor. This may prevent some false positives but not all: for that we need to find and implement the checksum.

With respect to the 'broader picture': Is anyone working currently on the mentioned 'complete reworking of the code'? Maybe Benjamin Larsson (@merbanan) is already working on it, at least I would like to hear his idea's about possible improvements so I can take them along.

As mentioned at this moment I'm creating a plugin infrastructure (I have a basic working version in my plugin branch but its only in Alfa stage). I did notice some possible enhancements I would like in a next version of the plugin interface like providing the number of bits in each 'packet' (row), also currently each callback triggers calling the PWM decodingwhich seems somewhat inefficient to me as it needs to go through the time samples again and again.

I will create an issue on rtl_433 in which I will describe the idea's I have for some improvements so everyone can provide feedback and idea;s. This may prevent multiple people working on the same issues at the same time without knowing about each others work. I think rtl_433 is a great tool for discovering the world of 433 MHz sensors and actuators, but it probably needs some adaptions to make it more scalable and reusable. I'm not sure if this should be done in rtl_433 or if a 'rtl_433_ng' (Next Generation ;-) should be created for this.

@Batilan

This comment has been minimized.

Copy link
Contributor Author

commented Nov 23, 2014

@deennoo I added an extra check on the 5'th byte in the packets being 0 to minimize the risk of false positives in https://github.com/Batilan/rtl-wx/tree/auriol-Z31743a-TX , If your otio sensor generates more then 32 bits per packet the Auriol callback will probably not show a false result, if the otio only generates 32 bits or less it will not result in an improvement (and we have to find the checksum algorithm)

@rct

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2014

@Batilan, have you looked at jcarduino's changes to make more of the decode/detection structure available for the call backs to use? See issue #53. There is also a pull request. He asked for feedback but so far there isn't much. It's something you might want to take a look at for your updated plugin branch since all of the call backs will need some modifications.

@deennoo

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2014

@Batilan

that works

@valentt

This comment has been minimized.

Copy link

commented Jan 3, 2015

I have Auriol weather station and downloading latest rtl_433 source code still doesn't support this sensor. Also downloading @Batilan fork is not working also, but for other resons (compile issues):

make /home/ubuntu/toolchain-arm_cortex-a9_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/arm-openwrt-linux-uclibcgnueabi-gcc -c -o obj/rtl-wx.o rtl-wx.c -I. -I/home/ubuntu/toolchain-arm_cortex-a9_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/include/libusb-1.0 -Ilibrtlsdr/include make: /home/ubuntu/toolchain-arm_cortex-a9_gcc-4.8-linaro_uClibc-0.9.33.2_eabi/bin/arm-openwrt-linux-uclibcgnueabi-gcc: Command not found Makefile:52: recipe for target 'obj/rtl-wx.o' failed make: *** [obj/rtl-wx.o] Error 127

What are you suggestions for others that have this device? How to get support for it?

@valentt

This comment has been minimized.

Copy link

commented Jan 3, 2015

this is what "rtl_433 -a" captures from mine Auriol sensor:

*** signal_start = 34245414, signal_end = 34460872
signal_len = 215458,  pulses = 233
Iteration 1. t: 78    min: 69 (17)    max: 88 (216)    delta 2257
Iteration 2. t: 80    min: 72 (31)    max: 89 (202)    delta 10
Iteration 3. t: 82    min: 74 (49)    max: 90 (184)    delta 5
Iteration 4. t: 83    min: 76 (69)    max: 91 (164)    delta 5
Iteration 5. t: 84    min: 77 (81)    max: 92 (152)    delta 2
Iteration 6. t: 85    min: 77 (94)    max: 93 (139)    delta 1
Iteration 7. t: 86    min: 78 (103)    max: 94 (130)    delta 2
Iteration 8. t: 87    min: 79 (116)    max: 95 (117)    delta 2
Iteration 9. t: 88    min: 80 (131)    max: 96 (102)    delta 2
Distance coding: Pulse length 88

Short distance: 522, long distance: 1011, packet distance: 2348

p_limit: 88

[00] {0} 00 : 00000000 
[01] {32} 94 80 ee 09 00 : 10010100 10000000 11101110 00001001 00000000 
[02] {32} 94 80 ee 09 00 : 10010100 10000000 11101110 00001001 00000000 
[03] {32} 94 80 ee 09 00 : 10010100 10000000 11101110 00001001 00000000 
[04] {32} 94 80 ee 09 00 : 10010100 10000000 11101110 00001001 00000000 
[05] {32} 94 80 ee 09 00 : 10010100 10000000 11101110 00001001 00000000 
[06] {32} 94 80 ee 09 00 : 10010100 10000000 11101110 00001001 00000000 
[07] {33} 94 80 ee 09 00 : 10010100 10000000 11101110 00001001 00000000
@deennoo

This comment has been minimized.

Copy link
Contributor

commented Jan 3, 2015

@valentt

This comment has been minimized.

Copy link

commented Jan 3, 2015

@deennoo thanks for the tip, after compiling and running this version of rtl_433 this is what I get:

Sensor temperature event:
protocol      = Prologue
button        = 0
battery       = Low
temp          = 142.7
humidity      = 96
channel       = 1
id            = 9
rid           = 72
hrid          = 48
94 80 59 36 00

Which is obviously too high temperature because outside temperature is currently 10°C

And this is output from rtl_433 -a command:

*** signal_start = 1536940, signal_end = 1738739
signal_len = 201799,  pulses = 233
Iteration 1. t: 80    min: 66 (5)    max: 94 (228)    delta 841
Iteration 2. t: 80    min: 66 (5)    max: 94 (228)    delta 0
Distance coding: Pulse length 80

Short distance: 516, long distance: 1003, packet distance: 2347

p_limit: 80

[00] {0} 00 : 00000000 
[01] {32} 94 80 80 31 00 : 10010100 10000000 10000000 00110001 00000000 
[02] {32} 94 80 80 31 00 : 10010100 10000000 10000000 00110001 00000000 
[03] {32} 94 80 80 31 00 : 10010100 10000000 10000000 00110001 00000000 
[04] {32} 94 80 80 31 00 : 10010100 10000000 10000000 00110001 00000000 
[05] {32} 94 80 80 31 00 : 10010100 10000000 10000000 00110001 00000000 
[06] {32} 94 80 80 31 00 : 10010100 10000000 10000000 00110001 00000000 
[07] {33} 94 80 80 31 00 : 10010100 10000000 10000000 00110001 00000000 
@deennoo

This comment has been minimized.

Copy link
Contributor

commented Jan 3, 2015

What is your sensor type ? Référence, Ian, all is write on your sensor.

Try to Google : sensor id and arduino, i got a succès with this for a friend of mine.

@valentt

This comment has been minimized.

Copy link

commented Jan 3, 2015

Sensor model is Z31743B-TX (version 09/2013). Here are data dumps with temprature readings from station: http://pastebin.com/DPq160e3 and also raw data dump - http://pastebin.com/ZWBCTXHt

I have just finished writing blog post on this topic - http://kernelreloaded.com/reading-temperature-data-from-auriol-temperature-station-via-rtl_433/

It looks like converting third octet from binary to decimal gives temperature, did I correctly conclude this?

From reading this line: [01] {32} 94 80 b2 5a 00 : 10010100 10000000 10110010 01011010 00000000 temperature is locedted on third octet "10110010" and that converted to decimal is 178 which divided by 10 gives 17.8 witch is exactly the same that display on station was showing during this capture.

rtl_433_auriol_aha

I'm not sure how to decode humidity data because station isn't showing this information, any suggestions?

ps. strange thing is that after one data package next package has only "ffffff" and no temperature data (check raw data logs).

@deennoo

This comment has been minimized.

Copy link
Contributor

commented Jan 3, 2015

Great you got your temp with b2 !

Just a matter of decoding now ! (Can't help i'm not a killer on programing)

I try to help Nodotrx project (rfxcomtrx like but homemade http://www.listenlive.nl/blog/ he just discover RTL sdr capability and can be helpfull).

@Batilan

This comment has been minimized.

Copy link
Contributor Author

commented Jan 7, 2015

@valentt, Nice article! Its always nice to find out the required decoding yourself. You are almost there! However when temperatures rise above 25.5 degrees again it will suddenly get cold again ;-)

The code at https://github.com/Batilan/rtl_433/blob/plugins/src/plugin/plugin_auriol.c should be OK for this sensor. Currently it is only in my branch (and in my rtl-wx branch).

@Batilan

This comment has been minimized.

Copy link
Contributor Author

commented Jan 8, 2015

@valent Note that it is also possible to compile my rtl-wx repo when you first switch to the auriol-Z31743a-TX branch by using the command 'git checkout auriol-Z31743a-TX' first.

If you would like to use my rtl_433 version with plugins then use 'git checkout plugins' first. Then you can enable or disable several plugins by removing plugins from /usr/local/lip/plugins (after make install)

@papadeltasierra

This comment has been minimized.

Copy link

commented Apr 1, 2016

I've cracked the checksum for the Auriol sender, as used with LD2569 (e.g. 4-LD2569-2) devices. It works as follows:

  • Create your 24 bits of data (see below)
  • Create a starting 8-bit checksum of 0x00
  • Repeat the following 40 (forty) times (the last 16 times you will have no new data to add!)
    • If the top bit (0x80) of the checksum is set, XOR the checksum with 0x18
    • Rotate the checksum left (bringing the now '9th' bit back to the bottom bit).
    • XOR in the current top bit of the data into the bottom bit (0x01) of the checksum
    • Shift the data left 1 and AND with 0xFFFFFF (discarding the bit you just used)
  • Now the 32-bit data is the 24-bit starting data, ORed with the checksum.

BUT are there any mathematicians out there because if so, some questions for you:

  1. How come this ALWAYS creates a 32-bit value that has even parity? The bottom bit is NOT a parity bit, but it does appear like one!
  2. Any way to avoid the final 16-rotate where we are bringing in new data?
  3. Is there a more efficient method to generating the same checksum?

Now, that 24 bits of data...

  • bits 0-7 - Random value (never 0x00) set when inserting batteries
  • bit 8 - Manual/automatic data send (assume '1' means 'manual' - can someone confirm?)
  • bit 9 - Low battery; also causes a beep from the receiver. Low battery is only cleared by resetting the sender/receiver.
  • bits 10-11 - channel.
  • bits 12-23 - temperature in 'degC x 10'.
    • 0x800 bit set indicates 'negative' in which case the true temperature is 'negative 0x1000 - value'.
  • bits - 24-31 - checksum as described above.

Enjoy!
papadeltasierra.

@zuckschwerdt

This comment has been minimized.

Copy link
Collaborator

commented Apr 1, 2016

Execute the shift (was rotate) before the xor and only xor if the original top-bit (drops off) differs from the next data bit, and now you got a CRC. The poly should be something like 110001b -- maybe... just a thought that came to mind. Might be worth trying to express/test this as CRC.

@papadeltasierra

This comment has been minimized.

Copy link

commented Apr 4, 2016

Christian,

Interesting. Do you know of any CRCs that ‘fake’ extra data? It was the extra 16 steps that threw me because logically the input data for a CRC becomes 0xDDDDDD0000 where DD implies real data.
Paul DS.
From: Christian W. Zuckschwerdt
Sent: Friday, April 01, 2016 3:30 PM
To: merbanan/rtl_433
Cc: papadeltasierra
Subject: Re: [merbanan/rtl_433] Auriol temperature sensor Model no Z31743a-TX triggers Prologue callback (#45)

Execute the shift (was rotate) before the xor and only xor if the original top-bit (drops off) differs from the next data bit, and now you got a CRC. The poly should be something like 110001b -- maybe... just a thought that came to mind. Might be worth trying to express/test this as CRC.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub

@papadeltasierra

This comment has been minimized.

Copy link

commented Apr 23, 2016

Curses! The encoding/protocol is even more cunning. This encoding (with changes - see below) works for the initial transmission but not for following transmissions. Is anyone able to post a sequence of transmissions, ideally with the temperature changing?
Also, using the same nomenclature as before:
Bit 8 is the battery condidion flag with '1' indicating good and '0' indicating low.
Bit 9 bleeps, but seems to have no other function.

@MswPaulDSmith

This comment has been minimized.

Copy link

commented Apr 25, 2016

I'm beginning to think it's my transmitter that is at fault. Is anyone able to indicate what the 233 pulses that you see are (I don't have a working genuine transmitter - I've creating one from an Arduino). Counting off I expect:

7 x (1 + 32) = 7 frame of (long start pulse + 32 data pulses) = 231

So what are the other two pulses?

@papadeltasierra

This comment has been minimized.

Copy link

commented Apr 27, 2016

Anyone got a 'picture' of the raw pulses? I need to see how the frame(s) are started and ended.

@papadeltasierra

This comment has been minimized.

Copy link

commented Jun 3, 2016

OK, this is frustrating! Firstly, bit 8 is the 'low battery' indicator and bit '9' just makes the receiver beep. And with this, and sending using DMA to get an accurate signal and repeating 7 times as per the items above, the first send ALWAYS works. Now it gets odd...
If I set the 'beep' flag (risking irritating everyone within earshot) then the transmission always seems to work, but since I get multiple beeps (between 2 and 4 normally), the sensor must be managing to catch multiples of the retransmissions. Now turn the beep flag off, and the sensor only works very rarely, missing almost all the transmissions except for the first one which still always works.
Has anyone got the slightest idea what I might be missing from the transmissions? What I'm assuming is:
pulse, long frame start,
32 times pulse, zero/one low
repeat above 7 times
final pulse to terminate the last frame.

@papadeltasierra

This comment has been minimized.

Copy link

commented Jul 3, 2016

Aha - there's nothing wrong with my transmitter, the problem is the receiver. It seems that the Auriol base station only provides power to its 433MHz receive module every 30s (or so - still trying to get a precise reading!). So unless sending the data is synced with this schedule, no new data is received. That explains the occasional random receipt of data, and also why the first transmission ALWAYS works - the receiver is in 'sync up' mode and keeps listening until the first data arrives.

@merbanan

This comment has been minimized.

Copy link
Owner

commented Jul 3, 2016

This method help reduce collisions and gives better battery life.

@papadeltasierra

This comment has been minimized.

Copy link

commented Jul 4, 2016

Agreed but it does require the receiver and transmitter to be carefully designed as a single unit and then the receiver to keep sync with the transmitter to avoid drift. I had a quick play yesterday but haven't managed to get the timings right on my transmitter so I'm immediately out of sync. I need to get some more accurate timings to figure out how to schedule the transmitter.

@MswPaulDSmith

This comment has been minimized.

Copy link

commented Feb 9, 2017

A final comment. The encoding is correct and the last piece of the puzzle if you are making a transmitter is to transmit every 31s. Note that this means that you start each set of transmissions 31s after you started the last one - key this time off the START of each transmission and not the END of the last transmission because transmission lengths will changed because different values encode to 433MHz encodings of different length/times so the ends shift relative to the start.
Yesterday I had one of these weather stations in my office tracking my homebrew transmitter all day, the data for the homebrew transmitter being the temperature in my garden a mile away. The temperature was "transmitted" via a different homebrew 433MHz receiver with the two homebrew boxes communicating via the 'Weather Underground' website, the receiver uploading temperature data which the sender downloaded and then transmitted to the weather station on my office desk.

@jose1711

This comment has been minimized.

Copy link

commented Jan 15, 2018

@MswPaulDSmith could you please share details on how you made the transmitter? thank you, jose

@MswPaulDSmith

This comment has been minimized.

Copy link

commented Jan 16, 2018

I used a transmitter similar this this (there are a number of variants).
https://www.ebay.co.uk/itm/5PCS-433Mhz-RF-transmitter-and-receiver-link-kit-Arduino-ARM-MC-U-remote-control/181887579863?hash=item2a595836d7:g:GwkAAOSwrFtZ-76w
I drive this from an ESP8266 pin using DMA to drive PWM. The minimum clock rate is far too high so each '1' that I want to send is actually represented as 16 '1's in the data I send to the DMA (zeros are also 16x of course). Sending 16x 1s fast justs appears as a single long 1 on the output pin.
Use something like an ESP8266 variant 12 or 13 (not a 01!) so that you have enough pins to be able to set function (load new firmware etc) as well as having a free DMA/PWM pin. Other than pull down resistors and a 5V/3.3V regulator, there's nothing more to it. I created a simple antenna from about 18cm of wire rolled into a coil. The transmitter sends over at least 10m.
Hard bit is getting the ESP8266 to drive the DMA, especially resetting it - my code works about 99.9% of the time but there's clearly something not quite right because it locks up occasionally.

@jose1711

This comment has been minimized.

Copy link

commented Jan 17, 2018

@MswPaulDSmith thank you, tbh i have no electrical engineering background and lot to study. in a similar experiment i have tried to replicate signal sent by a remote using raspberry pi (pigpio python library) only to find that my "zeroes and ones" always take longer that the ones that remote generates. there are plenty or projects dealing with analyzing the rf signal but it gets very scarse when you want to transmit. if there's something you can recommend (maybe forget about raspberry pi), please share. thanks again, j

@MswPaulDSmith

This comment has been minimized.

Copy link

commented Jan 17, 2018

Jose, if you are interested in this specific project then this thread has plenty of links to 'here's what the signal should look like'. If you have a different project in mind then you need some way of sniffing the signal. I have used an Arduino to catch signals and drop 'microsecond, on/off' logs quite successfully for 'slow' protocols like infra-red remotes or these temperature sensors. After that it's a case of find suitable computer code to modify to get (typically) DMA to drive the signals so that they are precise and not messed up by the processor going off to do other things (Linux etc multi tasks of course by taking the CPU away from you to do other things!).
As for timings, you need to understand how the DMA works. Typically you set:

  • The base speed, i.e. 1/0 width based on a clock and...
  • One or more dividers so you might start with 10MHz, divide by 1000 and end up with a 10kHz clock.
    Often you can't get slow enough so you then scale your signal up so instead of sending a single 1010 you send
    11111111000000001111111100000000
    and run the clock (in this case) 8 times faster than you really want.
    So off to Google with you - both the Raspberry PI and the ESP8266 have some DMA code out there that you can start from. Figure out what it does and why, and then you can start tinkering with it. But you do need to understand it before you start otherwise you will never get it to work - I speak from experience!
@zuckschwerdt

This comment has been minimized.

Copy link
Collaborator

commented Jan 17, 2018

Things to look at for TX: CC1101 boards (RF100se) and HopeRF RFM69W boards. Those do the timing on-board and are connected by I2C/SPI. But you have to programm the timing and control the fifo buffers.

Repository owner deleted a comment from cityba Jan 30, 2018

Repository owner deleted a comment from cityba Jan 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.