Chris
Premium Member
Registered: 21st Sep 99
User status: Offline
|
Are any of you out there experienced in programming applications for sysmbian OS.
I have a concept for a track day information program that will;
Send GPS data back to Corsapsort track support truck
Data will then be displayed realtime on the screen inside the truck.
optional send of images from car.
This will give a realtime view of the cars on the track with speed and location.
|
Ian
Site Administrator
Registered: 28th Aug 99
Location: Liverpool
User status: Offline
|
Need to do something about plotting multiple points on a map overlay as well. I've got software to do a single GPS trace but you can't give it multiple NMEA sources.
|
John
Member
Registered: 30th Jun 03
User status: Offline
|
There are programs that report back as often as you want currently, GPS only updates every second so every couple of seconds would probably be about as high resolution as you got.
Not sure about getting multiple cars on one screen.
|
Ian
Site Administrator
Registered: 28th Aug 99
Location: Liverpool
User status: Offline
|
Yeah the data rate isn't massive, the GPS data is 1Hz.
If you can get an external facing IP in the truck then you could use HTTP POST to get the data back in.
In fact, they could POST back to the CS server and be made available to the script as CSV or something straight from the DB.
Might make a nice data-driven Flash app actually, could be online and mobile on the site then as well.
Flash app would be nice if you could extrapolate the track trajectory from the incoming data and interpolate additional keyframes based on the speed and heading data.
|
Paul_J
Member
Registered: 6th Jun 02
Location: London
User status: Offline
|
nokia = yuk
could write one for iphone.
|
Ian
Site Administrator
Registered: 28th Aug 99
Location: Liverpool
User status: Offline
|
No reason why there couldn't be a few apps so long as they agreed on the data format going in the POST.
Which really, could be the entire $GPRMC sentence from the NMEA data if you have that in the phone.
Otherwise regular long/lat would do. Do you know what format you have available to the app?
|
Chris
Premium Member
Registered: 21st Sep 99
User status: Offline
|
GPS would just be lat / long data, but possible to also include obd feeds for temp,throttle,etc.
reg,lat,long,alt,knot
http://www.corsasport.co.uk/trackday/?reg=RegNO&lat=54.31&alt=3.23&al=60&sp=87
The other end (truck) read out using http read as raw data from server then placed on to virtual com port to emulate gps feed for use in visualGSP etc.
|
Ian
Site Administrator
Registered: 28th Aug 99
Location: Liverpool
User status: Offline
|
Have you got lat/long in the handset?
|
Ste
Premium Member
Registered: 5th Mar 03
Location: Taif, Saudi Arabia
User status: Offline
|
Symbian is the better option as anyone who knows anything about phones wouldn't have an iPhone.
have a look at these apps already out there
my-symbian.com
http://gpsed.com/
http://www.symbianguru.com/phone-guardian-s60-3.html
[Edited on 08-02-2010 by Ian]
I would rather lose by a mile because i built my own car, than win by an inch because someone else built it for me.
|
ed
Member
Registered: 10th Sep 03
User status: Offline
|
I'm not sure how well a live update would work - there are some limitations on the data acquisition and also the upload of data. If you used batch processing to collect the GPS data at the highest resolution possible (1Hz?) and then uploaded the data as an array or similar at a rate of 0.1Hz to your web server. You could then have a web application that creates images that are updated every 10 seconds, or you could make the web application run 10-20 seconds in delay of realtime which means that you could have a pseudo-live updating image.
Lots of stuff to think about, sounds like a nice project though 
|
Chris
Premium Member
Registered: 21st Sep 99
User status: Offline
|
If you want a GPS rate higher then 1Hz carry multiple phones running the same app 
I currently have the code to send lat / long to sever via HTTP post.
Also collecting the OBD
Cycle;Timestamp;Calculated Load Value (%) ;Engine Coolant Temperature (°C) ;Short Term Fuel Trim - Bank 1 (%) ;Long Term Fuel Trim - Bank 1 (%) ;Engine RPM (1/min) ;Vehicle Speed (km/h) ;Ignition Timing Advance for #1 Cylinder (°) ;Intake Air Temperature (°C) ;Air Flow Rate (g/s) ;Absolute Throttle Position (%) ;O2 Sensor Bank 1 - Sensor 1 (V) ;O2 Sensor Bank 1 - Sensor 1 (%) ;O2 Sensor Bank 1 - Sensor 2 (V) ;O2 Sensor Bank 1 - Sensor 2 (%) ;Distance Traveled While MIL Is Activated (km) ;Fuel Economy (momentary) (l/100km) ;Fuel Economy (momentary) (MPG) ;OBD Port Voltage (V)
The data transfer is a small datagram so would be realtime ish obviously better with higher bandwidth connection.
www.racechrono.com is the ideal app but does not send data realtime
|
Ian
Site Administrator
Registered: 28th Aug 99
Location: Liverpool
User status: Offline
|
quote:
Originally posted by ed
You could then have a web application that creates images that are updated every 10 seconds, or you could make the web application run 10-20 seconds in delay of realtime which means that you could have a pseudo-live updating image.
I wouldn't even say that it needs to be that latent. You can get the data back as quick as it's being received as GPS and there's no overhead whatsoever with querying it from the caching tables and displaying it in the app.
PHP imagecreate() would work but would require a refresh, hence preferring Flash.
Could also do a desktop app that runs locally but streams the data down from a PHP script pretending to be a CSV file or something. UDP or TCP are the more logical choices but they are far more faffy particularly if you're talking about reconfiguring the CS server to do it as its not currently set up for anything like that.
And a polled HTTP request at 1hz would look no different to a UDP stream in the final app.
Just need to work out how to handshake it so the incoming data isn't susceptible to SQL injection and we're fine.
Having said that, 100Hz is lovely 
http://www.youtube.com/watch?v=xuycoNzl814
That is post-processed though.
|
Ian
Site Administrator
Registered: 28th Aug 99
Location: Liverpool
User status: Offline
|
quote:
Originally posted by Chris
?reg=RegNO
Would be preferable to send the IMEI or something peculiar to the handset and resolve that locally to reg/owner. Could do a hex conversion or use some other larger number base to reduce the length of the datagram while you've got the entire character set available and not just integers.
Edit - that would also mean that you don't have to configure at the handset and if the configuration wasn't present you could just display the data against the IMEI and not have potentially a load of handsets all sending you anonymous data.
[Edited on 05-02-2010 by Ian]
|
Chris
Premium Member
Registered: 21st Sep 99
User status: Offline
|
As of 2004, the format of the IMEI is AA-BBBBBB-CCCCCC-D, although it may not always be displayed this way. The IMEISV drops the Luhn check digit in favour of an additional two digits for the Software Version Number (SVN), making the format AA-BBBBBB-CCCCCC-EE
So CCCCCC is the actual serial of handset and AA-BBBBBB is the BABT allocation number.
10% of IMEIs are not unique
Would not be a problem to a URLencode on the incomming string to stop SQL enjection.
Nice other phone application would be to see the speed of the cars as they passed
|
Ian
Site Administrator
Registered: 28th Aug 99
Location: Liverpool
User status: Offline
|
Could just substring the serial portion, chance of a collision would be fairly small I would guess.
If you want another app to see the speed of cars that are passing you, you need to Pythag the location of the spectator handset with all the locations of the cars. If you ordered that query by distance descending then you would get the cars as they were passing.
You could also cache the distance and compare most recent with the current one and see if they were getting closer or further away.
|
