Category Archives: Hackspace projects

Talking V.23 to a Prism VTX 5000

This is the third post in a multi-part series about viewdata. A few members of the hackspace are working on a project to connect a ZX Spectrum with Prism VTX 5000 modem to an emulation of a viewdata system, providing a live demonstration experience.

A word in advance – this post is quite theory-heavy, and contains quite a bit of technical information. However, hopefully it’s of interest to people. You can find the complete source code for my softmodem at https://github.com/aquila12/v23.

Modems for viewdata systems use Mode 2 of the ITU V.23 standard for communication. This specifies the signal format for encoding the data as transmitted across a phone line. Mode 2 allows a maximum of 1200 baud operation, and specifies the mark (logic ‘1’) and space (logic ‘0’) frequencies as 1300Hz and 2100Hz, respectively. The standard also specifies a backward channel running up to 75 baud, using 390Hz and 450Hz for mark and space, respectively.

Viewdata uses the faster forward channel to deliver data to the customer’s terminal, while key presses are transmitted immediately over the backward channel. With the standard 7-bit ASCII data, even parity bit and the stop and start bits, the frames are a total of 10 bits long – so the forward channel can relay 120 characters per second, with the backward channel running at the much slower 7.5 characters per second. Viewdata frames are up to 40 characters wide, with 24 lines. This divides out neatly so that three complete lines of of non-escaped data can be sent each second (escape codes are used for display attribute changes), with a full frame taking around 8 seconds to transmit.

While a regular V.23 compatible modem could be used, these are somewhat rare now. To communicate with the Prism, we decided to use a software modem. While we’d had some success with minimodem, I found it slightly problematic to use in practice. On my laptop, it used a lot of CPU to demodulate signals, and it struggled to synchronise with the incoming data. I decided to put my somewhat rusty signal processing theory to practice and wrote a V.23-only softmodem to use for this project. My aim was to avoid performing any fourier transforms (e.g. FFTs) on the signal, as these are computationally expensive, and instead stick to simple operations such as moving-average filters and differentiators, as these can be made very computationally efficient.

My first arrangement has limited success, but was too sensitive to noise. The arrangement, briefly, did amplitude demodulation on the mark and space frequencies, then compared the magnitudes to see which was stronger, and fed the output to a shift register which detected the serial frames. Once I’d thought a bit more about the problem, I decided to attempt demodulation using an approach more suited to the frequency-shift-keyed modem signal, which produced much better results. I’ll describe that in more detail here.

Taking an input signal, I multiply on a complex local oscillator which runs halfway between the mark and space frequencies. This essentially moves the frequency spectrum down to DC – anything lower than the oscillator is seen as a “negative” frequency, while anything above is seen as a “positive” frequency – see the image below for a brief illustration. For a complex (I-Q) oscillator, this means that the direction of rotation of the output vector tells you whether the dominant frequency at the input is above or below the local oscillator frequency.

It’s worth mentioning that multiplying on the local oscillator doesn’t just “move” the spectrum – it causes two copies. One is shifted down around DC (the “difference” spectrum), while the other is shifted upwards (the “sum” spectrum). Because of this, and also because the input isn’t completely clean (in fact, it might contain other signals), the signal must be filtered before determining the direction the vector is rotating in. I used a moving-average filter for this.

Signal Processing 101

Signal Processing 101

Moving-average filters are very simple – essentially the samples between two points in time are summed. This is easy to implement efficiently as you only need to keep track of the samples within that period, and keep a running total. As each sample is added to the total, the sample added least recently is subtracted and removed from the buffer. These filters have a very characteristic transfer function (i.e. what frequencies they reject). The moving-average filter completely rejects signals at regular frequencies, and those frequencies occur depending on the period the filter is averaging over – the illustration shows the shape of the response. I used this fact to specifically tune the demodulation filters. When demodulating the forward channel, I placed the first “null” to eliminate the backward channel signal as much as possible (as in the picture), as the backward channel is within the side-bands of the forward channel. For demodulating the backward channel, since the band is quite narrow, I just placed the first null so it was away from the frequencies of interest.

The filtered signal is then passed to a function which determines the current phase of the vector. This essentially divides the vector components to produce the tangent of the phase angle, and then passes that through a function to determine the angle. As the precise angle isn’t important for this, I used a simple approximation for this – the tangent function, between -45° and +45°, is nearly a straight line, and it’s straightforward to replicate this approximation through the entire circle by flipping the division upside down to stay in this quadrant.

Once the phase angle is determined, we just need to average its change over each bit, and use the sign of this (positive or negative) to correctly demodulate the signal. The simplest way to write this was to take the derivative of the phase, and then run this through a moving-average filter. The output is then fed to the same frame-detection routine as I’d drafted for my first attempt, which I’ve illustrated below.

Frame Detection

Frame Detection using a Shift-Register

I’m aware this topic has been quite in-depth as far as the implementation goes, but I’m hoping it makes some sense to those of you who perhaps dabble in filters or radio-related topics! If you’d like me to expand on anything I’ve discussed here, please get in touch and I’ll do my best to address your query.

Next time, I’ll talk a bit about the viewdata frame format and how we’re writing our frames.

Simulating a Phone Line

Line Simulator built in an old ADSL filter box

This is the second post in a multi-part series about viewdata. A few members of the hackspace are working on a project to connect a ZX Spectrum with Prism VTX 5000 modem to an emulation of a viewdata system, providing a live demonstration experience.

Viewdata connections, much like dial-up internet access which followed later, relied on audio frequency telephone communication to transfer data between the user’s terminal and the information provider they were logged into. I’ll cover details of the signal modulation in a separate article; in this article I’ll describe how I connected a real Prism VTX5000 modem to a laptop’s sound card.

A UK telephone line, like that in most countries, is a relatively simple circuit. The line is supplied from a bank of batteries with approximately 50V DC, with earth on the positive side (to prevent line corrosion by offering cathodic protection). This would have originally been supplied via a pair of relay coils, which have three main effects:

  • The coils have a DC resistance, which in practice limits the off-hook condition of the line to about 8V at 20mA
  • The coils present a large inductance, which prevents AC (i.e. the audio signal) from being lost into the supply
  • The relay contacts are used to detect when the line is off-hook

For the purposes of our simulation, we only need the line simulator circuit to behave like a line in the off-hook state. This means it can run from a low-voltage supply of 9-12V. We’re also not interested in providing a ring signal (typically around 90V AC), as it’s also not required for this project.

On a telephone line, the AC audio signal sees a resistance of around 600 ohms. Audio signals are coupled to the phone line via capacitors, which pass the audio signal but block the DC supply.

The line simulator therefore has the following requirements:

  • To provide approximately 20mA at around 8V DC with a telephone connected off-hook
  • To provide several kilohms of dynamic resistance at DC
  • To provide around 600ohms of resistance to AC
  • A means to inject an audio signal from a laptop onto the line
  • A means to take off an audio signal to feed a laptop’s line input
  • Protection to prevent overloading of the sound card

Starting with the DC requirements, a fairly simple transistor circuit can be made to act roughly like a current source, up to near the circuit’s supply voltage. Adding a bypass resistor permits the introduction of a controlled dynamic resistance at DC, and this also affects the off-hook voltage level.

To provide the required AC resistance and injection capability, the circuit can be coupled via a capacitor and series resistor to the laptop’s headphone jack. A second resistor to ground helps to block the DC supply. A headphone output has a very low resistance of a few ohms at most. A 680 ohm resistor increases this to a more suitable level. While this is slightly on the high side, it leaves some room for other parallel resistances of a few kilohms, which the circuit will introduce.

The protection and take-off requirements can be met simply by placing two signal diodes in inverse-parallel; this limits the line signal to 0.7V peak, and also limits the extent of transients when the line switches between on- and off-hook conditions.

Line Simulator Circuit Schematic

Line Simulator Circuit Schematic

The complete line simulator circuit is shown above. The LED and series resistor are used to provide suitable biasing to the transistor. An unintended side-effect is that when the phone is on-hook, the LED supply is bypassed by the transistor, so the LED also acts as an off-hook indicator.

This circuit can easily be built on a small piece of stripboard. ADSL filters are widely available, and often going spare. These provide a suitable project box and, with the rest of the filter components removed from the board, a pair of phone jacks which can be connected to the line simulator circuit. Note that the circuit as presented is not suitable for connection to a PC microphone jack as the signal level is far too high; to use this an attenuator would need to be built in, which could be achieved with a simple resistive divider.

Once constructed, check the voltage at the phone socket is about right, then plug in an old phone to check it’s working. You’ll probably hear some quiet line noise, and the LED should light when the receiver is lifted. If you connect the circuit to a laptop or music player, you should be able to hear audio played clearly through the phone, complete with that lovely tinny quality.

Viewdata – A Brief Overview

This is the first post in a multi-part series about viewdata. A few members of the hackspace are working on a project to connect a ZX Spectrum with Prism VTX 5000 modem to an emulation of a viewdata system, providing a live demonstration experience.

Back in the early ’80s, before the world wide web was a thing, there was something a little like Teletext called Viewdata.

Viewdata pages look a lot like Teletext – they share the same frame formats – and viewdata terminals likely used the same IC to produce the video signal (The Mullard SAA5050, also used in the BBC Micro for its text-only mode). While teletext pages are transmitted in the blanking interval of a TV signal, in rotation so a receiver needs to wait for the right page, viewdata operates over a telephone line and so is more interactive.

When a subscriber wanted to log onto the service, they dialed the provider they wanted to access – for example Prestel – and provided their ten-digit ID number and password to log in.

Once logged on, the user was presented with the main page, and navigated using the number keys and enter. Pages were generally arranged hierarchically, so page 1234 would be below 123, and is reached from that page by pressing ‘4’. Like Teletext, viewdata pages could consist of multiple frames, so pages longer than one frame could be constructed.

Companies who wanted to host information on a viewdata service would pay the information provider (IP); this would involve a payment for a particular length of prefix (shorter prefixes would typically be more expensive), and also per page hosted. They could edit frames using special editing software, and then uploaded these to the IP. Frames weren’t restricted to being completely passive – “submission” frames could be authored, allowing people to order goods or fill in forms. Frames could also be marked with a cost, allowing companies to collect money against a user’s account when they accessed the information.

Often, information providers would have a mailbox system, allowing users to send each other messages, which could be retrieved and read when the user logged in. Some terminals would allow these, as well as other frames, to be retrieved and stored locally, so they could be read offline without the user keeping the line open.

As well as centralised information providers, such as BT’s Prestel, software later emerged allowing people to host their own viewdata systems – often bulletin boards – or set up peer-to-peer connections. Peer-to-peer connections allowed users to phone each other, and as long as they set their modems correctly, information could be transferred half-duplex. Bulletin boards could be run on systems such as the BBC Micro, and would present themselves in the same manner as an IP.

The modem standard – v.23 – used for viewdata is asymmetric. The forward channel (download) runs at 1200 bits per second (120 characters per second taking framing into account), while the reverse channel (upload) runs at 75 bits per second (7.5 characters per second). A terminal – apart from any storage functionality – is relatively “dumb”, and transmits key presses immediately. The information provider’s system reacts as needed – whether this means sending a new frame, or echoing characters typed into a response frame. The slow reverse channel is still generally fast enough to transmit the user’s keypresses, and is fairly noise-resistant because of the low bandwidth.

There are sites which contain demonstrations of some viewdata systems – https://www.viewdata.org.uk/ is a good example of this. Follow the “Logon Now” link to access an example.

Spacehack upgrades, Just in time!

You may have spotted a little while ago that we got a place at Maker Faire UK for the fourth year in a row.

For the past few years, setting up Spacehack hasn’t been a simple job, mainly because of how the server box (the gold pyramid) was a flimsy cardboard box with various things taped to it. We also had issues with the four consoles. Many LCDs were failing, pots not rotating correctly, switches not working or missing. So we had to do some upgrades.

One of the most ambitious upgrades was the server box upgrade. We wanted to get this one done before the Maker Faire this weekend, to make setup easier. I’m pleased to say that we have completed it on time! You can look forward to seeing the new server box this weekend.

The upgrades have enabled us to make the server more rugged and much more compact. We’ve eliminated the need for three of the five power supplies by making everything run on 5v. We even have a touch-screen GUI for managing the game. The GUI’s written in pascal, of course. 🙂

Just to be clear about why this needed doing; see this picture of the guts of the original server box. Yuk!

The Long-Awaited Low-Temperature Tuck Shop.

After having this lovely glass-sided fridge in the hackspace for many weeks, we’ve finally got it to a working state.

We got the fridge for free, in mostly working condition. It really needed a clean and the fan motor was very noisy. It also had a fluorescent light bulb in the top, which wasn’t working. We tried fixing the fan, but couldn’t get it quiet-enough to prevent it being a nuisance to people working in the hackspace. In the end we decided to replace the fan with an old PC cooling fan that was much quieter.

While we had the thing open, we decided to do something about the lighting. We removed the old light bulb and instead fitted some much lower power LED strips inside the fridge. Nick did a great job of wiring these up to the switch for the old light and even added a little microswitch to detect the door opening and turn on the white lights to make it a little easier to see. (As pretty as the blue and red lights are, they’re not ideal for reading labels on things.)

Let us know what we should stock!

 

It’s good to have places to put things

After much discussion, we finally decided what we needed to do to make better use of the space we have. We haven’t quite got it all done, but we’re most of the way there, so we decided to share some photos of how it’s going.

What we wanted was a shelf above the electronics workbench so that we could put all of the test equipment on the shelf so that it leaves the workspace below free. Most of the wood we used came from old pallets, the shelf is one large plywood sheet that was otherwise going to end up in a skip. In addition to the large shelf, we have most of what we need to in place for some extra smaller shelves above.

Of course this shelf is going to cast a shadow onto the desk, but with an abundance of white LED strips in the hackspace, it’s just a matter of time before somebody sticks one to the bottom of the shelf.

We’ve also addressed the issue of the overflowing bookshelf and cupboard. They now have a friend in the form of a black plastic shelf unit.

Who’s been labelling things in the space?

It’s very nearly Christmas, but there’s time for us to share one more hack.

Lots of printing, some of it good.

Lots of test prints, one good badge.

A little while ago, John brought an old till receipt printer to the hackspace to be hacked. Recently the temptation to do something with it got the better of me. You may [or may not] remember from the post about all the retro computer projects in the space, that I have a ZX spectrum that I’ve been playing around with lately. It’s a 48k Spectrum and I’ve got a Kempston Centronics E Interface for it. The centronics interface lets it talk to any printer with a centronics connection. John’s printer is actually fairly modern. It certainly wasn’t around in the eighties when the spectrum was. I think it’s probably mid-noughties era. It’s an Epson TM-T88ii. Nevertheless, it’s fairly easy to get the spectrum to drive this modern printer.

After a little bit of trial and error to get all the right escape sequences for text size, boldness, justification and cutting the paper after a print, I was able to get the spectrum to print name badges. I wrote a program that asks for your name and prints a “Hi, my name is…” badge on receipt paper.

If you have a spectrum with a centronics interface and a suitable printer, you can give the program a try! The code is on github in the form of a wav file recorded direct from the spectrum used here.

A word of caution if you do though, you might get carried away with yourself. When it’s as easy as just typing in a string and pressing enter, you’ll print lots of badges. I will leave you with these photos of the many badges I left around the space.

Have a great Christmas.

Dan.

A multimedia system fit for a hackspace

Being able to leave equipment permanently in place and attached to the walls or ceiling is a luxury we gained when we moved in to our new space. So naturally enough, when we had a projector and an amplifier system lying around doing nothing, it only made sense to give the space a proper multimedia setup.

Projector showing demo image

We put the projector on the ceiling a little while ago, but hadn’t really connected it up until we got the amp and speakers.

With a little bit of planning followed by shopping for the right cables, we now have a setup that should cater for most circumstances. Our projector can now take HDMI, VGA or Mini Displayport (or anything else you can convert to HDMI) with sound provided via a Cambridge audio A1 mk3 Stereo amplifier.

Cambridge audio amplifier and speakers

We can also cast audio to a Raspberry Pi using DLNA. The Pi is connected directly to the amp at the moment and so only does audio, but we plan to get an HDMI switch that will allow us to use the Pi for casting video to the projector without having to sacrifice the wired option.

Raspberry Pi in case, connected to amp

This solution makes it easy to connect almost any device we need to the system. The long HDMI cable ends at a desk on the other side of the room that is convenient for placing a laptop for showing a video or presentation. As the HDMI cable carries both audio and video, this is the only cable we need going to the projector setup, where a converter box splits the HDMI out to VGA and a pair or RCA connectors for audio. Unfortunately the projector doesn’t have any digital inputs, so we had to go for VGA. The other input options are provided by a kit of converters.

HDMI converter boxVideo format converters

We still need to get the speakers mounted on the wall for a proper cinema experience.

The software for the DLNA was a little awkward, but we got it working in the end. The Pi is running GMediaRenderer, a DLNA renderer for GStreamer. This had to be compiled from source and took some fiddling before it worked how we wanted it. This was worth doing though as we were then able to customise how it looked in the client app. Our logo is on it! We can already cast sound from laptops too, pulseaudio-dlna can cast sound from your linux PC to any DLNA device on the network and it works great.

dsc_5150