Quote:
Originally Posted by Fabb
I don't think there would be a permanent solution. The Bimmerlink relies on the BLE connection to stay alive to remember the settings. It doesn't change any memory settings in the ECU. Only if he could implement this on Bimmercode, the solution would be permanent.
|
Not to disregard your knowledge as you're probably correct and I don't have an intricate know-how on BimmerLink or BimmerCode apps.
BUT...don't both apps (BCode and BLink) communicate to the ECU via the dongle's BLE connection and the OBD port to toggle flags ON/OFF for certain features? Dongles like the Veepeak OBDCheck BLE act a comms bridge between the phone app and the car's ECU/DME:
- the BLE is used to receive commands from apps residing on the phone [primarily a half duplex communication as it always listens for phone commands; normally it won't allow to 'write/send' anything back to the phone, with perhaps the exception of an ACK - acknowledgement flag]
- while the CANbus wiring system is used to communicate and control various microprocessors inside the car [this is a full duplex with asynchronous Read/Write capabilities]
Maybe I got this wrong, but to my knowledge, at a very high level the data flows this way:
1. The BLE (Bluetooth Low Energy) is used to communicate to the phone app itself. A certain command is set from BimmerLink/BimmerCode apps, then sent to the OBD port via the BLE communication protocol running on the dongle (e.g. VeePeak)
2. Using the OBD port, the dongle 'receives command', and it then sends it via the CAN bus wiring system to the ECU for execution
3. For any flag/feature to remain permanent, the appropriate command needs to be written such that the ECU stores it.
If my
simpleton explanation above is true, why would the BLE connection need to always be on for a more permanent approach?
Feel free to correct any statements, I'm a student of knowledge and wish to learn how things work.