Tesla Temp Mux Testing

[johu]

So the software switches the mux and then in the NEXT cycle it sees the result from that mux input.
static variables are initialized once at startup. Basically in the "1" case we start over finding the max of all sensors. But thinking about this that could really cause oscillating values.
Yes the 10k sensors I also copied from your version

[cloudy]

Thanks, the max reset makes sense now. I also see what you mean about the next cycle, the actual analog read is done outside (before) the switch case and only the lookups from previously stored analog read are done within case. Would be handy to have a comment like below beside them for idiots like me Or perhaps integrate the read to happen within the case, (though possible you are doing this to allow the value to settle)

int tmphsi = AnaIn::tmphs.Get(); //Reads analog value from Tesla mux selected in previous iteration
int tmpmi = AnaIn::tmpm.Get();; //Reads analog value from Tesla mux selected in previous iteration


I also see there could be some weirdness as tmpmax after case1 will only take into account the sensors read in case 0 as it has no previous max to compare with as it was just reset. One of those sensors in case0 is not connected and set to 0, so tmpmax can only be zero during case1.
It would only be after a full cycle of 3 more GetTemps (back to case 0) that tmpmax will accurately reflect the maximum across all sensors.

Is it possible to just cycle all mux and find the maximums in a single call of getTemps - or is that too slow?
Or another way could be to keep a long term max from the previous complete cycle (this would also provide a little smoothing) ie:

tmphsMax = MAX(tmphsMax, tmphs); //Find maximum between cycle Max and current reading
tmphs = MAX(tmpsLastMax,tmphsMax); //Find maximum from previous cycle maximum, cycle maximum and current value & avoid updating LastMax

in case1:
tmpslastMax = tmphsMax; //Store this cycles max
tmphsMax = 0; //Reset cycle max

[johu]

Ok, moved the posts over here.

So I worked on the temperature reading more: https://github.com/jsphuebner/stm32-sin ... dcc9e2be5b

Basically I don't do book keeping on the multiplexer input but I read the current state of the mux pins and derive the input number from that. One redundancy gone.

Next I collect 3 heat sink and TWO motor temperatures and when I arrive at the last mux input I update tmpm and tmphs with the respective maximum. I have chosen to ignore the fluid temperatures as thats just another source of errors and it will hardly ever be warmer than stator or heatsink itself.

Please test and report back for both types LDU/SDU. If it works it's time for a new release.

[cloudy]

Thanks Johannes, this work is appreciated - will try and test over this weekend if time permits...

[retrEVnoc]

I tried the above version (4.83) and got the TMPHSMAX error. I didn't get this error using 4.81 (posted in the 'start problems' thread). Will update over there too.

[johu]

Jesus this is confusing. I will not support another hardware design with muxed inputs. I'm sure the opamp pros can come up with a hardware max-value-selector.
I went over this whole thing again, please test.
EDIT: Diff link: https://github.com/jsphuebner/stm32-sin ... ca63ae1f4f

[cloudy]

Thanks, sorry I didn't get to testing the last version. Re: hardware max - I guess because of the different sensor types in single channels you would need to hardware scale each first to be able to do temp comparators - probably easier using a small micro with a d>a, I think doing it the current way is the most flexible design...

[cloudy]

Sorry it's taken a while - Doing uploads via the wifi/web interface always seems to corrupt for me, so I had to pull the motor and split case to SWD it. Any ideas how to avoid this?

Tried the version attached above, but I don't think this had the fix in - posted a whole bunch of troubleshooting below until realising!
I compiled directly from source (which all seems to match up to the mux selects in hardware)

tmphs 24.30
tmpm 23.78

Within a degree or two of ambient - It's good! Seems a shame to throw away the fluid temp (uses identical TESLA_10K sensor to the case temp on SDU), is it worth adding that back in now the mux gremlins are sorted?

Anyway, massive thank-you for persevering with this headache, I'm pleased to be able to go back to the standard firmwares!

[cloudy]

post deleted - see post above

[cloudy]

post deleted - see post above