On the left: JTAG connector, crystal, reset chip, ATMega32 controller.
In the centre: USB device controller (not yet wired up).
On the right: Display controller, 7-Segment displays, Incremental Encoder.
Short video showing the unit in action.
The goal of this (hobby) project is to develop a human interface controller that interfaces with a flight simulator in order to manipulate cockpit instruments and to display cockpit values. Parameters that could be included for manipulation are:
The final unit has in the order of 20+ 7-Segment digits to display values and a number of incremental encoders to decrease/increase values, plus some tactile switches to toggle some options. Communication to the PC is via USB (Low-Speed) with the device representing a HID-Class device (Human Interface Device).
The prototype board only has four digits wired up to the display controller (the controller can drive up to 16 digits). The only tactile switch is the one integrated into the single incremental encoder. The display controller also scans a matrix of switches and interrupts the CPU when any switch is pressed. An Atmel ATMega32 controller is used here. For the final unit it would be of advantage using a micro controller with a built-in USB interface. Alternatively a separate tiny micro controller could implement the USB physical protocol layer in real-time in software (Low-Speed only/1.5Mbps).
|
On the left: JTAG connector, crystal, reset chip, ATMega32 controller. In the centre: USB device controller (not yet wired up). On the right: Display controller, 7-Segment displays, Incremental Encoder. |
Short video showing the unit in action. |
In Europe most digital clocks sold these days receive the exact local time from a LW radio station that gets its time from an atomic clock, which provides the exact official time for a region. However, the reception range of those radio stations is only in the range of 1000...2000km. Being very far away from these and being in a different time zone than these, a slightly different solution is required.
The GPS satellites broadcast UTC (Universal Time Coordinated). Their 'UTC' differs bit from the real UTC as leap seconds are not taken into account. These leap seconds accumulate over the years and decades. However, the number of missing leap seconds is also available, so the real UTC can be determined.
Once UTC is known, the local time can be determined by knowing the location (offset from UTC) and by knowing the date (daylight savings time or not). One then only has to use these inexpensive European radio controlled digital clocks (they cost as low as approx. AUD$15) and mimic the transmitter that they are designed to listen to in order to synchronise their time a few times a day. A very low transmission power (milliwatt(s)) only should be sufficient to cover one's house.
 This is the same board as for the KVM project below. |
 One of those inexpensive radio controlled digital clocks. |
Existing KVMs one can buy often only support VGA ports, no DVI or HDMI. They also only support either everything PS/2 or everything USB.
There are now a few KVMs that also switch DVI, however, this is often limited to lower resolutions such as max. 1280x1024 as otherwise the signal frequency on the DVI links becomes too high for the cheap switch circuitry and signal quality deteriorates (signal integrity).
Another desire for me is being able to use my IBM PS/2 Buckling Spring Keyboards that have a PS/2 connector only. I have tried PS/2 to USB converters and while some seem to work, they have problems with some keys or key sequences. One that I tried did not support ctrl-break for example. How much testing have they done ?
So on the keyboard side I want to use PS/2 but the computer side is all USB or at least will become USB only (some machines do no longer have legacy PS/2 ports). In a first stage I want to be able to switch the keyboard between multiple computers and soon thereafter the single mouse. Switching DVI requires more effort (PCB layout and necessary MUX chips) so this will be later.
The prototype board has an Atmel ATMega32 controller, a USB controller (device only), some logic (GAL) and a few extra components for the PS/2 port and the USB port. An LCD is connected to help with the debugging since the controller's serial port is needed for the PS/2 interface.
The final unit will need one USB host controller (for the mouse) and e.g. four (one for each workstation) USB device controllers to present mouse and keyboard to each workstation.
Ideally, audio should also be switched, both for line out and microphone in.
|
|
 |
| On the left: bottom: JTAG connector, centre: ATMega32 controller, crystal, reset
chip, top:PS/2 connector. In the middle: GAL 20V8 (glue logic). On the right: centre: USB device controller, connector for LCD (128x64), top: USB socket. A few extra components for the PS/2 port have not yet been added as is the case for the USB port too. This board will also be used for the above project (atomic clock time distribution) where the GPS module sends its NMEA protocol data to the serial port. The LCD serves for debugging/monitoring purposes. |
The LCD is a graphical one with 128x64 Pixels. It does
not have any built-in character generator. For this photo the
microcontroller runs a test program filling the graphics memory of the
LCD with characters from the character generator that is part of the
data stored with the program in the microcontroller's flash memory. (You can see that the last two or three characters at the bottom right corner seem to be in transition. This comes from the fact that the LCD was cold when I took the photo and hence the liquid crystals are slow in turning.) |