Sponsored
OP
OP
jmccorm

jmccorm

Well-Known Member
First Name
Josh
Joined
Sep 15, 2021
Threads
54
Messages
1,151
Reaction score
1,275
Location
Tulsa, OK
Vehicle(s)
2021 JLUR
Build Thread
Link
Occupation
Systems Engineering
Display Music Information from uConnect

The following script "showevic" listens to the CAN bus of a running vehicle and intercepts messages from the uConnect radio to the dash which contain audio input name, song title, and artist. It prints all messages to the screen (complete or incomplete) as they are received.

Source code follows:
Code:
#!/bin/bash
candump can0,328:0fff | ( while read a b c d e f g h i j k
  do
    [ "$e" -gt 39 ] && echo -n "Line ${e:1:1}: "
    [ "$f$g$h$i$j$k" == "000000000000" ] && echo ""
    printf "%b" "\x${f}\x${g}\x${h}\x${i}\x${j}\x${k}"
    done
)
Sample output:

Line 3: KOSU-NPR
Line 1: FM 106.9 HD-1
Line 2:
Line 3: KHTT-FM
Line 1: FM 104.5
Line 1: FM 104.5
Line 1: FM 104.5
Line 1: FM 104.5
Line 1: FM 104.5
Line 1: FM 104.5
Line 2: Z104.5 THE EDGE - www.edgetulsa.
Sponsored

 
Last edited:
OP
OP
jmccorm

jmccorm

Well-Known Member
First Name
Josh
Joined
Sep 15, 2021
Threads
54
Messages
1,151
Reaction score
1,275
Location
Tulsa, OK
Vehicle(s)
2021 JLUR
Build Thread
Link
Occupation
Systems Engineering
Printing a String to EVIC

I'll need someone to test this because I can't so easily go back-and-forth between my PC and my vehicle. I created a script called 'evic' where you supply a line number (3=title line, 2=artist line,1=device name) and a text message, and it displays that on the music screen of the dash (kind of like a Taser does).
Showing Live Values on the Dash

As I was playing around with the 'evic' script, I found that I could monitor the CAN bus for any particular message that I wanted and to display it's current value on the dash.

This one is going to require more playing around with to get it to work the best in every situation, but can very easily be more than worth the trouble when you're trying to figure something out in real-time.

FOR EXAMPLE:
You want to monitor the steering wheel position.

That's message ID $0023 on can1. You'll want to start printing the 1st character, and you'll want to display a string that's 4 hexadecimal digits long. Because it updates so often (100 times per second), you'll only want to see every one out of 10 updates (to prevent it from falling behind). So...

id=can1,0023:0FFF; pos=1; size=4; rate=10; pos=$(($pos+3))
candump -L $id | ( while read a b c; do n=$((n+1)); \
[ $(( $n % $rate )) -eq 0 ] && evic 1 "${c:$pos:$size}" ; done; )

Congratulations! You'll see the hexadecimal value of the steering wheel's position on the dash (under the music screen). It updates in real-time as you move the steering wheel from left-to-right.

UPDATE: A better example with engine RPMs is available here.
 
Last edited:

Ellivnarg

New Member
First Name
Granville
Joined
Jan 17, 2022
Threads
0
Messages
4
Reaction score
7
Location
Starkville, MS
Vehicle(s)
2021 Sahara 4xE
Wow, that's pretty cool. You are a bash expert!

I was hoping to be collecting data by now, but USPS lost my CAN shield. Can't wait to dive in.
 

NickJar

Well-Known Member
Joined
Jan 18, 2022
Threads
0
Messages
111
Reaction score
83
Location
Toronto
Vehicle(s)
2022 RD
This is sweet, awesome work! My jl is on order, I only have my jk. When I finally get it I can help with some dev work
 
OP
OP
jmccorm

jmccorm

Well-Known Member
First Name
Josh
Joined
Sep 15, 2021
Threads
54
Messages
1,151
Reaction score
1,275
Location
Tulsa, OK
Vehicle(s)
2021 JLUR
Build Thread
Link
Occupation
Systems Engineering
Wow, that's pretty cool. You are a bash expert! I was hoping to be collecting data by now, but USPS lost my CAN shield. Can't wait to dive in.
Hey, I hope to see more of you soon! You know what? I hadn't thought about it, but you're probably right. My bash really has improved over these past few weeks. I'm starting to feel better about it, thanks!

This is sweet, awesome work! My jl is on order, I only have my jk. When I finally get it I can help with some dev work
More company is always welcome!

This morning I played around a bit more with the script that prints text onto dash's music screen. I tuned down the delays and the script runs much faster. In fact, I confirmed that the weak link with displaying rapid updates isn't with the CAN bus but with the dash module. It has a limit on how fast it can process message updates.

Given all of this, I've made a new proof-of-concept. I wanted something which showed "real numbers" (decimal) instead of hexadecimal values. The following script is designed to be run from the command line. It creates an RPM display that's updated 5 times per second.

Here's the script for that:

INITIALIZATION OF VARIABLES:
id=can0,0322:0FFF; pos=1; size=4; rate=2; pos=$(($pos+3))

MAIN LOOP:
candump -L $id | ( while read a b c; do n=$((n+1)); [ $(( $n % $rate )) \
-eq 0 ] && evic 1 $( printf "RPM: %d" "0x${c:$pos:$size}" ) ; done; )

Jeep Wrangler JL JEEP HACKING CAN-C / CAN-IHS / UDS ! (Reverse Engineering) 1643121132084


Immediately, I can see how this can be improved upon. The updates (5 times per second) aren't coming as quick as they could. But if you increase the update rate to 10 times per second (chaging "rate" from "2" to "1"), it starts falling behind and can no longer keep up in real-time. But there's a way that we can be more efficient.

We don't need to print "RPM: " every time. Instead, we could put "RPM:" as the input name (on the bottom of the EVIC music screen) and refresh that piece of text only once every 20 updates (2 seconds). Then we could put the engine RPMs where the song title would normally go, and have it refresh every time we get a new number (every 1/10th of a second).

INITIALIZATION OF VARIABLES:
id=can0,0322:0FFF; pos=1; size=4; trate=20; rate=1; pos=$(($pos+3))

MAIN LOOP:
candump -L $id | ( while read a b c; do n=$((n+1)); [ $(( $n % \
$trate )) -eq 0 ] && evic 1 "RPM:"; [ $(( $n % $rate )) -eq 0 ] && \
evic 3 $( printf "%d" "0x${c:$pos:$size}" ) ; done; )

Jeep Wrangler JL JEEP HACKING CAN-C / CAN-IHS / UDS ! (Reverse Engineering) 1643121122708


There we go! Now we've got a digital tachometer which updates 10 times per second and doesn't start lagging behind the real-world values. I might remove the ":" after RPM, but other than that, it looks good.

I think this does a better job of showing how to create real code which updates text on the dash in real-time. You've just got to be careful how much you're updating how often because the dash itself has a bandwidth limitation.

Enjoy!
 

Sponsored

OP
OP
jmccorm

jmccorm

Well-Known Member
First Name
Josh
Joined
Sep 15, 2021
Threads
54
Messages
1,151
Reaction score
1,275
Location
Tulsa, OK
Vehicle(s)
2021 JLUR
Build Thread
Link
Occupation
Systems Engineering
Wow, that's pretty cool. You are a bash expert!
I realize that this was not your intent, but I've noticed that people who create incomprehensible code are often called experts. That's not what I'm after here. 😄

ShowRPM Script (now documented)

Because this script is going to be important to more people, I wanted to create an even more usable version called "showrpm". It is much less compact but far more commented, making it easier to pick apart and be reused for more interesting purposes.

Bash:
#!/bin/bash

# The message ID that we're listening for.
id=can0,0322:0FFF

# The starting position inside the message (1=the first hexadecimal digit)
pos=1

# How many hexadecimal digits we want to work with
# (1=nibble, 2=byte, 4=word, etc)
size=4

# How often we update the name of the page. It counts the number of times
# a new message (of the type selected above) has to appear on the CAN bus
# before we refresh the page title. (20=we update the title every
# time 20 new messages are received)
# MAKING THIS VALUE TOO LOW MAY INTRODUCE REFRESH LAG.
trate=20

# This is the name that we print on the bottom of the music info page.
tname="RPM"

# This controls how often we refresh the value that we're monitoring.
# It determines how many messages must appear appear on the CAN bus
# before we display the latest value. (1=always display the latest value,
# 2=display every other new value, 10=display every 10th new value)
# BE CAREFUL OF MESSAGES WITH QUICK UPDATES (like 1/100th of a second)
# YOU WILL CREATE LAG IF YOU REFRESH THOSE WITH A REFRESH RATE OF 1.
rate=1

# MAIN SCRIPT BEGINS HERE -------------------------------------------

# Adjusts our human-readable number into an actual offset. Do not modify.
pos=$(($pos+3))

# Read only our selected message from the CAN bus.
# Continually repeat this loop unless we haven't received any messages in
# a 10 second period (10000ms).
candump -T 10000 -L $id | \
( while read a b c
  do
    # Increment the message counter.
    n=$((n+1))

    # If the time is right, refresh the title.
    [ $(( $n % $trate )) -eq 0 ] && evic 1 "$tname"

    # Extract the value we selected.
    value=${c:$pos:$size}

    # Create the text we're going to display.
    # We convert our hexadecimal value into a decimal number.
    text="$(printf "%d" "0x${value}")"

    # If the text is 65535 ($FFFF), print the word OFF instead.
    [ "$text" == "65535" ] && text=OFF

    # If the time is right, refresh with the latest text.
    [ $(( $n % $rate )) -eq 0 ] && evic 3 "$text"
  done
)
 

redracer

Well-Known Member
First Name
Robert
Joined
Aug 22, 2017
Threads
20
Messages
558
Reaction score
619
Location
Manteca, CA
Vehicle(s)
2023 4xe Rubicon
Okay, i've added all of these to github.
 
OP
OP
jmccorm

jmccorm

Well-Known Member
First Name
Josh
Joined
Sep 15, 2021
Threads
54
Messages
1,151
Reaction score
1,275
Location
Tulsa, OK
Vehicle(s)
2021 JLUR
Build Thread
Link
Occupation
Systems Engineering
EVIC Music Info ($328), a CAN Bus Choice, and Tazer

Some additional notes...

Short version: When possible, send any $328 messages via the CAN-IHS bus.

Long version: The dash cluster's music information screen responds to messages on either the CAN-IHS or the CAN-C bus. However, the dash may or may not actually be wired into both CAN busses. When you send a $328 message on CAN-IHS, an unidentified module (I'm guessing the BCM) automatically repeats the message onto the CAN-C bus.

As we observed earlier, the CAN-C bus appears to be using TTCAN, a protocol on top of CAN which allocates predefined time slices to specific groups of messages. Each time a TTCAN unaware device (like an Adruino or Raspberry Pi) transmits on a TTCAN network, there's a chance that it will collide with another message which has a reserved timeslot. Both the existing message and the new message appear to be destroyed when the TTCAN specification is violated.

(with speculation) The Tazer uses this same music information screen to display it's in-vehicle menus. As was noticed earlier, it seems that some updates to the screen will become lost now and again. This is believed to be because the Tazer is sending it's $328 messages over CAN-C, it occasionally collides with other traffic, and intermittent messages are lost and to be retried later.

As mentioned earlier, when a CAN-IHS $328 message is transmitted on the CAN-IHS network, it is repeated onto the CAN-C network. This appears to be done by a device which is aware of the TTCAN timing rules and, as necessary, will delay transmitting a message so that an exclusive timeslot is not violated and colissions are avoided. Third party $328 messages (such as those from an Arduino or a Raspberry Pi) that are transmitted via the CAN-IHS network can be expected to be delivered much more reliably than those same messages transmitted on the CAN-C network.

It is not yet known if the CAN-IHS network uses TTCAN or simple CAN, but the CAN-IHS network is far less saturated with traffic, so even if it is a TTCAN network, the chance of a collision is greatly reduced.

A question: If this is the case, why doesn't the Tazer update the dash via CAN-IHS as well? It could be that they're aware that they're having a delivery issue, but they aren't aware of the exact cause. Or (I haven't attempted to verify this) their device has a single connection to the CAN-C bus and so it does not actively communicate on both CAN networks. If the Tazer is also capable of sending data via the CAN-IHS bus, it may be advantageous for it to switch it's $328 messages to that interface.
 
Last edited:

redracer

Well-Known Member
First Name
Robert
Joined
Aug 22, 2017
Threads
20
Messages
558
Reaction score
619
Location
Manteca, CA
Vehicle(s)
2023 4xe Rubicon

Sponsored

OP
OP
jmccorm

jmccorm

Well-Known Member
First Name
Josh
Joined
Sep 15, 2021
Threads
54
Messages
1,151
Reaction score
1,275
Location
Tulsa, OK
Vehicle(s)
2021 JLUR
Build Thread
Link
Occupation
Systems Engineering
New Project? RGB *Smart* Halo Lights

I think I may have walked into a new project.

I pulled the trigger on an Amazon Lightning Deal for some budget 9" RGB LED headlights. As it turns out, the RGB elements are quite good. As you'd expect, you can choose a new default setting over bluetooth.
It came in the mail today. The RGB ring of the halos consists of two rows, with each row having 60 LED elements. So that's 120 individually addressable LEDs per bulb. AWESOME! The color or color patterns are selected via this awful monstrosity of an app:

Jeep Wrangler JL JEEP HACKING CAN-C / CAN-IHS / UDS ! (Reverse Engineering) 1643243393380
The screenshot makes it look better than it actually is.

The "color" screen has a color wheel and color swatches, and is generally decent. The music screen flat-out doesn't work. (It's supposed to react to recorded music or live microphone sounds.) This "mode" screen (shown above) allows you to select one of 121 pre-defined patterns and adjust them with a slider for speed and a slider for brightness.

I'm putting it through it's paces on my workbench. It's pretty much what I expected. At maximum brightness, the halos consume 1A of power at 12vdc (for both lights). This isn't going to be a huge neon kind of halo that's strongly visible during the day, but that's not what I was after.

Given that it has 120 discrete LED elements, there's the possibility to create patterns that go well beyond what it was shipped with. What I mean to say is that this design can be more "expressive" than those other conventional single-row and mono-color RGB halos:

Jeep Wrangler JL JEEP HACKING CAN-C / CAN-IHS / UDS ! (Reverse Engineering) 1643243541459


I've ordered a bluetooth sniffing antenna (although I have no idea how that's really any different from an ordinary bluetooth USB antenna). I'm planning on using Wireshark to reverse-engineer the protocol. The bluetooth part of this will be difficult for me because I have no bluetooth experience. But this thing should spill it's secrets quite easily.

If I can create my own bluetooth connection with the Raspberry Pi, I'd like for it to dynamically control the headlight halos while I'm driving. Perhaps one pattern while in Park, one pattern while driving (relative to speed), and one pattern for when I'm in drive but going nowhere. Or a different set of patterns for day versus night. Maybe I could create a high-visibility safety-strobe kind of pattern for when the hazard lights are on?

If I can convince the vendor to give or to sell me a second bluetooth controller, then I'd like for each headlight to have their own bluetooth controller. Then I could do a turn signal switchback arrangement where one of the sides goes amber and the other side goes off while I've got the turn signal active (that's message id $318).

If I can't get bluetooth to work, my next plan of attack is to hook them up to a GPIO pin on the Raspberry Pi and have the Raspberry Pi directly bit-bang out a pattern. Towards that, I went ahead and purchased a 4-channel bi-directional 5.5 to 3.3V logic level converter to handle the mismatch in logical level voltages.

Bit-banging out my own patterns with the Raspberry Pi would be troublesome, but it would also open the door to all sorts of unique pixel-based expressions that the current bluetooth controller isn't capable of doing. And I think having expressive RGB halos would be a cool customization... especially when it automatically reads the CAN bus to react in real-time to whatever's going on with the vehicle.

If I make any significant progress, I'll probably want to move this over to it's own thread so that it doesn't pollute this one. Later down the road, I may cross the streams and show how it integrates with everything else we've got going on with the CAN bus.

NEW THREAD: HERE
 
Last edited:
OP
OP
jmccorm

jmccorm

Well-Known Member
First Name
Josh
Joined
Sep 15, 2021
Threads
54
Messages
1,151
Reaction score
1,275
Location
Tulsa, OK
Vehicle(s)
2021 JLUR
Build Thread
Link
Occupation
Systems Engineering
I've ordered two more items so that I can power the Raspberry Pi with the vehicle's accessory voltage (or aux button), while still leaving open the possibility for me to still use my USB-C battery pack to power the Raspberry Pi for extended programming sessions:

$12.59 12v to 5v Volt Converter, DROK DC Voltage Regulator Board Power Supply Module, DC 6.3-22V 12 Volt to 5 Volt 3A 15W

$6.99 USB C Terminal, Type C Female Screw Terminal Block Connector Solderless Pluggable 5P Block Extension Cord

If someone else has a better arrangement, please, share! It's the best I could figure out from the items I found on Amazon. If I'm going to have to leave it on all the time in order to do some programming, maybe I should just bite the bullet and get a battery tender with a quick-disconnect cable?
 
Last edited:
OP
OP
jmccorm

jmccorm

Well-Known Member
First Name
Josh
Joined
Sep 15, 2021
Threads
54
Messages
1,151
Reaction score
1,275
Location
Tulsa, OK
Vehicle(s)
2021 JLUR
Build Thread
Link
Occupation
Systems Engineering
@redracer I seemed to remember you saying that you've hooked up your Raspberry Pi to an aux switch? Which one did you use? (If it's aux3 or aux4, I'd like to set that as my standard.)
 

redracer

Well-Known Member
First Name
Robert
Joined
Aug 22, 2017
Threads
20
Messages
558
Reaction score
619
Location
Manteca, CA
Vehicle(s)
2023 4xe Rubicon
@redracer I seemed to remember you saying that you've hooked up your Raspberry Pi to an aux switch? Which one did you use? (If it's aux3 or aux4, I'd like to set that as my standard.)
I used Aux3 as it's one of the lower amp switches.
 
OP
OP
jmccorm

jmccorm

Well-Known Member
First Name
Josh
Joined
Sep 15, 2021
Threads
54
Messages
1,151
Reaction score
1,275
Location
Tulsa, OK
Vehicle(s)
2021 JLUR
Build Thread
Link
Occupation
Systems Engineering
I used Aux3 as it's one of the lower amp switches.
Thanks! I'll use that too.

I took a look at GitHub and it's looking good, thanks! There's one basic script that was missing, so I took the time this morning to try to make it just a little bit better before sharing. Here it is.

Improved Wake-Up Script

This is an improved version of 'wake', the script used to wake up the vehicle when it is asleep. This script is called by many other scripts if they do not read an expected piece of data from the vehicle.

The previous version of this script would always send the same code, sometimes leading to a module storing a fault code for a stuck button. Hopefully a bit of randomization will prevent that from happening.

Script follows:
Code:
#!/bin/bash
#
# This script is designed to wake up the CAN bus by simulating the
# press of a fictitious center dash button. A random number is
# used to help avoid the ECU interpreting this as a stuck button.
#
FAKE=$(printf "%x" $(( $RANDOM & 15 )))
cansend can0 2D3#07000000000000${FAKE}0
Sponsored

 
 



Top