FFW FRW

[AudioDrugs]

Hmmmm.... Trying to connect some mp3 module that have ffw and frw function. I can start forwarding, but i can't stop it. Anyone solved that?

[visualapproach]

I have not bothered about ffw/frw. Anyone else trying this? Can you tell us some more about your setup/mods?

[AudioDrugs]

So here is the mess on my desk

im using this player:

everything is connected to 4066 like in your scheme.

I guess the code should be very similar to case 16 and 17, just need to add more time before putting nextPin/prevPin to LOW. For example every time you press forward button it forwards 15 sec of track.

Or we need to know what data was sent by HU after forwarding button release.

I have tired some code modifications by changing times in:

void ffw() {
  digitalWrite(nextPin, HIGH);
  for (byte i = 0; i < 200; i++)
    delayMicroseconds(10000);

  digitalWrite(nextPin, LOW);

and only get continuous forwarding

[visualapproach]

Edit due miscalc Sweet! First thing you should change, is to make a nested loop instead of microseconds(10000)! Like for(0..100) For(0..100) Delaymicroseconds(200)

The delayus function does not work as you’d expect when timer is shut off.

[visualapproach]

I don’t know the exact limit but stay under 1000 in the delay

[AudioDrugs]

Problem solved! Thank you!

[visualapproach]

Wow, my pleasure! Cheers and have a great weekend!

[AudioDrugs]

Hello again! Everything works fine, but still... Can someone sniff what happens when FFW/FRW button is released? It would be amazing to make forwarding until button is released like the internal cd player.

[visualapproach]

In principle, You can sniff it yourself. Just have a computer connected via USB and watch the serial monitor (115200bps) First uncomment line 799 and comment out line 800 in the latest code. 798 - //Printing transmission log (from HU, excluding our answer and things after it) 799 - //if (ComTicks == 0) { //print all messages 800 - if (ComTicks == 0 && ConnTicks != 0) { //print unmatched messages (unknown)

I wrote "in principle" because there is a chance the HU will behave differently depending on what answer it gets from the external device.

[darjusp]

Just recently was dealing by myself with this issue, ended up using data saved in log starting from 800 line. Here is the code to get long press and release <<(DLP,DLR), >>(CLP,CLR), as well long press of CD1-6 buttons (CxL). Would be very beneficial to receive Thomas comments

if (ComTicks == 0 && ConnTicks != 0) { 
    if(byteCounter>4){
      // Check for long CD press
      if(melbus_log[0]==192 && melbus_log[1]==29 && melbus_log[2]==119 && melbus_log[3]==193){
        switch (melbus_log[4]) {
        //0x81 to 0x86 corresponds to cd buttons 1 to 6 on the HU (650)
          case 1:
            Serial1.write("<C1L>");
            break;
          case 2:
            Serial1.write("<C2L>");
            break;
          case 3:
            Serial1.write("<C3L>");
            break;
          case 4:
            Serial1.write("<C4L>");
            break;
          case 5:
            Serial1.write("<C5L>");
            break;
          case 6:
            Serial1.write("<C6L>");
            break;
        }
      }
      if(melbus_log[0]==192 && melbus_log[1]==27 && melbus_log[2]==113){
        if(melbus_log[3]==160){
          Serial1.write("<CLP>");
        }
        if(melbus_log[3]==208){
          Serial1.write("<CLR>");
        }
        if(melbus_log[3]==32){
          Serial1.write("<DLP>");
        }
        if(melbus_log[3]==80){
          Serial1.write("<DLR>");
        }
      }
    }
   } 

[visualapproach]

@darjusp I'm not sure what you want me to say, although I appreciate your belief in me :-) I reckon it is not working as you want yet? I can think of a couple of scenarios: 1) HU sends a special command for "long press" a button. This is the easiest problem. You should just have to add to the commands list and take care of it in the switch(cmd) cases. 2) HU send a special command for RELEASE button. Needs more work if you wanna delay the first PRESS command. 3) HU send repeated commands for button pressed. If I remember correctly this was the case for my car. Maybe add a counter in the particular switch(cmd) case, and after, say, 10 times you should consider it a "long press". You probably need to think about what happens if you just press the button briefly 10 times...

[darjusp]

Actually it does work, for instance for button >> in the melbus_log array it is such piece [192, 27, 113, 160] for press and [192, 27, 113, 208] for release. If it short press it doesn't trigger such output as the signal is actually sent on release of the button. So if the button is not release for 1 second, it invokes long press sequence. Same with 1-6 buttons. i just wanted to know whether the logic is correct and whether the place to catch the sequence and take some actions is right, as all matching is happening way above line 800. Maybe it can break the process actions if it takes too long in this place?

[visualapproach]

If it works, no need to fix it. But if you want to be consistent and follow the other code, then try to add

define CLP {4, 192, 27, 113, 160}

and so on. Then add command to the array const byte commands[][7]{ ..., CLP }; Add a new case 34: