openinverter forum

johu wrote: ↑Fri Dec 22, 2023 3:39 pm If you find out which is the eclipse (==cubeide) project file we could add it to the repo so people who prefer eclipse can use it with little hassle

When you open a project in STM32CubeIde (or Eclipse IDE for C/C++ Developers), the ".cproject", ".project" and ".SETTINGS" files are automatically created in the project directory (I put them all in the archive). However, I believe it would be better if these files were created individually by the user when opening the project.

I am trying to find out why we statically need 60k of RAM. I have started an optimization branch that omits the various TCP, UDP etc. buffers in favour of pointers that point directly into the ethbuffer. Also makes some memcpy redundant. It's still hierarchical, so ip buffer points into eth buffer and tcp buffer into ip buffer and finally payload buffer into tcp buffer.

https://github.com/jsphuebner/ccs32clar ... ptmization

Ok, mem usage is still 57k so the bulk must be somewhere else

Last post of the year I suppose, happy new year everyone

Happy new year. The memory consumption should be visible in the map file, I guess the structures of the exi codec need a lot.

Yes you're right, the dinDocs take up 25k each
https://www.sikorskiy.net/info/prj/amap/index.html

I guess that's nothing you want to mess with. "EXI is targeted at embedded systems with a small memory footprint"

Yeah, this is a good joke. I think this was written by a professor in theoretical informatics, who never wrote a line of C code for a small embedded system. And from his point of view he is right: "Normal" computers had hundreds of megabytes RAM at that time, so consuming just 100k is a very small footprint compared to this. (facepalm)

Haha, yes Turing machines have infinite memory, right

I have added a test mode: https://github.com/uhi22/ccs32clara/com ... 143438f92b

It lets you test all outputs and I took some precautions that you can't enable it while connected to a charger.

Should we remove the test code that is triggered by the button?

Also it seems the buffer optimization has no adverse effects, should I merge it?

Yes, if we have a better test mode lets kick out the button-triggered. And yes, buffer optimization makes sense.

uhi22 wrote: ↑Mon Jan 01, 2024 6:06 pm ...buffer optimization makes sense.

I agree with this. Maybe you shouldn't worry too much about the lack of memory - just change the controller to a controller like stm32f405rgt6. I don't think it's a big problem. Of course, it may not be the most popular solution

Just to say it clear, to avoid misunderstandings: The currently used application (ccs32clara) and bootloader fits well into the F103RET6 which is used on the foccci board. In terms of RAM, ROM and runtime. The ongoing optimizations are not driven by a lack, they are
- an exercise to see how less is possible
- a preparation to integrate more functionality on one device, e.g. add the ccs software into VCU
- or even use a smaller, cheaper controller than the F103RET6

Thanks to our little project here I was able to snatch Elons free energy yesterday Was in the process of doing a captest of the Nissan battery so that was very convenient

"Zahlen Sie weniger mit eine Mitgliedschaft"!?
do you get money back then?

No, you need to sign the membership before the charging, normally. But we have "Special days" until today: First charge of a new user is free.

Do not do this at home.
Foccci and Clara live in a box together with CCS2 socket, German "SchuKo" and a power bank. RGB LEDs directly soldered on the board.
Test on Alpitronic worked, but not on Supercharger. Next time will take the laptop for logging.

By the way: How big are the chances that a normal 230V-in-USB-out mobile phone charger will work with DC Input?

uhi22 wrote: ↑Sun Jan 07, 2024 3:18 pm By the way: How big are the chances that a normal 230V-in-USB-out mobile phone charger will work with DC Input?

Chances should be pretty high.

Phone Chargers (at least in the last years) are typically Switched-mode power supplys. So they have a bridge rectifier to convert the AC to DC. If you apply DC to the input, only 2 of the diodes (depending on the polarity) will conduct and DC will go through. Even if they have a half bridge rectifier you can just switch the polarity and it should work. So it will just conduct instead of rectifing it and the rest should work normal. Chargers are made to accept a wide range of inputs to make them compatible with the different power grid situation in different countries.


Fun Fact: In some countrys the power outlets you can find on trains are actually DC (and are labeled "X Volt DC. Phone Charging only"). I was a bit confused when I saw this for the first time


You only want to plug the phone charger in your Schuko socket? If you plan to build it into your adapter make sure there is no Voltage left on the input capacitor when you dismantle it (some of the cheaper ones dont have the resistor to slowly discharge it when unplugged). Nearly fried myself when I was younger .



By the way: Seeing your adapter made me realize why you added the "fast blinking" LED to further separete the states
I wonder what kind of reactions you will get when you charge your phone or cook some tea in a charging park on a CCS Charger with your adapter

My first thought was, "probably". Then . . .

f0ld wrote: ↑Sun Jan 07, 2024 5:26 pm Phone Chargers (at least in the last years) are typically Switched-mode power supplys. So they have a bridge rectifier to convert the AC to DC.

RMS 230vac (sinusoidal) = (230*1.41=) 324vdc, so if the SMPS is designed around having >300vdc input, then you might have to have clara ask for a higher voltage than expected. But then . . .

f0ld wrote: ↑Sun Jan 07, 2024 5:26 pm Chargers are made to accept a wide range of inputs to make them compatible with the different power grid situation in different countries.

That caused me to throw out my thought above. If the phone charger is designed to work "worldwide", that would include Japan (100vac/141vdc) and therefore a wide range of input DC will be sufficient.

f0ld wrote: ↑Sun Jan 07, 2024 5:26 pm . . . make sure there is no Voltage left on the input capacitor when you dismantle it (some of the cheaper ones dont have the resistor to slowly discharge it when unplugged). Nearly fried myself when I was younger .

I will NEVER forget "Televideo model 955" (see my alphabetic notation in my repair notes list.) The HV flyback transformer has no bleed resistor by design, and you're only ignorant of this once. It hurt :/

Fun & games
I have tested some SMPS to work down to 60V DC. I think there are very few devices these days that actually need AC. Mind you, anything that has a switch (like a kettle or hair dryer) will arc when turning off via that switch!

On other news I tried the shutdown function with space key of pyPLC but it wasn't reacting? I'm on Linux. Nevermind: I used the noGui version, it only works on the GUI version

Also did some refactoring to remove some redundancies and make the code a bit more compact. It works on the bench, I submitted a PR to have a second set of eyes on it.

Also came to my mind that CHAdeMO has so useful sanity checks: if actual current is x A above requested current for y seconds it will signal a fault. Likewise if battery voltage is more than z V lower then charge port voltage (excessive voltage drop). Could add that check also.

johu wrote: ↑Sun Jan 07, 2024 5:59 pm Also did some refactoring to remove some redundancies and make the code a bit more compact. It works on the bench, I submitted a PR to have a second set of eyes on it.

Yeah, this makes sense. It's a more complex change, so looking with four eyes is good, but also does not see everything. Testing will show how it works.

johu wrote: ↑Sun Jan 07, 2024 5:59 pm Also came to my mind that CHAdeMO has so useful sanity checks: if actual current is x A above requested current for y seconds it will signal a fault. Likewise if battery voltage is more than z V lower then charge port voltage (excessive voltage drop). Could add that check also.

This makes sense. Please including the reporting of the abort reason, so that it is possible to see what was the issue. In best case, store the abort reason also non-volatile, and including a time stamp, so even after driving further it is possible to see what happend during the day.

In Chademo the limits are 10V for voltage drop for 5s and 12A more current then requested for 1s. Should we just roll with that or does the CCS spec say something else?
Could also make it config parameters

I'm not aware that these checks are specified, so yes, we should use config parameters and just take the defaults from the Chademo.

I have few questions / ideas
Are contactor output transistors cooled good enough? I had such problem with zombieverter vcu. There is some space so maybe connect drain to some polygon?
DRV8874 IPROPI output could be connected to analog input to measure actuator current. It could be useful for sockets without lock position feedback.
Is it possible to add more thermistor inputs (my socket has 5 thermistors but 3 phase one would have 7)? I think it would be good to measure temperature of all power contacts of CCS socket, DC + 3 phase AC.

Very good points. In the first version with the NCVs I indeed used more copper area on the drain. This was lost with some changes, and the hope is, that it does not make much difference because anyway the layer below is quite near and distributes the heat. But yes, this is a hope, no fact. Would be nice to make some thermal images under load.
Regarding more NTCs: running out of connector pins. So the options are: use other connector, or share pins (e.g. one pin which can be used either for LED or for NTC).
I will put the topics on the todo list, to further think about them.

Single wire sensors would be a scalable option but of course requires refitting new sensors to the contacts

This looks perhaps to be a use case for an external multiplexing board to translate the sensors' values to CAN, outside the foccci.

Had some test sessions with foccci and clara and the light bulb, including logging the serial. The results are "mixed".
- Alpitronic worked perfect, as usual.
- Numbat glowed the lamp very weak. It was in the charging loop, but the voltage did not reach the expected level. Need to check the logs.
- chargepoint was out-of-order. No authorization was possible with card or app. Nevertheless, the communication was established.
Created a new github repository to collect the logs: https://github.com/uhi22/clara-logs