Humanoid Robots Wiki - User contributions [en]

Nvidia Jetson: Flashing Custom Firmware

2024-08-30T19:56:36Z

Vedant: /* Flashing the Kernel */

= Flashing Standard Firmware =
== SDKManager ==
SDKManager is available only on Linux, and can be installed here: <code>https://developer.nvidia.com/sdk-manager</code>
# Start up the SDKManager
# Put the Jetson into recovery mode. For the AGX, this can be done by pressing the recovery button while powering on the device. For the Nano and NX, however, a jumper will be required.
# Connect the Target Jetson to the host device and ensure that the target device is recognized.
# Follow the instructions on the application, choosing configurations as necessary.

= Flashing Custom Firmware (For Jetson 36.3) =
== Pre-requisites ==
# Please install required packages with the command <code>sudo apt install build-essential bc && sudo apt install build-essential bc</code>.
=== Downloading the Toolchain ===
# Download the Toolchain binaries located in <code>https://developer.nvidia.com/embedded/jetson-linux</code>.
# From there, <code>mkdir $HOME/l4t-gcc</code>, <code>cd $HOME/l4t-gcc</code> and extract the installed toolchain into this newly created directory using the <code>tar</code> command.

== Downloading the Kernel ==
# Follow steps 1 to 3 as mentioned in Flashing Standard Firmware.
# Proceed to the second step of the SDKManager, where the respective individual dependencies and Jetson Images are listed and are to be installed. Proceed with the installation.
# When prompted to actually flash the Jetson, opt to skip. This will install the <code>nvidia</code> folder on your home directory, in which the <code>rootfs</code>, <code>kernel</code>, and <code>bootloader</code> are located.
# Navigate to <code>nvidia</code> and <code>cd</code> through its subdirectories, until <code>Linux for Tegra</code> is reached.
# Inside <code>Linux for Tegra</code>, <code>cd</code> into the <code>sources</code> folder. It should be unpopulated with the exception of some bash scripts. Run the <code>source_sync.sh</code> script and when asked to specify the release tag of the downloadable sources, enter <code>jetson_36.3</code>. This will install the sources for the respective Jetson version as necessary. To find the release tag of future iterations of the Jetson firmware, please refer to its respective release notes.
# Once sources have been synced, the <code>sources</code> directory should now be populated with the required files.

== Customizing Kernel ==
# Within <code>source</code>, enter the <code>kernel</code> eventually navigate to the <code>kernel-jammy-src</code> folder and run <code>make menuconfig ARCH=arm64</code>. This will bring up a UI with configurable drivers and peripherals. Select desired configurations and save.
# The configurations can be found within a <code>.config</code> file located within the same directory. Copy the contents and locate the <code>defconfig</code> file in <code>./arch/arm64/configs/</code>, overwriting it with the copied contents.

== Building Custom Kernel and Installing Modules ==
# Navigate back out to <code>sources</code>.
# Define the Cross-compilation toolchain with the commands <code>export CROSS_COMPILE=<toolchain-path>/bin/aarch64-buildroot-linux-gnu-</code>. If installation was done correctly as per the pre-requisites section, the command <code>export CROSS_COMPILE=$HOME/l4t-gcc/aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-</code> should work.
# Define the Cross-compilation toolchain with the commands <code>export CROSS_COMPILE_AARCH64_PATH=</code>, and <code>export CROSS_COMPILE_AARCH64=/bin/aarch64-buildroot-linux-gnu-</code>. (Potentially deprecated)
# Inside the sources, directory, make an output directory for built kernel files using <code>mkdir kernel_out</code>.
# Build the modules using the command <code>./nvbuild.sh -o kernel_out</code>. This will compile the drivers and device trees for the new kernel.
# Navigate out from the <code>sources</code> directory into the <code>Linux for Tegra</code>.
# Use the <code>cp</code> to overwrite <code>./rootfs/usr/lib/modules/5.15.136-tegra/updates/nvgpu.ko</code> with <code>./source/kernel_out/nvgpu/drivers/gpu/nvgpu/nvgpu.ko</code>.
# Repeat the previous step to replace <code>Linux_for_Tegra/kernel/dtb/</code> with </code>source/kernel_out/kernel/kernel-jammy-src/arch/arm64/boot/dts/nvidia</code>. Ensure that instead of overwriting the directory, only the files are copied over.
# Overwrite the Image file in <code>./kernel</code> with <code>./source/kernel_out/kernel/kernel-jammy-src/arch/arm64/boot/Image
</code>.
# To specify the installation path for the compiled modules, use the command <code>export INSTALL_MOD_PATH=$HOME/nvidia/nvidia_sdk/JetPack_6.0_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/rootfs/</code>.
# Install modules using the command <code>./nvbuild -i</code>. The Jetson is now ready to be flashed.

== Flashing the Kernel ==
Ensure that the target Jetson is connected to the host device and is in recovery mode. Navigate to the <code>Linux for Tegra</code> directory and run <code>sudo ./nvsdkmanager_flash.sh</code>. When prompted, disconnect the Jetson from host device and allow it to boot. Congratulations, you have successfully flashed your Jetson with custom firmware.

Nvidia Jetson: Flashing Custom Firmware

2024-08-30T19:56:24Z

Vedant: /* Flashing the Kernel */

Nvidia Jetson: Flashing Custom Firmware

2024-08-30T19:55:57Z

Vedant: /* Building Custom Kernel and Installing Modules */

Nvidia Jetson: Flashing Custom Firmware

2024-08-30T19:54:28Z

Vedant:

= Flashing Standard Firmware =
== SDKManager ==
SDKManager is available only on Linux, and can be installed here: <code>https://developer.nvidia.com/sdk-manager</code>
# Start up the SDKManager
# Put the Jetson into recovery mode. For the AGX, this can be done by pressing the recovery button while powering on the device. For the Nano and NX, however, a jumper will be required.
# Connect the Target Jetson to the host device and ensure that the target device is recognized.
# Follow the instructions on the application, choosing configurations as necessary.

= Flashing Custom Firmware (For Jetson 36.3) =
== Pre-requisites ==
# Please install required packages with the command <code>sudo apt install build-essential bc && sudo apt install build-essential bc</code>.
=== Downloading the Toolchain ===
# Download the Toolchain binaries located in <code>https://developer.nvidia.com/embedded/jetson-linux</code>.
# From there, <code>mkdir $HOME/l4t-gcc</code>, <code>cd $HOME/l4t-gcc</code> and extract the installed toolchain into this newly created directory using the <code>tar</code> command.

== Downloading the Kernel ==
# Follow steps 1 to 3 as mentioned in Flashing Standard Firmware.
# Proceed to the second step of the SDKManager, where the respective individual dependencies and Jetson Images are listed and are to be installed. Proceed with the installation.
# When prompted to actually flash the Jetson, opt to skip. This will install the <code>nvidia</code> folder on your home directory, in which the <code>rootfs</code>, <code>kernel</code>, and <code>bootloader</code> are located.
# Navigate to <code>nvidia</code> and <code>cd</code> through its subdirectories, until <code>Linux for Tegra</code> is reached.
# Inside <code>Linux for Tegra</code>, <code>cd</code> into the <code>sources</code> folder. It should be unpopulated with the exception of some bash scripts. Run the <code>source_sync.sh</code> script and when asked to specify the release tag of the downloadable sources, enter <code>jetson_36.3</code>. This will install the sources for the respective Jetson version as necessary. To find the release tag of future iterations of the Jetson firmware, please refer to its respective release notes.
# Once sources have been synced, the <code>sources</code> directory should now be populated with the required files.

== Customizing Kernel ==
# Within <code>source</code>, enter the <code>kernel</code> eventually navigate to the <code>kernel-jammy-src</code> folder and run <code>make menuconfig ARCH=arm64</code>. This will bring up a UI with configurable drivers and peripherals. Select desired configurations and save.
# The configurations can be found within a <code>.config</code> file located within the same directory. Copy the contents and locate the <code>defconfig</code> file in <code>./arch/arm64/configs/</code>, overwriting it with the copied contents.

== Building Custom Kernel and Installing Modules ==
# Navigate back out to <code>sources</code>.
# Define the Cross-compilation toolchain with the commands <code>export CROSS_COMPILE=<toolchain-path>/bin/aarch64-buildroot-linux-gnu-</code>. If installation was done correctly as per the pre-requisites section, the command <code>export CROSS_COMPILE=$HOME/l4t-gcc/aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-</code> should work.
# Define the Cross-compilation toolchain with the commands <code>export CROSS_COMPILE_AARCH64_PATH=</code>, and <code>export CROSS_COMPILE_AARCH64=/bin/aarch64-buildroot-linux-gnu-</code>. (Potentially deprecated)
# Inside the sources, directory, make an output directory for built kernel files using <code>mkdir kernel_out</code>.
# Build the modules using the command <code>./nvbuild.sh -o kernel_out</code>. This will compile the drivers and device trees for the new kernel.
# Navigate out from the <code>sources</code> directory into the <code>Linux for Tegra</code>.
# Use the <code>cp</code> to overwrite <code>./rootfs/usr/lib/modules/5.15.136-tegra/updates/nvgpu.ko</code> with <code>./source/kernel_out/nvgpu/drivers/gpu/nvgpu/nvgpu.ko</code>.
# Repeat the previous step to replace <code>Linux_for_Tegra/kernel/dtb/</code> with </code>source/kernel_out/kernel/kernel-jammy-src/arch/arm64/boot/dts/nvidia</code>. Ensure that instead of overwriting the directory, only the files are copied over.
# Overwrite the Image in <code>./kernel</code> with <code>./source/kernel_out/kernel/kernel-jammy-src/arch/arm64/boot/Image
</code>.
# To specify the installation path for the compiled modules, use the command <code>export INSTALL_MOD_PATH=$HOME/nvidia/nvidia_sdk/JetPack_6.0_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/rootfs/</code>.
# Install modules using the command <code>./nvbuild -i</code>. The Jetson is now ready to be flashed.

== Flashing the Kernel ==
Ensure that the target Jetson is connected to the host device and is in recovery mode. Navigate to the <code>Linux for Tegra</code> directory and run <code>sudo ./nvsdkmanager_flash.sh</code>. When prompted, disconnect the Jetson from host device and allow it to boot. Congratulations, you have successfully flashed your Jetson with custom firmware.

Nvidia Jetson: Flashing Custom Firmware

2024-08-30T19:42:22Z

Vedant:

= Flashing Standard Firmware =
== SDKManager ==
SDKManager is available only on Linux, and can be installed here: <code>https://developer.nvidia.com/sdk-manager</code>
# Start up the SDKManager
# Put the Jetson into recovery mode. For the AGX, this can be done by pressing the recovery button while powering on the device. For the Nano and NX, however, a jumper will be required.
# Connect the Target Jetson to the host device and ensure that the target device is recognized.
# Follow the instructions on the application, choosing configurations as necessary.

= Flashing Custom Firmware (For Jetson 36.3) =
== Pre-requisites ==
# Please install required packages with the command <code>sudo apt install build-essential bc && sudo apt install build-essential bc</code>.
=== Downloading the Toolchain ===
# Download the Toolchain binaries located in <code>https://developer.nvidia.com/embedded/jetson-linux</code>.
# From there, <code>mkdir $HOME/l4t-gcc</code>, <code>cd $HOME/l4t-gcc</code> and extract the installed toolchain into this newly created directory using the <code>tar</code> command.

== Downloading the Kernel ==
# Follow steps 1 to 3 as mentioned in Flashing Standard Firmware.
# Proceed to the second step of the SDKManager, where the respective individual dependencies and Jetson Images are listed and are to be installed. Proceed with the installation.
# When prompted to actually flash the Jetson, opt to skip. This will install the <code>nvidia</code> folder on your home directory, in which the <code>rootfs</code>, <code>kernel</code>, and <code>bootloader</code> are located.
# Navigate to <code>nvidia</code> and <code>cd</code> through its subdirectories, until <code>Linux for Tegra</code> is reached.
# Inside <code>Linux for Tegra</code>, <code>cd</code> into the <code>sources</code> folder. It should be unpopulated with the exception of some bash scripts. Run the <code>source_sync.sh</code> script and when asked to specify the release tag of the downloadable sources, enter <code>jetson_36.3</code>. This will install the sources for the respective Jetson version as necessary. To find the release tag of future iterations of the Jetson firmware, please refer to its respective release notes.
# Once sources have been synced, the <code>sources</code> directory should now be populated with the required files.

== Customizing Kernel ==
# Within <code>source</code>, enter the <code>kernel</code> eventually navigate to the <code>kernel-jammy-src</code> folder and run <code>make menuconfig ARCH=arm64</code>. This will bring up a UI with configurable drivers and peripherals. Select desired configurations and save.
# The configurations can be found within a <code>.config</code> file located within the same directory. Copy the contents and locate the <code>defconfig</code> file in <code>./arch/arm64/configs/</code>, overwriting it with the copied contents.

== Building Custom Kernel and Installing Modules ==
# Navigate back out to <code>sources</code>.
# Define the Cross-compilation toolchain with the commands <code>export CROSS_COMPILE=<toolchain-path>/bin/aarch64-buildroot-linux-gnu-</code>. If installation was done correctly as per the pre-requisites section, the command <code>export CROSS_COMPILE=$HOME/l4t-gcc/aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-</code> should work.
# Define the Cross-compilation toolchain with the commands <code>export CROSS_COMPILE_AARCH64_PATH=</code>, and <code>export CROSS_COMPILE_AARCH64=/bin/aarch64-buildroot-linux-gnu-</code>. (Potentially deprecated)
# Inside the sources, directory, make an output directory for built kernel files using <code>mkdir kernel_out</code>.
# Build the modules using the command <code>./nvbuild.sh -o kernel_out</code>. This will compile the drivers and device trees for the new kernel.
# Navigate out from the <code>sources</code> directory into the <code>Linux for Tegra</code>.
# Use the <code>cp</code> to overwrite <code>./rootfs/usr/lib/modules/5.15.136-tegra/updates/nvgpu.ko</code> with <code>./source/kernel_out/nvgpu/drivers/gpu/nvgpu/nvgpu.ko</code>.
# Repeat the previous step to replace <code>Linux_for_Tegra/kernel/dtb/</code> with
# To specify the installation path for the compiled modules, use the command <code>export INSTALL_MOD_PATH=$HOME/nvidia/nvidia_sdk/JetPack_6.0_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/rootfs/</code>.
# Install modules using the command <code>./nvbuild -i</code>.

== Flashing the Kernel ==
# Ensure that

Nvidia Jetson: Flashing Custom Firmware

2024-08-29T23:04:43Z

Vedant:

= Flashing Standard Firmware =
== SDKManager ==
SDKManager is available only on Linux, and can be installed here: https://developer.nvidia.com/sdk-manager
# Start up the SDKManager
# Put the Jetson into recovery mode. For the AGX, this can be done by pressing the recovery button while powering on the device. For the Nano and NX, however, a jumper will be required.
# Connect the Target Jetson to the host device and ensure that the target device is recognized.
# Follow the instructions on the application, choosing configurations as necessary.

= Flashing Custom Firmware (For Jetson 36.3) =
== Pre-requisites ==
# Please install required packages with the command <code>sudo apt install build-essential bc && sudo apt install build-essential bc</code>.
=== Downloading the Toolchain ===
# Download the Toolchain binaries located in <code>https://developer.nvidia.com/embedded/jetson-linux</code>.
# From there, <code>mkdir $HOME/l4t-gcc</code>, <code>cd $HOME/l4t-gcc</code> and extract the installed toolchain into this newly created directory using the <code>tar</code> command.

== Downloading the Kernel ==
# Follow steps 1 to 3 as mentioned in Flashing Standard Firmware.
# Proceed to the second step of the SDKManager, where the respective individual dependencies and Jetson Images are listed and are to be installed. Proceed with the installation.
# When prompted to actually flash the Jetson, opt to skip. This will install the <code>nvidia</code> folder on your home directory, in which the <code>rootfs</code>, <code>kernel</code>, and <code>bootloader</code> are located.
# Navigate to <code>nvidia</code> and <code>cd</code> through its subdirectories, until <code>Linux for Tegra</code> is reached.
# Inside <code>Linux for Tegra</code>, <code>cd</code> into the <code>sources</code> folder. It should be unpopulated with the exception of some bash scripts. Run the <code>source_sync.sh</code> script and when asked to specify the release tag of the downloadable sources, enter <code>jetson_36.3</code>. This will install the sources for the respective Jetson version as necessary. To find the release tag of future iterations of the Jetson firmware, please refer to its respective release notes.
# Once sources have been synced, the <code>sources</code> directory should now be populated with the required files.

== Customizing Kernel ==
# Within <code>source</code>, enter the <code>kernel</code> eventually navigate to the <code>kernel-jammy-src</code> folder and run <code>make menuconfig ARCH=arm64</code>. This will bring up a UI with configurable drivers and peripherals. Select desired configurations and save.
# The configurations can be found within a <code>.config</code> file located within the same directory. Copy the contents and locate the <code>defconfig</code> file in <code>./arch/arm64/configs/</code>, overwriting it with the copied contents.

== Building Custom Kernel and Installing Modules ==
# Navigate back out to <code>sources</code>.
# Define the Cross-compilation toolchain with the commands <code>export CROSS_COMPILE=<toolchain-path>/bin/aarch64-buildroot-linux-gnu-</code>. If installation was done correctly as per the pre-requisites section, the command <code>export CROSS_COMPILE=$HOME/l4t-gcc/aarch64--glibc--stable-2022.08-1/bin/aarch64-buildroot-linux-gnu-</code> should work.
# Define the Cross-compilation toolchain with the commands <code>export CROSS_COMPILE_AARCH64_PATH=</code>, and <code>export CROSS_COMPILE_AARCH64=/bin/aarch64-buildroot-linux-gnu-</code>. (Potentially deprecated)
# Inside the sources, directory, make an output directory for built kernel files using <code>mkdir kernel_out</code>.
# Build the modules using the command <code>./nvbuild.sh -o kernel_out</code>.
#

Nvidia Jetson: Flashing Custom Firmware

2024-08-29T22:42:52Z

Vedant:

Nvidia Jetson: Flashing Custom Firmware

2024-08-28T18:45:54Z

Vedant:

Nvidia Jetson: Flashing Custom Firmware

2024-08-28T06:49:30Z

Vedant: /* Downloading the Toolchain */

Nvidia Jetson: Flashing Custom Firmware

2024-08-28T06:44:43Z

Vedant: /* Flashing Custom Firmware (For Jetson 36.3) */

Nvidia Jetson: Flashing Custom Firmware

2024-08-28T06:29:58Z

Vedant:

Nvidia Jetson: Flashing Custom Firmware

2024-06-19T18:50:45Z

Vedant:

= Developing Custom Firmware =
== For the Jetson Orin Nano ==

= Flashing =

Notes:
- Current Design constraints:
- Based off of the availability of parts in JLCPCB. Possibility of parts not being found or existing.
-

- Flashing is done with the flash.sh script through the following command
$ sudo ./flash.sh <board> <rootdev>
where board is the actual board (Jetson-Nano-XX, etc.)
rootdev determines what type of device is being flahed. Use mmcblk0pc1 to flash a local storage device (eMMC or SD card)
- TO begin flashing, put the device into force recovery mode and then press reset.
- Run the flash script using the previous command specified.

Flash using a convenient script:
- To avoid having to specify the rootdev and the board configurations, can use the custom flashing script:
-

Using GPIO Pins to program protocol:
- you can use the rasberry pi libraries to interface with the pins, configuring them to whatever layout that is needed.
- Example: it is possible to direclty interface with the i2c system in the nano by using the linux terminal itself.

Current Game Plan:
- mess around with the programming of the GPIO pins: Figure out if there are ways to choose access teh data that the GPIO pins are Or Receiving.
Test if it is possible to reconfigure the pins on the jetson on the firmware side

Build Time:
- On a single Nvidia Nano, it takes about 45 mins - 1 hour to complete the build. The build is encrypted through RSA. The source is still accessible and every time changes are made to the source files and want ot be reflected, the build files have to be remade. Current goal (Figure out if there's a way to make specific build files to decrease development time).

Notes:
- General requirements to build Linux kernel still apply: e.g. `build-essentials`, `bc`, `libssl-dev`, etc
- Need to install `libssl-dev (depends on whether the certain packages are included when running the script)

Current Approaches to Flashing:
- Decompile an existing DTB file into DTS, make appropriate changes then recompile back.
- Take a flash image that already exists and flash back onto the jetson:
- Caveats: Ensure that the current Jetson is running on Jetpack 5+. If not, you will need to flash 5 on it before flashing it to six. There are instructions online that deal with this setup.
-

Jetson: MCP2515

2024-06-13T21:00:41Z

Vedant:

=== Configuration ===

* Can access the Jetson Expansion Header Tool through the command <code>sudo /opt/nvidia/jetson-io/jetson-io.py</code>

Color Convention:
* Red: 3.3V (Pin 1)
* Black: Gnd (Pin 39)
* Green: CS
* Orange: MISO (Pin 21)
* Blue: MOSI (Pin 19)
* Yellow: SCK (Pin 23)
* Purple: Interrupt

Configurations for Interrupt and CS Pins:
* Interrupt: (Pin 16) + (Pin 32)
* CS: (Pin 12) + (Pin 38)

Jetson: MCP2515

2024-06-13T20:58:59Z

Vedant:

=== Configuration ===

* Can access the Jetson Expansion Header Tool through <code>/opt/nvidia/jetson-io/jetson-io.py</code>

Color Convention:
* Red: 3.3V (Pin 1)
* Black: Gnd (Pin 39)
* Green: CS
* Orange: MISO (Pin 21)
* Blue: MOSI (Pin 19)
* Yellow: SCK (Pin 23)
* Purple: Interrupt

Configurations for Interrupt and CS Pins:
* Interrupt: (Pin 16) + (Pin 32)
* CS: (Pin 12) + (Pin 38)

Jetson: MCP2515

2024-06-13T20:56:28Z

Vedant:

Jetson: MCP2515

2024-06-13T20:53:48Z

Vedant:

=== Configuration ===

* Can access the Jetson Expansion Header Tool through <code>/opt/nvidia/jetson-io/jetson-io.py</code>

Color Convention:
* Red: 3.3V (Pin 1)
* Black: Gnd (Pin 39)
* Green: CS (Pin 12)
* Orange: MISO (Pin 21)
* Blue: MOSI (Pin 19)
* Yellow: SCK (Pin 23)
* Purple: Interrupt (Pin 16)

Jetson: MCP2515

2024-06-13T20:53:20Z

Vedant:

=== Configuration ===

* Can access the Jetson Expansion Header Tool through <code>/opt/nvidia/jetson-io/jetson-io.py</code>

Color Convention:
Red: 3.3V (Pin 1)
Black: Gnd (Pin 39)
Green: CS (Pin 12)
Orange: MISO (Pin 21)
Blue: MOSI (Pin 19)
Yellow: SCK (Pin 23)
Purple: Interrupt (Pin 16)

Jetson: MCP2515

2024-06-13T20:39:03Z

Vedant: Created page with "=== Configuration === * Can access the Jetson Expansion Header Tool through <code>/opt/nvidia/jetson-io/jetson-io.py</code>"

=== Configuration ===

* Can access the Jetson Expansion Header Tool through <code>/opt/nvidia/jetson-io/jetson-io.py</code>

Nvidia Jetson: Flashing Custom Firmware

2024-06-04T00:33:26Z

Vedant: Created page with "= Developing Custom Firmware = == For the Jetson Orin Nano == = Flashing = = Notes: - Current Design constraints: - Based off of the availability of parts in JLCPCB...."

= Developing Custom Firmware =
== For the Jetson Orin Nano ==

= Flashing =
=

Notes:
- Current Design constraints:
- Based off of the availability of parts in JLCPCB. Possibility of parts not being found or existing.
-

- Flashing is done with the flash.sh script through the following command
$ sudo ./flash.sh <board> <rootdev>
where board is the actual board (Jetson-Nano-XX, etc.)
rootdev determines what type of device is being flahed. Use mmcblk0pc1 to flash a local storage device (eMMC or SD card)
- TO begin flashing, put the device into force recovery mode and then press reset.
- Run the flash script using the previous command specified.

Flash using a convenient script:
- To avoid having to specify the rootdev andthe board configurations, can use the custom flashing script:
-

Using GPIO Pins to program protocol:
- you can use the rasberry pi libraries to interface with the pins, configuring them to whatever layout that is needed.
- Example: it is possible to direclty interface with the i2c system in the nano by using the

Wireless Modules

2024-05-28T08:52:50Z

Vedant:

= Justification =
Robust, wireless communication between multiple PCB boards decreased design constraints and wiring, allowing for much more modular and adjustable designs capable. This would allow for mobility, ease of communication, reduced clutter, and scalability. Could potentially

= Current Methods of Integration =

= ESP32 Built-In =
== Connections ==
=== UART Communication ===
* Hook up UART_TX and UART_RX to STM32.

=== I2C Communication ===
=== SPI Communication ===
== Firmware ==
== Examples ==
[https://www.digikey.com/en/products/detail/espressif-systems/ESP32-C3-MINI-1-N4/13877574 ESP32-C3-MINI-1-N4]
* ESP32 Chip adjusted specifically for the sole purpose of wireless communication.
* Interfaced with using UART
*
[https://www.digikey.com/en/products/detail/espressif-systems/ESP32-WROOM-32-N4/8544298 ESP32-WROOM-32]
* uses UART To both receive and send data to other modules

== Pros and Cons ==
=== Pros ===
Allows for convenient, easy to mount access to wireless communication.
Easy to interface with, using UART in order to communicate data.

=== Cons ===

= Bluetooth Modules =
== Component Selection ==
=== HC_05/HC_06 ===
=== CYM4343W ===
Contains both Bluetooth as well as Wifi protocols
Uses UART for Bluetooth
Uses SDIO for wifi communication

== Pros and Cons ==
=== Pros ===
* Simple implementation with supported Code
=== Cons ===
* Separate PCB Board interfaced with/ Not modular.

== TODO ==
Look into the specific components of the Bluetooth modules to find ICS that can be easily used and interfaced with.
Figure out how to interface with ESP32 software using STM32, how to send specific commands, etc.

= Interfacing with Other Boards =
== Network Setup ==
=== Access Point ===
Set up one device as the master. Intended purpose of the CANdaddy. Host signal and allow other devices to connect using SSID and password. In the case of the ESP32, this is done through built in libraries that allow for
== Communication Protocol ==
== Data Exchange ==

Wireless Modules

2024-05-28T08:36:23Z

Vedant: /* Examples */

= Justification =
Robust, wireless communication between multiple PCB boards decreased design constraints and wiring, allowing for much more modular and adjustable designs capable. This would allow for mobility, ease of communication, reduced clutter, and scalability.

= Current Methods of Integration =

= ESP32 Built-In =
== Connections ==
=== UART Communication ===
* Hook up

=== I2C Communication ===
=== SPI Communication ===
== Firmware ==
== Examples ==
[https://www.digikey.com/en/products/detail/espressif-systems/ESP32-C3-MINI-1-N4/13877574 ESP32-C3-MINI-1-N4]
* ESP32 Chip adjusted specifically for the sole purpose of wireless communication.
* Interfaced with using UART
*
[https://www.digikey.com/en/products/detail/espressif-systems/ESP32-WROOM-32-N4/8544298 ESP32-WROOM-32]
* uses UART To both receive and send data to other modules

== Pros and Cons ==
=== Pros ===
Allows for convenient, easy to mount access to wireless communication.
Easy to interface with, using UART in order to communicate data.

=== Cons ===

= Bluetooth Modules =
== Component Selection ==
=== HC_05/HC_06 ===
=== CYM4343W ===
Contains both Bluetooth as well as Wifi protocols
Uses UART for Bluetooth
Uses SDIO for wifi communication

== Pros and Cons ==
=== Pros ===
* Simple implementation with supported Code
=== Cons ===
* Separate PCB Board interfaced with/ Not modular.

== TODO ==
Look into the specific components of the Bluetooth modules to find ICS that can be easily used and interfaced with.

Wireless Modules

2024-05-28T08:34:54Z

Vedant: /* UART Communication */

Wireless Modules

2024-05-28T08:32:55Z

Vedant: /* TODO */

Wireless Modules

2024-05-28T08:32:46Z

Vedant: /* Pros and Cons */

Wireless Modules

2024-05-28T08:32:33Z

Vedant: /* Pros */

Wireless Modules

2024-05-28T08:31:13Z

Vedant: /* CYM4343W */

Wireless Modules

2024-05-28T08:30:55Z

Vedant: /* ESP32 Built-In */

Wireless Modules

2024-05-28T07:45:02Z

Vedant: Created page with "= Justification = Robust, wireless communication between multiple PCB boards decreased design constraints and wiring, allowing for much more modular and adjustable designs ca..."

K-Scale CANdaddy

2024-05-28T07:38:08Z

Vedant:

= Features =
# USB-C + Battery compatibility
# Able

=== Voltage ===

* Load sharing between USB and battery

= Central Components =

== MCU ==
=== STM32 ===

Used:

STM32F407VET6
Justification: 512 kB of flash memory, unit price at $3, powerful enough to run heavy programs

== Buttons + Debouncer ==

* Button Debouncer
** TODO: Add the IC name

== LCD ==

=== PCF2518 ===

* How do we connect I2C chip to the LCD screen?

== Battery Charger ==

== CAN Communication ==
=== MCP2515 ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

= Design =
== Schematic ==
== Layout ==
== Final Form Factor ==

= Other =
== Questions ==

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

== Notes ==
* Need to figure out the interface for the SPI lines using MCP2515
** Pros if successful:
*** Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
** Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

== Github Repository ==

K-Scale CANdaddy

2024-05-28T07:36:41Z

Vedant: /* Battery Charger */

K-Scale CANdaddy

2024-05-28T07:36:29Z

Vedant: /* MCP 2515 */

= Features =
# USB-C + Battery compatibility
# Able

=== Voltage ===

* Load sharing between USB and battery

= Central Components =

== MCU ==
=== STM32 ===

Used:

STM32F407VET6
Justification: 512 kB of flash memory, unit price at $3, powerful enough to run heavy programs

== Buttons + Debouncer ==

* Button Debouncer
** TODO: Add the IC name

== LCD ==

=== PCF2518 ===

* How do we connect I2C chip to the LCD screen?

== Battery Charger ==

=== MCP 2515 ===

== CAN Communication ==
=== MCP2515 ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

= Design =
== Schematic ==
== Layout ==
== Final Form Factor ==

= Other =
== Questions ==

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

== Notes ==
* Need to figure out the interface for the SPI lines using MCP2515
** Pros if successful:
*** Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
** Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

K-Scale CANdaddy

2024-05-28T07:36:18Z

Vedant: /* CAN Communication */

= Features =
# USB-C + Battery compatibility
# Able

=== Voltage ===

* Load sharing between USB and battery

= Central Components =

== MCU ==
=== STM32 ===

Used:

STM32F407VET6
Justification: 512 kB of flash memory, unit price at $3, powerful enough to run heavy programs

== Buttons + Debouncer ==

* Button Debouncer
** TODO: Add the IC name

== LCD ==

=== PCF2518 ===

* How do we connect I2C chip to the LCD screen?

== Battery Charger ==

=== MCP 2515 ===

== CAN Communication ==
=== MCP2515 ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

= Design =
== Schematic ==
== Layout ==
== Final Form Factor ==

= Other =
== Questions ==

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

== Notes ==
* Need to figure out the interface for the SPI lines using MCP2515
** Pros if successful:
*** Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
** Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

K-Scale CANdaddy

2024-05-28T07:35:47Z

Vedant:

= Features =
# USB-C + Battery compatibility
# Able

=== Voltage ===

* Load sharing between USB and battery

= Central Components =

== MCU ==
=== STM32 ===

Used:

STM32F407VET6
Justification: 512 kB of flash memory, unit price at $3, powerful enough to run heavy programs

== Buttons + Debouncer ==

* Button Debouncer
** TODO: Add the IC name

== LCD ==

=== PCF2518 ===

* How do we connect I2C chip to the LCD screen?

== Battery Charger ==

=== MCP 2515 ===

== CAN Communication ==
=== MCP2515 ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

= Design =
== Schematic ==
== Layout ==
== Final Form Factor ==

= Other =
== Questions ==

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

== Notes ==
* Need to figure out the interface for the SPI lines using MCP2515
** Pros if successful:
*** Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
** Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

K-Scale CANdaddy

2024-05-28T07:34:54Z

Vedant:

= Features =
# USB-C + Battery compatibility
# Able

=== Voltage ===

* Load sharing between USB and battery

= Central Components =

== MCU ==
=== STM32 ===

Used:

STM32F407VET6
Justification: 512 kB of flash memory, unit price at $3, powerful enough to run heavy programs

== Buttons + Debouncer ==

* Button Debouncer
** TODO: Add the IC name

== LCD ==

=== PCF2518 ===

* How do we connect I2C chip to the LCD screen?

== Battery Charger ==

=== MCP 2515 ===

== CAN Communication ==
=== MCP2515 ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

= Other =
== Questions ==

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

== Notes ==
* Need to figure out the interface for the SPI lines using MCP2515
** Pros if successful:
*** Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
** Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

K-Scale CANdaddy

2024-05-28T07:34:24Z

Vedant:

= Features =
# USB-C + Battery compatibility
# Able

=== Voltage ===

* Load sharing between USB and battery

= Central Components =

== MCU ==
= STM32 =

Used:

STM32F407VET6
Justification: 512 kB of flash memory, unit price at $3, powerful enough to run heavy programs

== Buttons + Debouncer ==

* Button Debouncer
** TODO: Add the IC name

== LCD ==

=== PCF2518 ===

* How do we connect I2C chip to the LCD screen?

== Battery Charger ==

=== MCP 2515 ===

== CAN Communication ==
=== MCP2515 ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

= Other =
== Questions ==

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

== Notes ==
* Need to figure out the interface for the SPI lines using MCP2515
** Pros if successful:
*** Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
** Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

K-Scale CANdaddy

2024-05-28T07:28:51Z

Vedant:

=== MCU ===

* STM32
** Programming mode button (boot / reset)
Used:

STM32F407VET6
Justification: 512 kB of flash memory, unit price at $3, powerful enough to run heavy programs

=== USB ===

* adsfasdfasdf

=== Buttons ===

* Button debouncer
** TODO: Add the IC name

=== LCD ===

=== PCF2518 ===

* How do we connect I2C chip to the LCD screen?

=== Battery Charger ===

=== MCP 2515 ===

=== Github access ===

=== CAN ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

=== Voltage ===

* Load sharing between USB and battery

=== Questions ===

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

=== Notes ===
* Need to figure out the interface for the SPI lines using MCP2515
** Pros if successful:
*** Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
** Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

K-Scale CANdaddy

2024-05-28T01:24:25Z

Vedant:

=== MCU ===

* STM32
** Programming mode button (boot / reset)

=== USB ===

* adsfasdfasdf

=== Buttons ===

* Button debouncer
** TODO: Add the IC name

=== LCD ===

=== PCF2518 ===

* How do we connect I2C chip to the LCD screen?

=== Battery Charger ===

=== MCP 2515 ===

=== Github access ===

=== CAN ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

=== Voltage ===

* Load sharing between USB and battery

=== Questions ===

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

=== Notes ===
* Need to figure out the interface for the SPI lines using MCP2515
** Pros if successful:
*** Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
** Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

K-Scale CANdaddy

2024-05-28T01:17:04Z

Vedant: /* PCF2518 */

=== MCU ===

* STM32
** Programming mode button (boot / reset)

=== USB ===

* adsfasdfasdf

=== Buttons ===

* Button debouncer
** TODO: Add the IC name

=== LCD ===

=== PCF2518 ===

* How do we connect I2C chip to the LCD screen?

=== Battery Charger ===

=== MCP 2515 ===

=== CAN ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

=== Voltage ===

* Load sharing between USB and battery

=== Questions ===

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

=== Notes ===
* Need to figure out the interface for the SPI lines using MCP2515
** Pros if successful:
*** Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
** Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

K-Scale CANdaddy

2024-05-28T01:16:11Z

Vedant:

=== MCU ===

* STM32
** Programming mode button (boot / reset)

=== USB ===

* adsfasdfasdf

=== Buttons ===

* Button debouncer
** TODO: Add the IC name

=== LCD ===

== PCF2518 ==

* How do we connect I2C chip to the LCD screen?

=== Battery Charger ===

=== MCP 2515 ===

=== CAN ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

=== Voltage ===

* Load sharing between USB and battery

=== Questions ===

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

=== Notes ===
* Need to figure out the interface for the SPI lines using MCP2515
** Pros if successful:
*** Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
** Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

K-Scale CANdaddy

2024-05-27T01:13:29Z

Vedant:

=== MCU ===

* STM32
** Programming mode button (boot / reset)

=== USB ===

* adsfasdfasdf

=== Buttons ===

* Button debouncer
** TODO: Add the IC name

=== LCD ===

* How do we connect I2C chip to the LCD screen?

=== CAN ===

* How to get supply-side VCC without having it on the bus (from supply-side GND)?
* What do we do if supply-side GND is missing?

=== Voltage ===

* Load sharing between USB and battery

=== Questions ===

# How does the switching regulator mechanism work?
# Do digital logic levels depend on source voltage? For example, let's say that a 3.3V powered device is sending signals to a 5V power device. From my understanding of the datasheet, a direct connection between the signals should not be allowed. However, why is this? What are the internal mechanisms of the pins that make it so that the logic levels need to be based off of the source voltage?
# I understand that there is a way to both use the battery as a source as well as to charge it using the USB. However, wouldn't this mean not being able to put a diode within the circuit directing current in one direction? Isn't this a hazard, destroying the circuit the moment a bit of noise comes through?
# Power Ground in the context of a switching regulator for our circuit to amplify 3.7 V battery to 5 V source. Do we just connect Power Ground to Battery Ground?

=== Notes ===
* Need to figure out the interface for the SPI lines using MCP2515
* Pros if successful:
* Reduces amount of wiring for STM32, requires just one SPI bus with a bunch of easily programmable chip selects
* Cons: Need to understand the interface for the MCP2515. Need to confirm how interrupts and timing works.

CAN Daddy

2024-05-24T23:40:55Z

Vedant: /* Design Requirements */

== Design Requirements ==

* Means bullet point

= * n means a header of some kind. Need to wrap it.

CAN Daddy

2024-05-24T23:40:22Z

Vedant: /* Design Requirements */

== Design Requirements ==

*Hello there

CAN Daddy

2024-05-24T23:40:13Z

Vedant: /* Design Requirements */

== Design Requirements ==

*Hello there
asdf

CAN Daddy

2024-05-24T23:40:05Z

Vedant: /* Design Requirements */

== Design Requirements ==

*Hello there*

CAN Daddy

2024-05-24T23:39:53Z

Vedant: /* CAN Daddy */

== Design Requirements ==

CAN Daddy

2024-05-24T23:39:45Z

Vedant: Created page with "=== CAN Daddy === == Design Requirements =="

=== CAN Daddy ===

== Design Requirements ==

K-Scale CANdaddy

2024-05-14T20:18:03Z

Vedant:

User:Vedant

2024-05-09T10:47:11Z

Vedant:

{{infobox person
| name = Vedant Jhawar
| organization = [[K-Scale Labs]]
| title = Technical Intern
}}

[[Category: K-Scale Employees]]

User:Vedant

2024-05-09T10:46:06Z

Vedant: Created page with "{| class="wikitable" |- ! Vedant Jhawar !! |- | Name || Vedant Jhawar |- | Organization || K-Scale Labs |- | Title || Technical Intern |- |}"

{| class="wikitable"
|-
! Vedant Jhawar !!
|-
| Name || Vedant Jhawar
|-
| Organization || K-Scale Labs
|-
| Title || Technical Intern
|-
|}