There’s a new update on the v.23 decoder, there was a major bug on the demodulation routine.

There is a script process_wav_to_data.sh It takes an audio file as the first parameter. It will try to decode the v23 data and split it into files based on pauses in between. Those files will be packed into a zip archive which will be stored next to the audio file.

If you have the bildschirmtext decoder https://github.com/bildschirmtext/bildschirmtext installed next to it, it will also generate preview images.

https://github.com/Casandro/v23_tape_recovery

I have written a little software package to decode v23 encoded files. It can be adapted to support parity. It can back-track in case of parity/framing errors.

Another neat feature is the timed octets output which preserves timing information.

https://github.com/Casandro/v23_tape_recovery

Aufgrund von verschiedenen Umständen ging es zuletzt eher im Hintergrund mit BTX und der Zentrale Neu-Ulm weiter. Sei es das es Umzüge von beteiligten Personen gab, Corona die Motivation ziemlich kaputt machte oder die Hardware mal nicht mehr das macht, was sie soll. Und das Leben außerhalb von BTX hat auch immer wieder Arbeit und Aufmerksamkeit gefordert. Wir sind nicht weg – wir sind aktiver als man vielleicht denken mag. Auch bei BTX.

Zum Beispiel wird derzeit im Hintergrund an einer neuen Version von Neu-Ulm gearbeitet, bzw. komplett neu geschrieben damit auch Andere leicht sich in die Software einarbeiten und dann auch ihre eigenen Beiträge dazu leisten können. Auf das es in Zukunft noch besser läuft.

Wir sind noch da – manchmal aber auch einfach nur im Hintergrund. So ist auf der Mailingliste halt auch nur ab- und zu mal was los, aber auch nicht alles hat es auf die Mailingliste geschafft, so wie in der letzten Zeit z.B. neue Hardware.

Liebe Grüße
Hammi

Da dieses Jahr das Easterhack auf Grund von COVID 19 ausfiel, gab es als Ersatz den virtuellen Kongress DIVOC, das „DIgital Verteiltes Online Chaos“.

Dazu gab es ein BTX-Terminal mit dem jeder spielen konnte. Um die Schwelle dafür möglichst klein zu machen ist die Schnittstelle zum Hacker ganz einfach UDP. Ein kleines Programm nimmt die UDP-Pakete entgegen, limitiert die Datenmenge auf 120 Zeichen pro Sekunde. Ein Multitel-21 mit dem Raspberry Pi D-BT-03 Emulator bekommt die Daten und stellt sie dar. Das Bild wird dann von einer Webcam gefilmt und über ein Jitsi-Meet verbreitet.

Auf zukünftigen (virtuellen) Events könnte man das noch professioneller machen. Zum Beispiel könnte man mit einem besseren Framegrabber den Stream direkt erzeugen, oder das Ergebnis als Projektion irgendwohin werfen.

(Update) Seit Veröfentlichung des Artikels haben jetzt auch einige Leute ihren Code dazu veröffentlicht. https://github.com/Eigenbaukombinat/btxfltclnt

(Update 2) Ich hab noch ein den Code des Servers und ein paar Demos veröffentlicht. https://github.com/bildschirmtext/btx_flut Ich freue mich über Beiträge.

In letzter Zeit wurde der Raspberry PI basierte DBT-03 Emulator fertig.

Jetzt ist man nicht mehr auf wackliges WLAN angewiesen. Man kann jetzt im Prinzip sogar die Serversoftware direkt auf dem Gerät ausführen.

Das Projekt findet man auf Github https://github.com/bildschirmtext/rpi-dbt03 Platinen kann man im 3-er Pack von Aisler fertigen lassen. https://aisler.net/p/KISJVUNX0 Falls jemand mehr davon fertigen lässt wäre ein Austauschprogramm nett.

Die Schaltung hat jetzt auch Optokoppler drin, so dass das Terminal potentialfrei angebunden werden kann. In der Schaltung ist aber ein 1 Megaohm Widerstand um statische Aufladungen abzuleiten.

Der Mikrocontroller ein ATMega8L wird über SPI angesprochen. Im Prinzip empfängt der Befehlt vom Raspberry PI und antwortet darauf. Der ATMega wickelt den UART zum Terminal in Software ab. Dafür läuft mit 1200 Hz eine ISR. Die selbe ISR erzeugt auch die ganzen Töne. Das Protokoll ist im Repository dokumentiert. Einzelne Details muss man da aber noch aktualisieren. Im Repository ist auch die Firmware drin, inklusive einem Makefile welches auch gleich den Mikrocontroller flasht. Dazu ist es aber meistens notwendig in /etc/avrdude.conf die Geschwindigkeit des verwendeten „Linux-SPI“ Programmers zu reduzieren. Unprogrammierte ATMegas laufen nur mit 1 MHz über den internen RC-Oszillator weshalb die Programmierung langsamer laufen muss. Später geht das dann auch schneller.

Hier ist mal ein Stück Doku dazu wie man in der BTX-Serversoftware von Michael Steil Seiten anlegen kann. https://github.com/bildschirmtext/bildschirmtext

Im Unterverzeichnis data finden sich weitere Unterverzeichnisse. Seiten werden etwas merkwürdig adressiert. Existiert eine Seite unter data/123/456a.cept, so kann diese als *123456# aufgerufen werden. Die Seite a muss immer existieren, weitere Folgeseiten haben dann b, c usw im Dateinamen.

Jede Seite benötigt 2 Dateien. Die .cept-Datei enthält die rohen CEPT-Dateien. Die .meta-Datei enthält Metainformationen wie Verknüpfungen, Anbieterkennungen oder Farbpaletten. Eine a.glob-Datei in einem Verzeichnis kann hier auch Werte vorbelegen.

Hier auf github https://github.com/bildschirmtext/tape_recovery findet sich ein kleiner Satz an Programmen den ich hier mal vorstellen möchte.

Das Problem welches dieses Programm zu lösen versucht ist es V.23 modulierte Daten zu dekodieren. Die Daten werden dabei auch in Pakete aufgeteilt. Dies ist sehr praktisch um BTX-Daten von Tonbändern zu bekommen. Die extern benötigten Pakete sind sox und zip.

Die „Installation“ ist relativ einfach. Man klont sich das Repository. Dort gibt es unter src/bin ein Verzeichnis mit den C-Programmen. Ein Aufruf von ./compile.sh übersetzt diese. Um Dateien zu konvertieren wechselt man wieder in das src-Verzeichnis und führt dort process.sh aus. Der Parameter dafür ist die WAV-Datei des Bandes. Es sollten alle von sox unterstützen Dateiformate verwendet werden können.

Als Ausgabe wird ein ZIP-Archiv erzeugt welches alle erkannten Blöcke sowie ein wenig textuelle Info über den Prozess gespeichert werden. Die Datenblöcke werden im Format Stunde-Minute-Sekunde.Millisekunde benannt. Das ermöglich eine einfach Zuordnung zu der Position in der WAV-Datei.

Die Software soll im Sinne von Freier Software frei sein, deshalb ist wie hoffentlich so gut verständlich, dass Nutzer selbst sinnvolle Änderungen daran durchführen können.

Die mir vorliegenden Dateien scheinen mehrere CEPT-Blöcke zu haben. Diese werden über Zeiger an den Offsets 0x92, 0x9a und 0xa2 referenziert. (Update: wohl auch 0xae)

Gleichzeitig scheint der ASCII-Block auch zweigeteilt zu sein und über 0x88 und 0x8e referenziert zu sein.

Die Zeiger sind jeweils 16 Bit in Intel Byteorder (least significant byte first) für die Position und die Länge.

Scheibar ist der CEPT-Block nicht 0-terminiert. Einige Daten, besonders die „Rasterfahndung“ haben 0-en in den CEPT-Daten drin. Im Offset 0x10-0x11 des Blocks ist ein Zeiger auf ein Ende der CEPT-Daten, welcher aber zumindest manchmal viel weiter nach hinten zeigt.

Scheinbar enthält aber der Anfang eines Blockes nicht nur den Zeiger auf die folgenden Daten, sondern auch noch ihre Länge. Ist in 0x92-0x93 der Zeiger zum CEPT-Block gespeichert, so enthält 0x94-0x95 seine Länge. Ist der Zeiger in 0x9a-0x9b, so ist die Länge in 0x9c-0x9d. Dies könnte ein Schlüssel zum Verständnis der Daten sein.

Es stellt sich heraus, dass das Offset zum ASCII-Text immer an Stelle 0x88-0x89 steht. Das Offset zum CEPT-Block findet sich entweder an Stelle 0x92-0x93 oder, falls da Nullen drin sind, and Stelle 0x9A-0x9B. Warum das so ist, ist mir im Moment noch nicht klar.