Reminder: "FooChanged" signal is deprecated in AMB 0.12+
by Rees, Kevron
Reminder again,
If you are using "FooChanged" (ie, VehicleSpeedChanged on
org.automotive.VehicleSpeed), this signals has been removed for 0.12.
Please use PropertiesChanged on org.freedesktop.DBus.Properties.
-Kevron
8 years
Unit for Instant Fuel Consumption
by FABIEN HERNANDEZ
Hello,
Thanks to initiate this mailing list :-).
My first comment/issue is linked to fuel consumption.
This data is specified like this (Vehicle Information API Spec.html):
readonly attribute unsigned short InstantConsumption Must return instant fuel consumption in milliliters of fuel per second
Unit doesn't seem adapted because if you drive at 90 km/h, it means that for:
- 1ml/s the average consumption is ~4l/100km
- 2ml/s the average consumption is ~8l/100km
If we take a speed of 10 km/h, it means that for:
- 1ml/s the average consumption is ~33l/100km
- 2ml/s the average consumption is ~66l/100km
At least, we need to allow average consumption with a granularity of 0.1l/100km.
With a unit in micro liter we could have these results at 10km/h:
- 1µl/s the average consumption is ~0.033l/100km
- 2µl/s the average consumption is ~0.066l/100km
Which are more aligned.
µl/s unit with data on 16bits at least should be enough.
Best regards
Fabien HERNANDEZ
PSA Peugeot Citroën
Route de Gisy
VV237
78943 - Vélizy Villacoublay Cedex
Tél : +33 (0)1 57 59 41 22 (Vélizy) - Fax : 01 41 36 32 21
fabien.hernandez(a)mpsa.com
"Ce message peut contenir des informations confidentielles. S'il ne vous est pas destiné, merci de le détruire et d'informer immédiatement son émetteur. Pour plus d'informations relatives à la confidentialité et à la sécurité veuillez consulter http://disclaimer.psa-peugeot-citroen.com"
"This message may contain information that is confidential. If you are not the intended recipient, please advise the sender immediately and delete this message. For further information on confidentiality and the risks inherent in electronic communication see http://disclaimer.psa-peugeot-citroen.com."
8 years
First post and upcoming 0.12 changes
by Kevron Rees
There is a list for AMB discussion now!
First, thanks to 01.org and Intel for hosting the mailing list for
Automotive Message Broker. 0.11 is now beta which means only bug fixing
from here onward. The focus of 0.12 is performance and here are some of
the planned changes many of which have already landed in master:
- DBus signal fire rate throttled.
There is a new config option for the dbus sink plugin called "frequency".
This is how many times signals will be fired from the DBus. The reason is
that firing signals over DBus is very expensive in terms of CPU. The
frequency units are Hz, so if you want 100 signals per second, you would
enter "frequency" : "100".
- High speed data should not use DBus plugin
DBus is great for setting, getting data with security, but it's not great
for high speed data. It is recommended that applications use DBus for
getting single values and for setting and for low speed data changes. If
applications need high-speed data, they should use the new websocket plugin.
- New websocket plugin
The new plugin we could call "websocket2". It uses libwebsocket but the
protocol can be either Json or a binary protocol. It uses QJsonDocument
which is the fastest Json parser on the planet. Early benchmarks show it's
at least twice as fast as libjson-c and turning on the "binaryProtocol"
option inside the config makes it even faster.
We still have the old websocket plugin in the tree for now. We may remove
it in the future and recommend developers use the new websocket plugin.
PLEASE NOTE: the new websocket plugin has an updated json protocol.
- Dynamic DBus objects
In 0.11, all DBus object were created at startup. Application developers
where asked you use FindObject (and like methods) to discover the paths for
the specific objects they wanted. Because these objects where created at
startup, boot performance was impacted. Additionally, signals would fire
on these object whether or not any application would be listening. This
means that if the dbus sink received 1000 data updates per second, it would
fire 1000 over dbus even if no one was listening. In 0.12 the objects will
not be available on DBus until FindObject (and like methods) are called and
the object will stay "active" on DBus until the last process that called
FindObject has disconnected from DBus or closed.
This change in behavior will not break existing applications that are
already using FindObject. If an application is hard-coding the object path
(ie "/asdfa234234/0/VehicleSpeed") then those applications will break.
The combination of the above changes should have a huge impact on AMB
performance, especially when using DBus.
These performance issues are being tracked in the tizen ivi jira here:
https://bugs.tizen.org/jira/browse/TIVI-2368
Happy New Year! I'm looking forward to a very productive year in AMB
development.
Kevron
8 years
