NAME

Contents:

MAIN / START UP SCREEN

This screen embodies the core of the program. Here you will find the master list of all frames. Also, here you can navigate to the other aspects of the program. You can have multiple sub-windows open at once - in fact, quite often this is very beneficial.

THE MAIN FRAME LIST

THE BOTTOM STATUSBAR

THE REST OF THE MAIN WINDOW

Suspend Capturing / Resume Capturing is a button that will temporarily disable frame capture or re-enable it. This can be used to keep everything connected without capturing traffic for a short time. This can help to not capture traffic in between tests.

The "Normalize Frame Timing" button is used to reset the lowest timestamp to "0" and offset all other timestamps accordingly. This is useful to remove the starting offset when you start up the GVRET board long before actual traffic starts. SavvyCAN is designed such that this doesn't really matter most of the time but normalizing the timing might be useful to help correlate the timing between two different captures.

The "Clear Frames" button will erase all captured messages. They will be irreversibly erased and all memory will be freed.

The "Auto Scroll Window" checkbox will cause the main frame list to hunt toward the bottom of the list as frames come in. It will normally not be quite at the very bottom as, for performance reasons, the program runs at quarter second updates to things like the auto scroll. Thus, the main list will be scrolled to the bottom four times per second.

The "Interpret Frames" checkbox is used to specify whether the loaded DBC file should be used to interpret all available messages and signals. One might want this off for performance reasons (interpreting takes some extra processor power and RAM) or to declutter the main frame list.

The "Overwrite Mode" checkbox is used to ensure that only the newest frame for each message ID is shown. That is, if 100 messages with ID 0x105 come in you will see only the newest one. This is generally used alongside "Interpret Frames" to interpret frames and always see the up-to-date information.

"Frame Filtering" provides a list of all the frame IDs seen so far. Any ID which is checked will be shown in the main list. Any ID which is unchecked will not. This can be used to hone in on frames of importance while hiding frames that are currently of no interest. The filtered list can be saved as well.

LOADING AND SAVING FRAMES

There are many other formats supported. Some are only supported for writing, some only for reading. The list of supported formats is expanded every so often.

FILTERS

WHAT IS DBC AND WHY WOULD I CARE?!

HOW DBC INTERACTS WITH THE MAIN SCREEN?

CONNECTION WINDOW

The connection window is used to add, remove, and modify connections. At the moment it is possible to use any QT SerialBus compatible device and any GVRET compatible device in any of the supported operating systems. SerialBus supports socketcan on linux, passthrough on Linux and Windows 32 bit, and Vector, PeakCAN, and TinyCAN on supported OS's.

At this time GVRET compatible devices are: EVTVDue, EVTV CANDue (1.3/2/2.1/2.2), Teensy 3.1-3.6, Macchina M2, EVTV ESP32 Due.

CONNECTING TO A DONGLE

SavvyCAN can also connect to a wide variety of CAN hardware through the built-in QT SerialBus drivers. These drivers vary by operating system but support socketcan on LINUX and Vector tools on both LINUX and Windows. When you select "QT SerialBus Devices" you will get a list of device types supported. Select a device type and for most devices you should see the Port list fill out with all registered and valid ports for that driver. Socketcan devices, for instance, are automatically detected now. Then push "Create New Connection" and you should see the new connection in the table on the left of the window. Note that SocketCAN devices don't support changing the baud rate within a program. You must do this when you set up the connection via console commands. This is outside the scope of this documentation. Consult the SocketCAN documentation for details on configuring such devices.

The last connection option is "Remote Host." If you select this option then Port will change to a textbox. Enter the IP address of the remote (but still local to your LAN) IP address. Currently this works with EVTV ESP32 boards and M2 boards.

DEBUGGING CONNECTION PROBLEMS

PREFERENCE WINDOW

SETTING PREFERENCES

"Save/Restore window positions and sizes": If this is set then the size and placement of the various windows in this application will be saved when the program is closed and loaded when each window is brought back up in the future. This can be used to create your own preferred layout. If you'd rather things come up in their default state every time then you can uncheck this box.

"Display values as hexadecimal": A lot of the time people who are doing CAN reverse engineering like to see values in hexadecimal (base 16) instead of the more familiar decimal (base 10) system. Checking this box will cause most of the values in the application to show up in hex. This applies to CAN ids and data bytes. Unchecking this causes values to default to decimal instead. The reason for using hex is that each hex digit is 4 bits. Integers on a computer tend to be in multiples of 8 - 8, 16, 32, 64. So, hex digits have a direct mapping to the underlying binary. Decimal does not have this correspondence AT ALL. But, the choice is yours.

"Require validation of GVRET connection": GVRET style devices run over a serial connection. Serial connections can be finicky sometimes and so the connection can be validated to prove that everything is really still operating and talking. There probably isn't any reason to turn this off except while debugging to see if it changes anything. Mostly just don't touch this.

"Time Keeping": There are a variety of ways one could timestamp CAN frames as they come into the program. Selecting "Seconds" will cause the timestamp to be expressed as seconds since the frame list was last cleared. This tends to be an easy choice to work with. "Microseconds" will express the timestamp as millionths of a second since the last time the frame list was cleared. This is exactly like "Seconds" mode but without any decimal point. You might find this to be a bit hard to conceptualize. The last option is "System Clock" this will timestamp frames with the current system time when the frame came in. This is still very precise but now you'll get an absolute time stamp with the full date and time. The display of this mode can be changed by editing the "Time Format String" value. It defaults to an output that looks like "JAN-10 12:34:53.234" But you can set it to other values. Look here to find a reference for how you can create new format strings: http://doc.qt.io/qt-4.8/qdatetime.html#toString

"Use filtered frames in sub-windows": The main window has a filtering interface where you can uncheck IDs to hide them. Ordinarily when you bring up one of the other windows it will still use the main unfiltered list. Sometimes you really do want to deal with the filtered list of frames even in the other windows. If this is checked then the other windows will see the filtered list and not the unfiltered actual list of frames that have been captured.

"OpenGL Accelerated AntiAliased Graphing": A personal favorite of mine. Checking this will cause all of the graphs to use OpenGL 3D acceleration. Most modern machines have some form of 3D acceleration so this option should be OK to use. If you check this your graphs will look a lot better and on good hardware should also be faster. In the future other options are likely to be added to the graphing screen that will likely only be enabled if OpenGL mode is also enabled. Try enabling this and see if performance is still good. It's safe to leave it off if in doubt.

"Autoscroll main frame window by default": If checked it will automatically check the relevant checkbox on the main screen when the program starts. This will cause the view to automatically scroll to the bottom by default. This is merely a convenience option if you'd prefer it to be the default.

"Use timestamp mode by default": This is another convenience option. With this checked the Flow view will default to using time stamps on the graphing area instead of frame numbers.

"Set Auto Reference by default": The Flow view can either use static referencing or dynamic referencing (see the Flow view documentation for more info). If you'd like to use dynamic referencing and automatically set the reference by default then check this option.

"Loop by default": Set the playback window to default to looping infinitely by default.

"Default playback speed (ms)": Set the default timing for playback

"Default Sending Bus": Set a default for which bus to send frames on.

"Auto expand all nodes": Both of the referenced windows have tree views that potentially have a large number of nodes. It's more neat not to expand them all by default but it also then requires more clicks if you have to expand them to view the information. So, you can set whether you'd like to expand them all by default or not.

After changing preferences it is the best practice to close and reopen the application to ensure that all settings have taken effect.

DBC FILE MANAGER

WORKING WITH DBC FILES

DBC FILE ORDERING

DBC MESSAGE EDITOR

WORKING WITH NODES

WORKING WITH MESSAGES

DBC SIGNAL EDITOR

DEFINING AND EDITING SIGNALS

Otherwise, select a signal to edit. The details of it will fill out the rest of the window.

On the right side you can rename the signal and you'll see that it is renamed in the list as well.

"Bit Length" - This sets how many bits the signal uses. Once you do this you'll see that that many bits are now highlighted in the 8x8 data grid above. The black bit is the "start" bit, green bits are the other bits in the signal. Gray bits are already used by another signal. You can still use them for the current signal too but doing so would be quite unusual.

"Byte Order" - The way that the green bits are filled out is changed by this checkbox. Checking it selects little endian mode whereas deselecting chooses big endian mode. This will have an effect on any signal that crosses byte boundaries.

"Type" can be: 1. UNSIGNED INTEGER - No sign bit, only positive numbers 2. SIGNED INTEGER - The top bit is used as a sign bit 3. SINGLE PRECISION - Floating point number (should be a 16 bit signal) 4. DOUBLE PRECISION - Floating point number (should be a 32 bit signal) 5. STRING - Directly turn the CAN bytes into a string

"Scale" is used to multiply the signal by the value to scale it appropriately

"Bias" is added to each value generated by the signal to set it at a different bias point

"Min Value" is purely informational. It is just a reference to anyone else viewing the DBC information as to what you expect the lowest value to be.

"Max Value" is likely informational.

"Units Name" is displayed after the value when you interpret a signal on the main frames list. For instance, you could set the units name to V so that a voltage value reads something like "12.34V" when it is displayed.

"Receiving Node" This is informational at the moment. You can set which node (out of all your defined nodes) is the one that receives this signal.

"Multiplexing" This is a somewhat involved topic. DBC signals can be multiplexed which means that a given frame might have a range of data that is not always found in every frame. There is a key of sorts that specifies which piece of data this particular frame is sending. This leads to the concept of multiplexed signals and multiplexors. Multiplexors are the key. They provide a value that specifies which multiplexed data item is being sent. A multiplexed signal is then connected to a specific value of the multiplexor. Thus, a multiplexed signal requires that a multiplexor also exists. You would normally set all of this to "Not multiplexed" and skip all this complication. But, multiplexed signals do exist. In that case the message would have one multiplexor and one or more multiplexed signals. So, you'd set up a multiplexor for the message and then create additional multiplexed signals that are marked as "Multiplexed" and have filled out the "Multiplex Value" with something unique.

"Comment" is purely informational.

Signals that use either "UNSIGNED INTEGER" or "SIGNED INTEGER" as their type can define a Value Table. This table allows text strings to be substituted in place of integer values. For instance, if you know that a value of 0x10 means PARK then you can go to the next empty entry in the list, type 0x10 for the value and PARK for the Text. This will make the interpreted value read PARK any time the signal has a value of 0x10. This is used to make a more human friendly presentation. It should be noted that if the signal has a value not in the list then it will still be shown as it's integer value. But, known good values can be entered in the Value Table to make them easier to work with.

GRAPHING WINDOW

CREATING A NEW GRAPH

SELECTING A GRAPH

EDITING A GRAPH

DELETING GRAPHS

MOVING AROUND

LOADING AND SAVING GRAPHS

REAL TIME GRAPHING

HIDDEN TRICKS

GRAPH SETUP

SETTING UP A GRAPH

GRAPHING A DBC SIGNAL

MANUAL SIGNAL GRAPHING (OR EDITING)

"Name" is for your reference and will be shown on the Graphing Window.

"ID" is the frame ID to use for this graph. You can enter in either decimal or hex. Hex values are preceded by 0x

"Data Len" is used to specify how many bits are in the signal to graph. You can graph odd bit lengths such as 9, 11, or 15 bits. These are not as uncommon as you might think.

"Little Endian" switches between little and big endian mode. This will change how the signal grabs bits from the frame.

Once you've set both Data Len and Little Endian you can set the bits to use. The 8x8 grid above is used for this. Click on the start bit and the rest of the bits will automatically be selected for you based on Data Len and Little Endian.

"Signed" can be used to select between signed and unsigned mode.

"Mask" will apply a mask to the value before using it.

"Bias" allows for setting an offset to the values to bring them to a different resting point

"Scale" is used as a multiplier to change the scaling of the values

"Stride" is not often used but will cause only every "x" values to actually be graphed. This can be used to graph a very dense set of data with less points to speed things up.

"Color" changes the color of the graphed line. It is automatically randomly set for new graphs but if you don't like the random color you can click the color and select a better one.

FLOW VIEW WINDOW

THE PURPOSE OF FLOW VIEW

SELECTING AN ID TO FLOW

VIEWING THE FLOW

Below the 8x8 grid view is a graph based view. The "+" in the center marks the "current" time. You can thus see both into the future and the past (relative to the current frame) in this view. All 8 data bytes are graphed according to their value. You can thus see in the graph what the value is doing as time ticks by.

Between these three views you should have a very good idea of how the data bytes change over time.

CONTROLLING THE FLOW

ADDITIONAL CONTROL OPTIONS

REFERENCE VALUES

SEEKING TO SPECIFIC VALUES

BISECTOR WINDOW

USING THE BISECTOR WINDOW

ID Range - Grab a set of frames between two values. Note that you cannot pick and choose frame IDs here but rather just use a list. If you want to pick and choose then use the filter interface on the main form and then save the filtered list from the File menu.

Frame Number - You can split right at a given frame number. All frames up to that number will be on one side with all the rest on the other.

Percentage - Pretty much just like the Frame Number option but in percentage instead in case that is more convenient.

In all cases, you have the option of which side of the split you want to save. Click "Calculate Split" to process the split. You will see above the buttons a reference of how many frames there were in total and how many you would be saving after the split. From here you should be able to do one of two things:

"Save split frames to a new file" - Save the new list of frames (after the split) to a file. You can save to any file format that SavvyCAN supports elsewhere.

"Replace main list with split frames" - Were this to work it would replace the frames loaded in the rest of the application with the split list. I'm sure this would be a really nice thing to be able to do. Well, you can't right now. It's not implemented yet. So, just imagine you can do this. In the mean time you can save to a file then load that file. Sorry...

SNIFFER WINDOW

USING THE SNIFFER WINDOW

This window updates with a 200ms interval.

NOTCHING AND UNNOTCHING

ADVANCED OPTIONS

NEVER EXPIRE IDS

MUTE NOTCHED BITS

FADE INACTIVE BYTES

VIEW BITS

FRAME DETAILS WINDOW

THE PURPOSE OF FRAME DETAILS WINDOW

It provides information about a given frame ID across all frames with that ID. You can get such information as the number of frames, the number of data bytes that frame ID has, the average interval between frames with that ID, and the minimum and maximum interval.

Also listed are detailed statistics for each data byte in that frame. Each byte has listed which bits changed, the range of values found, and a histogram both graphically (at the right-hand side of the window) and textually. The textual representation shows the number of times a specific value occurred.

The top right graph is a histogram of all the bits and the number of times each bit was set. This can be used to quickly visually see where data has changed.

The bottom right graph is of each individual byte as its value varies over time. All textual information can be saved to a text file for later analysis.

FILE COMPARISON WINDOW

THE PURPOSE OF THE FILE COMPARATOR

THE LAYOUT OF THE DIFFERENCES LIST

FUZZING WINDOW

THE PURPOSE OF FUZZING

FUZZING IS DANGEROUS

CONTROLLING THE FUZZY BEAST

The "ID Scanning" box has two radio buttons:

But, perhaps you don't want to fuzz IDs like that? The next box is "ID Selection" and the choices are:

The last box is "Bit Scanning"

In order to fuzz bits you need to set which bits to fuzz and which not to. As listed at the bottom of the window, there is a color code to the 8x8 grid. Clicking cells in the grid will toggle them between their various values. White bits are never set, black bits are always set no matter what, green bits follow the fuzzing pattern you specified in "Bit Scanning" You can also set the bytes directly with the text boxes above the 8x8 grid. Setting a hexadecimal value in these boxes will set the relevant bits in the 8x8 grid. You must press the ENTER/RETURN key to set the values. Merely changing the value will not update it (as a safety measure).

PULLING THE TRIGGER

ISO-TP DECODER

USING THE ISO-TP DECODER

The main list at the top shows any messages that seem to conform to ISO-TP. There will very likely be messages here which aren't really ISO-TP. You can deselect IDs that seem to generate false positives so that they quit showing up in this list. As you can see in the picture only the ids 0x7E0 through 0x7EA were selected. These IDs are standard for UDS communication. If you want to immediately recalculate the results to exclude the deselected IDs then push "Interpret Previously Captured Frames" to regenerate the whole list. Otherwise the effect of changing the ID selections will only happen for newly captured frames.

The "Show incomplete and/or corrupted messages" checkbox will cause a lot of false positives and should only be used as a last resort if you suspect that you might have some dropped traffic.

"Use extended addressing" will cause the decoder to assume that extended addressing is being used on this CAN bus. Extended addressing adds an additional byte of addressing that is found in the data bytes of the frame. This isn't that commonly used but is used on some vehicles and ISO-TP decoding won't work properly unless this setting is correct. If you find that decoding seems to have failed you might try toggling this setting to see if it helps. Remember to click "Interpret Previously Captured Frames" to recalculate things for previously captured traffic.

Once you have messages in the table at the top of the window you can click on a message to get more details about it in the text box in the lower left. In the picture you can see that 0x7F 0x10 0x12 was interpreted as a UDS error response saying that the ECU does not support the requested sub-function passed to the diagnostic session control service. This is much easier than trying to remember what all those bytes mean off the top of your head!

RANGE STATE WINDOW

USING THE RANGE STATE WINDOW

To use it first set up the follow things:

Once you've got it all set up click "Recalculate Candidate Signals." Be prepared to wait depending on what options you selected. Once it is done processing you'll get a list of candidates in the upper list labeled "Candidate Signals." Here you can see all of the signals it found. You get the ID, the starting bit (remember, bits start at 0 and go through 63), the length, and whether it was signed/unsigned and big/little endian. If you click on or otherwise select a signal in this list then a graphical view of it will appear in the graphing area beneath. You might try the arrow keys Up and Down to move through the list. You can even hold down the arrow key and let it rapidly scroll. As it scrolls through the signals you can look at the graph and stop when you see a signal that catches your eye. This is useful as you can have hundreds of candidates and it is tedious to view them explicitly one at a time.

UDS SCAN WINDOW

PURPOSE OF THE UDS SCAN WINDOW

USING THE UDS SCAN WINDOW

"Show tests with no Replies" - This checkbox does what it says. It is a personal preference whether you'd like to see an entry in the list for scans that returned no results. Sometimes an ECU will just plain ignore messages it doesn't like. In that case you have the option to see an entry in the list telling you that the message was ignored or whether you'd prefer to reduce clutter and just skip anything that had no reply.

You need to also set a type of scan to do. You can select more than one type but if you don't set any then you aren't going to see any results. Keep that in mind as none are checked by default.

"Read By ID" - UDS allows one to read data from the ECU by an ID number. These are not defined anywhere and are custom to each ECU. But, you can use this to scan a range of IDs to see if you get a response to any of them. There is no real standard for how many bytes the ID will be. It could be 1, it could be 2, 3, 4. It's likely to be around 2. You can set the number of subfunction bytes which will set the size of the ID. Then you can set the upper and lower bound to scan.

"Read By Addr" - You can also read data by address. Like IDs the address could be different sizes depending on the hardware you are querying. This works the same as reading by ID but by address instead.

"Session Ctrl" - UDS has the concept of session type. Some types are "normal" "extended diagnostics" "programming". Scanning for session type will try them all and let you know which the device supports. However, note that you might get a response that indicates that conditions are not correct or that access was denied. This probably means that the mode is actually supported but you'd have to do the right things first. This is still useful information. This scan window is too simple to use for further cracking of such things but the scripting interface is the perfect thing to use instead.

"ECU Reset" - The ECU might also support being reset by a UDS message. This scan type will try the various reset types and see which are supported.

"Security Access" - When a device is first started and normally operating it will generally not allow you to do potentially dangerous or sensitive operations such as downloading firmware or changing parameters. To do these things you need to enter a different security level. The security access mechanism is used for this. There are a few different security levels that are likely to be supported. This scan type will attempt to find security levels and see if they are protected or not. That is, unfortunately for the casual cracker, most of the time the elevate security levels will be protected by a challenge/response system. The ECU will send you a challenge in the form of one or more random looking bytes. You are tasked with returning the proper response for those challenge bytes. You generally don't have very many guesses before your hands are slapped. Sometimes the C/R is actually fixed and you can just capture valid traffic once and then use the same response forever. Sometimes the C/R is stupidly easy or there are only a couple of different possible answers. Sometimes the ECU developer actually took more than 2 seconds to implement these features and your work will be cut out for you. This scan type will find which levels the ECU seems to support but is unlikely to actually unlock them.

"Tester Present" - A scan that tries to see if tester present is supported. It almost certainly is. This scan can be used to sweep a wide range of addresses just to narrow down the list of addresses to scan more thoroughly. Normally tester present is sent periodically by a connected device just to let the ECU know that someone is still there.

"Wildcard" - Allows for you to set a lower and upper range for the service byte as well as the number of subfunction bytes and the range there as well. This allows for UDS fuzzing by shooting the moon and trying a huge range of traffic just to see what is supported and what isn't. This test can take a VERY long time if you aren't careful but will thoroughly determine what the ECU will support and what it won't.

PLAYBACK WINDOW

PREPARING FRAMES FOR PLAYBACK

Once you've set up a sequence of frames to playback you can also decide whether you'd like to loop that sequence forever or not. Up above the Playback Sequence and ID Filtering sections is the "Loop Sequence" checkbox.

PLAYING BACK FRAMES

The next order of business is frame timing. There are two approaches possible here. If you click "Use original frame timing from captured frames" then frames will be sent out in approximately the same timing as they came in with. The word approximately is used because it is difficult to get 1ms timing precision on a desktop OS. Frames that come in rapidly might have a 2-3ms jitter. In practice this is almost always irrelevant. This setting is suitable for nearly all uses.

Alternatively, it is also possible to send on a set schedule. With the "Use original" checkbox not checked you can set a playback speed in milliseconds and a burst rate. Burst means that it'll send that many frames every tick. So, if you have a burst of 5 and a timing of 10ms then every 10ms 5 frames will be sent. This mode can provide for a predictable number of frames per second and could be useful to test how quickly a device really requires traffic without faulting. But, it will potentially drastically alter the timing of frames compared to their timing when they were captured.

The top of the window has a series of 6 icons all in a row:

PLAYBACK STATUS

CUSTOM SENDER WINDOW

GENERAL OVERVIEW

LAYOUT OF THE VIEW

WRITING TRIGGER RULES

Triggers are allowed to have one or more conditions. Each condition contained within a single trigger is separated by a space ' '.

The program implements the following conditions:

Now, a full example of a trigger line: "id0x200 5ms 10x bus0,1000ms" This trigger means: Trigger when a frame with ID 0x200 comes in on bus 0. Wait 5 milliseconds before sending and only allow this to happen at most 10 times. Also, always trigger every 1 second and never stop doing this.

WRITING MODIFICATIONS

Modifications always start with a data byte to modify The syntax is 'D' or 'd' followed by a number 0 through 7. For example: 'D4'. This is then always followed by an equal sign '='. Thereafter there is a string of operands and operations.

Operands have a special syntax. Each operand can have multiple sections separated by colons ':'.

A few full examples of operands:

Each operand is usually followed by an operation and then a second operand. If no operation or second operand is found that is also OK. Thus a modifier can be as simple as "D0 = D1" if you choose. Operands can also be directly chained such that the output of the last operation is used as the left hand operand for the next operation. This will be shown later on.

Modifiers can use the following operations:

Putting all of that together yields complete modifiers. For simplicity all operations are done left to right. There is no special order of operations like in normal mathematics.

Here are a few examples:

SCRIPTING INTERFACE

PURPOSE OF THE SCRIPTING INTERFACE

MANAGING SCRIPTS

GETTING SCRIPT STATUS

The other way to see script status is to use the "Public Variables" interface. Here you will find variables that were registered by the current script. Each script has its own list so information that needs to be updated frequently and/or specific to a script and easily accessible should be registered here. But, public variables can have their value set by you, the user, as well. So, care should be taken not to edit variables used for script feedback and scripts shouldn't try to change the value of variables used for input to the program.

WRITING SCRIPTS

CALLBACK FUNCTIONS

setup () - If you create a function named setup then it will be called as soon as the script starts. Yes, you probably could just dump code into no function at all right into the file but that's bad form!

tick () - If you registered to receive a periodic tick within your setup function then the script interface will call this function for every tick. You can do whatever you need to periodically do here. But, you get only one tick handler so if you need multiple tick rates you'll have to create a fast tick here and dispatch from this function at different rates yourself.

gotCANFrame (bus, id, len, data) - A callback that will be called whenever a CAN frame comes in that you've registered for. You did register for frames in your setup function didn't you? Well, if you use one of the below callbacks you might not need this one.

gotISOTPMessage (bus, id, len, data) - If you are instead looking for ISO-TP messages (which could have been multiple CAN frames in length) then you can create this function and it will automatically be registered with the system. But, you still will need to set which ISO-TP message IDs you want to receive. That is covered later on.

gotUDSMessage (bus, id, service, subfunc, len, data) - UDS messages are transmitted over ISO-TP but with additional structure. If you're looking to interface directly at the UDS level then you can create this function to have it automatically registered. As with raw CAN and ISO-TP you still need to specify which messages IDs you are interested in.

THE HOST OBJECT

host.setTickInterval(interval) - If the interval is more than 0 then your tick callback will be called every "interval" milliseconds. If a value of 0 is passed then the tick timer will be stopped.

host.log(text) - Send text to the log window. It will be timestamped, marked according to which script sent it, and placed into the log window.

host.addParameter("variablename") - Add the named variable to the list of public variables. From then on any changes that you make in the GUI will immediately show up in the script and any changes the script makes to a value will reflect in the GUI within 250ms. Remember to use quotes around the variable name. You want to pass the variable name, not its value.

THE CAN OBJECT

can.setFilter(id, mask, bus) - register to receive messages based on an ID, Mask, and Bus. It works like this. First the bus is compared. If it doesn't match the frame is not delivered to you. Then, the incoming frame has its ID ANDed with your mask. Let's say your mask is 0x7F0 and the incoming frame has an ID of 0x235. 0x235 AND 0x7F0 is 0x230. This value is compared to the ID you passed. So, if your filter ID is 0x230 then the frame is accepted and you will get a callback with the frame. Otherwise the frame is not delivered to you. This masking setup is very common in CAN bus interfaces. Basically, the mask allows a single filter to accept a range of IDs. 0x7F0 would accept 16 different IDs (0x230 through 0x23F in this case). 0x700 accepts 256 different IDs, etc.

can.clearFilters() - remove all filters and revert to a clean state. You will no longer receive any CAN callbacks unless you create more filters with setFilter.

can.sendFrame(bus, id, length, data) - Send a CAN frame out the given bus. The CAN id will be what you set as will the length. The length can thus be different from the actual length of "data" which should be a valid javascript array. The length can not exceed 8. The frame will be sent as soon as possible so long as that bus is connected and not in listen only mode.

THE ISOTP OBJECT

isotp.clearFilters() - Clear all ISO-TP filters and no longer receive ISO-TP traffic.

isotp.sendISOTP(bus, id, length, data) - As in the can version. The difference here is that ISO-TP messages can be longer than 8 bytes and so might get turned into a multi-frame set of messages with flow control. This is handled for you by SavvyCAN so you needn't handle of the details of the exchange.

THE UDS OBJECT

uds.clearFilter() - Remove all filters and quit receiving UDS traffic.

uds.sendUDS(bus, id, service, sublen, subfunc, length, data) - Sends a UDS message out from the script. service must be between 0 and 255, subfunc can be larger than one byte if needed. data is only needed for extended payloads as the actual UDS protocol is handled by the service and subfunc parameters.

A FULL EXAMPLE SCRIPT

var newID = 0; //set this to the ID you want your RLEC to become
function setup ()
{
    host.log("RLEC ID Changer");
    can.setFilter(0x0, 0x0F, 0);
    can.sendFrame(0, 0x7E0, 8, [0x0d, 1, 0, 0, 0, 0, 0, 0]);
}
function gotCANFrame (bus, id, len, data)
{
     var dataBytes = [];
    if (len == 8)
    {
        if (data[0] == 0xd && data[1] == 1 && data[2] == 0xAA)
        {
            host.log("Got challenge: 0x" + data[3].toString(16) + data[4].toString(16));
            var notData3 = ~data[3];
            var notData4 = ~data[4];
            dataBytes[0] = 0xD;
            dataBytes[1] = 2;
            dataBytes[2] = ((notData4 & 0xF) << 4) + ((notData3 >> 4) & 0xF);
            dataBytes[3] = ((notData4 >> 4) & 0xF) + ((notData3 & 0xF) << 4);
            dataBytes[4] = 0;
            dataBytes[5] = 0;
            dataBytes[6] = 0;
            dataBytes[7] = 0;
            can.sendFrame(0, 0x7E0, 8, dataBytes);
        }
        if (data[0] == 0xd && data[1] == 2 && data[2] == 0xAA)
        {
            host.log("Passed security Check!");
            dataBytes[0] = 4;
            dataBytes[1] = 0x15;
            dataBytes[2] = newID;
            can.sendFrame(0, 0x7E0, 8, dataBytes);
        }
        if (data[0] ==4 && data[1] == 0x15 && data[2] == 0xAA)
        {
            host.log("ID Reprogramming Successful!");
        }
    }
}

AUTHOR

COPYRIGHT