I want to measure current fuel level inside my car's fuel tank using OBD2 bluetooth/USB adapter.
When i try to query that PID i got following data as "NO DATA" while at the same time i can check other PIDS like RPM and all data comes fine.
I have small python program which reads its but i am unable to get it.
import serial
#ser = serial.Serial('COM12',38400,timeout=1)
#ser.write("01 2F \r")
#speed_hex = ser.readline().split(' ')
#print speed_hex
#convert hex to decprint ("SpeedHex",speed_hex)
#speed = float(int('0x'+speed_hex[3],0))
#print ('Speed',speed,'Km/h')
ser1 = serial.Serial("COM12",38400,timeout=1)
#ser1.write("ATZ \r")
#ser1.write("ATE0 \r")
#ser1.write("ATL0 \r")
#ser1.write("ATH1 \r")
#ser1.write("ATSP 5 \r")
ser1.write("01 0C \r")
fuel_hex= ser1.readline()
print fuel_hex
#convert to hex to decprint ("FuelHex",fuel_hex)
#fuel = float(int('0x'+fuel_hex[3],0))
#print ("Fuel in Per",fuel)
Can any one suggest here how to get fuel level which is their inside in car at this current time. As i can see in my panel with bar sign.
In order to get all the available PIDs in a vehicle, you have to request the following PIDs at first exactly like you ask the rpm of the vehicle:
0x00, 0x20, 0x40, ....0x80 and so on.
For instance when you request PID 0x00 the ECU will return you 4 bytes which means if it supports PIDs from 0x01 - 0x20. Each byte has 8 bits in total of 32 bits which is exactly from PID 0x01 to PID 0x20. Now it is time to parse the data. If each bit is 1 it means the ECU will support and 0 no support. It is your duty to do some bitwise operations to translate these bits:
Also you can look out this Wikipedia link which shows in graphics!
byte 1 bit 1 : availability of PID 0x01
byte 1 bit 2 : availability of PID 0x02
byte 1 bit 3 : availability of PID ox03
....
byte 4 bit 7 : availability of PID 0x1F
byte 4 bit 8 : availability of PID 0x20 --> Here the ECU tells you if support any PIDs in next 32 PIDs. If it is 0, you do not need to check anymore!
After parsing and gathering all the supported PIDs, then you can have a roadmap to calculate or check each PIDs you want. Do not forget many of conversion rates a formulas in wikipedia is wrong due to the complexity of calculations. You have to read the ISO 15031 part 5 and do NOT forget ECU only gives you the emissions-related diagnostics and not all the data.
Related
I have a APC SMC1000-2UC UPS device that has a serial port to connection. The serial port protocol seems that is based on microlink protocol which has not documented. I monitored the communication of the UPC and PC witch UPS deriver has been initialed. I want to detect command of UPS such as shutdown command by a microcontroller-based device. Some information of "https://sites.google.com/site/klaasdc/apc-smartups-decode" site is compatible with things I observed. but calculation of frame checksum and Challenge string calculation don't pass.
Data length of protocol has been set to 32 bytes, So each frame has 35 bytes.
[Msg ID | 32 byte data | 2 byte checksum]
Regarding calculation of challenge frame, the UPS send 0x65 frame ID then 0x68 frame ID, after that the PC response with 0x65 frame ID and UPS send confirmed frame by 0x65 frame ID. based on presented calculation, I think format or Position of Password_1, Header data and two bytes of that has been changed as the protocol has been configured to 32 bytes data. The following frame are a sample of this challenge:
Header frame: 0x00 0a206903fa27090001004000f802fe04fe0940fc1042fc1044fc20f80416fc10 32a6
UPS : 0x65 ffff00010000a0e80000 c0bbb4e1 000001040000001000000004000000000020 7350
UPS : 0x68 000000000000000000000008004c2943000000000966039a063b675601f30000 864f
PC : 0x65 0a 04 8afb65f1 bdf0
UPS : 0x65 ffff000100000eaf62d8 8afb65f1 000001040000001000000004000000000020 6227
How can I satisfy the challenge and checksum type? I try many type of checksum for that data but they not correct.
It may be a bit late, but have you looked at this:
https://github.com/klaasdc/apcups-serial-test
This looks like somebody got pretty far reverse engineering the MicroLink protocol, including the checksum part. The GitHub repo also contains a link to a web page with a protocol description.
For the following entries, what instructions do they represent respectively?
Binary: 00000001110001011000100000100001
Hexadecimal: 144FFF9D
I'm completely lost on what I'm doing here - searching online has produced a bunch of results that make very little sense to me, but what I've gathered is I'm basically supposed to match up the numbers to their appropriate instructions/registers, but how exactly do I know what those are? Where can I find a comprehensive list? How do I know whether it's an R I or J format function?
The first 6 bits (it is easier to work in binary) are the opcode, from which you can determine how to interpret the rest. This site should get you started: http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html
Update: Calling the first 6 bits the opcode is (to be too kind) misleading, but it is enough to tell you how to interpret the rest of the instruction; you may need to look elsewhere (typically at the end of the instruction) for the complete determination of the opcode.
There are 3 Type of MIPS Instructions:
R_type: Opcode must be 000000 (the first 6 bits) and with last 6 bits we can know what is the correct instruction
I_type
j_type
In this case, we have a R-type MIPS instruction and thus :
Opcode rs rt rd shamt funct
000000 01110 00101 10001 00000 100001
addu $s1 , $t6 , $a1
Can someone please explain, in very simple, simple terms why we need bitwise operators? I just started programming one month ago.
I understand that everything is stored in binary form. I understand computers count in base 2. And I understand the bitwise operators. I just don't understand what kind of programming would require using bits and bitwise operators?
I tried to look for the answer on the web, and I read something do with binary flags and disabilities, and got even more confused.
I guess I'm just wondering, what kind of real life application would require bits and bitwise operators?
You can pack data in a very concise format.
The smallest amount that an x86 computer can adress is a byte - that's 8 bits.
If your application has a 24 yes/no flags (bools), would you store them in 1 byte each? That's 24 bytes of data. If you use bits, then each byte contains 8 of those bools - so you only need 3 bytes for 24 yes/no values:
> 1 Byte per flag:
> 0000 0000 = off
> 0000 0001 = on
> Easy to check: if(b == 0) { /* flag is off */ } else if(b == 1) { /* flag is on */ }
> 1 Bit per flag
> 0011 1101 = Flags 1, 4, 8, 16 and 32 are on, flags 2, 64 and 128 are off
> Packs 8 flags in 1 byte
> Harder to check:
> if( (b & 32) != 0) { /* Flag 32 is on */ }
This is important for network protocols and other systems where every byte really counts.
For general purpose business applications, there is usually no need for the additional complexity, just use 1 byte per flag.
This isn't just used for bools. For example, some applications may want to store two numbers than can go from 0-15 - an example is the Commodore 64 which really needed to conserve RAM wherever possible. One byte can hold two of those numbers:
> Instead of interpreting this as 8 bits (ranging from 1 to 128)
> this is really two 4 bit numbers:
> 1001 0110
> First Number: 1001 = 1 + 8 = 9
> Second Number: 0110 = 2 + 4 = 6
>
> Getting the first number requires a bit shift to move them into position:
> (b >> 4) turns the above number into this:
> 0000 1001 - this can now be simply cast as a byte and returns 9
>
> The second number requires us to "turn off" the first 4 bits
> We use the AND operator for this: b = (b & 15)
> 15 in decimal is 0000 1111 in binary.
>
> 1001 0110 AND
> 0000 1111 =
> 0000 0110
>
> Once again, the result can be interpreted as a byte and results in the number 6
One more really neat trick is to quickly check if a number is even or odd. An odd number always has the lowest significant bit (the 1 Bit) set, while an even numer always as it clear.
So your check for IsEven looks like this:
return (b & 1) == 0; // Bit 1 not set - number is even
(Note: Depending on the language, Compilers MAY decide to optimize stuff, but in a nutshell, that's it)
Storing state using binary flags allows you to have many "active flags" in one variable, and by accessing it bitwise we can check be binary value of each position. You can also use it to access specific parts of a number if you know how it's stored, here's an example from processing.
I've used it in real life business solutions to store state that is best represented as many related flags. Like proficiency in different kinds of magic :)
Skills:
None (0)
Conjuration (1)
Evocation (2)
Illusion (4)
Necromancy (8)
Alteration (16)
Now I can store what magic wizards are capable of in a single field. If a wizards skills sum up to 13 we know that he knows: Conjuration, Illusion and Necromancy. All of this is easily accessed using bitwise operations. Exploiting what we know about bits and base-2 we can use each bit in a number as a boolean flag, usually to store some kind of related state (like options or magic proficiency, in C# the FlagsAttribute is very helpful.
well...there are a number of instances where you might use bitwise operators. Here's one. The linux system call takes a file path name and a bitmask that specifies the access mode for the file as arguments. Examples: open("somefile", O_RDWR | O_CREAT | O_TRUNC | S_IWUSR), open("somefile", O_RDONLY). The bitwise or operation allows us to specify a lot of information in a single argument, and therefore simplifies the interface to the kernel.
I have a categories table:
id;description;special
----------------------
1;Spares;TRUE
2;Accessories;TRUE
4;Consumables;TRUE
8;Services;TRUE
11;Printer;FALSE
12;Monitor;FALSE
13;Other;FALSE
The special field designates special categories that have fixed ids and cannot be deleted nor modified. I've assigned bitwise OR-able ids to those.
Then I have items, each item belongs to a category (with a 1:n relationship).
Now I'd like to write a stored procedure that takes an input parameter containing an OR-ed combination of ids:
1 I want spare parts
2 I want accessories
4 I want consumables
**5 I want consumables AND spare parts**
etc
If the parameter is NULL, then I want every item regardless of its category.
This is quite easy, say the parameter is called _or_category, then the WHERE clause could be something like:
SELECT
*
FROM
items I
JOIN
categories C ON (C.id = I.category)
WHERE
(_or_category IS NULL) OR (C.special = TRUE AND C.id | _or_categoria = _or_categoria)
;
First problem:
*edit: sorry this is not a problem, since I have C.special=TRUE in the WHERE clause.*
category 12 could be "seen" as id=8 OR 4, thus if I want to select only the consumables, I would get also the monitors!
Second problem:
I don't know how to specify when I want all the items which are NOT a service (cat: 8).
Second problem: I don't know how to
specify when I want all the items
which are NOT a service (cat: 8)
If I understand your question I think you're looking for the bitwise Invert bits ~
for example
C.special = TRUE AND (~C.ID | or_categoria = _or_categoria)
You need
0x01 - Spares
0x02 - Accessories
0x04 - Consumables
0x08 - Services
0x10 - Printer
0x20 - Monitor
0x40 - Other
And all things not services = 0x7F & ~0x08
Edit: If you only want the first 4 things to be flags it is not much different. The first 4 bits are reserved exclusively for your bit comparisons. So you cannot have any additional ids that would require a value in the first 4 bits (from the right)...
0x01 - Spares
0x02 - Accessories
0x04 - Consumables
0x08 - Services
0x10 - Printer
0x20 - Monitor
0x30 - Other
And again, Ax(~Sx) = 0x3F & ~0x08
Is it possible to program in binary?
A friend of mine told me he knows someone who can program in binary. I've never heard of someone programming in binary and a few quick Google searches didn't return anything useful. So I figured I'd turn to the SO community. Does anyone have any info on programming in binary and if possible maybe a quick Hello World example.
Of course. It's more commonly called machine code. It's basically assembly language without the mnemonic devices. Someone who knows assembly very well could program in machine code with additional effort, referring to opcode listings (e.g. x86) as needed.
Would I do it? No. Even assembly is only useful in rare circumstances, and there's no reason (beside demonstrating your skills) to reject the assembler's help.
Since you asked about hello world, you should check out this article. He shows how he wrote, then optimized, an x86 ELF program to output it. It was originally written in nasm then modified in a hex editor.
It's very much possible to memorize machine code equivalent of assembly instructions. Actually, when writing code in assembly language, one often happens to see hex code through machine code monitors, disassemblers, assembly listings, etc. As a result, over time some instructions can be memorized in their hex form without any extra effort.
In the picture an 6502 ROM monitor is seen, where hex code and assembly mnemonics are shown side by side.
Second skill you're going to need is to transform hex code into binary which is quite easy with a trick I'll explain in a bit.
Think of the following instructions:
OPCODE HEX
LDA #imm 0xA9 imm
STA adr 0x85 adr
STA (adr),Y 0x91 adr
LDY #imm 0xA0 imm
With above opcodes memorized only, we can write the following machine code using only pen and paper:
0xA9 0x00
0x85 0x01
0xA9 0x02
0x85 0x02
0xA0 0x00
0xA9 0x01
0x91 0x01
Actually the above is the following assembly code in mnemonic form:
LDA #00
STA $01
LDA #02
STA $02
LDY #00
LDA #01
STA ($01), Y
The above code puts a white pixel at the top-left corner of screen in 6502asm.com assembler/emulator, go ahead and try it out!
Now the trick for converting hexadecimals into binary and vice versa is to work it out only for nibbles (4-bit values).
First, remember how to convert binary into decimal. Every time you see 1, multiply that by its binary power. E.g. 101 would be 4 + 0 + 1 = 5. It can be visualized like this:
1 1 1 1 --> binary points
| | | |
v v v v
8 + 4 + 2 + 1
| | | +---> 2^0 * 1 Ex: 13 is 8 + 4 + 0 + 1
| | +-------> 2^1 * 1 1 1 0 1 -> 1101 (0xD)
| +-----------> 2^2 * 1 Ex: 7 is 0 + 4 + 2 + 1
+---------------> 2^3 * 1 0 1 1 1 -> 0111 (0x7)
With this in mind, and well practiced, the following should be possible:
LDA #00 -> 0xA9 0x00 -> 1010 1001 0000 0000
STA $01 -> 0x85 0x01 -> 1000 0101 0000 0001
LDA #02 -> 0xA9 0x02 -> 1010 1001 0000 0010
STA $02 -> 0x85 0x02 -> 1000 0101 0000 0010
LDY #00 -> 0xA0 0x00 -> 1010 0000 0000 0000
LDA #01 -> 0xA9 0x01 -> 1010 1001 0000 0001
STA ($01),Y -> 0x91 0x01 -> 1001 0001 0000 0001
With some retro computing spirit, motivation and fun, we could actually have written the entire code in binary without writing down the intermediate steps.
On a related note, Paul Allen coded a boot loader for Altair 8800 with pen and paper on an airplane, and possibly had to translate it to binary also with pen and paper: https://www.youtube.com/watch?v=2wEyqJnhec8
There isn't much call for it any more, but it has been done. There was a time when code could be entered into a system in binary from the front console. It was error prone.
I used to have a very short uudecoe program encoded in ASCII which could be prefixed to a UUEncoded file. The resulting file would be self-extracting and could be emailed around. I would expect the machine code was hand done. I can't find it, and don't have a use for it even if I could.
Well of course you can write the binary for the machine code and then enter the machine code via your hex key pad into your computer. I have put together a computer based on the TMS1100.
A simple program to display 5 on the hex LED would be 0001000 0000101 0000001 written in binary converted to machine code that would be 8 5 1 . This program would then run and display 5 on the LED.
You could follow this procedure for far more complex programs using the TMS1100 and I guess programming in binary.
Actually, I think this is very satisfying and rewarding if you are interested in mathematics and programming.
For the brave of heart: you can try getting a MikeOS floppy image and running the monitor.bin program. It allows you to enter hexadecimal opcodes by hand and execute them. For example (as stated on the docs), entering the following instructions:
BE0790 E8FD6F C3 4D00$ will produce a single M on the screen.
There are some esoteric programming languages. They are used as experiments, and are rather impractical, but one, called BrainF**k (yes, it is actually a real thing) uses eight different characters to modify byte values. Those kind of languages are about as close as you can get.