Need help testing new mobile logger.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I've downloaded Embedded Visual Basic (full version is free from Microsoft, old now, but so is my Pocket PC 2002). I quite like its simplicity, and it seems OK to use after playing with VB Express 2005 with patches to Mitsubishilogger.
Since my fabrication skills are dodgy with microcontrollers, especially in making it look nice in a box with display etc, and since the Pocket PC has a user interface already and a nice screen, I propose to use it as the front end of my in-car project.
So there will be three hardware parts in the chain: VAG COM RS232 cable, AVR baud rate converter, Pocket PC to serial cable.
The VAG COM RS232 cable is DCE, the Pocket PC serial cable will also be DCE since it is an Active Sync cable designed to connect to a desktop PC. So I need to run 2 UARTS on the AVR which are setup as DTE, and if plugging it all together they need to be DB9 male ports. So the AVR is behaving like a desktop PC, master if you like, the car ECU and the Pocket PC are behaving like slaves.
This is a page on the port of my device (HTC Wallaby, marketed as O2 XDA in the UK).
http://wiki.xda-developers.com/index...ame=Connectors
Since my fabrication skills are dodgy with microcontrollers, especially in making it look nice in a box with display etc, and since the Pocket PC has a user interface already and a nice screen, I propose to use it as the front end of my in-car project.
So there will be three hardware parts in the chain: VAG COM RS232 cable, AVR baud rate converter, Pocket PC to serial cable.
The VAG COM RS232 cable is DCE, the Pocket PC serial cable will also be DCE since it is an Active Sync cable designed to connect to a desktop PC. So I need to run 2 UARTS on the AVR which are setup as DTE, and if plugging it all together they need to be DB9 male ports. So the AVR is behaving like a desktop PC, master if you like, the car ECU and the Pocket PC are behaving like slaves.
This is a page on the port of my device (HTC Wallaby, marketed as O2 XDA in the UK).
http://wiki.xda-developers.com/index...ame=Connectors
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
A huge find in my cables box!!!
When I bought my XDA the previous owner also had a TomTom GPS, and had it linked to the XDA, he kept the GPS but included the cradle.
This cradle has a connection to 12V to allow the XDA to be charged. It then has a 4 pin RJ45 socket that just so happens to have:
RS232 Tx
RS232 Rx
5.17V
Ground
This is just what I need to send to my AVR unit. I cannot believe this stroke of luck.
When I bought my XDA the previous owner also had a TomTom GPS, and had it linked to the XDA, he kept the GPS but included the cradle.
This cradle has a connection to 12V to allow the XDA to be charged. It then has a 4 pin RJ45 socket that just so happens to have:
RS232 Tx
RS232 Rx
5.17V
Ground
This is just what I need to send to my AVR unit. I cannot believe this stroke of luck.
Depending on what Hamish already has running and on what devices, I had another idea.
What about using an Atmel AVR microcontroller to interface the MUT 15625 baud to 9600 baud that a Pocket PC (or almost any terminal device) could use directly? Sort of like an Elm chip, but for MUT, and running at full speed (9600 would keep up given the actual transfer rate would only use a third of that speed). Unlike the Elm chips we wouldn't have ASCII conversions of the data and the low speed of OBD II. The AVR hardware UART(s) can do the baud rates required and sent the init commands as well as talk to the Pocket PC.
Reducing the hardware to the absolute minimum, an AVR Tiny13 might do it, using two software UARTs and its internal RC oscillator (may have baud rate creep so might need a crystal), and could power it off the ECU's 5V supply to remove the need for a regulator. The only external components would be to convert between the TTL of the AVR and the 12V of the K-line. Going from the K line to the AVR would simply need a resistor and a shunt diode to 5V, or a pair of resistors as JoeBee did it. Going from the AVR to the K-line would possibly need a transistor and two resistors - the software UART can invert, or we could possibly use a PNP resistor to avoid inverting the signal?
It is a bit of a workaround, but might open up simple comms with many more devices. The Atmel software would be fairly simple, and the Pocket PC side would be simply to send request ID at 9600 8N1 and receive reply.
It might be that a ready made board with a higher spec microcontroller is more economical since it will be all done for us, these things are very cheap, especially compared with a new Pocket PC and faffing about with limited USB functionality. It is just whether many Pocket PCs bring out their serial lines, my old XDA does and a serial cable is available for activesync use. I think they all have terminal emulation software to do simple tests.
What about using an Atmel AVR microcontroller to interface the MUT 15625 baud to 9600 baud that a Pocket PC (or almost any terminal device) could use directly? Sort of like an Elm chip, but for MUT, and running at full speed (9600 would keep up given the actual transfer rate would only use a third of that speed). Unlike the Elm chips we wouldn't have ASCII conversions of the data and the low speed of OBD II. The AVR hardware UART(s) can do the baud rates required and sent the init commands as well as talk to the Pocket PC.
Reducing the hardware to the absolute minimum, an AVR Tiny13 might do it, using two software UARTs and its internal RC oscillator (may have baud rate creep so might need a crystal), and could power it off the ECU's 5V supply to remove the need for a regulator. The only external components would be to convert between the TTL of the AVR and the 12V of the K-line. Going from the K line to the AVR would simply need a resistor and a shunt diode to 5V, or a pair of resistors as JoeBee did it. Going from the AVR to the K-line would possibly need a transistor and two resistors - the software UART can invert, or we could possibly use a PNP resistor to avoid inverting the signal?
It is a bit of a workaround, but might open up simple comms with many more devices. The Atmel software would be fairly simple, and the Pocket PC side would be simply to send request ID at 9600 8N1 and receive reply.
It might be that a ready made board with a higher spec microcontroller is more economical since it will be all done for us, these things are very cheap, especially compared with a new Pocket PC and faffing about with limited USB functionality. It is just whether many Pocket PCs bring out their serial lines, my old XDA does and a serial cable is available for activesync use. I think they all have terminal emulation software to do simple tests.
I have also developed some circuits that do PWM/OBDII/MUT/OBDI/KWP/CAN all on the same plug.
I can only spare about 1 or 2 hours per week to this project, but everytime I do I seem to gain knowledge 10 fold on this stuff.
If you want to help out this project.. post here all the different microcontroller chips/lcds/sd/bluetooth chips that look awesome and cheap.
Last edited by evo4mad; Jun 9, 2007 at 02:00 AM.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I'm not up on the Bluetooth stuff, but I have a Blackberry that has it, but I don't know Java, and you have to pay $100 to RIM to get the Bluetooth programming stuff.
I like the AVR microcontrollers a lot since I am familiar with them and have various boards knocking about and my beloved BASCOM AVR that is so easy to write but compiles to really compact and fast code. There are various Bluetooth add ons, maybe even an integrated all in one board.
Presently I have two ways I can go with my Pocket PC2002 which I have the serial wiring ready to hopefully today wtih the cradle I found.
1. Simply get the ECU to talk at 9600 or 19200 and wire my KKL RS232 cable to the Pocket PC, writing logging software in eVB 3.0. eVB can do break signals it seems and I have a SD slot, 320*240 4096 colour touchscreen display, used Pocket PC 2002 are very cheap. This does mean it can only be used by those who can flash their ECUs, and that we need to add logic to the ECU to switch from 15625 to other baud rates to keep compatibility with factory tools.
or
2. Use one of my Atmel boards to make a baud rate interface 15625 to 9600 or 19200. It would use RS232 inputs and outputs as that is easy, but a Bluetooth add on could be used for Bluetooth devices. Any terminal device could protentially be used if the code was put in the Atmel to print out ASCII stuff - ie live data, peaks etc. If the terminal device could be sent a clear screen command then a text based logging screen could be built up. Better to use a Pocket PC though that can do the graphing etc. My old Pocket PC is as powerful as my old laptop that I was using until 6 months ago for all my car stuff! It ran ECUflash, Evoscan, Mitsubishilogger no problems, although the logging speed was half speed if also displaying data on the screen.
If you have any Pocket PC 2002 code (eVB 3.0 if possible as I don't have Visual Studio 2003 or 2005) that would do MUT logging at 9600 or 19200 baud including the break signal init please let me know. If not I hope to have a simple logger going soon that just displays the 8 items I was logging with my Atmel/LCD board based on JoeBee's project. Even that would be quite useful in car, and it would be fairly easy to show lowest octane, highest knock, highest boost, highest temperatures etc.
I like the AVR microcontrollers a lot since I am familiar with them and have various boards knocking about and my beloved BASCOM AVR that is so easy to write but compiles to really compact and fast code. There are various Bluetooth add ons, maybe even an integrated all in one board.
Presently I have two ways I can go with my Pocket PC2002 which I have the serial wiring ready to hopefully today wtih the cradle I found.
1. Simply get the ECU to talk at 9600 or 19200 and wire my KKL RS232 cable to the Pocket PC, writing logging software in eVB 3.0. eVB can do break signals it seems and I have a SD slot, 320*240 4096 colour touchscreen display, used Pocket PC 2002 are very cheap. This does mean it can only be used by those who can flash their ECUs, and that we need to add logic to the ECU to switch from 15625 to other baud rates to keep compatibility with factory tools.
or
2. Use one of my Atmel boards to make a baud rate interface 15625 to 9600 or 19200. It would use RS232 inputs and outputs as that is easy, but a Bluetooth add on could be used for Bluetooth devices. Any terminal device could protentially be used if the code was put in the Atmel to print out ASCII stuff - ie live data, peaks etc. If the terminal device could be sent a clear screen command then a text based logging screen could be built up. Better to use a Pocket PC though that can do the graphing etc. My old Pocket PC is as powerful as my old laptop that I was using until 6 months ago for all my car stuff! It ran ECUflash, Evoscan, Mitsubishilogger no problems, although the logging speed was half speed if also displaying data on the screen.
If you have any Pocket PC 2002 code (eVB 3.0 if possible as I don't have Visual Studio 2003 or 2005) that would do MUT logging at 9600 or 19200 baud including the break signal init please let me know. If not I hope to have a simple logger going soon that just displays the 8 items I was logging with my Atmel/LCD board based on JoeBee's project. Even that would be quite useful in car, and it would be fairly easy to show lowest octane, highest knock, highest boost, highest temperatures etc.
Last edited by jcsbanks; Jun 9, 2007 at 04:00 AM.
unfortunately sorry i dont have any RS232 serial code for PocketPC2002.
what about easy and cheap kits for everyone else? how much does an Atmel chip cost? how much for the lcd interface? do you know any chip models with built in bluetooth? how much for an AVR Tiny13 chip?
what about easy and cheap kits for everyone else? how much does an Atmel chip cost? how much for the lcd interface? do you know any chip models with built in bluetooth? how much for an AVR Tiny13 chip?
I have 3 of model PocketPC2003, it only has a 4 pin usb (OTG type usb plug) and it uses Intel PXA272 as its microprocessor.
Speed: 416Mhz
Flash chip type: 28F256L18
Data Bus: 32bits
LCD: 240 x 320 TFT (16536 colors)
Damn you're right, look at that power! 416Mhz!
but these things are still too expensive for the hobbyiest, better to buy a cheaper microcontroller and cheap lcd panel.
consider this: you can buy a full on MP3/Mpeg4 player with color lcd for under $200, the pocketpc phones go for between $400-$600
Still I'm gonna build both hopefully.
Speed: 416Mhz
Flash chip type: 28F256L18
Data Bus: 32bits
LCD: 240 x 320 TFT (16536 colors)
Damn you're right, look at that power! 416Mhz!
but these things are still too expensive for the hobbyiest, better to buy a cheaper microcontroller and cheap lcd panel.
consider this: you can buy a full on MP3/Mpeg4 player with color lcd for under $200, the pocketpc phones go for between $400-$600
Still I'm gonna build both hopefully.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
Atmel chips are anything from $2 to $20 I think. There are nice $100 boards with colour displays. However, used old Pocket PCs can be bought for this, and are much more powerful $ for $.
Most of these old Pocket PCs can connect to GPS units, it seems the most popular are simple serial devices. So with a simple connector you have a serial port.
Most of these old Pocket PCs can connect to GPS units, it seems the most popular are simple serial devices. So with a simple connector you have a serial port.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
Success: Pocket PC 2002 talking to the ECU at 19200 baud (changed the ECU baud rate to 19230, close enough). I cheated because I let Evoscan init the ECU at 19200 and then quickly swapped the cables over so I could use the terminal emulator on the Pocket PC to talk to the ECU. It does work with the usual echo and response, and although it was as ASCII characters the responses were correct where it was a displayable ASCII character.
Now I just need to get cracking with some code, sending 1800ms break signal in eVB 3.0 from the Pocket PC, 200ms wait then FEFFFEFF.
Re the hardware: VAG COM KKL RS232 cable (DCE), male-male null modem cable (allows the two DCE devices to talk to each other), female DB9 plug to RJ11 cable (DCE) to plug into the Pocket PC cradle. Since I have the female DB9 to RJ11 cable wired as DCE, the DB9 can also be plugged into a PC for serial comms, although it doesn't do activesync as I only wired Tx, Rx and ground.
I'm learning a lot about RS232 LOL
Now I just need to get cracking with some code, sending 1800ms break signal in eVB 3.0 from the Pocket PC, 200ms wait then FEFFFEFF.
Re the hardware: VAG COM KKL RS232 cable (DCE), male-male null modem cable (allows the two DCE devices to talk to each other), female DB9 plug to RJ11 cable (DCE) to plug into the Pocket PC cradle. Since I have the female DB9 to RJ11 cable wired as DCE, the DB9 can also be plugged into a PC for serial comms, although it doesn't do activesync as I only wired Tx, Rx and ground.
I'm learning a lot about RS232 LOL
Last edited by jcsbanks; Jun 9, 2007 at 02:13 PM.
I dont have a dang clue what you guys are talking about, but I like where yall are headed. I hope to soon be able to log and switch maps with a pocket pc/someday blackberry. Heck maybe even an Ipod!!! lol Good luck guys with this project!!!!!
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I'm having trouble sending break signals in Embedded visual basic 3.0 for the Pocket PC 2002. Whether I have the port open or not, the break signal true or false makes no difference to the voltage on the line. If I turn the comm port on or off I can create a break signal on the multimeter, but the car doesn't respond to it, maybe it isn't a clean break when the serial port is closed and then reopened?
I can connect with the Pocket PC if I get my Atmel board to send the 1800ms break signal first and then swap the plugs over! The ECU is very tolerant about the timing of the FE FF FE FF stuff. The timers on the Pocket PC seem accurate too.
I'm wondering whether to use a 3rd party comm control...
I can connect with the Pocket PC if I get my Atmel board to send the 1800ms break signal first and then swap the plugs over! The ECU is very tolerant about the timing of the FE FF FE FF stuff. The timers on the Pocket PC seem accurate too.
I'm wondering whether to use a 3rd party comm control...
There are some advanced parameters for the comm port component in eVB, you can also find/write an RS232 module that directly controls the port instead of using the mscomm components.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
Thanks, I've been looking for documentation with no success. Google isn't finding anything, and the help isn't suggesting anything further about break signals.
The 3rd party stuff looks very complex, I'm nearly there, just need a break signal.
Do you know of any info that would help?
The 3rd party stuff looks very complex, I'm nearly there, just need a break signal.
Do you know of any info that would help?
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
I used one of the libraries, but the break only works on that after you have sent a single character after opening the port. It turns out that the original Comm control does the same, so this is a workaround.
Evolved Member
Joined: May 2006
Posts: 2,399
Likes: 6
From: UK
Now the Pocket PC is connecting and MUT logging under its own steam. The init procedure and connection appear robust
Just 18 lines of code so far and no dll hell
No external libraries or fancy runtimes needed.
Just 18 lines of code so far and no dll hell
No external libraries or fancy runtimes needed.
