Group Actions
Engagement
  • Author Author: phoenixcomm
  • Date Created: Date Created
  • Views 553 views
  • Likes 3 likes
  • Comments 4 comments
Related
Recommended

Flight Simulator 101 or back to college - part 5.2: Protocols

phoenixcomm

Ok so here is a map of our simulator:

image

  • A small network.
  • The CDU.
  • The IO Processor #1.
  • The Simulation Processor.
  • A block diagram of the arduino and what's it doing.
    • Interfaces to the display controllers via I2C.
    • Ps2 keyboard Interface.
    • The switches via some custom hardware.
    • USB virtual serial port.
    • Client Software.
  • A Virtual Serial Port, from the arduino to the IOP#1.
  • The Host software running on IOP#1

 

The Client Software running on the arduino duemilanove will use a one byte protocol. Valid data can be any 7 bit ASCII character or one of four (4) switches and its associated BCD data value.
arduino 1 Byte Protocol to Host
Bit 7Bit 6Bit 5Bit 4Bit 3Bit 2Bit 1Bit 0
0Valid 7 Bit ASCII Character (Keyboard)
1000BCD from Mode Switch
1001BCD from Display Switch
1010BCD from DEST thumb wheel
1011BCD from FLY-TO thumb wheel
11xxData Not Valid

 

When Host Software running on the IOP receives a keystroke (one byte at a time) from the arduino the host shall respond with a 4 byte message which has the following format:

 

Host 4 Byte Protocol to Client (arduino)
Byte 0Byte 1Byte 2Byte 3
START BYTEDispaly - DigitASCII CharAttributes
FF0010 - 0011360

 

  1. Is the START Byte this will contain a hex FF.
  2. Has two (2) nibbles which are encoded:
    1. Is which display you wish to write to: Target,  Left,  Right,  Center,  Both,  LED.*
    2. Is the digit to be displayed (with 0 offset)
  3. Is the DATA for the display position selected (ASCII).
  4. Is the attributes. Such as BLINK, Lamp Test, Cursor, etc. #

 

NOTE: * This should be a enumerated list with a 0 offset.

NOTE: # In this blog I will not go into the various attributes.

NOTE: This format is all so used when the CDU is listening to network traffic for updating the display with various parameters, such as Network Time, Stored Locations, Time To Destination (DME), etc.

 


NOTE: This blog eludes to communications between the Host Software and the Simulator, I have chosen not to talk about it at this time.

 

 

image keep tuned in more to come

Cris ~

 

AFTER THOUGHT: This system was designed using an arduino duemilanove. I am now writing code on a stellaris armRegistered LunchPad module to see if I can move the HOST software to this platform as well.

  • in reply to shabaz
    • The 4 switches 2 are BCD encoded thumb wheel switches, the rotary switches I use a 7->3 priority encoders, and a a 4->10 decoder for my address decoder. I use Tri-State buffers to switch the right switch to the bus ( that takes 4 quad packages), so my total parts count is 7 packages.
    • I chose a ps2 keyboard to handle my small keyboard (the controller is free) and the protocol is ubiquitous, and only cost me 2 I/O lines vs using the keyboard matrix input of my display controller, and that is a bit messy..
    • USB is good for 2 meters vs RS232 but then I would need a MAX level shifter, and Ethernet the overhead (software burden), is expensive, and besides this a point to point protocol.

    One more thought I don't do well with surface mount in my prototyping phase, and besides I just love wire wrap, (not manual) and  I have all the tools, and wire for the jobs, I have been using them for years...

  • in reply to phoenixcomm

    Hi,

    Just as an idea which maybe you are already considering, I find the I/O expanders (like PCA9535) quite nice for thumbwheel/rotary switches etc - they have an open drain interrupt pin, so there is no need to poll to check until there is an interrupt. If the keypad is not multiplexed, it might also replace a PS/2 controller, if you can read fast enough to keep up with key presses (I've not tried that).

    Also, maybe the USB is not needed (if it is removed then the raw serial could also be transported over the network in future if you needed to separate the control panel from the IO processor #1 by a long distance (I'm no expert, maybe there is no use-case for long distance in this application).

  • Hi Chris,

     

    Have you thought about defining your test issues as you go along?  I know a lot of members have not seen the process of taking your requirments into a test plan.  Could be a useful blog.

     

    Just a thought,

    DAB