ESI Project: Laser coolant monitor

[Fred 453]

Not done much yet. So hard finding the time these days. I soldered on some headers and also added the components for the two unpopulated LEDs. I noticed that JP12 (connects ESIVCC to DVCC) was unpopulated so I added a jumper there as I suspect it might be needed for the ESI.

 

I would have added a user button to SW2 but I don't have a button with the appropriate footprint. I might have to steal one from another launchpad as these seem to be "US stock" and hard to get from UK suppliers without a stupid fee (i.e.

[bluehash 1,581]

Not done much yet. So hard finding the time these days. I soldered on some headers and also added the components for the two unpopulated LEDs. I noticed that JP12 (connects ESIVCC to DVCC) was unpopulated so I added a jumper there as I suspect it might be needed for the ESI.

 

I would have added a user button to SW2 but I don't have a button with the appropriate footprint. I might have to steal one from another launchpad as these seem to be "US stock" and hard to get from UK suppliers without a stupid fee (i.e.

[Fred 453]

@@bluehash - Thanks for the offer, but don't worry. I can probably find something equivalent if I look hard enough. It just seems so daft for such a small cheap basic component!

[abecedarian 330]

ebay maybe?

[Fred 453]

How can it not cost more than that for just the postage?

[abecedarian 330]

Don't know. But, looking at the cost of the Farnell order, you could have well over one hundred switches.

[Fred 453]

Well, my MSP-FET arrived and I've finally found a little bit of time to play with this. (Lots of other crap going on I won't bore you with.)

 

I decided that the easiest ESI stuff to toy with would be the example quadrature encoder that comes with MSP430Ware. You'll find it at examples\devices\fr5xx\MSP430FR58x8x_MSP430FR6x7x_MSP430FR6x8x_Code_Examples\C\msp430fr69xx_esif_01.c. This example seems simpler than the TI design examples here and it also processes digital signals (from an optical encoder) which are more closely aligned to the hall sensor I'm using.

 

One thing I did find is that this sample requires the LFXTAL to be fitted. Reading up on this it looked like the 12.5pF load capacitors were needed. From the user guide:

3.2.2 LFXT Oscillator

The LFXT oscillator supports ultra-low-current consumption using a 32768-Hz watch crystal. A watch crystal connects to LFXIN and LFXOUT and requires external capacitors on both terminals.

However, it seemed odd the TI would supply a crystal but not matched capacitors. I tried fitting without and it seemed to work just fine.

 

A quick teardown of the flow sensor I have shows it's based on the Winson WSH130. This isn't just a bare hall effect sensor but also has a comparator with hysteresis and provides a simple open collector digital output. There's just about room to add another sensor inside the case so it would do quadrature sensing, but it actually has two magnets on the rotating disc. This would mean I'd have to have only 45 degrees between the sensors rather than 90. Not really practical.

[Fred 453]

Another thing I noticed is that when using the MSP-FET instead of my MSP-FET430UIF I immediately got an EnergyTrace window showing up. Without even digging into the detail it already looks really useful.   

 

Don't stop there though! All it takes is enabling the EnergyTrace++ option in CCS and you get this: 

[chicken 630]

Oooh, I love stats    Didn't notice that when I played with the MSP-FET. I fear my ESI project might get sidetracked for a while..

[Fred 453]

@@chicken Don't click on the graph tabs then. They're even cooler.

[Fred 453]

This is fairly hard going. I assume from the fact that there's not been much from the other ESI projects, that everyone else is taking time to get to grips with this. I think I'll do a bit of blogging as I go. Maybe my small steps might prove interesting or useful.

 

The first thing I did was to get my existing interrupt and TimerA based code running on the FR6989. No problems there. As I mentioned, I'm really impressed by the EnergyTrace++ features. It just makes you want to see how low you can go - even if you don't really need to. My project is mains powered but I still wanted to get it down to 2mA (6mW) by using low power modes properly. (I think this included some blinking LEDs, so I should really exclude this.) If I can't beat this with the ESI then it's not worth using.

 

The next thing I did was take a look at the msp430fr69xx_esif_01 quadrature example. Rather worryingly, when I get the output of this on the 'scope I seem to get a fir bit of jitter. The MSP430 generates a fake quadrature signal. Two nice clean 20Hz 50% duty cycle square waves 90 degrees out of phase. However the output from the ESI (counting 20 rotations) seems to normally be a 1Hz square wave but the low signal and then jumps up to 600ms, shortly followed by the high. The output pulse are 1s, 1s, 1s, 1.1s, 1.2s,... That's a LOT of jitter for such a clean and synchronised input. If I can't sort that out, it's a high price to pay to save a little power.

[abecedarian 330]

Hoping to cheer you up, here....

 

I'm waiting for a few Hall Effect flow sensors, and some solder flux to arrive.

 

MAX9926 is capable of processing floating and single ended sensors... but the footprint is an issue. Hot air reflow is going to contribute to global warming, right?

 

I'm sure it's going to be interesting when we each get to write up the blogs.

[Fred 453]

The first part of the ESI I've looked at is the Processing State Machine. The best explanation seems to be in section 4.7 of slaa639 which explains the LC base quadrature encoder example. It's particularly good at showing how to create the PSM table from your state machine design (4.7.2). The PSM is also explained is section 28.2.8.3 of the slau367e but I don't think it's done as clearly.

 

Note that if you're looking at both the LC design and the MSP430Ware quadrature example, these do things slightly differently. For instance the LC one uses Q6 and Q7 interrupts and the MSP430Ware one doesn't. They're fairly similar, but not quite the same. As this is just a list of 16 hex constants it's not easy to tell!

 

One thing that isn't obvious is what's done with the bits reflecting the current and new state of the two inputs. These are in a fixed order and hence tell you which of the 16 PSM bytes you're dealing with.

 

My flow sensor actually has two magnet on the rotating disc and uses a "N" to set the output high and a "S" to set it low again. I could add a second sensor to make it a quadrature encoder, but to avoid too much unnecessary modification I'm going to try adapting to code to fit instead. I'll try to convert the ESI quadrature code to accept a simple single pulse input.

 

Stay tuned to see how it goes...

[chicken 630]

Thanks for sharing your research. This will be very helpful when I revisit my project... right after work and live gets out of the way, which might be right in time for Christmas :-/

[Fred 453]

OK. Some progress on the Processing State Machine part of things. In all the examples I've seen the PSM is programmed by inserting a mysterious arrays of 16 hex digits. That's just so helpful! Here's an example from the simple quadrature encoder example msp430fr69xx_esif_01.c

const unsigned char psmTable[] = {
        0x00, 0x03, 0x0C, 0x49,
        0x00, 0x01, 0x48, 0x09,
        0X00, 0X41, 0X08, 0X09,
        0X40, 0X01, 0X08, 0x09
 }; 

Well, by just the addition of a couple of definitions for those bit flags and it's a little clearer. If the states go 0,1,3,2 then it counts up. 0,2,3,1 counts down. Transitions between non-adjacent states (from a quadrature point of view) flag an error.

#define PSM_COUNT_UP    BIT1 //0x02
#define PSM_COUNT_DOWN  BIT2 //0x04
#define PSM_GOTO_S0     0
#define PSM_GOTO_S1     BIT0 // 0x01
#define PSM_GOTO_S2     BIT3 // 0x08
#define PSM_GOTO_S3     BIT0 + BIT3 // 0x09
#define PSM_Q6          BIT6 // 0x40
#define PSM_Q7          BIT7 // 0x80

// Interrupt Q6 flags an error (but actually gets ignored in this code)
#define PSM_ERROR		PSM_Q6

const unsigned char psmTable[] = {
    /* State 0 */
    /* Input 00 */    PSM_GOTO_S0,
    /* Input 01 */    PSM_GOTO_S1 + PSM_COUNT_UP,
    /* Input 10 */    PSM_GOTO_S2 + PSM_COUNT_DOWN,
    /* Input 11 */    PSM_GOTO_S3 + PSM_ERROR,
    /* State 1 */
    /* Input 00 */    PSM_GOTO_S0,
    /* Input 01 */    PSM_GOTO_S1,
    /* Input 10 */    PSM_GOTO_S2 + PSM_ERROR,
    /* Input 11 */    PSM_GOTO_S3,
    /* State 2 */
    /* Input 00 */    PSM_GOTO_S0,
    /* Input 01 */    PSM_GOTO_S1 + PSM_ERROR,
    /* Input 10 */    PSM_GOTO_S2,
    /* Input 11 */    PSM_GOTO_S3,
    /* State 3 */
    /* Input 00 */    PSM_GOTO_S0 + PSM_ERROR,
    /* Input 01 */    PSM_GOTO_S1,
    /* Input 10 */    PSM_GOTO_S2,
    /* Input 11 */    PSM_GOTO_S3
 };

Well, I haven't actually got a quadrature input. I've just got a simple pulse, so I'm only using ESICI0 to toggle between states 0 and 1. I am wondering whether the PSM should/can be ditched completely for this, but as this is to find out about the ESI I'll keep going.

const unsigned char psmTable[] = {
    /* State 0 */
    /* Input 00 */    PSM_GOTO_S0,
    /* Input 01 */    PSM_GOTO_S1 + PSM_COUNT_DOWN,
    /* Input 10 */    PSM_GOTO_S2,
    /* Input 11 */    PSM_GOTO_S3,
    /* State 1 */
    /* Input 00 */    PSM_GOTO_S0,
    /* Input 01 */    PSM_GOTO_S1,
    /* Input 10 */    PSM_GOTO_S2,
    /* Input 11 */    PSM_GOTO_S3,
//Should only every flip between states 0 and 1, but just in case it gets to 2 or 3...
    /* State 2 */
    /* Input 00 */    PSM_GOTO_S0,
    /* Input 01 */    PSM_GOTO_S1,
    /* Input 10 */    PSM_GOTO_S2,
    /* Input 11 */    PSM_GOTO_S3,
    /* State 3 */
    /* Input 00 */    PSM_GOTO_S0,
    /* Input 01 */    PSM_GOTO_S1,
    /* Input 10 */    PSM_GOTO_S2,
    /* Input 11 */    PSM_GOTO_S3 + PSM_COUNT_DOWN
 };

Well, that's my small amount of progress for now. The PSM is less of a mystery but then again I feel that was one of the simpler parts. It does seem that it's perfect for quadrature decoding, but perhaps difficult to use for anything else. I must look at the 3-sensor LC example to see if that yields anything interesting.