Rio

Page not found...

I am looking for something more professionally manufactured PCBs or ready-made modules (Core8 and/or Sid Module). If someone has left in Europe and no longer needs it - please PM me. Thanks, rio.

why did someone solder this in? it's obvious. And also check the Midi In port. yes change the MIDI Out port and then test it in mios studio. if you do not have a desoldering iron, cut the legs and remove the legs with heat using a soldering iron and pliers.

Hey, What are you talking about - the midi port? IN or OUT? I'm not sure what you're examining. Here the schematics from http://www.ucapps.de/mbhp_core.html with all the interconnections: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf Greetings, rio

Because it just sends back the request code. Edit: sorry my fault...i used a "forward sysex code" in the past ... i just couldn't remember. that was the reason..

Hi, What could be the reason why the PIC18F4685 sends the status request (triggered by "query" button in MIOS studio) back to the midi-in?: f0 00 00 7e 32 00 00 01 f7 In Midi Studio, the pic is recognized correctly, only the additional response is wrong. Greetings, rio

The way to the doctor is certainly not necessary for that ;)

Hey, What do you mean by "deleted" exactly? What does the LCD or "Mios Studio 2" report if you connect Midi In and Out to the PC as soon as you switch on the core? And yes, the boot loader comes up first (it has its own address) Note: here are some useful docs/infos: http://www.ucapps.de/mbhp_core.html http://www.ucapps.de/mios_bootstrap_newbies.html http://www.ucapps.de/mios_bootstrap_experts.html http://www.ucapps.de/howto_debug_midi.html Greetings, rio

hi. you don't really need to burn if you still have a bootloader on the pic. the upgrades also go through midi .. PS: But if you really want to "burn", several things are crucial. I would recommend that you take a new PIC for testing and not this one that's already baked.. in any case then do not use the file in the "midi" folder. Greetings,

I was just wondering because in the "MIDI" config on the Jam Page, it has not yet been updated. Greetings.

hi and welcome, Do you want to drive an update? Is there already firmware on it? Then it is possible to upload the firmware (newer bootloader or newer mbsidv2) via midi. What response do you get when you use mios studio 2, connect and set "midi in" and "midi out" for your device and you press the "query" button for example for "device ID:" 0? But please don't load a hex file for it yet ... first you need to look at which ID and version the PIC is responding. Greetings!

Please be careful with such suggestions of implementation and if it is useful please only suggest this as an explicit option. Other data can also be transmitted to MIDI IN (routing, etc.) than just what is to be recorded (even while recording ...).

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

That could be investigated...just unclear. 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?