AmbiOBU — the C-V2X On-Board Unit (OBU) development kit, and the moving node.
AmbiOBU is a Cellular Vehicle-to-Everything (C-V2X) On-Board Unit (OBU) development kit — vehicle-side V2X hardware for vehicle manufacturer (OEM), tier-1 and research integration work, from Ambimat Electronics, an embedded design and manufacturing house in Ahmedabad, India. It is a mature, production-ready V2X development platform available to order from Ambimat, built around a direct 5.9 GHz C-V2X PC5 radio at 3GPP Release 14 with a global navigation satellite system (GNSS) receiver, a 9-axis inertial measurement unit, a separate 4G LTE backhaul and the AmbiSEC secure element. It is not certified, homologated or type-approved, and environmental qualification of the standard configuration is not claimed unless explicitly stated.
An on-board unit is the equipment fitted in the vehicle — the moving participant in any Vehicle-to-Everything scenario, the thing that broadcasts where this car is and what it is doing, and that listens for everyone else. For development and demonstration the kit can be run in a 1:10-scale movable test vehicle, so the moving node genuinely moves instead of being simulated on a bench. It is supplied for algorithm development, integration, testing and demonstration, with no programme partner required first, and manufacturable in quantity. Production ready describes that maturity and orderability rather than environmental qualification; homologation for a production vehicle is specific to the final integrated product. Choose a development setup →
With a second On-Board Unit it does Vehicle-to-Vehicle (V2V) communication — car to car. With the Roadside Unit development kit it does Vehicle-to-Infrastructure (V2I) communication — car to roadside. Both use the same radio and the same trust model.
It pairs with the RSU development kit, the stationary roadside node. Between them you have both sides of a real V2X exchange: two participants, signed messages, and a receiver that has to decide whether to trust what it just heard.
AmbiOBU is available to order from Ambimat.
AmbiOBU is a mature, production-ready V2X development platform available to order from Ambimat. It is supplied for algorithm development, integration, testing, research and demonstration — a complete on-board-unit development endpoint, not a bare radio evaluation board. No programme partner and no custom-engineering commission is required first. Environmental qualification of the standard configuration for extreme temperature, high humidity, ingress, vibration, shock, vehicle-specific installation or outdoor roadside installation is not claimed unless explicitly stated; homologation and certification for installation in a production vehicle remain specific to the final integrated product and its target programme. Choose a development setup →
Download the AmbiOBU datasheet (PDF, 4 pages) — the development configuration, interfaces, security status and qualification boundary in one document.
AmbiLogistics is not a prototype.
It is Ambimat's existing, field-deployed vehicle tracking platform: GPS-capable, IMU-equipped, cellular-connected, and validated on Indian roads in Indian conditions. AmbiOBU evolves that hardware by adding V2X sensing and integrating the AmbiSEC secure element for PKI-signed V2X message broadcasting.
AmbiLogistics is not a claim made only on this site. It is a shipping Ambimat product with its specification published on the parent company's own site, where the receiver, sensitivity, accuracy, environmental range and anti-spoofing behaviour are all stated: ambimat.com/solutions/ambilogistics. The figures in the table below are taken from there.
That heritage matters for a specific reason, and so does its limit: the standard AmbiOBU is qualified for none of the five items in this paragraph. The hard parts of an Indian on-board unit are not the V2X modem, which is a purchasable part. They are thermal behaviour in a 48 °C ambient, vibration on Indian road surfaces, GNSS performance under dense urban multipath, cellular behaviour on Indian networks, and manufacturing at a cost point that works on a two-wheeler — and the standard AmbiOBU is qualified for none of them. Ambimat has shipped hardware against all five on AmbiLogistics rather than on AmbiOBU, in that enclosure, and a qualified envelope for a named AmbiOBU deployment is separately scoped engineering work rather than something the lineage already carries.
The AmbiLogistics-derived baseline, as configured for V2X development.
The AIS-230-aligned specification supersedes the table below and is pending. Read this as the hardware lineage rather than as a published product specification. Rows describe the platform as configured for V2X development; they are not separately published figures, and none of them is a validated rating. No environmental figure is carried over from another Ambimat product. The one row still quoted from the AmbiLogistics specification is marked as AmbiLogistics', and it is that product's figure, not AmbiOBU's. The GNSS rows describe the receiver in the V2X development configuration, which is the u-blox MAX-M10S. The AmbiLogistics tracking platform publishes a u-blox M8-based receiver, and that lineage figure is not carried over here.
| Component | Specification | Source |
|---|---|---|
| GNSS receiver | u-blox MAX-M10S — a u-blox M10 standard-precision GNSS module, professional grade, with concurrent reception of four constellations: GPS/QZSS L1C/A, Galileo E1-B/C, GLONASS L1OF and BeiDou B1I/B1C, all in the L1 band. What that gives a V2X development node → | Development configuration |
| Positioning accuracy | u-blox specifies typical 1.5 m CEP in its multi-constellation modes under its own stated test conditions — CEP 50%, 24 hours static, −130 dBm, more than six satellites per system. Tracking and navigation sensitivity −167 dBm, cold start −148 dBm. A typical figure measured under those conditions is not a guaranteed field result. | Development configuration |
| GNSS integrity | MAX-M10S module security features: RF interference and jamming detection and reporting, spoofing detection and reporting, configuration lockdown, cryptographically signed receiver messages, and secure boot of signed firmware images. These protect the positioning layer; V2X message authentication is a separate layer. GNSS spoofing as a V2X attack class → | Development configuration |
| Geofencing | Up to four circular areas, with safe-zone exit notification | Published — AmbiLogistics |
| Operating temperature | No validated operating range has been published for AmbiOBU, and no extreme-temperature or high-humidity qualification is claimed for the standard configuration. Establishing and validating a temperature range for a named application is separately scoped engineering work | Not published |
| Enclosure | No ingress rating is published for AmbiOBU, and none is claimed. Sealing and ingress qualification for a named installation is separately scoped engineering work | Not published |
| Compute | NVIDIA Jetson Orin Nano Super, 8 GB LPDDR5 — the same compute platform and memory configuration as AmbiRSU, so both endpoints run one development environment. NVIDIA specifies the module as NVIDIA Ampere architecture with 1024 CUDA cores and 32 third-generation Tensor cores, a 6-core Arm Cortex-A78AE CPU, 8 GB of 128-bit LPDDR5 at 102 GB/s, and up to 67 sparse INT8 TOPS. Those are NVIDIA's compute-platform specifications, not measured AmbiV2X application performance. The common platform → | Development configuration |
| IMU | 9-axis — accelerometer, gyroscope, magnetometer; motion, orientation, hard-event logging | Development configuration |
| Environmental sensing | Ambient temperature, relative humidity, barometric pressure | Development configuration |
| Direct V2X radio | 5.9 GHz C-V2X PC5 subsystem, 3GPP Release 14, including C-V2X power-saving modes. PC5 is the direct communication path between nearby V2X participants — vehicle to vehicle and vehicle to roadside — and the local exchange does not go through a mobile network or require a subscription. This is the only radio direction Ambimat develops and supplies for V2X. What Release 14 and PC5 are → | Development configuration |
| Cellular | SIMCom A7672-series 4G LTE Cat 1 module for backhaul, telemetry, remote diagnostics, backend and IP services and experiment data upload; cellular plus GNSS dual-mode positioning for redundancy. This cellular connection is separate from the direct C-V2X radio and does not provide PC5. | Development configuration |
| V2X security | AmbiSEC — Ambimat's hardware-protected security subsystem. It provides device-bound identity, protected key storage and protected cryptographic operations for the platform. The V2X message-security implementation that uses them — IEEE 1609.2 and ETSI TS 103 097 signing and verification, and the credential lifecycle around it — is being developed. What is implemented and what is being developed → | Development configuration · message-security implementation in development |
| Software environment | Ubuntu 22.04 LTS with ROS 2 Humble Hawksbill; C++ and Python development against documented interface packages, with SAE J2735 message development and IEEE 1609.x integration below the application layer. The AmbiV2X Developer Stack → | Development configuration |
| Power | USB-C charging, off-the-shelf battery pack, LED multi-function indicator | Development configuration |
What the development kit interfaces with, and what it does not. The kit is a self-contained node. Its inputs are its own sensors — GNSS, the inertial measurement unit and the environmental sensors — and its outputs are the signed messages it broadcasts over the radio, plus its cellular uplink. Everything it says about itself, it derives from itself.
It does not carry a vehicle data bus interface. There is no CAN or CAN-FD connection, and none is implied by the term “on-board unit”. It does not carry lidar, radar or camera hardware either — V2X is a communication technology and an information source alongside those sensors, not a replacement for them. Why that distinction matters →
That is a deliberate scope for a development kit, and it is also the honest boundary: a production on-board unit that must read wheel speed, brake state or gear position from the vehicle needs a bus interface, and adding one is programme-specific engineering rather than something the kit already does. Where a vehicle programme supplies that data from another subsystem, the same applies — the integration is designed, not inherited. Where that work sits →
Two of those published rows matter more for V2X than they do for tracking. GAGAN and NavIC place the positioning work on Indian augmentation and constellation infrastructure rather than on GPS alone — Ambimat's published milestone record notes vehicle-tracking units built on NavIC receivers in 2018 and again in 2020. And spoofing detection is a V2X security property before it is a tracking feature: a C-V2X unit derives both its position claim and its PC5 timing reference from GNSS, so a receiver that can be walked off its fix can be walked off the air. GNSS spoofing as a V2X attack class → How V2X depends on GNSS position and time →
The 48 °C ambient discussed above is a reason the lineage matters, and it is not a claim about this kit. AmbiLogistics' published operating range is AmbiLogistics'. It was measured on that product, in that enclosure, and it is not carried over here: no operating-temperature range and no ingress rating is published for AmbiOBU, and neither is claimed for the standard configuration. Establishing an envelope for a specific vehicle category — and validating it — is separately scoped engineering work, not something the lineage already carries.
Multi-constellation positioning with u-blox M10.
AmbiOBU uses the u-blox MAX-M10S, a multi-constellation M10 standard-precision GNSS receiver supporting GPS, Galileo, GLONASS and BeiDou. It combines high satellite availability, configurable navigation rates, Super-S operation and assisted-GNSS and augmentation capability for position-aware V2X development.
Why a V2X development node cares about the receiver. Almost every message an on-board unit sends is a claim about where it is and what it is doing, and in C-V2X the sidelink also takes its timing reference from satellite time. Position availability — getting a fix at all, and keeping it — therefore decides how much of an experiment is usable, not merely how precise the coordinates are.
Four constellations, concurrently. The M10 platform receives GPS, GLONASS, Galileo and BeiDou at the same time. More visible satellites means the receiver can select the best signals, which is what keeps a fix alive in the deep urban canyons, tree cover and multipath that a campus or a city trial actually runs in. u-blox supports GPS/QZSS L1C/A, Galileo E1-B/C, GLONASS L1OF and BeiDou B1I and B1C — all L1-band signals, on a single-band receiver.
Standard precision, stated as such. u-blox specifies typical 1.5 m CEP for the MAX-M10S in its multi-constellation modes, measured under its own stated conditions: CEP 50%, 24 hours static, −130 dBm, more than six satellites per system. That is a standard-precision positioning tier and this page describes it as one. It is not a lane-level or centimetre-level solution, and a typical bench figure is not a guarantee of what any particular vehicle will see on any particular road.
Configurable navigation rate. The rate depends on which constellations are enabled, and the trade-off is a real experimental variable rather than a fixed number. In the default GPS, Galileo and BeiDou B1I configuration u-blox specifies 3 Hz; a high-performance configuration reaches up to 20 Hz in a GPS-and-Galileo combination, and single-GNSS configurations go higher still. A team studying how update rate interacts with message generation can move that dial deliberately.
Motion, not just position. u-blox specifies 0.05 m/s velocity accuracy and 0.3° dynamic heading accuracy, both at 50% and 30 m/s in dynamic operation. That heading is derived from the receiver's own motion over ground; it is a single-antenna solution and not dual-antenna GNSS heading. Operational limits are up to 4 g dynamics, 500 m/s velocity and 80,000 m altitude.
Weak-signal and small-antenna behaviour. u-blox Super-S technology is described by u-blox as offering greater RF sensitivity, able to improve dynamic position accuracy with small antennas or in non-line-of-sight scenarios — which is the condition a compact development node on a small platform is usually operating in. It improves how a standard-precision receiver behaves; it does not change its precision tier.
Assistance and augmentation. The module supports AssistNow assisted-GNSS services — Live Orbits, Predictive Orbits and Autonomous — which shorten time to first fix. It also supports SBAS augmentation covering GAGAN, India's own augmentation system, alongside EGNOS, WAAS, MSAS, KASS and SouthPAN, plus QZSS L1S (SLAS). SBAS and QZSS augmentation require GPS operation to be enabled. These are module capabilities; which of them a programme actually enables, and whether an augmentation service is receivable at a given site, is a configuration and deployment question rather than a property of the hardware.
Power behaviour. The receiver offers continuous mode, power-save modes covering cyclic tracking and on/off operation, and hardware and software backup modes, at 25 mW in continuous tracking. These are GNSS power modes and are unrelated to the C-V2X radio's power-saving modes described in the specification above — two separate subsystems, two separate power stories.
MAX-M10S, M10, Super-S and AssistNow are u-blox products and technologies, not Ambimat developments. The figures above are u-blox specifications under u-blox test conditions; see the MAX-M10S data sheet (UBX-20035208).
Two measurement sources, one application layer.
These are two independent measurement sources feeding one application layer, and the page draws them that way deliberately. The GNSS receiver produces position, velocity, heading and time. The 9-axis IMU produces acceleration, rotation and orientation. Both arrive in the ROS 2 environment as separate streams that a research application can use, log, replay and compare.
What the baseline does not include is a dead-reckoning navigation solution. Having a GNSS receiver and an inertial measurement unit in the same enclosure is not the same thing as an implemented and validated GNSS/INS fusion engine, and this page does not claim one. u-blox lists an odometer firmware feature on the MAX-M10S, which measures travelled distance — that is a distance accumulator, not dead reckoning either.
Building a state estimator that fuses the two streams is exactly the kind of work the ROS 2 development environment exists to support, and it is a realistic research project on this platform. It is a piece of engineering a programme would scope and carry out, not a capability the kit ships with. Where that work would sit →
The Uu side needs a cellular identity that outlives the SIM slot nobody built.
A production on-board unit for this market will in practice be dual-mode — PC5 for direct safety messaging, Uu for network-assisted features — whatever Draft AIS-230, whose text is not public, turns out to require. The Uu path is what carries certificate batches, trust-list updates and firmware — which means the unit needs a cellular identity that survives a fifteen-year service life and possibly several markets, in a sealed enclosure. In practice that is an embedded SIM provisioned remotely, not a card. Ambimat's eSIM and eUICC work sits on a sister property and is part of the same conversation. Why the Uu side needs a subscription →
What the platform is being designed against.
- C-V2X on 5.9 GHz — aligned to the TRAI spectrum proposal and the G.S.R. 466(E) licence exemption for 5875–5905 MHz. The band →
- PKI-signed message broadcasting — aligned to the TRAI cybersecurity direction and the AIS-230 security requirements. The draft mandate →
- Hardware-backed key storage via AmbiSEC — the property MTCTE cybersecurity testing should treat as pass/fail. Why →
- Secure OTA over cellular via AmbiOTA.
These are design and compliance references. They are not assertions that the platform carries any formal certificate.
What AmbiSEC secures, and what it does not.
Stated layer by layer with a status attached to each, because a protected key and a working credential lifecycle are different achievements and the difference is the whole point of a security page.
AmbiSEC provides the hardware-protected security foundation for AmbiOBU and AmbiRSU, including device-bound identity, protected key storage and the cryptographic operations the V2X message-security implementation uses. It is Ambimat's own security subsystem, engineered by the AmbiSecure business unit, and it is the only security component this site names.
What that sentence does not say. AmbiSEC is not the PC5 modem and it is not the radio. Its presence is not evidence that AmbiOBU is certified, that national PKI integration is complete, that Ambimat participates in an operational Root CA, SCMS or CCMS, or that production credential provisioning and certificate-lifecycle management are finished. It protects keys, identity and cryptographic operations; it does not stop a hostile transmitter from transmitting, and no security component can.
| Layer | What it is | Status |
|---|---|---|
| AmbiSEC hardware protection | A tamper-resistant security boundary across which long-term secrets are never exposed to application firmware, with the host application domain on the other side of it | Implemented — AmbiSEC is in production |
| Device-bound identity | A unique identity key held inside the secure boundary and non-extractable by hardware design, so identity operations are anchored to the individual endpoint rather than to ordinary application storage | Implemented |
| Protected key storage and cryptographic operations | On-chip key generation, private keys with no exit path in any lifecycle state, and signing, verification, encryption and decryption performed inside the boundary — the host sends a hash and receives a signature | Implemented |
| Secure boot and authenticated update | Boot sequence cryptographically verified before the unit becomes operational; firmware authenticated before installation | Implemented |
| V2X message signing and verification | IEEE 1609.2 secured-message encoding, signature generation over what the platform broadcasts, and verification of what it receives | Being developed — the cryptographic primitives exist; the standards-level message path around them does not yet |
| Certificate and credential lifecycle | Enrolment credential handling, pseudonymous certificate batches, rotation policy and revocation handling | Being developed; the profile and the provisioning route are programme-specific |
| Programme or national PKI infrastructure | Enrolment and Authorisation Authorities, root and trust-list distribution, and the audited Certification Practice Statement behind them | External to Ambimat. A designated authority operates it. Supplying the security subsystem does not make a supplier the Root CA. How the credential chain works → |
| National or programme trust-anchor operation | An operational RCAI, SCMS or CCMS that a market's vehicles actually chain to | Not claimed. No participation, listing, approval or endorsement is asserted or implied |
Keeping those rows apart is not pedantry. A programme that reads “secure element” and hears “certified V2X security” will budget for the wrong thing, and will discover the gap at conformance testing rather than at architecture. Certification, when it comes, attaches to a completed integrated product and its target programme — never to a component, and never by inheritance. What AmbiSEC is, at the module level → · The threat model underneath all of it →
An orderable development platform, and a homologated vehicle unit, are two different things.
AmbiOBU is a mature, production-ready V2X development platform available to order from Ambimat, and the design is manufacturable in quantity. It is supplied for algorithm development, integration, testing, research and demonstration. Contact Ambimat for configuration, lead time and pricing; nothing on this site publishes a price, a stock position or a delivery commitment, because none is fixed in advance of an enquiry.
Production ready is a statement about maturity, manufacturability and orderability — not about environmental qualification. Environmental qualification of the standard configuration for extreme temperature, high humidity, ingress, vibration, shock, vehicle-specific installation or outdoor roadside installation is not claimed unless explicitly stated, and no operating-temperature range or ingress rating is published for it. Where a deployment needs one, that is an IDH engagement → Homologation and certification for installation in a production vehicle remain specific to the final integrated product and its target programme: the platform is not in production deployment, not certified, not homologated and not type-approved, and it is not an AIS-230-compliant product. AIS-230 approves vehicles, so no development platform can be compliant with it — that is a category distinction, not a certification gap. ISO 26262 and Automotive SPICE conformity for an integrated unit are targets, not claims.
What comes with the platform: 44 years of embedded hardware design and manufacture carried by one organisation across the design-to-manufacture boundary; a vehicle platform already validated on Indian roads and specified publicly; the AmbiSEC security layer with device-bound identity; secure boot and OTA; and certification-support experience across FCC, CE and Indian conformity regimes — the FCC part of which is a dated, published outcome from 2014 rather than a general capability statement.
Where a programme wants more than the standard platform — a vehicle-bus interface, a different enclosure or power input, a defined operating-temperature or ingress requirement, a sensor payload, or a production build — AmbiOBU can be the engineering baseline for a customer-specific production on-board unit. That is optional Ambimat custom engineering, taken up after you have the platform, and it is not a condition of buying one. Two- and three-wheeler programmes are of particular interest, because that is where the Indian draft mandate bites hardest and where almost nobody is building.
Need a deployment-specific production design?
The standard AmbiOBU and AmbiRSU are production-ready development platforms, available to order exactly as they are, and manufacturable in quantity. Where a programme instead needs automotive, roadside, outdoor or other environment-specific qualification, Ambimat Technologies Pvt Ltd can act as your IDH — independent design house — partner, and adapt or develop the V2X hardware around that programme's electrical, mechanical, RF, environmental, security and integration requirements.
Requirements are captured first. The qualification scope, and the evidence that closes it, are agreed and validated as part of that programme rather than assumed from the standard configuration or promised in advance. It is a separately scoped engineering engagement, and it is not a prerequisite for buying anything — the standard platforms can be ordered directly, with no IDH engagement, no programme partnership and no custom-engineering commission first.
Where this fits.
AmbiSEC
The secure element inside it, and the applet that manages its credentials.
India regulation
AIS-230, the October 2028 date, and the six open questions.
V2V
The four safety applications AIS-230 specifies first.
Hardware root of trust
The verification-throughput question every OBU proposal should answer.
AmbiV2X Developer Stack
The ROS 2 V2X development environment this unit runs, and what a programme actually receives with it.
AmbiRSU
The roadside counterpart — the same compute, GNSS, LTE, C-V2X and ROS 2 foundation, as a static endpoint.
eSIM and eUICC
The cellular identity the Uu path depends on.
A moving node that actually moves.
An on-board unit is the moving participant, and a good deal of V2X behaviour only shows up when it is genuinely in motion — relative velocity in the message payload, GNSS behaviour under real dynamics, link quality as the geometry changes, and every trust decision the receiver has to take at speed.
For development and demonstration the OBU kit can therefore be run in a 1:10-scale movable test vehicle: a mobile development platform rather than a production automobile, small enough to drive around a test area or a demonstration floor and large enough to carry the unit, its antenna and its power. It is a development and test representation, not a qualified vehicle installation. Paired with the RSU development kit on its antenna mast, it gives both participants of a real V2X exchange in a space you can walk across.
The antenna is part of that: a unit that moves has to hear messages arriving from any direction, which is an antenna and RF problem before it is a software one. It is a development and test representation, not a vehicle product. AmbiOBU itself is a production-ready development platform, available to order: mature in that role, but not certified, not homologated and not type-approved as a vehicle unit, and not qualified for a specific vehicle installation. What it demonstrates is the communication, the message handling and the trust decisions — which is what a programme needs to see before committing to a vehicle integration. Choose a development setup →
Have a vehicle programme that needs a V2X on-board unit?
Bring the vehicle category, the target market and the timeline. We will bring the hardware baseline, the security architecture and an honest view of what it takes to get from here to a type-approved unit. That work runs as the V2X hardware design engagement.
Questions this page answers.
What is an On-Board Unit?
The V2X equipment fitted in the vehicle. It knows where the vehicle is and what it is doing — speed, heading, braking — broadcasts that about ten times a second as a signed message, and listens for the same from everything around it. It is the moving participant in any Vehicle-to-Everything scenario.
What is an On-Board Unit development kit?
A complete on-board-unit development endpoint rather than a bare radio evaluation board. AmbiOBU carries a u-blox MAX-M10S multi-constellation GNSS receiver, a 9-axis IMU, a 5.9 GHz C-V2X PC5 subsystem at 3GPP Release 14, a SIMCom A7672-series 4G LTE module for backhaul and the AmbiSEC secure element for hardware-protected keys. The design lineage is AmbiLogistics, Ambimat's field-deployed vehicle-tracking platform. AmbiOBU publishes no operating-temperature range or ingress rating of its own, and no environmental qualification of the standard configuration is claimed.
Can I order the AmbiOBU development platform, and how do I request a quotation?
Yes. AmbiOBU is a mature, production-ready V2X development platform available to order from Ambimat, with no programme partner and no custom-engineering commission required first. Email Ambimat with the setup you want, how many nodes and what you intend to develop; enquiries reach the V2X engineering team directly. Price, lead time and delivery terms are quoted per enquiry and are not published on this site. Choose a development setup.
Does AmbiOBU use direct 5.9 GHz C-V2X PC5, and what is the LTE module for?
Yes, and the two are separate subsystems doing different jobs. The 5.9 GHz C-V2X PC5 subsystem is the direct path between nearby V2X participants — vehicle to vehicle and vehicle to roadside — and that local exchange does not go through a mobile network or need a subscription. The SIMCom A7672-series 4G LTE module is a separate backhaul path for telemetry, remote diagnostics, backend and IP services and experiment data upload. Ordinary 4G LTE does not provide the PC5 radio path, and this platform does not offer DSRC or IEEE 802.11p. PC5 and Uu, side by side.
What secures the V2X messages AmbiOBU sends?
AmbiSEC, Ambimat's hardware-protected security subsystem. It provides device-bound identity, protected key storage and protected cryptographic operations, with long-term secrets never exposed to application firmware — all implemented today in the supplied configuration. The V2X message-security implementation that uses them, meaning the IEEE 1609.2 and ETSI TS 103 097 signing and verification path and the credential lifecycle around it, is being developed. AmbiSEC is not the PC5 modem and not the radio, and its presence is not evidence of certification, of completed PKI integration, or of participation in any operational Root CA, SCMS or CCMS. The layers, kept apart.
Is the platform homologated for installation in a production vehicle?
No, and that boundary is deliberate — it is also a different question from production readiness. The platform is mature, manufacturable and available to order; what is not claimed is qualification. Environmental qualification of the standard configuration for extreme temperature, high humidity, ingress, vibration, shock, vehicle-specific installation or outdoor roadside installation is not claimed unless explicitly stated. Homologation, type approval and certification for installation in a production vehicle remain specific to the final integrated product and its target programme, and they are granted by an authorised body rather than by a supplier. AIS-230 approves vehicles, so no development platform can be compliant with it — that is a category distinction, not a certification gap.
Can Ambimat customise the hardware for temperature, power or enclosure requirements?
Yes, as optional engineering rather than as something the standard platform already carries. Where a programme requires a specific operating-temperature range, ingress rating, vibration profile, power-input condition, enclosure or installation format, Ambimat can provide independent design-house (IDH) engineering — that is, engineering carried out by an independent design house on the customer's behalf — to develop and validate the required configuration. Where that work sits.
Can the On-Board Unit development kit be used on something moving?
Yes, and that is rather the point. For development and demonstration it can be run in a 1:10-scale movable test vehicle — a development and test representation rather than a qualified vehicle installation — so the moving node is genuinely in motion. A good deal of V2X behaviour only appears under real dynamics — relative velocity in the message payload, GNSS behaviour while moving, link geometry changing, and trust decisions taken at speed.
How does it do Vehicle-to-Vehicle communication?
Put a second On-Board Unit in another vehicle. Each broadcasts its own state and verifies the other's signature before acting on what it hears. That car-to-car exchange is Vehicle-to-Vehicle (V2V) communication. How V2V works.
How does it do Vehicle-to-Infrastructure communication?
Pair it with a roadside node. The Roadside Unit development kit signs infrastructure messages — signal timing, a work zone, a hazard — and the On-Board Unit verifies the signature before acting on them. That is Vehicle-to-Infrastructure (V2I) communication. How V2I works.
Which GNSS receiver does AmbiOBU use?
A u-blox MAX-M10S — a u-blox M10 standard-precision GNSS module, professional grade, with concurrent reception of four constellations: GPS/QZSS, Galileo, GLONASS and BeiDou, on their L1-band signals. u-blox specifies typical 1.5 m CEP position accuracy in multi-constellation modes under its own stated test conditions, 0.05 m/s velocity accuracy and 0.3° dynamic heading accuracy, with configurable navigation rates, Super-S sensitivity technology, AssistNow assisted GNSS, and SBAS augmentation including GAGAN. The positioning section.
Does AmbiOBU support RTK?
No. The current MAX-M10S development configuration is a standard-precision GNSS implementation and is not presented as a real-time kinematic receiver. u-blox documents no RTK, carrier-phase or centimetre-level capability for this module. Higher-precision positioning can be evaluated as a programme-specific option where a research scope genuinely needs lane-level or reference-grade accuracy.
Does AmbiOBU provide dead reckoning?
No. The standard configuration includes a GNSS receiver and a 9-axis IMU, but an implemented dead-reckoning navigation solution is not part of the published baseline. Having both sensors is not the same as having a validated GNSS and inertial fusion engine. u-blox lists an odometer feature on the MAX-M10S, which measures travelled distance rather than providing dead reckoning. Building a state estimator that fuses the two streams is a realistic research project on the ROS 2 environment, and would be scoped as engineering work rather than assumed.
Can Ambimat develop a production unit after the prototype?
Yes, and it is optional rather than assumed. The development platform is the engineering baseline; the development service takes a programme from architecture through prototype and design for manufacture to production, including the provisioning line and submission support for FCC, CE and MTCTE. Type approval remains with the authorised body. You do not have to commission any of it to order a platform.
Last updated 2026-10-01 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: v2x@ambimat.com