pcmhacking.net

Well ill just leave it out unless I run into other problems. Bit pointless since program relies on the message length to receive other bytes.

I chucked in a timer to see the difference between using the "readline" and a loop for readbyte(), turns out the time it takes for both to get the exact same frame is pretty much identical, but ill leave the read byte function in to see if that fixes the problem.

I put in a quick tester background worker to continuously spam frames over the com port. Frames are being sent with 3ms intervals and program seems to be keeping up so car communication speed shouldnt be an issue
Also had it sending through a "correct" response randomly when I send through a frame, seems to be picking it up flawlessly now with all the other data. Im thinking that the buffer was full as stated by you guys, buffer is now emptied every time a frame is sent.
Will do a proper log tomorrow and post up the result.

Cheers.

Thought Id update for anyone interested.


Sorry not the best picture, computer screen capture is not exactly great!
Is picking up all chatter, Have had it running through couple serialport monitors at the same time and it hasnt dropped any packets even after some time.

The custom frames sent works great now that im using the "readbyte" function, the readline seems to miss bytes and is inconsistent.

Been a while since I posted about the logger.

But been going really good so far! Been able to track down specific packets sent and received with the help of some DH members. Found how the instrument cluster gets the "volume" info and also the "radio station" info. Can simply parrot those packets and display different stations out of the car!.

Hoping to figure out which "mode" will allow for custom text displayed over the whole screen, since theres someone on youtube that does it! Im sure most people have seen it.

Anyways, hoping I could get a few answers on how vital timing/silence when dealing with aldl communication?
As in, I noticed OSE tool searches for "silence", is this required when sending custom frame or is it simply done to allow best chances of retrieving a reply?

For a few applications where by a bcm or cluster is required to be unlocked, it requires a few frames to be sent and collected. I send a "disable bcm" chatter a few times then send off the frame immediately, generally a reply is picked up instantly and all is good!
But Iv found in other cars, sometimes it struggles to get a response as I believe the chatter starts up quicker? Or chatter doesnt stop immediately or quick enough?.
In saying that, Im guessing a higher class car (eg a Lux BCM) will have more chatter on the bus then a lower model (mid BCM)?

Cheers,
Taz

as the cars get newer there are more and more devices sending regularly timed data on the bus. The BCM is sending the heartbeat, all devices see it, wait a programmed amount of time then fire off their packet. This keeps them in sync and prevents bus collisions. There is a short gap, i think it is immediately after the heartbeat, and you need to get your packet in there so no other devices transmit and collide with your data. Silencing chatter in that gap helps immensely, as it removes most of the problem in the first place, but you also loose the dash etc. In your case, its probably no problem. That is what people are trying to do. Windows timing is not so great, and windows serial drivers are not designed to be time critical either so it can be hard but some apps can do it successfully (efilive v4, VL400s flash tool etc) so it can be done.

This is what the bus of a VT looks like on a scope, it repeats over and over (its all BCM initiated with the replies coming from all the devices when they are addressed). You can see the ~123ms free bus time that you should be aiming for when initiating comms and silencing the BCM... And this shows a zoomed in section, heartbeat is the last thing before the free time...

and that my friends is the delco matrix

Ahahahah, wow! Now that was interesting to see! Looks nice and organised when viewing by the scope.

I know of windows/VB limitations now after going through all the hassle of getting it to communicate successfully and work happily! It does work.. just temperamental at times!

So pretty much, I would need two setups. One for being in car and the other being out of car (on bench). I need to search out the heart beat (does that when listening to chatter), then once heart beat is found, fire off the disable BCM frame then send my custom frame for the greatest "silenced" time for a successful response.
Alright... this will be interesting!

I guess collecting the difference in time between sent frames would help, can get it to fire off once its found the heartbeat and had around say 25ms of silence.

Good to know theres a more "precise" approach instead of spamming disable chatter!

Should be able to tx straight after the heartbeat. Also If you know that your frame and the response are less than the total silence time you can get away without disabling chatter.

Using the silence works well, can request and log a full message 0 data frame in the silence. The ALDL logger does this, data rate is terrible (~3Hz) but means you keep the dash happy.

WOW, searching for Heartbeat and sending directly after makes a MASSIVE difference with response time, reliability and dont require sending multiple times and always get a response!

Just need to test in a few different cars to check it works and fine tuning it.

Cheers for the help!

Hoping to get possibly a beta version of the logger out for testing and feedback sometime soon once got a few other minor changes sorted, if anyone is feeling game to test!