Troubleshooting midiphy SEQ v4+

[latigid on]

Nice to hear you got it resolved! 

The (tented) via that you mention is the SO signal, so that ties in perfectly with your observations. The likely short was to 0V, so the 595 registers never received any bits to shift in.

Best,
Andy

[Adam Schabtach]

I think I've bumped into a manufacturing defect on one of my lemec PCBs. I've started soldering the superflux LEDs in groups of four and am testing them with the diode-checker function on my DMM as I go along. I have finished the first lemec PCB and there seems to be a break in one trace for the red element of one of the LEDs. The LED itself works; it lights up when I apply the probe tip to its pin directly. 

By investigating other parts of the PCB I have found that each red element is connected to two of the pads labeled "1". Hence there is--or should be--continuity between pairs of these pads. In the case of one LED on the PCB, it is connected to only one of the pads. The attached photo shows the location of the bad trace; it's the third LED from the right, lower row. The green line shows the connection that works; the red line shows the connection that should work but doesn't. In other words, there is no connection between the lower "1" pad and the LED's pad.

I can fix this problem with a jumper wire but I thought I should mention it since other PCBs could have the same defect and troubleshooting the problem after the board is completely assembled could be difficult. It's possible that I broke the trace myself but I think unlikely. First, it's pretty difficult to actually break a copper trace by accident, and second I was being quite careful while doing this soldering because of the delicate nature of the superflux LEDs.

Thanks for your attention.
 

[latigid on]

Hi Adam,

I don't fully get it: are you able to illuminate both superflux LEDs (red) in this column? Also, is it the _L or _R board and what is the version number?

You can see the board trace should connect all "red" LEDs in this row, but the SJ part will not be connected to the LED until the resistor is placed. This sets the output for the MEC LED but you were talking about superflux?

 

I can see a scratch on the board in your picture, is it related? If you're feeling masochistic you could sand back the solder mask and see where the copper stops (if it does).

If the trace I marked with a "?" really doesn't connect, I would suggest to use a 1k THT resistor as indicated with the red mark. It would also be possible to use one of the 2/3 positions, but the matrix addressing will need changing in the HWCFG file.

 

[Adam Schabtach]

Hi,

The PCB says "lemec v1.3_R (c) 2018". I am testing the superflux LEDs individually; there are no other components on the board yet. The cathode pins of the LEDs are not connected; I left the cathode pins pointing straight up so that I could test each superflux LED in isolation with a DMM.

Yes, the trace you marked with a "?" does not connect. There is no connection between the "1" pad for that superflux LED and the square pad marked "1" below your "?" mark.

The scratch you see is because I started to scratch away the solder mask to add a jumper wire between the middle of the trace and the pad for the LED, but then I decided to stop and document the issue before doing anything else. I think that your suggestion for adding the resistor is a better idea. It would be interesting to remove all of the solder mask to find the break, but I think that it would be more interesting to just keep building the kit. 

Thanks for your help!

[Hawkeye]

Hi Adam,

first of all, thanks for your intensive testing, you would not want to test the new LoopA boards, too by chance? These should be ready soon :)

Then, I checked all LeMEC_Rs we have in stock (new ENIG plated are a newer version than the 1.3_Rs) and a handful of remaining HASL ones with the same version 1.3 we still had as old stock - no problem on a few dozen totally tested boards, so it must be a local thing on your board, i'd expect a scratch, or a lifted/misconnecting pad or something like that. Also, the 1.3s were built by many people without that problem.

Here is how i measured - PIN 1 lower superflux (red) to PIN 1 SJ connector - and i just heard a lot of beeps for many boards :) - the one in the picture is a 1.3_R.

We take all quality reports seriously and if you say it's a problem on the PCB, we'll send you a new board as a replacement, i just could not reproduce it on any of the boards we have in stock.

Best regards,
Peter

[Adam Schabtach]

Hi Peter,

The testing is coincidental; I do not usually check every trace on a PCB... 

I expect that the problem is rare. I knew from the date on the PCB that many of them must have been built by now. Your photo shows the same measurement which I made; thank you for the verification. I doubt that it is a lifted pad partly because I am using a lower temperature than usual for soldering the LEDs and I did not have any particular problem soldering that connection--and all other connections from that building session worked on the first test.

In any case, I will fix it with a jumper or with the resistor. Thank you for the offer of the replacement, but there is no need to send one. I think that I would rather fix it than solder all of those LEDs again. 

[Adam Schabtach]

I finally found some time to work on my sequencer, and soldered the remaining superflux LEDs without trouble. I then went back to the one with the broken trace to figure out exactly where the break is. I pierced the solder mask with a DMM probe to check continuity. Once I narrowed it down I scraped away the solder mask to find the break. Somewhat surprisingly, it was broken in the middle of the trace, underneath where "SJ3" is printed. Here's a photo taken with my cheap USB microscope; you can see both what looks like a scratch at about a 45-degree angle to the trace, and more damage parallel to the trace. No, I definitely did not inflict this damage myself, and (as before) I am sure that it happened in the factory. The silkscreen was not damaged, and my DMM told me that the break was in this part of the trace before I scraped off the mask.

It's academic now but it is sort of interesting.

[latigid on]

Thanks for the follow up! You're certainly not to blame for this, so I'll ask the fab what happened. Looks like the copper substrate was scratched from the beginning or some of the mask rubbed off before etching.

Let us know privately with any subsequent order and we can spare you some $$ for the trouble.

[Adam Schabtach]

Are the white LEDs used in the pushbuttons available from Mouser or Digi-Key? I'm having some intermittent problems with two buttons on my JA board. Removing and replacing them will probably destroy the LEDs, so I'm going to have to get new ones somehow.

[latigid on]

Hi Adam,

Interesting, the MEC/Apem switches are typically quite solid! How are you determining intermittent behaviour? Could it be that the switches are fine but the LED legs are broken/intermittently contacting (compare DIN events in MIOS Studio versus LED emission)? Removing the switches is really a pain (as is inserting LEDs when the switch is already in).

I don't think the LEDs are available at Mouser. Considering the issues you've had, I think we could send you a set of replacements. If that would be too slow for you, you could also find similar replacements on eBay but they will likely ship from Asia.

Best,
Andy

 

[Adam Schabtach]

Hi Andy,

I finally figured out the problem, and it was not the switches. The problem was that two of the switches seemed to be sticking in the on position while I was testing them with MIOS Studio. I had tried everything else--resoldered all solder joints (twice, even), checked for shorts with a DMM, checked that the pullup resistors were connected properly, etc. Finally I had removed all of the switch caps and had unsoldered the LEDs in the two suspect switches, and I finally saw the problem while I was looking sideways at the PCB. There was some sort of fibrous material stuck to two of the pins on the resistor network. Apparently it was conductive enough to cause problems, because I removed it and the buttons then worked correctly. I don't know what it was; maybe cat fur soaked in solder flux? 

Unfortunately one of the LEDs is now damaged and can't be reused. I can either order them myself or if you can spare two (if you're going to send one, you might as well send an extra) I can "buy you a beer" to cover the cost. Either is okay with me.

Thanks--

--Adam

[Hawkeye]

Hi Adam,

no problem to send you a spare LED, with all the "Murphy's Law" you encountered during the build!

But, could you count if you don't have a spare already? For similar reasons (i.e. if one of the LEDs is defective from the start or is damaged during installation), we usually pack a total of 60pcs 2x3x4mm LEDs for a full kit, so there should be more than a single white 2x3x4mm LED left over as a spare.

Have a good sunday and best regards,
Peter

 

[Adam Schabtach]

Hi Peter,

After I went to bed last night, I suddenly thought, "I bet that they put extra LEDs in the kit already, so maybe I am lucky and I already have the spare that I need." Then I was busy all day today but just now I finally had a chance to count the LEDs, and yes there are several extra white ones. There were even two extra white ones just in the bag of assorted colors.

So, thanks for your reply, and thank you for packing extras! Hopefully Mr. Murphy will be less interested in the remaining steps of building my sequencer.

--Adam

[lp1977]

Hi,

I completed my Midiphy RH Seq v4+ about a week ago and have been using it pretty much every day for the past week. All my build testing seemed to indicate there are no issues, however I notice a couple of things after using it for a week:

1). If I remove the SD card while the unit is on, I get the "SD Card Removed" notification on the OLED screen and suddenly any and all of my push buttons become unresponsive. The encoder turns continue to move the cursor on the OLED screen, but the encoder presses, Matias switch presses, and MEC switch presses do nothing. When this happens, the button presses begin to show in MIOS Studio with:

[160430.669] [SEQ_UI_Button_Handler] Button SR:8, Pin:D2 not mapped, it has been pressed.

[160430.813] [SEQ_UI_Button_Handler] Button SR:8, Pin:D2 not mapped, it has been depressed.

 

When I re-insert the SD Card, i get the notification on the OLED screen saying "SD Card Connected", but the buttons are still unresponsive. I can reach the SD Card through MIOS Studio with the 'sdcard' command and the Play/Stop commands from MIOS Studio all still work, but the SEQ hardware button presses remain 'not mapped' in MIOS Studio. If I use MIOS Studio File Browser to re-upload the MBSEQ_HW.V4 while in this state, it autoloads after upload and all the buttons function again until the next time that I remove the SD Card. Also, a restart command or power cycle with the SD card installed will restore the button functionality. When booting without SD, I don't get to have the RH config loaded, but some of the button/encoder presses do random things, so they appear to be working. 

 

2). Exporting to MIDI Files causes a "Hard Fault at PC=0x08049b0c" or "08049b54" (just examples) to be displayed on the OLED screen, or the SEQ just locks up with the "Exporting G_T_ to /MIDI/___.MID" notification on the OLED. At this point, the SEQ is completely unresponsive, even in MIOS Studio. I've tried exporting one measure of one track, or a whole song with 140 measures and I get one of those two outcomes without any successful exports.

I have tried 4 different SD cards that I have on hand: SanDisk 2GB SD, SanDisk Ultra SDHC 16GB, SanDisk Ultra Micro SDHC 16gb, and an unlabeled 2GB micro SD. Micro SDs are being used in a SanDisk SD adapter.

 

I'm running MIDIbox SEQ V4+.095 with associated midiphy-rh MBSEQ_HW.V4 from the release package. 

 

I've been able to do many things without issue. Successfully format SD card in MIOS Studio with 'sdcard_fomat yes, I'm sure', Booting with SD card installed, create new Session, save patterns, create pattern chains in song mode, Switch Sessions, export Sessions in the Utility -> Disk screen.  A lot of SD card activity all functioning with all four SD cards I have.

 

Thanks in advance for any help you can provide. Apologies for length, as I've tried to include as much info as I can.  I can use the SEQ pretty extensively without doing these two things, but I would like to fix it if i could!

[latigid on]

For removing the SD card during runtime, we've established that this can break things, so please restart if the card was removed.
(would be nice to reload the HW config file upon remounting the SD).

I'm not sure if the MIDI file export is related to any particular hardware. Sounds a bit like a memory overrun. What is the flash size of your STM chip when you query in MIOS Studio/is the chip VET6 or VGT6 on the Waveshare board?

Please post the request (maybe also the previous bug report) in the following thread and hopefully TK. gets some time to look at it. Additionally, provide an example session that could be tested. 

http://midibox.org/forums/topic/13137-midibox-seq-v4-release-feedback/

 

 

[lp1977]

1 hour ago, latigid on said:

For removing the SD card during runtime, we've established that this can break things, so please restart if the card was removed.
(would be nice to reload the HW config file upon remounting the SD).

Thanks for clarification. I had read this about the MBSEQ_HW.v4 file in the uCApps User Manual and was applying it to my situation: 

"The file will be loaded (only once!) after startup. In distance to other configuration files, it won't be loaded again if the SD Card is reconnected to avoid sequencer hick-ups during runtime, and to cover the special case where files should be loaded from a SD card which contains a MBSEQ_HW.V4 file for a different hardware."

This made it sound like you could hot-swap the SD cards if you had different files on different cards, without it affecting your HW config.

 

1 hour ago, latigid on said:

What is the flash size of your STM chip when you query in MIOS Studio/is the chip VET6 or VGT6 on the Waveshare board?

The waveshare is installed in the case so I'd need to disassemble it to look at it. 

This is what I see in MIOS Studio query window:

Operating System: MIOS32

Board: MBHP_CORE_STM32F4

Core Family: STM32F4xx

Chip ID: 0x10076413

Serial: #1D0027001851373337323532

Flash Memory Size: 1048576 bytes

RAM Size: 196608 bytes

MIDIbox SEQ V4+.095

(C) 2018 T. Klose

 

 

 

Thanks for the response. I'll get a sample together and post in the release feedback thread.

[Antichambre]

1 minute ago, lp1977 said:

Flash Memory Size: 1048576 bytes

It's a VGT6.

[latigid on]

7 hours ago, lp1977 said:

Thanks for clarification. I had read this about the MBSEQ_HW.v4 file in the uCApps User Manual and was applying it to my situation: 

"The file will be loaded (only once!) after startup. In distance to other configuration files, it won't be loaded again if the SD Card is reconnected to avoid sequencer hick-ups during runtime, and to cover the special case where files should be loaded from a SD card which contains a MBSEQ_HW.V4 file for a different hardware."

This made it sound like you could hot-swap the SD cards if you had different files on different cards, without it affecting your HW config.

TK.'s description is slightly ambiguous, but I agree with your assessment. The config file should stick and the hardware should know to keep the correct matrix assignments.

 

7 hours ago, lp1977 said:

The waveshare is installed in the case so I'd need to disassemble it to look at it. 

This is what I see in MIOS Studio query window:

Operating System: MIOS32

Board: MBHP_CORE_STM32F4

Core Family: STM32F4xx

Chip ID: 0x10076413

Serial: #1D0027001851373337323532

Flash Memory Size: 1048576 bytes

RAM Size: 196608 bytes

MIDIbox SEQ V4+.095

(C) 2018 T. Klose

 

 

 

Thanks for the response. I'll get a sample together and post in the release feedback thread.

Bruno is right; the 1MB flash confirms the correct VGT6 chip.

[SimonSays]

Hey all - i’ve just had an issue come up... at some point today, the switch LEDS on the transport row have lit incorrectly. I’ve niw got all lit aside from play and play doesn’t light green whether playing or stopped. All functionality is correct (play, pause, stop, etc) but the LEDs aren’t lit correctly.

I’ve got to disassemble to bridge the OTG switch so i’ll fix at same time - any idea what the culprit might be before I dive in?
 

Thanks

[latigid on]

So all LEDs are lit except play? And it's a sudden change? 

If the switches function properly, the issue is either with the anode side (IC3), THT resistors or with the LEDs themselves. 

I would check individual diode functionality with a multimeter. A possible fault is that one or more LEDs are busted. 

[SimonSays]

Thanks - I discovered last night that it’s probably a bad joint: plugged SEQ in and only stop button light lit (normal state). Pressed play and play LED lit green for a second and then all transport LEDs lit white again with play unlit completely, as per ‘bad’ state.

it was always going to be my soldering :( I’ll look where you suggest!

 

Edited December 15, 2019 by SimonSays

[latigid on]

Check also the 1N4148 diode orientation, probably all are fine as the switches work but just to be sure.

[SimonSays]

It turned out to be a button/case issue... As soon as I got the top off, the button LEDs returned to proper service.

 The top was a very tight fit to all the buttons, switches and dials when i first fitted it. Although all the transport buttons were free to move, something must have been trapped underneath... perhaps one button not quite fully lifting back up? I couldn't repeat the issue with the top off so can’t be certain.

I spent 20 mins with a fine file and gave some up/down movement potential to the jog dial board and moved it less than 0.5mm upwards. That has also allowed my aftermarket jog dial to fit the aperture precisely and improved how I could fit it vertically.

The issue recurred when I got the screws for the cream top back in and tightened - it seems to be held at bay by only just nipping up the right hand (jog side) 2 top screws. I don’t think my transport buttons are off the PCB, though. Might be a bad joint somewhere on the switch LEDs still, but it’s back working again now.

Thanks

[otropom]

Good morning, everyone,
I have a little problem with the dot display of my seq v4+, few month ago, after finishing the assembly i had systematicly the first two lines lighting up at the beggining of a sequence, I had thought about the cable but after changing it it persists. As a video is easier to understand: https://www.youtube.com/watch?v=24E-SRoXB30&feature=youtu.be Any idea where this could come from?

thanks!

Edited January 21, 2020 by otropom

[latigid on]

https://www.youtube.com/watch?v=dOXIs6Rkhyk&t=7353s

contains testing for the JA matrix. Please reload the _NG .hex file and see if you can control the LEDs with CC16.

 

If you can, maybe it has something to do with the track settings not being in sync on the SEQ?