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.

11

With this my goal is seding out the time/date at the connection, without defining any action in the app, The interval is works ofcos, but that not sent out at the start… Any possible way to achieve this ?

In an other post I found that the Initialvalues only sending out when no CAN frame received yet, so my device not sending anything (waiting to this frame to starting the streaming).. The CAN setup frames are arrives…

<!-- App Init frame-->
    <frame id="0x7F">
        <value targetId="211" offset="0" length="4" initialValue="true"></value>        <!-- Time/Date -->
    </frame>
12

Without trigger/action no. You could use Number of Active connections value change trigger with action to send your CAN frame.

13

Using that way already, I just want to eliminate adding extra actions over the descriptor file…,
also the document says:

value ‘initialValue’ attribute (optional)

If this attribute is present, value is written to CAN after connection has been made to the CAN bus.

but this never happened (no outgoing frames) so this means just initialised these variables inside the APP with the “initialValue” ? (then updated with incoming frames..) ?

14

I think it does not understand “true” as a value. Try initialValue=“1” if that launches the CAN frame.

Edit: actually looking at the code, it just sets the value of targetId in RealDash and does not send the frame. This is an error in documentation.

I could pretty easily add the system that initialValue=“true” would read the attached input value and send the frame after connection. This would be on next version of RealDash.

1 Like