BlueBus: A fully integrated A2DP Bluetooth solution

[hobo]

Actually the Kombi light is not full on, but only stuck at current dimm wheel setting level.
Disabling park lights in confort menu and waiting a few secs unlock the wheel settings. Then you can switch back park light ON.

Until next car start.

Okay, yeah that makes sense. The LSZ does not accept dimmer wheel updates while a diagnostic function is in process, meaning it will only update the dimmer setting once the diagnostic is over. The problem is that I am keeping diagnostics on indefinitely, so it never updates. One of my amazing project contributors was going to look into this, but I'm not really sure there's anything we can do.

That's why I'm wondering if the Intravee somehow solved this.

Thanks!
-Ted

Tested with intravee, no issues with it!

We've identified what is likely causing this. The comfort parking lights automatically disable when lights are turned on via the switch (as they are redundant at that point), however this is delayed by up to 18 seconds. In this time the dimmer switch is apparently ineffective.

[Orphee]

Okay, yeah that makes sense. The LSZ does not accept dimmer wheel updates while a diagnostic function is in process, meaning it will only update the dimmer setting once the diagnostic is over. The problem is that I am keeping diagnostics on indefinitely, so it never updates. One of my amazing project contributors was going to look into this, but I'm not really sure there's anything we can do.

That's why I'm wondering if the Intravee somehow solved this.

Thanks!
-Ted

Tested with intravee, no issues with it!

[hahnweiler]

Hello,
I have a bug with latest FW, I guess it us linked to DRL :

Dashboard KOMBI light is full ON and the dimm wheel does not work.

And I don't know how I triggered it but I was able to get back light OK.

But it seems to happen every time I use the car.

I didn't take time yet to catch when and how it happens.

I have the same issue since i updated to 1.1.18. First I thought my LSZ is defect. Good to know that i am not alone.with this problem.

[Pklauser]

Ted, this is awesome, reminds me a lot of what the guys over at https://cantalouperadio.com/collections/products were doing, and as a software engineer myself I definitely appreciate the open source aspect!

Looking at the module you're using, it looks like it could support aptX-HD if loaded with the right firmware, is that correct? Curious if the bluebus as-sold supports that codec.

[t3ddftw]

Actually the Kombi light is not full on, but only stuck at current dimm wheel setting level.
Disabling park lights in confort menu and waiting a few secs unlock the wheel settings. Then you can switch back park light ON.

Until next car start.

Okay, yeah that makes sense. The LSZ does not accept dimmer wheel updates while a diagnostic function is in process, meaning it will only update the dimmer setting once the diagnostic is over. The problem is that I am keeping diagnostics on indefinitely, so it never updates. One of my amazing project contributors was going to look into this, but I'm not really sure there's anything we can do.

That's why I'm wondering if the Intravee somehow solved this.

Thanks!
-Ted

[Orphee]

Actually the Kombi light is not full on, but only stuck at current dimm wheel setting level.
Disabling park lights in confort menu and waiting a few secs unlock the wheel settings. Then you can switch back park light ON.

Until next car start.

[Orphee]

If you still own the Intravee, can you check if this happens as well? It's a byproduct of keeping light diagnostics active indefinitely (DRL always on).

-Ted

I played a bit with it.
As soon as park light is on when I switch on headlights : KOMBI full ON

No matter I switch headlight OFF/ON, KOMBI full ON.

Now if I disable/enable parklight setting while headlight ON, after one or more tries, KOMBI light switch to real value and dimm wheel works.

I'll check with Intravee currently installed on the M5, but I don't recall having this issue with it.

Thanks

[tcp]

Weird -- Sounds like it has crashed and restarted. Did this correlate with anything happening, like a song change or a call coming in?

If you could, try to pull the trap counters via the terminals -- the command is: get err

Thanks!
-Ted

I've experienced a similar issue as Der_Spanier. This is with version 1.1.18 on an '05 M3 with a CD53. The trap counters show a non-zero BC127 Boot Failures value. I don't remember the exact number... I think it was 6 or 7, but it could definitely correlate to the number of "reboots" I've experienced.

I just thought it was the cold boot issue. I seem to remember that being a thing. The car stays in a non-climate controlled garage and it's been chilly here lately...

[t3ddftw]

Hello,
I have a bug with latest FW, I guess it us linked to DRL :

Dashboard KOMBI light is full ON and the dimm wheel does not work.

And I don't know how I triggered it but I was able to get back light OK.

But it seems to happen every time I use the car.

I didn't take time yet to catch when and how it happens.

If you still own the Intravee, can you check if this happens as well? It's a byproduct of keeping light diagnostics active indefinitely (DRL always on).

-Ted

[Orphee]

Hello,
I have a bug with latest FW, I guess it us linked to DRL :

Dashboard KOMBI light is full ON and the dimm wheel does not work.

And I don't know how I triggered it but I was able to get back light OK.

But it seems to happen every time I use the car.

I didn't take time yet to catch when and how it happens.

[t3ddftw]

I'll do that. I'll need a detailed list of instructions though. I'm guessing I need to gather a log, but a log of what?



Jeeez $400 is steep! Says a lot about you that you're warning us about this. Someone else would've hopped on the wagon and simply raised their price altogether...

Just enable IBus logging for a quick second and note the number between brackets. For example,

[2729302] DEBUG: BM83: TX: AA 00 02 14 1A D0

2729302 / 1000 = 2729 seconds of uptime, or 45.48 minutes.

Jeeez $400 is steep! Says a lot about you that you're warning us about this. Someone else would've hopped on the wagon and simply raised their price altogether...

I think gouging that much is outrageous. There's another BlueBus on Facebook marketplace for $300, which is still very expensive but certainly outside the range of being a ripoff.

-Ted

[Der_Spanier]

Any chance I could get you to take a laptop with you when you drive and just grab the current timestamp that the BlueBus is showing after a failure? The number between brackets is milliseconds since it last booted up. I just want to know if it has reboot or if there's been a protocol related issue that caused the radio to stop "seeing" it. I know that's a pain in the ass, but unfortunately you're the only one reporting this problem

I'll do that. I'll need a detailed list of instructions though. I'm guessing I need to gather a log, but a log of what?

FYI to everyone, but apparently some folks are trying to make a buck on the supply / demand issue with the BlueBus -- I am actively working on the hardware and software modifications required to spin up a new revision of the board -- Don't pay $400 for a BlueBus, especially as I am looking to lower the price to $199:

-Ted

Jeeez $400 is steep! Says a lot about you that you're warning us about this. Someone else would've hopped on the wagon and simply raised their price altogether...

[t3ddftw]

Hey Ted,

I didn't check but is the current version on the most recent batch running 1.1.18?

Yep!

Happened again yesterday evening after I had pulled the trap counters. Only this time I had been driving about for 20 minutes or so. However, I had only switched the radio on and gone to Bluebus mode a couple minutes prior to it "crashing".
This time I could pull over and check the boot. The Bluebus was showing a green light (constant, not blinking) all along, and the connectors were firmly sat in place. As usual, everything started working again after a few minutes.

Any chance I could get you to take a laptop with you when you drive and just grab the current timestamp that the BlueBus is showing after a failure? The number between brackets is milliseconds since it last booted up. I just want to know if it has reboot or if there's been a protocol related issue that caused the radio to stop "seeing" it. I know that's a pain in the ass, but unfortunately you're the only one reporting this problem

FYI to everyone, but apparently some folks are trying to make a buck on the supply / demand issue with the BlueBus -- I am actively working on the hardware and software modifications required to spin up a new revision of the board -- Don't pay $400 for a BlueBus, especially as I am looking to lower the price to $199:

-Ted

[Der_Spanier]

Soo I finally pulled the trap counters. Here's what I got:

Trap Counts:

Oscillator Failures: 0
Address Failures: 0
Stack Failures: 0
Math Failures: 0
NVM Failures: 0
General Failures: 0
Last Trap: 00

BC127 Boot Failures: 0

I'm no expert but it sounds like everything is alright on that front...

Funnily enough every since I posted about the issue here it has not reproduced itself 😂 The only thing I can think of is that both times it happened, I had left the car parked outside overnight or for a very long time (8 hours or so) in cold temperatures. I don't know if that could have something to do with it.

Happened again yesterday evening after I had pulled the trap counters. Only this time I had been driving about for 20 minutes or so. However, I had only switched the radio on and gone to Bluebus mode a couple minutes prior to it "crashing".
This time I could pull over and check the boot. The Bluebus was showing a green light (constant, not blinking) all along, and the connectors were firmly sat in place. As usual, everything started working again after a few minutes.

[simonnim]

Hey Ted,

I didn't check but is the current version on the most recent batch running 1.1.18?