TK.

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.

Yes, the resolution is very poor and you can hear some zipper noise when the volume is modulated. On the other hand some cool stereo effects can be realised - like this one: http://www.midibox.org/midibox_sid/mbsidv2_demo2.mp3 Who needs a Leslie? ;-) Best Regards, Thorsten.

which voltage do you measure at the outer pins? Could it be that it changes? It should always be 5V Best Regards, Thorsten.

In order to exclude that this is a configuration problem, please check the pots with the ain64_din128_dout128_v2_0 application. Each pot should send an individual MIDI event: B0 <pot-number> <value> Best Regards, Thorsten.

Maybe the wrong encoder type is selected, you have the choice between three types: http://www.midibox.org/dokuwiki/doku.php?id=encoder_types The type can be changed for each encoder individually in mios_tables.inc Best Regards, Thorsten.

You could send the modulation wheel event with the virtual keyboard of MIOS Studio Best Regards, Thorsten.

Hi Max, the described effect sounds like there is a problem in the 12bit->8bit conversion, but my problem is, that I'm not able to test this so easily anymore, since my AOUT_LC modules are configured for 12/4 bit mode, and built into a case. The register upload routine is located in cv_aout_lc.inc, CV_AOUT_LC_LoadAOUTx_8_8 It looks clean, and so far I remember, I tested this before the v1.1 release... :-/ Could you please doublecheck, that your AOUT_LC module is really configured correctly? S&H: this would require a refresh of the S&H stages each milisecond. I never tried this with MIDIbox CV, but I fear that continuous register accesses would add some permanent noise. In general I noticed that the digital noise is extremely low when MAX525 are used. I'm not an analog expert, but maybe there are possibilities to improve the circuit by adding filter networks (R/C/L)? Best Regards, Thorsten.

Fine that the module is working now! :) Btw.: the LCD shows [tt]Sl1 Sl2 Sl3 Sl4[/tt] for Slave 1/2/3/4 SysEx commands to MIOS are handled in a special way, they won't be reported to the application, accordingly they cannot be forwarded to the IIC slaves. So - I think that the modules are ok :) Best Regards, Thorsten.