To convert from hex to decimal, there are many ways to do it in the shell or with an external program.

With bash:

$ echo $((16#FF))
255

with bc:

$ echo "ibase=16; FF" | bc
255

with perl:

$ perl -le 'print hex("FF");'
255

with printf:

$ printf "%d\n" 0xFF
255

with python:

$ python -c 'print(int("FF", 16))'
255

with ruby:

$ ruby -e 'p "FF".to_i(16)'
255

with node.js:

$ node -e "console.log(parseInt('FF', 16))"
255

with rhino:

$ rhino -e "print(parseInt('FF', 16))"
255

with groovy:

$ groovy -e 'println Integer.parseInt("FF",16)'
255

What you actually want to say is:

$ echo "ibase=16; C0" | bc
192

for hex-to-decimal, and:

$ echo "obase=16; 192" | bc
C0

for decimal-to-hex.

You don't need to give both ibase and obase for any conversion involving decimal numbers, since these settings default to 10.

You do need to give both for conversions such as binary-to-hex. In that case, I find it easiest to make sense of things if you give obase first:

$ echo "obase=16; ibase=2; 11000000" | bc
C0

If you give ibase first instead, it changes the interpretation of the following obase setting, so that the command has to be:

$ echo "ibase=2; obase=10000; 11000000" | bc
C0

This is because in this order, the obase value is interpreted as a binary number, so you need to give 10000₂=16 to get output in hex. That's clumsy.

Now let’s work out why your three examples behave as they do.

1. echo "ibase=F;obase=A;C0" | bc

   180

   That sets the input base to 15 and the output base to 10, since a single-digit value is interpreted in hex, according to POSIX. This asks bc to tell you what C0₁₅ is in base A₁₅=10, and it is correctly answering 180₁₀, though this is certainly not the question you meant to ask.

2. echo "ibase=F;obase=10;C0" | bc

   C0

   This is a null conversion in base 15.

   Why? First, because the single F digit is interpreted in hex, as I pointed out in the previous example. But now that you've set it to base 15, the following output base setting is interpreted that way, and 10₁₅=15, so you have a null conversion from C0₁₅ to C0₁₅.

   That's right, the output isn't in hex as you were assuming, it's in base 15!

   You can prove this to yourself by trying to convert F0 instead of C0. Since there is no F digit in base 15, bc clamps it to E0, and gives E0 as the output.

3. echo "ibase=16; obase=A; C0"

   192

   This is the only one of your three examples that likely has any practical use.

   It is changing the input base to hex first, so that you no longer need to dig into the POSIX spec to understand why A is interpreted as hex, 10 in this case. The only problem with it is that it is redundant to set the output base to A₁₆=10, since that's its default value.

It's not just that number, it's any number over 7fffffffffffffff, because it's using 64-bit integers and that's the largest one. 16-digit numbers over that wrap around and become negative (because of two's complement representation of signed integers):

$ echo $((16#7fffffffffffffff))
9223372036854775807
$ echo $((16#7fffffffffffffff + 1))
-9223372036854775808
$ echo $((16#8000000000000000))
-9223372036854775808

Past ffffffffffffffff (aka -1), it wraps back to zero:

$ echo $((16#ffffffffffffffff))
-1
$ echo $((16#ffffffffffffffff + 1))
0
$ echo $((16#10000000000000000))
0

Net result: only the last 16 hex digits actually matter; anything past that gets dropped off the high end of the 64-bit integer representation:

$ echo $((16#0000000000000010))
16
$ echo $((16#10000000000000010))
16
$ echo $((16#ffffffff0000000000000010))
16

Since 1553255926290448384 is 17 digits long, the first digit is being dropped off in this way:

$ echo $((16#1158e460913d00000))
1553255926290448384
$ echo $((16#158e460913d00000))
1553255926290448384
$ echo $((16#121345158e460913d00000))
1553255926290448384