OP
OP
jmccorm
Well-Known Member
- Thread starter
- #346
This is the age-old conflict between software people and hardware people. One of them wants to start counting at zero, and the other wants to start counting with one. I keep forgetting which is which, as I try to do both!
I'm going to continue to kick the can on how we handle that conflict until we have more people join us. In the meantime, I've been using the most neutral language I could muster, which would be to say, "the first value is..." and "the first variable contains". Referring to their relative position rather than an absolute position. If I said "Byte one contains...", then people are going to wonder where I started counting from and if there's a byte zero or not.
Actually, this topic naturally leads into two more things...
Data sizes. A word is simply defined as a number that's two bytes long. So in hex, a number like 0x1234 is going to be a word. Something smaller like 0x12 is just a byte. And something even smaller, just one hex digit like 0x3, is a nibble. Then there are going to be a few weird situations where a variable is three hex digits long. You'll see that with message ID 0x079:
$x???0??????? – Vehicle is stopped? bitmap
$?xxx0??????? – Braking pressure (see notes)
$????0xxx???? – Braking pressure (see notes)
$????0???xxxx – Vehicle speed (MPH x 200)
The first variable is one nibble long, the second variable is three nibbles long, the third variable is three nibbles long, and the fourth variable is a word. Because of the odd alignment, there can be some confusion in how the layout is described, so that leads into the other topic I wanted to cover.
We have to be careful to avoid ambiguity when discussing the layout of our findings. Take this hypothetical layout, for example:
$xxxx????0000???? – Engine RPMs
$????xxxx0000???? – Vehicle MPH
$????????0000xxxx – Turbo Turbine RPM
In looking at this, you see that the first word contains Engine RPMs, right? And the second word contains Vehicle MPH, yes?
But what about the third word? Let's look at it. Wait. There's two different ways to look at it. If you look at the digits, you have xxxx for the engine RPMs, then xxxx for the vehicle MPH, and then you have 0000 which is just a static placeholder. So you could say that 0x0000 is the third word.
But another person might say that Engine RPMs is the first word, and Vehicle MPH is the second word, and then for the third word we've got the RPMs of the turbo.
So which one gets call the third word?
I've been mostly consistent here, or at least, I thought I had been, but I've tried to avoid any ambiguity by referring to these in terms or values or variables and not by their sizes. And we've got three variables (Engine RPMs, Vehicle MPH, Turbo RPMs). I might say, "the first value contains RPMs" or "the first variable contains Engine RPMs".
Perhaps the best way to keep things sorted is to accept that Column D is going to focus on where something begins, how wide it is, and what title we give it. Then when we talk about it in Column L, we don't need to talk about data alignment or width in most cases. We'd just say the first variable (referring to Engine RPMs) or the third variable (referring to turbo RPMs). Turbo RPMs is our third variable, and we actually avoid talking about it in terms of being the third word because then we're talking about size or alignment (which is done in Column D).
There's nothing wrong with the way Python treats the data (aligning it at the byte level), but sometimes our data wasn't designed that way. Like the second variable (braking pressure) with message ID 0x079.
If this all doesn't make sense right away, don't worry too much. If we need to, we can adjust these rules. But I think you're likely to pick up on the rules and the exceptions as you continue. But if there's a better system that's minimizes ambiguity without making things too difficult, I'm willing to go another direction if everyone else is.
Hope this helps.
Sponsored
