1 2 3 Previous Next

Ultimate Road Test

78 posts

Element14 and Texas Instruments (TI) are pleased to announce the winner of the Ultimate Road Test competition.

 

It was a difficult choice, given the quality of our competitors and the innovative solutions they put forward using TI SimpleLink Wi-Fi CC3000TI SimpleLink Wi-Fi CC3000 and MSP430-FRAM evaluation module kit.

 

We were intrigued by John Tiernan's "Nice Asgard Project"; the ability to set the perfect atmosphere for watching a film with a minimum of fuss is an excellent application of home automation technologies.

 

IMAG0004.jpg

We also thought very highly of Nick Schulze's "Bread and Butter" project: the idea of a smart fridge which tells you when you're low on supplies has been around for some time, however a smart refrigerator shelf seems a much better and more inexpensive way forward.  

 

smartshelf.jpg

However, in the end there could only be one winner: thanks not only to his innovative yet quirky project, but also the breadth and depth of information he has provided, as well as his boundless enthusiasm, the winner is Monte Chan and project "Code Name.”

monte-led.jpghttp://www.element14.com/community/servlet/JiveServlet/downloadImage/102-46372-16-86563/289-242/Code3.jpg

Monte will be receiving a DLP LightCrafter ProjectorDLP LightCrafter Projector from TI; we hope that this prize will continue to inspire him in his engineering endeavours.

 

A sincere thanks to all those who took part; we look forward to the next Ultimate Road Test!

16th July

A Great Progress Day

I have been continuing SIT testing and today I have my project producing sound whilst responding to Wi-Fi datagrams.

Although this does not sound like much to most you will need to consider what is happening.

 

The Basic WiFi Demonstration uses a SPI port with interrupts to service the CC3000.

As not to interfere with this activity, I have connected the 256K FRAM buffer, DAC and LCD to the other SPI port.

 

The Basic Wi-Fi Demonstration also uses a Timer A for handling its events.

As not to interfere with this activity, I have used Timer B0 to generate a 8KHz Interrupt for sound and mouth articulation processing.

 

Sound is produced using a sample rate of 8kHz.

When the Interrupt Service Routine (ISR) for Timer B0 is invoked,

     It firstly checks to see if sound is to be produced by checking the sound enable flag

     If this flag is set then the following occurs

          The FRAM Buffer is taken out of its hold state

          The FRAM Buffer is accessed to obtain the next DAC value

          The FRAM Buffer is accessed to obtain the next mouth value

          The DAC is loaded with the new value

          The mouth is loaded with its new value

          The FRAM Buffer is put back into its hold state

     The Timer is reloaded.

 

Using the hold state enables the use of quicker FRAM buffer accesses by utilising its auto increment address feature.

 

For SIT testing, this ISR is even more complicated because I have given it the ability to produce a continuous sound by relooping through the FRAM buffer.

I may leave this feature in because I am finding it useful. I am currently generating sine waves of a nominated frequency.

This feature would be useful for creating Alarm sounds.

July 15th

Some Odd Quirks

I've been busy performing System Integration Testing and Unit Testing and have encountered a few hurdles on the way.

 

1. CCSv5/MSP430 C Compiler and handling of long variables.

I've always used long variables with the premise that they have a minimum size of 32 bits.

After encountering odd behaviour and through debugging I have found that with CCSv5 and MSP430FR5739 the compiler wants to use a 16 bit register thus truncating its value.

A work around is available. I forced the compiler to use RAM with the volatile keyword.

After using it I got the expected behaviour.

 

Note: The MSP430 Optimizing C/C++ Compiler v 4.1 manual says that longs are 32 bit values.

The E2E Community forum confirms my finding.

 

I also noticed that the stepping function through some long arithmentic was not consistent. some lines were skipped but at the end of the calculations the value of the long variable was correct.

 

 

2. Basic WiFi Demo Buffer size strikes again.

From odd behaviour from my project I had to perform some debugging to find that there appears to be a 256 byte limit for the receive buffer size.

The work around is to limit the receive buffer size to 256.

July 14th

More on the Solution to the Odd problem

The solution is working very well and hasn't failed yet.

My polled SPI drivers do not use the UCBUSY status bit at all.

All I do is poll the UCTXIFG flag on UCA1IFG prior a transmit and poll the UCRXIFG (also on UCA1IFG) flag after it.

When the UXRXIFG flag is set, the UCA1RXBUF is read irrespective of whether the value is used later or not.

 

Here's an example.

 

unsigned char sendchar1SPI(unsigned char d, unsigned char cntl_nCS) {
    unsigned char b;

 

    // Assert Chip Select if it was requested
    if (cntl_nCS != 0) {
        UCA1CTLW0 |= UCSWRST;              // Ensure clean start
        UCA1CTLW0 &= ~UCSWRST;

        nCS_POUT &= ~DEVICE_nCS;
    }

 

    // Perform SPI transaction

    while((UCA1IFG & UCTXIFG) == 0);        // Ensure transmit buffer ready

    UCA1TXBUF = d;                          // Transmit character
    while((UCA1IFG & UCRXIFG) == 0);        // Ensure transmission has completed
    b = UCA1RXBUF;

 

    // Negate Chip Select if it was requested
    if (cntl_nCS != 0)
        nCS_POUT |= DEVICE_nCS;

 

    return b;
}

 

My MSO has confirmed this produces textbook timing.

July 13th

An Odd Solution to the Odd problem

The odd problem had to do with driving a particular SPI device.

I had a look at the E2E website and there's a lot of comments about it.

I found my own alternate that seems to work for me.

 

My issue is the UCBUSY bit for some reason intermittently remains set indefinitely even after all bits of the transmission have been set.

Only a reset seems to clear it.  I could not find anything to explain the reason why the UCBUSY bit remained high.

 

My alternative is to use the UCRXIFG interrupt bit to sense when a transmission is complete.

This works because as a byte is being transmitted a byte is simultaneously being received.

 

It seems to work a treat.

Let's see how it works.

July 12th

Having the Odd problem or two?

I've been working on a odd problem.

A software driver works perfectly well in unit test but when put into system integration test it misbehaves.

Even odder is the fact that the error condition with the software driver does not occur when the part is removed in system integration test.

Quite peculiar.

July 7th

Feeling Isolated

web ISO pcb.jpg

The ISO7221ADs arrived and I have mounted one on a new PCB that I just designed and milled specifically for them.

These are good insurance policy against ruining expensive control modules, the CC3000 and rest of the project hardware.

The datasheet specifies that its decoupling capacitors must be mounted about 2mm from the power pins.

July 7th

SPI FRAM Unit Test

This unit test was run some while ago. The signals from top to bottom are;

     3    nCS

     1    CLK

     B1      MSO interpreted SPI MOSI

     B1      MSO interpreted SPI MISO

     2    SIMO from MSP430FR5739

     4    SOMI to MSP430FR5739

web SPIFRAM memread.png

Address 0x00000000 was written with a 0xAA value and then read back again

The read sequence is;

OP Code(0x03 = READ), address byte_0, address byte_1, address_byte2

(with address_byte0 being the most significant byte)

 

this is followed by the FRAM outputting the value from that memory address.

 

The diagram confirms a textbook response.

July 5th

Text to Speech Conversion Details

Attached are some test samples.

The Text to Speech conversion is currently done using a PC to create the an 8 bit 8kHz PCM required by the DAC.

The sample data is extracted from the .WAV file and will be loaded into the FRAM buffer for play back.

July 5th

DAC Unit Test Details

The SPI DAC Unit test was run somewhile ago.

I re-ran it today to include the following picture of it performing a roughish saw wave.

web SPIDAC Unit Test.png

July 5th

Working in isolation    

As not to blow up my Fraunchpad, C2000 Multi-DC/DC Colour LED Module, Three Phase BDLC Motor Driver or other independent module, I have ordered some Texas Instruments ISO7221 Dual Digital Isolators.

These are to similar to relays but are used but for low power and low voltage digital signals at much faster frequencies.

This allows my project's serial channels to be electrically isolated for protection. The last thing I want is some 50 odd volts from the BDLC motor driver or some introduced voltage potential difference to flow through where it shouldn't.

 

The ISO7221 is available in four different speed variations ranging from 1Mbps through to 150Mbps.

For this application I am using the 1Mbps A version.  The deployment of ISO7221s is not dissimilar to that of placing buffers in your circuit except that you are deploying are also providing galvanic isolation.

Power doesn't come from vapour so the ISO7221 requires two sets of power. One for each side. Like buffers, there are specified voltage thresholds to be met for digital signalling.

 

web isolation.png

July 3rd

Unit Testing of Serial Mux Board

web Unit Test Ser Mux.jpg

I have just completed testing of the Serial Mux board in isolation.

The Serial Mux board was disconnected from the main project and tested in isolation with the alternate Fraunchpad.

A software driver was written to pump out data from the TX pin with P1.0 and P1.1 configured as outputs driving the Port Select Address pins on the Serial Mux Board.

All four combinations of the Port Select Pins were selected with the output from the TX pin tested on both RX and TX pins.

This works because the CD4052 is an analog Multiplexer/Demultiplexer (i.e. In reality a bidirectional analog switch).

 

Testing has proved successful. No modifications to the PCB required.

The PCB was annotated to make future connections to it easy.

COMPACT

Project "code name" Part 040

Posted by COMPACT Jun 30, 2012
July 1st (Still June 30th GMT)

Where to from Now?

I am very proud of  The Project "code name" device.

The aim of this project was perform The Ultimate Road Test on the CC3000 and I hope I have been successful in acheving this goal and be invited for others in the future.

Many thanks to Texas Instruments and Element14 for giving me the opportunity to participate and I hope I have not disappointed.

They have so kindly provided the participants with the hardware, software and some goddies to remember the occasion.

I hope I have clearly demonstrated to the sponsors and the Element14 Community what can be accomplished with a bit of imagination and engineering knowledge.

 

My project's hardware design is complete with all major elements attached and basic functionality working.

At this point I must be really careful with the testing because I do not want my effort to "end in tears" by rushing through it, blowing it up and turning the whole lot into a pile of scrap!!

Once this testing has been competed I shall integrate the TMP006AIYZFTTMP006AIYZFT Thermopile sensor, complete the software and add additional CC3000 controlled devices to my Home Automation Network.

 

If requested, I can produce CC3000 walkthough video where I'll take a toy or domestic appliance and WiFi enable it.

 

If you have any questions about the project send them through I am happy to answer them.

 

Cheers

 

Very Compact

COMPACT

Project "code name" Part 039

Posted by COMPACT Jun 30, 2012
June 30th

Twitter Dee Twitter Dum

The Twitter interface is not complete but here is a description of the plans for it.

 

The MSP430FR5739 has only 16K RAM for code space and data and thus does not have enough space to include all of the necessary code to connect and communicate with Twitter.

I have previously mentioned SuperTweet as a means to reduce this requirement but for this project there are other aspects that require attention.

This includes converting text to speech and generating the necessay mouth movements of the toy.

Like the TI Home Automation Demonstration, for the moment I will require a PC to provide additional services.

I think I'm pretty right saying that the PC is used to convert the raw Fraunchpad Thermistor ADC reading to a Standard Temperature Scale Reading as this removes the need for using a math library in the Fraunchpad thus conserving value memory space.

 

Using a PC,when a Twitter message is received it will be parsed and sorted into the following categories;

     Home Automation Command

or

     Incoming Message

(Alternatively - this could be accomplished by two Twitter accounts - One for commands and one for messages.)

 

For commands, these are processed and the selected action is performed.

The command could be to;

     Perform an immediate action

     Read a Sensor Reading

     Activate a defined sequence

     Schedule an action or sequence

     Enable a function

 

For incoming messages, these are processed as follows;

     TTS (Text to Speech) is performed to create an 8 bit, 8kHZ .WAV and accompanying .LSF (lipsync file).

     The incoming message is sent to the CC3000.

     The .WAV file is sent to the CC3000.

     The .LSF file is sent to the CC3000.

     The CC3000 is instructed to annunciate the received message;

          The LCD Display shows the message.

          The Deer lifts its head.

          The Truck suspension is activated.

          The HeadLight blink sequence is activated.

          The Audio Amplifier is enabled.

          The Deer on the truck starts speaking.

     Once the message has completed, the Toy deactivates;

          The Neck is lowered.

          The Truck suspension is deactivated.

          The Head Lights are turned off.

          The Audio Amplifier is turned off.

         

In addition to remotely launched actions listed above there is also alerting.

Like the TI CC3000 Wi-Fi Home Automation Demonstration, Twitter messages can be sent out to nominated recipients from the CC3000 if a defined alerting situation arises from its input sensor readings.

 

The requirement for the PC to process the TTS and Lipsync file can be removed at a later if the CC3000 has an attached module with the capability to perform these tasks thus making it self contained.

 

Networking is the way to go!

Slave or Peer CC3000s can be joined together forming a larger sensor and activation network making for a formidable yet quirky Home Automation System.

COMPACT

Project "code name" Part 038w

Posted by COMPACT Jun 30, 2012
June 30th

Preparations for complete integration

Here is a picture of all modules connected in preparation for testing.

There's plenty here to control a whole building.

Who'd have thought to have so much connected to an MSP430 and have it all wirelessly controlled from the Internet?

.... (Now that's some pudding!)

 

Just image if you have several of them..... I can rule the world!

 

web the whole thing.jpg

 

 

Below is a close up of the DRV8312EVM board and its connections to the Serial Multiplexer/Demultiplexer.

 

There are no modifications required. The connect tap points for its serial control port are;

     J12 for TX and RX

     JTAG port GND Pin

Easy peasy!

 

Like the Multi-DC/DC Colour LED Kit, the DRV8312-C2-Kit has its own power supply but this time to provide power to a three phase motor rather than several LED arrays

.

web DRV8312.jpg