v2 user specified TxID / RxID possible ?

[Feezex]

Hi @jglim, im trying to send single frame over user specified txID but its just uses cbf specified channel to transmission. I have specified rxID and txID in combobox, some code below show my implementation. Due lack of knowledge i cant handle that. Is it possible to make this happen?

   string selectedTxId = cbTransmitId.SelectedItem.ToString();
   string selectedRxId = cbReceiveId.SelectedItem.ToString();

   if (!int.TryParse(selectedTxId, System.Globalization.NumberStyles.HexNumber, CultureInfo.InvariantCulture, out int txId) ||
       !int.TryParse(selectedRxId, System.Globalization.NumberStyles.HexNumber, CultureInfo.InvariantCulture, out int rxId))

      byte[] response = DiogenesSharedContext.Singleton.Channel.Send(request, true);
                Console.WriteLine($"Send over {selectedTxId} : {BitUtility.BytesToHex(request, true)}");
                Console.WriteLine($"Response over {selectedRxId} : {BitUtility.BytesToHex(response, true)}");

it gaves result of sending data with cbf opened channel eg: 7E1 8 10 10 + request part 1 7E1 8 03 + request part 2

[jglim]

Hi Sergey,

Assuming you're working with UDS, this region might be of interest on the transmit side:

https://github.com/jglim/CaesarSuite/blob/8c7901b623dc788d69577f002cd6ee3bac670aab/Caesar/CaesarConnection/Protocol/UDS.cs#L279

You might be able to achieve that by modifying the active protocol's ComParameters by calling SetParameter with either CP.CanPhysReqId or CP.CanFuncReqId depending on your connected target.

I did not design this with the consideration that the IDs might be changed on the fly, so there'll be issues that come with that. For example the J2534 filters might also need to be reconfigured to allow the messages from the new ID.

[Feezex]

since monaco can use j2534 for multiple connections it must be possible. Point is not to stop active connection but send and receive couple more messages from/to other can ID

[jglim]

I don't doubt that it is possible, though the implementation of the receive side is rather tricky:

The "correct" way to do that is to open another J2534 channel on the same device, which should allow for a different set of filters when it comes to receiving messages. This method is simpler, when you send a message and the ecu is available, you'll get the expected message from your target, and only from your target.

In practice, some vendors don't implement this well and the underlying hardware/dll expects only one channel/session to be used.

This could also be emulated by sharing the same J2534 channel, but you will need to configure the filter mask by bitwise-ORing all the expected receive IDs, then manually check the IDs on every received frame, and dispatch them into their parent emulated channels. This method should not run into compatibility issues, but will be more complicated to implement correctly.

[Feezex]

this can be done by modifying cbf CP_REQUEST_CANIDENTIFIER / CP_RESPONSE_CANIDENTIFIER and its also mets a task. Send gives 10 10 header to first message, second part aint sent at all. How i can get rid of that

[jglim]

Send gives 10 10 header to first message, second part aint sent at all. How i can get rid of that

I'm having difficulty understanding this, as far as I know, the application does not send anything like that. This might have been done at the hardware level when the device is splitting a message per iso15765 to fit in a CAN frame?

[Feezex]

Still trying to find a way. @jglim Can you assist to open second channel?

[jglim]

These are a few options that I can think of, with varying difficulties and costs

(Quoting myself from above)

---

The "correct" way to do that is to open another J2534 channel on the same device, which should allow for a different set of filters when it comes to receiving messages. This method is simpler, when you send a message and the ecu is available, you'll get the expected message from your target, and only from your target.

In practice, some vendors don't implement this well and the underlying hardware/dll expects only one channel/session to be used.

I don't have any hardware that does this correctly, so this isn't something I can work on. I don't like this approach as other users may not have hardware that does this correctly too.

---

This could also be emulated by sharing the same J2534 channel, but you will need to configure the filter mask by bitwise-ORing all the expected receive IDs, then manually check the IDs on every received frame, and dispatch them into their parent emulated channels. This method should not run into compatibility issues, but will be more complicated to implement correctly.

DTS Monaco uses this channel emulation technique; they open the J2534 device in CAN mode instead of isotp, and they have their own isotp stack. However this requires manual handling of isotp details such as framing, reassembly, flow control. It is difficult and labour intensive to write a new C# isotp stack that works accurately, so this also feels like a dead end.

---

Third option which is the least painful is to connect an additional J2534 device (for example, via a Y-cable, just need CAN+, CAN- and GND), then run two instances of Diogenes, which should behave like 2 channels.