jaromir.sukubaThe key part of this project is determining location through known date/time and light levels.
The equation
Determining geographical longitude from light levels data is relatively straightforward. Take the time of solar noon and compare it to 12:00 of Greenwich time. If it's 12:00, then you are (approximately though) at Greenwich, if not, you are 15 degrees farther to East for each hour.
Calculating the latitude is somehow different matter. The relation between day length (at particular solar zenith angle), solar declination and geographical latitude is called sunrise equation, in general form looking like this
where A is solar zenith angle
L is geographical latitude
D is solar declination
O is hour angle
I played with it a bit, discovering relations between the variables. At first I was curious how does look the relationship between latitude and day length at different solar declinations, as those are the the main variables that come into game.
Expectedly, I can see strong relationship of day length and latitude when solar declination hits its extremes (winter and summer solstices) and very weak relationship at zero declination (spring/autumn equinoxes).
Change of day length over the changes of solar declination (= throughout the year) is almost linear, for -48, -22, 0, 22 and 48 degrees of latitude.
I was interested also how much the day length is changing when taking into account different solar zenith angles; the previous ones being at -0,83 degrees; being standard for sunrise/sunset tables. Though my detection algorithm triggers at slightly different angle, shifting the measured day length to somehow longer times. Here are day lengths at different sun zenith angles, for three different latitudes (48, 0, -48 degrees)
and here are just the differences
The differences are almost linear, with change rate slightly being dependent on latitude.
The problem
My problem with this equation is it's reverse of what I need - it gives me length of day from latitude, while I have the day length known, with latitude unknown. It looks like there isn't analytical solution to this equation. For now I have plan of having huge precomputed tables in FLASH memory of MCU and doing lookup, but I can't say I'm happy with it, though it can be quite effective when it comes to power consumption.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
What about solving the inverse sunrise equation numerically? Viewed that way, you are looking for roots of :
cos(O)cos(L)cos(D) - sin(A) + sin(L)sin(D) = 0
(where O, D, and A are known). You may be able to bracket the solution, then use bisection to find L.
Are you sure? yes | no
Thanks for hint. If I consider I need to solve the equation when O,D and A are known and constant for the time being
cos(O)cos(D)cos(L) + sin(D)sin(L) = sin(A)
is equation in form of
K1.cos(L)+K2.sin(L)=K3, where K1..K3 are constants
Seems that this form of equations fits into one of common equations forms, see here https://math.stackexchange.com/questions/201399/solving-sin-x-sqrt-3-cos-x-1-is-my-solution-correct/201405#201405
I tried the method with piece of paper and calculator and it seems to work.
Are you sure? yes | no
Nice. Glad you found it.
Now, you just need to write a paper-and-calculator simulation on your MCU :-)
Are you sure? yes | no
@Ted Yapo it wasn't that hard. I coded the thing into the MCU, without any optimizations the double precision calculation takes ~42ms of computing time of underclocked PIC24 while taking 300uA. That is 12uAh of capacity per calculation, battery should be OK with more than 50 years worth of calculations per day. I think the basic consumption of LCD, RTC and sleeping MCU will be the major contributor to battery depletion (roughly in 10 years).
Are you sure? yes | no
That's very good. 10 years is the shelf-life of the CR2032, so going longer than that probably isn't too interesting.
You might be able to reduce the power consumption with an external RTC, if it matters. This one claims 60na, or 17na for less precision:
http://www.microcrystal.com/index.php/news/25-cat-news/cat-articles/186-x-treme-low-power-real-time-clock-module-from-micro-crystal
I am looking at it for another project.
Also, how many positions can you log? I could see putting these things in bottles and throwing them in the ocean with a note and reward offer for safe return. It's cheaper and easier than the GPS+solar alternative. Without an LCD, they could be very small.
Are you sure? yes | no
@Ted Yapo there is 25AA256 EEPROM on board, able to keep 32768 bytes. If one record is say four bytes long (IMO enough to keep position precise enough for given method), that is 8192 records. Doing one record per day - that is 8192 days, roughly 22 years worth of location data.
The logger can be made very small. My PCB is 5x5cm, due to user interface, not needed for "throw-away" unit. Also, with no need for LCD driving, choice of MCU is much wider.
That RTC looks just fine for such as application, I wasn't aware of that.
Another idea - logger can be accumulator powered, with diodes like BPW34 or perhaps bigger ones could provide not only light measurement, but also power to charge the accumulator. That way, logger could have longer life and/or smaller dimensions.
Are you sure? yes | no