Anyway, apart from a few projects on the go the last couple of my weeks have been dedicated to reverse engineering an old MS DOS schematic capture file format. I am not one to look for obscure file formats to break apart and so there is a motive behind this relatively tedious project.

On the motivation behind this relatively tedious project

Like most other beings I spend my days doing work, though unlike the larger portion of other beings part of my work requires electrical system schematics to be drawn. Well, perhaps there is a fair sized portion of employed people using schematic capture software but what makes my experience unique is that its done in an MS DOS program called Protel Schematic V3.31. For those who are thinking, so what?! Its 2011, that’s what! And, my knowledge of MS DOS history is pretty pour but by the time I could use a computer Microsoft had moved onto Windows 98. Though, with that said I understand that there are many companies out there using antiquated technology and, perhaps it’s for the simple reason that they are tools that work and are easy to use.

If the system ain’t broke don’t try to fix it and its true, why churn out thousands of dollars to replace a tool that all your staff are trained on and can use efficiently? The answer in this case is that Windows 7 won’t run Protel Schematic V3.31 with out running it through an emulator of some kind.

Since its debut in the 80s Protel, an Australian company, has been bought out by Altium who promptly put a stupendous price tag on their line of EDA software currently called “Altium Designer 10″. Even though it does open old Protel files it would be of no use to you because you have just sold your liver and three of your kidneys to get a license that lasts only a year.

There are plenty of cheap options out there, though trying to find one without all the bells and whistles is hard, since we do system design and generally don’t get down to circuit level and PCB design and testing. After some searching I found KiCad, its not too ugly to look at and, its free which means as I pryed apart the layers of Protel schematic files I had a format to convert it too. The beauty of KiCads’ schematic file format is that its ridiculously simple to interpret and since it’s in plain text, if you got your geek on and neglected life for a bit, you could write your own schematic by hand.

This has been my first real experience with the process of reverse engineering and so this article is going to serve the purpose of passing on the things I have learned, as well as break down and document an otherwise undocumented Protel Schematic V3.31 file format.

On reverse engineering and using your head

Two factors in this process of reverse engineering have made my life easy, for one I have the software that generates the file format, secondly the format that I am converting to is well documented. Having the software to generate the file format means that you can control the data stored in the file, take one of our large system schematics for example; it contains a couple of hundred lines, junctions, text labels, a document box and components, that’s a lot of bytes to process.

One tool that will be invaluable is a decent hex editor, on windows I use 010 Editor and on the mac I use hex fiend (pretty basic but it works).

I began by opening up the schematic file in the hex editor which shows gibberish nonsense when looking at it in ASCII and plain text. Having a split screen of the file, one side translated in ASCII and the other in hex helps pick out patterns.

ASCII will encode what it can into characters and in some parts of the file  words are formed which gives clues at to what is contained in that section. It allowed me to pick up where labels and components were located in the file.

HEX is a base16 numbering system using 0-9 and A-F, so instead of trying to find patterns in large amounts of binary it it stores groups of 4 bits as a single value.

With that initial formatting done large blocks of data stand out and it is easy divide the file up into its patterns and start to get a grasp on how the file is structured.

As I mentioned before, having the software that creates the file format allows you to have control over the data that is stored and so, by saving a blank schematic you can see what data is related to the document setup, formatting and what is used to define the other objects on the page.

On Ruby and processing files bit by bit

Using Ruby to write the file converter made things simple since it has some useful tools for reading data byte by byte.

Initially with when loading the file into Ruby we set it to binary mode, this means that it won’t be automatically encoded or use any ASCII newline commands that may be in the file and also reads the file as ASCII-8BIT. This is done using the File subclass of the IO class.

schematic = File.new(ARGV[],"r")
schematic.binmode

The IO class also provides us with another function called seek and this allows us to jump to certain locations within the file, as well as remember its current location.

In the example given below, I have found out how many bytes in size the header information for the schematic file is (16 bytes), so using the seek function I move past it and then read the next 16 bytes of data.

#our position within schematic is 0
schematic.pos  #=> 0
header = 0x10
schematic.seek(header, SEEK_CURR)
schematic.pos  #=> 16
schematic.read(16)

The next part to this article is going to be a break down of the file format and other technical stuff such as that…

The question is this: how can I route using, instead of a unique id, a different column in a set of data.

Say, for example I have a table with the columns id and name and both are unique. The data contained in my table is:

The default routing would be as such:

http://localhost/users/1

But what I am after is this:

http://localhost/Fred

How is this done? After playing around here is what I came up with:

Open the routes.rb file and add the line:

map.connect ':name', :controller => 'users', :action => 'show'

So we are passing the parameter :name to our show action in the user controller. Now we need to modify our users_controller.rb to accept this parameter.

def show
@user = User.find_by_name(params[:name])
end

And that’s all there is to it. Look up the Ruby on Rails API for more information on the find_by_ function

I haven’t had much experiance with ruby on rails so if I have said something that may be a little misleading make sure you let me know!

If you have no idea what Ruby on Rails is see: http://rubyonrails.org. 

Having been introduced to Rails many moons or perhaps about 2 years ago, it had always remained concealed behind a cloud of mystery for myself and as I developed websites for different clients using mainly PHP scripted Content Management Systems I didn’t feel the need to waste time and learn how to use it.

Silly me?

Perhaps so, though at some point there comes the urge to write a new system alot simpler than those systems such as Joomla! or others like it, a system that is tailor made to clients needs and not overloaded with features that have no relavance or are perhaps useless.

Time to removed that cloud of mystery … Enter Ruby on Rails.

Setting Up Rails

I currently am using Mac OS X Tiger 10.4 so I set out to find information on setting up Ruby On Rails.

A brilliant tutorial which has pretty much got me set was from hivelogic:

http://hivelogic.com/articles/view/ruby-rails-mongrel-mysql-osx

Though now with new updates and other current changes there was a few things that triped me up.

• In the Paths section of the tutorial you will see that you are to edit the .bash_login file so that terminal looks in our /usr/local directory though I found when I entered ‘ruby -v’ into terminal it was still showing my old 1.8.2 version of ruby. After scratching around some time on the internet I found that I would actually need to edit .bash_profile instead of .bash_login for terminal to recognise a new path.
• When installing the MySQL native bindings gem using the gem install method it was downloading yet failing to build, again I scratched around the net for a bit and found that due to Ruby Version 1.9.1 I would need to get the latest version of MySQL/Ruby and for some reason gems was only getting version 2.7 and the latest is 2.8 .1 (http://rubyforge.org/frs/?group_id=4550) so I downloaded that tar.gz file and installed it, tested and everything was looking great

I haven’t bothered installing a http server for Rails yet as I am just using the one packaged.

With everything installed, the fun begins…

More on Ruby On Rails comming soon!

The background matte was made in Photoshop and the model in Blender. If you’re interested in getting into 3D modeling or animation I recommend checking out Blender, you can find it here: www.blender3d.org .

Also I’ve just setup a new CG Portfolio section as well so I’m hoping on expanding that as well.

Enjoy!

So… here it is!

Now when dealing with constant processing of input or output data and in my case it is data being received, as well as a graphical user interface you are asking ruby to do two things at once. In the general scheme of things it is not what simple old ruby does, all it knows is to run through a series of instructions and then either loop back over those instructions or terminate, that being said with exceptions. So let me now introduce threads.

Ruby threads, without going into to much detail, allow multiple processes to run parallel to each other. So I needed ruby to not only be managing the GUI but also receiving and processing I/O data and thus the use of threads.

Setting up a thread is quite simple:

And you can find more information about them in the ruby core libraries documentation, see here.

Like the rest of my programs featuring GUI’s I have a soft spot for FXRuby, and I really don’t know why but I think it is mainly because it works, strangely enough. To allow me to update each piece of information (speed, altitude, etc.) I used FXRuby’s Data Targets which I setup to be updated from within the threaded receiving process.

All in all it is a pretty straight forward program but there are still plenty of loose ends needing to be tied up before I can call it a completely finished. It doesn’t even fulfill its intended purpose yet so there is plenty more to do.

If anyone is interested in the complete ruby code post a comment (with your email address) or send me an email and I will forward it on to you.

Stay tuned for more!

The idea of using these three programs is to get real time data from a flight simulator program and then process and output it through ruby. Also a future goal is to be able to send data  to control different systems while in flight through external components.

The following post contains information on FlightGears .xml protocols and configuring the simulator to output data through a socket. Also two scripts in Ruby and IronRuby which gets data from FlightGear and displays it.

Please also note that you will find that some information I give is similar to what is given at http://linkslink.wordpress.com/takeoff/ as I used the information as a guide when I was learning about the .xml Protocol files and has led me to some handy .Net libraries when using IronRuby.

Only last week IronRuby and FlightGear were unknown to me as I scowered through the immense achieves of the internet looking for any reference to Ruby being used to acquire data from Microsoft Flight Simulator X. But in the true spirit of Microsoft to even get access to the SDK you needed to have purchased the deluxe edition of FSX and perhaps I was aiming a little high with the Ruby side of things. Yet in my search I came across a very interesting project called IronRuby.

IronRuby allows ruby integration with the .Net libraries and you can get more information about it here: http://www.ironruby.net/ . Previous to using IronRuby I had been barely able to write a simple C# program but now things seem to make more sense. If anyone is interested I would recommend checking it out.

In the end I gave up on Microsoft Flight Simulator when I found FlightGear (http://www.flightgear.org/) which is quite a nice open source flight simulator project and I look forward to being able to do some work on the source code of my own as I have a few ideas I would like to try out in it. Anyway I digress.

Getting Data from FlightGear

FlightGear provides a relatively easy way to access information about the aircraft and other environmental variables in realtime through a number of different methods of communication. These are either through a TCP or UDP network socket connection, serial connection or by writing a file to the hard drive which can be updated at a specified amount of times per second.

For my purposes the socket connection method is the most practical so this is what I will be covering here. Before I go into setting up this output method an important thing to understand is what format the data will be outputted in and exactly what data is going to be outputted. FlightGear uses .xml files to control how data is sent or recieved through a socket connection and what data it is. These files are kept in \data\Protocol file which is in the FlightGear directory, also a document I recommend you read is kept in the \docs file which is called README.protocol, it goes over how a general .xml protocol file is setup but I am going to cover it briefly here.

.xml Protocol Files

The basic structure of the .xml Protocol files are as follows:

<?xml version=”1.0″?>
<PropertyList>
<generic>
<output>
<line_separator>newline</line_separator>
<var_separator>|</var_separator>

<chunk>
<name>speed</name>
<type>integer</type>
<format>%d</format>
<node>/velocities/airspeed-k</node>
</chunk>

… Have as many output chunks as you desire …

</output>
</generic>
</PropertyList>

The <output> tag it can be replaced with <input> but I am not going to be covering that at this time so the first important things to look as is the <line_separator> and <var_separator> tags. These, as their names suggest determine how the chunks of data are to be separated. In this case after all the chunks of data have been sent it then starts on a newline when it goes to send the data again, but as each chunk of data is sent it puts a | between them so we can determine where a chunk begins and a chunk ends. <chunk> tags define what data to print by giving, <type>, <format> and <node>.

The <name> tag doesn’t get sent and is simply there for us old humans so we know whats what. Also there are other tags that can be put within a chunk and you can find more information on them in the README.protocol file.

<type> defines what type of data the chunk is, types that can be used are things such as: integer, string, boolean and float. <format> pretty much speaks for itself, and is similar to the job of <type> yet has more functions.

<node> defines the location of the chunk of data and the easiest way I know of so far of finding this information is by doing the following setup in Advanced Options in flight gear, starting up the game and then minimizing out of the game, opening a web browser and going to 127.0.0.1:5501 or localhost:5501.

For the Ruby and IronRuby examples I give here I use following .xml Protocol file:

<?xml version=”1.0″?><PropertyList><generic>

<output>
<line_separator>newline</line_separator>
<var_separator>|</var_separator>

<chunk>
<name>speed</name>
<format>%d</format>
<node>/velocities/airspeed-kt</node>
</chunk>

<chunk>
<name>heading</name>
<format>%02d</format>
<node>/orientation/heading-deg</node>
<factor>57.29578</factor>  <!– radians to degrees –>
</chunk>

<chunk>
<name>altitiude</name>
<format>%02d</format>
<node>/position/altitiude-ft</node>
</chunk>

<chunk>
<name>rate of climb</name>
<format>%02d</format>
<node>/velocities/vertical-speed-fps</node>
</chunk>

<chunk>
<name>pitch angle</name>
<format>%05.1f</format>
<type>float</type>
<node>/orientation/pitch-deg</node>
</chunk>

<chunk>
<name>bank angle</name>
<format>%05.1f</format>
<type>float</type>
<node>/orientation/roll-deg</node>
</chunk>

<chunk>
<name>engine</name>
<format>%02d</format>
<node>/engines/engine[0]/rpm</node>
</chunk>
</output>

</generic>

</PropertyList>

Configuring the Output of FlightGear

FlightGear then needs to be configured so that we can get an output from it using our .xml protocol. This is quite easy to do as you can either do it through a command line or through the FlightGear Wizard GUI which I show here.

Notice that the Generic field allows you to select the .xml Protocol file.

Getting FlightGear to talk to Ruby

Now this is pretty straight forward as Flightgear sends its data in an ASCII coding, though you can change that to binary if you wish through the .xml Protocol files. In Ruby all we practicly have to do is setup a TCP server and listen for FlightGear on a specific socket. When it connects we then split the data up into an array and this allows us to show only the data we want.

This Ruby program simply prints the recieved data, so it isn’t very special but basicly a foundation for better things to come… assuming they will come.

require ‘socket’include Socket::Constants

socket = Socket.new(AF_INET, SOCK_STREAM, 0)
sockaddr = Socket.pack_sockaddr_in(5500, ’127.0.0.1′)
socket.bind(sockaddr)
socket.listen(5)

puts “Server Started. Waiting for connection from client…”

while (FgClient  = socket.accept)
puts “Client Connected, getting data…”
loop do
rawData = FgClient[0].readline
data = rawData.split(‘|’)
puts “Speed = #{data[0]}”
puts “Heading = #{data[1]}”
puts “Altitude = #{data[2]}”
puts “Rate of Climb = #{data[3]}”
puts “Pitch Angle = #{data[4]}”
puts “Bank Angle = #{data[5]}”
end
end

Getting FlightGear to talk to IronRuby

And here is practically the same thing in IronRuby though I haven’t put the received data through any formatting so that you can see how the data is sent from FlightGear.

require ‘mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=x86′
require ‘System, Version=2.0.50727.42, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL’

#call on the different classes required within the .Net framework
tcpListener = System::Net::Sockets::TcpListener
networkStream = System::Net::Sockets::NetworkStream
streamReader = System::IO::StreamReader

ipAddress = ’127.0.0.1′
port = 5500

#Parse IPAddress
localAddr = System::Net::IPAddress::Parse(ipAddress)

puts “FgACS >> Starting FlightGear Aircraft Control Server…”

#Start TCP Server
FgServer = tcpListener.new(localAddr, port)
FgServer.Start()#ToDo: need to check to see if server already started before starting new one.

puts “FgACS >> Server online. IP Address: #{ipAddress}, Port: #{port}”
puts “FgACS >> Waiting for FlightGear Client to connect…”

FgSocket = FgServer.AcceptSocket()

puts “FgACS >> FlightGear Client Connected Successfully”

FgStream = networkStream.new(FgSocket)
readStream = streamReader.new(FgStream)

while FgStream.CanRead do
$receivedData = readStream.ReadLine()
puts “#{$receivedData}”
end

In Conclusion

There is a multitude of more information I could add to this post but as I see it that information is very easy to get your hands on and doesn’t really need repeating here so use your head an you will be able to fill in any of the blanks I have made. There is still so much more I have to learn in this area and as I see it this is just the very tip of the iceberg.

Perhaps ruby is not the way forward if you are looking from a consumers perspective but I found that it makes building up a prototype of an idea or trying something to see if it will work so much more quicker and easier.

I hope some of you find this post of some interest!

Enjoy!

Anyway by now you are asking why I named this post The Bench-top Power supply so I’ll get straight to the point: I needed something to do… so I made a Bench-top Power Supply. There are plenty of other things I could of made which would have been much more stimulating and interesting but the fact is having a variable power supply is so handy and I would add a few small features which I find come in handy.

I have used a standard step down transformer (240 VAC to 15 VAC), a bridge rectifier kit and a voltage regulator kit from Jaycar (www.jaycar.com.au). So thats the basic idea to a power supply, I then added terminals to plug in a dc supply to be regulated (i.e. Car battery) and a toggle switch to select between the ac and dc sources. I then added a tie switch which allows the power supply to be either floating, positive tied to earth or negative tied to earth. Call me lazy but it saves the extra wire to do the tying for you.

I hope to be a little more frequent now with this blog but no guarantees as I’m coming to the end of my avionics course so I’m a little busy. Anyways, Enjoy.

So what is the digital harp? Well the idea evolved from a thought train of creating a dynamic and complex music instrument that could be controlled by the fingers yet while not touching a single string/key/button/pie and produce a vibrant and beautiful sound. So after a bit more thinking I came up with a compromise to my ambitious thoughts and
managed to bang together a digital harp consisting of four “digital” strings, a ukulele and a very very simple synthesizer.

So very simple.

Using four LDRs and a voltage divider circuit which a transistor sensing the increase in voltage drove a solid state relay I was able to create a very small and easy control circuit for when a hand moved in front of the LDR and blocked its light source from the laser.

I created the oscillator using a 7414 chip which is a Hex Inverter with Schmitt trigger inputs and put a resistor in between the input and output legs and a capacitor. This oscillator provides a square wave output, unfortunately square waves don’t produce the best quality sounds but for this project it worked okay, though if you have the time and the parts I would recommend building a sinusoidal wave oscillator as they sound a lot better.

I setup four of these oscillators for each of the digital strings and then their outputs into the one amplifier.

This is the square wave oscillator setup:

Then its just fitting everything together onto the ukulele which was basically done using a hot glue gun. I removed the nylon strings and tuning pegs, put a on/off switch on the side with a LED… its not a real project if there are no LEDs, and fixed a 6.5mm audio socket to it as well so I could plug it into my guitar amplifier.

I haven’t drawn up an official schematic yet but I do plan to in the near future… if anyone is interested in it let me know, it might just help with motivation.

There are a few little problems with it at this stage but it is practically working as expected and is a great little tool to annoy friends.

Until next time!

I built it from the schematic from this website: http://jap.hu/electronic/combination_lock.html:

The hex and asm code can also be downloaded from the website to program the pic with. For this initial setup of the combination lock i made a few modifications to the design which involved taking out the 5v regulator and replacing it with a 5v1 diode, removing the relay and transistor setup and replacing it with a simple L.E.D and also getting rid of LED1. The crystal I used was a 3.578 MHZ crystal. The main purpose for all this is just to make sure the PIC is being interfaced with the keypad correctly and is acknowledging a password being entered in and being able to change its password stored in its memory. Which, believe it or not – works! <insert a little dance here>

So now that everything looks dandy on a basic level the goal is to have a combination lock that is interfaced with a computer, allowing a number of parameters of the lock to be changed via pc as well as passwords and a log of what has been entered on the keypad and any successful or unsuccessful entry attempts. Anyway thats hopefully where things are heading!

Stay tuned for more mystical, world domineering and pointless projects.