Is it necessary to always removing the sdcard from the slot when I’m booting?
If I don’t remove the card, the Module will not be found in the MIOS Studio.
Sorry I can’t help more…
No, it should not be necessary to remove the card when booting (I assume you mean “switch power on” to the core).
Is the power supply to the core good enough? (that’s my only guess…)
I use the module USB Powered. So when I plug in the usb connection and the SDCard is in the slot, MIOS Studio shows an error.
Is the midi connection by USB or UART?
What is the error message text (if any)?
The midi connection is by USB. The error message is someting like “core module not found”, I don’t remember exactly. I will check it this evening at home.
Try re-starting MIOS Studio *after* you connect the USB to the core.
Are you using PC or OSX?
I’m using a PC, but there’s no difference when I’m restarting MIOS Studio after I connect USB to the core. When the connection failed once, the error is always the same until I start it up without sdcard and put the card in the slot after startup of the module.
To me that sounds as if something was fishy with the card. Have you tried to re-format it properly and see if the behaviour remains the same?
Hi Beat, I don’t know if what I am seeing is the same as you so I tried removing the SD-card to see if it would come up. I removed the SD-card, plugged in the USB port, then brought up Mios Studio. It did come up OK with status indicating OS, release and such, but when I press the QUERY button I get a timeout error of “Timeout on query request.”. If I type HELP in the Mios Studio it returns the help information and then the QUERY function works OK. With the SD-card installed, then I get an error and its sometimes very difficult to get the USB connection working properly.
I think this is also relaited to not installing the GM5 driver in the PC. My PC is Windows 7 - 64 bit. I have 2 LPC units running Midio128. When I bring up one of the units up it shows the USB ports as “GM5 Port 1-4” and this unit comes up in good health all the time. But the other one has issues. It shows the USB ports as MIDIO128 for the first port and “MIDIIN2-4 (MIDIO128)” for the final 3 ports. The only reliable way I have found to get it to work so I can down load new software is to select MIDII2 port for both IN and OUT ports then reselect them to the MIDIO128 port.
What are the USB port names you see when your unit powers up? This might give a clue to the issue.
Pete
So I installed the GM5 drivers now and tried to format the sdcard. It’s a 4GB sdhc card, I’m waiting now for 10minutes yet, is this normal? The command “sdcard_format yes, I’m sure” is grey, so I think it’s working on the formatting?
I’d say 10 mins is probably more than it should take. How about formatting the card on your computer?
There are USB driver issues in Windows, still.
I have had problems with all drivers (GM5, Windows, Korg).
The most recent Bootloader fixed some of the issues, but I’m still having problems with the File Browser functionality *unless* I recompile the app for *one* USB port (not four).
Typically the file transmissions fail during transfers related to editing a file.
From memory, I have this experience with applications: SEQ V4 and NG, on OS’s: Windows 7 x64 and WinXP.
For simplicity, we might ask TK to include a binary with only one USB port enabled in the pre-compiled zip for MIDIbox NG?
Having said all of that, I don’t know that it will fix the current problem of this thread, but it is something that needs to be eliminated anyway.
So sdcard formatting was a long process. I was to impatient, after a long time, the message came back that everything is OK with formatting now.
I have material for a second LPC17 core module at home so I will build it now to countercheck the issues I have.
Thanks a lot for the quick answers!
Could please somebody reply on my question about the backlight of my display. I only have to know if the backlight should be on after startup. If yes I have to search at my hardware, if not I have to search the correct command in the program. I still have to learn a lot, thanks for your patience 
By all means build another core and see if you have the same problem…
BUT…There are still real problems with USB drivers under windows. They only affect sdcard operations as far as I know, and are solved by having only 1 USB port enabled in the firmware. The pre compiled binary has 4 ports enabled…
You are right Duggle, there are problems with the USB drivers under windows which is the only OS I am familure with. By building another core you will find out some of the issues. I have been living with issues like not recognizing the default Midi USB port so its difficult to down load a new version of my test software. See previous post. When I load the GM5 driver, all problems go away. This includes any SD-card issues. But when I disconnect my MidiBox 1 and then connect my MidiBox 2 hardware to the PC USB port, the PC doesn’t use the GM5 drivers but uses the default Windows driver instead. I would expect a different instance of the GM5 drivers to be used rather than the default Windows driver on this different but similar hardware.
I don’t know now the switch-over from Boot software to Runtime software is done in MidiBox, but I suspect that they share common tables or code during the switchover. You talked about defining only 1 USB port. If I recompile the Midio128 software with this change, do I have to worry about updating the boot software?
Pete
I’ve noticed the same thing with a second core using Windows drivers instead of GM5.
I think it came down to which physical USB socket I plugged into in the PC, in my case.
Definitely make sure you have the latest bootloader (1.010, I think it’s called). In my case this improved the handling of multi USB port applications to the point where I could route different USB ports to different MIDI ports on my SEQV4 handling MIDI events and SysEx perfectly for the first time. However, the File Browser does not work right in this set up.
I had the same problem on my NG core on another PC, (I found, naturally, that no File Browser with NG was totally unacceptable, so I recompiled for 1 USB port and now all is fine).
So to answer your question, my advice is to update your bootloader, and then load the app build that has just 1 USB port enabled.
I’ve noticed the same thing with a second core using Windows drivers instead of GM5.
I think it came down to which physical USB socket I plugged into in the PC, in my case.
Definitely make sure you have the latest bootloader (1.010, I think it’s called).
If you do more testing you will find out that the GM5 drivers will always follow the MidiBox hardware unit that was pluged in when you installed the GM5 driver. Any other unit will use the default Windows drivers. The Midi port doesn’t change this. It seems like Windows is keying off something like a serial number stored in the LPC17 core. I built a 3rd LPC17 core and it also uses the default windows drivers rather than the GM5. I wonder if this specific problem is in the PC side? Or maybe MidiBox is initializing the USB structure types wrong that causes this to happen. I’m just guessing here. It would make sense for all MidiBox hardware to use the GM5 drivers in the PC and load a different instance of the same driver in case a 2nd MidiBox was plugged into the PC at the same time. That way you would have 8 names to select from rather then 4.
Pete
Pete
What I’m seeing is this:
With MIDIbox KB and SEQV4 (LPC17), as I described will use GM5 driver if plugged into a certain USB port, Windows drivers if plugged into another. Then, if I swap the USB ports they are plugged into, the drivers also swap. From this it would seem that the GM5 driver associates itself with a certain physical that was used during it’s installation. I could try installing GM5 on the other port out of curiosity sometime.
What I do notice is that the File Browser functionality is more profoundly defunct using GM5 rather than Windows Drivers (i.e both faulty with slightly different signs and symptoms)
Do you have the same issues with the Korg driver?
http://discourse.midibox.org/t/topic/15813
Best Regards, Thorsten.
I updated the application to NG 1.020 from the precompiled zip.
- After disconnecting the core and restarting MIOS Studio, the 4 USB devices appear, but Query does not work on any of them.
- I run the GM5 installer and uninstall.
- Now MIOS Studio can communicate with the Core and 4 USB devices appear, but the File Browser fails during opening a file for edit.
- I run the “Install KORG USB-MIDI Device” from the start menu, “ERROR: No Device plugged in”
- I select “unistall” for MIDbox NG device in Device Manager
- I run the “Install KORG USB-MIDI Device” from the start menu, “Allow Hardware Wizard to run”, or similar
- The device enumerates and shows MIDIbox NG in device manager
- I run the “Install KORG USB-MIDI Device” from the start menu, “ERROR: No Device plugged in”
So unfortunately I am unable to actually install the KORG driver 
To restore things to functional again I have had to reflash the Core with single USB device firmware build NG using UART midi from a GM5 Interface module.
I’ll also mention an interesting observation, with the GM5 drivers: Both the Core USB devices and the GM5 module appear as “MIDIbox NG” which was very confusing at first.
This also occurred with 4 USB midi device version of NG and the GM5 module with the windows drivers,(If I am not going completely mad…which is conceivable 
.
Now that I am back to my single USB device build NG with the windows drivers I see “MIDIbox NG” (x1) and “[2] Ploytec GM5 www.midibox.org” as I should and it’s all working fine.