Don't know if this will help... but this is what I've done using the Arduino.
This link below is to my Gear Indicator project using the Arduino but heavily based on Vladimir (AKA KADA) and Nick A.'s original LPT Gear Indicator Code.
Updated to be compatible with S2 Z28 and concerns about LAG all proved wrong. Very Responsive... very cool and even expandable.
So...
Out with the LPT Port and In with the Serial Port ( including any USB-SERIAL converter... as found on Arduino boards)
Project Status is here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1293046321
This link below is to my Gear Indicator project using the Arduino but heavily based on Vladimir (AKA KADA) and Nick A.'s original LPT Gear Indicator Code.
Updated to be compatible with S2 Z28 and concerns about LAG all proved wrong. Very Responsive... very cool and even expandable.
So...
Out with the LPT Port and In with the Serial Port ( including any USB-SERIAL converter... as found on Arduino boards)
Project Status is here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1293046321
Arduino
I noticed that Arduino was mentioned earlier and there was fear of this thread dying. Ok, I'll help.
This link below is to my Gear Indicator project using the Arduino but heavily based on Vladimir (AKA KADA) and Nick A.'s original LPT Gear Indicator Code.
Updated to be compatible with S2 Z28 and concerns about LAG all proved wrong. Very Responsive... very cool and even expandable.
So...
Out with the LPT Port and In with the Serial Port ( including any USB-SERIAL converter... as found on Arduino boards)
Project Status is here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1293046321
This link below is to my Gear Indicator project using the Arduino but heavily based on Vladimir (AKA KADA) and Nick A.'s original LPT Gear Indicator Code.
Updated to be compatible with S2 Z28 and concerns about LAG all proved wrong. Very Responsive... very cool and even expandable.
So...
Out with the LPT Port and In with the Serial Port ( including any USB-SERIAL converter... as found on Arduino boards)
Project Status is here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1293046321
Railroad wheels have a variable diameters and solid (non differential) axles and not the FLAT surface like a tire against a road. The area nearest a wheel flange is larger diameter, so in the case of a curve where the flange engages to keep the wheel surface on the track, the wheel on the other side of the axle is smaller diameter.
This = less need for slipping of any kind.
Large Radius curves are not necessarily due to the wheel physics. It has to do with a) Car length (distance between Axle sets) b) engaging the wheel flanges, which increases drag forces and a host of other reasons. Logging Railroads with short cars and engines can maneuver through extremely sharp curves that a passenger coach would have problems with... not even taking into account the body overhang from a long car that would cause the car to extend beyond legal track clearances.
I'm no expert... but I know a few things about trains. http://www.railsimstuff.com
This = less need for slipping of any kind.
Large Radius curves are not necessarily due to the wheel physics. It has to do with a) Car length (distance between Axle sets) b) engaging the wheel flanges, which increases drag forces and a host of other reasons. Logging Railroads with short cars and engines can maneuver through extremely sharp curves that a passenger coach would have problems with... not even taking into account the body overhang from a long car that would cause the car to extend beyond legal track clearances.
I'm no expert... but I know a few things about trains. http://www.railsimstuff.com
Last edited by PWILLARD, .
It isn't racing... but it would be an interesting "fork" in the project for some people. While I have no interest in an Arcade edition personally... having a Drift/Stunts/Demolition Derby version and a Racing version could divert some of the more arcade oriented drivers to where they want to be. The Racing version gets to remain a Serious Simulation and the Drift/Stunts/Demolition version is for the people that prefer "arcade" driving with maybe some wacky physics.
Having a separate license for Drift/Stunts/Demolition could even be an alternate revenue stream for the developers.
Having a separate license for Drift/Stunts/Demolition could even be an alternate revenue stream for the developers.
You could try adding a bootloader to your AVR and make an Arduino. It has built in serial and servo libraries... among the many other things it can do.
A lot of microcontrollers have PWM built into available library code or commands. This makes PWM simple and lowers tha parts count.
Air Core gauges are expensive because they require the winding of a lot of copper coils in a small space.
Air Core gauges are expensive because they require the winding of a lot of copper coils in a small space.
Ouch... the truth hurts a little when you have to stare it in the face.
For the simple reason... the developers wish to retain control over certain aspects of the LFS racing simulator to maintain a high quality experience over the life of the project versus what happens when these parts (cars and tracks) are left up to the community where some are experts and some are novices and the end result is extremely variable.
I normally hate seeing these kinds of responses but I know feel compelled to finally write one.
If it is your first day with C# and you do not understand the LFS examples shown so far... then you have more lessons to study before trying any Outgauge coding.
Even generic C examples, such as those by Vladimir Kadlec with his Gear Indicator will show you how to read the packet in way that you should understand and apply to C#.
Maybe by studying the Gear Indicator project code you will gain the skills you need. Until then, you are the Grasshopper that cannot yet snatch the pebble from the Master's hand.
Basically, at this stage, anything we say in trying to assist you will likely come out in SIMLISH.
http://en.wikipedia.org/wiki/Simlish
If it is your first day with C# and you do not understand the LFS examples shown so far... then you have more lessons to study before trying any Outgauge coding.
Even generic C examples, such as those by Vladimir Kadlec with his Gear Indicator will show you how to read the packet in way that you should understand and apply to C#.
Maybe by studying the Gear Indicator project code you will gain the skills you need. Until then, you are the Grasshopper that cannot yet snatch the pebble from the Master's hand.
Basically, at this stage, anything we say in trying to assist you will likely come out in SIMLISH.
http://en.wikipedia.org/wiki/Simlish
Yeah... laptop batteries do that. It's how they die. Soon it won't take a charge at all and you will need a replacement. Laptop batteries will continue to discharge when not in use... in some cases... a really deep discharge or long period with no recharge will make them go from healthy... to never healthy again.
You know... some people actually write code for a living. This means a few things...
1) Someone (employer) is willing to pay out good money for the expertise of people that know how to write code.
2) Writing code is the equivalent of "work".
3) Contrary to popular belief, everything you need to write for your custom application has not already been written by someone else who just happend to upload it somewhere... so just googling will not find you the code you want.
4) It is really really important to understand what you "read" in someone else code. You need to know what you are doing and why. This is why everyone says you need to "learn" something, make some progress then ask questions. Don't ask questions before you make progress.
1) Someone (employer) is willing to pay out good money for the expertise of people that know how to write code.
2) Writing code is the equivalent of "work".
3) Contrary to popular belief, everything you need to write for your custom application has not already been written by someone else who just happend to upload it somewhere... so just googling will not find you the code you want.
4) It is really really important to understand what you "read" in someone else code. You need to know what you are doing and why. This is why everyone says you need to "learn" something, make some progress then ask questions. Don't ask questions before you make progress.
Here is what I consider to be an excellent book on C#
HEAD FIRST C# - Brain Friendly Guides
Andrew Stellman & Jennifer Green
Published by OReilly
Worth checking to see if the learning style is right for you. Don't just take my word, it's also highly rated on AMAZON as well.
pw
HEAD FIRST C# - Brain Friendly Guides
Andrew Stellman & Jennifer Green
Published by OReilly
Worth checking to see if the learning style is right for you. Don't just take my word, it's also highly rated on AMAZON as well.
pw
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.
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 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.
Last edited by PWILLARD, .
What if that is not an option? I'm pretty sure my pedals work on the same axis.
Cmon! It just means that they could afford a G25 and you are only mad because you don't have one.
(Really, I'm only joking... but it is the only reason I could think of why someone would put G25 in their name. Maybe mine needs to say RED MOMO so you can understand if my wheel breaks mid-race. <GRIN>)
(Really, I'm only joking... but it is the only reason I could think of why someone would put G25 in their name. Maybe mine needs to say RED MOMO so you can understand if my wheel breaks mid-race. <GRIN>)
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.
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.
I hope I don't sound like I'm ranting... I'm not. (Oh, and I'm new at posting here and missed the actual recent thread on Licencing... you have my permission to smack the noob.)
Dougie, You have to supply source... "somehow". Usually it means along side the release as a separate download but is commonly found in the same package.
Honest, I'm not trying to argue and I do know how GPL gets under some peoples skin. I'm also not looking for anyone to say "Hey, I agree with you!". I can be a lone wolf with my opinion and not mind it a bit.
The LINUX world has this GPL argument all the time. If the product is to be part of a "for sale" proprietary package... it gets downright uncomfortable to use GPL sources. The rule there is... "don't use it". It might mean you need to re-invent something, but that was the consequence. The real sticky part comes if you have a new idea "added" to the original GPL code that you are not completely willing to share and would prefer to just provide compiled code for your "novel" approach. It's a "no can do" with GPL, but OK with MIT or somthing more relaxed.
I prefer to think that the original goal of GPL is to counteract proprietary solutions and... amazingly enough... discourage code stealing because you always have to supply the code... If the revisions get reviewed and code is readily available... there is little possibility someone can steal code and call it their own. ;-)
Of course, if the GPL is not followed and code is assembled into binary and the souces are never supplied... well... it would take more than a few minutes to figure out it was originally GPL'd code. Time for lawyers in that case.
Anyway, for the add-on market proprietary usually means "for sale" and with items like LFS or any other PC based SIM or "toy", I'm certainly in favor of the developers that provide source code for the very reasons being discussed. I'm not saying people should not try selling sofware add-ons... just that I personally will always look at those items LAST. I'm not saying that because I'm pinching pennies.
Having been burned by orphaned software products one too many times in the past, I am now less likely to see payware as a preferred path for add-ons.
Last edited by PWILLARD, .
Reason : revision after seeing other threads.
Really...
Why would GPL be an issue?
Let's see... A New LFS Patch comes out... the original solo developer now plays World Of Warcraft and never leaves to drive LFS again and can't be bothered to update code...
How many times have you been burned by closed binary only releases and the developer (some guy on his own) just gives up and fades away never to be seen again.
More people might get involved and help keep it running strong if the source is available . Big Deal... keep sharing the code and keep the community string.
Long Live LFS.
Why would GPL be an issue?
Let's see... A New LFS Patch comes out... the original solo developer now plays World Of Warcraft and never leaves to drive LFS again and can't be bothered to update code...
How many times have you been burned by closed binary only releases and the developer (some guy on his own) just gives up and fades away never to be seen again.
More people might get involved and help keep it running strong if the source is available . Big Deal... keep sharing the code and keep the community string.
Long Live LFS.
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.
pw
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.
pw
Last edited by PWILLARD, .
FGED GREDG RDFGDR GSFDG