We have an ambulance company requesting the following; a director needs TAIP messages to incorporate tracking into the Computer Aided dispatch. How would one go about doing that?
Edited by EishiFUN
We have an ambulance company requesting the following; a director needs TAIP messages to incorporate tracking into the Computer Aided dispatch. How would one go about doing that?
You need to be logged in to reply to this post and participate in the Geotab Community discussions.
Great question. This comes up a lot with EMS/ambulance fleets whose Computer-Aided Dispatch (CAD) systems expect AVL data in TAIP (Trimble ASCII Interface Protocol).
The key thing to understand up front: Geotab GO devices do not natively output TAIP. The GO device talks to the Geotab cloud in Geotab's own protocol, so there is no TAIP stream coming off the device or directly out of MyGeotab. This is a middleware and translation integration, not a device setting.
The proven pattern is to pull positions from the Geotab cloud, translate them to TAIP in a piece of middleware, and deliver them to the CAD.
How to build it:
1. Pull positions with the Data Feed API. Use the GetFeed method against LogRecord (latitude, longitude, speed) and, if you need engine or status data, StatusData. Each call returns a FeedResult with a version token you resubmit on the next call so you only get new records. This gives you near real-time GPS, typically polled every few seconds. SDK sample here: https://geotab.github.io/sdk/software/js-samples/#data-feed
2. Translate to TAIP in your middleware. For each Geotab device, map it to a TAIP vehicle ID and emit TAIP PV (Position/Velocity) messages, for example >RPV...;ID=nnnn;*CC<, at the cadence and over the transport your CAD expects.
3. Deliver to the CAD over whatever transport it requires, such as a TCP server it connects to, or UDP.
The real work is on the CAD side, not Geotab. "Accepts TAIP" is never the full spec. Before building, get these details from your CAD vendor, because they drive the whole design:
- Which CAD product or vendor (CentralSquare/Superion, Tyler/New World, Hexagon/Intergraph, ESO, ZOLL RescueNet, and so on)
- Transport and direction, meaning TCP vs UDP, who initiates the connection, and which port
- The exact TAIP message set, whether PV only or also ID, status, and emergency indicators
- Update frequency, since EMS often wants sub-5-second updates
- Vehicle ID mapping, meaning how a Geotab device maps to the TAIP ID scheme the CAD uses
One more tip: Confirm TAIP is actually mandatory. Many modern CAD systems also accept a simpler REST/JSON AVL feed. If yours does, you can skip TAIP entirely and save significant effort by pushing positions from the Data Feed straight into the CAD's REST endpoint.
How many units? We can build that in real-time. Is the CAD in the cloud or on Prem?
@mhead-1468 Not sure, I will have to ask the customer.
You have to ingest real-time gps data feed, convert to TAIP message then push to CAD system.
Great question. This comes up a lot with EMS/ambulance fleets whose Computer-Aided Dispatch (CAD) systems expect AVL data in TAIP (Trimble ASCII Interface Protocol).
The key thing to understand up front: Geotab GO devices do not natively output TAIP. The GO device talks to the Geotab cloud in Geotab's own protocol, so there is no TAIP stream coming off the device or directly out of MyGeotab. This is a middleware and translation integration, not a device setting.
The proven pattern is to pull positions from the Geotab cloud, translate them to TAIP in a piece of middleware, and deliver them to the CAD.
How to build it:
1. Pull positions with the Data Feed API. Use the GetFeed method against LogRecord (latitude, longitude, speed) and, if you need engine or status data, StatusData. Each call returns a FeedResult with a version token you resubmit on the next call so you only get new records. This gives you near real-time GPS, typically polled every few seconds. SDK sample here: https://geotab.github.io/sdk/software/js-samples/#data-feed
2. Translate to TAIP in your middleware. For each Geotab device, map it to a TAIP vehicle ID and emit TAIP PV (Position/Velocity) messages, for example >RPV...;ID=nnnn;*CC<, at the cadence and over the transport your CAD expects.
3. Deliver to the CAD over whatever transport it requires, such as a TCP server it connects to, or UDP.
The real work is on the CAD side, not Geotab. "Accepts TAIP" is never the full spec. Before building, get these details from your CAD vendor, because they drive the whole design:
- Which CAD product or vendor (CentralSquare/Superion, Tyler/New World, Hexagon/Intergraph, ESO, ZOLL RescueNet, and so on)
- Transport and direction, meaning TCP vs UDP, who initiates the connection, and which port
- The exact TAIP message set, whether PV only or also ID, status, and emergency indicators
- Update frequency, since EMS often wants sub-5-second updates
- Vehicle ID mapping, meaning how a Geotab device maps to the TAIP ID scheme the CAD uses
One more tip: Confirm TAIP is actually mandatory. Many modern CAD systems also accept a simpler REST/JSON AVL feed. If yours does, you can skip TAIP entirely and save significant effort by pushing positions from the Data Feed straight into the CAD's REST endpoint.
@MVS Thank you for all of this information. I appreciate it.
hi
Geotab devices don't natively send TAIP messages. To integrate them into a computer-aided dispatch (CAD) system, you need to use middleware: 1. Pull the positions from the Geotab cloud using the Data Feed API (the 'GetFeed' method for 'LogRecord'). 2. Convert that data to the TAIP format in your middleware. 3. Send the converted messages to the CAD system.