Brymen IR connection protocol - Anyone sniffed it yet?

[Simon Loell]

You're observations regarding the init pulse was correct.

It seems the 10 ms pulse comes first, then some data from the multimeter, and then the clock.

I will try to see if I can manage to get some communication answers on a Tiny2313. I even found my vintage STK500 board. It's a bit dusty but I think it will work:-)

Regarding RX and TX sides: When looking on the multimeter from the back side, the multimeter RX is on the left hand side.

On the picture I have my thumb closest to mutimeter RX and the propes in the background closest to multimeter TX.

[jadew]

Hmm, interesting, so I'm either not transmitting the pulse correctly (maybe not the right power or it's not the right angle) or I'm not receiving the data.

I'll try it with a hand held TX LED and will try to check the TX of the multimeter with my phone's camera, maybe it'll pick something up.

[jadew]

alright... I'm getting a response, it seems the issue is that my TX diode is not strong enough, the RX side seems to work fine from pretty much any angle, but for proper TX I need to hold the LED against the small window, right in the middle and at a perfect 90 degrees angle.

Would be really nice if that's all it took, a 10ms signal.

Edit: going to look for a remote to tare down

[Simon Loell]

I'm glad it worked out for you.

I managed to burn the IR TX LED on my original communication cable!
But I was lucky, it only took the LED. I'm back on track again.

Did you make a loop including the clock cycles?, or did you only register the RX pin going high (active)?

[jadew]

Sorry about your LED and I'm glad too it was only the LED.

I managed to get a response using the old TX led, simply by increasing the power (I lowered the resistance to 150 Ohm).

I'm about to make the clock tick. I'll let you know how it goes in about 10-20 minutes.

[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: [Select]

#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);
   
  }
}
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.

[microbug]

Has anyone else noticed this?

[jadew]

@microbug,

Yes, but it's the protocol for the cable, not the meter. It's also what confused me, because I was living under the impression that there's a more complicated handshake.

[rastro]

The cheapest MCU with USB that I know of is the PIC18F14K50.

Great detective work.  I'm looking to purchase a Brymen.  I'd rather build my own cable and also make it OSX compatible.
   
You may also consider the New Pro Micro ATmega32U4 5V 16MHz.  Selling on eBay for around $8.00US delivered.
http://www.ebay.com/itm/New-Pro-Micro-ATmega32U4-5V-16MHz-Replace-ATmega328-Arduino-Pro-Mini-/181177986498?pt=LH_DefaultDomain_0&hash=item2a2f0cadc2

[Simon Loell]

Not because I wan't to make this a religions war on PIC vs. AVR, but I too would prefer an AVR. Mostly because of my experience.
And the Pro Micro Arduino board you link to Rastro, looks very promising. It only needs a power stage (SOT23 N-FET) for driving the TX IR LED.

I won't be making a lot of measurements before monday, but this project has triggered somthing in me.

[jadew]

Yeah, I'd prefer an AVR as well. I guess we'll see, I'll do some tests tonight, after work, with V-USB and if the USB stuff takes less than 1ms to complete, it shouldn't interfere with our clock too much and we could do this with a tiny25, tiny2313.

As for the TX transistor, looks like it could do with out, but I guess it's better to have it in. It needs about 30mA (in my case), which is doable from one pin on the tiny2313.

[jadew]

@Simon

Any chance you can dump the HID descriptor of the original cable?

Edit: HID Report Descriptor.

[jadew]

Simon, thanks for the report descriptor!

 

Will post code and schematic in a bit.

Edit: I added the schematic and the code.

Now here's  the deal, I didn't use the original cable's VID and PID, because brymen owns them, this means the cable here won't work with the original software since it's looking for a different VID/PID pair.

Enjoy

Edit2:
Changed the schematic a bit.

[aurel]

As suggested before, you should really have a look at Brymen's protocol documentation. You can find the BM869 one inside the BM860-Bs86x windows software distribution from http://brymen.com/product-html/software-download/. It is indeed the documentation of the USB protocol of Brymen's official cable, but it seems to have only a very thin layer over the raw IR protocol.

In the documentation the transfer is described as one 27 bytes packets, but in fact, it is the concatenation of 3 USB HID interrupt transfer, each one composed of one HID report ID byte (always 0x00) and 8 actual payload bytes. So if you remove the HID report bytes, the actual packet is 24 bytes, the last 4 of which are always 0x00 in my experience (probably USB HID padding). So this leaves us with only 20 bytes of actual content, which is.... tadammm... 160 bits ! (does that ring a bell ?  )
Looking at the scope capture of the IR data, the encoding seems to match perfectly Brymen's documentation (without the HID report ID bytes), with each byte transferred LSB first. Each bit of the IR transfer represents one segment of the LCD.

So it seems Brymen's cable just packs the raw IR data into some standard USB HID interrupt transfer, without any other kind of transformation.

I hope this can help you support more features with your home made cable.

[jadew]

Hey,

Thanks for posting, but the cable is already complete since my last post

And you are correct, there's not much to it, it's just the data they describe in that document.

From the code I posted last time:

Code: [Select]

switch (read_step)
{
// Report 1
// First report consists of a blank byte + the first 7 bytes read
case 1:
outbuf[0] = 0;
memcpy(outbuf + 1, buff, 7);
break;

// Report 2
// Second one consists of the next 8 bytes read
case 2:
memcpy(outbuf, buff + 7, 8);
break;

// Report 3
// This one consists of only 0x86 in the 4th byte while the other ones are "Don't care"
case 3:
outbuf[3] = 0x86;
break;
}


[jancelot]

So, did anyone achieve a data-logging to the computer of the 869S using custom software and hardware? I would like to see the whole thing.

[Simon Loell]

Hi Jancelot.

The best chance is propably with Jadew. I haven't looked into the project since sniffing the protocol. And my primary whish is to be able to log both temperature channels, so my motivation isn't that high.
maybe next winther I'll be writing a Visual Studio program just for the practice.

-Simon

[bfishman]

This is digging up an old post, but I'm also curious if either of you gentlemen continued your efforts on this project?

[Simon Loell]

Hi bfishman.

I haven't worked further on the project.
All hardware issues are solved, so the only part missing is coding a program for a PC. I would sigges c# in Visual Studio, since it is a common language and Visual Studio is free.

-Simon

[jancelot]

Hi Simon Loell, is the complete documentation available on the internet or is just a work of yours?

[Simon Loell]

I haven't searched the internet, but all information should be available for you in this thread.

A short brush up:
Segment info:  #15   https://www.eevblog.com/forum/testgear/brymen-ir-connection-protocol-anyone-sniffed-it-yet/15/
Schematic info: #18 picture1 https://www.eevblog.com/forum/testgear/brymen-ir-connection-protocol-anyone-sniffed-it-yet/15/] [url]https://www.eevblog.com/forum/testgear/brymen-ir-connection-protocol-anyone-sniffed-it-yet/15/[/url]
Protocol info:  #34  https://www.eevblog.com/forum/testgear/brymen-ir-connection-protocol-anyone-sniffed-it-yet/30/

-Simon