[GreenKeys] The continuing M15 Saga

[Harold Hallikainen]

> It would seem to me, in these days of raspberry PIs and microcontrollers
> and such, that we could create something to deal with this. I can see some
> approaches as long as we use the (hard to find) Volpe board.  I wonder if
> we could reprogram the Volpe board to count the characters and insert the
> CRLFs and buffer the signal as required and not require anything else. I
> am not sure what can be done with the microcontroller on that board.
>
> I’m wondering if Eric Volpe or John Nagle have any ideas. Or anyone else
> out there who is an electrical engineer.
>
>
> Paul

I had to do "word wrap" in this product:
https://www.qsc.com/solutions-products/accessibility/usl-ccr-100/ . It can
display 32 characters per line of US characters, and 16 characters per
line of Asian characters. Ideally the movie studios would create the
caption files with the right number of characters per line, but sometimes
they don't. If the packet I received had more than 32 characters in a
line, the code would search back to find the last space before the 32
character point, then move the text down to the next line. Lines were
moved down unless there ended up being more than 3 lines (the limit of the
display). In that case, the line breaks in the file (it's XML with a Text
element for each line) are ignored and the text is just fit the best it
can.

I never got Asian text to wrap correctly, though. It's tricky in that the
text is encoded as UTF-8, so there is more than one byte per character,
and also there are not spaces between characters.

For RTTY, it would be nice if it were just transmitted correctly. But, if
we want to "cheat" and handle it on the receive end, I'd probably insert a
carriage return and line feed after the first space after the 72nd
character in the line and if we get to 80 without a space, insert a CRLF
without regard to breaking up a word. It gets fun since we also have to
ignore non-printing characters (blank, figs, ltrs, etc.) when counting
line position. We could also insert an LF after a CR and before the first
printing character if one was not received. This would prohibit purposeful
overtyping, though.

Again, I'd prefer stuff be transmitted correctly. Failing that, code could
be added to a software TU driving the Teletype. Or a separate box could
insert the required characters, but that gets expensive since you'd need
another local loop, etc.

I plan on messing with making a TU on a microcontroller some day. I might
add something like that if I ever get around to that project. Current big
project is scanning more stuff for http://bh.hallikainen.org/ .

Harold



-- 
http://w6iwi.org