Car Area Networks: An Open Source IoT for Your Car?

Поделиться
HTML-код
  • Опубликовано: 4 окт 2024

Комментарии • 13

  • @williamhurst1519
    @williamhurst1519 3 месяца назад

    That all sounds like something that could be done over a CAN bus (separate from the critical systems in the car, although the "server" could listen on that bus to relay any relevant data). You could use a low priority message to request X number of message IDs for the device, which the server could then assign. A separate message could be sent that tells the server what data each of its assigned messages contain, and the expected send/receive frequencies. It could also ask the server to broadcast data from the car's existing CAN bus, and the server could point it to the message and byte(s) that contain the requested info.
    A CAN bus requires 2 120 ohm resistors at the far ends of the bus. I would handle this by putting one in the "server", and putting a "Y" splitter near any added devices (one end going to the device, the other to a termination plug with the other resistor, so no add-on device needs the resistor). In theory, each device would only need 2 wires for the CAN bus and an appropriately sourced and sized power connection. If there was a predesignated device limit and maximum power draw per device, then all 4 wires could be prepackaged in various lengths with standardized connectors and the "Y" already built in (think PoE). Installing the "server" would be the hardest part, especially if you intend to read data from the existing CAN bus, but then each add-on device could be plug-n-play.
    You would want some way for the server be able to remove devices (preferably from the GUI), and a way for the device to be reset (both by the server and individually). The server should also be able to reorganize and reassign the devices' message IDs for priority handling (limited cases) and be able to display how full the bus is.
    For debugging, you would want to be able to read the assigned message IDs from the individual devices (i.e. EEPROM via USB), and a way to read all messages on the bus (either in a service mode in the GUI, or through an external connection).

  • @hangingwithbigmike
    @hangingwithbigmike 4 месяца назад

    Really excited for this, I always wanted to make a carputer that I could make a car smarter with, having bluetooth OBDII connections, and mood lighting, gauges etc. but I'm no good at programming.
    Something that might be worth looking at, if you haven't already, is i2c, that should at least make connecting a large number of devices together easier, and would allow for easy addition of other non bluetooth devices, like single chip accelerometer, compass etc, and allow using the cheaper 8266s.
    As always, keep up the good work and videos!

    • @GarageTinkering
      @GarageTinkering  4 месяца назад

      Awesome, I'll definitely have a look into that. Great idea!

  • @yomboprime
    @yomboprime 4 месяца назад +1

    Hi, I was recently thinking of uses of esp32 inside the car. The only thing I thought is using a cheap (5$) serial GPS receiver and show real speed, heading, height and of course latitude and longitude in a 4 wire SPI screen. Although this can be an independent device, perhaps it could be good to include in the car area network.
    I will watch your new video, thanks.
    (I bought a 3.5 inch display and is coming)

    • @GarageTinkering
      @GarageTinkering  4 месяца назад

      Yeah, I think this is a great addition. I'll keep that idea in the back pocket!

  • @MarkVovo
    @MarkVovo 3 месяца назад

    MQTT Broker on the ESP32 Server as well, and this means no reinventing the wheel with new protocols?

    • @GarageTinkering
      @GarageTinkering  3 месяца назад

      Hmmm, I'll have to look into that. It's not one I know of

  • @62f100
    @62f100 4 месяца назад

    Check out nextgenefi & what he’s doing with esp32.

    • @GarageTinkering
      @GarageTinkering  4 месяца назад

      Seems in a similar ballpark, though focusing on digital dashes and ECU replacements rather than interconnected control devices. Interesting though.