Jump to content

latigid on

Frequent Writer
  • Posts

    2,516
  • Joined

  • Last visited

  • Days Won

    147

Everything posted by latigid on

  1. The soldering on the OLED headers could be better, try to rework. If the fillet looks like a teardrop, it might not be contacting the PTH properly. Try to get the heat into the pad and the solder will flow there. Soldering could be better on IC2, pin 8. Recheck R33abcd. Try swapping the OLED cabling to the other J15 port. Could be bad cables again, could also be that some pins on the cable short out components on the OLED, so isolate with even a scrap piece of plastic or card on the OLED PCB right under the connector.
  2. That might be a hard combination to tune. But yes, normally blue should have a lower-value resistor as it's typically dimmer. At least on the older SEQ firmware, the measure LED was not "XORed" i.e. beat and measure would trigger at the same time. That might be a way to get all three going at once for white-ish, though I can't remember if it's still part of the current firmware.
  3. Sometimes I feel like there can be oxidation or other crap on the pins that prevents good contact and messes up the data transfer.
  4. If _NG is flashed and JA is working it's a good sign. The _l and _r .NGC files specify the position of JA. You can use _r to test lemec_L. It's possible to test lemec_R as the first board in the chain, but you need to reconfigure the file. The boards are chained JA-lemec_L-lemecR, correct? You should measure +5V on the 74HC165 input pins and 74HC595 outputs should go to +5V with set dout all 1. Check the preceding pages of this thread or the datasheets for pin assignments. You can follow the SRIO chain (especially the SO signal) to see how far the data gets. Seeing as you have some DIN activity, consider replacing IC2/IC4, which were reversed and then heated up probably quite a lot during rework.
  5. Just check first that the MB_NG app is flashed and you have loaded the correct seq_l or seq_r.ngc. Was testing of the JA board okay? To simulate DOUT behaviour you can try set dout all 1 Or go through and count the dout pins (8 per chip) until you get to the correct IC -> replace all with the one you want to toggle. DOUT rows/cathode sink rows are given in previous pages. The matrix is controlled by ICs 2 (cathodes) and 3 (DIN). Having spare parts is always useful and could be used in future projects. I typically get 100 shift registers at a time.
  6. No worries. It might be that IC2 was damaged by being reversed. Did you use new chips or the same? I was troubleshooting with @niles the past weeks on a similar problem. The same advice applies, so check cables, resolder IC2 and IC3. Many solder joints look "cold" Any MIOS output with set debug on ?
  7. When you say the "kernel" doesn't boot, do you mean the waveshare MCU breakout board? If this is the case, a typical cause is a short between 0V/+5V. Please check the orientation of all ICs. At least IC4 is in backwards! (The stripe on the IC should go towards pin 1).
  8. Glad you got it working. Interesting solution, as R33A is more associated with the OLEDs.
  9. Frequency is controlled by the CPU, I'd say if you see the clocks at all it's good. It might be that RC is 1 kHz. How's your DIN matrix looking?
  10. R26 is connected between 0V and pin 13. If pin 13 is at 0V, it's a good sign. Perhaps the serial data doesn't make it to IC2. Actually ICs 17, 19 and 20 are before IC2 and finally IC4 in the chain. Scope the same pin 14 on each IC to see how far it gets. You can also check for continuity between the following points: J89 pin 6 (middle pin, other side of the notch), IC17 pin 14 IC17 pin 9, IC19 pin 14 IC19 pin 9, IC20 pin 14 IC20 pin 9, IC2 pin 14 Looking at your picture, I can see a probably cold joint on IC19, pin 14.
  11. Sometimes OTG devices don't play nice together. We're still learning what works and what doesn't. Did you adjust the Keystep jumpers for USB sync?
  12. I think you've ascertained that the DIN side is good. Thanks for the tests! The sequence of outputs on the 595 just goes around in a cycle. It toggles one output high, which turns that transistor "on". Meanwhile, all other outputs are low, so all other transistors are "off". Then the next output goes high. By turning on one transistor at a time, you enable only one row to be scanned (here only four switches). This is how you differentiate between switches in the column of (here four). It makes not difference if any switch is pressed; the 595 outputs cycle like a background task. The fact that you see (or saw) all four switches triggering makes sense, as your 595 outputs are all high, rather than 1/8 each time. So I suggest paying close attention to IC2 again. E.g. it looks like pin 8 is not soldered properly? It is actually possible (hopefully not, but a possibility nonetheless) to damage CMOS by sending it data while the chip is not properly powered. If you compare IC2, pin 14 on both boards, you should see a similar pulse train that is offset by (I think) 24 clock ticks. Pin 12 should toggle at the end (and I think also at the start) of the pulse train. Check R26 is properly soldered and that pin 13 of IC2 is ~0V.
  13. It just interrupts the +5V supply on the USB A socket. I don't know the workings of a Keystep: can you power it externally?
  14. First thing: did you connect the jumper on the USB PCB?
  15. @Simon Sounds like a sync issue, probably not related to the build. Please explain your setup, what sync and routing settings are used etc. Maybe in a new thread? Thanks for the beer the other day btw!
  16. Maybe your issue is actually on the sink side, where multiple rows are triggering at the same time. With the NGC loaded, with your scope you should see the 595 outputs on IC3 (pins 15,1,2,3,4,5,6,7) toggling high in a sequence of 8. The pins correspond to A B C D E F G H where A controls the first four encoder switches, B the second four encoder switches, C the first four Matias switches...G the first four MEC switches (note SW19!)...
  17. If you remove the seq-plate do you get the same behaviour? That would rule out clearance problems. ICs 1 and 5 scan the encoders (no matrix). ICs 2 (sink side) and 3 (DIN side) form the matrix for switches. Pins 11,12,13,14,3,4,5,6 of a 165 shift register are the inputs. If you don't read a voltage, probably the contacts in the encoder are connected to the common (0V) pin. Turning the encoder will change the state of the 165 inputs. You should also test the switch behaviour on IC3 in this way (first column pin 11, eighth column pin 6). I.e. test a switch in column 1, check that the input on pin 11 toggles low and high again. Check that the other inputs do not toggle. With your scope you can check pin 2 (clock, I think it's 1kHz) and pin 1 (strobe/latch, triggers after a certain number of clocks). Pin 10 is the serial data input that comes from 165s further down in the chain, pin 9 is the serial output that shifts data to the MCU or the previous 165 in the chain. Pin 15 should be at 0V. Did you already check if any adjacent pins of the ICs are shorted? IC2 could also be tested without the matrix running. Restart MIOS studio and don't load an NGC file. If you can be careful enough, you can try bridging the 165 inputs to 0V one at a time. Monitor the console data output. You could also use set dout x 1 where x is the 595 output to control sets of 4 switches without using a matrix, but maybe this doesn't clarify the problem.
  18. Are the note events always the same, no matter what switch is pressed? I can't see any of the parts designators, so I can't help there. It's a bit fuzzy, but the solder joints look rough rather than smooth. So maybe some cold joints are there. Maybe try a slightly higher iron temperature? The JA board not being connected doesn't affect things. Are you sure you have seq_r.ngc loaded? As you have a working le mec, you can compare voltages on IC2 and IC3. Note any differences.
  19. Backwards 165 IC or resistor network maybe? Bad cables? Transistors/diodes interchanged or wrong type of transistors? Pic of the PCB?
  20. Probably SW19 is not soldered? Check for continuity across "bridge" marked with silkscreen and solder the pins or temporarily bridge if needed.
  21. At a guess, some of the components from the seq-plate are shorting out those on le mec. The usual offender is the encoder right above the J89A header, but it could be more around IC3 on le mec, e.g. long diode legs from above. Check the diode orientation too. The note numbers from your output can be used to trace events in the NGC: D#2 = note 39 D#4 = note 63 D#6 = note 87 They correspond to the fourth column of buttons, pin 14 of IC2. Check the sixth pin (counted from the left when looking at the top of the seq-plate) of the 10-pin header J2.
  22. Nearly there! The blood sweat and tears will make it all the sweeter!
  23. The mini USB shouldn't have much to do with the +5V power, and it could be a dodgy pin contact (the PWR 5V pin as Peter noted) that reconnects when you put pressure on the board. A little note on connectivity tests: if you probe for connections between +5V/0V lines, you may get a short "beep" as there are capacitors that charge up temporarily. A short circuit on the +5V lines to 0V (which is quite nasty for your USB power supply and probably other components) is only diagnosed as such when you get a continuous beep or 0 ohm resistance.
×
×
  • Create New...