#Waveshare 4" 480x480 OBD CAN dashboard for vehicles

93 messages Β· Page 1 of 1 (latest)

mossy flame
#

Waveshare 480x480 S3 display configuration figured out! This is going to monitor the CAN traffic of a BYD E6 electric car and compute the kWh etc since those numbers are not shown on the dashboard.

pale whale
mossy flame
#

Yes! Waveshare makes good hardware πŸ™‚ sometimes the lack of general purpose IO can be an issue with these boards but if you can use the RS485 / CAN they are nice solutions.

#

I really like that these newer ones have the touchscreen glass larger than the PCB with adhesive on the edges so you can stick it into a 3d printed enclosure completely flush.

pale whale
#

we just need to find a volunteer who will implement NMEA2000 and ISO 15765 πŸ˜› (we already have CANopen via an external component πŸ™‚ )

mossy flame
#

Ya if that fits your needs go for it, I want custom enclosures usually 😁

#

I am using the built in CAN library to decode these automotive frames, will test tomorrow

sacred cipher
#

My 7” also got CAN

mossy flame
sacred cipher
pale whale
#

just take its schematics and create the mapping in your config πŸ™‚ but sure, it is easier when you can just take a config without thinking, but this should not be the case if you are playing with LVGL

sacred cipher
#

with a few minor changes. it worked i have to add

#

but further discussion should not be here

mossy flame
#

Great! Ya this one needed a few changes too, will share it later..

pale whale
#

I am just waiting (as I am lazy :D) for some CAN related stuff πŸ™‚

sacred cipher
#

i'm lazy and unsecure hence i ask alot

broken slate
#

I'm using the Waveshare 4.3B board for exactly this application. Currently just have it capturing engine RPM but have more planned.

sacred cipher
#

read fault codes ...resetting service light ?

broken slate
#

All possible, but needs coding. The display will also be reporting other data like house battery status, tyre pressure.

sacred cipher
#

you drive a Volvo i hope

broken slate
sacred cipher
#

me neither but still i drive a Volvo....wierd but true

broken slate
#

A long time ago I owned two Volvos at the same time - a 244 sedan and a 240 wagon.

sacred cipher
#

clssics....lovely cars

#

in sweden we call them wagons 245's

#

5 for 5 door

broken slate
#

Yeah, the 240 came out after the 244 and 245 - for some reason they dropped the number of doors from the model number.

sacred cipher
#

i would love to wire that 7" display to my Volvo but i face the reality of not having the knowledge

broken slate
#

I am pretty sure the Volvo will have J1979 (OBD-II) CANBus support so stay tuned.

mossy flame
mossy flame
#

I'm learning more about CAN.. at first I was surprised by no signaling out and the 1 second blocking by the CAN component - realized it's caused by no response being received by the CAN component basically makes it wait a whole second. And if the buss is not actually connected to anything else it just looks like it's timing out blocking for a second each time.. anyways just wasn't what I expected at first but I'm glad I understand the hardware / firmware layer more now.

broken slate
#

The CAN controller does retransmissions if it gets no acknowledge, and the software waits for it. The CANbus component could do with some improvements. Here's my RPM decode - the particular message is part of J1939 - heavy vehicles. ```
canbus:

  • platform: esp32_can
    rx_pin: GPIO16
    tx_pin: GPIO15
    can_id: 1
    bit_rate: 500kbps
    on_frame:
    • can_id: 0xCF00400
      use_extended_id: true
      then:
      • lambda: |-
        id(engine_rpm).publish_state((x[3] + (x[4] * 256)) * .125f);
mossy flame
#

Thanks! I'm doing it similarly but something wasn't working perfectly the one chance I had to test on the actual car so far.

broken slate
#

I have not yet tried the J1979 messages, but my understanding is that many of them are only sent on request. I started by receiving all frames and logging them. Fortunately one that was being sent regularly was one I wanted. Beware of voluminous logs!

mossy flame
#

I reverse engineered the can data by logging it with peak can compatible logger and a Chinese proprietary OBD reader requesting the battery BMS data. This BYD E6 car does not use standard OBD CAN as far as I can tell.

broken slate
#

I guess the OBD spec was written for IC vehicles and much of it would not apply to EVs.

wintry pumice
#

Nice, I've decoded the Infotainment CAN bus in my VW. I'm thinking of using a waveshare screen to provide an touch interface to control some things on that bus. This thread has me excited.

mossy flame
#

Ahh I finally figured out my CAN woes!!! I have to use the newest Dev version for CAN to work with ESP32 S3 - not sure if its something else special with this setup but ive confirmed its not just this board, my other ESP32 S3 board does nothing with the main release esphome

#

I can finally receive and send CAN frames to my other CAN debugger..

mossy flame
#

Update: me thinking I needed Dev version was probably me actually needing to "clean build files"... I wish there was a way to know when issues are being casued by that?? So of course when I switched to the Dev version of the ESPhome add-on it was starting fresh and the same as if I had run a clean build files on the release version.

broken slate
#

Basically if you get a link time error, do a clean.

mossy flame
#

link time errors will show up but still allow it to compile? because it was compiling but not working

#

Ill have to pay much more attention to the compiler output

somber geode
#

Apparently, in rare situations, it will compile fine, but not work properly. However, that's supposed to be "fixed" in recent versions. If you change something, it forces a clean build.

broken slate
mossy flame
mossy flame
#

Okay I made a little progress, figured out how to read all CAN IDs πŸ™‚ and display them for debugging. Maybe I should try and contribute this to the offical CAN ESPhome page?

canbus:
  - platform: esp32_can
    tx_pin: GPIO5
    rx_pin: GPIO6
    can_id: 4
    bit_rate: 500kbps
    tx_queue_len: 1 # default is 5 I believe - 1 should make it drop extras?? 
    rx_queue_len: 1
    on_frame:
      - can_id: 0  # listen to all messages
        can_id_mask: 0
        then:
          - logger.log:
              level: INFO
              format: "CAN ID: 0x%03x Data: 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x"
              args: [ '(uint)can_id', '(uint)x[7]', '(uint)x[6]', '(uint)x[5]', '(uint)x[4]', '(uint)x[3]', '(uint)x[2]', '(uint)x[1]', '(uint)x[0]' ]
broken slate
#

format_hex_pretty() is your friend. ```
ESP_LOGD("canbus", "can_id: 0x%08x, length: %d, content: %s", can_id, x.size(), format_hex_pretty(x).c_str());

mossy flame
#

That should definitely be part of the https://esphome.io/components/canbus/ page πŸ™‚

[21:57:00][I][canbus:080]: can_id: 0x00000132, length: 8, content: 73.8C.FA.FF.2D.40.FF.0F (8)\```
#

Right at the top of the example lambda code.. Its so necessary for almost any CAN application - debugging all the data

mossy flame
#

The values in "x" are also reversed from that I was used to, the highest byte being x[0] not x[7]

somber geode
#

highest byte?

#

They are in order of receiving.

mossy flame
#

yeah... just opposite of the order of value usually - but maybe thats just specific to the CAN vehicle frames I have been decoding. Not saying its wrong just opposite of how ive been dealing with them in DBC file notation

somber geode
#

It's not a value there, just bytes. If you converted it to an int (long long int?) then it would print in the order you expect I guess.

mossy flame
#

hmm.. some of them are 8 bit values so each byte is a value.. the way vehicle data is encoded in them is strange

#
case 0x292:
      battery_beginning_of_life = (((rx_frame.data.u8[6] & 0x03) << 8) | rx_frame.data.u8[5]);
      battery_soc_min = (((rx_frame.data.u8[1] & 0x03) << 8) | rx_frame.data.u8[0]);
      battery_soc_vi = (((rx_frame.data.u8[2] & 0x0F) << 6) | ((rx_frame.data.u8[1] & 0xFC) >> 2));
      battery_soc_max = (((rx_frame.data.u8[3] & 0x3F) << 4) | ((rx_frame.data.u8[2] & 0xF0) >> 4));
      battery_soc_ave = ((rx_frame.data.u8[4] << 2) | ((rx_frame.data.u8[3] & 0xC0) >> 6));
#
BO_ 658 ID292BMS_SOC: 8 VehicleBus
 SG_ BattBeginningOfLifeEnergy292 : 40|10@1+ (0.1,0) [0|102.3] "kWh"  Receiver
 SG_ SOCmax292 : 20|10@1+ (0.1,0) [0|102.3] "%"  Receiver
 SG_ SOCave292 : 30|10@1+ (0.1,0) [0|102.3] "%"  Receiver
 SG_ SOCUI292 : 10|10@1+ (0.1,0) [0|102.3] "%"  Receiver
 SG_ SOCmin292 : 0|10@1+ (0.1,0) [0|102.3] "%"  Receiver
 SG_ BMS_battTempPct : 50|8@1+ (0.4,0) [0|100] "%"  Receiver
somber geode
#

Use ``` around that text. πŸ™‚

mossy flame
mossy flame
somber geode
#

But discord is mangling it.

mossy flame
#

The order is not an issue for me though πŸ˜‰ just opposite of how I was dealing with the value in Arduino code base. The CAN library I use there has the data bytes in the opposite order

#

I am pretty sure... Or maybe I am confused lol will figure it out eventually

#

Yeah it is opposite.. So the bytes in the Arduino library start with x[0] being least significant - in the ESPhome CAN the first byte x[0] is the most significant - at least in relation to these car protocols

somber geode
#

well, esphome just prints them in received order πŸ€·β€β™‚οΈ

mossy flame
#

yup.. it just happens that the most significant is first πŸ™‚

somber geode
#

(your print statement)

mossy flame
#

oh the printing is correct

#

its the byte order in the actual x - the printing takes that into account I guess

#

They are received with the highest byte first which is why its x[0] in this case - the Arduino CAN library must reverse the order after they are received, swapping x[7] with x[0] etc

pale whale
#

DBC support in esphome would be handy (already a feature request esp32 can dbc based sensor config). for that would be probably SD card support needed for reading these files and logging

mossy flame
#

DBC native support would be amazing.. I found that same pull request while searching πŸ˜‰ I already hearted it πŸ˜‰

somber geode
#

Does the DBC number the bytes in the reverse order?

mossy flame
#

theyre numberd the same as the Arduino library - highest is x[7] lowest x[0]

somber geode
#

That's insane...

mossy flame
#

but it doesnt necessarily specify bytes

#

just bits of the whole frame

#

wouldn't you normally have the highest value byte with the highest number? I dunno I am not expert

somber geode
#

It's not the highest value. That depends on what the data is.

#

But why would you ever number bytes in reverse order of receiving them??

mossy flame
#

when you turn them into one larger variable you have to use the first bytes as the higher bits

#

in these car protocol, maybe its not standard

#

I just created a CAN logger via the text sensor lol 🀣

mossy flame
# pale whale DBC support in esphome would be handy (already a feature request [esp32 can dbc ...

I think the DBC file wouldn't be read from an SD card (but SD card would potentially be nice for storing logs but not necessary for many applications).

Instead the DBC file would be included in the YAML file and parsed by some sort of interpreter into C code to decode all the values 😁 at least that may be possible?? I am more of a code hacker vs programmer... I can understand most sources and add to and change things but it's not my specialty - electronics is more my thing.

The DBC format interpreter could even just work in the YAML on bits and pieces of included DBC file format, since most users wouldn't need all CAN IDs decoded just certain ones. I am guessing someone who is good at that sort of data interpretation logic could create it if they desired.

somber geode
#

You should definitely be possible if someone wants to do it.

mossy flame
#

Okay after many hours of frustration I have it working! In the end I replaced the CAN transceiver trying to fix weird triangular waveforms(probably caused by clipping diodes?) on the GPIO 0 CAN rx pin this board uses (horrible choice of IO right?) I moved that pin to GPIO 4 which is the SD MISO pin but I am not using the SD card right now.

I believe it is something specific to this pin or configuration or I fried the pin earlier trying to fix things...

lucid flicker
mossy flame
#

BYD 2017 E6 supplemental dashboard working! this car just has abysmal efficiency is what I've learned.. 2 mile per kwh. Good news is the 70kwh LFP may be pretty good still πŸ˜„ car probably getting scrapped for my friends house battery..

broken slate
#

can you share your config?