Using SPI for pressure sensor

victorf · Post by **victorf** » 27 June 2007, 18:34 PM

The "silent" failure precludes being able to create robust apps where causes of failure could, and should, be reported to the user. It was a good thing when exception raising was incorporated into some of the "bigtime" languages. I'm not sure that repeating other's mistakes is necessarily a good thing. I agree with Tony:

Maybe it should only be silent in "compatibility mode", and will complain vocally if in "native ZX mode"....

Vic

mikep · Post by **mikep** » 27 June 2007, 20:34 PM

Let's step back and think about what this problem is really about.

Most of the failures in programming are due to the programmer making a mistake that the compiler and tools cannot prevent. This is especially true for microcontrollers. For example if you specify the wrong baud rate or use the wrong pin or forget the pullup resistors on I2C then no tool is going to able to help you here except the one between your ears.

In the case of programming directly to the AVR hardware, it is very easy to specify the wrong bit on a control register or forget to setup something correctly. For example if you forget to zero the MCUCSR register after a reset you may stay in an infinite loop resetting the device forever. Again tools cannot prevent you from shooting yourself in the foot.

The ZBasic System Library provides a high-level abstraction into the AVR device and actually eliminates many possible programmer errors. So that leaves us again with the possible failures modes of different APIs in the System Library. In the case of OpenSPI, Don has already listed a few. Nothing can be done to prevent the programmer specifing the wrong pin number for the csPin. I think if you specify the wrong flag e.g. 0x40 then nothing extra happens. In this case the compiler or the ZVM could check for a SPI channel number out of range. This is a relatively easy fix but in the grand scheme of things it is a nit.

By the way there is a lot more to creating a robust application than having the runtime check for an error and the programmer writing the extra code, which most don't, to trap and deal with the error. In this case what happens? The programmer slaps forehead, changes the hard-coded value in the OpenSPI subroutine call and never needs any of that extra baggage again.

I would ask what is the biggest problem here? Not reading the manual, mistyping the SPI port number, or figuring out how to use the SCP1000 pressure sensor? Let's keep a perspective here.

victorf · Post by **victorf** » 28 June 2007, 4:49 AM

Mike,

You, Don and Steve know a lot more about this sort of stuff than I will ever know. This is certainly evidenced by my requests for help in understanding how to do things that I do not understand. This thread is evidence of that! I don't think I was talking about having a system library that might not be robust. I have every confidence that, in fact, it is. I use the ZX-24 platform for developing applications that I would like to sell. When I write a routine of my own, I consider the consequences if it should not perform properly. I usually include some error checking in the routine that will allow me to inform the user/developer that there was a failure and offer some clue as to the nature of the failure. Once a test project is up-and-running, it is quite easy to see if I forgot a pullup resistor or used an inappropriate baud rate or used the wrong SPI port number. After thorough testing most, if not all, of these sort of bugs are discovered and fixed. But I must remind you that s**t happens! and when it does, you can end up having an irate customer. I can, and try to, control how the software I write performs and knowing I am fallible I try to take precautions to mitigate the consequences of my falliblity.

Again, thanks to all of you who take the time to assist others on this forum. You are a value-adding feature of the ZX product line!

Vic

spamiam · Post by **spamiam** » 28 June 2007, 4:54 AM

Mike, You are absolutely right. I got stuck on the "silent failure" aspect without thinking too much further about the invalid channel and CSpin. I was thinking about if you specified an illegal channel and CSpin, not just the WRONG (but otherwise legal) one.

No criticism was intended. I guess I was trying to say that (for me) it is OK to NOT be limited by BX compatibility if some enhancement would otherwise be worthwhile.

You are right, the runtime code shouldn't have checks for everything under the sun. It will just get too bulky and slow. We do have to leave some stuff to the programmer!

-Tony

victorf · Post by **victorf** » 02 July 2007, 10:55 AM

Shipped the project board for the SCP1000 to ExpressPCB today and have started to work on the software.

I need to convert the pressure value into height referenced to the US Standard Atmosphere. There are plenty of on-line calculators that do this, but I need to do this programmatically. The SCP1000 provides pressure in Pascals and the temperature in degrees Celsius. Can someone provide me a formula to convert this data into height in the Standard Atomsphere? I get somewhat confused with units when examining the equations.

Any enlightenment will be appreciated.

Vic

cloxwerx · Post by **cloxwerx** » 02 July 2007, 12:44 PM

Vic,

Wikipedia has a pretty decent explanation of pressure and height and provides equations to compute pressure if height is known. You will have to solve the equations for height since you are dealing with a known pressure. Check http://en.wikipedia.org/wiki/Atmospheric_pressure for the information.

Good Luck,
Dennis

Instrument pilot
Skydiver
Paraglider pilot

victorf · Post by **victorf** » 05 July 2007, 10:51 AM

A bit more searching came up with a good equation for computing standard atmosphere height given the pressure. I have made a .PDF of the equation which is attached. Any comments?

on-paper calculation of height for pressure of 100000P gave 110 meters and 90000P gave 987 meters.

Vic

mikep · Post by **mikep** » 05 July 2007, 11:39 AM

Your PDF equation matches this website http://en.wikipedia.org/wiki/Altimeter if you bear in mind that their equation gives an answer in feet rather than meters.

Note that Pref is not always 101325 Pascals and can vary day to day. If your launch site is not at mean sea level then you to adjust when calibrating. Also P and Pref do not have to be measured in Pascals - other units of pressure can be used providing the same unit is used for both. I notice that the SCP1000 uses kPa for example.

The advantage of the wikipedia page is that they have precalculated all of the constants which will make it snap to implement in ZBasic.

victorf · Post by **victorf** » 05 July 2007, 12:11 PM

Mike,

Thanks for the reply. I agree about PRef. However, my application is mimicking a barometric altimeter as used in aircraft. The Kollsman Window shown in the Wiki is used to adjust the altimeter to the prevailing surface (airfield) pressure. This is standard aviation usage. I am designing such a critter into my altimeter. Since some users may wish to use feet and Inhg and some may want feet and millibars and some might want kP and meters, I prefer computing using Pascals and meters and have the output display scaled to the user preference. As in the Wiki, I have precomputed the constants.

Vic

victorf · Post by **victorf** » 21 July 2007, 11:58 AM

Thanks to a lot of help from contributors to this thread, I finally got a prototype altimeter built using a ExpressPCB board. The board is an auxillary to a ZX-24 prototype board that I use for development. I have attached a copy of the altimeter schematic.

As you can see from the schematic, I use the level shifting scheme suggested by mwf. My only deviation was to ground all the OEBars so all the outputs are enabled all the time. The 3.3V to 5V conversions work. I feed in 3.3 volts at the B01 connector on either of 3.3V signals (MISO and DRDY) and they get converted to 5V at the xY outputs of U2 as advertised. I am taking the 3.3V from the on-board 3.3V regulator U3. However feeding 5 volts to any of the 5V signals on J1 (MOSI, SCLK and CSBAR) does NOT produce 3.3V on the appropriate xY outputs of U1. I measure 4.3V on them. Measuring the output of U3 shows 4.3V instead of 3.3V. Removing the 5V from the J1 terminal restores the output of U3 to 3.3V. I do not understand what is going on. BTW: the altimeter board is NOT connected to anything on the ZX-24 board during these tests nor is the sensor breakout board installed.

Any enlightenment will be appreciated.

Vic

Post by **dkinzer** » 21 July 2007, 12:16 PM

victorf wrote:Measuring the output of U3 shows 4.3V instead of 3.3V.

The symptom that you're seeing results from the absence of a limiting resistor in series with the 5 volt inputs to the 3.3v powered device as suggested by the equivalent schematic shown in the datasheet (reproduced below). When an input is at 5 volts you're effectively powering the device with 4.3 volts supplied through the upper clipping diode attached to the input.

victorf · Post by **victorf** » 21 July 2007, 14:25 PM

Anything I can do to recover?

Vic

Post by **dkinzer** » 21 July 2007, 14:51 PM

victorf wrote:Anything I can do to recover?

If you have enough space it should be easy to correct. Just cut the trace running between J1 and the input of the buffer gate and solder a resistor across the cut. Something in the 4.7K to 10K range should work.

victorf · Post by **victorf** » 23 July 2007, 5:25 AM

Don,

I tried adding the resistors (4.7K) as you suggested and they did not have any effect. I get the same symptoms that I reported in my previous post. I have attached the updated! schematic to show where the resistors were placed. Have you any further suggestions?

Any further enlightenment will be appreciated.

As you must be aware by now, my knowledge of electronics is somewhat limited. I certainly appreciate ALL the advice I get here.

Vic

Post by **dkinzer** » 23 July 2007, 7:44 AM

victorf wrote:I tried adding the resistors (4.7K) as you suggested and they did not have any effect.

The resistors need to be between the 5 volt outputs from the ZX and the inputs of the 74AHC125. This positioning prevents those 5 volt signals from powering the 74AHC125 through the clamping diodes on its inputs.

I've attached a modified schematic showing the correct positioning.