Jump to content
SAU Community

Recommended Posts

ive released an update to the pocket pc edition which fixes the logging frequency (now its as often as pda can handle, ie as many log packets as sensor updates on screen, depends on speed of ur pda), and also creates seperate file each time for logging)

http://www.ecutalk.com

  • Replies 149
  • Created
  • Last Reply

Top Posters In This Topic

  • 1 month later...

ECUTalk v1.2 - http://www.ecutalk.com/

Combined Standard and Pocket PC versions into the single unified executable (single .exe also), based off the last Pocket PC release.

Added auto connect back in - it will connect on the given com port, select the sensors, and view gauges fullscreen on startup (after its set up).

Added in injector duty cycle % sensors, and added MPH and degrees F sensors (for speed/temp).

Left: Running on PC/Laptop

Right: Running on Pocket PC

ecutalk_v1.2_sensors.jpg

More screenshots: http://www.ecutalk.com/screenshots.aspx

nah, you'll need a pocket pc. palms are the poor mans pocket pc :spank:

i think theres some software written for a palm out there somewhere called "palmz" this guy wrote it: http://ecu2.forumwise.com/profile.php?mode...ofile&u=440

on that note, i picked up a h2210 on ebay for $40 :dry: (though it has nearly all non-essential bits missing and bluetack/tape needed to hold battery in, but it works!)

rz1710 ipaqs can be found a bit over 100$, might be a reasonable upgrade

Edited by NewKleer

NewKleer, i need to get a new boost controller, and some other bits first, plus i am running out of places to mount this stuff. LOL. I think a lappy will do for now, the wife is riding my nuts cos i spend too much money, Blody women, you can't live with them and you can't shoot them.

a silly question, i take it this does not work on a Palm such as an m515???

if so how, cos i can't get it tp work

what about this?

http://eccs.hybridka.com/viewtopic.php?t=105

  • 3 months later...

ECUTalk v1.3 Released - http://www.ecutalk.com

1) Added ability to log sensors without showing them on gauges (when logging is enabled, checkboxes have a greyed out checkstate, indicated logging only)

2) Logging changed so it logs all packets (only gauges will drop packets/not update when cpu is falling behind, but all packets will be logged)

3) Colour setup for gauges added. Hard bit for you is coming up with a colour theme that looks ok!

4) Added Instant Fuel Economy Sensor - requires RPM, Injector and Speed kph selected to work

5) Changed DutyCycle/RH Sensors to calculate values from RPM and Injector/RH sensors (therefore requires them to be logged at least to work)

6) Fixed Timestamps when milliseconds are less than 100 (3 digits). Previously they would not have leading zeroes

7) Simplified gauges such that they will only display values within their range (however, logging will show the calculated value) and will no longer auto change their range to suit the values (as occasionally a weird value may be read which causes a unco gauge to be drawn).

8) Added an option to allow the full-screen mode to only use the "working area" of the screen. Eg, it wont cover taskbar in a normal windows desktop, and for carpc users with special frontends, it may mean gauges display properly if running ECUTalk from within your frontend.

9) Improved the saving of settings to .ini file. Note that the order of items in this .ini file matters - their names (what is shown before the ":") does not. Eg autoconnect, logging, selected sensors, working area option, injector size, gauge colours, etc are all stored in here.

10) Removed EGT sensor (it's useless, only ever reads 4.98v)

See screenshots below to better understand difference between selecting sensors for gauges (batt, duty, econ, temp) which you check once, and for logging (rpm, injector, speed) which are checked a second time to make them grey. Also shown is how you can set the colour of the gauges yourself.

ecutalk_v1.3_sensors.jpgecutalk_v1.3_coloursetup.jpg

ECUTalk v1.3.2 Released - http://www.ecutalk.com

This version fixes a few bugs and has some pretty big performance improvements.

Users of v1.3 and v1.3.1 should update to this version.

v.1.3.1 added a MPG sensor for Imperial users (and an option to switch between Imperial/Metric sensors).

1) Fixed issue in v1.3 and v1.3.1 which meant data packets weren't being dropped when CPU couldn't keep up

2) Increased performance of gauge drawing by ~250% (on my PPC, time to draw a gauge went from ~30ms down to around ~12ms).

3) Changed code to always draw gauges (even if data hasnt changed) in order to result in consistent amount of packets being logged per second.

4) Added option to specify minimum gauge update speed - higher value means more packets are logged due to less gauge updates (and hence more time for logging). Eg on my 568 Jornada PocketPC 2002, 10ms = ~5 packets logged/second, whereas 1000ms = close to full 50 packets). The setting ignored when not logging (it will just update as quickly as possible).

5) Improved consult streaming to allow more data to be read in and processed (rather than lost). Probably the best program for data logging due to the sheer amount of data able to be read in. On my desktop PC, setting minimum gauge refresh to 0ms (ie never skip a gauge redraw, hence uses most CPU), can log 35 packets/second of all sensors. Setting minimum refresh to just 50ms gives the full 50 packets/second. I compared this to Nissan Datascan, which can only log 16 packets/second on the same PC (and thats without gauges shown at all) with the same sensors.

6) Changed options controls to dropdowns rather than textboxes (i didnt realise id disabled the use of the soft input panel on PPC, so you couldnt change settings). If you want to enter a value other than shown, edit the .ini file.

7) Fixed logging time output, both to add in the missing leading zeros (eg it would show 7:5:7 for 7:05:07), and also added in a interpolated millisecond value for PPC users (which doesnt have a millisecond capability in standard time object).

8) Minor changes to individual sensors to better display on gauges, and slight changes to change config (units shown next to sensor rather than down bottom as often the units would overlap gauge).

9) Added a hidden option for CarPC users with frontends (eg Centrafuse) to manually edit .ini file to set custom top/bottom/left/right co-ordinates for full-screen mode. Example: FullScreenBounds_L|T|R|B:10|20|1000|900. Setting all to 0 will use default method.

If I was to have a PDA with the only connection being via USB, would this program still be able to work on the PDA providing I have the following cable:

http://www.blazt.biz/products/images/usblarge.JPG

I've read all 5 pages of this thread, but it's still all a bit confusing. I can't see why this wouldn't work?

Please let me know.

Thanks,

Richard.

i can see two reasons:

1) your PDA most likely does not have USB host capabilities (ie, its not able to have usb devices connect to it - its only able to act as a usb device to a PC)

2) the current usb blazt cable is based off a usb/serial converter which has no virtual com port drivers for windows ce (ie pocket pc/windows mobile)

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



  • Similar Content

  • Latest Posts

    • Great interview on damper settings and coil selection by HPA https://www.facebook.com/HPAcademy/videos/30284693841175196/?fs=e&s=TIeQ9V&fs=e
    • Yeah, it was a pretty deep dig.
    • The values for HID colour are also defined ~ see https://www.legislation.gov.au/F2006L02732/latest/text  ~ goto section 3.9 onwards ....
    • So, if the headlights' cutoff behaviour (angles, heights, etc) are not as per 6.2.6.1.1 without automatic levelling, then you have to have to have automatic** levelling. Also, if the headlight does not have the required markings, then neither automatic nor manual adjusters are going to be acceptable. That's because the base headlight itself does not meet the minimum requirement (which is the marking). ** with the option of manual levelling, if the headlight otherwise meets the same requirements as for the automatic case AND can be set to the "base" alignment at the headlight itself. So that's an additional requirement for the manual case. So, provided that the marking is on the headlight and there is a local manual adjustment back to "base" on the headlight, then yes, you could argue that they are code compliant. But if you are missing any single one of these things, then they are not. And unlike certain other standards that I work with, there does not seem to be scope to prepare a "fitness for purpose" report. Well, I guess there actually is. You might engage an automotive engineer to write a report stating that the lights meet the performance requirements of the standard even if they are missing, for example, the markings.  
    • Vertical orientation   6.2.6.1.1. The initial downward inclination of the cut off of the dipped-beam to be set in the unladen vehicle state with one person in the driver's seat shall be specified within an accuracy of 0.1 per cent by the manufacturer and indicated in a clearly legible and indelible manner on each vehicle close to either headlamp or the manufacturer's plate by the symbol shown in Annex 7.   The value of this indicated downward inclination shall be defined in accordance with paragraph 6.2.6.1.2.   6.2.6.1.2. Depending on the mounting height in metres (h) of the lower edge of the apparent surface in the direction of the reference axis of the dipped beam headlamp, measured on the unladen vehicles, the vertical inclination of the cut off of the dipped- beam shall, under all the static conditions of Annex 5, remain between the following limits and the initial aiming shall have the following values:   h < 0.8   Limits: between 0.5 per cent and 2.5 per cent   Initial aiming: between 1.0 per cent and 1.5 per cent   0.8 < h < 1.0   Limits: between 0.5 per cent and 2.5 per cent   Initial aiming: between 1.0 per cent and 1.5 per cent   Or, at the discretion of the manufacturer,   Limits: between 1.0 per cent and 3.0 per cent   Initial aiming: between 1.5 per cent and 2.0 per cent   The application for the vehicle type approval shall, in this case, contain information as to which of the two alternatives is to be used.   h > 1.0   Limits: between 1.0 per cent and 3.0 per cent   Initial aiming: between 1.5 per cent and 2.0 per cent   The above limits and the initial aiming values are summarized in the diagram below.   For category N3G (off-road) vehicles where the headlamps exceed a height of 1,200 mm, the limits for the vertical inclination of the cut-off shall be between: -1.5 per cent and -3.5 per cent.   The initial aim shall be set between: -2 per cent and -2.5 per cent.
×
×
  • Create New...