Our IoT tracking devices operate from a permanent external voltage source, typically by connection to the vehicle fuse box or battery. All our devices have 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 operating mode).

Vehicles can typically be left stationary for up to 2 weeks without any battery drain problems (continuous operation mode). For motorcycles and vehicles which may be parked for longer periods, we recommend the use of low-power mode, 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, this 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 standard notation used to specify 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 vehicles. 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 care 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. Installation Guides and lots of other useful documents can be found on our downloads page.

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, AT241 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 (GPRS/2G, 3G, LTE CatM1 and NB-IoT). As at the time of writing (2021), GPRS/2G and 3G services are still widely available and are the primary services used for IoT applications, by millions of devices, all over the world. Some countries have already switched-off GPRS/2G services, but network operators in most of the world still offer services. There is no exact timetable for the 'sunset' of 2G services, mobile network operators (MNOs) are very competitive and typically don't share their long-term strategy, but many have publicly stated that they expect to continue providing 2G services until at least 2025. Its almost certain that the 3G sunset will happen earlier than 2G for most countries and MNOs. So, we are entering into unknown territory in this respect. What we can certainly expect is a slow and gradual degradation in the capacity and bandwidth available over 2G and 3G services over the next 5 years or so. It may be that 2G is still around in 2030, but there's little doubt that the coverage, availability and capacity will be a fraction of what it is now.

Until now, IoT applications have shared the same mobile network services as consumer devices, smart-phones and tablets etc. Continuing along that path does not make sense, since consumer applications use many giga bytes (GB) per month, and typical IoT devices use only a few mega bytes (MB). Hence the launch of Low-Power Wide Area network services (LPWA), such as LTE Cat M1 and NB-IoT. These services are designed specifically for IoT applications, small, low-power, low bandwidth and inexpensive. These services are rolling out globally, and although they are not yet ready to use everywhere, it won't be long until these services are as ubiquitous as good old 2G. Astra's updated 2021 product range are all compatible with LTE Cat-M1 and NB-IoT with 2G/GPRS fall-back, so we can continue as we are, using 2G, but with the reassurance that we are ready for LPWA services as and when they roll-out. Note that LTE Cat-M1 is also known as "eMTC" or "LTE-M"

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 there 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.