openinverter forum

Got a large parcel from JLCPCB today, I think I ordered them just a week ago. They get faster every time!

So amongst them is the new Leaf adapter board with its integrated ESP32. So grabbed Petes ESP32 port (the other one didn't work for me at all). First thing I found it is using Serial2 for inverter comms. Bummer, I wired up Serial1.

So changed the code accordingly, removed all debug output (hmm, could have just moved it to serial2) and I'm now getting replies from the inverter but it's missing large chunks of data, especially noticeable on the json command.

Have you run into this problem? How to cure it? I found the question on the web with no success reported and also you state that the implementation doesn't use DMA.

Needless to say the little brother 8266 handled serial data just fine at 1 Mbit/s

My code uses the espressif api directly for the inverter comms and only uses the arduino library for debug. The arduino comms library is shockingly slow. If you swap the ports you need to keep using the espressif api calls on the inverter port.

Esit - it should be possible to just swap the port definitions when you open them (fairly sure there is a #define for the inverter port) without needing any major code changes.

Ok, I see. So went back to your version and only changed
According to https://www.espressif.com/sites/default ... eet_en.pdf page 9

Now I'm one step further. I listen to the inverter return data upon reset and I see Then I change baud rate to 921600 on my terminal to find the ESP32 still sends its commands at 115200. I wonder if it power cycles for some reason

EDIT found that one. uart_readUntill() and uart_readStartsWith() was using UART_NUM_2 hard coded. I see the json reply from the inverter now but it doesn't end up in my browser

Seem to remember using a different command to change the espressif api baud rate. Its possible that I forgot to use the #define in it?

Edit - its on line 505 - looks ok so not sure what the problem is, it worked fine on uart2

johu wrote: ↑Wed Nov 02, 2022 4:36 pm EDIT found that one. uart_readUntill() and uart_readStartsWith() was using UART_NUM_2 hard coded. I see the json reply from the inverter now but it doesn't end up in my browser

Oops, must have missed those, do a search on the uart functions and see if any others are still hard coded

All good, it was another hard coded UART_NUM_2 when reading the data. Now it works

On to firmware update. At least that worked when I had it running via the Serial class and it no longer works with the API calls. By not working I mean it sends corrupted or incomplete firmware.

Not that surprised, there were a lot of untested edits to those functions to move to the api calls

Yep, found it: Don't format page size to a string, just send it as a byte.

I'm fairly impressed with the ESP32 and your port. It seems to react a lot faster, especially establishing the connection is quicker.

Do you want me to pull request?

EDIT: this is my 4000th post, first time I notice a round number

johu wrote: ↑Wed Nov 02, 2022 4:57 pm I'm fairly impressed with the ESP32 and your port. It seems to react a lot faster, especially establishing the connection is quicker.

Do you want me to pull request?

Never been too keen on the esp8266 but the esp32 does seem a much nicer device to work with. I assume its down to not having to share a slower processor with the wifi stack?

Not too sure sure what that means, is that pulling your changes to my repo or the other way round? Either way can do. Think Bigpie has made a few more changes to the webpage that aren't on github yet too.

johu wrote: ↑Wed Nov 02, 2022 4:57 pm EDIT: this is my 4000th post, first time I notice a round number

That's what I thought but now I found I can't fork your esp32 repo because you forked it from my esp8266 repo and I can't fork back
So no pull requests for now.

Oh one thing I found in this one https://github.com/Bedz01/esp32-web-interface-port I think only then does the web server run on its own core?

My understanding (disnt spend much time on it though so could well be wrong) is that as standard all user code (including the web server) runs on one core and the wifi stack on the other. You can choose to run a task on the either processor if you want (and it looks like that is what is being done there) but I think you then have to start putting mutexes around any shared resources. Since it seemed to run quite happily with everything on the one processor I left it that way.

Ok understand. Then lets not touch that

Just a thought, I did try using that port to start with but couldn't get the web server to work at all, wonder if that was why?

Careful not to trample on the wifi stack, safest just to leave that core alone if you're relying on OTA

Can do multiple xTaskCreate's on one core though, if that's any help.

You mean while you still went via the Serial class?

Hadn't made any changes at all, just couldn't get the web page to work.

Turned out that porting the 8266 code was pretty simple so went that route instead.

Bigpie wrote: ↑Mon Oct 24, 2022 2:38 pm Just had 70kw :O hope the logs are working.

Is 70kW still the limit for you? If so any idea what is limiting it?

Your motor parameters seem virtually identical to the Outlander rear and when I simulate that I get almost a 100kW This is with a 350V battery voltage which I think is near enough to yours?

Edit - oops, meant to post this in the simulator thread

I've not had chance to mess around again yet, I'd stolen the esp32 for something else at the moment but one arrived in the post today so can start logging again.
I know the front is a lower torque to the rear I think 60kw 120nm vs 70kw 200nm based on Mitsubishi information.
I did briefly try upping the throtcur value to 4.7 (currently 4.5 I think) and that seemed to work on my show test drive but didn't have my phone on showing my shunt data and the boot was open with a desk hanging out the back

My battery is 96s so around 355 nominal

Bigpie wrote: ↑Wed Nov 09, 2022 5:18 pm I've not had chance to mess around again yet, I'd stolen the esp32 for something else at the moment but one arrived in the post today so can start logging again.
I know the front is a lower torque to the rear I think 60kw 120nm vs 70kw 200nm based on Mitsubishi information.

That could explain the difference. It would suggest that two motors have significantly different flux linkage values despite the inductances matching? Next time you're logging try to include a coast so that we can work the flux linkage value out.

Bigpie wrote: ↑Wed Nov 09, 2022 5:18 pm I did briefly try upping the throtcur value to 4.7 (currently 4.5 I think) and that seemed to work on my show test drive but didn't have my phone on showing my shunt data and the boot was open with a desk hanging out the back

Not the ideal setup for a power run!

and issues... With or without the extra pullup resistors. I had to do the flash efuse thing with this ESP32

I'll try different cards and boards tomorrow

Currently in the process of generating the json from BINLOG_LIST. Now I found a somewhat redundant format:
Would you mind if I changed that to
Easier to generate and kindof like the other "json"
Also for easier generation I'd like to change "signed" and "unsigned" to "int32_t" and "uint32_t", ok?

Losing the 01, 02, etc will break the decoder. It started off without them but unfortunately the qt json handling functions lose the order of all the json fields, and just order them alphabetically, so it needed the the extra field to force it to retain the order. The alternative would be to rewrite the decoder in something else that retains the field order.

Prefer the signed flag as it doesn't imply an incorrect bit width but if you can't make that work then the _t types would be ok. The decoder would need changing to match.

Ah yes, that makes sense.

How about that one: That should definitely be sorted

I tried various formats, which I think included that, but couldn't find a way to make the qt libraries retain the order without the extra number. Found a few forums suggesting various class overloads or source code changes but no real solutions.

If you want to go that route it will need a decoder writing in something else (probably not a bad thing, the qt version was just a quick bodge to test if everything else worked and could do with tidying up and command line arguments adding at the very least.