Missing sync on first transmit

[WoodsterDK]

Hi there,
Isn't the first sync bit missing on the first transmit, and then it comes as the last just before the retransmit...?

[fingolfin]

Hmm, indeed... The sync should be sent first, but it actually is only sent last. So we effectively loose one transmission. Thanks for the report!

Of course fixing this is trivial. But I am not in a position right now to test the change, so I am somewhat reluctant to make it right now (while it should be trivially harmless, I learned that hard way that "obvious" fixes can lead to non-obvious breakage).

If you made the relevant change, and can verify that it works, feel free to open a pull request. Else, I'll get to it eventually.

[WoodsterDK]

I actually haven't made the change yet - I just noticed something was wrong. To make it perfect shouldn't there be added a pause after each frame (I have seen that for the Anslut/Kaku protocol), between the retransmits?

[Martin-Laclaustra]

In my sockets (BAIHUAN, referred in the wiki as the ones sold in Spain, in Alcampo stores), the remote control does not send the sync pair of levels before the first data pair but after the last data pair. So the concatenated repeats start with a data bit and end with a sync bit. I could visualize this in the recorded received signal.
So, this proposed change might not be needed, as the original remote works this way. I wonder if remotes from other brands also behave like this and send the sync after the signal, to separate from the next repeat.
I observed the signal with ReceiveRF.py from
[http://www.instructables.com/id/Super-Simple-Raspberry-Pi-433MHz-Home-Automation/?ALLSTEPS]
Other users could report also if their remotes do the same.

[Martin-Laclaustra]

Searching a little further I found that, as I suspected, the SC5262 sends the codes with the sync bit after the address+data bits (12 tri-state bits).
See: [https://www.digchip.com/datasheets/parts/datasheet/433/SC5262.php]
Extract from page 4:

[sui77]

The codes need to be repeated at least 2-3 times anyways due to the simple ook transmission being fragile to interferences. This said it doesn't make a difference if the receiver counts the ending sync bit of the first iteration as the starting sync bit of the second one.

[sui77]

=> continue discussion in #86