paddlenbike

iTrader: (1)

I searched the web in an effort to find aftermarket PDA (Palm) support for the BR-3 scan tool, but came up dry. Has anyone found compatible PDA software? I have an old Palm Vx and would love to use this software called "OBD Gauge"


Beyond protocol differences, is there really that much difference in the hardware that would disallow certain software from being used?

Here is the website for OBD Gauge: http://www.qcontinuum.org/obdgauge/

midiwall

Yeup, Bev (the designer of the BR-3) has always had the message header specs up online, but no one's ever written anything for Palm OS.


Are you talking about how "in theory' you should be able to take the OBD Gauge software, and tweak it for use with the BR-3 hardware? Yes, "In Theory" that should be possible.

The BR-3 interface is basically a PIC which is taking the raw OBD-II message stream and packing it up into something easier to digest. The work involved in tweaking OBD Gauge to work from this depends a LOT on how well written OBD Gauge is in the first place. If it's a well structured program, then the work is straightforward. If its data handler is a hack, then you have a LOT of work to do.


btw... You may also want to look at Auterra's offering, it's pretty elegant and will work just fine with your Palm Vx. I have both the BR-2 & Auterra systems and love them for different reasons.

paddlenbike

iTrader: (1)

Thanks for the reply midiwall. I was having trouble deciding between the BR-3 and the one from Scantool. I ultimately chose the BR-3 because it was cheaper and had a better Windows user interface, however I had forgotten that it had no PDA support. There are also quite a few 3.4 owners here that have the BR-3s, so I figured I would have my own support group. It should be here on Thursday.

midiwall

Ahh... well, Bev's got the info out there on how to use his interface, and the source for OBD Gauge is on their site, so "In Theory" (there's that phrase again! ) someone has everything they need to be able to make it happen.

I haven't done any Palm programming in a quite a while... Maybe this is an interesting way to get back into it.

Which OS flavor is in your Vx?

paddlenbike

iTrader: (1)

The Vx uses Palm OS 3.3 but alledgedly can be upgraded to 3.5 with ease.

I emailed the guy who markets the BR-3 and he said the same thing as you--the information needed to write PDA-capable software for the BR-3 is available on the web, but to his knowledge no one has written the code to do it.

Want new-found popularity and the potential to make some $? Palm support for the BR-3!

paddlenbike

iTrader: (1)

Not to encourage you or anything but

(1) here is the zipfile containing OBD Gauge 1.9 software

(2) here is the source code for OBD Gauge 1.9 (zipfile)

(3) here is the link for the free download utility "Palm OS Developer Suite."

midiwall

Yeup, I pulled it a bit ago, have it all here and have been looking at it.

It's not trivial work, the I/O in the OBD Gauge app is broken out fairly well, but he's pulling data directly out of the input buffer higher up the food chain. That means that on top of the I/O having to get tweaked for Bev's protocol, then a "thunking" layer has to be written to get the data from the OBD.com stream into the places that ODBG wants to see it.

There's also an issue of setting up the init data and various request streams to make it through Bev's PIC.

And... the OBDG app is a bit short on error checking. It doesn't understand timeouts or how to look for the interface before trying to talk to it. That's currently causing a bunch-o hangs which will make the work even more "challenging".

Not "hard", just "time consuming" considering that there's no real documentation, and a bunch of guesswork involved. As well, the ideal spot would be to code this in the 4Runner while the Palm is hooked up to the interface. It's kinda' cold out in the driveway, cramped in the cab, and the laptop would be a PITA to code on. {whine}


So, that all said...

midiwall

Status update...

- I can build the original project and it matches his binary download. That's a HUGE step. It's VERY uncommon these days for shared source to compile clean and actually match the download binaries.

- There's now a new option in the Preferences | Interface drop list for "OBD.com". It doesn't do much, but it's there and shows that the code is modifiable and rebuildable.


I think my first foray will be to fix up his routines for port detection and timeout. If I don't fix that first, this will be a bear to work on.

paddlenbike

iTrader: (1)

So do you think you can actually get this to work? Laptops are bulky and somewhat expensive, while a Palm Vx can be purchased for $20-30, boots immediately and would become a permanent addition to my 4Runner's toolkit. I would be *thrilled* if I could just read MIL codes and display two or three parameters at a time, similar to the pic in my first post. If this is even in the realm of possibility, I'm excited!

Ken

midiwall

I might be able to... A lot of it depends on the time I can put to it. This week is a bit mashed up, but I should be able to dig into it pretty well next week.

My main fear _was_ that the source for OBDG didn't match the binary, now that's gone, so the next fear is sitting down and being able to make use of Bev's header info. Debugging on the Palm _without_ the compiler interface is grueling, and my laptop won't support the Palm OS interface.

I've written a couple of routines already that should make it easier (like a routine to be able to stream the buffer contents out to the display).

Lemme say this.. I'm encouraged by what I've been able to do so far, and I _will_ keep working on it. I won't make any promises though. This is one of those "anything is possible, it's only software!" projects... (kinda' an inside joke to devs)

paddlenbike

iTrader: (1)

Got my BR-3 yesterday and got to play around with it a little. It found my MIL was triggered by a lean engine condition (P0171)...this popped up shortly after I did the deckplate modification. I'll try cleaning the MAF and see what happens.

The readings on the laptop screen exactly matched my dashboard readings and it was interesting watching things happen as the engine warmed up--the ECU switching from open loop to closed as it warmed up, coolant temperature steadily climbed to 190 degrees, thermostat opened and the temp never went over 191 degrees after that. Now I'm thinking it's time for something custom. What I would really like is a four-line LCD display mounted in the DIN slot below my stereo that would allow me to monitor some of this stuff.


BTW midiwall, I happened upon this site and thought it might provide you with some more programming info. http://freediag.sourceforge.net/

Ken

midiwall

It can't hurt, and should help. Also clean out the TB and air filter.


I had started a project a couple of years ago to put a PC under the passenger seat and have it feed an LCD panel in the dash. That's pretty comon these days, but my specs also included running the BR-2/-3 through it and supporting the SMT-5.

The short of it is that the PC crashed, it got sent off to be dealt with (it wasn't a common motherboard) and I never got it back.

If you're interested in something down those lines, there's a TON of info over at MP3Car.com. Those guys have pretty well perfected mounting PCs in the car.

Past that... If you're really just looking for a 4-line panel, then there's a bit of work behind it. The LCD is easy enough to come by, but you'll need to looking to a Basic Stamp or PIC to drive the display, handle user input and process the OBDII info. That'll be programming in BASIC or C and some hardware design. Pretty straight forward stuff though - once you get the OBDII stream info broken out.


Yeup, I've looked at those guys before... They actually support Bev's box, so I may grab their driver and see if I can retrofit it into the OBDGauge app.


btw... I've got the I/O routines beefed up for OBDGauge. They now know about timeouts and the interface not being there. Work progresses!

paddlenbike

iTrader: (1)

Sure enough, the MAF was dirty. The truck was literally faster at 3/4 throttle than full, now it drives as it should. The BR-3 paid for itself the first day I had it.

I have considered going the carpc route--the biggest downside beyond cost is screen location; even a motorized flip-out TFT in the top DIN slot is too low for useful navigation. I thought it would be slick to enclose a touchscreen TFT into the driver's side visor, then you can flip it down into your field of vision when you want to use navigation features, obd stuff, etc. I have a lift, rock sliders and other things to worry about first though.

There are some new LCD/vacuum florescent displays on the market that are designed specifically to read out OBD information; like the one pictured above. They are way pricier than they should be considering the hardware involved.

GREAT! I will be *thrilled* if you able to integrate the OBD Gauge software with the BR-3. Check out some of these closed ebay auctions...complete Palm Vx units are selling for $22. An older Palm and the BR-3 would make a perfect toolbox companion on a long trip.