Author: Tom Zicarelli

notes

After a few vexing timing issues I have been able to send and decode RTTY (technically AFSK audio frequency shift keying ) in Max at 300 baud. Click hear to listen to an example of a 13 word message at 300 bps (300 baud)

The js object adds significant delays (on the order of a few milliseconds) – so I replaced the encoder with a coll and that cleaned up the timing problems when encoding. This patch demonstrates the issue:

Also… You can use threshold~ instead of snapshot~to feed binary pulse amplitude detection logic into edge~ – but you need to run the signal through average~ to prevent the amplitude from repeatedly dropping to zero at the signal frequency. Like this:

Is it better than snapshot~? it seems to be, but who knows – at these speeds it would probably be better to write the whole thing in gen~

There are a few other things – like using counter~ instead of phasor~ to drive the decoder clock. This allows you to restart the clock, when the onset of the start bit is detected – and you can add a variable amount of delay to find optimal point in the signal vector to read the pulse. At 300 bps, at 96k SR, each pulse is 320 samples (3.1 milliseconds) –

I’ll write more on this later –

The Katja Vetter article on Beat-Slicing was helpful – along with several Max tutorials on Audio control rates, and envelope followers.

Local Patches are in;

tkzic/ max teaching examples/

• rtty-send10.maxpat
• rtty-recv9a.maxpat