VEMS ECU has had internal SD (traditionally upto 4GB, SDHC support added ~2014 for 8..16GB or more) to store logfiles (upto around thousand hours runtime total),

* VemsTune is most often used to capture logfiles interactively,

* external logger can sometimes be useful (that can be used interactively or non-interactively).

----

Originally implemented on STM32F103 and FAT filesystem on SD, using device' built-in RTC (real-time-clock) and USB-device port for mass-storage device.

ECU serial external datalogger (old, STM32 based) :

* request runtime data via (bidirectional, full duplex) 1st serial port of VEMS ECU

* log to SD card

** in .vemslog format

** with correct timestamps if RTC available

* USB mass storage device to PC, so files from SD can be transferred to PC fast (normally without removing SD).

----

Battery powered RTC note:

Although usually easy to find the .vemslog logfile of interest among the last dozen big files (based on file length: hours,minutes,seconds)

* RTC timestamp can be useful if available

* OrangePiPc/DataLogger can get time/date after boot from wireless (gsm /mobile-broadband or wifi), in which case continuous battery power is optional.

** even if network occasionally not available right after boot, time/date will be monotonous

----

2017-05 the STM32 code was ported to Orange PI PC (or compatible lite / one / zero / plus or other H3 similar)

* with optional header-connected I2C RTC (useful if no ntp/GSM/wifi internet or other time-source)

* the immensely powerful device can be "double"-used for many apps simultaneously, even cloud apps: secure wallet, or file sharing, audio/video play/encode or communications / capture (/ motion detect)

* perhaps recording audio/video before/during rally race could log more information about date, environment, vehicle than an RTC would provide,

** and perhaps even running vemstune (although a bit slower than most notebooks, the VT linux build hasn't been too agressively tested) the 512MB - 2048MB RAM versions are certainly capable (have the resources).

----

STM => Orange PI PC notes/differences

* logging to (unix) file instead of self-handled FAT FS on SD block device

** the timestamp is handled automatically

* using high level /dev/ttySx or /dev/ttyUSB0 or similar serial port, instead of stm32's raw UART.

* mainloop: select() instead of busyloop (act nice in a non-cooperative multitasking environment)

----

Brainstorming, random old notes (special, not normally needed or handled differently)

* optional: data relay (via network)

** if serial data is coming without request, sending (relaying) the same RAW data to the TX would make (perhaps) sense.

** This way ECU TX => ARM => VT => ECU RX could be implemented (when no VT, just plug in a dummy DSUB9 with 2-3 connected to close the loop )

** alternatively ARM could be sniffing the ECU TX => VT line (and ARM => ECU commands only activated when commands from VT cease). No serial relay is needed in the ARM for this.

** However, '''ARM best have v3 ECU config (only needed for EGT cal, 75 works well though, as egt calibration is 75 usually)

*** ECU config requested at startup, which might not be available if VT is started before ARM (not the normal usecase, but worths to consider)

----

OrangePiPc/DataLogger with virtual serial port

* network socket not currently supported or tested (or even needed, perhaps)

** socat with pipe can be straightforward, just would need a command line option to disable the tcsetattr()

** or perhaps socat exec trick (so socat would be connected to stdin and stdout also)

----

Other architectures/platforms

* Not currently built to [Risc-V], MIPS, microblaze or soft-cores, but anything running unix/linux should be easy target if necessary, since dependencies are minimal

* esp8266 / esp32 (with SPIFFS, this is the most lightweight lowest consumption easily available smart wifi chip) not currently supported

** usually <16MByte flash would limit logfile size to a few hours - would still help to buffer telemetry data between regular downloads while the bandwidth is low or vehicle is out of range, happens in drone apps and rally,

** using esp8266 / esp32 as a "ser2net" serial to wifi gateway is easy already

----

See also: BuildrootOrangePiPc (fast boot)