How to identify bits on an electric signal

Question

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

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?

Answer 1

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

Answer 2

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

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.