Skip to main content

Wireless Setup Documentation

📌 What is this for? (Quick Summary for New Interns)​

In simple words: This document explains how data travels between the physical pod and our servers over trackside wireless networks. It explains the TCP/IP network connection on port 20006, how the Go server buffers incoming packets, and how 13-byte CAN bus sensor frames are received and verified.

Prepared by: Sirish Sekhar

TuTr Hyperloop Pvt. Ltd. — Private & Confidential

1. Communication

1.1 TCP/IP Protocol Overview :​

The TCP/IP protocol suite is the foundational communication framework of the internet and most local networks. It stands for Transmission Control Protocol/Internet Protocol and consists of a layered set of protocols that allow devices to communicate reliably over both wired and wireless networks.

While TCP - used for end-to-end communication and data integrity & IP - Handles logical addressing and routing of packet.

1.2 Client-Server Connection​

How Connection is Established​

  1. Server starts and listens on IP 0.0.0.0 and port 20006.
    • This means it's ready to accept connections from any client on that port.
  2. A client connects (e.g., another computer or device).
    • The server accepts the connection and logs the client's IP.
  3. The connected client is added to a list of active clients.
  4. A new separate process (goroutine) starts for that client to keep listening to incoming data.
  5. The server also keeps checking (every 5 seconds) if the client is still connected by sending a small “ping”.
    • If the client disconnects or doesn't respond, it's removed from the list.

Note: Only one client can be connected to the server.

1.3 CAN Message Processing and Buffer Management​

How CAN is Processed​

  1. The client sends CAN messages to the server over the TCP connection.
  2. The server reads data from the client in chunks (using a 1024-byte buffer).
  3. But a CAN message is always 13 bytes, so:
    • The server collects the incoming data into a temporary dataBuffer.
    • It waits until it has at least 13 bytes in that buffer.
  4. Once there are 13 or more bytes:
    • It checks if the first 13 bytes are a valid CAN message (by checking if the length byte equals 8).
    • If valid, it processes the message.
    • If not valid, it throws away just 1 byte and tries again (to skip bad or misaligned data).
  5. After processing, it removes that message from the buffer and checks if another complete 13-byte message is waiting.

Why the Buffer is Used​

  • TCP doesn't guarantee message boundaries, so a single read might have half a CAN message, one full message, or even multiple messages.
  • The buffer helps assemble complete messages and process them one-by-one, even if they arrive in parts or bunched together.

2. Edge Computing (Rpi5 Setup)

2.1 - 2.2 - Refer RPi5 Connection Journal for this particular section.

3. CAN Processing with Go

3.1 CAN ID :​

What is CAN ID and How Is It Used?​

Every CAN message your server receives includes:

  1. Length (1 byte) – Always 8 in your case.
  2. CAN ID (4 bytes) – A unique number that tells what type of data the message contains (like a label).
  3. Data (8 bytes) – Actual data values like voltage, current, speed, etc.

What Happens When a CAN Message Arrives?​

  1. Your code reads the full 13 bytes (1 length + 4 CAN ID + 8 data).
  2. It extracts the CAN ID and checks:
    • If it's 1281 → it means inverter voltage/current data.
    • If it's 1282 → it means inverter fault data.
    • If it's 1283 → it means slip speed and Vrms.
    • If it's 1284 → it means frequency and speed.
  3. Based on the CAN ID, it calls the correct function (processCANMessage101, 102, etc.).

3.2 Buffer :​

How the Data Buffer is Used​

Inside each function like processCANMessage101, the 8-byte data is split:

  • First 4 bytes: converted into a float32 (e.g., current).
  • Next 4 bytes: converted into another float32 (e.g., voltage).

This is done using:

math.Float32frombits(binary.BigEndian.Uint32(data[:4]))

So, the buffer holds raw binary data, and your code decodes it into readable values like 12.45 V or 34.8 A.

Where the Final Values Go?​

All processed values are stored in a shared map called LatestMessage.Data, so other parts of your program (like a dashboard or logger) can easily access the latest sensor readings.

4. AWS IoT Core

🔹 Step 1: Go to AWS IoT Core​

🔹 Step 2: Register Your Device (Thing)​

  • Navigate to Manage > Things > Create things
  • Choose Create a single thing
  • Name it (e.g., Rpi5)
  • Skip adding device shadow
  • Click Next

🔹 Step 3: Create Certificates​

  • Choose Auto-generate new certificate
  • Click Create thing

🔹 Step 4: Download Required Files​

Download and save the following to your Raspberry Pi:

  • device-certificate.pem.crt
  • private.pem.key
  • AmazonRootCA1.pem (link provided in AWS UI)
  • Save endpoint from AWS (you'll use this later)
  • Click Activate the certificate
  • Click Attach Policy and create one if needed:
json
CopyEdit
{
  "Effect": "Allow",
  "Action": "iot:*",
  "Resource": "*"
}

Attach it to the certificate.

🔹 Step 5: Transfer Certs to RPi​

move these files to /home/pi/certs:

  • device-certificate.pem.crt
  • private.pem.key
  • AmazonRootCA1.pem

Install MQTT Client​

bash
CopyEdit
go get github.com/eclipse/paho.mqtt.golang

const (
endpoint = "[your-endpoint.iot.your-region.amazonaws.com:8883](http://your-endpoint.iot.your-region.amazonaws.com:8883/)"
certFile = "certs/device-certificate.pem.crt"
keyFile  = "certs/private.pem.key"
caFile   = "certs/AmazonRootCA1.pem"
topic    = "test/topic"
)

5. Python MQTT Container

Use case :​

  1. Connects your backend (FastAPI) to AWS IoT Core securely using TLS certificates.
  2. Whenever a message is received from AWS IoT:
    • It formats it and sends it to connected WebSocket clients (like a React frontend).
  3. The backend also has a /control API to:
    • Send control messages ("enable" or "disable") back to AWS IoT.

How It Works :​

  • /ws WebSocket endpoint:

    Lets the frontend connect and receive live updates (like a real-time dashboard).

  • /control GET API:

    Frontend sends ?command=enable or ?command=disable

    → Backend publishes that to AWS IoT Core

    → AWS IoT sends to the device.

6. React Frontend

React helps you build fast, dynamic, and real-time dashboards that feel like mobile apps.

  • It updates only what changes (e.g., speed or voltage) without refreshing the whole page.
  • Works smoothly with WebSockets to show live data instantly.
  • Easy to break your UI into reusable components like charts, meters, and control buttons.
  • Works perfectly with backend APIs and AWS IoT messages.

7. InfluxDB Storage & Real-Time Monitoring

What’s InfluxDB?​

It's like a time-based database — perfect for storing live sensor data like vehicle speed, current, and voltage with timestamps.

How the Code Works :​

  1. Connect to InfluxDB:

    The InitInfluxDB() function connects your Go code to the InfluxDB server (like logging into the database).

  2. Read CAN Data:

    The logCANMessage() function reads raw CAN bus data (like vehicle speed or battery info) and turns it into human-readable values (like 12.5V, 60km/h).

  3. Buffer Data:

    Instead of sending every message instantly, it collects 5 messages into a temporary storage called a “buffer” for performance.

  4. Write to InfluxDB:

    Once the buffer has 5 entries, writeBatchToInfluxDB() sends all 5 to InfluxDB at once (efficient and fast).

  5. Repeat Every 0.5s:

    The LogPeriodicCANMessages() function runs in a loop, calling the logger every 0.5 seconds to simulate live data streaming.

8. Additional

8.1 AWS Cognito For secure SSO​

  • Amazon Cognito offers user authentication, authorization, and user management for web and mobile apps.
  • It supports SSO (Single Sign-On) via SAML, OIDC, and social logins (Google, Facebook, etc.).

8.2 API Gateway​

  • Use API Gateway to expose your backend securely (e.g., FastAPI/Go on RPi or AWS ECR).
  • Combine with Cognito for login-protected APIs.
  • Good for IoT control panel.