I am trying to read a MIDI signal. I have used a logic analyzer to look at the signal:

enter image description here

enter image description here

The upper picure is the note-on signal that should read 0x90 0x3C 0x7F.

The lower picture is the note-off signal that should read 0x80 0x3C 0x0 .

In binary I get

100100000011110001111111 note on 60

100000000011110000111100 note off 60

EDIT: The note number is 0x3C (60) in decimal and 00111100 in binary.

I have no idea how this corresponds to the signals pictured. Can someone help?


2 Answers 2


You are just reading the bits in wrong order.

You should enable UART frame decoding.

MIDI uses standard UART framing of 8 data bits, no parity, and 1 stop bit. at bit rate of 31250. UART also sends least significant bit first and most significant bit last. The line idles high, start bit is low and stop bit is high.

Therefore, 0x90 0x60 0x7F is Note On on Channel 0, note 0x60, velocity 127.

In binary it looks like:

S00001001P S00000110P S11111110P

I used S for low start bit and P for high stop bit. There can be arbitrary amount of idle high time between stop bit and the next start bit. Your logic capture may also have too low sampling rate so see the bits accurately, it looks slightly inaccurate (or the note number is not really 0x60).

The Note Off is:

S00000001P S00000110P S00000000P

Edit: The note number is not 0x60. It's 0x3C or 60 in decimal. The transactions are as follows:

S00001001P S00111100P S11111110P

S00000001P S00111100P S00000000P

  • 1
    \$\begingroup\$ 9x60?? Is that correct? \$\endgroup\$ Commented Nov 1, 2022 at 11:19
  • \$\begingroup\$ @ScottSeidman I did say it looked weird but I believed the OP saying 0x60 is sent but it is not 0x60 but 60 which is 0x3C, middle C of MIDI. \$\endgroup\$
    – Justme
    Commented Nov 1, 2022 at 11:21
  • \$\begingroup\$ You are right I made a mistake the note is 0x3C. Thank you very much for the detailed answer. \$\endgroup\$
    – John Am
    Commented Nov 1, 2022 at 11:31
  • 4
    \$\begingroup\$ What does "9x60" mean? I know that "0x" indicates hexadecimal, but I've never seen "9x" before. I'm guessing that that's a typo for 0x60. \$\endgroup\$ Commented Nov 1, 2022 at 12:03
  • 1
    \$\begingroup\$ @Tanner-reinstateLGBTpeople -- yeah, it was the 9x that I was questioning. \$\endgroup\$ Commented Nov 1, 2022 at 15:10

I was drawing while justme was writing their excellent answer ...

enter image description here

Just to add a note on how to go about interpreting the signals. Basically it's 1) make a guess, 2) confirm it. The details might help if you've never done it before.

  1. Start with manipulating the two signals so they are less tall, and line them up. (Use GIMP/photoshop/similar) This emphasises the signal and the similarities.
  2. Use a drawing package such as Inkscape (which has import bitmap, arbitrary stretch, and draw-on-grid functionalities), and pull in the image signal. Stretch it until the narrowest pulse of the signal lines up well with a grid unit, and see that all the transitions are plausibly on the grid.
  3. You might notice that the narrowest postive pulses are narrower than the narrowest negative pulses: you sometimes have to guess a bit.
  4. Redraw the signal with lines snapping to the grid (black lines in lower portion). This is the "idealised" signal. Move your drawn image until you can convince yourself it really does match the measured signal. You might have to stretch and move the bitmap a few times until it lines up.
  5. I know that most asynchronous serial works with a stable "stop" condition and an opposite polarity "start" bit. You can see from the image that the quiescent signal is H, so we expect that H=stop, L=start. If you measure at different points in a circuit you might easily have an inverted signal.
  6. We are expecting 10-bit patterns L????????H, and we find three in a row. This is confirmation that we have something like the signal we're expecting. Stop bits can get stretched. Most commonly they are 1 bit time, but sometimes 2 bit times, sometimes they are 1+fraction. In these signals they appear to be exactly 1 bit time, but if they weren't you might have to do some adjustmens and guessing.
  7. Write out the bits. Usually they are low-bit-first, so signal LLLLHLLH probably represents binary 10010000, hex 0x90: confirmation that it's LBF and L=0/H=1; checking other signal gives 0x80, also expected. (Sometimes signals are inverted or, rarely, high-bit-first, so LLLLHLLH might also represent b01101111=0x6f, b00001001=0x09, or b11110110=0xf6 but they don't match expectations here.)
  8. We see second byte is 0x3c, original guess was 0x60, but quickly spot that decimal 60 is 0x3c. Confirmation with correction.
  9. Each of the last bytes is as expected: 0x7f and 0x00: confirmation.

At step 2, you're basically estimating the bit time by eye. If you assume this is a start-bit-stop-bit signal, you can get a numerical estimate by taking the whole width from the first fall to the last rise (220 pixels) and dividing by 29 (for three bytes: 3 starts + 3x8 data + 2 stops), which is 7.86 pixels/bit. If you thought it was four bytes use 39 etc.

  • 3
    \$\begingroup\$ very helpful graph. I have been able to read the midi signal with an attiny13... by using your graph \$\endgroup\$
    – John Am
    Commented Nov 2, 2022 at 2:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.