ALDL logger VB10
Re: ALDL logger VB10
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).
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).
Re: ALDL logger VB10
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.
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
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Re: ALDL logger VB10
Bit of an update on it all.
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:
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.
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)
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
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
- 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
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.
Re: ALDL logger VB10
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.
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
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Re: ALDL logger VB10
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.
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.
Re: ALDL logger VB10
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.
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?
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.
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.charlay86 wrote:But maybe checking the echo is a good thing, that way you know that your message transmitted correctly;
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
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Re: ALDL logger VB10
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.Tazzi wrote: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.charlay86 wrote:But maybe checking the echo is a good thing, that way you know that your message transmitted correctly;
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.
-
- Posts: 2883
- Joined: Sun Aug 02, 2009 9:16 pm
- Location: Bayside, Melbourne, Victoria
- Contact:
Re: ALDL logger VB10
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?
Re: ALDL logger VB10
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.
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!
Efi live V4 would have probably been made with one of the earlier versions of VB which didnt seem to drop packets.
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.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.
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
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726