303mhz even though its not officially supported?

[MACscr]

Like many others, Ive struggled to find a DIY option for listening to my ceiling fan remotes at 303mhz and also transmitting. Now for testing I have solved listening with my SDR, but needed to be able to transmit as well. Looking at the following project (https://github.com/owenb321/hampton-bay-fan-mqtt), I ended up buying a CC1101 (this exact one https://www.amazon.com/gp/product/B00U5TO37W/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1) and while it said it only supported down to 315mhz, I thought I would give it a try because the project author said it worked for him.

Unfortunately I am not having any luck at 303mhz. 315mhz and 433mhz of course work, but I already had those covered with other solutions. ive tried tweaking the RXBW and setting the MODULATION to 2 (for OOK), but still no luck. I can receive just fine at 303mhz with my SDR using the following settings:

rtl_433 -f 303.869mhz -R 0 -X 'n=master_fan,m=OOK_PWM,s=384,l=700,r=1000,bits=13,invert,countonly,unique'

Any suggestions? Is it possible with the CC1101 and this library? I swear I picked up some random 303mhz traffic already on the serial, but ive only seen it once so far. I do live in an area with a lot of different RF traffic.

[LSatan]

Hi, first interesting project. For your questions. cc1101 officially supports this frequency. The module you ordered is for 433mhz. This means that you can easily operate at 300 - 348 MHz and 387 - 464 MHz. The author appears to be using rc-switch. Therefore I would suggest you use the examples for rc-switch contained in my library. https://github.com/LSatan/SmartRC-CC1101-Driver-Lib/tree/master/examples/Rc-Switch%20examples%20cc1101 see if you are using ReceiveDemo_Advanced_cc1101 or ReceiveDemo_Simple_cc1101 received something. don't forget to set your frequency in the examples ELECHOUSE_cc1101.setMHZ(303.631); . and use the wiring as shown. If you do not receive your remote control, there are other options, but you should try this first. then give me a feedback. I wish you success. Regards

[LSatan]

https://github.com/owenb321/hampton-bay-fan-mqtt/issues/2#issuecomment-665626456

[MACscr]

So i did the calibration with my SDR for 315mhz, which gave me the following calibration:

ELECHOUSE_cc1101.setClb(1,13,14);

I then tried the ReceiveDemo_Simple_cc1101 with a the following custom settings:

ELECHOUSE_cc1101.setMHZ(303.869);
ELECHOUSE_cc1101.setClb(1,13,14);

(I used 303.869 because thats what my SDR picks up when i use the remote.)

No serial activity. If i switched it to 433.92, i picked up the traffic just fine.

[LSatan]

OK no broken legs. try this example: https://github.com/LSatan/SmartRC-CC1101-Driver-Lib/tree/master/examples/Rc-Switch%20examples%20cc1101/ProtocolAnalyzeDemo_cc1101

it needs this modified branch of rc-switch: https://github.com/Martin-Laclaustra/rc-switch/tree/protocollessreceiver

if it still doesn't work then we should start recording raw data.

addendum: insert the calibration into the setup here as well

[MACscr]

That worked, got the following with two different button presses:

Received 254 / 12bit Protocol: 6
data bits of pulse train duration: 13360
proposed protocol: { 371, { 35, 1 }, { 1, 2 }, { 2, 1 }, true }
====
first level down
12985 386 
355 753 370 741 384 735 369 744 756 360 746 367 750 360 753 370 
748 362 761 347 745 388 362 734 
====
Received 247 / 12bit Protocol: 6
data bits of pulse train duration: 13382
proposed protocol: { 372, { 35, 1 }, { 1, 2 }, { 2, 1 }, true }
====
first level down
12961 388 
383 708 421 695 407 708 421 697 764 358 775 343 775 341 758 348 
395 721 758 381 745 367 728 385 
====

[LSatan]

ok you can use this methode to transmit:

include

include

int pin; // int for Transmit pin.

RCSwitch mySwitch = RCSwitch();

void setup() { Serial.begin(9600);

ifdef ESP32

pin = 2; // for esp32! Transmit on GPIO pin 2.

elif ESP8266

pin = 5; // for esp8266! Transmit on pin 5 = D1

else

pin = 6; // for Arduino! Transmit on pin 6.

endif

ELECHOUSE_cc1101.Init(); ELECHOUSE_cc1101.setMHZ(303.869); ELECHOUSE_cc1101.setClb(1,13,14);

// Transmitter on mySwitch.enableTransmit(pin);

// cc1101 set Transmit on ELECHOUSE_cc1101.SetTx();

// Optional set protocol (default is 1, will work for most outlets) mySwitch.setProtocol({ 372, { 35, 1 }, { 1, 2 }, { 2, 1 }, true });

// Optional set pulse length. // mySwitch.setPulseLength(320);

// Optional set number of transmission repetitions. // mySwitch.setRepeatTransmit(15);

}

void loop() {

mySwitch.send(254, 12); delay(3000);
mySwitch.send(247, 12); delay(3000);
} //corrected at 18:40 gmt+1

[MACscr]

what about receiving and what did we figure out the issue was? Why do we have to approach this remote differently? BTW, thank you so much for your time, I really appreciate it.

[LSatan]

So firstly. I can not see in the library which model he owns from hampton_bay_fan. my guess he owns a different model than you. in his bibliotehk I see that he works with 21bit protocol. hers has 12bit. that can not go. As a second. The protocols that rc-switch does not know will not be shown to you either. A look at the cpp file of rc-switch with protocol number 6 = {450, {23, 1}, {1, 2}, {2, 1}, true}, // protocol 6 (HT6P20B)

Your protocol however = {372, {35, 1}, {1, 2}, {2, 1}, true}.

because of these differences, it cannot work. You can now use the methods mentioned above to send and receive. or you modify rc-switch and use your values ​​in protocol 6.

[MACscr]

Again, thank you so much for your time. At least now i know the transceiver will work for my purpose and I just have software changes to make. Thanks again!

[LSatan]

No problem. if you have any questions i am available.

[MACscr]

Do you have paypal so I can at least buy you a beer?

[LSatan]

thank you. very attentive. ;)) https://www.paypal.me/LittleSatan666

[LSatan]

thank you for the donation. Incidentally, it is my first since this bibliotehk existed. At this point I would like to mention that I do all the support and work on the library in my free time. I am glad that there are still people who appreciate this and I am very grateful to you for it. Donations are voluntary but I have had some expenses for module microcontrollers since the library existed. To either make them compatible or to eliminate errors. for me personally there was no use. That's why I would like to thank you again at this point.

[MACscr]

Well unfortunately while that information seems consistent for incoming, if i try to transmit with your example, it fails. It also looks completely different on my SDR when analyzing the transmission with RTL_433 where it shows 13 bits of data.

Low Button:

root@raspberrypi:~# rtl_433 -f 303.869mhz -R 0 -a 4
rtl_433 version 20.02-86-gd362397 branch master at 202007062107 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/root/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Disabling all device decoders.
Registered 0 out of 156 device decoding protocols [ ]
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
[R82XX] PLL not locked!
Sample rate set to 250000 S/s.
Tuner gain set to Auto.
Tuned to 303.869MHz.
Allocating 15 zero-copy buffers

*** signal_start = 791781455, signal_end = 791844988, signal_len = 63533, pulses_found = 91
Iteration 1. t: 126    min: 80 (49)    max: 173 (42)    delta 136
Iteration 2. t: 126    min: 80 (49)    max: 173 (42)    delta 0
Pulse coding: Short pulse length 80 - Long pulse length 173

Short distance: 105, long distance: 197, packet distance: 3259

p_limit: 126
bitbuffer:: Number of rows: 7
[00] {13} 7c 40     : 01111100 01000
[01] {13} 7c 40     : 01111100 01000
[02] {13} 7c 40     : 01111100 01000
[03] {13} 7c 40     : 01111100 01000
[04] {13} 7c 40     : 01111100 01000
[05] {13} 7c 40     : 01111100 01000
[06] {13} 7c 40     : 01111100 01000

Medium Button

*** signal_start = 791781455, signal_end = 791844988, signal_len = 63533, pulses_found = 91
Iteration 1. t: 126    min: 80 (49)    max: 173 (42)    delta 136
Iteration 2. t: 126    min: 80 (49)    max: 173 (42)    delta 0
Pulse coding: Short pulse length 80 - Long pulse length 173

Short distance: 105, long distance: 197, packet distance: 3259

p_limit: 126
bitbuffer:: Number of rows: 7
[00] {13} 7c 40     : 01111100 01000
[01] {13} 7c 40     : 01111100 01000
[02] {13} 7c 40     : 01111100 01000
[03] {13} 7c 40     : 01111100 01000
[04] {13} 7c 40     : 01111100 01000
[05] {13} 7c 40     : 01111100 01000
[06] {13} 7c 40     : 01111100 01000

And this is what my attempt using your example for transmitting:

*** signal_start = 2797434, signal_end = 3120941, signal_len = 323507, pulses_found = 1
Distance coding: Pulse length 303506

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 303506
bitbuffer:: Number of rows: 0

I also did an advanced receive demo with the CC1101 and got the following for low when testing from the remote: 21:05:42.207 -> Decimal: 119 (12Bit) Binary: 000001110111 Tri-State: 00F1F1 PulseLength: 372 microseconds Protocol: 6 21:05:42.319 -> Raw data: 13010,371,423,674,389,736,370,745,375,739,384,729,762,374,741,365,766,358,370,709,774,343,748,359,781,

Kind of lost on what to do next. Its great that i can read the data, but i already could do that with the SDR, so really need a way to be able to transmit without having to simple record audio files for each button and transmitting that way, which is super dirty and not something i want to do.

[LSatan]

you only get a pulse of 1. something is wrong. did you also connect gdo0 with d1? I'm pretty sure we can get it to work.

[MACscr]

How else would it be transmitting on the correct frequency if it wasn’t?

• Mark

On Jul 29, 2020, at 9:58 PM, LSatan notifications@github.com wrote:

 you only get a pulse of 1. something is wrong. did you also connect gdo0 with d1? I'm pretty sure we can get it to work.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

[LSatan]

that the cc1101 transmits on the frequency only says that you have spi correctly wired. it is also strange that you see a signal even when nothing is broadcast.

I transmit your prot: repeat = 10

after transmit without setrx:

if it is similar to you then it is ok. i just want to exclude possible causes in advance. I am very surprised that he only recognizes a long pulse. that's not the case with me.

[MACscr]

Well I feel like an idiot. gdo0 and gdo2 were swapped. Definitely getting more output output with rtl_433 now. Wife is asleep in the bedroom, so cant test if it works yet with the actual fan (i used a different decimal value for testing), but definitely getting more info on the SDR and buffer values now. Really appreciate the detailed help. I could have saved tons of time by just getting a couple new 433 receivers, but i love a challenge and wanted to figure this out (plus two less fans to have to reinstall, lol). Will let you know more tomorrow for sure. Thanks!

[LSatan]

no problem. I just used a second cc1101 as a receiver. The result:

Received 123 / 12bit Protocol: 6 data bits of pulse train duration: 13638 proposed protocol: { 380, { 34, 1 }, { 1, 2 }, { 2, 1 }, true }

first level down 13102 412 379 750 396 747 386 735 401 772 369 744 789 359 758 370 770 401 739 384 378 771 745 374 739 382

[LSatan]

the problem is gdo0 can receive and send. gdo2 can only receive.

[LSatan]

Hi, could you test it already?

[MACscr]

It works! Sorry for taking so long to respond. Sick child unfortunately.

So glad to get this fan figured out! Even got it working with two different fans now. Thanks so much!

[NorthernMan54]

Just to add some colour on the same issue. I was trying the same use case out, and was using the OpenMQTTGateway firmware as a base and had the same challenge. After trying a couple of things, I found that the version bundled with OpenMQTTGateway of your library needed to be updated to the most recent version then it worked okay.

From: smartrc-cc1101-driver-lib = SmartRC-CC1101-Driver-Lib@2.5.2

To: smartrc-cc1101-driver-lib = SmartRC-CC1101-Driver-Lib@2.3.5

[Tomasinjo]

@NorthernMan54 Can you please share JSON payload of MQTT request that you send to OpenMQTTGateway?

I have Faro ceiling fan that works on 433Mhz and uses the same protocol and 12 bits of length. I tried sending the following to endpoint MQTTto433: {"value": 111, "protocol": 8, "length": 12} -> same as read by OMG when I press button on remote {"value": 111, "protocol": 6, "length": 12} -> tried protocol 6 as proposed by LSatan's script.

None of those work, I will probably have to update the library as suggested, but I first want to be sure that my payload is correct.

Example level 3 fan speed for future visitors:

Received 111 / 12bit Protocol: 6
data bits of pulse train duration: 11956
proposed protocol: { 332, { 35, 1 }, { 1, 2 }, { 2, 1 }, true }
====
first level down
11734 292 
380 606 406 603 376 600 400 600 400 601 724 269 743 269 398 603 
728 248 745 268 724 269 751 245 
====

[NorthernMan54]

This is a home assistant discovery message I inject into my setup for configuration of my ceiling fan

{
    "avty_t": "~LWT",
    "name": "Test Fan 1",
    "uniq_id": "3C71BF9E0770_F1_1",
    "payload_high_speed": "{\"value\": 1119,\"protocol\": 6,\"length\": 12,\"delay\": 437,\"mhz\": 303.732}",
    "payload_medium_speed": "{\"value\": 1135,\"protocol\": 6,\"length\": 12,\"delay\": 437,\"mhz\": 303.732}",
    "payload_low_speed": "{\"value\": 1143,\"protocol\": 6,\"length\": 12,\"delay\": 437,\"mhz\": 303.732}",
    "pl_off": "{\"value\": 1149,\"protocol\": 6,\"length\": 12,\"delay\": 437,\"mhz\": 303.732}",
    "pl_avail": "online",
    "pl_not_avail": "offline",
    "speeds": [
        "off",
        "low",
        "medium",
        "high"
    ],
    "cmd_t": "~commands/MQTTto433",
    "device": {
        "name": "cc1101-9e0770",
        "model": "[\"BME280\",\"BH1750\",\"RF\",\"Pilight\",\"rtl_433\"]",
        "manufacturer": "OMG_community",
        "sw_version": "esp32dev_rtl_433",
        "identifiers": [
            "3C71BF9E0770-1"
        ]
    },
    "~": "home/cc1101-bbbbbb/"
}