djmp wrote:

I’ve noticed that IR reliability goes way down if I use in a room with a plasma screen. That produces a ton of IR interference so I think the timing code is getting thrown off and misdecoding the pulse sequence. I’ve seen it go into debug reporting too which meant that it got a bit lost. Haven’t had time to dig further and I don’t have a scope.

"(...) When mounting the IR receiver in a setup
with a plasma screen, make sure to place the
receiver on the same wall as the screen. If the
IR receiver is placed incorrectly, the light
emitted by the screen can impede remote
control operation of BeoSystem 1! (...)"

There are indeed versions of the IR eye with plasma filter layer. I read this in the IR eye overview that you can find with a google search.

Hi,

I hope you don't mind me asking a question about your posts, I found an old thread that had some other information in I've found useful/interesting reading. https://archivedarchivedforum2.beoworld.org/forums/t/30181.aspx

I think I'm trying to achieve something similar to your project and was wondering if you could point me in the right direction.

I basically want to listen in on the data line of a datalink cable via a raspberry pi and then trigger a command in linux. So essentially if someone pressed an arrow key on a beo4 remote say 'the up key' the pi realised that and then posted in linux 'the up key has been pressed'.

I've experimented with the Pi and LIRC and whilst I can get it to monitor and hear commands on the databus I can't get it to understand what those commands are or do anything with them.

Would you be able to perhaps enlighten me? I feel really stupid for not being able to get over this hurdle.

Thanks,!

I haven't read through the full description of the data link info, but one line said it follows the same structure as the IR codes.

To handle something like IR or the databus, you need to be doing real-time processing of the signal - while that is probably possible with a Pi, its a lot easier with an arduino as you are working at much lower level - essentially a big loop, and its happy doing that uninterrupted 24x7. So I'd suggest using an Arduino for handling the bus interface, and then provide a higher level view of the data to the RPi. The great thing about the combo, is most Arduino have a USB port for serial comms, and that will connect directly to the USB on the RPI - and be mapped to an I/O file on the RPI as something like /dev/USBSerial01, and the RPI will supply power via USB.

If you look at the Arduino code, Bemote.cpp, this is what is doing the hard work. It maps the remote input to an interrupt pin, and creates a timer. When the timer ticks, an function is called which increments a counter for the number of ticks. When a pulse from the remote is detected, the interrupt occurs, it collects the timer info, and maps that into the command structure. Once the command is complete, it gets written out over USB.

You may or may not have the same timing thing to do, but I'd suggest using an interrupt pin on the arduino to collect the data, and then send it to the RPI will be simplest. Given you can get a handful of arduino nano for $20, and the nano is ~20x43mm, its small enough to fit almost anywhere, such as acting as a dongle on a cable.