Well, I did it – what I’ve been trying to accomplish for some time now. I have a “live” decode of IRIG-B to my little 5×7-character-based LCD display.

Pulling Threads

I created two new threads in my read_irig program.

One thread reads the keyboard, looking for single character commands:

q: quit read_irig
d: show decoded data
r: show raw data 3 lines at a time (60 bits at a time), and if raw data already showing, reverse the bit sequence
t: show raw data 1 line at a time (20 bits at a time) with header, and if already showing, reverse the bit sequence
u/l: move between windows of present format up/down (e.g. show next or previous 20 bits of raw data)
h: freeze the display at the present time

The second thread takes a full structure of present time data and displays it on the screen, in accordance with the present format and situation.

Displayed Output

Decoded Display

Decoded Time Display, showing decoded date, day of year, time of day (HH:MM:SS and straight binary seconds in hex)

Decoded Data Second Page, showing format, gain and amplitude of signal

Raw Display

Raw Data Second Page, showing chips 40 to 99

Reversed Raw Display

Reversed raw display is convenient because the bits are arranged from most significant (MSB) to least significant (LSB) from left to right, which is convenient for most people to read.

Reversed Raw Data, showing chips 99 to 40

Reversed Raw Data Second Page, showing chips 59 to 0

Timeout/Searching for Signal Display

Timeout Indication, showing blanked out data, presently searched-for signal type, gain and amplitude of signal

What’s Next?

I was thinking that I might introduce a third display mode, that of raw data with headers, more like the console output of read_irig:

#
#--------------------------------------------------------------------------------------------------||------------------------------------------------------------|
#           Normal Unmodulated IRIG-B Raw  (noninv audio)  (Gain  93 giving  +1.0 dB)              ||   Normal Unmodulated IRIG-B (noninv, gain  93 ->  +1.0 dB) |
# StrtBinSecs (SBS) |    Control Bits   |   Year  |    Day of Year    |  Hours  | Minutes |Seconds ||Day|   Date and Time    |SBS hex|Leap| DST |Offset|Qual|Par |
# ........ .........|......... .........|.... ....|       .. .... ....|  .. ....| ... ....|........||...|.... .. .. .. .. .. | . ....|....|.....|......|  ..|....|
#                   |                   |         |                   |         |         |        ||   |                    |       |    |     |      |    |    |
.001010101.010111101.000100000.010111000.000101001.000000001.010000000.000100010.000001000.01001001. 140 2019-05-20 12:08:29   0_AABD !lsp  DST  UTC-05   00 1 ok 
.001010101.010111110.000000000.010111000.000101001.000000001.010000000.000100010.000001000.01100000. 140 2019-05-20 12:08:30   0_AABE !lsp  DST  UTC-05   00 0 ok

And Then, and Then!?!

You think that would be enough for me? Well, apparently not! read_irig takes very little computing power, so it could easily run on a smaller processor… say, an ARM… on a Raspberry Pi, or a Beagleboard – then it could be made portable. I have two Beagleboard Blacks and like them. The problem here is that none of these boards have easy audio input ports, like my laptop. Some do have ADC inputs, but they need to be protected, amplified, provided with a jack, etc. Hmm, have to think about this.

Almost every device these days has an I2C port, so there shouldn’t be much trouble there.

IRIG2LCD()