# v3.1.2 / bootloader v3.2
- asynchronous VESC communication
- support for dual BMS on CAN
- automatic backups
- update & backup made into a separate application
- press a button to reboot in case of a critical error
A few weeks back, there was a small update to the DAVEGA X hardware. The input voltage is changed from 5V to 3.3V.
When the unit connects to WiFi, power consumption increases and that results in a sudden voltage drop. The built-in voltage regulator sometimes does not manage to handle this, which results in the unit shutdown and reboot.
Taking 3.3V directly from VESC prevents the problem. This has been tested with various VESC types and is working well.
The latest orders already received the updated hardware.
An important thing to keep in mind is that the v1.1 must not be accidentally connected to 5V input since that would destroy the MCU. All the new units are shipped with correct cables. It’s still worth double checking since a human error can happen.
Here’s the connection diagram for v1.0 and v1.1 and for various VESC types:
Possibly. There are a few other Metr/DAVEGA (MEGA ) features we have discussed. I’m not sure how much I can still fit into the current DAVEGA hardware. Some of these features may need to wait for the next generation DAVEGA with more RAM. There will also be CAN, which will make it easier for Metr and DAVEGA to talk to each other.
For the most part, this is an implementation detail. Before, DAVEGA would send a request to VESC and idle-wait for the response. This was OK back when it only cared about the VESC data. Now, there are also requests for DieBieMS/FlexiBMS data and Metr data. Plus, there can be two BMSes (Bioboards uses that in their battery pack). In the worst case scenario, it’s already too much idle-waiting for responses and there’s apparent slowdown.
So now instead, DAVEGA sends all the requests to VESC without waiting for the response. It checks for responses after each screen update and if there’s one, the new data is reflected in the next screen update.