Deleting a single sample of data
Moderators: Mangus, robertisaar, dex
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
Deleting a single sample of data
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.
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.
I'll third this plan. If an error occurs receiving a packet, the error counter should increment, but the entire packet should be ignored.
NismotronicSA Tuning Package/Powered by TunerCodeSA
Speed-Density Tuning for Nissans
Speed-Density Tuning for Nissans
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
sweet.Mangus wrote:Hmm, the packet actually should be ignored. Not sure why it's not, but I shall fix it for you...
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.robertisaar wrote:sweet.Mangus wrote:Hmm, the packet actually should be ignored. Not sure why it's not, but I shall fix it for you...
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...
***************************************
TunerPro Author
1989 Trans Am
TunerPro Author
1989 Trans Am
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
TunerPro Author
1989 Trans Am
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
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.
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.
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.
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
TunerPro Author
1989 Trans Am
-
- Author of Defs
- Posts: 962
- Joined: Sat Feb 21, 2009 3:18 pm
- Location: Camden, MI
you mean that isn't done all the time?
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....
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....
I could sure use this feature to help develop a VE map for the MAF to speed-density conversion I'm working on.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.
Thanks,
Dave
NismotronicSA Tuning Package/Powered by TunerCodeSA
Speed-Density Tuning for Nissans
Speed-Density Tuning for Nissans