Showing posts with label BoosterPack. Show all posts
Showing posts with label BoosterPack. Show all posts

Monday, February 12, 2018

TI Motor Drive Bundle (LAUNCHXL-F28027, BOOSTXL-DRV8301) & MotorWare - How Easy is it to Get Your Motor Spinning

Introduction

I would like to thank Element14 and Texas Instruments for selecting me for this roadtest. I applied to review the TI Motor Drive Bundle because of a previous experience with the BOOSTXL-DRV8301 boosterpack and a not so compatible launchpad. I have previously reviewed this boosterpack with less than favourable results. I was therefore hoping that after 3 years of availability, the documentation and support would have improved.

Unboxing & First impressions

Element14 has worked with TI to deliver these boards as complete evaluation kit. The packaging has therefore been altered to reflect this. The three components, each individually packaged, come shipped in a single kit box. The launchpad is packaged in the standard TI box. The DRV8301 on the other hand is shipped in what has been labeled a new product box. If this was a new product, as it may have been during my initial review, this would be acceptable. Its now substanily later in the products life and this generic, oversized box reflects an apathy or disinterest towards this product. The provided motor (DN4240S24-026-TI) is shipped wrapped in bubble wrap. As a perk, a pen with a screwdriver in the back and a level and ruler on the side has been included.
Kit contents as assembled by TI in partnership with Furnell/Newark

The getting started guide for the LAUNCHXL-F28027 has a simple demo to let you know the board is working. The demo interestingly contains two parts. The first demo is done with no PC connected. Once powered up a reference temperature is take. If the temperature changes, the change is reflected on the LEDs to indicate the difference. A new reference value can be set by pressing the S3 switch.
Demo: LEDs displaying change in temperature from initial setpoint

An extension of the first demo is accessed by connecting the LAUNCHXL-F28027 to a PC. After connecting the board, configuring the terminal (115200, 8, No parity, 1 stop) and pressing reset, the board display a text version of the TI symbol.
Terminal after resetting the F28027F

The display prompts you to press the S3 button. This again begins the temperature demo. Instead of only having the LEDs to inform you of the change, the measured value is updated at the bottom of the display.

The DRV8301 doesn't have a quickstart program to run even though there is a quick start guide. Any demo software for this boosterpack is found in the motorware software package and will be look at later in the review.

Getting Started

The various getting started guides all demonstrate how to configure the onboard switches and jumpers before starting. Once these are set there is little help to get you any further.
Proceeding to look through Motorware which had previously installed didn’t help. Knowing that this is an InstaSPIN-FOC board I looked under this section first. Unfortunately there are only projects listed there with no documentation. Attempting to use the Universal GUI to get started revealed the documentation for this software was lacking.

MotorWare labs available for the 8301 Rev B,, notice no documentation listed

Fortunately I was directed by a fellow member of Element14 (najath) to look in the Motorware software for further information. More specifically najath specified to look under the resources section (Resources > Launchpads > F28027F Launchpad). The “Kit Readme First” provides some information but nothing that has not already been provided from the various other getting started guides. The “GUI Quick Start Guide” is also the same as listed under InstaSPIN-FOC. Thankfully najath provided some further instructions. Under “Training:User’s Guides, Labs, Tutorials” is a PDF called “InstaSPIN Projects and Labs User's Guide”. This guide finally gets a user moving forward with this kit.

The resources section has a bit more information but, nothing particularly useful under the F28027F section

After spending a considerable amount of time to get to the kit working it became abundantly clear that TI had not made much, if any progress with this kit since my last review. The main difference between the current and previous review is the help provided from the Element14 community, something I don’t believe I got from TI’s e2e forum on previous attempts.

Documentation

The documentation for this kit has already been mentioned in passing. There is however a decent amount more to be said about this. The quick start guides, of which there seem to be an abundance, don’t point a user in any meaningful direction. The getting started guide for the launchpad shows the user how to configure the board and run the preprogrammed demos. It then points a user to CCS or ControlSUITE for anything further the user may want to do. This may be pretty standard for a getting started guide but, in this case the instructions don't lead to anything concrete to help a user move forward.

Sadly the getting started guide for the DRV8301 is worse then this. After explaining how to setup the hardware, and not really explaining how to connect the motor we arrive at step VI. If anything has been intuitive or well explained until now TI has made sure to rectify that. This last step simply states “Enable your control algorithm and spin that motor”. If this is unclear then TI suggest using MotorWare to get started.

Step 4 listed in the 8301 getting started guide, “Enable your control algorithm and spin that motor”

As has already been outline in the getting started section, this is more complicated than it would appear. There is no clear starting point once MotorWare is opened up. It should be mentioned at the END of the instructions for each project in MotorWare there is one line “Follow the InstaSPIN Projects and User’s Guide to Get Started”.

Atr the END of each project TI lists where to find more information about getting the lab working

This concept of doing things out of order and in a non intuitive manor seems to be common with this kit. The Quick Start Guide for the Universal GUI also lists all the steps needed to run the software including clicking on run. Only after completing the lab, TI explains how to setup the hardware that the software runs on. Just before setting up the hardware but, after the completion of the lab, is the explanation of the GUI’s interface.

Other issues include incorrect referencing/labeling of tables in the lab guide. Steps that are not relevant to some launchpads, including the one included with this kit, are not commented as such. Missing steps, such as those needed to get the Universal GUI working. The steps for the GUI were eventually stumbled upon by reading the readme file in the InstaSPIN_F2802xFUNIVERSAL folder. The GUI has also been changed since the guide for it was last updated in 2015. There have been some components added and others removed. This leaves a user unclear what the functionality of these components are.

Overall TI has really dropped the ball with regards to its documentation for this product. The time between this product first being introduced and now has not been used to streamline the process to get a new user from demo to product. Nore has it been used to increase ease of use. I would be beneficial for TI and it’s customers if these documents where revamped. It would also be helpful if there was one getting started guide with a logical progression to get this kit running with minimum hiccups along the way.

Software

Once the documentation has been worked out and, the single useful starting point found, there is a lot of software to work through. Because of the complexities of the Piccolo along with the those of controlling a motor TI has provided a HAL layer. This allows a user to focus on getting the system working as needed and not worry about setting up registers. Another reason not made clear at first, is the need to hide the code running in the FOC. As this is proprietary and TI not wanting it shared, this HAL also provides access without giving away anything. In order to help the user understand each of the functions are 20+ labs each with multiple parts. While some of these labs are not relevant to the LAUNCHXL-F28027 there are still a large number of demos helping someone working with this kit to understand how to get their project working.

Each lab is provided with complete code that compiles out of the box. Sadly not all the code is well explained and there is a decent amount of following functions to get to the root of their intent. This added effort adds time and complexity to getting through each lab. Along with a unclear explanation of the software in each lab is an equally brief explanation in the lab manual. It is definitely possible to work out the ambiguities but this again adds time. One major issue in this regard is the lack of mentioning when a specific part of the software is not relevant to a microcontroller. Some of the labs require code changes to be made in order to get a better understanding of what the software is doing. The sections in the lab manual are not labeled as not being relevant to different controllers. The only way to infer this is by looking at the #ifdef statements at the top of each section of code.

Another issue with the software and its associated documentation is the assumption of specific knowledge. There are terms and abbreviations used that are not explained or done so very briefly. This would be acceptable if there was some reference information provided to help a new user to learn more, but there are no footnotes or references.

Regarding this specific kit, each project uses a header file to pull in parameters that the user can set for their motor. TI has kindly provided parameters for 16 different motors. This allows for a user to easily switch over to a different motor without needing to figure out the parameters of that motor. TI however forgot or decided to not include the parameters for the motor (DN4240S24-026-TI) that is shipped with this kit. Adding to this issue is the lack of availability of any documentation for this motor. Only after contacting the manufacturer of the motor was I able to get the documentation for it. This one page document still did not provide all the needed information. There is however a page, that was pointed out by another element14 member (MARK2011), that doesn't seem to be anyway linked to the kit or the product identifier that does have the full specs.

DN4240S24-026-TI datasheet as received from the manufacturer

Hardware

The hardware provided in this kit has a few interesting factors. The first and most obvious is the ill fitting nature between the LAUNCHXL-F28027F and the BOOSTXL-DRV8301. The switch S4’s form factor prevents the boosterpack from seating properly on the launchpad.

The S3 switch on the F28027 launchpad can interfere with the DRV8301s ability to be correctly seated

A workaround for this is to provide an extra set of headers to increase the clearance between the bottom of the boosterpack and the switch. The placement of this switch as well as S1 means that any change to these switches requires that the boosterpacks be removed. This again is solved by adding the extension

Headers added to the F28027 launchpad allow the DRV8301 to clear the S3 switch

Another interesting issue noticed is the seemingly incompatibility between the F28027F and the F28027. The previous review I did was supposed to contain an F28027F but instead I received a F28027. Since TI specifies these are pin compatible and the schematics for the LAUNCHXL-F28027/F don’t mention any alterations depending on the provided chips the F28027 was swapped for a F28027F. Unfortunately this did not resolve any issues and the board does not perform like one containing a F28027F.

On the positive side, TI has positioned the BOOSTXL-DRV8301 on top of the LAUNCHXL-F28027F in such a way as to keep S2 and S3 (the two user push buttons) accessible during operation. This allows for those buttons be incorporated into a design without concern for accessibility.

The two user switches have been well placed allowing them to be accessed even when a boosterpack is mounted

SUPPORT

TI included with this kit 6 hours of free online help with your own “personal trainer”. This is probably the one thing TI has done well to move this product forward. The kit includes a card with a TI employees name and email address. Contacting the employee reveals he is someone well acquainted with the software for this kit. I was also informed that should more than the advertised 6 hours be needed that would not be an issue. The help includes anything from just answering a few short questions to getting a walk through on the software. The idea is that after the personal help you should be well on your way with your project. In the few interactions I had through this service I found the employee to be both helpful and courteous.

TI’s e2e forum is still available for this product so if immediate help is needed (the personal trainer is located in Germany) you can try find answers there. The one big difference between the personal trainer and e2e is accountability. By directing your question to one person instead of to a broad forum is there is one person responsible. This leads to both better and more timely responses.

Moving forward

Having spent a decent amount of time getting to know this kit I am looking forward to using it further both as a learning tool as well as in future projects. Something that I have found this kit to be useful for other than motor control is it sability to teach control theory. Because there are so many variables in controlling a motor and both the LAUNCHXL-F28027F and the BOOSTXL-DRV8301 allow for these variables to be controlled this is a great platform for learning applying these control strategies.

I would also like to complete all the labs associated with this kit. As previously mentioned working through each lab and following each function call down to its base call to get a better understanding takes time. I have therefore been unable to complete all 19 labs for the BOOSTXL-DRV8301. Once this has been completed I would like to try implement this kit in a boat project I have been looking at. This would be used control the propulsion propeller allowing for such things as cavitation mitigation to be implemented

Conclusion

Overall this is a quilty kit provided from TI in partnership with Element14. The software and HAL layers are well implemented. There are sufficient demonstrations to allow a user to learn how to use the kit for any application they may have in mind.

Sadly these great qualities are overshadowed by the badly written getting started guide and the abundance of them. Had TI selected to have one getting started guide for the BOOSTXL-DRV8301 that clearly outlined the steps to get the kit working with the demo software this kit would be a lot more useful. Along with this had TI put more effort into the lab manual to explain what the various functions are doing as well as what functions work with what kit that would have helped as well.

I am therefore looking forward to working more with this kit to learn about motor control as well as control theory in general. I am also hoping to implement more motors into my projects now that I have become acquainted with this product and its use cases. For others wanting to learn about motor control and have the time and energy to go through the many pages of documentation and lengthy lines of code, this kit is definitely useful and has a lot to offer.

Original post on Element14 can be found here

Wednesday, September 24, 2014

Sending Atmospheric Data from the MSP430 and CC3100 Wi-Fi BoosterPack to Plot.ly


Figure 1. Terminal screen displaying live data being transmitted and demo Plot.ly graph

For a while now I have been thinking about the ability to remotely monitor what is going on environmentally in a location. I have thought about this with regards to the summer, with a cottage more than an hour away it would be nice to know what the weather pattern is for the cottages location (not the general city or county) to decide if it is worth the long drive. I have also thought about this with regards to parts of my house, such as the attic, basement etc, to help determine how well the insulation is working or what is going on in parts of the house where people may not often frequent. Lastly it has come up in many conversations with storekeepers who want to know how their fridges are performing and to know when there may be an issue. With all these usage cases I decided I should come up with a solution.

When TI came out with their CC3000 I thought I would give that a try. I spent a few weeks working with this BoosterPack in conjunction with a Stellaris (Tiva C) and MSP430G2553  launchpad but had a good few issues that just didn't seem easily resolvable as well as some limitations that hinder the usability of the system, besides by then TI had come out with the CC3100 that was supposed to resolve a lot of issues as well as be some what easier to use.
Figure 2. CC3100 layout and pin assignment

At the same time I was introduced to Plot.ly, an online graphing tool that allows for real time plotting of almost any form of data. After looking over how Plot.ly works I decided these two tools together would make a good start to resolving my real time remote data logging problem.

As I have a decent background with TI devices the use of TI products was a natural and convenient choice.The MSP430F5529LP was chosen as the brains behind the system and as previously stated the CC3100  was chosen for the Wi-Fi connection. The MSP430F5529LP was chosen do to the wide availability of example code and wide usage of this launchpad with the CC3100.
MSP-EXP430F5529LP_QSG_PinOut.png
Figure 3. MSP430F5529 pin assignment for use with BoosterPacks

The Wi-Fi connection is a CC3100 Boosterpack that contains an integrated TCP stack and is interacted via SPI. One of the important features about this BoosterPack is its conformity to the BYOB (build your own board) standards.

Figure 4. Build Your Own Board pin assignment layout

This means that all the pin connections are in predetermined locations allowing for ease of use with other BoosterPacks. The sensor chosen is a MPL3115A pressure sensor from Freescale and was integrated using the Xtrinsic sensor board from Element14 and Freescale. Lastly as this needs to be able to work in a remote location I decided to add a local power source, for this the Fuel Tank BoosterPack from Element14 was chosen. This choice however does present its own issue. The Fuel Tank BoosterPack does not conform to the BYOB standard. With some connections in contention this board was connected via jumper leads and for now only provides power, the power monitoring ability of the BoosterPack has not been implemented but hopefully will be in a later iteration of this project.




Figure 5. Fuel Tank BoosterPack pin assignment (non-conforming)


The project is based on the TCP_Socket demo for the CC3100. This demo has the basics needed to connect to an access point (AP), open a socket and send data, this provides a very substantial start for the project. This code was modified one step at a time. The first step was to allow for data of my choosing to be transmitted. This was tested and verified using a piece of software from HW-Group called Hercules. This software allows you to have a server running on your PC and to easily receive and see incoming data. One this was done the code needed to be further modified to allow for one connection to be made and multiple packets of data to be transmitted. This was done by splitting the BSDclient function into two distinct functions. The first function would take care of creating a socket and connecting to it. The second function packetTx would then take care of transmitting the desired data. Once this was done (with some difficulty, see forum posts for details), it was time to start transmitting data to Plot.ly.

The website for Plot.ly origanly did not provide a lot information if you were not using one of there standard platforms (Arduino, Matlab, etc) or one of there chosen languages (Python, R, Arduino), I therefore had to take the Arduino code (the easiest to understand) and parse it so it could be used in the format needed by the CC3100. From this code (Plotly’s Arduino code) I was able to create a graph using the REST API commands. These commands in their most basic form look like this:

POST /clientresp HTTP/1.1
Host: 107.21.214.199
User-Agent: MSP430F5529/0.5.1
Content-Length: 243
where the IP address “107.21.214.199” is the address of Plot.ly. The content length is the length of the following string in bytes that actually creates the graph (Note each line is terminated with a carriage return as well as a new line (“\r\n”)):

version=2.2&origin=plot&platform=Stellaris&un=Kas&key=ABCDEFGHI&args=[{"y": [], "x": [], "type": "scatter", "stream": {"token": "1234567890", "maxpoints": 500}}]&kwargs={"fileopt": "overwrite", "filename": "test plot", "world_readable": true}

I will explain this string briefly. Platform is the platform or language being used, from what I can tell changing this has no effect on how the graph behaves. “un” is the username, mine is Kas. “key” is your unique identifier key that allows access to your account. “args” is used to set up the individual traces, in this case I have only one trace so there is only one set of args. if you wanted more than one trace you would use something like this:

version=2.2&origin=plot&platform=MSP430F5529&un=Kas&key=ABCDEFGHI

&args=[{"y": [],"x": [],"name": "Temperature","type": "scatter", "stream": {"token": "1234567890", "maxpoints": 500},"yaxis":"y1"}, {"y": [],"x": [],"name": "Pressure","type": "scatter", "stream": {"token": "1a2b3c4d5e", "maxpoints": 500}, "yaxis": "y2"}]

&kwargs={"filename": "Temperature and Pressure", "fileopt": "overwrite", "style": {"type": "scatter"}, "layout": {"title": "Temperature and Pressure vs. Time", "xaxis": {"title": "Time (s)"}, "yaxis": {"title": "Temperature (Celsius)"}, "yaxis2": {"title": "Pressure"}}, "world_readable": true}




for a full listing of commands you can look at this documentation. “kwargs” is the settings for the overall graph such as the title, public/private access as well as others. At this point I had a graph created and was able to see it in my workspace on the Plot.ly website. I now needed to stream data, using the Arduino code for this however did not appear to help very much. I will again show the commands to open a stream and stream data and then explain them.

POST / HTTP/1.1
Host: stream.plot.ly
User-Agent: Python
Transfer-Encoding: chunked
Connection: keep-alive
plotly-streamtoken: 1234567890

In this code the main command that you need to edit is “plotly-streamtoken”. This line is used to specify the specific trace that this data should be posted to, it is the same as the token in the args passed to create the graph. Note each line is terminated with a carriage return as well as a new line (“\r\n”). Once the stream is open data can be sent to tos graph and trace specified this is done by the following line:

3134
{"x":1,"y":5}
3134
{"x":2,"y":5}

This is where it gets confusing, the 3135 appears to be meaningless but is is infact hex for 14. There are 14 bytes transmitted here including a new line. The “X” value here can be seen to be 1, 2 and the “Y” value is 5. The order of the “X” and ”Y” does not appear to matter. Data must be transmitted once per minute or Plot.ly closes the stream, you can choose to reopen the stream (Plot.ly would prefer you don’t consttly open and close sockets) or preferably send a heartbeat (“\r\n”) if it will be longer then a minute before your next data transmission. Now that we can open a connection with Plot.ly using the CC3100, stream data to plot in reat time its time to get the data from the desired sensor.

I chose to use the MPL3115A as it is a relatively simple sensor to use and I had one laying around. The MPL3115A uses I2C to communicate and once set up to take a reading every second there is not much to do other than poll for data. This will eventually be changed to an interrupt based system which would ideally allow for the MSP430F5529LP to sleep for approximately 95% of the time (back of the envelope calculation) increasing the units life by orders of magnitude.

Figure 6. Xtrinsic Sensor Board and pin assignment configuration

This code was initially developed separately from the TCP_Socket code and was slowly merged allowing for issues to be easily resolved. The main issue encountered was the “Error: "Program will not fit into" after adding interrupt handler” this was eventually resolved by simply removing the interrupt handler for “USCI_B1_ISR” in board.c. Once the data is read in it needs to be changed to a string and assembeled as message that Plot.ly can interpret. This is all done in the “plotlyPlotString” function, two integers are passed in as well as a pointer to a char array. The integers are converted to chars and inserted into the string ready to be sent to Plot.ly (this function in its entierty can be confusing so if anyone would like more clarification I would be happy to further exlpain it below). One integrated and tested the system performed pretty well.

P1010197.JPGP1010203.JPGFigure 7. MSP430F5529 with CC3100 BoosterPack mounted and connected to the Xtrinsic Sensor Board (P4.1, P4.2) and Fuel Tank BoosterPack (3.3V, 5V, GND)

Next Steps
Moving forward there are a number of improvements that need to be made. As of now the system disconnects from Plot.ly after ~530 data points (this does not happen with the Hercules server), this issue will need to be resolved and is currently under further investigation. There is also the issue of inadvertent disconnections from the AP that for a robust system will need to be taken care of, this will involve checking that the connection has not been closed and if it has, to reconnect. There is also the need to check that the socket has not been closed and again if it has to reopen it before continuing to send data. Lastly for complete robutness the system should be able to check for error messages from Plot.ly and react to them in a meanigfull manour.

Besides for these steps the inclusion of pressure data on a separate “Y” axis would allow for a better use of the chosen sensor. Also the full implementation of the Fuel Tank BoosterPack with power monitoring and plotting time remaining, battery voltage and possibly other metrics would be a useful addition.

I will update this post as the project evolves. If you have any questions or comments I would be happy to address them in the comments below.

For those who would like to try this and may run into the same issues I have, I have included a link to the issues I had and how TI helped me resolve each of them

CC3100




Original post on Element14 can be found here