Let's see how that adds up. The first byte identifies the type of frame and the length (this can be set to 0, then there is another byte used for length later), but in this case, 82 hex would mean:
10B for frame type (with addressing, physical addressing)
000010B for length (2 data bytes)
Since the length is not zero, and addressing is present, the next two bytes would represent:
0x10 = Target
0xF1 = Source (common for a test tool)
The next two bytes, 21 02 would be the data bytes, 21 should be the service type.
21 Hex falls into the range of a "request", because bit 6 = 0. In generic 14430-3, it means:
The identifier would then be "02". If this is a read channel 2 request, then so far so good.
The last byte, A6, should be a checksum of the packet. If we add the other bytes up, we get 0x1A6, which truncates to a byte checksum of A6, so the request looks good.
Now the response:
The first bytes again breaks down into a 'addressing/physical' (10B) packet, but the length is 26 (decimal), which matches the length minus addressing.
F1 would then be the target (the test tool)
10 would be the source (the module sent the request above)
61 means a 'positive response' to request 21.
The next byte, 02, is probably the address from the request, but not nec.
The last byte, 22, is again, a checksum (and seems to match).
The bytes in between the 61 and the 22 follow the generic pattern of id:value, but what exactly they mean in this case I could not really say.