RF433 noise or interference generated by openmqttgateway

[ctripodi]

Hello, I am using this excellent project like a bridge of IR + RF433 + Bluetooth Since I started to use the bridge, I could see some interference at home with other RF 433 devices (for example in my car to unlock the door using the key, in my wife car the same or for open my garage using the native RF key) After some analisis, I removed the RF433 TX module from the bridge and the noise problem has disappeared. Looks like the TX RF433 is sending a signal "noise" all the time. I am using a 433Mhz RF Transmitter module MX-FS-03V Could be possible to enable some PIN to activate a transistor and then enable the RF433 TX just to send "transmit" the codes? OpenMQTTGateway version used V0.3.1

Thank you

[savage872]

I have experienced something similar when I used the 433 on OMG. I have remote key fobs that are paired with sonoff 4ch pro for my lights. When the OMG was turned on and I pressed the key it didn't do anything. I had to press it several times to work once. When I powered down OMG it worked fine. I don't know what the solution is I'm afraid. The modules that i used were 433MHz RF Receiver SRX882 and Transmitter STX882.

[1technophile]

Depending on the module type used we could either power it directly by a pin either by an intermediary transistor. I could add this has an option to OMG

[ctripodi]

Thanks @1technophile , this could be great. When do you think that this option could be added to OMG?

[AlmightyFrog]

I have had a similar issue using the FS1000A. Back then I used version 0.5 and as far as I remember Noise was starting about when first signal was sent out.

I just remember that I fixed the issue by reassigning the rf transmitter to another pin on my WEMOS D1 mini.

Updated yesterday to latest version and found there kinda seems same issue exists. Changing in config_RF.h following assignment did help me #define RF_EMITTER_PIN 4 // RX on nodemcu if it doesn't work with 3, try with 4 (D2) // put 5 with rf bridge direct mod but I did not verify it like with version 0.5 by SDR.

I guess at my board this has something to to with the RX-Pin itself maybe influenced by USB-Serial Adapter or whatever.

[ggggh]

Same issue here running it on a nodemcu (ESP-12). Noise is very noticeable and only happens after a first transmit, and goes away with a reboot. It's so noisy it affects unrelated RF devices 30 meters away.

[1technophile]

Unfortunately I'm not reproducing this issue (Emitter connected to RX on a NodeMCU with an FS1000A).

Is your USB port still connected to the computer or not?

[AlmightyFrog]

I did use the USB-Port for power and had that connected to a ordinary smarphone powersupply. Not sure, if that is causing an issue. I did never try it with direct power from bench supply or such.

[ggggh]

Apologies for the confusion. I seem to have changed the nodemcu at some point and totally forgot about it. I'm actually using an ESP32, with the Transmitter Data pin on IO12. It's an XD-FST, and the receiver is an RXB6 ESP32 is powered through USB port to a phone charger, not to computer.

[1technophile]

Thanks for the details. I will try to reproduce with a phone charger

[1technophile]

Hello,

I tried with v0.9.3beta + an SDR radio to check the signal persistence FS1000A emitter or stx882 a phone charger, a battery and a hub

But I don't reproduce the issue, the signal stop after 2 seconds.

[ggggh]

I must say I'm starting to doubt it being triggered only by transmitting. I started experiencing interference today although certain hadn't transmitted anything. I'll set up some test with SDR recording to check actual noise - at the moment it's just based on symptoms (my garage door won't open every now and again). Fixed by just rebooting OMG or unplugging the transmitter, 30 meters away from the garage door.

[1technophile]

Maybe a track to follow is the use of another version of RC-switch from the one referenced in OMG repo. Indeed if you use 2.6.2 from here https://github.com/sui77/rc-switch You are missing this modification , maybe this is the reason of having noise after the sending of an inverted protocol.