blog:car_stuff_pycosworth_configuration

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
blog:car_stuff_pycosworth_configuration [2021/08/18 10:38] – [AEM Wideband AFR Settings] johnblog:car_stuff_pycosworth_configuration [2021/08/18 10:56] (current) – [Configuring PyCosworth] john
Line 1: Line 1:
 ====== PyCosworth Configuration ====== ====== PyCosworth Configuration ======
  
-===== Configuring PyCosworth =====+{{:blog:pycosworth:ford-cosworth-yb-turbo-engine.jpg?400|}}
  
-PyCosworth is a combination of code-reader/sensor reader, data logger and digital dashboard.+[[:blog:car_stuff_pycosworth|PyCosworth]] is a combination of code-reader/sensor reader, data logger and digital dashboard.
  
 The software can be configured to enable or disable most of those options. The software can be configured to enable or disable most of those options.
Line 74: Line 74:
  
 ==== Cosworth ECU Settings ==== ==== Cosworth ECU Settings ====
 +
 +Only valid if **USE_COSWORTH** is set to **True**.
  
 * COSWORTH_ECU_USB * COSWORTH_ECU_USB
Line 79: Line 81:
  
 ==== AEM Wideband AFR Settings ==== ==== AEM Wideband AFR Settings ====
 +
 +Only valid if **USE_AEM** is set to **True**.
  
   * AEM_USB   * AEM_USB
Line 84: Line 88:
  
 ==== Graphics / OLED Display Settings ==== ==== Graphics / OLED Display Settings ====
 +
 +These settings are only valid if the **USE_GRAPHICS** setting is set to **True**. They control how the emulated screen and the physical OLED screen behave, the sensors which are shown and/or their sizes and resolutions.
  
 * GFX_MASTER_SIZE * GFX_MASTER_SIZE
Line 102: Line 108:
 ==== Datalogger Settings ==== ==== Datalogger Settings ====
  
-* LOGGING_HEARTBEAT_TIMER+Datalogger settings are only valid if the **USE_DATALOGGER** variable is set to **True**. These settings configure how the data logging portion of the application works, including the name and location of where sensor data logs are stored. 
 + 
 +  * LOGGING_HEARTBEAT_TIMER
     * The time, in seconds, between update messages sent from the **DataLoggerIO** process to the user interface. This updates the user interface on whether the logger is running or not, or if it has encountered an error (such as disk space). **Reccomendation: 2-3 seconds**     * The time, in seconds, between update messages sent from the **DataLoggerIO** process to the user interface. This updates the user interface on whether the logger is running or not, or if it has encountered an error (such as disk space). **Reccomendation: 2-3 seconds**
  
-* LOGGING_ACTIVE_SLEEP+  * LOGGING_ACTIVE_SLEEP
     * Controls the granularity of the data logs which are written with sensor data. A higher value lowers the frequency at which a line of sensor data is written to disk. A value of **0.1** indicates that 10 lines of log data are written to disk in 1 second. The value of a sensor at the point it is written to disk is dependent on  the refresh value of that sensor. Bear in mind that with the Cosworth ECU particularly, we have a very slow serial baud rate that means we can only do, **at best** 60 single-byte sensor queries per second.     * Controls the granularity of the data logs which are written with sensor data. A higher value lowers the frequency at which a line of sensor data is written to disk. A value of **0.1** indicates that 10 lines of log data are written to disk in 1 second. The value of a sensor at the point it is written to disk is dependent on  the refresh value of that sensor. Bear in mind that with the Cosworth ECU particularly, we have a very slow serial baud rate that means we can only do, **at best** 60 single-byte sensor queries per second.
     * All sensors have a different refresh value (it doesn't make sense to look up battery voltage every 100 milliseconds, for example), and these are written in the back-end ECU support classes:     * All sensors have a different refresh value (it doesn't make sense to look up battery voltage every 100 milliseconds, for example), and these are written in the back-end ECU support classes:
Line 111: Line 119:
     * <code>../iomodules/sensors/AEM.py</code>     * <code>../iomodules/sensors/AEM.py</code>
  
-* LOGGING_SLEEP+  * LOGGING_SLEEP
     * How long to sleep, in seconds, before responding to an 'Activate Logging' signal. Again, a compromise between CPU over-use and responsiveness. **Reccomendation: 1-2 seconds**     * How long to sleep, in seconds, before responding to an 'Activate Logging' signal. Again, a compromise between CPU over-use and responsiveness. **Reccomendation: 1-2 seconds**
  
-* LOGGING_DIR+  * LOGGING_DIR
     * The directory where sensor logs should be written to. If the directory does not exist, it will be attempted to be created the first time the application runs. This should be in a location that the application can write to, not in a system directory or an administrative user.     * The directory where sensor logs should be written to. If the directory does not exist, it will be attempted to be created the first time the application runs. This should be in a location that the application can write to, not in a system directory or an administrative user.
  
-* LOGGING_FILE_PREFIX+  * LOGGING_FILE_PREFIX
     * The first part of the filename of your sensor log files - this will be suffixed with an auto-incrementing numeric value. **Reccomendation: "pycosworth_"**     * The first part of the filename of your sensor log files - this will be suffixed with an auto-incrementing numeric value. **Reccomendation: "pycosworth_"**
  
-* LOGGING_FILE_SUFFIX+  * LOGGING_FILE_SUFFIX
     * The last part of your sensor log file names. **Reccomendation: ".csv"**     * The last part of your sensor log file names. **Reccomendation: ".csv"**
 +
 +==== Watchdog Timer Settings ====
 +
 +Watchdog timer settings are only relevant if the **USE_PI_WATCHDOG** variable is set to **True**. These settings configure how the Pi interacts with and responds to status information from the //Super Watchdog V2// addon.
 +
 +  * WATCHDOG_HEARTBEAT_TIMER
 +    * The amount of time, in seconds, to send a //"still alive!"// message to the watchdog timer addon to prevent the Pi from being automatically reset. If the Pi stops sending alive messages, the watchdog will reset the power and cause the Pi to reboot, in the scenario the programme has crashed and become unresponsive. **Reccomendation: 30 seconds**
 +
 +  * WATCHDOG_POWER_TIMER
 +    * How often, in seconds, to ask the watchdog timer/UPS addon to check the incoming power state to the Pi. This should be frequent enough to detect problems in the supply voltage (in the case where the ignition it turned off) without using too much processor time to do so. **Reccomendation: 5 seconds**
 +
 +  * WATCHDOG_POWER_SHUTDOWN_TIMER
 +    * How long after detecting the input voltage to the Pi has failed before beginning to shut down the system and save any open data logs. This should be short enough that the battery on the watchdog/UPS addon does not expire, but long enough to keep the Pi from shutting down constantly in the middle of starting and stopping the engine multiple times in the space of a few seconds or minutes. This setting will keep the Pi running (from the watchdog battery) for this amount of seconds after the power has been turned off. //Note: if power is detected as restored before the timer expires, the shutdown is aborted//. **Reccomendation: 60-180 seconds**
 +
 +  * WATCHDOG_POWER_NOMINAL
 +    * How many volts should be considered nominal to power the Pi. If less than this number of volts is detected, then consider the input power or ignition to have been disconnected and after the next //WATCHDOG_POWER_TIMER// interval, start a shutdown timer of //WATCHDOG_POWER_SHUTDOWN_TIMER// seconds. **Reccomendation: 5.0 (standard Pi input voltage)**
 +
 +----
 +
 +Back to main [[:blog:car_stuff_pycosworth|PyCosworth]] page.
  • blog/car_stuff_pycosworth_configuration.1629279516.txt.gz
  • Last modified: 2021/08/18 10:38
  • by john