TK.

It's just the router project, slightly extended by some very specific button/encoder functions for my private needs: Button A: MBSEQ routed to MBSID/MBFM Button B: Force MIDI Channel of Keyboard to a specific Channel Button C: Transpose Keyboard Button D: Keyboard to MBSID enable/disable Button E: Keyboard to MBFM enable/disable Button F: Keyboard to MBSEQ enable/disable I don't plan a customizable version, it wouldn't be worth the effort... I'm happy with the available functions and I'm using them intensively since 1 year The routing/filtering/mapping can be changed in the source code, accordingly this is the most flexible MIDI router you can find ;-) Best Regards, Thorsten.

http://www.midibox.org/dokuwiki/doku.php?id=lcd_module_liquid_crystal_display Search for Jim Henry's superb guide about LCD soldering Best Regards, Thorsten.

Have you ever checked the multiplexer control lines between CORE:J6 and AIN:J6? If four analog channels are not working, it sounds like one of the three select lines is not connected, or that it has a short Best Regards, Thorsten.

I added the keyword "schematic" to the .pdf's... Best Regards, Thorsten.

Finally: Best Regards, Thorsten.

The waveforms of the encoder pulses are inverted, as the DIN register chains are working with low-active. As you've already noticed, it doesn't make a difference. However, maybe the output signals of your encoders are too unstable when it is rotated. There is no encoder debouncing implemented (would consume too much RAM and too much CPU performance), but you could decrease the update frequency - maybe this helps. So, what does happen when the update frequency (MIOS_SRIO_UpdateFrqSet) is 5 mS instead of 1 mS? Best Regards, Thorsten.

This is the link to the Walkthrough: http://www.ucapps.de/midibox_sid_walkthrough.html Best Regards, Thorsten.

thats strange, because there is no "bootloader V1_2a" file released, only bootloader_v1_2a_pic18f4620.hex and bootloader_v1_2b_pic18f4620.hex, whereas for PIC18F4620, there is no functional change in both versions I will contact Mike, maybe it is a wrong version Nevertheless it could make sense to send me the PIC for further analysis. I could read out the bootloader and compare it with the official version. And if it is identical, I could check it on my core module. Since there are not so many users who have tried the PIC18F4620 yet, I cannot exclude that a certain chip revision doesn't work properly Best Regards, Thorsten.

Hi Ole, I made some experiments with the bootloader in order to get a feeling about what happens, when the wrong one is programmed into the PIC. If the PIC18f452 bootloader is programmed, you wouldn't receive any MIDI data at all, only zeroes The PIC18F4685 bootloader would work like the PIC18F4620 bootloader So, it's very likely, that the problem is not caused by a wrong bootloader I also checked my suggested SysEx sequence, and noticed, that an error won't be sent as expected. Problem is, that the core will be reset before the last byte (F7) is sent out. However, following sequence should return an error response, could you please try it? f0 00 00 7e 40 00 02 7f 00 00 01 11 22 33 44 55 66 77 00 00 00 00 f7 Best Regards, Thorsten.

Hi, there are no modifications required for +/- 5V, the TL074 works fine in this voltage range. Best Regards, Thorsten.

so, thats definitely not a PSU problem. Unfortunately you forgot to answer my other question (who has programmed the PIC) Best Regards, Thorsten.

there is too much code which would need to be changed. It's less effort to reprogram the application from scratch in C, with your special usecase in mind... Best Regards, Thorsten.

Ok, one idea: what happens when you send following MIDI message to the PIC (you can use the SysEx tool of MIDI-Ox): F0 00 00 7E 40 00 02 00 00 F7 Best Regards, Thorsten.

I fear that the LTC module only increases the complexity (especially on today PCs), so continue with a normal MIDI interface. I must say that I'm out of ideas! Who has programmed the PIC? Maybe it's a wrong bootloader or PIC ID? Best Regards, Thorsten.

I would propose to continue with the MIDI troubleshooting guide - which one of these tests is working, which one not? http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten.

I don't think that changing the PIC ID will help here, because the EUSART bug affects the MIDI Out port, and not the In Port. It seems like the PIC doesn't receive the MIDI data, accordingly it sends an upload request again. Thats strange, especially because the same core module works ok with a PIC18F452 device ID is 00 - correct, so the bootloader should be addressed with incoming code blocks, sent to device ID 00 (default) Could you please try different upload approaches to give me more input, what is going on here? E.g., try it without feedback, try to upload a normal application w/o MIOS (program won't be executed... this is just an upload test) Best Regards, Thorsten.

Ja - schaue einfach mal in den Schaltplan: http://www.ucapps.de/mbhp/mbhp_opl3.pdf, dort findest Du die Signale wieder. Gruss, Thorsten.

With preinstalled MIOS it's normal that you get only a single upload request during power-on. Accordingly the MIDI Out stays at 5V so long nothing is sent Best Regards, Thorsten.

It could be a power related issue. Your PSU might be strong enough, but what about the 100nF bypass caps? Do you have a core module, where they are already available? If not, just add them at the bottom of the PCB Best Regards, Thorsten.

this is a calculation error in the script which has generated the table - with the lowest setting, one period takes 65536 update cycles -> 65536*0.00081 = 53 seconds -> 0.018 Hz Best Regards, Thorsten.

In order to highlight, that there are more MIOS based projects to explore than the ones hosted at ucapps.de, I added following projects to the navigation bar: AC Sensorizer and MIDIbox SpeakJet made by Audiocommander MIDIbox KB made by Bill Traktorizer made by MTE Selektor II made by Wild Weasel MIDIbox UC (project made in University of Ilmenau) There are some additional "Work in Progress" projects in the Wiki, which I will add once a firmware has been published, and the documentation has reached a state which allows to reconstruct the hardware (please inform me) I removed some old PIC16F based projects from the navigation bar, as they are expired and cannot be supported in future anymore. Just only for the floorboard no MIOS based replacement is available so far - here I would like to see a similar (and especially much more flexible) solution made by a user. Best Regards, Thorsten.

Excellent! So, the module itself is working, it could be a windows issue :-/ (sorry, I'm out of ideas what else could help to get the driver running) Best Regards, Thorsten.

You should see the ID 0547 - this is the official vendor ID of EZ-USB Would it be possible for you to test module on another PC? Best Regards, Thorsten.

It isn't a configuration problem - it's very likely that one of the connection is faulty. You can easily measure the voltages at the outer pins of each pot, and you can measure the voltage between ground and the middle pin - these are the voltages which are converted by the internal ADC of the PIC. This should help you to locate the error Best Regards, Thorsten.

Hallo, hast Du die Verbindungen zum MBHP_OPL3 Modul mit dem Interconnection Test, oder nur visuell ueberprueft? Das Audio-Signal koenntest Du auch an I3+/I4+ von IC3/5 abgreifen - vor den OPs ist es noch sehr leise. Im default patch (der waehrend des Firmware Uploads in das interne EEPROM geladen wird) sind alle 4 Kanaele aktiv. Gruss, Thorsten.