Renault "Tuner List" Head Unit/CD changer hacking - Controls - Page 6

Vicne · 02-14-2006, 02:49 AM

Quote: Originally Posted by Ale

I think that something go wrong with level 0 threshold becouse the recalculated CRC of the frame 3D 01 FE FD isn't correct (3F instead of 0).

Well, indeed :
- either this frame is a special connection attempt "Anybody there ?" that doesn't follow the normal format. Not only is the CRC wrong, but also the length which should be 0
3D : start frame
01 : frame ID
FE : length (not !)
FD : CRC (not !)

- or there's a decoder error. But it would be perfectly reproductible 3 times in a row, while bytes 3D and 01 are decoded OK ? Strange...

I'd be tempted to think it's a special message that isn't in the "frame format"...

BTW, just to make sure : that's the message he saw when reading the Tx from the HU while no changer was connected, right ?

Vicne · 02-14-2006, 04:22 AM

Quote: Originally Posted by pippolippi

connects2 uses an ba8270f to interface to the head unit and I don't see how this chip could be used if HU interface is compatible with a simple rs232

I don't understand either. This chip seems targeted at synchronous communication while here we obviously have asynchronous dialog. Even if I direct connection is not reliable, putting a MAX chip seems much easier than using this specific circuit.
Maybe all Connects2 devices share the same multifunctional hardware to make scale savings, and only the software and external connections vary from model to model ? Just an idea...

pippolippi · 02-14-2006, 05:22 AM

Quote: Originally Posted by Vicne

BTW, just to make sure : that's the message he saw when reading the Tx from the HU while no changer was connected, right ?

Well, as I said I don't really understand romanian

but I think so. What I found interesting is that he connected the pc directly, with no interface.

Putput · 02-14-2006, 07:53 AM

I took both logfiles (COM1 and COM2 dump files by Vicne) and tried to parse them with the info gathered so far. I don't think that it needs much explaining, just try to load the log files (or any log files in the same format) and see what happens. As you can see, there are still some errors (in parse code or logging

) that we need to exclude before everything is clear. I think that most of the errors (sorry Vicne

) are logging and communication errors, mostly its just 1 bit wrong thats why I'm assuming that they are communication errors. I also recalculated the FCS for each frame, when something is wrong the FCS is written in red and after the 'x' the correct FCS is stated for the frame as it was logged.

Vicne · 02-14-2006, 08:26 AM

Before going further, I really want to find where these errors come from.
Here are my observations :
- They seem to affect almost always the first byte. Moreover, this byte doesn't get a random value, but almost everytime BD or BF.
- The most affected frame seems to be the second one after a track change...
- Most errors consist in '1's read instead of '0's : We get BD (10111101) or BF (10111111) while we should get 3D (00111101)

Possible causes :
- Ambiant noise.
- Level problem.
- Software problem.

I really don't think it comes from software. Not only because I'm better in software than hardware, but mostly because it works most of the time, and errors are so localised.
The fact that many errors come after a track change can be due to the spikes generated by motors inside the changer, or to the motors drawing so much current that voltage drops temporarily and levels are pulled down...

Anyway, when I have time, I'll try the changes advised by Ale and will take some mesures again to check levels and threshold

Vicne · 02-14-2006, 08:45 AM

Quote: Originally Posted by Putput

I took both logfiles (COM1 and COM2 dump files by Vicne) and tried to parse them with the info gathered so far. I don't think that it needs much explaining, just try to load the log files (or any log files in the same format) and see what happens. As you can see, there are still some errors (in parse code or logging

) that we need to exclude before everything is clear. I think that most of the errors (sorry Vicne

) are logging and communication errors, mostly its just 1 bit wrong thats why I'm assuming that they are communication errors. I also recalculated the FCS for each frame, when something is wrong the FCS is written in red and after the 'x' the correct FCS is stated for the frame as it was logged.

Now, that's great !

Maybe you could add a checkbox "only show CRC errors" the same way you put "show C5". This way I can play around with my circuit and quickly load a dump and see if it has errors or not. I intend to play a bit with the values of the divider resistor to see if it's a threshold problem...

Just a question : once you get a bad CRC, how do you resynchronize ? I mean, if the length byte is wrong, we jump too far and crash in the following frame and so on...

Oh, and for the sake of knowledge sharing, would you mind posting the source code ? It's written in Delphi, isn't it ?

Thanks a lot for your efforts.

Putput · 02-14-2006, 09:31 AM

Yes, I use Delphi, old habit, I'll change the program and post it here. No problem

.

Quote:

Maybe you could add a checkbox "only show CRC errors" the same way you put "show C5". This way I can play around with my circuit and quickly load a dump and see if it has errors or not. I intend to play a bit with the values of the divider resistor to see if it's a threshold problem...

Allmost done.

Quote:

Just a question : once you get a bad CRC, how do you resynchronize ? I mean, if the length byte is wrong, we jump too far and crash in the following frame and so on...

I tried to make it a little bit 'intelligent', First: when I read a frame length larger then 32 bytes its marked as bad. Second: once length is bad the prog tries, byte/byte, to find a new 3D or C5 or something similar in the data region. When found, it assumes that everything in front of that byte is data + CRC and, the known byte is the start of a new message. Its not waterproof but it works pretty well I think. Of course when a 3D appears in the data section with a corrupted length shxt hits the fan ...

.
Stay on it, where almost there.
Another thing, on my todo list is still a selfmade OBDII interface using a MAX232 as RS232 interface together with ELM323, its designed in Eagle, do you want a copy? Perhaps you can use it for comparison, its designed to work in cars.

Putput · 02-14-2006, 09:36 AM

Oeps, lost track of time, my Valentine date is waiting. Got to go, sorry, has to wait until tomorrow.

Vicne · 02-14-2006, 09:56 AM

Quote: Originally Posted by Putput

Oeps, lost track of time, my Valentine date is waiting. Got to go, sorry, has to wait until tomorrow.

Same for me. We must take care of not reaching a critical level of WAF (Women Acceptance Factor).
So there'll be a pause tonight :-)

Putput · 02-14-2006, 10:00 AM

Found 5 minutes, so here's the new version.

Happy Landings!!

mox · 02-14-2006, 01:01 PM

Quote: Originally Posted by Vicne

Mox, can you check on your connects2 if pin 17 is connected to something ?

The pin is in use, but it is definitely not the main power supply. My guess would be that the connects2 starts mimicking a CDC once pin 17 goes high, i.e. when the HU is turned on.

Quote:

Maybe you have hi-res pictures of the PCB ?

I happen to have this one hires'ish picture, taken before I stashed the interface behind my dashboard's top cover:

Of course the PCB is double sided but unfortunately I don't have any pictures of the flip side (which actually contains only a few minor components, like a little donut shaped transformer, 2 RCA connectors, 2 crystals and a couple of electrolytic caps). The 14 pads at the bottom center belong to a small molex connector, some pins of which are not being used. The connects2 comes with a cable with a (partially wired) 14-pin harness at one end and the familiar blue ISO at the other. I have marked the pins in use with numbers.

1 = 12V (permanent)
2 = 12V switched (the famous "remote out", pin 17)
3 = UART A
4 = SPDIF GND
5 = SPDIF out
6 = UART B
7 = GND

The printing on some of the chips is a bit unclear, but the actual types can be found in one of my earlier postings: http://www.mp3car.com/vbulletin/show...1&postcount=13

Quote:

By the way, it would be very interesting to know if the connects2 follows the same "3V/12V" convention. It would be easier to do 0V/12V if it's compatible, but if connects2 bothered making 3V/12V, it's probably a requirement...

Let me fix something to eat first, I will take the oscilloscope out into the garage afterwards. I am feeling a bit guilty of neglecting this thread, especially since you guys have been making such excellent progress lately. Sorry about that

Vicne · 02-14-2006, 03:37 PM

Still here, but not for long :-)

Just got an idea and would like an opinion (Ale maybe) :

What if I used an offset instead of a resistor divider ? Practically, I'd replace the 18K resistor by a few diodes in series to get, say, 2.5 V drop, transforming the 12V/3V levels into 9V/0.5V which would be much more immune to noise than the values I have now 4V/0.75V, wouldn't it ?
Well, input impedance would be divided by 4 but I don't think it's a problem...

Any comment is welcome.

Ale · 02-14-2006, 06:24 PM

Quote: Originally Posted by Vicne

What if I used an offset instead of a resistor divider ?

I think that if the spikes are so high they can pass the divider, the drop of 2,5V without the divider isn't enough. Or the spikes aren't so high but enter from the gnd pin of max232, if this is the case it is better to filter with the 10 uF capacitor near V+ and GND pins. Or try adding another 33K resistor connected between rx pin and V- of charge pump (-5V).

Vicne · 02-15-2006, 02:10 AM

Quote: Originally Posted by Ale

I think that if the spikes are so high they can pass the divider, the drop of 2,5V without the divider isn't enough.

So, if my understanding is correct, you think it's due to noise and not to a threshold problem, like I'm misusing the RS232 input by using it as an inverter, or the internal resistor is at the boundaries of the spec or something ?

Quote:

Or the spikes aren't so high but enter from the gnd pin of max232, if this is the case it is better to filter with the 10 uF capacitor near V+ and GND pins.

I'll put the 10 uF capacitor for sure, just have to find time to go to the nearest electronics shop - when it's open :-)

Quote:

Or try adding another 33K resistor connected between rx pin and V- of charge pump (-5V).

Wow, sorry to bother you again as you're helping me, but can you give a few words of explanation about the goal of this resistor ? Drag the voltage down further ?

Thanks for your unvaluable help.

Vicne · 02-15-2006, 01:33 PM

Quote: Originally Posted by Putput

Another thing, on my todo list is still a selfmade OBDII interface using a MAX232 as RS232 interface together with ELM323, its designed in Eagle, do you want a copy? Perhaps you can use it for comparison, its designed to work in cars.

Yes, thanks, that can be a helpul source of inspiration.