I’m looking to make my own home-made dashboard (like a DaveGa but using e-paper) and I was hoping that extracting serial data from the Unity would be as simple as attaching to TX and GND pins on the COMM connector and all the data I ever wanted would just start streaming out.
Unfortunately that didn’t happen.
Is it possible to generate a data stream on that port? Or am I not understanding its intended use?
Thanks,
I’ve been spelunking in the vesc and os davega code recently.
It looks like you have to construct a packet and send it to the vesc to request data.
Then you have to grab the bits coming back and parse it into meaningful data.
Edit
The vesc code is pretty messy and very lite on documentation. There is an outdated blog post on vedders website that shows the basics of how it works
That makes sense. I did find the packet structure in some DaveGa code here:
in case it helps you out
uint8_t GET_VALUES_PACKET[] = {0x02, 0x01, 0x04, 0x40, 0x84, 0x03};
This should do it but I get no response. I’ll keep digging.
Not without continuously requesting data. But the can bus will continually send status data. If you got a can converter is possible to read all the data this way.
Make sure you have UART enabled on the VESC.
I actually had plans myself to do a DAVEGA with an e-ink display but I abandoned the project. There are several issues:
These are some things to consider before you go down the rabbit hole.
Yeah I found that but was having trouble figuring out the packet structure and what each byte of the array meant
@janpom nailed it - turning on UART opened up the floodgates.
Now I send the {0x02, 0x01, 0x04, 0x40, 0x84, 0x03};
and i get back (hex):
2 54 4 0 DF 0 DE FD 56 FD 5F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 1 2D 0 0 0 0 0 0 0 0 0 0
Questions:
Is there any indication that having PPM and UART enabled at the same time causes problems?
how long did it take before the ghosting appeared? That could shut the whole thing down quickly.
Interestingly I have the opposite goal - something that I can read in bright sunshine. I almost never ride at night.
This is the one I got:
This will allow me to display battery V, Amps and current speed in a very large font.
I got it for a different project, but that project doesn’t seem to be getting much traction so these are kicking around my desk.
You’re right that the refresh rate sucks, but I’m not sure I look at the thing more than once every few minutes anyway.
Thanks for your help!!
No, but if you send any throttle commands over UART while a PWM/PPM signal input is active they will conflict. UART telemetry requests + ppm for throttle input = good to go.
What MCU are you using?
Thanks for the heads up. I’m only going to query once every second or two.
I’m using a Teensy 3.2, which is my go-to processor. It’s a bit power hungry for this job - I’ll slow the clock down and see if I can get some semi-sleep in between reads.
Eink has very poor refresh rates. 2hz is amazing. Two refreshes a second you got from the eink display? I’d love to see a video that sounds really cool.
I did a quick test, doing a full screen refresh I get about 2.4 seconds.
This brings up the idea of displaying average and instantaneous, like within a 5 second interval display both the average and peak current, average and peaks speed, etc.
Ok, here’s what I came up with.
When RPM is zero it gives me trip stats
When you’re rolling it gives you max and average, and alternates between battery V and battery %
(CLEARLY there’s something wrong with my maths - the average is higher than the peak)
Some character spacing issues but I want to get it on the board and do a road test to make sure something obvious isn’t missing before I spend a lot of time calculating positioning.
And under the heading of feature creep
Because batteries aren’t linear in their discharge curve I want to use a table lookup to more accurately represent the % figure. so from 40v to 39v maybe that’s 8 % whereas from 33v to 32v that might be 15%. I’m sure someone’s already figured this out I just need to find the table or formula (pointers welcome!)
Distance to Empty. I’d love to calculate the number of miles I have left before the battery is exhausted, using the above formula for more accuracy.
miles per hour is “mph” not “MPH”
I believe the discharge curve would vary based on the cells you’re using. What cells are you using?
Awesome work, this is a really cool project!
I think they are NCR20700B’s. I assume most LiIon’s have the same or very similar discharge curve. I did a cursory google and didn’t find much.
@b264 good catch, lower case will save me some screen real-estate.
The basic shape is roughly similar between different Li-Ion cells but the voltages can vary by a lot depending on how much current you will be drawing and whether you are interested in the voltage-under-load (when being used, with voltage “sag”) or the resting voltage (when not being used).
Those voltages can also vary considerably.
Here are my under-load discharge curves for the NCR20700B: Sanyo 20700B 4000mAh 20700 Bench Test Results...a peek at the future? | E-Cigarette Forum
so based on your graph here
it’s surprisingly linear once you get past the initial sag.
The easiest way to fit a formula to it would be to not start the DTE until the cell drops down below 3.75V and then go linear.
Thanks!
Yea, it’s really just at the start and end of a discharge when the curve goes sharply non-linear.
