ESP32 Based Web Interface & Data Logger

[johu]

You could just find the 3V3 trace and cut it, then you have the option to enable it if needed later on.

[Pete9008]

I have similar reservations on WiFi in cars. My approach is to move the ESP32 off board by using a RS485 link from the OI board. This still gives a high bandwidth data link but allows the ESP32 to be positioned for good signal strength and low noise. It also allows it to be unplugged when not needed! I've also added an extra control input to the ESP32 module so that it can either operate in logging mode without the WiFi enabled or in WiFi mode.

The CAN interface doesn't have enough bandwidth to do the fast logging I'm trying to do (although that's possibly more relevant to FOC motor control).

@johu - possibly worth starting a new thread for the CAN based ESP code?

Edit - also worth being careful if just removing the 3v3 supply. You may find the ESP32 tries to take power over the UART lines (via the built in pin protection diodes) which could stress the STM pin while also failing to power the ESP properly.

[Pete9008]

The possible firmware issues identified in another thread today have made me realise that I need to rewrite chunks of the logging code. The current F405 implementation is a hybrid of the two previous versions and runs a lot of the logging in the terminal thread, the issues have made me realise that if there is a problem with processor resource then the terminal thread will be the first to hang and so logging could be lost when it would be most usefull!

I'm going to move all the logging back into the pwm thread to make sure it continues running. By changing the buffer arrangement slightly and optimising the way it uses the DMA it should be possible to do this without any significant increase in the control loop execution time. This does mean it's going to be a little longer before it's ready to be ported over to the F103 though

[Pete9008]

The logging code is now integrated into the auto-setup-withlogging branch on my github. Tested mainly on my F405 build but also on a F103 bluepill board (no motor connected on the later though so can't be totally sure the data is going through correctly but it looks believable).

This now uses a zero copy approach to load the data into the DMA buffers which allows all the work to be done in the pwm task without any real overhead when compared with the old version. It also puts multiple data packets into each buffer (previously was just one) which improves data throughput slightly. Worth noting that even with this the extra spot value byte it is now using pretty much all the available comms bandwidth on the F103.

[Bigpie]

So, to carry this on. I've not got one of Damiens WIP Remote-ESP32-CANLOGGER7500 boards.
I've put https://github.com/Pete9008/esp32-web-interface on there, after burning the efuse

Code: Select all

espefuse.py --port /dev/tty.usbserial-14200 set_flash_voltage 3.3V

Tested working:
SDCARD
RTC

Unfortunately, it doesn't have the RX TX pins from the ESP32 broken out for easy use, but does have 2 can interfaces and some serial interfaces (RS-485/RS-422) which my OI boards don't have. So next need to bodge these on there.

[Pete9008]

If Damien followed my pinout then the RS485/422 should be on the UART you need so the easiest way it to remove that and bring out the UART lines.

Alternatively I do have a spare transceiver here that could be bodged onto your IO board header to make it talk RS422. Let me know if you want it?

[Bigpie]

Done this for now

Looks like he has done that though. When he's back online I'll see if he'll put on github to so I can make some tweaks and send off to JLCPCB for one with fixes on.
Going to put your auto tune branch on this board now and test if it gets logging. Still not figured out the current sensors so can't run it on a spinning motor yet.

[Pete9008]

That looks like it should work

Has Damien moved to Kicad yet?

Seem to remember reading on the wiki that plugging the CTs in before reversing the pinout could damage the sensors, could that be the problem?

[Bigpie]

I've reversed the CT pins before plugging in, so that shouldn't be the problem.
On your branch I've getting invalid JSON back from the json command.

[Pete9008]

Sure that worked here, is that the auto-setup or auto-setup-withlogging branch?

Looks like an issue with the added 'si' field used to decode the spot values. Is it using the right version of libopeninv?

Edit - for the auto-setup-withlogging branch libopeninv should be on version ac64ccc off my github

Edit2 - are the CTs reading 0 with all code versions or just the auto-setup ones?

[Bigpie]

Yep, on that branch. 'libopeninv': checked out 'ac64ccc6b3542fe8f3fc61f5f5c3a1d23a4e7327'
It's able to parse the json command response on stock firmware, will play around some more.

[Pete9008]

Somehow it seems to be treating spot values as parameters (isparam being wrongly interpretted).

Could this be something to do with the recent param_prj.h file changes? Have you replaced the one in the repo with your own?

Will set up my test rig and try it but 99.9% sure it works fine here and git is reporting as up to date with github.

Edit - this is the response I see which looks fine:

response_p.json

(16.13 KiB) Downloaded 60 times

Edit2 - Could you check a couple of bits of your code (both in libopeninv), line 23 of params.cpp should be :

Code: Select all

namespace Param
{

#define PARAM_ENTRY(category, name, unit, min, max, def, id) { category, #name, unit, FP_FROMFLT(min), FP_FROMFLT(max), FP_FROMFLT(def), id },
#define VALUE_ENTRY(name, unit, id) { 0, #name, unit, 0, 0, 0, id },
static const Attributes attribs[] =
{
    PARAM_LIST
};
#undef PARAM_ENTRY
#undef VALUE_ENTRY

and line 261 on of terminalcommands.cpp should be :

Code: Select all

         if (Param::IsParam((Param::PARAM_NUM)idx))
         {
            fprintf(term, "\"isparam\":true,\"minimum\":%f,\"maximum\":%f,\"default\":%f,\"category\":\"%s\",\"i\":%d}",
                   pAtr->min, pAtr->max, pAtr->def, pAtr->category, idx);
         }
         else
         {
            //fprintf(term, "\"isparam\":false}");
            fprintf(term, "\"isparam\":false,\"si\":%d}", spotIdx++);
         }

[Bigpie]

Seems to be loading the params now. Next up, see if I can get binary logging going. I think I must have a naff SD Card, it only mounts 1 in every 5 to 10 boots.

[Pete9008]

What did you change?

Having looked again I think it might have been corruption of the param table in flash (if the min and max values get messed up it will start seeing spot vals as parameters)?

Edit - Not seen that, my SD card mounts fine every time (on both the prototype and proper PCB versions). Do you have the same pull ups as on my schematic?

[Pete9008]

Oops, just remembered on my F405 version I added two lines just before the SD start up, not sure they got pushed to the F103 version (which I'm still running on the prototype hardware so not needed):

Code: Select all

//initialise SD card in SDIO mode
  gpio_set_direction(GPIO_NUM_2,GPIO_MODE_INPUT);  //hardware pull up causes bootload problems so use pullup
  gpio_set_pull_mode(GPIO_NUM_2,GPIO_PULLUP_ONLY); //possibly not needed and probably over ridden by driver
  //if (SD_MMC.begin("/sdcard", true, false, 40000, 5U)) {
if (SD_MMC.begin()) {

These allowed it to run without a pullup on SDIO.D0 which otherwise caused a problem with the bootloader. Might be worth adding them to see if it helps with the SD issues?

[Bigpie]

That seems to have done the trick, its mounting every time

[Pete9008]

Sorry about that, those two lines completely slipped my mind. Guess that they are actually needed then!

[johu]

Got mail.
This is the modified ESP32 CanLite from which I removed the 12V high side drivers and replaced them with an SD-card slot. Also rerouted the pins to be compatible with Petes and Damiens design. As you see it also comes with a nice printed enclosure.

It only communicates via CAN so won't be able to do any real time logging but therefor will be able to talk to all openinverter devices on your bus, provided you took care of your node ids. Node ID is selectable in the web GUI. I have finally merged chrskly's better looking web interface. Only downside it's a bit wide for phones.

https://github.com/jsphuebner/esp32-web-interface

Will put it in the shop soon.

[johu]

And it's for sale https://openinverter.org/shop/index.php ... duct_id=78

[Leo M]

When composing a sketch, it returns an error. Maybe I don't understand something. Please enlighten me)))

[johu]

It must be something with the compiler version, it doesn't seem to understand the overloading.
Can you try to compile with platformio? Arduino I haven't tried.

[Leo M]

In the description on the git hub, you posted instructions for arduino) I'll try it on the Platformio…

[Leo M]

Platformio is good ))

[johu]

Good. I guess we'll remove the Arduino instructions to have less things to keep alive.

On other news I tested the device on my very busy Touran CAN bus and that wasn't very good. As soon as it starts transmitting the CAN bus is disturbed, i.e. ABS light comes on and other indicators. Even a permanent airbag fault developed. Maybe it doesn't properly back off when loosing arbitration?

[Bigpie]

I get the same can message corruption on my ESP32 based BMS, the messages have CRC though so I can junk rubbish messages but yea, lost confidence in ESP32 for can projects.