Post by teixeluis on Sept 3, 2018 21:33:41 GMT
This is in most part the excerpt of an email that I sent directly to VoltasIT in November last year. Most of these points are still valid:
- speed: it is often a painfully slow experience, when switching between realtime data from the ECUs. Based on the experience with other tools it doesn't seem that the latency is in the communication with the car ECUs. If it is related with the processing/load in your backend servers, I would say it is something for you to give close attention to while you plan to scale the business (an elastic cloud based infrastructure could help in that respect). If it is related to code inefficiencies, you should invest in refactoring or optimizing the critical aspects (I would assume the app has to do a lot of lookups to resolve lable data for each particular CAN UDS device, so proper indexing of the data is crucial).
- use cases: the tool seeems to be oriented only for sporadic use, and not as a tool that the performance driver will want to have running and looking at all the time (even though it could potentially be so). With the large spectrum of sensor data the this tool is capable of collecting and presenting, it could be second to no other application in the market, if it had the capability of presenting multiple gauges in a similar fashion to apps like "Torque".
- leave the dongle attached to the diagnostics port: many users have reported that leaving the dongle attached after leaving the vehicle, quickly causes the battery to be depleted. It is speculated that this quick draining is not directly from the dongle itself, but from the ecu's that it forces to stay awaken (e.g. because of unfinished test runs), even after the user logs out or goes out of the bluetooth range. Judging by the hardware that you have selected to use in your dongle, it should not be a unsurmountable challenge to implement some power saving features: i.e. when a user diconnects from the bluetooth, you could shut down the CAN transceiver and the microcontroller (while keeping the bluetooth receiver in standby - which likely should consume a marginal amount of power). This likely would cause the ECUs to go to sleep, just as if the user had physically removed the dongle.
- selection of bluetooth radio: based on the dodgy bt address of these dongles (e.g. 00:aa:bb:cc...), I would assume that you have taken aggressive compromises in production costs by picking up a low cost chinese vendor for these radios. I would however recommend that you revise this aspect in later iterations, as your are also increasing the security concerns for the users, by using a repeating bt address instead of a globally unique one;
- measurements available in the different languages: after switching to portuguese language, I noticed that the Fuel level measurement is not available, while other fields not available in english are available in portuguese (reported here a while ago: forum.obdeleven.com/thread/3822/output-test-availability-depending-language);
- apps: I have tried enabling the oil temperature display on the instrument cluster. The app tried to apply the change but at the end it reported it was unable to apply the adaptation. Nothing changed on the instrument cluster, but after reviewing the long coding history I could see that the value change was persisted. I would expect that in this type of scenario, the app would roolback to the previous setting. While in this case it may mot make a difference (not sure however..), it could be a problem in other settings/ecu's.
- long login times - sometimes the app will not connect to the dongle, prompting for selection of the bluetooth device after a while.
- support for screen rotation - not always is convenient to present the screen vertically, especially if one wants to monitor data and eventually present via MirrorLink in the Infotainment.
I hope at least some of this feedback can influence improvements in the product.
Best regards,
Luis Teixeira
- speed: it is often a painfully slow experience, when switching between realtime data from the ECUs. Based on the experience with other tools it doesn't seem that the latency is in the communication with the car ECUs. If it is related with the processing/load in your backend servers, I would say it is something for you to give close attention to while you plan to scale the business (an elastic cloud based infrastructure could help in that respect). If it is related to code inefficiencies, you should invest in refactoring or optimizing the critical aspects (I would assume the app has to do a lot of lookups to resolve lable data for each particular CAN UDS device, so proper indexing of the data is crucial).
- use cases: the tool seeems to be oriented only for sporadic use, and not as a tool that the performance driver will want to have running and looking at all the time (even though it could potentially be so). With the large spectrum of sensor data the this tool is capable of collecting and presenting, it could be second to no other application in the market, if it had the capability of presenting multiple gauges in a similar fashion to apps like "Torque".
- leave the dongle attached to the diagnostics port: many users have reported that leaving the dongle attached after leaving the vehicle, quickly causes the battery to be depleted. It is speculated that this quick draining is not directly from the dongle itself, but from the ecu's that it forces to stay awaken (e.g. because of unfinished test runs), even after the user logs out or goes out of the bluetooth range. Judging by the hardware that you have selected to use in your dongle, it should not be a unsurmountable challenge to implement some power saving features: i.e. when a user diconnects from the bluetooth, you could shut down the CAN transceiver and the microcontroller (while keeping the bluetooth receiver in standby - which likely should consume a marginal amount of power). This likely would cause the ECUs to go to sleep, just as if the user had physically removed the dongle.
- selection of bluetooth radio: based on the dodgy bt address of these dongles (e.g. 00:aa:bb:cc...), I would assume that you have taken aggressive compromises in production costs by picking up a low cost chinese vendor for these radios. I would however recommend that you revise this aspect in later iterations, as your are also increasing the security concerns for the users, by using a repeating bt address instead of a globally unique one;
- measurements available in the different languages: after switching to portuguese language, I noticed that the Fuel level measurement is not available, while other fields not available in english are available in portuguese (reported here a while ago: forum.obdeleven.com/thread/3822/output-test-availability-depending-language);
- apps: I have tried enabling the oil temperature display on the instrument cluster. The app tried to apply the change but at the end it reported it was unable to apply the adaptation. Nothing changed on the instrument cluster, but after reviewing the long coding history I could see that the value change was persisted. I would expect that in this type of scenario, the app would roolback to the previous setting. While in this case it may mot make a difference (not sure however..), it could be a problem in other settings/ecu's.
- long login times - sometimes the app will not connect to the dongle, prompting for selection of the bluetooth device after a while.
- support for screen rotation - not always is convenient to present the screen vertically, especially if one wants to monitor data and eventually present via MirrorLink in the Infotainment.
I hope at least some of this feedback can influence improvements in the product.
Best regards,
Luis Teixeira