Ideas for data to grab

[jilleb]

There are a few data elements you can grab from the persistance channels.

export LD_LIBRARY_PATH=/mnt/app/root/lib-target:/eso/lib:/mnt/app/usr/lib:/mnt/app/armle/lib:/mnt/app/armle/lib/dll:/mnt/app/armle/usr/lib 
export IPL_CONFIG_DIR=/etc/eso/production 

on -f mmx /net/mmx/mnt/app/eso/bin/apps/pc i:<address>:<key>

I know of the following:

Address	Key	Data element
1304	211	Drive Level
1304	212	Night mode
1304	213	Distance
1304	214	Gear
1304	215	Fuel level low
1304	216	Speed
1304	217	Sat # in view
1304	218	Sat # in use
1304	219	GPS latitude (E7)
1304	220	GPS longitude (E7)
1304	221	GPS accuracy (E3)
1304	222	GPS altitude (E2)
1304	223	GPS speed (E3)
1304	224	GPS bearing (E6)
1304	225	Parking brake
1304	226	GPS timestamp

These are used in the Android Auto Sensors green menu screen.
It should be possible to grab the Exlap data as well, but I never figured out how... would be lovely to be able to send the transmission temperature to the AID, since this data element isn't available anywhere else.

You can grab them with pc

[OneB1t]

cannot test it now but latest version should produce something as this:

[OneB1t]

i keep receiving following error message

root@mmx:/mnt/app/root> on -f mmx /net/mmx/mnt/app/eso/bin/apps/pc i:1304:211   [PersistenceClient::getIntResult] error: result == DOES_NOT_EXIST
-1
root@mmx:/mnt/app/root>

other than that it is working :-)

[OneB1t]

maybe following data can be also loaded from some persistence channels? (maneuvr, destination dist)

[jilleb]

In the car right now, going through the green menu to see what other live data is displayed there.

Dead reckoning has Speed and Heading
Map position has height
Road attributes has current street, distance to next move, exit name, Heading

In the past I wrote a persistence address scanner, that would go over a range of addresses to see whats there. I never used it while driving, or navigating/playing audio in Android Auto, so maybe there's more useful info there.

If only we could get the exlap data from the console... Then we would have whatever data we want! Transmission temperature would be the most interesting.

[OneB1t]

Can you specify which script it is using? Also please specify full path where you find this so i can try to replicate at my car.

[jilleb]

Yes, I'm in the office now so I can check the .esd files to see where they get their data. I'll get you a list of persistence addresses for these data elements in about an hour.

[jilleb]

The following elements are found in the green engineering menus (esd files), which all represent persistence coding addresses we can call with the pc command:
(format I used here is: <label>: <type> per <partition> <address>)

speed: int per 0x01c500e6 108
heading: int per 0x01c500e6 109
angular velocity (deg/sec): int per 0x01c500e6 101

road attributes: 0x01c500e6 111
this contains the following data elements (name, type, size):

• current street String 15
• distance next destination int 15
• distance next maneuver int 15
• next street String 15
• sign post String 15
• destination direction int 15
• distance final destination int 15
• segment ID String 15

map position: 0x01c500e6 110
this contains the following data elements (name, type, size):

• longitude String 15
• latitude String 15
• heading int 15
• z-level int 15
• height String 15
• parking int 15
• ramp detection int 15
• tunnel int 15
• mapMatcherStatus int 15

About the AndroidSensors, address 1304 210 holds the update frequency.. If it's 0, the data isn't refreshed. So I think we need to set:
on -f mmx /net/mmx/mnt/app/eso/bin/apps/pc i:1304:210 1
And then the ones you tested above that lead to a -1 could possibly work?
Hopefully, then the Android sensor data will provide some information.
I need to check the other addresses in this 1304 range to see what else is there, while I'm playing music in Android and/or navigating in Maps/Waze.

During a persistence scan in 2020, I found the following addresses to be valid within this partition:

And then there are some other data elements related to media, although I haven't checked them yet:
PSD Artist: String per 1 0x00012021
PSD Title: String per 1 0x00012020

And these could be useful for a proof of concept:
WLAN name: Blob per 28836065 40
WLAN password: Blob per 28836065 39
TMC message: Blob per 29688038 210
GPS coordinates: Blob per 29688038 504

I got data from these.
To get the data it's always like this:
on -f mmx /net/mmx/mnt/app/eso/bin/apps/pc b:28836065:40
where b = blob, s = string, i=integer

I'll search some more elements.
Edit, more data elements:

Driving state: String 0x01be00df 501
Think blue score: int 0x01be00df 502
Vehicle Acceleration: int 0x01be00df 503
And some experimental ones in the same area I didn't validate:
Vehicle speed: int 0x01be00df 504
Car in reverse (boolean): int 0x01be00df 505
Car driving (boolean): int 0x01be00df 506
Engine: String 0x01be00df 507
2nd Engine: String 0x01be00df 508
Gear type: String 0x01be00df 509

[jilleb]

Did some more research, unfortunately i don't have access to the MIB2 at work, because that would make life easier.
There's a developer script, rdActivateSDIS.sh:

#!/bin/sh
. "/scripts/commonConfigExchange.sh"

setup_mmx()
{
	${MOUNT} -uw "/mnt/system"
	${MV} "${MMX_CFG_DIR}/rdiserver.json" "${MMX_CFG_DIR}/rdiserver_exlap.json"
	${MV} "${MMX_CFG_DIR}/rdiserver_full.json" "${MMX_CFG_DIR}/rdiserver.json"
	${MOUNT} -ur "/mnt/system"
	${SYNC}
	slay rdiserver
}

if [ -e "${MMX_CFG_DIR}/rdiserver_full.json" ] ; then
	setup_mmx
	${ECHO} "Done."
else
	${ECHO} "Target is already configured for sdis communication."
fi

no idea what this does, but the contents of rdi_server_exlap.json is as follows:

{
 "baselibname" : "exlap_plugin",
  "path" : "/eso/bin/apps/",
  "ignore_plugin_errors" : true,
  "supervision" : {
	"queue_error_level" : 200,
	"queue_warning_level" : 150,
	"queue_stay_time_ms" :1000,
	"update_cycle_ms" : 4000
  },
  "datastorage" : {
    # location where to store the files
    "location" : "/tmp/",
    # maximum filesize for one file in kilobyte
    "max_file_size_in_kb" : 2000
  },
  "connectivity" : {
        "add_dlink" : false,
        "add_local" : true,
        "bind_retry_count" : 100,
        "bind_retry_sleep_time" : 100,
        "listener" : [
                {
                        "name" : "uap0",
                        "type" : "wlan"
                },
                {
                        "name" : "ncm0",
                        "type" : "usb"
                },
                {
                        "name" : "mlan0",
                        "type" : "wlan"
                }
        ]
  }
}

Looks like it can write exlap data to /tmp, next to having it avialable on the local network.

[OneB1t]

on -f mmx /net/mmx/mnt/app/eso/bin/apps/pc b:28836065:40

this is working well for me but address 1304 there is nothing :-)
EDIT: ok found something

EDIT: you been right first you need to write to update
on -f mmx /net/mmx/mnt/app/eso/bin/apps/pc i:1304:210 1

GREAT SUCCESS!!!
after enabling of this field i now have this

road attributes: 0x01c500e6 111 && map position: 0x01c500e6 110 are for integrated navigation :-/ so that is no use for AA integration

if we can only somehow find out this maneuvr position somewhere in the memory then it will be posible to render "next move" with proper arrow, distance and everything 😢

[jilleb]

Awesome!!!

Let's scan some more partitions and addresses to see what's there. There is a Car partition

[OneB1t]

problem is if you need to write something somewhere before those data are visible...

but based on android auto data i can make it auto-enable and auto-disable so when there is no android auto running VC will return to normal in-car navigation map :-) it will be so awesome

also in case that we cannot use on -f mmx to read data from some part of memory we can still try to read GAL process memory from python (something like trainer for games) and get the data that way

[OneB1t]

maybe we can also take next turn from GAL logs there should be
following line inside log which contains

[jilleb]

Sounds like a good idea!!

[OneB1t]

now the question is where is the log file :-) and can we point it to /tmp folder to not kill internal memory?
also how to set up GAL_trace logging level?

parsing log in python should be quite easy task

[OneB1t]

maybe this? and where is the resulting file stored?