Our IoT tracking devices operate from a permanent external voltage source, typically by connection to the vehicle fuse box or battery, therefore the devices are always working. Our devices all bhave an internal backup battery, which allows the device to report power disconnect / fault events and continue to operate for a few hours or days after losing power (depending on the device model and opertaing mode).

Vehicles can typically be left stationary for up to 2 weeks without any battery problems. For motorcycles and vehicles which may be parked for longer periods, we recommend the use of low-power, which allows the device to operate from its internal battery for several weeks, before starting to consume any power from the vehicle battery, ultimately allowing vehicles to be left for up to 1 month without any trouble. Please refer to our Low Power Mode Application Note for more details.

All of our devices have non-volatile storage for 1000s of reports, to ensure that no data is lost during communications outages. All reports are stored until they are successfully sent to the host server and the device receives an acknowledgment. In a typical application, the storage allows at least 7 days of storage until the oldest data starts to be overwritten (FIFO style).

We offer numerous devices with ingress protection (IP) ratings from IP65 to IP68.

IP67, is a standrd notation used to specifc a level of Ingress Protection. The digits after the "IP" refer to the level of protection offered by any product against solids and liquids. The first digit refers to the protection against solids and ranges from 1-6, where 1 is not protected from solids and 6 is completely protected against dust ingress. The second digit refers to the protection against liquid and ranges from 1-9, where 1 is not protected from any liquids, and 9 is protected from high-pressure, high-temperature cleaning.

We offer IoT tracking devices that range from IP65 to IP68.

Our reports are extremely data-rich, providing over 200 data fields, with a capability to read data from numerous external devices over RS232, 1-wire, BLE or CANBus. These options include gritters, road-sweepers, refrigerators, weighing equipment, temperature sensors, card readers, trucks, vans, cars, kick-scooters and electric vehicles, to name just a few. Please request a copy of our Modular Communication Protocol X documentation to see full details of data content and supported vehicles, devices and accessories. What if our device or data content is not supported? Please share details of your requirements and in most cases, we are happy to integrate new vehicles and devices free-of-charge.

CANBus is the generic name given to the communication networks used in vehicles to interconnect the ECU with sensors, actuators, controls and the dashboard display, amongst other things. The CANBus network typically contains some data that is of interest to fleet managers, such as fuel consumption. Unfortunately, the data is formatted by each vehicle manufacturer using proprietary, non-standard protocols. Furthermore, the manufacturers do not often share those protocols, making it very difficult for us to access the data we are interested in. Fortunately, there are some standards in the industry that can help us, namely OBD (J1979) and FMS (J1939).

OBD (On-Board Diagnostics) defines a standard format to access vehicle diagnostic data for cars and light commercial vehicles (vans). For the past 20 years or so, it has been mandatory for vehicle manufacturers to provide an OBD port which conforms to the J1979 standard. The standard defines the connector type and pinout, along with a set of diagnostic commands which can be used to query the vehicle data. Unfortunately, the standard does not include fuel consumption data. Fuel level data is included, but it is optional and many manufacturers choose not to provide it. Astra Telematics devices support the OBD standard (CANBus compatible devices, such as the AT400, AT201, AT240 and AT110) and where fuel level is available, our devices estimate fuel consumption based on fuel level and journey distance. Note that this data is estimated and will differ from the fuel consumption figure displayed on the vehicle dashboard display. Also note that OBD requires read/write access to the CANBus and therefore contactless CAN adapters, such as our CC002 cannot be used, as they allow read-only access.

FMS (Fleet Management System) is a standard protocol supported by a group of HGV manufacturers to provide useful vehicle data for 3rd party devices in a safe way, without risk of interfering with the vehicle’s systems. The data format is standardised across all supporting manufacturers and the standard is openly available, so that companies such as Astra Telematics can read and use the data. Furthermore, the FMS standard includes fuel consumption data, along with a wealth of other stuff that is potentially useful for fleet managers. FMS is not universally available on all vehicles manufactured, even by those that are involved in the standard. FMS is often a manufacturer option, although recently it appears to be available on the majority of new HGVs supplied.

Vehicles without FMS will require the use of a 3rd party gateway device to convert the manufacturer proprietary vehicle data to FMS standard, so that it can be read by our devices. We offer a range of FMS gateway devices which are compatible with a wide range of vehicle. Please contact us for details, prices and a list of supported vehicles.

Contactless CANBus adapters, such as our CC002, are used to read data from the vehicle CANBus without a direct electrical contact. The contactless adapter simply clips over the insulated CANBus wires, avoiding potential issues with interference or warranty liabilities etc. Note that contactless CANBus adapters allow read-only functions and therefore cannot be used for OBD applications, which require read/write access to the CANBus.

All our devices support a simple method to update firmware "over-the-air", commonly referred to as FOTA. All that is required is to send a command, instructing the device to download our latest release and the device takes car of the entire process. As with all other commands, the FOTA command can be sent to the device by SMS, RS232, BLE or TCP. The process is safe, reliable and fast, usually complete in less than 3 minutes. We provide free firmware updates with all our devices.

Installation is different for each device, vehicle, client and application. Our Installation Guide documents cover the recommended tools, consumables, procedures and final checks / commissioning. We recommend that our clients provide their installers with a copy of our Installation Guide, even if they have years of experience, using the correct tools and following the correct procedures can often avoid a second visit to address installation issues. Please see the relevent product page or use the links below: AT200 Low-Cost Tracker Installation Guide AT240 Advanced Vehicle Tracker (IP67) Installation Guide AT110 Advanced Vehicle Tracker Installation Guide AT210 Plant & Machinery Tracker Installation Guide.

Yes, this is usually no problem, due to the tiny dimensions of our devices.

BLE 4.2

BLE (Bluetooth Low Energy) is used to send commands to the IoT device via a mobile phone, typically for custom client applications, such as moto-sharing or connected-vehicles.

Our AT400, AT401, AT240 and AT500 are available with BLE, either as a standard feature or an optional extra.

All of our devices support driver ID using iButtons (Dallas Keys) or RFID/NFC ID cards.

This often depends on whether your client (end-user) already has RFID cards in use, in which case, they will undoubtedly prefer to use their existing cards and RFID will be a good choice. If not, then the iButton option will probably be the way to go, since they are inexpensive, robust and reliable. If you require more advice please contact one of our team, we will help you decide which option is most suitable for you.

Yes, this is a popular option for 2 reasons. The first is simply to ensure that the drivers always present their ID for every journey. In this case, the vehicle will not start until ANY ID has been read. No checking is done, we simply expect to see an ID before allowing the driver to start the vehicle. The second application is to control which drivers are allowed to use specific vehicles or vehicle types, to enforce driving licence vehicle classes or simply to prevent drivers from using vehicles or equipment which they are not trained to use. In the latter case, the driver ID is verified for each specific driver and vehicle. Both modes are supported by Astra Telematics devices.

GPS (Global Positioning System) is a network of 24 satellites which are used to determine time, location, speed and heading very precisely. Other similar systems, such as GLONASS, GALILEO and BeiDou, can also be used to provide the same data, globally and free of charge. Collectively, these systems are now referred to as GNSS or Global Navigation Satellite Systems. Signals from the GNSS satellites are very weak and therefore will not usually travel through metal or buildings etc. In most circumstances, GNSS devices only work outdoors.

Our devices work anywhere in the world, subject to suitable mobile communication network services (GSM, 3G, LTE CatM1 and NB-IoT).

Obviously this is subject to availability of GNSS and mobile communications network services. GNSS works all over the world, but generally does not work indoors or in covered areas, such as tunnels. With that caveat, we typically expect a location accuracy of approx. 2m anywhere in the world, when outdoors. Almost certainly you have a mobile phone and you understand the coverage aspects of mobile network communications quite well. In cities and on major routes, coverage is almost guaranteed these days, but of course thera are always exceptions. With these caveats understood, we can safely say that our devices will send accurate location to your server / platform in real-time, typically less than 1 second, whenever services are available.