Notices
General Engine Management / Tuning Forum Discuss general EMS tuning concepts that do not pertain to a specfic brand or product.

Very minor bug in TXS Tuner interface

Thread Tools
 
Search this Thread
 
Old Apr 18, 2004 | 05:35 PM
  #1  
MalibuJack's Avatar
Thread Starter
EvoM Guru
20 Year Member
iTrader: (5)
 
Joined: Feb 2003
Posts: 10,572
Likes: 14
From: Royse City, TX
Very minor bug in TXS Tuner interface

Ok, this is a VERY minor bug, but I discovered it when doing a raw serial data dump troubleshooting an issue with my application..

When the Tuner appends the AFR to the end of the line on Data1 (shift-1 specifically, comma delimited) it tags a NULL character onto the end of the line before the CRLF

Some programs do not discard nulls, and will cause weird results..

You guys might have to revise your serial stream to remove the nulls or other programs may have issues. I have worked around it, but I was stumped as to why my application worked fine, and then it didn't when the tuner was installed.

ALSO, since nulls are considered characters, they affect the spacing (visually their not there) but programmatically, they take up a byte space and can cause applications to choke, since most programming languages tag the null as an 'end of variable space'
Reply
Old Apr 19, 2004 | 12:08 PM
  #2  
PDXEvo's Avatar
Evolved Member
iTrader: (4)
 
Joined: Jan 2004
Posts: 1,054
Likes: 1
From: Portland, OR
Actually what you are seeing is a \r or a carriage return register. Just add 1 byte to all your lines and you will be fine. The parser I wrote recognizes this last byte properly and sets the logs so they always come out identicle to the logs captured via hyperterminal. Removing that carriage return would make it harder to understand eol when performing logs without spaces and it would make the log file output from hyperterminal ugly too.
Reply
Old Apr 19, 2004 | 05:37 PM
  #3  
MalibuJack's Avatar
Thread Starter
EvoM Guru
20 Year Member
iTrader: (5)
 
Joined: Feb 2003
Posts: 10,572
Likes: 14
From: Royse City, TX
Nope that wasn't it.. It was definitely a null.. Generally the com port routines strip it out.. I spotted it when I was capturing raw data.. It was easily fixed, but it shows up only with the Tuner.. It was a &H00, not a &H0C or &H0D.... Most of the lines have the null in it, except for the >25:1 lines, which don't have an issue (Only have the Carriage return)

Canned Serial routines generally filter this stuff out already before its processed by the user.. I have a serial sniffer and discovered that the null would cause the application to stop processing after that point.. again easily fixed, but I noticed that older terminal programs have trouble with that null (QmodemPro for windows, and Procomm Plus for DOS is a good example)

Depending on where your capturing the log files, they may have a CR or CRLF at the end.. however most apps don't care or have problem with standard EOLN delimiters.. its the Null that confuses some apps because of how most programming languages delimit variable space as null terminated.

But my point wasn't that its there, just that its inconsistent and caused weird things to happen on some of the apps I tested. Along with discovering a minor bug in my app that didn't expect to see a null.
Reply




All times are GMT -7. The time now is 05:38 AM.