Dashboard Via Phidgets

[KeiichiRX7]

Anyone interested in making a Phidgets program so that users can use Phidgets to build a functioning dashboard?

Phidgets are ready to use interfaces that one need only write code for
(www.phidgets.com (http://www.phidgets.com)). if we could Tie Servos and LED's to RPM's speeds and system status that would be a huge step in sim building... functional sim cockpits

[Tweaker]

Sounds cool. My friend has been having fun working with LCDs and configuring them to read stuff off his computer. I should have him experiment with LFS sometime, it would probably be a lot easier since LFS has all that data outputted very nicely.

Never heard of this Phidgets stuff, but if someone could make a digital thing to make a hi-tech LCD display (like digital RPM bar, and stuff), that would be SWEET!. Would be an interesting project, I'll take note of this for my friend.

[himself]

Looks like a nice idea :thumb: ... only if you dont have to make the whole code in assembler :schwitz:

[nikimere]

nice idea :)

[KeiichiRX7]

I was thinking along the lines of the program getting all the variables from LFS, then letting the driver define what to do with those variables. this way you could do formula style RPM LEDs or use a servo for an analogue Tachometer.

[Anarchi-H]

LFS has no programming interface for retrieving real time telemetry / engine data. It can be accessed in a RAF, and could also probably be gleaned if you can find it in memory, but otherwise you are SOL unless something has changed since I last checked.

[Janni1687]

this idea isn't new.
Some guys on rscnet.org talked about that 1 or 2 years ago.
Scawen sayed that he likes the idea and would think about a OutGauge-System :)

if you wanna test a phidget servo as speedometer, you could use RACER (www.racer.nl).

[KeiichiRX7]

Hooray... maybe i CAN make a functioning Formula car wheel after all (started designing a concept in Paint Shop Pro today)

id have to also ask for the ability to bind a live setting to an axis.

as long as i can tell the system what to do with the information i would be happy. If i want to send my vehicle speed to a Phidget's LCD that would do the job for me. In fact i could probably fit everything i need on one LCD. use a bar type tach, digital speedo, fuel and temp indicators, and maybe just one character to make sure teh pit speed limiter is really on

[Janni1687]

Hooray... maybe i CAN make a functioning Formula car wheel after all (started designing a concept in Paint Shop Pro today)

id have to also ask for the ability to bind a live setting to an axis.

as long as i can tell the system what to do with the information i would be happy. If i want to send my vehicle speed to a Phidget's LCD that would do the job for me. In fact i could probably fit everything i need on one LCD. use a bar type tach, digital speedo, fuel and temp indicators, and maybe just one character to make sure teh pit speed limiter is really on

I think a normal Phidget LCD isn't big enough for that information. A Graphical LCD can do much more and i would prefer one of them connected to printer port. USB has problems with timing on some mainboards(usb controllers). Timing is very important for information like Speedo. I use a Crystalfontz 128x64 LCD (Printer Port) and i'm very happy with it!

[KeiichiRX7]

tell me more wise one

[lbodnar]

Did you mean driving actual car instruments, like here:
http://www.lbodnar.dsl.pipex.com/gauges/index.html
This needed no modification to a stock Audi A3 cluster at all (apart from disabling immobiliser light as it kept flashing and I don't want to start it with real ignition key! :) )...

The biggest benefit of this approach is that you don't need to massage data to make it fit real instruments. I mean tacho is a tacho and it was calibrated within its full range when it left production line. So much easier than to calibrate servos, etc.

Or is it still better to drive the oversized LCD / full set of LEDs? It will take a lot of tedious work...

In either case access to internal data is essential. Also the quality of data is important, you can see on the video that tach is life-like because RPM data samples are supplied by the game at the rate of about 50 per seconds... Potentially, the hardware can accept data as fast as 500/seconds but this is not of any practical use...

I thought that LFS cannot output live data? :(

Janni1687, what USB timing problems?! I really have to know details since I am developing USB hardware... :shrug:

[Janni1687]

Janni1687, what USB timing problems?! I really have to know details since I am developing USB hardware... :shrug:

In Theory parallel hardware is faster than serial hardware. I read somewhere that the transferrate and timing-latency can differ very much on different usb chipsets. So many LCDs(controller) connected to usb are very slow. To show information like rpm on usb lcds depends much on your mainboard's usb chip.

I may be wrong! CORRECT ME! :)

Back to topic:

Scawen said some time ago on RSC that he will think of implementing a OUTgauge system.
I like your gauges. Do you know if its possible to control the gauges over CAN-bus?
i think i do have a CAN interface-card somewhere in my room :)

[lbodnar]

USB latency for full speed controllers like mine (and I guess phidgets') is in the order of 1 millisecond. Now, it is up to a designer what he wants to do with this millisecond - if he controls LCD by just outputting one byte every millisecond and then reading LCD status back in another millisecond than it will indeed work very slow! But this will only happens if you use generic USB controller as a dumb I/O box.

On the other hand, if you just send controller the information to display and let the controller follow interfacing protocol with LCD (read/write/check status) then without much effort you can dump data at speeds about 50 kilobytes/second. If all you need to pass is some telemetry data, say 100 bytes or so, your update rate will be in the order 500/second. This is "instant" for human vision. In this case the LCD itself is a limiting factor but it will be as well if you connect it directly to a parallel port or anything else...

For example, I don't think that PC should draw and referesh each pixel of your 128 x 64 = 8 kilobytes of screen data on every data frame. PC should send telemetry data to a controller and it will refresh graphical LCD data itself.

USB is very complicated protocol and the problem you are referring to will not mean that any device attached to this motherboard will be "slow". There are three speeds and five ways to transfer information on the bus.

Instruments cluster has CAN bus but I don't think you can actually control the needles from there. Maybe on the latest hardware, but it is too expensive to experiment with.

[filur]

Seeing how USB has been able to cope with multi-channel MIDI in professional audio production for years, and even multi-channel high quality audio in later years, being able to update an RPM gauge shouldn't be much of a problem in terms of speed, logically.

This (http://www.m-audio.com/products/en_us/AudiophileUSB-main.html) consumer level audio interface can record 24bit/96kHz stereo sound in realtime, it's not possible for this thing to have a large enough internal buffer for lengthy recordings, so that's ~288 KB/s thru USB.

[Janni1687]

USB latency for full speed controllers like mine (and I guess phidgets') is in the order of 1 millisecond. Now, it is up to a designer what he wants to do with this millisecond - if he controls LCD by just outputting one byte every millisecond and then reading LCD status back in another millisecond than it will indeed work very slow! But this will only happens if you use generic USB controller as a dumb I/O box.

On the other hand, if you just send controller the information to display and let the controller follow interfacing protocol with LCD (read/write/check status) then without much effort you can dump data at speeds about 50 kilobytes/second. If all you need to pass is some telemetry data, say 100 bytes or so, your update rate will be in the order 500/second. This is "instant" for human vision. In this case the LCD itself is a limiting factor but it will be as well if you connect it directly to a parallel port or anything else...

For example, I don't think that PC should draw and referesh each pixel of your 128 x 64 = 8 kilobytes of screen data on every data frame. PC should send telemetry data to a controller and it will refresh graphical LCD data itself.

USB is very complicated protocol and the problem you are referring to will not mean that any device attached to this motherboard will be "slow". There are three speeds and five ways to transfer information on the bus.

Instruments cluster has CAN bus but I don't think you can actually control the needles from there. Maybe on the latest hardware, but it is too expensive to experiment with.

ok, i understand. You're the hardware-master.
some OT question:
I've seen all your stuff over at RSC. And as I understand you're coming from flight simulatin community. What made you going in to race sims?
And are you professional hardware manufacture(i think you mentioned that over at rsc)or is it hobby? what industries are you delivering to?

janni

[lbodnar]

I've seen all your stuff over at RSC. And as I understand you're coming from flight simulatin community. What made you going in to race sims?
And are you professional hardware manufacture(i think you mentioned that over at rsc)or is it hobby? what industries are you delivering to?

:D This is not my day job, it's a hobby. However, I made some custom versions for guys who make simulation hardware for living because I think their products are cool, that's all.

I am not really from flight simulation community but unlike racing in real car I do fly real plane so I know how simulation should look like (and it does not :( ). Mmmm, curiosity is probably the best answer! :shrug:

[Janni1687]

:D This is not my day job, it's a hobby. However, I made some custom versions for guys who make simulation hardware for living because I think their products are cool, that's all.

I am not really from flight simulation community but unlike racing in real car I do fly real plane so I know how simulation should look like (and it does not :( ). Mmmm, curiosity is probably the best answer! :shrug:

what are you're further ideas or plans in sim racing hardware?
racing wheel with lcd integrated? perhaps as an update to DFP frex kits or little gimmicks like realtime mirror adjustment with an HAT switch (hmm no sim is featuring this :scratchch ) i think my definition of simulation hardware is a bit crazy. :D

[KeiichiRX7]

OK Outguage has been released, its time to revive this thread.

I was thinking while waiting, and looking at a program called FS2Phidget. its an interfacing progaf for taking data from MSFS and feeding it to phidgets. its its particularly neat because it lets you sort thru the variables to find the one you want, then you decide what to do with it yourself, by telling the program what to do with it. for instance, you could find teh RPM variable and define a series of lights to light up as teh RPM's increase, ala F1

(sorry about typos, my pc isnt keeping up right now and im typing into the buffer)

ayway i thought this would be a neat idea for LFS because then anyone could do anything they wanted to build an LFS cockpit with almost no programming knowledge, jsut setting up the LFS2Phidget priogram and testing it till itperforms as desired. like setting a fuel warning light, or temp warning light. logging of data (an external function, but still propbably possible in this kind of application)

Thoughts?

[Dygear]

I might just give this thing a shot, owen. Give me some time to scrape some money togeather and buy this thing. The programing itself should be pretty easy.

[horrgakx]

I found this on YouTube - who made it?

http://www.youtube.com/watch?v=60KuE5RxONk&mode=related&search=

[KeiichiRX7]

No idea, looks vaguely like the Frex dash, but its certainly not Phidgets based.

and here you'd gone and gotten my hopes up by posting in my thread

[Gunn]

Sounds cool. My friend has been having fun working with LCDs and configuring them to read stuff off his computer. I should have him experiment with LFS sometime, it would probably be a lot easier since LFS has all that data outputted very nicely.

Never heard of this Phidgets stuff, but if someone could make a digital thing to make a hi-tech LCD display (like digital RPM bar, and stuff), that would be SWEET!. Would be an interesting project, I'll take note of this for my friend.A friend of mine is currently investigating the possibilities of driving LEDs from LFS for various dashboard features. We've also discussed fuel warnings, radio messages, tachometers, temperature guages and other various alarms and indicators.
We've talked about USB and serial connectors.
Not sure if this will ever bear fruit but if it does the info and method will be shared publicly.

[KeiichiRX7]

http://forums.trossenrobotics.com/showthread.php?goto=newpost&t=956

i went over to a retailer's site and asked for help frot eh Flight Sim community. They do guages and stuff al the time, so they woul dhave the programming know how to make it happen

[Kada_CZ]

We've talked about USB and serial connectors.If you have LPT, you may try this (http://forum.rscnet.org/showthread.php?t=285679) (self promotion :shy:).

[Gunn]

If you have LPT, you may try this (http://forum.rscnet.org/showthread.php?t=285679) (self promotion :shy:).Sorry, I don't follow links to RSC.

[Kada_CZ]

Sorry, I don't follow links to RSC.Ok, I made an ugly GI homepage (http://nlp.fi.muni.cz/~xkadlec/lfs/gi/) (I hate html). I don't know your motivation to not follow liks to RSC, but I would probably created the page outside RSC anyway. You just pushed me to do that :-).

[KeiichiRX7]

you guys seem to have missed the point that phidgets are nicely modular and easy to configure, little to no soldering required, and are USB, little to no risk to destroy your machine

[Gunn]

you guys seem to have missed the point that phidgets are nicely modular and easy to configure, little to no soldering required, and are USB, little to no risk to destroy your machine
No, I didn't miss the point. Currently I'm using breadboards and while it is way cheaper for me to make my own modules up, the Phidgets solution is quick and easy. I think it's a great little niche for them and quite possibly I will try their stuff in the future.

Ok, I made an ugly GI homepage (http://nlp.fi.muni.cz/%7Exkadlec/lfs/gi/) (I hate html). I don't know your motivation to not follow liks to RSC, but I would probably created the page outside RSC anyway. You just pushed me to do that :-).Thanks for the new link :) For the record, I don't follow RSC links because that place is a shithole.

I've bookmarked your page for later reference.

[Dygear]

Gunn, that has the be the most Non PC gray text ever!

[Gunn]

Gunn, that has the be the most Non PC gray text ever!Thanks, I appreciate the compliment friend. :)

[KeiichiRX7]

Got a response from a programmer over at the phidgets forum. Looks like the work is going to be ridiculously expensive, and I'd have to send 1 of every kind of phidget i intend to use for this.

Unless you guys are willing to help me raise some cash, I'm gonn aahve to wait for another programemr to come along into my web


(current beer count: 3)