User avatar
pi-anazazi
Posts: 778
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Noise with 433MHz receiver [Opened again]

Fri Dec 16, 2016 10:19 am

Just to be sure, by GPIO17 you mean pin 11 and GPIO27 pin 13?
Kind regards

anazazi

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver [Opened again]

Fri Dec 16, 2016 10:22 am

Yes!
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver

Sun Dec 18, 2016 4:40 pm

I did some further "research" and I am starting very slowly to understand what is going on here. Maybe I will put this in another thread because in my head and even on this forum so many things were/are wrongly stated.
andies wrote:I have measured the voltage of the 433-receiver. If no signal is present the receiver (measured to the ground) has stable 1,2V, approx. The needle is not moving.
Yes, the needle is not moving. But if I am putting a capacitor in between the voltage should drop to zero if it is DC. It doesn't. Hence, there is "noise", it is (HF) AC. This cannot precisely be measured by the voltmeter I have.
andies wrote:At the moment when I connect Data from the receiver with GPIO 17 or GPIO27 the voltage between GND and Data drops to zero (0.0V), regardless whether I push a button or make a cup of coffee (voltage meter impedance is 20kOhm)?!

First, it is not DC but AC what I am "measuring" (the voltmeter can handle only 50-100Hz and here there must be much more "noise"). Second, the low voltage is a result of the high impedance of the GPIO, see viewtopic.php?f=44&t=164147&p=1083759#p1083759

So two of the mysteries disappear. More to follow.
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

User avatar
pi-anazazi
Posts: 778
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Noise with 433MHz receiver [Opened again]

Sun Dec 18, 2016 5:11 pm

Do you have an extra-trashy power supply? Just asking... :-)
Kind regards

anazazi

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver [Opened again]

Sun Dec 18, 2016 5:21 pm

I know, once I was searching several months (!) for a strange error until I found out that my 1A couldn't handle the current :evil:

This time I have a 2,5A supply.
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver [Solved]

Tue Dec 20, 2016 4:19 pm

I think I finally solved the problem. It is very embarrassing: "Somehow" parts of wiringPi got deleted. I cannot reconstruct what happened but it seems that I had two installations on my Pi. One manually installed version and another via apt-get. Then, the apt-get version was removed. In the end nothing worked.

I just realized that something was wrong with wiringPi, I installed it again with apt-get and now I get my signal. I cannot decode it but this is another story.

I am also trying to understand the signal my garage opener is sending I at least managed to record the signal the following way. I am running "sudo pigpiod" and then

Code: Select all

sudo pilight-raw -L >> signal.txt

Then I am pressing the button and then I am interrupting the recoding using CTRL-C. The file signal.txt is huge (around 120kB). BUT it is nicely written, for example:

Code: Select all

433gpio:  7201 -#: 1
433gpio:  813 275 614 130 28 6589 -#: 6
433gpio:  134 64 59 11 829 218 723 757 224 232 330 <200 or more numbers!> ... 14752 -#: 49
433gpio:  813 275 614 130 28 6589 -#: 6
Notice the following: The third line is much longer than all other lines. This seems to be recorded noise where the other lines seem to come from the signal. That way I was able to distinguish noise from signal! And indeed, I had about ten lines inside and two very, very long lines. I deleted the long lines and I believe that I recorded the raw signal from my garage opener that way. I will further analyze it and hopefully find out what that means.
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver [Solved]

Tue Dec 20, 2016 9:37 pm

I just made a nice histogram with the numbers a simple

Code: Select all

pilight-raw -L
command produces over four seconds. Interestingly, the numbers around 20 appear very often. I was not aware that any particular device (weather station, garage opener...) was sending anything during those four seconds.
Noise.png
Noise.png (35.68 KiB) Viewed 4535 times
One bin corresponds to signals between 0-20, 21-40, 41-60 etc. The y-axis contains the probability.

My son asked me to use this smiley: :P
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver [Solved]

Sun Dec 25, 2016 9:17 am

A final remark. My ultimate goal was to analyze a garage opener from Came. My problem was that I used RFSniffer, debug and similar software - but they will output only signals they understand (=where the protocol is known). But Came's protocol isn't understood yet.

In this thread (https://forum.pilight.org/Thread-Came-d ... atic-gates) I described how I was finally able to understand/debug/re-engineer the signal. It is not tested yet, I will do that if the sender arrives (from Shenzen 8-) ). Maybe my approach is helpful for others as well.
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver [Solved]

Fri Dec 30, 2016 4:53 am

I did some further research (mainly because I am still unable to re-engineer my door opener) and I am about to come to the conclusion that with this kind of cheap receiver a proper analysis of a 433MHz signal is impossible. Let me explain why.

I started with a simple arduino program that produces a nice quadratic wave of, for example, 20kHz. Here is the code:

Code: Select all

void setup() {
  pinMode(2, OUTPUT);
}

void loop() {
    for (long i=0; i<100; i++){
      PORTD &= ~_BV(PD2);          //set to LOW, hardwired to make it faster, see http://www.instructables.com/id/Arduino-is-Slow-and-how-to-fix-it/?ALLSTEPS
      delayMicroseconds(50);      
      PORTD |= _BV(PD2);           
      delayMicroseconds(50);      
    }
}

I checked this code by connecting the PIN D2 of my arduino to an oscilloscope. I could see a clear 20kHz-wave, the picture is below.

[EDIT] I am struggling with the pictures. Sometimes I can include them into the post, sometimes I cannot. Depending on what kind of hardware you are browsing the forum they are upside down or they are displayed correctly. I have no clue why and when. Therefore, I am simply attaching all pictures at the end of the post. Here original.JPG is supposed to be.[/EDIT]
original.JPG
original.JPG (43.2 KiB) Viewed 4362 times
I later changed the "delayMicroseconds(50)"-line from the original value of 50μs down to 3μs and up to 700μs and always got the same result. So producing "nice" frequencies in the range of 333kHz to 1,43kHz is no problem.

The next step was to interrupt the direct connection

Code: Select all

arduino ==> oscilloscope
and place the 433 MHz transmitter and receiver in between

Code: Select all

arduino ==> 433MHz transmitter || air || 433MHz receiver ==> oscilloscope
Ideally, the oscilloscope should show the same frequency. If not, it is a problem of either the receiver or the sender. Again I changed the frequency/microsec and now I got a completely different picture. Below are the results of 5μs and 25μs delay (corresponding to 200kHz and 40kHz):

Since I cannot add more than three files I will continue in the next post.
Attachments
25muesec.JPG
25muesec.JPG (59.06 KiB) Viewed 4360 times
5muesec.JPG
5muesec.JPG (63.2 KiB) Viewed 4362 times
Last edited by andies on Fri Dec 30, 2016 7:29 am, edited 10 times in total.
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver [Solved]

Fri Dec 30, 2016 5:00 am

Using higher delays resulted in the following pictures (the name of the file corresponds to the μ-seconds in the above code)
100mueseec.JPG
100mueseec.JPG (57.16 KiB) Viewed 4416 times
200muesec.JPG
200muesec.JPG (63.04 KiB) Viewed 4416 times
500muesec.JPG
500muesec.JPG (59.07 KiB) Viewed 4416 times
(I cannot add the 700muesec picture - it is similar to the 500 one but even more "distorted").

[EDIT]As in the above post I have no clue why all pictures are upside down on a desktop computer (they aren't on my iPhone). Notice that HIGH is shorter then LOW, maybe your picture is wrongly displayed! The exact relation is not that important, the bad thing is the asymmetry between both.[/EDIT]

What is clearly visible is the following:
  • For very small delays (lower than 50 μs) the communication does not work. That seems to be a problem of the sender, it cannot handle that amount of traffic ("traffic rate too high").
  • For small delays (above 50μs and below 150μs) the transported signal is more or less visible.
  • For larger delays (above 150μs) the signal gets more and more distorted. It is hardly recognizable at a delay of 500μs and above.
  • Notice also the increasing asymmetry between the length of the LOW and the HIGH signal. With 10kHz the HIGH signal is a little bit shorter than LOW; but with 2kHz "HIGH" (which is not constantly high anymore, therefore the "") is much shorter than LOW.

    The quotient of HIGHT-time per (HIGH-time+LOW-time) is in some cases denoted as "duty cycle". I have put in a clear duty cycle of 50% and received something that is much less. The voltage issue (=not constant voltage for one particular HIGH or one particular LOW) could probably be solved using an interrupt with CHANGE, because the massive voltage drop or voltage increase is easily identified. But the change in the duty cycle cannot be solved with software, this is a hardware bug. And I have no idea how to overcome this.
This is very bad news. I am certain that my door opener uses a microsec of 200 and above. But then the important signal is in a range where the receiver (and I suspect the receiver to be the culprit) is not able to give me a clear signal. The wave is far from being quadratic. If this wave is now analyzed I will not get a proper number as time difference between HIGH and LOW but a completely wrong distance will be reported. I would be able to analyze that signal if my "low-pass filter" (=the kind of software tool that tries to get rid of the noise you see in these pictures; unfortunately it does not filter low pass waves - but this is a different story) would know the precise mathematical form of these distorted waves and take this into account. In my experiment I am lucky that I do know what the correct signal and wave form is. But with my door opener I do not enjoy this luxury. I am stuck.

If the opener would be working in the higher frequency range (between 6kHz and 20kHz) this receiver would do its job. But outside that range the task of re-engineering with this tool seems to be a mission impossible. I have to get another receiver.
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver [Solved (sort of)]

Fri Jan 06, 2017 10:16 pm

I looked at my tools again. I used two different transmitters (Superregeneration or XY-MV-5, for example http://www.avc-shop.de/433Mhz-Sender-Em ... T-XY-MK-5V and superheterodyn, for example http://www.ebay.de/itm/like/40115812458 ... noapp=true - both are mentioned in many posts) and the same receiver (RXB 12 - until now I have only this one). I made several histograms which I will show in a moment but with both senders the pictures were more or less the same. Hence, I conclude that the problems I described have to do with the receiver, not the transmitter.

I used an arduino to send particular signals to the sender. These signals were all like

Code: Select all

A-B-A-B-...
meaning I had A microsec LOW, followed by B microsec HIGH, followed by A microsec LOW etc. pp. (Code is in the post above.)

Then, I placed the receiver next to the sender and recorded the signal using pilight-raw. Pilight-raw reports numbers. I then plotted a histogram of those numbers using Mathematica. The ideal result would be: I am sending 50-50 and the histogram shows me a peak at 50 and no other numbers. This in fact happens with 50-50 but this seems to be the only case. I already mentioned that it will not turn out that way if one deviates from 50-50 but my question was: What exactly does the receiver show? How "wrong" is the result? Now I will present three pictures of 13 recordings.

The first picture shows four different A-B-patterns that have in common that A+B=600 (so a single signal or "pulse train" lasts 600µs). Read the pictures from top-left to bottom-right. I started with 200µs-400µs, then 250-350, then 300-300 and the last was 400-200.
600.jpg
600.jpg (55 KiB) Viewed 4250 times
One can observe two things: 1) More or less in all cases one signal is around 150-200 and the other 400-450, regardless what exactly I am sending. 2) The longer the LOW-period the more concise are those two peaks visible. With 400-200 you more or less exactly see 150 and 450, this is less pronounced in the 200-400 case. In this last case there is also one small peak around 25 and another around 120.

The same happens if I look at A+B=900µs. Here I have choosen 300-600, 400-500, 600-300 and 700-200. Again the same picture: The shorter the LOW-period the steeper the histogram:
900.jpg
900.jpg (62.07 KiB) Viewed 4250 times
The last picture shows what the receivers communicates (again from left top to bottom right) to me if I am sending 100-100, 200-200, 300-300, 500-500 and 700-700. These are symmetric signals in the sense that LOW-time=HIGH-time or A=B, the difference being the length of the entire signal.
100-700.jpg
100-700.jpg (60.81 KiB) Viewed 4250 times
I had to downsize the picture to 64kB so it is not very easy to read. But the story is interesting. Regardless what I am sending if I am above 200µs the receivers is always telling me the number 200. The other peak is such that it adds up with the 200µs to the sum of A+B. So if, for example, I am sending 500-500 the entire signal has a length of 1000µs and I am receiving the 200µs plus a peak at 800µs (because 1000-200=800).

The first and probably most important message of this post is: You cannot rely on any reported number that is above 50. The second message: I do not see how we can easily construct a "low-pass filter" given this observation (see, for example, this wiki entry: https://wiki.pilight.org/doku.php/low-pass_filter). Such a low-pass filter should be able to reengineer from 200-800 that I have been sending 500-500?! And the third message: At least there seems to be some regularity in the receiver's bug when reporting some signal?
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver [Solved (sort of)]

Fri Jan 13, 2017 5:41 pm

I got a new receiver a few days ago, both from the guy who maintains pilight (see https://www.pilight.org/shop/#sender). The difference is stricking. Even if I am simply recording the signal from the garage opener I do not get any noise at all as this "screen shot" from the raw data shows:

Code: Select all

433gpio:  333 685 317 663 338 668 335 328 676 673 312 695 308 678 325 355 654 682 306 696 307 677 326 339 641 15180 -#: 26
433gpio:  345 660 342 667 318 712 291 342 661 671 331 669 334 674 313 351 657 677 327 682 305 723 281 356 640 14872 -#: 26
433gpio:  354 656 345 666 319 680 326 360 642 667 334 681 322 669 317 371 638 673 330 675 313 697 305 356 640 15158 -#: 26
433gpio:  354 657 347 656 342 661 341 323 663 667 335 671 351 670 314 333 659 673 330 675 329 674 329 331 649 14870 -#: 26
433gpio:  358 651 349 654 349 655 345 320 668 668 333 675 328 675 328 332 661 675 329 673 329 671 333 340 640 15164 -#: 26
433gpio:  357 655 345 662 323 675 326 339 665 670 332 669 333 670 316 350 659 673 332 670 316 691 312 356 641 14872 -#: 26
433gpio:  355 654 348 656 329 683 318 341 665 661 339 671 331 671 315 358 652 670 333 673 330 676 312 356 640 15158 -#: 26
433gpio:  368 636 365 638 432 570 346 325 662 665 337 666 337 673 330 338 654 673 331 672 330 674 335 329 646 14870 -#: 26
433gpio:  359 652 349 656 345 656 345 324 663 664 338 673 329 670 333 327 666 672 331 670 335 670 332 329 651 15168 -#: 26
433gpio:  344 666 334 653 354 650 345 324 685 660 320 681 321 684 319 333 660 684 318 680 324 674 329 340 641 14892 -#: 26
433gpio:  337 666 334 653 348 657 345 319 683 695 291 680 323 666 337 345 647 697 306 672 332 670 332 333 649 15160 -#: 26
433gpio:  360 649 352 657 344 659 342 324 715 613 336 668 335 670 333 333 659 675 328 675 328 674 329 340 642 14871 -#: 26
433gpio:  360 645 353 659 342 660 341 320 667 668 334 667 335 669 334 331 663 674 328 677 328 670 332 332 648 15171 -#: 26
433gpio:  341 667 334 653 348 656 345 317 686 665 321 683 319 670 332 354 639 687 316 670 333 670 333 336 645 14891 -#: 26
433gpio:  338 668 333 655 346 657 347 316 684 669 316 690 313 671 332 350 658 673 314 688 315 673 332 332 648 15169 -#: 26
433gpio:  361 654 348 652 332 675 327 333 668 663 340 664 338 669 317 346 664 668 334 673 315 689 314 348 648 14870 -#: 26
433gpio:  359 664 334 654 332 675 327 337 666 664 338 667 335 670 383 282 662 668 334 672 332 669 320 350 643 15167 -#: 26
433gpio:  338 675 326 655 346 658 344 422 582 664 329 683 318 805 230 332 665 659 302 671 331 670 333 334 647 14885 -#: 26
433gpio:  360 652 332 656 346 658 341 324 685 684 298 685 319 665 335 347 667 671 312 688 315 669 339 344 631 15170 -#: 26
433gpio:  357 660 341 653 332 678 324 335 779 553 338 666 335 673 315 346 662 676 327 680 308 689 313 350 648 14865 -#: 26

So the solution with too much noise is: Get a better receiver. No low-pass filter, no capacitor, no software. Just spend 10$ instead of 1$.
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver

Sat Jan 21, 2017 4:56 pm

Joan: I read that I can decode as well as transmit codes to a 433-device. What I do not understand is the following. If I am decoding a code I get the information of low signal, high signal and intersignal length (three numbers) as well as the actual keycode. But the Readme says that it is enough to transmit with

Code: Select all

./_433D -t5 8246184 # Transmit code on GPIO 5.
How is this possible if the three other numbers are missing?

PS Maybe I am in the wrong thread. Can you point me to the correct one?
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

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

Re: Noise with 433MHz receiver [Completely solved]

Sat Jan 21, 2017 5:33 pm

Most devices seem to use pulse lengths of 300µs and 900µs, so those values are the defaults used to send the codes.

The receive side doesn't care what the pulse lengths are (as long as they are significantly different). Just in case the pulse lengths are non-standard the receive side keeps track of the lengths and prints them out on request. They can then be used to configure the send side if needed.

andies
Posts: 144
Joined: Mon Nov 11, 2013 8:12 pm
Location: Berlin

Re: Noise with 433MHz receiver [Completely solved]

Sat Jan 21, 2017 5:50 pm

joan wrote:They can then be used to configure the send side if needed.
How is this done? I did not find any argument for the command line.
raspberry B, Noir camera, Mac Book Air, iPhone, Bezzera

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

Re: Noise with 433MHz receiver [Completely solved]

Sat Jan 21, 2017 5:54 pm

andies wrote:
joan wrote:They can then be used to configure the send side if needed.
How is this done? I did not find any argument for the command line.

Code: Select all

$ ./_433D -?
./_433D: invalid option -- '?'

Usage: _433D [OPTION] ...
   -r value, rx gpio, 0-31,                  default None
   -t value, tx gpio, 0-31,                  default None
   -d value, monitoring duration in seconds, default 60

   -b value, TX bits, 6-64,                  default 24
   -x value, TX repeats, 1-50,               default 6
   -0 value, TX t0, 100-1000,                default 300
   -1 value, TX t1, 300-3000,                default 900
   -g value, TX gap, 5000-13000,             default 9000

   -l value, RX glitch, 0-500,               default 150
   -m value, RX min bits, 6-64,              default 8
   -n value, RX max bits, 6-64,              default 32
   -f      , RX show full code details,      default off

   -h string, host name,                     default NULL
   -p value, socket port, 1024-32000,        default 8888
EXAMPLE
_433D -r20
   Listen for received codes on GPIO 20.

_433D -t21 2345 8789001
   Transmit codes 2345 and 8789001 on GPIO 21.

_433D -r20 -t21 8675 878 9041
   Transmit codes 8675, 878, and 9041 on GPIO 21.
   Then listen for received codes on GPIO 20.
The -0 and -1 options.

Return to “Troubleshooting”