The GT3 Esprit uses the following Turbo :
Lotus P/N - A920E6002
Garrett P/N - 465133-(000)3
From
the turbo's ID plate, it is known that the GT3 has a 50 trim compressor
wheel in a T3 housing. With that information, the compressor 'map' can
be obtained from the manufacturer to observe it's performance.
The 'map' is an area graph, covering a complex set of variables, the main culprit being the constantly changing heat generated by compressing
air. This is represented by the coloured efficiency 'islands' - the more
efficient areas the turbo operates in, the less heat is generated. In the above case, the T3 is actually pretty good across the board, only deviating 65%-75% over the map.
Pressure Ratio.
The
Pressure Ratio (PR) can be basically defined as the boost pressure. This turbo's maximum
boost pressure on the GT3 Esprit is capped at 0.97 bar (14.06 psi) above atmospheric pressure. Pressure ratio is the absolute pressure at the turbo outlet, divided by the absolute inlet pressure, in this case the pressure ratio = (14.06 psi + 14.7 psi) / 14.7 psi = 1.95
However, no induction system can ever be perfect and will always encounter losses. Whilst the pressure ratio is regulated at 1.95 at the cylinder head, the pressure ratio measured at the turbo outlet itself would be read higher due to these losses, in this example 5% loss gives a PR of 2.05 at the turbo. This represents the fact the turbo has to spin faster to generate the required PR minus the losses.
Therefore, if the engine requires 15lbs of air / minute, it can be seen that the turbo would need to spin faster (by a few thousand rpm) to generate the same air flow.
This clearly sets out the case for an efficient induction system which would reduce turbo spool time (lag) and temperature.
Air Flow.
Air flow rate is rated in pounds of air delivered / per minute (lbs/min), but can also be expressed as cubic feet per minute (cfm).
The graph now shows the approximate air consumption rates for engine speeds of the GT3's 1997cc engine at 3,000 and 6,000 rpm. As can be seen at 3,000 engine rpm, the turbo needs to spin about 116,000 rpm to achieve the demanded pressure ratio. If the induction was more efficient it would need to spin less fast.
At 6,000 engine rpm, the turbo races at nearly 140,000 rpm to maintain the pressure ratio.
Surge Limit.
The last part of the graph is the surge limit line. This dictates how quickly the turbo may accelerate before the blades on the compressor start to encounter turbulence and potentially stall. This can cause the compressor catastrophic damage so it is important to consider this especially as some smaller turbos can accelerate very quickly unless checked.
At idle the engine needs only approximately 4 lbs of air a minute. If the accelerator is smashed, the engine will bolt and the turbo will accelerate and rapidly build up pressure towards the cap point. This rate of acceleration can be contained by the car's ECU, and indeed the Esprit uses a special valve to control this performance called the 'wastegate solenoid'.
Tuesday 18 February 2014
Spectrum gets an upgrade
Before all the parts can come together the Pi has to be fitted to the case of the Spectrum so that everything can be located and engineered into place correctly.
The ruling element here was the HDMI socket. This was going to be the hardest part to remove if it came to that due to the amount of fine pitch surface mount pins. I do have the equipment to do this but the way I see it, why make life hard ?
The solution was to mount it so that the HDMI was sat near to one of the cut outs already in the Spectrum case. This location also allowed me to keep the ethernet port fixed to the board. The less that could be de-soldered the less likely any damage would occur to the Pi itself.
In order for the Pi to fit in this location of the case a few additional components had to be removed. The audio jack and composite video plug are pretty useless so they went straight away. The twin stack USB port had to be remove as it was too high, this will be replaced by a USB hub at a later date.
The GPIO (general purpose in/out) port also had to go, interestingly the Spectrum had a very similar expansion slot which protruded out of the back so the idea here was to emulate that with this build using a ribbon connector to extend the Pi's GPIO, again at a later date.
The Pi is held in by 2x counter sunk screws into the case with a small stand off. I also added a small heat sink for the CPU/GPU/RAM chip for good measure. Note the Pi will not be powered by the micro USB port in the bottom left, this is because it will interfere with the case screws. Therefore the 5V power will come in via a fuse into test points TP1 and TP2, I fitted two pins onto these locations for the power wires fitted later.
The hole in the back of the case was slightly enlarged to accommodate the HDMI port and the whole thing is ready to be test assembled.
The ruling element here was the HDMI socket. This was going to be the hardest part to remove if it came to that due to the amount of fine pitch surface mount pins. I do have the equipment to do this but the way I see it, why make life hard ?
The solution was to mount it so that the HDMI was sat near to one of the cut outs already in the Spectrum case. This location also allowed me to keep the ethernet port fixed to the board. The less that could be de-soldered the less likely any damage would occur to the Pi itself.
In order for the Pi to fit in this location of the case a few additional components had to be removed. The audio jack and composite video plug are pretty useless so they went straight away. The twin stack USB port had to be remove as it was too high, this will be replaced by a USB hub at a later date.
The GPIO (general purpose in/out) port also had to go, interestingly the Spectrum had a very similar expansion slot which protruded out of the back so the idea here was to emulate that with this build using a ribbon connector to extend the Pi's GPIO, again at a later date.
The Pi is held in by 2x counter sunk screws into the case with a small stand off. I also added a small heat sink for the CPU/GPU/RAM chip for good measure. Note the Pi will not be powered by the micro USB port in the bottom left, this is because it will interfere with the case screws. Therefore the 5V power will come in via a fuse into test points TP1 and TP2, I fitted two pins onto these locations for the power wires fitted later.
The hole in the back of the case was slightly enlarged to accommodate the HDMI port and the whole thing is ready to be test assembled.
Friday 14 February 2014
New PC case design
Time to make a decent PC case, the old rig has been hanging on the wall for too long. I took some inspiration from the internet and decided on a design that would allow open planning and futuristic look. Initially I wanted a 'Steam Punk' rig but I took this idea from some architecture in Valve's game "Portal" and infrastructure I've seen at McLaren cars factory.
--CAD pic ----
--CAD pic ----
Thursday 13 February 2014
Wednesday 5 February 2014
Getting the keyboard to work
I really wanted to integrate the Pi into the Spectrum, as opposed to the other way around, which consequently is quite difficult.
The keyboard membrane functions to short out two pins to generate the keystrokes. The Spectrum uses 5 and 8 pin connectors, therefore 5x8 = 40 key combinations are possible. The first job was to integrate the spectrum membrane into a USB keyboard which could be used with the Pi.
Once this was joined together a complete key-map can be determined by pressing the keys on the membrane and seeing what keystrokes are generated by the Pi and putting them into a spreadsheet for reference :
The greyed out keys are what the Spectrum keyboard 'should' print, the red keys are what actually prints on the screen. As can be seen the map is a complete mess, ??? denotes a function of the Japanese standard keyboard of all thing. No matter, all that is needed is the key codes from this reference.
When a key is pressed, the computer simply reads it as a code. For example key A may be code 65, B is code 66, C is code 67 and so on. All that needs to be done is tell the computer code 65 no longer means A, it means something else. It's a bit like taking the keys off the keyboard and rearranging them, but doing it on a software level.
This is where things get extremely tricky...
Everyone I have seen at this stage use a program on the Pi called xmodmap to fudge the keyboard. It has to be run as a script or manually on every boot and takes a long time for the Pi to compile, from what I have seen it also does not fully emulate the Spectrum's keyboard nor does it run in Linux's command line interface (shell). I wanted a more professional feel to my Spectrum Pi so I wanted to totally edit or create a key map so it worked on all levels.
This is a lot harder than it seems and there is scarce documentation on the subject requiring less than a computer degree to make sense of !
Firstly I tried to re-program the existing generic keyboard map the Pi uses, unfortunately this has no provision for a SHIFT + Function key and I need this to generate some capital letters and symbols. I also struggled to define some of the Japanese function keys stated above and it looked like this method not going to be possible as a lot of people had stated on forums.
However, not to be beaten, using another 'model' (eg the Commodore Amiga) of key maps allowed me to generate the functions I wanted. This is also handy as it still preserves the old generic model in case you want to go back to them later.
There are three files that need to be worked on here :
1) /usr/share/X11/xkb/keycodes
This is where the MODELS are stored. A model defines what code refers to what location on the keyboard. If this sounds complicated, that's because it is. For example, when a key is pressed code 23 may be generated, the MODEL file changes this code into an alias...in this case AD01.
2) /usr/share/X11/xkb/symbols
This is where the LAYOUTS are stored. A layout defines what alias (defined in the keycode file) makes what key to print on the screen. In the above example code 23 = AD01 = letter Q.
The idea is the model should be regarded as a type of keyboard, and the layout regarded as the region or language. The whole process is long winded and complicated, especially when you're working it out with no instructions !
It also has one last twist to the tale. The reason why people said it was impossible to re-map keyboards by editing these two files is because they missed a quirk in the last file...
3) /etc/default/keyboard
This file tells the Pi what model and layout to use. It is imperative to understand that if these values do not change in this file, then a new keyboard will NOT be compiled. People were editing the model and layout files and wondering why nothing had changed, believing it didn't work. However, by studying the Pi's startup process you could tell that when you changed the 'keyboard' file the Pi took longer to boot. This lead me to believe that in order to generate new keyboard maps the file names of the model and layout would have to be changed in the 'keyboard' file every time you made a change / edit.
This is indeed the case, the easy way was to make a re-named clone of the model and layout files and alternate between them when testing, that way the Pi would always re-generate the keyboard maps using your trial and error values each time.
Confused ??!!
I'd be annoyed if you weren't !
It's extremely hard for me to put this into words, it's long winded and a weird way of programming the keyboard if you ask me, BUT it does work. Through this you can generate the Spectrum ZX keyboard very accurately, it loads instantly and is widely customisable.
The keyboard membrane functions to short out two pins to generate the keystrokes. The Spectrum uses 5 and 8 pin connectors, therefore 5x8 = 40 key combinations are possible. The first job was to integrate the spectrum membrane into a USB keyboard which could be used with the Pi.
Once this was joined together a complete key-map can be determined by pressing the keys on the membrane and seeing what keystrokes are generated by the Pi and putting them into a spreadsheet for reference :
The greyed out keys are what the Spectrum keyboard 'should' print, the red keys are what actually prints on the screen. As can be seen the map is a complete mess, ??? denotes a function of the Japanese standard keyboard of all thing. No matter, all that is needed is the key codes from this reference.
When a key is pressed, the computer simply reads it as a code. For example key A may be code 65, B is code 66, C is code 67 and so on. All that needs to be done is tell the computer code 65 no longer means A, it means something else. It's a bit like taking the keys off the keyboard and rearranging them, but doing it on a software level.
This is where things get extremely tricky...
Everyone I have seen at this stage use a program on the Pi called xmodmap to fudge the keyboard. It has to be run as a script or manually on every boot and takes a long time for the Pi to compile, from what I have seen it also does not fully emulate the Spectrum's keyboard nor does it run in Linux's command line interface (shell). I wanted a more professional feel to my Spectrum Pi so I wanted to totally edit or create a key map so it worked on all levels.
This is a lot harder than it seems and there is scarce documentation on the subject requiring less than a computer degree to make sense of !
Firstly I tried to re-program the existing generic keyboard map the Pi uses, unfortunately this has no provision for a SHIFT + Function key and I need this to generate some capital letters and symbols. I also struggled to define some of the Japanese function keys stated above and it looked like this method not going to be possible as a lot of people had stated on forums.
However, not to be beaten, using another 'model' (eg the Commodore Amiga) of key maps allowed me to generate the functions I wanted. This is also handy as it still preserves the old generic model in case you want to go back to them later.
There are three files that need to be worked on here :
1) /usr/share/X11/xkb/keycodes
This is where the MODELS are stored. A model defines what code refers to what location on the keyboard. If this sounds complicated, that's because it is. For example, when a key is pressed code 23 may be generated, the MODEL file changes this code into an alias...in this case AD01.
2) /usr/share/X11/xkb/symbols
This is where the LAYOUTS are stored. A layout defines what alias (defined in the keycode file) makes what key to print on the screen. In the above example code 23 = AD01 = letter Q.
The idea is the model should be regarded as a type of keyboard, and the layout regarded as the region or language. The whole process is long winded and complicated, especially when you're working it out with no instructions !
It also has one last twist to the tale. The reason why people said it was impossible to re-map keyboards by editing these two files is because they missed a quirk in the last file...
3) /etc/default/keyboard
This file tells the Pi what model and layout to use. It is imperative to understand that if these values do not change in this file, then a new keyboard will NOT be compiled. People were editing the model and layout files and wondering why nothing had changed, believing it didn't work. However, by studying the Pi's startup process you could tell that when you changed the 'keyboard' file the Pi took longer to boot. This lead me to believe that in order to generate new keyboard maps the file names of the model and layout would have to be changed in the 'keyboard' file every time you made a change / edit.
This is indeed the case, the easy way was to make a re-named clone of the model and layout files and alternate between them when testing, that way the Pi would always re-generate the keyboard maps using your trial and error values each time.
Confused ??!!
I'd be annoyed if you weren't !
It's extremely hard for me to put this into words, it's long winded and a weird way of programming the keyboard if you ask me, BUT it does work. Through this you can generate the Spectrum ZX keyboard very accurately, it loads instantly and is widely customisable.
New Plumbing
After cutting a new inspection panel with the multi-tool I managed to damage the old copper pipework which had been laid directly under the floorboard join as opposed to in the centre line making damage almost inevitable.
Re-plubing and soldering this in copper neatly was to be expensive and arduous due to the cramped and poorly planned layout so I decided to try plastic heating pipe.
This is made by a company called Speedfit and it's very cheap and user friendly, I really like the ability to manipulate the joints after fitting - I would thoroughly recommend it.
I did have to do a few solder and compression joins but thankfully I could prepare them on the bench and then fit the pipes in place afterwards. Overalls it's a cracking job.
Re-plubing and soldering this in copper neatly was to be expensive and arduous due to the cramped and poorly planned layout so I decided to try plastic heating pipe.
This is made by a company called Speedfit and it's very cheap and user friendly, I really like the ability to manipulate the joints after fitting - I would thoroughly recommend it.
I did have to do a few solder and compression joins but thankfully I could prepare them on the bench and then fit the pipes in place afterwards. Overalls it's a cracking job.
Subscribe to:
Posts (Atom)