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.

[Portisch]

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.

[AlbertWeterings]

@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

[ErikAndren]

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

[AlbertWeterings]

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

[ErikAndren]

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

[Portisch]

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

[AlbertWeterings]

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.

[AlbertWeterings]

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

[Portisch]

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

[AlbertWeterings]

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.

[Portisch]

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

[AlbertWeterings]

@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

[AlbertWeterings]

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

[AlbertWeterings]

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

[Portisch]

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

[mcspr]

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

[Portisch]

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

[AlbertWeterings]

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

[Portisch]

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

[mcspr]

@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, https://github.com/Portisch/RF-Bridge-EFM8BB1/issues/2#issuecomment-371779478

[AlbertWeterings]

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

[Portisch]

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!