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  

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...