Receive OK, but sending does not work with espurna

[franki29]

Hello, i could manage to load the prebuild hex image to my sonoff rfbridge.
Now i tried to learn a code from my remote and it is working.
But i could not send any learnd command.

I am using pilight with my raspberry pi for sniffering and my bridge does not send out any code.

Any help what i have to do to get it work?

[Portisch]

I don't know the status of the espurna firmware if every commands are supported.

[franki29]

Hi, can you tell us how you are using the code? I tested it also with Tasmota Software, but same problem.
Looks like the original command does not work? What are you using to send the code?
Thanks for helping

[Portisch]

I do all the tests with a COM terminal program like HTerm.

[franki29]

To what port do you connect and with what baud rate?

[Portisch]

To the RX/TX header next to the EFM8BB1. And put the switch to the OFF position. This will cancel the RS232 connection to the ESP ISP.
Baud: 19200, 8N1

[franki29]

Hi , i tried with your way with HTerm, but still nothing was send. I tried also the sample code on your page.
My code would be AAA52724014003D405151155 and it should be OK.
The only code that make some reaction is the learning command.
And of course receiving is no problem.
Anny suggestion what i am doing wrong ?

[Portisch]

AA Sync
A5 Comand
2724 T-Sync
0140 T-Low
03D4 T-high
051511 Data
55 Sync end

Looks alright. I will test it later this week.

[ciotlosm]

I've also flashed the provided hex file and I'm able to learn commands but they don't work when sent back. I assume there is a problem with sending.

[franki29]

Hi, the code you put as "original" does not work.

[Portisch]

I checked the transmitting and there is a problem of handling the SYN115 chip.
Does somebody have any information (source code) how to handle the chip correct?

The SYN115 chip will transfer the data but the sync isn't correct. So the receiver will not understand the signal.

The chip looks like is turning off transmit after ~7ms. So I can't transmit a sync bit with 10ms!?
The datasheet is telling something about a third power mode what isn't descripted in the PDF.

So if anyone do have information about this SYN115 let me know!

[AlbertWeterings]

I hope having a look here will help.

[Portisch]

No, they just attach dummy data in front to enable the chip. Also they don't have a pause of 10ms in the transfer.

[AlbertWeterings]

I will have to wait till I get a new Bridge with original firmware than I can log what is happening on the data line. I hope I will also be able to read the original firmware from the chip. I found that with my Wellon VP998 I can read the data from the EFM8 chip as long as the code protection bit is not set.

[Portisch]

Chip protection isn't set. Also I asked them for the original HEX file - no support.

[Portisch]

I just checked it today again. It looks like working with the last commit.

I have done a test by sending the data AAA5382C01CC057845D50C55 4 times, with a 200ms delay to the EFM8 chip:

Channel 1 is the data line on the SYN115. Channel 3 is the data line on the receiver.
As you can see one difference to remotes is the pause between the data packets.
A normal remote will send these 4 packets without a delay of 200ms between each data.

This is a detail of one packet. As you can see the sync and data is received by the EFM8 itself right.

If somebody do have an oscilloscope and original firmware a record of transmitting would be helpfull.

Here the picture where I attached the oscilloscope:

[AlbertWeterings]

@Portisch I have a oscilloscope only have to wait on a new bridge with original firmware. I ordered a few but it seems the (delivery)pigeon have difficulties finding the Netherlands. So when they arrive I hope to have the original firmware available and can do some measurements.

b.t.w. I have read somewhere the data from the receiver is always inverted to what is send to the transmitter in your images I don't see that.

[franki29]

Hi , thanks to keep on going. Maybe this link helps : https://drive.google.com/open?id=0BwEYW5Q6bg_ZTDhKQXphN0ZxdEU. Original web side is http://www.rflink.nl/blog2/development. It looks like they support two SYN115 devices. http://www.rflink.nl/blog2/wiring : Cheap Alternative transmitter 2. Hope this can help.

Br. Frank

[Portisch]

@AlbertWeterings A meassurement on the original firmware would be helpfull. I know espurna will make repeats. But I don't know if the firmware of the EFM8 will do also repeats when transmitting. May I open another branch for testing repeating by the EFM8 chip.

[Portisch]

I have created a new branch.
This version will repeat the data 5 times. It looks ok on the oscilloscope :

[AlbertWeterings]

@Portisch I will test it but will not be at home before tomorrow morning.

As far as I can see ESPURNA in RAW supported mode:
Send message 1 time if only the message is comes in over the MQTT topic "rfraw"
Send message multiple times defined by {code},{times} over the MQTT topic "rfraw"

In original mode:
Send messages from the web interface a predefined amount of times (default 4)
Send message 1 time if only the message is comes in over the MQTT topic "rfout" (not 100% sure)
Send message multiple times defined by {code},{times} over the MQTT topic "rfout"

So i'm not sure if it makes sense to have the EFM repeat the message as having it repeating it will not be able to receive during that time.

[Portisch]

@AlbertWeterings may you try the master again. I fixed the wrong byte position in the uart data.
Please test the master now. It doesn't include repeats - repeats are done by espurna.

[AlbertWeterings]

@Portisch Tested the latest version now and it still doesn't transmit anything. I also connected the input line from the receiver to decoding Arduino direct to Data line to transmitter and don't see anything passing by.

Did you program the light on pin 14 (P1.0) that it must blink while transmit? This stays off all the time.

I have send this several times to the EFM:
0D0A0D0AAAA5382C01CC057845D50C55
Response from EFM:
AAA055

In the morning I will hook up a oscilloscope to see if there is something coming out of the EFM

[AlbertWeterings]

@Portisch Last update and going to sleep now.

AAA50601D0F932113355
No RF light - Sometimes short beep - Nothing on receiver

AAA80601D0F932113355
No RF light - Nothing on receiver

AAB00601D0F932113355
RF light blinking - Nothing decodable receiver
Receiver gets data but can't decode

[AlbertWeterings]

@Portisch Well have been testing today and found all kind of strange behavior. I think we will have to sort out things more structural. I wrote a little program to send data into the EFM the same way ESPURNA does.
In every run I repeat the data 10 times. This is the result.
0D0A0D0AAA {A5} 382C01AE055045D50C550D0A
No LED blink - No buzzer - Data to transmitter - Receiver is not decoding

0D0A0D0AAA {A8} 382C01AE055045D50C550D0A
No LED blink - buzzer beeps for every transmission - No data to transmitter - Receiver is not decoding

0D0A0D0AAA {B0} 382C01AE055045D50C550D0A
No LED blink - buzzer beeps for every transmission - No data to transmitter - Receiver is not decoding

I think we shout first figure out how to get A5 mode send correct data that will be the original mode. Currently it sends something but unable to decode. A wild guess from me is lets try to invert the ASK signal.

[Portisch]

The receiver on the same RF Bridge get disabled while transmission. You only can see it on the oscilloscope. Or did you use another receiver?

[AlbertWeterings]

@Portisch I use a other receiver. And finally I figured out how to measure the pulses coming out of the EFM.
In A5 mode.
The signal of a PT2264:
Approximately : long pulses 1400us short pulses 430us (software measured)
Same code from EFM measured the ASK line:
More precise : long pulses high 1300us low 1200us short pulses high 380us low 450us (oscilloscope)

The signal of a EV1527:
Approximately : long pulses 1080us short pulses 327us (software measured)
Same code from EFM measured the ASK line:
More precise : long pulses high 1000us low 840us short pulses high 280us low 350us (oscilloscope)

You can see there is a difference between the length of a pulse in low and high state, I think that should not be the case. Tomorrow I will measure the ASK signal on both transmitters of the remotes to get theire timings. I have also connected a different transmitter on the ASK line of the EFM that one did also not transmit a signal that could be decided.

[Portisch]

The length of the pulses should not matter. Only the duty cycle. 75% for a 1 bi, 25% for a 0 bit. Like 1400us and 430us are 23%.

[AlbertWeterings]

@Portisch I think I found where it goes wrong. I'm currently comparing the transmission from back to front.
When I send in mode A5 code 380E01D6058C45D50C it starts with a 7ms High 1.2ms low .56 ms high 14320 ms low and from there pulse length of 440 and 1440. The first part is wrong the remote is doing something completely different so I'm now comparing from the end to the front to see if all bits are transmitted.

[AlbertWeterings]

@Portisch Well I have put some time today in finding a working solution based on the data sheets of PT2264 and EV1527 remotes. To compare practical working and theory I used specific receivers for PT2264 and one for EV1527. And started to generate signals according to data sheets instead of signals transmitted by remotes and came to some nice conclusions.

For PT2264 The data sheet say's:
Sync High part = 1/8 bit time
Sync Low part = 4 * bit time - Sync High Part
Bit time = 4 * period time
This means all times can be calculated out of 1 variable the "Period time" so If we keep to the rule of how the total signal has to be build there is a min and max period time on what the receiver is working. I tested this for hours and found min = 395 and max = 1057 uS with repeat to 4 the signal was rock solid on all values in between. At 726 uS the repeats could go back to 4 without loosing stability.
Edit (18-03-2018) - Changed Sync low time as total Sync time is 4 * Bit time including Sync High part. As a result also the period time min and max changed. (all values changed are now bold)

For EV1527 The data sheet say's:
Sync High part = period time
Sync Low part = 30 * period time
Bit time = 4 * period time
This means all times can be calculated out of 1 variable the "Period time" so If we keep to the rule of how the total signal has to be build there is a min and max period time on what the receiver is working. I tested this for hours and found min = 325 and max = 444 uS with repeat to 8 the signal was rock solid on all values in between. At 384 uS the repeats could go back to 2 without loosing stability.
Edit (18-03-2018) - Changed Sync low time as total Sync time is 31 * period time including Sync High part. As a result also the period time min and max changed. (all values changed are now bold)

The period time is what we know as Thigh coming from the EFM when it receives the value has to be divided by 3 to get 1 period time.

So if we are able to Learn a Signal with the bridge we can construct the output signal using only Thigh

Here is the Arduino Sketch I used to test on a Arduino Leonardo with a standard low-cost transmitter:
Emulated_Remote.zip

Emulated_Remote_new.zip

[franki29]

Hi, i tested the new code and it is working for me with my older bridge and the espurna code 1.1.24!
Receiving , learning sending, no problem.
I bought a second one with new layout and this is not working.
So it looks like the new layout cause the problem, the code is OK.

Br. Frank

[ciotlosm]

@franki29 are you using the web interface of Espurna? Did you enable "raw" flag when flashing?

[franki29]

Hi, no i am using the standard bin version of Espurna, i did not compile by myself this time.
And yes, i am using the web interface to switch ON/OFF.
It looks like the new PCB has a additional 5 Pin chip, a"IB3HJ" and it is close to the SYN115. But i could not find what kind of chip it is in the internet yet.

[ciotlosm]

For me the new code for some buttons I have at work doesn't work. It doesn't show up after pressing learn. Some DIO buttons, model: CAWST-907.

[franki29]

Some more information:
Learn code with old PCB ON
2710014A03D4051511
New PCB
2738013603CA051511

OFF
Old PCB 26E8014003D4051514
New PCB 2738014003C0051514

But even i use the OLD PCB code in the new PCB it does not work with the new PCB.

[AlbertWeterings]

@Portisch
With the values in the table below I think you can set the receive limits of both remotes. All values are calculated with the values I found when testing witch actual RF receivers. (See above)

PT2264	Period Min	Period Max	Sync High Min	Sync High Max	Sync Low Min	Sync Low Max	Bit 1 High Min	Bit 1 High Max	Bit 1 Low Min	Bit 1 Low Max	Bit Time Min	Bit Time Max	Repeats	Transmit time Min	Transmit time Min
							Bit 0 Low Min	Bit 0 Low Max	Bit 0 High Min	Bit 0 High Max			by EFM	ms	ms
	395	1057	197.5	528.5	6122.5	16383.5	1185	3171	395	3171	1580	4228	8	353.92	947.072
EV1527	Period Min	Period Max	Sync High Min	Sync High Max	Sync Low Min	Sync Low Max	Bit 1 High Min	Bit 1 High Max	Bit 1 Low Min	Bit 1 Low Max	Bit Time Min	Bit Time Max	Repeats	Transmit time Min	Transmit time Min
							Bit 0 Low Min	Bit 0 Low Max	Bit 0 High Min	Bit 0 High Max			by EFM	ms	ms
	325	444	325	444	9750	13320	975	1332	325	1332	1300	1776	8	330.2	451.104

Now we have to find a way to transmit the signals in the correct format based on the hex data we send to the EFM. I found that if the period time (Thigh/3) is higher than 444us it is alway's a PT226x based remote below 444us it can be a EV1527 and PT2264. To get to know below 444us what remote format to use is harder I think I found a way but can't confirm yet, it looks like the decimal "code" value of a EV1527 has always 1 digit more than the PT2264. Will try to find confirmation in the datasheets.

It is also a possibility to send the codes in both formats PT226x and EV1527 but that can lead to having devices respond to codes that supposed to go to a different device.

[ErikAndren]

Very nice.
Maybe it makes more sense to have a byte in the uart command to the EFM define what protocol is used instead of a heuristics based approach? What will happen if yet another format with a similar timing is to be used?

[AlbertWeterings]

@ErikAndren I like the idea. Problem is the original FW can do the trick without sending a extra Byte so to stay backwards compatible the most general protocols shout work without sending a extra byte.

In RAW mode I think having the extra Byte would be a good thing to make sure the data is send in the proper shape.

[Jason2866]

@franki29 My new unknow 5 Pin chip is namend "IB3HB"

[Portisch]

@AlbertWeterings

For PT2264 The data sheet say's:
Sync High part = 1/8 bit time
Sync Low part = 4 * bit time - Sync High Part
Bit time = 4 * period time

This is Correct:
Let's say Tsync = 10000µs. Then Tsync_low = Tsync / (4096 - 128) * 128 = 322µs.
Tsync_high = 10000µs.
The bit timing is 3:1 or 1:3.

For EV1527 The data sheet say's:
Sync High part = period time
Sync Low part = 30 * period time
Bit time = 4 * period time

Not correct! Sync = 32 * period time. It's hard to read but the arrows in the datasheet shows 1/32 and 31/32 for the sync.
Let's say Tsync = 10000µs. Then Tsync_low = Tsync / 31 = 322µs.
Tsync_high = 10000µs.
The bit timing is 3:1 or 1:3.

So I see no difference between except the sync. For PT226x it should be on back, for EV1527 it is in the front.

@Jason2866
This looks like a USB ESD protection. The SYN115 is connected to the same pin like here: https://github.com/Portisch/RF-Bridge-EFM8BB1/blob/master/doc/Bridge_v1_0.jpg
Also the SYN470 pin is the same.

EDIT: Or it is a Step-Up controller. This is may the reason of L7, D7 and C26. Meassure the voltage on pin 3 a the SYN115 chip if the voltage is higher as 3.3V.

[Jason2866]

@Portisch ok, thx. So new and old version should in general work?!
What frequence does X2 on your board have? On the new board it is 13.560 Mhz.
In circuit diagramm it is 12.000 Mhz.

[Jason2866]

@Portisch: You are right it is a step up controller. Pin 3 on SYN115 is 12 Volt.

[ErikAndren]

I don't follow this math:
Let's say Tsync = 10000µs. Then Tsync_low = Tsync / (4096 - 128) * 128 = 322µs.

According to datasheet tsync is 4096 alpha, ts_high is 128 alpha:
Tsync_high = (tsync / 4096) * 128 = (10000 / 4096) * 128 = 312.6 us.
Tsync_low = (tsync / 4096) * (4096 - 128) = 9687.5 us

[Portisch]

@ErikAndren
I (we) guess the Tsync in the command 0xA5 is the low time of the sync.
The sync bit is 128α high + 3968α low == 4096α

I checked the EV1527 command 297C0168042EB22894:
T-Sync-low: 10620µs
T-Bit-0-high: 360µs
T-Bit-1-high: 1070µs

So T-Sync-high should be 10620 / (4096 - 128) * 128 == 342µs
T-Bit-0-low: 360 * 3 == 1080µs
T-Bit-1-low: 1070 / 3 == 356µs

Sync:

Bit 1:

Bit 0:

EDIT: With original firmware:

Sync:

Bit 1:

Bit 0:

[ErikAndren]

ok, thank you.
Did you come to this conclusion by measuring with the original firmware?

[Portisch]

I have done now some more tests with the original firmware:

AA A5 1F 40 01 90 04 B0 B2 28 94 55
	Should	Meassured
		High	Low
	[µs]	[µs]	[µs]
Tsync	8000	360	7164
Tlow	400	360	1079
Thigh	1200	1075	363
AA A5 2E E0 02 58 07 08 B2 28 94 55
	Should	Meassured
		High	Low
	[µs]	[µs]	[µs]
Tsync	12000	537	10744
Tlow	600	538	1616
Thigh	1800	1612	542

data	description
AA	sync init
--	--
A5	command
1F 40	Tsync
01 90	Tlow
04 B0	Thigh
B2 28 94	data
55	sync end

Make the sync:
High: Tlow;
Low: Tsync

Bit 0:
High: Tlow;
Low: Thigh

Bit 1:
High: Thigh
Low: Tlow

I added a new branch to act like the original firmware on command 0xA5: aef7a13

[ErikAndren]

Interesting.
What is the end goal with the 0xA5 command from your perspective?
Is it to replicate the original firmware implementation or to make it follow the protocol specifications as close as possible?

[Portisch]

The master branch is doing like the datasheet is telling us. But it looks like not working 100%.
So if we get the 0xA5 command working like the original firmware it should be OK. Maybe after this it can be improved again. But right now it is less working than the original firmware.

The alternative firmware have to be 100% compatible to the original one to be able to work with an espurna firmware what isn't supporting the RAW data mode.

[Jason2866]

@ErikAndren Good question. Protocol Specs. are made for best compatibility. But real life is sometimes different. Maybe the guys at ITEAD made an error or the copied (wrong) code "everybody" use...
In my humble opinion the code from the origi. Firmware is "fast written" -> it works! Specs who cares...
So in my case a very old and simple code (Intertechno Power Outlet -> HX2262) is false decoded from the RFBridge and cant be learnend. To sent works very well, with hand calculated correct code.
This brings me to the conclusion, the code isnt that good...

[AlbertWeterings]

@Portisch I agree on the part where for EV1527 Tsync low is 31* period time.
Can we also agree that what the EFM reports as Thigh = 1/3 of a bit(other words the high part of a bit 1)? If we do than perid time is 1/4 of a bit. If you start calculating from these facts the total Sync of a PT226x is completely different as from the EV1527.

If I generate the signals with a arduino they are perfectly accepted by the specific receivers to the EV1527 and PT226x I tried to put the sync as calculated for the EV1527 behind the code part of the PT226x and the receiver doesn't respond anymore.

PT226x						EV1527
Periode time	Total Sync	Tsync High	Tsync low	Thigh from EFM		Periode time	Total Sync	T Sync High	T Sync low	Thigh from EFM
	Thigh*16	1/8*bit	(4bit)-(1/8bit)			Thigh/3	Thigh*32	Thigh	Thigh *31
395	6320	197.5	6122.5	1185		395	12640	395	12245	1185
396	6336	198	6138	1188		396	12672	396	12276	1188
397	6352	198.5	6153.5	1191		397	12704	397	12307	1191
398	6368	199	6169	1194		398	12736	398	12338	1194
399	6384	199.5	6184.5	1197		399	12768	399	12369	1197
400	6400	200	6200	1200		400	12800	400	12400	1200
401	6416	200.5	6215.5	1203		401	12832	401	12431	1203
402	6432	201	6231	1206		402	12864	402	12462	1206
403	6448	201.5	6246.5	1209		403	12896	403	12493	1209
404	6464	202	6262	1212		404	12928	404	12524	1212
405	6480	202.5	6277.5	1215		405	12960	405	12555	1215
406	6496	203	6293	1218		406	12992	406	12586	1218
407	6512	203.5	6308.5	1221		407	13024	407	12617	1221
408	6528	204	6324	1224		408	13056	408	12648	1224
409	6544	204.5	6339.5	1227		409	13088	409	12679	1227
410	6560	205	6355	1230		410	13120	410	12710	1230
411	6576	205.5	6370.5	1233		411	13152	411	12741	1233
412	6592	206	6386	1236		412	13184	412	12772	1236
413	6608	206.5	6401.5	1239		413	13216	413	12803	1239
414	6624	207	6417	1242		414	13248	414	12834	1242
415	6640	207.5	6432.5	1245		415	13280	415	12865	1245
416	6656	208	6448	1248		416	13312	416	12896	1248
417	6672	208.5	6463.5	1251		417	13344	417	12927	1251
418	6688	209	6479	1254		418	13376	418	12958	1254
419	6704	209.5	6494.5	1257		419	13408	419	12989	1257
420	6720	210	6510	1260		420	13440	420	13020	1260
421	6736	210.5	6525.5	1263		421	13472	421	13051	1263
422	6752	211	6541	1266		422	13504	422	13082	1266
423	6768	211.5	6556.5	1269		423	13536	423	13113	1269
424	6784	212	6572	1272		424	13568	424	13144	1272
425	6800	212.5	6587.5	1275		425	13600	425	13175	1275
426	6816	213	6603	1278		426	13632	426	13206	1278
427	6832	213.5	6618.5	1281		427	13664	427	13237	1281
428	6848	214	6634	1284		428	13696	428	13268	1284
429	6864	214.5	6649.5	1287		429	13728	429	13299	1287
430	6880	215	6665	1290		430	13760	430	13330	1290
431	6896	215.5	6680.5	1293		431	13792	431	13361	1293
432	6912	216	6696	1296		432	13824	432	13392	1296
433	6928	216.5	6711.5	1299		433	13856	433	13423	1299
434	6944	217	6727	1302		434	13888	434	13454	1302
435	6960	217.5	6742.5	1305		435	13920	435	13485	1305
436	6976	218	6758	1308		436	13952	436	13516	1308
437	6992	218.5	6773.5	1311		437	13984	437	13547	1311
438	7008	219	6789	1314		438	14016	438	13578	1314
439	7024	219.5	6804.5	1317		439	14048	439	13609	1317
440	7040	220	6820	1320		440	14080	440	13640	1320
441	7056	220.5	6835.5	1323		441	14112	441	13671	1323
442	7072	221	6851	1326		442	14144	442	13702	1326
443	7088	221.5	6866.5	1329		443	14176	443	13733	1329
444	7104	222	6882	1332		444	14208	444	13764	1332

PT2264 vs EV1527.zip

[Portisch]

@AlbertWeterings
Did you try the new branch? This should now act like the original firmware on comand 0xA5.

[AlbertWeterings]

I have to agree with @Jason2866 the values the EFM with original FW is spitting out for Tsync and Tlow can't be right. I can not find any way to compair them to the signals @Portisch and myself have measured by oscilloscope. The only value I could make sens of is Thigh if I divide it by 3 it always comes close to the High part of a bit 1

@Portisch I will test right away when I'm at home

[Portisch]

As the transmit like described in the datasheet isn't working very well I have done this new PT226x branch. I think ITEAD have done trial & error on the firmware. So the alternative firmware should "simulate" as near as possible the original behavior.

But I don't know if this will also have affect to the transmitting:

	should	is	diff	diff
	[µs]	[µs]	[µs]	[%]
Tsync	8000	7164	836	10,45
Tlow	400	360	40	10
Thigh	1200	1075	125	10,41667
	should	is	diff	diff
	[µs]	[µs]	[µs]	[%]
Tsync	12000	10744	1256	10,46667
Tlow	600	538	62	10,33333
Thigh	1800	1612	188	10,44444

The original firmware reduce the timings about 10%.

This is with the PT226x branch:

	should	is	diff	diff
	[µs]	[µs]	[µs]	[%]
Tsync	8000	7987	13	0,1625
Tlow	400	392	8	2
Thigh	1200	1188	12	1

[AlbertWeterings]

@Portisch The PT2264 branch is better than the master It learns PT2264 remote (pretty well sometimes need retries) and instantly learns EV1527. It transmits PT2264 reliable (receiver responds by only the repeats from the EFM) EV1527 reliable (receiver responds by only the repeats from the EFM)

Codes from SonOff PIR-2 are learned ok ( Chip LD27L2 )
Codes from SonOff door sensor are learned ok ( EV1527 )

ESPURNA may not repeat otherwise receiver is triggered twice. So codes cannot be used in the webinterface.

This looks really good thanks for the effort. Can you tell how the values TSync, Tlow and Thigh are now related to the generated signal?

[Portisch]

Just take a look above: #2 (comment)

[Portisch]

@ALL
Thank all for the help!
Issue closed by commit 3ee7477.

[Jason2866]

@Portisch
Is master branch now the same as 3ee7477 ?

[Portisch]

Yes, the commit got merged to the master.