2024 - 2026 SRR Initial Outline


1 Introduction 

1.1 System Purpose 

1.1.1 The Data Acquisition system shall handle driver communication, data transmission, and race strategy generation. 

 

1.2 System Components and Descriptions 

1.2.1 Driver Communication – radio communication between driver, pit team, and timer (FSGP) 

1.2.2 Telemetry – all vehicle sensors, telemetry module, and software that displays data on dashboard 

1.2.3 Race Strategy – software that generates driving recommendations for FSGP and ASC 

1.2.4 TelemetryCAN – CAN bus connecting relevant vehicle sensors and telemetry module 

1.2.5 CarCAN – CAN bus connecting relevant electrical systems and telemetry module 

 

2 General Description 

2.1 System Interfaces 

2.1.1 The driver radio shall accept input from the driver via a push-to-talk button and facilitate two-way communication between the driver and the pit team. 

2.1.2 The telemetry module and vehicle sensors receive power from the Low Voltage System. 

2.1.3 The telemetry module shall accept relevant communication over TelemetryCAN from vehicle sensors pertaining to IMU, temperature, and air flow measurements [add other measurements as needed (battery data, motor/wheel RPM, steering wheel angle, GPS data, Suspension data?)] from various points on the car. 

2.1.4 The telemetry module shall accept relevant communication over CarCAN from other electrical systems pertaining to the car state, battery, battery protection system, motor, and array. 

2.1.5 The telemetry module shall output data to the dashboard [insert rate]. 

[Add inputs/outputs for race strategy.  

Inputs for race strategy: 

  • Telemetry data 
  • Battery state information 
  • Race path/GPS 
  • Environment variables 

Outputs for race strategy: 

  • Driving recommendations regarding speed/energy efficient strategies 
  • Safety Warnings] 

[Add final block diagram. 

Vehicle Sensors -> Telemetry Module -> dashboard + pit team communications] 

 

2.2 System Functions 

2.2.1 The Data Acquisition System shall allow the driver to communicate with the pit team and timer (FSGP). 

2.2.2 The Data Acquisition System shall allow the pit team to view the speed, acceleration, and position of the car. 

2.2.3 The Data Acquisition System shall allow the pit team to view the state of the battery, array, and electrical systems. 

2.2.4 The Data Acquisition System shall present race strategy recommendations to the pit team. 

 

2.3 General Constraints 

2.3.1 The Data Acquisition System shall adhere to regulations in the FSGP and ASC Regulations document. 

2.3.2 The Data Acquisition System shall adhere to all Low Voltage power constraints. 

 

3 Functional Requirements 

3.1 Telemetry 

3.1.1 The telemetry module shall receive messages from CarCAN at a TBD [20Hz] frequency. 

3.1.2 The telemetry module shall receive messages from TelemetryCAN at a TBD [20Hz] frequency. 

3.1.3 The dashboard shall indicate whether protection faults and/or a Safe State have occurred within a TBD [30Hz] time period. 

3.1.4 The dashboard shall indicate if the primary and supplemental battery packs are above/below the appropriate voltage, temperature, and current thresholds [values pending]. 

Temperature: A note should be displayed when the battery temperature is reaching a temperature that may cause damage to itself or surrounding components.  

These temperature ratings are for lithium-ion batteries. 

  • The recommended temperature range is 66-77ºF. If the driver can do something about the battery’s temperature, it might be useful to indicate that it is not within the ideal battery temperature. Thus, the driver can get more power out of the battery before it requires recharging. 

 

  • The display must provide a warning when the battery reaches an unacceptable temperature of less than 32ºF or greater than 113ºF. 

 

 

3.1.5 The Data Acquisition System shall record the current position, speed, and acceleration of the car accurate to a TBD [1Hz] time period. 

3.1.6 The Data Acquisition System shall record the current air flow rate through the cockpit, electrical enclosures, and intake/exhaust vents accurate to a TBD [pending, however 20 to 50 Hz is likely range] time period. 

[Add additional measurements needed for the pit crew/driver to take appropriate action.] 

  • None (for now) 

[Add additional measurements needed by the mechanical team for post-processing.] 

  • None (for now) 

 

3.2 Race Strategy 

3.2.1. (FSGP) The race strategy software shall maximize laps driven given that the car may start with a fully charged battery pack and charging may only occur using the array in designated charging areas. 

The race strategy software shall output an optimal driving speed at a TBD frequency. 

3.2.2. [Add inputs to race strategy software.] 

- Car: motor current, electronics power (76.18), battery capacity (other parameters including motor_power, max_speed, array_power, electronics_power, total_power, battery can be calculated from these inputs) 

- Track: elevation, slope 

- Weather data from API 

- Solar array: number of cells (num_c60, num_e60), temperature coefficients, temperature, intensity_from_sun (from weather data) 

4 Non-functional Requirements 

4.1 Driver Communication 

4.1.1 All communications by the solar car driver must be verbal and hands-free at all times. Hands-free operation is defined as operation where the driver can activate the radio without removing their hands from the steering wheel. 

4.1.2 The team must be in two-way radio communication with the solar car driver at all times. Communications should be maintained between the solar car, the pit area, and the timing area at all times. 

4.1.3 (FSGP) Each team must provide a team member to serve as a timer. This team member must be in radio contact with both the solar car driver and the pit crew. 

 

4.2 Hardware 

4.2.1 The telemetry module will adhere to the constraints of the STM32F413 processor. 

4.2.2 The telemetry module will use 1 CAN bus to interface with CarCAN. 

4.2.3 The telemetry module will use 1 CAN bus to interface with TelemetryCAN. 

4.2.4 The telemetry module will use 1 UART port for debugging. 

4.2.5 The telemetry module will use 1 UART port for XBee module interfacing. 

4.2.6 The telemetry module will use 1 UART port for GPS module interfacing. 

 

Related pages