|
|
Post by JohnyForElectric on Nov 26, 2022 0:58:55 GMT
How to enter "FF FF FF FF FF FF" (no spaces) into the value box. please? No letters are allowed, only numbers... Any pointers, please?  OBDeleven it would be great to have the ability to name individual "Adaptation UCS" lines/adaptations, it can get pretty confusing very fast with more complex adaptations... Thank you |
|
|
|
Post by dv52 (Australia) on Nov 26, 2022 2:19:43 GMT
@jonnyforelectric: Hi. I have absolutely no idea what you are trying to do (it's my deficiency- not yours) - but I do like to fool myself into thinking that I know a (little) bit about base 16 arithmetic (i.e. hexadecimal) and it's bother numbering set; Binary (i.e. base 2 maths) So, let's start with hex. Each pair of digits in Hex number is called a Byte and in OBD11 speak, it's separated by a space - but in truth this is a nonsense because the space isn't needed (all that's needed is to count in pairs of digits to understand how many Bytes in a Hex string). A single Hex digit can have 16 x different values like this 0,1,2,3 ...........8,9,A,B....F
Binary numbers operate in base 2 arithmetic - which means that they use only ones and zeros. Each digit in a Binary number is called a "Bit" and because a Binary number needs to line-up with a Hex digit (which has 16 x values), 4 x Bits are needed for each Hex digit. Remembering that a Byte has 2 x Hex digits, this means that a Hex pair must have 8 x Bits
OK- now we need to discuss nomenclature - which is just a fancy name for the rules. I don't like rules - they tend to stop folk from out-of-the-box thinking, however rules are needed in numbering systems to ensure that everyone understands each other when they write stuff down!! The only 3 x rules that are important for your little problem are: - Hexadecimal numbers are read from left to right
- Binary numbers are read from right to left
- Both Hex & Binary numbers start with zero
That's it (no more rules needed)!! Regardless of which number system you want to use, each different type has an equivalence in any other numbering system. Here's how the 3 x numbering systems line-up: | Hex | Binary
| Decimal
| 0
| 0000
| 0
| 1
| 0001
| 1
| 2
| 0010
| 2
| 3
| 0011
| 3
| 4
| 0100
| 4
| 5
| 0101
| 5
| 6
| 0110
| 6
| 7
| 0111
| 7
| 8
| 1000
| 8
| 9
| 1001
| 9
| A
| 1010
| 10
| B
| 1011
| 11
| C
| 1100
| 12
| D
| 1101
| 13
| E
| 1110
| 14
| F
| 1111
| 15
|
Hope that I haven't lost you yet - that's ALL the background stuff that I want to talk about!!
Let's look at your number sequence "FF FF FF FF FF FF" - it's just a Hexadecimal string that happens to have 6 x Bytes. If you have followed my ramblings above, you should see that the Blue "FF" (in hex) above is Byte 00 and the black bold "FF" is Byte 05 (i.e. 6 x Bytes starting at Byte 00 means that the highest Byte = Byte05)
Also, if you have understood my equivalence table above, you should see that "FF" (in Hex) = 11111111 in Binary.
So, if we combine the lot - this is how your number string pans-out in Bytes & Bits:
<--------------------------BITs------------------------>
Byte HEX 7 6 5 4 3 2 1 0
00 FF 1 1 1 1 1 1 1 1
01 FF 1 1 1 1 1 1 1 1
02 FF 1 1 1 1 1 1 1 1
03 FF 1 1 1 1 1 1 1 1
04 FF 1 1 1 1 1 1 1 1
05 FF 1 1 1 1 1 1 1 1
Remember the Binary rule - these numbers are read from right-to-left. So, Bit 0= the right-most digit and Bit 7 is the left-most digit in a binary number. It just so happens that ALL the Bits in your Binary numbers are 1 - but the position distinction is important when reading Binary numbers!!
Don
|
|
|
|
Post by JohnyForElectric on Nov 26, 2022 5:09:28 GMT
Nice meeting you dv52 (Australia). Thanks mate, great background, much appreciated. Now, back to the OCA creation. The channel with ID 1395, Byte 0, Starting with bit 0 has a 48 bit length code (6 bytes). The value is 255(DEC), FF(HEX) 11111111(BIN) for each byte, so all 48 bits are "1". How to code that in the OCA UI while building the app in the OCA Builder app.obdeleven.com/build-oca/, please? The value box does NOT permit entering 6x255 nor 6xff nor 48x1... Thoughts, pointers, please? ...I can think about workaround, since only the last byte is changing, I can of course change only that and not the entire ID Channel that shows in the OBDEleven app... ...but I'm trying to mimic the exact value I'm seeing in OBDEleven - which is this:  ...and this is the same adaptation channel from VCDS: IDE12986-ENG278492-BAP configuration-Bap_fc_list_exterior_light, FF FF FF FF FF FFThoughts, please? |
|
|
|
Post by dv52 (Australia) on Nov 26, 2022 21:29:26 GMT
JohnyForElectric : I suspect that I owe you an apology - clearly from your 2nd post, you are well aware of the basic information that I included in my response. I obviously (grossly) underestimated your knowledge-base!!!
So yes, back to the OCA
First, an important caveat; I've not used the OCA builder - so I'm guessing how the OBDeleven application works
For VCDS admaps - I have found 2 x vehicles that have your adaptation channel (is this car an Audi Q4, or a ID.4?). To be exact - the full descriptor as reported by VCDS and as factory set for this adaptation channel is:
- IDE12986-ENG278492-BAP configuration-Bap_fc_list_exterior_light,EF FF FF FF FF FF ,8
- IDE12986-ENG278492-BAP configuration-Bap_fc_list_exterior_light,FF FF FF FB FF FF ,8
Of course, the actual channel value varies with the vehicle - but notice that both instances above have an "8" as the last field in the .CSV record. My understanding of the nomenclature for VCDS admaps is that the last field in each record denotes the Bit length for the channel.
Now, Yes - I can see that there are 6 x hex pairs in this channel value and also yes, 6 x hex pairs = 48 x Bits - which aligns with the "Length 48" entry in your OBD11 picture. But, if this channel was expecting a full 48 Bit entry - I would have thought that the last field value in the VCDS admap entry would be 48 (and it is not "48")
Maybe - if this channel was expecting a full 48 x Bit entry, the Admap would report the value as as FFFFFFFFFFFF (i.e. with no spaces)? Or said another way -perhaps the requirement for separate 8 x Bit entries explains why there is a space between each Hex pair value in the Admap report (i.e. the space separator is a deliberate VAG protocol that distinguishes the entry type - for those that know the rule)?
So, based entirely on the intriguing oddity of the last digit in the VCDS admap descriptor (and I'm totally guessing), I wonder whether this channel is expecting 6 x separate, 8 x Bit entries? Is the OCA builder happy with a single hex, or 8 x Bit entry for each Byte number for ID1395 -maybe by increasing the Byte number on the OBD11 picture in your first post?
Again, I'm hypothesizing by my suggestions
Don
|
|
|
|
Post by JohnyForElectric on Dec 17, 2022 20:02:00 GMT
Thank you. Again can't enter 6 bytes in either hex or dec format. I have decided to downgrade to PRO version as I can't use the OCA builder as I expected. I will use VCDS to restore adapatations after car upgrade from v2.3. to v.3.1. It has a similar "bulk update" functionaly that is much easier to use.
|
|
