Rio

Hi, "Midi solutions" tools (like Merger, Thru aso.) are only powered via midi. I wonder if that would also be possible with a simple pic core module (stuffed with a PIC18F452, where no hungre lcd etc. are connected). I just want to process some midi data from IN to OUT. greetings, rio  

You mean, the port confusion should not have been a problem.

yes and no. Regardless, the h2testw test program shows me a lot of errors, the card is useless and it's not a SDHC - it's a SD, and nobody sells such SDs anymore. But, I just want to know if something is wrong on my hardware setup, or if someone else notices these things (long formatting time, hanging on startup, aso.) and if something could be fixed (on hardware: possibly through additional stabilization or possibly software adjustments). Strangely, I have tested 2x Sandisk Extreme SDHC 4GB, 1x Medion SDHC 4GB and 1x Medion SDHC 32GB. All cards show the same behavior.

Update: I have now tested an SD Extreme III 1GB - FAT. No problem. sdcard_format command is finished in 1sec. The Card is never undetected - SEQ always boots. The problem only occurs with SDHC (FAT/FAT32), tested > 4GB.   Ok and now a few screenshots of my tests (with CH2 (blue) - RC1/CS# trigger): 1a. switched on 1b. switched on (another one) 2. Screenshot after booting (while the logo is displayed - before the card is read) 3a. Tried detect/read SD - and failed 4. After a failure, it always stays down for a few seconds. That remains until the next attempt. Then happens the same again and again (Screen 2, 3, 4), except I plug the card out / in. Then it will be interrupted and the card can then be recognized often. 3b. Another try detect/read SD - and failed 3c. Another one - failed And now a few screenshots, if the SD card is successfully detected after the boot: 5a. Successfully detected 5b. Successfully detected 5c. Successfully detected It's hard for me to make a difference to the failed detection. But maybe you recognize something from it. The lower blue line is the spectrum of CH2. I have CH1 (yellow) taken directly from the LF33 and it always looks stable (about 3.2 V). Best regards, rio

Do you mean to change trigger to CH2 in openhantek? And do you mean there must load on RC1 through the SD connection e.g. during boot? this will be hard to pinch the probes without shortening the circuit...

Update: 1. I screwed out the core board and looked at all solder joints. Looks clean.  2. sdcard_format command works, but it takes a long time for the SDHC card!! Contrary to my assumption that sdcard_format crashes the seq - that's not true. It works with success but it takes for the 4GB up to 15 minutes and it just gives me until then no status. So I assumed it crashed. I did not know that there is no status message of the process. Is that the same with you? The long time for formatting for SDHC 4GB is also reported here: http://midibox.org/forums/topic/17763-sdcard-problem/#comment-156398  Regardless, I also specified the bootloader to use a single USB port...

ok now the screen with full connected MIDI devices...That looks ok - no drop down. But the SD itself is no longer connected, as I have clamped the DCO's probes to the pins of J16. But, unfortunately I noticed that my x0xb0x was inadvertently connected from OUT2 of SEQ to MIDI THRU instead MIDI IN and it ran and I did not notice it the last couple of times. It has supplied both devices with lower voltage once one is turned off :/. Are the ports not protected? - but I did the measurement and the screenshot and CH1 still looks good (even if it was wrong connected). I've plugged it right again and once did the tests with the SD card. But, the behavior remains - sometimes it does not start with SD with full connection of all devices. if I remove 5 devices from it, then it always boots with sd (once found .. then everything works.). Besides: what I also noticed that the sdcard_format command does not work for the faster cards (SDHC), even if no devices are connected and even if no Quad IIC boards, no MIDI IN / OUT, no J8, no J9, no LCDs are connected anymore. LPC17 freezes immediately after sending command. That should not happened, but I've never noticed it, because I have never used that command before (since I built the box). Does something already show what's going on with it? What should I check next?

The screenshot below shows (as recommended by Antichambre) Vd (CH1 yellow) and RC1 (CH2 blue) of J16. This is on the fly, without any devices at the ports. I could not recognize long spikes when switching on (its to fast). That looks ok? Although Vd is slightly below 3.3V (3.2). Next time I hang up all devices

hey that's a lot of information. Thank you. I'll turn on the DCO. As background: I use 12x MIDI OUT and 3x MIDI IN ... fed by LPC Coreboard +2x Quad IIC boards. I know - it's a lot but I only live once.

I want to update openhantek (software for certain DCOs) before doing some tests. It seems that the last official version supports the dds120 ... Update: I got the last openhantek 6022 variant running with dds120. It is not possible to record directly inside, but I can configure following params: I could export a CSV or save it as PDF. Additionally I can zoom and measure (as tools).

with "Ground connected" do you mean that I should connect both "Probe ground clip" to the ground of the SEQ, right?

I will test later. j16E is from the LPC17 core board, right?

I can do that. do I have to pay attention to DCO connections? I have a dds120 here: https://sigrok.org/wiki/SainSmart_DDS120 the probes can be switched 1:1, 1:10. The software is a modified openhantek variant ... however, what is completely unclear, why is the failure rate dependent on the amount of devices connected and powered on the midiports?

it goes through this loop: https://github.com/midibox/mios32/blob/3cb2f368e39a686451ce2759966530251f455681/mios32/common/mios32_sdcard.c#L181 and ends up here: https://github.com/midibox/mios32/blob/3cb2f368e39a686451ce2759966530251f455681/mios32/common/mios32_sdcard.c#L190 and MIOS32_SDCARD_PowerOn is repeated thereafter (after a while)

a delay - based on? The startup is already delayed enough by the logo display (about 3 sec)