Open source timing software. - Page 31
Like Tree119Likes

Thread: Open source timing software.

Page 31 of 32 FirstFirst ... 21 22 23 24 25 26 27 28 29 30 31 32 LastLast
Results 301 to 310 of 314
  1. #301
    Member
    Join Date
    Nov 2016
    Posts
    36

    Re: Open source timing software.

    Yes, I read that post about calibration procedure. Idea is to take quartz watch as reference and compare it to sound card, because sound card is not so accurate (also described in that post). I'm just little confused about mentioned "correction procedure" of quartz watch, because it goes usually fast +10 s/day. So what is the real accurate reference? What is the result of calibration procedure ? Is it diff between quartz clock and sound card clock?
    If so, we can use digital metronome too, they are declared as accurate, they usually have audio output, adjustable beat rate etc...
    The reason I'm talking about whole this stuff is:
    conventional timegraphers are usually calibrated in factory to same reference timing source, so they will all have very similar results. They also have same sound pickup method, so inputs in state machine are pretty solid, right? So you can expect similar results with some small error rate...
    TG is excellent idea, ingenious algorithm, it should be used to it's limits. If we don't have sort of standardized pickup and time reference, we can not compare results precisely, right?
    I'm thinking of running it on dedicated platform (RPI3 with some Linux, even better try would be Android tablet (ARM or x86) with some Linux distro), so now I'm picking up best practice tips regarding sound pickup and calibration.
    I know it can be done via GPS, for example, have to study it in more details... But I think it would be overkill, because result values are not in that precision range as GPS time reference.
    Building some stable oscillator reference would be "long road" too, even if I'm sure there must be some ready modules out there... So I'm trying to get best effort reference.

    Pretty much we have excellent product here... Imagine you can have this software running on some embedded platform (like RPI or similar). It is affordable, you know what is "inside", it is upgrade-able etc.
    So, open questions like sound pickup and calibration would be 99% of that road.
    I' not speaking about price. If you compare price of RPI+Sound Pickup+Some Display+Miscellaneous stuff, it is similar to cheap timegrapher machine from Far East... But it is huge difference if you build it, you can debug it, upgrade, service etc... Not to mention contribution of members of such a large community of watch hobbyist and enthusiasts.
    Thank you, please share your thoughts.

  2. #302
    Member
    Join Date
    Sep 2015
    Posts
    77

    Re: Open source timing software.

    First, many thanks to dmnc for the mac installer!

    Djolemag makes many good suggestions, for which I am very grateful. Let me express my opinion on them one by one...

    Quote Originally Posted by djolemag
    1. Start/stop/pause/restart features : very convenient when you change the position of watch, so false/error readings (during change of position) are not written
    This one is not complicated to implement. I'm trying to evaluate whether it would be an really needed. The most straightforward way to keep track of various position is to time them separately (hitting clear between one and the next), make one snapshot per position, and then save all the snapshots together in the same file using the "save all snapshots" option. Notice that you can name snapshots, so you can call them with the name of the respective positions.

    Quote Originally Posted by djolemag
    2. Someone already mentioned lift angle in decimals... I know it will not cause too much errors, but maybe to reconsider adding it
    It mostly boils down to what you find less annoying. Without decimals, it's quicker to adjust with the up and down arrows (ten times less clicks for equal adjustments). With decimals, you have the peace of mind that if your movement is 51.4 you can set precisely 51.4. Technically, those 0.4 degs do not make any difference at all. Possibly the best solution is to allow decimals and program the arrows to jump by integer steps (those who want decimals still can enter them via keyboard). I will put this on the todo list.

    Quote Originally Posted by djolemag
    3. Screenshots are really nice feature. One or two textboxes on mainscreen for comment would be great, so you can add what watch you measured in what position.
    The name of the snapshots is editable, and allows you to do precisely that. You suggest a larger text area?

    Quote Originally Posted by djolemag
    Also, have you though of putting timestamp on screenshot, very convenient feature?
    Great idea. This is definitely near the top of the todo list.

    Quote Originally Posted by djolemag
    4. Printing ... AS I understood, it is in TODO list... My opinion is that it should have only measured values and paper graph - dots. Finally, it is enough to print it into PDF, then everyone can print it to physical printer if needed... Very common way for many diagnostic equipment.
    Yes, that's more or less how I envisage the printouts. It's a lot of code to implement, that's why it is not yet there. The move to GTK+3 of the latest version will allow me to merge some code from an old pull-request of a GitHub user named wahlstedt (I think he is also a member here) that implements a prototype for printing...

    Quote Originally Posted by djolemag
    Also, I've seen a lot of people are using piezo microphone with amplifier.. So it is not a general problem, but I couldn't figure out about audio input: should be stereo or mono? If stereo, I have to wire it in parallel to get same signal on L and R channel?
    I'm strongly for piezo pickup because reduction of environmental noise...
    For now, tg takes the default audio input and makes the average of the two stereo channels. Selection of audio input is also something that needs to be improved in tg, and there is also material in this direction in wahlstedt's pull request.

    Finally, I completely agree with alvh on this.

    Quote Originally Posted by alvh
    That's not completely correct etc.
    Tg is just a comparator that, indirectly, checks a mechanical watch under test against a reference quartz watch, using the clock of a sound card to transfer this information. It's like weighing an apple against a kilogram weight by first using the weight to calibrate a scale and then using the scale to weigh the apple. A quartz watch is usually good enough for the job, unless you seek the very ultimate haute horologerie kind of precision.

    One last note. Snapshots are not just screenshots. The format is actually numeric, this means that if you see a snapshot on a tg window of a different size, or even on a different computer running a different operating system, the snapshot will still look, in a sense, as good as new. More importantly, when we finally have printing, all snapshots even taken today will be pretty-printable by just loading and hitting "print".

  3. #303
    Member
    Join Date
    Sep 2015
    Posts
    77

    Re: Open source timing software.

    Quote Originally Posted by djolemag View Post
    Yes, I read that post about calibration procedure. Idea is to take quartz watch as reference and compare it to sound card, because sound card is not so accurate (also described in that post). I'm just little confused about mentioned "correction procedure" of quartz watch, because it goes usually fast +10 s/day. So what is the real accurate reference? What is the result of calibration procedure ? Is it diff between quartz clock and sound card clock?
    If so, we can use digital metronome too, they are declared as accurate, they usually have audio output, adjustable beat rate etc...
    Sorry, this post came while I was writing my other post...

    So quartz watches are very accurate and by design often they achieve this accuracy in a slightly counter-intuitive manner. The quartz crystal in them is made to go fast, each individual crystal is characterized at the factory, and the specific watch is programmed to apply a periodic correction which is precisely equal and opposite to excess speed of the quartz. The result is very accurate, but, because of the periodic correction, the trace does has this zig-zag shape that you see in the figure of my calibration post. This is also the reason why the calibration procedure needs to be a little long: to average the zig-zags.

    I have no experience with metronomes. Watches are designed for long-term stability: to keep time accurately for long. Metronomes, being designed for the music, I would guess are not necessarily engineered for accurate time-keeping at the part-per-million level. Clearly, the ultimate time reference would be the 1PPS from a GPS receiver, and, as you say, that's definitely overkill.

  4. #304
    Member
    Join Date
    Nov 2016
    Posts
    36

    Re: Open source timing software.

    Thanx for quick answer, let me elaborate my idea in short as possible.


    Djolemag makes many good suggestions, for which I am very grateful. Let me express my opinion on them one by one...



    This one is not complicated to implement. I'm trying to evaluate whether it would be an really needed. The most straightforward way to keep track of various position is to time them separately (hitting clear between one and the next), make one snapshot per position, and then save all the snapshots together in the same file using the "save all snapshots" option. Notice that you can name snapshots, so you can call them with the name of the respective positions.
    Haven't thought of it in such way, good point.
    However, I mentioned in some previous post, if we go in "blackbox" design way, it is good to think about start/stop/pause feature. Personally, if I have to implement it on some RPI (which was my first thought :D ), I would also hook few GPIO pins with these button actions in mainthread. In that way I would need almost no action from keyboard/mouse. Also, if I put it to run on Linux distro on some tablet-like device, I have full benefit of touchscreen, so I can start/stop/pause routine without much GUI complications....




    It mostly boils down to what you find less annoying. Without decimals, it's quicker to adjust with the up and down arrows (ten times less clicks for equal adjustments). With decimals, you have the peace of mind that if your movement is 51.4 you can set precisely 51.4. Technically, those 0.4 degs do not make any difference at all. Possibly the best solution is to allow decimals and program the arrows to jump by integer steps (those who want decimals still can enter them via keyboard). I will put this on the todo list.
    This is good idea, very efficient. Default step by arrows is One, decimals must be entered separately. in "blackbox" design, I would add decimal spinner, for example... But honestly, it complicates GUI...


    The name of the snapshots is editable, and allows you to do precisely that. You suggest a larger text area?
    My suggestion was like this:
    Add one (or two) text fields for user input. If user want, can edit them. By default, they are blank (or timestamp...). So, me as user, I can add title "Omega Seamaster ....." in first field, "DU" as DialUp testing position.
    Now, when you take snapshot, you have all relevant data to pull from screen and perform auto-naming of snapshot....
    In bottom line, very similar, but user has less intervention. In mathematic way, it is sort of optimization / minimization, you type name only once per session, changing only watch position....

    Great idea. This is definitely near the top of the todo list.



    Yes, that's more or less how I envisage the printouts. It's a lot of code to implement, that's why it is not yet there. The move to GTK+3 of the latest version will allow me to merge some code from an old pull-request of a GitHub user named wahlstedt (I think he is also a member here) that implements a prototype for printing...




    For now, tg takes the default audio input and makes the average of the two stereo channels. Selection of audio input is also something that needs to be improved in tg, and there is also material in this direction in wahlstedt's pull request.
    Yes, I noticed that, also I've been reading some comments/conversation on Git regarding pull request and changes.
    Does it mean I can wire L and R channel in parallel when wiring mic?

    Finally, I completely agree with alvh on this.



    Tg is just a comparator that, indirectly, checks a mechanical watch under test against a reference quartz watch, using the clock of a sound card to transfer this information. It's like weighing an apple against a kilogram weight by first using the weight to calibrate a scale and then using the scale to weigh the apple. A quartz watch is usually good enough for the job, unless you seek the very ultimate haute horologerie kind of precision.
    Good, now is more clear. Honestly, I was little confused at first reading because I saw zig zag line. Now I see that calibration makes zig zag average, so everything is just fine.

    One last note. Snapshots are not just screenshots. The format is actually numeric, this means that if you see a snapshot on a tg window of a different size, or even on a different computer running a different operating system, the snapshot will still look, in a sense, as good as new. More importantly, when we finally have printing, all snapshots even taken today will be pretty-printable by just loading and hitting "print".
    Nice. So basically, you record data and interpret them via GUI interface. I've took a brief look of .tgj file, very good point. It represents "frozen" state of GUI in particular moment in time. Congrats! Much better than screenshot as .blob or sort of image.

    One kind note: My primary job makes me to read a lot of code each day, various platforms, languages etc. I work as senior technical consultant for some IT/electronic production company. So, 99% of day I read a code or projct demands, but I'm not in "good shape"of writing a code, maybe I'm loosing focus or I'm getting old... :D
    So, from that point of view, I know how annoying some "software/project changes" could be. From my perspective, I tried to filter all my "first snapshot" ideas and converge to something which could give real effort and improvement.
    Once again, I see your idea as brilliant and I'm very proud if I can add at least a tiny idea to improve software....

  5. #305
    Member
    Join Date
    Nov 2016
    Posts
    36

    Re: Open source timing software.

    Quote Originally Posted by contrate_wheel View Post
    Sorry, this post came while I was writing my other post...

    So quartz watches are very accurate and by design often they achieve this accuracy in a slightly counter-intuitive manner. The quartz crystal in them is made to go fast, each individual crystal is characterized at the factory, and the specific watch is programmed to apply a periodic correction which is precisely equal and opposite to excess speed of the quartz. The result is very accurate, but, because of the periodic correction, the trace does has this zig-zag shape that you see in the figure of my calibration post. This is also the reason why the calibration procedure needs to be a little long: to average the zig-zags.

    I have no experience with metronomes. Watches are designed for long-term stability: to keep time accurately for long. Metronomes, being designed for the music, I would guess are not necessarily engineered for accurate time-keeping at the part-per-million level. Clearly, the ultimate time reference would be the 1PPS from a GPS receiver, and, as you say, that's definitely overkill.
    Now is more clear, thank you. I have to think loud, please correct me if I'm wrong:
    In normal usage of 24h, mechanical watch will change many positions and variations of them (positions). So, it means that sum of slow and fast rates during the day will give some effort to final 24h result, in practice.
    Quartz watch does not have that problem. Maybe some temperature, humidity and battery level will have gain/impact on final 24 h result. That result would be better than on average mechanical watch. That makes a Quarty watch good enough for time reference.

    Using GPS is good idea, but it needs a lot of tweaks and job. Final effort is not so big, so yes, it is overkill... However, that brings me to some new idea.. I have some broken ARM tablets at home, working but wiht bad displays (kids ...) . So, if I think about it, it has:
    Audio input
    GPS (not sure, I think one have it)
    Enough CPU power

    So, getting some Linux distro on it would be perfect playground. If it has GPS, then it is feasible to to use pulses from it for time reference...
    I will post results if successful.
    Thanx, cheers!

  6. #306
    Member 1afc's Avatar
    Join Date
    Mar 2014
    Location
    Australia
    Posts
    479

    Re: Open source timing software.

    Quote Originally Posted by djolemag View Post
    Now is more clear, thank you. I have to think loud, please correct me if I'm wrong:
    In normal usage of 24h, mechanical watch will change many positions and variations of them (positions). So, it means that sum of slow and fast rates during the day will give some effort to final 24h result, in practice.
    Quartz watch does not have that problem. Maybe some temperature, humidity and battery level will have gain/impact on final 24 h result. That result would be better than on average mechanical watch. That makes a Quarty watch good enough for time reference.

    Using GPS is good idea, but it needs a lot of tweaks and job. Final effort is not so big, so yes, it is overkill... However, that brings me to some new idea.. I have some broken ARM tablets at home, working but wiht bad displays (kids ...) . So, if I think about it, it has:
    Audio input
    GPS (not sure, I think one have it)
    Enough CPU power

    So, getting some Linux distro on it would be perfect playground. If it has GPS, then it is feasible to to use pulses from it for time reference...
    I will post results if successful.
    Thanx, cheers!
    Hi djolemag

    I've been following this thread for a while but I still may have missed something so please excuse.

    However, my question is What are you trying to solve with a super accurate time source?
    It would appear to me that the calibration system works well and is not broken.

    My electronics skills are far less than yours and by all means go for it with this project but, if you have the capability, it would seem that a neat cheap preamp would be far more useful to the majority of users.

  7. #307
    Member
    Join Date
    Nov 2016
    Posts
    36

    Re: Open source timing software.

    Hi,
    idea is to have sort of standardized approach to sound pickup, that is why I ask about piezo mic and preamp. I tested TG with headphones and it works nice, however it must be quiet room in order to work efficiently. Therefore, my choice is piezo guitar pickup, will test it when I get back from vacation.
    About accurate time source: as I explained in previous post, I was confused about accuracy of quartz watch, now is everything clear.
    But, I like to have things straight... If I can use GPS module for free (like in tablet), why not to try?
    Main reason, to be honest : I have only one quartz watch and lot of mechanical watches :)

  8. #308
    Member
    Join Date
    May 2017
    Posts
    4

    Re: Open source timing software.

    Quote Originally Posted by djolemag View Post
    If I can use GPS module for free (like in tablet), why not to try?
    I was wondering how you are imagining this? Hooking up a GPS timesignal straight to the input of the PC's sound card somehow? Because, if you would route it via the tablet's audio output or something, you would introduce yet another unknown error source (the tablet's DAC)...

  9. #309
    Member
    Join Date
    Nov 2016
    Posts
    36

    Re: Open source timing software.

    Quote Originally Posted by alvh View Post
    I was wondering how you are imagining this? Hooking up a GPS timesignal straight to the input of the PC's sound card somehow? Because, if you would route it via the tablet's audio output or something, you would introduce yet another unknown error source (the tablet's DAC)...
    Well, idea is to do it from source code, not by physically routing PPS to sound card...
    As contrate_wheel explained in calibration procedure post
    As any computer program that emulates a timing machine, tg necessarily
    takes its time reference from the clock of the audio card of the computer.
    There is anecdotal evidence that audio cards have usually relatively
    stable clocks. However, unfortunately, these clocks are often affected by
    a constant deviation from true time, sometimes of many seconds per day. To
    correct for it, one must measure the deviation by comparison to a more
    accurate time source, and then inform the program of its value. With tg,
    this can be done either manually or through an automatic calibration
    procedure.
    ......
    The automatic calibration feature works by comparing any analog quartz
    watch (producing one beat per second) to the sound card. Operationally,
    you put a quartz watch on the microphone and then you click on the
    calibrate button.
    ...
    So, we have a sound card internal clock which has unknown accuracy. On the other hand, we have a quartz watch, beating 1 beat per second and we suppose it is accurate enough (and as we agree in previous posts, it usually is accurate enough for our needs).
    So, we still can get sound card clock and compare it to PPS of 1 pulse per second reference we got from GPS. That is usually achievable by standard gpsd daemon in Linux, haven't been looking to much, but is feasible for sure, with one constraint: if GPS module has PPS feature or not, which may vary from model to model.
    However, as i mentioned in previous post, it is worth to give a try... nevermind if result is success or failure, some other user will have useful info, to go or not to go that way in further research....

    Please correct me if I'm wrong, thank you for getting interest in this discussion.
    alvh likes this.

  10. #310
    Member 1afc's Avatar
    Join Date
    Mar 2014
    Location
    Australia
    Posts
    479

    Re: Open source timing software.

    Quote Originally Posted by djolemag View Post
    Hi,
    idea is to have sort of standardized approach to sound pickup, that is why I ask about piezo mic and preamp. I tested TG with headphones and it works nice, however it must be quiet room in order to work efficiently. Therefore, my choice is piezo guitar pickup, will test it when I get back from vacation.
    About accurate time source: as I explained in previous post, I was confused about accuracy of quartz watch, now is everything clear.
    But, I like to have things straight... If I can use GPS module for free (like in tablet), why not to try?
    Main reason, to be honest : I have only one quartz watch and lot of mechanical watches :)
    Sounds like quite a challenge so will be interesting to see your solution.

    Regarding piezo pickups etc, this thread has a bit of discussion that you might find of use.

    What microphone to use with tg Open Source Timing Software?

    I think the summary was if one is using a piezo then a pre amp looks necessary.

    Always interested to find better ways to use this great software.

Page 31 of 32 FirstFirst ... 21 22 23 24 25 26 27 28 29 30 31 32 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

    Similar Threads

    1. Open Source for Ambit
      By hal_c_on in forum Suunto
      Replies: 1
      Last Post: May 9th, 2013, 12:05
    2. Timing Machine software
      By zodiac in forum Public Forum
      Replies: 12
      Last Post: October 24th, 2009, 23:14
    3. BIBURO watch timing software users?
      By Av8tor1 in forum Watchmaking
      Replies: 15
      Last Post: April 27th, 2009, 22:30
    4. Open Source Watch Project
      By fstshrk in forum High Accuracy Quartz watches
      Replies: 4
      Last Post: April 5th, 2009, 07:26
    5. Great design software that is Open-source *free*
      By bfgreen in forum Watch Concepts & Designs
      Replies: 1
      Last Post: October 7th, 2007, 01:42

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •