Pocket PC logging now working
Jun 22, 2007, 09:53 AM
#76
Evolved Member
Thread Starter
Here is the latest version:
COM1 19200baud
Live graphing of octane, knock, MAT, IAT, MAP, TPS
Live scatter plot of knock vs RPM - red if TPS=100, blue if >90, green otherwise
Logging to SD card in .csv format
Setup for 240*320 display
Temps in Celcius, pressures in kPa
MAT,MAP are Evo IX JDM/UK calibration, will return junk values on US models
Tested on Pocket PC 2003SE, runs under .net compact 2.0
Logs as fast as the PC based loggers.
Requires VS2005 trial or full version to compile.
Do no think of this as a consumer release, it is my project of which I'm sharing the code. I'll not be able to support it although will be interested in other deployments.
COM1 19200baud
Live graphing of octane, knock, MAT, IAT, MAP, TPS
Live scatter plot of knock vs RPM - red if TPS=100, blue if >90, green otherwise
Logging to SD card in .csv format
Setup for 240*320 display
Temps in Celcius, pressures in kPa
MAT,MAP are Evo IX JDM/UK calibration, will return junk values on US models
Tested on Pocket PC 2003SE, runs under .net compact 2.0
Logs as fast as the PC based loggers.
Requires VS2005 trial or full version to compile.
Do no think of this as a consumer release, it is my project of which I'm sharing the code. I'll not be able to support it although will be interested in other deployments.
Jun 22, 2007, 10:04 AM
#77
Evolved Member
Thread Starter
The way I believe UARTs usually work in asynchronous mode is to use the high-low (-5V to +5V RS232) transition as their start bit, so the Pocket PC might insert little gaps where it goes high again in between each byte being sent?
I didn't mean to patronise about the init procedure, but doing it with RS232 or a microcontroller is rather different to doing it with FTDI drivers, and none of the same assumptions apply hence why I needed to dig out the voltmeter to get it working. Same end result perhaps, but everything that could go wrong did for me for so long trying to get the Pocket PC to do it for some reason. I had to get buttons on the screen to open or close the port, to send a character, to turn break on or off etc, whilst watching the voltmeter to work it all out. I'm sure you'll get there quicker
I didn't mean to patronise about the init procedure, but doing it with RS232 or a microcontroller is rather different to doing it with FTDI drivers, and none of the same assumptions apply hence why I needed to dig out the voltmeter to get it working. Same end result perhaps, but everything that could go wrong did for me for so long trying to get the Pocket PC to do it for some reason. I had to get buttons on the screen to open or close the port, to send a character, to turn break on or off etc, whilst watching the voltmeter to work it all out. I'm sure you'll get there quicker
Jun 22, 2007, 10:11 AM
#78
Evolved Member
Thread Starter
Sorry stating the obvious, but you have to open the port (and send the dummy character - doesn't matter if the cable is connected when this happens) before you send the break command.
When testing with a terminal emulator, some will give an echo on the terminal and then a double echo when you plug the cable in, some will give no echo on the terminal and a single echo with the cable plugged in. I'm sure you could test this with a PC with a serial port and your Vagcom KKL cable to prove the hardware works.
When testing with a terminal emulator, some will give an echo on the terminal and then a double echo when you plug the cable in, some will give no echo on the terminal and a single echo with the cable plugged in. I'm sure you could test this with a PC with a serial port and your Vagcom KKL cable to prove the hardware works.
Jun 22, 2007, 11:39 AM
#80
The way I believe UARTs usually work in asynchronous mode is to use the high-low (-5V to +5V RS232) transition as their start bit, so the Pocket PC might insert little gaps where it goes high again in between each byte being sent?
I didn't mean to patronise about the init procedure, but doing it with RS232 or a microcontroller is rather different to doing it with FTDI drivers, and none of the same assumptions apply hence why I needed to dig out the voltmeter to get it working. Same end result perhaps, but everything that could go wrong did for me for so long trying to get the Pocket PC to do it for some reason. I had to get buttons on the screen to open or close the port, to send a character, to turn break on or off etc, whilst watching the voltmeter to work it all out. I'm sure you'll get there quicker
I didn't mean to patronise about the init procedure, but doing it with RS232 or a microcontroller is rather different to doing it with FTDI drivers, and none of the same assumptions apply hence why I needed to dig out the voltmeter to get it working. Same end result perhaps, but everything that could go wrong did for me for so long trying to get the Pocket PC to do it for some reason. I had to get buttons on the screen to open or close the port, to send a character, to turn break on or off etc, whilst watching the voltmeter to work it all out. I'm sure you'll get there quicker
d
Jun 23, 2007, 04:42 AM
#81
Had anyone every confirmed if any of the newer devices actually had a USB Host that worked properly? I actually got a build of mitsulogger to work on my emulator which does support USB host (using a VAG-COM FTDI USB cable as its recognized as a regular serial device)
Jun 23, 2007, 10:29 AM
#82
Evolving Member
iTrader: (2)
Join Date: Sep 2004
Location: South Bay
Posts: 287
Likes: 0
Received 0 Likes
on
0 Posts
Not newer devices yet. Many new devices are supposed to have USB "On the Go" which acts as both host or device depending on what is connected. FTDI guys say it should work but is not tested.
Some of the new Windows Mobile 6 (or whatever they renamed it to) devices are going to have those ports.
In the meantime I am going to buy a used Toshiba e805 or e405 which definitely DO have a host controller.
Some of the new Windows Mobile 6 (or whatever they renamed it to) devices are going to have those ports.
In the meantime I am going to buy a used Toshiba e805 or e405 which definitely DO have a host controller.
Jun 24, 2007, 10:49 AM
#83
Newbie
Join Date: Jan 2007
Location: Surrey, UK
Posts: 5
Likes: 0
Received 0 Likes
on
0 Posts
Interesting stuff going on here - courtesy of John Banks and colleagues.
From JB's posts in the MLR forum, I've got some kit from display3000 and will look at getting some logging to work on that.
From JB's posts in the MLR forum, I've got some kit from display3000 and will look at getting some logging to work on that.
Jun 25, 2007, 05:59 AM
#84
Evolved Member
Thread Starter
The knock logging scatter graph vs RPM with three colors depending on the TPS when the knock occurred is working really nicely! Very pleased with it.
Jun 25, 2007, 09:00 AM
#86
Evolved Member
Thread Starter
Screen shot attached of the knock graphing of today's driving. It only produces a single pixel for each RPM level and plots the knock. However, it is very easy to assess on the display, and a ncie summary of a lot of driving. You can see the knock sum of 0 along the bottom, didn't get much chance to red line my engine today with traffic 
Jun 26, 2007, 05:23 AM
#87
Hey, if you guys have PDA's with CF slots, there is a USB Host adapter that works with them. I had trouble getting the Tactrix cable recognized without hacking the driver install so it recognizes the devices ID, but it recognized the FTDI VAG-COM cable immediately, which means the Tactrix cable would also work if you fudge the registry/inf files a bit.
Jun 26, 2007, 07:57 AM
#88
Hey, if you guys have PDA's with CF slots, there is a USB Host adapter that works with them. I had trouble getting the Tactrix cable recognized without hacking the driver install so it recognizes the devices ID, but it recognized the FTDI VAG-COM cable immediately, which means the Tactrix cable would also work if you fudge the registry/inf files a bit.
d
Jun 29, 2007, 03:17 PM
#90
Evolving Member
iTrader: (2)
Join Date: Sep 2004
Location: South Bay
Posts: 287
Likes: 0
Received 0 Likes
on
0 Posts
John,
I have revamped your logger code that you posted earlier.
- FTDI support (in addition to your Serial Port code)
- Cleaned up and packaged code (more object oriented)
- Ditched the tab pages (large memory footprint)
- Enumerated MUT requests
- Kept your nice graphs and displays
Please give it a shot and revise as needed. I haven't tested any of it because I still don't have an interface working with a device, but it should be okay as I used code that is known to work.
I still want to make it multithreaded with an eventhandler for the OnReceived COM event, but I have to wrap it up so it can be a generic interface that will work with FTDI or Serial class. I will do that once I get the interface going.
Download here:
http://www.quickwarehouse.com/NewerLogger.zip
Sorry for the delay, but I thought a merge of the two was better...
Also, check out this nice description of Microsoft's IO.SerialPort class:
http://forums.microsoft.com/MSDN/Sho...41186&SiteID=1
I have revamped your logger code that you posted earlier.
- FTDI support (in addition to your Serial Port code)
- Cleaned up and packaged code (more object oriented)
- Ditched the tab pages (large memory footprint)
- Enumerated MUT requests
- Kept your nice graphs and displays
Please give it a shot and revise as needed. I haven't tested any of it because I still don't have an interface working with a device, but it should be okay as I used code that is known to work.
I still want to make it multithreaded with an eventhandler for the OnReceived COM event, but I have to wrap it up so it can be a generic interface that will work with FTDI or Serial class. I will do that once I get the interface going.
Download here:
http://www.quickwarehouse.com/NewerLogger.zip
Sorry for the delay, but I thought a merge of the two was better...
Also, check out this nice description of Microsoft's IO.SerialPort class:
http://forums.microsoft.com/MSDN/Sho...41186&SiteID=1