ENDURIDE·VEHICLE TELEMATICS
A crash alert is only useful if it arrives in time.
Enduride is a ₹1,139 telematics dongle that collects 10+ driving parameters per second, predicts maintenance issues, detects crashes, and logs trips on-chain for emergency response. It won the Enduraverse Hackathon.
Role
Team lead / firmware + app
Stack
React Native, Arduino, Solidity
Hardware cost
₹1,139
Competition
Enduraverse Hackathon winner

Architecture
How the system fits together
Vehicle sensors → Arduino dongle → mobile app → on-chain trip logs
The problem
Emergency response is slow because data is missing
After a crash, every minute matters. But first responders often do not know where the vehicle is, how severe the impact was, or who to contact. The data exists in the car’s sensors, but it never reaches the people who need it.
The goal was to build a cheap, open device that bridges that gap.
Competitive gap
What existing vehicle safety products get wrong
Factory crash systems are locked to the manufacturer and only call their own service centers. Aftermarket GPS trackers report location but miss impact severity. Insurance dongles optimize for premiums, not for first responders.
Enduride is open, cheap, and sends both location and impact data to the driver and emergency contacts.
Data flow
A dongle that talks to three audiences
Enduride reads accelerometer, gyroscope, GPS, and engine-like signals from an Arduino-based dongle. It sends data to a React Native app over Bluetooth/Wi-Fi, runs a lightweight predictive model for maintenance, and writes trip hashes to a Solidity contract for tamper-evident logs.
The same stream serves the driver, the mechanic, and the emergency responder.
The fix
Firmware throughput was the bottleneck
Early versions dropped packets when sending over Bluetooth. We rewrote the serial protocol to batch readings, added checksums, and tuned the sampling rate so the phone could keep up without killing the dongle battery.
The result was a 25% throughput improvement across Bluetooth and Wi-Fi tests.
struct Packet {
uint32_t timestamp;
float ax, ay, az;
float gx, gy, gz;
float lat, lon;
uint16_t crc;
};
void send_batch(const Packet* batch, uint8_t n) {
Serial.write(0xAA); // start marker
Serial.write(n);
Serial.write((uint8_t*)batch, sizeof(Packet) * n);
Serial.write(0x55); // end marker
}Results
Measured outcomes
We tested the dongle across city and highway driving, plus simulated crash events.
< 5s
Crash alert latency
FROM IMPACT TO APP ALERT
98%
Predictive maintenance accuracy
ON HELD-OUT TESTS
+60%
Emergency response improvement
WITH LOCATION + TRIP LOG
Source · Enduraverse Hackathon test track, simulated events
Lessons
What building it taught me
Hardware projects fail at the interface. The sensor works, the app works, but the BLE pairing, the power budget, and the packet format will each waste a day you did not plan for.
The blockchain part was the easiest to reason about: write a hash, not the whole trip. On-chain storage is expensive; on-chain truth is cheap.
The hard part of IoT is not the sensor; it is getting the packet from the sensor to the screen intact.
Still open
Where it is still rough
Simulated crashes only
Real crashes have complex impact profiles. The threshold was tuned on hammer strikes and hard braking tests, not actual accident data.
Power budget
Continuous GPS and Bluetooth keep the dongle alive for hours, not days, on a small battery. A vehicle-powered version is needed for production.
Blockchain durability
Trip hashes are on-chain, but the off-chain trip data still needs a pinning strategy or self-hosting to remain retrievable.
In short
What Enduride came down to
01
Packet integrity first
A sensor is useless if the data never arrives. Batch, checksum, retry.
02
One stream, many uses
The same telemetry serves the driver, mechanic, and emergency responder.
03
Hash the trip
On-chain storage is for truth, not for files.


