Transmit CAN with scaling

Connectivity RealDash CAN
1

Sorry if this has been covered but I searched a lot for an answer.
I’m using RealDash CAN XML to transmit a MYECU value. Basically just receive it on one ID and send it back out on another. XML looks like this -

...
        <frame id="0x120" endianess="big">
           <value name="MYECU: Value" offset="0" length="2" signed="false" conversion="V/1000"></value>
...
        <frame id="0x121" endianess="big" writeInterval="1000">
           <value name="MYECU: Value" offset="0" length="2" signed="false" conversion="V*1000"></value>
...

It’s a 3 dp signal that I want to display and conversion=“V/1000” does it’s job. But what I send back on ID 0x121 is just the integer value. Say if the Value was 4.234, I just get 4 where what I wanted was 4234 transmitted. In fact it doesn’t matter what I put in the conversion, it seems to be ignored.
Is this a bug, not supported, or am I doing something wrong?

Thanks,
Darren.

2

This could be due that RealDash considers both values to be the same custom input as their names are exactly the same. Try renaming your values in XML to differentiate them from each other.

3

No luck unfortunately.
I changed the name of the Tx signal and used the Input Mapping to set the source of the Tx signal to the value of the Rx signal. The Tx signal displays the correct value, but what’s transmitted in the frame data is still ignoring the conversion.
I tried “v/1000” and “v*1000”, same result.

4

Hmm, onto outgoing frame, try to rename ‘conversion’ into ‘conversionOut’

5

That did the trick!
And using the same signal name for receive and transmit was also fine.

Thanks.

6

The ‘conversion’ should work as ‘conversionOut’ is an internal, non-documented feature. I will check this for next release.

7

I don’t necessarily think it’s a bad thing to use a different tag for scaling Tx values.

I work a lot with CAN and DBC files. In these the factor and offset for a signal is always set as if receiving. Eg. CANInteger * Factor + Offset = RealValue.
When transmitting, a module reading the DBC must reverse this so (RealValue - Offset) / Factor = CANInteger.
A DBC file is similar to how your XML file just lists CAN frames and signals. But a DBC also lists Nodes which then specify which frames a Node transmits and signals it receives. You can then have one DBC for a complete CAN bus of modules and all modules can use the same DBC file to create their firmware for the CAN interface, knowing which node they are.

Because you support so many operators in your conversion (which is great!), I don’t think its feasible to reverse the logic automatically for transmit. You’re also only making a definition for RealDash so there’s no need. But I found it strange that you don’t specifically define which frames are received or transmitted in the XML. I guess this stems back to really using serial comms underneath where RX and Tx are separated. But that’s not the case with CAN.

I’ve only used writeinterval to Tx so far, and this is a way to specifically define a Tx frame in XML.
But RealDash can also Tx a frame if a signal used on the frame is ‘updated’ internally, right? So the source of the signal could be from CAN if a frame is received on that ID, and also internally generated (Eg. Input Mapping) meaning the signal could have two sources?

The one thing I’m very wary of is transmitting a CAN frame on the same ID as another module. But you can’t do this of course as it can clash and crash the whole CAN bus. This can stop a vehicle from driving, not good if you lose power on a freeway. I’m speaking from experience…

8

Thank you for the insights. RealDash transmits a CAN frame in these conditions:

  1. frame has ‘writeInterval’ attribute in XML.
  2. data specified in a frame changes via Actions.
  3. frame has ‘initialValue’ attribute.

Good tip to everyone; be very cautious when sending CAN frames to the vehicle for abovementioned reasons. Typical use-case of RealDash is completely custom system, but keep in mind that you can cause issues to OEM vehicles by sending CAN frames.

I can see the benefit of having separate ‘conversionOut’ attribute. I think I will leave it there and add to the documentation.

9

This thread has been helpful and very close to what I am wanting to do. So i will add my question here.

I would like to pass the tablet GPS speed to my ecumasters black. Would this work? Thanks!

<frame id="401" writeInterval="1000">
  <value targetId="24" units="KPH" offset="0" length="2" conversionout="V*0.1"></value> <!-- gps Speed -->
</frame>
10

Looks good to me, don’t see any problems with quick glance.