Brymen IR connection protocol - Anyone sniffed it yet?

[onmobile]

Hello,

Has anyone sniffed the brymen 867 or 869 IR connection? It would be good to know what's going on in there, how the handshake looks like, how data gets transmitted, baudrate, etc.

I guess a simple sniffing session for one data acquisition from the DMM, would be enough to get the rest of us started in making our own connection cables.

[Slothie]

I recently bought a Brymen 257 Multimeter and that has an IR port. I read on here somewhere that the software for the IR cable has PDF's with it that detail the protocol for all models. This software is downloadable from Brymen's website as a windows installer. I have downloaded it but not yet used it because I dont have a working windows PC (all Linux...) at the moment but I'm going to set up a VM and see if I can extract the files.
Somewhere on the forum (sorry I looked for it but couldnt find it again) someone posted the PDF for the '867 and I recall it looked like the port just outputs a bitstream that indicates if the segments of the display are on or off.

[jadew]

Indeed, they do publish the protocol, but it's the protocol between the PC and the cable, which then makes the request to the DMM trough IR.

What they're not saying in there is how they are forwarding the data: How is the IR signal modulated? What baudrate? And what is the cable sending before the user bytes - I suspect it might send out some unknown bytes, for framing and for keeping the protocol closed.

If someone who already owns a cable, could capture the IR stream, from the cable to the device, I would greatly appreciate it. (oscilloscope capture or logic analyzer, anything would do)

Currently I'm trying to initialize it based on the mentioned PDFs, however lots of variables are a mystery.

I got the protocol docs from the brymen software zip, located at: http://brymen.com/product-html/software-download/BM860-Bs86x-V6002s-use-BC86X-Win7.zip

BU-86x being the cable for the BM867 and BM869.

I also found this:
http://g-tech.no-ip.org/~mrnuke/brymen_protocols/500000-count%20DMMs%20protocol-r1.pdf

Which seems to be similar to http://sigrok.org/wiki/Device_cables#Brymen_BC-85Xa which was used by Extech. From the last PDF I linked, it looks like brymen changed something to the cable/protocol between BR85X and BC-85Xa - what exactly was that, I don't know, but it could be anything from the IR baudrate to just a few frame bytes or something silly. The change might have been propagated to BU-86x too, but again, just a guess.

What's clear is that they like to change stuff, apparently just to make them incompatible, in order to get you to spend another $60 on a cable which can be made with $4 parts.

What I did notice by checking their PDFs for other products is that they usually use a 9600 baudrate for the serial connection, which makes me think they might use the same baudrate for the IR communication - just a guess tho.

Anyway, if someone is willing to capture some traffic from the cable, I'd appreciate it and I promise to share whatever results I get.

[madshaman]

I've got a BM867 with the BU-86x kit.  I can't guarantee I'll ever get around to it, but if I find any extra time I could give it a go.

[jadew]

I've got a BM867 with the BU-86x kit.  I can't guarantee I'll ever get around to it, but if I find any extra time I could give it a go.

That would nice. I managed to get some sort of response from the meter last night, but it wasn't what I was hoping for so I started blasting it with consecutive numbers + the specified 4 bytes (00 00 86 66), however I stopped, because I realized that if I keep sending Junk I might overwrite calibration data or something. Hopefully I did not do that, I guess I'll know for sure once I take a look at how real data looks like.

Thanks for offering.

[Slothie]

I don't know about the 86x series but the cable for the 25x series is available in rs232 or USB and looks to me like the USB adapter is just a rs232- USB adapter. I've leant my meter to a friend but when I get it back I'll hook up a IR receiver to my scope and look at what the output looks like. At least the 25x doesn't have a reciever so I've only half the problem!!

I wondered why there where two kinds of adapter for Brymen meters perhaps the slot type on the 25x is transmit only and the round  ish one is bidirectional .

[jadew]

I wondered why there where two kinds of adapter for Brymen meters perhaps the slot type on the 25x is transmit only and the round  ish one is bidirectional .

Yeah, I can confirm that the 86x one is bidirectional. You're also right about the USB-2-SERIAL cable, it's just that.

I also think the fact that the new cable (the 86x) is registering as a HID device is because they're using a cheap chip, with no native USB support, so they're only able to bit-bang USB. That means low speed USB and you can't register as a CDC device with that. That's just a guess, but I don't see why else they wouldn't want to provide a virtual COM port.

[jadew]

Anyone still willing/able to help?

Thanks

[madshaman]

Still willing.  Life's gotten in the way of recent.  I'll have time beginning of June ^^'

[sado1]

I wrote simple Python program for Linux for plotting and logging Brymen 257 output:
https://github.com/sadol/brylog.

[macboy]

I can't speak to the Brymen specifically, but I have a handheld meter with an IR serial interface, a B&K 5360 (aka Metrix mx56c). There is no special modulation or data format, the data on IR is just vanilla UART style serial, no additional carrier (like a TV remote control) or anything. I used a USB-TLL serial converter (PL2303 based), with a IR diode and current-limit resistor for Tx, and a phototransistor and pull-up resistor for the Rx. Very simple. Sometimes the simplest answer is the one.

[pradipkhare]

I recently bought the Brymen BM869 along with the s/w and interface USB cable pack.

Supplied s/w on the CD was not getting installed on my Windows-8 Laptop due to the version issue. I downloaded the Win-7 version (that is the recent they have) from the Brymen's website. It got installed and working fine now.

For installing USB interface driver, I needn't require to install it separately, as when I plugged the usb cable in, Windows automatically detected and installed the driver and protocol from the already inserted CD.

I am using it successfully and baud-rate is enough for all types of logging. It also shows a nice wave form. You can log data for all the parameters that can be measured using this multimeter. I also used export-to-CSV file feature successfully and were able to do additional analysis using the Excel.

It is working fine and has an excellent accuracy. I love this multimeter and recommend to everybody looking for an advance DMM.


Dave,
Thank you very much for doing the review of this meter, as from there only I got to know about Brymen and bought this.

Regards,

[Simon Loell]

@Jadew / others.
Did anyone start monitoring this IR protocol?

I have both the BM869 and the USB/IR interface.

I don't know much about USB communications, but the IR part should be a bit more simple to sniff.

What is your main purpose of knowing the protocol?

If it's making a new PC interface for it, it would be GREAT! I use my multimeter for logging temperature a lot. It has 2 temp inputs, but in the PC interface only T1 is displayed. A huge bug in my opinion.

-Simon

[jadew]

I tried sniffing the protocol, but not knowing the handshake doesn't get you anywhere, because the meter won't start transmitting, even if it's plain UART

@Simon, yes I'd like to make an IR interface, since I'm too cheap to buy an original one which honestly... it's super expensive for what it is.

As for the USB communication, I wouldn't worry about that too much at this point. The first step is to establish serial communication with the meter, in order to get some usable data out. The HID device should be fairly easy to implement.

[Simon Loell]

Well I hooked my oscilloscope into the Rx and Tx diodes, and my findings are not so obvious I think.
It seems that the data is not UART protocol, but Brymens own. Maybe some direct indication of what segments are active in the display.
In my attached pictures it can be seen that a "1" is represented by two LOW bits, where as a "8" has a hole bunch.

Another strange thing is that the Rx and Tx diodes measure the exact same, and no I did not short circuit anything...

Last but not least. The packages are sent with a speed of approx 5Hz, which is even faster than the PC User Interface can update. It would be very nice with a UI with faster update speed.

I hope you can find some logic in my pictures. Since I have the setup, I'm not that eager to spend a lot of time on this projects. But if you need a reading or two to figure out the puzzle I can give it a try. As long as you're the brain in this backwards engineering

[jadew]

Awesome!

Thanks a lot for the screenshots!

Indeed, I think it represents which segments are ON or OFF and yeah, doesn't seem like UART because I can't spot any stop or start bits.

Also, it's probably safe to assume that the spot where you wrote the values is actually the last digit, which is turned off, hence the HIGH value for all the segments.

I think the bit meaning is this (MSB first):
  4
5   0
  1
6   2
  3
   7

So bit 7 is the dot, 4 - the top segment, 0 - top right, 1 - middle, etc.


I think what we need to know now is what gets transmitted when you first plug the device in or when you start reading data, because there has to be a trigger string that starts all this up. So if you still have everything set up, it would be great to see what's going on at that time.

I don't know why the TX diode reflects whatever is on RX, maybe it's just a way of saying we got the bit right, go on. I guess I can experiment with that once I get communication going. This would explain the weird baud rate as well, meaning that it's not given by any clock, but by how fast the devices respond to each other.

Thanks again.

PS: Love that scope of yours.

[Simon Loell]

I just took the IR thing apart again. Maybe I have to measure some where else on the phototransistor.

I will do the measurements tomorrow (it's 1a.m. local time).

[jadew]

Cool, I'll set up a test environment by tomorrow.

Cheers!

[Simon Loell]

Happy news.
I've got it hooked up right this time. After have tried to ohm the tracks on the PCB, it lead me into 3 pinheader holes marked with silkscreen "T", "R", "G"..... Guess what Einstein

Anyway. It makes a bit more sense now.
The PC transmits clock at a given frequency. Exactly 160 clock cycles.
The multimeter sends data back in sync with the clock.

Before the clock starts, a initialization pulse is given on 10ms.

See if the data makes sense or if I have to make more measurements.

[jadew]

Nice!

I find it a bit weird tho that the clock signal is behind the data, in the close up you can tell that RX went high before TX went down.

Kinda makes you wonder which edge is the setup edge and which one is the sampling edge, or... what's really the deal in there.

I'll send that initial 10ms pulse first and see if I get anything in response.

Edit: I'll get to it in about 20 minutes. I'm still working for my day job right now.

[jadew]

Alright, I just gave it a try, I sent the 10ms pulse, but to no avail.

Are you sure there's no other data sent from the device to the meter when communication starts? Like... when you start the software that controls it?

Edit:
I guess a good test would be to leave the device disconnected from the meter and see what happens, it should try to sync with the meter.

[Simon Loell]

I will try to measure the TX line without the multimeter connected tonight. (In 10 hours from now).

Did you send the 10ms pulse wait for about 120ms, and then start sending 160 clock cycles?

I would imagine the communication is like SPI, but without MOSI (Master Out Slave In) and CS (Chip Select). Where the PC is the master giving the CLK (syncronous Clock) and the multimeter sending data in sync on MISO (Master In Slave Out).

What platform are you testing via?

I could hook up an AVR on both a STK600 board or just use a simple Arduino Uno to generate the clock cycles, read back from multimeter, pack the 160 bits into 20 bytes and send to a PC over the UART.

[jadew]

Hey, I did not send the clock, because from the last screenshots, it looks like the meter does something first and only then the clock starts rolling.

I think that after the meter is initialized, things happen like this:
Tx: 10 ms pulse
Rx: goes high
Tx: starts rolling the clock

This is visible in the picture called "BM869 link startup close-up on beginnning on first data packet".

From that picture we can also conclude that the falling edge of the clock is the setup edge and the rising one the sample edge. You can pretty much tell why communication happens at this speed based on the response of the meter to the falling edge (it's way off).

I'm testing it with an AVR and a temporary "adapter" I made from cardboard. The receiver diode is connected in series with a resistor, between vcc and gnd and I'm probing between the resistor and the diode with the scope. Once the diode starts conducting, the line will get high (tested it, the receiver works).

Edit: It would be useful if you could tell me which one is the RX and which one is the TX diode on the meter, because they're the same color and I have to reverse the "adapter" for each test I'm making

[Simon Loell]

Which AVR are you using?
What compiler?
What clock rate etc.

If you give me the details, I will try to mock up a setup exactly identical. In that way we can exchange our code.

Regarding the IR diode and phototransistor, can you make a schematic - just a handwritten, so no misunderstandings will occour.

[jadew]

I'm using an attiny2313.

Compiler: avr-gcc, altho the code at this point is just a pulse generating thingie, so nothing special there.

Using the internal 8Mhz clock, however, the timing for this protocol should be easily met with pretty much any clock speed.

As you can see from the code, there's not much to it at this point. Also, if you're going to use that makefile, make sure you're changing the fuse settings to match the chip you're testing on, otherwise you might brick it.