RomRaider

Sasha_A80, could you shed some light on reflashing one of those cheapo BT ELM adapters to work for K line comms? I was going to build one but this seems light a better solution. I would assume it should work with that BTSSM program as well as Romraider.

There are two ways, namely:
- configure installed BT module to accept 4800 bps data stream instead of preprogrammed 38400 bps
- reflash PIC18F25K80 controller to become a 4800-38400 bps data stream convertor

The first approach needs a couple of wires to be reconnected, the second one may need or may not.
Some cheep BT modules have a limited packet datalength ( maybe about 100-120 bytes) and need a pause bitween packets.
ELM BT dongles based on similar modules are to be reflashed the second way.

The second approach allows SSMoverCAN\OBD CAN messages to be converted to SSM-Kline data stream.

I got my BT OBDKey (ELM) back with the new version of software (OBDKey 1.40 00025) which supports SSM. Sadly it fails to perform very well. I see many missing request/replies in slow poll if it even connects in the first place.
The http://www.btssm.com/ product is perfectly stable and can be used with any Subaru ECU that still supports K-line communications (slow or fast poll) via the OBD connector.

perfect! thanks Dcshultz.

It appears that currently Android logger is not the only inexpensive solution.
8' Windows 8.1 tablets under $120-250 fill the bill.
16GB ROM ( about 5 GB is available for user applications ) and 1 GB RAM is quit enough.
8' ASUS Vivo and Prestigio Visconte are capable for all day logging and tested with wired and BT adapters.

Cheep BT ELM adapters are based on different BT modules.
Some of them are not able to send packets longer then 20-120 bytes that is complety not applicable for SSM.
Those BT adapters require additional effords in PIC controller programming and testing.
I would prefer to spend similar effords on OBD-CAN or at least SSM-over-CAN translator development.

Apparently the OBDKey works with Torque and SSM, so I doubt it's a packet length problem. I think it has something to do with the BT connection not staying connected. I just haven't had time to dig deeper.

my android app works with OBDKEY just fine so far

This is what Im currently doing; running RR logger and actually a couple of successful flashes (more failures though, it fails to read back at various stages (random) causing failure. It also is slower than using my Macbook with a windows VM (for flashing, logging is fine).

Any suggestions for a BT unit to keep cables on the dash to a minimum?

Hi

I had missed this discussion earlier and only recently became aware of BtSsm. I started looking at the Android approach, but then went back to an earlier idea of using Romraider (logger) on a Windows tablet. Your post piqued my interest once again. Has any more testing been done pairing the BtSsm bluetooth adapter with Romraider (logger)? If, as you noted, it worked with your test ECU, do you think it would work with the TCU as well?

It should.

It will work provided your TCU supports k-line SSM2 protocol.
Not all TCU does.
I use a similar tool chain ( BT dongle / Tablet PC / ecuExplorer ) for some years.

Thanks for the replies!

Been using RR on a laptop with the Vag-Com for some time now (full coverage of ECU and TCU PIDs, including "switches", logger only) but if the BtSsm bluetooth adapter will work with RR and a Windows tablet, as well as with BtSsm on an Android phone (the BtSsm App), that will fill my interest for monitoring and logging for now. ("Second instrument panel")

dshultz -- back around October 2013 we discussed the need for the ECU to be defined in order for RR to display the Learning Table Values, and the fact that there wasn't (isn't) a definition for my ECU 4B12148007. I recently corresponded with heiche (BtSsm developer) with this same concern because the App video and handbook focus on the LV. He added an "alias" (I guess in the App) so that my 4B12148007 will be substituted by 4B12147007, which is defined. I haven't yet set up an Android device to test this out (will initially do it with the Vag-Com cable), but this should be interesting as well. What do you think?

Incidentally, is there a connection between Romraider and BtSsm? They seem to be so similar, even down to using the rear defrost button to control recording. Or is it because RR is "open source", and anyone can apply the basic program to other OSs and applications?

I am waiting to the Andriod head unit to be delivered. that will be amazing clean installation with BtSSM App, will keep you posted with the details.
Wayne from BtSSM will support hopefully if there is compatibility issue.

http://www.autopumpkin.com/car-dvd-play ... dvd-player

The BtSsm app is a completely home-grown codebase that is different than RR and other SSM efforts. But it does try to accomplish a similar goal (communicating with Subaru ECUs using the SSM protocol to present the user with meaningful info). But specifically for Android. This being said, some definitions for extended parameters have been helpful, thanks to the hard work here at RR (another donation being made now!)

And the BtSsm hardware adapter was simply designed to present the SSM data to bluetooth devices, intended for the android app, but in a generic way.