BMW IBus-Heads - Page 3

aal2000 · 04-19-2006, 10:06 AM

Could you tell me how can I capture the log file? Thanks

sama · 04-19-2006, 11:52 AM

select everything ni the window, that's the log

aal2000 · 04-19-2006, 12:49 PM

OK. I will post both files tomorrow.
One more thing, where it is supposed to disply the mid messages in an e46? In the radio display?

sama · 04-19-2006, 02:36 PM

if you set the flag in the ini file to be FF, then it will send to all devices capable of displaying

you should get it displayed in behind the wheel near the instrument cluster and the radio display

sama · 04-19-2006, 07:34 PM

here it is chaps, scrolling text as promised! I have not tested it in the car yet, but it works on my screen here. let me know how it goes, it's the middle of the night and I'm not going outside

Whenever a scroll is required, an extra 2 spaces will be placed at the end of the string, so spaces in the name can be distinguished from the end of the scroll (this of course assumed your song names don't have more than one consecutive space between them!)

The ini file now contains the follwing extra fields to play around with.

; Tells the scrolling mechanism whehter to wrap the scrolled string or not
WrapScroll=True

so either this (true):

Code:

[T H E . T I T L] E . .
[H E . T I T L E] . . T
[E . T I T L E .] . T H
[. T I T L E . .] T H E
...

or this (false):

Code:

[T H E . T I T L] E . .
[H E . T I T L E] . . .
[E . T I T L E .] . . .
[. T I T L E . .] . . .
...

; The message length which to scroll beyond
MessageLength=8

; The scroll speed in milliseconds
ScrollSpeed=400

the startup message will also scroll, as will any entries to the form directly

I may add some more scroll styles. like this (bounce):

Code:

[T H E . T I T L] E S .
[H E . T I T L E] S . .
[E . T I T L E S] . . .
[H E . T I T L E] S . .
[T H E . T I T L] E S .

and you would also control the number of bounces before it goes out. what do you guys think?

enjoy, and let me know how it goes

DarthTater · 04-19-2006, 07:52 PM

That kicks ***, Sama. I should have a chance to test it tomorrow! I'll let you know how it goes.

sama · 04-20-2006, 02:37 PM

I can confirm this works. I just tested it with FF as a target and both my MID and OBC cluster showed the message. The MID only shows 11 charachters while the OBC shows 19 or 20 (I just counted it but can't remmeber!)

The scroll speed setting also works as does the wrap true/false

however! there's a bug that you can't scroll more than 27 charachters! The reason being (I think) that the ibus packet is limited in size to 32 charachters

68 XX 80 DATA CC
That's 1 + 1 + 1 + 27 + 1 = 31 bytes - which kinda makes sense. So I'll be limiting the strings being sent to 27chars soon and see if that fixes it.

I still can't get rid of this frigging foreground forcing loop thing. it's really ****ing me off now! I've turned off the flags etc. It doesn't happen in the original so I think I'll diff the versions, and start to slowly add the changes to see what's causing it. hell I'm gonna install VB on my carputer till I find out what's doing it

sama · 04-20-2006, 05:54 PM

sorry guys, I'm talking to my self here. But here's an updated version that works with any length message, and here's an mp4 video to prove it

DarthTater · 04-20-2006, 09:06 PM

Great job, sama. I just tested it and works almost perfectly. The only problem I came across was if you have a track name that is currently being scrolled and then change to a track that is shorter than the minimum scroll length, it will quickly flash the short track, but then continue scrolling the previous track. Something simple to exit the sub on the track change should fix it. Excellent work, though!

sama · 04-21-2006, 01:54 AM

Thanks darth. here's a fixed version.

I'll work on bouncing the string next.

I've just had another thought. since we can have 20 charachters, how about this:

Code:


|<------ scrolling track name --------->|     2  1  :  2  3 
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20

That can be the track remaining time. this would hog the display, but if the code listens for any displayable messages and stops displaying for say 10 seconds when it sees one, then resumes, that should allow the other message to be seen on the display. We may have to resend the message in cases where the trackname was sent just before the other message was received.

I was also thinking for users that have both the MID and high cluster, independant messages can be sent to both.

what do you think?

I've seen a post on hacktheibus that there's a message sent when reverse is selected. this is used to tell the passenger mirror to go down. I wanted to know if this is for both manuals and autos. I don't see why it shoudln't work for both but just wanted to check. what's ur transmittion? mine's an auto (sadly)

DarthTater · 04-21-2006, 05:12 PM

Mine's a standard. That might be a good way to implement a reverse camera. I'll try to do some ibus event logging tonight. There's a couple other messages I need to sort out to get my screen switching perfect, anyway.

I think the independent message thing would be cool - then you could set two different scroll lengths! The scroll timers would probably need to be a little offset so that the bus doesn't get too crowded, though.

*** edit: see version 1.[1].89 a couple posts down - this one had a problem!!! sorry.
Here's my addition to your 1[1].87 code.

I've enabled a crude version of hardware contention management in the ClearToSend sub. If you've set ContentionManagement to modes 3, 4, or 5 in the .ini, then the ClearToSend sub will check to see if there is traffic on the bus before returning a true value. Test your interface to see which line(s) are available to monitor. DSR, CTS, or CD = high, then the bus is clear. If low, then there is traffic. Not quite a full hardware handshake, but better than just the software method.

sama · 04-21-2006, 05:19 PM

interesting. which ibus adaptor do u use? I got the one from eedesignkits or similar.

DarthTater · 04-21-2006, 05:35 PM

It probably won't work for you then. I originally bought mine from eedesignkits because it was the only USB solution at the time. Those clowns have taken the SEN/STA pin on the Melexis chip and grounded it. This forces the Tx line open and shuts off any bit comparison between the Tx line and the iBus - ie. no hardware collision detection and no method to monitor the bus activity. I've since switched to Rolf Resler's V5 USB version. It will allow you to monitor the DSR, CTS, or CD lines. I used a handy little program called COM Port Toolkit 3.6 to test both interfaces. Try it on the eekit and you'll see what I'm talking about - the status lines will all stay high no matter what kind of ibus activity is going on. They should take the 'hardware collision detection' bullet off their site, it's simply not true.

sama · 04-21-2006, 06:48 PM

oh dear... wish I knew that then!

but I guess I'm doing alright for now. if it poses too big a problem, I'll sell this or eat it or something

DarthTater · 04-22-2006, 07:54 PM

Sorry guys, that last version was a turd. I put it together and didn't test it in the car first. I screwed up how I was handling the select case for the contention management. Here's a corrected version, I've removed the other one.