Not a bug (yet ), but a wiring error. I’m not sure how fritzing is detecting it, but the ground wire on the bottom of the breadboard with the amphenol connectors is missing. Adding that completes routing. Found by using the delete minus function to delete parts one by one until routing completed. That happens when that particular breadboard is deleted. Then looking at only that wiring indicated the problem. There are however more problems that I am still looking at. The opto isolator circuit is incorrect (it won’t work as it stands). It looks to be backwards the input should be coming from Din2 pin 4 in to the diode on the opto isolator and the output from the opto isolator (currently going to Din2 but with no ground) should go to the rx data pin on the mega. This assumes that pin 4 of Din2 is TX data from whatever connects to Din2 (as seems likely). As currently connected this won’t do anything. In the updated sketch below there are still some routing problems in schematic in that di for the neopixel is connected to +5V although it is not in breadboard. It is possible the neo pixel part is in fact incorrect, I’ll have a look at that next.

Chewie 2_fixed.fzz (90.5 KB)

Peter

Thank you for looking at my sketch, just noticed the optocoupler is the wrong way around I will flip it now. Can the value of it be changed? I need it to be a 6n138 optocoupler. The diodes vaue needs changing to a 1n914 diode too. Okay thank you! I have just edited the position of the optocoupler. Everything should be right. Chewie 2_fixed.fzz (87.3 KB)

Ah, I see the 6n138 runs on .5 ma of diode current (as opposed to 5ma for the 6n137) and seems to be preferred for midi applications. However since the 220 ohm resistor they recommend will produce 20ma of diode current, the 6n137 should work just as well and since it has an active output shouldn’t need the 74ls14 to drive the repeater circuit to din1. If you like I can modify the circuit to use the 6n137 for you. As well the routing problems are a labeling error in the neopixl strip part. I’m correcting the part and will check it fixes the routing issue and post the corrected sketch with the new part in a bit.

Peter

Yeah I built it exactly as to what I was told. So I used the parts that were recommended. It won’t matter about modifying the 6n137. Because I’m going to use the 6n138 anyway when I make a pcb. I was just saying for label referencing. I’m not sure what is going on with the pixel strip. Thanks!

In that case you should switch to the 6n138 now as trying to change it later will be a pain and may break routing. The 6n138 available in core parts doesn’t have pin 7 included and that is needed to implement the circuit shown here:

I can modify your current 6n137 part to be a proper 6n138 (with pin 7) fairly easily and add the suggested 74ls14 or 74hc14 fairly easily.

The pcb view on the part was broken (no holes generated in the gerber) and the labels in breadboard are misplaced leading us to short things together which tied 5V to din (which isn’t correct). I have a corrected version of the neo pixel and will swap it in and make sure the routing npw works correctly.

Peter

I have the 6n138 connected to my breadboard physically. That’s why I would like to change it. Do I have to use the 74ls14 or 74hc14 as well? Because the midi in is working fine with just the optocoupler 6n138. Alright I didn’t see that, thank you for fixing it for me!

The 74ls14 is only needed for the repeater jack. The article I referenced said that with the 6n138 sometimes the midi commands didn’t get through because of slow edges from the 6n138 (that is what the resistor on pin 7 is about, it speeds up the rising edge, but may need adjustment). The 6n137 is 10 times faster than the 6n138 with an active output ((the 138 needs a pull up resistor which is why the edge is slow). If it was me I’d use the 6n137 as it should be more reliable, and it doesn’t need the 74ls14 to drive the output.

Peter

Just remember you CAN’T change connections in 1 view if there are SOLID connections in another view. Either Delete Minus the part and fit new part, or delete all the traces in the other views first, so they are ratsnests, and then change the connections in the main view you are working on.

OK I’ve made a bunch of changes to your last posted version and arranged schematic how I would typically do it and routed the parts (mostly the power connections using ground and VCC nets) as an example. I didn’t do anything with pcb layout as it is likely to be driven by your space requirements.

Breadboard view:

1. Added the corrected neopixel part and fixed connection order in breadboard. Due to incorrect labeling in breadboard view we had +5V and DIN reversed!

2. Changed wire colors on the LEDs to orange for red and green for green so which is which is obvious (don’t need to do on physical bb unless you want to)

3. Changed the part label on the amphenol connectors to J1 - j10 in the correct order (they were out of sequence) for neatness.To do so click on the part then “show part label”, then click on the label itself, click edit and change the label. Note that you need to make sure all the labels are unique as routing will screw up with duplicate labels!

4. Did the same thing for the LEDs.

5. Changed the opto coupler to use the 6n137 (instead of the 6n138), rotated the 6n137 180 degrees so it is in standard format and connected it so it should work correctly (with less parts) than using the 6n138. It should also work more reliably as the 6n137 can do 10 mhx rather than 100khz for the 6n138 making this worth doing in my view. Replaced the zener diode with a 1n4148 from my post in parts_submit back in Sep of 2016 and deleted a couple of unneeded resistors. Changed the wire color to purple for the entire rxd line for consistancy

6. Delete ground wire on din2 pin 2 as suggested in Midi standard at https://mitxela.com/other/ca33.pdf

7. Added a 1K pull up resistor to the output of the opto coupler (pin 6) as suggested in the 6n137 data sheet

8. Reverse the power/gnd wires on the bottom right end of the led6 breadboard as power and ground were reversed (found in schematic when led3 - led6 were to +5V instead of ground)

Schematic

1. Arrange input jacks on the left of the schematic and outputs (neopixels and leds) on the right in numeric order.

2. Added VCC and gnd symbols from core to reduce the clutter caused by running power connections as one large wire.

Chewie 2_fixed_2.fzz (107.6 KB)

Peter

Thank you for fixing so many things on the sketch. I won’t be able to test this connection physically because I don’t have them parts because I am using the 6n138 optocoupler with the 1n914 diode. The only thing that has caught my attention is the midi out going through the optocoupler. I don’t need it to, I only needed the midi in to go through the midi in.

Anyway I have had a go at the schematic view and have everything routed but I’m not sure if it’s correct. But since doing the schematic view the breadboard view isn’t fully routed. One of the capacitors has a rats nest on it. I only need the capacitors for the led ring and strip. I have one going across the power rails of them. Do I need both of them? Chewie 2_fixed_2.fzz (120.7 KB)

The 1n914 is the same as the 1n4148 so no problem there, you only need to get a 6n137 to change to that if you choose. The posts I saw on the 6n138 say that the slow rise time because of the open collector output some times cause serial errors on the mega UART which manifests as either no midi output or the wrong command because of an error in the serial data coming in. If you don’t see this problem the 6n138 should work fine (unfortunatly it may work fine most of the time but fail sometimes which is why I would use the 6n137 solution.) The resistor connected to pin7 on the 6n138 is intended to speed up the rise time of the output, but getting a proper value may need you to have an oscilloscope to look at the wave form (which you probably don’t have). A way to test this if you can arrange it is to have the midi device that connects to din2 to send the same midi message over and over to the mega. On the mega you would need to write code that receives and checks the value of the midi message. If the message is the same every time and none of the messages are missing (based on time or a count of how many messages the midi device sent) then you don’t have a problem. If messages are missing then the 6n137 (which can be tested the same way) is probably a better bet. As I said I’d use the 6n137 because it is likely to be more reliable and simpler (doesn’t need the tuning resistor) but either will probably work.

Then you can delete din1 and its associated resistors completely as its only purpose is to pass the received data on to the next midi device. That simplifies your board by a bit.

That is because there is an error in schematic. If in schematic view you click on any +5V or ground connection you will see that both +5V and ground connections highlight yellow indicating there is a short between 5V and ground which is causing the routing problem in breadboard. It looks like you moved the top neo pixel part at some point and that moved the wire from +5V that should go to the neo pixel part to ground causing the short and the routing problem. As well a number of other parts were moved creating non straight lines. To avoid this problem you may want to lock the all the parts by clicking on them one at a time and clicking “lock part” with that set you can’t move the part by accident (and need to unclick it if you want to move the part).

If both neo pixels connect at the same place you can probably only use a single capacitor at that point. The reason for the large capacitor on the neo pixel is that they draw a lot of current, and the current draw varies with time (as the individual clocks in the neo pixels drift in time). I would use separate wires from the power supply (which needs to be able to source the entire current drawn by all neo pixels being on at the same time because that will sometimes happen!). I would be tempted to put a 1 amp or higher schottky diode (for low diode drop) followed by a 100uf capacitor between the power supply and the circuitry other than the neo pixels. What can happen when the neo pixels all come on at once is that the 5V line will momentarily drop below 5v (the 1000uf capacitor is supposed to stop that but it may not be able to do so) and that can cause the mega to reset or otherwise malfunction sometimes which can be very frustrating to find. The shottky diode blocks the drop from the neopixel getting to the mega and the 100uf cap supplies power to the mega with a steady 5V until the power supply catches up again. Another alternative is two power supplies, one that supplies the mega and one that supplies the neopixels, but the first solution is cheaper and easier. Below is your sketch with the various lines straightened and the short removed and rewired to the neopixel correctly.

Chewie 2_fixed_3.fzz (122.9 KB)

Peter

I have ordered some 6n137 optocouplers, so they will take a few days to arrive and I will then test the circuit for the midi in and out you drew. I don’t have a oscilloscope so I can’t test the wave form. But I’m sure it will work, I will test the 6n137 optocoupler anyway. As long as the messages are sent it’s all good. Because the leds are controlled by midi using scripts in a program. The neo pixel and the led strip are over to the left hand side of my project so they will most likely be together. So I could probably use just a single capacitor, I will have to have a look at maybe using a schottky diode. Thank you for updating the sketch, how can I move on now to a pcb. I really want to progress to pcb, I’ve never made one before so it’s all new to me.

I expect the messages will be sent correctly, the problem is that they may not be received at the mega correctly. The errors that were reported with the 6n138 are that the rising edge is too slow (because it is being pulled up rather than driven up). That means that while the midi device probably sent the message correctly, the mega doesn’t always receive it correctly. Since the source of the midi messages is a script it should be fairly easy to test this. Modify the source script to send the same midi message something like 1000 (or even 10,000) times. On the mega create a program that reads incoming midi messages, compares the message to what should be sent (and counts an error if the message received doesn’t match what was sent, easy to do when always sending the same message, if it doesn’t match at the mega, then an error occurred in transmission) and counts correct messages. When the source has sent its 1000 (or 10,000) messages check the count on the mega and see if the good message count plus the error count match the number the script sent. It they don’t match then some messages were lost completely.This may take a long time, but you can run it overnight (or for a few days if needed) to see what the error rate looks like. This would also be a good tool to keep around, in case you run in to a situation where messages look to be being lost. If you run this program on the link where messages are being lost it should tell you if the errors are occurring on the serial link (as opposed to somewhere else in the system). If the mega doesn’t receive all the messages then you have the system error rate and you can decide if it is acceptable (a couple of losses in 1000 is perhaps acceptable, 500 losses in 1000, i.e a 50% error rate, probably is not). Doing the same test with the 6n137 installed is also worthwhile to see if it has a lower error rate.

Note Old_Grey’s comment on making changes when more than one view is routed. At worst you have the current version to fall back to if a change in pcb breaks the other views. I’d advise keeping a copy of working sketches as you proceed so you don’t lose a large amount of work to an error that corrupts the database. Start by positioning the parts in pcb view in such a way as to make routing easy. Unfortunatly it is trial and error (and autorouting works so poorly that it isn’t worth even trying for a board like this!). If you find that you can’t route some traces, see if moving one or more components around will make routing easier. It is hard and experience is the only way it gets any easier. You can also always post your current sketch and one of us can tell you how we would do what you want to do (as a first board that’s what I would do, one of us can probably make a suggestion that will save you a lot of trial and error). Once its done, before ordering boards post the final result here for some of us to check for you as it is easy to make mistakes that produce non working boards. Good luck!

Peter

When I recieve the new optocouplers I will have to try all that you have said. I would also like a sketch of what I have set up on breadboard. The original sketch I first sent. But I’m scared of editing the one you fixed because of routing issues. I’d like one because everything is working fine how it should be and I don’t want to go moving things on my board and not remember where components originally were. Thanks

Steps I took that resulted in the problem:

Import Adafruit Fritzing Library

What I expected should have happened instead:

should be smooth and responsive

My version of Fritzing and my operating system:

0.9.3, Windows 10

Please also attach any files that help explaining this problem

Happened to me when there are too many detailed parts at the same time and you zoom out. Seems to be a problem related to program perfomance which can’t be solved right now since there isn’t maintenance from devs.

Hi folks,

My circuit has grown in complexity and now it makes sense to create a ground fill in order for my components to be routed easily to ground. My question is how to great ground vias.

It seems to me that the best way to create them is to bring in a bunch of arbitrary vias to be board and set them as ground fill seeds. Is this correct? Is there a better way?

Try turning off the grid feature. If it is set to a low value it can cause massive lag. If turning it off helps but you want to use it then set it to as large of a value as you can use.

There are two ways.

1. as you said already you can place a bunch of vias and set them as ground seeds.

2. create your ground fill and then place the vias (no need to set the seeds)

The advantage of 2 is that it does not create a gap around the vias with traces connecting it. These gaps are required when soldering to a pin connected to the ground fill because the ground fill would pull away the heat too quickly to get a good solder joint. But with vias in the ground fill we do not need this heat break and we would actually rather have it transfer heat really well.

The disadvantage of 2 is that you need to delete the vias and replace them every time you want to re-generate ground fill because if they are in place already it will create the gap. I usually save the file right before placing the vias, generate gerbers and then revert the file back to before the vias were placed.

Ah! #2 makes more sense for my purposes. Thanks!