Electrical For discussions regarding wiring up electrical modifications such as radar detectors, brake light mods, power sockets, and driving lights in Cooper (R50), Cabrio (R52), and Cooper S (R53) MINIs.

Electrical Getting more out of the R53 MFSW

Thread Tools
 
Search this Thread
 
  #26  
Old 10-01-2008, 02:05 PM
GBMINI's Avatar
GBMINI
GBMINI is offline
6th Gear
Join Date: May 2002
Location: Gloucester, MA, USA
Posts: 3,433
Likes: 0
Received 1 Like on 1 Post
You're exactly correct about OUT10...13 and the V1 signals.

The only issue is if the controlled device has switch signals which are not pulled to ground to trigger - but then only if the device is also connected to the car wiring (eg to power it). In that case, you'd need relays, but otherwise the "open collector" output you have is perfectly fine.
 
  #27  
Old 10-01-2008, 04:48 PM
DaveC's Avatar
DaveC
DaveC is offline
2nd Gear
Thread Starter
iTrader: (2)
Join Date: Oct 2004
Posts: 107
Likes: 0
Received 0 Likes on 0 Posts
Ian, thanks for taking the time to go over the circuit and the finer points of this stuff.

Originally Posted by GBMINI
You're exactly correct about OUT10...13 and the V1 signals.
Whew, I was worried for a second that I was gonna blow something up...

Great, I'll keep it that way for the V1 signal. Actually now that you've pointed this out, it dawns on me that in this case, since Out is tied to the V1's GND which is the same as the car's GND...I guess I was doing it right, though not due to any actual skill on my part

Trial and error got me to a working solution (it didn't work when hooked up the other way), but it's nice to have an explanation for why things are.

Originally Posted by GBMINI
The only issue is if the controlled device has switch signals which are not pulled to ground to trigger - but then only if the device is also connected to the car wiring (eg to power it). In that case, you'd need relays, but otherwise the "open collector" output you have is perfectly fine.
I'll have to run a meter on the leads from the iPod connector (which does share power/ground with the car) as they seem to work as hooked up no matter which wires I matched to the collector or emitter. Orientation doesn't seem to matter at all. Might just be a fluke. I left some room at the top right of my board for additional stuff like relays so I have room to throw some on if needed.

Yet another reason why I personally wasn't about to go commercial and sell these circuits...I know the design works for me, but haven't the expertise to make sure it is a generalized/safe/foolproof enough solution to actually sell.

BTW, I don't know if you've delved into coding for the Arduino (truthfully, I'm a better coder than a hardware guy) yet but it's pretty darned easy to write code for and quite nice. Certainly easier than writing for the AVR or some other PIC in Assembly. I'll post my code once I've had a chance to proof it/comment it and do some slight tweaks/optimizations on it.

Thanks again,

Dave
 
  #28  
Old 10-01-2008, 05:00 PM
GBMINI's Avatar
GBMINI
GBMINI is offline
6th Gear
Join Date: May 2002
Location: Gloucester, MA, USA
Posts: 3,433
Likes: 0
Received 1 Like on 1 Post
Hadn't heard of Arduino before - I guess since I tend to "roll my own" as it were! Just took a quick peek, looks pretty neat; the language is interesting, a sort of Basic / C cross. I created a similar language back in 1995(!) to run our company test rigs.

And I agree about PIC assembler, it's a pain - I use C for that processor family (but I can still code direct to HEX for the 6502!)
The HKenabler and iBus remote are in HC908 assembler, just because I did my initial development on such a board (history on GBMINI.net)

I look forward to seeing where you take this project, next
 
  #29  
Old 10-01-2008, 05:31 PM
BlimeyCabrio's Avatar
BlimeyCabrio
BlimeyCabrio is offline
6th Gear
iTrader: (5)
Join Date: Sep 2006
Location: Holly Springs, NC
Posts: 8,773
Likes: 0
Received 9 Likes on 7 Posts
Ian, you're a geek.

Just in case you didn't know.

Takes one to know one.
 
  #30  
Old 10-02-2008, 01:04 AM
DaveC's Avatar
DaveC
DaveC is offline
2nd Gear
Thread Starter
iTrader: (2)
Join Date: Oct 2004
Posts: 107
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by GBMINI
And I agree about PIC assembler, it's a pain - I use C for that processor family (but I can still code direct to HEX for the 6502!)
Oh man, that brings back memories of my geek days from high school. I remember that I couldn't afford to buy an Assembler Software for the Apple II, but you could just enter "CALL -151", enter your opcodes (I think I had like 50% of the opcodes for the 6502 instruction set committed to memory) in Hex by hand and run your program right then and there, no compiling, no linking, nada...oh those were the days.

That's OK Ian, I'm geeking out big time, right with you.

Dave
 
  #31  
Old 10-03-2008, 03:37 PM
DaveC's Avatar
DaveC
DaveC is offline
2nd Gear
Thread Starter
iTrader: (2)
Join Date: Oct 2004
Posts: 107
Likes: 0
Received 0 Likes on 0 Posts
Program Code for the IBUS-Arduino circuit

They call programs for the Arduino's "Sketches". Go to www.Arduino.cc to download the free development environment (a C like language, has versions that will run on Windows, OS X and Linux). It's not quite as powerful as programming in AVR assembly, but MUCH easier with lots of external libraries to expand the AVR's capabilities w/o you having to re-invent the wheel and write the code yourself (ie. Math Libraries, I2C serial communications, LCD Displays, Servo Controllers, etc).

Here is a basic sketch that listens for the Tel button and the R/T button to be pushed and will control 2 external devices based on which buttons are pushed.

As it is written, it's not a particularly elegant algorithm and there are some problems with occasionally missed commands and slow response if too many button pushes are stacked up in a row, but it works.

I have a a newer version that is much more elegant, responsive and flexible that I'm still debugging/testing but ultimately I want to write a version that will use interrupts so that no button pushes will ever be missed and multiple complex sequences of commands for the outputs can be executed w/o any dropped incoming IBUS data/commands.

Anyways, this may be a good start for DIY'ers to play with and for experimenting.

Dave

*/
IBUS-Arduino Driver v1

Copyright 2008 David Chen (JCW@DaveChen.org) All Rights Reserved
Released under the Creative Commons Attribution Non-Commercial Use License
http://creativecommons.org/licenses/by-nc/3.0/

*/

//main serial Rx pin switched via NPN transistor, this pin is connected to the base of the transistor
//serial Rx port is effectively blocked until activateSerialPin is set to high
//serial data from IBUS interface will keep Arduino from fully starting up otherwise
#define activateSerialPin 2

//this version switches 2 devices, a Radar Detector Mute and a 2 button Garage Door opener
#define garage1Pin 10
#define garage2Pin 11
#define radarmutePin 12


//diagnostic LED light, strobes while getting data and stays lit during matches
#define ledPin 13

//Initialize the Output Pins and the Serial communications with the IBUS Module
void setup() {
pinMode(garage1Pin, OUTPUT);
pinMode(garage2Pin, OUTPUT);
pinMode(activateSerialPin, OUTPUT);

pinMode(ledPin, OUTPUT); //we'll use the debug LED to output a heartbeat

//start recieving Serial Data
Serial.begin(9600);
digitalWrite(activateSerialPin, HIGH);
}

//Main Program Loop
void loop() {
char incomingByte;
char sequenceBytes[4];

// Look to see if there is any IBUS data to process
if (Serial.available() > 0) {
digitalWrite(ledPin, HIGH); //light the debug LED
// read the incoming byte:

incomingByte = Serial.read();

//check if the incoming byte fits our desired patterns
if ((incomingByte == 80) || (incomingByte == -48)) {
lcd.cursorTo(2,0); //Show Match result on right half of the screen
//grab the next 5 bytes
if (Serial.available() > 0) {
sequenceBytes[0] = Serial.read();
}
if (Serial.available() > 0) {
sequenceBytes[1] = Serial.read();
}
if (Serial.available() > 0) {
sequenceBytes[2] = Serial.read();
}
if (Serial.available() > 0) {
sequenceBytes[3] = Serial.read();
}
if (Serial.available() > 0) {
sequenceBytes[4] = Serial.read();
}

if(sequenceBytes[0] == 4) {
switch (sequenceBytes[3]) {
case 16:
// Vol Down
break;
case 17:
// Vol Up
break;
case 1:
// Right
break;
case 8:
// Left
break;
case 0x80:
//Tel button
// Garage 1 button pushed
digitalWrite(garage1Pin, HIGH);
delay(1000);
digitalWrite(garage1Pin, LOW);
break;
case -112:
// Tel Hold
break;
}
}
else if ((sequenceBytes[0] == 3) && (sequenceBytes[2] ==1)) {
// R/T button
// V1Mute and Garage 2
digitalWrite(radarmutePin, HIGH);
digitalWrite(garage2Pin, HIGH);
delay(500);
digitalWrite(radarmutePin, LOW);
delay(500);
digitalWrite(garage2Pin, LOW);
}
}

}
digitalWrite(ledPin, LOW);
} //end loop
 

Last edited by DaveC; 10-03-2008 at 05:39 PM.
  #32  
Old 07-09-2009, 12:00 PM
Maarten CH's Avatar
Maarten CH
Maarten CH is offline
Neutral
Join Date: Jul 2009
Posts: 6
Likes: 0
Received 0 Likes on 0 Posts
Thanks for posting this interesting stuff. I am searching for something to use the MFSW buttons to control my 2nd gen Ipod touch.

I found a lot about the Arduino but I still have several questions

Can you explain (in easy words) what the Resler Ibus interface is doing? It is reading the Ibus commands but what type of signal (digital?) is coming out? And what is then read by the Arduino?

It would be great if you can give a link/document with more info about the Resler

Many thanks!
Maarten
 
  #33  
Old 07-10-2009, 12:29 AM
DaveC's Avatar
DaveC
DaveC is offline
2nd Gear
Thread Starter
iTrader: (2)
Join Date: Oct 2004
Posts: 107
Likes: 0
Received 0 Likes on 0 Posts
The Resler I-Bus module is doing the actual interfacing with the actual I-Bus and monitoring/spitting out serial data of what is flowing across the I-Bus.

The Arduino reads the serial data from the I-Bus and looks for strings of data that matches the 5-6 byte pattern that corresponds to a particular event (ie. a MFSW Button push) and then acts on it (ie. closes a switch or relay).

Dave
 
  #34  
Old 07-10-2009, 12:39 AM
DaveC's Avatar
DaveC
DaveC is offline
2nd Gear
Thread Starter
iTrader: (2)
Join Date: Oct 2004
Posts: 107
Likes: 0
Received 0 Likes on 0 Posts
Info on the Reslers I-Bus interface can be found here: http://reslers.de/IBUS/index.html

I had gotten around to making a custom circuit board (picture of the board below) that used the Melixis chip directly (thus didn't need the Reslers I-Bus interface) with an Arduino Nano on board, but alas, I'm a bit of an amateur and it isn't working as expected (no I-Bus serial data coming out at all). Not sure what the problem is, but I can post the schematic/design if someone wants to help me trouble shoot it and sort it out.

Basically, I know just a bit about digital electronics and a little more about coding the software. I took bits and pieces of Rolf Reslers and other folk's designs (from the Arduino web site tutorials) to make this board, had to teach myself how to use Eagle to design a board and submitted a design to get made. It was fun, but very time consuming.

Actually, I haven't worked on this stuff in a few months, I was figuring out stuff by trial and error on my own time and have hit a bit of an impasse. If there are others out there who'd be interested in collaborating be more than happy to share what I've figured out already to see if improvements can be made in the design.

Dave
 
Attached Thumbnails Getting more out of the R53 MFSW-arduino-i-bus-v3.2.jpg  

Last edited by DaveC; 07-10-2009 at 01:03 AM.
  #35  
Old 07-10-2009, 02:25 AM
AKIndiMini's Avatar
AKIndiMini
AKIndiMini is offline
OVERDRIVE
iTrader: (2)
Join Date: Oct 2006
Location: Kodiak, AK
Posts: 8,011
Received 2 Likes on 1 Post
Does anyone know if the 'extra button' on the 2-spoke MFSW sends an event to the I-Bus?

I kinda like my 2-spoke steering wheel and it would be great if I could make that extra button 'do' something, like open my garage door...
 
  #36  
Old 07-10-2009, 05:59 AM
Maarten CH's Avatar
Maarten CH
Maarten CH is offline
Neutral
Join Date: Jul 2009
Posts: 6
Likes: 0
Received 0 Likes on 0 Posts
So the Arduino can't read the Ibus itself and needs the Resler to do that.
Sounds ok but how did you figure out which pins from the serial output of the Resler to take?

I was thinking of taking the serial Resler (I think is easier to connect than the USB version) and connect it to the Arduino Duemilanove (http://arduino.cc/en/Main/ArduinoBoardDuemilanove).
Other/better ideas are
 
  #37  
Old 07-10-2009, 06:00 AM
GBMINI's Avatar
GBMINI
GBMINI is offline
6th Gear
Join Date: May 2002
Location: Gloucester, MA, USA
Posts: 3,433
Likes: 0
Received 1 Like on 1 Post
Yes, it does. This, for example, was triggered by the unused middle button:
http://www.gbmini.net/wp/2004/09/ano...dd-on_circuit/

And this earlier button brought out all the controls, for a friend to wire in to his iPod remote (in the days before easy iPod control was available in cars!)
http://www.gbmini.net/wp/2004/06/mor...ol_using_mfsw/
 
  #38  
Old 07-10-2009, 06:06 AM
GBMINI's Avatar
GBMINI
GBMINI is offline
6th Gear
Join Date: May 2002
Location: Gloucester, MA, USA
Posts: 3,433
Likes: 0
Received 1 Like on 1 Post
One other note ...
If you're doing READ ONLY iBus monitoring (ie: don't need to send messages out), you really need nothing more than a resistor (and maybe a transistor) to interface between the iBus and a processor - the circuit pictured top of this page has just a resistor (and smart programming); the transistor is there to drive the relay output, not to interface to iBus.
 
  #39  
Old 07-10-2009, 12:33 PM
AKIndiMini's Avatar
AKIndiMini
AKIndiMini is offline
OVERDRIVE
iTrader: (2)
Join Date: Oct 2006
Location: Kodiak, AK
Posts: 8,011
Received 2 Likes on 1 Post
Originally Posted by GBMINI
Finally, if there was enough interest in this, I might be able to produce a circuit that connected to iBus and brought transistor outputs to mimic the switches, for certainly less than the $90 price you needed to pay for your parts - but there would need to be more than a couple of people needing it, to bring the price down. Not that I'm wanting to steal anything, it's just that I've done it before ...
Ian - I'm most definitely interested in this. Hopefully others will be too. Thanks!
 
  #40  
Old 08-02-2009, 11:45 AM
Maarten CH's Avatar
Maarten CH
Maarten CH is offline
Neutral
Join Date: Jul 2009
Posts: 6
Likes: 0
Received 0 Likes on 0 Posts
Inspired by the nice example from Dave I started a project as well. I have an Arduino and the Resler interface should come in the next few days


In post #9 you wrote that you used Rx (pin 9), Tx (pin 10) and CTS (pin 11) from the Resler interface. Is it correct that these are pin 2, 3 & 8 at the serial connector? Some time ago you posted the code you wrote for the Arduino. Do you have a more resent version where you also send data?


I will keep you updated about my progress and maybe there are still some questions to come.

Cheers,
Maarten
 
  #41  
Old 08-07-2009, 03:31 AM
DaveC's Avatar
DaveC
DaveC is offline
2nd Gear
Thread Starter
iTrader: (2)
Join Date: Oct 2004
Posts: 107
Likes: 0
Received 0 Likes on 0 Posts
> In post #9 you wrote that you used Rx (pin 9), Tx (pin 10) and CTS (pin 11) from the Resler interface. Is it correct that these are pin 2, 3 & 8 at the serial connector?

Yes, the pins 9, 10, 11 are TTL signals that I intercept to send to the Arduino BEFORE they pass through the serial comm chip (MAX232) which puts out a Serial signal at pins 2, 3 and 6/8. The Serial signals are different enough (different Line Levels and voltages) that I didn't try to interface them to the Arduino who's serial pins read TTL signals.

> Some time ago you posted the code you wrote for the Arduino. Do you have a more resent version where you also send data?

I haven't gotten around to sending data across the I-BUS. I think what you need to do that is listen for pin 11 to go low to indicate that the I-BUS is clear for incoming signals before sending data/message over pin 10. Haven't messed with this but I was intending to do it at some point. If you can get it to work, I'd be interested to see how you did it and to see if the theory on how it is to be done (via information kindly provided by Rolf Resler) works.


> I will keep you updated about my progress and maybe there are still some questions to come.

That would be great, thanks for sharing your experiences. As I've said in the past, the project has been at a stand still for me as I've not had much time recently to mess with it.

I'm still trying to get an Arduino to work without the Resler interface (fewer components the better). Ian, I think you mentioned that you can interface with the I-Bus for data reading purposes w/o the Melixis/I-Bus interface circuitry. Would you mind sharing a schematic of how/what kind of resistor/transistor would be needed to do this?

Thanks all for taking an interest and sharing information,

Dave
 
  #42  
Old 08-07-2009, 03:47 AM
DaveC's Avatar
DaveC
DaveC is offline
2nd Gear
Thread Starter
iTrader: (2)
Join Date: Oct 2004
Posts: 107
Likes: 0
Received 0 Likes on 0 Posts
Improved Arduino Code for reading MFSW codes

This is the improved code I mentioned before for grabbing MFSW codes.

Rather than repetitive pattern matching for particular MFSW button push byte sequences, this newer version looks for the byte pattern "80" that is the start of the data stream that indicates a MFSW button push event.

The program then reads the next 3 bytes and calculates a checksum (a rather arbitrary calculation that creates an unique checksum for each button event, but since it is just addition/subtraction it is quite a fast calculation. I suppose I could have used XOR's and bit shifting, but this was quick and dirty).

A "case" command is used to implement the action required for each particular button push.

Code:
/* Match Patterns from the I-Bus/K-Bus for the MFSW Button Pushes Version 2
*/

/* Licensed for FREE use under Creative Commons Attribution-Noncommercial 3.0 United States License.

/*
 main serial Rx pin switched via NPN transistor, this pin is connected to the base of the transistor
 serial Rx port is effectively blocked until activateSerialPin is set to high
 serial data from IBUS interface will keep Arduino from fully starting up otherwise
*/
#define activateSerialPin 2
#define CTSSerialPin 3

#define ipodKeyPress 50    // hold the ipod control button for this many msec
#define fwdipodPin 10
#define playipodPin 11
#define revipodPin 12

#define radarKeyPress 100
#define radarmutePin 13

// Extra Pin Definitions - not hooked up to hardware but can be assigned as needed
#define freeKeyPress 0
#define freePin4  4
#define freePin5  5
#define freePin6  6
#define freePin7  7
#define freePin8  8
#define freePin9  9

void setup() {
  pinMode(activateSerialPin, OUTPUT);

  pinMode(fwdipodPin, OUTPUT);
  pinMode(playipodPin, OUTPUT);
  pinMode(revipodPin, OUTPUT);

  pinMode(radarmutePin, OUTPUT);

  //start recieving Serial Data
  Serial.begin(9600);
  digitalWrite(activateSerialPin, HIGH);  
}

void loop() {  
 char incomingByte, checkSum;
 
 // Process data only when you have some data in the buffer to work with
 if (Serial.available() > 0) {
   // read the incoming byte:   
   incomingByte = Serial.read();
   
/* Check if the incoming byte fits our desired patterns
 <Source> <Count> <Dest> <D2> <D3> ... <Dcount> <Xor checksum>
*/
   if (incomingByte == 80) {                            // First byte is a match for a Steering Wheel Button Push event
     do { } while (Serial.available() == 0);            // Make sure there is some data in the buffer
     incomingByte = Serial.read();                      // Grab the next byte
     // Looking for a message with 4 or 3 bytes
     if((incomingByte == 4) || (incomingByte == 3)) {
       do { } while (Serial.available() == 0);          // Get more data and calculate our own checSum = <Dest> + <D2> - <D3>
       checkSum = Serial.read();
       do { } while (Serial.available() == 0);
       checkSum += Serial.read();
       do { } while (Serial.available() == 0);
       checkSum -= Serial.read();
            
       switch (checkSum) {
         case 137:
           // Vol Up
           digitalWrite(freePin4, HIGH);
           delay(freeKeyPress);
           digitalWrite(freePin4, LOW);
           break;
           
         case 138:
           // Vol Down
           digitalWrite(freePin5, HIGH);
           delay(freeKeyPress);
           digitalWrite(freePin5, LOW);
           break;

         case 162:
           // Rt Down
           digitalWrite(fwdipodPin, HIGH);
           delay(ipodKeyPress);
           digitalWrite(fwdipodPin, LOW);
           break;
         case 130:
           // Rt Up
           break;
         case 146:
           // Rt Hold           
           digitalWrite(freePin6, HIGH);
           delay(freeKeyPress);
           digitalWrite(freePin6, LOW);
           break;

         case 155:
           // Lt Down
           digitalWrite(revipodPin, HIGH);
           delay(ipodKeyPress);
           digitalWrite(revipodPin, LOW);
           break;
         case 123:
           // Lt Up
           break;
         case 139:
           // Lt Hold
           digitalWrite(freePin7, HIGH);
           delay(freeKeyPress);
           digitalWrite(freePin7, LOW);
           break;

         case 131:
           // Tel Down
           digitalWrite(freePin8, HIGH);
           delay(freeKeyPress);
           digitalWrite(freePin8, LOW);
           break;
         case 99:
           // Tel Up
           digitalWrite(freePin9, HIGH);
           delay(freeKeyPress);
           digitalWrite(freePin9, LOW);
           break;
         case 115:
           // Tel Hold
           digitalWrite(playipodPin, HIGH);
           delay(ipodKeyPress);
           digitalWrite(playipodPin, LOW);
           break;

         case 47:
           // R/T
           digitalWrite(radarmutePin, HIGH);
           delay(radarKeyPress);
           digitalWrite(radarmutePin, LOW);
         break;
       }       
     }
   }
 }
} //end loop
There is an additional optimization that I want to implement at some point. Currently, the code uses a pre-defined delay between toggling the respective control pins high and low. A more elegant solution is to set a array element (corresponding to a particular output pin) to the Arduino's current time tick/counter value. A second check would run through the array and see when the current time tick/counter is greater than a defined value more than the array element's value and flip the pin's state. This way, the main loop isn't stuck in a delay command while waiting to toggle a pin state and the whole program will be (potentially) more responsive.

I'm sure my description is less than clear, this code example may be a better description of what I mean to do:
http://www.arduino.cc/en/Tutorial/BlinkWithoutDelay

Feel free to use and or improve the code and share at will. I'm not a trained programmer, just a hobbyist and I'm sure that someone out there can come up with much more elegant code.

Regards,

Dave
 
  #43  
Old 08-07-2009, 03:52 AM
DaveC's Avatar
DaveC
DaveC is offline
2nd Gear
Thread Starter
iTrader: (2)
Join Date: Oct 2004
Posts: 107
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by GBMINI
One other note ...
If you're doing READ ONLY iBus monitoring (ie: don't need to send messages out), you really need nothing more than a resistor (and maybe a transistor) to interface between the iBus and a processor - the circuit pictured top of this page has just a resistor (and smart programming); the transistor is there to drive the relay output, not to interface to iBus.
Ian, would you be willing to share a Schematic for how you'd interface w/o the I-Bus interface? What resistor/transistor values would you suggest.

It would be a great help, especially since you actually are an electronics expert and know what you're doing. I'm a bit of a hack/amateur at this and have been going at it via trial and error hoping not to fry anything important.

Thanks,

Dave
 
  #44  
Old 08-07-2009, 04:38 AM
BlimeyCabrio's Avatar
BlimeyCabrio
BlimeyCabrio is offline
6th Gear
iTrader: (5)
Join Date: Sep 2006
Location: Holly Springs, NC
Posts: 8,773
Likes: 0
Received 9 Likes on 7 Posts
I'd buy a preconfigured circuit that does this stuff in a heartbeat, if such a thing existed (anymore). I'm loving what y'all are doing - I just don't have the time or energy to DIY this anytime soon. So, Ian, put me on the list...
 
  #45  
Old 08-07-2009, 06:01 AM
GBMINI's Avatar
GBMINI
GBMINI is offline
6th Gear
Join Date: May 2002
Location: Gloucester, MA, USA
Posts: 3,433
Likes: 0
Received 1 Like on 1 Post
Dave,
The key is to be able to get the software working OK.

The "interface" to read iBus data is no more than a single resistor! Something like a 22K or 33K between the iBus and an input of the "PIC"
Although the iBus goes to 12V, the processor has built-in voltage limit diodes, so the "spare" voltage just drops across the resistor - and choosing a high value resistor limits the current so you don't hurt the input pin or the iBus itself.
I used 33K on my HKenabler circuits.

The key however, is that without any transistor interface, the iBus data is "upside down" at the processor. From my s/w comments:
... communicates with a Harmon Kardon amplifier across the MINI iBus, which is a serial bus running at 9600/E/8/1, using open-collector output to transmit.
The bus is non-inverted, high when idle with data beginning with a low start bit ...
If you use a built in "UART" (serial interface) electronics in the "PIC", it won't be able to decode the data.
So instead you need a software serial receive routine, which handles the "upside down" pin. That was easy on my project since I just wrote the code. I don't know if the Arduino offers that facility - though I bet it can.


Ian C.

Originally Posted by DaveC
Ian, would you be willing to share a Schematic for how you'd interface w/o the I-Bus interface? What resistor/transistor values would you suggest
 
  #46  
Old 08-07-2009, 08:29 AM
DaveC's Avatar
DaveC
DaveC is offline
2nd Gear
Thread Starter
iTrader: (2)
Join Date: Oct 2004
Posts: 107
Likes: 0
Received 0 Likes on 0 Posts
Ian, thanks for the info. Sounds like it's doable but for the Arduino as there is a "software serial" library/routine you could probably adapt to account for the signal inversion, but there is no buffering available via this method. Though ideally, it'd be nice to use one of the UART driven serial inputs as that way, there is some buffering of the serial data so no bytes/data are lost.

If I'm reading this right, it sounds like a 33K resistor to a Transistor or some other way to change the polarity of the signal (from 0<->Negative voltage to 0<->Positive voltage) is in order. Not sure if the term "Pull Up" circuit applies in this case. Any suggestions on hooking up a Transistor to accomplish this? Maybe something like this attached image? Not sure what appropriate Resistor values should be used to convert an inverted 12V serial signal to a 5V TTL signal (needed by the Arduino).

I think I'm in way over my head on this one.

Dave

Originally Posted by GBMINI
Dave,
The key is to be able to get the software working OK.

The "interface" to read iBus data is no more than a single resistor! Something like a 22K or 33K between the iBus and an input of the "PIC"
Although the iBus goes to 12V, the processor has built-in voltage limit diodes, so the "spare" voltage just drops across the resistor - and choosing a high value resistor limits the current so you don't hurt the input pin or the iBus itself.
I used 33K on my HKenabler circuits.

The key however, is that without any transistor interface, the iBus data is "upside down" at the processor. From my s/w comments:


If you use a built in "UART" (serial interface) electronics in the "PIC", it won't be able to decode the data.
So instead you need a software serial receive routine, which handles the "upside down" pin. That was easy on my project since I just wrote the code. I don't know if the Arduino offers that facility - though I bet it can.


Ian C.
 
Attached Thumbnails Getting more out of the R53 MFSW-trinvert.gif  

Last edited by DaveC; 08-07-2009 at 08:38 AM.
  #47  
Old 08-07-2009, 09:53 AM
GBMINI's Avatar
GBMINI
GBMINI is offline
6th Gear
Join Date: May 2002
Location: Gloucester, MA, USA
Posts: 3,433
Likes: 0
Received 1 Like on 1 Post
That attached schematic is a perfectly usable transistor inverter.
The input resistor could be 10K, the resistor above is fine at 1K, but going in to the "PIC" input another 10K would also be perfect.

The transistor wants to be any inexpensive NPN signal transistor; we use 2N4401 or similar, but basically if it's good gain and not slow, it'll work.
 
  #48  
Old 08-07-2009, 10:19 AM
jbkone's Avatar
jbkone
jbkone is offline
4th Gear
Join Date: Dec 2008
Location: Pensacola, FL
Posts: 373
Received 1 Like on 1 Post
I'm barely following... and only 50% of that! But fascinating! Keep it up.
 
  #49  
Old 08-08-2009, 07:15 PM
blalor's Avatar
blalor
blalor is offline
6th Gear
Join Date: Jan 2005
Location: RVA
Posts: 1,231
Likes: 0
Received 0 Likes on 0 Posts
Had a few minutes to kill tonight and Googling "arduino ibus" landed me here, via the arduino.cc forum. Arduino/IBus integration has been on my list for a while, now. I originally gave the MCAW guys a $100 deposit for that IBus interface circuit they were developing, and that didn't end well. I pretty much just want to do the same thing that Dave is doing: mute my V1, and also turn it off for a period of time (like when I'm in a shopping center and there's a new bogey popping up every 3 seconds). I've been into the Arduino for a while and have been working on some "smart home" stuff, but haven't gotten around to building the interface circuit for my MINI, yet. I also want to do some OBD2 datalogging with an ELM323…

Ian, if you're looking for another potential customer for a general-purpose IBus circuit, sign me up!
 
  #50  
Old 08-26-2009, 02:08 PM
Maarten CH's Avatar
Maarten CH
Maarten CH is offline
Neutral
Join Date: Jul 2009
Posts: 6
Likes: 0
Received 0 Likes on 0 Posts
Yes, the pins 9, 10, 11 are TTL signals that I intercept to send to the Arduino BEFORE they pass through the serial comm chip (MAX232) which puts out a Serial signal at pins 2, 3 and 6/8. The Serial signals are different enough (different Line Levels and voltages) that I didn't try to interface them to the Arduino who's serial pins read TTL signals.
Thanks for the info! I will go for that as well.

Here is a small update:

Last weekend I soldered the cables to the connector in the back of the radio (no CD changer connector to use ) and the Reslers IBus interface is working with my laptop. It can read and send data to the Ibus. It didn't work with the Arduino so far but I will give it another try soon.

However, my goal is to control my Ipod touch in it's IR controlled docking station (that needs to be build in the car) and I made some progress on this side . I decoded the Apple IR remote and can send all the commands with the Arduino using just a single IR LED. With this solution the docking station can be used in the trunk or glove box and I don't have to open/kill the original remote. I can post the codes if someone is interested.

I hope to solve the last issues this weekend
 


Quick Reply: Electrical Getting more out of the R53 MFSW



All times are GMT -7. The time now is 09:57 PM.