It should work the same with the Datalogit as it does with the Hako , unfortunately most South African RX7's don't use apexi , so I don't know anyone with a Datalogit to verify . All the info you require is on the google code page . Just make Shure you have the baud rate set to 57k in the cfg file. I would appreachiate any help from coders

 

It's fairly straightforward code. There could be some optimization with regards to the serial comms to speed things up. Also, it only polls the advanced information group -- which isn't bad per se, but if you only want a generic set of information you could get faster results with the "basic" group. In addition, it needs auxiliary parsing added for widebands/etc. I'll look into picking up another raspberry to play around with it and add a "test" mode to simply test the responsiveness of the display.

 

Even when using a laptop, the data from the datalogit comes faster when you're monitoring fewer parameters (ie just basic, rather than basic/advanced/aux, or whatever)

It might run faster if it's hardcoded for specific gauges, rather than having so much versatility.
Hopefully it doesn't come to that, but having one "everyday" program with a few typical gauges, another program with appropriate gauges for the track and another separate program with specific gauges for tuning would reduce overhead somewhat

I guess it really depends where the bottleneck is... which we don't currently know

 

thanks For your input guys , I really hope we can make this work nicely . @ SonicRat if you want to make additions to the code , pm me your email and I add you to the contributed group on google code

 

Correct. This is why I'm going to add in a simple gauge test routine that'll eliminate the serial port as a bottleneck and determine the possible refresh rate of the GUI itself.

 

I've got it built and running on OSX in the meantime and will be committing a few changes in the near future. I'll be testing out the responsiveness on my FD tomorrow and I'll see if I can tweak it from there.

Additionally, when looking at the current gauges, there's only two gauges (fuel temp and MOP duty cycle) that are not already available in the basic information query, so some time can be shaved off swapping those out to something more useful.

 

Seems it is quite easy to port this for between Linux/Free BSD based platforms , seeing that it only took you a little while to compile it on OSX . Leaves some room to port this to Android in the future maybe ( as most phones and tablets are faster than the Raspberry pi ) I see you made your first commit SonicRaT :-) .

If you want to create your own gauges , just use the gauge designer of Megatunix , then design a dash . After that you need to manually edit the dash XML file , and change the datasource with the one from Raspexi viewer .

 

Porting this to android would be difficult using the same dashboard style -- GTK isn't currently available for android. However, a number of other methods would be available. I have an entirely working gauge display for iOS/OSX though...

I'm committing a few more changes as well -- a toggle for "random" data (Key D) and fixing the random number generator. Also a few other minor things along the way, such as disabling some of the debug messaging for performance sake.

 

Interesting , just IOS would be difficult , as there is no way to connect the USB to for instance my IPAD

 

Are you able to build the new releases? A meaningful test would be to build the current source on the Pi, set your serial port to /dev/null and the interval to 35 (comes out to around 30fps) and then run the random data "demo" to see how the Pi handles the refresh rate.

 

I haven't had the chance to build them yet , its 12:50 lunch time this side of the globe so i am stuck at work . I don't have a router at the moment (lightning stike) I hope i get it this week , so i can compile with your changes and test it . I must say , you are really quick with your commits

 

Well, I went out and tested today. It went pretty well. Although, I did notice that the baud was set for 57600 8,e,1. FC-EDIT (most popular PowerFC software), Datalogit, and my PowerFC adapters all run at 57600 8,n,1. I can't imagine why the FC-HAKO would run with parity.... Perhaps it's doing error correction to compensate? Try running 57600 8,n,1 and see if your response rate improves.

Here's the recording of it running on OSX at roughly 30 fps.

 

Wow looks very impressive , my developer did not have the physical cable for the PFC Maybe that's why he made the cfg file parameters like this . I will change accordingly this evening and see if this makes it as responsive as yours on the raspberry pi . This would be a really easy fix then can't wait to check . Should be able to give feedback in about 11 hours from now when I am home

 

There wasn't a cfg file available with the source (which was why I committed one). I snagged the one from your zip files and used that as my template.

Things I will be working on shortly:
*Fix the boost gauge or swap it to a normal pressure gauge
*Add wideband support through the auxiliary channels

 

The video you made from your OSX build , was this with real data from the car ?

 

Yes, the car was rather cold, so I didn't do much other than let it idle and rev it gently a few times.

 

Looks great
Hopefully it's not just your increased process ing power that is making the difference but time will tell.
If it is a simple fix, you should change the numbers on the tach so that when it goes from 3 digits to 4 (or back) the individual digits don't shift over to compensate for the increased/decreased space used

 

I also hope it's not the processing power , but I will let you know tonight . As for the digital digits , this is unfortunately how the original megatunix gauges where designed , I don't know how much work it would be to change that . But the main focus is to get this running smooth on a cheap raspberry pi and then see about aesthetics

 

There's a video of a Pi running Megatunix that has a better refresh rate than yours, so I'd imagine it's possible to get it better.

 

I haven't seen the video , but I saw on a forum once a guy that said he compiled it on the pi and it ran well . That's why I took the decision to utilized the megatunix source . I am quite impressed that it runs so smooth with all the gauges at once on the raspberry .
One question , did you also get the abrupt needle movement on OSX when you had parity set to e ?

 

The interface adapter I use doesn't correct serial parity errors, so it went haywire after a few packets and stopped receiving data completely. The HAKO may attempt to do more correction than I do, which is why you'll need to test it on your own.

 

Awesome news guys :

changed the cfg file on my current r3 binaries as suggested by SonicRat

Changed parity from e to n
Refresh 35 ms

Works like a charm in real time no lag


Only tested with 3 gauges , but Shure It can handle more . Sorry the videos are a bit crap ( I am a bit in a rush , still need to do homework with my son .)

So short answer raspberry pi can handle it in real time . @SonicRat you are a genius

 

That is fantastic!
Great job guys

 

So now that we up and running in a usable state I would like to request some more community help :

Design some nice RX7 gauges and dashboards with the gauge and dash designer from megatunix

Someone that can make a nice lightweight fast booting raspberry pi image with a startup logo and automatic boot of Raspexi from terminal without booting into x desktop . I have seen images that boot in less than 10 seconds . Someone with mad Linux skills would be helpful

Someone that can design a nice logo for Raspexi that we can use at the startup .

After this we can compile a nice downloadable raspberry pi image .


Let's make this as professional and as close to a OEM standard as possible as a community

 

That functionality would be heavily dependent upon if the program will run using GTKfb. If not, X11 will be required.