Sensor Priority

SailerMan

Hypothetically... I have 8 pressure sensor they have a pulse width Output. I have these hooked up to Port B of an SX 28. I can poll each pin in sequence and retrieve the pulse width. No problem with that.

What I what to do is poll each pressure sensor based on a specific pressure. In other words lets say that critical pressure is 10 and all of the sensor are reading 5 except one of them which happends to read 6. The system would prioritize that sensor and read it more frequently and read the other 7 sensors less frequently. There is only 64 Polls and depending on the pressure reading.. Some sensor·might only get polled 1 time out of the 64.

Each sensor gets polled at least 1 time in 64.

I hope this makes sense.

Anyone have Ideas on how to make this happen?

Regards,
Eric



[noparse][[/noparse]Subject Added By Moderator]

Post Edited By Moderator (Chris Savage (Parallax)) : 2/13/2007 3:43:29 PM GMT

Mike Green

First you need to identify the specific rules you want to use. How many "levels of concern" do you want to have? You want to guarantee at least one reading of each sensor per cycle of 64. What's the maximum number of times for a given sensor? At what readings do you switch priority? Once you define this, you can choose a way to make it happen. How much memory do you have available? How well do you want to distribute multiple readings across the 64 slots? You probably don't want to do all the multiple readings of a sensor in the same portion of the cycle. You want to spread them out.

John R.

Ahoy mate;

How about something like this (conceptually):

Define a 64 member array.

Set every 8th element to one of the sensor pin IDs.

Set the balance of the elements to "zero".

Have an index variable for the array.

When it's time to poll, check the value of the array index. If it's zero, skip until you find a non-zero value. Then poll that pin.

If you find a pin that needs a higher priority, change one or more array elements to that pin.

When that pin no longer needs to be "higher" in priority, zet the element back to zero.

Lots of details to fill in, but at least one possible concept. How to know what pins have what elements is the biggest problem I can think of now.

Thinking conceptually, another possible variation would be for each pin to have it's own array of "poll/don't poll" elements. Cycle through the arrays, and only poll the pin if the current element is "1".

This would provide regular polling of all pins, and keep the frequency for all pins at a "maximum", yet allow for adding additional polling for one or more pins.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John R.
Click here to see my Nomad Build Log

Mike Green

Some specific ideas ... You will need a slot counter that's incremented with each sensor reading. When the least significant 3 bits are zero, the sensor to be read is defined by the most significant 3 bits and the sensor value is stored in a table with 8 entries (one for each sensor). That sets up the minimum conditions for reading the sensors.

SailerMan

Mike,

Can you elaborate with a little psuedo code.



I'm just throwing our arbirtary numbers.

There are definately 8 Pressure sensors. Each one can read an equivalent value of 0 to 254 (1 byte)

I selected 64 polls because of 8 sensor. but maybe that is not the right way to think about it.

Let's say for instance all sensors read 128. and there are 64 Polls. then Each one would recieve 8 Polls.

If Sensors 1 thru 4 are reading 64 and 5 thru 8 are reading 192 than Sensors 1 thru 4 would each get 4 Polls and Sensors 5 thru 8 would each get 12 Polls.

I want this to work through all readings of the sensors. Maybe I will need more polls, but the number of sensors will be fixed at 8 and the Readings range from 0 to 254.

The reason I want this is because There is really no reason to Poll these·presure sensors so frequently unless one is increasing in pressure then I want to poll more frequently to get more accurate pressure samples. And stop the Pump when the pressure gets with in a certain Sent critical limit.

Mike Green

Maybe it's better to not have a fixed length cycle. For each sensor, you keep the last two readings so you know the absolute value and the change from the previous reading. You also have a counter for each sensor that indicates how many cycles (of 8 readings) that you will skip before checking again. You will go through a cycle of 8 sensors as follows:

1) If the "skip count" is > 0, decrease it by 1 and go on to the next sensor

2) Copy the "most recent value" to the "previous value" for this sensor, read the sensor, and save the "most recent value"

3) If the value is < 64, set "skip count" to 3; if < 128, set to 2; if < 192, set to 1; otherwise, set to 0
This prioritizes the readings in favor of sensors already seeing a higher value

4) If the "most recent value" - "previous value" is > 64, set "skip count" to 0
This makes sure we will track a rapidly increasing value even if it's low at present

5) If the "most recent value" is greater than the critical limit, stop the Pump

SailerMan

I'll have to try this out..

I'm thinking of a percentage thing now. If

If Sensor1 is reading 142 = 142/255 =.559 and each Sensor is Allocated 8 Polls than this one Should Recieve 4.47 or 4 Polls. Oh but this wont work because what if the other sensors are also reading 142 then I would only have 32 Polls. leaving the other 32 to be skipped over. I want this to scale accordingly... So If if all sensors are equal they each get an equal amount of cycles.
OK So I read all 8 sensors and take the average reading.



Then Take the Sensor Reading /Average of all sensors* Total Polls·(64) = Number of Polls for Sensor.

It works.

For instance


Reading Polls
Sensor 1 255 12.76995305
Sensor 2 128 6.410015649
Sensor 3 128 6.410015649
Sensor 4 128 6.410015649
Sensor 5 128 6.410015649
Sensor 6 255 12.76995305
Sensor 7 128 6.410015649
Sensor 8 128 6.410015649
Average 159.75 Total Of Polls 64

Now considering that these are the number of polls to be assigned to each sensor.

how can I intermix them so they are shuffled properly. In the instance above I don't want Sensor 1 to be polled 12 times in a row.

Post Edited (SailerMan) : 2/13/2007 9:40:23 PM GMT

SailerMan

Does anyone have any Ideas on how to handle the last question I had concerning how to Shuffle the Results.

I have 8 Sensor...

I have 64 Time Slots (Polls)

Sensor 1 Polled 12· Times
Sensor 2 Polled 6···Times
Sensor 3 Polled 6···Times
Sensor 4 Polled 8·· Times
Sensor 5 Polled 6·· Times
Sensor 6 Polled 8·· Times
Sensor 7 Polled 6·· Times
Sensor 8·Polled 12· Times

I don't want the polling to be seqential but rather·mixed.

The number of polls per 64 time slots depends one the Sensor Values. So these are dynamic numbers.





Post Edited (SailerMan) : 2/14/2007 5:10:09 PM GMT

John R.

Eric;

What kind of timing are we talking about, how much time is available to "manage" the polling priority, and how fast do the pressures and priorities change?

At the end of each polling cycle, could you re-populate an array of 64 bytes with the polling order? Then you could take your priority list as you have above, and put the sensor number in the appropriate number of evenly spaced slots.

Ignoring some rounding issues:

Sensor 1 and 8 in every 5 slots
Sensor 4 and 6 in every 8 slots
Sensor 2, 3 5 and 7 in every 10 slots


You could deal with the rounding by filling a couple slots with either an extra poll or "zero" to just skip the poll and then re-establish the priority list sooner.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John R.
Click here to see my Nomad Build Log

SailerMan

John,

Thanks for the Reply, I'm really only interested on how to fill in the "Slots" Because Sensor 1 and 8 might not demand 12 Polls (5 Slots) I'm trying to figure out an Algorithm and was looking for some Ideas. I can't get my head around how to accomplish this.

The Polling takes between 100 and 500 uS but that really isn't that important at the present time.

Thanks again for your response and if you have any more Ideas please let me know.

Eric

John R.

My questions on timing were more targeted at how dynamic the polling list needs to be. If you could live with working through all 64 (or so) polls before establishing a new priority list, than the above might work along the following lines:

At the end (or beginning) of each polling cycle:

Use either method from your post 4 postions up (where you talk about possibly only getting 32 polls in one case, and then use percentages to get 64).

Now you know how may polls each pin should be allocated. Take 64 / polls for each pin, this gives you the "every x slots for each pin.

Then:

Clear the array

For each sensor pin:

If the x is < 8, it is a "high priority"
--Fill in the first avaialble slot
--Skip every x slots, and fill in the next available.
If x >=8, it is a "low priority"
--go to the Xth slot, and fill in the next available
--skip every x slots and fill in the next available

When polling:

Process the pins per the array.
If a slot in the array is zero, skip to the next

I played with this "by hand" in Excel, filling up a column with the pin numbers from above. It may need some tweaking, and/or you may need an array bigger than 64 but skip more zeros, but I think this "could" work. If you have to resort to this, you'd also have to count how many times you inserted each pin and stop when appropriate.

Because you would just skip over zeros, it wouldn't necessarily matter if you didn't total out "exactly" 64 polls. This might make your first method of calculating priorities more attractive.

I'm not saying it's the best, or is in a "final form" but it looked like it could work out.

The problem has my interest piqued. I'm at work, and just chekcing inbetween processes I have running. If I still don't get what you're after, kick me again, and I'll see what I can do. I have not worked much with microprocessor programming, my background is in business programming with lots of resources (ram and processing time). If my concepts are not practical with SX/B or assembly, let me know, I'm working on learning here too.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John R.
Click here to see my Nomad Build Log

jb1311

How about a count down counter for each sensor and the decrement amount is computed based on the variance from the set point? If the function is complex you could decrement based on a look up table.

Capt. Quirk

Mike said

"First you need to identify the specific rules you want to use. How many "levels of concern" do you want to have?"

I am always curious about monitoring sensors like this and so I was wondering if you set your "levels of concern" by incremented pressure levels or by the rate +/- of·change· ?

Post Edited (Capt. Quirk) : 2/14/2007 7:36:52 PM GMT

John R.

jb1311 said...
How about a count down counter for each sensor and the decrement amount is computed based on the variance from the set point? If the function is complex you could decrement based on a look up table.

The challenge with this and other concepts of just "setting a priority" is that you risk checking the high priority lines on two or more successive polls, and not cheking anything else in between:·Or checking all the "low priority" pins on successive polls, and not checking any "high priority" pins during this time span.

The challenge becomes how to "level out" the field so there is an "equal number" of other pins polled between each poll of a given pin.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
John R.
Click here to see my Nomad Build Log