You said… We do!

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!
(i’d like to learn) Laser cutting
We have a laser cutting workshop in the pipeline, watch this space!

Next hackSaturday Open Day: May 26th 10:00 ’till 16:00

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.

Want to know how to find us? Click here

For more details about our open nights, see the wiki.

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!

 

Questions?

Please contact us using any of the methods below!

Twitter • Facebook 16x16.png Facebook • Instagram 16x16.png Instagram • GooglePlus 16x16.png Google+ • Email 16x16.png Mailing List • Github 16x16.png GitHub • Telegram 16x16.png Telegram

Open Day this Saturday, April 14th.

 

Crochet CRAFT LogoThe next hackSaturday will be from 10:00 until 16:00 on Saturday the 14th of April

So why not pop down and say hello. There will be members there to show you around or chat about the space and what people do here.

Want to know how to find us? Click here

For more details about our open nights, see the wiki.

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!

 

Questions?

Please contact us using any of the methods below!

TwitterFacebook 16x16.png FacebookInstagram 16x16.png InstagramGooglePlus 16x16.png Google+Email 16x16.png Mailing ListGithub 16x16.png GitHubTelegram 16x16.png Telegram

hackSaturday This Weekend!

 

 

 

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.

Want to know how to find us? Click here

For more details about our open nights, see the wiki.

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!

 

Questions?

Please contact us using any of the methods below!

Twitter • Facebook 16x16.png Facebook • Instagram 16x16.png Instagram • GooglePlus 16x16.png Google+ • Email 16x16.png Mailing List • Github 16x16.png GitHub • Telegram 16x16.png Telegram

New Workshop: Hackspace First Aid

Please note: The date for this workshop has changed to the 22nd of March (1830 to 2200)

We’re kicking off our Workshop series with an evening workshop: Hackspace First Aid.

Hackspaces can be a bit hazardous, depending what you’re doing: sharp things, spinny things, hot things, cold things, laser-y things, poisonous things…

Whilst unlikely, all of these things can hurt you. The aim of this workshop is to share some knowledge on how to respond to accidents that you might see at a Hackspace.

We’re aiming to cover:

  • CPR
  • Cuts/bleeding/trauma
  • Burns
  • Eye injuries
  • Falls
  • Electrocution
Be aware: this is not a First Aid course! It is not ratified by anyone, and you will get no qualifications at the end of it.
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.

Register for a free ticket at https://www.eventbrite.co.uk/e/hackspace-first-aid-tickets-42955741780

 

New Event: hackSaturdays!

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. 

Want to know how to find us? Click here

For more details about our open nights, see the wiki.

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!

 

Questions?

Please contact us using any of the methods below!

 Twitter • Facebook 16x16.png Facebook • Instagram 16x16.png Instagram • GooglePlus 16x16.png Google+ • Email 16x16.png Mailing List • Github 16x16.png GitHub • Telegram 16x16.png Telegram

More Open Days, More Workshops, More Better!

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!

 Twitter • Facebook 16x16.png Facebook • Instagram 16x16.png Instagram • GooglePlus 16x16.png Google+ • Email 16x16.png Mailing List • Github 16x16.png GitHub • Telegram 16x16.png Telegram

 

 

Debugging a Laser

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 Tester - Circuit Schematic

Laser Supply Test Hardware

Laser 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!

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.

1 2 3 5