Products > Test Equipment
Brymen IR connection protocol - Anyone sniffed it yet?
Simon Loell:
For your info, some respons will get back when making the clock tick. I can see the TX led on the multimeter blink with my mobile camera.
I'm building a foot for my LED TX and RX on some plastic at the moment.
Simon Loell:
And the proof!
I know the setup should be glued, and the phototransistor amplified, but at least now we know how to interface with the BM869.
The lower purple signal is the clock generated from below code on a ATtiny2313 and the IR LED is connected to a NPN547 with a 470ohm resistor to 10V.
--- Code: ---#include <avr/io.h>
#define F_CPU 8000000UL
#include <util/delay.h>
int main(void)
{
unsigned char x;
PORTD = 0;
DDRD = 1;
while (1)
{
//send init pulse on 10ms.
PORTD = 0;
_delay_ms(10);
PORTD = 1;
_delay_ms(125);
//send 160 clock cycles.
for (x=0; x<160; x++)
{
PORTD = 1;
_delay_us(75);
PORTD = 0;
_delay_us(75);
}
PORTD = 1;
//wait 20ms before next package.
_delay_ms(20);
}
}
--- End code ---
The upper blue signal is measured on the phototransistor, which means transmitted from BM869.
jadew:
Nice!
I pretty much did the same thing, but I'm not getting anything out..
Here's some screenshots and my code:
jadew:
GOT DATA!
I just had to move the Tx diode a bit, it seems it wasn't strong enough to carry the clock.
jadew:
Well, good job!
Now... this is what I think the protocol is:
1) The device sends a 10ms pulse.
2) It then waits until the meter sends something. I made my code time out after 600ms.
3) Once the meter has sent something, the clock starts. On my meter the time between the Tx signal and the first signal from the meter is only 60ms, as opposed to the 120ms you got on your measurements. My guess is that you have to wait for the meter to say something first, otherwise you might end up reading the LCD buffer in the middle of a change. I suspect the signal from the meter comes when the LCD buffer is in a stable state and can be read.
Reducing the delay between reads to 20ms, as you did, will yield the next signal from the meter at about 120ms, which makes sense, because it takes a while before the next LCD buffer is ready.
4) My guess is that it's setup on rising, sample on falling, where rising means active LED.
Let me know if this makes sense or if you have corrections or any other ideas.
Edit: Just did some clock stretching experiments and it looks like number 4 is right.
Edit 2: For the kicks, I also tried to read more than 160 bits, nothing else came out :)
Edit 3: I changed the code a bit and attached it in here. Most notably, I changed the pins because PD0 and PD1 are used for serial communication and this code will output what it reads over serial, at a 125000 baud rate. The 20 bytes are in hex, followed by \r\n.
Edit 4:
I updated the attachment. I changed the endiannes and negated the bits, since (because of my hardware) I was sampling them inverted.
I also included a header file which maps the bits in the first 15 bytes to the LCD segments. I don't know what the other 5 bytes mean, but 4 of them seem to always be 0x86, while the other one seems to always be 0.
Practically, at this point we can build our own cables and build software for them that understands the data, however for the cable to be compatible with the original software, we'll need a USB enabled chip. I don't know if V-USB is a viable option here because I'm not sure if we can meet the timing requirements of both USB and the meter. In my clock stretching experiments, I didn't have much success in stretching the clock too much over 2ms / cycle. I'm happy with this solution anyway, but I'll look into giving it USB support too, over the weekend. The cheapest MCU with USB that I know of is the PIC18F14K50.
I also attached two screenshots that give away the meaning of the first signal from the meter and the setup/sampling edges. It all becomes obvious when the clock is stretched to 1ms/cycle.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version