A little background:
I've been logging lap times using RaceChrono for motorcycle racing and for training and video overlay for a while now (
). I'll start by saying thank you, this app is amazing. I was a die hard trackmasters fan, but one try of RaceChrono and I was hooked. Everything works so much better. I literally never go to the track without my timer setup and I get a lot of good comments on how great this system is for the cost. I have also verified the lap times using a 818xt vs the Westfield transponders used in CCS Racing and the difference is generally in the .0x seconds.
Sadly, motorcycles in general are not OBD2 complaint, so there is no option to log data from them using a OBDII reader off the shelf. I've been wanting to get data from my bike for a while now so I took on trying to achieve this and have sucesfully built a real time data viewer.
After some research on the Honda ECU, its message structure, etc (
http://forum.pgmfi.org/viewtopic.php?f=57&t=22199&sid=42dceeae3e52ca83a70b340ace2ccdd4&start=60) and after seeing that the physical layer is basically OBDII (iso9141-2) with different message structure I thought it would be worth a shot to attempt to obtain connection to ECU via an ELM327 Bluetooth adapter using serial comm. I've basically built a DLC (Honda Test Connector) to OBDII cable and linked the pins appropiately (Pin 7 is K-Line, others are just ground and battery power).
I tested the connection and the ELM is answering fine, but I couldn't even get the Slow Init (communication initiation) to work, it turns out that the Honda ECU Slow Init is radically different from any OBD standard, I did not want to build custom hardware since my electronic engineering skills are pretty much non existant. So my new approach was to the use a GiPro DS Gear indicator (
http://www.healtech-electronics.com/) (which logs the data I need from the ECU in order to calculate the current gear) as a comm manager and use the ELM327 as a sniffer to just get the information that I need.
So I built a cable that splices in between the DLC and GiPro DS and plugs the KLine into the appropiate pin on the ELM327 and bingo, I can see all the data comming and going from and to the ECU. It is rather limited since the GiPro uses only one command to extract data, but this pulls all the relevant data needed. With some tinkering on the ELM327 settings I can get messages to come and go in perfect structure, the only issue I have is that at the end of every line I get a "<DATA ERROR" indication. This is due to the fact that the ELM327 doesnt recongnize this as a valid data structure. It does not really matter though, I just filter it out by software.
An example of the data
In this first example the GiPro requests data, but the ECU does not answer. That is what a request looks like.
72 07 72 10 00 11 F4 <DATA ERROR
In this second example we can see the request and then the response. Interpretation for most of the data is already on PGMFI (link posted before).
72 07 72 10 00 11 F4 02 17 72 10 00 05 91 19 00 5C 5A 8A 46 75 4F FF FF 83 0C 03 00 A1 3B <DATA ERROR
Different command but still same data explained:
72 05 71 10 08 ----|
----------------------|
02 16 71 ------- [c m d]
10 -------------- [table]
00 00 ----------- [rpm]
18 00 ----------- [tps]
37 70 ----------- [ect]
56 5C ----------- [iat]
87 5C ----------- [MAP]
FF FF ----------- [...]
7A ------------- [Battery Voltage]
00 -------------- [Speed]
00 -------------- [...]
00 -------------- [Fuel injection valve]
80 -------------- [.?.]
1B -------------- [checksum]
Based on that I've built an app that can display the data from the ELM327 in realtime averaging about 15hz. (it goes down to 10 or peaks out at about 32 - sometimes the ecu gets a request and does not respond several times in a row, when this ocurrs that data is ignored, hence dropping the refresh rate considerably).
What I want to do is tie this data logging together with RaceChrono in order to get lap times + datalog just like you would for an OBDII enabled vehicle.
Now, I know it would probably not be of much interest for the community as a whole since I'm currently the only person with this logger setup, however we could look at some kind of interaction between Apps through a Service or Broadcast where data could be shared in a standarized way, that way any custom logger could be built as long as it adheres to standard way of communicating that RaceChrono could understand. Or maybe its just easier to include the data interpretation code into RaceChrono as it is quite simple and have it only show up in the menus when people have installed a certaint app as a key (not for money, but as to not clutter the UI with unneeded options). In the end, there are many ways of doing it, it is always a possibility to export the data and then combine it, but I would love to be able to have an export auto sync the data.
Does any of this seems interesting to you? could we somehow work together on getting integration on this?
Comments
Instead, I offer a general solution for all custom data loggers builders, which is the $RC2 sentence:
http://www.racechrono.com/forum/#/discussion/comment/4330
I perfectly understand your reasoning, your time is better aimed towards mass functionality, I agree with that.
Is the only way to send $RC2 sentences to the app via a "RaceDac" BT connection?
I could use that sentence perfectly, it would allow to send all the data I want, the only issue is that I need my app to process the data before sending it to the app, hence it can not come from a BT device. As you see from the message structure the data comes in un-processed, for example the RPMs are a simple 16bit number, but the Coolant temperature has a crazy formula, I've also built a selected gear calculation based on RPM/Speed and gear ratios, so straight from BT wont really work.
I dont know if I could perhaps try to emulate a BT device via software, I've never tried it.
That is why I spoke of "...some kind of interaction between Apps through a Service or Broadcast Reciever where data could be shared in a standarized way...". This would mean using the same $RC2 sentence but from a cross app interaction instead of a BT device.
Thanks,
Stefano.
Sorry I didn't quite understand correctly from the first e-mail what you need. Now I do I think. How about TCP/IP socket as alternative connection method where you could feed the $RC2 data? RaceChrono would be the client, and your data source would be the server. You could run the server as separate Android app, no problem.
I could do it during summer as part of my private driving simulator project. This way also some WiFi OBD-readers would become supported too.
-Antti
Let me do some research on the subject and I'll post back.
I did some research and asked around work (I work at a mobile dev company), and heard some suggestions on a reasonable way to design this.
In order for this to make sense for RC it would have to be a generic solution so anyone who would want to feed RC data from another app could use the same interface. Anyone could use it as long as they adhere to a certain standard.
In this sense, a generic implementation of cross-app communication using the $RC2 sentence would be the objective, it would be processed in the exact same way as a RaceDac without handling the BT connection.
The most logical path we came up with for this is by using Broadcast Receivers / Intents to communicate between apps.
The setup would follow a little like this:
- (1) RaceChrono app.
- (2) DataOrigin app.
(2) Contains a service that can be invoked by sending a specific intent for which it has already registered a broadcast receiver. (example: com.racechrono.app.startdata).
This would trigger (2) to do what ever it has to do in order to connect to its data source and begin to query or generate the necessary data.
(1) would register a Broadcast Receiver filter for a specific intent (example: com.racechrono.app.incomingdata).
(2) would poll data from its source, every time it has data to send to (1) it would issue a new intent (com.racechrono.app.incomingdata) with a string extra ("message":"$RC2,[time]...").
(1) would recieve this intent through the registered Broadcast Receiver and align the data with that being pulled from other sources as is currently done with RaceDac.
This method makes no permanent connection between the two apps necessary, (1) would only receive data when it is being polled from (2). Any error in (2) would not risk issues in (1).
Imho the option for TCP/IP connection is more flexible in order to communicate with hardware, but in Android far more complicated and prone to errors, a potential crash in (2) would risk hanging (1).
--
In order to test this before I posted up here I built two separate apps to simulate the setting. These work just how it was indicate above.
I'm getting ~1000hz message rate between apps. The difference here is that a fixed String is being sent to the receiving app, it is not being pulled from BT device. But at that message rate it would mean the limiting factor would be the data source rate (BT) not the message transmission.
You can get the test apps here, check them out so you can see the mechanism working.
https://www.dropbox.com/s/nlhoa6qh0xljj84/IntentTestRecieve.apk
https://www.dropbox.com/s/xrg46gzrl1ykm8l/IntentTestSend.apk
I could share the code if you want to take a look, its quite simple actually.
Let me know what you think,
Stefano.
I think would be still going with the TCP/IP solution. My reasoning is that TCP/IP port would require minimal modifications to the current code base. Also it would allow much wider range of data sources, for example such that run outside the device itself (WiFi devices and simulators).
-Antti
Ok! When you start working on how you would want to setup the connection over TCP/IP let me know so I can modify what I'm doing to also work with the pattern you design.
Thanks,
Stefano.
I'm new to the forums, and a long way from being a programmer, but I am a racechrono fan from early symbian days. First of all, thanks for this app; I honestly think it's the greatest thing a telephone can be used for.
Now to the thought I want to add to this discussion: I recently stumbled over a Sony Smartwatch (1st gen), which of course fails terribly as a watch, but could be much more useful as a durable, lightweight and relatively cheap remote racechrono-display. It already seems to communicate with android devices/apps in the way Stefano mentioned and thus could probably be added to the system easily.
Like Stefano, I think in motorbikes. Like him and JoeC over at the other thread I have attached an OEM-Diag-to-OBDII-Cable to my old Ducati 996*
The Smartwatch could be used for showing recent/best laptimes and many other things live and is easily integrated in a motorbike cockpit. I'm even considering the possibility of mounting the watch to the swingarm and using the built-in accelerometer to gain a better understanding of my suspension. No idea if that would actually work, but I would definitely appreciate a standardized way of feeding back that data to racechrono in the way mentioned before.
So, thats one more vote for Stefanos suggestion (mind you, based on no programming knowledge at all - just flipping through the code provided by Sony). Whatever you guys come up with -or decide not to include- thank you.
Matthias
*Unfortunately, at the moment, the Ducati is in no state of giving the feedback you requested in the other thread.
When I've got it back together, I'll be happy to provide that log file. So far, I had managed to get a Ducati-specific application to read out all provided values in the garage, but no proper communication with racechrono (both s60v3/android).
I've been working on what we had mentioned previously, in the end I finished building my own logger and I just combine the data in DashWare (which was my main objective). This would still be pretty interesting so more people could build custom data inputs, however, on my part I found an alternate route that worked.
Stefano.
Seeing if I can remove the bluetooth from the solution
Thanks, Jeff