ELM327 & Class 2 Serial Data

[TJBaker57]

Well the plan is to do it with an arduino so I'd like to use that. Would it be ok to plug the arduino digital pin into the obd port on my truck or would that mess something up. Its a 2000 s10 LS. The coolant temp and fuel level and probably gear indicator are all that's controlled over serial but they all come from the ecu I would assume but I want to replicate the data the ecu sends to the cluster not what goes into the ecu. I don't even know if that's the same data line that goes to the DLC, I'm pretty sure it's not.

You cannot simply connect an Arduino to a serial data bus and have it do anything. It requires more hardware and software for the Arduino.

This is my own Arduino project to connect to a J1850VPW bus...



The Arduino Nano is the small board attached to the larger board.


The code I put together to run it is several hundred lines long.

There is another thread here on this website titled Arduino Chat that discusses this sort of thing.

 

[TJBaker57]

network runs at 12v

nope! nominally 7 volts and the pulses are from 64 microseconds to 200 microseconds.

 

[Riley_UwU]

You cannot simply connect an Arduino to a serial data bus and have it do anything. It requires more hardware and software for the Arduino.

I would say "in that case I'll only have tach and speed" but even the gear selector is done over serial. I'm lazy and mostly deal in hardware and the cluster i bought will never be used for anything other than video games again so I'll probably just tear the cluster apart, take all the chips off the board and wire all the gauges and lights up to only an arduino so I'll have full control and won't have to deal with a 25 year old barely documented data standard.

 

[Riley_UwU]

im already trying to learn LIN messages for a tesla because i bought a tesla steering wheel for a different project that failed so im using that for the wheel of the sim and i cant even figure LIN out. if i just tear into the chevy cluster and make it simple then its one less data line to not deal with.

 

[Riley_UwU]

You cannot simply connect an Arduino to a serial data bus and have it do anything. It requires more hardware and software for the Arduino.

This is my own Arduino project to connect to a J1850VPW bus...

View attachment 114658

The Arduino Nano is the small board attached to the larger board.


The code I put together to run it is several hundred lines long.

There is another thread here on this website titled Arduino Chat that discusses this sort of thing.

I just got my cluster in. It does work but my theory of just running all the gauges and LEDs with an arduino instead of serial might not work. I didn't realise that these gauges are servo motors not whatever is in the older ones and this board is alot more complex than the older ones. I really don't want to have to deal with serial data though, any idea what would be easier?

 

[TJBaker57]

really don't want to have to deal with serial data though, any idea what would be easier?

I haven't got a clue.

 

[Riley_UwU]

I haven't got a clue.

Well thank you for all your help with the serial data stuff, even if I don't end up using it for the project it was very nice of you to share your work.

 

[TJBaker57]

Well thank you for all your help with the serial data stuff, even if I don't end up using it for the project it was very nice of you to share your work.

If for whatever reason you find yourself looking for serial data assistance give a holler!

 

[gigawatts]

@TJBaker57

I've been trying to map out a few commands my 2006 Avalanche uses and this thread has been of great assistance. That spreadsheet is awesome for quickly finding what is talking to what. I'm using ELM327 dongles (both a bluetooth one and a USB one) to log messages on the Class 2 network and I have successfully sent a few messages found here and elsewhere, such as making the car chime, door lock/unlock, gauge cluster light tests and sweeps, etc so I know my setup works.

However, what I seem to be stuck on is what exact header to set when trying to forge and send a message to the car that I've previously logged. One example, the OnStar system is capable of displaying the phone number you have verbally told it to dial on the DIC before it tries to make a connection. I have recorded a session with those message being sent (even ASCII decoded the data hex bytes to confirm it matches the number that was displayed). But while trying to re-play these OnStar to DIC messages (via ELM327 serial console), nothing is happening, and I suspect its because I'm not setting the "AT SH xx yy zz" header correctly.

Any advice on how to calculate the correct header to use while using your spreadsheet to reference and decode each raw message?

 

[TJBaker57]

That spreadsheet is awesome for quickly finding what is talking to what.

My spreadsheets are a mess I don't even know what ones are where and how many times I've copied and altered them to suit the moments needs !!

I know I shared one or more here, but I really didn't think anyone used them.

I have successfully sent a few messages found here and elsewhere, such as making the car chime, door lock/unlock, gauge cluster light tests and sweeps, etc so I know my setup works

That's a very good start right there.

One example, the OnStar system is capable of displaying the phone number you have verbally told it to dial on the DIC before it tries to make a connection

I once read somewhere a fellow had done this for fun, sending a message to the DIC.

have recorded a session with those message being sent (even ASCII decoded the data hex bytes to confirm it matches the number that was displayed). But while trying to re-play these OnStar to DIC messages (via ELM327 serial console), nothing is happening, and I suspect its because I'm not setting the "AT SH xx yy zz" header correctly.

I usually will begin such a task by just mimicking the message seen in the recorded session. Is this what you have tried?

Go ahead and post up some of the recorded session here if you can.

 

[gigawatts]

I believe this is all of the relevant section from the raw capture. Address 97 is the OnStar module.

13:19:50.976 8A EA 97 B1 01 97 12 17 00 00 33
13:19:50.976 08 FF 58 03 E8
13:19:50.984 8A EB 60 B1 01 97 12 17 00 00 82
13:19:50.999 8A EB 97 B2 01 12 20 20 20 20 20 0B
13:19:51.008 8B EA 60 72 01 54
13:19:51.039 8A EB 97 32 01 12 20 20 20 20 20 B7
13:19:51.050 8B EA 60 72 01 54
13:19:51.055 28 FF 40 06 07 0B 0B 83
13:19:51.086 8A EB 97 B2 01 12 20 31 32 38 33 AC
13:19:51.087 8B EA 60 72 01 54
13:19:51.125 8A EB 97 32 01 12 34 35 36 37 38 6F
13:19:51.125 8B EA 60 72 01 54
13:19:51.149 8A EB 97 B2 01 12 39 30 04 20 20 EB
13:19:51.157 8B EA 60 72 01 54
13:19:51.166 88 25 29 07 00 97
13:19:51.169 8A EB 60 B3 01 97 12 01 38
13:19:51.263 08 FF 1A 03 9A
13:19:51.384 08 FF 98 03 CB
13:19:51.429 08 FF 80 03 25
13:19:51.658 88 25 29 07 00 97
13:19:51.768 8A EB 60 B3 01 97 12 06 6B

 

[TJBaker57]

I believe this is all of the relevant section from the raw capture. Address 97 is the OnStar module.

13:19:50.976 8A EA 97 B1 01 97 12 17 00 00 33
13:19:50.976 08 FF 58 03 E8
13:19:50.984 8A EB 60 B1 01 97 12 17 00 00 82
13:19:50.999 8A EB 97 B2 01 12 20 20 20 20 20 0B
13:19:51.008 8B EA 60 72 01 54
13:19:51.039 8A EB 97 32 01 12 20 20 20 20 20 B7
13:19:51.050 8B EA 60 72 01 54
13:19:51.055 28 FF 40 06 07 0B 0B 83
13:19:51.086 8A EB 97 B2 01 12 20 31 32 38 33 AC
13:19:51.087 8B EA 60 72 01 54
13:19:51.125 8A EB 97 32 01 12 34 35 36 37 38 6F
13:19:51.125 8B EA 60 72 01 54
13:19:51.149 8A EB 97 B2 01 12 39 30 04 20 20 EB
13:19:51.157 8B EA 60 72 01 54
13:19:51.166 88 25 29 07 00 97
13:19:51.169 8A EB 60 B3 01 97 12 01 38
13:19:51.263 08 FF 1A 03 9A
13:19:51.384 08 FF 98 03 CB
13:19:51.429 08 FF 80 03 25
13:19:51.658 88 25 29 07 00 97
13:19:51.768 8A EB 60 B3 01 97 12 06 6B

I just may have to have a look at my own 2 Onstar vehicles. Both are the older defunct systems I believe. Never had a reason to fool with them before. Will need to peek into the owners manual for instructions !

 

[gigawatts]

Mines defunct as well, plus I took away it's antenna. To get it to show messages on the DIC, hit the call button (either on the mirror or the steering wheel), say "call number", it will respond, then you can speak a phone number. It will confirm the number by displaying it on the DIC.

My other goal of figuring out these Class 2 messages is to spoof the XM radio module. I patched into the analog audio signals between the XM module and the head unit to setup an Aux input, but have to leave the XM module powered up and connected to the Class 2 network, otherwise the head unit disables the XM input. I want to spoof the init and heartbeat messages to keep the XM input available (while ripping out the XM module) and also make use of the Artist and Track message fields to display other info. I think I've captured all of that, just have to figure out how to calculate what headers to set to send those messages.

But we'll start with the DIC messages and work from there Thanks!

 

[TJBaker57]

But we'll start with the DIC messages and work from there Thanks!

Had a chance to record some traffic in my 2005 Yukon. I'll be having a look and perhaps trying a few things out.

 

[mr_infamous]

I've read this thread twice and I still don't know how to record and send messages on the class 2 bus. The closest I got was this. I typed "atma", hit enter, and when nothing happened for several seconds, I turned the ignition switch off and suddenly the window was full of those '88 6f 10 01 10 00 60' interspersed with the occasional 'cc fe 10 60 8b'.

I installed the recommended "Serial Bluetooth Terminal" app but it almost immediately disconnects after I hit connect. My guess is since I'm doing this in a 1999 Saturn SL2, which I believe only has the IPC and PCM on the DLC pin #2 network, there's nothing keeping the network alive. The RKE module is connected to the PCM, but the circuit diagrams imply that it's simply connected to an internal relay that opens the connection to ground whenever the engine is running and the VSS says the vehicle is moving more than 8 MPH (or was it 3).

So yeah, to be clear, I'm asking if there's a video or guide somewhere showing how I can interact with the bus using a Bluetooth elm327 dongle. Specifically, how to record messages and eventually experiment with sending. I already have the 1999 versions SAE J2178 and understand how messages are coded.

 

[AmpOverload]

Welcome to the forum! Always happy to see more folks learning and using the power of OBD2!

So yeah, to be clear, I'm asking if there's a video or guide somewhere showing how I can interact with the bus using a Bluetooth elm327 dongle. Specifically, how to record messages and eventually experiment with sending. I already have the 1999 versions SAE J2178 and understand how messages are coded.

I can't point to a video or a tutorial offhand, but as you've seen in this thread, there are several folks here who are very familiar with OBD2.

I installed the recommended "Serial Bluetooth Terminal" app but it almost immediately disconnects after I hit connect.

But you were able to send the "ATMA" command, so it must have worked at some point, right?

My guess is since I'm doing this in a 1999 Saturn SL2, which I believe only has the IPC and PCM on the DLC pin #2 network, there's nothing keeping the network alive.

Your 1999 Saturn's PCM definitely is connected to the DLC (16-pin connector), on pin #2, so it should speak the VPW protocol (protocol #2 in the ELM327 world): CHARM website: 1999 Saturn DLC wiring diagram

So, my quick 'n' dirty recommendation is to do this, to see if you can communicate with the PCM, because if you can't get that working, there's no point going any further, IMHO.

>ATZ
ELM327 v1.3a

>ATL1
OK

>ATTP 2
OK

>ATDP
SAE J1850 VPW

>ATH1
OK

>0100
48 6B 10 41 00 BE 3F B8 11 75

>

Your adapter's reply to the 'ATZ' command might be different and your vehicle's reply to the '0100' command will almost certainly be different, but you should get a reasonable reply (not "NO DATA") to the '0100' command, which (assuming that your adapter powers up with OBD2 header bytes set for functional addressing using what's known as "Legislated Diagnostics", which is almost a certainty) is simply a command that asks any supporting node to report their Mode $01 PID "capabilities". It's an innocent (safe) command that the PCM is required to support.

If that works, you're off to the races. If not, let us know and we'll help figure it out.

Good luck! The journey to OBD2 nirvana is long, but rewarding.

 

[mr_infamous]

One of my neutral attributes is whenever something doesn't work they way I thought it would, my response is to try to get more information rather than just throwing a million monkeys at a keyboard and hoping I happen to be watching when the right thing finally does happen at random. Situations like this is why I consider it neutral rather than positive, since I should have tried using the other commands...


Anyway, this is what happened when I tried again just now. There was a severe lag between when I hit send and something shows up on the terminal. It still apparently freezes after "atma" and this time there was about a 10 second delay after I took the key out and the window filling up, so it was probably a coincidence. Since I can't copy and paste from that app and the Samsung multipage screenshot isn't working, I have no idea how many lines there is.

With the "Serial Bluetooth Terminal" app, I was assuming it rather instantly disconnects because unlike the "car scanner" app, it has no idea what it is connected to and maybe the elm327 expects periodic "pings" from whatever device is connected to it? The most low level networkish thing I've done is write an IRC chat bot. With that, the server sends a PING message every minute or so and if it doesn't get a PONG reply, the connection is lost. I would also expect to have to configure it to display the data as hex and not sure how the checksum is calculated or when I would need to do so.


I guess for now, I'm going to try to find another app with a functional "terminal". Thanks for the swift and non-hostile reply!

 

[AmpOverload]

There was a severe lag between when I hit send and something shows up on the terminal. It still apparently freezes after "atma" and this time there was about a 10 second delay after I took the key out and the window filling up, so it was probably a coincidence.

That's because "ATMA" is unleashing a "torrent" of traffic on your poor little adapter! I'll humbly recommend that you initially stick to commands that provoke a single reply from the vehicle/adapter, not one which will overwhelm even some of the most capable of adapters. This, IMHO, is a better way to learn how OBD2 communications work.

If you insist on testing with "ATMA" (no judgment on my part, that's certainly an interesting, if overwhelming, experiment ), then read up in the ELM327 datasheet on how to limit the traffic, which will make your adapter stop screaming in pain from the "flood"!

With the "Serial Bluetooth Terminal" app, I was assuming it rather instantly disconnects because unlike the "car scanner" app, it has no idea what it is connected to and maybe the elm327 expects periodic "pings" from whatever device is connected to it?

Some adapters are designed to go to sleep after some duration with no traffic. In fact, some vehicle nodes are the same way. If your adapter and/or your vehicle's nodes are like that, then a "ping" (typically something innocent like "ATRV" to query the adapter's voltage or even my aforementioned "0100" command) can be warranted. But that's pretty rare, in my experience. Nevertheless, you'll see a lot of OBD2 software do these sorts of "pings".

I don't see that there's anything obviously wrong with your Bluetooth serial app. Both before and after you connect to the vehicle, the adapter does nothing until you tell it to.

 

[TJBaker57]

@mr_infamous

Tell us SPECIFICALLY what OBD2 adapter you have there. Like share a link to the item??

There are a lot of cheaply tossed together items out there and I ran through 3 or 4 different devices before discovering the Veepeak units.

My 1st few adapters would drop the connection repeatedly making them nearly useless.

None of my 8 or 9 Veepeak units exhibit such behaviour.

 

[TJBaker57]

With the "Serial Bluetooth Terminal" app, I was assuming it rather instantly disconnects because unlike the "car scanner" app, it has no idea what it is connected to and maybe the elm327 expects periodic "pings" from whatever device is connected to it?

No. Serial Bluetooth Terminal is a very basic simple interface. It doesn't expect to see anything, and it doesn't do anything you haven't told it to do.

So if the connection to the bluetooth dongle drops out, that is a fault of the bluetooth device or the android device.

Car Scanner does keep talking to the bluetooth device AND the PCM whenever it is connected. This can help maintain a connection with a low quality bluetooth device.

However, Car Scanners' serial terminal is not meant for any heavy lifting. So throwing an ATMA instruction at it is bound to cause trouble.

I just looked at the current version of Car Scanners terminal. It is definitely whacky right now so I would steer clear of it.

ATMA means you want the bluetooth adapter to put onscreen absolutely every message that is on the vehicle data network. Everything. And it will keep doing that until you press the "send" again. At that point it will report "STOPPED".

If you try to send something different while the ATMA instruction is still printing out all messages to the screen, it will not work.

You must conclude the ATMA instruction by pressing send again BEFORE sending anything else.



The instruction @AmpOverload gave you "0100" is a standard query to your vehicle requesting which of the standard OBD PIDs between $01 and $20 does your vehicle support? The response you received contains that information. It is coded and needs to be decoded to see what's what.

Wikipedia and others can provide the details of how that is done. I have a spreadsheet made up for such things. Where column C has a green background with a 1 in it are the standard PIDs your vehicle supports.




See Column C, row 17? The 1 there indicates your vehicle supports the Mode $01, PID $05 which is "engine coolant temperature".

If instead of sending "0100" you follow the same steps and send "0105" you will receive a response which contains your engine coolant temperature. It will be the 6th byte of the message, given as celcius, in hexadecimal format, most likely with a +40 offset. So you take the hexadecimal value, convert that to decimal, then subtract 40 and that's your engine coolant temperature in Celcius.

This is what apps like Car Scanner are doing in the background when you want to display your coolant temperature.

 

[mr_infamous]

I googled "ELM327DS.pdf" and found a new 68 page document that based on the first 20 pages I'm guessing will be the last missing piece of the puzzle. Really bothering me that I just accepted that all there would be was that simple command list I initially saw. The ineffectiveness of search engines when it comes to extremely esoteric subjects like this has rotted my brain fr.


Whatever... still glad I found this place and I'm sure I'll be back.

E: oh, I guess that popup that prevented me from hitting submit was an alert that others had posted since I refreshed the window. Don't know if it'll let me edit but my scanner is "kitbest". At the time I bought it, almost exactly a year ago actually, it was the highest rated/best seller on Amazon.

 

[TJBaker57]

my scanner is "kitbest". At the time I bought it, almost exactly a year ago actually, it was the highest rated/best seller on Amazon.

I took a look, found mixed reviews but that is to be expected online.

The lowest priced Veepeak is far more popular. This Veepeak model works fine when using it with just one android device. Gets troublesome when using with more than one Android device.






A somewhat more expensive Veepeak is a better choice when pairing with multiple Android devices.





I think I currently have like 4 or 5 of the cheapest Veepeak, 2 of the model shown above and 1 of the next higher level, the OBDCheck BLE+.

I may need an intervention

 

[mr_infamous]

This is bordering on off topic perhaps, so forgive me since I'm still extremely new here, but... what's going on with the SDM in 1998 and some early 1999 model year GM vehicles? Most of the cars I've looked at (98 GMC Jimmy, 99 Oldsmobile Alero, 98 Saturn for explicit examples) have a "tan" wire (circuit #800) running from the SDM to slot 9 of the DLC and the most descriptive description I'm seeing on the diagrams is "UART Serial Data". My guess is there's an adapter that uses pin 9 instead of pin 2 for the bus+. Doesn't make sense to me to use an entirely different network protocol to program the SDM when J1850 VPW "class 2" had already been well defined by then. Then again, it doesn't make sense to isolate the SDM from everything else.


That brings me to another set of vague but perhaps more on topic questions. 1999 Saturns have a purple wire running from pin 4 of the SDM connector to pin 1 of the DLC, which the diagrams call circuit 1807, which anyone reading this is probably aware that 1807 is always (in 1996-2008) the main class 2 bus+ circuit. Starting in 2000, pin 4 of the SDM, which is identical to the 1999 one AFAIK (SIAB with new SDM first available in 2001), goes to the BCM instead of pin 1, and according to the diagrams, there's another purple wire going from slot 5 of the SDM to the IPC. I've never verified this, but it's got me scratching my head. If the SDM is connected to the BCM, which is obviously connected to the IPC, why the redundant wire?

I've completely disassembled the interior wiring in my 99 SL2 with the one exception being the SDM, since I couldn't figure out how to get the connector off without breaking it. Supposedly, there's an "airbag telltale lamp driver module" somewhere in the 99, which supposedly controls the airbag light in the otherwise fully-PCM-controlled cluster, so maybe it's under the main SDM case. I tried just looking at the wires but after 25 years, the tape around the bundle running under the center console, which was surprisingly well done, is completely petrified.


Anyway, backtracking a bit... is it safe to assume that any purple wire identified as circuit 1807 on a 1996-2008 (or whatever, before the switch to using the CAN bus for OBD-II) GM vehicle can be connected to the DLC pin 2 wire? I'm guessing that is so and that there was (is?) an adapter for the 1999 model years still lacking a BCM that effectively "shorts" pins 1 and 2 together, temporarily connecting the SDM to the main network and making it possible to check/clear unlatched B codes from the SDM.


By the way, the reason I originally got interested in this is the radio. The 1997 S-series coupe/sedans had a OEM/"Delphi" brand 12 disc trunk mounted CD changer option that works when the "AX" button on the head unit is pushed. Even though the radio isn't connected to anything else, I figure what the manual calls the "E/C Data Line" going between the head unit and the CD changer is really class 2 connection and if so, that would mean it would be rather trivial to trick the head unit into thinking the CD changer is available and I could listen to audio from my phone's AUX port. It would also mean I could assign functions to e.g. the RDM button. I am almost certain I remember a thread on the now defunct saturnfans.com forums where someone did exactly what I'm talking about, although it may be using a different protocol.

 

[endjuser]

Mines defunct as well, plus I took away it's antenna. To get it to show messages on the DIC, hit the call button (either on the mirror or the steering wheel), say "call number", it will respond, then you can speak a phone number. It will confirm the number by displaying it on the DIC.

My other goal of figuring out these Class 2 messages is to spoof the XM radio module. I patched into the analog audio signals between the XM module and the head unit to setup an Aux input, but have to leave the XM module powered up and connected to the Class 2 network, otherwise the head unit disables the XM input. I want to spoof the init and heartbeat messages to keep the XM input available (while ripping out the XM module) and also make use of the Artist and Track message fields to display other info. I think I've captured all of that, just have to figure out how to calculate what headers to set to send those messages.

But we'll start with the DIC messages and work from there Thanks!

I've been doing a lot of research on the Class 2 messages in my 04 Suburban, including XM (DRR) and various radios. Here's an excerpt from the DRR section, specifically the exchange between radio and DRR when XM1 is selected on the radio:

(AA A5 89 1C B2 XX is required before radio will display XM band, e.g. AA A5 89 1C B2 03 for normal operation)

When XM band is selected, RADIO sends these functional messages:
6A A4 80 99 B2 2E                        Audio Tuner/Receiver    Load Command Ext (B2)    Q    19: 2E (XM Action: Band 1)
EB EA 80 3A B2                        Displays            Status Req Ext (B2)        3A (request XM band text)
6A 94 80 86 B2                        Audio Control        Load Command Ext (B2)    Q    06 (device on/off stage 2? on with Q)

If there is no response, the latter two are repeated several times and then "ERROR" is displayed on the radio and the following message is sent:
6A 94 80 06 B2                        Audio Control        Load Command Ext (B2)        06 (device on/off stage 2? off without Q)

If DRR is attached, however, it responds as follows:
6A A4 80 99 B2 2E:
    AA A5 89 99 B2 2E                    Audio Tuner/Receiver    Report Status Ext (B2)    Q    19: 2E (XM Action: Band 1)
    AA A5 89 18 B2 00 01 81                Audio Tuner/Receiver    Report Status Ext (B2)        18: 00 01 81 (Tuning: channel 1, band XM1, preset 1)
        RADIO responds with:
        6A A4 80 99 B2 00             Audio Tuner/Receiver    Load Command Ext (B2)    Q    19: 00 (XM Action: None)
            DRR responds with:
            AA A5 89 99 B2 00            Audio Tuner/Receiver    Report Status Ext (B2)    Q    19: 00 (XM Action: None)
6A 94 80 86 B2:
    AA 95 89 86 B2                    Audio Control        Report Status Ext (B2)    Q    06 (device on/off stage 2? on with Q)
    if no further data is sent by radio after after 4 seconds, DRR sends:
    AA 95 89 06 B2                    Audio Control        Report Status Ext (B2)        06 (device on/off stage 2? off without Q)
EB EA 80 3A B2:
    AA EB 89 BA B2 01 02 58 4D 03 04        Displays            Report Status Ext (B2)    Q    3A: 01 02 58 4D 03 04 (XM band text: "XM")

NAV RADIO also sends:
8A 94 80 89 B2                        Audio Control        Load Command Ext (B2)    Q    09 (device on/off stage 3? on with Q)
DRR responds with:
AA 95 89 89 B2                    Audio Control        Report Status Ext (B2)    Q    09 (device on/off stage 3? on with Q)
(if asked multiple times in rapid succession, sometimes it reports Q then not Q)

Once XM band 1 is selected, the following message from DRR sets text on radio:
AA A5 89 1C B2 04                        Audio Tuner/Receiver    Report Status Ext (B2)        1C: 04 (XM Status: TUNING)
AA EB 89 B6 B2 01 02 41 42 03 04            Displays            Report Status Ext (B2)    Q    36: 01 02 41 42 03 44 (text: 'AB')
AA A5 89 1C B2 03                        Audio Tuner/Receiver    Report Status Ext (B2)        1C: 03 (XM Status: idle)
    (NOTE: 1C: B2/03 is required to close out 1C: B2/04, otherwise radio displays text, but user is stuck and cannot change bands, etc.)

multi-line text requires toggling Q for each successive message
    AA EB 89 B6 B2 01 02 41 42 43 44
    AA EB 89 36 B2 45 46 47 48 49 4A
    AA EB 89 B6 B2 4B 4C 4D 4E 03 04
note: radio accepts message so long as data starts with 01 and ends with 04 -- 02 and 03 do not seem to be required
    AA EB 89 B6 B2 01 4D 45 4F 57 04 (displays MEOW)

Attached is an excerpt from the JSON file I created for my decoder with some of the relevant functional messages.