What features would you request for Carloop 3.0?

Hi @cyberchucktx,

You can probably do all that with a modern car, but it will take more work than just using ODBII.
On modern cars, the ODBII messages are required by law (for emissions testing, etc.) and so the message format is public knowledge. Things like the vehicle speed sensor (VSS) are part of ODBII and you can calculate an average speed from that. The mass airflow sensor (MAF) is also part of ODBII and can help calculate your fuel efficiency.

However, the ODBII messages are sent over the main CANbus. Other messages are probably sent over it as well. A modern car might even have more than one CANbus or even other protocols. Things like braking, turning the steering wheel, using the turn signal are probably on some bus, but you have to find it for your car; it is often custom to the model or manufacturer. The current Carloop will access the main CANbus, but you will have to car-hack to discover all the other messages going on.

Maybe Carloop 3.0 can be designed to tap into those other CANbuses or other protocols. Once tapped in, some car-hacking might reverse-engineer the messages and discover how to get all that info. Personally, I am working on tapping into K-Line, which is older than CANbus.

The combination of Carloop and the expertise on a vehicle-specific forum might prove to be very powerful.
We all have to work on it to make it happen!

Repeating a bit of the above…

  1. Easy ability to connect the Carloop to a non-OBD port connection. Just some headers with CAN H, CAN L and ground would be nice. Would be useful for applications such as B-CAN where the bus is not on the OBD connector.
  2. Support for K-line would be handy for reverse engineering diagnostic tools
  3. Someday I would like to see Carloop ported to other boards, such as the Adafruit Feather or maybe even the PyCom WiPy / LoPy.

Honestly, I have not tried carloop yet, but if possible here are some ideas.

I have a Hyundai Sonata with the full tech package. I have to pay Hyundai a yearly service fee to get some of the neat features built into the car which to me is BS. I would like to remote start my car (not with their app), turn on/off heat (and heated seats), lock/unlock the doors, and get the system health report. Not sure that can be done through the OBD port, but maybe with a newer product. Also, my dash has a display and I would like to change the view. For instance, I would like to see both my Digital speed AND efficiency at the same time. Currently I have to toggle between screens. Also, I am sure there could be a lot more if I had a way to program the touch screen too.

Hi @mtkapp27,

You can probably control all of that through the CANbuses. However, you will have to do some of the figuring out. Your car likely has multiple CANbuses, not just the main one that OBDII runs on. It may even have some Hyundai proprietary buses. You, or maybe with help from others on a Sonata forum will have to figure all that out.

If you want an electronic tool to hook up to the bus, then CANbus along with some improvements mentioned above are the way to go. You will then have to figure out (hack) the messages. Yep, those ODBII messages will be the easy ones.

Specifically for the remote start, you will need some remote car starter hardware in case it is not yet built in. Sometimes, the hardware is there, but you have to pay for the code to unlock it. One thing to think about before modifying any of the settings, is how that will affect your warranty. Also, what will the dealer do if they catch you. You might have to create a base configuration file so you can return your car to specification before taking it in for service. What you do will be your choice and your risk.

Good luck!

Some ideas in no particular order:

  • Support for a micro-SD card so you can store captured data and look at it offline. Plus a sample app that could be loaded to read and filter the message and save them to files on SD. This way someone can put together a CANBus logger in a few minutes.

  • A GUI data visualizer that can show CANBus captured data and a way to see what’s going on. Something like SavvyCAN.

  • A standard way to define and share CAN message IDs, parameters, and descriptive text. This could be a JSON file, or something more complex. Then when writing apps you could easily interpret the fields and dump them out instead of manually having to crack the data. I know the DBC format exists, but that requires proprietary software. Also, a way to share the data with other people so owners of a certain model vehicle can help fill-in the gaps.

  • A high-level object-oriented API for CAN messages. For example, instead of just CANMessage you could have CANTemperatureMessage, or CANSpeedMessage, etc. to hide the gory byte and bit twiddling that needs to happen.

  • Support for a high-level messaging protocol like MQTT so CANBus messages could be pushed out to the net and apps can subscribe to them when they’re updated.

  • Instead of the single fixed CAN module you could move to a more flexible hardware solution that can be reprogrammed for all different kinds of communication schemes. Something like a Xilinx FPGA with CAN IP or one from Lattice. This way those who need other protocols like FlexRay or LinBus could just add it in.

  • A simple mechanism for playing back recorded CAN messages. For example, to record steering wheel angles and then, if the car has hardware to support it, play them back to make the vehicle turn.

  • Add-on Bluetooth and/or BLE HW support so mobile phones could talk to the Carloop directly.

  • Finally, integration with something beefier than the Particle. Perhaps something like the Nvidia Jetson TX1. This could be used for people wanting to try DIY self-driving projects :wink:

  1. Carloop should not connect the two grounds together (chassis ground on pin 4 and signal ground on pin 5). These grounds are for difference purposes and connecting them together by plugging-in Carloop could add noise to the OBDII bus and therefore create major problems. As a temporary work-around I cut the pin 4 wire in my OBDII extension cable. I believe Carloop should only connect to pin 5 signal ground.

  2. It would be great if there was a jumper option for the +12v supply to Carloop. While pin 16 is usual, on the Nissan Leaf pin 8 is only on when the car is on which could be preferable for some applications.

  3. Expanding on the suggestions above, it would be great if Carloop had a second CAN bus input and this would have jumper options to be any other pins on the OBDII connector, as many cars such as the Nissan Leaf have other CAN busses on other pins. If this second bus could be software-selected that would be even better (so by default pins 6/14 are selected, but by asserting a GPIO pin, whichever other OBDII pins were selected on the jumpers would be used instead).

hey @raminf as I was reviewing everyone’s feature requests, I came across this one and wanted to mention we currently support BLE via the Carloop Bluetooth combo! https://store.carloop.io/products/carloop-bluetooth

Just noticed some V3 changes on git… does this mean Carloop 3.0 is close?!.. Definitely like the sd card slot.

The V3 changes might be what the carloop founders are calling CarloopXL. Not sure if they are planning on producing it or not. It is bigger but more capable!

If you are looking at the CarloopRetro branch, then that is a development to add in K-Line support (ISO9141-2 and KWP2000) for older cars. I need to get it done…

1 Like

There might be something in the works (in the next 2 months) that you will really really like in that case!

2 Likes

awwwwwwwww yeahhhhhhhh… apparently I needed 20 characters to respond

i would love to see elm327 support to read data from vehicles with older protocols

1 Like

I think 3.0 should feature a j2534 or “layer one” pass thru device. J2534 was intended to unify access to embedded protocols:

ISO9141
ISO14230 (KWP2000)
J1850
CAN (ISO11898)
ISO15765
SAE J2610
J1939 (since 2005)

Some resource info:

@SinusoidDelta, I took a list at all the protocols you listed, and it is all possible. However, the Carloop hardware has to be able to work for all the hardware protocols. The rest are communications protocols running on top of that hardware. Any communication protocol can be coded into the firmware as long as you have the right hardware underneath.

In your list, there are only 4 hardware protocols.

  1. CANbus, which is already done by Carloop
  2. K-Line (the hardware layer for ISO9141, KWP & KWP2000), which I am working on a CarloopRetro to do this; a schematic is already on GitHub. However, I am only managing 30 minutes a month (I do not work for Carloop), so it will be a long time coming.
  3. Off-Road
  4. Heavy machinery

@elhajj33, you can code firmware to emulate the elm327 on CANbus for Carloop. As mentioned above, you need to have the hardware layer to be able to emulate the elm327 on other protocols. However, once you have the hardware, you can code firmware to do whatever you want, which could be much more than the limited functions of elm327. Don’t get me wrong, elm327 emulation is something I would love to see as it is extremely useful, but Carloop allows for much more than that.

Is there any ETA for the new Carloop 3.0?

I am waiting for it coming out for my new Car Tracking Project for school.

I would love to see GPS+SD Card slot on the board, as I am still debating whether use the official supported particle board or go with STM32

Thanks,

I’m a little late to the game but thought I’d post my thoughts anyway. SD and GPS are definitely tops on the list that I would like to see. One problem I expect living where I do in northern NJ is to have no WiFi or Cellular Access in many areas. The ability data-log to an SD card and Upload the data to a Rest Service when connectivity is available is a must. The ability to add a 9DOF sensor for additional telemetry data would be great. Having 9DOF built right in would be even better

@JerseyTechGuy, You are never too late to the game. There is a new GPS that plugs in on top of the Carloop or with a JST cable. The GPS circuit board happens to also have a microSD card slot. That should already cover a lot of what you are looking for.

For 9DOF sensors or an integrated IMU, I would recommend doing some careful research first before selecting one for the purpose of car telemetry. Check out this thread for some of the limitations you might come up against (I have the example sensor on hand; I might be looking for a replacement):

Smart home connection with MQTT or similar to get in home automation like fibaro home central or similar. ex. put on heating system or charger if car is cold or get low battery. open garage door when car is close to home. warn if car is outside a dedicated area or drive to fast (kids loan the car)

@IBICO,

All the things you listed are functions that Carloop can help you accomplish. However, this thread is about what you would change with the Carloop itself… is there anything you would change in the Carloop itself to help in your projects?

With a Photon, you can do MQTT today. No extra hardware required. Check out the MQTT library in the Particle online IDE.