I like that. I’m thinking that aligning all the numbers at the decimal point would improve readability. The labels could maybe be right aligned. Something like this:
38.94 km/h max speed
17.43 km/h avg speed
0.14 A motor amps
0.00 A battery amps
43.70 V min pack volt
4.10 V avg voltage
3961.00 mAh capacity
29.00 °C VESC temp
NONE fault code
or maybe labels on the left are actually better if everything is aligned nicely:
max speed 38.94 km/h
avg speed 17.43 km/h
motor amps 0.14 A
battery amps 0.00 A
min pack volt 43.70 V
avg voltage 4.10 V
capacity 3961.00 mAh
VESC temp 29.00 °C
fault code NONE
I’m more a fan of left side numbers but let’s see what other think about it. Spacing will an issue in large font mode, will probably need more abbreviated labels.
Hi ive built a screen using an arduino nano and a 2.2 inch screen that ive got connected to a flipsky 6.6 dual vesc. But im having a problem with connection the data led is flashing away on the nano so pretty sure there is a signal there screen is stuck on first screen with red flashing and buttons not working im running the latest stock vesc firmware .48 is this compatible or do i need to roll back to an older firmware.
Edit: I have about a meter of shielded usb cable to connect from vesc to nano could this be too long ?
I did the check for SmartRing : 3 FET temperatures have been added at tthe end of COMM_GET_VALUES.
Depending on your library, if end of packet is ignored, that could work.
(Did’nt test it though, I switched to COMM_GET_VALUES_SELECTIVE)
The problem is that I do check the CRC and that’s probably trimmed. So I suppose it doesn’t work out of the box. The COMM_GET_VALUES_SELECTIVE sounds like the way to go.
Is the CRC dependant of the payload content in your library ?
The one I used (forked from @solidgeek) don’t care about the payload content as long as the calculated CRC matches the read one.
Need to give a try though.
COMM_GET_VALUES_SELECTIVE is really great and should avoid bringing big update each time.
COMM_GET_VALUES_SETUP(_SELECTIVE) may gain your interest for coulomb counting also !
Hm, I can’t see how a library has a choice in that. The CRC is computed from the payload so if you don’t have the payload you can’t compute the CRC. Am I missing something?
I probably won’t use it because of backwards compatibility (I don’t want to implement features that would only work with the latest VESC FW), but it looks pretty neat. Thanks for pointing it out.
Sorry, I wasn’t clear enough.
I meant, the CRC computation doesn’t care of the meaning of each byte of the payload. It computes it based on the values.
So once the CRC is checked and verified, the library pushes the payload to the parsing process.
During it, if you don’t parse all the packet and ignore the end, there is no difference between FW3.40 and FW3.48. The only difference between both is some values added at the end of the payload.
Not sure I’m clear enough in my explanation.
Sorry for that.
Really wish i understood what you guys are talking about as it sounds like you know how to get it running on .48 and id much rather stay on that than use the older firmware
Right, makes sense. The problem is that with Arduino you have the 64 bytes UART message limit and even with FW 3.40, the last byte of the response to GET_COMM_VALUES gets trimmed. That’s not a problem though since that’s the “message termination” byte and it’s not at all important. However, with more bytes added to the payload more bytes at the end of the message will be trimmed, namely the CRC bytes. You should still be able to parse the message and maybe even compute the CRC. You just won’t have anything to compare it to.
With @Solidgeek 's library, Arduino can handle packets >63 bytes (by emptying the buffer while receiving data).
But anyway, old story now with COMM_GET_VALUES_SELECTIVE (unless you need a big amount of data, this command reply back also with the 32 bit mask after COMM_PACKET_ID, so only 53 useful bytes).
Ah, I looked at the code and also read up a little bit on the 64 bytes limit since I didn’t understand the code at first. It’s actually pretty straightforward. You just need to wait a bit for the data. Something like:
while (Serial.available())
Serial.read()
will only read what’s in the buffer. However, something like this will read all:
long start = millis();
int timeout = 100;
while (millis() - start < timeout) {
if (Serial.available())
Serial.read();
}
Good to know. Maybe an easier way for me to support the 3.48. Thanks!
@Bbaldrickk@Wainecaplin I spent a little bit of time on the Dave FW today. This version might work with VESC 3.48. I haven’t had time to test it with 3.48. I merely verified that it still works with 3.40. IMO there’s a pretty good chance it will work with 3.48 though. If you don’t mind being guinea pigs, please give it a try. It definitely won’t break anything. In the worst case it just won’t work. One thing you could try in that case is going to vesc_comm.h and changing
as it sounds like you know how to get it running on .48 and id much rather stay on that than use the older firmware
