VY/VZ Headunit Mod for Aux Input

[TazzI]

Havent had much luck with the bus pirate for SPI communication. The options for SPI in BS can be seen below. Iv pretty much tried every combination possible below. And even used some other software for the BS which output different data again.. but nothing like what Nem was getting or even atreidae.. so may have to resort to the arduino and see what it gets.. May be due to the BS outputs 3.3v? and radio might be 5v logic?

Set speed:
1. 30KHz
2. 125KHz
3. 250KHz
4. 1MHz

Clock polarity:
1. Idle low *default
2. Idle high

Output clock edge:
1. Idle to active
2. Active to idle *default

Input sample phase:
1. Middle *default
2. End

CS:
1. CS
2. /CS *default

Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)

[TazzI]

Alright, I think I have hit another major issue. Seems the hardware SPI pins are introducing too much noise or something causing the communication between the lcd and board to stop. As soon as any of the SPI pins (including SS) touch the arduino pins it causes all info to hault.

I think I need slave mode... although the arduino does not support this in the SPI library *opens new google tab*

*Edit
Success! (I think!)
I was monitoring only MOSI.. But monitoring MISO shows the LCD info.

eg
[0x80(0xAA)0x80(0x00)0x84(0x00)0x80(0x00)0x85(0x00)0x80(0x09)]
[0x80(0x02)0x80(0x5A)0x80(0x7F)0x80(0x00)0x80(0xDB)0xAD(0x00)]

[0x80(0xAA)0x80(0x00)0x84(0x00)0x80(0x00)0x85(0x00)0x80(0x09)]
[0x80(0x02)0x80(0x5A)0x80(0x3F)0x80(0x00)0x80(0x9B)0xAD(0x00)]

[0x80(0xAA)0x80(0x00)0x84(0x00)0x80(0x00)0x85(0x00)0x80(0x09)]
[0x80(0x02)0x80(0x5A)0x80(0x3F)0x80(0x00)0x80(0x9B)0xAD(0x00)]

[0x80(0xAA)0x80(0x00)0x84(0x00)0x80(0x00)0x85(0x00)0x80(0x09)]
[0x80(0x02)0x80(0x5A)0x80(0x3F)0x80(0x00)0x80(0x9B)0xAD(0x00)]

[0x80(0xAA)0x80(0x00)0x84(0x00)0x80(0x00)0x85(0x00)0x80(0x09)]
[0x80(0x02)0x80(0x5A)0x80(0x3F)0x80(0x00)0x80(0x9B)0xAD(0x00)]

[0x80(0xAA)0x80(0x00)0x84(0x00)0x80(0x00)0x85(0x00)0x80(0x09)]
[0x80(0x02)0x80(0x5A)0x80(0x3F)0x80(0x00)0x80(0x9B)0xAD(0x00)]

[0x80(0xAA)0x80(0x00)0x84(0x00)0x80(0x00)0x85(0x00)0x80(0x09)]
[0x80(0x01)0x80(0x7B)0x80(0x30)0x80(0xAC)0xBD(0x00)]

The above is slowly turning volume down.. where the volume bars remain constant until it reaches the volume that a bar reduces thus the message above changes

[TazzI]

1 step forward, 2 steps back.

Soooo I can read the SPI commands... buuuuutttt I dont know how to inject them back in! haha. Im unsure if my examples on the arduino are failing because the message isnt formatted correctly or if its because the bus is being halted by the arduinos presence.. or if the Hz speed is too high!

The radio communicates on really low speed, well.. thats what I found using the bus pirate.. all the higher speeds produced rubbish data. On the arduino Mega, at its 16Mhz frequency.. the slowest I can get it is 16/128 = 128Khz, which is still too fast (1 think). I originally attempted reading the MISO/MOSI at 1Mhz.. which really gave out odd/useless data that meant nothing.

Well.. might need to use something with a lower frequency. Or exchange the 16mhz for a 4mhz one..

Or, I can hook the buspirate onto the SPI at the same time and see what the arduino is sending.. which is probably the smartest option there.

*Random Jibber Jabber*
MISO = Master In Slave Out = Slave sends data to Master
MOSI = Master Out Slave In = Master sends data to Slave

Both of these actions occur at the same time (kinda). MOSI sends out data, then MISO will send back data and this will contirnue to occur until CS is pulled high again and communication has haulted.
So MOSI is where the micro sends info to the LCD
ANd MISO is where the LCD sends info to the Micro (I think?! or have I got that the wrong way round?)

So by the above logic, if I send data over MISO, it would only be directed at the mirocontroller and the LCD wouldnt see it, but MISO is the line that had the "useful" command lines as seen with Nems examples, but then why would the LCD be sending commands and the micro acknowledgeing them.. shouldnt it be the other way round? . So.. does that mean I need to send those commands over MOSI, will the LCD interpret the correctly??

This then brings me back to the original issue, that as soon as a "master" is introduced to the system (Send over MOSI), this causes the comms to stop. Meaning, I need to set the arduino as a "slave", then inspect the comms until it is pulled low.. swap arduino to master, sends frames over MOSI, then swap back over to slave. But then if Im waiting for comms to be pulled low, this means that the micro is sending info at the same time?

Ahhhhhhhh... so confused!!! This then means I need to be disable the micro so that I can pull CS low whenever needed, pull CS high then re-enable the micro. ANd even then, I have to disable the SPI pins again to prevent the comms from freezing up again (which Im still unsure why this is happening).


*Plan of action*
-Tinker a little more with trying to send data to LCD using buspirate.. might get lucky
-Work out who is slave and who is master! Simple question but im now confused!
-Possible (midi) interface between lcd board and mother board. Arduino intercepts commands from each direction and injects its own.. will need a software SPI setup so that two spi systems can run together.

And finally, try reading MISO and MOSI on arduino to see if selected baud rate picks up correct frames.

[TazzI]

Something Iv noticed,

hen putting the BP into SPI sniffer mode, the headunit functions fine without a hassle and I can get clear reads from the buttons.

As soon as I take it out of sniffer mode the line is held hostage and communication stops. I think this goes back to the whole mater/slave dilemma where the board is holding the CS line and other parameters preventing further communication.

[TazzI]

*Sigh* Good and bad news.

Looks like that"midi" idea might actually work.. not the same way that vlad or nem used but it works for our purposes I think.

I cut the harness to the lcd, wired in some dupont cables to plug into the arduino. All went well, radio powered on and data was being sent, but I didnt insulate the wires and the faceplate moved, causing a few wires to touch..which released the magical smoke that makes everything run, RIP radio number 1.

Lesson learnt.. dont be lazy.

[TazzI]

Unit number 2 up and running.

But still no luck in sending SPI frames back to the LCD. I must be missing something. Im tempted to power the faceplate up by it self and attempt to communicate with it without the motherboard.. just afraid Im gonna fry the bugger again!

[TazzI]

Well I think I finally hit my limitation for this. I cant figure out how to communicate with the lcd from my micro controller. I can read the info with the buspirate.. but cannot simply write back. Bugger..

[atreidae]

Wow you have been busy.
I wanted to say I haven't evaporated.
Work and the 3d printer have been consuming a fair bit of my time.

I ran into the same issues as you with the arduino. As soon as I tried to communitcate (or even connect the bus) the SPI bus would crash and the micro on the LCD would goto sleep..

Bad luck with the magic smoke.

The app I was using to read my arduino sniffer was OLS 0.9.7 and that seemed to work well

Im thinking we can bit blast the interface via the arduino. If we set the pins as inputs we can set them high (enable pullup resistor) or Low to leave them floating.

Leaving them floating should allow normal communication to occour on the bus, with us occasionally injecting a few random words to get the data that we want.

[TazzI]

Yeah I exhausted all my options and cant seem to gt any further.

Bit banging hey... hmmm. Might be a good plan. I have no idea how to bigbang data across though.. may need to read up a bit more.
Although, does this mean we need to wait for the CS to go high/low? Or should we manually pull it high, bitbang then bring low as per usual? Or just try bitbang and see what happens? lol.

Vlad said "The LCD interface looks like SPI but it is not. It is a proprietary interface that needs further reverse engineering to get it working.'

Which I find a bit weird since Nem managed to get it working over SPI.. well I think?

[silversv6]

Hi Tazzi, just a quick question since your the VY/VZ headunit guru! My sons VY berlina 6 stacker keeps coming up with a "MECH" error, when you try to load the discs. Any common problems with them or is it knackered? thanks & cheers