Control 7-Seg Groups From Parallel Port

I'm working on a flight sim cockpit project and want to build 2 Nav/Com Radios, ADF Radio , And Transponder to simulate a Cessna 172SP. The sim software I'm using has offsets that I can program to the parallel port. That part I think I can handle. My question is can someone help me with the electronics side of this project (schematics, what parts to use, etc...?) I have an electronics knowledge of that of a flea, :lol:

I've done some research but one area I'm having a hard time understanding how to take the 8 ouput lines from the parallel port and routing it to approximately 10 groups of 4-5 digit 7-segment leds. (Each group is a separate frequency)

My thinking is that I can get away with 4 digits because the first digit in all the Nav/Com units will always be one and there will always be a decimal between the 3 and 4th number. I would imagine this could just be hardwired to always be on.

Com Range: 118.00 to 136.975 Mhz In 25Khz Increments
Nav Range: 108.00 to 117.95 Mhz In 50Khz Increments
ADF Range: 200KHz to 1799 KHz in 1 KHz increments
Transponder Range: 0000 to 7777


The other area would be the knobs and buttons to change these frequencies.

If anyone is interested in helping me tackle this project, please feel free to email me.

It seems like you are going to have to develope your own protocol..
what i mean is the hardware needs some way to distinguish what data is going to go to what Display..
a 3x8 decoder can route the data to each display
there is a million ways to do this that is the problem..

ok right from the start .. do you have the ability to ' Talk ' to to parallel port , without any interference from an intermediary program..
or put another way
what is going to be sending the data to the displays??

Hi Willi-

Data would be sent to the display by the knobs and switches on the iradios. The radios could send the data to the parallel port where I can write a program to read it and interpret it and set the necessary frequencies in the flight sim program. Or... the software I write will read the values from the flight simulator software and send it to the parallel port to update the frequencies on the display.

To be honest, I don't really know what the best way is. It seems it would be best to have the knobs and switches on the physical radios control the displays and send the data to the parallel port for faster updating. The other way I think could be a little slower.

There is a program called FSUIPC that provides the offsets from MS-Flight Simulator. Using the SDK I can interface with that.

that provides the offsets from MS-Flight Simulator

Click to expand...

what do ya mean by offsets?

These are some offset examples from the program. If I read offset 0x034e from the program, it might say 2345 (For the nav/comm radios it excludes the 1 because it is always 1). So the actual frequency would be 123.45. I can port to/from the parallel port this data. Does that make any sense???

Offset Size (in bytes) Description
0x034e 4 COM1 frequency
0x0354 4 Transponder code
0x3118 4 COM2 frequency
0x3122 4 Radio flags (which radios are turned on, which
is transmitting)

ok , so at location 0x0354 in pc memory is the location of the transponder code..
right?
i get ya..

once you get your data
This is how i would do it using Pascal

PORT[$3F8]:= $FF
But windows wont let you talk directly to the parallel port..
you have no idea how many times this comes up in discussions..
people trying to use the parallel port and windows blocks the use of it..
anyway when you get your data how will the SDK output it?

I don't have a problem with the programming. I can take care of that. I just need help designing the circuity, etc...

FLPilot said:

I don't have a problem with the programming. I can take care of that. I just need help designing the circuity, etc...

Click to expand...

thats what i am trying to say..unless i know how the sdk is going to output the data , it is pointless to try to design an interface..

Do you mean what format it will output the data in? Binary, Decimal, etc...?

FLPilot said:

Do you mean what format it will output the data in? Binary, Decimal, etc...?

Click to expand...

sort of..
what i need to know is how the SDk will output the data..
Specifically when it is outputting say 2345 ..
how will you distinguish which display is to receive 2345..
and which display is to receive another value..?
this gets back to the protocol question..
if you can output a three bit value designating which display the data is to go to that would be a start..

it might go something like this..
you send an eight bit value value out to the parallel port..
three of those bits I can decode
once decoded i will know that the next four characters are going to display X..
then you send the four chars ..
then you send another control byte with the info i need to know where to send the data..

so it would go::
Control byte
first digit ..
second digit..
third..
and fourth..
control byte..
ect..

If I understand you right, then I'm thinking each display can have its own address. Then the program will listen and talk to those addresses when something changes. I think back to my audio/visual days about the DMX512 protocol used in the lighting industry to control dimmer packs. Each dimmer pack has a dip switch to give it a unique address. I was recently reading something about the I2C protocol, but don't know if that's the right protocol to use. I'm not familiar with the different protocols.

So... you turn the knob to change the frequency, it updates the display on the radio and then outputs the frequency using its identifying address and sends it to the parallel port. My program I write will read the identifying address and the value, process it and send it to the FSUIPC program which will update the simulator.

Those are my thoughts. I'm thinking, but could be wrong, there is no need for the simulator to send data to the radio stack only for the radio stack to send to the simulator.

Like I said in my first post....I really don't know much about electronics. Programming I think I have a decent knowledge that I can use to figure things out...but electronics to me is like a rat in a maze going in circles.
My heads been spinning since I first started thinking about this project!!!

Ex.
Display Address In Some Format
Com1 Active A0
Com1 Standby A1
Nav1 Active A2
Nav1 Standby A3
etc... A16

If I understand you right, then I'm thinking each display can have its own address

Click to expand...

Yes exactly..
did ya see my previous post..

Okay, is that what you mean by a 3x8 decoder?
3 bits signify the address
and then 8 bits to signify the value of the display?

Ohhhh, I think I need a drink tonight!!!!!!

FLPilot said:

Okay, is that what you mean by a 3x8 decoder?
3 bits signify the address
and then 8 bits to signify the value of the display?

Ohhhh, I think I need a drink tonight!!!!!!

Click to expand...

sort of..
the 3X8 decoder uses three values A, B , C are inputs..
Y0 through Y7 are the outputs Used to select which display to use ..
make any sense?
How many different sets of displays are needed?

**broken link removed**

Oooh, I've got to see the completed results on that! Can you get them to me once it's finished? I'd LOVE somthing like that. 8)

Rain

If I may interject something, take a look at the site **broken link removed**
In the "How To" section, there are 3 designs for printer port expansion data controllers you may find usefull to consider. The easiest to impliment is based on a 3 wire communication setup from the parallel port to 1 or more daisy chained 74HC595 serial to parallel shift register chips. Basically, a data pin from the parallel port is tied to the serial input of the 595, then the port is bit banged similar to I2C. Clocking and latching uses parallel port printer control lead outputs. This gives a large quantity of output points you can use to drive leds, relays or whatever you can figure out how to interface. For data read in, I am sure there is a complimentary chip out there that will do parallel to serial using the same basic strategy.
If you want even more speed, there are also 2 fully addressable parallel designs, but the build will be more complex due to the parallel busing involved.
Dialtone