ALDL logger VB10

Programs / Tools / Scripts
User avatar
charlay86
Posts: 584
Joined: Thu Sep 17, 2009 2:00 pm
cars: VT S1 SS (L67)
Location: Perth, WA

Re: ALDL logger VB10

Post by charlay86 »

All the chatter on the bus is scheduled, so once you identify the pattern of the chatter you should be able to know what packet to expect, and when to expect it (and perhaps most importantly, when to expect the bus to be silent!). Send the disable chatter command after the heartbeat as there will be the longest silence then.
With chatter disabled there should only be reply messages in response to the ones that you have sent (until the disable chatter times out, or you enable it again).
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: ALDL logger VB10

Post by Tazzi »

Alright, I have noticed the trend in the received frames but havent look into it alot. But being able to predict when/where the information is going to appear would optimize the performance since its not filtering everything.
I think that will be the plan to cut back the unwanted chatter, disable chatter, send message, look for response, resume chatter. Will see how that works out, cheers charlay.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: ALDL logger VB10

Post by Tazzi »

Bit of an update on it all.
Image

All filters working brilliantly, Counter works great. although when there is ALOT of different ALDL frames to compare with in the list then it starts to drop packets (unfortunately) but thats after 100's of lines.
As you can see Im just letting it pick up the "echo" from the sent for the moment.

When plugged into the car, I occasionally get the original problem I was facing at the beginning of this all!. Dont understand why it is occuring, performace is definitely not an issue so its something to do with the codind or cable. Could be to do with the tiny small delay due to the length of the aldl cable (I think).
When data is received, it is automatically picked up.. as seen below:

Code: Select all

Private Sub SerialPort1_DataReceived(ByVal sender As Object, ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles SerialPort1.DataReceived
Dim Count As Integer = SerialPort1.BytesToRead  'set count as the amount bytes to read
        Dim Buffer(0 To (Count - 1)) As Byte    'set buffer array
        Dim Text2Display As String = ""   
        SerialPort1.Read(Buffer, 0, Count)
The amount of bytes to read is automatically set, when thinking about it, this could also be the issue, as the messages are set so often and quickly that it could be picking up the wrong information?
Bytes are then put into Buffer array to then be viewed on screen.

Im having trouble figuring out how to set a "filter" to search for heart beat and then display all aldl frames flowing through the bus. Still ran into the same problem which bits and pieces mumbled up sometimes.

SOOO, Id say I need to find 8,55,A3 .. then look for next two bytes.. eg. 11,5A which will then inform program that there is another 5 bytes + checksum to grab before getting the next two bytes.. ect ect.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
VL400
Posts: 4991
Joined: Sun Mar 01, 2009 2:54 pm
cars: VL Calais and Toyota Landcruiser. Plus some toys :)
Location: Perth, WA
Contact:

Re: ALDL logger VB10

Post by VL400 »

Yeah you need to eat bytes until the heartbeat is found. I do this using the rxr to get two bytes initially, makes it easier to throw away bytes - don't want to get an 0x08 that is the cs of the previous frame, but assume byte 1 and then throw away the real id 0x08 if it was next up thinking its less than 0x55.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: ALDL logger VB10

Post by Tazzi »

Alright, after a bit of frustration with working a way around the serialport locking up due to no data being received (when not plugged in). Have got it demolishing bytes that come through!. keeps eating till it finds 08.. grabs next byte to check if its 55.. then grabs next one to check its 03. If none are found, it loops around a few times before cancelling. If it finds the heart beat, it then grabs first byte as DeviceID and next byte is the message length. A readline is called to grab the remanding bytes after finding the message length. Process is then repeated.

So all of the above is only used when listening to the chatter. Have slightly adapted it for searching for response when an frame is sent over the com port. Chews throw the bytes to find the device id (taken from first byte of sent frame), once found it takes next byte as length then gets the rest. BUT I seem to be having an issue with an echo response from the sent frame.. sent frame is picked up in the received side.
Iv ended up adding another IF statement to check if the received frame is the same as the sent... if so it starts eating the bytes again to find the next deviceID match.
So my problem is.. is there any point/situation that a device ID would send back the same message? Any other ways of removing the echo? A simple but I guess dirty way of it is to Send message then immediately put thread to sleep for 10ms or so, might be long enough to miss picking up the frame.. although could end up missing the actual response. Or I turn off the received side of the com port, send message then turn it back on directly after.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
charlay86
Posts: 584
Joined: Thu Sep 17, 2009 2:00 pm
cars: VT S1 SS (L67)
Location: Perth, WA

Re: ALDL logger VB10

Post by charlay86 »

Surely the serial port hardware still buffers the received data while the thread is asleep..?

I guess you could blindly discard the data in the RX buffer as soon as you finish transmitting your message.
But maybe checking the echo is a good thing, that way you know that your message transmitted correctly;
If it was corrupted you would not be able to trust the reply frame to be valid, in which case you would need to re-transmit your message.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: ALDL logger VB10

Post by Tazzi »

Cheers for the response charlay.

Oh yeah the RX buffer will still get data when thread is asleep, I just meant clear the buffer out after 10ms or so since the echo is pretty much immediately after sent.
charlay86 wrote:But maybe checking the echo is a good thing, that way you know that your message transmitted correctly;
I originally figured that. But second guessed my self.. Just unsure if any modules ever send back the same frame that was sent. Guess it wouldn't really make sense if that was the case.

But yeah it does give a good indication whether the frame was sent correctly. Although I run my program with a serial sniffer at the same time and haven't had any problems with the sending side of things. Only the receiving, need to minimize the amount of worked required when filtering the data. Possibly need to do some more threading optimization.. could be why so many people drop bytes occasionally?
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
charlay86
Posts: 584
Joined: Thu Sep 17, 2009 2:00 pm
cars: VT S1 SS (L67)
Location: Perth, WA

Re: ALDL logger VB10

Post by charlay86 »

Tazzi wrote:
charlay86 wrote:But maybe checking the echo is a good thing, that way you know that your message transmitted correctly;
I originally figured that. But second guessed my self.. Just unsure if any modules ever send back the same frame that was sent. Guess it wouldn't really make sense if that was the case.
you could have a "echo received" status flag that is cleared at the start of your transmit routine, and is set once you receive the first frame that correctly matches your transmission (i.e. the echo, which should obviously be straight away) and then any other data frame after that is treated as a reply, regardless of it matching the sent frame or not.

It is pretty low speed communications, I don't really see any reason why it should be dropping data, maybe it is a limitation of visual basic.

As far as optimisation goes, (just thinking out loud here) perhaps you could have the TX/RX thread insert the valid sent / received frames into a lightweight database, with a unique ID (but common to each corresponding sent / received message pair) and a timestamp, that way you can query the database in another thread, letting the DB engine do the filtering via a select statement.
VX L67 Getrag
Posts: 2877
Joined: Sun Aug 02, 2009 9:16 pm
Location: Bayside, Melbourne, Victoria
Contact:

Re: ALDL logger VB10

Post by VX L67 Getrag »

As far as dropping frames I think VL400 may be able to shed a light here as he knows his does & I've noticed it quite frequently, but with old version 4 of EFI live I have it picks up every single frame?
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: ALDL logger VB10

Post by Tazzi »

Yeah having a read over the web about VB's serial communications abilities and dropping packets. I seems that people that used VB6 or higher experienced packets being dropped.. with no explanation. Must have been a limitation or coding error in VB in the newer versions. Although I didn't find much on VB10 struggling with serial communication and packet drops.
Efi live V4 would have probably been made with one of the earlier versions of VB which didnt seem to drop packets.
charlay86 wrote: As far as optimisation goes, (just thinking out loud here) perhaps you could have the TX/RX thread insert the valid sent / received frames into a lightweight database, with a unique ID (but common to each corresponding sent / received message pair) and a timestamp, that way you can query the database in another thread, letting the DB engine do the filtering via a select statement.
Alright, that sounds like a good path to follow.. although I havent used any database functions in VB so thatll be a first. Guessing once the info is in there, itll be pretty easy to filter and check.

Have now chucked in a "Echo check" that you suggested charlay so that once the echo is picked up, the search continues on. This is assuming that there will always be an echo. Will change it so that it is not depending on that later!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Post Reply