TELEMATICS TALKS - EPISODE 10 Guest: Oscar Zhang, General Manager DVR Business Unit, Jimi IoT Host: Vlad, Vice President of Operations, Navixy Topic: AI-Driven Event-Based Video Telematics ═══════════════════════════════════════════════════════════════════════════════ Vlad: Hello everyone, and welcome back to Telematics Talks. I'm Vlad, Vice President of Operations at Navixy. Today's episode is special because we're talking about AI-driven, event-based video telematics. As many of you know, at Navixy we've recently added Lightmetrics to our Marketplace, giving partners an easy path to bring video intelligence into their fleets. And on the hardware side, one of the manufacturers is Jimi IoT. Our guest today is Oscar Zhang, General Manager of the DVR business unit at Jimi IoT — the team behind the G-series multi-camera AI dash cams used by fleets across 180+ countries. Oscar leads product strategy for predictive analytics, covering everything from ADAS and DMS to multi-channel recording and cloud workflows that keep costs down and evidence secure. In this conversation, we'll dive into questions like: how do we capture the right clip when coverage is spotty and data is expensive? What's the practical upload playbook — LTE now versus Wi-Fi later, storage sizing, and SD card health? And for high-risk cargo: how do you protect shipments with camera layouts, tamper and jamming detection, and smart retention? So let's get into it. Oscar, it's great to have you here. How are you? ─────────────────────────────────────────────────────────────────────────────── Oscar: Nice to meet you too. I'm doing well, thank you. ─────────────────────────────────────────────────────────────────────────────── Vlad: Great. My first question is: what actually motivated you? What was that exact moment when you thought, "Yes — video is essential, not just a nice-to-have"? Was it meeting a client, or a product launch, or something else? ─────────────────────────────────────────────────────────────────────────────── Oscar: Early in this industry, the main focus was location tracking — basic telematics. Video was often seen as an extra: nice to have, but not essential. If I had to pinpoint a moment that really shifted my thinking, it was during a customer visit. The customer was a logistics company that adopted our video solution. After only a few months, I visited their office and they showed me the results. In just one month, they reduced operational costs and sharply reduced road incidents. They also successfully resolved several insurance claims. But what stood out the most was what they told me: it's not just a camera — it's a witness. That really shifted my perspective. It's not only about specific features; it's about real impact: reducing costs, improving driver safety, and building a safety culture. That's why we keep releasing new products and solutions — to help customers get more value. ─────────────────────────────────────────────────────────────────────────────── Vlad: Amazing, thank you. I totally understand why you made that shift — when you see real value for the customer, everything becomes clear. Let's move on. I'll give a bit of context for the audience: a lot of routes have thin coverage, and data isn't cheap. Continuous video sounds good, but in practice it can miss key moments when the truck goes offline, and it floods the team with footage to review. The real need is reliable evidence — at predictable cost. So let's get practical. Do you think live streaming, continuous streaming, is really worth it? ─────────────────────────────────────────────────────────────────────────────── Oscar: That's an interesting question. I wouldn't say "never," but it only makes sense in specific cases. For example: short-haul, high-value operations — where the cost of 24-hour or even 48-hour live streaming is acceptable. But for most logistics fleets, it's too expensive and wasteful. That's why we shifted from continuous streaming to an event-based smarter system that captures what really matters. ─────────────────────────────────────────────────────────────────────────────── Vlad: Got it. Next question: what's the main pain point for fleets? Is it the data bills, the number of clips they have to review, or something else? What hurts the fleet manager most? ─────────────────────────────────────────────────────────────────────────────── Oscar: It's a complex question because there are many types of fleets, but generally I'd summarize three main pain points. First: operational cost. That includes data costs, time spent reviewing clips, and also the financial risk of missing a video event — which can lead to insurance payouts. Second: safety and security. That includes safety of the vehicle, cargo, and drivers. Without reliable video evidence, you miss opportunities for driver coaching and effective security monitoring. Third: regulatory compliance. Many countries are releasing new regulations around driver behavior, working hours, and security standards. Non-compliance isn't just about fines — it can affect a fleet's ability to operate. ─────────────────────────────────────────────────────────────────────────────── Vlad: That makes sense. Instead of streaming everything, fleets are moving to edge AI — the camera detects important moments and sends only those clips, plus a short buffer so you get context. Clear evidence, predictable data costs, and less time spent reviewing. The real art is choosing the right alerts, tuning buffer length, reducing false alarms, and keeping drivers on-side. So let's dig into the practical basics. Oscar, what should the main settings be when starting with customers and partners? What are your tips on which alerts to enable first, and how to get a simple, easy setup running? ─────────────────────────────────────────────────────────────────────────────── Oscar: There are many different types of alerts on the device. For driver safety, the most important are things like speeding, ADAS, and DMS — anything that helps detect risky driving behavior and explain what happened and why. That supports driver coaching. Other alerts like "camera blocked" should be sent to the operations team because they need to fix it or take action — it's not necessarily useful for the driver. And alerts like SOS or collision are the highest priority, because the operations team needs to respond quickly and contact the driver. So customers should define alert priorities. We suggest high-priority alerts should be sent to the cloud immediately. Lower-priority events can wait until higher-priority uploads are done. ─────────────────────────────────────────────────────────────────────────────── Vlad: So if I'm understanding correctly: most high-priority alerts should go over LTE immediately, and lower-priority ones can wait for Wi-Fi to save data? ─────────────────────────────────────────────────────────────────────────────── Oscar: Yes. Most devices can connect to Wi-Fi hotspots or a Wi-Fi station. But continuous streaming isn't useful for most fleets — we're shifting to event-based. For event-based systems, all alerts can be uploaded over LTE, but the key is prioritization: upload high-priority events first, then others. And if you want to upload a larger set of footage — for example, the last 4 or 8 hours stored in the device — you can do that when the vehicle reaches a Wi-Fi station and upload everything to the server. ─────────────────────────────────────────────────────────────────────────────── Vlad: Can you give examples of high-priority alerts that should definitely be sent over LTE right away? ─────────────────────────────────────────────────────────────────────────────── Oscar: One example is the SOS button on the hardware. If the driver experiences a dangerous situation, they press the button and the operations team is notified. After that, they can start live streaming to see what's happening in the cabin, listen through the device, and then contact other drivers or call for help. Another example is collision detection. If the device detects a collision, there may be injuries — the operations team needs to handle that immediately. ─────────────────────────────────────────────────────────────────────────────── Vlad: Collision detection is a really interesting topic. What would be the standard buffer time for an event like that? You need context before the collision — you can't just record after. ─────────────────────────────────────────────────────────────────────────────── Oscar: We typically have a default of 15 seconds total: about 7 seconds before the event and 8 seconds after. But it can be configured longer — 30 seconds or even 60 seconds total. We suggest 15 seconds because it's usually enough to capture what happened and why. And if one clip isn't enough, the fleet manager can request the device to upload longer normal recording — for example, one minute or three minutes — to get more context. ─────────────────────────────────────────────────────────────────────────────── Vlad: Thank you. Partners often ask us: "We want to try video, but we're afraid of the data cost." This helps a lot. You mentioned the critical high-priority events like SOS and collision. Could you name some second-priority events — the ones that are uploaded only when Wi-Fi is available — so the audience understands that not everything is pushed to the cloud immediately? ─────────────────────────────────────────────────────────────────────────────── Oscar: Sure. Even within AI alerts, we can have different priorities. For example, if a distraction alert triggers multiple times in a short period — say three times in one minute — that's a real risk scenario, and we elevate it to high priority and send it immediately. But if an alert triggers only once, it could be a false event — maybe the driver looked to the side briefly. In that case it might not be urgent. Some alerts like speeding or geofence events can be lower or medium priority. The operations team can record them and review them in daily or weekly reports. But if events combine — for example, speeding plus distraction — that becomes higher priority because it's a safety and security issue. ─────────────────────────────────────────────────────────────────────────────── Vlad: That hierarchy is great: combining events to make something more urgent. Now, on the other side of the coin: not only data costs money, but human review also costs money. If too much is uploaded, reviewing becomes overwhelming. What's the best practice? How should they prioritize reviews? ─────────────────────────────────────────────────────────────────────────────── Oscar: It's good to have a review team to monitor the platform and focus on dangerous or high-priority events. But since resources are limited, the platform should also prioritize. Just like the device sends high-priority events first, the platform should surface high-priority events first for reviewers. Then, when they have time, they can review lower-priority events. ─────────────────────────────────────────────────────────────────────────────── Vlad: And what would you recommend for someone who wants to start simple — not enable everything and overwhelm themselves? What are the "must-have" alerts? ─────────────────────────────────────────────────────────────────────────────── Oscar: Start with the high-priority ones that protect driver and vehicle safety: ADAS, DMS, speeding. But you should also tune thresholds by context. For example, if speed is under 20 km/h and the driver checks a phone for navigation, that may not be too dangerous. But at higher speeds — for example 60 km/h — phone distraction is very dangerous. So we set different speed thresholds for different AI functions. Also, if the same risky event is detected repeatedly, we elevate it and use stronger in-cab warnings — it may feel noisy, but it can save lives. ─────────────────────────────────────────────────────────────────────────────── Vlad: That's the key: when coverage is spotty, don't upload everything — send the right clips at the right time. LTE for urgent events, Wi-Fi for the rest. Smart retry when the truck goes offline, enough local storage so nothing is lost, and good SD card management. Oscar, if you had to define simple rules: which alerts should go via LTE, and which via Wi-Fi? ─────────────────────────────────────────────────────────────────────────────── Oscar: If I had to name the top three that should go immediately: speeding, creation (crash/incident), and key AI safety features — driver safety events, especially when they're detected repeatedly in a short time. Other events can be uploaded later — for record-keeping and reporting for the operations team. ─────────────────────────────────────────────────────────────────────────────── Vlad: Switching topics: SIM cards. What's your suggestion for cross-border delivery, where vehicles move across countries and roaming becomes expensive? ─────────────────────────────────────────────────────────────────────────────── Oscar: Recently we've heard customers asking to integrate multi-IMSI SIM cards. With roaming, overseas data costs are high. But some operators offer SIMs with multiple identities. When the vehicle moves to another country, the SIM can use a local identity — which gives lower cost and more stable connectivity. The SIM itself can be more expensive than a normal one, but over time the total cost can be lower because roaming fees are so high. ─────────────────────────────────────────────────────────────────────────────── Vlad: Great. Now, what about loss of connectivity? The truck is outside coverage, the device keeps recording events onto the SD card, and they pile up. What happens when connectivity comes back — what gets uploaded first? ─────────────────────────────────────────────────────────────────────────────── Oscar: When the device reconnects, it should send real-time data first — continue uploading current events. Then it can start sending historical data in the background. If the device detects jamming, that event should be sent as a high priority as soon as possible, because the operations team needs to know immediately — it could mean theft or something serious. If it's simply an area with no network coverage, then the stored events can be uploaded later, one by one. ─────────────────────────────────────────────────────────────────────────────── Vlad: Right — it makes a big difference whether the vehicle went into a tunnel or was jammed. So those events are recorded on the SD card, but with different upload priority. ─────────────────────────────────────────────────────────────────────────────── Oscar: Exactly. If jamming is detected, it must be treated as high priority. We record it, create logs, and protect that footage so it can't be overwritten — stored in a secure area. Then when network is available, or someone reaches the vehicle, they can check those videos to understand what happened and when. If there is no jamming and the area is just outside network coverage, then it's normal recording that can be uploaded later. ─────────────────────────────────────────────────────────────────────────────── Vlad: Let's talk cargo safety. Safety cameras started with the road view, but a lot of losses happen around cargo and doors — in depots, after hours, with tampering and jamming. You can lose the one clip that proves what happened. So, Oscar, what's your recommendation for a basic cargo safety setup? Is it enough to have one internal camera and one rear camera, or should fleets build a larger multi-camera layout? ─────────────────────────────────────────────────────────────────────────────── Oscar: In general, first you need driver and road-facing cameras: one road-facing for ADAS, one driver-facing (DMS) to record the driver and cabin. A side camera can also help reduce blind spots. For cargo, we recommend a rear camera and a camera on top near the rear door to capture activity near the door. Also, a camera inside the cargo bay facing the door can be useful. With accessories like door sensors, when the door opens, the camera can start recording — especially during periods when the door should not be opened. ─────────────────────────────────────────────────────────────────────────────── Vlad: But there's a difference between a basic setup and a full 360-degree layout with extra cameras. What would you suggest for someone who wants to be sure the cargo is safe — is one camera inside the cargo bay enough? ─────────────────────────────────────────────────────────────────────────────── Oscar: For most fleets, that can be enough for monitoring cargo safety and providing evidence around the doors. But there are scenarios where fleets need more — for example, monitoring the fuel tank in areas where fuel theft is common. The key is the high-value risk points. If the cargo is high value or security risk is higher, then adding more cameras — including wider coverage like 360 monitoring — can make sense. For most cases, a basic setup is fine. ─────────────────────────────────────────────────────────────────────────────── Vlad: If you put cameras all over the vehicle and use motion triggers, does it create a lot of false alarms while driving? ─────────────────────────────────────────────────────────────────────────────── Oscar: While driving, cameras detect things like motorbikes or bicycles for safer driving. But most motion-triggered security events happen during parking periods — when the vehicle is stationary. If someone comes close, the camera detects it and starts recording. ─────────────────────────────────────────────────────────────────────────────── Vlad: For cargo security and tamper protection, what are the must-have alerts? Jamming, cutting wires, covering the lens — what should be prioritized? ─────────────────────────────────────────────────────────────────────────────── Oscar: The alerts you mentioned are all important because they indicate something is wrong — either device failure or tampering. If someone jams the device, cuts power wires, or covers the lens, the device should upload those alerts immediately to the server, so the fleet manager knows in real time. Then they can determine whether it's theft/tampering or a device issue, and take action. ─────────────────────────────────────────────────────────────────────────────── Vlad: And with jamming specifically: is it mostly GPS jamming, or network jamming? ─────────────────────────────────────────────────────────────────────────────── Oscar: It's mostly network, but both can happen. If the network is jammed, you can't get data from the device. GPS can also be affected — the location becomes wrong. Our device detects jamming by identifying abnormal signal patterns — for example, location suddenly becoming inconsistent compared to previous location, or signal behavior becoming abnormal. Then it flags it so the team knows. ─────────────────────────────────────────────────────────────────────────────── Vlad: Oscar, thank you for sharing your perspective on video telematics — this was really insightful. We covered cargo safety, data consumption, and a lot more. And for the listeners: if you're a telematics service provider or fleet operator looking to bring these solutions to your market, maybe we can help. We've added Lightmetrics to the Navixy Marketplace and work with leading device makers like Jimi IoT to make deployment straightforward and cost-effective. This has been Telematics Talks. Until next time — stay safe on the road. ═══════════════════════════════════════════════════════════════════════════════ Learn more: - Navixy: https://www.navixy.com - Jimi IoT: https://www.jimilab.com - Watch this episode: https://youtu.be/tgwQAX0v6B4