Page 48 of 81 FirstFirst ... 383940414243444546474849505152535455565758 ... LastLast
Results 471 to 480 of 801
Like Tree1Likes

Thread: Renault "Tuner List" Head Unit/CD changer hacking - Controls

  1. #471
    Constant Bitrate
    Join Date
    Feb 2006
    Posts
    113

    new version of cdc.py

    Attached is a new version of cdc.py
    It still has some problems but I didn't manage to hang the HU neither to produce LINK ERRORs with this program.
    It has the test function (i.e to send commands starting from 0 each time you pull the stalk control) and some of them do interrupt the sending of commands by the HU.
    I still see some duplicates packet (maybe I'm not acknowledging them fast enough) but the filtering on the sequence number is effective.
    It seems it is possible to receive one or more packets from the HU after sending a command and before receiving an acknwledgment. To keep the program simple (i.e. not multithreaded) if the reply is 3d instead of c5 I receive the packet, and wait for a new reply (eventually the c5 comes, if it doesn't I retry using the same sequence number).
    Note that the "playingCD" packet is necessary for the HU to recognize the simulated CD changer, but it's not taken into account everytime to show the cd number (i.e. if I turn off and on the HU with the program running it won't show the cd number). OTOH when the HU recognizes the command it sends a "Play" command.
    There are now two levels of "verboseness" (3 if you count verbose off): 10 (only error and other important messages) and 20 (every packet sent or received), you invoke the program with the "verboseness" level as the second parameter, e.g.:

    Code:
    python cdc.py 1 20
    will use the first serial port and show everything while
    Code:
    python cdc.py 1 10
    will use the first serial port and show only errors. With no parameter at all
    Code:
    python cdc.py 1
    it will show only normal messages (i.e the decoded commands from the HU).
    Attached Files Attached Files

  2. #472
    mox
    mox is offline
    Constant Bitrate mox's Avatar
    Join Date
    Nov 2004
    Location
    The Netherlands
    Posts
    183
    Quote Originally Posted by Vicne
    It'd also be interesting to know how-PIC based emulators behave when the HU saturates them with commands...
    If I flood the Connects2 with NEXT/PREV commands by turning the stalk dial encoder thing like mad, it seems as if the commands are queued in a small FIFO buffer. The sound mutes and unmutes at every click of the stalk rotary switch and this continues about 10 to 15 times after I stop spinning the switch. Apparently the FIFO stack is capable of buffering a number of commands in order to have them processed properly.

    I have tried my best to crash the HU, but to no avail.
    CarPC status: HW all done, SW needs tweaked.
    Hardware: VIA MII-12K, 512MB, 60GB 2.5", CW-8123 DVD-CDRW, 7" Lilli ts, Opus 90W, BU-353 GPS, 802.11b PCI, USB bluetooth dongle, AverMedia AverTV Cardbus Plus, Morex Cubid 3677
    Software: RR, MM/FD

  3. #473
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326
    Quote Originally Posted by pippolippi
    Attached is a new version of cdc.py
    It still has some problems but I didn't manage to hang the HU neither to produce LINK ERRORs with this program.
    Very good. I'll upload it to SourceForge.
    Not crashing the HU is my next goal too.
    It has the test function (i.e to send commands starting from 0 each time you pull the stalk control) and some of them do interrupt the sending of commands by the HU.
    As not all stalk controls are the same, what do you mean by "pull the stalk control" ? Is it NEXT ? PAUSE ?
    I still see some duplicates packet (maybe I'm not acknowledging them fast enough) but the filtering on the sequence number is effective.
    I also thought it was fixed in my program, but it seems I sometimes get so many retries that the HU increments the sequence number, so I'm still getting duplicate commands in the output...
    Note that the "playingCD" packet is necessary for the HU to recognize the simulated CD changer, but it's not taken into account everytime to show the cd number (i.e. if I turn off and on the HU with the program running it won't show the cd number).
    Well, CD number is not contained in PLAYING frames, so I think that's why the HU cannot "take it into account" :-)
    As far as I can tell, CD number is only sent as last byte of frame 20h (STATUS) and second byte of frame 26h (TRAY_STATUS) during the CDC boot process, plus second byte of frame 22h (TRAY_OPERATION) when changing CD.
    If you want the CD number to change without the user pressing any button and without faking a reboot of the CDC, you can simulate that the current CD has reached its end and CDC loads a new one. There's a log here containing this sequence (around 480s).

  4. #474
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326
    Quote Originally Posted by mox
    If I flood the Connects2 with NEXT/PREV commands by turning the stalk dial encoder thing like mad, it seems as if the commands are queued in a small FIFO buffer. The sound mutes and unmutes at every click of the stalk rotary switch and this continues about 10 to 15 times after I stop spinning the switch. Apparently the FIFO stack is capable of buffering a number of commands in order to have them processed properly.
    I have tried my best to crash the HU, but to no avail.
    That's very interesting. It makes me think that :

    1) Connects2 guys don't crash HUs. Good news for them and their customers

    2) The FIFO thing obviously shows that even if it is counter-intuitive, it's probably not good to reply too fast to the HU. My emulator currently tries to follow as quickly as possible, acknowledging requests immediately and queuing all reply frames asap, even before dispatching events to plugins. But maybe during the time the HU mutes/unmutes, it is not able to read incoming frames, so its buffers overflow, it looses queued answers and it concludes that if there are no answers, the command has to be sent again...
    There's definitely much work that can be done regarding timing.

    3) You have the same mute/unmute sequence as I do, while with the actual CDC (but you can probably test this if you have single CD too), the sound mutes only once, then the dashboard display follows your quick rotary switch movements but with sound still off, then finally sound unmutes when you have finished playing like mad. So I re-parsed old dumps with intense skipping on the actual CDC and formatted them in Excel (attached). The very interesting thing is that track change sequence is interruptible : while a minimum "stand alone NEXT" goes like (without header, ID, length and FCS) :
    Code:
    27h 80h <track#> 22h
    21h 0Ah
    21h 05h
    27h 10h <track#> 22h
    , when you queue multiple "NEXT", you only get a "27h 80h ..." per request, and only after you stop your mad skipping, the full sequence goes on and terminates with a "27h 10h ..." which causes the HU to un-mute.
    This is much more elegant of course but a bit harder to deal with.

    I'll get back to that as soon as I have a little time.
    Attached Files Attached Files

  5. #475
    Constant Bitrate
    Join Date
    Feb 2006
    Posts
    113
    Quote Originally Posted by Vicne
    As not all stalk controls are the same, what do you mean by "pull the stalk control" ? Is it NEXT ? PAUSE ?
    Sorry, I should have been more specific. The thing that you have to pull is the wheel that skip tracks or changes the radio station, the result while listening to the radio is switching from tuner preset->tuner list->tuner manual


    Well, CD number is not contained in PLAYING frames, so I think that's why the HU cannot "take it into account" :-)
    I know, I was referring to the frame that says the selected CD
    Code:
      def playingCD(self,number):
        """Sends the cd number currently playing"""
        return self.sendPacket('\x20\x01\x03\x09\x05%s' % chr(number))
    that I send in the start sequence as well as I receive a cd change command. However not everytime it is accepted by the HU and it displays a blank cd number.

  6. #476
    Constant Bitrate
    Join Date
    Feb 2006
    Posts
    113
    Quote Originally Posted by Vicne
    2) The FIFO thing obviously shows that even if it is counter-intuitive, it's probably not good to reply too fast to the HU. My emulator currently tries to follow as quickly as possible, acknowledging requests immediately and queuing all reply frames asap, even before dispatching events to plugins. But maybe during the time the HU mutes/unmutes, it is not able to read incoming frames, so its buffers overflow, it looses queued answers and it concludes that if there are no answers, the command has to be sent again...
    I doubt that they took the pain of implementing a FIFO for outgoing commands and then forgot to implement an input buffer. Anyway it's easy to test, just wait a while before sending the c5 back.

  7. #477
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326
    Quote Originally Posted by pippolippi
    I doubt that they took the pain of implementing a FIFO for outgoing commands and then forgot to implement an input buffer.
    True...
    Anyway it's easy to test, just wait a while before sending the c5 back.
    I think I'll still send the C5 asap, but wait before sending the "27/21/21/27" frames...

  8. #478
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326
    Quote Originally Posted by pippolippi
    Sorry, I should have been more specific. The thing that you have to pull is the wheel that skip tracks or changes the radio station, the result while listening to the radio is switching from tuner preset->tuner list->tuner manual
    ???

    I didn't know one could pull that wheel !!!

    Not sure it's the case in my car. I'll test when I get back home in a few minutes... If it does, for sure I should have RTFM of the HU

    I know, I was referring to the frame that says the selected CD
    Code:
      def playingCD(self,number):
        """Sends the cd number currently playing"""
        return self.sendPacket('\x20\x01\x03\x09\x05%s' % chr(number))
    that I send in the start sequence as well as I receive a cd change command. However not everytime it is accepted by the HU and it displays a blank cd number.
    Oh, I see... That's weird...
    Well, otoh, I admit I never saw these packets while CDC was playing, only while it was doing operations...

  9. #479
    Constant Bitrate
    Join Date
    Feb 2006
    Posts
    113
    Quote Originally Posted by Vicne
    ???

    I didn't know one could pull that wheel !!!

    and not only switches between tuner preset->tuner manual->tuner list, if you keep it pulled for a while it will start the search to fill the "tuner list" memory, and I think that last function is independent of the source selected.
    Anyway, the "short pull" is sent as 24 (hex) to the cdc.

  10. #480
    Variable Bitrate
    Join Date
    Apr 2005
    Location
    Belgium
    Posts
    326
    Quote Originally Posted by pippolippi
    Anyway, the "short pull" is sent as 24 (hex) to the cdc.
    Jeez, ...
    Yes, I just tested that and noticed the 24h frame
    I tried it on CDC position and it skips to the next CD (CD1 > CD2 > CD3 ... > CD6 > CD1 ...). Now it would be interesting to spy the protocol for that event too, but unfortunately my spy setup is dismantled now... Although, I still have a spare M/F mini-iso set (coming from my previous "pass-through" setup) so I might rebuild a spy circuit one of these days
    And not only switches between tuner preset->tuner manual->tuner list, if you keep it pulled for a while it will start the search to fill the "tuner list" memory, and I think that last function is independent of the source selected.
    Edit: Confirmed : When holding the wheel for a long time, the tuner seems to begin searching for stations.
    The "NEXT_CD" event has been added to the protocol page on Sourceforge, along with new info about frame TRAY_STATUS

    Anyway, that's a very interesting interface for a tree menu navigation (up/down/enter + timeout to cancel), for example for navigation in your mp3 filesystem...

    Edit :
    It's really a pity all these commands mute the sound though :-(
    If displaying ID3 tags is the Holy Grail, preventing the HU from muting is second on my wishlist...

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •