Was just perusing the ecutalk web site (http://www.ecutalk.com/) and it looks like there is a new version of the ECUTalk software (version 1.3.4). Given that there are a number of members that run in car PC's and PDA's these days I thought I'd give this as a heads up! I won't get a chance to test it until the weekend so if anyone does fire it up, please post up with results!
actually theres nothing too exciting in this one, just fixing the com port bug where com10-com19 didnt work (only really affects usb cable users on laptops), and allows to edit ini file to use alternative ECU id (some later model cars use different ID). unless you're affected by either of those, there is no need to upgrade. this com port bug was only brought to my attention recently which is why ive done this minor update once the next firmware is out for LCD (audible alerts/adjustments), the software will probably get alerts and probably the % change of speed for people with diff tyres, and maybe active tests.
Next version requests I luv your system ... kool. It would be good if : 1... it could generate an audible alarm on temperature too high, 2... audible alarm on voltage too low. 3... flag to not clear the current drive data, e.g. liters/100km, fuel consumed, srive duration.
ok ive added voltage too low to the audible alerts ticket for LCD, temp is already there. retaining trip stats over sessions is scheduled for the next firmware revision after this next one (its a bit difficult as you have limited amounts of writes to eeprom and u dont know when car will be turned off)
use the SD Card slot I admit I could be completely wrong here ... but there is an SD Card slot on the side, these statistics could be written here instead of to eeprom. Actual would prefer it written here as could write other performance info here and take away to analysis separately on a PC.
you need to also write the position you are up to writing on the sdcard to the eeprom. whether or not the trip stats are then on eeprom or not doesnt matter so much as you still have the problem of not knowing when the car will be turned off the sd card isnt written in pc readable format so cant do things in the same manner that would seem logical on a PC (partly because its difficult and would affect how much can be logged, and time to add the feature, but also because its difficult to remove the sd card do ull just download the logs via USB port)
audible alarms, alarm screens, alarm acknowledgement My apologies if this has been discussed or is described somewhere else. The following are some suggestions in reference to audible alarms, alarm screens, and alarm acknowledgement. Alarm Screen Currently there are two main screens that can be button-toggled through while driving; the gauge-value screen, and the trip-computer screen. I would like to see a third / fourth main screen specifically for Alarms be added to the button-toggle screens loop. This alarm screen would display each enabled alarm, its set alarm activation value, its current value, and whether this alarm has been acknowledge. If there are too many alarms selected to be displayed on one screen then additional alarm screens will be added onto the end of the button-toggle main screens loop. Alarm Acknowledgment When an alarm threshold has been exceeded I would like to have an audible alarm which repeats every (say 30 seconds), and the screen displays a warning message for that alarm with its set alarm activation value, and its current value. The audible alarm will repeat until such time as both front panel buttons are held down together to acknowledge the alarm, at which time the alarm sound will stop. Alarm Repeat For each alarm there will be an incremental threshold where the audible alarm and alarm acknowledgment process is repeated if the alarm condition worsens. Example For example I set the temperature alarm to 95C with a threshold increment of (either 5C or 10C), for which I happen to choose 5C. I am driving along in traffic on a hot day and the car?s temperature starts to rise from the normal 85C towards 95C. Once 95C is reached the audible alarm goes off and the sound repeats every 30 seconds, the main screen switches to displaying the warning message for temperature with the set alarm activation value, and its current value. I acknowledge this alarm by holding down both of the front panel buttons. The alarm sound terminates and the main screen returns to the gauge display. Unfortunately the temperature continues to rise and now reaches 100C, at which point the alarm sound starts again but is now repeated every 20 seconds, the main screen switches to displaying the temperature warning message with the set alarm activation value, and its current value. Being stuck in traffic on this stinking hot day there is nothing much that I can do, so I acknowledge this alarm by holding down both of the front panel buttons. The alarm sound terminates and the main screen returns to the gauge display. The temperature continues to rise to 105C the alarm sound starts again but is now repeated every 10 seconds, the main screen switches to displaying the temperature warning message with the set alarm activation value, and its current value. So I acknowledge this alarm by holding down both of the front panel buttons. The alarm sound terminates and the main screen returns to the gauge display. The temperatures are going through the roof, 110C is reached and the alarm sound starts again but is now repeated every 5 seconds, the main screen switches to displaying the temperature warning message with the set alarm activation value, and its current value. Fortunately traffic starts moving again. As the temperature reduces down past the last incremental threshold e.g. 105c, then the unit beeps twice, and the main screen display switches to displaying the alarm-clearing message with the set alarm activation value, and its current value. There is no need to acknowledge this notification. After 30 seconds the main screen returns to the gauge display. As the temperature reduces again to the next incremental threshold e.g. 100c, then the unit beeps twice ?. The process continues until the temperature has reduced to the original alarm set threshold.
thanks for the suggestions. so far the design for the alerts is basically: 1) set alerts on/off from the Alerts section off the main menu, here u also set the value they would be alerted at for the 6 sensors, rpm, speed, temp, afm, injector duty (all max values) and voltage (min value) or turn it off if u dont want alert for it. 2) when an alert is met, the display switches to sensor screen (if on trip screen), there is an initial buzz, and the alerting sensors will flash 3) every 30s that the alert is still active, it will send a reminder buzz. 4) possibly the volume of alerts can be adjusted via options, though im not sure if it would adjust volume or merely pitch (hardware constraint, wont know till i try) holding down both buttons wont work because then all buttons presses would need a delay in order to account for if the second button would also be pressed, and this delay would then affect normal operation if u werent pressing both buttons. but possibly (though i dont think in the first version of it) there maybe should be a way to ignore the alert or something, though really if an alert isnt important then it shouldnt really be set (and if its marginal, a warning every 30s shouldnt be much of an issue). while your overall suggestion sounds good, the limitations on the program memory (ie how much logic can be in the application) is limited, as is time to implement features etc, so the best bank for buck is the simplest solution that achieves the objective (to alert the user when a condition is met) that most people require. then if everyone wants it to do this or that, that can be done later (but it would be a waste of time to do a grand solution only to find no one needs 80% of it). also a reason i dont want to put another screen in the main loop is that im planning to add more in future (e.g. a 'switches' screen, and maybe a trip/sensor hybrid screen which takes the more important bits from both). so dont want the loop having too many things on it. Peter
have put up a beta of v1.3.5, most importantly adds alerts (inverts color of affected sensor and beeps). havent tested the beeps but it worked on the emulator. http://www.ecutalk.com/downloads/ECUTalk_v1.3.5_beta.exe
I think I'll defer to BigCol to do some beta testing for us. Not sure if the new version would be a big benefit/change/improvement over version 1.3.4 That "Alert" function isn't available on the PDA/PPC displays, but only on the V.2 display, correct?
no, the update is a software update (nothing to do with displays, that would be a firmware update). the displays already have alerts, this is just adding it to the PPC/laptop ecutalk software. although now i see most of this thread was about the display, but the original post was to do with the ecutalk software, not display.
I'm not aware of any alerts or even a prompt to activate it when ECUTalk boots up on my PPC. You're saying that the alert function is supposed to be active for both systems of displays, correct?
the point of this update, v1.3.5, is to ADD the alerts - if they were already in your v1.3.4 version then you wouldnt need this! (and of course i wouldnt have added them a second time if they were there). the LCD displays have had the alerts for a while, since v2.02 firmware - now im finally catching up and adding it to the software. of course both in the LCD display, and now the v1.3.5 beta, you need to activate the alerts you want and set their value. for the software its on the options->alerts tab.
have updated the proper thread - http://www.aus300zx.com/forum/showthread.php?t=257979 as this one will just confuse people with all the talk about the display
I've had a chance to play with this last weekend and I've got to say really nice work Peter. The implementation of the warning lights is great. The way the gauge illuminates is great, as is the way you implemented the trigger value. The only thing I'd like to see in future releases would be selecting a custom sound. But other than that EXCELLENT! Anyone running the old version should update without hesitation.
rename your windows\voicbeep.wav to something else and put a new voicbeep.wav in...but it fires every 1-2 seconds when alert is met so has to be short sound. also one thing i didnt check, is that the firing of the sound doesnt 'block' everything - see what happens if u put a long wav in (like 5s) whether they just overlap, or whether the software locks up (and hence there wont be the usual 20 logs per second in logs) until sound is finished?
