Closed rsporsche closed 4 years ago
@rsporsche,
This is directly related to #2, but I will keep it open nonetheless. The issue is that the MID doesn't like how quickly the BlueBus writes the UI again, so some things are missed at times.
However, I am working on hijacking the UI by emulating the factory TEL module. The MID lends itself wholly available to the TEL and prevents other modules (DSP, RAD) from writing to it while the TEL view is active. This would allow me to ignore the tug-of-war with the RAD.
I'll have more on this soon.
Thanks! -Ted
test in my case: MID without phone option/button does not handle the phone messages.
@harryberlin,
Can you try issuing this frame on the I-Bus?
C8 04 C0 27 02 29
The display should blank out and accept messages from the TEL.
Thanks! -Ted
@harryberlin,
If that doesn't work, also issue these messages:
C8 04 BF 02 31 40
C8 04 C0 02 30 3E
Then issue:
C8 04 C0 27 02 29
will take some time. because, MID is not connected at the moment.
The issue is that the MID doesn't like how quickly the BlueBus writes the UI again, so some things are missed at times.
Based on the log file it looks as though the BlueBus isn't issuing the ibus commands to redraw the UI though?
I'm assuming that the lines marked [SELF] are commands sent by the BlueBus and the leading number on each line is uptime in milliseconds?
Btw, I have some experience in software development, also with embedded systems, and would be happy to help with this project particularly as related to the MID interface if possible. The only drawback is that the only device I have to test on is the one in my car.
@harryberlin,
No worries, I appreciate you testing. Please note that I have updated the frame as I gave the XOR checksum in decimal rather than octal :(
@rsporsche,
That happens too, because the BlueBus tries to differentiate its own menu writes from that of the RAD, which means looking at the nuances of the way the RAD writes to the screen -- another reason to move into a bespoke UI mode.
The [SELF]
messages are frames sent by the BlueBus and you're correct about the timestamp.
Are you based in the U.S.? I have a boneyard of BlueBus prototypes and units that failed due to the recall issue, and I can definitely spare one of those :).
-Ted
I wondered if it would be an option to keep track of the commands that were issued by the BlueBus to update the MID and redraw if a MID display command is seen that doesn't match that 'known' set?
Maybe the TEL idea works better though.
I'm in Germany unfortunately. I wasn't thinking so much of the BlueBus but more the radio/MID. I guess I would also need the IKE?
Is it possible to 'brick' the BlueBus?
@rsporsche,
This isn't as easy as it sounds because I have to wait until the RAD is done "speaking" in order to override the MID display again, otherwise things are liable to not write out consistently. That means "knowing" when the RAD is done speaking. This is why I want to move to bespoke UI mode :smile:
You only need a RAD/MID for a bench setup. The IKE is icing on the cake (I have a 540i IKE, but I don't use it with the MID).
It is not possible to brick the BlueBus. The bootloader lives in the first 0x1800 addresses of memory and has been protected against accidental writes. See: https://github.com/tedsalmon/BlueBus/blob/master/firmware/bootloader/lib/protocol.c#L74
@rsporsche,
Can you please try: https://t3ddftw.s3.us-east-2.amazonaws.com/BlueBus/firmware/bluebus_1_1_15_mid_tel_ui.hex
You will need to use the Audio
button to exit the BlueBus UI. Any subsequent presses of the 1 - 6 buttons will force the MID to enter "BlueBus" mode again.
Text scrolling is still a bit off, but it should at least stay pinned to the MID.
Thanks! -Ted
Thanks Ted, just installed the new firmware today.
First impressions are that the Bluebus menu works now but it's still responding to button presses when I think it shouldn't.
Example: I press the TONE button by the tape deck and it shows me options for bass/treble/etc. but if I click one of those it immediately switch back to the BlueBus. Same if I press the BC button on the MID and try selecting any of the options such as CONS/RANGE/etc.
I logged the output while pressing the TONE, AUDIO, and BC buttons ten times. Looks like there is a message for the BC and AUDIO buttons that could be detected but nothing that I can see for the TONE button, presumably it's part of the radio so the radio only writes to the display.
I'm wondering if it would be possible to detect when these buttons are pressed and switch out of the BlueBus menu mode until the AUDIO button is pressed again?
Also, the MODE button is effectively lost when entering the BlueBus menu. I guess this is what you mean by "You will need to use the Audio button to exist the BlueBus UI"? I think it would be possible for the BlueBus to handle the mode button press though?
@rsporsche,
This firmware should fix those issues: https://t3ddftw.s3.us-east-2.amazonaws.com/BlueBus/firmware/bluebus_1_1_15_1.hex
On the MODE button issue, it is technically possible, but ultimately difficult to emulate the MODE button press. The new firmware places the MID in TEL mode, so the RAD stops listening to commands / button presses from the MID (and the MID stops addressing the RAD). I would have to give up TEL UI mode, then emulate the MID mode button press, and this can be clumsy depending on the amount of bus traffic at the time.
Thanks! -Ted
Thanks Ted,
So far it looks like a big improvement. I think it's at a point where I could live with it pretty happily.
Come to think of it, while it would be nice to retain the MODE button, I don't use the radio or tape so it's not really a problem.
I had been thinking I could create a device to isolate the radio on a second IBUS network and selectively relay messages, but not worth the effort at this point and wouldn't work as well with the 'TEL' GUI.
@rsporsche,
I'm going to mark this as resolved :). Here's the latest binary: https://t3ddftw.s3.us-east-2.amazonaws.com/BlueBus/firmware/bluebus_1_1_15_3.hex
This was resolved in 48396c9
Thanks! -Ted
Thanks Ted, I'll check out the latest version. I noticed that the MID display seems to switch off when ending a call now but I'll log a new bug report for that if it still happens with the latest firmware.
@rsporsche,
This isn't a bug moreso than it is a lack of a feature. I tell the car that a call is active and the MID automatically blanks out because it expects the phone system to write something about the call to the screen, and I have yet to add that.
Thanks! -Ted
@harryberlin,
Can you try issuing this frame on the I-Bus?
C8 04 C0 27 02 29
The display should blank out and accept messages from the TEL.
Thanks! -Ted
The message is working. The others had no effect.
I have a German delivered 1999 E39 M5 with Business Audio (tape) and MID.
I've noticed that the MID display is very quickly overwritten and the BlueBus is not redrawing.
Example: If I click the 'Settings' button for BlueBus, I see 'Settings HFP: On' displayed and the menu updates with Back, Edit, <, >, etc. But this is quickly replaced by the CD changer display and menu, i.e. 'CD 1-01' and '*1, 2, 3, 4, etc.'. My understanding is that the BlueBus would see that the display had been redrawn by the RAD or IKE and immediately redraw it's own text but that is not happening.
I have attached a log file, demonstrating this.
The firmware version is 1.1.14, I noticed that there is a 1.1.16, should I upgrade?
Note that I have also had some other issues such as BlueBus responding to button presses when it should not (e.g. when changing bass/treble/etc.) and a few times the radio has 'lost' the BlueBus and I can only select radio or tape. I don't know whether these issues are related so I will create separate issues when I have been able to captures logs.
The attached log file was created with 'bt', 'sys' and 'ibus' on but I had to unplug the USB and cycle the ignition after setting those initially and I don't know whether that would have affected these settings. I assume by the volume of ibus messages that it did not.
[Com COM3] (2020-09-09_160349).log