user15552: Supposedly, if an R or S value will equal a "negative" number, one must append zeros to it and alter the "length" descriptor for the value to reflect that.  When manually creating a raw tx how does one determine whether one's R and or S values require the addition of these extra byte(s)?  All conversions I do with a hex calculator always show positive numbers.

user38482: There are unsigned and signed numbers. R + S values are obviously interpreted as signed numbers, and when the first bit of the number is high, then you have a number, which is interpreted as negative. So all signatures' S and R values beginning with "more than 7F" 
Pieter explained it here:
extract:

R and S are signed integers, encoded as a big-endian byte sequence.
They are stored in as few bytes as possible (i.e., no 0x00 padding in
front), except that a single 0x00 byte is needed and even required
when the byte following it has its highest bit set, to prevent it
from being interpreted as a negative number.


user44264: If the first byte is greater than or equal to 0x80 (128), then you need to add a leading zero byte. You can do 0x80 & first_byte. If the result is zero, no padding is needed.

15552: <p>Supposedly, if an R or S value will equal a "negative" number, one must append zeros to it and alter the "length" descriptor for the value to reflect that.  When manually creating a raw tx how does one determine whether one's R and or S values require the addition of these extra byte(s)?  All conversions I do with a hex calculator always show positive numbers.</p>
 38482: <p>There are unsigned and signed numbers. R + S values are obviously interpreted as signed numbers, and when the first bit of the number is high, then you have a number, which is interpreted as negative. So all signatures' S and R values beginning with "more than 7F" </p>

<p>Pieter explained it <a href="http://bitcoin-development.narkive.com/OOU2XVSG/bitcoin-development-who-is-creating-non-der-signatures" rel="nofollow noreferrer">here</a>:
extract:</p>

<ul>
<li>R and S are signed integers, encoded as a big-endian byte sequence.
They are stored in as few bytes as possible (i.e., no 0x00 padding in
front), except that a single 0x00 byte is needed and even required
when the byte following it has its highest bit set, to prevent it
from being interpreted as a negative number.</li>
</ul>
 44264: <p>If the first byte is greater than or equal to 0x80 (128), then you need to add a leading zero byte. You can do 0x80 &amp; first_byte. If the result is zero, no padding is needed.</p>
