What features would you request for Carloop 3.0?

[alanm]

Hello!
We cannot express how thankful @jvanier and I are about this community's support and enthusiasm so far! Thanks for being so awesome! Since you've been with us since the beginning, we'd like to ask: What are some features, enhancements, and improvements you'd like to see for Carloop 3.0? What is important to you?

We have our pencils sharpened and ready to take notes so fire away!

[alanm]

[cyclin_al1]

The improvement I would love to see is support for K-Line.
Per the discussions in this community and on Particle, there are at least a few people interested in this.

I want this enough that I already have a paper napkin schematic.
Eagle software is now installed so I can start producing something I can share.

As for firmware, I have some ideas how K-Line can be done in parallel with the CAN bus based on a library ScruffR developed for Particle for a different purpose.

For hardware, I have some parts in mind, but waiting for supplier answers to my questions.
I'll keep you posted.

[cyclin_al1]

Not for me, but would there be interest in a 24volt version? There is a different adapter for the vehicle (blue colour plus a tab to prevent mixing 12v and 24v plugs), and then the power supply components probably need to be different. 24 volts are used by a lot of diesel powered vehicles (at least in North America) and heavy trucks. Maybe someone would want it for fleet management or fuel management?

[ScruffR]

Since the Photon only sports one CAN interface, but a car might have multiple CAN (like) interfaces exposed on the OBD2 connector a way to select which ones to connect your device to would be good - either the cheap way via jumpers or even software "routable".
Also an extra connector to feed busses not present on the cars own OBD2 connector into the device might become useful.

[corollan]

I would love to see an easy way to integrate multiprotocol ICs like the elm327 or stn1110.

[scrapsparcs]

I would like to use Carloop with a 1994 BMW that has pre OBD2 ADS. I have a conversion cable to a sixteen pin OBD connector, but I am not sure the Carloop will receive data correctly as most instructions say a "Real Serial Port" is required. Is this the K Line issue?

http://www.bimmerforums.com/forum/showthread.php?1650885-(Almost)-free-DIY-ADS-interface/page20

[seibert]

+1 for being able to select multiple CAN interfaces. My Nissan Leaf has 3, and the detailed battery stats are reported on the non-default one, unfortunately.

[cyclin_al1]

@scrapsparcs, I checked my list (see the link in the thread about ISO 9141) and it looks like BMW used mostly ISO 9141-2 (which is K-Line) between 2005 and 1996. In some models they used KWP2000 (which is a different message format on K-Line). My best guess is that you will also be looking for a K-Line solution.

[cyclin_al1]

@corollan, I may have a different opinion from yours. Instead of integrating those ICs, I prefer how CarLoop is done now which is more bare-bones and gives greater flexibility. If we have basic communications protocols implemented in CarLoop (CANbus, K-Line, J1850, etc.) then we can do pretty much whatever we want. If we really want the ELM327 functionality, then we (CarLoop community) could write a CarLoop Library in firmware for the AT command set that the ELM series uses. This way, we can use CarLoop instead of the ELM327 and be able to do much more as well. CarLoop looks to be a very powerful tool, but the flip side is integrating with ELM327 might get some applications up and running more quickly & easily compared with CarLoop as it is now.

The STN1110 is one I am not yet familiar with (NOTE: I better go take a look).

This is just my opinion and am open to discussing it further. I may have missed something along the way!

[cyberchucktx]

I'm new here, so this might not be possible. But I'm curious to find out if it is possible to use ODBII to build a "driving profile" based on car measurements of things like average speed, number of times the brakes are applied, number of times a left turn is made, etc.

Once patterns are established driver Best Practices could be suggested such as how to get better mileage, etc.

Or are there already apps that do this sort of thing?

Charlie in Houston, TX

[cyclin_al1]

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!

[clemoyne]

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.

[mtkapp27]

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.

[cyclin_al1]

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!

[raminf]

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

[Mitchell]

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).

[alanm]

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

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

[egarl004]

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

[cyclin_al1]

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...