Welcome! Log In Create A New Profile



Posted by swinfen 
December 16, 2013 07:28PM
Hi there,

Anyone used this device? I've hooked it up to a PIC16 via I2C. I can retrieve the firmware '1a' and the IR code, but the 'high' byte that contains the important 'valid' bit seems to always be 0x1b 'esc'. I wonder if there is a firmware issue? Any ideas welcome!


Re: BV4615
December 17, 2013 09:35AM
The data sheet is very poor in its explanation of the way read is used for I2C the implication being that a command should precede it but this is not the case.

The way to read this device on I2C is exactly as follows:
send start condition
send 0x25 // read address
read 2 bytes
send stop condition
Of course some systems may wrap this up into two or even a single command. The first byte is the status bit and the second byte is the key value.
Re: BV4615
December 17, 2013 11:34AM
Thanks Jim. I guess I'm to infer that sending a command (what does <esc>[k do anyway?!) will overwrite the high byte that would otherwise have held the status bit from the IR read? Will try it later. I guess in this case one should ignore any code with 0x1b in the high byte!

This module would be much more useful if it decoded other protocol standards, such as NEC! I think I'll just write a decoder algorithm and hook up the IR receiver direct to my µC instead. Was trying to avoid as it will put an increased burden on the µC which is already managing synchronous and asynchronous I/O with other devices.

On off the chance - could I have the source and is the module reprogrammable?


Re: BV4615
December 17, 2013 12:36PM
I am not sure what you are talking about with esc[k? No esc commands are needed.

To read the device you simple read 2 bytes and that will give you a status and a key byte. e.g

status = i2c_readbyte()
data = i2c_readbyte()

As you say this device considerably frees up any resources required to monitor, decode and present the IR signal, at least one interrupt and timer would be needed.

Sorry the source code is not for sale.

Re: BV4615
December 17, 2013 03:04PM
Hi Jim,

I was referring to the documentation which is what appears confusing as the following 'write' command appears just before the description on reading the IR code. According to the documentation: "Reading is slightly different in that, first a command is given as in the writing mode and then a read is performed using the device read address (0x25 in 8 bit addressing)", so I assumed this was the command that should be 'written' before reading the IR code:

0x24>s 1b 5b 6b r g-2 p

So once you clarified that no write command was required, I was wondering what this write command in fact does (it is not listed in the command table) and whether it had an effect on that stored IR data requested with the read command to obtain the code. I think it is fair to assume it does and the data read from the module's buffer after executing the above command will now contain '0x1b' and perhaps the 'left over' IR code in the second byte.

Anyway thanks for the response.


Sorry, only registered users may post in this forum.

Click here to login