Receiving codes not ok. #5

AlbertWeterings · 2018-02-25T13:18:51Z

Not only sending RF codes doen't go very well at the moment as reported by @franky29. I have flashed multiple versions found at https://github.com/rhx/RF-Bridge-EFM8BB1 and https://github.com/Portisch/RF-Bridge-EFM8BB1 With both I was still able to receive correct codes from a EV1527 remote but receiving codes from a PT2264 remote completely stopped working.

A other downside effect is that somehow out of nothing my unit seemed to receive over 400 codes in less than 15 min where it only received about 100 codes in the past two months.

Portisch · 2018-02-26T12:28:06Z

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.

AlbertWeterings · 2018-02-27T05:51:55Z

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.

Portisch · 2018-03-07T15:54:58Z

@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...

AlbertWeterings · 2018-03-07T16:12:27Z

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.

mcspr · 2018-03-07T16:45:11Z

@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.

Portisch · 2018-03-08T07:12:01Z

@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.

AlbertWeterings · 2018-03-08T07:33:42Z

@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.

Portisch · 2018-03-08T09:13:31Z

@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.

AlbertWeterings · 2018-03-08T09:25:06Z

@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.

Portisch · 2018-03-08T10:03:47Z

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

AlbertWeterings · 2018-03-08T10:14:51Z

@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.

Portisch · 2018-03-08T11:16:13Z

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.

AlbertWeterings · 2018-03-08T11:37:48Z

@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.

mcspr · 2018-03-08T11:53:58Z

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

AlbertWeterings · 2018-03-08T12:01:04Z

@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

AlbertWeterings · 2018-03-08T12:29:18Z

@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

Portisch · 2018-03-08T15:20:03Z

Lets go to transmit issue #2

AlbertWeterings mentioned this issue Mar 6, 2018

Getting x: 0x43 in return #6

Closed

Portisch closed this as completed Mar 8, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Receiving codes not ok. #5

Receiving codes not ok. #5

AlbertWeterings commented Feb 25, 2018

Portisch commented Feb 26, 2018

AlbertWeterings commented Feb 27, 2018 •

edited

Loading

Portisch commented Mar 7, 2018

AlbertWeterings commented Mar 7, 2018

mcspr commented Mar 7, 2018 •

edited

Loading

Portisch commented Mar 8, 2018

AlbertWeterings commented Mar 8, 2018

Portisch commented Mar 8, 2018

AlbertWeterings commented Mar 8, 2018 •

edited

Loading

Portisch commented Mar 8, 2018

AlbertWeterings commented Mar 8, 2018 •

edited

Loading

Portisch commented Mar 8, 2018 •

edited

Loading

AlbertWeterings commented Mar 8, 2018

mcspr commented Mar 8, 2018 •

edited

Loading

AlbertWeterings commented Mar 8, 2018

AlbertWeterings commented Mar 8, 2018 •

edited

Loading

Portisch commented Mar 8, 2018

Receiving codes not ok. #5

Receiving codes not ok. #5

Comments

AlbertWeterings commented Feb 25, 2018

Portisch commented Feb 26, 2018

AlbertWeterings commented Feb 27, 2018 • edited Loading

Portisch commented Mar 7, 2018

AlbertWeterings commented Mar 7, 2018

mcspr commented Mar 7, 2018 • edited Loading

Portisch commented Mar 8, 2018

AlbertWeterings commented Mar 8, 2018

Portisch commented Mar 8, 2018

AlbertWeterings commented Mar 8, 2018 • edited Loading

Portisch commented Mar 8, 2018

AlbertWeterings commented Mar 8, 2018 • edited Loading

Portisch commented Mar 8, 2018 • edited Loading

AlbertWeterings commented Mar 8, 2018

mcspr commented Mar 8, 2018 • edited Loading

AlbertWeterings commented Mar 8, 2018

AlbertWeterings commented Mar 8, 2018 • edited Loading

Portisch commented Mar 8, 2018

AlbertWeterings commented Feb 27, 2018 •

edited

Loading

mcspr commented Mar 7, 2018 •

edited

Loading

AlbertWeterings commented Mar 8, 2018 •

edited

Loading

AlbertWeterings commented Mar 8, 2018 •

edited

Loading

Portisch commented Mar 8, 2018 •

edited

Loading

mcspr commented Mar 8, 2018 •

edited

Loading

AlbertWeterings commented Mar 8, 2018 •

edited

Loading