IMPORTANT: If you have a particular project (a type of engine) that you are thinking of, the method to get support is via editable project page(s) : MembersPage (required for tech support, otherwise optional)

* Any request without reference to thematically organized project page might be silently ignored. Editable, thematically organized page is required for tech support.

----

Q.

* I have problem with SD logging and dash comms. Dash comes from Bulgarian [LD performance]

* And (claims to) "supports VEMS". Seems it reads Vems protocol, not AIM.

* In dash settings we have to choose KMS protocol and miraculously it works!

* But then comes issue with SD card logger. If it writes .vemslogs dash do not works. If it writes .triggerlogs we cannot convert and open our

datalogs.

** Example .triggerlog file is in attachment. Android converter

just fails with message: Conversion is failed. How to open it?

Triggerlog and vemslog (if not corrupted) can be opened in Vemstune see

Vemstune help vems.hu/vt

One can use other tools, if they work. We support vemstune.

---

Triggerlog

Thanks! Clear. It is not android kind of .triggerlog.... but... why it is there at all? Faster?

* triggerlog does not contain most runtime data. Only trigger events.

** Very special, rarely needed, and unlikely to be of any use from the SD-card. Please, if it opens in VemsTune, and useful for your purposes to watch trigger data, use it. Otherwise neglect it. triggerlog certainly does not contain engine runtime data (like kPa and TPS) so most likely not suitable for most purposes

* So in which way this setting under SD (ECU) logger setup change what happens in comm cable? Because dash, connected to our usual serial 1 cable, just stop to read VEMS values if we:

* 1. enable ECU logger

* 2. It writes .vemslog on SD card. But works if it writes .triggerlog

* May be KMS protocol is similar to AIM and we can use second serial?

** don't know, those should specify who use "KMS" (we don't use that term but it might or might not be same or similar)

The settings that effect the AIM stream sent via 2nd serial port:

* BroadcastDatastreamAimSecondSerial

** note that small changes stop the stream completely

* BroadcastDatastreamAim

Note that it is very easy to see the AIM stream via a TerminalProgram. Every 5th byte is 0xA3

* That is usually enough to see if the stream is being sent. In case of high involvement (should not be necessary) if you have Linux, We can send some program (or C sourcecode) that displays AIM and triggerframe frames ("unescaped", with CRC verification) in hex for more diagnostics.