RoadTest: Hanhaa Symbisa IoT Dev Kit
Author: vlasov01
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: BlackBerry Radar https://ca.blackberry.com/qnx-radar is a combination of a tracking device and a platform to manage fleets, track equipment and shipments.
What were the biggest problems encountered?: No support for event detection in the current version of the firmware. The device was not able to lock on satellites for GPS position during one of the tests.
Detailed Review:
Last year I've participated in IoT on Wheels design challenge with my project Smart Drive. The idea of the project was to connect different participants on the wheels for a safer drive. My project required bi-directional communication, GPS positioning and sensors data. After a quick look at Symbisa hardware specs and advertising materials I felt that it can be a good platform to support my Smart Drive project as it has key technology capabilities from hardware and communication perspective as well APIs to receive data and manage devices.But soon after receiving device, getting related documentation and getting answers from Symbisa support it become clear that my expectations can't be achieved with the current implementation of Symbisa firmware and its cloud platform.
Location precision is one of the key parameters of any tracking device. I've found it useful that precision of location reporting can be clearly distinguished between GPS and GSM based reporting.Here is a screenshot I've captured from Symbisa platform. There are a different columns for GPS and GSM reporting.
Symbisa portal provides a Google Satellite map with location points reported by the device. I've set frequency of reporting for my test to 10 minutes.The first two reporting has been captured while I was walking in a suburb. The device was not able to lock on satellites during my walk. The location precision of GSM signal is far from perfect. It was several hundred meters off target.Then I took a train .The device generated next three reports while I was on the train. The location data was provided by GSM signal again. I believe the device failed to send one report as the time between reports was 20 minutes instead of expected 10 minutes. It may be result of my train moving over the bridge. One interesting aspect of this is the fact that the device hasn't buffered information to resend it next time. It just dropped it instead.
The map below has been generated by data captured from my Android phone and passed to Google. Google provides option to visualize and export these data on Google Maps Timeline . I've exported these data in KML format for the same time frame as reported by my Symbisa device during the test and load KML data set to Google Earth in Chrome browser. The data captured by Google in the same conditions was much more precise for most of the points and clearly aligned with the rail track.The only exception was the location of the first point, which was significantly off and close to what was reported by my Symbisa device.
As Symbisa was not able to lock on salivates in the first test I've run another test. I've put the device outside in clear view of the skies and without any movement.This time it was able to capture location relatively precise. The first reported location was off only by 15 meters and the second report was off by 10 meters. I've took measurements of the temperature using my thermometer and information provided by Environment Canada. The temperature was around 11.5C-12C. Then I've compared it with data reported by my Symbisa device. The temperature reported by Symbisa device was 18.3C and 19.5C. I'm not sure how to explain such significant difference, especially for the second reading.
I've took the device for a trans Atlantic trip. I've put the device into the baggage. Here its travel path.
And somebody opened the baggage twice in Geneva and once in Warsaw according to Symbisa Data Sheet. And it detected drops many times.
Bi-directional communication allows to change important Symbisa parameters - reporting interval, message, bar-code. .
I was looking for an option to disable the device (stop reporting) remotely and then enable it remotely as well.It is not possible at this point. The best available alternative to disable device remotely is to increase time between reporting to maximum possible value . The longest reporting interval accepted by the device I was able achieve is 24h (1440 minutes).
The device settings gets communicated to the device only when a device starts or when the reporting interval has been reached and it was able connect to Synbisa backend. So if you set reporting interval to the maximum value (24h) and then want to switch to a hourly reporting, later then you need to wait for up to a day. Alternatively, the device can be manually restarted., so it will pull new settings at restart time. But the manual option is not very convenient for a large or geographically distributed set of devices.
The firmware update requires USB connection to a PC and installation of the update utility. Windows Defender SmartScreen was not able to recognize this utility. So you need to accept some risk by installing it.
Portal is quite intuitive and easy to use.The Symbisa team has done a great job there.
API security seems follows OAuth2 Client Credential Flow (RFC 6749, 4.4 Client Credentials Grant), which is documented quite well on Internet (for ex. Medium ). But it will be nice if Symbisa documentation included examples.
I've used Symbisa portal API test application and curl to test APIs. Once you understand how OAuth2 Client Credential Flow works it is pretty straightforward to use them.
I've used Symbisa User Manual v1.6 (August 2018). I've followed it to perform firmware update, device registration and exploration.
The User Manual document has many references to "Interrupt functionality". One of examples is "Free fall Interrupt functionality - Notify a freefall event of 50cm". I've just opened a support ticket.
I've opened two tickets in the support portal. Both tickets was processed relatively fast (initial response from 23h to 3 days) and professionally by Shafiq and Valeria. So I've got answers on my questions, where documentation were not complete.
Good management capabilities over the portal and APIs.
Long battery life for a relatively small device.
Ability to use GSM location data in case no GPS lock.
Nice display with the current interval reporting configuration.
I wish reporting can be triggered by predefined set of events (geo-fencing events, sensors interrupts / reading over the threshold) or their combination.
It will be great if I had ability to change firmware or some kind of SDK (like Amazon Alexa Skills SDK), where capabolity can be extended to a specific use case. It can open the platform to a bigger market.
I'd like to be able to push configuration changes in near real-time and not only based on reporting intervals.
It will be great to push firmware updates over the air (OTA).
GPS improvements in getting signal (may be A-GPS and / or better antenna?)
Display reflects current situation in terms of satellite lock, GSM signal strength, battery capacity. Right now it provides information from the time of the last reporting.
Extend API documentation. It is quite limited at this point.
Events sourcing (push data to other platforms). They can only be pulled over API.
As the product is still in development I wish the team can share their development roadmap.
Based on my experience with the temperature sensor I wish it is has a better calibration and reliability.
