Post by thread:Fuel Tank Sender Buffer

> I have a meter to measure the fuel level of a tank 0=empty 255=full. > I want to use software to provide a buffer so that the slosh of the > fuel is not seen on the fuel gauge. There has been a lot of discussion on averaging, noise immunity, etc.e tc. After messing around with averaging filters and other things, I have settled on median filters as being very effective. Step 1: clear a section of RAM say 10 or 20 locations Step 2, take a series of readings at intervals which should cancel out the sloshing. What frequencies do you expect from a sloshing gas tank? 1 hz? .25 Hz? You might take readings at one or two times a second Step 3 as you take readings, sort them into the RAM locations so that they are arranged low to high. Step 4 if you took 20 readings, take the tenth one as your data point. Step 5 clear the RAM again. If you need some help with a sorting routine I can provide more detail. My question to you: How are you going to ensure that your sensor can't short out and cause a spark and/or explosion? I'd be way worried about this possiblility. -- Lawrence

Lawrence Lile <spam_OUTlilelTakeThisOuTTOASTMASTER.COM> wrote: >My question to you: How are you going to ensure that your sensor >can't short out and cause a spark and/or explosion? I'd be way >worried about this possiblility. It is surprisingly difficult to cause an explosion INSIDE of a fuel tank. The air/vapor ratio has to be within a range seldom, if ever, seen inside a tank. Years ago I worked on a low fuel level warning system for a major automobile manufacturer. The system used a thermistor which was self heated to a temperature well above any ambient temperature that was expected. When the thermistor was in the fuel it would cool down, changing its resistance, changing the current through a relay causing the contacts to transfer. The customer spent a great deal of time and money attempting to cause explosions as the result of various faults and, as I recall, was unable to do so. YMMV, standard disclaimers apply. -- Bob Fehrenbach Wauwatosa, WI .....bfehrenbKILLspam@spam@execpc.com

On Tue, 3 Feb 1998, Lawrence Lile wrote: > > I have a meter to measure the fuel level of a tank 0=empty 255=full. > > I want to use software to provide a buffer so that the slosh of the > > fuel is not seen on the fuel gauge. PTM: Q&D solution: TEMP = (TEMP + NW)/2 This needs 8 bit + carry to handle 0..255 values. This function works if the sloshing makes small differences to both sides of the right one and the time period is rather short, about 1/20 sek. If this still give odd values, you can make even: TEMP = (TEMP + NV - TEMP/D) VAL =TEMP / D There TEMP is a 16 bit register for the summ NV = nev measured value (0..255) D is 2,4,8,16... (2^n) static VAL is the value that is shown in the display. This gives you totally wrong values from the first D*5 times (I tried this) but after that you get every time a bit better approximation. D is selected as a 2^n to get the program easier. You can even make a try with QBasic: '-------------------------------------------------- 'PTMUSTAKILLspamUTU.FI 'Demonstrating running averages 'shareware ;) '-------------------------------------------------- CLS NV = 3 D = 4 FOR i = 1 TO D * 6 'here we simulate random slosh NVU = NV + (RND(1) - .5) / 10 'running average value TEMP = (TEMP + NVU - TEMP / D) DISPLAY = TEMP / D PRINT i;"New=";NVU;"Displ=";DISPLAY;"err=";(DISPLAY-NV)/NV;"%" NEXT -------------------------------------------------------------------------- PTM, .....pasi.mustalahtiKILLspam.....utu.fi, EraseMEptmustaspam_OUTTakeThisOuTutu.fi, http://www.utu.fi/~ptmusta Lab.ins. (mikrotuki) ATK-keskus/Mat.Luon.Tdk OH1HEK Lab.engineer (PC support) Computer Center OI7234 Mail: Turun Yliopisto / Fysla, Vesilinnantie 5, 20014 Pt 02-3336669, FAX 02-3335632 (Pk 02-2387010, NMT 049-555577) --------------------------------------------------------------------------

Pasi T Mustalahti wrote: {Quote hidden}> PTM: Q&D solution: > TEMP = (TEMP + NW)/2 > This needs 8 bit + carry to handle 0..255 values. > This function works if the sloshing makes small differences to both sides > of the right one and the time period is rather short, about 1/20 sek. > > If this still give odd values, you can make even: > TEMP = (TEMP + NV - TEMP/D) > VAL =TEMP / D > There TEMP is a 16 bit register for the summ > NV = nev measured value (0..255) > D is 2,4,8,16... (2^n) static > VAL is the value that is shown in the display. > This gives you totally wrong values from the first D*5 times (I tried > this) but after that you get every time a bit better approximation. > D is selected as a 2^n to get the program easier. > > You can even make a try with QBasic: > > '-------------------------------------------------- > 'PTMUSTAspam_OUTUTU.FI > 'Demonstrating running averages > 'shareware ;) > '-------------------------------------------------- > CLS > NV = 3 > D = 4 > FOR i = 1 TO D * 6 > 'here we simulate random slosh > NVU = NV + (RND(1) - .5) / 10 > 'running average value > TEMP = (TEMP + NVU - TEMP / D) > DISPLAY = TEMP / D > PRINT i;"New=";NVU;"Displ=";DISPLAY;"err=";(DISPLAY-NV)/NV;"%" > NEXT I'm planning on using something similar to this running average algorithm in my current project which is to read current drawn by a 40HP AC motor. The value read fluctuates wildly sometimes (nature of the machinery) and needs to be damped. I don't know much about PICs but the algorithm can be easily implemented on 68HC11 because of 16 bit arithmetic instructions. Maybe somebody could implement it in PIC code. What I would do in your case would be:- LEVEL = 0 ; tank level value read by sensor (0 - 255) N = 16 ; number of readings to average over (2, 4, 8, 16,.... 256) RAVG = 0 ; running average value of tank level (0 - 255) over N readings RTOTAL = 0 ; running total after N readings :LOOP LEVEL = read new tank level value RAVG = (RTOTAL + LEVEL) / N RTOTAL = RTOTAL + LEVEL - RAVG END LOOP I get the running average first then the running total, I save on one divide operation. N value is chosen based on the frequency of the fluctuation in relation to your sampling rate. Choosing N=256 would really damp slow fluctuations and has one additional bonus in that you only have to take the hi order byte of the 16 bit value for (RTOTAL + LEVEL) / N to get RAVG. For any other N values you would have to do some shift right operations. And for N=256, RTOTAL has max of (2^16) - 1. I've not implemented this Q&D solution (as you put it) yet. I'm not sure whether it's going to work. -------------- seetho

On Thu, 5 Feb 1998, seetho wrote: > Pasi T Mustalahti wrote: > > If this still give odd values, you can make even: > > TEMP = (TEMP + NV - TEMP/D) > > VAL =TEMP / D > > I get the running average first then the running total, I save on one divide > operation. PTM: If D= 2^n, you don't actually divide, you just shift right. That's only one instruction in any prosessor. This makes this Q&D -solution so beatifull. > > I've not implemented this Q&D solution (as you put it) yet. I'm not sure > whether it's going to work. PTM: I have used it myself. -------------------------------------------------------------------------- PTM, @spam@pasi.mustalahtiKILLspamutu.fi, KILLspamptmustaKILLspamutu.fi, http://www.utu.fi/~ptmusta Lab.ins. (mikrotuki) ATK-keskus/Mat.Luon.Tdk OH1HEK Lab.engineer (PC support) Computer Center OI7234 Mail: Turun Yliopisto / Fysla, Vesilinnantie 5, 20014 Pt 02-3336669, FAX 02-3335632 (Pk 02-2387010, NMT 049-555577) --------------------------------------------------------------------------

On Thu, 5 Feb 1998, seetho wrote: > Pasi T Mustalahti wrote: > > > > If this still give odd values, you can make even: > > TEMP = (TEMP + NV - TEMP/D) > > VAL =TEMP / D > I get the running average first then the running total, I save on one divide > operation. PTM: Using 2^n values, you don't actuallly divide, you shift right. It is only one instruction -------------------------------------------------------------------------- PTM, RemoveMEpasi.mustalahtiTakeThisOuTutu.fi, spamBeGoneptmustaspamBeGoneutu.fi, http://www.utu.fi/~ptmusta Lab.ins. (mikrotuki) ATK-keskus/Mat.Luon.Tdk OH1HEK Lab.engineer (PC support) Computer Center OI7234 Mail: Turun Yliopisto / Fysla, Vesilinnantie 5, 20014 Pt 02-3336669, FAX 02-3335632 (Pk 02-2387010, NMT 049-555577) --------------------------------------------------------------------------