A large update to the help files. The reference pictures have been

updated and several of the help files have been updated. This process
is not done yet.

help/connectionwindow.md

@@ -3,46 +3,19 @@ Connection Window
 
 ![Connection Window](./images/ConnectionWindow.png)
 
-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.
-
+The connection window is used to add, remove, and modify connections.
 
 Connecting To A Dongle
 ==============================
+Click the button "Add New Device Connection" and fill out the screen with the proper settings. Some devices may create more than one bus but will still only take up one row in the list.
 
-SavvyCAN is able to connect to GVRET compatible devices to capture new traffic. These 
-devices will present as serial ports on the connected PC.
-To connect to a dongle select the proper serial port and click "Create New Connection". 
-If a valid device is found on that serial port the first statusbar section will update 
-and the currently set canbus speeds will show in the table at the left of the window. 
-These speeds can then be changed by clicking on the speed (or otherwise selecting the cell 
-in the table) and typing in a new value. Leaving the cell will update the speed to the new 
-value. GVRET devices also support setting "listen only" on each bus. This mode causes the 
-device to not acknowledge any traffic or try to modify the bus at all. It is as it says, 
-a mode where you can only listen to whatever traffic is found on the bus. Some older GVRET 
-devices supported a mode where you could change the second bus between single wire CAN 
-and normal CAN. This is deprecated. However, newer GVRET devices have dedicated single 
-wire CAN buses and the relevant bus will show the checkbox.
+Removing a Device
+==================
+Click on the device in the list in the upper lefthand side of the window then click the "Remove Selected Device" button
 
-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.
+Modifying Device Settings
+=========================
+Once you have selected a bus from the list you can disconnect it or modify its settings in the parameters at the buttom left. You must click "Save Bus Settings" to confirm the new settings. If the device you have selected has multiple buses then you will see tabs appear below where it says "Bus Details", one for each bus.
 
 Debugging Connection Problems
 ==============================

help/framedetails.md

@@ -12,6 +12,10 @@ It provides information about a given frame ID across all frames with that ID. Y
 
 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. 
 
+If you have a DBC file loaded which matches the ID you've selected then you will also see details about how the various signals changed over the capture.
+
 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.
+
+The interval histogram is in logarithmic scale and shows a listing of what intervals were seen between frames. This can be used to visually see the frame timing. Some frames get sent very regularly. They will show a very pronouced bell curve. Other frames might get sent on demand. These frames will have peaks at odd places and not conform to a nice distribution. For instance, in the picture you can see that the frame shows many frames around 15-20ms timing but some around 40, 60, and 80 as well. This might indicate the frame is not always sent or it might show that the frame is getting lost. After all, those timings are all around multiples of 20ms.

help/fuzzingwindow.md

@@ -17,7 +17,7 @@ You have now been warned. Sending random garbage over the CAN bus to see what ha
 Controlling the Fuzzy Beast
 ===========================
 
-So, you want to give it a try? Let's do it! First of all, you can set the delay between frames and the burst rate. The delay is in milliseconds but can be set as low as 0. If the delay is set to 0 then the system will attempt to send frames as fast as it can. However, even then you may not get quite as many frames per second as you'd like. Even at 0 it will still be scheduled by your operating system and so might not quite get to the speed you want. The burst rate can cause the program to send one than one frame each interval. This is useful as a CAN bus could potentially support 2000 to 8000 frames per second. If you need rapid frame sending your best bet is to set the sending interval to 1-2ms and then adjust the burst
+So, you want to give it a try? Let's do it! First of all, you can set the delay between frames and the burst rate. The delay is in milliseconds but can be set as low as 0. If the delay is set to 0 then the system will attempt to send frames as fast as it can. However, even then you may not get quite as many frames per second as you'd like. Even at 0 it will still be scheduled by your operating system and so might not quite get to the speed you want. The burst rate can cause the program to send more than one frame each interval. This is useful as a CAN bus could potentially support 2000 to 8000 frames per second. If you need rapid frame sending your best bet is to set the sending interval to 1-2ms and then adjust the burst
 rate until you get your desired sending rate. Then you can set the number of bytes to send. Ordinarily this would be the full 8 but you can experiment with smaller frames. You can set to send on a specific bus. That's all the simple settings. It gets a bit more complicated now.
 
 The "ID Scanning" box has two radio buttons:

help/graphsetup.md

@@ -39,5 +39,12 @@ Once you've set both Data Len and Little Endian you can set the bits to use. The
 
 "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.
+"Only Points" will graph using disconnected points instead of lines.
 
+"Point Style" has a list of every style you can use for points. The default is to not show the points and instead draw a line through where the points are at. But, there are many other options.
+
+"Line Thickness" will set how many pixels the line should be wide. The default of 1 is the "fastest" but you can use other thicknesses.
+
+"Line 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.
+
+"Fill Color" If you're feeling fancy you can also specify a fill color. The default fill color has an alpha value of 0 meaning it is completely transparent / no used. If you set a fill color you will need to set the alpha channel as well. An alpha of even 40-60 is usually plenty. 

help/mainscreen.md

@@ -12,42 +12,37 @@ The Main Frame List
 
 The main frame list takes up the majority of the main screen. This list consists of the following sections:
 
-- Timestamp: The timestamp is either in microseconds or seconds. This is a setting in preferences. Either way, the timestamp can have
-  microsecond resolution. The difference is just whether there is a decimal point or not. GVRET has the ability to maintain full microsecond
-  resolution for timestamping purposes. There is a third timing mode where the timestamp can be customized and is based upon the actual "clock" time.
+- Timestamp: The timestamp is either in microseconds or seconds. This is a setting in preferences. Either way, the timestamp can have microsecond resolution. The difference is just whether there is a decimal point or not. GVRET has the ability to maintain full microsecond resolution for timestamping purposes. There is a third timing mode where the timestamp can be customized and is based upon the actual "clock" time.
 - ID: The ID is specified either in hexadecimal or decimal (a preference you can set). This is the message identifier sent over the CAN bus.
+- RTR: 0 = Standard Message 1 = Remote transmit request. An RTR frame merely asks a node to send a message, it has no payload of its own.
 - Ext: 0 = Standard message (11 bit ID). 1 = Extended message (29 bit ID)
 - Dir: Either "Rx" or "Tx" to show whether SavvyCAN has received or sent this message.
 - Bus: SavvyCAN supports a variety of capture hardware. GVRET compatible devices can support more than one bus. The bus a frame came in on
   is specified here. Many file formats do not specify bus and thus all frames will be loaded as bus 0.
 - Len: The number of data bytes that were sent with this frame. It can range from 0 to 8.
+- ASCII: A character based view of the CAN bytes in ASCII characters. Many systems that send serial numbers or VIN numbers will send them in ASCII and these will thus be visible here.
 - Data: All of the data bytes separated by spaces. Can be in either hexadecimal or decimal (preference). If "Interpret Frames" is checked you will
-  also see extra data at the end of any frames that have DBC data. To see the rest of this data click upon the frame in the list. It will
-  automatically expand to show all signals attached to that frame.
+  also see extra data at the end of any frames that have DBC data. To see the rest of this data click upon the frame in the list. It will automatically expand to show all signals attached to that frame.
 
 
 The Bottom Statusbar
 ====================
 
-At the very bottom of the main screen is a status bar with two sections. 
+At the very bottom of the main screen is a status bar with three sections. 
 
 * The first section shows the connection status. You will see the number of currently connected buses here.
 * The second section shows which file is currently loaded. This is updated by loading or saving.
+* The third section reminds you that F1 will bring up help. Most all screens have their own help.
 
 
 The Rest of the Main Window
 ===========================
 
-To the right of the main frames list is an area that shows the total number of captured frames and the frames per second. Total frames might not match
-the number of shown frames. If you've deselected any IDs in the filter list then fewer frames will be shown. Frames per second is calculated as
-an average and so will wind up or down when there is a sudden change.
+To the right of the main frames list is an area that shows the total number of captured frames and the frames per second. Total frames might not match the number of shown frames. If you've deselected any IDs in the filter list then fewer frames will be shown. Frames per second is calculated as an average and so will wind up or down when there is a sudden change.
 
-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.
+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 "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 a device 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.
 
@@ -61,6 +56,12 @@ this off for performance reasons (interpreting takes some extra processor power
 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.
 
+"Expand All Rows" will expand all the rows to show every signal in every message. This will take a **VERY** long time if there are many messages loaded. Because of this, you may receive a warning if the program determines that this will take an excessive amount of time to complete. You can make it work faster by filtering away any unneeded messages.
+
+"Collapse All Rows" will drop all rows back to taking up only one line. This can also take a while to run and will also warn if the operation seems like it will take a very long time to complete.
+
+"Bus Filtering" allows for messages to be shown or hidden based on which bus they came in on.
+
 "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.
 
@@ -71,14 +72,11 @@ Loading And Saving Frames
 What CANBus analysis tool would be complete without an easy way to load and save frames? 
 
 SavvyCAN can load and save in several formats (a few of which are listed below):
-	- CRTD: This format was made by Mark Webb-Johnson for OVMS (open vehicle monitoring system) and other related tools. It is a reasonably 
-	  readable and compact format.
+	- CRTD: This format was made by Mark Webb-Johnson for OVMS (open vehicle monitoring system) and other related tools. It is a reasonably readable and compact format.
 	- GVRET: This is the native format for GVRET and SavvyCAN. The GVRET format saves more information such as the bus a frame originated on. This format is in CSV 
 	  (comma delimited) format and as such can easily be loaded into your favorite spreadsheet program as well.
 	- Generic ID/DATA - Another CSV format. This is a very cut down format with limited information.
-	- BusMaster - This is the format output by the BusMaster CANBus program. BusMaster is an open source Windows-only somewhat clone 
-	  of CANAlyzer (the 800lb gorilla in the analysis space). The ability to load and save in this format makes SavvyCAN fully capable 
-	  of swapping data with BusMaster should you need to do so.
+	- BusMaster - This is the format output by the BusMaster CANBus program. BusMaster is an open source Windows-only somewhat clone of CANAlyzer (the 800lb gorilla in the analysis space). The ability to load and save in this format makes SavvyCAN fully capable of swapping data with BusMaster should you need to do so.
 	- Microchip - Format output by Microchip CANBus tools. Perhaps you have logs that were captured with a $100 Microchip dongle? You can load them in SavvyCAN.
 
 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.
@@ -87,33 +85,18 @@ There are many other formats supported. Some are only supported for writing, som
 Filters
 ========
 
-You might notice that there are three entries in the file menu that mention filters. SavvyCAN can filter messages so that you only see some 
-of the messages coming in on the bus. It still saves all incoming messages but you are able to filter which you will view at any given time. 
-SavvyCAN allows for loading and saving the list of frames you'd like to view so that you can easily switch "sets" of frames to view. Also,
-when saving you can optionally save just the frames that you have filtered instead of every captured frame. Filters are set in the lower
-right-hand of the this screen. All IDs are selected by default. To deselect an ID click on the checkbox next to it. You can also deselect
-all IDs or select all IDs. These are useful if you only want to view a couple of IDs (click None then the few you need) or you just want
-to remove a couple (click All and then deselect the ones you don't care about).
+You might notice that there are three entries in the file menu that mention filters. SavvyCAN can filter messages so that you only see some of the messages coming in on the bus. It still saves all incoming messages but you are able to filter which you will view at any given time. 
+SavvyCAN allows for loading and saving the list of frames you'd like to view so that you can easily switch "sets" of frames to view. Also, when saving you can optionally save just the frames that you have filtered instead of every captured frame. Filters are set in the lower right-hand of the this screen. All IDs are selected by default. To deselect an ID click on the checkbox next to it. You can also deselect all IDs or select all IDs. These are useful if you only want to view a couple of IDs (click None then the few you need) or you just want to remove a couple (click All and then deselect the ones you don't care about).
 
 
 
 What is DBC and why would I care?!
 ==================================
 	
-I'm glad you asked. DBC is a file format used to specify how "signals" are stored in "messages." A message is essentially a unique 
-packet of data sent on the CAN bus. Ordinarily this message is differentiated by frame ID. Each ID is a different message (usually).
-A signal is a piece of data stored in a message. For instance, ID 0x105 might be a message from the vehicle control unit to the motor
-inverter. Within that message bytes 0 and 1 might encode the desired torque. That would be a signal. A DBC file allows these relationships
-to be specified and named. It also allows for scaling of values stored in a signal. Additionally, a signal can have values associated with
-textual output. For instance, if a signal encodes the current gear then a DBC file can define that a value of 0 means "Park" and a value
-of 1 means "Drive". This makes analysis a lot easier since you do not need to remember the mapping yourself. In this way data can be better
-understood by users of the program. Also, other windows can use the DBC file for such things as being able to graph a signal without having
-to figure out the actual details of that signal.
+I'm glad you asked. DBC is a file format used to specify how "signals" are stored in "messages." A message is essentially a unique packet of data sent on the CAN bus. Ordinarily this message is differentiated by frame ID. Each ID is a different message (usually). A signal is a piece of data stored in a message. For instance, ID 0x105 might be a message from the vehicle control unit to the motor inverter. Within that message bytes 0 and 1 might encode the desired torque. That would be a signal. A DBC file allows these relationships to be specified and named. It also allows for scaling of values stored in a signal. Additionally, a signal can have values associated with textual output. For instance, if a signal encodes the current gear then a DBC file can define that a value of 0 means "Park" and a value of 1 means "Drive". This makes analysis a lot easier since you do not need to remember the mapping yourself. In this way data can be better understood by users of the program. Also, other windows can use the DBC file for such things as being able to graph a signal without having to figure out the actual details of that signal.
 
 
 How DBC interacts with the main screen?
 =======================================
 	
-First of all, one can load and save DBC files from the "DBC File Manager" found in the File menu. Also in the File menu it is possible to save the currently
-loaded frames but with DBC decoding. This is somewhat like the normal saving functionality with a two differences: there is only one output format
-and that format has all signals contained in each message listed and decoded.
+First of all, one can load and save DBC files from the "DBC File Manager" found in the File menu. Also in the File menu it is possible to save the currently loaded frames but with DBC decoding. This is somewhat like the normal saving functionality with a two differences: there is only one output format and that format has all signals contained in each message listed and decoded.

help/newconnection.md

@@ -0,0 +1,47 @@
+Adding a new connection
+========================
+
+![New Connection](./images/NewConnection.png)
+
+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, Macchina A0, EVTV ESP32 Due.
+
+You can also use a variety of network based connections to gain access to remote capture hardware.
+
+
+Connecting To GVRET Devices
+==============================
+
+SavvyCAN is able to connect to GVRET compatible devices to capture new traffic. These 
+devices will present as serial ports on the connected PC. To connect to a dongle select "Serial Connection." This will bring up a list of serial ports on the machine. Select the proper one and then press "Create New Connection". This will close the window and bring you back to the connection manager window. If connection succeeds the status will show "Connected" for your newly set up device.
+
+You can also connect to some GVRET devices over the network (A0, EVTV ESP32Due). These devices broadcast their address. Once you've selected "Network Connection (GVRET)" you should see a list of IP addresses that appear to have GVRET devices on them. You can also manually enter the proper IP address but if the device did not automatically register itself it is unlikely to work with a manual entry either.
+
+
+Connecting to QT SerialBus Compatible Devices
+=============================================
+
+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.
+
+QT also includes a "virtualcan" device type. You can use this to create a bus that will loop back anything you send to it. This is useful for testing without needing to connect any devices or load any log files.
+
+Connecting to Socketcand
+========================
+
+This is a LINUX only solution which allows one to connect to a socketcan device that is registered on the local network. You can also set up SSH tunnels or VPN to expand the reach over the internet. It should fill out a list of any available socketcand interfaces. Setting up socketcand is outside the scope of this help file but may your GoogleFu be strong.
+
+Connecting over MQTT
+====================
+
+Lastly, it is possible to connect to an MQTT broker to send and receive CAN traffic over the internet. This is much like socketcand but more cross platform and also supports easy broadcasting. For instance, for capture the flag events, it would be possible to connect the device over MQTT and have multiple participants and/or watchers all connected at once. Connection to the MQTT broker is set up in the main SavvyCAN preferences. In this window you merely select the topic name to subscribe to. There is currently no automatic way to list these topics so you will need to know the topic to subscribe to ahead of time. It should be noted that the bidirectional nature of this interface means that everyone is on equal footing. You can create an MQTT interface that others can connect to or you can connect to a topic that is currently being sent to from elsewhere and get the traffic. Additionally, the SavvyCAN source code at GitHub has a python script which can be used to connect a socketcan interface to MQTT. You can use this script on a remote system to connect it to the internet so that you can run SavvyCAN somewhere apart from the device under test.

help/playbackwindow.md

@@ -30,6 +30,6 @@ The top of the window has a series of 6 icons all in a row:
 6. White Right Arrow - Play the next frame (just one frame)
 
 Playback Status
-================
+===============
 
 Below the number spinners for Playback Speed and Burst Rate is text that displays the currently playing sequence item along with the current frame within that capture.

help/preferences.md

@@ -3,35 +3,58 @@ Preference Window
 
 ![Preference Window](./images/Preferences.png)
 
-Setting Preferences
-====================
-
 There are a variety of preferences that can be set in the program and persisted for future sessions.
 
+General Settings
+====================
+
 "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.
 
+"Save/Restore CAN bus connections": This will cause the program to remember the devices you were connected to last time you ran the program and attempt to reconnect to them upon start up.
+
 "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.
 
+"Label filters using messages from DBC files": Part of a two part system. If this is selected and a given DBC file also has its checkbox checked then the IDs list on the main screen (lower right) used for filtering will have not only the IDs but also the message name from the DBC file. This will allow for more easily determining what a given message means. Sometimes IDs can be hard to remember. Do note that this checkbox must be checked or the checkboxes for each loaded DBC file won't do anything. This is the master on/off switch.
+
 "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.
+"OpenGL Accelerated AntiAliased Graphing": 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.
 
+
+Flow View Settings
+==================
 "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.
 
+
+Playback Window Settings
+========================
 "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.
 
+
+File Info And Comparator Window Settings
+========================================
 "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.
+
+MQTT Settings
+=============
+
+MQTT allows SavvyCAN to connec to a broker for CAN transmission over the internet. You will need to set up the host, port, username, and password. These things are determined by your broker. You can run your own on Linux with Mosquitto.
+
+
+Final Word of Warning
+=====================
+
+After changing preferences it is the best practice to close and reopen the application to ensure that all settings have taken effect. Some settings do take effect immediately but others do not.

help/rangestate.md

@@ -19,3 +19,5 @@ To use it first set up the follow things:
 7. Signed Mode - Likewise, any signal over 1 bit could be either unsigned or signed. Signed signals have their highest bit as 1 for negative numbers and 0 for positive numbers. You can search for only unsigned signals, only signed, or try it both ways. There really isn't any rhyme or reason for when a signal would be signed or unsigned. It could easily be both ways so unless you're sure it's probably safest to allow the program to try it both ways and you can pick which looks best.
 
 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.
+
+This window is handy for quickly finding signals if you know what the shape should be. For instance, vehicle speed is pretty easy to recognize. You can't go from 0 to 100 in an instant so speed tends to have a lot of sweeping motions up and down. Thus, being able to quickly see the signals makes it easy to find things that look like they "could" be speed. It might be vehicle speed in km/h, it might be mph, it could be wheel RPM. But, being able to see the graphs at a glance helps to narrow down the possibilities.

help/scriptingwindow.md

@@ -83,7 +83,6 @@ uds.sendUDS(bus, id, service, sublen, subfunc, length, data) - Sends a UDS messa
 
 A full example script
 =====================
-
 ::
 
     var newID = 0; //set this to the ID you want your RLEC to become

help/signaleditor.md

@@ -6,15 +6,11 @@ DBC Signal Editor
 Defining and Editing Signals
 ============================
 
-If you're starting from scratch or otherwise adding a signal then you will need to right click in the list box in the upper left of the window. From there select "Add a New Signal." This will create a randomly named signal that you can then edit.
+On the right side you can rename the signal and you'll see that it is renamed in the DBC window as well. 
 
-Otherwise, select a signal to edit. The details of it will fill out the rest of the window.
+"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 unless you have multiplexed signals. 
 
-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. 
+"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. The simplest explanation is that little endian signals start at the start bit and then go "down" in bit numbers while big endian mode goes "up."
 
 "Type" can be:
 1. UNSIGNED INTEGER - No sign bit, only positive numbers
@@ -23,20 +19,26 @@ On the right side you can rename the signal and you'll see that it is renamed in
 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
+It should be noted that this pertains **ONLY** to the way the signal is encoded within the CAN frame itself. Signals encoded as integers can still take fractional values because of scaling.
 
-"Bias" is added to each value generated by the signal to set it at a different bias point
+"Scale" is used to multiply the signal by the value to scale it appropriately. This could turn an integer into a "real" number instead. For instance, if the signal is in 0.002V increments then the scale would be 0.002 and a value of 48 stored in the CAN frame will be multiplied by 0.002 and end up as a value of 0.096.
+
+"Bias" is added to each value generated by the signal to set it at a different bias point. Think of this as the value the signal will report if the encoded value from the CAN frame was 0.
 
 "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.
+"Max Value" is likewise informational. However, both can be used in other applications, or this one in the future, to help with automatic generation. For instance, signals could be fuzzed with values between the min/max values specified here. As such, it is a good idea to fill these values appropriately.
 
 "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. 
+"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. It could potentially be used for ECU simulation in the future (or by other applications).
 
-"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.
+"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 Low and High values with something unique. However, it is also valid to have "extended" multiplexing. In extended multiplexing there are potentially multiple levels of multiplexing. There is still only one multiplexor for a message. But, now the next level down can be **BOTH** a multiplexed signal **AND** a multiplexor for a lower level. Extended multiplexing also allows for low/high thresholds for matching. So, for multi-level multiplexing you'd set one multiplexor. Then, set as "extended" all the middle signals in the hierarchy. You will also need to set the multiplex parent. For the level just under the multiplexor you'd select the multiplexor. The bottom signals can be either extended or "multiplexed" and must have their multiplex parent set to the proper signal. 
+
+Extended multiplexing is complicated so here's an example:
+
+OBD-II really does use extended multiplexing. The multiplexor in this case is the OBD-II service. Various services are available and the interpretation of the rest of the frame is contingent on which service this frame encodes for. Service 1 is "Show current data". So, one of the entries for the next level down is Service 1. This would be set as an extended multiplexed signal with a low and high value of 1 and a parent listed as the service specifier signal. Within service 1 there are many "PID" codes, each of which presents a different data item. PID 04 is "Fuel system status" so there might be yet another signal set as a "multiplexed" signal with a low/high value of 4 and a multiplex parent set as the extended signal setup for service 1. In this way there are three levels of signals set up.
 
 "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. 
+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 its interpreted value. But, known good values can be entered in the Value Table to make them easier to work with.

help/sniffer.md

@@ -27,7 +27,7 @@ and will not color the output if those bits are toggled in the future. They will
 be ignored except that you can visually still see them updating. If you click the Notch 
 button repeatedly it will add any new changed bits to the old changed bits. In this way you 
 can build up a set of bits to ignore. Un-notching causes all notched (ignored) bits to be 
-reset and thus all changes will be colored once again. 
+reset and thus all changes will be colored once again. Notching is used to ignore bits that are changing all of the time. Why do this? The biggest reason is that you will probably want to ignore the "steady state" when you are doing research. Here is an example: Let's say you are searching for the steering position in your car. If you aren't moving the steering wheel you could safely assume that the value is not changing either. So, you might notch several times to mask out all the changing bits. You know anything currently changing isn't steering angle because you aren't moving the steering wheel. So, after thoroughly notching you then move the steeering wheel and see if you can spot an ID where suddenly bits changed where they weren't before. This can also be used to find gear selectors, speed and tachometer values, etc. Keep in mind that the default behavior when bits are notched is to still update but no longer change color. You can change this (see below)
 
 Advanced Options
 ==================
@@ -53,7 +53,7 @@ ignore any notched bits and not even change the display to update if only notche
 This completely hides all notched data. The view of the frames will then NOT perfectly or correctly
 represent the actual most up to date data for each ID. So, use this option with caution. But, it
 is handy when you are looking for a needle in a haystack and you don't want things changing if you've
-already told the program to notch them away.
+already told the program to notch them away. This will make changes even more visible but you must be cautious since the data is now somewhat "fake" anywhere there are notched bits.
 
 Fade inactive bytes
 ====================

help/temporalwindow.md

@@ -18,3 +18,8 @@ bright streaks in the background color). There isn't a lot that can be done to m
 zooming and panning the view. If you get the view too messed up the R key will reset the view back to standard. As with the Graphing Window, it is 
 possible to select just the X or Y axis and zoom/pan that axis without affecting the other one. To do so, click on the axis marks of the axis you'd like
 to independently control. To control both again click in the graph itself.
+
+So, what is it good for?
+========================
+
+The idea here is to find areas of high traffic so that you can investigate those areas. Chances are, things that are sent rapidly are important. Steering data is usually sent rapidly, low level engine performance data is usually sent rapidly. These things can change rapidly and are safety critical so they tend to have a high rate of transmission. This window can also show where "clusters" of IDs are. Sometimes a given device will send long form data over a range of ideas, say, 0x102, 0x103, 0x104. These clusters could be visible on the temporal graph. A reasonable rule of thumb is that the "busy" areas of the temporal graph are probably important. The question is, for what? This window thus takes a supporting role and other windows would help answer the question of "why is there so much traffic there?"

help/uds_scanner.md

@@ -12,7 +12,7 @@ This is essentially another CAN fuzzing window but a very special one. This wind
 Using the UDS Scan Window
 ==========================
 
-UDS queries are sent out on the bus from "Starting ID" to "Ending ID". Usually UDS compliant ECUs will respond to 0x7E0 through 0x7E7 which is why those are the defaults. Some vehicles use UDS "like" protocols on other IDs. Usually UDS nodes reply with an ID 8 higher than the request ID. This is thus the default in the program. However, some nodes cheat and do not do this. It is quite common for responses to come from an address 16 higher instead. To deal with this situation there is a checkbox "Allow adaptive reply offset." If this is checked then replies will be accepted no matter what address they come from. Deselecting this will cause only replies of the proper offset to be accepted. The offset defaults to 8 but can be changed with the "Reply Offset" selector. Additionally, you can select which bus to scan and set how long you want to wait for replies. 
+UDS queries are sent out on the bus from "Starting ID" to "Ending ID". Usually UDS compliant ECUs will respond to 0x7E0 through 0x7E7 which is why those are the defaults. Some vehicles use UDS "like" protocols on other IDs. Usually UDS nodes reply with an ID 8 higher than the request ID. This is thus the default in the program. However, some nodes cheat and do not do this. It is quite common for responses to come from an address 16 higher instead. Sometimes the reply address has no resemblance to the listening address. To deal with this situation there is a checkbox "Allow adaptive reply offset." If this is checked then replies will be accepted no matter what address they come from. Deselecting this will cause only replies of the proper offset to be accepted. The offset defaults to 8 but can be changed with the "Reply Offset" selector. Additionally, you can select which bus to scan and set how long you want to wait for replies. 
 
 "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.