If you’re anything like us, you have a pile of half-finished projects (or half-baked ideas) sitting around gathering dust.

That’s why we are having a one-day community Hackathon and the theme is Finish a Project! Don’t worry if you have a huge project that might take longer to finish, just finish a part of it. The event is free and open to everyone to attend, if you don’t have a project you can help someone else.The event will take place from 10AM to 10PM on Saturday, 28 July at the ‘space. The day will kick off at 10am with (free!) breakfast, followed by a chance to tell everyone what your plan is for the day, and perhaps canvas some help!

Feel free to pop in and out throughout the day.

What can you work on at the hackathon?You can work on anything, it’s a really open Hackathon.Are you coding something you want to finish?Want to fix a bug in an open source project?Finish writing something, design something?Finish a craft project you have lying around?

What should I bring to the hackathon?Bring whatever you need, although the hackspace will have some parts/materials and tools available. Bringing a laptop is a good idea.This is a one-day event so be ready to take home what you make.Hope to see you on the day! We have a facebook event here

If you follow us on social media or are a member of our mailing list, you have probably seen our survey asking you for your ideas on what we can change to make the space (still open here).

You asked us to…

Rearrange to make more space

We’ve rejigged the space to make it a bit more collaborative and to make it a bit more open:

More opening times to non members

We have a regular Saturday open day (hackSaturdays!) planned, roughly once per month, in addition to the regular Wednesday Open Nights. Keep an eye out for notifications via twitter, facebook and the blog!

The next hackSaturday will be from 10:00 until 16:00 on Saturday the 26th of May

Wednesdays have been Open Nights since version 1.0 of York Hackspace, way back when we used to meet in the Black Swan. However, we understand that weeknights aren’t the best time for everyone to visit the space.

We are therefore pleased to announce that we are starting up hackSaturdays: different day, different time, but the same original recipe as the Wednesday Open Evenings.

Curious about what to bring?

All you need is yourself, enthusiasm and curiosity. Feel free to bring a project, things to make, things to do, things you want help with, or things you just can’t find time to do elsewhere.

What does the hackspace have to offer?

You’ll be free to use whatever tools and facilities you want, subject to the necessary training and/or supervision. Non-members will be expected to contribute towards hardware, electronic components etc (members get all this stuff for free!) if it’s more than a few bits and pieces. We have a fast Internet connection sponsored by Andrews & Arnold which you’re welcome to use. And a tuckshop!

Curious about what to bring?

All you need is yourself, enthusiasm and curiosity. Feel free to bring a project, things to make, things to do, things you want help with, or things you just can’t find time to do elsewhere.

What does the hackspace have to offer?

You’ll be free to use whatever tools and facilities you want, subject to the necessary training and/or supervision. Non-members will be expected to contribute towards hardware, electronic components etc (members get all this stuff for free!) if it’s more than a few bits and pieces. We have a fast Internet connection sponsored by Andrews & Arnold which you’re welcome to use. And a tuckshop!

The next hackSaturday will be from 10:00 until 16:00 on Saturday the 24th of February

Wednesdays have been Open Nights since version 1.0 of York Hackspace, way back when we used to meet in the Black Swan. However, we understand that weeknights aren’t the best time for everyone to visit the space.

We are therefore pleased to announce that we are starting up hackSaturdays: different day, different time, but the same original recipe as the Wednesday Open Evenings.

Curious about what to bring?

All you need is yourself, enthusiasm and curiosity. Feel free to bring a project, things to make, things to do, things you want help with, or things you just can’t find time to do elsewhere.

What does the hackspace have to offer?

You’ll be free to use whatever tools and facilities you want, subject to the necessary training and/or supervision. Non-members will be expected to contribute towards hardware, electronic components etc (members get all this stuff for free!) if it’s more than a few bits and pieces. We have a fast Internet connection sponsored by Andrews & Arnold which you’re welcome to use. And a tuckshop!

Tickets are free, but there will be a suggested donation (TBC) that we would greatly appreciate if you attend, especially if you aren’t a member of York Hackspace.

Wednesdays have been Open Nights since version 1.0 of York Hackspace, way back when we used to meet in the Black Swan. However, we understand that weeknights aren’t the best time for everyone to visit the space.

We are therefore pleased to announce that we are starting up hackSaturdays: different day, different time, but the same original recipe as the Wednesday Open Evenings.

Our first hackSaturday will be from 10:00 until 16:00 on Saturday the 10th of February.

Curious about what to bring?

All you need is yourself, enthusiasm and curiosity. Feel free to bring a project, things to make, things to do, things you want help with, or things you just can’t find time to do elsewhere.

What does the hackspace have to offer?

You’ll be free to use whatever tools and facilities you want, subject to the necessary training and/or supervision. Non-members will be expected to contribute towards hardware, electronic components etc (members get all this stuff for free!) if it’s more than a few bits and pieces. We have a fast Internet connection sponsored by Andrews & Arnold which you’re welcome to use. And a tuckshop!

It is probably a bit late in the month for New Years resolutions, but York Hackspace never does things by the books, so why start now…?

An inkjet printer cartridge looking genuinely shocked that a new blog post has appeared

It’s been a while since our last blog post: Since October, in fact. Despite the radio silence, lots has been going on: the laser cutter has some shiny new modifications and upgrades (watch this space for an update!), plans hatched, wood carpenter-ed, mallets crafted, lasers cut, many chocolate bars munched and cans of Coke drunk. We just need to tell people about it!

So, York Hackspace has a New Year’s Resolution: BE MORE SOCIAL!

This is what we have planned:

Expect more posts about what we’ve been up to on the blog, Facebook, Instagram, Twitter… you name it, you’ll see it.

More open events! Wednesday evenings at 8pm will remain Open Nights, but we will be having regular open days on weekends (to be announced later this week!) so more people can make it down to the space.

Workshops: we want to share skills and help people teach themselves about making cool stuff, so expect workshops about laser cutting, PCB making… watch this space!

Hackathons: 24 hours of hackery goodness!

Want to keep up to date with whats going on? Follow us at any of the links below, and see ya at the ‘space!

We were going to write a post a few weeks ago about our new laser cutter. Unfortunately, after a relatively short time, it stopped cutting. This post is about how we’ve gone about diagnosing the problem, since it’s hard to find this sort of information online.

Before I get into things, please be warned: Lasers used for cutting are extremely hazardous – the diffuse radiation from the laser can blind you without staring into the beam, and the carbon dioxide lasers commonly used produce a beam which is mostly invisible! Additionally, the power supplies produce extremely high voltages (on the order of 25kV – that’s enough to cross a significant air gap), and can supply enough current to produce a lethal shock (it only takes 27mA). Don’t do this unless you know what you are doing – and even then, please have someone working with you.

That being said, let me get on with the article!

Firstly – some basics. I’m not a laser expert by any means, but I’ll attempt to describe the requirements around the operation of one. A carbon dioxide laser relies on electrical excitation of the gas molecules to produce radiation, which leads to laser operation. To excite the gas, a high voltage must be applied to the tube, which ionises the gas and “strikes” the tube. Once ionised, the gas begins to pass electrical current, which then sustains the laser operation. For our tube, around 25kV is required to strike it, after which the voltage reduces to around 2kV. The power supply regulates the current supplied, to stabilise the power output of the tube.

The aim of our diagnosis was to determine which of these components was most likely the cause of the fault:

The laser tube

The high voltage power supply

The laser controls

We’d already eliminated the basics – mains power issues, fuses, etc. The next thing we checked was whether there was any sign of laser power. Once we’d determined there was no sign of laser activity, we flipped open the laser cover to observe the tube. We could see some faint glowing around the electrodes, which suggested that there was some ionisation of the gas, but not enough to strike the tube.

The first thing we attempted to rule out was the panel controls. We found the data sheet for the laser supply. The power supply has a regulation input of 0-5V, which controls the current to the laser. On our cutter, this is directly wired to a potentiometer on the front panel. We checked this using a multimeter, and verified that the output varied smoothly, with no jumps or dirty spots. We also checked that the test button was able to drive the input terminal on the power supply, that the panel ammeter was able to pass current, and that the wiring was sound.

Since we had no guarantee that our laser tube was OK, we needed to create a test circuit that “looked” like a laser tube to the power supply. This would then provide a means to check whether the power supply was able to produce the high voltage required to strike the tube, and whether it was capable of supplying the current to sustain operation.

Since testing the supply’s sustain current was the simplest thing to do, we calculated an appropriate resistor value to load the supply. As we knew our tube was a 40W model, and worked at about 20mA current, we chose a 100kOhm resistor (20mA into 100k produces 2kV, 2kV x 20mA = 40W). We purchased a large, high wattage ceramic coated resistor for this, both to ensure sufficient power dissipation, and to be certain the high voltage wouldn’t arc over the resistor. The resistor was wired in instead of the laser, and we used the earth terminal on the cutter’s chassis as the return path, after verifying that this connected to the power supply’s return terminal. We also connected a 100 ohm resistor in series, at the earth side of the power resistor – this provided a 1000:1 resistance ratio, which was suitable for connecting a voltmeter to, so we could see the voltage produced by the supply.

We began testing with our control potentiometer turned all the way down, and tested for a few seconds at increasing levels. The result showed a gradual increase in current with no sign of a problem. We then held the supply at its maximum current (which was about 18.5mA) for 10 seconds to check it produced a steady current.

Laser Supply Test Hardware

Laser test hardware

To test the striking voltage, we used a simple spark-gap setup in series with the resistor. Dry air has a breakdown voltage of about 3kV/mm. We used some bare copper wire to assemble a simple gap which could be varied by bending the wires. While this didn’t provide a way to directly measure the striking voltage, the gap would provide an approximation – with the rest of the circuit acting as a realistic dummy load and providing a means to check the current and running voltage.

Starting with a gap of about 1mm, we tested the supply. At 1mm, we got a nice clean purple arc. Increasing the gap, we got to around 3mm before we hit trouble. At this point, the breakdown voltage was about 9kV, but the supply would only strike with the control potentiometer in a particular position, and wouldn’t sustain operation. Increasing the gap further resulted in no striking at all.

As the laser required around 25kV to strike, this setup should have worked up to a gap of about 8-9mm, so we were quite far off.

This seemed to indicate a problem with the power supply – most likely, some form of insulation breakdown in the flyback transformer.

We’ve since ordered and installed a new power supply, and I’m pleased to report that the laser cutter is now back in working order!

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

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 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.