philetaylor

Also, to make you feel better. I may now "officially" be a Guru but I have made similar mistakes.... Here is a picture of the mess I made of one of my CORE32 PCB's: On the left, you will see an aborted attempt at desoldering a regulator with a snapped pin (I bent it round and it snapped) My iron was too cold and I ripped two of the pads off. It isn't neat but I replaced the broken tracks with wire links further down the track. On the bottom you will see the result of trying to remove one of the LCD sockets with the same crappy soldering iron. I lost so many pads that I haven't even bothered trying to sort this out as luckilly the PCB has 2 LCD sockets ! Other than having only 1 LCD socket and looking like a bag of sh*t, this CORE32 works perfectly My point is, unless you really really screw up, most things are fixable Phil EDIT: I forgot to mention, I threw that soldering iron away. I would recommend a temp controlled soldering station, the best that you can afford!

Hi Philippe. The transparent material that comes out of the solder is called the flux. This is added to most solder to help it to bond to other metals. Often if you over-heat a connection, the flux disappears and that can cause a dry joint (one where the solder hasn't bonded correctly). The PCB has what is called a solder mask, this is the protective coating over everything other than the solder pads which is an insulator. It is difficult to tell whether there is a bridge without cleaning the excess flux off the PCB (get an old toothbrush), it does look like there could be one from the picture. There also seem to be lots of scratch marks around the pads as well which could have scratched through the solder mask. EDIT: Yes you have really made a mess of the other PCB :( Cheers Phil p.s. 500 posts, now I am a Guru !!!!!!

Hi. Is there any reason you want to communicate with a Linux program to control the lights? I have created a DMX module for MIOS32 that works well and allows the CORE32 to talk DMX! There is also a CORE8 version that uses a rewritten IIC_MIDI firmware to talk DMX. I currently have it working as a simple lighting desk using the guts of an old Strand board.... Take a look at http://www.midibox.org/dokuwiki/doku.php?id=midiboxdmx I have to admit that things have slowed down a bit on development recently but eventually I hope to have a fully featured desk with moving light control etc. Also using the MIDIbox ETHernet interface, it will be able to talk to other devices over OSC and Art-Net etc. I also aim to support RDM for automatic fixture configuration. With regard to faders, buttons etc obviously they are easy for MIDIbox to support! Cheers Phil

If the PIC isn't installed, I really can't see how you can possibly have a short on all 3 CORE boards unless as you say, you have made the same mistake on all of them! Looking at the circuit diagram for the core, J9:SI connects directly to pin 20 of the PIC and has a pullup to 5v via a 10K resistor (R9). It should have no connection at all to Vs. Looking at the quick view of the layout on ucapps.de, J9:SI looks to be connected by a very fine track which runs between the other pins so if you haven't been particularly careful with your soldering iron, it would be easy to accidently bridge some solder over the tracks. Vs is the thick track that runs most of the way round the outside of the PCB so make sure that there is no solder bridge between J9:SI and it. Thanks Phil

MIOS32 already has all of the code required to use OSC but it will always take some coding to make use of it. I guess that TK will add OSC support to most of the "standard" MIDIbox apps where it makes sense to add it. Of course, the issue is related to implementation, there still isn't really a "standard" for OSC so it really depends on what your client expects to receive. Here is "one implementation" (from the OSC example app) which sends a pot value as an OSC "bundle". MIOS32 already has all of the functions required to "build" the packet. s32 OSC_CLIENT_SendPotValue(mios32_osc_timetag_t timetag, u32 pot, float value) { // create the OSC packet u8 packet[128]; u8 *end_ptr = packet; u8 *insert_len_ptr; end_ptr = MIOS32_OSC_PutString(end_ptr, "#bundle"); end_ptr = MIOS32_OSC_PutTimetag(end_ptr, timetag); insert_len_ptr = end_ptr; // remember this address - we will insert the length later end_ptr += 4; end_ptr = MIOS32_OSC_PutString(end_ptr, "/cs/pot/value"); end_ptr = MIOS32_OSC_PutString(end_ptr, ",if"); end_ptr = MIOS32_OSC_PutInt(end_ptr, pot); end_ptr = MIOS32_OSC_PutFloat(end_ptr, value); // now insert the message length MIOS32_OSC_PutWord(insert_len_ptr, (u32)(end_ptr-insert_len_ptr-4)); // send packet and exit return OSC_SERVER_SendPacket(packet, (u32)(end_ptr-packet)); } Cheers Phil

If you are building TK's variant (which I think you are) then if you look in setup_808_mbseqv3_tk.asm (within the midibox_808_v1_1a.zip file) it tells you exactly how everything should be connected. Also http://www.ucapps.de/midibox_808.html tells you how the buttons should be layed-out. Phil

When you say you have "ruined" the PCB. Do you mean that you have lifted a track (or 2)? This can usually be fixed with some link wire (or cut leads from other components). What type of soldering iron are you using? It may be too hot as you shouldn't lift tracks unless you left the iron on the track for a long time. What is wrong with the other 2 CORE PCB's that you have failed to build? Do you still have them? It may be possible to fix one of those? I really hate to give up on this sort of thing and I have repaired PCB's before that others wanted to throw away because they had burnt out or lifted tracks. The result never looks particularly neat but if it works, so what :) Although the picture wasn't "that" clear, the soldering didn't look too bad to me, other than the common mistake of too much solder on some joints. A good joint should look like this, slightly rounded but not a "ball" of solder: Cheers Phil

Looking at the picture, it is quite messy under J9. It is quite possible that the "mess" is causing a short. I would try cleaning the PCB with an old toothbrush and some alcohol based cleaning solution first. There are some other joints that appear to have a bit too much solder on which could be causing a "bridge". A similar shot of the top of the PCB would also be useful (to make sure everything is in the right place!) I don't want to make you feel even worse but I have built Cores from both Mike and SmashTV and never had a problem so i'm sure it is something that can be fixed :) Cheers Phil

The point is that blue LEDs can cause eye damage that you might not see (until you can no longer see !!!!!) http://texyt.com/bright+blue+leds+annoyance+health+risks is quite a good article on the subject. Cheers Phil

Hi Wilba, I should hope so, the binary was built with MSVC running on Windows 7 x64 :) Juce (the class library that it uses) does have a bit of a mac "look and feel" I think this is because it doesn't use any of the native controls (so it looks the same on windows/mac and linux! Cheers Phil

I assume that is a question :) OSC is working with the STM32, there is a sample application that works as a simple OSC client/server but it doesn't really do anything useful. None of the 'proper' apps currently support OSC (yet!) It would be (fairly) easy to add OSC support to the new Midibox LC though. Sorry I don't know, I don't use ProTools. Cheers Phil

That sounds like a "short" to me, There should be a very high resistance between SI and VS, as it has a 10K pullup, there shouldalso be 10K ohm between SI and VD. If you remove the PIC, does it still read 15ohm between SI and VS? if so there is a short somewhere on the board. Cheers Phil

If you are really struggling, you could try the new MIOS Studio MkII beta. If you send a PM to TK he may let you download it and give it a go. It is an early beta so usual disclaimers apply, it may cause your computer to self destruct and your house to fall down.... or it may just fix your problem :) Cheers Phil

Hi. Firstly, as the CORE32 PCB is supplied by SmashTV with the STM32 presoldered, it is no more difficult to construct than the CORE8. Obviously though, mb_seq_v3 has been more thoroughly tested and most of the bugs have been ironed-out over the last few years whereas v4 is still in a beta stage and pretty new! In answer to your question, MBHP_IIC modules are daisy-chained (IIC is a bus topology) and each IIC module must have a unique address (selected by J3). The best option is probably to use ribbon cable with IDC connectors as you can then put as many connectors on cable as you need. Another point though, as the CORE32 has 2 MIDI in and out ports, if you did go for it, you would only need 2 MBHP_IIC modules..... Thanks Phil

As the GM5 is a pre-programmed Atmel AVR, the MIDI (serial) port speed will be referenced to the clock speed, it may work but the MIDI speed would be 35154 baud (and not 31250) so it wouldn't be able to talk to anything :) Phil EDIT: It probably wouldn't work as 8Mhz (16/2) is the maximum clock speed of the AT90USB162 Phil

Phew... Complicated is certainly the word, up to 1584 POTs! I believe that would make it the largest MIDIbox ever made :) I don't want to sound negative but this is going to be fairly difficult to implement using MIDIbox hardware modules, each AINx4 module supports up to 32 analogue inputs and you are not going to be able to daisy-chain 49 of these.... Also the CORE32 currently supports a maximum of 16 motorfaders! You are either going to need multiple CORE32s or design new hardware modules (and write drivers for them!). If I was going to attempt something like this, I would probably use encoders rather than POTs where possible as with POTs you can get jitter problems, especially as the CORE32 operates at 3.3v. Do you anticipate this "just" being a controller or do you plan to incorporate audio mixing as well? If so you may want to look at the MIDIbox mixer project http://www.midibox.o...id=midiboxmixer Also, how are your programming skills? You would definately need to do quite a lot of coding to achieve this! On the positive side, none of the current MIDIbox projects have exceeded the capacity of the STM32 so it may well be possible to achieve much of what you desire :) Cheers Phil

What happens when you try to upload? What do the MIDI Monitor screens show? There are problems with MIOS Studio  and the (to quote Wilba) "crappy Mac Java MIDI library". This could be what you are seeing, there has been mention on the forum of installing the latest version of Mandolane http://www.mandolane.co.uk which is much better than the standard Java MIDI library If this doesn't work, TK is currently writing a version of MIOS Studio written in C++, an early alpha release is available for developers which TK may let you try.... Uploading an app to the Core, requires the MIDI subsytem being able to reliably transfer large sysex streams. Many implementations (both operating system and manufacturers drivers) seem to be quite poor at this which I find amazing! Cheers Phil p.s. As nILS has suggested, you should also double check all connections/components round the MIDI ports :)

I believe that the MIDIbox Plus was one of the first projects that TK created and pre-dates MIOS! it was created in the late 90's!!! http://www.ucapps.de/midibox_plus.html has some information but as LyleHaze has said, you may be lucky to get any support for such an old design. All of the current projects use either 16bit PICs (PIC18f452 and compatible) or the newer 32bit STM32! Thanks Phil

Did you modify the app_lcd line in the Makefile: # include application specific LCD driver (dummy driver by default) include $(MIOS_PATH)/modules/app_lcd/t6963c_h/app_lcd.mk Cheers Phil

That's great :) Not so great :mad: I am not using MicroSDHC but I guess it is the same technology as SDHC and the mods that I made to the MIOS32 driver were tested on a 4GB SDHC Now this is the question.... I have never tried but I will give it a go when I get home. My MB SEQ is running the latest CVS version. I have various different types of SD/MMC card so I will give it a go. I guess that this is a bit beyond the usb-msd mode goals of providing an easy method of copying files to and from SD cards though :) It 'may' work :) MBSEQ wouldn't be able to use the second partition though... The msd module is an adaptation of the ST example code and is actually quite complex (it emulates a SCSI device!) but I don't know how thoroughly things like formatting have been tested (if at all!) Cheers Phil

According to the datasheet for the T6963C, it is (NOT)Chip Enable so MUST be low to enable communications. I think the problem that you have is the RESET is also (NOT)RESET so must be High (tied to 5v) for normal operation. It has in internal pullup so it could also be left floating. Cheers Phil

Farnell offer free delivery (and have the TLV5630 in stock for less than RS): http://uk.farnell.com/texas-instruments/tlv5630idw/12bit-dac-smd-5630-soic20/dp/8455775 Cheers Phil

You should be able to leave reset tied to ground but I guess CE would need to be tied to 5v to enable the chip? FS is used by the internal font generator. The level of this pin doesn't matter as MIOS only supports graphic mode for this display type (MIOS used its own fonts). Cheers Phil

Hi. There are many people on here that are more than happy to help people that are new to MIDIbox (and some not so new!) but what most people expect is for people to read as much as they can from http://ucapps.de http://wiki.midibox.org/ and from this forum, you will find the answers to everything you ever wanted to know about MIDIbox (and a lot you probably don't want to know) in these 3 areas but things do take a bit of searching for sometimes. We are all busy building our own MIDIboxes so it is generally considered polite to at least do a bit of research before asking questions. For example, http://www.ucapps.de/mbhp_din.html and http://www.ucapps.de/mbhp_dout.html tell us that the DINx4/DOUTx4 modules each have 4 shift registers which each support 8 digital inputs/outputs so a 64 button monome would need 2 x DINx4 and 2 x DOUTx4 modules! If you want OSC support then the MBHP_ETH module would be useful as well. At the top of the forum screen, there is a search button, if you search for "monome" you will get 224 results, so yes it has been discussed on here quite a bit :) The first page of results show at least 2 people that are/were building monome clones! Edit: Oh an by the way the MIOS is written in PIC assembler and MIOS32 (for the STM32 core) is written in C Cheers Phil

I had never noticed that there is a seperate MBCV app! just shows, I thought that I had read everything there was to read on ucapps.de. I suppose as I have never needed CV outputs for any of my projects it passed me by :) Cheers Phil