ARCHIVED FORUM -- March 2012 to February 2022READ ONLY FORUM
This is the second Archived Forum which was active between 1st March 2012 and 23rd February 2022
Hi,
So I followed Johans recommendation and just started with an Arduino and some beginners lessons, like blinking LEDs and thermometers with display etc. This to learn how to write code and basic wiring. To the Scandinavian members I can highly recommend www.lawicel.se they sell the things but also run a blog with an Arduino school with really good lessons, that in addition to code also touch on topics like basic electronics. So now I’m totally in to this stuff
Next I started with the IR part of the actual project I want to build, and rather soon run in to problems
From an old LX2802 I have taken the IR receiver, and on the Arduino I tried to get commands both with a library that supports Beo commands and with a code that work with raw IR communication. Not much luck with either, only managed to get two signs of life in receiving raw code right after connecting power to the receiver, not sure if this was actual commands or just errors (IR seems to be quite sensitive stuff)
I tried to check that the receiver works at all with a LED and it does glow (pulse) faintly when a bottom on Beo4 is pressed. But with a standard integrated 38kHz receiver connected to the LED it glows constantly and “pulses” when a command is sent. So I started looking through the PCB diagram again, also checking the main PCB of the TV, and there are actually a couple of resistors and a transistor on the signal path also on this PCB before it enters the IC. So I started thinking that it might be that signal I actually want to use as input on the Arduino. Or is it even more missing (is demodulation really done on IC3 on mainboard?) If anyone can help out here, it’s much appreciated?
The Beo command library for Arduino is said to work with the hockey puck receiver from beolink active. But I have a hard time comparing the PCB of that and the LX receiver, if someone can help by looking at these two that’s also a possible way forward.
IR PCB of LX2802:
Main PCB of LX2802 where #138 enters:
Beolink IR receiver for comparison:
Thanks in advance
According to the schematic you posted, the LX IR receiver board doesn't have a demodulator. Instead, it is outputting the raw 455 kHz pulse train, modulated by the actual IR command bits. The hockey puck receiver on the other hand outputs only the IR command bits (you can think of this as the difference between an antenna amplifier that outputs a radio signal and an actual tuner that outputs audio, if that sounds more familiar to you).
Apparently the demodulation is done by the processor (IC3 above) further down the line in the LX. I believe you could do that with the Arduino as well (it is much faster than the old microcontroller in the LX), but the ready made libraries won't help you there, they all expect the baseband IR pulse train. What you need is a TSOP7000 receiver chip which is an integrated receiver for the 455 kHz carrier frequency, or the full-fledged B&O receiver/transceiver.
--mika
Hmm, even worse then...
but the TSOP7000 and TSOP5700 are both discontinued since long. and even if there are some selling it I would only buy it is someone could recommend from where.
so it will not help me adding the 4resistors and transistor in the signal path
makes me wonder... I read about someone who used a IR from a Beovision 8802 as input to a lintronic box, and connected it where the hockey puck beolink IR receiver normally goes... maybe the older BVs had the demodulation on the same PCB
I put in small orders from these ebay sellers, no problems at all. All delivered fine within reasonable time:
http://www.ebay.com/itm/VISHAY-TSOP7000-DIP-3-IR-Emitting-Diode-Power-/221241394076?pt=Bauteile&hash=item338303c39c
http://www.ebay.com/itm/TSOP7000-Manu-VISHAY-Encapsulation-DIP-3-IR-Emitting-Diode-Power-/370729982030?pt=LH_DefaultDomain_0&hash=item56513a984e
http://www.ebay.com/itm/VISHAY-TSOP7000-DIP-3-IR-Emitting-Diode-Power-/360673202793?pt=LH_DefaultDomain_0&hash=item53f9cc5269
BeoLignage: makes me wonder... I read about someone who used a IR from a Beovision 8802 as input to a lintronic box, and connected it where the hockey puck beolink IR receiver normally goes... maybe the older BVs had the demodulation on the same PCB
Some of them probably did, yes. As somebody (Johan?) said in the other thread, these B&O receivers that are constructed from discrete components are a lot more sensitive than the TSOP7000, and we're all used to the comfort of not caring where the remote is pointing at. The LX front-end would therefore be well worth using if the demodulation could be solved. The AVR processor on the Arduino would be plenty fast to do it in software, but probably not fast enough to do this using interrupts like the regular library does; it would need some skilled low level programming.
EDIT: I believe 8802 used the old Mars bar remote controller - it is completely different from Beolink 1000 and uses 30-50 kHz carrier as far as I know.
I've bought from here http://darisus.de/.
Right, these units are great for tinkering and figuring stuff out, but I use MCL2 transceivers instead in the final "product". Better reception and a nice looking package.. and they are not that expensive considering that people sell MCL2As for a couple of hundred SEK.
The signal from the transceiver is more or less the same as the demodulated IR signal, so using a TSOP7000 for development is fine.
As Mika says, demodulation is certainly possible on the Arduino, but you wouldn't have time to do much more. Interrupts are too slow, and delay takes too long. What you would have to do is just loop and read the state of the pin as fast as possible and track the changes in state. I don't recommend it.
Get a TSOP for development and an MCL2 transceiver (or puck) for your "product".
/ Johan
The circuit diagram of the LX2802 IR Module shows a simple but complete strait AM receiver for a fixed frequency of 455 KHz
At the left the input filter, then in the middle another filter with an amplifying stage and between the last two transistors the received high frequency signal is rectified and low pass filtered before the last transistor makes a nicer and stronger signal. There's also a feedback to manipulate the gain of the 'HF' amplifier (an AGC function)
So the module should work with the Arduino program if the module itself is working correct. It might be defect.
An alternative is the Videosensor for the VX5x00 VCR recorder or an MCL2 sensor. Both have the great sensitivity for Infrared signals like the 'puck'.
But as stated before a TSOP7000 or TSOP5700 (the SMD version of the former) might work for testing at the workspace but for the final 'product' a real B&O reciever is worth of it.
Ralph-Marcus
RaMaBo:At the left the input filter, then in the middle another filter with an amplifying stage and between the last two transistors the received high frequency signal is rectified and low pass filtered before the last transistor makes a nicer and stronger signal. There's also a feedback to manipulate the gain of the 'HF' amplifier (an AGC function)
You are, of course correct - forget my earlier talk about the missing modulator...
Then, perhaps only the signal polarity is reversed to what the Arduino library expects from an integrated receiver?
I think you may be right, Mika. Counting the inverting amplifiers in the circuit it seems that last transistor right before the input is necessary to make it active low (which I think it should be).
Again, correct me if I'm wrong.
Hi, I was reading everything from the top and was thinking that I should thank you for your answer and, believe it or not, say that I was naive to think that the discrete components on the PCB diagram of the LX IR represented the same as the nice boxes on the PCB diagram of the Puck. That was what I was hoping for all the time....
but then I got to this post
tournedos: RaMaBo:At the left the input filter, then in the middle another filter with an amplifying stage and between the last two transistors the received high frequency signal is rectified and low pass filtered before the last transistor makes a nicer and stronger signal. There's also a feedback to manipulate the gain of the 'HF' amplifier (an AGC function) You are, of course correct - forget my earlier talk about the missing modulator... Then, perhaps only the signal polarity is reversed to what the Arduino library expects from an integrated receiver?
and voalà, I might be on track again! spent the last hour surfing auction sites for a MCL 2a or PC kit or x-tra speaker kit with receiver. and now I might not need it.
I would assume (or hope, that is) that the last components in the main PCB are as you say to change polarity,( and amplify(?)). So I will order those and some new 38kHz IR leds as well.
In the meanwhile I have built the project as intended with RF tranmitter and 38kHz IR tranmitter but instead of a beo receiver i put in a 38kHz on the receiving end as well. Only made a really simpel program so far, since thats where I have a steep learning curve.
So a big thanks to all, impressive that we have so knowledgeable people on the forum, in so many areas.
I think your right Johan, and yes, the program expects an active low signal, while I currently seem to get active high from the receiver.
as I wrote, it makes a LED puls when I hit a button on Beo4, while the 38kHz TSOP makes the same LED light at standby and puls when a button is hit on a standard remote.
If the problem is polarity, you don't actually need any components to reverse it, the interrupt input in the AVR can be programmed to trigger either on the falling edge or the rising edge of the signal.
This
BeoLignage:as I wrote, it makes a LED puls when I hit a button on Beo4, while the 38kHz TSOP makes the same LED light at standby and puls when a button is hit on a standard remote.
... really suggests that it is the other way round with the LX receiver, but I'm not sure if it would matter if you are trying to record a raw IR command (I re-read this thread as well, and realized that there actually is no ready made library for receiving the B&O remote protocol).
Anyway, if you get a definite response of some kind to pressing the remote buttons, I believe it's just back to the drawing board... with no soldering iron required
Of course you right, Mika, but I think the last transistor is also there to give a nice 0-5V signal.
Johan:Of course you right, Mika, but I think the last transistor is also there to give a nice 0-5V signal.
Yeah - what I meant was that there's no need to add another one to invert it again
Hi again, and thanks for your advice so far.
A general question to the diagrams and part lists in the B&O service manuals. Diods, caps and transistors are all listed in the part lists, but only some resistors are. The ones listed have info like max power and tolerance e.g 220k 1/4W 5%... but for the ones not listed, what type should be used in terms of tol. and power? R value is on the diagram itself.
//Goran
When the power rating, tolerance and stuff like that isn't mentioned, it usually means either "doesn't matter" or that the particular service manual has a "catch-all" specification somewhere. If not, you can use whatever was typical back then. For '60s-'70s vintage kit, it is usually 0.5W / 10% (if they used carbon resistors), later often 0.25W / 5% metal film will be enough.
victory!
so long story short it works!!!
long story: with the last parts in the signal path (transistor and 4 resistors) the code for receiving raw code kind of works, but since it is designed for 38kHz all commands are the same, whatever button I press.
tournedos: (I re-read this thread as well, and realized that there actually is no ready made library for receiving the B&O remote protocol).
(I re-read this thread as well, and realized that there actually is no ready made library for receiving the B&O remote protocol).
but there is Mika https://github.com/christianlykke9/Beomote library for beo comands. however it did not work right away, even with the last resistor changing polarity of the signal. So I did a small mod (without knowing exactly what I did, changing some cycle length) and now it works. What makes it interesting is that I now tried to connect the LX IR receiver directly and it works as well . So the beo library is prepared for both active low and active high signals. And if the last resistor is amplifying, it is insignificant in this case.
so with that said, all electronic parts work, i.e. 455kHz and 38kHz IR receivers as well as IR and 433MHz RF transmitters. only programming left
first successful program is now ready, controlling 5€ socket switches with LIGHT commands from the Beo4 over RF
tournedos: When the power rating, tolerance and stuff like that isn't mentioned, it usually means either "doesn't matter" or that the particular service manual has a "catch-all" specification somewhere. If not, you can use whatever was typical back then. For '60s-'70s vintage kit, it is usually 0.5W / 10% (if they used carbon resistors), later often 0.25W / 5% metal film will be enough.
Thanks!
I ordered some of both metal film and carbon before I asked the question.
the carbons are 1W / 5% and turned out to be really big and since you point out that 0,25W will in most cases be enough I don't need to worry with the metal films having too low power rating, spec at 0,6W / 1%
BeoLignage:So the beo library is prepared for both active low and active high signals.
Oh, I wasn't aware of that library. It seems to be implemented with remarkably little code. I didn't think this through, but it may be that the B&O command frame bit encoding is such that the polarity doesn't actually matter for the receiver, if it takes some shortcuts and doesn't care about complete start bit patterns, or something.
Anyway, well done so far! Keep us posted
BeoLignage: but there is Mika https://github.com/christianlykke9/Beomote library for beo comands. however it did not work right away, even with the last resistor changing polarity of the signal. So I did a small mod (without knowing exactly what I did, changing some cycle length) and now it works.
but there is Mika https://github.com/christianlykke9/Beomote library for beo comands. however it did not work right away, even with the last resistor changing polarity of the signal. So I did a small mod (without knowing exactly what I did, changing some cycle length) and now it works.
The way it's done in the lib the timer is dependent on the actual clock speed of the CPU (not the most rigid solution perhaps) so changing that to work with your particular clock speed makes sense. Well done.
tournedos: BeoLignage:So the beo library is prepared for both active low and active high signals. Oh, I wasn't aware of that library. It seems to be implemented with remarkably little code. I didn't think this through, but it may be that the B&O command frame bit encoding is such that the polarity doesn't actually matter for the receiver, if it takes some shortcuts and doesn't care about complete start bit patterns, or something. Anyway, well done so far! Keep us posted
Well, the implementation isn't the most robust, and doesn't really handle errors. Also, two-way communication would probably confuse the hell out of it, as that is not considered at all. Anyway, it should work reasonably well as long as you don't push it to do things it can't.
Johan: Göran, how are you testing that it's working? / Johan
Göran, how are you testing that it's working?
It’s actually Goran, but I see why you guessed with dots on the o = ö
Well I consider it as working since I get the right codes on the serial monitor when pressing different buttons. In addition I wrote a small program (sketch on arduino language (see below)) which checks for incoming signals and then compare them to the codes in the commands.h file, e.g if 7 is pressed in Light mode a “light #1 on” signal is sent to the 433MHz transmitter and if the 4 on beo4 is pressed in same mode the same lamp is turned off. And this works. So I haven’t stress tested the code (wouldn’t know how to either) but it seems to me that it works, so far every press on one button gives the same code, and no code is received as from noise.
Still a bit confused as to what the tick really is, I changed from 625 to 125 but 200 works as well. I would expect it to be more sensitive to changes if this is actually the counter that interprets the signal. Will read this http://www.instructables.com/id/Arduino-Timer-Interrupts/step2/Structuring-Timer-Interrupts/ as soon as I press post.
What would you suggest as an alternative to this way of reading IR code, and what is the risk with this non robust way of doing it. Do I risk getting wrong codes or missing incoming or getting false signals…
The code:
#include <Beomote.h>
#include <rf433.h>
int irPin = 10;
int clickCount = 0;
bool serialOut = true;
void setup() {
Serial.begin(9600);
Beo.initialize(irPin);
set_out_pin(2); // Set pin RF sender is connected to.
}
void loop() {
BeoCommand cmd;
if (Beo.receive(cmd)) {
//Serial.print(cmd.link, HEX);
//Serial.print(cmd.address, HEX);
//Serial.println(cmd.command, HEX);
if (cmd.address == 0x1B && cmd.command == 0x07){
int light_id = 1;
int on = 1;
for(int i=0; i < 4; i++) {
send(switches[light_id], on ? ON : OFF);
delay(80);
else if (cmd.address == 0x1B && cmd.command == 0x04){
int on = 0;
BeoLignage: It’s actually Goran, but I see why you guessed with dots on the o = ö
BeoLignage: Well I consider it as working since I get the right codes on the serial monitor when pressing different buttons. In addition I wrote a small program (sketch on arduino language (see below)) which checks for incoming signals and then compare them to the codes in the commands.h file, e.g if 7 is pressed in Light mode a “light #1 on” signal is sent to the 433MHz transmitter and if the 4 on beo4 is pressed in same mode the same lamp is turned off. And this works. So I haven’t stress tested the code (wouldn’t know how to either) but it seems to me that it works, so far every press on one button gives the same code, and no code is received as from noise.
Ok. Sounds sane.
BeoLignage: Still a bit confused as to what the tick really is, I changed from 625 to 125 but 200 works as well. I would expect it to be more sensitive to changes if this is actually the counter that interprets the signal. Will read this http://www.instructables.com/id/Arduino-Timer-Interrupts/step2/Structuring-Timer-Interrupts/ as soon as I press post.
The lib works by polling the pin at a regular interval. As you surely have figured out the interval is dependent on the expression (F_CPU / 2000000) * TICK. F_CPU is the clock speed of the uC. This is why you had to change the value of TICK (because your clock is different than the lib implementer's). Clearly not a very portable implementation, especially since it doesn't even say what (F_CPU / 2000000) is expected to evaluate to. Anyway, if you have it working you're probably fine. I think as long as you're polling often enough it should work.
BeoLignage: What would you suggest as an alternative to this way of reading IR code, and what is the risk with this non robust way of doing it. Do I risk getting wrong codes or missing incoming or getting false signals…
Johan:I would use interrupts to trigger upon the pin going low and then keep track of the time between the interrupts.. That way you don't have to poll all the time and waste energy.
Exactly. But if it works now, do not worry - similarly for the error robustness, if the application is just there to receive button presses by a human, you can just press again if it doesn't go through. The library only seems to be prepared for 17 bit commands which is fine for the basic Beolink 1000 commands, but it won't work for example V.TAPE2 commands or LINK commands, which are longer.
I use interrupts in my own applications. With a bit of trickery, the resolution of the millis() system call is enough to keep track of the pulse intervals (which are 1 to 5 multiples of 3.125 milliseconds), which nicely allows you to not care about the actual CPU clock frequency. The interrupt routine stores the received pulse intervals into a circular buffer and also looks for a stop condition; when received, it sets a global flag so that the main program knows that there's (potentially) a command frame in the buffer. The actual pulse intervals are then decoded by the main program, outside of the interrupt routine.
So this tinkering project was put on hold (for some years :) )
But some time ago I brought it up again and continued the evolution as well. So, since I got so much help here on the forum, I thought I give you some pictures and write some lines on what I did.
Where I left it in 2014, I had a scope including controlling both RF and non-B&O stuff via IR. In the end the IR sending part was from a HW perspective trickier than what I could manage and the Beo IR at 455khz disturbed the ~38khz signal which I never got strong enough. I ended up buying a Lintronic box to fit the need in that room and left the Arduino to rest in a drawer.
Later on, I saw the potential to make a really simple IR to RF converter and got to it again.
Now I skipped the large proprietary B&O receiver and went for a TSOP7000 and also started looking in to using just the Atmega IC instead of an Arduino uno, but still with the Arduino bootloader on it. So now I can control Telldus and Nexa wall socket switches with the Light command on Beo4 and Beolink1000! And that by a pretty little box only 3x5cm in footprint.
This is very cool. Did you use a library for the ir decoding or did you code it from the ground up?
Hi CheapB,
I only did the high level coding on my own. I used the below librarys for decoding the IR codes.
https://github.com/christianlykke9/Beomote
the 433MHz library for the wall sockets is no longer available but many more exist, so should not be a problem finding one that works with your switches.
I also ended up making a custom box for it :)