Bang & Olufsen support

[danielwallner]

Supports both IR and Datalink '86 protocols
Has been tested with a Beo4 remote and a Beomaster 5500
The way repeats without gaps are handled could perhaps have been done in a cleaner way without the extra dummy message but I couldn't figure out another way that didn't require modifications to other parts of the library.

[ArminJo]

Thanks for the contribution, but there are some errors.

[danielwallner]

I apparently made a last minute error
BEOOlufsen should be BangOlufsen in two places
I have committed a fix for it

[ArminJo]

Thank you very much for the contribution. maybe I will make a few adaptions to it next.

[ArminJo]

Have you tested sending?
What is the reason of using a 32 bit header in
sendBangOlufsen(uint32_t aHeader, uint8_t aData, int8_t aHeaderBits, bool aDatalink, int_fast8_t aNumberOfRepeats)

[ArminJo]

Can you post the timings for one command as well as for one command followed by a repeat?

[danielwallner]

I have tested sending.
The pulses weren't completely even but it did work.
I have seen messages with 40 bits in total when the protocol is used between units (in wire OR mode, not IR), it's called datalink then.
So the 32 bit header/address is needed.
When receiving long messages extra is used too.

[ArminJo]

I have tested sending.

did you specify SEND_PWM_BY_TIMER for sending?
And what board did you use for testing send?

I have seen messages with 40 bits in total when the protocol is used between units (in wire OR mode, not IR), it's called datalink then.

So does it make sense to support 40 bits in an IR library?

When receiving long messages extra is used too.

When does this happen?

[danielwallner]

When a command is is repeated the next AGC part immediately follows the previous stop space and the normal stop mark is omitted.
I have successfully sent and received repeated volume commands.
The timing was close enough to work when individual commands where sent without using the repeat parameter and just setting the backToBack flag correctly.
I have to do it that way since I want to be able to correctly translate and mirror repeated commands from a different remote.
455kHz is perfect for that since you won't get an optical OR-gate with other systems if the receivers are good enough.

B&O commands are normally not repeated, only the buttons which you normally hold repeats, e.g. volume.

The start state needs to be inverted when the first bit is skipped. It currently works in the unit test but not with a real remote.
I have committed a fix for that on my fork.

[ArminJo]

I did some measurements, and the maximum PWM frequency at a 16 MHz UNO is 181 kHz.

[danielwallner]

I should measure what I got then. But I will not be able to do that for a few days.
I only noticed that the pulses weren't evenly spaced.
Maybe B&O receivers are wideband enough for it to still work.

It looks like the initial state is still off in sendBangOlufsenRawDataLink but I cannot test that right now.
But the reception from a real remote does work now.

[ArminJo]

Thank you very much for your quality assurance, I forgot to change sendBangOlufsenRawDataLink() too. 🥇
I fixed it now.
WhichArduino board do you use?

[danielwallner]

I have now tested IR send and datalink receive again, and measured the carrier frequency.
At about 100kHz It is indeed way lower than it should be, (I am using an UNO), and I see now that the range is quite limited.

Since it does work even over IR, I'm fairly certain it would work reliably if this signal was fed to the rear "Sensor" input though, which unlike most other extender inputs does take a modulated signal.
So I think it would be good if it was possible to force enable sending without modifying the code as it is now.