Some biting XGAUGE questions

[hobbit]

I've finally sat down and read through ALL of Dan's "dummies" thread
and related, the Xgauge coding reference, Bob64's rundown over on
Priuschat, re-read my local copies of the ELM327 data sheets, the
Bosch CAN 2.0 standards, the intrepidcs.com training slides, and just
reviewed most of Attila's info again just for perspective. There's
a lot missing from what I am able to learn about the Scangauge,
particularly with regard to XGAUGEs, and I need to get it sorted out.
In a longish discussion with Ron during Hybridfest he acknowledged
several large gaps in the Xgauge documentation, particularly where
passive CAN snooping is concerned, and hopefully that will be firmed
up at some point. Maybe asking some of these questions will help.
.
Please make some time to read through all this carefully, because
there are a lot of different points raised herein.
.
First of all, XGAUGE is a wonderful idea and allows all the community
support for customizations. The implementation seems clever and
versatile, although there are some magic bits whose meaning need to
be spelled out more clearly. I'll get to those later. I really wish
there was a nice one-page network protocol encapsulation chart, though.
If I knew enough about what goes into where, I would make one. And
I do understand that some of the field values are totally arbitrary
as chosen by the automotive testing and diagnostics industry.
.
That may or may not help with my issues, which follow, and which
are totally kicking my butt so far. If you choose to respond to
this, please try to answer as many of the separate questions as
possible. Or reassure me that I'd just have to go pester Ron and
the boys to get anywhere on this. If you know me at all you know
that I can't accept "just plug these numbers in" as an answer, I need
to try and understand what it's all *doing* at a fairly deep level.
While I appreciate the work that people have put into this, my
response is always "Thank you for the answer but please show your
work for full credit." I've even gone back and re-read *this* drivel
as it's taken shape to see if I've answered any of my own questions,
but I haven't managed to.
.
Many of these concern passive CAN in a Prius, e.g. where Xgauge TXD
only contains two bytes. First of all, when and how was this "feature"
discovered, and by who? It certainly isn't documented in the main
or programming manual, and Ron didn't offer a very good explanation
of it when I talked to him.
.
The community is already realizing the value of passive CAN because
it's so fast and doesn't bog down the ECUs with repeated queries.
Fundamentally, it gives everyone the moral equivalent of CAN-View
on the cheap that works in any Prius after MY '04. But it has become
pretty clear that Scangauge version "3.15*" with the asterisk has
hopelessly broken passive CAN and should thus be subject to immediate
RECALL and remediation. Anyone with 3.15* or any other broken
version that came out *AFTER* the functional 3.15 should contact
LL and demand a downgrade or whatever it takes.
.
The main issue is this: why does passive CAN snooping need any sort
of TXD at all? You aren't transmitting, you're listening. Okay,
I could see the need for a fake "transmit" just to trigger the SG
to listen for something in the first place, sure. But much less
clear is what's said about what TXD needs to contain: the CAN ID
of interest with bit 3 flipped [counting from the low-order end as
bit 0]. Both the programming manual and bob64's rundown insist
on using the target CAN ID with bit 3 inverted, but without ever
saying why. Looking for particular bus traffic is supposed
to be the job of RXF, but this bit-3-flipping business apparently
causes some sort of pre-filtering in the SG before you even hit
RXF. Now, I do understand that there is something in the CAN /
OBDII spec about query ID versus response ID, such that it seems
like you ask an engine controller something using an ID of 7E0 and
expect a response back from ID 7E8, but I cannot find a definitive
statement of WHY. And I've groveled through numerous spec documents
about this. I would love a pointer to where this is spelled out
to the automotive testing industry, for real. And it's a different
game for 29-bit IDs. The base CAN spec even calls for a "query"
bit in the headers, called RTR or Remote Transmission Request, but
it seems that nobody ever uses it and they use these bit-flipping
games in the ID instead. In addition, sending active queries to a
car with ID 7DF is supposed to be a "broadcast" that any ECU is able
to answer, but if TXD in the Scangauge is specifying some sort of
additional CAN ID filtering then obviously this wouldn't work.
.
I suppose that whatever it is, it may stem from the similar spec
inside the OBDII packets [via any of the enclosing low-level
protocols], where you ask for mode $01 and get back $41 in the
reply. But nothing I've read ties in the concept of needing to
do that out in the CAN packet headers too.
.
To investigate this further, I used the example of Prius go-pedal
position: 024C / 0102 8244 0000 / 4008 / 000A 0002 0000 which does
seem to work and provides an instant test if data is being read
or not by pushing the pedal a little. This even works in IG-ON
state without having to completely power up the car. After seeing
it work, I went back in to edit the xgauge and changed TXD to
just about anything else, including 00 or 0000. Data capture ceased
[albeit in a sort of sporadic way, but I think that's a separate
problem], so it's clear that TXD needs to contain specific content.
But really, it shouldn't need to in a PASSIVE LISTENING scenario.
To be fair, setting TXD to 024F also works and confirms that the
lower 3 ID bits become dont-cares.
.
Side note: it seems that to fully switch to a changed XGAUGE, one
has to move away from it in the gauge display and keep pushing
the button to roll back around to it again. Otherwise some old
programming values appear to persist in odd ways.
.
To condense this piece: what exactly is the SG doing with the TXD
in 11-bit passive CAN? Is anything actually *transmitted* onto
the bus at all? What goes into the chip's acceptance registers
as a result of any given combination of TXD and RXF?
.
Moving on: I understand that a lot of Dan's list for the Prius
came from Attila's spreadsheets, and kudos for working up all the
translations to SG-ese. But where did Dan obtain the bytes for
the solicited queries, such as MAF flow or SOC? Or how about
all the Ford Escape ones, where did the info for those come
from? What is the precise field-by-field breakdown, for example,
of those TXDs? What are people using to determine these -- is
it as highfalutin' as a two-interface CAN analyzer/logger and
a hybrid-aware scantool?
.
Where is the OBDII *length* field in any of the active/solicited
TXD queries? That's usually the first data byte of the CAN packet,
and yet these listed TXDs seem to jump straight from the CAN ID to the
OBD mode. So what I see for 07E321CE, listed as "state of charge"
in Dan's chart, if I had to put this together and guess, should
make the SG put together 7E3 as the transmitting ID, the extra
stuff in the CAN header, an OBDII length of 02, and then 21 CE as
the mode and PID. Except that what the heck is mode $21, since
that matches neither "legislated" or "non-legislated" modes of 00
and 22? Anyway, I would guess that 07E3 02 21 CE hits the bus,
and the SG starts listening for stuff back from ID 07EB. And
this doesn't take into account the *CAN* length nibble, but that
probably doesn't matter here.
.
Now, some stuff that isn't specific to CAN, but general Xgauge
operation.
.
There are undocumented bits in the RXF. Under "Special RXF values"
in the programming doc, one is documented as "trip gauge" and
two others are listed as "special" for Offset 1, but never explained.
And yet I've found an Xgauge that uses them, notably Horsepower or
HPR, using 4000 8000 0000 in RXF. What is that doing, for example,
and where is it getting its info? What about the fact that TXD
for that one is "00", about which all that's ever said elsewhere
in the manuals is "it can also contain 00 to indicate that this is
a valid gauge" ?? I would like to see ALL the special bits in ALL
fields clearly documented, along with which order they're used and
if any COMBINATIONS of the special bits have particular effects too.
And since the special bits prevent usable RXF byte offsets larger
than 31, are we sure this mechanism is future-proof for when cars
might start someday sending larger packets around?
.
Where exactly does sign-extension occur during or after MTH?
The multiply and divide inside MTH appear to use an intermediate
32-bit result, but brought back down to 16 bits and supposedly
used as a signed value afterward. I can't see how to make this
work for me. Take as an example one that's been screwing everybody
up -- passive Prius hybrid battery current. A 12-bit field inside
CAN ID 03B, reading tenths of amps as a signed value. I've
programmed this up in various ways, notably changing MTH to try and
pull those bits out and shift them around and make them come back
as a signed value with the high bit on if it swings negative. With
no conversion at all and battery current bobbling slightly on either
side of zero, I see either small values or something just shy of
4095, which is entirely reasonable given that it's 12 bits. But all
positive values. If I then try MTH with 0010 0001 0000 to push it
to the high end of a supposedly resulting signed 16-bit value, I
still don't see it ever go negative. [Regardless of the fact that
I'd have no way to downconvert it to +/- 256 amps afterward..]
.
The "display as hex" bit seems to have no effect, either; I messed
around with this trying to debug the Prius battery current figure,
with no change in what I see.
.
The x10 and x100 decimal-point mover bits in RXF are fairly confusing,
and it would be nice to know at exactly what stage between MTH,
conversion to decimal, and display it is applied. To sum up, a very
detailed rundown on how MTH and the decimal mover are applied would
be really useful, along with some hints on best ways to get quanties
to creatively wrap around across various register lengths for best
results. What we have is pretty sketchy so far, but I see some
fairly clever instances of bit-banging in some of the listed Xgauges
already and I'd like a better feel for how those were derived.
For example, look at the LT/ST fuel trim MTH. Times 200 [decimal],
div 256, subtract 100 -- I'm still trying to figure out why that
works.
.
Now, once you've got your wonderful set of CAN-specific Xgauges
all done up for a Prius, what happens if you move that Scangauge
to a car running a different electrical protocol like PWM or KWP?
Do the Xgauge bytes now turn into a meaningless kiss of death for
the other car's ECUs? I think we've already seen some evidence
that they can, and I'm thinking that maybe adding a switch to cut
off the SG's various network leads but still keep power to it may
help the user make sure the potentially confusing xgauges are out
of the way before conversing with the car. Attila added a switch
to his DLC plug to do that, in fact. There's no warning about
this in the manual, but there probably should be, in a big box
at the beginning of the XGAUGE section.
.
And finally, I wish Ron or whoever would stop referring to it
as "hex-a-decimal" ... I've never seen that word hyphenated.
.
_H*

[Dan]

I've scheduled this thread for heavy contemplation over Guiness tonight


11011011

[CarlD]

A few things...

if the MSB (b15) is set AFTER the MTH, the SG asumes this is a negative number in 2's complement format as displays it as such. This can and does cause problems because the MTH is not 2's complement correct.

As Dan has pointed out, the bit for displaying hex is the LSB of the 2nd match field, NOT the 3rd match field indicated in the SG document. To display hex the RXF would be, zum beispiel:

046215490623

An 8 is 10x, a 4 is 100x, a 2 is on/off, a 1 is hex.

The decimal mover is after MTH, and it doesn't round up the value. It will drop places after the decimal as numbers get larger, so there is usually no disadvatage to using it.

The L/SFT MTH is pretty straight forward. To get a range of -100 to +99.2, the 1 byte full scale reading of 0xFF corresponds to 99.21875 and a vaule of 0x80 corresponds to zero and 0x00 corresponds to -100. If it were me, I would have used the 10x decimal mover and a MTH of 07D00100FC18.

I have moved my SG from my CAN FEH to my Toyota VPW and GM VPW cars with no problems. The xgauges, as expected, are blank but nothing funky has happened.

[JimboK]

Originally Posted by Dan

I've scheduled this thread for heavy contemplation over Guiness tonight


11011011

I gave up on heavy contemplation after getting about 1/4 through it. I could still do a Guiness though. Makes me thankful for my CAN-View!

Hobbit, maybe Norm (the CV developer) might provide some insight. I wouldn't be overly optimistic; I got the sense he was a little vague when Jay Groh was trying to pin him down recently on how CV derived some of its values. But it wouldn't hurt to ask. All he can do is say "no."

[xcel]

Hi Al:

___I am not going to begin to try and figure out half of what you have asked as it is a bit beyond my pay grade. About demanding a recall. When the Prius-III comes out w/ a 62 mph EV capability due to a programming hack allowing MG1 to spin to its 10K limits, should you go after Toyota for a reflash allowing 62 mph EV? The OEM Prius-II PHEV allows it and it is possibly only a re-programming of the ECU more than likely? The ScanGauge offers features that work for its release and seeing the upgrade bug is not a pretty sight but it is understandable if it is more than just a flash upgrade but a HW upgrade to 3.15 as well?

___The last one I may be able to help with… I have used the Prius specific coded X-Gauge in the Accord on a non-CAS-Bus system and nothing displays or blows up when looking at any of the Prius specific X-Gauges. That is a good thing too

___Good Luck

___Wayne

[hobbit]

One additional piece I forgot to put into the first stab...
.
It also looks like RXD is counting the two bytes used for CAN ID
as part of the "response", thus increasing all the bit offsets
by $10 higher than they would be if one was only examining the
payload. This is confusing as hell, and I have no idea how it
would apply to non-CAN protocols. This is something that really
needs to be spelled out explicitly in the coding guide.
.
As far as recalls -- bad example, because the progression from
3.15 to 3.15* REMOVED or BROKE functionality that existed and
worked before. That is the opposite of progress and doesn't
match the prius EV speed improvement example, sorry. If the
'09 or '10 removed EV mode or lobotomized it to 15 MPH just
in software, then you'd hear some far and wide howling. If
I have an old version of something and have chosen to not
upgrade, I don't expect the expanded functionality. But if I
have in good faith upgraded to track product improvements and
suddenly find myself lacking something I depended on, that
falls on the manufacturer's head.
.
Unless I've got 3.15 and 3.15* backwards, but my impression
was that LATER releases were causing all the problems.

_H*

[CarlD]

You have it backwards. The 3.15* was not a progression. It refers to units with the old processor that was obsoleted by Microchip.

[jps000]

Should anyone have patience for a non-technical, non-erudite intrusion here into an esoteric discussion: Will the Scangauge F--K up my car? The Prius I put it in, with the x-gauge codes offered in Dan's link.

[Bob64]

I believe I may be responsible for coining the "passive" term, as we're fooling the scangauge to be "pre-filtering" for "passive" traffic on the CAN bus. This pre-filter then sends it to the RXF for additional filtering. Note: all of my "work" is based mostly on the xgauge guide - which is very poorly written... and half-assed guesses trying to piece it together... I've had no luck figuring out how the scangauge sends data or receives it, and how the RXF works, and if it includes the SOF (start of frame) data passed to the filter, as well as how close it matches the CAN spec...

it seems like you ask an engine controller something using an ID of 7E0 and
expect a response back from ID 7E8, but I cannot find a definitive
statement of WHY.

I understood it as a sort of prefilter by the scangauge, it automatically looks for any reply with the Most Significant Bit of the 3rd HEX ID and then passes it to the RXF filter.

Which means, if you send something with an id of 7E0, it'll accept the following IDs back for RFX processing:
7E8 (111 1110 1000)
7E9 (111 1110 1001)
7EA (111 1110 1010)
7EB (111 1110 1011)
7EC (111 1110 1100)
7ED (111 1110 1101)
7EE (111 1110 1110)
7EF (111 1110 1111)

I believe the 12 bit problem was solved by "reading" four bits past it, getting whatever garbage is after - thus enabling the MSB to display the sign, then dividing by 160 to cancel out the garbage... But I haven't tested it.

I don't know if the sg sends any data in "passive" mode or not. For all I know, its sending empty frames with just the ID...

[Dan]

Originally Posted by hobbit

Many of these concern passive CAN in a Prius, e.g. where Xgauge TXD
only contains two bytes. First of all, when and how was this "feature"
discovered, and by who? It certainly isn't documented in the main
or programming manual, and Ron didn't offer a very good explanation
of it when I talked to him.

I don't know how they kludged passive CAN into the mix, but I think it had to do with just wanting battery Voltage. Everything else they published was solicited CAN. Don't know who at LL gets the credit though. Have some theories below.

Originally Posted by hobbit

The community is already realizing the value of passive CAN because
it's so fast and doesn't bog down the ECUs with repeated queries.
Fundamentally, it gives everyone the moral equivalent of CAN-View
on the cheap that works in any Prius after MY '04. But it has become
pretty clear that Scangauge version "3.15*" with the asterisk has
hopelessly broken passive CAN and should thus be subject to immediate
RECALL and remediation.

I'll buy Ron and Carl's explanation that the passive CAN failure in 3.15* is in essence a hardware bug. 3.15* is a best attempt to bring some functionality to those units already in the field. It sucks, but I can't fault them for not seeing this coming.

Originally Posted by hobbit

The main issue is this: why does passive CAN snooping need any sort
of TXD at all? You aren't transmitting, you're listening. Okay,
I could see the need for a fake "transmit" just to trigger the SG
to listen for something in the first place, sure. But much less
clear is what's said about what TXD needs to contain: the CAN ID
of interest with bit 3 flipped [counting from the low-order end as
bit 0]. Both the programming manual and bob64's rundown insist
on using the target CAN ID with bit 3 inverted, but without ever
saying why. Looking for particular bus traffic is supposed
to be the job of RXF, but this bit-3-flipping business apparently
causes some sort of pre-filtering in the SG before you even hit
RXF. Now, I do understand that there is something in the CAN /
OBDII spec about query ID versus response ID, such that it seems
like you ask an engine controller something using an ID of 7E0 and
expect a response back from ID 7E8, but I cannot find a definitive
statement of WHY.

My best guess on all this has to do with commonly available parts. Although CAN is a common protocol, it's not nearly as common as IIC. IIC (SMBus) is a 2 wire protocol that looks real, real similar to CAN. In particular some of the minutia about bus arbitration. IIC uses odd addresses for reads and even addresses for writes (did I get that backwards?). The reason it does this is because on an SMBus, zero wins. So writes to the bus (trailing zero) are given a higher priority than reads. In most cases this is what a HW designer would prefer. So... if my WAG is correct, LL (cleverly) may be using an IIC chip to do all it's CAN talking with a simple serial shifter bit padding the input and output addresses. My experience with these chips is that they are stone dumb. They are designed to be cheap and fast, so extensive configurablility is not a priority. So to summarize, my guess is he's using an IIC engine to do his CAN traffic and that engine conforms to the even write / odd read rule. So programming the TXD as odd (after the bit shifter clips the last three bits). Problem with that WAG is that the magic that needs to be done on bit three is not to assert it, but rather to INVERT it. So some TXDs have bit three ODD, others have it EVEN. My only thought is that the IIC controller is simple and doesn't care about ODD EVEN but rather pairing same high order bits. Pure assumption, so dismiss at will.

Originally Posted by hobbit

I suppose that whatever it is, it may stem from the similar spec
inside the OBDII packets [via any of the enclosing low-level
protocols], where you ask for mode $01 and get back $41 in the
reply. But nothing I've read ties in the concept of needing to
do that out in the CAN packet headers too.

I think that may be a good lead, I missed that. If the chip he's using is true CAN and not IIC, then it he may be trying to fake it out. If the part puts out XXXX 0XXX it may start listening for XXXX 1XXX. But it doesn't explain why we are INVERTing the bit, and not simply clearing it.

Originally Posted by hobbit

To investigate this further, I used the example of Prius go-pedal
position: 024C / 0102 8244 0000 / 4008 / 000A 0002 0000 which does
seem to work and provides an instant test if data is being read
or not by pushing the pedal a little. This even works in IG-ON
state without having to completely power up the car. After seeing
it work, I went back in to edit the xgauge and changed TXD to
just about anything else, including 00 or 0000. Data capture ceased
[albeit in a sort of sporadic way, but I think that's a separate
problem], so it's clear that TXD needs to contain specific content.
But really, it shouldn't need to in a PASSIVE LISTENING scenario.
To be fair, setting TXD to 024F also works and confirms that the
lower 3 ID bits become dont-cares.

Now that is starting to look like IIC again with a shifter in and a shifter out.

Originally Posted by hobbit

Moving on: I understand that a lot of Dan's list for the Prius
came from Attila's spreadsheets, and kudos for working up all the
translations to SG-ese. But where did Dan obtain the bytes for
the solicited queries, such as MAF flow or SOC?

A guy posted them from a German site. I took them up wholesale then people started correcting them. The SOC one was in Ron's inital XGauge list. Atila did poke around with the solicited queries and he decodes his guesses (which turned out to be right) in the bottom of his spreadsheet. The spreasdheet is included in my Prius XGauge download zip under "ResearchData"

Originally Posted by hobbit

Or how about
all the Ford Escape ones, where did the info for those come
from?

Always thought those were Carl's work

Originally Posted by hobbit

What is the precise field-by-field breakdown, for example,
of those TXDs? What are people using to determine these -- is
it as highfalutin' as a two-interface CAN analyzer/logger and
a hybrid-aware scantool?

I got that in my head once so hear goes on a recreate. First the Generic CAN:
O2 Sensor Bank 1 Sensor 1
TXD: { 07 E0 01 14 }
My guess is this is targeting 07E0 (generic ECU right?) in mode $01 for PID 14. This lines up well with the ODBII PID lists. Now the RXF filter expects the response to look like { XX XX XX 41 14 dd... } (where dd is data). So the first 2 bytes may be 07 E8 with the 3rd byte being the width count field. One way to find out for sure would be to change the RXD field to something like { 00 10 }. This would dump the first two bytes (in HEX if you ask RXF) so you could see what it's fishing for. So far it looks "kinda" like what's in wikipedia (my only "free" CAN doc) at: http://en.wikipedia.org/wiki/OBD-II_PIDs#Response

Now on to non-standard / Vehicle specific stuff. Lets take the FEH SOC pid:
TXD: { 07 45 22 49 23 }
again, I'm guessing ECU 0745, in mode $22 for PID 4923. So looking at this RXF, what it's looking for is { XX XX XX 62 49 23 dd... } (where dd is data). This looks similar to the wikipeda stuff in regards to vehicle specific mode 22 stuff.

Now the really weird stuff that Toyota does. Lets take a Prius SOC pid:
TXD: { 07 E3 21 CE }
So using our earlier assumptions ECU 07E3, mode $21, PID CE. Looking at RXF what it's looking for is { XX XX XX XX 61 CE dd... } where dd is data. So going back to wikipedia, one proposed response may look like this { 07 E3 cc 7F 61 CE dd } where cc is the data count and dd is the data. Now notice the mode $21 had the bit 3 flip to $61. Kinda cool. Anyway, that's how I've always interpretted solicited query response to work.

Originally Posted by hobbit

Where exactly does sign-extension occur during or after MTH?
The multiply and divide inside MTH appear to use an intermediate
32-bit result, but brought back down to 16 bits and supposedly
used as a signed value afterward. I can't see how to make this
work for me. Take as an example one that's been screwing everybody
up -- passive Prius hybrid battery current. A 12-bit field inside
CAN ID 03B, reading tenths of amps as a signed value. I've
programmed this up in various ways, notably changing MTH to try and
pull those bits out and shift them around and make them come back
as a signed value with the high bit on if it swings negative. With
no conversion at all and battery current bobbling slightly on either
side of zero, I see either small values or something just shy of
4095, which is entirely reasonable given that it's 12 bits. But all
positive values. If I then try MTH with 0010 0001 0000 to push it
to the high end of a supposedly resulting signed 16-bit value, I
still don't see it ever go negative. [Regardless of the fact that
I'd have no way to downconvert it to +/- 256 amps afterward..]

Yeah, I'm ready to call this a bug. So I have gotten 03B working. The trick is to use a MTH field of 0001 0001 0000. The value comes across with the correct sign, but the displayed value is (current * 160). Now as Carl eluded to there are signed multipliers and unsigned multipliers. Lets look at 0x88 { 10001000b }. This comes out -120 using twos complement. Now if you divide 0x88 by two a signed divider would end with a result of 0xC4 { 11000100b }. Now a unsigned divider would yield a result of { 01000100b }. So what's happening with 03B seems to be a special case. I think the SG divider is sign aware, but only on data that is byte aligned. So if the sign bit is bit 7, 15, 23, 31, 39, 47 ... all works well. But if the sign bit is in bit 3, 11, 19, 27, 35, 43 ... I think your SOL. In this particular case the sign bit is in bit 51... one of the SOL bits. I think your fine as long as you don't go to the divider curcuit, but once you do, it assumes byte alignment and doesn't honor nibble alignment.

Originally Posted by hobbit

The "display as hex" bit seems to have no effect, either; I messed
around with this trying to debug the Prius battery current figure,
with no change in what I see.

Yep... I found that one. Carl mentioned the fix, so I'll leave it at that.

Originally Posted by hobbit

Now, once you've got your wonderful set of CAN-specific Xgauges
all done up for a Prius, what happens if you move that Scangauge
to a car running a different electrical protocol like PWM or KWP?
Do the Xgauge bytes now turn into a meaningless kiss of death for
the other car's ECUs? I think we've already seen some evidence
that they can, and I'm thinking that maybe adding a switch to cut
off the SG's various network leads but still keep power to it may
help the user make sure the potentially confusing xgauges are out
of the way before conversing with the car. Attila added a switch
to his DLC plug to do that, in fact. There's no warning about
this in the manual, but there probably should be, in a big box
at the beginning of the XGAUGE section.

That's a big Yes Siree Bob! Just plug a fully programmed FEH XGauge into a Prius and watch the red triangle flicker. I've determined that passive gauges are benign, but solicited queries can spell trouble if they start poking the wrong soft spots.

Originally Posted by hobbit

One additional piece I forgot to put into the first stab...
.
It also looks like RXD is counting the two bytes used for CAN ID
as part of the "response", thus increasing all the bit offsets
by $10 higher than they would be if one was only examining the
payload. This is confusing as hell, and I have no idea how it
would apply to non-CAN protocols. This is something that really
needs to be spelled out explicitly in the coding guide.

My conclusions as well. I assumed as much earlier in this post.

Hope I got it all... I'm out of Guinness so I better go to bed.

Originally Posted by jps000

Should anyone have patience for a non-technical, non-erudite intrusion here into an esoteric discussion: Will the Scangauge F--K up my car? The Prius I put it in, with the x-gauge codes offered in Dan's link.

If TXD is 4 characters long like "05AC" it won't F-K up any car, no worries. If it is 8 characters or longer it could confuse your car but won't do real harm other than lighting your check engine light.. If check engine is a F-K up than yes...

Originally Posted by Bob64

I believe the 12 bit problem was solved by "reading" four bits past it, getting whatever garbage is after - thus enabling the MSB to display the sign, then dividing by 160 to cancel out the garbage... But I haven't tested it.

Nope. I beleive the sign extendtender in the hardware only works on the byte boundry not the nibble boundry. It's fine as long as you don't send it to the divider curcuit.

11011011