the reason i am getting my friend to make it is because that stuff may as well be dutch cuz i still won't get it (i have no clue what you just said lol) but i have email my but the links from here and rsc, so hopefully he will be able to get something sorted
Hi all... first of all, sorry for my bad english...i'm italian...
I just want to know: what do i need for build this gear indicator?!?
- a 7-segment display
- a LPT
- some wire
- some led
- Resistors? (how many ohm)
- what else?
Sorry for this stupid question, but i'm not good with electronic things
That's OK. I'm working on a parts list and circuit diagram for the rev meter version at the moment but you can find all the info you need through Kada's site and links from there. Will post it as soon as it's done.
Here is my version of Kada's GI program, which incorporates a 5 LED Rev Meter. The first file is the program, the second is the source code. I have also attached a pdf (also included in the zip files) which has a circuit diagram and parts list for my gear indicator should you wish to make your own.
If you have any questions just give me an email or PM. Good luck!
Edit 20/12/07: New version for patch Y with support for the FBM and adjusted rev meter redlines.
Edit: 02/03/08: V1.1 Update by Kada including output for braking lights and reversing lights and some bug fixes. Thanks
Edit: 06/03/08 v1.2 Added output for "engine running"
Edit: 26/10/08: Mistake in PDF file corrected. Pin 10 should be connected to +9V.
I had a pm asking how to add a shift light, pit limiter etc...
There are only 12 outputs available through the parallel port. 7 are used by the Gear Indicator, which leaves 5. I have used all 5 for the rev meter. If you want to add more indicators (shift light, pit limiter etc) you would have to loose some of the rev meter LEDs. The wiring is the same, you just define the functions in the config.txt file of the GI program. You could then have say a shift light, pit limiter and a 3 LED rev meter, in which case I would recommend using the rpm3 rpm4 and rpm5 functions for the rev lights in the config.txt file.
So this works with pci-card that has parallel port? Or is there an expansion card that someone knows for sure works? It was said that works best with cards connected to ISA bus , but unfortunately new computers doesn´t have any of ISA -bus, neither parallel ports. Thats a bit sad becouse this is the coolest thing I´v heard for a long time and I definitely want to build one.
Well I haven't tried it with a PCI card parallel port so can't say for sure. I hope so because when I buy a new PC next year I'll need to try it. I think Kada and others may have used one, so that they don't risk damaging the PC if something goes wrong, so I think it would work. Maybe Kada can say for sure?
I have a Pci 1284 EPP/ECP Parallel card. When I ad the hardware to the port all the lights goes on, but thats it. No changes when running the game. I can´t even run the Parallel Port monitor program. It says Privileged instruction when I try to run that. Is it becouse the card is not the way it should or where the problem could be?
Do you have set OutGauge Mode 1 in cfg.txt? If you use Vista, you need the different version of inpout32.dll. Go to the Win32 folder and run InstallDriver.exe. I'll add a notice about it to the GI page soon.
Maybe you need to set a different LPT port in GI's config.txt, the number (default 0x378) can be found in Windows Device Manager. Look for the card and click "Properties".
Using KADA's code as a starting point, I just made a quick modification to send commands out the COM port instead of driving segments from LPT pins.
While this means that I need to talk to an external device that INTERPRETS RS232 commands, it gives me the flexibility I need to make more complex solutions.
For example, I have used a PARALLAX SX28 microcontroller listening on the cable attached to my COMPORT 1. The controller has a 16 Segment display for Gear Indicator.
See Image:
Clearly, an LPT port just won't do 16 segments, but the "R" does look like an "R" and the "N" looks like an "N" with this display... That was important to me. ;-)
When I finish this... (If I do finish... I guess I have to say) I could make the details available if there is interest and nobody objects.
I maintained as much of the original code as possible so I would not re-invent the whole solution.
The SX28 code is written in SX/B and is quite simple. The Microcontroller is really cheap (like US $3.00 each) unlike the BASIC STAMP which is overkill and maybe even bit slower.
Still testing prototype... so not much to show yet.
Of course! It really just depends where you want to do the "work" to make it work for you. I looked into a few options before deciding what to do.
1) You can swap the existing LPT commands for RS232 commands pretty easy... as long as you have a good RSR232 routine collection. (I have a working Bloodshed DEV-C++ RS232 collection so that part was already done in my case)
2) You would lose PINS on the Microcontroller if you want to READ the LPT DATA pins (with LPT there are 8 actual DATA pins, D0 thru D7). You would have a lot of flexibility and speed.
CAVEAT: You could be creative here and use fewer LPT PINS (DATA [D0]/CLOCK[D1]) and then "shift-register" the data out using only two pins and that would be almost the same as RS232. In my case, only 1 pin is needed for RS232.
Using RS232 seemed simpler and I had the idea that I could eventually implement a multi-drop solution using only 1 COM port from the PC. This would mean that a whole series of gauges could be implemented, each with their own controller listening on a daisy-chained wire using a slightly non-standard serial protocol. Each device would listen for it's own header data, "#OGx" for gear indicator, "#ORx" for RPM, etc.
Nothing says I won't re-visit the idea of using the LPT port again.
PWILLARD: With COM port, one needs additional hardware -- some controller able to handle with rs232. If you decide to go this direction, I would recommend to choose controller able to work with USB and use USB. There are some examples over internet, how to create DYI USB HID device.
fifasxxi: it works with RBR. I don't have the GPL licence, maybe in the future....
I also work on a new GI version initialized by InSim, so it'll work with other InSim addons like LFS relax.
Yes, I understand. To me, HID's are mainly for INPUT devices and I have created my own HID keys in other projects. I may be making my solution very undesirable because it requires a separate device to read the serial gauge output. It just so happens that I personally have plenty of cheap micro-controllers to customize and talk to as indicator controllers.
I really did strip out a lot of existing code. Essentially, I used your Gear Indicator code to show me how to use WINSOCK calls from DEV-cpp and how to interpret the outgauge packet. That saved a lot of time and I am happy for it.
After removing all of the segment driver and LPT code... and really really simplifying the CONFIG file code, it was sort of an empty skeleton to which I added the Serial Com port code.
Example: I turned the CONFIG file read into a 1 pass read instead of the 2 pass that was using the STATE variables by just changing the routine to read the next inline token and that seemed to work for what I needed.
//-----[ PORT ]----------------------------------------------------- if (strcasecmp (wrd, "Port") == 0) { // If Token Matches then wrd = strtok (NULL, " \t\n\r"); // Grab Next Token value = strtol(wrd, &error_value, 10);// Convert token to base 10 if ((*error_value) != 0) { // Yell if conversion fails warning("invalid port number\n"); } conf->port = value; // Otherwise, we are good }
My goal is the flexibility of using only 1 OUTGAUGE UDP listener for many external indicators, all attached to a custom serial listener bus. This removes the need for some form of outgauge proxy or other complicated multi-outgauge solution.
Right now it works the way I want and I just need to prototype more displays. (An 8 LED TOP-RPM indicator is my next module to finish a prototype)
I drive my solution with USB-SERIAL adapter and then to an RS232 to TTL interface for the RCV data pin. (using a MAXIM MAX232 device). I hang everything else onto that.
Sorry if this seems to drag on... I'm just having fun and you gave me the tools I needed... KADA thanks.
(i have no clue what you just said lol) but i have email my but the links from here and rsc, so hopefully he will be able to get something sorted 
