Serial MIDI (DIN->Optocoupler->GPIO15) issue

[arsamus]

Hi everybody, i've build a MIDI IN interfaz via optocoupler to connect a keyboard vía tradicional midi cable (schematica below) using GPIO15 (UART RXD). Everything works ok but only if I press one key at a time. If I play chords, just one note is played by Mididexed and if a "note Off" event occurs near another event (in the same message chain) the note continues to playing forever.

It seems that MIDI messages chains with more than 3 bytes, for example when I play two notes at the same time or when pitch bender is actioned, are truncated and only the first 3 bytes are proceced and the rest of the message is lost, as I could note on screen activating Midi dumping option.

I've tested on Raspberry 1B+ and 2B with the following schematics:

(schematics from Here but I've adapted to RB with 3.3v)

[craigyjp]

I don't have much success with 6n devices, I tend to use 4n devices, this one works perfectly with a midi keybed playing chords and sequences.

[craigyjp]

Here is the 6n138 version that I started with, check the wiring against yours.

[luisfcorreia]

I've tested this in Raspberry Pi 1B+, Raspberry Pi 2B and Raspberry Pi 3B

In Raspberry Pi's containing a Bluetooth module, you'll have to disable it, as it uses the same serial port

@probonopd how to you want me to document this further?

[craigyjp]

So does the circle OS allow for disabling of the Bluetooth in a config file?

[luisfcorreia]

I think it can be disabled by not having the relevant DTD file (but I'm not a Circle expert)

[arsamus]

Let's also triple check that we are not confusing IN and OUT, TX and RX. The naming can be confusing at times. The jack labeled "IN" needs to go to RX on the Pi. Sorry if it was obvious to you but I've seen people fall into this trap more than once.

I've done it with almost all circuits described here with RB 1B+ and 2B. Some midi messages are handled (note on, note off, prog change events). Everything is ok if I play one note at a time. But I can't press two or more keys simultaneously.

[caysira]

Hi all, thanks for this great project and all the effort that went into it. Just want to report my midi experience:

• usb midi controllers worked fine from the beginning (e.g. akai lpk 25)

• legacy midi equipment (quite old) with various different midi2usb converters worked somehow (could get an old Casio ctx to work with the miditech usb adapter, but my technics sx-px222 piano had always stuck notes) but had massive

• I analyzed the raw midi output from the px222; it got active sense, running status and no note off (instead note on with velocity 0)

• I can happily report that the px222 works flawlessly with the above 6n138 midi-in circuit

PS: I am using a pi 2B and the raspiaudio audio+ V2 dac

[craigyjp]

I would suggest changing your resistor values to similar values to the ones used in my 6n138 design.

[craigyjp]

That is very strange, if the 4n35 version doesn't fix it you have some other issues.

[arsamus]

I've just build your 4n35 version with exactly the same component values and I've got the same result. I don't know what it is happens I am very disoriented, the circuit is very simple, my Roland keyboard's MIDI OUT works ok with other connections. :(

[craigyjp]

I don't know what it could be, I presume the circuitry is correct and signals/power/ground connect to the pi.

Only thing I can think of is a faulty UART on your pi, do you have another pi available?

[probonopd]

Over at #179 (comment) someone built a working MIDI IN circuit.

[arsamus]

I've tested on Raspberry models 1B+ and 2B with same results. I'm looking forward for #179 schematics and in parallel test other things (wiring, cable, etc.).

[ghost]

Could be helpful as a general MIDI primer in the WIKI section but also how the MIDI hardware circuitry is implemented :
https://learn.sparkfun.com/tutorials/midi-tutorial/all

[craigyjp]

I just looked at circle on GitHub, it suggests Bluetooth is not even supported yet.

…

On Thu, 28 Apr 2022, 11:19 Luis Correia, ***@***.***> wrote: I think it can be disabled by not having the relevant DTD file (but I'm not a Circle expert) — Reply to this email directly, view it on GitHub <#170 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMFJTAKDAJOB3VN5UNOV7K3VHJCYJANCNFSM5UJFVOVQ> . You are receiving this because you commented.Message ID: ***@***.***>

[luisfcorreia]

FYI, I've added a new section in the WIKI for this
https://github.com/probonopd/MiniDexed/wiki/Hardware#classic-midi-input

[craigyjp]

You could add my in/out/thru design too as I have tested that on a pi400 and a pi 4b

[luisfcorreia]

I will, as soon as I'll fire up my Kicad at home with a bit more time.
(but I'll probably do the 74LS14 version, if you don't mind)

as a side note, I'm also designing a midi splitter Eurorack module, from which all my designs derive.

[craigyjp]

It makes no difference to me, either will work, I put a 5 way splitter/thru into my Roland A110 clone using the 74HC14 so I know it works.

…

On Thu, 28 Apr 2022, 11:58 Luis Correia, ***@***.***> wrote: I will, as soon as I'll fire up my Kicad at home with a bit more time. (but I'll probably do the 74LS14 version, if you don't mind) as a side note, I'm also designing a midi splitter Eurorack module, from which all my designs derive. — Reply to this email directly, view it on GitHub <#170 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMFJTAM3ACVIKEVPW43UUHTVHJHMTANCNFSM5UJFVOVQ> . You are receiving this because you commented.Message ID: ***@***.***>

[diyelectromusic]

From my experience, the 6N138 really "likes" 5V as its VCC, so that could be part of the issue?

You might be ok in some cases, depending on the specific part, with 3V3 (I've had some working fine), but other circuits I've seen power the 6N138 with 5V but pull the RX connected output UP to 3V3. I talk about this a bit here: https://diyelectromusic.wordpress.com/2021/02/15/midi-in-for-3-3v-microcontrollers/

Note: I'm not really an electronics person, so treat with caution :)

Generally I've had the most success with a H11L1/H11L2 when building MIDI IN circuits for use with 3V3 power levels. This is pretty much the design in the Adafruit MIDI Feather Wing and the Clumsy MIDI interface for the RPi. The Teensy MIDI IN uses a 5V powered, 3V3 RX output 6N138 though IIRC... I'm working on the assuming that pjrc, Adafruit and gmcn42 all know much more than me :)

(It might also be worth adding a 100uF capacitor between VCC and GND for the optoisolator too)

Could it be that you are getting corrupted/slow MIDI frame sequences that are being decoding in odd ways...? Can you see the MIDI signal in a logic analyser at all?

(If you don't have access to a logic analyser to "see" the signal, I built a "pretend" one from an Arduino for similar situations. It should be ok with a 3V3 receive signal as long as the 5V is kept well away from the Pi...? https://diyelectromusic.wordpress.com/2021/06/08/arduino-midi-analyser/)

Kevin

[luisfcorreia]

From the datasheet, that's not what I read.

It says Supply voltage goes from -0.5v to 7V

But I've confirmed that the circuit I've described on the WIKI page works without a glitch

[diyelectromusic]

Yes, I've seen that too. As I say on my blog "It hasn’t been clear to me from reading datasheets why this is the case – I’ve seen data sheets that talk of a “detector supply voltage” from -0.5V to 7V" and yes, I've had 6N138's working fine at 5V too.

I repeat, I'm not an electronics person, but rather just seeing what others have done in their published designs (in actual products in some cases) and in various discussions from others (including on the MIDI Forum: https://www.midi.org/forum/1475-best-optoisolator-for-3-3v).

Anyway, it was just a thought :)

Kevin

[bmillier]

@LuisCorreia As diyelectromusic mentioned, the 6N138 needs 5V on its Vcc (pin 8) . The -.5- 7V are the maximum voltages that you can place from Vcc to GND without damage- not the correct operating voltage. In the spec sheet it shows typical parameters when powered by 4.5-5V. I am using the 6N138 with MiniDexed and it works fine (and I've used them many times in the past for MIDI IN ciircuits- on 5V). The 2.2k resistor is probably OK, but its better to use 1k as that results in slightly faster switching speed. The 2.2k pull up resistor does have to go to the 3.3V supply, for sure.

[diyelectromusic]

@bmillier for my own learning - what should I have been looking at in the spec sheet? I must admit I find them quite opaque to me at present! I'm assuming it would be one of the graphs at the back?

[bmillier]

@ditelectronics. The company that made the 6N138's that I used in the past, and have on-hand (HP) no longer make them. But, take Everlight, who currently sell them. Here is a link to the datasheet
https://everlightamericas.com/index.php?controller=attachment&id_attachment=9
On page 3 in the Transfer Characteristics section you'll see in the heading "Vcc= 4.5V" On page 4 in the Switching Characteristics, in the heading you'll see Vcc = 5V
When I used these many years back, the companies making them (HP & Motorola I think) had datasheets that were more clear. Back then, the MCUs were all powered from 5V,and used 5V logic levels so I naturally used 5V for the 6N138 Vcc. Now, I use Teensy MCUs etc. (and the Raspi for this project) and they all use 3.3V for power /logic levels. Someone had mentioned on a Teensy forum that 6N138 needs 5V for Vcc so that is what I continue to use, and it works fine. Digikey sells 6N138s by about 5 companies. I am using older HP 6N138s on hand, so I've not bought any of these manufacturer's parts. It's possible that some of them might work on 3.3V for Vcc, but why take a chance?
Hope this is helpful

[luisfcorreia]

I do electronics, analog and digital for more then 30 years now (yes, I'm old)

For this case I could be that a VCC of only 2V would be enough for the circuit to work

VCC is only providing a weak positive polarization to the photo-sensitive transistor, and as soon as light hits the "base die", it will conduct and make the output transistor pull down the RX line.

Think what you will, my 6N139 optocouplers were bought from tme.eu about 3 years ago, all of them are new stock

[arsamus]

Hi everybody, I've insert some printf on the code of serialmididevice.cpp to monitors what it is happends. I've found an extrange (until today for me) situation, when I play two or more notes at the same time my keyboard (early nineties Roland JV80) just the first note that it send has the "status byte", but the rest of the notes pressed just send the second and the third byte. This is not a faulty. In order to minimize latency, some controllers send the status byte and then a string of pair of bytes containing all data information. Most of modern USB modern interfaces "filters" this and complete the three byte message. You can read about this on this article.

@probonopd in order to handle this is necessary to evaluate the 4th byte and determinate if it's a Status Byte or a Data Byte. This is supposed that happens on Process() method of serialmididevice.cpp class. I below I've attached the code with my suggested additions (sorry I'm not a professional programmer... ). I've tested on a custom built and finally everything works ok!

On the other hand, it is important to say that all of the schematics discussed here are Ok, I've tested almost all. Meybe some are better than others but I've choose the 4n35 versión of @craigyjp

Here the modified Process() method of serialmididevice.cpp class:

void CSerialMIDIDevice::Process (void)
{
	m_SendBuffer.Update ();

	// Read serial MIDI data
	u8 Buffer[100];
	int nResult = m_Serial.Read (Buffer, sizeof Buffer);
	if (nResult <= 0)
	{
		return;
	}

	// Process MIDI messages
	// See: https://www.midi.org/specifications/item/table-1-summary-of-midi-message
	// "Running status" see: https://www.lim.di.unimi.it/IEEE/MIDI/SOT5.HTM#Running-	
	
	for (int i = 0; i < nResult; i++)
	{
		u8 uchData = Buffer[i];
				
		switch (m_nSerialState)
		{
		case 0:
		MIDIRestart:
			if (   (uchData & 0x80) == 0x80		// status byte, all channels
			    && (uchData & 0xF0) != 0xF0)	// ignore system messages
			{
				m_SerialMessage[m_nSerialState++] = uchData;
			}
			break;

		case 1:
		case 2:
		DATABytes:
			if (uchData & 0x80)			// got status when parameter expected
			{
				m_nSerialState = 0;

				goto MIDIRestart;
			}

			m_SerialMessage[m_nSerialState++] = uchData;

			if (   (m_SerialMessage[0] & 0xE0) == 0xC0
			    || m_nSerialState == 3)		// message is complete
			{
				MIDIMessageHandler (m_SerialMessage, m_nSerialState);

				m_nSerialState = 4; // State 4 for test if 4th byte is a Status Byte or a data Byte 
			}
			break;
		case 4:
			
			if ((uchData & 0x80) == 0)  // true data byte, false status byte.
			{
				m_nSerialState = 1;
				goto DATABytes;
			}
			else 
			{
				m_nSerialState = 0;
				goto MIDIRestart; 
			}
			break;
			
		default:
			assert (0);
			break;
		}
	}
}

[diyelectromusic]

Oh well done for spotting that! :)

Kevin

[probonopd]

Excellent. Thank you very much @arsamus.
#194

[probonopd]

Please try this build: https://github.com/probonopd/MiniDexed/suites/6325409557/artifacts/227363985

Once I have a few positive feedbacks, I will merge it into the main branch.

[Kirtai]

Oh, MIDI Running Status. I've seen that bite a few midi projects.