Downloaded and compiled CRC_reveng, but it's not finding any solutions. Maybe I'm over-thinking this? Not knowing too many other tricks that might be performed on the data or CRC before or after it's computed, I'm looking for guidance. I tried leaving out the start byte, and tried both 8-bit and 16-bit widths. No luck. Here's some sample data packets:
10020200C6FE2D00C5FE2D00047C000010038CEC 10020200C5FE2D00C6FE2D00046D00001003DFA4 10020200C6FE2D00C5FE2D00015B00531003C1C4 10020200C5FE2D00C6FE2D0001A405534B000D004B1003F50D 10020200C6FE2D00C5FE2D00047D00001003C7E7 10020200C5FE2D00C6FE2D00046E0000100313B9 10020200C6FE2D00C5FE2D00015C155344000000000000000000008C4C08080000040D00201003BC41 10020200C5FE2D00C6FE2D0001A505534B000D004B1003D221
The data shown is both directions of the Fluke 233 IR port (every other line originates from either the display or the multimeter itself). Seems like "C6FE2D00" and "C5FE2D00" might be identifiers for the display and multimeter itself, since you see the same patterns on every other line. The data was collected with a DSLogic logic analyzer, and it looks like the data is simply 19200 baud, 8 bits, no parity. Most commonly, the data packets are 20 bytes long, but as you can see, that's not always the case.
Any ideas how I might proceed since
reveng -w 16 -s [data] and
reveng -w 8 -s [data] don't turn up anything?
If anyone else has a Fluke 233 and feels like sniffing out the same data lines to compare notes, that'd be awesome. I'm wondering too if there's a unique identifier for the wireless display or if you can simply swap out the display between units.