OBDX Development - Developer Tools and Suggestions

[bubba2533]

The next item I have been excited playing with, is the potential for addition of an SDCard to a new design we are working on. With that, I have been able to do semi and fully automated setups for read/writing engine computers using the tool (Pretty damn cool!!!!!). Logging can also be setup to begin saving logs to the SDCard, and can then be later uploaded to a PC using wireless or USB connection.

This is the best thing I've heard all day!

[hjtrbo]

Question, any consideration to adding mode $23 as an advanced option to your s/w?

[Tazzi]

Question, any consideration to adding mode $23 as an advanced option to your s/w?

Its not something that would go into a public OBDX app since its not really something people need or use.

But could be put into just a very basic program to prob a modules memory, or loop through memory addreses?

[hjtrbo]

But could be put into just a very basic program to prob a modules memory, or loop through memory addreses?

I would really like that. I know u/p can do it with a bit of advanced knowledge, but for a newb it's a bit daunting where to start.

[Tazzi]

I would really like that. I know u/p can do it with a bit of advanced knowledge, but for a newb it's a bit daunting where to start.

Ill see how I go for timing over the next week to pop something together.
Is there something in particular your wanting to poke at?


Onto todays adventures of wireless flashing and time differences.

The best way to get a real feel for how fast a tool is going, is adding the support of a wireless protocol to J2534 so I can compare flashing times.

When flashing a OS on a BCM, it took:
USB = 113seconds
WIFI= 123seconds (~10% slower)
Classic BT = 131seconds (~16% slower)

I was quite shocked with the BT results, I actually thought it would be faster then WIFI, but WIFI took the cake for wireless.
The Bluetooth connection is 'technically' using a socket connection.. so.. there could be some latency being brought in here but Im assuming its running pretty damn close to the actual native speed.

I know we are only talking about 10-20seconds difference here. But routines that take up to 45mins+ could result in actually taking close to 1hr+ depending how the latency is in comparison to USB.
Which makes you think that wireless probably isnt such a great idea for long running tasks like that.

Reliability wise, I stayed connected to both, non-stop repeat flashing for 1day each without a single dropout issue. So anyone that tells me wifi or bluetooth is unstable and unreliable can go kick rocks until they show me the proof

Now heres the real kicker... time to flash via SDCard routine = 111seconds.
This is the theoretical limits of flashing this module since I there is no delays via USB or anything else via this method.

[hjtrbo]

Ill see how I go for timing over the next week to pop something together.
Is there something in particular your wanting to poke at?

Yah.
E67 and T43. For the T43 I'm hoping to read about 30 ram addresses between 0x300000 and 0x30ffff. Looking at torque converter state machine registers primarily. Haven't got to my e67 yet so nothing on that for now.

Ooh that reminds me. I'm looking at moving away from my Tatrix to buy one of your cables for using with PCMTEC, would you happen to know if there is any improvement in polling rates for ZF data-logging? I understand the bit about Rolands software driving the timing of comms requests, however I wanted to know if you have had some feed back from customers.
Ta, hj

[Tazzi]

Yah.
E67 and T43. For the T43 I'm hoping to read about 30 ram addresses between 0x300000 and 0x30ffff. Looking at torque converter state machine registers primarily. Haven't got to my e67 yet so nothing on that for now.

Ooh that reminds me. I'm looking at moving away from my Tatrix to buy one of your cables for using with PCMTEC, would you happen to know if there is any improvement in polling rates for ZF data-logging? I understand the bit about Rolands software driving the timing of comms requests, however I wanted to know if you have had some feed back from customers.
Ta, hj

I feel like the ZF uses kline? From memory? With the OBDX Pro scantools do not support at this time.

[hjtrbo]

Too easy, i'll throw a post up on the pcmtec forum. Cheers Tassi

[Tazzi]

I have done a great deal of learning with SD cards recently, so much so I'd like to say Iv become a bit of a pro with understanding the nitty gritty of them.
The easier connection to them is using SPI, this does not get you crazy fast speeds like you see with dedicated SDCard readers, but with the correct memory management and block sizes, you can still get very decent speeds.

The last couple days have been going over some basic libraries to see how people currently handle using SDCards along with the common formatting for handling creating documents/files/ect.

When first using off the shelf libraries, writing a 4mega byte file (MB) took around 30seconds, this equated to about 130KB/s.

After some modifications with optimizing block sizes, clock speeds and transfer protocol, we do a 4MB file in 2.3seconds. This still equates to a little under 2megabytes per second, which isnt crazy large in terms of file transferring speeds that we see on computers, but in the world of microcontrollers, this is moving. Whats crazy, is this was the result of saving a millisecond between every operation which gave a huge boost in speed.

The reason for spending time on this is purely due to the reason of needing to be able to save or read files from an SDCard over a wireless connection (WIFI and Bluetooth). This comes more into play when reading the file off the SdCard when pulling something like a CSV log which could be many megabytes long.

This leads us to then optimizing how logs are saved, where by a simple 4byte timestamp and then a full CAN frame is used, all saved in raw byte form.
If logging at 60hz with 24PIDs, this would be 60x24x 16 = 23k bytes per second, which is 1.38MB per minute.
This is very much possible since CANbus is 500kbits/s which equates to a max bus load of about 62500bytes per second, so only 1/3rd of the network is still being used with the above figures.
Assuming someone logs for 15minutes, that will be roughly 20.7MB.

Still, not a big file, but that will be roughly 11.5seconds just to read the file via USB directly. Doesnt sound that bad right? Well.. the point of this is for wireless since everyone has a smartphone these days, but not a PC.

Our wireless module runs at 921600baud, which is roughly 155200 bytes per second, so assuming we could even maximise that throughput, transferring that file would take a minimum of 133seconds which is 2minutes 13sec for that 20.7MB file. Realistically, this is likely going to be more like 4minutes+ as have to account for the time it takes for each chunk of data to send plus the latency between each packet ect.

We have never needed to be faster then the 921600 serial baud rate for our wireless, since we have never needed to send large files in a short time span. But in this circumstance, we would actually benefit from migrating to a SPI connection so we can go to something like 50MHZ which would significantly speed up that transfer rate between the wireless to processor, that way the limiting factor is just the wireless protocol itself.

Anyways, Im rambling on a bit now here, but its just a bit of insite to how far we think ahead to identify our limitations to better design our hardware.

[Tazzi]

Its fantastic seeing new softwares in production! It truly does motivate me to continue expanding the tools capabilities.
I have been speaking with developers making apps for Opels, Chev/GMC, Toyotas, Nissan and Fords! Its genuinely exciting to hear from these developers!

On that note, I have been VERY busy myself, and am just about ready to release this app which will be an all-in-one GM flashing application.
The aim is to add all the custom abilities I can currently do plus basically replace techline to allow techs to perform a job without relying on techline.

So naturally, I have gone absolutely overboard with it.
I have servers configured to pull RPOs for each car which are then used throughout the application to ensure correct configuration/calibrations are offered for that specific car, along with offering any customizable options to go with them. This includes checking and verifying a modules information to minimize the chance of fitting incompatible parts.

I am looking forward to seeing the community solve issues faster and easier with this. No more "techline is down" messages, no more waiting days for support replies, there will be active developers/helpers to fix issues or provide guidance (As this is a joint venture).

Will be looking for testers soon

homescreenpic.png (69.78 KiB) Viewed 671 times