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 ... 3 4 [5] 6

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

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: New project, A Clock
« Reply #60 on: December 07, 2020, 05:12:39 PM »

Indeed I am now in data gathering mode.  I’ve treated myself to a second prototype.  It meant sacrificing a PIC as it needs to be soldered to an adapter but heck, they’re only about 30p each last time I looked.    That means one device can now be semi-permanently deployed, gathering data that I can read from screen and simply note with pencil and paper each day, to get an idea of the trends.

One compromise with the averaging is, illustrated with an extreme example... It is now nearing the shortest day and if I were to average sunrises over the past 90 days it would be skewed numerically downwards because, averages aside, the sun actually rose earlier in Autumn.  Similarly the sunsets would be skewed upwards.   Taking the average of each would not yield a useful figure for today’s daylight seconds.  It’d not even yield an average for day 45, as the changes over time are not linear.

With that in mind, I think the shorter the period of averaging the better, as the lesser the above errors will be.   I’m sure mathematics can be used to correct these errors, but I’d rather just dodge them.
« Last Edit: December 07, 2020, 05:18:19 PM by sevenlayermuddle »
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9812
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: New project, A Clock
« Reply #61 on: December 08, 2020, 04:41:29 AM »

I think that’s entirely the right approach.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: New project, A Clock
« Reply #62 on: December 08, 2020, 07:56:22 AM »

Bit of Eureka moment.   The device survived its first full sunset/sunrise cycle and has successfully synchronised its display with the quartz reference.   

It is telling me the time.   :yay:  :drink:  :graduate:

Clock is about 11 minutes fast compared with my wristwatch, which is slightly disappointing as true solar time today should be just a couple of minutes 4 minutes ahead for my location.  So a probable error of about 8-9 minutes.  ???

edit: Corrected solar time adjustment figure.
« Last Edit: December 08, 2020, 04:27:50 PM by sevenlayermuddle »
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9812
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: New project, A Clock
« Reply #63 on: December 08, 2020, 09:18:08 AM »

It’s always nice to get to a point like that.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: New project, A Clock
« Reply #64 on: December 08, 2020, 10:02:37 AM »

There's nothing like a major annoyance to start the day.

I decided that with progress made on the clock, it's high time I got my source and designs under version control.

I have my own subversion server on a Linux box, and svn client command line tools on the Mac OS are included with XCode, which Apple provide.  Except they are not, they've been deprecated.  I updated XCode a few weeks ago and have just discovered, svn command has evaporated.   :o

Most common suggestion from Google hits is to install svn via homebrew, but I whilst I have unswerving trust in the good intentions of developers of such software the fact is it weakens my system's security, leaving me vulnerable to so-called 'supply chain' attacks.  Same can be said of Linux of course, but the difference us that a 'pure' MacOS is pretty darned safe when shipped by Apple, it's a shame to break the seal, so as to speak.  Not entirely happy, now!   >:(

Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9812
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: New project, A Clock
« Reply #65 on: December 08, 2020, 10:10:46 AM »

Could you build it yourself?
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: New project, A Clock
« Reply #66 on: December 08, 2020, 11:22:14 AM »

Could you build it yourself?

I'd rather not.  But I think I have found a solution.

Since I have old versions of XCode installed, there are also old versions of svn lurking within directories you'd never think of looking... still seem to work - or at least, 'svn list' does as you'd expect.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: New project, A Clock
« Reply #67 on: December 08, 2020, 12:10:30 PM »

SVN crisis averted, you may be interested to see what I can see.

On the 2nd line, '255' bottom left is the A/D conversion.  ADC has 10 bit resolution but values above 100 or so are of no interest here so I cap it at 8 bits.

The middle number is the duration of daylight in seconds, currently incrementing.  The last number is the duration of darkness, frozen until next sunset, telling me there were 56560 seconds between perceived sunset last night and sunrise this morning.

The ugly loops of black wire are just a scaffold to stop the LCD from slithering around.  They could do with tidying, but I don't want to disturb it when it's running nicely.

The big blob of blue tack is a temporary shade for the sensor diode, giving it some immunity from room lighting.

I hope nobody looks too closely at the soldering on that SMD chip adapter.  I'll try to be neater when making the final device(s).   :blush:

Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: New project, A Clock
« Reply #68 on: December 08, 2020, 04:25:50 PM »

With apologies for consecutive posts....

It has just triggered today's sunset. Based on today's daylight seconds, clock has resynchronised exactly 7 minutes and 24 seconds ahead of GMT.  timeanddate.com predicts that for my location, the difference should be 4 minutes (they don't give seconds) so my clock is currently accurate to true Solar Time within about 3-4 minutes. 

Better still as I watched it nudging down towards the trigger,  I noticed a bug.  I've set the transition threshold at '10 units of ADC', but on the way up it's testing for x>=10, on the way down it's testing x<10.  That bug slightly delays the 'sunset' transition by a few minutes, perhaps just about the right amount bring it into exact agreement with timeanddata.com.    :)

Beginners luck, fluke, call it what you like, but I'm reasonably happy so far.   The Post Office speaking clock service could soon become completely redundant, once I enhance my device with Weaver's averaging suggestions. :D
« Last Edit: December 08, 2020, 04:31:20 PM by sevenlayermuddle »
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: New project, A Clock
« Reply #69 on: December 11, 2020, 03:23:04 PM »

@Weaver, ref your assistance with filtering & smoothing...

I found an interesting Application note from Microchip.  It explains how to use the on-chip ADC filtering computation that's on some PICs.

My chosen PICs don't the ADC filter computation feature, just basic ADC.  But the description of how the low pass filtering works is tantalisingly close to my existing diode smoothing...

http://ww1.microchip.com/downloads/en/AppNotes/AN2749-Using-PIC18F26K42-ADC2-00002749A.pdf
Quote
Low-Pass Filter (LPF) – Low-Pass Filter mode functions similar to Average mode, except that after an initial accumulation of samples based on the ADRPT setting, the module continues to accumulate samples and perform filtering operations indefinitely.

The only enhancement in that, beyond what I already do, is the initial averaging.  Once there's too many samples for averaging, it drops into what I already do.  I can easily amend my code to the initial averaging and then mode-switch.   

Is there any great advantage in doing more than that?   The sunrise and sunset variations due to cloud etc can be seen as equivalent to AC noise on a DC signal, so I'm thinking it's the same problem, with same solution?

I'm also thinking that the best parameter candidate for smoothing is the length of a solar day, Noon to Noon.  That number changes fairly gradually so should respond well to smoothing. And moreover, by looking at absolute value (together with trend) I think I can attempt to compute the time of year whenever I like.   This Wiki page has probably already been linked, but it talks about Solar Days...

https://en.wikipedia.org/wiki/Solar_time

 
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9812
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: New project, A Clock
« Reply #70 on: December 11, 2020, 04:56:34 PM »

It is indeed the same kind of idea.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: New project, A Clock
« Reply #71 on: December 12, 2020, 09:10:29 PM »

I’m thinking there might be a way of trivialising the run-time maths for full precision Equation of Time.

Why don’t I simply have a look up table consisting of the incremental delta, in seconds, for EOT of each day in the year?   That delta never exceeds 16 seconds per day which is nice, as the table can be expressed in 4 bit entries.  It could even be further compressed with zero suppression but probably not worth the bother, memory’s not that tight.   The sign of the delta changes four times a year, but that can be handled.

My table would also be slightly modified from the usual EOT as, when creating my table, I’d feed the EOT through the same smoothing filter my clock will use, thus compensating for the phase delay of my filter.

It wouldn’t be fast as each calculation, disregarding optimisations, would involve up to 365 16x4 bit additions.   But who cares, it only needs to be done once a day.

Sound promising?   Unless I awake tomorrow thinking it is a stupid idea, or am told so by Weaver or anybody else, I may start trying it out on a simple C program. :)

Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 9812
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Re: New project, A Clock
« Reply #72 on: December 12, 2020, 09:54:50 PM »

I think it is a good idea, and I agree I wouldn’t bother with the compression thing.
Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: New project, A Clock
« Reply #73 on: December 16, 2020, 12:54:28 PM »

Among the pain of writing fairly sophisticated (by my standards) code in assembly, one small experiment looks worth pursuing.

If it is ever to be a useable indoors device, it must be usable with room lighting switched on.  Early experiments had already shown that to be a challenge, requiring careful shielding of the sensor to avoid being dazzled by the room lights.

However, I vaguely remembered a snippet of information, that when used as a photodiode, an LED is sensitive to wavelengths equal to or shorter than the colour it emits.  I'd been using red LEDs which would thus be sensitive to most visible light, whereas I think most indoor bulbs are weak at the blue end of the spectrum. So I bought some blue LEDs for comparison.

The blue LEDs still provide a strong signal from overcast daylight, but seem to be almost totally immune to room lighting from incandescent bulbs.  A room lit by LED bulbs has a small effect,  but probably at least an order of magnitude less interference than before.   What remains to be seen is whether the blue LEDs are more affected by cloudy sunsets vs clear skies.  I wait with interest to see.   :-\

Only problem is, I began this project on the basis that
Quote
It would consist of a photocell, a microcontroller, and an LCD  character display.   All of these are conveniently to hand, residing in a drawer labelled “bits & bobs”

I'm now going ahead with a different PIC, a different LCD, and different photocell.  Is anybody familiar with Trigger's broom? :D

Logged

sevenlayermuddle

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5347
Re: New project, A Clock
« Reply #74 on: December 18, 2020, 05:56:21 PM »

The blue LEDs show promise.  After a full sunrise/sunset cycle with blue LED, clock display synchronised just 12 seconds adrift  from  timeanddate.com prediction, for my location.  And it seems completely immune to toggling on/off room lighting in my test location, even around sunset/sunrise. That accuracy is undoubtably a little bit of a fluke, but encouraging all the same.  :graduate:

I’ll probably stop updating this thread for a while as development is likely to be suspended during Christmas festivities, and I’ve an awful lot of code(/bugs) to write to move it forwards.  But if it ever does evolve from ‘breadboard prototype’ to ‘production candidate’, I might update again.

Thanks for all support & encouragement. :)
Logged
Pages: 1 ... 3 4 [5] 6
 

anything