[GreenKeys] Mystery RTTY Project

[Harold Hallikainen]

Good analysis! I agree that the "framing error" results in the shaft
continuing to rotate and go onto the next character. With a valid
character, I'd EXPECT (but do not know) that the shaft would stop rotating
11 ms into the stop bit (center of a 22 ms bit time, even though the stop
is usually 31 ms long). If there is an invalid stop bit (space), it would
"roll into" the next character with the start bit starting 11 ms after the
end of D4. It would then sample D0 33 ms later (22 ms for start bit and 11
ms to center in D0).

The software UART (
https://github.com/HaroldHallikainen/DSP_TU/blob/master/src/BaudotUart.c )
in my DSP TU (https://w6iwi.org/rtty/DspTU/ ). Detects the mark to space
transition for the beginning of the start bit and checks it again 11 ms
later to make sure it was a good start. If so, it then samples the input
every 22 ms to pick up the data bits. After the last data bit, it samples
another 22 ms later for the middle of the stop bit. If the stop bit is not
mark, it increments an error counter. I'm planning on reporting a ROUGH
error rate by comparing bad stop bits to good start bits.

By the way, I've started assembly of the DSP TU PCB (
https://w6iwi.org/rtty/DspTU2/ ). After soldering a few 0603 resistors
with a soldering iron, I ordered a hot air solder station and solder
paste. That should be here Monday.

Harold
https://w6iwi.org




On Sat, July 8, 2023 7:06 pm, Jones, Douglas W wrote:
> From: Harold Hallikainen via GreenKeys [greenkeys at mailman.qth.net] --
> Saturday, July 8, 2023 5:49 PM
>
>> So, it seems like we'd get framing errors on a square wave
>
> Mechanical asynch receivers like TTYs don't detect framing errors, nor do
> they much care about them.
>
> Here's what I would have expected.
> 1 --- idle line
> 0 - start
> 1 - D0
> 0 - D1
> 1 - D2
> 0 - D3
> 1 - D4
> 0 - stop (framing error, but note*
> 1 --- idle line, note **
> 0 - start
> 1 - D0
> 0 - D1
> 1 - D2
> 0 - D3
> 1 - D4
> 0 - stop
> 1 --- idle line, note **
> 0 - start
>
> Note*: yes, a framing error, but the TTY doesn't care, it's simply
> insensitive to the state of the line for about 31 ms
> Note**: for 9 ms, the line is ignored as part of the stop bit, the
> remaining 13 ms of this 1 bit are seen as an idle line.
>
> The net result?  I wouldn't have expected RYRYRY, I'd have expected RRRRRR
> from just a square wave.
>
> Unless what is happening is the following:
> 1 --- idle line
> 0 - start
> 1 - D0
> 0 - D1
> 1 - D2
> 0 - D3
> 1 - D4
> 0 - stop also sensed as a start bit for the next character ***
> 1 - note ****
> 0 - D0
> 1 - D1
> 0 - D2
> 1 - D3
> 0 - D4
> 1 - stop (not a framing error)
> 0 - start
>
> Note***: framing error, clutch remains engaged, shaft continues to spin.
> Note****: 0-1 transition was 9 ms before expected end of stop bit, too
> little time for it to matter.
>
> This would give RYRYRY, but it would probably be rather sensitive to the
> rangefinder setting.  I'd expect the RYRYRY to sound a bit syncopated,
> that is, more like RY RY RY RY (not printing spaces, but a little off in
> the timing).
>
>           Doug Jones
>           jones at cs.uiowa.edu
>


-- 
https://w6iwi.org