'Engineers of Innovation Wiki' - User contributions [en]

Throttle

2026-05-02T10:56:45Z

Fromeijn: fix example

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the [[CAN-bus|CAN bus]] using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The [[CAN-bus|CAN bus]] need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed. To summarize:

# Lever in the forward position
# Lever in the center position
# Lever in de backward position
#

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 40Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] and [https://triforce-docs.readthedocs.io/en/latest/canbus/canbus.html Here]. The throttle supports the following modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Filtered Duty Cycle || 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Duty Cycle|| 0x02 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x03 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x04 || RPM || Specify the rpm for forward and backwards in two int16_t's
|-
|Current Control Relative
|0x05
|Percentage
|None lever in the maximum forward position is 100%
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

==== Example command: ====
<syntaxhighlight lang="bash" line="1" start="69">
# duty cycle
cansend can0 337#AA0200000000

# 120A current control
cansend can0 337#AA0304B004B0

# relative current control
cansend can0 337#AA0500000000
</syntaxhighlight>

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Throttle

2026-04-04T19:45:16Z

Fromeijn:

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the [[CAN-bus|CAN bus]] using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The [[CAN-bus|CAN bus]] need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed. To summarize:

# Lever in the forward position
# Lever in the center position
# Lever in de backward position
#

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 40Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] The throttle supports the following modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Duty Cycle|| 0x00 || Percentage || None lever in the maximum forward position is 100%
|-
|Filtered Duty Cycle|| 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x02 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x03 || RPM || Specify the rpm for forward and backwards in two int16_t's
|-
|Current Control Relative
|0x04
|Percentage
|None lever in the maximum forward position is 100%
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

==== Example command: ====
<syntaxhighlight lang="bash" line="1" start="69">
# duty cycle
cansend can0 337#AA0000000000

# 120A current control
cansend can0 337#AA0204B004B0

# relative current control
cansend can0 337#AA0400000000
</syntaxhighlight>

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Foils

2026-04-02T10:22:32Z

Fromeijn:

The foils of the solar boat is a system that is comprised of the following:

* Wing design
* Foil assembly
* [[Autopilot]]

A small overview is given below what any of these signify in the hydrofoils.

== Wing design ==
[[File:Wing.jpg|thumb|The designed wing to be used on the solar boat.]]
The wing design is based on the calculation of the airfoil database website: http://airfoiltools.com/plotter/index

From this database an implementation has been made into matlab to tweak some parameters as well as a plot for generating the wing shape.

The matlab scripts are on the [https://git.engineersofinnovation.nl git] and can be found [https://git.engineersofinnovation.nl/matlab-scripts/Hydrofoil_Design here].

== Foil assembly ==
The foil assembly connects the wing to the foil mast and then to the hull of the boat.
[[File:Foil assembly.gif|center|thumb|230x230px|Scaled down for showing moving of the foil assembly.]]

== Autopilot ==
The [[autopilot]] is the control electronics that controls the servos of the foil assembly. This a signal PCB with that measures the angle of the solar boat and adjust accordingly towards keeping the hull above the water.

== Height sensors ==
We use ultrasonic height sensors for sensing distance between water and our hull. Currently we use cheap A02 RS485 sensors from DYP.

Datasheets can be found https://www.dypcn.com/uploads/A02-Datasheet.pdf and https://www.dypcn.com/uploads/A02-Output-Interfaces.pdf

Data from this sensor is being processed by our RS485 to CAN interface

= CAN Messages =
All multi-byte values are little-endian. Any state byte not listed maps to <code>Unknown</code> on the receiver side.
{| class="wikitable"
!Message
!CAN ID
!DLC
!Byte
!Field
!Type
!Values / Range
|-
|ServoRudderSetpoint
|0x010
|2
|0–1
|Setpoint
|u16 LE
|1000–2000
|-
|HeightSensorFrontLeft
|0x011
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|distance in mm
|-
|HeightSensorFrontRight
|0x012
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|distance in mm
|-
|HeightSensor (placement TBD)
|0x013
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|distance in mm
|-
|HeightSensor (placement TBD)
|0x014
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|distance in mm
|-
|ServoRudderStatus
|0x020
|3
|0
|State
|u8 enum
|0=Uninitialized, 1=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Current setpoint
|u16 LE
|1000–2000
|-
|ServoRudderCommand
|0x021
|1
|0
|Command
|u8 enum
|0=Initialize
|}

Foils

2026-04-02T08:08:06Z

Fromeijn:

The foils of the solar boat is a system that is comprised of the following:

* Wing design
* Foil assembly
* [[Autopilot]]

A small overview is given below what any of these signify in the hydrofoils.

== Wing design ==
[[File:Wing.jpg|thumb|The designed wing to be used on the solar boat.]]
The wing design is based on the calculation of the airfoil database website: http://airfoiltools.com/plotter/index

From this database an implementation has been made into matlab to tweak some parameters as well as a plot for generating the wing shape.

The matlab scripts are on the [https://git.engineersofinnovation.nl git] and can be found [https://git.engineersofinnovation.nl/matlab-scripts/Hydrofoil_Design here].

== Foil assembly ==
The foil assembly connects the wing to the foil mast and then to the hull of the boat.
[[File:Foil assembly.gif|center|thumb|230x230px|Scaled down for showing moving of the foil assembly.]]

== Autopilot ==
The [[autopilot]] is the control electronics that controls the servos of the foil assembly. This a signal PCB with that measures the angle of the solar boat and adjust accordingly towards keeping the hull above the water.

== Height sensors ==
We use ultrasonic height sensors for sensing distance between water and our hull. Currently we use cheap A02 RS485 sensors from DYP.

Datasheets can be found https://www.dypcn.com/uploads/A02-Datasheet.pdf and https://www.dypcn.com/uploads/A02-Output-Interfaces.pdf

Data from this sensor is being processed by our RS485 to CAN interface

= CAN Messages =
All multi-byte values are little-endian. Any state byte not listed maps to <code>Unknown</code> on the receiver side.
{| class="wikitable"
!Message
!CAN ID
!DLC
!Byte
!Field
!Type
!Values / Range
|-
|ServoRudderSetpoint
|0x010
|2
|0–1
|Setpoint
|u16 LE
|1000–2000
|-
|HeightSensorFrontLeft
|0x011
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|TBD (raw, unit undecided)
|-
|HeightSensorFrontRight
|0x012
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|TBD (raw, unit undecided)
|-
|HeightSensor (placement TBD)
|0x013
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|TBD (raw, unit undecided)
|-
|HeightSensor (placement TBD)
|0x014
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|TBD (raw, unit undecided)
|-
|ServoRudderStatus
|0x020
|3
|0
|State
|u8 enum
|0=Uninitialized, 1=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Current setpoint
|u16 LE
|1000–2000
|-
|ServoRudderCommand
|0x021
|1
|0
|Command
|u8 enum
|0=Initialize
|}

Foils

2026-03-31T18:00:18Z

Fromeijn:

The foils of the solar boat is a system that is comprised of the following:

* Wing design
* Foil assembly
* [[Autopilot]]

A small overview is given below what any of these signify in the hydrofoils.

== Wing design ==
[[File:Wing.jpg|thumb|The designed wing to be used on the solar boat.]]
The wing design is based on the calculation of the airfoil database website: http://airfoiltools.com/plotter/index

From this database an implementation has been made into matlab to tweak some parameters as well as a plot for generating the wing shape.

The matlab scripts are on the [https://git.engineersofinnovation.nl git] and can be found [https://git.engineersofinnovation.nl/matlab-scripts/Hydrofoil_Design here].

== Foil assembly ==
The foil assembly connects the wing to the foil mast and then to the hull of the boat.
[[File:Foil assembly.gif|center|thumb|230x230px|Scaled down for showing moving of the foil assembly.]]

== Autopilot ==
The [[autopilot]] is the control electronics that controls the servos of the foil assembly. This a signal PCB with that measures the angle of the solar boat and adjust accordingly towards keeping the hull above the water.

= CAN Messages =
All multi-byte values are little-endian. Any state byte not listed maps to <code>Unknown</code> on the receiver side.
{| class="wikitable"
!Message
!CAN ID
!DLC
!Byte
!Field
!Type
!Values / Range
|-
|ServoRudderSetpoint
|0x010
|2
|0–1
|Setpoint
|u16 LE
|1000–2000
|-
|HeightSensorFrontLeft
|0x011
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|TBD (raw, unit undecided)
|-
|HeightSensorFrontRight
|0x012
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|TBD (raw, unit undecided)
|-
|HeightSensor (placement TBD)
|0x013
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|TBD (raw, unit undecided)
|-
|HeightSensor (placement TBD)
|0x014
|3
|0
|State
|u8 enum
|0=NotPluggedIn, 1=ModbusError, 2=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Height value
|u16 LE
|TBD (raw, unit undecided)
|-
|ServoRudderStatus
|0x020
|3
|0
|State
|u8 enum
|0=Uninitialized, 1=Operational, 0xFF=Unknown
|-
|
|
|
|1–2
|Current setpoint
|u16 LE
|1000–2000
|-
|ServoRudderCommand
|0x021
|1
|0
|Command
|u8 enum
|0=Initialize
|}

Rudder

2025-11-10T20:43:10Z

Fromeijn:

The motor currently in use in the rudder is the Lehner 30100/12 with a NTC Temp. Sensor (B 25/100 3988 ±1%) installed. There is also a [[Hub Sensor|magnetic encoder]] placed behind the motor.

=== Rudder-controller ===
To accommodate the new rudder design and its features, a controller is needed. With this controller we want to enable a multiple of functionalities that will help with the integrate cooling system and the control of the back-foil.

The design should therefore have the following requirements:
{| class="wikitable"
|+Requirements for the rudder-controller
!Feature
!Description
!Electrical connections
|-
|Power
|Power will be coming from the [[CAN-bus]]
It is important that the inrush of the connected motors must not decrease the [[CAN-bus]] voltage.
|4-pins connector that hosts the [[CAN-bus]] and Power
|-
|Communication
|The board will use the [[CAN-bus]] to communicate and retrieve commands
|4-pins connector that hosts the [[CAN-bus]] and Power
|-
|Back-foil control
|A TMC2209 or comparable is needed that supports [https://www.analog.com/en/lp/001/building-better-stepper-motor-system.html StallGuard™]
|Available on the platform connected to the back-foil motor
|-
|Back-foil motor
|The [https://www.omc-stepperonline.com/nema-11-stepper-l-31mm-w-rear-shaft-gear-ratio-14-1-planetary-gearbox-11hs12-0674d-pg14 Nema 11 Stepper motor] fits the rudder design to control the back-foil.
|4-pins connector for power and control
{| class="wikitable mw-collapsible mw-collapsed"
|+Connection information
!Color
!Function
|-
|Red
|B+
|-
|Black
|A+
|-
|Blue
|B-
|-
|Green
|A-
|}
|-
|Water pump
|The available waterpump: [https://nl.aliexpress.com/i/32870145384.html ZC-A210](24 V version)
|2-pins connector
{| class="wikitable mw-collapsible mw-collapsed"
|+Connection information
!Color
!Function
|-
|Red
|24v
|-
|Black
|GND
|}
|-
|Flowmeter
|We have 2 flowmeters for inlet and outlet: [https://nl.aliexpress.com/item/1005006813605315.html?gatewayAdapt=glo2nld#nav-specification DWS-MH-02]
|6-pins connector
{| class="wikitable mw-collapsible mw-collapsed"
|+Connection information
!Color
!Function
|-
|Red
|5-24v
|-
|Black
|GND
|-
|Green
|50k Temp
|-
|Yellow
|Pulse out
|-
|Red and Blue
|TDS sensor
|}
|-
|Platform
|Right now(10-11-2025) the [https://www.duet3d.com/duet3toolboard1lc Duet 3 1LC] is available to use for prototyping.
Other options are [https://www.amazon.nl/-/en/BIGTREETECH-EBB-36-communication-STM32G0B1CBT6/dp/B0B1JBH8R5?dib=eyJ2IjoiMSJ9.u31ykTjqWpKnziWf-HlcFHPpjlpjFLlMqEGFS3VpEFoPMYB-ntfAoEM9qNUGVXtrwW3rHJDEbeMY6RI2Lnt_Jtbu8Ol-uZWBKFFmNuOY6nmBhfIGwyNLOpUkqAEEaxYpMGk7qOkz7OW_7PpcIhFg62Eqz-3x8XMlKipaq8vMtd6wiodByGlve9HrpBM9C38kSyzMRwFGneHUDJH7guP-7ENePjKpuOrLC7x83iRWhyoga6SRJgVPjpXohVvbPL6_Za6mVcNkD2xQyB3WFCoZoBKtCA469K9urtnIuDb5imU.4tJLo0B2n2WNGx17gcoOJ0Y6ITTdpQukln7ZNMG0YR8&dib_tag=se&keywords=ebb36&qid=1762803999&sr=8-1&th=1 EBB 36] and [https://mellow.klipper.cn/en/docs/ProductDoc/ToolBoard/fly-sht36/sht36/ SHT36 with TMC2209]
|Host listed connections above.
|}

MPPT

2025-06-02T14:56:49Z

Fromeijn:

The Maximum Power Point Trackers (MPPT) are the abdomens of the SolarBoat (BoII) that gives the battery juice from the solar panels.

The MPPTs are self made, where the hardware can be found on the altium365 [https://engineers-of-innovation.365.altium.com workspace] and the software on [https://git.engineersofinnovation.nl/boat-fw/mppt-software Git].

== What is a MPPT? ==
A MPPT (Maximum Power Point Tracker) is a device that ensures that a solar panel is used at the most efficient point of its I-V curve. The I-V curve of a solar panel can be redrawn into an P-V curve by summing the voltage and current, resulting in the voltage at which the panel generates the most power. Because the output of the MPPT is connected to a battery (which is a very constant voltage source) any adjustments in the dutycycle of the MPPT influence the voltage over the solar panel, making it possible to steer the panel towards its maximum power point.

== PCBs ==
[[File:2023-07-17 Updated MPPTS WHITEBG.png|thumb|815x815px|Deck layout with corresponding MPPTs ID per panel.]]
There are probably 8 MPPT PCBs in total. Where 4 are used in the current SolarBoat. The picture on the right shows the layout of the solar panels with the corresponding MPPTs.
{| class="wikitable"
|+
!MPPT
!ID
!State
!Notes:
|-
|1
|3
|Reseve
|Channel 3 broken
|-
|2
|5
|In boat
|Second
|-
|3
|4
|In boat
|Third
|-
|4
|2
|In boat
|Most forward (Channel 1 not used)
|-
|5
|3
|In boat
|Forth, Channel 1 broken(LTC4444)
|-
|6
|1
|Reserve
|Diodes of buck broken
|-
|7
|7
|Reserve
|Harvested for donor componends
|}
Note: Most reward position not populated ATM!

MPPT

2025-06-02T14:56:09Z

Fromeijn:

The Maximum Power Point Trackers (MPPT) are the abdomens of the SolarBoat (BoII) that gives the battery juice from the solar panels.

The MPPTs are self made, where the hardware can be found on the altium365 [https://engineers-of-innovation.365.altium.com workspace] and the software on [https://git.engineersofinnovation.nl/boat-fw/mppt-software Git].

== What is a MPPT? ==
A MPPT (Maximum Power Point Tracker) is a device that ensures that a solar panel is used at the most efficient point of its I-V curve. The I-V curve of a solar panel can be redrawn into an P-V curve by summing the voltage and current, resulting in the voltage at which the panel generates the most power. Because the output of the MPPT is connected to a battery (which is a very constant voltage source) any adjustments in the dutycycle of the MPPT influence the voltage over the solar panel, making it possible to steer the panel towards its maximum power point.

== PCBs ==
[[File:2023-07-17 Updated MPPTS WHITEBG.png|thumb|815x815px|Deck layout with corresponding MPPTs ID per panel.]]
There are probably 8 MPPT PCBs in total. Where 4 are used in the current SolarBoat. The picture on the right shows the layout of the solar panels with the corresponding MPPTs.
{| class="wikitable"
|+
!MPPT
!ID
!State
!Notes:
|-
|1
|3
|Reseve
|Channel 3 broken
|-
|2
|5
|In boat
|Second
|-
|3
|4
|In boat
|Third
|-
|4
|2
|In boat
|Most forward (Channel 1 not used)
|-
|5
|3
|In boat
|Forth Channel 1 broken(LTC4444)
|-
|6
|1
|Reserve
|Diodes of buck broken
|-
|7
|7
|Reserve
|Harvested for donor componends
|}
Note: Most reward position not populated ATM!

MPPT

2025-06-02T14:50:30Z

Fromeijn:

The Maximum Power Point Trackers (MPPT) are the abdomens of the SolarBoat (BoII) that gives the battery juice from the solar panels.

The MPPTs are self made, where the hardware can be found on the altium365 [https://engineers-of-innovation.365.altium.com workspace] and the software on [https://git.engineersofinnovation.nl/boat-fw/mppt-software Git].

== What is a MPPT? ==
A MPPT (Maximum Power Point Tracker) is a device that ensures that a solar panel is used at the most efficient point of its I-V curve. The I-V curve of a solar panel can be redrawn into an P-V curve by summing the voltage and current, resulting in the voltage at which the panel generates the most power. Because the output of the MPPT is connected to a battery (which is a very constant voltage source) any adjustments in the dutycycle of the MPPT influence the voltage over the solar panel, making it possible to steer the panel towards its maximum power point.

== PCBs ==
[[File:2023-07-17 Updated MPPTS WHITEBG.png|thumb|815x815px|Deck layout with corresponding MPPTs ID per panel.]]
There are probably 8 MPPT PCBs in total. Where 4 are used in the current SolarBoat. The picture on the right shows the layout of the solar panels with the corresponding MPPTs.
{| class="wikitable"
|+
!MPPT
!ID
!State
!Notes:
|-
|1
|3
|Reseve
|Channel 3 broken
|-
|2
|5
|In boat
|Second
|-
|3
|4
|In boat
|Third
|-
|4
|2
|In boat
|Most forward (Channel 1 not used)
|-
|5
|3
|In boat
|Channel 1 broken(LTC4444)
|-
|6
|1
|Reserve
|Diodes of buck broken
|-
|7
|7
|Reserve
|Harvested for donor componends
|}
Note: Most reward position not populated ATM!

Datalogger

2025-05-03T21:46:39Z

Fromeijn: added GNSS can messages

The datalogger is a PCB that stores the [[CAN-bus]] data and shows the data on-screen and sends this data to one of the [[Linux servers|EoI-servers]].

The datalogger is quite complex since it is an embedded Linux platform as well as a screen. The embedded platform makes use of a root file system. Compiling of this file system and any modifications are discussed below.

The screen makes use of cross-compiling QT and is on itself quite the big project for compiling and modifying the generated [[Dashboard|GUI]] for the screen. Therefore one can read more about this topic at [[QT Creator Setup|QT Creator Setup.]]

== Datalogs format ==
As of October '22 the datalogger [[Dashboard|GUI]] is accessing the [[CAN-bus]] data and creating the logfiles and writing them onto its filesystem. The delimiter of the logfile format is a space, this is done to support the http://www.gnuplot.info/ software. This should probably be delimited with a comma or something else.

A snipped of a logfile is given below:<pre>2022-08-27-09-46-55 807280 47.8 -25.4 3.09 28.5 96 3.99 32.6411 -16.9088 15.2 261
2022-08-27-09-46-56 807530 47.8 -24.9 3.09 28 96 3.99 32.6411 -16.9088 15.2 261
2022-08-27-09-46-56 807680 47.8 -24.9 3.45 28.3 96 3.99 32.6411 -16.9088 15.2 261
2022-08-27-09-46-57 807910 47.8 -25.9 3.29 29.2 96 3.99 32.6411 -16.9089 15.2 261
2022-08-27-09-46-57 808090 47.8 -26.2 2.98 29.2 96 3.99 32.6411 -16.9089 15.2 261
2022-08-27-09-46-58 808340 47.8 -25.9 3.4 29.4 96 3.99 32.6411 -16.9089 15.2 260
2022-08-27-09-46-58 808560 47.8 -24.9 2.98 27.9 96 3.99 32.6411 -16.9089 15.2 260
2022-08-27-09-46-59 808740 47.8 -26 3.02 29 96 3.99 32.6411 -16.909 15.2 261
</pre>
{| class="wikitable"
|+
!Date and Time
!Time since start
!Battery voltage <code>[V]</code>
!Battery current netto <code>[A]</code>
!Battery current in <code>[A]</code>
!Battery current out <code>[A]</code>
!SoC <code>[%]</code>
!Highest cell voltage <code>[V]</code>
!GPS latitude
!GPS longitude
!GPS speed <code>[km/h]</code>
!GPS track
|-
|2022-08-27-09-46-55
|807280
|47.8
| -25.4
|3.09
|28.5
|96
|3.99
|32.6411
|<nowiki>-16.9088</nowiki>
|15.2
|261
|}

== Rootfs ==
The datalogger uses a Debian 10 root file system (rootfs), this page walks you through the steps of setting this up and making modifications.

This process has been automated, this is described in the datalogger rootfs repository https://git.engineersofinnovation.nl/datalogger/rootfs

If you'd like do all the steps manually by all means, please continue reading.

=== Creating a Debian filesystem ===
To create a filesystem we use debootstrap. This guide has been tested on Ubuntu 18.04 and Debian 10 Host machines.

==== 1. Install the required dependencies ====
<code>sudo apt update && sudo apt install debootstrap qemu-user-static binfmt-support</code>
====2. Create a new directory 'debian-fs' and enter it====
<code>mkdir ~/Documents/Datalogger/rootfs</code>

<code>cd ~/Documents/Datalogger/rootfs</code>

====3. run the first stage bootstrap====
<code>debootstrap --no-check-gpg --arch=armhf --foreign --include apt,kmod,lsof,ssh,wget,dialog buster rootfs <nowiki>http://deb.debian.org/debian/</nowiki></code>

====4. set up emulation by copying the qemu executable====
<code>sudo cp ./qemu-arm-static rootfs/usr/bin</code>

====5. run the second stage debootstrap ====
<code>sudo chroot rootfs /debootstrap/debootstrap --second-stage</code>

====6. Configure the rootfs for your board, run the following script====
<pre><nowiki>#</nowiki>!/bin/sh

<nowiki>#</nowiki> Modification from acmesystems acqua.sh, please visit their website for great documentation! (acmesystems.it)

<nowiki>#</nowiki> Directory contains the target rootfs

TARGET_ROOTFS_DIR="rootfs"

<nowiki>#</nowiki> Board hostname

filename=$TARGET_ROOTFS_DIR/etc/hostname

echo eoi-datalogger > $filename

<nowiki>#</nowiki> bashrc user/hostname color (optional)

filename=$TARGET_ROOTFS_DIR/root/.bashrc

echo >> $filename

echo "PS1='\${debian_chroot:+(\$debian_chroot)}\[\033[01;96m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\\$ '" >> $filename

<nowiki>#</nowiki> Default name servers

filename=$TARGET_ROOTFS_DIR/etc/resolv.conf

echo nameserver 8.8.8.8 > $filename

echo nameserver 8.8.4.4 >> $filename

<nowiki>#</nowiki> Default network interfaces

filename=$TARGET_ROOTFS_DIR/etc/network/interfaces

echo >> $filename

<nowiki>#</nowiki>echo auto eth0 >> $filename

echo allow-hotplug eth0 >> $filename

echo iface eth0 inet dhcp >> $filename

echo hwaddress ether 00:04:25:12:34:56 >> $filename #eth0 MAC address

echo >> $filename

echo auto wlan0 >> $filename

echo iface wlan0 inet dhcp >> $filename

echo wireless-essid any >> $filename

echo pre-up wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf -B >> $filename

echo post-down killall -q wpa_supplicant >> $filename

<nowiki>#</nowiki> configure Wi-Fi AP

filename=$TARGET_ROOTFS_DIR/etc/wpa_supplicant.conf

touch $filename

echo ctrl_interface=/var/run/wpa_supplicant > $filename

echo ap_scan=1 >> $filename

echo >> $filename

echo network={ >> $filename

echo 'ssid="testnaam"' >> $filename

echo 'psk="testtest"' >> $filename

echo } >> $filename

<nowiki>#</nowiki> Set the the debug port

filename=$TARGET_ROOTFS_DIR/etc/inittab

echo T0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100 >> $filename

<nowiki>#</nowiki> Set rules to change wlan dongles

filename=$TARGET_ROOTFS_DIR/etc/udev/rules.d/70-persistent-net.rules

echo SUBSYSTEM=='"net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"' > $filename

<nowiki>#</nowiki> microSD partitions mounting

filename=$TARGET_ROOTFS_DIR/etc/fstab

echo /dev/mmcblk0p1 /boot vfat noatime 0 1 > $filename

echo /dev/mmcblk0p2 / ext4 noatime 0 1 >> $filename

echo proc /proc proc defaults 0 0 >> $filename

<nowiki>#</nowiki> Add the standard Debian non-free repositories useful to load

<nowiki>#</nowiki> closed source firmware (i.e. WiFi dongle firmware)

filename=$TARGET_ROOTFS_DIR/etc/apt/sources.list

echo deb <nowiki>http://deb.debian.org/debian/</nowiki> buster main contrib non-free > $filename

echo deb-src <nowiki>http://deb.debian.org/debian/</nowiki> buster main contrib non-free >> $filename
</pre>

====7. Install required packages ====
```

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt update</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt install -y net-tools udev iputils-ping ifupdown isc-dhcp-client ca-certificates wpasupplicant firmware-ralink wvdial iw resolvconf libssl-dev ppp autossh</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt install -y locales adduser nano usbutils can-utils i2c-tools git fonts-dejavu gpsd gpsd-clients libqgpsmm-dev libqgpsmm23 minicom picocom python3 python3-pip python3-numpy libsocketcan-dev psmisc moreutils</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt install -y libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa libglu1-mesa-dev libegl1-mesa libegl1-mesa-dev libgles2-mesa-dev mesa-common-dev mesa-utils libgbm-dev libgbm1 libbz2-dev libdrm-dev libgles2-mesa</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt install -y qt5-default qtdeclarative5-* qml-module-qtquick* qml-module-qtquick2 qtquickcontrols5-* qtserialbus5-* qttools5-* qtbase5-* libqt5svg5-* libqtwebkit-* qtmultimedia5-* qmlscene qml gstreamer1.0-omx libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt build-dep qt4-x11 -y</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt build-dep libqt5gui5 -y</code>

====8. set a root password====
<code>sudo chroot rootfs passwd</code>

==== 9. remove the qemu binary====
<code>sudo rm rootfs/usr/bin/qemu-arm-static</code>

====10. download and apply the patchfiles====
<code>wget <nowiki>https://git.engineersofinnovation.nl/datalogger/rootfs/-/raw/master/patches/ssh_patch.patch</nowiki></code>

<code>wget <nowiki>https://git.engineersofinnovation.nl/datalogger/rootfs/-/raw/master/patches/ssh_patch_client.patch</nowiki></code>

<code>wget <nowiki>https://git.engineersofinnovation.nl/datalogger/rootfs/-/raw/master/patches/gpsd_patch.patch</nowiki></code>

<code>wget <nowiki>https://git.engineersofinnovation.nl/datalogger/rootfs/-/raw/master/patches/4g_patch.patch</nowiki></code>

<code>sudo patch -p1 < ./patches/ssh_patch.patch</code>

<code>sudo patch -p1 < ./patches/ssh_patch_client.patch</code>

<code>sudo patch -p1 < ./patches/gpsd_patch.patch</code>

<code>sudo patch -p1 < ./patches/4g_patch.patch</code>

====11. Other stuff====
PPP setup?

https://github.com/sixfab/Sixfab_PPP_Installer

Daemons and services for gui and other scripts?

== CAN bus ID Overview ==
<syntaxhighlight lang="text">
0x100 EoI Battery start
0x10F EoI Battery end

0x200 EoI GNNS info, u8 fix (bool); u8 sats; u8 sats used
0x201 EoI GNNS f32 speed, kmh; f32 direction, degrees
0x202 EoI GNNS f64 Latitude, degrees
0x203 EoI GNNS f64 Longitude, degrees
0x204 EoI GNNS date time, u16 year, u8 month, u8 day, u8 hour, u8 minute, u8 second

0x302 MG Battery
0x402 MG Battery
0x482 MG Battery cell voltage

0x700 MPPT start
0x77F MPPT end

0x0900 THROTTLE To VESC
0x1337 THROTTLE Status

0x0909 VESC Status message 1
0x0E09 VESC Status message 2
0x0F09 VESC Status message 3
0x1009 VESC Status message 4
0x1B09 VESC Status message 5
</syntaxhighlight>

Throttle

2024-10-07T18:44:22Z

Fromeijn: /* Setting the Control Mode over CAN */ Off by one error

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the CAN bus using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The CAN bus need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed. To summarize:

# Lever in the forward position
# Lever in the center position
# Lever in de backward position
#

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 10Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] The throttle supports four modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Duty Cycle|| 0x00 || Percentage || None lever in the maximum forward position is 100%
|-
|Filtered Duty Cycle|| 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x02 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x03 || RPM || Specify the rpm for forward and backwards in two int16_t's
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

==== Example command: ====
<syntaxhighlight lang="bash" line="1" start="69">
cansend can2 337#AA0000000000
</syntaxhighlight>

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Motordriver

2024-09-11T11:00:43Z

Fromeijn: added dimentions to backup motor driver

Our new boat will be powered with a BLDC (brushless direct current) motor motor instead of a brushed motor, which will make the drivetrain more efficient. This will require a new, more complicated, controller. Efficiency is the most important factor in this design, not only because of the limited power of the solar panels, but an efficient motor controller also produces less heat which ensures easier cooling techniques.

== Requirements ==
Because the motor (driver) is primarily used during the Solar Sport One (SSO) races, they should comply with their regulations (Link)

To reduce the development time spent on the embedded software, the motor driver was made compatible with the VESC BLDC driver software project. This software can do sensorless field-oriented control (FOC) with minimal development effort. All specifications of the motor driver are summarized below:

* VESC compatible hardware
* As efficient as possible; >99.5% at around 1kW of motor power
* Up to 5kW with minimal cooling
* Max power up to 15kW
* Modular design for easier future updates
* Fully isolated data interfaces
* Upgrade path for more advanced motor control (FPGA)
* Input power between 32.5 and 58 V DC, 48 V DC nom.
* High ambient temperature est. 70° C
* Interface communication
** CANbus
** UART, for debugging purposes

== Power stage ==
The most important part of the design for efficiency are the MOSFETs driving the motor, and is therefore the starting point of the design. MOSFETs were chosen on a figure of merit (FOM) based on their on-resistance RDS(on) over their Gate charge QG. This list of devices is dominated by GaN-based transistors, the top contenders of which were included in more sophisticated losses estimation.

GaN FETs have slightly different power loss parameters than conventional silicon MOSFETs as there is no body diode present in the semiconductor structure, which means there are no reverse recovery losses, something that is a significant loss especially for large and fast switching devices. The rest of the power losses are quite similar and were calculated for the FETs with the highest FOM. An example of the power loss for four parallel EPC2218s, in a three-phase bridge configuration, is shown in the pie chart below.

[[File:2109111532 Pie.png|center|frameless|1000x1000px|

]]

While this efficiency is quite good, a problem with cooling these small power MOSFETs at higher powers is foreseen. To reduce the losses and spread the heat out over a larger surface area, a configurable power-stage was implemented which can switch between 4 and 8 parallel devices. Efficiency calculations of both implementations are plotted below.

[[File:2109111547 Eff.png|center|frameless|1000x1000px|[[File:2109111551 per-FET.png|center|frameless|1000x1000px]]]]

And while the difference in efficiency seems quite small between the two implementations, the real benefit comes when the power dissipation per MOSFET, and thus the ease of cooling, is plotted.

[[File:2109111551 per-FET.png|center|frameless|1000x1000px]]

At high powers about one third of the cooling per FET is required by switching to the 16-FET per bridge configuration.

== Power Circuit Layout ==
GaN FETs also have the potential for very high switching speeds and low dead-time , which in turn increases the efficiency. These factors however are highly dependent on parasitic inductance and thus the layout of the power-stage is of utmost importance. The image below shows two parallel low-side and two parallel high-side MOSFETS with their ceramic decoupling capacitors.
[[File:Layout inductance overview.png|center|frameless|1000x1000px|

]]

The low inductance layout used is based around reducing magnetic field loop area (in gray) as much as possible, this is achieved by interleaving opposite current paths and making sure current return paths flow on adjacent layers.

Eurocircuits is the perfect assembler for these boards, as their impressive 0.125 mm clearance on 60 um (2 OZ) thick copper is impossible to get at other poolable PCB services. This with small 0.4mm vias make sure that both the DC resistance and the parasitic inductance can be as low as possible.

The rest of the layout consists of a double mirror-symmetric set of 8 MOSFETS with the low-side FETs near the driver, which is positioned in the middle, the switching layout with all four layers can be seen below.

[[File:PCB Animated right.webp|center|frameless|1000x1000px]]

The final layout shown below consists of one phase per PCB with large copper planes to accept 10mm copper busbar, the far end has a connection point for a single motor wire. The near end has a right-angle connector to connect back up to the controller PCB.
[[File:Phase-scaled.jpg|thumb|Single GaN half bridge with 16 MOSFETs]]

== Controller ==
The heart of the logic is situated on the controller board shown below. It is based around an STM32, which is used to run the embedded software from the VESC project. The supported communication protocols are CAN and RS485. The three GaN phases are connected as shown at the top of the image. An FPGA is present to process the incoming delta-sigma current signals for controlling the phases.
[[File:Controller.jpg|thumb|Controller PCB of the motordriver]]

== Electrolytic Capacitor mount ==
To have the decoupling capacitors as close to the switching action as possible, they are mounted on top of the copper busbars running past all the phases as shown below. Their PCB layout is symmetrical on top and bottom so that the board can be flipped to accommodate both sides of the Phase-PCB. The mounting holes on these PCBs are there to potentially accommodate heat sinks for better heat dissipation.
[[File:Image029.jpg|center|frameless]]

== Current Sensors ==
The Current sensors use an external large sense resistor, as temperature swings would decrease the accuracy of PCB mount shunt resistors. The current sensor boards consist of a simple analogue current shunt amplifier feeding back analogue signals directly to the MCU. These amplifiers, however, have a hard time dealing with the large common mode jumps seen at the output of the motor driver. A future proof solution to this is an isolated delta sigma ADC which digitizes the shunt voltage directly, this requires some signal processing on the FPGA which will be added in future software implementation.

[[File:Current Shunt-scaled.jpg|center|frameless|1000x1000px|

\\

]]

== Software ==
The git repo can be found on Gitlab

== Backup motor driver ==
Our backup motor driver is the [https://trampaboards.com/1x-vesc-75v-300a-black-anodised-non-conductive-cnc-housing--375-each-p-26627.html Trampa VESC 75V 300A] data sheet can be found [https://trampaboards.com/resources/manuals/256.pdf here] and [https://trampaboards.com/resources/manuals/267.pdf here]

Motordriver

2024-05-08T10:07:06Z

Fromeijn: added backup motor driver

Battery

2024-03-25T18:31:08Z

Fromeijn: /* 0x102 */ update soc times 100 since it does otherwise not fit in uint16_t

This page contains the information about the EoI battery development, everything from the requirements to the implementation can be found here.

== What is the battery? ==
The battery is the energy buffer of the boat, it stores the energy coming in from the solar panels and provides a constant voltage for the motor path and peripheral electronics. The battery consists of multiple parts:

* Battery cells
* Battery management system (BMS)

The BMS makes sure that the battery cells can't be overcharged or over-discharged, as this might damage them and present dangerous situations. Besides monitoring the voltage a BMS usually monitors the current and temperature as well.

== Technical regulations (as per September 2022) ==

* Maximum nominal voltage: 58,8V (14S lithium-ion)
* Maximum capacity: 1,5 kWh (= 5400 MJ)
* All battery cells must be commercially available
* The BMS must monitor the battery voltage and current
* The BMS must be capable of shutting down the system
* The BMS must be able to monitor charge and discharge currents
* The BMS must have a means to limit over-current in charge and discharge paths
* The BMS must monitor all individual cells
* All electrical systems must be provided with a fuse in series connection with the main battery ('Main fuse')
* The battery must be fused
* The BMS must be fused

== Specifications ==
{| class="wikitable"
|+Functional requirements
!ID
!Specifiction
!Value
!Pass/Fail
|-
|
|Nominal pack voltage
|<code><= 58,8V</code>
|
|-
|
|Maximum capacity
|<code>1,5 kWh</code>
|
|-
|
|Monitor (pack) voltage
|
|
|-
|
|Monitor (pack) current
|
|
|-
|
|Monitor (pack) temperature
|>> 1 sensor (8)
|
|-
|
|Limit overcurrent in (dis)charge path
|
|
|-
|
|Capable of shutting down the whole system
|
|
|-
|
|CAN-bus communication
|<code>5V / 1 Mbit</code>
|
|-
|
|Internal cell balancing
|
|
|-
|
|Charge and discharge paths can be operated simultaneously
|
|
|-
|
|Motor and MPPT should be enabled independently
|
|
|-
|
|The battery should be enabled with a N.O. contact
|open = off
closed = on
|
|-
|
|Separate enable contact for Motor path (output) (Optional: Software disable only)
|
|
|-
|
|Battery should be fully disabled (all outputs disabled) by emergency switch
|
|
|-
|
|Shelf life (Save battery mode)
|>= 1 year (<code>2.8mA max</code>)
|
|-
|
|Humidity sensor
|
|
|-
|
|Galvanic separation of safety path (bilge and horn)
|
|
|-
|
|(Optional) I.M.U.
|
|
|-
|
|(Optional) Phase change cooling hardware
|
|
|}
{| class="wikitable"
|+Electrical requirements
!ID
!Specification
!Value
!Pass/Fail
|-
|0
|Motor path (output)
|<code>60V / 300A</code>
|
|-
|1
|Charge path (input)
|<code>60V / 50A</code>
|
|-
|2
|Peri path (output)
|<code>24V / 2.5A</code>
|
|-
|3
|Safety path (output) (bilge and horn)
|<code>24V / 4A</code>
|
|}
{| class="wikitable"
|+Environmental requirements
!ID
!Specification
!Value
!Pass/Fail
|-
|0
|Ambient operating temperature
|0 - 50 °C
|
|-
|1
|Ingress protection
|IP67 or better
|
|}

== Battery Management System ==
The Battery Management System (BMS) is the brains of the battery and makes sure to manage the battery so it is Dedier proof and does not catch on fire.

The BMS has different functionalities on the PCB and therefore different settings. Since these settings are extensive (especially with the Cell Voltage Monitoring (CVM) chip, this chip does more than only measuring the cell voltages but we will be calling it the CVM from now for better readability.

The BMS has different hardware components that is used in the EoI-battery, these are shown in their corresponding figures throughout the page. Shown below is the full battery system with cells in the box.
[[File:Battery in box.png|center|thumb|Battery box]]

=== Hardware ===
The full BMS system consist of at least three PCBs that are:

* Main board
* Current sense board for the discharge
* Charge path board

Each of the hardware are further elaborated in their own sections.

==== Main board ====
[[File:Bms pcb top view.jpg|thumb|691x691px|BMS PCB top view]]
The main board (shown right) is big brain of the battery system. On the main board there are multiple ICs with their own configurations and applications, namely:

* Cell Voltage Measurement IC
* ADC
* Microprocessor
* ...

[[File:Current sense pcb top view.jpg|thumb|Current sense PCB top view]]
[[File:Charge path PCB top view.jpg|thumb|Charge path PCB top view]]

=== CVM ===
The CVM that is used on the BMS is the [https://www.ti.com/product/BQ76952 BQ76952], located in the middle of the main board. This CVM-chip has an extensive list of configurations and features which makes it cumbersome to scroll through the code to know which features are enabled and which safety configurations are made. Therefore a list is generated with a description of the used configuration below.

These are preliminary configurations and could be changed through the course of time and should be changed accordingly here as well.
[[File:FUSE pin.png|thumb|FUSE pin configuration of the CVM IC.|570x570px]]
{| class="wikitable"
|+
!Short description
!Configuration
!Long description
|-
|Min Blow Fuse Voltage
|STACK: 60.2V(4.3V per cell)
|Permanent faults the device and enables FUSE pin to trigger the fuse.
FUSE pin stays on indefinitely and thus manual intervention is needed.
|-
|PF_FUSE
|Enabled
|Whenever a permanent fail occurs the FUSE pin should also be triggered.
|-
|Internal regualtors 1 & 2
|Disabled
|Regulator 1 and 2 are disabled since we do not use that with the CVM on the BMS.
|-
|Pre-regulator REG0
|Disabled
|Pre regulator is used to generate voltages for regulators 1 & 2.
|-
|CFETOFF
|Disabled
|CFETOFF pin is not used on the BMS.
|-
|TS1,2,3
|18k resistor model & 18k pull-up resistor internal
Used for cell protection
|Temperature pins are configured to be used in cell temperature protection
|-
|DFETOFF
|DFETOFF pin is configured as a termistor input
18k resistor model & 18k pull-up resistor internal

Used for cell protection
|DFETOFF can have different functions and is used for temperature measurement as a termistor input.
|-
|DDSG
|Configured as analogue discharge enable
|CVM IC can determine if the battery may be discharged. This pin activates the discharge path if everything is within spec
|-
|DA
|Resolution measured current: 0.1mA
Resolution measured voltage: 10mV

Internal temperature not used for cell/FET protection
|DA configuration specifies the units for measuring the current and voltage. And can configure if the internal temperature readout should be used for cell protection.
|-
|VCELL
|Disable cell protection on cells 14 and 15
|Configures which cell should be used for cell protection and which cell should be ignored. Cell 14 and 15 are shorted since EoI uses a 14s battery.
|-
|FET settings
|Disabled
|The CVM IC can drive its own FETs, as in the MOSFETs can directly be driven by the chip itself since it can run in standalone mode.
|-
|FET charge pump
|Disabled
|N/A EoI
|-
|Shutdown internal temperature
|80C
|If measured internal temperature of the CVM is above 80C than the CVM should go into shutdown mode.
|-
|Over voltage protection
|Over voltage: 4.25V
Delay: 2000ms

Over voltage reset: 4.00V
|Over voltage protection triggers alert after Delay resets trigger after reset voltage
|-
|Under voltage protection
|Under voltage: 2.8V
Delay: 2000ms

Under voltage reset: 3.00V
|Under voltage protection triggers alert after Delay resets trigger after reset voltage
|-
|Permanent failure under voltage protection
|Under voltage: 2.5V
Delay: 5000ms
|Permanent failure under voltage protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure over voltage protection
|Over voltage: 4.3V
Delay: 5000ms
|Permanent failure over voltage protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure over temperature protection
|Temperature: 90C
Delay: 5000ms
|Permanent failure over temperature protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure VSSF protection
|VSSF: 100mV
Delay: 5000ms
|Permanent failure over VSSF triggers alert after Delay. VSSF is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure 2LVL protection
EDIT: Should not have to use.
|Delay: 5000ms
|Permanent failure over 2LVL triggers alert after Delay. 2LVL is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure LFOF protection
|Delay: 5000ms
|Permanent failure over LFO oscillator frequency deviates from expected value after Delay triggers alert. LFOF is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure HWMX
|Delay: 5000ms
|Permanent failure for input MUX used for OV, UV protection if check fails and fails after Delay trigger alert.
Needs manual intervention for reset
|-
|Over temperature protection for charge
|Temperature: 60C
Recovery: 55C
|Triggers fail and disables charge path until Recovery
|-
|Under temperature protection for charge
|Temperature: 0C
Recovery: 5C
|Triggers fail and disables charge path until Recovery
|-
|Over temperature protection for discharge
|Temperature: 70C
Recovery: 65C
|Triggers fail and disables discharge path until Recovery
|-
|Under temperature protection for discharge
|Temperature: -40C
Recovery: -35C
|Triggers fail and disables discharge path until Recovery
|-
|Over temperature protection FET
|Temperature: 80C
Recovery: 75C
|Triggers fail and disables discharge path until Recovery
|-
|Over temperature protection internal
|Temperature: 70C
Recovery: 65C
|Triggers fail and disables CVM until Recovery
|-
|Under temperature protection internal
|Temperature: -20C
Recovery: -15
|Triggers fail and disables CVM path until Recovery
|-
|Balancing configuration minimum cell voltage
|3.60V
|Minium cell voltage before balancing
|-
|Balancing cell voltage delta
|10mV
|Minimum cell voltage between cell before stopping balancing (or start balancing if bigger than)
|-
|Number of cells balancing simultaneously
|7 cells
|CVM supports multiple cell balancing up to 16 cells.
|}

== Open questions ==

* Do the MPPTs have to be modified for the 14S battery?
*Integrated or seperate charge/discharge paths? (I've got a slight preference for seperate pcb's)

== CAN ID's ==

=== 0x100 ===
float rPackCurrent_A

float rPerriCurrent_A

=== 0x101 ===
float rChargeCurrent_A

float rDischargeCurrent_A

=== 0x102 ===
uint16 * 100 rSOC_pct

uint32 rErrorFlags

uint16 rBalancingStatus

=== 0x103 ===
uint16 * 1000 rCellVoltages_V_1, rCellVoltages_V_2, rCellVoltages_V_3, rCellVoltages_V_4,

=== 0x104 ===
uint16 * 1000 rCellVoltages_V_5, rCellVoltages_V_6, rCellVoltages_V_7, rCellVoltages_V_8,

=== 0x105 ===
uint16 * 1000 rCellVoltages_V_9, rCellVoltages_V_10, rCellVoltages_V_11, rCellVoltages_V_12,

=== 0x106 ===
uint16 * 1000 rCellVoltages_V_13, rCellVoltages_V_14, rPackVoltage_V, rStackVoltage_V

=== 0x107 ===
int8 rBattTemps_1, rBattTemps_2, rBattTemps_3, rBattTemps_4

int8 rICTemp_degC

uint8 rBatteryState

uint8 rChargeState

uint8 rMotorState
=== 0x108 ===
uint32 uptime ms

uint32 unused

CAN-bus

2024-03-18T20:37:52Z

Fromeijn:

The communication between the electronics within the [[Solar boat (boii)|solar boat]] is build upon the CAN-bus protocol, where the [[datalogger]] logs the CAN messages. Pinout of our Binder connectors are:

# Brown VCC (24 V)
# White CAN H
# Blue CAN L
#Black GND
#Safety

== Battery (MG) CAN-format (No longer used) ==
As of now the MG electronics [[battery]] is used in the [[Solar boat (boii)|solar boat]]. Although a new battery is being developed, this MG battery is still in use (as of September '22). Therefore the battery format is given here below.
{| class="wikitable"
|+
!Node-ID
!Index
!Subindex
!Data
!Type
!Resolution
|-
|0x302
|0x2005
|0x01
|Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x02
|Current <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x03
|Current Discharge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x04
|Current Charge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x05
|State-of-Charge <code>[%]</code>
|int8_t
|1 <code>[%/LSB]</code>
|-
|
|
|0x06
|
|
|
|-
|
|
|0x07
|Time to Go <code>[min]</code>
|uint16_t
|1 <code>[min/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x402
|0x2005
|0x09
|Cell Temperature High <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0A
|
|
|
|-
|
|
|0x0B
|Cell Temperature Low <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0C
|Cell Voltage High <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0D
|Cell Voltage Low <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0E
|BMS State
|uint32_t
|
|-
|
|
|0x0F
|Temperature Collection <code>[°C]</code>
|4x uint8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x482
|0x2000
|Cell nr
|Cell <code>[Cell_nr]</code> Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x202
|Don't Care
|Don't Care
|Power Level <code>[%]</code>
|uint8_t
|1 <code>[%/LSB]</code>
|}

CAN-bus

2024-03-18T19:28:54Z

Fromeijn: add pinout canbus, removed information that is no longer true

The communication between the electronics within the [[Solar boat (boii)|solar boat]] is build upon the CAN-bus protocol, where the [[datalogger]] logs the CAN messages. Pinout of our Binder connectors are:

# Shield
# Brown VCC (24 V)
# Black GND
# White CAN H
# Blue CAN L

== Battery (MG) CAN-format (No longer used) ==
As of now the MG electronics [[battery]] is used in the [[Solar boat (boii)|solar boat]]. Although a new battery is being developed, this MG battery is still in use (as of September '22). Therefore the battery format is given here below.
{| class="wikitable"
|+
!Node-ID
!Index
!Subindex
!Data
!Type
!Resolution
|-
|0x302
|0x2005
|0x01
|Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x02
|Current <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x03
|Current Discharge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x04
|Current Charge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x05
|State-of-Charge <code>[%]</code>
|int8_t
|1 <code>[%/LSB]</code>
|-
|
|
|0x06
|
|
|
|-
|
|
|0x07
|Time to Go <code>[min]</code>
|uint16_t
|1 <code>[min/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x402
|0x2005
|0x09
|Cell Temperature High <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0A
|
|
|
|-
|
|
|0x0B
|Cell Temperature Low <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0C
|Cell Voltage High <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0D
|Cell Voltage Low <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0E
|BMS State
|uint32_t
|
|-
|
|
|0x0F
|Temperature Collection <code>[°C]</code>
|4x uint8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x482
|0x2000
|Cell nr
|Cell <code>[Cell_nr]</code> Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x202
|Don't Care
|Don't Care
|Power Level <code>[%]</code>
|uint8_t
|1 <code>[%/LSB]</code>
|}

Battery

2024-03-05T08:22:11Z

Fromeijn: typo

This page contains the information about the EoI battery development, everything from the requirements to the implementation can be found here.

== What is the battery? ==
The battery is the energy buffer of the boat, it stores the energy coming in from the solar panels and provides a constant voltage for the motor path and peripheral electronics. The battery consists of multiple parts:

* Battery cells
* Battery management system (BMS)

The BMS makes sure that the battery cells can't be overcharged or over-discharged, as this might damage them and present dangerous situations. Besides monitoring the voltage a BMS usually monitors the current and temperature as well.

== Technical regulations (as per September 2022) ==

* Maximum nominal voltage: 58,8V (14S lithium-ion)
* Maximum capacity: 1,5 kWh (= 5400 MJ)
* All battery cells must be commercially available
* The BMS must monitor the battery voltage and current
* The BMS must be capable of shutting down the system
* The BMS must be able to monitor charge and discharge currents
* The BMS must have a means to limit over-current in charge and discharge paths
* The BMS must monitor all individual cells
* All electrical systems must be provided with a fuse in series connection with the main battery ('Main fuse')
* The battery must be fused
* The BMS must be fused

== Specifications ==
{| class="wikitable"
|+Functional requirements
!ID
!Specifiction
!Value
!Pass/Fail
|-
|
|Nominal pack voltage
|<code><= 58,8V</code>
|
|-
|
|Maximum capacity
|<code>1,5 kWh</code>
|
|-
|
|Monitor (pack) voltage
|
|
|-
|
|Monitor (pack) current
|
|
|-
|
|Monitor (pack) temperature
|>> 1 sensor (8)
|
|-
|
|Limit overcurrent in (dis)charge path
|
|
|-
|
|Capable of shutting down the whole system
|
|
|-
|
|CAN-bus communication
|<code>5V / 1 Mbit</code>
|
|-
|
|Internal cell balancing
|
|
|-
|
|Charge and discharge paths can be operated simultaneously
|
|
|-
|
|Motor and MPPT should be enabled independently
|
|
|-
|
|The battery should be enabled with a N.O. contact
|open = off
closed = on
|
|-
|
|Separate enable contact for Motor path (output) (Optional: Software disable only)
|
|
|-
|
|Battery should be fully disabled (all outputs disabled) by emergency switch
|
|
|-
|
|Shelf life (Save battery mode)
|>= 1 year (<code>2.8mA max</code>)
|
|-
|
|Humidity sensor
|
|
|-
|
|Galvanic separation of safety path (bilge and horn)
|
|
|-
|
|(Optional) I.M.U.
|
|
|-
|
|(Optional) Phase change cooling hardware
|
|
|}
{| class="wikitable"
|+Electrical requirements
!ID
!Specification
!Value
!Pass/Fail
|-
|0
|Motor path (output)
|<code>60V / 300A</code>
|
|-
|1
|Charge path (input)
|<code>60V / 50A</code>
|
|-
|2
|Peri path (output)
|<code>24V / 2.5A</code>
|
|-
|3
|Safety path (output) (bilge and horn)
|<code>24V / 4A</code>
|
|}
{| class="wikitable"
|+Environmental requirements
!ID
!Specification
!Value
!Pass/Fail
|-
|0
|Ambient operating temperature
|0 - 50 °C
|
|-
|1
|Ingress protection
|IP67 or better
|
|}

== Battery Management System ==
The Battery Management System (BMS) is the brains of the battery and makes sure to manage the battery so it is Dedier proof and does not catch on fire.

The BMS has different functionalities on the PCB and therefore different settings. Since these settings are extensive (especially with the Cell Voltage Monitoring (CVM) chip, this chip does more than only measuring the cell voltages but we will be calling it the CVM from now for better readability.

The BMS has different hardware components that is used in the EoI-battery, these are shown in their corresponding figures throughout the page. Shown below is the full battery system with cells in the box.
[[File:Battery in box.png|center|thumb|Battery box]]

=== Hardware ===
The full BMS system consist of at least three PCBs that are:

* Main board
* Current sense board for the discharge
* Charge path board

Each of the hardware are further elaborated in their own sections.

==== Main board ====
[[File:Bms pcb top view.jpg|thumb|691x691px|BMS PCB top view]]
The main board (shown right) is big brain of the battery system. On the main board there are multiple ICs with their own configurations and applications, namely:

* Cell Voltage Measurement IC
* ADC
* Microprocessor
* ...

[[File:Current sense pcb top view.jpg|thumb|Current sense PCB top view]]
[[File:Charge path PCB top view.jpg|thumb|Charge path PCB top view]]

=== CVM ===
The CVM that is used on the BMS is the [https://www.ti.com/product/BQ76952 BQ76952], located in the middle of the main board. This CVM-chip has an extensive list of configurations and features which makes it cumbersome to scroll through the code to know which features are enabled and which safety configurations are made. Therefore a list is generated with a description of the used configuration below.

These are preliminary configurations and could be changed through the course of time and should be changed accordingly here as well.
[[File:FUSE pin.png|thumb|FUSE pin configuration of the CVM IC.|570x570px]]
{| class="wikitable"
|+
!Short description
!Configuration
!Long description
|-
|Min Blow Fuse Voltage
|STACK: 60.2V(4.3V per cell)
|Permanent faults the device and enables FUSE pin to trigger the fuse.
FUSE pin stays on indefinitely and thus manual intervention is needed.
|-
|PF_FUSE
|Enabled
|Whenever a permanent fail occurs the FUSE pin should also be triggered.
|-
|Internal regualtors 1 & 2
|Disabled
|Regulator 1 and 2 are disabled since we do not use that with the CVM on the BMS.
|-
|Pre-regulator REG0
|Disabled
|Pre regulator is used to generate voltages for regulators 1 & 2.
|-
|CFETOFF
|Disabled
|CFETOFF pin is not used on the BMS.
|-
|TS1,2,3
|18k resistor model & 18k pull-up resistor internal
Used for cell protection
|Temperature pins are configured to be used in cell temperature protection
|-
|DFETOFF
|DFETOFF pin is configured as a termistor input
18k resistor model & 18k pull-up resistor internal

Used for cell protection
|DFETOFF can have different functions and is used for temperature measurement as a termistor input.
|-
|DDSG
|Configured as analogue discharge enable
|CVM IC can determine if the battery may be discharged. This pin activates the discharge path if everything is within spec
|-
|DA
|Resolution measured current: 0.1mA
Resolution measured voltage: 10mV

Internal temperature not used for cell/FET protection
|DA configuration specifies the units for measuring the current and voltage. And can configure if the internal temperature readout should be used for cell protection.
|-
|VCELL
|Disable cell protection on cells 14 and 15
|Configures which cell should be used for cell protection and which cell should be ignored. Cell 14 and 15 are shorted since EoI uses a 14s battery.
|-
|FET settings
|Disabled
|The CVM IC can drive its own FETs, as in the MOSFETs can directly be driven by the chip itself since it can run in standalone mode.
|-
|FET charge pump
|Disabled
|N/A EoI
|-
|Shutdown internal temperature
|80C
|If measured internal temperature of the CVM is above 80C than the CVM should go into shutdown mode.
|-
|Over voltage protection
|Over voltage: 4.25V
Delay: 2000ms

Over voltage reset: 4.00V
|Over voltage protection triggers alert after Delay resets trigger after reset voltage
|-
|Under voltage protection
|Under voltage: 2.8V
Delay: 2000ms

Under voltage reset: 3.00V
|Under voltage protection triggers alert after Delay resets trigger after reset voltage
|-
|Permanent failure under voltage protection
|Under voltage: 2.5V
Delay: 5000ms
|Permanent failure under voltage protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure over voltage protection
|Over voltage: 4.3V
Delay: 5000ms
|Permanent failure over voltage protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure over temperature protection
|Temperature: 90C
Delay: 5000ms
|Permanent failure over temperature protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure VSSF protection
|VSSF: 100mV
Delay: 5000ms
|Permanent failure over VSSF triggers alert after Delay. VSSF is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure 2LVL protection
EDIT: Should not have to use.
|Delay: 5000ms
|Permanent failure over 2LVL triggers alert after Delay. 2LVL is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure LFOF protection
|Delay: 5000ms
|Permanent failure over LFO oscillator frequency deviates from expected value after Delay triggers alert. LFOF is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure HWMX
|Delay: 5000ms
|Permanent failure for input MUX used for OV, UV protection if check fails and fails after Delay trigger alert.
Needs manual intervention for reset
|-
|Over temperature protection for charge
|Temperature: 60C
Recovery: 55C
|Triggers fail and disables charge path until Recovery
|-
|Under temperature protection for charge
|Temperature: 0C
Recovery: 5C
|Triggers fail and disables charge path until Recovery
|-
|Over temperature protection for discharge
|Temperature: 70C
Recovery: 65C
|Triggers fail and disables discharge path until Recovery
|-
|Under temperature protection for discharge
|Temperature: -40C
Recovery: -35C
|Triggers fail and disables discharge path until Recovery
|-
|Over temperature protection FET
|Temperature: 80C
Recovery: 75C
|Triggers fail and disables discharge path until Recovery
|-
|Over temperature protection internal
|Temperature: 70C
Recovery: 65C
|Triggers fail and disables CVM until Recovery
|-
|Under temperature protection internal
|Temperature: -20C
Recovery: -15
|Triggers fail and disables CVM path until Recovery
|-
|Balancing configuration minimum cell voltage
|3.60V
|Minium cell voltage before balancing
|-
|Balancing cell voltage delta
|10mV
|Minimum cell voltage between cell before stopping balancing (or start balancing if bigger than)
|-
|Number of cells balancing simultaneously
|7 cells
|CVM supports multiple cell balancing up to 16 cells.
|}

== Open questions ==

* Do the MPPTs have to be modified for the 14S battery?
*Integrated or seperate charge/discharge paths? (I've got a slight preference for seperate pcb's)

== CAN ID's ==

=== 0x100 ===
float rPackCurrent_A

float rPerriCurrent_A

=== 0x101 ===
float rChargeCurrent_A

float rDischargeCurrent_A

=== 0x102 ===
uint16 * 1000 rSOC_pct

uint32 rErrorFlags

uint16 rBalancingStatus

=== 0x103 ===
uint16 * 1000 rCellVoltages_V_1, rCellVoltages_V_2, rCellVoltages_V_3, rCellVoltages_V_4,

=== 0x104 ===
uint16 * 1000 rCellVoltages_V_5, rCellVoltages_V_6, rCellVoltages_V_7, rCellVoltages_V_8,

=== 0x105 ===
uint16 * 1000 rCellVoltages_V_9, rCellVoltages_V_10, rCellVoltages_V_11, rCellVoltages_V_12,

=== 0x106 ===
uint16 * 1000 rCellVoltages_V_13, rCellVoltages_V_14, rPackVoltage_V, rStackVoltage_V

=== 0x107 ===
int8 rBattTemps_1, rBattTemps_2, rBattTemps_3, rBattTemps_4

int8 rICTemp_degC

uint8 rBatteryState

uint8 rChargeState

uint8 rMotorState
=== 0x108 ===
uint32 uptime ms

uint32 unused

Battery

2024-03-05T08:17:53Z

Fromeijn: added uptime

This page contains the information about the EoI battery development, everything from the requirements to the implementation can be found here.

== What is the battery? ==
The battery is the energy buffer of the boat, it stores the energy coming in from the solar panels and provides a constant voltage for the motor path and peripheral electronics. The battery consists of multiple parts:

* Battery cells
* Battery management system (BMS)

The BMS makes sure that the battery cells can't be overcharged or over-discharged, as this might damage them and present dangerous situations. Besides monitoring the voltage a BMS usually monitors the current and temperature as well.

== Technical regulations (as per September 2022) ==

* Maximum nominal voltage: 58,8V (14S lithium-ion)
* Maximum capacity: 1,5 kWh (= 5400 MJ)
* All battery cells must be commercially available
* The BMS must monitor the battery voltage and current
* The BMS must be capable of shutting down the system
* The BMS must be able to monitor charge and discharge currents
* The BMS must have a means to limit over-current in charge and discharge paths
* The BMS must monitor all individual cells
* All electrical systems must be provided with a fuse in series connection with the main battery ('Main fuse')
* The battery must be fused
* The BMS must be fused

== Specifications ==
{| class="wikitable"
|+Functional requirements
!ID
!Specifiction
!Value
!Pass/Fail
|-
|
|Nominal pack voltage
|<code><= 58,8V</code>
|
|-
|
|Maximum capacity
|<code>1,5 kWh</code>
|
|-
|
|Monitor (pack) voltage
|
|
|-
|
|Monitor (pack) current
|
|
|-
|
|Monitor (pack) temperature
|>> 1 sensor (8)
|
|-
|
|Limit overcurrent in (dis)charge path
|
|
|-
|
|Capable of shutting down the whole system
|
|
|-
|
|CAN-bus communication
|<code>5V / 1 Mbit</code>
|
|-
|
|Internal cell balancing
|
|
|-
|
|Charge and discharge paths can be operated simultaneously
|
|
|-
|
|Motor and MPPT should be enabled independently
|
|
|-
|
|The battery should be enabled with a N.O. contact
|open = off
closed = on
|
|-
|
|Separate enable contact for Motor path (output) (Optional: Software disable only)
|
|
|-
|
|Battery should be fully disabled (all outputs disabled) by emergency switch
|
|
|-
|
|Shelf life (Save battery mode)
|>= 1 year (<code>2.8mA max</code>)
|
|-
|
|Humidity sensor
|
|
|-
|
|Galvanic separation of safety path (bilge and horn)
|
|
|-
|
|(Optional) I.M.U.
|
|
|-
|
|(Optional) Phase change cooling hardware
|
|
|}
{| class="wikitable"
|+Electrical requirements
!ID
!Specification
!Value
!Pass/Fail
|-
|0
|Motor path (output)
|<code>60V / 300A</code>
|
|-
|1
|Charge path (input)
|<code>60V / 50A</code>
|
|-
|2
|Peri path (output)
|<code>24V / 2.5A</code>
|
|-
|3
|Safety path (output) (bilge and horn)
|<code>24V / 4A</code>
|
|}
{| class="wikitable"
|+Environmental requirements
!ID
!Specification
!Value
!Pass/Fail
|-
|0
|Ambient operating temperature
|0 - 50 °C
|
|-
|1
|Ingress protection
|IP67 or better
|
|}

== Battery Management System ==
The Battery Management System (BMS) is the brains of the battery and makes sure to manage the battery so it is Dedier proof and does not catch on fire.

The BMS has different functionalities on the PCB and therefore different settings. Since these settings are extensive (especially with the Cell Voltage Monitoring (CVM) chip, this chip does more than only measuring the cell voltages but we will be calling it the CVM from now for better readability.

The BMS has different hardware components that is used in the EoI-battery, these are shown in their corresponding figures throughout the page. Shown below is the full battery system with cells in the box.
[[File:Battery in box.png|center|thumb|Battery box]]

=== Hardware ===
The full BMS system consist of at least three PCBs that are:

* Main board
* Current sense board for the discharge
* Charge path board

Each of the hardware are further elaborated in their own sections.

==== Main board ====
[[File:Bms pcb top view.jpg|thumb|691x691px|BMS PCB top view]]
The main board (shown right) is big brain of the battery system. On the main board there are multiple ICs with their own configurations and applications, namely:

* Cell Voltage Measurement IC
* ADC
* Microprocessor
* ...

[[File:Current sense pcb top view.jpg|thumb|Current sense PCB top view]]
[[File:Charge path PCB top view.jpg|thumb|Charge path PCB top view]]

=== CVM ===
The CVM that is used on the BMS is the [https://www.ti.com/product/BQ76952 BQ76952], located in the middle of the main board. This CVM-chip has an extensive list of configurations and features which makes it cumbersome to scroll through the code to know which features are enabled and which safety configurations are made. Therefore a list is generated with a description of the used configuration below.

These are preliminary configurations and could be changed through the course of time and should be changed accordingly here as well.
[[File:FUSE pin.png|thumb|FUSE pin configuration of the CVM IC.|570x570px]]
{| class="wikitable"
|+
!Short description
!Configuration
!Long description
|-
|Min Blow Fuse Voltage
|STACK: 60.2V(4.3V per cell)
|Permanent faults the device and enables FUSE pin to trigger the fuse.
FUSE pin stays on indefinitely and thus manual intervention is needed.
|-
|PF_FUSE
|Enabled
|Whenever a permanent fail occurs the FUSE pin should also be triggered.
|-
|Internal regualtors 1 & 2
|Disabled
|Regulator 1 and 2 are disabled since we do not use that with the CVM on the BMS.
|-
|Pre-regulator REG0
|Disabled
|Pre regulator is used to generate voltages for regulators 1 & 2.
|-
|CFETOFF
|Disabled
|CFETOFF pin is not used on the BMS.
|-
|TS1,2,3
|18k resistor model & 18k pull-up resistor internal
Used for cell protection
|Temperature pins are configured to be used in cell temperature protection
|-
|DFETOFF
|DFETOFF pin is configured as a termistor input
18k resistor model & 18k pull-up resistor internal

Used for cell protection
|DFETOFF can have different functions and is used for temperature measurement as a termistor input.
|-
|DDSG
|Configured as analogue discharge enable
|CVM IC can determine if the battery may be discharged. This pin activates the discharge path if everything is within spec
|-
|DA
|Resolution measured current: 0.1mA
Resolution measured voltage: 10mV

Internal temperature not used for cell/FET protection
|DA configuration specifies the units for measuring the current and voltage. And can configure if the internal temperature readout should be used for cell protection.
|-
|VCELL
|Disable cell protection on cells 14 and 15
|Configures which cell should be used for cell protection and which cell should be ignored. Cell 14 and 15 are shorted since EoI uses a 14s battery.
|-
|FET settings
|Disabled
|The CVM IC can drive its own FETs, as in the MOSFETs can directly be driven by the chip itself since it can run in standalone mode.
|-
|FET charge pump
|Disabled
|N/A EoI
|-
|Shutdown internal temperature
|80C
|If measured internal temperature of the CVM is above 80C than the CVM should go into shutdown mode.
|-
|Over voltage protection
|Over voltage: 4.25V
Delay: 2000ms

Over voltage reset: 4.00V
|Over voltage protection triggers alert after Delay resets trigger after reset voltage
|-
|Under voltage protection
|Under voltage: 2.8V
Delay: 2000ms

Under voltage reset: 3.00V
|Under voltage protection triggers alert after Delay resets trigger after reset voltage
|-
|Permanent failure under voltage protection
|Under voltage: 2.5V
Delay: 5000ms
|Permanent failure under voltage protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure over voltage protection
|Over voltage: 4.3V
Delay: 5000ms
|Permanent failure over voltage protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure over temperature protection
|Temperature: 90C
Delay: 5000ms
|Permanent failure over temperature protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure VSSF protection
|VSSF: 100mV
Delay: 5000ms
|Permanent failure over VSSF triggers alert after Delay. VSSF is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure 2LVL protection
EDIT: Should not have to use.
|Delay: 5000ms
|Permanent failure over 2LVL triggers alert after Delay. 2LVL is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure LFOF protection
|Delay: 5000ms
|Permanent failure over LFO oscillator frequency deviates from expected value after Delay triggers alert. LFOF is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure HWMX
|Delay: 5000ms
|Permanent failure for input MUX used for OV, UV protection if check fails and fails after Delay trigger alert.
Needs manual intervention for reset
|-
|Over temperature protection for charge
|Temperature: 60C
Recovery: 55C
|Triggers fail and disables charge path until Recovery
|-
|Under temperature protection for charge
|Temperature: 0C
Recovery: 5C
|Triggers fail and disables charge path until Recovery
|-
|Over temperature protection for discharge
|Temperature: 70C
Recovery: 65C
|Triggers fail and disables discharge path until Recovery
|-
|Under temperature protection for discharge
|Temperature: -40C
Recovery: -35C
|Triggers fail and disables discharge path until Recovery
|-
|Over temperature protection FET
|Temperature: 80C
Recovery: 75C
|Triggers fail and disables discharge path until Recovery
|-
|Over temperature protection internal
|Temperature: 70C
Recovery: 65C
|Triggers fail and disables CVM until Recovery
|-
|Under temperature protection internal
|Temperature: -20C
Recovery: -15
|Triggers fail and disables CVM path until Recovery
|-
|Balancing configuration minimum cell voltage
|3.60V
|Minium cell voltage before balancing
|-
|Balancing cell voltage delta
|10mV
|Minimum cell voltage between cell before stopping balancing (or start balancing if bigger than)
|-
|Number of cells balancing simultaneously
|7 cells
|CVM supports multiple cell balancing up to 16 cells.
|}

== Open questions ==

* Do the MPPTs have to be modified for the 14S battery?
*Integrated or seperate charge/discharge paths? (I've got a slight preference for seperate pcb's)

== CAN ID's ==

=== 0x100 ===
float rPackCurrent_A

float rPerriCurrent_A

=== 0x101 ===
float rChargeCurrent_A

float rDischargeCurrent_A

=== 0x102 ===
uint16 * 1000 rSOC_pct

uint32 rErrorFlags

uint16 rBalancingStatus

=== 0x103 ===
uint16 * 1000 rCellVoltages_V_1, rCellVoltages_V_2, rCellVoltages_V_3, rCellVoltages_V_4,

=== 0x104 ===
uint16 * 1000 rCellVoltages_V_5, rCellVoltages_V_6, rCellVoltages_V_7, rCellVoltages_V_8,

=== 0x105 ===
uint16 * 1000 rCellVoltages_V_9, rCellVoltages_V_10, rCellVoltages_V_11, rCellVoltages_V_12,

=== 0x106 ===
uint16 * 1000 rCellVoltages_V_13, rCellVoltages_V_14, rPackVoltage_V, rStackVoltage_V

=== 0x107 ===
int8 rBattTemps_1, rBattTemps_2, rBattTemps_3, rBattTemps_4

int8 rICTemp_degC

uint8 rBatteryState

uint8 rChargeState

uint8 rMotorState
=== 0x108 ===
uit32 uptime ms

uit32 unused

Battery

2024-02-05T20:01:14Z

Fromeijn:

This page contains the information about the EoI battery development, everything from the requirements to the implementation can be found here.

== What is the battery? ==
The battery is the energy buffer of the boat, it stores the energy coming in from the solar panels and provides a constant voltage for the motor path and peripheral electronics. The battery consists of multiple parts:

* Battery cells
* Battery management system (BMS)

The BMS makes sure that the battery cells can't be overcharged or over-discharged, as this might damage them and present dangerous situations. Besides monitoring the voltage a BMS usually monitors the current and temperature as well.

== Technical regulations (as per September 2022) ==

* Maximum nominal voltage: 58,8V (14S lithium-ion)
* Maximum capacity: 1,5 kWh (= 5400 MJ)
* All battery cells must be commercially available
* The BMS must monitor the battery voltage and current
* The BMS must be capable of shutting down the system
* The BMS must be able to monitor charge and discharge currents
* The BMS must have a means to limit over-current in charge and discharge paths
* The BMS must monitor all individual cells
* All electrical systems must be provided with a fuse in series connection with the main battery ('Main fuse')
* The battery must be fused
* The BMS must be fused

== Specifications ==
{| class="wikitable"
|+Functional requirements
!ID
!Specifiction
!Value
!Pass/Fail
|-
|
|Nominal pack voltage
|<code><= 58,8V</code>
|
|-
|
|Maximum capacity
|<code>1,5 kWh</code>
|
|-
|
|Monitor (pack) voltage
|
|
|-
|
|Monitor (pack) current
|
|
|-
|
|Monitor (pack) temperature
|>> 1 sensor (8)
|
|-
|
|Limit overcurrent in (dis)charge path
|
|
|-
|
|Capable of shutting down the whole system
|
|
|-
|
|CAN-bus communication
|<code>5V / 1 Mbit</code>
|
|-
|
|Internal cell balancing
|
|
|-
|
|Charge and discharge paths can be operated simultaneously
|
|
|-
|
|Motor and MPPT should be enabled independently
|
|
|-
|
|The battery should be enabled with a N.O. contact
|open = off
closed = on
|
|-
|
|Separate enable contact for Motor path (output) (Optional: Software disable only)
|
|
|-
|
|Battery should be fully disabled (all outputs disabled) by emergency switch
|
|
|-
|
|Shelf life (Save battery mode)
|>= 1 year (<code>2.8mA max</code>)
|
|-
|
|Humidity sensor
|
|
|-
|
|Galvanic separation of safety path (bilge and horn)
|
|
|-
|
|(Optional) I.M.U.
|
|
|-
|
|(Optional) Phase change cooling hardware
|
|
|}
{| class="wikitable"
|+Electrical requirements
!ID
!Specification
!Value
!Pass/Fail
|-
|0
|Motor path (output)
|<code>60V / 300A</code>
|
|-
|1
|Charge path (input)
|<code>60V / 50A</code>
|
|-
|2
|Peri path (output)
|<code>24V / 2.5A</code>
|
|-
|3
|Safety path (output) (bilge and horn)
|<code>24V / 4A</code>
|
|}
{| class="wikitable"
|+Environmental requirements
!ID
!Specification
!Value
!Pass/Fail
|-
|0
|Ambient operating temperature
|0 - 50 °C
|
|-
|1
|Ingress protection
|IP67 or better
|
|}

== Battery Management System ==
The Battery Management System (BMS) is the brains of the battery and makes sure to manage the battery so it is Dedier proof and does not catch on fire.

The BMS has different functionalities on the PCB and therefore different settings. Since these settings are extensive (especially with the Cell Voltage Monitoring (CVM) chip, this chip does more than only measuring the cell voltages but we will be calling it the CVM from now for better readability.

The BMS has different hardware components that is used in the EoI-battery, these are shown in their corresponding figures throughout the page. Shown below is the full battery system with cells in the box.
[[File:Battery in box.png|center|thumb|Battery box]]

=== Hardware ===
The full BMS system consist of at least three PCBs that are:

* Main board
* Current sense board for the discharge
* Charge path board

Each of the hardware are further elaborated in their own sections.

==== Main board ====
[[File:Bms pcb top view.jpg|thumb|691x691px|BMS PCB top view]]
The main board (shown right) is big brain of the battery system. On the main board there are multiple ICs with their own configurations and applications, namely:

* Cell Voltage Measurement IC
* ADC
* Microprocessor
* ...

[[File:Current sense pcb top view.jpg|thumb|Current sense PCB top view]]
[[File:Charge path PCB top view.jpg|thumb|Charge path PCB top view]]

=== CVM ===
The CVM that is used on the BMS is the [https://www.ti.com/product/BQ76952 BQ76952], located in the middle of the main board. This CVM-chip has an extensive list of configurations and features which makes it cumbersome to scroll through the code to know which features are enabled and which safety configurations are made. Therefore a list is generated with a description of the used configuration below.

These are preliminary configurations and could be changed through the course of time and should be changed accordingly here as well.
[[File:FUSE pin.png|thumb|FUSE pin configuration of the CVM IC.|570x570px]]
{| class="wikitable"
|+
!Short description
!Configuration
!Long description
|-
|Min Blow Fuse Voltage
|STACK: 60.2V(4.3V per cell)
|Permanent faults the device and enables FUSE pin to trigger the fuse.
FUSE pin stays on indefinitely and thus manual intervention is needed.
|-
|PF_FUSE
|Enabled
|Whenever a permanent fail occurs the FUSE pin should also be triggered.
|-
|Internal regualtors 1 & 2
|Disabled
|Regulator 1 and 2 are disabled since we do not use that with the CVM on the BMS.
|-
|Pre-regulator REG0
|Disabled
|Pre regulator is used to generate voltages for regulators 1 & 2.
|-
|CFETOFF
|Disabled
|CFETOFF pin is not used on the BMS.
|-
|TS1,2,3
|18k resistor model & 18k pull-up resistor internal
Used for cell protection
|Temperature pins are configured to be used in cell temperature protection
|-
|DFETOFF
|DFETOFF pin is configured as a termistor input
18k resistor model & 18k pull-up resistor internal

Used for cell protection
|DFETOFF can have different functions and is used for temperature measurement as a termistor input.
|-
|DDSG
|Configured as analogue discharge enable
|CVM IC can determine if the battery may be discharged. This pin activates the discharge path if everything is within spec
|-
|DA
|Resolution measured current: 0.1mA
Resolution measured voltage: 10mV

Internal temperature not used for cell/FET protection
|DA configuration specifies the units for measuring the current and voltage. And can configure if the internal temperature readout should be used for cell protection.
|-
|VCELL
|Disable cell protection on cells 14 and 15
|Configures which cell should be used for cell protection and which cell should be ignored. Cell 14 and 15 are shorted since EoI uses a 14s battery.
|-
|FET settings
|Disabled
|The CVM IC can drive its own FETs, as in the MOSFETs can directly be driven by the chip itself since it can run in standalone mode.
|-
|FET charge pump
|Disabled
|N/A EoI
|-
|Shutdown internal temperature
|80C
|If measured internal temperature of the CVM is above 80C than the CVM should go into shutdown mode.
|-
|Over voltage protection
|Over voltage: 4.25V
Delay: 2000ms

Over voltage reset: 4.00V
|Over voltage protection triggers alert after Delay resets trigger after reset voltage
|-
|Under voltage protection
|Under voltage: 2.8V
Delay: 2000ms

Under voltage reset: 3.00V
|Under voltage protection triggers alert after Delay resets trigger after reset voltage
|-
|Permanent failure under voltage protection
|Under voltage: 2.5V
Delay: 5000ms
|Permanent failure under voltage protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure over voltage protection
|Over voltage: 4.3V
Delay: 5000ms
|Permanent failure over voltage protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure over temperature protection
|Temperature: 90C
Delay: 5000ms
|Permanent failure over temperature protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure VSSF protection
|VSSF: 100mV
Delay: 5000ms
|Permanent failure over VSSF triggers alert after Delay. VSSF is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure 2LVL protection
EDIT: Should not have to use.
|Delay: 5000ms
|Permanent failure over 2LVL triggers alert after Delay. 2LVL is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure LFOF protection
|Delay: 5000ms
|Permanent failure over LFO oscillator frequency deviates from expected value after Delay triggers alert. LFOF is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure HWMX
|Delay: 5000ms
|Permanent failure for input MUX used for OV, UV protection if check fails and fails after Delay trigger alert.
Needs manual intervention for reset
|-
|Over temperature protection for charge
|Temperature: 60C
Recovery: 55C
|Triggers fail and disables charge path until Recovery
|-
|Under temperature protection for charge
|Temperature: 0C
Recovery: 5C
|Triggers fail and disables charge path until Recovery
|-
|Over temperature protection for discharge
|Temperature: 70C
Recovery: 65C
|Triggers fail and disables discharge path until Recovery
|-
|Under temperature protection for discharge
|Temperature: -40C
Recovery: -35C
|Triggers fail and disables discharge path until Recovery
|-
|Over temperature protection FET
|Temperature: 80C
Recovery: 75C
|Triggers fail and disables discharge path until Recovery
|-
|Over temperature protection internal
|Temperature: 70C
Recovery: 65C
|Triggers fail and disables CVM until Recovery
|-
|Under temperature protection internal
|Temperature: -20C
Recovery: -15
|Triggers fail and disables CVM path until Recovery
|-
|Balancing configuration minimum cell voltage
|3.60V
|Minium cell voltage before balancing
|-
|Balancing cell voltage delta
|10mV
|Minimum cell voltage between cell before stopping balancing (or start balancing if bigger than)
|-
|Number of cells balancing simultaneously
|7 cells
|CVM supports multiple cell balancing up to 16 cells.
|}

== Open questions ==

* Do the MPPTs have to be modified for the 14S battery?
*Integrated or seperate charge/discharge paths? (I've got a slight preference for seperate pcb's)

== CAN ID's ==

=== 0x100 ===
float rPackCurrent_A

float rPerriCurrent_A

=== 0x101 ===
float rChargeCurrent_A

float rDischargeCurrent_A

=== 0x102 ===
uint16 * 1000 rSOC_pct

uint32 rErrorFlags

uint16 rBalancingStatus

=== 0x103 ===
uint16 * 1000 rCellVoltages_V_1, rCellVoltages_V_2, rCellVoltages_V_3, rCellVoltages_V_4,

=== 0x104 ===
uint16 * 1000 rCellVoltages_V_5, rCellVoltages_V_6, rCellVoltages_V_7, rCellVoltages_V_8,

=== 0x105 ===
uint16 * 1000 rCellVoltages_V_9, rCellVoltages_V_10, rCellVoltages_V_11, rCellVoltages_V_12,

=== 0x106 ===
uint16 * 1000 rCellVoltages_V_13, rCellVoltages_V_14, rPackVoltage_V, rStackVoltage_V

=== 0x107 ===
int8 rBattTemps_1, rBattTemps_2, rBattTemps_3, rBattTemps_4

int8 rICTemp_degC

uint8 rBatteryState

uint8 rChargeState

uint8 rMotorState

Battery

2024-02-05T19:57:31Z

Fromeijn: added basic can messages bms

This page contains the information about the EoI battery development, everything from the requirements to the implementation can be found here.

== What is the battery? ==
The battery is the energy buffer of the boat, it stores the energy coming in from the solar panels and provides a constant voltage for the motor path and peripheral electronics. The battery consists of multiple parts:

* Battery cells
* Battery management system (BMS)

The BMS makes sure that the battery cells can't be overcharged or over-discharged, as this might damage them and present dangerous situations. Besides monitoring the voltage a BMS usually monitors the current and temperature as well.

== Technical regulations (as per September 2022) ==

* Maximum nominal voltage: 58,8V (14S lithium-ion)
* Maximum capacity: 1,5 kWh (= 5400 MJ)
* All battery cells must be commercially available
* The BMS must monitor the battery voltage and current
* The BMS must be capable of shutting down the system
* The BMS must be able to monitor charge and discharge currents
* The BMS must have a means to limit over-current in charge and discharge paths
* The BMS must monitor all individual cells
* All electrical systems must be provided with a fuse in series connection with the main battery ('Main fuse')
* The battery must be fused
* The BMS must be fused

== Specifications ==
{| class="wikitable"
|+Functional requirements
!ID
!Specifiction
!Value
!Pass/Fail
|-
|
|Nominal pack voltage
|<code><= 58,8V</code>
|
|-
|
|Maximum capacity
|<code>1,5 kWh</code>
|
|-
|
|Monitor (pack) voltage
|
|
|-
|
|Monitor (pack) current
|
|
|-
|
|Monitor (pack) temperature
|>> 1 sensor (8)
|
|-
|
|Limit overcurrent in (dis)charge path
|
|
|-
|
|Capable of shutting down the whole system
|
|
|-
|
|CAN-bus communication
|<code>5V / 1 Mbit</code>
|
|-
|
|Internal cell balancing
|
|
|-
|
|Charge and discharge paths can be operated simultaneously
|
|
|-
|
|Motor and MPPT should be enabled independently
|
|
|-
|
|The battery should be enabled with a N.O. contact
|open = off
closed = on
|
|-
|
|Separate enable contact for Motor path (output) (Optional: Software disable only)
|
|
|-
|
|Battery should be fully disabled (all outputs disabled) by emergency switch
|
|
|-
|
|Shelf life (Save battery mode)
|>= 1 year (<code>2.8mA max</code>)
|
|-
|
|Humidity sensor
|
|
|-
|
|Galvanic separation of safety path (bilge and horn)
|
|
|-
|
|(Optional) I.M.U.
|
|
|-
|
|(Optional) Phase change cooling hardware
|
|
|}
{| class="wikitable"
|+Electrical requirements
!ID
!Specification
!Value
!Pass/Fail
|-
|0
|Motor path (output)
|<code>60V / 300A</code>
|
|-
|1
|Charge path (input)
|<code>60V / 50A</code>
|
|-
|2
|Peri path (output)
|<code>24V / 2.5A</code>
|
|-
|3
|Safety path (output) (bilge and horn)
|<code>24V / 4A</code>
|
|}
{| class="wikitable"
|+Environmental requirements
!ID
!Specification
!Value
!Pass/Fail
|-
|0
|Ambient operating temperature
|0 - 50 °C
|
|-
|1
|Ingress protection
|IP67 or better
|
|}

== Battery Management System ==
The Battery Management System (BMS) is the brains of the battery and makes sure to manage the battery so it is Dedier proof and does not catch on fire.

The BMS has different functionalities on the PCB and therefore different settings. Since these settings are extensive (especially with the Cell Voltage Monitoring (CVM) chip, this chip does more than only measuring the cell voltages but we will be calling it the CVM from now for better readability.

The BMS has different hardware components that is used in the EoI-battery, these are shown in their corresponding figures throughout the page. Shown below is the full battery system with cells in the box.
[[File:Battery in box.png|center|thumb|Battery box]]

=== Hardware ===
The full BMS system consist of at least three PCBs that are:

* Main board
* Current sense board for the discharge
* Charge path board

Each of the hardware are further elaborated in their own sections.

==== Main board ====
[[File:Bms pcb top view.jpg|thumb|691x691px|BMS PCB top view]]
The main board (shown right) is big brain of the battery system. On the main board there are multiple ICs with their own configurations and applications, namely:

* Cell Voltage Measurement IC
* ADC
* Microprocessor
* ...

[[File:Current sense pcb top view.jpg|thumb|Current sense PCB top view]]
[[File:Charge path PCB top view.jpg|thumb|Charge path PCB top view]]

=== CVM ===
The CVM that is used on the BMS is the [https://www.ti.com/product/BQ76952 BQ76952], located in the middle of the main board. This CVM-chip has an extensive list of configurations and features which makes it cumbersome to scroll through the code to know which features are enabled and which safety configurations are made. Therefore a list is generated with a description of the used configuration below.

These are preliminary configurations and could be changed through the course of time and should be changed accordingly here as well.
[[File:FUSE pin.png|thumb|FUSE pin configuration of the CVM IC.|570x570px]]
{| class="wikitable"
|+
!Short description
!Configuration
!Long description
|-
|Min Blow Fuse Voltage
|STACK: 60.2V(4.3V per cell)
|Permanent faults the device and enables FUSE pin to trigger the fuse.
FUSE pin stays on indefinitely and thus manual intervention is needed.
|-
|PF_FUSE
|Enabled
|Whenever a permanent fail occurs the FUSE pin should also be triggered.
|-
|Internal regualtors 1 & 2
|Disabled
|Regulator 1 and 2 are disabled since we do not use that with the CVM on the BMS.
|-
|Pre-regulator REG0
|Disabled
|Pre regulator is used to generate voltages for regulators 1 & 2.
|-
|CFETOFF
|Disabled
|CFETOFF pin is not used on the BMS.
|-
|TS1,2,3
|18k resistor model & 18k pull-up resistor internal
Used for cell protection
|Temperature pins are configured to be used in cell temperature protection
|-
|DFETOFF
|DFETOFF pin is configured as a termistor input
18k resistor model & 18k pull-up resistor internal

Used for cell protection
|DFETOFF can have different functions and is used for temperature measurement as a termistor input.
|-
|DDSG
|Configured as analogue discharge enable
|CVM IC can determine if the battery may be discharged. This pin activates the discharge path if everything is within spec
|-
|DA
|Resolution measured current: 0.1mA
Resolution measured voltage: 10mV

Internal temperature not used for cell/FET protection
|DA configuration specifies the units for measuring the current and voltage. And can configure if the internal temperature readout should be used for cell protection.
|-
|VCELL
|Disable cell protection on cells 14 and 15
|Configures which cell should be used for cell protection and which cell should be ignored. Cell 14 and 15 are shorted since EoI uses a 14s battery.
|-
|FET settings
|Disabled
|The CVM IC can drive its own FETs, as in the MOSFETs can directly be driven by the chip itself since it can run in standalone mode.
|-
|FET charge pump
|Disabled
|N/A EoI
|-
|Shutdown internal temperature
|80C
|If measured internal temperature of the CVM is above 80C than the CVM should go into shutdown mode.
|-
|Over voltage protection
|Over voltage: 4.25V
Delay: 2000ms

Over voltage reset: 4.00V
|Over voltage protection triggers alert after Delay resets trigger after reset voltage
|-
|Under voltage protection
|Under voltage: 2.8V
Delay: 2000ms

Under voltage reset: 3.00V
|Under voltage protection triggers alert after Delay resets trigger after reset voltage
|-
|Permanent failure under voltage protection
|Under voltage: 2.5V
Delay: 5000ms
|Permanent failure under voltage protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure over voltage protection
|Over voltage: 4.3V
Delay: 5000ms
|Permanent failure over voltage protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure over temperature protection
|Temperature: 90C
Delay: 5000ms
|Permanent failure over temperature protection triggers alert after Delay
Needs manual intervention for reset
|-
|Permanent failure VSSF protection
|VSSF: 100mV
Delay: 5000ms
|Permanent failure over VSSF triggers alert after Delay. VSSF is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure 2LVL protection
EDIT: Should not have to use.
|Delay: 5000ms
|Permanent failure over 2LVL triggers alert after Delay. 2LVL is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure LFOF protection
|Delay: 5000ms
|Permanent failure over LFO oscillator frequency deviates from expected value after Delay triggers alert. LFOF is measured internal of the IC.
Needs manual intervention for reset
|-
|Permanent failure HWMX
|Delay: 5000ms
|Permanent failure for input MUX used for OV, UV protection if check fails and fails after Delay trigger alert.
Needs manual intervention for reset
|-
|Over temperature protection for charge
|Temperature: 60C
Recovery: 55C
|Triggers fail and disables charge path until Recovery
|-
|Under temperature protection for charge
|Temperature: 0C
Recovery: 5C
|Triggers fail and disables charge path until Recovery
|-
|Over temperature protection for discharge
|Temperature: 70C
Recovery: 65C
|Triggers fail and disables discharge path until Recovery
|-
|Under temperature protection for discharge
|Temperature: -40C
Recovery: -35C
|Triggers fail and disables discharge path until Recovery
|-
|Over temperature protection FET
|Temperature: 80C
Recovery: 75C
|Triggers fail and disables discharge path until Recovery
|-
|Over temperature protection internal
|Temperature: 70C
Recovery: 65C
|Triggers fail and disables CVM until Recovery
|-
|Under temperature protection internal
|Temperature: -20C
Recovery: -15
|Triggers fail and disables CVM path until Recovery
|-
|Balancing configuration minimum cell voltage
|3.60V
|Minium cell voltage before balancing
|-
|Balancing cell voltage delta
|10mV
|Minimum cell voltage between cell before stopping balancing (or start balancing if bigger than)
|-
|Number of cells balancing simultaneously
|7 cells
|CVM supports multiple cell balancing up to 16 cells.
|}

== Open questions ==

* Do the MPPTs have to be modified for the 14S battery?
*Integrated or seperate charge/discharge paths? (I've got a slight preference for seperate pcb's)

== CAN ID's ==

=== 0x100 ===
float rPackCurrent_A

float rPerriCurrent_A

=== 0x1031 ===
float rChargeCurrent_A

float rDischargeCurrent_A

=== 0x102 ===
uint16 * 1000 rSOC_pct

uint32 rErrorFlags

uint16 rBalancingStatus

=== 0x103 ===
uint16 * 1000 rCellVoltages_V_1, rCellVoltages_V_2, rCellVoltages_V_3, rCellVoltages_V_4,

=== 0x104 ===
uint16 * 1000 rCellVoltages_V_5, rCellVoltages_V_6, rCellVoltages_V_7, rCellVoltages_V_8,

=== 0x105 ===
uint16 * 1000 rCellVoltages_V_9, rCellVoltages_V_10, rCellVoltages_V_11, rCellVoltages_V_12,

=== 0x106 ===
uint16 * 1000 rCellVoltages_V_13, rCellVoltages_V_14, rPackVoltage_V, rStackVoltage_V

=== 0x107 ===
int8 rBattTemps_1, rBattTemps_2, rBattTemps_3, rBattTemps_4

int8 rICTemp_degC

uint8 rBatteryState

uint8 rChargeState

uint8 rMotorState

Datalogger

2024-02-05T19:50:15Z

Fromeijn: added can bus id overview

The datalogger is a PCB that stores the [[CAN-bus]] data and shows the data on-screen and sends this data to one of the [[Linux servers|EoI-servers]].

The datalogger is quite complex since it is an embedded Linux platform as well as a screen. The embedded platform makes use of a root file system. Compiling of this file system and any modifications are discussed below.

The screen makes use of cross-compiling QT and is on itself quite the big project for compiling and modifying the generated [[Dashboard|GUI]] for the screen. Therefore one can read more about this topic at [[QT Creator Setup|QT Creator Setup.]]

== Datalogs format ==
As of October '22 the datalogger [[Dashboard|GUI]] is accessing the [[CAN-bus]] data and creating the logfiles and writing them onto its filesystem. The delimiter of the logfile format is a space, this is done to support the http://www.gnuplot.info/ software. This should probably be delimited with a comma or something else.

A snipped of a logfile is given below:<pre>2022-08-27-09-46-55 807280 47.8 -25.4 3.09 28.5 96 3.99 32.6411 -16.9088 15.2 261
2022-08-27-09-46-56 807530 47.8 -24.9 3.09 28 96 3.99 32.6411 -16.9088 15.2 261
2022-08-27-09-46-56 807680 47.8 -24.9 3.45 28.3 96 3.99 32.6411 -16.9088 15.2 261
2022-08-27-09-46-57 807910 47.8 -25.9 3.29 29.2 96 3.99 32.6411 -16.9089 15.2 261
2022-08-27-09-46-57 808090 47.8 -26.2 2.98 29.2 96 3.99 32.6411 -16.9089 15.2 261
2022-08-27-09-46-58 808340 47.8 -25.9 3.4 29.4 96 3.99 32.6411 -16.9089 15.2 260
2022-08-27-09-46-58 808560 47.8 -24.9 2.98 27.9 96 3.99 32.6411 -16.9089 15.2 260
2022-08-27-09-46-59 808740 47.8 -26 3.02 29 96 3.99 32.6411 -16.909 15.2 261
</pre>
{| class="wikitable"
|+
!Date and Time
!Time since start
!Battery voltage <code>[V]</code>
!Battery current netto <code>[A]</code>
!Battery current in <code>[A]</code>
!Battery current out <code>[A]</code>
!SoC <code>[%]</code>
!Highest cell voltage <code>[V]</code>
!GPS latitude
!GPS longitude
!GPS speed <code>[km/h]</code>
!GPS track
|-
|2022-08-27-09-46-55
|807280
|47.8
| -25.4
|3.09
|28.5
|96
|3.99
|32.6411
|<nowiki>-16.9088</nowiki>
|15.2
|261
|}

== Rootfs ==
The datalogger uses a Debian 10 root file system (rootfs), this page walks you through the steps of setting this up and making modifications.

This process has been automated, this is described in the datalogger rootfs repository https://git.engineersofinnovation.nl/datalogger/rootfs

If you'd like do all the steps manually by all means, please continue reading.

=== Creating a Debian filesystem ===
To create a filesystem we use debootstrap. This guide has been tested on Ubuntu 18.04 and Debian 10 Host machines.

==== 1. Install the required dependencies ====
<code>sudo apt update && sudo apt install debootstrap qemu-user-static binfmt-support</code>
====2. Create a new directory 'debian-fs' and enter it====
<code>mkdir ~/Documents/Datalogger/rootfs</code>

<code>cd ~/Documents/Datalogger/rootfs</code>

====3. run the first stage bootstrap====
<code>debootstrap --no-check-gpg --arch=armhf --foreign --include apt,kmod,lsof,ssh,wget,dialog buster rootfs <nowiki>http://deb.debian.org/debian/</nowiki></code>

====4. set up emulation by copying the qemu executable====
<code>sudo cp ./qemu-arm-static rootfs/usr/bin</code>

====5. run the second stage debootstrap ====
<code>sudo chroot rootfs /debootstrap/debootstrap --second-stage</code>

====6. Configure the rootfs for your board, run the following script====
<pre><nowiki>#</nowiki>!/bin/sh

<nowiki>#</nowiki> Modification from acmesystems acqua.sh, please visit their website for great documentation! (acmesystems.it)

<nowiki>#</nowiki> Directory contains the target rootfs

TARGET_ROOTFS_DIR="rootfs"

<nowiki>#</nowiki> Board hostname

filename=$TARGET_ROOTFS_DIR/etc/hostname

echo eoi-datalogger > $filename

<nowiki>#</nowiki> bashrc user/hostname color (optional)

filename=$TARGET_ROOTFS_DIR/root/.bashrc

echo >> $filename

echo "PS1='\${debian_chroot:+(\$debian_chroot)}\[\033[01;96m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\\$ '" >> $filename

<nowiki>#</nowiki> Default name servers

filename=$TARGET_ROOTFS_DIR/etc/resolv.conf

echo nameserver 8.8.8.8 > $filename

echo nameserver 8.8.4.4 >> $filename

<nowiki>#</nowiki> Default network interfaces

filename=$TARGET_ROOTFS_DIR/etc/network/interfaces

echo >> $filename

<nowiki>#</nowiki>echo auto eth0 >> $filename

echo allow-hotplug eth0 >> $filename

echo iface eth0 inet dhcp >> $filename

echo hwaddress ether 00:04:25:12:34:56 >> $filename #eth0 MAC address

echo >> $filename

echo auto wlan0 >> $filename

echo iface wlan0 inet dhcp >> $filename

echo wireless-essid any >> $filename

echo pre-up wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf -B >> $filename

echo post-down killall -q wpa_supplicant >> $filename

<nowiki>#</nowiki> configure Wi-Fi AP

filename=$TARGET_ROOTFS_DIR/etc/wpa_supplicant.conf

touch $filename

echo ctrl_interface=/var/run/wpa_supplicant > $filename

echo ap_scan=1 >> $filename

echo >> $filename

echo network={ >> $filename

echo 'ssid="testnaam"' >> $filename

echo 'psk="testtest"' >> $filename

echo } >> $filename

<nowiki>#</nowiki> Set the the debug port

filename=$TARGET_ROOTFS_DIR/etc/inittab

echo T0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100 >> $filename

<nowiki>#</nowiki> Set rules to change wlan dongles

filename=$TARGET_ROOTFS_DIR/etc/udev/rules.d/70-persistent-net.rules

echo SUBSYSTEM=='"net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"' > $filename

<nowiki>#</nowiki> microSD partitions mounting

filename=$TARGET_ROOTFS_DIR/etc/fstab

echo /dev/mmcblk0p1 /boot vfat noatime 0 1 > $filename

echo /dev/mmcblk0p2 / ext4 noatime 0 1 >> $filename

echo proc /proc proc defaults 0 0 >> $filename

<nowiki>#</nowiki> Add the standard Debian non-free repositories useful to load

<nowiki>#</nowiki> closed source firmware (i.e. WiFi dongle firmware)

filename=$TARGET_ROOTFS_DIR/etc/apt/sources.list

echo deb <nowiki>http://deb.debian.org/debian/</nowiki> buster main contrib non-free > $filename

echo deb-src <nowiki>http://deb.debian.org/debian/</nowiki> buster main contrib non-free >> $filename
</pre>

====7. Install required packages ====
```

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt update</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt install -y net-tools udev iputils-ping ifupdown isc-dhcp-client ca-certificates wpasupplicant firmware-ralink wvdial iw resolvconf libssl-dev ppp autossh</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt install -y locales adduser nano usbutils can-utils i2c-tools git fonts-dejavu gpsd gpsd-clients libqgpsmm-dev libqgpsmm23 minicom picocom python3 python3-pip python3-numpy libsocketcan-dev psmisc moreutils</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt install -y libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa libglu1-mesa-dev libegl1-mesa libegl1-mesa-dev libgles2-mesa-dev mesa-common-dev mesa-utils libgbm-dev libgbm1 libbz2-dev libdrm-dev libgles2-mesa</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt install -y qt5-default qtdeclarative5-* qml-module-qtquick* qml-module-qtquick2 qtquickcontrols5-* qtserialbus5-* qttools5-* qtbase5-* libqt5svg5-* libqtwebkit-* qtmultimedia5-* qmlscene qml gstreamer1.0-omx libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt build-dep qt4-x11 -y</code>

<code>sudo LC_ALL=C LANGUAGE=C LANG=C chroot rootfs apt build-dep libqt5gui5 -y</code>

====8. set a root password====
<code>sudo chroot rootfs passwd</code>

==== 9. remove the qemu binary====
<code>sudo rm rootfs/usr/bin/qemu-arm-static</code>

====10. download and apply the patchfiles====
<code>wget <nowiki>https://git.engineersofinnovation.nl/datalogger/rootfs/-/raw/master/patches/ssh_patch.patch</nowiki></code>

<code>wget <nowiki>https://git.engineersofinnovation.nl/datalogger/rootfs/-/raw/master/patches/ssh_patch_client.patch</nowiki></code>

<code>wget <nowiki>https://git.engineersofinnovation.nl/datalogger/rootfs/-/raw/master/patches/gpsd_patch.patch</nowiki></code>

<code>wget <nowiki>https://git.engineersofinnovation.nl/datalogger/rootfs/-/raw/master/patches/4g_patch.patch</nowiki></code>

<code>sudo patch -p1 < ./patches/ssh_patch.patch</code>

<code>sudo patch -p1 < ./patches/ssh_patch_client.patch</code>

<code>sudo patch -p1 < ./patches/gpsd_patch.patch</code>

<code>sudo patch -p1 < ./patches/4g_patch.patch</code>

====11. Other stuff====
PPP setup?

https://github.com/sixfab/Sixfab_PPP_Installer

Daemons and services for gui and other scripts?

== CAN bus ID Overview ==
<syntaxhighlight>
0x100 EoI Battery start
0x10F EoI Battery end

0x302 MG Battery
0x402 MG Battery
0x482 MG Battery cell voltage

0x700 MPPT start
0x77F MPPT end

0x0900 THROTTLE To VESC
0x1337 THROTTLE Status

0x0909 VESC Status message 1
0x0E09 VESC Status message 2
0x0F09 VESC Status message 3
0x1009 VESC Status message 4
0x1B09 VESC Status message 5
</syntaxhighlight>

Live data

2023-05-17T15:49:42Z

Fromeijn: added known issues for connecting ha to mqtt broker

The live data of the [[Solar boat (boii)|solar boat]] is build upon the logged [[CAN-bus|CAN-data]] from the [[datalogger]] that sends a JSON string of MQTT packet to the [[Linux servers|EoI Linux server]] that can be used to show in the home assistant dashboard.

This dashboard can be accessed through [https://Live.boi2.nl live.boi2.nl]. Where a login is prompted before it can be accessed, the login can be asked from: '''Quinten or Floris.'''

== Home assistant dashboard ==
The home assistant dashboard is subscribed to the MQTT topic, where the [[CAN-bus|CAN-data]] is processed and shown on the dashboard.

=== Pages ===
On the dashboard there are multiple pages where the data is shown to the user. A list of those pages are given below:
{| class="wikitable"
|+
!'''Pagename'''
!Description
|-
|HOME
|This is the overview with common used data during a race.
|-
|BATTERY
|A detailed view within the state of the battery.
|-
|MPPT
|A detailed view of the different MPPTs.
|-
|GRAPHS
|A graph showing the power output of all the solar panels.
|-
|MAP
|Map showing the location of the boat.
|}

== Wish list ==
The dashboard and plug-ins that home assistant provides is still in its infant state and can be drastically improved to show the data in a sophisticated way. Therefore a list of possible improvements are shown here.

* An easier way to create graphs for different variables
* Map were a path can be drawn and calculate distance ( for long distance races )
* A way to start a timer of some sort to create a point for data analysis
* A way to show estimated time on basis of incoming and outgoing power
*As of now the dashboard only includes live data that is sent to the server via MQTT. A way for simulating data while the [[datalogger]] is not generating that data, is a must feature for developing strategies.

== Known issues ==
Connecting our MQTT to Home Assistant might not work when setting it up via add new integration button, since we are using MQTT with TLS for encryption. Work flow is as follows:

Go to you profile in HA, enable '''Advanced Mode''', then go to Settings->Integrations and click on add integration, search for MQTT and click on it (plain). Open Advanced settings, fill everything out as shown below:
[[File:Mqtt config 2.png|thumb]]
[[File:Mqtt config 1.png|thumb]]

File:Mqtt config 2.png

2023-05-17T15:48:22Z

Fromeijn:

mqtt config

File:Mqtt config 1.png

2023-05-17T15:42:30Z

Fromeijn:

mqtt config