This is critical, since all the important information should be distilled into a form where they are available at a quick glance.

This is probably going to take some careful thought into table design in order to partition the tables correctly.

Most of this will be for strategy purposes during the race, which will probably operate on a week's worth of data at most (realistically probably just the previous day). I can see the data being used for ad-hoc queries after the race, in order to explore various characteristics of our design.

I think this has lower priority than getting the GUI complete, as we can always log to a file and then perform ETL afterwards.

One thing we learned from ASC 2018 was that internet connectivity is going to be spotty. Verizon had coverage, but there were times when even that was bad.

We can ETL into another datastore and perform ingestion whenever we have connectivity (or need to perform analytics), but IMO that's out of scope here.

Occasionally, the XBee may disconnect, and so you'll have to backfill your dashboard's data with your stored data.

Or if the app is closed, then you have historical data instead of a blank state.

The GUI should display the speed

I found this extremely useful during ASC 2018, when choosing our cruising speed during the hilly parts.

It's not critical for telemetry, but it is pretty important for strategy. I found that typically, we would end up averaging slower than our target speed by 10-15 kmph, due to the variation in road grades.

The GUI should display the battery pack module stats (voltage, temperature) in a visualization of the pack.

If there is room on the main tab to display this, that would be ideal, otherwise it can go in a separate tab.

Personally, I would like to see something like what Kentucky or Delft has implemented. Especially with our pack layout being split into a master/slave box, I think having the telemetry GUI representation reflect that layout would be really nice.

I propose that we colour code the cells (like Kentucky), and then make the individual battery modules smaller (like Delft).

This physical layout visualization isn't critical for telemetry/strategy, but it helped me understand hardware faults (on the AFE) as well as which areas of the pack required additional attention. I got around this during ASC 2018 with a separate spreadsheet that I marked out the pack layout in, which I would cross-reference against my data readings.

It can also help visualize the temperature distribution inside the pack. 

The GUI should display the minimum module voltage.

At FSGP/ASC 2018, there were some concerns as to whether or not the AFE could handle enabling more than 1 bleed resistor per AFE, given we had observed that the board would heat up a significant amount. A new board revision is supposed to fix this, but we should follow up with this requirement when that is completed.

This would also allow provide us with an interface to remotely enable bleed resistors.

This can probably go underneath a separate tab that isn't the Main Dashboard.

The motor controller gives us the following error flags:

• Hardware Overcurrent
• Software Overcurrent
• DC bus Overvoltage
• Bad motor position hall sequence
• Watchdog reset
• Config read error
• 15 V rail voltage lockout

And the following limit flags (which determine what control loop is limiting output):

• Bridge PWM
• Motor Current
• Velocity
• Bus Current
• Bus Voltage Upper Limit
• Bus Voltage Lower Limit
• Heatsink Temperature

Having this would have been critical for ASC 2018, where we dealt with a lot of issues with our motor controllers.

Since we didn't have solar sense working at ASC 2018, we resorted to measuring the current entering the pack from the BMS (by coasting).

This would be useful because:

1. It allows us to verify that the array is connected
2. View the energy output from the array