Question about SavvyCAN conversion of frame bytes to signed

[bvernham]

I was looking at the code in the utility.h the function static int64_t processIntegerSignal. I am confused how this converts the raw frame data to a signed value. I understand the part about accumulating the bits either big or little endian. But I would have thought after that all that was necessary was to take a two complement of the accumulated?

But then I saw this example on http://socialledge.com/sjsu/index.php/DBC_Format

BO_ 500 IO_DEBUG: 4 IO
SG_ IO_DEBUG_test_unsigned : 0|8@1+ (1,0) [0|0] "" DBG
SG_ IO_DEBUG_test_signed : 8|8@1- (1,-128) [0|0] "" DBG

It states :Signed Signal: A signed signal can be sent by simply applying a negative offset to a signal. Let's add a signed signal to the previous message.

I thought a signed signal meant the encoded bits in the frame for a particular signal represented the two complement of the a signed integer and that an unsigned signal encoded bits represented an unsigned integer?

Any thoughts on this?

A nice feature for savvy can would be able to read in a DBC file and be able to encode a message from the raw engineering units.

I do not think this is possible right now, is it?

PS Savvy CAN and the DUECAN is working great feeding the Teensy4.1. Trying to write the code to convert the incoming frames into engineering units via a parsed DBC file.

Thanks

Bruce

[collin80]

You're right, when it says "signed integer" for a DBC signal it means that the bits are 2s complement signed. I think what they're trying to say about negative offset is that you can get a negative number that way. For instance, it is quite common to send temperature as an unsigned 8 bit value in degrees centigrade. Then you put a -40 offset on it. So, a value of 10 is really -30C. This is still an "unsigned" signal but the offset allows it to go negative anyway. A lot of signals end up like that so that the developers don't have to think about 2's complement numbers. ;)

It is an existing idea to allow sending traffic based on DBC signals that have been defined. I do want to support this at some point but it is currently not implemented.

[bvernham]

Yes you are absolutely correct.. a key point is you can't check overwrite. I was looking for a little more graphable format. I know you can output from a graph so do I just graph all the signals and output them that way? Thanks Bruce ---------- Original Message ---------- From: Collin Kidder ***@***.***> To: collin80/SavvyCAN ***@***.***> Cc: bvernham ***@***.***>, Author ***@***.***> Subject: Re: [collin80/SavvyCAN] Question about SavvyCAN conversion of frame bytes to signed (#363) Date: Tue, 15 Jun 2021 17:01:28 -0700 You're right, when it says "signed integer" for a DBC signal it means that the bits are 2s complement signed. I think what they're trying to say about negative offset is that you can get a negative number that way. For instance, it is quite common to send temperature as an unsigned 8 bit value in degrees centigrade. Then you put a -40 offset on it. So, a value of 10 is really -30C. This is still an "unsigned" signal but the offset allows it to go negative anyway. A lot of signals end up like that so that the developers don't have to think about 2's complement numbers. ;) It is an existing idea to allow sending traffic based on DBC signals that have been defined. I do want to support this at some point but it is currently not implemented. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

…

____________________________________________________________ Sponsored by https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more He Reluctantly Testified. Now His Home Is Burned and He's Gone http://thirdpartyoffers.juno.com/TGL3131/60ca162296d0216220fc0st03vuc1 Lumber Price Shift Suggests a 'Bubble That Has Burst' http://thirdpartyoffers.juno.com/TGL3131/60ca1622ba20f16220fc0st03vuc2 'No Breaking of Bread' During Biden-Putin Meeting http://thirdpartyoffers.juno.com/TGL3131/60ca1622e043f16220fc0st03vuc3

[bvernham]

Last reply was to the incorrect forum. Sorry... I had a case where they defined the message as signed. Was 8 bits with a multiplier of 1 and an offset 0f 0 and had a range of 0 to 255. Can't do that with int8.... If the DBC is defining it a signed signal but the actual encoded bits in the frame are unsigned how does that work? Do you compare against the range versus the range of the bits encoded? Thoughts? Thanks Bruce ---------- Original Message ---------- From: Collin Kidder ***@***.***> To: collin80/SavvyCAN ***@***.***> Cc: bvernham ***@***.***>, Author ***@***.***> Subject: Re: [collin80/SavvyCAN] Question about SavvyCAN conversion of frame bytes to signed (#363) Date: Tue, 15 Jun 2021 17:01:28 -0700 You're right, when it says "signed integer" for a DBC signal it means that the bits are 2s complement signed. I think what they're trying to say about negative offset is that you can get a negative number that way. For instance, it is quite common to send temperature as an unsigned 8 bit value in degrees centigrade. Then you put a -40 offset on it. So, a value of 10 is really -30C. This is still an "unsigned" signal but the offset allows it to go negative anyway. A lot of signals end up like that so that the developers don't have to think about 2's complement numbers. ;) It is an existing idea to allow sending traffic based on DBC signals that have been defined. I do want to support this at some point but it is currently not implemented. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

…

____________________________________________________________ Choose to be safer online. Opt-in to Cyber Safety with NortonLifeLock. Plans starting as low as $6.95 per month.* https://store.netzero.net/account/showService.do?serviceId=nz-nLifeLock&utm_source=mktg&utm_medium=taglines&utm_campaign=nzlifelk_launch&utm_content=tag695&promoCode=A34454

[collin80]

It sounds like it is encoded improperly somewhere then. You're right, a signed 8 bit value can't take 0 through 255 as values but rather -128 to 127. If the DBC file defines it as signed then the code will assume it is signed and the values you get will be interpreted as signed and thus -128 to 127 only. Now, it is possible that the DBC says the range is 0 to 255 but that's a lie. The range for a signal is more or less a suggestion and/or for information purposes only. Technically it's for when you have a program that sends signals and then the range can be used for sweeping the range while sending. But, still, the range values in the DBC file could be set wrong. When actually interpreting signals from a DBC file the range specified is really not relevant. The only relevant thing is what values you could get when actually doing the decoding. A signed 8 bit value will only return -128 to 127. This then can be modified by scaling and offset.

[bvernham]

I agree with you 100%. Luckily we have software spec does to confirm against. DBC file is created after the fact and I am sure full of mistakes. I saw a J1939 message that blew my mind. An 8 bit signal was split between two bytes which can happen) But there are 4 empty bits in between. In either work either of the bytes have to capacity to hold the entire signal contents. Irrespective of "endianness" why would you split it when you have bits in a single byte to contain it with a OEM message (not a standard J1939 message)?

…

---------- Original Message ---------- From: Collin Kidder ***@***.***> To: collin80/SavvyCAN ***@***.***> Cc: bvernham ***@***.***>, Author ***@***.***> Subject: Re: [collin80/SavvyCAN] Question about SavvyCAN conversion of frame bytes to signed (#363) Date: Wed, 23 Jun 2021 18:04:56 -0700 It sounds like it is encoded improperly somewhere then. You're right, a signed 8 bit value can't take 0 through 255 as values but rather -128 to 127. If the DBC file defines it as signed then the code will assume it is signed and the values you get will be interpreted as signed and thus -128 to 127 only. Now, it is possible that the DBC says the range is 0 to 255 but that's a lie. The range for a signal is more or less a suggestion and/or for information purposes only. Technically it's for when you have a program that sends signals and then the range can be used for sweeping the range while sending. But, still, the range values in the DBC file could be set wrong. When actually interpreting signals from a DBC file the range specified is really not relevant. The only relevant thing is what values you could get when actually doing the decoding. A signed 8 bit value will only return -128 to 127. This then can be modified by scaling and offset. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

____________________________________________________________ Sponsored by https://www.newser.com/?utm_source=part&utm_medium=uol&utm_campaign=rss_taglines_more 2 Young Girls Found Dead in Florida Canal http://thirdpartyoffers.juno.com/TGL3131/60d461613d793616117ecst04vuc1 Socialist Scores Upset Win in Buffalo Mayoral Primary http://thirdpartyoffers.juno.com/TGL3131/60d4616160bd1616117ecst04vuc2 Sydney Now in 'Scariest Period' of Pandemic http://thirdpartyoffers.juno.com/TGL3131/60d4616184a7c616117ecst04vuc3