phoenixdigital
Posts: 5
Joined: Thu Jan 08, 2015 10:57 am

433Mhz Reciever for existing devices

Fri Jan 16, 2015 3:12 am

I have set myself a task of working out how to receive signals from various 433MHz devices on the Raspberry Pi

So I have purchased a few of these
Image

and plan to sniff and decode signals from devices like these
  • Wireless weather stations - Image
    Wireless power meter - Image
    PIR Motion Sensors - Image
    Door Reed switches - Image
    Smoke alarms - Image
All of these devices supposedly run on 433Mhz so I should be able to listen in and hopefully decode them and put some sort of web interface and logging system on the pi to work with this. Links to the devices I bought at the end of this post.

Now I have been reading through many many different sites and come across a lot of people sending (from arduinos) and receiving (to Pi). The majority of posts are dealing with sending of 433Mhz signals to existing devices, but there are very few people sniffing for existing devices. References at the end as well.

The closest post I have found for receiving on the pi is this.
http://www.homautomation.org/2013/09/21 ... pberry-pi/

Now instead of wiring directly into the pi I have placed a voltage divider on the GPIO input to protect the input on the pi.
http://i.imgur.com/Q51lOqN.jpg

I compiled wiringPi and RFSniffer as in that blog post but get nothing out. I suspect it is because I am not using the associated transmitter. I am just sniffing the air for anything from the existing devices I have.

Images of my “circuit” and other related images
http://imgur.com/a/NnFQK

So I tweaked some python code I found (thanks Alex) to just watch this pin and see what was happening.
http://pastebin.com/giCYGgf4

The code waits for a GPIO event and then prints to the screen.
  • The current time
    the number of microseconds since the last event
    the direction of the event
    the GPIO port
The output is here from just listening
http://pastebin.com/MFSj30aj

To confirm there was nothing wrong with this port I tested it with a floating high 3.3V signal and it was fine.

First thing I can see is how can you have multiple “falling” detections in a row?

Is the python script not fast enough to detect?

So it looks like a bunch of noise at the moment and I am not sure where to go from here.

Does anyone have any suggestions?

The Next Steps
I have ordered one of these so I can do some sniffing from my PC
https://www.adafruit.com/product/1497

I have also ordered a BitPirate to test out the receiver a bit more on the PC too
https://www.adafruit.com/products/237

References I have been investigating

Sending from arduino receiving on pi
http://www.homautomation.org/2013/09/21 ... pberry-pi/

Using a Bus Pirate to test reciever
http://tinkerman.eldiariblau.net/decodi ... -switches/

Decoding weather station data
http://www.susa.net/wordpress/2012/08/r ... nd-rfm12b/

This guy is doing something close to what I want to do
http://jas-hacks.blogspot.co.uk/2012/06 ... panel.html

Another transmitter only (but I plan to build his sniffer when my 10M resistor arrives)
http://www.hoagieshouse.com/RaspberryPi ... CPlug.html

Arduino version only
http://www.wes.id.au/2013/07/decoding-a ... rc-switch/

Devices I am using
433Mhz Tx/Rx: http://www.ebay.com.au/itm/301365910052
Power monitor: http://www.wattsclever.net.au/shop/ener ... rgymonitor
Weather Station: http://www.ebay.com.au/itm/281320110249
PIR Sensor: http://www.ebay.com.au/itm/161368248083
Door Sensor: http://www.ebay.com.au/itm/161517810950
Smoke Alarm: http://www.ebay.com.au/itm/151274893620
Panic Button: http://www.ebay.com.au/itm/161022668346

phoenixdigital
Posts: 5
Joined: Thu Jan 08, 2015 10:57 am

Re: 433Mhz Reciever for existing devices

Fri Jan 16, 2015 10:20 am

An update on this

It appears that the Rx I was using was faulty. I swapped it out for one of the other 2 I bought and RFSniffer started working for
  • PIR motion sensors
    Panic Button
    Door Sensors
RF Sniffer displayed a unique number for each.

I saw nothing from the weather station or power monitor but I suspect that is due to a range or modulation issue. The range for the ones that did work is no greater than 5 meters even with an antenna attached.

I received my 1M resistors today as well and made the plug to plug into my soundcard input and listened to the data pin with audacity. Damn there is constant noise on the data line which would explain why that Python script was constantly triggering. It would be near impossible to isolate anything signal on that. Maybe the BitPirate might give better results.
http://i.imgur.com/Lc6KhjO.jpg

You can see there is something happening every 5 seconds or so and that could be my weather station or power monitor but alas RFSniffer ignores it.

So then I found this site
http://wiki.pilight.org/doku.php/receivers

and have ordered one of these which will hopefully increase the range to something useful like 30m through a few walls. The weather station is on the roof of a two story house.
http://www.ebay.com.au/itm/221412827876

Is it possible that the signal modulation is different between the two receivers I bought?

AM vs Superheterodyne

Is possible the weather station and power meter use some other form of modulation at 433MHz?

The current range on the ones I have now are too poor for anything useful. I have soldered a 27cm antenna and coiled it 17 times so that shouldn't be the issue.

Getting closer to my goal but any advice would be appreciated.
Last edited by phoenixdigital on Fri Jan 16, 2015 10:52 am, edited 1 time in total.

User avatar
joan
Posts: 14021
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: 433Mhz Reciever for existing devices

Fri Jan 16, 2015 10:32 am

My pigpio library is likely to give the most reliable results.

e.g. Virtual wire.

If the signal can be detected by piscope you can write code to receive/send the code.

Massi
Posts: 1691
Joined: Fri May 02, 2014 1:52 pm
Location: Italy

Re: 433Mhz Reciever for existing devices

Fri Jan 16, 2015 11:30 am

you can read quite a lot of topics in this forum regarding the same "project" (sniff air to receive 433 MHz)
Basically, do it in the "brute force way" with a Pi is going to be a bad idea, since you'll use all your pi power just to sniff air.
Second, your receiver (same as mine) is bad :)
Third: noise. You'll ALWAYS get a lot of noise with that receiver, for the internal AGC. That's why your python script will use all your cpu, because there will be always noise triggering gpio level

In my case (i was trying to decode signals from outdoor sensors of a weather station), i gave up since my pi has to do much more things than that.

phoenixdigital
Posts: 5
Joined: Thu Jan 08, 2015 10:57 am

Re: 433Mhz Reciever for existing devices

Sat Jan 17, 2015 6:50 am

joan wrote:My pigpio library is likely to give the most reliable results.

e.g. Virtual wire.

If the signal can be detected by piscope you can write code to receive/send the code.
Thanks for the tip looks like a great little app. Could come in handy when the new receiver arrives. Will definitely run it on the pi and view on my fedora laptop which appears to be possible based on the youtube demo of yours.
pattagghiu wrote:you can read quite a lot of topics in this forum regarding the same "project" (sniff air to receive 433 MHz)
Basically, do it in the "brute force way" with a Pi is going to be a bad idea, since you'll use all your pi power just to sniff air.
Second, your receiver (same as mine) is bad :)
Third: noise. You'll ALWAYS get a lot of noise with that receiver, for the internal AGC. That's why your python script will use all your cpu, because there will be always noise triggering gpio level

In my case (i was trying to decode signals from outdoor sensors of a weather station), i gave up since my pi has to do much more things than that.
Couldn't find the other project you were referring to.

Hmmm yes I think you are right there RFSniffer (compiled c) appears to chew up all the CPU (95%). Not ideal at all.

Maybe I should look at incorporating an Arduino for sniffing. I was trying to avoid another tech and wanted an all Pi solution.

Will see how the other tuner goes and then maybe look at linking it with an Arduino or is there something better suited for 433?

User avatar
joan
Posts: 14021
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: 433Mhz Reciever for existing devices

Sat Jan 17, 2015 8:01 am

I'm not convinced wireless static is an insurmountable problem on the Pi. I'm not sure how hard people have tried to filter out static in software.

The pigpio VirtualWire is a Python implementation but is still comparable to (possibly better than) RFSniffer. A C version could handle filtering more easily.

Massi
Posts: 1691
Joined: Fri May 02, 2014 1:52 pm
Location: Italy

Re: 433Mhz Reciever for existing devices

Sat Jan 17, 2015 8:59 am

phoenixdigital wrote: maybe look at linking it with an Arduino or is there something better suited for 433?
I was looking for a moteino, that basically is "linking it with an arduino" :)
I'm not convinced wireless static is an insurmountable problem on the Pi. I'm not sure how hard people have tried to filter out static in software.
For sure you would do it better :) but basically "filter out static in software" i think equals "search for a known pattern", so giving some calculation to every level change. Can't think about changing my script much..
btw, as we were saying in the other topic, even tour TX/RX class is consuming lot of cpu, so that's not far from "cpu intensive"
A C version could handle filtering more easily.
That's quite sure. But i don't think in the "5%" class..

phoenixdigital
Posts: 5
Joined: Thu Jan 08, 2015 10:57 am

Re: 433Mhz Reciever for existing devices

Sun Jan 18, 2015 11:53 pm

pattagghiu wrote:I was looking for a moteino, that basically is "linking it with an arduino" :)
Thanks for the tip I might look into one of these
https://lowpowerlab.com/shop/index.php?_route_=RFM69HW

It appears that all the heavy lifting is handled by these transceivers and this might handle most of the gruntwork. This can then leave the Pi to other duties and it can just check for new data every second or so. If my limited understanding of how these work is right.

The only other issue is if I am sniffing two different devices which use different styles of transmission I might need two receivers?

Massi
Posts: 1691
Joined: Fri May 02, 2014 1:52 pm
Location: Italy

Re: 433Mhz Reciever for existing devices

Mon Jan 19, 2015 9:26 am

phoenixdigital wrote:
pattagghiu wrote:It appears that all the heavy lifting is handled by these transceivers and this might handle most of the gruntwork. This can then leave the Pi to other duties and it can just check for new data every second or so. If my limited understanding of how these work is right.
Yes, this is the idea :)
The only other issue is if I am sniffing two different devices which use different styles of transmission I might need two receivers?
And yes, this is the big question :)
In another topic (here: http://www.raspberrypi.org/forums/viewt ... 37&t=96491 ) i was wondering the exact same thing :)

breno
Posts: 14
Joined: Fri Jan 16, 2015 6:31 pm
Location: Brazil (not my fault)

Re: 433Mhz Reciever for existing devices

Fri Jan 23, 2015 9:07 pm

On the Joan's vw.py, what adaptations should be done ? I found this great code today but I don't know how to adapt it.

I noticed that I have to change "Specify Pi, rx gip and baud". My receiver data pin is connected to the pin 12 and power to the 17. I'm keeping the BPS at 2000.

Then I tried to run the code and it asked if I specified the right pi host/port in the enviroment variable PIGPIO_ADDR/PIGPIO_PORT

I am using Raspberry Pi B+ running Raspbian.

Thanks in advance for any help.

luberth
Posts: 6
Joined: Sat Nov 24, 2018 10:44 am

Re: 433Mhz Reciever for existing devices

Thu Nov 29, 2018 9:41 am

hello

Thank you for all your 433 related links
will take a good look
i am also playing with it

http://luberth.com/Bangert_30_1619GJ_An ... _Pi_433Mhz
greet luberth

btidey
Posts: 1614
Joined: Sun Feb 17, 2013 6:51 pm

Re: 433Mhz Reciever for existing devices

Fri Nov 30, 2018 8:58 am

There are 2 basic types of receivers; super-regenerative and super-heterodyne. The first sort is like the first type you posted. They are very cheap but also tend to have poor range. The superhet types have better range and are more stable. They are not significantly more expensive. Search for RXB6 for typical units.

No signal noise output is common to most types and is a consequence of the gain being turned up to the max by the agc when no real signal is present. The noise pulses tend to be significantly shorter in width than real transmitted signals so a simple software filter that ignores these can help a lot in reducing cpu load on the Pi. This is particularly the case if using pigpio as the underlying bit handling mechanism. For example, most 433MHz protocols use data pulses in the range 500 - 2000 uSec. Ignoring pulses below 150uSec in width will dramatically reduce unnecessary handling of noise.

I have 433MHz listeners using about 1.5% cpu background load (Pi3) and they run fine on Pi Zero.

One nice mechanism is to use the custom.cext facility in pigpio to add custom handlers into the processing of the bit changes

Alex Konshin
Posts: 41
Joined: Sun Jan 29, 2017 10:02 pm
Location: Boston MA, USA

Re: 433Mhz Reciever for existing devices

Fri Nov 30, 2018 5:35 pm

Look at my project for decoding temperature sensor signals with RF receivers.
https://github.com/alex-konshin/f007th-rpi
This project can use my yet another project that is Linux driver that can effectively filter most of noise:
https://github.com/alex-konshin/gpio-ts

There is also my thread in this forum about these projects:
viewtopic.php?t=173023

Len-Tikular
Posts: 24
Joined: Tue Dec 24, 2013 5:54 pm

Re: 433Mhz Reciever for existing devices

Sun Dec 23, 2018 10:19 pm

This may well be the forum I'm seeking.

I have a weather staion in my garden (See picture)
I inherited it with the house purchase.
I do not have the reciever all you see is all i got.

Is it possible to build a reciever with the Pi to pick up the signals from my mast.
The cups spin freely and the vane moves freely
I havnt a clue what frequency it is on (if any)

Thanks
weatherstation.jpg
weatherstation.jpg (81.27 KiB) Viewed 6101 times

btidey
Posts: 1614
Joined: Sun Feb 17, 2013 6:51 pm

Re: 433Mhz Reciever for existing devices

Mon Dec 24, 2018 9:32 am

It is common to use 433MHz to transmit data from stations like this, but no guarantees.

You can check this out by using a low cost usb dvb-t tv stick as a spectrum analyser. See https://www.rtl-sdr.com/

Establishing the frequency of transmission is just the first step. You then have to work out how data is sent and what its content is.

If it is 433MHz then a simple 433MHz receiver (preferably superhet) can be used with a Pi to capture the raw data.

The control electronics for the station are probably in the rectangular box half way on the mast. If you can get inside this and establish the make / model of the unit that might help identify what type of messaging is being used.

pfletch101
Posts: 449
Joined: Sat Feb 24, 2018 4:09 am

Re: 433Mhz Reciever for existing devices

Mon Dec 24, 2018 3:06 pm

Len-Tikular wrote:
Sun Dec 23, 2018 10:19 pm
This may well be the forum I'm seeking.

I have a weather staion in my garden (See picture)
I inherited it with the house purchase.
I do not have the reciever all you see is all i got.

Is it possible to build a reciever with the Pi to pick up the signals from my mast.
The cups spin freely and the vane moves freely
I havnt a clue what frequency it is on (if any)

Thanksweatherstation.jpg
If you don't want to risk taking one of the components of the weather station apart to identify it (and a google search for WS images doesn't help, which it may), try posting the picture in an appropriate subforum on http://www.wxforum.net/. One of the experts there will almost certainly be able to identify it and may be able to give you more information about it.

Len-Tikular
Posts: 24
Joined: Tue Dec 24, 2013 5:54 pm

Re: 433Mhz Reciever for existing devices

Mon Dec 24, 2018 5:08 pm

Yep,
I can confirm it's a 433Mhz 'MISOL' weather station
Maybe someone has already built a receiver for this one ?

George
Here is what was under the tall round cover.
TX2.jpg
TX2.jpg (95.97 KiB) Viewed 5927 times
TX1.jpg
TX1.jpg (96.54 KiB) Viewed 5927 times

PhatFil
Posts: 1246
Joined: Thu Apr 13, 2017 3:55 pm
Location: Oxford UK

Re: 433Mhz Reciever for existing devices

Mon Dec 24, 2018 5:26 pm

there is a arduino lib for 'hearing the fine offset protocol used by the weather stations and the stc1000+ brewfridge crack, ive used this lib with and arduino
https://github.com/lucsmall/WH2-Weather ... or-Arduino
and
https://github.com/lucsmall/BetterWH2

its been a few years since I was here but iirc i had better results with the V1 lib..

a cheap arduino sat with the RF receiver connected to your pi over a serial connection might be the simplest solution.

For other basic fixed code encoding protocols such as PT2260, PT2262, PT2264, EV1527, etc. used for simple alarms,button controllers, etc.
I use a sonoff rf bridge flashed with tasmota firmware, this £8 device sits and echos all RF signals it can decode as Mqtt topic/payload messages, which makes it a simple task to integrate any compatible device into your automation system.

https://www.itead.cc/wiki/Sonoff_RF_Bridge_433
https://github.com/arendst/Sonoff-Tasmota/wiki

TheNetStriker
Posts: 3
Joined: Tue Jan 08, 2019 9:54 am

Re: 433Mhz Reciever for existing devices

Tue Jan 08, 2019 10:19 am

I'am trying to capture the alarm signal of an König SAS-SA200 smoke detector using a 433 MHz receiver. I've tried receiving the signal using the Arduino RC-Switch library and using the rpi-rf python library, but the signal does not seem to be supported yet. So I've tried to capture the signal using the SimpleRcScanner: https://github.com/sui77/SimpleRcScanner

Here is the output data of one of the scans:

Code: Select all

1424,776,2760,772,1448,752,1420,776,1420,776,2760,772,2768,776,1416,772,2768,776,2764,772,1424,776,1420,772,1360,780,20020,8096,928,776,2760,784,2756,772,2772,772,1416,776,1420,780,1416,776,2764,776,1420,776,1420,776,1424,772,1416,776,1424,772,2764,772,1424,776,1420,776,1420,776,2764,772,2764,772,1428,768,2768,772,2760,776,1424,776,1420,772,1360,776,20092,8088,932,776,2760,776,2760,776,2768,776,1416,772,1424,776,1420,772,2764,776,1424,768,1424,776,1428,772,1420,768,1424,776,2760,776,1420,776,1420,776,1420,776,2764,772,2768,776,1412,780,2764,776,2756,776,1424,776,1416,776,1364,776,20024,8092,932,776,2760,776,2760,776,2768,772,1420,776,1420,776,1420,772,2764,776,1420,776,1420,772,1424,776,1420,772,1424,776,2760,776,1420,776,1420,780,1416,776,2760,776,2768,776,1416,776,2768,772,2760,772,1424,776,1420,772,1360,776,20028,8088,940,772,2760,776,2764,772,2764,776,1420,772,1424,776,1424,772,2760,780,1420,776,1416,776,1424,772,1420,772,1424,776,2764,772,1424,776,1420,772,1420,776,2764,776,2760,776,1424,772,2764,776,2760,776,1424,776,1420,772,1356,776,20036,8084,932,776,2760,776,2768,772,2764,776,1416,776,1420,776,1424,772,2764,776,1420,776,1416,776,1424,780,1412,776,1420,780,2756,776,1420,776,1424,776,1416,776,2768,772,2760,780,1420,772,2760,780,2760,776,1424,776,1416,776,1356,776,20040,8080,936,772,2764,772,2772,768,2764,780,1416,776,1420,772,1424,772,2760,780,1420,776,1420,772,1420,784,1416,772,1420,780,2760,772,1424,776,1424,772,1420,768,2772,772,2760,784,1416,772,2764,776,2760,776,1420,780,1420,772,1360,776,20028,8088,936,776,2760,772,2764,776,2764,776,1420,776,1416,776,1420,784,2756,776,1420,776,1420,772,1420,780,1420,776,1416,776,2764,776,1420,776,1424,772,1420,776,2760,776,2760,776,1428,768,2764,776,2764,772,1420,780,1420,776,1356,772,20036,8084,936,776,2760,772,2768,776,2756,780,1420,772,1424,772,1424,780,2756,776,1424,776,1416,776,1420,776,1420,772,1420,776,2768,772,1420,772,1428,776,1416,776,2760,776,2764,776,1420,776,2760,780,2756,776,1420,776,1424,776,1356,776,20032,8084,936,772,2764,768,2768,776,2764,772,1424,776,1420,772,1424,780,2756,776,1420,776,1416,776,1428,772,1424,772,1420,772,2764,776,1420,772,1424,776,1420,772,2768,776,2760,772,1424,776,2760,776,2764,772,1420,776,1420,780,1356,776,20036,8080,936,776,2760,
I've analyzed the scanner output on this website: https://test.sui.li/oszi/

I've also put the picture of one of the transmissions as an attachment to this post. My guess is that this device uses a completely different kind of sync signal as the remotes. Also the pulse length seems to vary between a 0 and a 1 transmission. I already tried different protocol settings, but nothing worked so far. Are the current libraries able to handle such a signal? And if not, is there maybe a fork of those libraries that can handle this signal?
Attachments
Signal.png
Signal.png (3.13 KiB) Viewed 4553 times

btidey
Posts: 1614
Joined: Sun Feb 17, 2013 6:51 pm

Re: 433Mhz Reciever for existing devices

Wed Jan 09, 2019 9:26 am

The message is repeated twice in your sequence and is consistent each time.

It looks to me like the basic structure is

Leading sync consisting or 8ms on, 1msec off

The following pulses are either 760uSec, 1420 uSec, or 2760uSec. There can be some timing distortion reading pulses so lets call these 700uSec, 1400 sec and 2800uSec as they are likely to be related to each other.

One interpretation would be this is binary data where
1 is represented as a 700uSec on followed by 1400 uSec off
0 is represented by a 700uSec on followed by a 2800uSec off

obviously the choice of 1 or 0 is arbitrary

Assuming this the message would be 24 bits long (with a final pulse of 700uSec to terminate
000111011111011100100111 or 0x1DF727

There is an inter message gap of 20 msec

You maybe able to find a library to handle this or is configurable in some way, but once you know the structure it is pretty easy to roll your own anyway.

Your next hurdle is how to interpret the meaning of the data. As it s a smoke detector the amount of data is likely to be small so I would guess that most of this is made up of an address or id identifying the unit with then a small portion Indicating the state of the alarm.

TheNetStriker
Posts: 3
Joined: Tue Jan 08, 2019 9:54 am

Re: 433Mhz Reciever for existing devices

Wed Jan 09, 2019 3:02 pm

btidey wrote:
Wed Jan 09, 2019 9:26 am
The message is repeated twice in your sequence and is consistent each time.

It looks to me like the basic structure is

Leading sync consisting or 8ms on, 1msec off

The following pulses are either 760uSec, 1420 uSec, or 2760uSec. There can be some timing distortion reading pulses so lets call these 700uSec, 1400 sec and 2800uSec as they are likely to be related to each other.

One interpretation would be this is binary data where
1 is represented as a 700uSec on followed by 1400 uSec off
0 is represented by a 700uSec on followed by a 2800uSec off

obviously the choice of 1 or 0 is arbitrary

Assuming this the message would be 24 bits long (with a final pulse of 700uSec to terminate
000111011111011100100111 or 0x1DF727

There is an inter message gap of 20 msec

You maybe able to find a library to handle this or is configurable in some way, but once you know the structure it is pretty easy to roll your own anyway.

Your next hurdle is how to interpret the meaning of the data. As it s a smoke detector the amount of data is likely to be small so I would guess that most of this is made up of an address or id identifying the unit with then a small portion Indicating the state of the alarm.
Thanks for the quick help. I also continued trying to get the rc-switch library to work for me. I simply copied the cpp and h file to my project and renamed the class so I can try different changes. The first thing I found out is that the nSeparationLimit of 4300 is to low for this signal. With the setting this low the receiveProtocol method is never executed on this signal. When I set this to 10'000 the receiveProtocol method is executed and tries to decode the signal.

After that I tried several protocol settings. The last one I tried was this one:

{ 780, { 1, 10 }, { 1, 3 }, { 1, 2 }, true }

With this setting I did receive a consistent number from the library. The only strange thing is that the number is negative, but I will try some more settings to try to get this right.

Edit: I had the best results with those settings:

{ 700, { 1, 11 }, { 1, 4 }, { 1, 2 }, true }

The problem with the negative number was cause because I converted the unsigned long to int. Now I receive the number 1963815 constantly. I also changed the start bit to 3 on the following line:

const unsigned int firstDataTiming = (pro.invertedSignal) ? (3) : (1);

I think this works already very good with those changes.

btidey
Posts: 1614
Joined: Sun Feb 17, 2013 6:51 pm

Re: 433Mhz Reciever for existing devices

Wed Jan 09, 2019 9:44 pm

Yes. That sounds promising.

1963815 is the decimal equivalent of 0x1DF727 which is what I though t the message was.

I am not familiar with how that config works but I guess it is definitions are base clock period and then how header 0 and 1 are made up. So 1,2 (700/1400 for a zero and 700/2800 for a 1 makes sense.

If you have more than one detector or can trigger an alarm then changes to the message received will help interpret what the bits mean. It is normally better to use hex for this as the changes are probably mapped onto particular bits.

TheNetStriker
Posts: 3
Joined: Tue Jan 08, 2019 9:54 am

Re: 433Mhz Reciever for existing devices

Thu Jan 10, 2019 3:45 pm

btidey wrote:
Wed Jan 09, 2019 9:44 pm
Yes. That sounds promising.

1963815 is the decimal equivalent of 0x1DF727 which is what I though t the message was.

I am not familiar with how that config works but I guess it is definitions are base clock period and then how header 0 and 1 are made up. So 1,2 (700/1400 for a zero and 700/2800 for a 1 makes sense.

If you have more than one detector or can trigger an alarm then changes to the message received will help interpret what the bits mean. It is normally better to use hex for this as the changes are probably mapped onto particular bits.
The format of the protocols is the following:
/* Format for protocol definitions:
* {pulselength, Sync bit, "0" bit, "1" bit}
*
* pulselength: pulse length in microseconds, e.g. 350
* Sync bit: {1, 31} means 1 high pulse and 31 low pulses
* (perceived as a 31*pulselength long pulse, total length of sync bit is
* 32*pulselength microseconds), i.e:
* _
* | |_______________________________ (don't count the vertical bars)
* "0" bit: waveform for a data bit of value "0", {1, 3} means 1 high pulse
* and 3 low pulses, total length (1+3)*pulselength, i.e:
* _
* | |___
* "1" bit: waveform for a data bit of value "1", e.g. {3,1}:
* ___
* | |_
*
* These are combined to form Tri-State bits when sending or receiving codes.
*/

And the boolean at the end is for inverted signals.

I've already tested another smoke sensor that I paired with the "master" smoke sensor before and this sensor now sends the exact same signal as the master sensor. So I don't really have to find out what the signal bits mean. I just have to listen for that one signal and send an e-mail or make an automated phone call.

By the way, I also tried to run the same library and the python "rpi-rf" library on a Rasberry Pi 3, but receiving signals seams to be much worse compared to the Arduino. (Using the same receiver hardware) The rc-switch code only detects the signal about every 30 seconds instead of every second and the python library just detects all kinds of different values. I guess the Raspberry is just not made to analyze signals in realtime. Also both libraries utilize one complete cpu core while running.

btidey
Posts: 1614
Joined: Sun Feb 17, 2013 6:51 pm

Re: 433Mhz Reciever for existing devices

Fri Jan 11, 2019 8:39 am

TheNetStriker wrote:
Thu Jan 10, 2019 3:45 pm

By the way, I also tried to run the same library and the python "rpi-rf" library on a Rasberry Pi 3, but receiving signals seams to be much worse compared to the Arduino. (Using the same receiver hardware) The rc-switch code only detects the signal about every 30 seconds instead of every second and the python library just detects all kinds of different values. I guess the Raspberry is just not made to analyze signals in realtime. Also both libraries utilize one complete cpu core while running.
The Raspberry running raw python to do the low level timing detecting this type of real time signal will struggle to be reliable due to the nature of the OS which can switch to a different process in the middle of decoding. Also as you have noted if the timing is done in the foreground then it will burn up 1 core.

However, it is possible to do reliable detection with low cpu utilisation on the Raspberry by using the excellent pigpio service to sample the raw data. As this uses dma to get the gpio data, it gets accurate timing plus it is then possible to do decoding of the pigpio data with low cpu utilisation.

The pigpio site http://abyz.me.uk/rpi/pigpio/ contains some examples of decoding although they would need to be adapted for your protocol.

My Lightwaverf 433MHz decoder which uses pigpio running on a Pi3 uses less than 3% cpu and runs with multiple other unrelated programs. https://github.com/roberttidey/LightwaveRF

Return to “Automation, sensing and robotics”