ENNOID XLITE & VESC

ENNOID · June 13, 2021, 2:45pm

Sure, let’s do that. I have a few units functionnal, but that I cannot sell due to small damages and still sitting on the shelf

janpom · June 13, 2021, 2:48pm

Is this the firmware you’re using?

ENNOID · June 13, 2021, 2:49pm

Yes, under the ENNOID branch.

Yoodog · June 13, 2021, 2:50pm

is there any eta on XLITE?

ENNOID · June 13, 2021, 2:55pm

Probably end of july approx. maybe even faster if things goes well. Won’t be cheap due to part shortage. Parts are crazy expensive at the moment.
@Yoodog : The other thing is: it is quite odd that some peoples think that a good quality BMS with nice features can be build for nothing… Understand that development process can only be sustained if some profit comes in…also why not paying a bit more to protect the most expensive & important part of your project (battery pack) than trying to go cheap on BMS… Good quality VESC aren’t cheap, so a proper BMS can’t be any different. Both share most components and I might even say that BMS hardware design is even harder.

Yoodog · June 13, 2021, 2:56pm

we will see thanks for info

janpom · June 13, 2021, 3:00pm

I suspect you changed the code of COMM_GET_BMS_CELLS?

ENNOID · June 13, 2021, 3:08pm

Not much if I remember well. I just changed the packet_ID number from 150+ instead of 50+ to remove conflicts with the newest VESC packet_ID There are some new command as well such as: GET_TEMP_AUX & GET_TEMP_EXP. ( temperatue readings of aux channel on LTC68XX IC & external temperature readings from expansion boards). Those new commands are implemented tge same way as get_BMS_CELLS

The serial config for GET_BMS_CONF is very different, but I don’t know if you go that far with functionnalities with davega

janpom · June 13, 2021, 4:19pm

Right. COMM_GET_BMS_CELLS is 51 on DieBieMS and apparently it’s 151 on Ennoid:

github.com

EnnoidMe/ENNOID-BMS-Firmware/blob/ENNOID/Main/mainDataTypes.h#L595


	COMM_ERASE_BOOTLOADER_HW,
	COMM_JUMP_TO_BOOTLOADER_ALL_CAN_HW,
	COMM_ERASE_NEW_APP_ALL_CAN_HW,
	COMM_WRITE_NEW_APP_DATA_ALL_CAN_HW,
	COMM_ERASE_BOOTLOADER_ALL_CAN_HW,
	COMM_SET_ODOMETER,
	
	// ENNOID-BMS specific
	COMM_STORE_BMS_CONF = 150,
  COMM_GET_BMS_CELLS,
	COMM_GET_BMS_AUX,
	COMM_GET_BMS_EXP_TEMP,
} COMM_PACKET_ID;
typedef enum {
	CANIDStyleVESC = 0,
	CANIDStyleFoiler
} CAN_ID_STYLE;
typedef enum {

Should be an easy update at the DAVEGA side. I may not even need a test unit. I’ll draft the update and ask @Prism to test it.

ENNOID · June 13, 2021, 4:30pm

alright! thank you very much! Having EBMS option in Davega 'd be great

Will order a davega eventually once I’ll get time for testing this one day

Prism · June 13, 2021, 4:38pm

I’ll be happy to test it.

Prism · June 13, 2021, 4:46pm

…

ENNOID · June 13, 2021, 4:55pm

Wow, that was fast…

Davega is UART based I think? or maybe CAN?

Should I consider going eventually non isolated for CAN bus? This would allow maybe to get CAN working during charging & ESC is OFF… I went isolated for reliability reasons, but I might reconsider this for future update.

janpom · June 13, 2021, 5:40pm

DAVEGA currently only has UART and connects to VESC. The BMS is then expected to be connected to VESC via CAN so that DAVEGA can access it using VESC’s CAN forwarding.

Maybe we can trade a DAVEGA for an E-BMS. Would be helpful for developments.

In general, if you can still afford making backwards incompatible changes in the BMS firmware, I would highly recommend that you maintain compatibility with the DieBieMS CAN communication as much as possible. There are other esk8 telemetry devices that support DieBieMS – Metr definitely does. Robogotchi might as well. @DRI? If you maintain the compatibility it will be much easier/faster for these devices to enable support for your EBMS, which is a significant selling point for customers in the esk8 world.

JTAG · June 13, 2021, 5:47pm

Eventually I need to update the protocol as well ( to avoid packet conflict with VESC ). I will add a transition period where both offsets are supported.

There is a large update upcoming ( with only no/little protocol changes, no worries ) also with support straight into the VESC tool. I am waiting until Trampa/Benjamin release their next revision of the code / hardware to be compatible with that straight away.

ENNOID · June 13, 2021, 5:58pm

Glad to hear from you Danny, I have some folks working on the code on my side as well. Let me know if you need anything. IMO there is still a lot of cleaning to do in some .c files. Things are hard to modify & troubleshoot in modOperationnalState honestly. The GCC porting is also fully functionnal, not my work by the way…many thanks to @drdrs That GCC porting of the code was necessary I think in order to bring more external contributers to the project. Keil uVision is an expensive piece of software and is not needed anymore.

I also realised that the newest VESC firmware was getting into conflict with DieBieMS, so that explain some changes I made.

ENNOID · June 13, 2021, 6:59pm

Sure, lets do that. PM me for details

Yoodog · June 13, 2021, 8:49pm

sounds very exciting! any open source material to read on upcoming futures and changes on either or both ends? or may be you can share some cool facts to look forward?

ENNOID · June 14, 2021, 11:24am

Starting the testing of those freshly designed 100V|75A ESC this week with my EBMS. Should be good for up to 20S in a 70mm x 75mm x 16mm package. DRV less design with IMU+bluetooth. It does not have one of those failure prone integrated anti-spark switch

Yoodog · June 14, 2021, 1:31pm

75 battery current or phase current?