Scribble Text or Hell display on waterfall

This is a mega16 AVR program. Scribble Text (multi_tone Hell), sends characters for display
on waterfall. One of 7 tones is sent (one a time). The carrier is always on and is shown as
inter-letter underline on the waterfall. 

This sends Hell type characters as a varying carrier frequency. Each character is comprised
of pixels within a 5x5 matrix. Some characters are narrower and take up less pixels in the x
direction. When there are no pixels in the column at all, the D/A output value is 001 for a
carrier offset of 0 Hertz. If the lowermost pixel of a column is part of the current character,
the D/A output value changes to 010 (or 2); this then becomes carrier offset of +50Hz. However,
if the lowermost pixel isn't required but the pixel immediately above is, the D/A output changes
to 011 (or 3) for a carrier offset of +100Hz. So this differs from Hell in that unused (or blank)
pixels aren't sent; there are no breaks or pauses in the transmitted carrier.

The underline (D/A code 001) is sent for 200mS (100mS if b1=0) between characters, or for 4
columns duration for space (0x20) character.

The time duration of each column is 100mS, if there are four pixels to be sent in the column, each
pixel lasts 25mS. And if there were only three pixels to be sent in the column, each would be sent
for 33mS. So when viewed on waterfall display, the columns of pixels can be seen to slope from
lower left to upper right. The characters represented can, with interpretation, be read directly
from the waterfall display. Some characters such as 'M' and 'V' don't really work out that well
and perhaps the program could be modified a little to recognise these difficult characters as
special cases and send the columns slightly differently?

Above with pB0=1 (about 1 sec/char)
And with pB0=0 (about 1.5char/sec)

This mega16 circuit is much the same as the keyr circuit. But an D/A circuit is added from the
lowermost bits of portA. This D/A is intended to move the frequency of a crystal controlled
oscillator by about 50Hz for each D/A count.
D/A with series and parallel combinations
Voltage steered xtal oscillator. When the uP switches an output to '1' level, that output pin is
effectively connected to the supply rail. The capacitor at the D/A output is intended to prevent
power supply noise making its way to the varactor, a small value of 10n or 4n7 is best. Although the
D/A output (with b2=1) is never below 001, perhaps the resistor shown from D/A output to ground
should return to +5v to ensure the diodes are always biased. A more precise way of arranging this
circuit is to use 7 resistors (the selected resistor as output, the others as inputs). Or by using three
diodes from pA2..pA0 to switch in three capacitors. But this simpler circuit can be improved by making the
lowest value resistor adjustable.

port bits & directions

     lowermost 4 bits outputs; (msb) b2,b1,b0 (lsb) are D/A output drive pins
     b7..b4 are inputs
 portB (mode select pins):
     b4...b0 are inputs
     b7...b5 are outputs
     all bits are outputs except for b1 (input pin for bootloader if used)
     b0 pulses high at start of character (for 'scope trigger)
     all bits are inputs except for b1 and b4 and b5 and b7
     b0 UART serial 9600 input with 8Mhz xtal
     b1 UART serial 9600 output with 8Mhz xtal
     b4,b5 are test only tones, in quadrature
     b7 is 500Hz test output (xtal/16000 with !SLOW=0, see mv3)
mode select (portB), these inputs are usually at '1' level
  ; b0 LSB is normally '1' for repeat send column pixels
  ; b1 is double speed when '0' (50mS columns instead of 100mS) (changed for mv3)
  ; b2 is fixed time/pixel when '0' (50mS fixed time, or 25mS with b1='0')
  ; b3 is 0 for invert D/A when '0'
  ; b4 echo send character to serial/prog mode, set '0' to program message
    notice that b4 is latched at device reset.
    The firmware shows b2..b0 value as decimal mode number, a miniature bcd switch can be used at
    pins b2..b0 instead of DIP selector.
A simple program was written to design the characters and at the lower right can be seen the
character plotted with columns that slope from lower left to upper right.
(The numbers at the top of each column are the count of pixels for that column, these are used
to adjust the time of pixel widths).

The lowermost bit of portC is an output that pulses to '1' level at the beginning of each character.
This can be used as trigger for 'scope to show current character on display (the D/A values).
But I could only get it to display with b0=0 and b1=0 (that's the letter 'A' at 50mS/div, and
since b0 and b1 are both 0, 50mS/column).

The pictures at the top (MSHV) are from the test tone on pD4,pD5. AVR source
shellmv.hex AVR object for sending Ms and Vs

Project updated:
shellmv2.hex AVR object for sending Ms and Vs, (still working on this):
The font design program was reworked (this is android  basic program) needs large screen.
This time the top of each column shows the direction of plot for the column pixels. Also, six pixels are shown for each
column. For five pixels the on time per pixel is 100ms/5 or 20mS. It didn't seem a good idea to lower the pixel time below
this. So while six pixels are available, a maximum of five is used (anywhere within the column) to maintain the 100mS/column]
across all characters.

This is 100mS/div with b2=1,b1=1,b0=0. Each column is 100mS*, and the pixel widths have been adjusted to fit. Compare this
with the letter A in the picture below. The longer pixels show more brightly; perhaps the waterfall colours should indicate
frequency offset from maximum bins instead?

from Spectran (average=off) with b2=1,b1=1,b0=0 (audio test tones), columns with single pixel only are sent in 75mS.
The @ and the $ are six pixels high. [Even so, these two characters are hard to find in the picture. This suggests
this communications scheme is unsuitable for the transmission of email messages or financial tickers].

The character font tries not to have only a single pixel on in either the first or last columns. The actual display
varies a great deal with waterfall program settings, perhaps an automatically adjusting waterfall display is best
for testing this. Maybe the waterfall display could use the interletter underline as AGC level for pixel ON/OFF
detection?. Or perhaps 'operator skill' (see Ham Radio) is required.dc.wav 44100 mono repeat column mode.
[Keep the volume low on that .wav. Otherwise you might hear the /!? tone sequence many hours afterwards!] 

pA3 toggles for each column and might allow for a frequency dither between columns. Also, shellmv2 toggles pC4 for each
message, so pC4 could be connected to a pB bit to test between two different settings.
 repeat columns 
double (repeat) column mode with b0=1, (Spectran with average off; this might be work for financial messages?). Not much
chance that B gets confused with 8 [maybe with a & though]? Notice the slope of the right side of A.

After spending more than a few hours on this, it was clear that columns that have a single pixel only must be sent in a
shorter time (75mS and not 100mS in the picture above*. Especially with repeat column mode; the 50mS single pixel is repeated
for a total of 100mS. Compare the W characters of shellmv and shellmv2 in repeat column mode to see this improvement).
This is a pity since it doesn't allow for fancy noise rejection based on known column timing. So now noise rejection should
depend on the frequency on the interletter underline and the detection of the active bins within the waterfall. The spacing
of tones for this system can't be specified exactly since the transmitter might use the steered xtal oscillator with offsets
that makes exact frequency offsets impossible to implement. This noise rejecting waterfall might be more useful if the number
of expected tones (or frequency range) could be set by the user; so it would work with two or three tone QRSS as well.
Notice that on VHF there isn't the delayed multipath signal found on HF. On HF, this delayed signal can cancel out or produce
a false pixel. However with 20mS pixels, propagation effects can be observed directly.
Beacon status notification
left QRV char x27 and right QRU char x60. pA7 input selects between these two beacon status characters when a ^ character
is in the message buffer, this allows propagation or operator status to be indicated in the beacon message.

Project updated to mv3:

!TILT= was added, (TILT can be 0...+/-3)
 5Hz tilt 
here each column is 5Hz higher than the one before. (This only for the pD4,pD5 audio. For the D/A, something from pC0 would be
needed). Now if only someone had thought about delaying their bins 20 years ago...

The switch on pB1 selects between variable time per column (b1=1 normal case) or fixed time/column when b1=0.
This picture is with b0=1 so times are doubled; on the right 100mS columns are repeated for 200mS total and  columns with only
a single (50mS) pixel are repeated for 100mS total:
On the left is b1=0 and on the right b1=1 (normal case). The columns with single pixel only are wider on the left. If the switch
b2=0, then the b1 switch setting is ignored (all pixels are then 50mS wide). [With b2=1,b1=0,b0=1, the receiver might compare the
received data to that of 100mS previously. This could be combined with TILT?].

mode  pB2 pB1 pB0  single pixel time,  column time
   0    0   0   0     50mS                    
   1    0   0   1     50mS                                       repeat column
   2    0   1   0     50mS       	   		    
   3    0   1   1     50mS                                       repeat column
   4    1   0   0   20,25,33,50,100mS     100mS                 	
   5    1   0   1   20,25,33,50,100mS  100mS+100mS               repeat column
   6    1   1   0   20,25,33,50,75mS   100mS or 75ms*   
   7    1   1   1   20,25,33,50mS  -   100mS+100mS or 50mS+50mS* repeat column (selected with no switch installed)
   *if there is only a single pixel in the column or no pixel in the column, column time reduced
[All this b2,b1,b0 is simplified either by using the BCD switch and dialing up best results or by leaving out the switch altogether.
The program configures unconnected inputs as '1' with pullup resistors internal to uP. A jumpy on pB4 is needed to select between
programming and beacon modes however].

!SLOW= was added, here with !SLOW=4 (pD7 becomes 15.625Hz) from ARGO: 
This is 32 times slower, so the 200mS (repeated; 100mS+100mS) columns each take 6.4 SECONDS.
Tones are 4Hz apart: 1499.8Hz, 1503.7Hz,  1507.7Hz  1511.7Hz,  1515.7Hz,  1519.7Hz,  1523.8Hz
To change the xtal oscillator frequency by 4Hz, either breathe on it or adjust the supply voltage a little. 

The spectran pictures show 350Hz with 5.9Hz bins or 60 bins. The Argo picture shows 28Hz with 0.366Hz bins or 76 bins. So there
doesn't seem to be any advantage the slower speed? Unless time is considered. Because since the data is 32 times slower, the
filtering for the slower system is able to provide a 15db improvement by having a filter with frequency 32 times lower for the
waterfall display. 

!SLOW=1 is 2* 100mS speed, !SLOW=2 is 4* the 100mS speed, !SLOW=3 is 8* the 100mS speed, and !SLOW=4 is 32* the 100mS speed.
Reset to 100mS with !SLOW=0

!SAVE saves the message and the current CSET,TILT and SLOW values. Either TILT or SLOW, not both as same time:
shellmv3.hex AVR object for sending Ms and Vs, (still working on this some more)
here are some characters (friends for QRV and QRU) to try in cset2.asm :
A quick way to test a new character is with !CHAR=5,26,91,84,11,a6  Then type a ? to check. 
Then include a Tilde character in the message; this new character is always sent in single column mode with 100mS fixed time.

The capacitor at the D/A output; if too small a value is used there is a chance of some wideband noise on the output signal.
If the value is too large, there will be a traceback visible on the waterfall display (scribble text). A better approach is to use
a higher order of filtering between the D/A and the oscillator (that 10n value at the D/A output depends on D/A output impedance):
The LM358 has input and output voltage ranges that include 0v. Notice that the cutoff frequency of this filter must match the !SLOW
setting (must match pixel rate). The cutoff frequency depends on the 100k values; doubling both values (to 200k and 200k) would halve
the cutoff frequency to 250Hz. To double the cutoff frequency to 1Khz leaving the 100k's for a high impedance, halve the capacitor
values; so the 3.7nF becomes 1n8 and the 2n7 becomes 1n2. [This filter was designed for d=1.73 so as to maintain phase]. If all else
fails, consider two xtal for the oscillator; one for the oscillator and one as a filter.

This is essentially an analog communications scheme. It doesn't require a minimum signal level (or BER) before it begins to operate.
This is at the expense of image quality; digital systems produce an exact copy (with no loss of quality) of the original data. Like
the system you are using right now.

The communications scheme detailed here requires the operator to provide the final 'processing gain' to reconstruct the original
data (the image). You would only need a few parts of the message to work out what it was; you'd have information the digital system
wouldn't have. 

 test message 

Windows x86 program (tested with xp,w7 win32) to display the dc.wav audio as sideways waterfall (version 1.057)
Use Windows 'turn features on/off' to install .net runtime if needed
.zip MD5 72 50 15 AD ED 45 77 25 86 6D B6 8C DA F3 A5 5E

back to Metrcal54