What is the intended use of your CAN interface?

Here's a short survey to find out for what purpose you primarily use your CAN tools and which features you have been missing in your software so far.

I mainly use my CAN interface to get engines/control units from newer vehicles running in older vehicles, i.e., by simulating the bus system.

So far, I haven't found anything missing in this interface/software.

Greetings!

I am using the USBtin interface with the good old CAN hacker.
I also have a WGSoft interface lying around here, but I only use it in the car with faster CAN buses.

Interactive data collection:
===========================
The quick brown fox jumps over the lazy dog.
I used to use the CAN-Hack adapter from Fuchs.
Advantage: FTDI drivers are available for many platforms.
Disadvantage: the ASCII-based communication and the FTDI driver.

After having only problems using Android to access the drive CAN bus (see related post in this forum), I then used two PCAN-USB adapters from PEAK. I was already familiar with these from my professional experience.
For Android, I developed my own driver for this purpose, which allows me to now visualize and record data using the mobile phone, and then edit it later on a computer.

I would never use an ASCII-based communication adapter again (due to the high overhead in terms of performance and memory usage).


Embedded systems area:
Please provide the German text you would like me to translate into English. I will then give you only the translation, without any explanations.
The Atmel controller with the MCP2515 proved to be significantly underpowered for the drivetrain's CAN bus, so I would only use CAN controllers connected via non-I²C or similar serial local buses in the future. However, since no new control units are currently needed, things will remain quiet on that front for now...


Aunt Edith says:
Please provide the German text you would like me to translate into English. I will then give you only the translation, without any explanations.
I just realized that we are actually in the software domain here.
Therefore, I would like to reiterate that I develop my own software. In the past, I used C++/MFC for Windows applications; today, I use C#/WPF for Windows and Java for Android development.
Why? Because I haven't found anything else that suits me in terms of usability and features, besides professional tools that cost tens of thousands of euros.

Besides my main work, I develop tools related to diagnostics, bus systems, networking in vehicles, and 'tuning.' For example, I've created a CANdb editor, a tracker for identifying the logical connections between various ECUs, as well as editors for ECU images including characteristic map detection and modification. I also have tuning software that calculates performance based on a parts list (body, engine, transmission), taking into account parameters of the used components such as maximum speed, torque curves, etc.
I've also developed diagnostic testers for the good old K-line-based protocols, in a very traditional way.


Best regards,
candev

Gut, dass die CANhack Hardware RKS+CAN beides implementiert, ASCII Schnittstelle und binär per Windows-Gerätetreiber.

The advantage of the ASCII interface is its ease of use (you can try it out with any terminal program, regardless of the device).
The speed disadvantage will be negligible; no one is going to check bus schedules on a weak mobile phone or a 386 computer.

In addition to speed, the binary interface primarily offers advantages in handling or reacting to CAN messages when developing custom applications.

Best regards, Rainer.

Additional software supported by the RKS+CAN interface via the LAWICEL protocol:

https://txsuite.org/download/t7suite/
https://txsuite.org/download/t8-suite/
https://txsuite.org/download/trionic-can-flasher/
https://txsuite.org/download/trionic-can-flasher/

https://github.com/linux-can