Our Products
Commercial Vehicle Vision Systems
  • Vehicle Camera System
  • MDVR Kits
  • HD Camera
  • HD Monitor
  • AI Wireless
  • Radar
  • Core Technology

How Recording Stays Intact When Network Drops

A vehicle terminal keeps recording when its network disappears, because the recording was designed from the first line to need no network at all. The cameras write to the card on the vehicle. The link carries copies, requests and alarms. A dropout interrupts the copies. The originals continue. The pages of this series on dropouts and dual SIM lean on this mechanism in one sentence each. The mechanism itself takes a page.

The design principle has a name in this series: local first. The terminal records every camera to its own storage as the frames arrive, all day, every day, at the full configured quality. The platform never carries that recording in real time. What crosses the network is a selection: a light live view when someone watches, an alarm parcel when an event fires, a stretch of stored footage when an investigator asks. The selection needs the link. The recording does not.

The principle decides what a network drop can cost. The live view dies for the duration. Alarm parcels wait. The recording itself continues unchanged, because no part of the recording path touches the radio. A fleet that understands this stops fearing tunnels for its evidence and starts asking the two questions that do matter, the card and the power. The tunnel costs the watching. The card keeps the footage.

The claim rests on named parts: the loop that writes, the files that survive interruption, the queue that holds the alarms, the resume that empties the queue, the timestamps that keep the record in order, the two failures the mechanism cannot absorb and the hardware that defends against both. A fleet can verify every part on a bench in an hour.

The link carries copies. The card holds the originals.

On this page

  1. The recording loop runs alone
  2. Files built to survive interruption
  3. What happens at the moment of the drop
  4. The alarm queue and the resume
  5. Timestamps keep the record in order
  6. Overwrite pressure and the retrieval window
  7. What the standards require of all this
  8. The two failures the mechanism cannot absorb
  9. Verifying the mechanism on a bench
  10. Before the order
  11. Common questions

The recording loop runs alone

The recording loop is a closed path inside the terminal. A camera delivers frames. The encoder compresses them. The writer lays the compressed stream onto the card. Every stage of that path lives on the vehicle, powered by the vehicle, connected by internal wiring. The modem sits on a different path entirely. The loop has no step that asks the network anything.

The separation is deliberate architecture. The terminal’s software runs the recording as its own task, with its own buffers and its own priority. The network tasks, registration, heartbeat, streaming, uploads, run beside it. A network task that stalls, retries or dies leaves the recording task untouched. The design treats the recording as the product and the network as one consumer of it.

The entrance ramp of an underground parking garage
The entrance of an underground garage. A vehicle that drives down this ramp leaves coverage for the whole stop. The recording loop runs on, unaffected. (Photo: Matti Blume, CC BY-SA 4.0)

The loop’s independence shows plainest in the places with no signal at all. A vehicle parked overnight in an underground garage records its cameras for the whole stop, on the parked-monitoring duty its power budget was sized for. A truck through a long tunnel records the whole tunnel. The dropout pages of this series catalogue where links die. None of those places appears in the recording’s own failure list, because the recording carries no dependency on the link at all.

The loop also ignores the link’s quality, the second half of the same independence. A vehicle on a congested cell, with a live view stalling and uploads crawling, records at full configured quality throughout. Network conditions shape what a viewer sees in the moment. They shape nothing about what the card holds. The evidence quality is set by the camera, the encoder settings and the card, three things the radio cannot reach.

The loop’s real dependencies need naming, because they are the honest boundary of the claim. The loop needs power from the vehicle, a working camera on the wire, a healthy card in the slot and a terminal that has not overheated into a reset. Those four appear in the dropout page’s terminal layer and in the failure section below. The network appears nowhere in the list. A fleet auditing its recording risk spends its attention on those four lines and spends none of it on coverage maps.

Files built to survive interruption

Continuous recording meets interruption from one direction the network never causes: power. A recording is a file being written. A file being written is a file at risk at the moment writing stops. The terminal’s answer is to write files that are playable at every moment of their life. The recorder allocates the clip file ahead of writing, fills it in order, updates its index as it goes and closes it on schedule. A clip interrupted at any point plays back to within moments of the interruption. The pre-allocation carries the weight in that sentence. A naive recorder grows its file as it writes and saves the file’s index at the close, so an interruption leaves a large file with no index, unreadable by a normal player. The duty-built recorder reserves the clip’s space on the card first, writes the video into the reserved run in order, then keeps the index current as the frames land. The file is whole at every moment by construction. The flush cadence sets how close to the cut the playable tail reaches: the writer pushes its buffered data to the card on a short cycle, in fractions of a second to seconds, so the unwritten remainder at any instant stays small. The clip length bounds the exposure. The recorder cuts the continuous recording into separate clips of a few minutes each, closed in turn as they fill. A failure during one clip risks the tail of that clip alone. The closed clips behind it sit complete on the card. The structure turns the worst case from a lost day into a lost fraction of a minute, the difference between an inconvenience and a destroyed case. The writing pattern also serves the card’s endurance. The recorder writes sequentially, in steady blocks, the pattern flash storage handles best. Cards built for this duty carry endurance ratings in the tens of thousands of recording hours and hundreds of terabytes written at fleet capacities, on the published figures of the high-endurance card lines. The pattern and the rating together are what let one small card take years of continuous writing, the duty the storage section of every terminal datasheet assumes without saying so. The same design also keeps the write rate inside the card’s speed class with margin, because a writer that outruns its card drops frames at the moments of highest scene activity, the moments an investigation cares about. The clip files, the pre-allocation, the steady flush and the sequential pattern add up to one property a fleet can state plainly: at any second of any day, the card holds a playable record up to moments ago, whatever the network is doing and whatever happens next.

What happens at the moment of the drop

The moment the link dies, the terminal’s network tasks notice and the recording task does not. The session times out. The keep-alive stops being answered. The terminal begins its reconnection routine, the registration cycle the dropout and dual-SIM pages walk in detail. The writer, mid-clip, writes on. The encoder takes the next frame. The loop does not carry a branch for offline, because no branch is needed where no dependency exists.

The live view in progress dies with the session. The platform marks the vehicle offline. An operator watching the vehicle loses the picture, the loss the dropout page prices. The picture the operator lost continues to exist: the same camera’s frames keep landing on the card at the recording tier’s full quality. The interruption removed a viewer. The view continued onto the card.

Alarms that fire during the gap behave the same way at the recording layer. The event is detected on the vehicle. The clip around it is cut from the buffer on the vehicle. The stills are grabbed on the vehicle. Everything evidential is assembled and stored locally, exactly as it would be with the link up. The single difference sits at the last step: the parcel cannot send, so it waits.

Position reports follow the same queue-and-deliver path, which is why the track on the map completes after a gap. The terminal keeps logging its positions through the offline stretch, on the blind-spot reporting the tracking layer carries. After reconnection the stored points upload with their own original times. The platform draws the missing stretch of track in one late stroke. A vehicle’s route record ends the day complete, with the offline period visible only in the delivery timestamps.

The platform’s offline marker carries exactly this meaning and no more. The grey marker says the centre cannot see the vehicle. It says nothing about the vehicle’s own record, which is running at full quality behind the grey. An operator trained on this distinction stops equating the marker with lost evidence. The marker is a viewing outage. The evidence question is answered on the card, hours later if needed, by the playback query or by the card in a reader at the depot.

The alarm queue and the resume

The waiting parcels sit in a queue on the terminal’s storage. Each entry holds the assembled evidence and the alarm record that names it: the event type, the channels, the original event time, the same fields a live parcel carries on a clear day. The queue survives reboots, because it lives on the card with everything else. A vehicle that spends an evening in a coverage hole builds a small backlog, held in the order the events fired, ready for the first usable link.

The queue’s size stays small by the arithmetic of the parcels. An alarm parcel runs in the megabytes, on the figures the consumption page prices. An evening of events totals tens of megabytes on the card, a sliver beside the routine recording the same hours lay down. Storage pressure from queued evidence is a rounding error. The pressure that matters sits in the routine footage, the subject of the overwrite section below.

The resume begins when the link returns, with no operator action on either end. The terminal registers, the platform acknowledges, the queued parcels upload in turn, oldest first. A parcel that was cut off mid-transfer resumes from its breakpoint, on the resumable transfer the attachment protocol carries, so the bytes already sent are never sent again. The backlog clears at the uplink’s pace, a burst of minutes for an evening’s events.

The burst is the pattern a usage portal shows after offline days, the day-level spike the billing pages teach a fleet to read by week. The spike is honest traffic: the same parcels that would have spread across the evening arrive in one window. A fleet that knows the mechanism reads the spike as the queue clearing, with the per-vehicle figures confirming which vehicles spent the evening offline.

The platform sees the burst as a batch of late arrivals, each carrying its original identity. Nothing about a queued parcel marks it as degraded. The same files, the same alarm numbers, the same completeness checks apply as for a parcel sent live. The delay is the only difference. The timestamps below are the reason the delay does not disorder the record.

Timestamps keep the record in order

Every recorded frame and every alarm carries the time of the event, written at capture on the vehicle, before any network is involved in anything. The upload time is a property of the network’s day. The event time is a property of the evidence. The platform files arriving parcels by their event times, so an alarm that uploaded at midnight files under the afternoon it happened. The record reads in the order things occurred, whatever order the network managed to deliver them in.

The terminal’s clock makes this trustworthy across long gaps. The clock disciplines itself to satellite time whenever a positioning fix exists, the one time source every vehicle on the road shares with every other. A vehicle offline for hours still stamps its events from a clock that was synchronised before the gap and drifts little across it. Two vehicles at the same incident stamp the same moment, each from its own copy of the same time source. A cross-vehicle reconstruction then lines up on its own, with no clock arguments in it.

The ordering survives audits for exactly this reason. An investigator reading a fleet’s record after a bad day sees events in event order, with the upload delays visible as metadata beside them. A delayed record that files correctly is evidence. A prompt record with wrong times is a problem. The design spends its care on the first property.

Overwrite pressure and the retrieval window

The card is a circle. The recorder writes until the card fills, then overwrites the oldest footage to continue. The card’s size and the configured recording bitrates set the circle’s circumference in days, on the same arithmetic the consumption and codec pages of this series already price per channel. A larger card or a leaner codec buys more days. The days are the retrieval window: the time a fleet has to pull footage off the vehicle before the circle comes around.

Network drops press on this window from one side. Footage that would have been retrieved promptly waits for the link, ages on the card and moves toward the overwrite horizon. A vehicle that works deep coverage holes for days at a stretch needs a window sized for its worst run, the sizing question the storage line of the specification answers. The alarm queue holds its parcels apart from this pressure, because queued evidence is pinned until sent.

The pinning is its own design rule. A recorder that let the circle eat its unsent alarm parcels would lose exactly the evidence the system exists to keep. The design holds queued parcels and their clips out of the overwrite path until the upload completes. The circle consumes the routine footage first, the unclaimed hours nobody asked for, in the order nobody will miss.

The window question turns into one specification line. Take the route’s longest realistic offline-plus-unvisited run in days. Multiply the configured recording rate by that run, on the storage arithmetic the consumption and codec pages carry. Size the card a comfortable step above the product. A fleet that writes that line once has answered the only storage question a network drop ever raises.

Retrieval discipline stretches the same window from the other end. A fleet that pulls footage by event, the alarm clips and the flagged stretches, leaves the routine hours to the circle and loses nothing it ever wanted. A fleet that tries to pull everything pays uplink time and storage twice for footage nobody will open. The event-led habit is the one the protocol’s query machinery was built for: ask the vehicle for the minutes that matter, by time and channel, and let the rest age out on schedule.

What the standards require of all this

The local-first design is written into the transport standards, with the core duties taken out of maker judgment. The terminal standard requires continuous recording to local storage, sets retention the recorder has to meet and tests the device’s behaviour through power events. The protocol family defines the stored-footage query, the playback request and the resumable attachment upload, the machinery described above, message by message in the published documents. A compliant terminal carries the mechanism because compliance is defined as carrying it.

The division of labour between the standards is the series’ recurring map. The terminal standard owns the device’s recording duties on the vehicle. The protocol owns how stored footage is found, fetched and uploaded across the link after the fact. The platform standard owns what the centre does with late arrivals. The black-box recorder of the data-recorder standard runs its own separate survival rules for crash data, a different device with a different page. A buyer who knows which document owns which promise reads a compliance claim with the right expectations and puts each acceptance question to the document that answers it.

The two failures the mechanism cannot absorb

Supercapacitor cells and modules of several sizes
Supercapacitor cells and modules. A small bank of cells of this kind holds enough energy to close the current clip file when the supply dies. (Photo: Sechsa, CC0)

The mechanism survives every network failure by design. Two failures sit outside its reach. Both are physical. The first is the card’s end of life. Flash storage wears by writing. A recorder writes all day for years. A card past its endurance begins to slow and to error, the storage-fault pattern the dropout page lists among terminal causes. The defence is specification and replacement: a high-endurance card sized for the duty, swapped on a schedule read from its rated hours, ahead of any failure.

The second is power loss in the instant of writing. A supply that vanishes mid-write risks the open clip’s tail and, on a bad day, the card’s filesystem. The defence is stored energy. A terminal built for the duty carries a holdup reserve, supercapacitors in current designs, sized to finish the write in flight, close the open file and shut down in order. The wide-voltage page of this series walks the supply’s behaviour through cranks and cutoffs. The holdup is the recording’s insurance against the supply’s worst second, sized in the design and tested at the bench.

Both defences are specification lines a buyer can read. The card line names the endurance class and the capacity. The power section names the holdup and the orderly shutdown. A terminal missing either line records perfectly through every network drop and stays exposed to the two failures that have nothing to do with networks. The mechanism is complete only with both lines present.

The two defences also age differently, which decides the maintenance plan. The holdup hardware is fitted once and tested at acceptance, with the power-cut bench test re-run after firmware updates. The card wears every day by design, so its line lives in the service schedule: a replacement interval computed from rated hours against the configured write rate, with the swap logged per vehicle. One defence is a purchase. The other is a routine.

Verifying the mechanism on a bench

The whole chain tests in an hour with one vehicle. Park it on the bench with the platform screen beside it. Disconnect the antenna to kill the link. Trigger a test alarm, then run a few minutes of recording with the link still dead. Reconnect the antenna. Watch the platform: the vehicle returns, the queued parcel arrives, the alarm files under its event time. Pull the card and play the clips recorded through the gap. Each claim of the mechanism either shows up on the screen or fails in front of the technician.

The power half tests with the same directness. Cut the supply mid-recording, restore it, pull the card. The last clip should play to within moments of the cut. The filesystem should mount clean. A terminal that fails this test on the bench will fail it at a crash, the one moment the open clip matters. The acceptance paperwork takes both results as numbers: seconds of tail lost at power cut, minutes from reconnect to a cleared queue.

The test belongs at acceptance and after firmware updates, the same cadence the dual-SIM page sets for its switch test. The mechanism lives in firmware and hardware together. A firmware update can move the queueing or the file handling. Ten minutes of bench time per update keeps the fleet’s central promise, the intact recording, a verified fact through the terminal’s life.

The same hour also calibrates expectations for the control room. The technician times the queue clearing on the bench uplink and notes the per-event size. The control room then knows what a post-outage burst looks like in minutes and megabytes, before the first real outage produces one. An expected burst reads as the system working. An unexplained one is a finding for the next check. The bench hour buys the difference.

Before the order

Specify the high-endurance card by rated hours against the route’s worst offline run. Require the holdup line and orderly shutdown in the power section. Confirm queued alarm parcels are pinned against overwrite until sent. Run the antenna-pull test and the power-cut test at acceptance, with the results in the paperwork as numbers, then repeat both after firmware updates. The network can then drop wherever it likes, for as long as the route dictates. The record holds.

Common questions

Does a vehicle keep recording with no signal?

Yes. The recording loop, camera to encoder to card, runs entirely on the vehicle and has no network step in it. A vehicle in a tunnel, an underground garage or open country far from any mast records at full configured quality throughout. The link carries live views, alarm parcels and retrievals. The recording itself never touches the radio. The terminal standard requires this local-first behaviour, so it holds across compliant makers, with the evidence quality set by camera, encoder and card alone.

What happens to an alarm that fires while offline?

The evidence is assembled and stored on the vehicle exactly as normal: the clip is cut from the buffer, the stills are grabbed, the alarm record is written. The parcel then waits in a queue on the card. When the link returns, the queue uploads in order, with any cut-off transfer resuming from its breakpoint. The parcel arrives carrying its original event time. Position reports logged through the gap upload the same way, so the route record on the map completes after reconnection.

Does a long dropout mean footage gets overwritten?

Only against the card’s normal circle. The card overwrites its oldest routine footage when full, on a window set by card size and bitrate. Queued alarm evidence is pinned outside that circle until it uploads. A fleet working long coverage holes sizes the card’s days against its worst offline run, the same storage arithmetic the consumption pages price. The sizing line reads: longest offline-plus-unvisited run, times the configured recording rate, with a comfortable step above the product.

How does the record stay in order after delayed uploads?

Every frame and alarm is stamped at capture with the event time, from a clock disciplined to satellite time whenever a fix exists, the same source every vehicle in the fleet shares. The platform files arrivals by event time, so a parcel uploaded at midnight files under the afternoon it happened. Upload delay shows as metadata. The evidential order is the order things occurred.

What failures can still lose recording?

Two, both physical. A storage card past its endurance life slows and errors, which is why the card is specified by rated hours and replaced on schedule. A power loss in the instant of writing risks the open clip’s tail, which is why a terminal built for the duty carries a supercapacitor holdup to finish the write and close the file. Network failures are not on the list. The card defence is a service-schedule routine. The power defence is a specification line bought once and tested at acceptance.

How can a fleet verify all this before relying on it?

On a bench in an hour. Kill the link by disconnecting the antenna, fire a test alarm, record through the gap, reconnect and watch the queued parcel arrive under its original event time, then play the gap’s clips straight from the card. Cut the power mid-recording and confirm the last clip plays and the card mounts clean. Both results go into acceptance as numbers and repeat after firmware updates, because the queueing and file handling live in firmware and can move with it.

Footer Component - HOPE CCTV
滚动至顶部