MIDI IN skipping bytes

Hello folks!

I am trying to get hardware midi in working for my arduino project, but after lot of tries, searching this forum and interweb in general i can't solve following problem.

Using arduino mega, I've built this circuit from this tutorial only difference is i am using 1w resistors instead of 1/4w which shouldn't be a problem from what i've read(correct me if i am wrong).

When i try to send midi notes to arduino via that circuit, i am getting most of data but some bytes are missing, mainly when there is more data recieved. Two scenarios i tried are:

1) Sending simple sequence from Octatrack(hardware sampler / sequencer)
First message(note on) arrives intact but all following messages arrives without command byte unless there is long midi silence before next message(2+ seconds). Example debug log:

==>CMD: 153 (note on command byte)
DATA: 46 (note pitch data byte)
DATA: 126 (note velocity data byte)

(missing command byte here)
DATA: 46(pitch)
DATA: 0(velo)

(missing command byte here)
DATA: 46(pitch)
DATA: 126(velo)

(missing command byte here)
DATA: 46(pitch)
DATA: 0(velo)

etc...

2) Sending Control change messages by tweaking knobs on waldorf pulse(analog synth)

this time my midi input circuit is able to handle much more data, but still when i am sending too much messages some data is missing, this time data bytes only.
example log:
==>CTRL: 185 (control change command byte)
DATA: 76 (cc number data)
DATA: 110 (cc value data)
==>CTRL: 185 (command byte)
DATA: 76 (cc number)
DATA: 106 (cc value)
==>CTRL: 185 (command byte)
(missing data bytes)
==>CTRL: 185 (command byte)
(missing data bytes)
==>CTRL: 185 (command byte)
(missing data bytes)
==>CTRL: 185 (command byte)
DATA: 76 (cc number)
DATA: 1 (cc value)

what is really weird is that when i try to send CCs from octatrack its again the command bytes missing, so my midi input circuit is failing differently based on which HW send the data.

I Originaly used my own midi library which works perfectly when i am sending data from software via hairless midi, but when problems occured i cut all down to this simple code generating provided logs:
(MIDI_HW_BAUDRATE is 31250)

void setup() {

    Serial.begin(9600);
    Serial3.begin(MIDI_HW_BAUDRATE);
}

void loop() {
    if (Serial3.available()) {

        while (Serial3.available()) {
            int byte = Serial3.read();

            //command byte
            if ((byte & 0x80) == 0x80) {
                Serial.print("==>CMD: ");
                Serial.print(byte);
                Serial.print("\n");
            //data
            } else {
                Serial.print("DATA: ");
                Serial.print(byte);
                Serial.print("\n");

            }
        }
    }
}

I've already tried:
1)Rebuilt the circuit several times
2)Swapped optocoupler 2 times in case they're faulty
3)All four RX pins - all behave same
4)Changed my script in many different ways - for example to leave software serial communication completely, instead of logging i've just sent incoming midi via midi output(as my midi Output is working as a charm) - same behaviour as i expected from log i've got one message right, rest was ignored by synth receiving that midi data.
5) Both HW machines are tested properly working, when i monitor the via midiusb converter with midi monitor they are sending correct messages.

Thanks in advance for any ideas.

Your first problem is normal, the second is not.

MIDI uses running status: if the header byte doesn't change, you don't have to send it over and over again, just the data bytes should be sent.

Pieter

I suggest boosting the Serial speed to 115200 bits/s. The problem may be the Serial port at 9600 is so slow that data is being dropped on the MIDI port which is running much faster at 31250. The code is printing lots of bytes for every MIDI byte so the Serial must run faster to avoid being the bottle neck. And/or comment out the Serial lines and see if this helps.

PieterP:
Your first problem is normal, the second is not.

MIDI uses running status: if the header byte doesn't change, you don't have to send it over and over again, just the data bytes should be sent.

Pieter

Hey Pieter, thanks a lot for reply i finally get to test that and of course it is running status problem, i implemented that and it solved the biggest problem, "lost" status byte i dont get how i didn't run to this obvious problem much earlier:)

gbafamily:
I suggest boosting the Serial speed to 115200 bits/s. The problem may be the Serial port at 9600 is so slow that data is being dropped on the MIDI port which is running much faster at 31250. The code is printing lots of bytes for every MIDI byte so the Serial must run faster to avoid being the bottle neck. And/or comment out the Serial lines and see if this helps.

thats a good idea defy, i quess that was the reason why it sometime dropped the data byte of CC message, as there was much more CC data than note data when i was debugging this. Until now i always turned the logging off completely and tested just by sending midi from sequencer to a synth(which still gave me running status problem) as boosting serial speed dint come to my mind, thank you:)

gbafamily:
I suggest boosting the Serial speed to 115200 bits/s. The problem may be the Serial port at 9600 is so slow that data is being dropped on the MIDI port which is running much faster at 31250. The code is printing lots of bytes for every MIDI byte so the Serial must run faster to avoid being the bottle neck. And/or comment out the Serial lines and see if this helps.

Seconded, you are choking off the MIDI throughput substantially. Use 115200 by default, not the glacially
slow 9600

I hope your project is progressing well. I sympathized with you as I ran into the same problem and it took me ages to work out what was going on. I finally cracked the problem with a logic analyzer. I bought this on ebay for about a £9 see ebay item number 254005524168. This plugs into the computer which is running PulseView (free program) connect a lead to recv pin and you can see everything thats going on. The program shows 3 traces, the raw signal levels, the decoded binary data, and the decoded MIDI data, I really was amazed with this. Everything was became clear, if you try this you will be amazed like me. If you need further help with PulseView let me know. Rod

Hey Pieter, thanks a lot for reply i finally get to test that and of course it is running status problem, i implemented that and it solved the biggest problem, "lost" status byte i dont get how i didn't run to this obvious problem much earlier:)

Hi SSSN, could you share your running status code?
Thanks