Bianco
Posts: 55
Joined: Sun Jul 13, 2014 9:41 pm

Yet another RF 433 MHz topic

Sun Aug 10, 2014 1:38 pm

I've read my tutorials and done the wiring properly (using an LED in series with the second data pin on the receiver so show when it's getting something) and RFSniffer receive what I'm sending (using sudo ./codesend XXXXX) from the same RPi.

Image


But RFSniffer doesn't get anything when I'm trying to sniff my electric gate remote or my electric stores remote although the LED blinks (meaning they use 433 Mhz?).



I'm 100% new to this (RPi, RF and C) and not really comfortable with it. I'd really appreciate it if someone could give a complete newbie a hand to make some sense out of this.

rec9140
Posts: 33
Joined: Mon Sep 12, 2011 5:29 pm
Contact: Website

Re: Yet another RF 433 MHz topic

Sun Aug 10, 2014 10:05 pm

Bianco wrote:I've read my tutorials and done the wiring properly (using an LED in series with the second data pin on the receiver so show when it's getting something) and RFSniffer receive what I'm sending (using sudo ./codesend XXXXX) from the same RPi.
I would be interested in the tutorials you followed, I am looking at several and would like to look at a few more.

My goal is Oregon Scientific and other WX station 433.92Mhz devices.

Which receiver did you choose?
Bianco wrote:I
But RFSniffer doesn't get anything when I'm trying to sniff my electric gate remote or my electric stores remote although the LED blinks (meaning they use 433 Mhz?).
No, not necessarily.

This applies to the US ONLY. If NOT In the US, then you can just quit reading. I have no clue on authorizations outside the US.

Many garage door openers are at 315MHz in the US, along with some other frequencies for older ones.

If your testing with the devices in close proximity to the receiver... The receiver may be overloaded, and getting enough interference from a 315MHz device at 433.92 to cause the LED to light, but as it can't decode it is not valid data due to being off frequency.

Move the the device under test outside the area of the board, say 20-25 feet, and then retest.

If in the US you look up to see if the device is a 433.92 device by looking up the FCC ID number on the OET site.

http://transition.fcc.gov/oet/ea/fccid/

saltydog
Posts: 39
Joined: Mon Dec 24, 2012 10:40 am

Re: Yet another RF 433 MHz topic

Mon Aug 11, 2014 9:17 am

One way is to use piscope to manually read the pulses and then use the python send script (ir_tx_micros.py) in this link to transmit the pulses

Chris

Bianco
Posts: 55
Joined: Sun Jul 13, 2014 9:41 pm

Re: Yet another RF 433 MHz topic

Mon Aug 11, 2014 11:04 pm

rec9140 wrote:
Bianco wrote:I've read my tutorials and done the wiring properly (using an LED in series with the second data pin on the receiver so show when it's getting something) and RFSniffer receive what I'm sending (using sudo ./codesend XXXXX) from the same RPi.
I would be interested in the tutorials you followed, I am looking at several and would like to look at a few more.
I'll put some order in my links and come back to you.
Which receiver did you choose?
The CCC (Cheap Chinese Crap) almost everybody on a budget is using: http://www.electan.com/images/rf433k.jpg?language=en
Bianco wrote:I
But RFSniffer doesn't get anything when I'm trying to sniff my electric gate remote or my electric stores remote although the LED blinks (meaning they use 433 Mhz?).
No, not necessarily.

If your testing with the devices in close proximity to the receiver... The receiver may be overloaded, and getting enough interference from a 315MHz device at 433.92 to cause the LED to light, but as it can't decode it is not valid data due to being off frequency.

Move the the device under test outside the area of the board, say 20-25 feet, and then retest.
LED was flickering from a few meters away without an antenna, I'm failry confident it's 433.92 MHz.
Another door opener or my car key don't work at all.

saltydog wrote:One way is to use piscope to manually read the pulses
That's a great tip! I'm quite happy I don't have to hack my soundcard and use audacity.

But it seems to be freezing quite a lot. Is there some auto trigging (the triggers are deselected) or is it lagging (I d/l the hard float version)?
Is there a Piscope Guru on the forum? :mrgreen:
and then use the python send script (ir_tx_micros.py) in this link to transmit the pulses
I'll look it up once decoded.

rokasan
Posts: 2
Joined: Sat Nov 29, 2014 11:32 pm

Re: Yet another RF 433 MHz topic

Sat Nov 29, 2014 11:41 pm

Hi,

finally have you found the reason ? I have the same issue.

thanks for the feedback

Bianco
Posts: 55
Joined: Sun Jul 13, 2014 9:41 pm

Re: Yet another RF 433 MHz topic

Sun Nov 30, 2014 8:06 pm

Well, they were both using rolling codes so I didn't go any further since I was just trying to understand how RF works.

If I were you, I check the Pilight project to see the raw data. Some of the guys from their forum are even able to reverse engineer the rolling codes.

rokasan
Posts: 2
Joined: Sat Nov 29, 2014 11:32 pm

Re: Yet another RF 433 MHz topic

Sun Nov 30, 2014 10:28 pm

thanks Bianco, btw I'm sure I'm using (different kind of) non rolling code units, so the reasond should be something else.

Anyway drives me crazy.

What Raspberry model have you used for your tests ? I have B+ UK. I'm not sure it is important, just trying to check the differences compare the guides I have followed.

Bianco
Posts: 55
Joined: Sun Jul 13, 2014 9:41 pm

Re: Yet another RF 433 MHz topic

Mon Dec 01, 2014 2:30 pm

I was using a british B+ as well.

http://www.pilight.org/ should be able to display the raw code received from your module no matter what the protocol is. If not, you can try piscope (or any logic analyser) but it won't be as easy to use.

Unfortunately, I can't help you any further but you'll find specialists able to guide you if necessary :)

Return to “Automation, sensing and robotics”