openinverter forum

Posted: **Tue Nov 25, 2025 1:01 pm**

dennist wrote: ↑Tue Nov 25, 2025 12:53 pm again what do you think guys?

I think there should be a good reason to break backward compatibility. Why do you want to do these changes?

Posted: **Tue Nov 25, 2025 2:16 pm**

dennist wrote: ↑Tue Nov 25, 2025 12:53 pm Hello again!
I have looked a bit deeper on the current schematic.
what i have found:
Pin mapping on stm32 is sub optimal. changes also need changes in software.
CAN RX/TX from PA11/12 to PB8/9
add usb on PA11/12 Debuging without CAN / Firmeware upgrade without flasher hardware
LED_alive from PB7 to PC13
i2c on PB6/7 (for isolated messurement of HV Bat voltage.) Security reason, I don't want high voltage on the 12V ground same as chassi. its a risk

again what do you think guys?

edit
ah i see the hv input is a 5v input for a external device. but anyway think integrated is better.

Posted: **Tue Nov 25, 2025 5:00 pm**

There has never been a non-isolated voltage measurement, and no one has suggested one. USB can help if the board is accessible. That's not the case for me because it's in the battery box. At least for me, your changes are uninteresting, and I would have a problem with the lack of backward compatibility.

Posted: **Sat Nov 29, 2025 3:03 am**

Glad to find this community. I was wondering if someone could share the latest FW version available for the QCA7000, version QCA7000 MAC-QCA7000-3.2.0.20-00-20221002-CS in particular.

Posted: **Wed Dec 03, 2025 5:00 am**

Do we know a kind of change log which explains the differences between the available 2014-08-15 and the wanted 2022-10-02?

Posted: **Wed Jan 07, 2026 8:00 am**

Analog input problem:
In the user thread (https://openinverter.org/forum/viewtopi ... 744#p88744) it was discovered, that the ADC value for the temperature inputs are quite off, which leads to temperature error of ~40K.
I can reproduce this issue on my desk. When connecting 1082 ohms to the temp1 input, I measure 322mV on the divider, but the ADC input of the controller has 355mV. The expectation is, that the ADC input does not drive a significant current, but this is obviously not fulfilled.

: adc input voltage corrupted by series resistor

To be found out: What is the reason for this current? Is it a solution to reduce the 47k series resistor? Or is it a configuration issue?

[Edit] The 33mV voltage drop over R32 disappears if we hold the microcontroller in reset. This means, that the leakage is inside the controller, and not caused by external things like flux on the PCB.

[Edit2] Potential root cause: The sample-and-hold circuit contains a small capacitor. When converting multiple channels, this capacitor is switched from one channel to the next via the analog multiplexer. Each time, a small amount of charge is transferred from one channel to the next. If the multiplexing happens at a high rate, a small capacitor can transfer a significant amount of charge. To be checked: What is the predecessor channel of the temp1? At which rate are the channels switched?

Posted: **Wed Jan 07, 2026 9:06 am**

Root cause confirmed: Removed the 100nF parallel capacitor on the ADC input. Now we see each sampling event. Sampling is done in 20 microseconds interval. This is very fast.

This is much faster than needed.
Next step: check the ADC configuration. 10ms cycle is fast enough for our use case. Also check the sample duration.

Posted: **Wed Jan 07, 2026 10:01 am**

In anain_prj.h you can set SAMPLE_TIME to ADC_SMPR_SMP_239DOT5CYC

That should slow down sampling speed by a factor of 11

Posted: **Wed Jan 07, 2026 10:47 am**

Factor 11 would reduce the voltage drop over the series resistor from 33mV to 3mV. This is the right direction, but still 4 LSB. I would be happy If we could go with factor 50 or 100.

Posted: **Wed Jan 07, 2026 11:18 am**

Isn't 7.5 to 239.5 a factor of 34?

Posted: **Wed Jan 07, 2026 12:27 pm**

What's a double adc read, discard the first, use the second read give for consistency / target? This would throw away the carried charge from the previous channel-itself for the good read.
I would expect the parallel capacitor would have helped, too small?
Could add an opamp if needed.

Posted: **Wed Jan 07, 2026 4:34 pm**

uhi22 wrote: ↑Wed Jan 07, 2026 10:47 am Factor 11 would reduce the voltage drop over the series resistor from 33mV to 3mV. This is the right direction, but still 4 LSB. I would be happy If we could go with factor 50 or 100.

4 LSB is about the noise floor. Next thing would be reducing ADC clock frequency or...

jrbe wrote: ↑Wed Jan 07, 2026 12:27 pm What's a double adc read, discard the first, use the second read give for consistency / target? This would throw away the carried charge from the previous channel-itself for the good read.

This is exactly what I do in the inverter firmware when reading the resolver with injected channels. Helps a lot. With regular conversions it's harder to implement, as it steps on every sample instead of reading the same channel N times. That said Foccci uses the average of 4 medians for each channel, so it's quite likely the first sample is kicked out by the first 3-median.
Finally there would be the possibility to set NUM_SAMPLES=64 which is simply the average over the last 64 samples.

muehlpower wrote: ↑Wed Jan 07, 2026 11:18 am Isn't 7.5 to 239.5 a factor of 34?

You have to add 13.5 or something (the conversion time), so 7.5+13.5 vs 239.5+13.5

Posted: **Wed Jan 07, 2026 5:21 pm**

I believe the STM32F1 has a 12-bit ADC converter. The voltage range for a PT1000 with 10k at 3.3V is 0.1V. That means 124 digits for 0° to 100°. About 1 digit per degree C°. Not great, but sufficient to estimate the contact load. Despite the deviation of 25°, I did not observe any significant fluctuations, so setting ADC_SMPR_SMP_239DOT5CYC and a correction with an offset factor is probably sufficient for this purpose.

Posted: **Wed Jan 07, 2026 5:42 pm**

johu wrote: ↑Wed Jan 07, 2026 10:01 am In anain_prj.h you can set SAMPLE_TIME to ADC_SMPR_SMP_239DOT5CYC

Done. This increases the round trip time of the ADCs to 252µs. It reduces the voltage drop over the series resistor from 33mV to 2.7mV.
With this change, the PT1000 input on Temp1 look half-way plausible:
1.3°C at 1000 ohms (expected: 0°C)
22.2°C at 1082 ohms (expected: 21°C)

Binaries: https://github.com/uhi22/ccs32clara/act ... 0790467927

A little bit more improvement would be possible by more slowing down the AD sampling, to further reduce the current which is pumped by the sample-and-hold capacitor through the series resistor. But from my understanding this would need a bigger change, to stop using the continuous conversion. Maybe it is possible to configure the ADC list as single-shot and trigger it from a 10ms task or something like this.

[Edit] With the current solution, there is still a cross coupling from Temp1 to Temp2 of 3Kelvin, if the Temp2 is configured as PT1000 at 21°C and we change Temp1 between open-circuit and ground. The voltage drop over the 47k series resistor of Temp2 changes from 4.2mV to 1.4mV in this case.

Posted: **Wed Jan 07, 2026 6:11 pm**

Yes indeed the ADC prescaler is already maxed out at 8 in the 72 MHz default config, setting the ADC frequency to 9 MHz. So no more headroom there.

I see some more possibilities but these would need resistor value changes:
1. Lower R32 to 10k
2. Allow putting 2k2 in series with R31 with solder jumper and assume this to be closed for PT1000 or other low resistance probes
3. Lower R31 to 1k2 (like inverter) and increase hardware version number to handle it

1 is most straight forward as it requires no software change at all and can simply be done by piggy-bagging a resistor on existing hardware. 2 would need solid documentation which is perhaps not read and 3 would only work in the next revision, unless people swap in different resistors for R31 and the version resistor

Posted: **Wed Jan 07, 2026 6:15 pm**

jrbe wrote: ↑Wed Jan 07, 2026 12:27 pm What's a double adc read, discard the first, use the second read give for consistency / target? This would throw away the carried charge from the previous channel-itself for the good read.
I would expect the parallel capacitor would have helped, too small?
Could add an opamp if needed.

The problem which we have is a different one. Let me explain.

One usual issue is, that there is a series resistor before the microcontroller, and this slows down the charging of the sample-and-hold capacitor. If this is the case, it makes sense to take two (or more) samples, to get a more precise inrush to the final voltage. And it helps, to add a parallel capacitor, so that the charge for the sample-and-hold capacitor comes from the strong parallel C, instead of the weak series resistance. In Foccci, we considered this issue, by having a 100nF parallel C on the analog pins. This is much more than the some picofarads internal S&H cap. And is not our problem.

The actual observed issue is, that during each sampling, a certain amount of charge is pumped, depending on the difference voltage between the previous channel and the current channel. This amount of charge is small (some picofarads with some hundred millivolts), but it is repeated. A higher external capacitor does not solve this, because it only leads to longer inrush (let's say 5 seconds instead of 1 second), but the voltage will rise, until the current flow through ther series resistor is equal to the current flow injected by the S&H cap. This is what we measured with 33mV over 47kohms. If we half the pump rate, we get half the current, and in turn half the voltage error. So the solution is, instead of pumping each 50µs, pumping at a much lower rate.

Adding an op-amp to create a low-impedance signal path would be also a solution, yes. But since we do not need high bandwidth, the slower sampling is the cheaper solution.

Posted: **Wed Jan 07, 2026 6:20 pm**

johu wrote: ↑Wed Jan 07, 2026 6:11 pm I see some more possibilities but these would need resistor value changes

I'd prefer to NOT touch the hardware as long as we have a chance with software changes.
Do we have a kind of design documentation / explanation how the ADC channels together with DMA are working at the moment?
I can imagine to re-arrange the ADC handling in a way, that the conversion is software-triggered instead of continuous, but it is not clear how this will affect the DMA and the result buffer evaluation.

Posted: **Wed Jan 07, 2026 8:44 pm**

Yes I agree with this approach in general.
On the other hand, even with slower sampling the accuracy would still be poor because the dynamic range of the ADC is hardly used. Changing R31 would improve on that and we have a clean way to handle the change with the version resistor.

The software gets a bit messier with the manual approach, however it can be implemented without touching the AnaIn class by using injected conversion like here: https://github.com/jsphuebner/stm32-sin ... r.cpp#L447 (forget about timer trigger in our case)

The injected sequence (which can contain 4 channels) would be temp1, temp1, temp2, temp3 and the first temp1 is discarded

I would argue that the current approach with slower sampling is "good enough" for legacy boards and the cleaner solution for future boards would be changing R31.

EDIT: what happens if you add a dummy channel between "tempi" and "temp1" that also samples Pin C0?

EDIT2:

uhi22 wrote: ↑Wed Jan 07, 2026 6:20 pm Do we have a kind of design documentation / explanation how the ADC channels together with DMA are working at the moment?

Of course not

But it's simple.
The ADC uses a circular buffer, length is channel_count*sample_count
So if you have 4 channels c1, c2, c3, c4 and 3 samples the buffer is c1, c2, c3, c4, c1, c2, c3, c4, c1, c2, c3, c4. Get() would in this case return the median of the 3 samples. This all happens autonomously in the background via DMA
There is a dual mode which samples at twice the speed where ADC1 samples the odd channels and ADC2 samples the even ones. Memory layout is the same. Maybe it would be a solution to put all temp channels on ADC2. Want to try?

Code: Select all

#define SAMPLE_TIME ADC_SMPR_SMP_239DOT5CYC //Sample&Hold time for each pin. Increases sample time, might increase accuracy
#define ADC_COUNT 2

//Here you specify a list of analog inputs, see main.cpp on how to use them
#define ANA_IN_LIST \
   ANA_IN_ENTRY(lockfb,GPIOC, 5) \
   ANA_IN_ENTRY(ipropi,GPIOA, 3) \
   ANA_IN_ENTRY(pp,    GPIOA, 0) \
   ANA_IN_ENTRY(temp1, GPIOC, 0) \
   ANA_IN_ENTRY(udc,   GPIOC, 3) \
   ANA_IN_ENTRY(temp2, GPIOC, 1) \
   ANA_IN_ENTRY(button,GPIOC, 4) \
   ANA_IN_ENTRY(temp3, GPIOC, 2) \

Have removed tempi, we never used it. We need an even number of channels for dual mode. Now ipropri which is constant in most cases is always before temp1

Posted: **Wed Jan 07, 2026 9:29 pm**

uhi22 wrote: ↑Wed Jan 07, 2026 5:42 pm [Edit] With the current solution, there is still a cross coupling from Temp1 to Temp2 of 3Kelvin, if the Temp2 is configured as PT1000 at 21°C and we change Temp1 between open-circuit and ground. The voltage drop over the 47k series resistor of Temp2 changes from 4.2mV to 1.4mV in this case.

Would it help to connect unused temp channels to ground with 1k? I think that would be reasonable and would result in 0°, which does not yet play a role in necessary power reduction.

Posted: **Wed Jan 07, 2026 9:39 pm**

Yes, use Temp1 as unused with 1k, then the Temp2 and Temp3 would have slightly better accuracy. But in the end it is good enough anyway.

Posted: **Fri Jan 09, 2026 9:39 pm**

New attempt with 44.122. temp1 is connected to ground with 1k, temp2 is room temperature, temp3 is 40° water bath. temp1 has 0.302V, temp2 has 0.330V, temp3 has 0.341V. Should display 3°, 29°, and 40°!

edit:
My mistake, it was set to NTC. With the pt1000 setting, I get about 5° too much displayed for all three values.

Posted: **Sat Feb 14, 2026 3:46 pm**

https://openinverter.org/forum/viewtopi ... 700#p89700

There is discussion here that PWM will gradually disappear when charging AC. In the long term, this will be a job for foccci. Could AC charging with PLC be implemented in such a way that it looks exactly the same as it does now to the outside world (to the vehicle)? Output PLC data translated into 10% to 90% PWM via CAN. Also the cable limit, regardless of whether it is determined by resistance or via PLC.

Posted: **Sat Feb 14, 2026 3:54 pm**

One more question. MAC addresses are currently used to identify cars. Which one is used by focci, and can I assign any address that I know is unique, e.g., from an old network card?

Posted: **Sat Feb 14, 2026 4:26 pm**

muehlpower wrote: ↑Sat Feb 14, 2026 3:46 pm Output PLC data translated into 10% to 90% PWM via CAN. Also the cable limit, regardless of whether it is determined by resistance or via PLC.

That should be easy to do if we have info on how the Comms for AC charging works. Not sure what ISO protocol is used for that and if there is public info out there on it.

muehlpower wrote: ↑Sat Feb 14, 2026 3:54 pm Which one is used by focci, and can I assign any address that I know is unique, e.g., from an old network card?

I believe right now its hard coded in the homeplug.cpp

Code: Select all

62 uint8_t myMAC[6] = {0xFE, 0xED, 0xBE, 0xEF, 0xAF, 0xFE};

Should be easy enough to ammend, I will need to do it for a dual CCS charging test setup (Testing an EVSE not on one vehicle)

Posted: **Mon Feb 16, 2026 9:23 pm**

No. The "feed beef"-MAC address is only an initial default value, for the case no other address is set. Actually, we set the MAC depending on the serial number of the STM32, here: https://github.com/uhi22/ccs32clara/blo ... n.cpp#L138
If it is necessary, we could create parameters to set the MAC address via the web interface. And then, yes, anyone could use a "unique" MAC address of a network card or whatever.

openinverter forum

Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?

Re: Develop a QCA7000 board?