kpete

Hi all, I am modifying the Midio128 V3 software for an organ project. This unit will add Midi voices to an existing Rodgers 840 electronic organ. I want to save my stop information in the EEPROM on the LPC board rather than on the SD card since it might not be available all the time. I understand how to add it to my build since Midio128 doesn't use it at all. My question is: Do I have to worry about any reserved addresses that might be used by things like the boot loader? And has this software been used in other projects and found to work? Pete

I haven't seen this issue at all. In fact if Mios Studio is untouched and I recompile, all I have to do is press START to load the new code. Every time my code changes didn't upload, I forgot to do the file SAVE in Notepad++. Are you sure your pointing to the newly compiled HEX file? I've done this to. Pete

Hi TK, I went ahead and did some testing. I have an HP Pavilian running Windows 7 - 64 bit. I thought that the best test would be to copy the MIOS Studio executable code to my LPC SD card and back again using the browser in MIOS Studio. So I uploaded and then down loaded the same .exe file. This worked fine even with the file size of 2.9meg. I then ran the copied exe and it performed as expected so I would say it's a go. I did see something that was confusing and it had to do with deleting files on the SD card using the MSD mode and doing the upload/download functions with MIOS Studio. During this testing I had deleted a file on the SD card called MIOS_Studio.exe using the MSD file function. I then tried to copy this same file name from the PC to the SD card using the file browser. Problem was that it didn't let me do it. I suspect that the MidiBox software thought the file was there even though it wasn't displayed on the browser window. After I changed the target file name to MIOS_1.exe, this file copied fine. Maybe I shouldn't even talked about this little issue :sad: Pete PS-And I used the "Rescan MIDI Devices" a lot to get the ports working again after going into MSD mode and having to remove the USB cable get out of MSD mode without restarting the MIOS Studio application. Please don't remove this.

Thanks for responding so quickly TK. So its working correctly. I was having problems understanding when these options can be entered. Very little information found on how to set these options, only what they do. Maybe I just don't know where to look. My real problem was that when I entered "set single_usb 1", I thought it was set and would just load the application. Didn't even know about the "STORE" command which isn't mentioned in the bootloader documentation. The only reason I thought to investigate further was due to the message that said "Forcing of a Single USB port enabled after 'Store'. I then entered the store command which made all the difference in the world. Pete BTW-The USB port is working great now that I have set the single port option. I did try powering 2 MidiBoxes on at the same time with some problems but didn't change the device ID so I expected some problems.

I'm not sure whats going on but am having issues with getting the "set single_usb 1" command to work. I have been installing Bootloader V1.012 into the LPC unit with jumper J27 installed. I then remove the jumper with power on and it goes thru a process that looks like its copying the code into the shadow Boot ROM then see the "Up to Date message". Unplugging the LPC unit and restarting MIOS Studio 2.4.2 seems to work properly. When I query the core with only boot loader loaded, I see a message that says "Bootloader 1.012" on the second to the last line of the message window. The "set single_usb 1" commad is recognized. Problems start to happen when I load Midio128 V3.015. This code seems to be overlaying the new boot loader with an older version for some reason. After loading I get an error of "Unknown set parameter: 'single_usb" when I try to set it again. Now if I power the LPC unit down and instert J27 back into the board and power it up again and do a query, it shows a message of "MIOS32 Bootloader" without any version number and the last line (Copywrite line) shows as "© 2012 T. Klose" rather than the 2013 copy write message. Am I doing something wrong or do we have a problem? Pete

They are available. Sparkfun has them but they are a little expensive. https://www.sparkfun.com/products/11122 A friend of mine found some for under $3usd. Check around on the web and you should find them. Maybe your not finding them because you are googling 2x8. Try 8x2 LCD display.

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

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

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

I hope the MDS function is not removed from the Midio128 V3. It is working fine with the new boot loader that supports the 4 USB ports. It is very important to also install the GM5 driver midibox.org_gm5_X64_1.0.10.zip if you want to use any USB ports on the Windows 7 - 64 bit machines. If its not installed, then it is very difficult to get the USB ports to connect properly and Mios Studio won't work reliably. You can tell its installed because the port names are shown as "GM Port 1-4". Pete

Why don't you just clear the port bits for the Din/Dout definations and see if it fixes your problem.

Hi John and Duggle, I must agree with your elimination of ground loops by not grounding the 12volt common point to the frame ground and not putting a common ground on the LPC board. My original suggestion to put a frame ground at the 12v return point was for safety reasons only and not ground loop elimination reasons. Pete

Since you are driving LED's, and if you are using the Dout board from SmashTV, you can just remove the resistor networks and insert the uln2803 darlington driver chip. It will invert the signal for you. This link show how to insert the new IC's. http://mbhp.avishowtech.com/mbhp_doutR5.html You will have to put external resistors in series with the LED's. As far as inverting the inputs, maybe TK already has a solution for you. I don't know for sure but I believe I saw this added to Midio128 about a few months ago. Another hardware solution might be to just insert 1 inverter in series with each SO and SI serial data lines going to/from your core processor. I would vote for the software solution but thats because software doesn't intimidate me. Pete

When I said floating I mean it sounds like there is a floating pin somewhere on the Dout board or the chain. Maybe its a curled up pin or a socket pin thats not soldered. I noticed on the matrix J1 & J2 board connectors the RC signal is not passed thru on all of the pins. The pin 9's are missing on one side but this is on the Din side of the chain of the matrix board so it shouldn't be a problem. It uses the signal from the Dout RC signal for this. I haven't noticed any notes not playing, or pistons not working. This is the first time that you ever talked about the keyboards working properly. Thats great! I was worried that these might be affected by the firing of the SAM magnets.

if I put my finger in close proximity to the back of the first DOUT stage,74hc595 and Uln2803, the sams connected begin to randomly jump back and forth from on to off. Removing the finger, it stops. Boy this sure sounds like you have a floating input pin somewhere. Pete

Hi John, You have gone thru a lot of work getting to where you are now. The block diagram speaks for itself. What you might do is totally isolate the SAM contacts from going to J-organ/Artisan sound engine by pulling the Midi1 cable from the LPC17 board. Then start punching stops on the J-organ panel and see if all of the stops work with your setup. Even try pushing pistons on the screen to see if the proper stops get set. What I want to eliminate is issues with the input switches sending spurious or wrong values. And I notice there is a cable on the LPC Midi2 out connector. What is this for? Maybe just disconnect it since all I want to check is the output functions from J-organ to the SAM's. Don't want to cloud any issues with inputs going into J-organ at this time. Something else that you should also be aware of is that there are 2 different types of SAM's. +common and – common types. The coils between the 2 types are wired in reverse as far as polarity. You have the SAM wired in a “+common†mode. If you use the wrong SAM type for your system, the SAM's will not snap from 1 state to the other efficiently. They may work but not with as much power due to the magnet orientations. Another issue is that the SAM's are more prone to having cross-talk issues between a neighboring SAM. This means that when you active the coil on SAM-1 that the switch contact on SAM-2 might open or close for just an instant and give bad signals to the input board. Pete

Hi johnc, As far as the pin 10 current, I just wanted to make yourself aware of this. Its not continuous, just a spike due to the SAM coils being turned off. Using the ribbon cable with #28 wire doesn't seem large enough but because of the short duration, it should be OK. Problem is that the currents can couple into other wires that parallel the wires going to the SAM's. As far as the MIO-Matrix issue, I don't know if switching them around would help. And do we know that we have a problem here. It could be an issue like bundling the SAM switches and magnet wires together in one bundle. I don't know what software is driving the SAM chain but I would try to disable anything that reads the SAM switches and outputs Midi messages. This way you can use the J-organ panels on the PC to send Midi messages to your SAM processor to physically change the SAM state. With the SAM switches disabled, there wouldn't be an issue of the SAM processor echoing back unrelated switch states that were triggered by any noise. I suspect this is your DIO-Matrix but don't know for sure. Pete

Most of the front and back of the LPC17 PCB is ground which should be a good ground almost anywhere. But I would put it on the minus side of big capacitor C8. With it laying down, the extra ground wire can be soldered to the cap wire going to the PCB. As far as random Dout's turning on and off, this is why you need all these extra ground wires going to all of the Dout boards. They must not be daisy chained like they are normally hooked up. Something else that worries me is that you have a DIO-Matrix board between the LPC17 and your Dout chain. It so happens that just before reading the Din chain, the shift registers are loaded with the RC strobe signal. This same signal also strobes the Dout shift registers into the output holding registers. So when the outputs are changed to the SAM's, the input shift registers are being loaded at the same time. Could there be noise getting into the Din chain of the matrix board? I would also try to put a 10uf (or larger) across the 5v of the problem Dout chain and see if it improves things. One thing that I would check is that pin 10 of all the uln2803's are connected to your +12 power supply. I am sure you did this since you are not blowing up any of the 2803 chips. Just so you know, there are current spikes of 2 amps on pin 10 of the uln2803 when 4 of the SAM magnets on the same chip are turned off at the same time. Pete

Question; So what happens if the 12vdc comes on before the DOUT shift register is initialized. One indication is the SAM's might change state when power comes on. With the 74HC595's reset line tied high, there is no guarantee what the outputs will look like. On my LPC17 I have LED's on the Dout board and see the lights come on for about 1 second if I pull the USB cable then plug it back in after waiting about 5 seconds. If the LPC hasn't been plugged in for some time, I see the LED's are generally off, but not every time. With that done, is it necessary to put another ground on the LPC? This is where I said BUT in my previous message. I would add this extra wire to the LPC17 and if it works, leave it in. I do understand there is potential for ground loops with this due to the ground in the ribbon cable going to the Dout chain. At least this will keep any noise introduced by connecting the PC ground to your LPC17 from going thru the LPC17 to the Dout chain. With it grounded the noise from the PC will be directed to your common ground (star) connection. In a perfect world I would say leave the whole ground signals floating with reference to each other, but with a PC on one side of the LPC17 and a high current 12v power supply on the other, it ain’t going to be perfect no mater what you do. As far as the resistors on the output of the 595's, just don't connect anything to them. These are outputs and not sensitive to being unloaded. PS-I think it would have been better to have this thread placed in a separate topic rather than the generic Midio128-V3 area. Pete

Hi John, I don't want to throw another wrench into your project but there is another problem that I don't think you have seen yet. When power is applied to the Dout cards, the state of the output registers are not guaranteed to be set in the off state. I also wish that SmashTV would at least place a very large solder pad on the ground side connection of the board for high current applications. It would also be nice if another pad could be added for the output enable pins for the 74hc595 pin 13. Being able to cut 1 trace on the PCB and adding a single wire to control the enable pins from an external source would give more options for projects like this. Right now your only option is don't apply the 12 SAM power until the Dout chain has been initialized. On my project this looks to be about 1 second. As far as grounds to the Dout cards, I would do as TK suggests. I would connect at least an 18awg wire to each Dout card and connect them to 1 common point with wires as short as possible. I don't like connecting another ground to the LPC17 card since it introduces a ground loop between the SAM's and the ground wire in the ribbon cable BUT I would go ahead and add this LPC17 ground wire anyway and see if all works without problems. If it does create problems, remove it and see if the problems go away. P.S. If at all possible, make sure that the 12v 20amp power supply is isolated from protective ground. The minus (-) wire of this supply should go directly to your Dout common ground and nowhere else. Pete

Thanks.

Thank you Thorsten, That answers why the site looks like it goes down. This whole exercise caused me to look at the install documentation at http://www.midibox.org/dokuwiki/windows_toolchain_svn. It indicates to load TortoiseSVN-1.4.8 I currently have the latest version of 1.7.11. I uploaded this new version about 2 weeks ago because I kept getting messages to update it. Is it OK to use this newer version or should I go back to the older one. Pete

OK Peter, I am going to try to update my Midio128_v3 directory that has only 28 files in it. If that works I will be trying to update my entire tree since I think I have an issue in one of the module functions. I'm going to do this at 1:30 AZ time. Which is about 3 min. from now. Hope it doesn't create problems. Pete

Hi Louis, Have you tried to connect only your DOUT chain to the J8/J9 connector and then from MIOS STUDIO typed in the command “set dout all 1†to your LPC17 core and see if this works? I suspect that you have the older DIN card R4 or earlier that has a wire missing to rout the output data thru the DIN card. The following came from the change log of the DIN board R5 from SmashTV. Routed SO from J1 to J2 (so a DIN:DOUT chain is possible) To fix this add wires to all your DIN cards on the SO pin. This should allow you to dassy-chain your Din & Dout cards. Pete

Hi Peter, My real name is Pete Knobloch. In English the K is silent. An old girl friend gave me a nickname of Kaa-pete and I decided to use it as my user name here. Of course being German you should know what Knobloch is. Back to the issue. If it is my problem, I don't want my testing to impact or compromise the forum server if it does cause the site to crash. Yesterday it seemed to be down for a long time. This morning only for less than 1 hour. I don't know where the server is or who is responsible for it. Would just want some direction before I try to do an update to my hard drive again. Pete