From ECE Department Wiki

Bobcat CAN Bus Data Logger

Members (from left to right)

• Chestin Josewski
• Karl Becker
• Matthew Bitterman
• Michael Taube
• Advised by: Dr. Glower

Project Description

Log all data transmitted over CAN-Bus for at least a 4 hour period and store for analysis at a later time.  Be able to specify certain CAN-Bus messages for which filtering will be applied.  Make data accessible via static or removable memory.  The configuration software will run on Windows XP.  Ensure the designed software is compatible with Bobcat’s version of CAN.   

• Read and record all messages sent over the CAN bus
• Store recorded CAN messages to a memory storage device
• Physical size of device must fit into a space 8”x7”x3”
• Flash memory greater than 20MB to fit at least four hours of running data
• Create software to run on Windows XP to parse recorded CAN data

Technical Challenges

There were many challenges that our group had to overcome. This was a new project from Bobcat so there was no previous design to go from. We also had to organize four soon-to-be engineers in a single project. Then the requirements came. We had to read messages from a CAN bus, save a lot of data, and design a software system that allows the user to scan through the data for certain messages. We are also one of the first design groups to work with Bobcat so there is added pressure to succeed. The first thing that needed to be done is delegate different parts of the project. The breakdown was reading the CAN bus, store data using a flash device, and develop a software program to filter the data.

Task Assignment

With four members in the group, the most reasonable thing to do was divide and conqueror. We made a list of the individual tasks and voted on who wanted to tackle what part.

• Reading CAN messages was one of the biggest challenges to our project. None of us were familliar with CAN signals. Chestin and Michael were assigned to reading the CAN messages. Each person had a different processor to try and get working. Whichever person was successful faster would be the processor in the final design. Then the other person would help out on other tasks needed to be accomplished.
• Matt worked on finding a device that would store CAN messages. This required finding a device and understanding how to write to it. The processor that writes to the device would be decided on later. This allowed Matt to choose if the same processor could be used in both receiving and writing CAN messages.
• Karl was then in charge of designing software that would be easy to use. This needed to open large data files and have the capability to filter it. The software needed to be compatible with Windows XP. Since we were unable to tell how the data was going to be saved, Karl would help out wherever needed.

Reading CAN Messages

Understanding the CAN-bus was the first step in moving the project forward. CAN protocols were looked at by the entire team. It was understood that used two wires transmitted a differential signal. They were the CAN high and the CAN low. When in a recessive state, meaning no message was being sent, the signals operated at 2.5 volts. During the dominant state, when a message was sent, the CAN high went to 5 volts and the CAN low went to 0 volts. This can be better understood by viewing Figure #1.

Realizing a processor was needed to read this signal, more research was done to find an appropriate match. The processor needed to have pins dedicated to the CAN Rx and CAN Tx. The PIC18f258 was decided on by the group. We were hoping this would work but needed a backup option which was the Motorola M68HC12 and Michael will be briefly talking about it.

The PIC18f258 can be programmed using the PicStart Plus Development Programmer and MPLab that is currently within the department. MPLab needed to be upgraded to version 7.22 for the 18 series PIC processors. The 18 series are also programmed differently than the 16 series that we were familiar with.

Before trying to read a CAN message we wanted to get the PIC to accept some code and run what we wanted it to. Flashing a port of the processor seemed like a trivial idea. The pin diagram of the PIC18f258 is similar to that of the PIC16f876, which is a processor used in the embedded systems course. The programming is similar between the two but declaring the pins is extremely different. This was resolved by e-mailing Microchip with our problem.

Microchip is a big supplier of microprocessors. They offer free samples for people who are developing new products. We were able to get many samples throughout the course of the project to assist in our new design. They also have an online customer service page that people can submit tickets on. Programmers and engineers work through the problem and reply back in a timely manner. This was used a few times.

It took the first semester to get the PIC18f258 to accept code that work correctly. It was then that Microchip posted to use an alternate device to use for new designs. It was the PIC18f2580. Since we were not programming the CAN bus yet it made for an easy switch. To get this processor to work there were slight modifications in our code along with changing some configuration bits in the MPLab software.

The PIC18f2580 needs to be configured to accept CAN messages. There are many registers that can only be set in the configuration mode of the processor. This needs to be done in the programming. While doing more research on receiving CAN messages it was discovered a CAN transceiver is needed. The MCP2551 was one that was recommended. This was also something that we could order for free from Microchip.

The MCP2551 receives the CAN high and CAN low signals. It converts the differential signal to a 0 – 5 volt signal. This allows the PIC18f2580 to recognize the messages. The CAN transceiver transmits the messages to the CAN Rx pin of the processor. The processor then transmits back a signal indicating that a message was received.

Setting the baud rate for the CAN was the most difficult task. Three registers used to set this up. The values of these directly correspond to the rate at which you are receiving messages. An include file was used to set the definitions of these registers. It was thought that it would be easier to change the values without going into the program. This led into one of our biggest problems.

The CAN was receiving messages at 500kbps when 250kbps was needed. We attempted to set up a CAN transmit processor to try and fix our problem. We were able transmit messages, using CAN, and receive them so we knew our project was partially working. We could still not fix the baud rate problem and we encountered a few others with the Bobcat service tool and the CANalyzer software. Shawn Vasichek from Bobcat came down to help.

Shawn found that a wire from the service tool was connected wrong. He was also able to set the CANalyzer up to transmit messages at 500kbps to our CAN receive processor. It was then tried to type our baud rate directly into our program instead of having an include file. This was the solution that was needed to get the CAN receive processor to receive one message at 250kbps.

There was something with the configuration of the registers that only allowed one message to be received. The first thought was to re-configure all of the registers before getting a new message. This took way too long and many messages were being missed so we created a new configuration. This configuration only resets the registers need and then proceeds to getting a new message.

After receiving one message it gets time stamped and converted to ASCII code and transmitted to the MMC processor using the Enhanced Universal Synchronous Receive Transmitter (EUSART). The EUSART is used, in asynchronous mode, to allow Matt to have access to the SPI pins to write to the MMC card. The maximum speed the EUSART can transfer data is 115.2kbps.

After transmitting a message the processor is re-configured with the modified initialization and receives a new message. This process continues the entire time the processor has power. Here is a flowchart to better understand the process.

A CAN signal is a 2.5V differential signal. This means it has high and low signal components. When a signal is being transmitted on the CAN high line, the line goes to 5V when active and 2.5V when inactive. When a signal is being transmitted on the CAN low line, the line goes to 0V when active and 2.5V when inactive. Since the PIC cannot understand these signals, a transceiver is needed.

The CAN high and CAN low signals combined into a singal signal.

The output from the MCP2551 High Speed CAN Transceiver. It combines the 2.5V differential signal into a 0V-5V signal the PIC18F2580 can use.

The in-house CAN circuit. Use strictly for debugging purposes only. Note the large amount of LED's on the circuit for debugging errors.

Data Storage

To be able to store 20MB of data, Matt looked into several storage devices. One requirement for being used in a skid steer loader was that it would have to be solid-state-storage (sss). This ruled out any device such as a hard disk drive that might be damaged by the rough nature of skid steers. The table below lists the available devices and pin counts.

Initially, USB seemed to be the answer. Low cost per MB and only four pins to use, D+, D-, VCC, and GND. Using a PIC from Microchip as the microcontroller seemed obvious since there are several PicStart Plus modules in the department and the software is readily available on several PC’s which would cause no extra cost to the department. After searching Microchip.com, Matt discovered that free samples of the PIC18F2550 (which have the USB module) were available. After trying unsuccessfully for several weeks, Matt discovered that the PIC18F2550 was a USB slave device and that a USB master device would be required for this task. Since Microchip did not make a USB master device another storage option would have to be considered. The next device from Table 1 that was considered was the MMC. This uses only seven wires which still provides ease of setup. The MMC has two modes of operation, MMC and SPI. SPI is a very common protocol which is used by many devices. It requires 4 wires, CS, CLK, MISO, and MOSI. The other three wires are two grounds and power. When power is first applied to a MMC, it defaults to MMC mode. To get SPI working correctly, a series of commands need to be sent to the device with the correct responses. Each command is 6 bytes long. The first command is CMD0, which is 0x40, 0x00, 0x00, 0x00, 0x95. The first byte corresponds to the command number, and the last byte corresponds to the pre-calculated checksum. This command tells the MMC to go into idle state and wait for further commands. If this command is successful, a 0x01 should be received. All other received values indicate an error. The next command sent is CMD1, which is 0x41, 0x00, 0x00, 0x00, 0x00, 0xFF. The checksums aren’t necessary anymore but 0xFF is sent to fill in the byte. This command tells the MMC that data will be sent in SPI mode. 0x00 should be received if this command is successful. After this point, the write command can be sent and data storage can begin. A detailed explanation of the algorithm is explained on the following page.

Overview of MMC Algorithm (using a FAT formatted MMC)

1. After power-up, drive CS inactive (logic high) to disable the MMC. Do not have CLK higher than 400 KHz.
2. Initialize the PIC’s SPI module with the following registers set:
   1. SMP = 0
   2. CKE = 0
   3. CKP = 1
   4. SSPM1 = 1
   5. SSPEN = 1
3. Send at least 80 dummy clock cycles. This can be done by running through a “for” loop ten times sending 0xFF to the card each time.
4. Drive CS active (logic low) to enable the MMC and transmit CMD0 (0x40, 0x00, 0x00, 0x00, 0x00, 0x95) with 0xFF padded on each side of the command.
5. Wait for response of 0x01 before continuing.
6. Send CMD1 (0x41, 0x00, 0x00, 0x00, 0x00, 0xFF).
7. Wait for response of 0x00 before continuing.
8. Card is now in SPI mode and BAUD rate can now be increased to ≈ 10 MHz.
9. Get 512 bytes of data.
10. Send the write command (0x58, 0x00, 0x00, 0x00, 0x00, 0xFF) with 0xFF padded on each side of the command. The middle four bytes indicate the sector that you wish to write to multiplied by 512 (i.e. to write to sector four, you would write 0x58, 0x00, 0x00, 0x08 0x00, 0xFF)
11. To start writing data, send 0xFF, 0xFF, 0xFE. When the Flash device sees the 11111111 11111111 11111110, it will know that the 0 is the start bit and that the next 512 incoming bytes will be valid data.
12. Send 0xFF four times to pad the data at the end. The response after the fourth 0xFF should not be 0xFF. This indicates that writing was a success.
13. Go to #9

To find the maximum theoretical sector number of 512MB MMC:

In reality, a FAT formatted card has less than the specified amount so it is best to format the card first to see what the useable space is. Also, using a FAT formatted MMC locks the first four sectors (0, 1, 2, and 3) so starting at sector 4 is required.

MMC Pins and functions

The circuit for writing to a MMC card. The circuit design is very basic using only 4 wires for communication to the flash device. These are the green, yellow, blue and white wires.

Software

Bobcat requested a Windows XP-compatible software program that would work with the Data Logger. The software, named LogReader, should enable the user to get desired information from the large amount of recorded CAN data available on the MMC card. The functionality of the software and the user interface was cemented fairly early on in the design process. The choice of the best development tool with which to develop LogReader was the largest decision in creating the program.

Karl investigated three different development tools: Microsoft Visual Studio .Net, National Instruments LabView, and Runtime Revolution Ltd. Revolution Enterprise. To determine the most effective tool, Karl considered a few different criteria: 1. Approximate time to get the program’s basic functionality up and running 2. Ease and ability to upkeep code in the future 3. Cross-platform compatibility

Even though the original requirement stated Windows XP, the world is certainly multi-platform, so Karl wanted to consider how difficult it would be to port the software to other operating systems (OSes). The ability to upkeep the code is probably the most important feature for Bobcat engineers after the program is initially developed, but the time to get the program’s basic functionality up and running was probably the most important feature for our group since there were many other tasks to accomplish.

Time to get basic functionality up and running would be the least with Revolution Enterprise, because it is specifically designed as a Rapid Application Development (RAD) tool. Karl also has the most experience with the program, so the learning curve would be flat. LabView is tailored for fairly rapid development time, but the learning curve would be bigger than Revolution simply because Karl had done no previous development with the software; it is fairly expensive and was never used in a college class. Visual Studio .Net would have required the most time to develop, as it is intended for fairly large commercial applications.

Ability to maintain the code base is the most strange with Revolution, because it uses Transcript, an English-based scripting language that looks somewhat different than C or Java code. Transcript is very verbose, whereas LabView is very visual and is a fairly well-adopted industry tool and Visual Studio .Net is a traditional C/C# development package. Figure 5.1 contains sample code written in each language:

Revolution Transcript	LabView visual programming	Visual Studio .Net C#	C
on mouseUp put 5 into var1 put 3 into var2 put var1 * var2 into theResult end mouseUp		public static void mouseClick( void ) { int var1 = 5, var2 = 3; int result = var1*var2; }	void mouseClick( void ) { int var1 = 5; int var2 = 3; int result=var1*var2; }

Finally, cross-platform compatibility was the best with Revolution and LabView, because Visual Studio .Net is designed specifically for Windows systems. The .Net framework is intended to be hardware and OS-independent, but Microsoft develops the framework primarily for Windows, so using .Net will lock a developer in to Windows at the present time. LabView and Revolution both run on Windows XP, Mac OS X, and many varieties of Linux. LabView also had tight ties to many commercially-available hardware products on the different OSes; this would speed any future development of the software if it was to interface with a data acquisition board or other externally-developed hardware.

Karl initially decided LabView was the best tool because of its many possibilities for interacting with hardware in the future. After some development time, Karl got basic file input-output working, but the filtering was not very intuitive to develop with LabView’s visual programming.

Revolution was used to develop the final LogReader software. Its time to develop the software was predictably short, and the GUI was very customizable and looked native on each individual operating system. It was developed almost entirely on Mac OS X, only brought over to Windows to clean up some GUI issues.

The filters were to be very flexible, and were inspired from e-mail filtering software. Many different criteria could be applied to the data set, and the results could be grouped by which filter selected the results or all results could be lumped together in one big output file.

Filtering could be done on the timestamp, CAN ID, or data fields. Options were to include numerical value comparisons such as greater than (>), less than (<), and equal to (==). Filters could also match if a certain set of characters were found in the CAN ID or data fields, or if an ID or data field exactly matched a particular value. Figure 5.4 includes a flow-chart outlining how the software algorithm applies the filters to the data.

• PROJECT COMMENTS
  • We did not have appropriate CAN hardware until quite late in the first semester. This could have been avoided only with faster response times from Bobcat. Hopefully future Bobcat groups can get faster response times.
  • Learning a brand new industry protocol would have been greatly simplified if we had someone who had more experience we could have talked with frequently for about a week or two. Picking a design project involving a technology that someone in the department was very familiar with could be a great boon to any senior design project, simply to get an idea of how to go about resolving an issue.
  • Getting the CAN PIC to only record certain CAN IDs would have been great, but we got the CAN working too late in the project to allow this to become reality. Better planning at the beginning to allow for programmability – specifically setting up how the programmability would be done and maybe even implementing it before the CAN was completely working – would have enabled this nice feature.

• FUTURE LOGREADER SOFTWARE IMPROVEMENTS:

The LogReader software works well and can handle any size log file thrown at it, though it can slow to a crawl with fairly big files. A future improvement to the software could be further code optimizations to speed up the software when working with large log files. Another future improvement would be allowing sets of filters to be saved and loaded, so the user can quickly recall a large set of filters without having to tediously re-enter filter parameters.

Other features could have gone into software/hardware combination but were not implemented due to time. With some retooling of the PIC’s code, the LogReader software could program the PIC to allow only specific CAN IDs to be recorded to the MMC. This would streamline the viewing of log files, since the filters could be applied before writing data to the card. This has the potential to drastically shrink the length of the data log files, though it also introduces the possibility of not recording a CAN message that may be integral to the solution of a problem. The Data Logger’s CAN PIC processor could also be reprogrammed to spit out CAN data directly out to the LogReader while it is plugged into a CAN bus, just like the CANcaseXL product does. This would require additional hardware on our final board, though.

• TIPS TO NEW DESIGN STUDENTS
  • Be organized and set reasonable, manageable milestones early on. Set up a schedule from day one that is very lenient, so you have plenty of time to hit your goals but can still reschedule in case accomplishments occur late.
  • Decide on parts as early as possible so you can have plenty on hand, and to give yourself time later in the project
  • Big spikes of work at the end of the semester are unavoidable, but you really can lessen them by accomplish tasks early in the semester. Get to work hard right after summer or Christmas break so when the end of the semester rolls around you are not completely stressed out. Stress can help you work hard and fast, but excessively large amounts can hurt your mental or physical health!

Final Setup

Code

 Due to the nature of our project, all code is proprietary information to Bobcat.
 

Files

Keywords