Deleting a single sample of data

Submit feature suggestions for future versions of TunerPro here.

Moderators: Mangus, robertisaar, dex

Post Reply
robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Deleting a single sample of data

Post by robertisaar »

some of you will know what i'm talking about...

getting a single bad sample can ruin certain things in the histograms, like a trip fuel economy number. i can get say 75% through a log and that one frame comes up and then the number goes from something believable, like 31MPG to "1.#IO" and stays there until i clear the value and lose whatever data i get...

considering i only get maybe 1 bad frame every 30-60 minutes of logging, most of the time, just the one kills it for me. if there was some way to get rid of, or copy the value from the previous frame, or the next frame, something, it would be greatly appreciated.

yoda69
Posts: 31
Joined: Wed Dec 09, 2009 1:06 pm
Location: Australia

Post by yoda69 »

I second the idea, I've had a few logs ruined by 1 byte of data being wrong.
I think it would be a good feature to have.

yoda69

User avatar
dfddfd2
Posts: 112
Joined: Wed Feb 27, 2008 4:37 pm
Location: Burgaw, NC

Post by dfddfd2 »

I'll third this plan. If an error occurs receiving a packet, the error counter should increment, but the entire packet should be ignored.

User avatar
Mangus
TunerPro Author
Posts: 1830
Joined: Wed Mar 19, 2003 1:49 pm

Post by Mangus »

Hmm, the packet actually should be ignored. Not sure why it's not, but I shall fix it for you...
***************************************
TunerPro Author
1989 Trans Am

robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Post by robertisaar »

Mangus wrote:Hmm, the packet actually should be ignored. Not sure why it's not, but I shall fix it for you...
sweet.

some more background to it is that there are bad packets that do get ignored... and counted as errors. but there are also packets with crazy values that for some reason are not considered errors...

User avatar
Mangus
TunerPro Author
Posts: 1830
Joined: Wed Mar 19, 2003 1:49 pm

Post by Mangus »

robertisaar wrote:
Mangus wrote:Hmm, the packet actually should be ignored. Not sure why it's not, but I shall fix it for you...
sweet.

some more background to it is that there are bad packets that do get ignored... and counted as errors. but there are also packets with crazy values that for some reason are not considered errors...
Those must be the ones causing your specific issue. If TunerPro knows the data is bad, the packet is definitely ignored (I just verified in code and test). The packets that get through are packets that are of the proper (expected) size, but may contain false data. That has a higher probability of occurence for, say, 160 baud packets, as they're bit-banged.
***************************************
TunerPro Author
1989 Trans Am

User avatar
Mangus
TunerPro Author
Posts: 1830
Joined: Wed Mar 19, 2003 1:49 pm

Post by Mangus »

PS - one thing that I've thought about adding to histograms is the ability to only add histogram data if it falls under some user-defined range. This is good for statistical rejection of data that is good and valid, but out bounds for what you're interested in. This would also alleviate your issue, but I'm a ways out from adding something like that.
***************************************
TunerPro Author
1989 Trans Am

robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Post by robertisaar »

i don't know what bit-banged means, but i haven't touched a 160 baud setup in a LONG time...

i have to wonder what causes the packet to be the correct size...

that histogram concept reminded me of something else i thought was odd...

almost every time one of the bad packets slipped throuh, it's almost always in the same cell in a VE histogram, but the values usually vary. the most common example is it getting placed in the 800RPM 100kPa cell(which i would never actually reach during driving) and more often than not, the BLM and INT would show up as an incredibly low number, like 20 or less.

User avatar
Mangus
TunerPro Author
Posts: 1830
Joined: Wed Mar 19, 2003 1:49 pm

Post by Mangus »

Bit banged means data is read a bit at a time, bytes constructed by those bits, and the packet is constructed from those bytes.

I don't know what could cause the a rogue packet to come through with invalid data but the proper size.
***************************************
TunerPro Author
1989 Trans Am

robertisaar
Author of Defs
Posts: 962
Joined: Sat Feb 21, 2009 3:18 pm
Location: Camden, MI

Post by robertisaar »

you mean that isn't done all the time? :o

i'm certainly a noob when it comes to communication...

but is it possible a value either gets shifted forward or backwards without any software correcting it and that causing odd values? i don't even know if that's possible...

EDIT: but then the packet would be the wrong size.... hmm....

User avatar
dfddfd2
Posts: 112
Joined: Wed Feb 27, 2008 4:37 pm
Location: Burgaw, NC

Post by dfddfd2 »

Mangus wrote:PS - one thing that I've thought about adding to histograms is the ability to only add histogram data if it falls under some user-defined range. This is good for statistical rejection of data that is good and valid, but out bounds for what you're interested in. This would also alleviate your issue, but I'm a ways out from adding something like that.
I could sure use this feature to help develop a VE map for the MAF to speed-density conversion I'm working on.

Thanks,
Dave

Post Reply