Receive OK, but sending does not work with espurna about rf-bridge-efm8bb1 HOT 120 CLOSED

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

from rf-bridge-efm8bb1.

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.

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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 ?

from rf-bridge-efm8bb1.

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.

from rf-bridge-efm8bb1.

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.

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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!

from rf-bridge-efm8bb1.

I hope having a look here will help.

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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:

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

@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

from rf-bridge-efm8bb1.

@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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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?

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

The 7ms high in front is needed to activate the SYN115 chip. The 1,2ms is low and than the sync pulse is starting. 14320 / 3968 *128 = 460us.

from rf-bridge-efm8bb1.

@Portisch I don't have a oscilloscope that is possible to produce image. Can you have a look at the attached excel. It gives both the ASK out
bridge-vs-remote.zip

I'm going to hook up a different transmitter to the bridge and see if that will transmit anything.

put on the remote and EFM

from rf-bridge-efm8bb1.

Some questions based on http://www.princeton.com.tw/Portals/0/Product/PT2260_4.pdf

1. Looking at page 5 shouldn't the sync come last in the transaction? Maybe the command need to be sent twice?
2. Why divide by 3968? According to page 4 sync bit width is 4096 alpha

from rf-bridge-efm8bb1.

it looks like sync bit comes in the end. what also is strange A0 is the first bit of the word and repeated just before the sync bit.

A different transmitter instead of the SYN115 makes no difference

from rf-bridge-efm8bb1.

Last A0 is most likely a typo. Check the examples just below the image (2 data, 4 data)

from rf-bridge-efm8bb1.

@ErikAndren this is the unknown part. The master branch will do no repeats. The transmit_repeat branch will do 5 repeats on each UART command. I don't know how the original firmware is doing the transmission.

from rf-bridge-efm8bb1.

Well I figured out the following see Excel file for details.
If I measure with a oscilloscope in a remote on the ASK line I get the same pattern as I receive with the RCSwitch library. I only see a 0 on the end of the code Most likely the sync bit. When I measure on the ASK line from the bridge I see the sync bit in front of the code and it is missing in the end.

from rf-bridge-efm8bb1.

@Portisch & @ErikAndren guys the solution I disconnected the ASK line of the SYN115 from the EFM and injected the ASK signal as it comes from my PT2264 to the SYN115 and it transmit the code without any problem. So "The 7ms high in front is needed to activate the SYN115 chip" is not needed.

@Portisch Can you remove the 7ms high and place the SYNC puls on the end of the code. It must be working that way.

from rf-bridge-efm8bb1.

So you will need a minimum of 2 repeats? Otherwise you don't know where the data is starting, isn't?

from rf-bridge-efm8bb1.

Don’t think it is needed as the carrier of the SYN115 is always on so it will just start to transmit

See this it is explaining the transmitter will not transmit any energy as long as the ASK line is kept low. So the carrier can stay on without disturbing the receiver.

from rf-bridge-efm8bb1.

I don't think the SYN115 is always on. This is my problem. The datasheet is also telling something about power saving after ~75ms.

from rf-bridge-efm8bb1.

@Portisch Datasheet Page 6/16 and 8/16 "Enable control gates the ASK data. it only allows transmission when Lock, Amplitude and Under voltage detection conditions are valid. And page 10 14.2 first part.

We can just gif it a try

from rf-bridge-efm8bb1.

75ms is standby delay this doesn’t say the SYN115 needs a puls to come out of standby it is saying the SYN115 goes into standby 75ms after the last high to low transition

from rf-bridge-efm8bb1.

@Portisch you are right "So you will need a minimum of 2 repeats" Ï found in the) PT2264 data sheet that every code word has to be transmitted 4 times. This makes sense as the EV1527 has the sync pulse in front of the code word where PT2264 has it behind the code word.

In the transmission data to the EFM we put sync, high and low time. So the correct ASK signal can be generated as receivers for a specific type of transmitter will only listen to a signal with specific timings.

EV1527 has a significant shorter sync pulse as PT2264 so I think you can use the sync pulse length to determine the type of transmitter on the receiver (decoding) side. If you know the sync pulse you can use it to select the high and low times.

from rf-bridge-efm8bb1.

@AlbertWeterings I moved the SYNC to the end an repeating the data 2 times right now. Please have a try: https://github.com/Portisch/RF-Bridge-EFM8BB1/tree/PT226x_Test

For the PT226x and EV1527 the high and low times of the bits aren't matter. The decoding is done by duty cycle.
The sync duty cycle have to be mattched than decoding is starting.

from rf-bridge-efm8bb1.

@Portisch I am still waiting for external receivers, but tried out already known code for rf outlet associated with remote. New version with rotated sync works, but only when there are 4 repeats instead of 2. And that sometimes hangs the device - it stops handling uart, no receiving or sending commands.

Side note: Looking at the received data from rf PIR - consistently shows up as 3-4 repeats. Same for door one. Remotes send out one initially, and more when holding.

from rf-bridge-efm8bb1.

@mcspr thx for this info. I will change the repeat to 4. I also have seen the hangup on the EFM8 device. I am right now searching how to fix this.

from rf-bridge-efm8bb1.

@Portisch I will test the new version in the evening expect it will now work.

As far as I understand from the PT2264 datasheet the data needs to be send 4 times the Sync is in between the data so [data]sync[data]sync[data]sync[data]sync this is also what I see on the oscilloscope when I press the button on the remote in case of EV1527 I see the same on the oscilloscope only thing I did not notice is that for EV1527 sync is before data. In practice it doesn't matter if data is send 4 times with sync in between.

You say pulse length doesn't matter I'm not sure about that it doesn't matter if a specific receiver expects a predefined pulse length. On most uP the pulse width relates to the oscillator settings for example on a PT2264 you set the oscillator with a resistor on pin 15. On the EV1527 you do the same on pin 1. On the receiver side you set the oscillator to the same freq otherwise it will not receive right.So in basic you can't receive a code with a certain pulse width change the pulse width and expect the receiver to accept the code only based on duty cycle.

I had a hard time catching the data from the bridge on my oscilloscope with the previous version as it was only send once and there was 500ms in between. Both remotes where easy as they transmit a constant stream.

from rf-bridge-efm8bb1.

@mcspr Should work right now. I fixed the hangup and increased the repeat to 4 times.

@AlbertWeterings I also think it doesn't matter if the sync is on the front or back if it get repeated.
I have done this already before with sync ion the front BUT with a delay between each repeat. may this was the misstake. Other know protocols to have the sync in front of the data.

I think I will do again another branch where the sync is in front, but repeated 4 times without delay between.

from rf-bridge-efm8bb1.

@Portisch Thanks. Will try out later.

I also remembered that espurna uses 4 times by default for original rfout mode. Or optionally using code,repeats So it is either 4 times here or there? Or am I misunderstanding EFM8 repeats relation to the espurna's espurna/code/espurna/config/general.h, #2 (comment)

from rf-bridge-efm8bb1.

@Portisch and @mcspr I know ESPURNA does the repeats but PT2264 documentation states no delay between transmission. ESPURNA has a default 500ms in between every transmission. So in I think best way to go is have EFM send repeat 4 times as in documentation of protocol and see this as 1 transmission (same way a remote does) , ESPURNA or other software can repeat the transmission with a delay (like pressing the remotes button several times)

from rf-bridge-efm8bb1.

The new branch https://github.com/Portisch/RF-Bridge-EFM8BB1/tree/SYNC_IN_FRONT is doing the sync in front of data. Please test this and the https://github.com/Portisch/RF-Bridge-EFM8BB1/tree/PT226x_Test branch. But only with command 0xA5!

from rf-bridge-efm8bb1.

@Portisch Thanks for the effort we are making progress.
The result.:
https://github.com/Portisch/RF-Bridge-EFM8BB1/tree/SYNC_IN_FRONT Transmitting:
PT2264 code
380E01D6058C45D50C intermittently 2 out of 50
382201D6056E45D50C intermittently 15 out of 50 (Changed timing)
382201D6056E45D503 correct 50 out of 50
EV1527 code
2990012203D4B22894 correct 50 out of 50
2990012203D4B22898 correct 50 out of 50

https://github.com/Portisch/RF-Bridge-EFM8BB1/tree/PT226x_Test Transmitting:
PT2264 code
380E01D6058C45D50C correct
382201D6056E45D503 correct

EV1527 code
2990012203D4B22894 not received at all
2990012203D4B22898 not received at all

So I'm a big fan already for the sync in front version. Only have to find why it not sends all codes correct will test with more after dinner.

from rf-bridge-efm8bb1.

@Portisch Did a long test, it looks reasonably good.

I have send every code 50 times with ESPURNA firmware there was a 500ms delay between every transmission. All transmitted codes are learned by the bridge using Portisch firmware. At the moment I don't have a bridge with original firmware to compare.

EFM Firmware used is the new branch https://github.com/Portisch/RF-Bridge-EFM8BB1/tree/SYNC_IN_FRONT

All testing is done with mode A5

First my conclusion:
From the countable mistakes the codes transmitted by the bridge where 14 times more not decoded right by the receiver. (Faults counted bridge 80 remote 66) Total codes transmitted by the bridge and remote 1200 that are counted 146 faults = 12%. Faults by bridge 13% by remote 11%.

I think transmission of the codes by the bridge is good maybe with a little tweaking of the code it can be better.

@Portisch : Can you tell the current amount of repeats by the firmware "Sync in front"? if this is now 1 than it might be that if we increase reception can be better. If this is 2 than it is only decoded 1 time so then increasing will for sure increase the reliability.

The results in detail (logging of these result in attached zip file):
EV1527:
Code learned recently 2968014A0424B22894 when I re-transmit I don't receive anything.
Code learned earlier 2990012203D4B22894 (timing is different) this transmits.
Received 50 out of 50 - 45 out of 50 correct.
Same code send with remote: 40 out of 50 correct.

Code learned recently 29720154041AB22898 when I re-transmit I don't receive anything.
Code learned earlier 2990012203D4B22898 (timing is different) this transmits.
Received 50 out of 50 - 40 out of 50 correct.
Same code send with remote: 45 out of 50 correct.

Code learned recently 2972015E041AB22891 when I re-transmit I don't receive anything.
Don't have a previous log on this code.
Same code send with remote: 45 out of 50 correct.

Code learned recently 298601540424B22892 when I re-transmit I don't receive anything.
Don't have a previous log on this code.
Same code send with remote: 44 out of 50 correct.

PT2264:
Code learned recently 382C01D6058245D5C0
Received 21 out of 50 - 17 out of 50 correct.
Same code send with remote: 47 out of 50 correct.

Code learned recently 385E01D6057845D5F0
Received 1 out of 50 - 1 out of 50 correct.
Same code send with remote: 42 out of 50 correct.

Code learned recently 389A01E0056E45D5CF
Received 50 out of 50 - 42 out of 50 correct.
Same code send with remote: 49 out of 50 correct.

Code learned recently 384001CC056E45D503
Received 50 out of 50 - 45 out of 50 correct.
Same code send with remote: 45 out of 50 correct.

Code learned recently 384001CC057845D50C
Received 50 out of 50 - 44 out of 50 correct.
Same code send with remote: 42 out of 50 correct.

Code learned recently 384001CC057845D530
Received 50 out of 50 - 42 out of 50 correct.
Same code send with remote: 44 out of 50 correct.

Code learned recently 385401D6057845D5C3
Received 50 out of 50 - 43 out of 50 correct.
Same code send with remote: 44 out of 50 correct.

Code learned recently 385401D6057845D5CC when I re-transmit I don't receive anything.
Don't have a previous log on this code.
Same code send with remote: 44 out of 50 correct.

Code learned recently 385E01D6057845D53C when I re-transmit I don't receive anything.
Code learned earlier 386801CC058245D53C (timing is different) this transmits.
Same code send with remote: 0 out of 50 correct.

Code learned recently 386801D6058245D533
Received 50 out of 50 - 45 out of 50 correct.
Same code send with remote: 40 out of 50 correct.

Code learned recently 387201D6057845D50F
Received 50 out of 50 - 41 out of 50 correct.
Same code send with remote: 46 out of 50 correct.

Code learned recently 388601E0057845D53F
Received 50 out of 50 - 42 out of 50 correct.
Same code send with remote: 42 out of 50 correct.

The lines in the log files are sorted to make fault counting easier.
Code_log.zip

from rf-bridge-efm8bb1.

Thx for testing.

What does this mean:

298601540424B22892 when I re-transmit I don't receive anything.

Just learned and then transferred? Who is the receiver?

The sync_in_front is repeated 4 times. But because the sync have to be on the end, only 2 are useful.
First isn't complete because of DAY wakeup. Second and third are ok. Last one is missing the sync on the end. May more repeats are useful and also may a sent sync on end of the transfer would help.

from rf-bridge-efm8bb1.

@Portisch . Answer to the first question is Learned with the bridge and transmitted by the bridge. My secondary receiver decoded the code during the learn process but as the bridge send it is not decoded. As you can see on the EV1527 test results I learned codes several times and sometimes it is learning the same code with different timing and it then works. So maybe the accuracy of the learning is a bit off we can check after we get our hands on a bridge with original firmware. I can also measuring timings with a oscilloscope and compare them with the learned timings (will do that first).

I think with a sync on the end of the "fourth code word" might help in case of the PT2264 but I don't know how it affects the EV1527. I would suggest to try if you make a version with this in it I can do the test over.

A other option might be Sync in front or on the end based on what we tell the EFM. Sync for PT2264 is different as for EV1527. I found there are 6 different protocols with all their own sync pulse.

Maybe you found these two links already they give some inside information that might help improving the firmware.
Home Automation – RF Protocols
Home Automation – RF Protocol, update.

from rf-bridge-efm8bb1.

@AlbertWeterings I think the problem would be the timer for the sync. Example code: 38 86 01 E0 05 78 45 D5 3F.

sync low time: 14470µs (0x3886)
sync high time: 467µs (0x3886 / (4096-128) * 128)
bit 0 high time: 480µs (0x1E0)
bit 0 low time: 1440µs (0x1E0 / 4 * 12)
bit 1 high time: 1400µs (0x578)
bit 1 low time: 467µs (0x578 / 12 * 4)

CH1 is the transmitted data, CH2 the received on the RF Bridge.
+Width(3) is 360µs - should be 470µs
-Width(3) is 14265µs - should be 14470µs

The bits should be in tolerance.
Bit 0:

Bit 1:

from rf-bridge-efm8bb1.

@Portisch I also just measured the Remotes:

PT2264 on 12v with 4.7M osc resistor.
Sync Thigh 560us Tlow 14400us Total sync time 14960us
The total bit time is 1880us short part of a bit 360us long part of a bit 1520us

EV1527 on 12v with 330K osc resistor
Sync Thigh 400us Tlow 10600us Total sync time 11000us
The total bit time is 1380us short part of a bit 350us long part of a bit 1030us

Question now is do we have to adjust the receiving or transmitting part? problem is every time when I learn a code on the bridge I get a different Tsync Tlow and Thigh. I will log 100 decoded timings of the bridge for both remotes and we can look how close it comes to what I measured.

from rf-bridge-efm8bb1.

Timings as decoded with @Portisch firmware.
Every decoded code of both remotes is correct. I think safe to say the decoding part of the firmware is accurate.

EV1527

PT2264

timings.zip

from rf-bridge-efm8bb1.

I pushed a new commit where I tuned the sync timer a little bit. My tests with UNDERWATER PAR56 LED LAMP are working without any problems. As the RF data will be repeated by the EFM8 6 times there is no need to repeat by espurna.
If the standard repeat of espurna is 4 the data will be sent 4 * 6 times.

New timing on the same RF data: AA A5 38 86 01 E0 05 78 45 D5 3F 55

from rf-bridge-efm8bb1.

@Portisch I just did a short test and found that if I send a code 1 time it is decoded by the receiver twice if send 50 times it is decoded 100 times. So I think 6 repeats is a bit to much if a device has to switch on and off by the same code it will now do 2 actions.

Did you change the sync timer also on the receiving side? it looks to me during a short test the by the bridge decoded timing are more constant.

I will repeat the test from yesterday (re-learn all codes and transmit them a equal time)

from rf-bridge-efm8bb1.

@Portisch Sorry to say it became worse, most of the newly and old (by the bridge) learned codes are not decoded more than 4-9 times out of 50 after I transmit them again with the bridge.

I extended the test with a third receiver that has 12 channels and hooked up 12 led's to it. When I send the 12 codes corresponding to the led's (interval 1 sec) one after an other they shout light up one after an other in a steady flow. They don't it is not going regular and sometimes it skips led's.

An other observation is the RF led of the bridge (this is minor) it lights when receiving but doesn't light up when sending. In the original firmware id did. I think it is good to have it light also during transmitting.

from rf-bridge-efm8bb1.

I merged the SYNC_IN_FRONT branch to the master. Changed repeat from 6 down to 4 and added the LED flashing while transmit.

from rf-bridge-efm8bb1.

@Portisch Thanks will test in the evening. I also will get a few RF remotes today with hopefully different uPC's so we can check if they also work.

from rf-bridge-efm8bb1.

@Portisch. Latest version in master branch is not working at all. I had to go some versions back to find one that is working a bit.

https://raw.githubusercontent.com/Portisch/RF-Bridge-EFM8BB1/master/Keil%208051%20v9.53%20-%20Release/RF_Bridge.hex
transmit (bad) Learn Very bad.
https://github.com/Portisch/RF-Bridge-EFM8BB1/blob/f9121860310382b6420c0c96509167578c2cca83/Keil%208051%20v9.53%20-%20Release/RF_Bridge.hex
transmit (no) Learn (no).
17fdda4#diff-ff5aa20228c386165033a4574d0c48b6
transmit (no) Learn (no).

This one works reasonable:
https://github.com/Portisch/RF-Bridge-EFM8BB1/blob/6d73cdcd0849f78a4224ff0db69f5b91552b2bd8/Keil%208051%20v9.53%20-%20Release/RF_Bridge.hex
transmit (almost perfect) Learn (No)

So last one in the row sending almost perfect.
I got today a new bridge with original firmware. What I did is read all code's from the remote with this new bridge and programmed them in a loop with a 2 sec wait in between. I have the 12ch receiver programmed with the same codes in the same sequence. When I transmit the codes with the original firmware the led's switch on and of in the same sequence as the codes. When I send the codes with the firmware version that works reasonable the led's light up but sometimes one is skipped or they don't go in sequence.
Learning codes is not working with this firmware the buzzer says beep but nothing appears on the screen.

Than more bad news. The EFM8 in the new bridge is protected only the first half of the flash rom can be read. A other problem Communication between ESP en EFM is not working with ESPURNA the board is slightly different designed. I will have to search what they did.

from rf-bridge-efm8bb1.

You are sure it's protected or is it a 4k model? Would be bad because my firmware needs already ~6k. Do you have access to the RS232 header of the EFM8? Also a picture would be nice.

What I would need: transmit only one 0xA5 command over the RS232 to the EFM8 and record the T_DATA line with an oscilloscope. Then I can modify the firmware that it acts like the original one.

from rf-bridge-efm8bb1.

I managed to get the original firmware from the EFM and wrote it back in a other one It took me some time but it works. The hex file is in a format you can't write it with the Arduino programmer it has to be manipulated as it is in the wrong format (lines are to long).

I'm working on the file formats now

from rf-bridge-efm8bb1.

Oke here it is the original firmware. The ZIP contains 3 files I tested them all and they work. You can write the INTELH8 file with the Arduino programmer (after writing the flash do a power cycle) the other files can be used for different programmers.

If someone wants to use a programmer like the Wellon VP-890 or EasyPro80B the EFM8 is not supported by the software select "Silicon Lab C8051F300 (ISP)" and your programmer will do the job over the ISP C2 bus. (do not program the config bit)

SonOff_Bridge_origional_FW.zip

from rf-bridge-efm8bb1.

Very good! Than I can start debugging tomorrow morning. Thank you! Is it also ok for you that I add it to the master branch?

from rf-bridge-efm8bb1.

Sure these files I share so people can always decide to go back to the original firmware.

A remark on the beep function in the version I use it doesn't work yet. I have send in raw mode AAC001F455 to get a 500ms beep but nothing happens. The data between ESP and EFM has the linebreak in fron and after the code.

from rf-bridge-efm8bb1.

It's just beeping, nothing more.

from rf-bridge-efm8bb1.

Original firmware test command:
AA A5 38 86 01 E0 05 78 45 D5 3F 55

38 86: 14470µs
01 E0: 480µs
05 78: 1400µs

The original firmware is transmitting the data 8 times.
The sync is in front of the data:

Real timing of the sync bit:

430µs ON, 12954µs OFF
Calculated values:
4096 Alpha = 13384µs
128 Alpha = 418µs
3968 Alpha = 12965µs

Real timing of a bit 0:

430µs ON, 1258µs OFF

Calculated values:
512 Alpha = 1688µs
128 Alpha = 422µs
384 Alpha = 1266µs

Real timing of a bit 1:

1254µs ON, 435µs OFF

Calculated values:
512 Alpha = 1689µs
128 Alpha = 422µs
384 Alpha = 1266µs

Alternative firmware:
Real timing of the sync bit:

476µs ON, 14431µs OFF

Calculated values:
4096 Alpha = 14907µs
128 Alpha = 465µs
3968 Alpha = 14441µs

Real timing of a bit 0:

471µs ON, 1445µs OFF

Calculated values:
512 Alpha = 1916µs
128 Alpha = 479µs
384 Alpha = 1437µs

Real timing of a bit 1:

1391µs ON, 473µs OFF

Calculated values:
512 Alpha = 1864µs
128 Alpha = 466µs
384 Alpha = 1398µs

So now the question is:
The sync should be 14470µs. On the original firmware it get transmitted with these values:
430µs ON, 12954µs OFF
4096 Alpha = 13384µs

This is a difference about 1100µs...

from rf-bridge-efm8bb1.

There is also a difference at the sniffing. It looks like the original firmware is filtering repeated data.
My firmware isn't.
When I send a code repeated 8 times every second this is the result:

Original firmware:

12:17:08.693: AAA43EA801FE060EAAAAAA55
12:17:09.590: AAA43EA801FE060EAAAAAA55
12:17:10.220: AAA43EC601FE060EAAAAAA55
12:17:11.747: AAA43EA801FE060EAAAAAA55

My firmware:

12:19:48.487: AAA43EA801CC05E6AAAAAA55
12:19:48.619: AAA43EA801F4060EAAAAAA55
12:19:48.685: AAA43E9E01FE0618AAAAAA55
12:19:48.751: AAA43E9E0208060EAAAAAA55
12:19:48.817: AAA43E9E0208060EAAAAAA55
12:19:49.068: AAA43E9E01F4060EAAAAAA55

12:19:50.014: AAA43E9E01E005FAAAAAAA55
12:19:50.081: AAA43EBC01EA05FAAAAAAA55
12:19:50.147: AAA43EB201FE0604AAAAAA55
12:19:50.213: AAA43E9E02080604AAAAAA55
12:19:50.279: AAA43E9E01FE060EAAAAAA55
12:19:50.345: AAA43E9401F40604AAAAAA55
12:19:50.592: AAA43E9E0208060EAAAAAA55

from rf-bridge-efm8bb1.

@Portisch I will test the rebuild this evening.

I also noticed during read/learn the original firmware needs more samples, it looks like it records a few samples and only send one that occurred the most to the UART

This morning I did not had much time but i increased the baud rate from my receiver to the PC and noticed that I got like 350 received codes when I send only 50 that is what you see in the data and most likely is the repeating the EFM8 does.

Also the RF led behaves different in the original firmware. It blinks 1 time short after send in alternative firmware it does during send data. Changing this might be safer as no CPU cycles will be lost for controlling the LED during send. In receive mode it looks like the LED blinks when a sync comes by.

In my Setup beeping did not work yesterday I will check with newer version.

Maybe it is good to add a command to ask the EFM8 witch version of the alternative FW is loaded this can become handy when working on reported issues. Just a INT counter will do nothing fancy

from rf-bridge-efm8bb1.

@Portisch Found a bug in the latest build.
After sending the beep command "AAC001F455" The firmware doesn't come back in listening mode so receiver is dead. It comes back to life after sending a "A5" command.

Learning a code isn't working very well:
It doesn't learn any of the EV1527 remote codes and only some after many tries with the PT2264

Sending codes is looking good now.

from rf-bridge-efm8bb1.

Give me the two codes that I can test it.

from rf-bridge-efm8bb1.

@Portisch The difference you see in timings can they be related to the internal oscillator I have seen the EFM8 has 3 internal oscillators. The higest freq is also the most accurate 1.5% vs 2% For sampling the receiver data the highest possible frequency will be the most accurate.

from rf-bridge-efm8bb1.

Better would be an oscilloscope record of the not working remotes. May it is timing/tolerance issue.

from rf-bridge-efm8bb1.

PT2264
387C01CC058245D503 Need several tries
38A401E0058245D533 Does not learn at all

EV1527
2990015E0410B22894 Does not learn at all
2990015E0410B22898 Does not learn at all
2990015E0406B22891 Does not learn at all
299A015E0410B22892 Does not learn at all

All codes read by original firmware

from rf-bridge-efm8bb1.

Something else the Bridge with original firmware is not learning the codes I transmit with the other switch using alternative firmware. I will now try to feed the transmitting bridge the codes read with the original bridge and see what happens.

from rf-bridge-efm8bb1.

I will need oscilloscope records of the R_DATA line. Then and only than I can see the real duty cycle and high/low times.

from rf-bridge-efm8bb1.

not from ask line in remote? I think that will be the most accurate

from rf-bridge-efm8bb1.

The original FW bridge has it difficult learning its own codes when transmitted with the alternative firmware

from rf-bridge-efm8bb1.

Be right back, I will measure both in receiver and in remote.

from rf-bridge-efm8bb1.

not from ask line in remote? I think that will be the most accurate

Better would be the rdata line. That's what the EFM8 see. It doesn't matter what firmware, only the waveform would be interesting.

from rf-bridge-efm8bb1.

I’m working on it

from rf-bridge-efm8bb1.

@Portisch

Screenshots will follow. All times are uS

Difference between Receiver and Remote 92uS

Test with PT2264 and Bridge

PT2264 - Sync pulse High part

PT2264 - Sync pulse low part

PT2264 - Full Bit time

PT2264 - Bit 1 High part

PT2264 - Bit 1 low part

Bit 0 High part

Bit 0 Low part

EV1527 - Sync High part

Sync Low part

EV1527 - Full bit

EV1527 - Bit 1 High part

from rf-bridge-efm8bb1.

@AlbertWeterings Thank you for the nice pictures ;)
I increased the tolerance of the sync bit detection.
Before it was:

Now with commit aba0b61 it is:

I don't know why the EV1527 doesn't get recognized because on your sample the sync should have already been fitted:

Also the bit 0 and bit 1 tolerances should be good.
On your PT226x example:

On your EV1527 example:

I do have a 8% tolerance from 75% for bit 1 and 25% for bit 0.

from rf-bridge-efm8bb1.

@Portisch : I will do a new test this evening. Did you also looked at the other issues I mentioned above
#2 (comment)
and
#2 (comment)

from rf-bridge-efm8bb1.

The LED flashing takes no or less CPU cycles. It changes on the state of the received bit.
Same on sending. Won't fix.

The other thing with restarting sniffing after command 0xC0 and 0xFF is fixed.

from rf-bridge-efm8bb1.

@Portisch Good news and a bit less good.

ESPURNA 1.12.4 (Raw support on)
If learn key in web interface is pressed mode A1 EV1527, PT2264 and LD27L2 codes appear in the web interface.

ESPURNA 1.12.4 (Raw support off)
Send 1 for on 0 for off to topic ESPURNA_xxxx/rflearn/{relay_id}/set

• EV1527, PT2264 and LD27L2 codes appear in the web interface. (Learn mode A1)

ESPURNA 1.12.4 (Raw support on)
Send 1 for on 0 for off to topic ESPURNA_xxxx/rflearn/{relay_id}/set

• EV1527, PT2264 and LD27L2 codes appear in the web interface. (Learn mode A1)

ESPURNA 1.12.4 (Raw support on)
Send AAA655 to topic ESPURNA_xxxx/rfraw/set to enables Raw sniffing (Mode A5).

• EV1527, LD27L2 and PT2264 codes received are send in topic ESPURNA_xxxx/rfin to MQTT broker
  Send AAA755 to topic ESPURNA_xxxx/rfraw/set to disable Raw sniffing (returns to default sniffing)
• EV1527, LD27L2 and PT2264 codes received are send in topic ESPURNA_xxxx/rfin to MQTT broker

ESPURNA 1.12.4 (Raw support on)
Send AAA955 to topic ESPURNA_xxxx/rfraw/set to enables LEARN NEW (Mode A9).

• EFM goes into mode A9 When code 385401B8054645D503 is broadcasted EFM response with AA AB 04 01 45 D5 03 55 ESPURNA doesn't do anything with it. (only visual in Telnet when debug line in void _rfbReceive of rfbridge.ino is enabled)

ESPURNA 1.12.4 (Raw support on)
Send AAC001F455 to topic ESPURNA_xxxx/rfraw/set to enable BUZZER (Mode C0).

• Buzzer beeps LONGER as the expected 01 F4 = 500ms. EFM returns into default sniffing mode. ESPURNA does not understand to repeat beeps if ,x is added (like it can repeat transmitting codes)

ESPURNA 1.12.4 (Raw support on)
Send AAFF55 to topic ESPURNA_xxxx/rfraw/set to request alternative FW version (Mode FF).

• EFM8 returns the FW version in HEX (only visual in Telnet when debug line in void _rfbReceive of rfbridge.ino is enabled)

from rf-bridge-efm8bb1.

@Portisch
The less good news.
The codes from EV1527:
297C0168042EB22894
298601680424B22898
297C01680424B22891
297C01680424B22892
Are not transmitted in a correct way, my secondary receiver can decode them when send with the remote but not when send with the EFM in Raw and default mode after learning them.

Maybe good to now my secondary receiver reports a period duration of 344us when it receives this signal from the remote. (period duration = 1/3 of a bit)

When code is transmitted:
38D601D6057845D5CF
38540186055A45D50C
385401B8055045D503
The secondary receiver has massif problems decoding it decodes but when send 10 times with ESPURNA to the EFM witch repeat it 8 times so in total 80 times they are decode between 4 and 7 times correct. The secondary receiver reports a period duration of 463us when it receives this signal correct. (period duration = 1/3 of a bit)

The codes:
387C01A4053C45D50F
3854019A055A45D530
387C017C054645D533
387C017C052845D53C
38A40172053C45D53F
The secondary receiver decodes them rock solid 15 time when send 10 times with ESPURNA to the EFM witch repeat it 8 times so in total 80 times. The secondary receiver reports a period duration of 464us when it receives this signal correct. (period duration = 1/3 of a bit)

from rf-bridge-efm8bb1.

Thank you for testing! Looks like PT226x is working. For the EV1527 I will need the original waveform. Best from the remote. These screens aren't complete above. The timing of Bit 0 and 1 is missing.

from rf-bridge-efm8bb1.

@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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.

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.

from rf-bridge-efm8bb1.

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.

from rf-bridge-efm8bb1.

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.

from rf-bridge-efm8bb1.

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

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.

from rf-bridge-efm8bb1.

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?

from rf-bridge-efm8bb1.

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

from rf-bridge-efm8bb1.