Receiving codes not ok. about rf-bridge-efm8bb1 HOT 17 CLOSED

I do not own a PT2260 remote control. I will need the exact timing of the remote, SYNC bit, '1' and '0' bit.
For every bit the high and low time.
The "original" protocol got just implemented by datasheet.

from rf-bridge-efm8bb1.

The firmware has one issue more, it receives codes not send "NOISE" I receive with this firmware over 200K codes in 12 hours.

For PT2264 I have these timings.
tlow - min 460 - max 480 - avrg 469 us
thigh - min 1390 - max 1410 - avrg 1400 us
code synchronization time - min 14380 - max 14490 - avrg 14428 us

Maybe having a look at the RCSwitch library https://github.com/sui77/rc-switch.git helps you implement timings for other remotes to. The library supports the following remotes.

• SC5262 / SC5272
• HX2262 / HX2272
• PT2262 / PT2272
• EV1527 / RT1527 / FP1527 / HS1527
• Intertechno outlets
• HT6P20X

I hope this helps you let me know when you have a update and I will test it.

from rf-bridge-efm8bb1.

@AlbertWeterings
I am right now a litle bit confused about the sync time. Does the 14428µs mean high or low?
I gues low time...

Right now the source is checking the PT2260 remotes in a range from 9000-11000µs.
This will be the first problem.

The second is maybe this line:
#define PT2260 {PT2260_IDENTIFIER, 0, 10000, 0, 1080, 360, 75, 25, 24}
SYNC_HIGH = 10000
SYNC_LOW = 0

And this sync check:

			if (PROTOCOL_DATA[used_protocol].SYNC_HIGH > 0)
			{
				if (
					(period_pos > (PROTOCOL_DATA[used_protocol].SYNC_HIGH - SYNC_TOLERANCE_0xA1)) &&
					(period_pos < (PROTOCOL_DATA[used_protocol].SYNC_HIGH + SYNC_TOLERANCE_0xA1)) &&
					(period_neg > (PROTOCOL_DATA[used_protocol].SYNC_LOW - SYNC_TOLERANCE_0xA1)) &&
					(period_neg < (PROTOCOL_DATA[used_protocol].SYNC_LOW + SYNC_TOLERANCE_0xA1))
				)
				{
					ret = used_protocol;
					break;
				}
			}
			// only SYNC low should be checked
			else
			{
				if (
					(period_neg > (PROTOCOL_DATA[used_protocol].SYNC_LOW - SYNC_TOLERANCE_0xA1)) &&
					(period_neg < (PROTOCOL_DATA[used_protocol].SYNC_LOW + SYNC_TOLERANCE_0xA1))
				)
				{
					ret = used_protocol;
					break;
				}
			}

The SYNC_LOW == 0 so SYNC_LOW - SYNC_TOLERANCE_0xA1 (1000µs) will produce 0xFC18

Try this short fix in RF_Protocols.h:

#define PT2260				{PT2260_IDENTIFIER, 0, 0, 15000, 1080, 360, 75, 25, 24}

This will disable the check on the positive sync and have a SYNC_LOW range from 14000-16000µs.

As I said before I don't own a remote with the PT2260 chip so I can't test it...

from rf-bridge-efm8bb1.

Thank you for searching a sollution. Can you compile this into a HEX than I will flash it right away and test if it works. I'm not able to build the HEX myself at the moment.

from rf-bridge-efm8bb1.

@Portisch I have couple of devices that came with Itead's RF Bridge bundle - PIR, door one and remote. They are with 1/3 (25/75 as written in proto definitions here) split for bit pulses.

PIR (unmarked, maybe 2260) observed during the day has LOW sync time of 12470..12600µS
Reed sensor (EV1527) - 13440..14100
Remote (EV1527) - 8790..8900
And some old remote I had lying around with SCT2260 - 13460..13500

I am only in the process of tweaking values, but would it make sense to cover all of possible times? Or maybe use different tolerance value, with sync low value at 12500 and ~3000 sync tolerance for PT2260 only.

Also, reading rc-switch sources and wiki, the pdf also mentions this - there is a single pulse before the LOW part in sync (1/31 split). I've just ordered some rf receivers, nothing to check with yet besides the bridge.

from rf-bridge-efm8bb1.

@AlbertWeterings Please try the new file: 16e8156
I just changed the tolerance and switched SYNC_HIGH to SYNC_LOW.

@mcspr Maybe this will be good test to first check on a SYNC_LOW >5000 and <20000µs.
And then compare the last SYNC_HIGH to 1/8 bit width:
http://www.princeton.com.tw/Portals/0/Product/PT2260_4.pdf

Like if the SYNC_LOW is 14400µs the SYNC_HIGH should be than ~464µs.

from rf-bridge-efm8bb1.

@Portisch Sorry it still doesn't receive codes from PT2264. please note the values I have given are the values as they appear in the bridge with original EFM8 firmware. I'm also still receiving "noise" if I set the bridge in learning mode within 5 sec I receive random codes. Will try to figure out timing later today by measuring them on a oscilloscope.

from rf-bridge-efm8bb1.

@AlbertWeterings I have done a new commit e097667.
Was my mistake... I simulate right now with an AVR and an 433 transmitter your signal and it get decoded by the EFM8.
Now I will take a look to change the SYNC detection to be able to detect sync signals like from 6000-18000µs.

from rf-bridge-efm8bb1.

@Portisch it is now decoding PT2264 perfect, but it doesn't decode EV1527 anymore. It now also stopped receiving noise

b.t.w. Today I have the setup in front of my at my desk so if you want me to experiment just ask.

from rf-bridge-efm8bb1.

Now it should work: 345af76
I changed the detection of PT226x remotes.

A test with this simulated remotes where succesfull:

AA A4 43 DA 01 D6 06 40 AA AA AA 55

TSYNC: 17370
TBIT0: 470
TBIT1: 1600

AA A4 1A 04 00 D2 02 8A AA AA AA 55

TSYNC: 6660
TBIT0: 210
TBIT1: 650

from rf-bridge-efm8bb1.

@Portisch I can confirm it is now decoding both PT2264 and EV1527.
It started to pick up noise again. Below some codes received that I did not send maybe you can check somehow if it is really noise and filter them out.
1AC200780550000000
1A5400500096000000
1AA4001E0096010100
1AD6000A0140480040
1A7200DC0582000200
1A2C003C0276100109
18EC002801FE000801
18C400320136020000

Maybe @mcspr can test this also on his Sonoff sensors now.

from rf-bridge-efm8bb1.

I added an extra duty cycle check on each received bit, may this filter the noise: 3f2a756

Before it just have recognized a bit 0 if it wasn't a bit 1.
Now it check if is a possible bit 0 or bit 1.

from rf-bridge-efm8bb1.

@Portisch just loaded the code I will now monitor if it is still receiving noise.

As I have time today I will also have a look at the transmitting issue reported.

from rf-bridge-efm8bb1.

@Portisch Yeah, duty cycle check did it. I am not seeing anything besides radios explicitly activated, just like original firmware.

from rf-bridge-efm8bb1.

@Portisch I don't know if this needs to be checked. If you take it out I will try if it still works. For now I can confirm the Sonoff bridge is not sending anything, not with and not without raw support.
I'm updating soon with logging in between ESP and EFM8

from rf-bridge-efm8bb1.

@Portisch : Still no noise on the receiver that's great !!!

Communication between ESP and EFM8 - Nothing is transmitted. Transmitter is connected to P0.0 PIN2 of the EFM8 according to schematic.

Raw support on.
sending previouse learned code "383601D6056E45D503" from ESPURNA webinterface
[TO EFM8] Received 0x0D
[TO EFM8] Received 0x0A
[TO EFM8] Received 0xAA
[TO EFM8] Received 0xA5
[TO EFM8] Received 0x38
[TO EFM8] Received 0x2C
[TO EFM8] Received 0x01
[TO EFM8] Received 0xCC
[TO EFM8] Received 0x05
[TO EFM8] Received 0x78
[TO EFM8] Received 0x45
[TO EFM8] Received 0xD5
[TO EFM8] Received 0x0C
[TO EFM8] Received 0x55

[FROM EFM8] Received 0xAA
[FROM EFM8] Received 0xA0
[FROM EFM8] Received 0x55

Raw support off.
sending previouse learned code "383601D6056E45D503" from ESPURNA webinterface
[TO EFM8] Received 0x0A
[TO EFM8] Received 0x0D
[TO EFM8] Received 0x0A
[TO EFM8] Received 0xAA
[TO EFM8] Received 0xA5
[TO EFM8] Received 0x38
[TO EFM8] Received 0x2C
[TO EFM8] Received 0x01
[TO EFM8] Received 0xCC
[TO EFM8] Received 0x05
[TO EFM8] Received 0x78
[TO EFM8] Received 0x45
[TO EFM8] Received 0xD5
[TO EFM8] Received 0x0C
[TO EFM8] Received 0x55

[FROM EFM8] Received 0xAA
[FROM EFM8] Received 0xA0
[FROM EFM8] Received 0x55

from rf-bridge-efm8bb1.

Lets go to transmit issue #2

from rf-bridge-efm8bb1.