I think I might do a Ham radio licence. I’ve been thinking about it for a few weeks. It might be fun. I’ve been thinking of experimenting with using DCS squelch codes for data transmission of character streams. It should be possible using the 83 codes available with easy mapping.

023@ 114N 205r+ 306lf 4110 503: 703sp
025A 115O 223r- 311′ 4121 506; 712!
026B 116P 226g+ 315( 4132 516< 723″
031C 125Q 243g- 331) 4233 532= 731£
032D 131R 244b+ 343+ 4314 546> 732$
043E 132S 245b- 346, 4325 565? 734%
047F 134T 251up 351- 4456   743^
051G 143U 261dn 364. 4647   754&
054H 152V 263le 365/ 4658    
065I 155W 265ri 371\ 4669    
071J 156X 271dl        
072K 162Y          
073L 165Z          
074M 172*          



This would be easy to integrate into a multipurpose app to connect on digital modes for a low bandwidth 300 baud signal at 23 bits per character. This would be quite reliable as a means of doing a more modern RTTY. Just leaves ` _ | and ~ in base ASCII to do later, with 20 (11-9) codes “free”. The 2xx and the 6xx lines. This gives the printable 63, and the 20 control characters with no print, along with a special control for inclusion in printing (dl for delete correction) for 83.

So the 2xx codes (non-destructive locators except “delete” the anti-time locator) are colour saturation and direction control with delete (which correction “time” dynamics perhaps in a 6-bit code), and the 6xx codes are where more complex things happen. A basis repetition rate for distance starts and the coding uses this as a basis to transmit on. So a basis of 16 repetitions means each symbol is sent 16 times, for a 1/16 data rate. 612 uses 2^n repetitions based on a log for the number of rp after the symbol to be repeated. 2, 4, 8, 16 … after rp, rprp,rprprp … 662 returns to a maximum basis of repetitions and attempts to reduce to keep the number of 627 messages down.

The basis and the use of 612 might lead to a 662 if the decoder is not in synchronization with respect to the basis of repeats. This basis is ignored on the higher-level code and is just a summation of noise to increase S/N by the symbol repetition.

606 sy – synchronous idle 
612 rp – repetition of x[rp]x or x[rp]x[rp]xx (7)
624 ra – rep acknowledge all reps in RX in TX
627 re – rep acknowledge with err correct as 624
631 ri – rep basis increase request (2*)
632 rd – rep basis decrease request (2/)
654 ok – accept basis repetition count by request
662 un – unsync of repetition error reply (max)
664 cq – followed by callsign and sy termination

This allows for a variable data distance at a constant rate especially if the RX has a sampling of code expectation and averaging over the number of symbol reps. It also synchronizes the start of many DCS codes but would reduce the speed of lock to need the code aligned.

Extended codes could be used to extend the coding to include other things. This is not necessary, and 83 symbols are enough. This is a good start, and extras are fine though. Even precise datarate coding lock would give better performance over DX at high repetition basis.

A modified form of base64 encoding along with digital signatures (El Gamel?) could provide good binary 8-bit transmission, and block reception good certainty. A return of the good signature or the false signature on error makes for a good block retransmit given a simplex window size of 1. In this case, synchronous idle would be a suitable preamble, and the 2xx and 6xx codes would be ignored as part of the base64-esque stream (except 606 for filling in empty places in the blocks of 5 in the base64 code).