Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 2 [3] 4 5 6

Author Topic: New project, A Clock  (Read 6345 times)

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #30 on: November 25, 2020, 07:26:10 PM »

I wonder if the sensor would only need to have an unobstructed view in a southerly direction?  I.e. On the internal ledge of a south facing window.  :-\

That was my own first thought.  But the very few experiments I have conducted so far, using a completely different device containing the same sensor, suggest that direction doesn’t matter that much, the photovoltaic current simply drops through the noise floor quite quickly  (1-10 mins) after sunset.  It’s Currently facing vaguely West, seeing mostly light reflected off a brick wall, and it triggers broadly symmetrically either side of sunset/sunrise.

I suspect that maybe our eyes are better than we realise at adapting to twilight, being well within our pupils’ range of automatic adjustment, making the onset appear more gradual than it is.   That, at any rate, is what I am hoping will prove to be the case. :)
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: New project, A Clock
« Reply #31 on: November 25, 2020, 08:24:56 PM »

. . . the very few experiments I have conducted so far, using a completely different device containing the same sensor, suggest that direction doesn’t matter that much, the photovoltaic current simply drops through the noise floor quite quickly  (1-10 mins) after sunset.  It’s Currently facing vaguely West, seeing mostly light reflected off a brick wall, and it triggers broadly symmetrically either side of sunset/sunrise.

That is useful to know. So the mountainside looming over "The Weaving Shed", on Skye, should not be a problem.

Quote
I suspect that maybe our eyes are better than we realise at adapting to twilight, being well within our pupils’ range of automatic adjustment, making the onset appear more gradual than it is.

I, too, hold that same suspicion.  :)
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #32 on: November 29, 2020, 04:49:36 PM »

It might work, I’m not giving up.   :graduate:

The device is now capable of measuring ambience via its LED, photo current converted to voltage with the PIC’s Op Amp and measured with the PIC’s ADC.  As a temporary aid to development, it simply displays the A/D conversion result, as a decimal number, on the LCD.   In other words, I’ve spent all this time creating what already exists...  a digital light meter.   :D

In pitch darkness, I get a reading of 2 which presumably is the background noise and diode noise, as amplified.  Full scale ADC would read 1023.  I didn’t get it working early enough in the day to confirm, but my aim was that mid day readings would pretty much max it out.  Each unit represent a step of  2mV.

Here are a set of readings starting 40 mins before official sunset, from three different window sills, facing different directions.   It was placed on the sill in turn, with sensor diode angled at about 45 deg skywards, capped with a fresnel lens.

T-40    29/23/20
T-30    16/13/11
T-20    12/10/8
T-15     11/9/8
T-10     8/7/6
T-5       7/6/5
Sunset  5/4/4
T+5      4/3/3
T+10    3/2/2

So with this configuration at least, today, a threshold of ‘4’ would have got it about right in all three locations.   I can make the numbers bigger by changing the amplifier feedback resistor, which is probably worth trying.  It might over saturate at mid day, but I don’t think that matters.

In two of the test locations, switching room lights on/off made no difference.   In the third location room lights were a bit of a spoiler, adding about 8 to the reading at sunset.  This needs further thought. :-\
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #33 on: November 30, 2020, 06:25:37 PM »

Maths idea/question, for Weaver or anybody else....

I'm still not sure if I need trig functions.  It depends whether there is any credible prospect of doing latitude location.  But if I do need trig I'll need to find some shortcuts as, fool that I am, I am still determined to do it all in PIC assembly and if possible to see no name other than my own in code module headers.

Priority is to reduce memory footprint, including the footprint of big lookup tables as well as the footprint of large code libraries.  It doesn't have to be fast, it will have all day (literally) to work out the answer.

One idea I have is to approximate the smooth Sinusoidal graph, that we all recognise, into a number of straight lines between points -  thruppenny-bit style.  These reference points would be accurately calculated and hardcoded at build time, and there'd not be many of them - say, 8 or 16, built into a small look up table.

When I want to approximate SIN(x) for some arbitrary value I simply find the points that surround my value, and scale it as a linear transition between these known points.  I already have arbitrary precision binary multiply & divide working, so the scaling would hold no fears.

I have no idea whether that is a reasonable way of approximating Sin/Cos/Tan, or even a common way of doing so, or it is laughably flawed.   ???

« Last Edit: November 30, 2020, 06:29:28 PM by sevenlayermuddle »
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #34 on: November 30, 2020, 06:40:12 PM »

It’s what I would do. And linear interpolation is cheap, quadratic or cubic is more code and more time; and if you’re not too happy with the accuracy you can just add more points. You could also just do 0-45 degrees not 90 and use Pythagoras but that means having to calculate square roots which is awkward. I think you’re doing the right thing keeping it simple.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #35 on: November 30, 2020, 07:02:54 PM »


Many thanks for the fast response.

And linear interpolation is cheap,

Ah there’s a name for it.  I knew it was vanishingly unlikely be be something I had newly ‘invented’. :D

I might start experimenting.  My reference points don’t have to be evenly spaced of course, they can be more tightly packed at points where the graph is more ‘delicate’, ie top and bottom of a SIN curve.

I’m not afraid of square roots as they can be crudely iterated with multiply/divide.   That’d be embarrassingly slow but nobody would ever know, as speed is just not an issue.   I already have and use a very crude integer Log2 (Based on counting leading zeros), which might help to provide a first guess, for iterating a square root.


Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #36 on: November 30, 2020, 07:13:45 PM »

Indeed. Count leading zeros and then that gets you the log2, then you shift the result by half of that log2 when you’re done. That was my very first ever job, a 32-bit integer square root in Z80 code. It didn’t have to be very accurate, 1% very roughly but no exact choice was made regarding accuracy as all that mattered in this application was speed as it was called thousands of times. It was to calculate the vector that was normal to a surface and then the dot product of that normal with another vector. It was to calculate the illumination of light reflected from a rough surface (reflection in random directions) angled at some angle to a vector that was the direction of incident light from a source.
« Last Edit: December 01, 2020, 12:14:43 AM by Weaver »
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #37 on: November 30, 2020, 11:48:41 PM »

Interesting, Weaver.

My own biggest programming endeavour, since retirement in 2008, was to write a 3D OpenGL engine for an iOS App.  So I learned a lot about vectors, normals and dot products and much more.  Riveting stuff, for a guy who’d spent his career in comms protocols, it was  an entirely different challenge.

My OpenGL engine was a lot of fun.   Sadly Apple have deprecated OpenGL so I have to get around to rewriting my 3D engine in something else..   Not looking forwards to that at all, especially as I have now forgotten all the stuff I learned, about vectors, normals, etc.    :(

Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #38 on: December 05, 2020, 08:50:46 PM »

In the remote chance that anybody remains interested....

Clock is nearing initial trial stages.

Crystal controlled system timers working, a scheduler rattling the cages of other system modules every 1.0 seconds.   Lcd interface working reliably, interfaces that I have given names like “printChar”, “printDecimal24”, “printString”, “printHms” etc all work as the names imply.   8/24/32 bit maths (multiply/divide so far) behaving itself. 
Ambience sensing works, though needs a smoothing filter. 
Day/night clock setting logic has been implemented as a finite state machine.  Crude for now, but easy to enhance when testing begins.

Next stage is...

1. Deployment on a window sill, and watch for a few days.

2. Concurrently, start to think about actual packaging, decide what batteries to use, find a decent looking plastic enclosure box.  Maybe even get an initial PCB design submitted to the nice, amazingly cheap, Chinese fabricators. :)

But please tell me to stop if I’m boring you all, even if simply inferred by silence.  :D
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: New project, A Clock
« Reply #39 on: December 05, 2020, 09:16:37 PM »

I'm still following your progress and, I suspect, so is Weaver.  :)
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #40 on: December 05, 2020, 09:24:19 PM »

I'm still following your progress and, I suspect, so is Weaver.  :)

Thanks for the encouragement. :)
Logged

4candles

  • Kitizen
  • ****
  • Posts: 3297
  • Not young enough to know everything
Re: New project, A Clock
« Reply #41 on: December 05, 2020, 10:52:49 PM »

Not understanding a lot, but watching with interest. 
Logged
To err is human - to purr feline
Zen FTTC 40/10 + Digital Voice   FRITZ!Box 7530

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #42 on: December 06, 2020, 05:46:10 AM »

I most certainly am, am in awe
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5369
Re: New project, A Clock
« Reply #43 on: December 06, 2020, 11:12:12 AM »

I am wondering if any of us know much, or anything, about filtering algorithms.

I intend to filter/smooth the sensor diode with an algorithm I have used before, something like X = X - (X>>8) + newValue.    To get the rolling average, you take X>>8.

It's a tiny memory footprint and it's fast, and does seem to work as a low pass filter.  Taking a few tens/hundreds of samples per second, it succeeds in smoothing the signal from (say) 50Hz fluorescent lights.  But Apart from being vaguely intuitive that it will work I don't pretend to understand the maths, I don't even know what it is called, it's just something I've seen suggested in online discussions. :-[

I will also want to filter my 'hours of daylight' variable, such that the value I use for clock setting is averaged over a few days.   I wonder, is a similar algorithm appropriate?  Maybe combined with a 'peak' detector, such that when I see two successive days with vastly different values, I tend to favour the latest sunset and earliest sunrise as being more likely to be truthful?
Logged

Weaver

  • Senior Kitizen
  • ******
  • Posts: 11459
  • Retd s/w dev; A&A; 4x7km ADSL2 lines; Firebrick
Re: New project, A Clock
« Reply #44 on: December 06, 2020, 01:25:18 PM »

You can keep a rolling window of that last n values, when a value ages out of the oldest end of the window, we subtract that value from a total, when we add a new latest value in, we add it to the total. Suggest doing as you did and taking the total and subtracting the values

   static size_t youngest_ix = 1;
   static size_t oldest_ix = 0;
   /* remove oldest from the total */
  int oldest_val = circular_buffer[ oldest_ix ];
  static int moving_total -= oldest_val;
  oldest_ix = wrap_around( oldest_ix + 1 );  // size_t wrap_around (size_t x ) { return x >= circular_buf_size ? 0 : x; }

 /* add in most recent value into the total */
  int youngest_val = circular_buffer[ youngest_ix ];
  moving_total += youngest_val;
  youngest_ix = wrap_around( youngest_ix + 1 );

  const int = 3; /* or anything you like */

  weighted_moving_average = moving_total + ( youngest_val >> nshift ) - ( oldest_val  >> nshift ) ;

This weighted moving average, when unweighted (ie nshift = 0 ) is called convolution in mathematics; it comes up in Fourier transforms when you consider a time domain response of a filter that is bandwidth-limited in the frequency domain, ie. limited to pass frequencies between some f1 ≤ f ≤ f2 the Fourier transform of a square function, one whose whose frequency response is  = ( =1 ; f1 ≤ f ≤ f2; = 0 otherwise).

But there isn’t much mathematics in it as you can see; add up the last n entries sum [0..n-1] (where n = circular_buf_size ) and take that sum over entries 0..n-1, then take sum over entries 1..n, then 2..n+1 etc and this sequence of sums is the moving average. The size (width) ie  no. of entries in the circular buffer is the crucial parameter that determines the amount of smoothing. The more entries in the buffer, then the more the smoothing effect. Here I’ve just incorporated your idea as an additional tuning technique to also help tweak the behaviour as you please. There are many variations on this that you could try, but this is one, which I don’t particularly like because of the computational cost unless you use shifts instead of division and multiplication and also there could be problems with overflow which are nasty, so I prefer the earlier expression, although it’s not as flexible.

    /* An alternative technique; the weighting factor probably really ought to be a power of 2 to reduce the cost of the division */
    const uint weighting_factor = 2; /* for example */
    weighted_moving_average = (moving_total * weighting_factor + (youngest_val - oldest_val  >> nshift )) / weighting_factor;

Need to watch out for overflow in the multiplications and in the additions particularly where the buffer complete sum is calculated.

Remember if you have to go this way the old trick that divisions can always be done as follows by suitable (( x * ((1.0/div) << n ) ) >> n ) where ((1.0/div) << n ) is an integer constant and the multiplication needs to be done in enhanced width. You might want to add on an offset value after the multiplication to adjust for the rounding error when doing the division represented by the >> n, worth doing all this with a spreadsheet, integer maths and lots of tweaking to get the best accuracy. Probably best avoided though where accuracy matters.
« Last Edit: December 06, 2020, 07:58:21 PM by Weaver »
Logged
Pages: 1 2 [3] 4 5 6
 

anything