FAQs

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 2 months 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 AT402, AT202, AT241, AT242 and AT111) 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 (2023), 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.  Operators in the UK have announced that they will be withdrawing 2G and 3G services between 2023 and 2030.  What we expect is a slow and gradual degradation in the capacity and bandwidth available over 2G and 3G services over the next 7 years or so. It seems (in the UK at least) that 2G will still be available until 2030, but there’s little doubt that the coverage, availability and capacity will be slowly reduced over the coming years.

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 current 2023 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.

Astra began in 2009, but our technical team have been working in the field of GPS and IoT since 1998.

Please contact us with details of the feature you require and one of our product specialists will get in touch to discuss.

Of course! Many of our devices have been developed with a specific client application in mind, so please contact us with details of your requirements and we will be happy to discuss.

Not at all! Our devices are supplied ready to go, no need for scripts or code to define your application. We have done that for you, all that is required is to configure your chosen platform and SIM details to allow communication, and then to select your chosen features and options from a wide variety of configuration options. Our default configurations will be a good start in most cases, but when you need to tweak things, you will find that you have all the flexibility you require.

Yes, we offer an SDK which allows unlimited customisation of our device firmware, for use with all our devices. This option requires some investment in licences, development tools and very specialist embedded software development skills, so its not for everyone. Please contact us if you wish to discuss this option further.

Yes, our devices use a common protocol which is supported by a wide variety of ASPs (Application Service Providers).

That depends on the number of devices that you expect to deploy and the resources that you have available for development and support. Few fleets have sufficient numbers of vehicles to justify the development and support costs of running your own ASP service. The break-even figure depends on many factors, but we would suggest it is in the region of 1000s of vehicles/devices, rather than 100s. Development time should be considered in the region of 6 to 9 months at least, although this can be reduced by starting with an open source solution such as openGTS, those solutions are quite basic and may require significant additional development to meet your requirements.

Yes, our protocols are open and available to developers on request, please contact us for documentation and example parser code.

Yes, we have many partners offering services for different applications and locations. If you can share your requirements with us, we will be glad to recommend some suitable options.

Yes, we can offer an API as an option at a small extra cost pcm.

“IoT” (Internet of Things) is a new and fashionable term for what we previously called “telematics”, and before that “m2m” (Machine to Machine). All refer to products and solutions which involve devices collecting data from sensors and/or peripherals, and sending that data to another “machine” or “thing”, usually a server of some kind, using the internet for communications, via a variety of mobile communications network services.

Until recently, the vast majority of telematics devices were used in vehicles, for fleet management, security, driver behaviour (insurance) and logistics. More recently, we have seen IoT technology used in solutions such as smart motorways, vehicle sharing, smart meters, vending machines and many more! Astra Telematics devices are used mainly in automotive applications.

All our devices are supplied with an industry-leading 5 year warranty!

Our warranty covers device malfunctions or failures which result from manufacturing defects, design issues or firmware bugs.

In the first instance, please contact us for advice, a member of our technical team will first try to ascertain whether the issue could be resolved by configuration or a firmware update. Please contact us on +44 161 826 8800 or email support@astratelematics.com

If our technical team cannot resolve the issue remotely, you will be issues with an RMA number, which will be used to track the return/repair throughout the process. You can then return the devices to us. On receipt, we will assess the devices and send a report, detailing our findings and what repairs / replacements we consider necessary. Where a fault is not covered under warranty, we will advise the cost for the repairs and ask for approval to proceed with the work.

We aim for a 10-day turnaround time on all RMAs.

This depends on the type of fault, the component to be replaced, and the time necessary. We have a scheduled of fixed costs for common repairs, which can be found on the RMA form, which you will have completed at the start of the process.