[time-nuts] IRIG-B audio decoder circuits and ICs sought

[Joseph Gwinn]

Multiple answers interspersed below.  Joe

On Fri, 22 May 2015 12:00:02 -0400, time-nuts-request at febo.com wrote:
> Send time-nuts mailing list submissions to
>> 
> Message: 5
> Date: Thu, 21 May 2015 22:22:12 -0400
> From: Joseph Gwinn <joegwinn at comcast.net>
> To: time-nuts at febo.com
> Subject: Re: [time-nuts] IRIG-B audio decoder circuits and ICs sought
> Message-ID: <20150521222212517328.ec5ebcdf at comcast.net>
> Content-Type: text/plain; charset=us-ascii
> 
> Multiple answers interspersed below.  Joe
> 
> On Wed, 20 May 2015 10:04:19 -0400, time-nuts-request at febo.com wrote:
[snip]
> ------------------------------
> 
> ------------------------------
> 
> Message: 7
> Date: Thu, 21 May 2015 22:50:46 -0700
> From: Hal Murray <hmurray at megapathdsl.net>
> To: Discussion of precise time and frequency measurement
> 	<time-nuts at febo.com>
> Cc: hmurray at megapathdsl.net
> Subject: Re: [time-nuts] IRIG-B audio decoder circuits and ICs sought
> Message-ID:
> 	<20150522055047.020C7406057 at ip-64-139-1-69.sjc.megapath.net>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> joegwinn at comcast.net said:
>> I recall that there are audio files with real IRIG-B12x signals in  them,
>> for testing.  Does anyone recall where these files are? 
> 
> There is a program in the ntp package that generates IRIG audio from the 
> local system clock.  It says IRIG-B, but I don't know about the 12x 
> part.  A 
> comment in the code says "1000 Hz".
> 
> It's util/tg2.c

How do I get hold of the code?  Is it in the NTP distribution, versus 
all by itself somewhere?



> ------------------------------
> 
> Message: 9
> Date: Thu, 21 May 2015 21:58:14 -0700
> From: Chris Albertson <albertson.chris at gmail.com>
> To: Discussion of precise time and frequency measurement
> 	<time-nuts at febo.com>
> Subject: Re: [time-nuts] IRIG-B audio decoder circuits and ICs sought
> Message-ID:
> 	<CABbxVHtKxESvaoR6KCRAiCFC0Ln5dmdj9JPTqhpRR3zRNYZNOQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> I remember the need to use assembly also.  But those days are gone for
> two reasons (1) modern optimizing compilers are so good that they can
> beat hand written assembly.  and (2) Today CPUs are cheeper than
> software engineers.  Back in the 70's it was the other way around.

It is not true that compilers can outdo skilled assembly programmers, 
because skilled programmers can use the oddball machine instructions 
that compiler writers ignore.

Like triple-indexed remote execute (SEL 32/55, cloned from IBM 360 or 
the like).  Really good for N-dimensional tables of action routines.

But you are right about the tradeoff between machine cost and 
programmer cost.  That is what caused most embedded realtime to go to 
C/C++.  Although there have been cases where a little bit of assembly 
language was needed, typically in the form of a C-callable 
assembly-coded function.


> And NO, using C is hardly "being modern".  Maybe C++ is still "modern"
> in some circles but today we have Python, Swift and 50 others.  C (or
> more likely C++) while still widely used is kind of "old school".

Modern compared to the old days, where it was iron men in wooden 
ships.  

In the embedded world, C rules.  C++ is too big and too heavy.


> The last assembly I had to write was parts of the OS for a CDC
> mainframe (PPU code for a 6600)

Same era, different machines.

 
> OK back on topic:  How to process IRIG.    Can't you mix it down to
> baseband with a local oscillator, mixer and filter?  It's AM on a very
> low frequency carrier.

That is a standard approach, and goes by the name "product mixer".  
Feed IRIG signal to a hard limiter, lock a phase lock loop (PLL) to the 
resulting square wave, multiply the PLL output and the IRIG AM 
together, to yield the modulation (difference signal) and 2 KHz ripple 
(the sum signal).  Use a notch filter to eliminate the 2 KHz signal.



>> To be modern, one must code in C?  Isn't that true?
>> 
>> (Don't tell anybody, but I was an assembly-language programmer back in
>> the 1970s.  In those days, assembly was the only way to get sufficient
>> performance given the slow iron of the day.  Out main programs were
>> about 70,000 lines each.  The assembler took all night to ingest all
>> that.)

The machine was that SEL 32/55. Your smartphone is faster.

> 
> End of time-nuts Digest, Vol 130, Issue 32
> ******************************************