Lookdown-lookup

mmoreland

Is it ok to construct two look down tables that refer to the same look up table? I have 360 items to look down through, but pairs of them refer to the same reference item in a look up table. For example, if I have a, b, c, d, e...etc. (180 such items in one look down table) and I have aa, bb, cc, dd, ee...etc. (another 180 items in another look down table), and the look up table has 2, 4, 6, 8, 10...(180 such items in the table), and both "a" and "aa" refer to 2, is such an arrangement feasible? If the item being looked down is "aa," and it's not found in the first table, can it be written so that the search continues to the second table so that the referent "2" can be found and placed in memory?

Or is there a far easier way to do this maneuver?

Tracy Allen

I don't see any reason why not. The exact form it will take would depend on knowing more details about these items of data. I am assuming that you are using a BASIC Stamp, is that right? What sort of data are the series "a"... and "aa"... for the lookdown? You can have two lookdown statements in a row set up so that if the first one does not succeed, it will fall through to the second one.

z = 0
lookdown x,[5,8,13,21,34,55,89],z
IF z=0 THEN 
   lookdown x,[4,7,12,20,33,54,88],z
IF z=0 THEN
   DEBUG "bad luck",CR
  ELSE
    lookup z,[..........],k
    DEBUG "value=", DEC z,TAB,DEC k,CR
END

There is a limit on the number of values in a lookdown (=256). Also, LOOKDOWN can use a comparison like > or < rather than the default =.

It may be better to not use LOOKDOWN, and instead to store all of the "a"'s and "aa"s as DATA in eeprom, and write a little subroutine to find the match.

If the items in the lookup do in fact form a regular sequence like 2, 4, 6, 8, ..., then a loopup would not be needed at all. Just a math formula to relate the lookdown index to the output number.

kwinn

If I interpret the question correctly there is no reason it cannot be done, but I am wondering why you would need 3 tables to look up data in one of them.

mmoreland

Thank you, Tracy Allen, for your complete and helpful reply. I'm still working away on a controller for my solar array, and I'm taking it in stages. First, that it will set one angle per day and put it away in a vertical position at night. Later, when I've learned how to do the simple one, I'll change it to add several movements per day. I'm working on obtaining the day/month from a GPS string (in the form, i.e. 0101 for Jan 1 or 0528 for May 28), and then in the look down table I was going to list the first 186 days and in the second the next 186 days. Only one look up table would be required because the angles repeat beginning Dec 22 through June 21 and then back again through the same angles to Dec 21. Your reply helped me realize that since many of the days have the same angle in succession, that I could actually shorten the lookdown table to just 100 entries for the whole year and only 50 angles in the look up table. I appreciate the "bad luck" feature. I don't understand your other comment about DATA in eeprom, but you are correct that the lookup would be a regular sequence of angles from 15 to 65. Can you add any additional explanation or a link to a site where I can get more? mm

Tracy Allen

If you have the month and the day, you can calculate the day of year (1->364 or 365) directly with a formula (described here).

[COLOR=red]' MM is month (binary, not BCD), DD is day of month, YY is year (e.g. 11, for leap year)
JD=MM-1*30+(MM/9+MM/2)-(MM max 3/3*(YY//4 max 1 +1))+ DD[/COLOR]

Once you have day of year, you can use that for lookup. It is probably good enough to have it done for every 5 or 7 days and interpolate if helpful.

mmoreland

I have been able to extract the day (dd), month and year from the string using SERIN and GET, but if I ask for the results in DEC it gives me 495748574949 which seems to me to be the ASCII codes for 190911. I would like to work with the results which look great when I don't ask for DEC, but don't respond so well to arithmetic operations. How can I get the results in decimals that are the same as the ASCII results, not the code equivalents?

mmoreland

Got it...subtract 48 from each DEC result. Little slow here...

Tracy Allen

Right--that's it! Ask more questions if you get stuck. I've used that technique (using Julian sequential time) to build tables for sunrise and sunset. I think I had posted the excel spreadsheet I use, that has macros for solar position and transits.

mmoreland

Yes you had, and I have used it extensively. It has been extremely helpful.

mmoreland

I'm attempting to put together a four digit decimal to represent a day of a month (earlier post in this thread). I fail to understand how to perform math operations on the ascii numbers other that in the debug screen. For example, I have a four byte array from GPS. It is ddmm. I want to rearrange it and place it into a single word variable in the form mmdd, and I imagine that I must multiply the third dec byte by 1000, the fourth by 100, the first by 10, etc and add them together to get the number conversion I'm seeking to put in a word variable and use in a table. I'm unable to get the array bytes in a form that allows me to perform math operations on them.

Tracy Allen

Well, say it is September 23rd. Then your GPS returns dymn, that is, (I think), the ascii byte values, d="2" y="3" m="0" n="9". To convert the day and the month to two integer bytes, do this:
DD = ((d-"0") * 10) + (y-"0") ' 2 * 10 + 3 = 23 ' day of month
MM = ((m - "0") * 10) + (n - "0") ' month of year

When the Stamp encounters something like d="2" or this (d - "0"), it substitutes the ascii code for the thing in quotes. So for d="2" it subsitutes d=$32 (or decimal d=50, same number inside the computer). And for (d - "0") it substitutes (d - $30) or same thing (d - 48) in decimal.

To get from day and month to the sequential day of year is a little more complicated, because of the varying number of days in a month. That was the purpose of the formula I posted above. If you don't care about adjusting for leap years, then it can be simplified to,
JD = (MM - 1 * 30) + (MM/9+MM/2) - (MM max 3 / 3 * 2)+ DD

where MM and DD are integer values as calculated above from the GPS data.
JD then is a Word number that runs from 0 to 364.

mmoreland

OK. When I get the ddmm part of the string from the GPS (following PJAllen’s advice in another thread in Sensors), all I see is 2309 in the debug window or I get 50514857 if I ask for debug dec. I've never seen dymn, but perhaps that's one of those things that just exists subliminally ("same number inside the computer"). What is the ‘ mark before 2 and after 23 and before “month of year” in your reply above?” Are (d-”0”) and (“2”-48) equivalent statements? I'm using a 366 day year. If GPS doesn't provide a 2/29, the controller won't be the wiser.

Tracy Allen

I used dymn so as to have a separate letter for each of the 4 ascii bytes. Sorry for the confusion.

In your example, 50514857, the four bytes are d=50 y=51 m=48 n=57.
You are correct: d-"0" is equiv to d-48 is equiv to d-$30. So,

d-48 = 50-48 = 2
y-48 = 51-48 = 3
m-48 = 48-48 = 0
n-48 = 57-48 = 9

Put the 10s and the 1s digits together into two integer bytes for day and month:

dd = 2*10 + 3 = 23
mm = 0*10 + 9 = 9

Now into my formula for day of year (keeping in mind the Stamp's order of operations)

[COLOR=black]JD = (MM - 1 * 30) + (MM/9+MM/2) - (MM max 3 / 3 * 2)+ DD
      = ((9 - 1) * 30) + ((9/9) + (9/2)) - ((3/3) * 2) + 23
     = (8 * 30) + (1 + 4) - (1 * 2) + 23
     =  240 + 5 - 2 + 23
     = 266[/COLOR]

So Sep 23rd 2011 is the 266th day of the year. (Oh, in my previous post, I should have said 1 to 365, not 0 to 364!)

You also asked,"What is the ‘ mark..." It is the comment marker. Everything that follows the ' is a comment, not code.

mmoreland

Sorry you have to resort to such baby steps with me, but it's appropriate, and all the above was very helpful and it has all worked. Eventually, I will use the formula for "day of the year," but for now, I'm going to use a lookdown table with 99 entries representing days on which the tilt changes, e.g. 105 or 531 for January 5th and May 31st and a corresponding lookup table with tilt angles. If I get this simple program to work, and the array becomes automated, then I'll work on a bigger plan in which the array changes angles several times per day, and I'll use your more efficient formula above. I have used the information you provided to tie the formula to GPS data, and as you predicted, it gives the correct day of the year. It's very slick. Thanks.

Tracy Allen

Not a problem. Baby steps build up to making strides. Your approach sounds very workable.